Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru.
Продолжаем рубрику Заметки о MySQL, в которой я уже успел рассмотреть установку и настройку MySQL сервера баз данных, а также рассмотрел способы изменения кодировок сервера MySQL при помощи команды SET NAMES и файла конфигураций my.ini.
Сегодня будет краткая и если можно так сказать теоретическая статья, посвященная вопросу — что такое базы данных и какие базы данных бывают.
В этой статье я постараюсь изложить кратко какие виды и типы баз данных бывают и остановлюсь на некоторых из них более подробно.
Мы поговорим о структуре иерархических баз данных, уделим внимание структуре сетевых баз данных, и более подробно остановимся на структуре реляционных базах данных, рассмотрим особенности реляционных баз данных.
И в конце статьи немного затронем тему проектирования баз данных, естественно реляционных, так сервер MySQL это по сути математическая модель реляционных баз данных. Проектирование баз данных и типы данных, с которыми может работать MySQL сервер — это темы для последующих публикаций.
База данных. Математические модели, структура, определение
Я хоть и не собираюсь на своем блоге подробно рассказывать про математические законы и теории описывающие реляционные базы данных, но принцип того, как они устроены я рассказать должен, если вас заинтересует данная тема, то вы всегда можете посетить специализированный математический ресурс или почитать соответствующую литературу, а можете всегда задать вопрос в х к данной публикации, и я по мере своих возможностей постараюсь вам ответить. Как я уже говорил, тема данной статьи – реляционные базы данных. Я постараюсь ответить на вопрос, что такое реляционные базы данных простым и понятным языком. Затрону основные понятия, относящиеся к реляционным базам данных, терминологию, историю возникновения баз данных вообще и реляционных в частности.
Наверное, самое простое определения баз данных, база данных – это упорядоченное хранение какой-либо информации. То есть, информация хранится в упорядоченном или систематизированном виде. Видов систематизации, упорядочивания и хранения информации может быть множество.
Каждый из способов хранения информации отвечает каким-либо специфическим требованиям или предназначен для выполнения каких-либо определенных действий. На страницах своего блога я уже писал, про язык XML, данные в XML структурируются в виде дерева с разветвлениями, узлами и корнем. Но это лишь один из множества способов хранения информации.
Более подробно обо всем этом читайте в рубрике Заметки о XML и XLST.
Виды и типы баз данных
Как я уже говорил, видов и типов баз данных очень и очень много и описать их все в данной публикации я просто не смогу, но самые распространенные виды хранения информации или виды баз данных я постараюсь описать. Понятно, что база данных хранит в себе информацию о каких-то объектах, например, информацию о товаре в интернет-магазине. Любой товар в базе данных – это объект с какими-то определенными параметрами и свойствами. Перейдем к конкретным примерам.
Иерархическая база данных, структура иерархических баз данных
Иерархическая база данных – каждый объект при таком хранение информации представляется в виде определенной сущности, то есть, у этой сущности могут быть дочерние элементы, родительские элементы, а у тех дочерних могут быть еще дочерние элементы, но есть один объект, с которого все начинается. Получается своеобразное дерево. Примером иерархической базы данных может быть, документ в формате XML или файловая система компьютера, пример с файловой системой компьютера я приводил, когда рассматривал структуру XML документа, в рубрике Заметки о XML.
Следует сказать, что базы данных подобного вида оптимизированы под чтение информации, то есть, базы данных, имеющие иерархическую структуру умеют очень быстро выбирать, запрашиваемую информацию и отдавать ее пользователям.
Но такая структура не позволяет столь же быстро перебирать информацию, тут можно привести пример из жизни, компьютер может легко работать с каким-либо конкретным файлом или папкой (которые, по сути являются объектами иерархической структуры) но проверка компьютера антивирусам осуществляется очень долго. Второй пример – реестр Windows.
На рисунке вы можете увидеть структуру иерархической базы данных, в самом верху находится родитель или корневой элемент, ниже находятся дочерние элементы, элементы, находящиеся на одном уровне называются братьями, ну или соседними элементами. Соответственно чем ниже уровень элемента, тем вложенность этого элемента больше.
Сетевая база данных, структура сетевых баз данных
Сетевые базы данных, являются своеобразной модификацией иерархических баз данных. Если вы внимательно смотрели на рисунок выше, то наверное обратили внимание, что к каждому нижнему элементу идет только одна стрелочка от верхнего элемента.
То есть у иерархических баз данных у каждого дочернего элемента может быть только один потомок. Сетевые базы данных отличаются от иерархических тем, что у дочернего элемента может быть несколько предков, то есть, элементов стоящих выше него.
Для большей наглядности и понимания структуры сетевых баз данных обратите внимание на рисунок:
Стоит заметить, что сетевые базы данных обладают примерно теми же характеристиками, что и иерархические базы данных.
Но, в данной рубрике нас не сильно интересуют иерархические и сетевые базы данных, данная тема больше относится к формату XML, и возможно в рубрике посвященной языку расширяемой разметки, я постараюсь более подробно рассмотреть эту тему.
А в рубрике посвященной MySQL нас интересуют реляционные базы данных, на которых мы и остановимся более подробно.
Реляционные базы данных, структура реляционных баз данных
Реляционные базы данных получили очень широкое распространение и многие пытаются писать огромные статьи, посвященные вопросу – почему реляционные базы данных получили такое широкое распространение, делают глубокомысленные выводы и замечания. Но на самом деле все очень просто – реляционные базы данных очень легко описываются в математике, то есть, под них очень хорошо написана математика.
Был когда-то такой математик – Эдгар Франк Кодд, умерший в 2003 году, который в восьмидесятых годах очень подробно описал структуру реляционных баз данных математическим языком.
А если есть хорошо написанная математика, то соответственно есть и программная реализация. Останавливаться на биографии Э.Ф. Кодда я не буду, для этого есть различные энциклопедии. Именно благодаря Кодду реляционные базы данных стали активно развиваться.
Поэтому-то, когда мы говорим базы данных, чаще всего мы подразумеваем именно реляционные базы данных.
Особенности реляционных баз данных
Главной особенностью реляционных баз данных является, то, что объекты внутри таких баз данных хранятся в виде набора двумерных таблиц. То есть, таблица состоит из набора столбцов, в котором может указываться: название, тип данных(дата, число, строка, текст и т.д.).
Еще одной важной особенность реляционных БД является, то, что число столбцов фиксировано, то есть, структура базы данных известна заранее, а вот число строк или рядов в реляционных базах данных ничем не ограничено, если говорить грубо, то строки в реляционных базах данных и есть объекты, которые хранятся в базе данных.
На самом деле, базы данных – это абстрактное понятие, таблица – это всего лишь способ хранения информации, набор таблиц может быть связан логически и этот набор называют база данных.
Поэтому неправильно говорить, что MySQL это база данных, база данных – это хранящаяся информация. А вот такое понятие, как СУБД – система управления базами данных, это и есть MySQL сервер, именно при помощи него мы управляем хранящимися данными.
Или иначе MySQL – это программное воплощение математических идей.
Самой трудной задачей при работе с реляционными базами данных, является проектирование структуры баз данных. Проектирование структуры базы данных, заключается не только в том, чтобы создать таблицу и указать тип данных и наименование столбцов. На самом деле проектирование – это самый сложный этап при работе с базами данных.
Потому что мощности ваших компьютеров ограничены. Пока данных мало, мало таблиц и строк в этих таблицах, машина будет их обрабатывать очень и очень быстро. Но, со временем количество информации будет увеличиваться, и мы получим замедление, которое будет увеличиваться, поскольку машине необходимо время на обработку тех или иных запросов(обработка информации).
В прошлой статье я уже писал, что реляционные БД прежде всего ориентированы на модификацию(OLTP), то есть, добавить новую запись в таблицу – это очень простая операция для реляционной СУБД, а вот сделать выборку данных, это уже трудоемкая операция. Также есть и изменение данных, это как бы промежуточное звено между чтением и добавлением.
Хотя MySQL сервер всегда можно настроить.
Проектирование базы данных
Ну что же, мы немного поговорили о достоинствах и недостатках реляционных баз данных. И теперь, вкратце, я затрону вопрос проектирования баз данных.
Под проектированием я понимаю следующее: садится человек за стол, берет бумагу и ручку, и исходя из поставленной задачи, а также, исходя из достоинств и недостатков той или иной системы, в нашем случае СУБД MySQL начинает составлять структуру будущей базы данных. Требование к проектируемой базе данных обычно ставятся следующее:
- База данных должна быть как можно более компактна, то есть, неизыбыточна.
- База данных должна быть простой с точки зрения обработки.
И как вы, наверное, поняли, данные требования противоречат друг другу. Проектирование — это самый важный аспект при работе с базами данных. Обычно, проектировщик – это опытный администратор сервера баз данных, либо архитектор баз данных, с большим опытом работы.
В серьезных проектах может быть несколько десятков, а то и сотен таблиц, которые связаны между собой самыми замысловатыми способами связи. Конечно, я не собираюсь углубляться в проектирование баз данных, да и не смогу это сделать, но, кое какие основы проектирования баз данных я попытаюсь осветить на страницах своего блога.
Прежде чем приступить к проектированию базы данных, нужно понять, а что мы вообще собираемся проектировать. То есть, должны понять, что у нас должно получиться на выходе.
А на выходе мы должны получить так называемую диаграмму или как ее еще называют схема. Диаграмма – это определение: какая информация будет храниться, в какой таблице она будет храниться, в каком столбце какой тип данных, как называется таблица, сколько столбцов в таблице и их тип, как связаны между собой таблицы.
Да, типы данных в столбцах могут быть разными, например, номер телефона или индекс можно записать, как с помощью символов, так и с помощью числового типа данных.
Но появляется вопрос: какой тип данных лучше для хранения номера телефона или почтового индекса? Чисто интуитивно на этот вопрос чаще всего отвечают правильно – номер телефона в базе данных должен иметь символьный тип, а вот объяснить, почему именно символьный тип могут немногие.
Объяснение очень простое, например, нам потребовались все почтовые индексы, начинающиеся на 637 или номера телефонов начинающиеся на 952, так вот, сделать такую выборку из данных имеющих числовой тип задача довольно проблематичная, а сделать такую же выборку из данных символьного типа довольно легко.
При проектировании баз данных очень часто встречаются такие задачи и поверьте, от того, как вы будете их решать, будет зависеть, то, насколько быстро будет работать ваша система, в следующей статье я продолжу вопрос проектирования баз данных.
На этом всё, спасибо за внимание, надеюсь, что был хоть чем-то полезен и до скорых встреч на страницах блога для начинающих вебразработчиков и вебмастеров ZametkiNaPolyah.ru
Источник: https://zametkinapolyah.ru/zametki-o-mysql/bazy-dannyx-vidy-i-tipy-baz-dannyx-struktura-relyacionnyx-baz-dannyx-proektirovanie-baz-dannyx-setevye-i-ierarxicheskie-bazy-dannyx.html
Проектирование реляционной базы данных — Базы данных
Этапы проектирования и создания базы данных
Для проектирования базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, определять все необходимые источники информации для обеспечения предполагаемых запросов пользователя и решаемых в приложении задач. Следует заметить, что базы данных обычно создаются средствами СУБД в области организационно – экономического управления.
Определение состава и структуры данных, которые должны быть загружены в базу, осуществляется на основе анализа описания предметной области. Этот процесс подразумевает создание модели данных.
Структура данных предметной области может отображаться информационно – логической моделью.
Если при построении такой модели обеспеченны такие требования нормализации данных, и она соответственно представлена в каноническом виде, то на основе такой модели можно создать реляционную базу без дублирования данных.
При разработке модели данных могут использоваться два подхода.
- Аналитический или процессный подход: сначала определяются основные задачи, для решения которых строится база, выявляются информационные потребности задач и соответственно определяются состав и структура информационных объектов модели, а также связи между ними.
- Интуитивный подход: сразу устанавливаются типовые объекты предметной области и их связи.
Наиболее рационально использование сочетание обоих подходов. Это связанно с тем, что на начальном этапе, как правило, нет исчерпывающих сведений обо всех задачах.
Использование такой технологии тем более оправданно, что гибкие средства создания реляционной базы данных в Access позволяют на любом этапе разработки внести изменения в базу данных и модифицировать ее структуру без ущерба для введенных ранее данных.
В процессе разработки канонической модели данных предметной области для проектирования реляционной базы данных необходимо:
- Выделить информационные объекты, соответствующие требованиям нормализации данных;
- Определить связи между ними.
При определении проекта логической структуры реляционной базы данных каждый информационный объект канонической модели предметной области адекватно отображается реляционной таблицей.
Логические связи между парой связанных таблиц отображают связи между информационными объектами и характеризуются отношениями типа один – к – одному или один – ко – многим. Такие связи устанавливаются по уникальному ключу одной из этих таблиц, которая является главной в связи.
Во второй таблице, которая является подчиненной, поле связи может быть либо частью ее уникального ключа, либо быть не ключевым.
В процессе создания базы данных (БД) на компьютере сначала осуществляется конструирование таблиц средствами Access. Далее может создаваться схема данных базы, в которой фиксируются логические связи таблиц. В схеме данных могут быть заданны параметры поддержания связной целостности данных, если модель данных была разработана в соответствии с требованиями нормализации.
Связная целостность данных означает, что в базе данных установлены и корректно поддерживаются взаимосвязи между записями разных таблиц при загрузке, добавлении и удалении записей в связанных таблицах, а также при изменении значений ключевых полей. При обеспечении связной целостности в подчиненной таблице не может существовать запись, для которой отсутствует связная запись в главной таблице.
После формирования в Access схемы данных можно приступать к вводу данных в базу – загрузке с документов предметной области, являющихся источниками данных.
Построение информационно – логической модели данных
Информационно – логическая модель (ИЛМ) отображает данные предметной области в виде совокупности информационных объектов и связей между ними. Эта модель представляет данные, подлежащие хранении. В базе данных.
Информационные объекты
Информационный объект – это информационное описание некоторой сущности предметной области – реального объекта, процесса, явления или события.
Информационный объект образуется совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики сущности.
Примерами сущности являются: товар, поставщик, заказчик, поставка, отгрузка, сотрудник, отдел, студент, преподаватель, кафедра и т.п.
Информационный объект имеет множество реализаций – экземпляров объекта. Например каждый экземпляр информационного объекта СТУДЕНТ содержит значения реквизитов по конкретному студенту.
Экземпляр объекта должен однозначно определять среди всего множества экземпляров, т.е. идентифицировать значением уникального (первичного) ключа информационного объекта.
Уникальность ключа означает, что любе значение ключа не может повториться в каком–либо другом экземпляре объекта.
Простой ключ состоит из одного реквизита, а составной ключ — из нескольких реквизитов.
Таким образом, реквизиты информационного объекта подразделяются на ключевые и описательные, которые являются функционально зависимыми от ключа.
Функциональная зависимость реквизитов должна быть выявлена на основе описания предметной области для выделения информационных объектов. В процессе выявления функциональной зависимости реквизитов устанавливается соответствие значений ключевых (определяющих) и не ключевых (определяемых) реквизитов.
Каждому информационному объекту в модели данных предметной области нужно присвоить уникальное имя.
При графическом изображении модели данных каждый информационный объект представляется прямоугольником с обозначением его имени и идентификатора-ключа. Пример такого изображения для информационных объектов ТОВАР и ПОСТАВКА показан на РИС.
Рис.1. Пример графического изображения информационных объектов с простым и составным ключом
Здесь KOD (код товара) – простой ключ объекта ТОВАР, а KOD+KPOST (код поставщика) – составной ключ объекта ПОСТАВКА.
Для построения модели данных в каноническом виде совокупность реквизитов информационного объекта должна отвечать требованиям нормализации.
Требования нормализации
Реквизиты каждого информационного объекта канонической модели данных должны отвечать требованиям, соответствующим третьей нормальной форме реляционной модели данных:
- Информационный объект должен содержать уникальный идентификатор-ключ;
- Все описательные реквизиты должны быть взаимонезависимы, т.е. между ними не должно быть зависимостей;
- Все реквизиты, входящие в составной ключ, также должны быть взаимонезависимы;
- Каждый описательный реквизит должен функционально полно зависеть от ключа, т.е. каждому значению ключа должно соответствовать только одно значение описательного реквизита, а при составном ключе описательные реквизиты должны зависеть от всей совокупности реквизитов, образующих ключ;
- Каждый описательный реквизит должен зависеть от ключа не транзитивно, т.е. не должен зависеть через другой промежуточный реквизит.
Выполнение требований нормализации обеспечивает построение канонической модели данных и создание ее на основе реляционной базы данных без дублирования описательных данных, а также возможность автоматического поддержания связной целостности данных средствами СУБД при обновлении базы данных (добавлении и удалении записей, изменении значений в ключевых полях).
Источник: https://itteach.ru/bazi-dannich/proektirovanie-relyatsionnoy-bazi-dannich
SQL и NoSQL: разбираемся в основных моделях баз данных
Перевод статьи «Understanding SQL And NoSQL Databases And Different Database Models»
С незапамятных времен память была одной из самых важных и необходимых составляющих компьютера. Несмотря на разницу в методах реализации, большинство вычислительных машин оснащены необходимым аппаратным обеспечением для обработки и хранения информации.
В наше время невозможно представить работу какого-либо приложения, хоть игры, хоть сайта, без получения, обработки и записи определённого типа данных. Системы управления базами данных (СУБД) — это высокоуровневое программное обеспечение, работающее с низкоуровневыми API. Для решения различных проблем создавались новые виды СУБД (реляционные, NoSQL и т.д.
) и их новые реализации (MySQL, PostgreSQL, MongoDB, Redis и т.д.). В этой статье мы разберемся в основах баз данных и СУБД.
Системы управления базами данных
СУБД — это общий термин, относящийся ко всем видам абсолютно разных инструментов, от компьютерных программ до встроенных библиотек. Эти приложения управляют или помогают управлять наборами данных. Так как эти данные могут быть разного формата и размера, были созданы разные виды СУБД.
СУБД основаны на моделях баз данных — определённых структурах для обработки данных. Каждая СУБД создана для работы с одной из них с учётом особенностей операций над информацией.
Хотя решений, реализующих различные модели баз данных, очень много, периодически некоторые из них становятся очень популярными и используются на протяжении многих лет. Сейчас самой популярной моделью является реляционная система управления базами данных (РСУБД).
Модели баз данных
Каждая СУБД реализует одну из моделей баз данных для логической структуризации используемых данных. Эти модели являются главным критерием того, как будет работать и управлять информацией приложение. Существует несколько таких моделей, среди которых самой популярной является реляционная.
Хотя она и является весьма мощной и гибкой, есть ситуации, решения которых она предложить не может. Тут на помощь придёт сравнительно новая модель, называемая NoSQL.
Она набирает популярность и предлагает весьма интересные решения и дополнительный функционал.
Из-за того, что эти системы не используют строгую структуризацию данных, они предлагают большую свободу действий при обработке информации.
Реляционная модель
Представленная в 70-х, реляционная модель предлагает математический способ структуризации, хранения и использования данных. Отношения (англ. relations) дают возможность группировки данных как связанных наборов, представленных в виде таблиц, содержащих упорядоченную информацию (например, имя и адрес человека) и соотносящих значения и атрибуты (его номер паспорта).
Благодаря десятилетиям исследований и разработки РСУБД работают производительно и надёжно. В сочетании с большим опытом использования администраторами реляционные базы данных стали выбором, гарантирующим защиту информации от потерь.
Несмотря на строгие принципы формирования и обработки данных, РСУБД могут быть весьма гибкими, если приложить немного усилий.
Безмодельный (NoSQL) подход
NoSQL-способ структуризации данных заключается в избавлении от ограничений при хранении и использовании информации. Базы данных NoSQL, используя неструктуризированный подход, предлагают много эффективных способов обработки данных в отдельных случаях (например, при работе с хранилищем текстовых документов).
Популярные СУБД
В этой статье мы опишем вам парадигмы основных решений для работы с базами данных. Хотя точные числа привести очень сложно, в большинстве случаев выбор делается в пользу реляционной модели или NoSQL. Прежде чем мы сравним их, давайте узнаем, что находится “под капотом” у каждой из них.
РСУБД
Реляционные системы управления базами данных берут своё название от реализуемой модели — реляционной. Сейчас они остаются, да и ещё какое-то время будут, самым популярным выбором для надёжного, безопасного и производительного хранения данных.
РСУБД требуют чётких и ясных схем — не стоит путать со специфическим определением для PostgreSQL — для работы с данными. Эти рамки, определённые пользователем, задают способ их хранения и использования. Схемы очень похожи на таблицы, столбцы которых отражают порядковый номер и тип информации в каждой записи, а строки — содержимое этих записей.
Самыми популярными РСУБД сейчас являются:
- SQLite: очень мощная встраиваемая РСУБД.
- MySQL: самая популярная и часто используемая РСУБД.
- PostgreSQL: самая продвинутая и гибкая РСУБД.
NoSQL-СУБД
NoSQL-СУБД не используют реляционную модель структуризации данных. Существует много реализаций, рещающих этот вопрос по-своему, зачастую весьма специфично. Эти бессхемные решения допускают неограниченное формирование записей и хранение данных в виде ключ-значение.
В отличие от традиционных РСУБД, некоторые базы данных NoSQL, например, MongoDB, позволяют группировать коллекции данных с другими базами данных. Такие СУБД хранят данные как одно целое. Эти данные могут представлять собой одиночный объект наподобие JSON и вместе с тем корректно отвечать на запросы к полям.
NoSQL базы данных не используют общий формат запроса (как SQL в реляционных базах данных). Каждое решение использует собственную систему запросов.
Сравнение SQL и NoSQL
Для того, чтобы прийти к простому и понятному выводу, давайте проанализируем разницу между SQL- и NoSQL-подходами:
- Структура и тип хранящихся данных: SQL/реляционные базы данных требуют наличия однозначно определённой структуры хранения данных, а NoSQL базы данных таких ограничений не ставят.
- Запросы: вне зависимости от лицензии, РСУБД реализуют SQL-стандарты, поэтому из них можно получать данные при помощи языка SQL. Каждая NoSQL база данных реализует свой способ работы с данными.
- Масштабируемость: оба решения легко растягиваются вертикально (например, путём увеличения системных ресурсов). Тем не менее, из-за своей современности, решения NoSQL обычно предоставляют более простые способы горизонтального масштабирования (например, создания кластера из нескольких машин).
- Надёжность: когда речь заходит о надёжности, SQL базы данных однозначно впереди.
- Поддержка: РСУБД имеют очень долгую историю. Они очень популярны, и поэтому получить поддержку, платную или нет, очень легко. Поэтому, при необходимости, решить проблемы с ними гораздо проще, чем с NoSQL, особенно если проблема сложна по своей природе (например, при работе с MongoDB).
- Хранение и доступ к сложным структурам данных: по своей природе реляционные базы данных предполагают работу с сложными ситуациями, поэтому и здесь они превосходят NoSQL-решения.
Источник: https://tproger.ru/translations/sql-nosql-database-models/
Основы проектирования реляционных бд
- ID: 17229
- Название работы: Основы проектирования реляционных бд
- Категория: Лекция
- Предметная область: Информатика, кибернетика и программирование
Описание: Лекция №8 ОСНОВЫ проектирования реляционных БД При проектировании базы данных решаются две основные проблемы. Проблема логического проектирования баз данных. Каким образом отобразить объекты предметной области в абстрактные объекты модели данных чтобы эт…
- Язык: Русский
- Дата добавления: 2013-06-30
- Размер файла: 120.5 KB
- Работу скачали: 5 чел.
- Лекция №8
- ОСНОВЫ проектирования реляционных БД
- При проектировании базы данных решаются две основные проблемы.
- Проблема логического проектирования баз данных. Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области, и было по возможности, наилучшим (эффективным, удобным и т.д.)?
- Проблем физического проектирования баз данных. Как обеспечить эффективность выполнения запросов к БД, т. е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, какие необходимы дополнительные структуры (например, индексов) и т. д.?
Устно. В случае реляционных баз данных трудно предложить какие-либо общие рецепты по части физического проектирования. Здесь слишком многое зависит от используемой СУБД. Поэтому в дальнейшем ограничимся вопросами логического проектирования реляционных баз данных, которые существенны при использовании любой реляционной СУБД.
- Будем рассматривать проблему проектирования реляционной БД как обоснование принятия решения о том, из каких отношений должна состоять БД и какие атрибуты должны быть у этих отношений.
- Рассмотрим классический подход, при котором весь процесс проектирования БД осуществляется методом последовательных приближений к удовлетворительному набору схем отношений.
- Исходной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проектирования производится некоторый набор схем отношений (нормальная форма), обладающих «улучшенными» свойствами.
- Процесс проектирования называется нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами, в некотором смысле, лучшими, чем предыдущая.
- Каждой нормальной форме соответствует определенный набор ограничений, и отношение находится в некоторой нормальной форме (НФ), если удовлетворяет свойственному ей набору ограничений.
Ограничением первой нормальной формы (1НФ) является необходимость приведения всех атрибутов отношения к атомарному виду. Поскольку требование 1НФ является базовым требованием классической реляционной модели данных, т.е.
- В отношении нет одинаковых кортежей.
- Кортежи не упорядочены.
- Атрибуты не упорядочены и различаются по наименованию.
- Все значения атрибутов атомарны.
Будем считать, что исходный набор отношений уже соответствует этому требованию.
В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:
- первая нормальная форма (1НФ);
- вторая нормальная форма (2НФ);
- третья нормальная форма (3НФ);
- нормальная форма Бойса-Кодда (БКНФ);
- четвертая нормальная форма (4НФ);
- пятая нормальная форма, или нормальная форма проекции-соединения (5НФ или PJ/НФ);
- и другие.
Основные свойства нормальных форм состоят в следующем:
- каждая следующая нормальная форма в некотором смысле лучше предыдущей нормальной формы;
- при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.
Прежде чем рассмотреть методы проектирования укажем некоторые причины, по которым схема БД может оказаться неадекватной требованиям ПрО. Другими словами выделим аномалии противоречащие ПрО.
Например. Рассмотрим отношений Деканат следующего вида:
| №зк | ФИО | Группа | Предмет | Преподаватель | Кафедра | Оценка |
Структура такой схемы может привести к проблемам.
- Избыточность. Группа, Преподаватель, Кафедра повторяются столько раз, сколько раз сдавались экзамены.
- Аномалия обновления (UPDATE). Вследствие избыточности можно обновить, например, Преподавателя в одном картеже, оставляя его неизменным в другом.
- Аномалия включения (INSERT). В БД не может быть занесено ФИО, если студент в настоящее время не сдавал ни одного экзамена. При этом использование пустых значений может привести к дополнительным трудностям, например, таким как поиск и заполнение пустых значений.
- Аномалия удаления (DELETE). Обратная проблема может возникнуть при необходимости удаления всех ФИО (закончивших ВУЗ), вследствие чего непреднамеренно будет удалена вся информации о Предметах, Преподавателях и т.д.
Причина аномалии — хранение в одном отношении разнородной информации (и о студентах, и о преподавателях, и об успеваемости).
Вывод — структура данных неадекватна требованиям ПрО. БД, основанная на такой структуре, будет работать неправильно.
Функциональные зависимости
Для устранения указанных аномалий (а на самом деле для правильного проектирования структуры данных!) приведем структуру БД к нормальной форме более высокого порядка, для чего введем понятие функциональной зависимости атрибутов отношения.
Определение. Пусть — некоторое отношение.
Множество атрибутов функционально зависимо от множества атрибутов ( функционально определяет ) тогда и только тогда, когда для любого состояния отношения для любых кортежей из того, что следует что (т.е.
во всех кортежах, имеющих одинаковые значения атрибутов , значения атрибутов также совпадают в любом состоянии отношения ). Символически функциональная зависимость записывается
- .
- Другими словами:
- Если даны два атрибута X и Y некоторого отношения R, то говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X соответствует ровно одно значение Y.
- При этом X и Y могут быть составными, то есть составленные из нескольких атрибутов одного отношения.
- Можно сказать, что функциональные зависимости представляют собой связи типа «один ко многим», существующие внутри отношения.
- Множество атрибутов называется детерминантом функциональной зависимости, а множество атрибутов называется зависимой частью.
Замечание. Если атрибуты составляют потенциальный ключ отношения , то любой атрибут отношения функционально зависит от .
В основе процесса нормализации лежит понятие декомпозиции отношения на два или более отношений.
Декомпозицией схемы отношения R называется замена ее совокупностью = {R1,…,Rm} подмножеств R, таких, что R1 … Rm = R. При этом не требуется, чтобы Ri были непересекающимися, т.е. Ri Rj = .
- При “правильном” проектировании схемы БД необходимо, чтобы декомпозиция обладала свойством соединения без потерь, то есть должно выполняться условие:
- R = R1(R) > Y и Y —> Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.
Тогда определение 3НФ сформулируем следующим образом.
Определение. Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находится в 2НФ, и каждый неключевой атрибут нетранзитивно зависит от потенциального ключа.
Для того чтобы устранить зависимость неключевых атрибутов, нужно произвести декомпозицию отношения на несколько отношений. При этом те неключевые атрибуты, которые являются транзитивно зависимыми, выносятся в отдельное отношение.
- Рассмотреть пример с отношением Деканат.
- Отношению Список и Экзамен соответствует по одной ФЗ, и, следовательно, они находятся в 3НФ, так как транзитивность заведомо отсутствует.
- Отношению Кафедра соответствует две ФЗ:
- Предмет Преподаватель
- Преподаватель Кафедра
- проанализируем их.
Атрибут Кафедра транзитивно зависит от атрибута Предмет, следовательно отношение Кафедра не находится в 3НФ. Таким образом, необходимо выполнить декомпозицию по соответствующим ФЗ.
Декомпозиция представляется двумя отношениями Предмет и Кафедра.
Предмет Кафедра
Предмет Преподаватель Преподаватель Кафедра - При этом ФЗ распределяться следующим образом:
- для таблицы Предмет будет соответствовать ФЗ
- Предмет Преподаватель
- для таблицы Кафедра будут соответствовать ФЗ
- Преподаватель Кафедра
- Таким образом, среди полученных множеств ФЗ соответствующих каждой таблицы нет транзитивных, следовательно, каждое полученное отношений находится во 3НФ и БД в целом также находится во 3НФ.
- Спроектированная БД в 3НФ имеет следующую структуру:
- Список
- 1
- Экзамен
-
- Предмет 1 1 Кафедра
Предмет Преподаватель Преподаватель Кафедра - Следует отметить, что в данном примере первичные ключи каждой таблицы соответствуют левым атрибутам ФЗ, так как каждой таблицы соответствует одна ФЗ, которая определяет остальные атрибуты, и, следовательно, определяет первичный ключ.
- Проанализировав последовательность декомпозиции можно установить связи между таблицами, которые будут соответствовать типу “1:М”.
- Схема последовательности декомпозиции представляется следующим образом:
- Исходная таблица:
- Деканат
- 2НФ:
- Список Экзамен по атрибуту №зк
- Экзамен Кафедра по атрибуту Предмет
- 3НФ:
- Список Экзамен по атрибуту №зк
- Экзамен Предмет по атрибуту Предмет
- Кафедра Кафедра по атрибуту Преподаватель
- Алгоритм нормализации (приведение к 3НФ)
Итак, алгоритм нормализации (т.е. алгоритм приведения отношений к 3НФ) описывается следующим образом.
Шаг 1 (Приведение к 1НФ). На первом шаге задается одно или несколько отношений, отображающих понятия предметной области. По модели предметной области (не по внешнему виду полученных отношений!) выписываются обнаруженные функциональные зависимости. Все отношения автоматически находятся в 1НФ.
Шаг 2 (Приведение к 2НФ). Если в некоторых отношениях обнаружена зависимость атрибутов от части составного потенциального ключа, то проводим декомпозицию этих отношений на несколько отношений следующим образом: те атрибуты, которые зависят от части составного потенциального ключа выносятся в отдельное отношение вместе с этой частью ключа. В исходном отношении остаются все ключевые атрибуты:
- Исходное отношение: .
- Ключ: — сложный.
- Функциональные зависимости:
- — зависимость всех атрибутов от ключа отношения.
- — зависимость некоторых атрибутов от части составного ключа.
- Декомпозированные отношения:
— остаток от исходного отношения. Ключ .
— атрибуты, вынесенные из исходного отношения вместе с частью сложного ключа. Ключ .
Шаг 3 (Приведение к 3НФ). Если в некоторых отношениях обнаружена транзитивная зависимость некоторых неключевых атрибутов, то проводим декомпозицию этих отношений следующим образом: те неключевые атрибуты, которые транзитивно зависят от атрибутов потенциального ключа, выносятся в отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости:
- Исходное отношение: .
- Ключ: .
- Функциональные зависимости:
- — зависимость всех атрибутов от ключа отношения.
- — транзитивная зависимость неключевых атрибутов от потенциального ключа .
- Декомпозированные отношения:
— остаток от исходного отношения. Ключ .
— атрибуты, вынесенные из исходного отношения вместе с детерминантом функциональной зависимости. Ключ .
Устно. На практике, при создании логической модели данных, как правило, не следуют прямо приведенному алгоритму нормализации. Часто можно сразу построить отношения в 3НФ.
Тем не менее, приведенный алгоритм важен по двум причинам. Во-первых, этот алгоритм показывает, какие проблемы возникают при разработке слабо нормализованных отношений. Во-вторых, как правило, модель предметной области никогда не бывает правильно разработана с первого шага.
Эксперты предметной области могут забыть о чем-либо упомянуть, разработчик может неправильно понять эксперта, во время разработки могут измениться правила, принятые в предметной области, и т.д.
Все это может привести к появлению новых зависимостей, которые отсутствовали в первоначальной модели предметной области. Тут как раз и необходимо использовать алгоритм нормализации хотя бы для того, чтобы убедиться, что отношения остались в 3НФ, и логическая модель не ухудшилась.
Источник: http://5fan.ru/wievjob.php?id=17229
Руководство по проектированию реляционных баз данных
Page 2
Последнее обновление: 02.07.2017
Ключи представляют способ идентификации строк в таблице. С помощью ключей мы также можем связывать строки между различными таблицами в отношения.
Суперключ
Superkey (суперключ) — комбинация атрибутов (столбцов), которые уникально идентифицируют каждую строку таблицы. Это могут быть и все столбцы, и несколько и и один. При этом строки, которые содержат значения этих атрибутов, не должны повторяться.
Например, у нас есть сущность Student, которая представляет данные о пользователях и которая имеет следующие атрибуты:
- FirstName (имя)
- LastName (фамилия)
- Year (год рождения)
- Phone (номер телефона)
Какие атрибуты в данном случае могут составлять суперключ:
- {FirstName, LastName, Year, Phone}
- {FirstName, Year, Phone}
- {LastName, Year, Phone}
- {FirstName, Phone}
- {LastName, Phone}
- {Year, Phone}
- {Phone}
Каждого студента уникально может идентифицировать телефонный номер, поэтому любые наборы, в которых встречается атрибут Phone, представляют суперключ.
А вот, к примеру, набор {FirstName, LastName, Year} не является суперключом, так как у нас теоретически могут быть как минимум два студента с одинаковыми именем, фамилией и годом рождения.
Потенциальный ключ
Candidate key (потенциальный ключ) — представляет собой минимальный суперключ отношения (таблицы), то есть набор атрибутов, который удовлетворяет ряду условий:
- Неприводимость: он не может быть сокращен, он содержит минимально возможный набор атрибутов
- Уникальность: он должен иметь уникальные значения вне зависимости от изменения строки
- Наличие значения: он не должен иметь значения NULL, то есть он обязательно должен иметь значение.
Возьмем ранее выделенные суперключи и найдем среди них candidate key. Первый пять суперключей не соответствуют первому условию, так как все их можно сократить до суперключа {Phone}:
- {FirstName, LastName, Year, Phone}
- {FirstName, Year, Phone}
- {LastName, Year, Phone}
- {FirstName, Phone}
- {LastName, Phone}
- {Year, Phone}
Суперключ {Phone} соответствует первому и второму условию, так как он имеет уникальное значение (в данном случае все пользователи могут иметь только уникальные телефонные номера). Но соответствует ли он третьему условию? В целом нет, так как теоретически студент может и не иметь телефона. В этом случае атрибут Phone будет иметь значение NULL, то есть значение будет отсутствовать.
В то же время это может зависеть от ситуации. Если в какой-то систему номер телефона является неотъемлемым атрибутом, например, используется для регистрации и входа в систему, то его можно считать потенциальным ключом. Но в данном случае мы рассматриваем общую ситуацию. И для понимания потенциального ключа необходимо отталкиваться от конкретной системы, которую описывает база данных.
И в таком случае суперключи таблицы не содержат потенциального ключа.
Первичный ключ
Первичный ключ (primary key) непосредственно применяется для идентификации строк в таблице. Он должен соответствовать следующим ограничениям:
- Первичный ключ должен быть уникальным все время
- Он должен постоянно присутствовать в таблице и иметь значение
- Он не должен часто менять свое значение. В идеале он вообще не должен изменять значение.
Как правило, первичный ключ представляет один столбец таблицы, но также может быть составным и состоять из нескольких столбцов.
Если для таблицы можно выделить потенциальный ключ, то его можно использовать в качестве первичного ключа.
Если же потенциальные ключи отсутствуют, то для первичного ключа можно добавить к сущности специальный атрибут, который, как правило, называется, Id или имеет форму [Имя_сущности]Id (например, StudentId), либо может иметь другое название. И обычно данный атрибут принимает целочисленное значение, начиная с 1.
Если же у нас есть несколько потенциальных ключей, то те потенциальные ключи, которые не составляют первичный ключ, являются альтернативными ключами (alternative key).
Например, возьмем представление пользователей на сайтах с двухфакторной авторизацией, где нам обязательно иметь электронный адрес, который нередко выступает в качестве логина, и какой-нибудь номер телефона. В этом случае таблицу пользователей мы можем задать с помощью следующих атрибутов:
- Name (имя пользователя)
- Email (электронный адрес)
- Password (пароль)
- Phone (телефонный номер)
В данном случае атрибуты Email и Phone являются потенциальными ключами, они обязательны в рамках рассматриваемой системы и в принципе уникальны.
И теоретически, мы можем использовать один из этих атрибутов в качестве первичного ключа, тогда второй будет альтернативным ключом.
Однако опять же поскольку теоретически значения обоих атрибутов могут меняться, то лучше все таки определить дополнительный атрибут специально под первичный ключ.
Page 3
Последнее обновление: 02.07.2017
Базы данных могут содержать таблицы, которые связаны между собой различными связями. Связь (relationship) представляет ассоциацию между сущностями разных типов.
При выделении связи выделяют главную или родительскую таблицу (primary key table / master table) и зависимую, дочернюю таблицу (foreign key table / child table). Дочерняя таблица зависит от родительской.
Для организации связи используются внешние ключи. Внешний ключ представляет один или несколько столбцов из одной таблицы, который одновременно является потенциальным ключом из другой таблицы. Внешний ключ необязательно должен соответствовать первичному ключу из главной таблицы. Хотя, как правило, внешний ключ из зависимой таблицы указывает на первичный ключ из главной таблицы.
Связи между таблицами бывают следующих типов:
- Один к одному (One to one)
- Один к многим (One to many)
- Многие ко многим (Many to many)
Связь один к одному
Данный тип связей встречает не часто. В этом случае объекту одной сущности можно сопоставить только один объект другой сущности. Например, на некоторых сайтах пользователь может иметь только один блог. То есть возникает отношение один пользователь — один блог.
Нередко этот тип связей предполагает разбиение одной большой таблицы на несколько маленьких. Основная родительская таблица в этом случае продолжает содержать часто используемые данные, а дочерняя зависимая таблица обычно хранит данные, которые используются реже.
В этом отношении первичный ключ зависимой таблицы в то же время является внешним ключом, который ссылается на первичный ключ из главной таблицы.
Например, таблица Users представляет пользователей и имеет следующие столбцы:
- UserId (идентификатор, первичный ключ)
- Name (имя пользователя)
И таблица Blogs представляет блоги пользователей и имеет следующие столбцы:
- BlogId (идентификатор, первичный и внешний ключ)
- Name (название блога)
В этом случае столбец BlogId будет хранить значение из столбца UserId из таблицы пользователей. То есть столбец BlogId будет выступать одновременно первичным и внешним ключом.
Связь один ко многим
Это наиболее часто встречаемый тип связей. В этом типе связей несколько строк из дочерний таблицы зависят от одной строки в родительской таблице. Например, в одном блоге может быть несколько статей.
В этом случае таблица блогов является родительской, а таблица статей — дочерней. То есть один блог — много статей. Или другой пример, в футбольной команде может играть несколько футболистов.
И в то же время один футболист одновременно может играть только в одной команде. То есть одна команда — много футболистов.
К примеру, пусть будет таблица Articles, которая представляет статьи блога и которая имеет следующие столбцы:
- ArticleId (идентификатор, первичный ключ)
- BlogId (внешний ключ)
- Title (название статьи)
- Text (текст статьи)
В этом случае столбец BlogId из таблицы статей будет хранить значение из столбца BlogId из таблицы блогов.
Связь многие ко многим
При этом типе связей одна строка из таблицы А может быть связана с множеством строк из таблицы В. В свою очередь одна строка из таблицы В может быть связана с множеством строк из таблицы А. Типичный пример — студенты и курсы: один студент может посещать несколько курсов, и соответственно на один курс могут записаться несколько студентов.
Другой пример — статьи и теги: для одной статьи можно определить несколько тегов, а один тег может быть определен для нескольких статей.
Но в SQL Server на уровне базы данных мы не можем установить прямую связь многие ко многим между двумя таблицами. Это делается посредством вспомогательной промежуточной таблицы. Иногда данные из этой промежуточной таблицы представляют отдельную сущность.
Например, в случае со статьями и тегами пусть будет таблица Tags, которая имеет два столбца:
- TagId (идентификатор, первичный ключ)
- Text (текст тега)
Также пусть будет промежуточная таблица ArticleTags со следующими полями:
- TagId (идентификатор, первичный и внешний ключ)
- ArticleIdId (идентификатор, первичный и внешний ключ)
Технически мы получим две связи один-ко-многим. Столбец TagId из таблицы ArticleTags будет ссылаться на столбец TagId из таблицы Tags.
А столбец ArticleId из таблицы ArticleTags будет ссылаться на столбец ArticleId из таблицы Articles.
То есть столбцы TagId и ArticleId в таблице ArticleTags представляют составной первичный ключ и одновременно являются внешними ключами для связи с таблицами Articles и Tags.
Ссылочная целостность данных
При изменении первичных и внешних ключей следует соблюдать такой аспект как ссылочная целостность данных (referential integrity).
Ее основная идея состоит в том, чтобы две таблице в базе данных, которые хранят одни и те же данные, поддерживали их согласованность.
Целостность данных представляет правильно выстроенные отношения между таблицами с корректной установкой ссылок между ними. В каких случаях целостность данных может нарушаться:
- Аномалия удаления (deletion anomaly). Возникает при удалении строки из главной таблицы. В этом случае внешний ключ из зависимой таблицы продолжает ссылаться на удаленную строку из главной таблицы
- Аномалия вставки (insertion anomaly). Возникает при вставке строки в зависимую таблицу. В этом случае внешний ключ из зависимой таблицы не соответствует первичному ключу ни одной из строк из главной таблицы.
- Аномалии обновления (update anomaly). При подобной аномалии несколько строк одной таблицы могут содержать данные, которые принадлежат одному и тому же объекту. При изменении данных в одной строке они могу прийти в противоречие с данными из другой строки.
Аномалия удаления
Для решения аномалии удаления для внешнего ключа следует устанавливать одно из двух ограничений:
- Если строка из зависимой таблицы обязательно требует наличия строки из главной таблицы, то для внешнего ключа устанавливается каскадное удаление. То есть при удалении строки из главной таблицы происходит удаление связанной строки (строк) из зависимой таблицы.
- Если строка из зависимой таблицы допускает отсутствие связи со строкой из главной таблицы (то есть такая связь необязательна), то для внешнего ключа при удалении связанной строки из главной таблицы задается установка значения NULL. При этом столбец внешнего ключа должен допускать значение NULL.
Аномалия вставки
Для решения аномалии вставки при добавлении в зависимую таблицу данных столбец, который представляет внешний ключ, должен допускать значение NULL. И таким образом, если добавляемый объект не имеет связи с главной таблицей, то в столбце внешнего ключа будет стоять значение NULL.
Аномалии обновления
Для решения проблемы аномалии обновления применяется нормализация, которая будет рассмотрена далее.
Page 4
Последнее обновление: 02.07.2017
Во второй нормальной форме каждый столбец в таблице, который не является ключом, должен зависеть от ключа.
Ключевой момент второй нормальной формы — полная функциональная зависимость.
Она предполагает, что атрибут В полностью функционально зависим от атрибута А, если атрибут В функционально зависит от полного значения атрибута А, а не от какого-либо подмножества значений из атрибута А.
То есть, если атрибут А составляют несколько значений, скажем, А1 и А2, то атрибут В полностью функционально зависит от А, если он зависит и от А1 и от А2 (А1, А2 → В).
Если атрибут В зависит только от какого-либо подмножества из атрибута А, например, только от А1, то имеет место частичная функциональная зависимость.
Эта форма применяется к тем таблицам, которые имеют составной первичный ключ, то есть где первичный ключ состоит из нескольких атрибутов. Если в таблице несоставной первичный ключ, то в этом случае считается, что все остальные атрибуты автоматически находятся в полной функциональной зависимости от первичного ключа.
Вторая нормальная форма применяется только к тем таблицам, которые находятся в первой нормальной форме. После применения второй формы все столбцы таблицы зависят от первичного ключа.
Возьмем сформированную в прошлой теме таблицу StudentCourses после применения первой нормальной формы:
StudentId Name CourseId Course Date TeacherId Teacher Position 1 Том 1 Математика 11/06/2017 1 Смит Профессор 1 Том 2 JavaScript Источник: https://metanit.com/sql/tutorial/
Загрузка...
