Связи и третья нормальная форма (3NF)

Теперь определим связи между сущностями.

Например, мы выделили отдельную сущность (таблицу) “Автор”. Но нам всё же требуется указать автора для каждой книги.

Для этого мы снова введём атрибут (столбец) “Автор” для сущности (таблицы) “Книга”. Но теперь мы поместим туда не фамилию автора, а идентификатор сущности “Автор” – т.е. значение поля ID в таблице “Автор”.

Таким образом мы установили связь между сущностями “Книга” и “Автор”.

Чтобы описать связь, обычно приводят название и степень для каждой из её двух сторон (сущностей). Степень, иногда называемая также кардинальным числом, показывает, сколько экземпляров одной сущности может соответствовать экземпляру другой сущности. Обычно применяется всего два варианта значения степени – “1” (один экземпляр) и “N” (сколько угодно экземпляров).

Например, описанная только что связь – это связь “Автор”/”Книга”, степени 1:N. Для каждой книги может быть только один автор (вспомним о нашем упрощении). Но у каждого автора может быть сколько угодно книг.

Существует три типа связей:

· один-к-одному (1:1);

· один-ко-многим (1:N);

· многие-ко-многим (N:N).

Связи вида 1:1 обычно лучше не использовать. Такая связь означает, что была выделена лишняя сущность. В самом деле – если каждая строка одной таблицы строго соответствует одной, и только одной, строке другой таблицы – не проще ли их объединить?

Связь вида 1:N наиболее просто отражается в реляционной БД. Для сущности, к которой относится степень N, добавляется атрибут, содержащий значение идентификатора второй сущности. (Проще говоря, в таблицу добавляется столбец, и значения в нём соответствуют значениям в поле ID другой таблицы). Такой атрибут является внешним ключом (foreign key, FK).

На ER-диаграммах связи изображаются с помощью линий (не обязательно прямых – они могут быть ломаными). Степень связей указывается с помощью ромбиков на их концах: отсутствие ромбика указывает соответствует степени 1, а его наличие – степени N. Внешние ключи отмечаются как FK.

C помощью внешних ключей нам не удастся смоделировать отношение “многие-ко-многим” (N:N). В реальной библиотеке именно таким будет отношение “Автор”/”Книга”: ведь у каждой книги может быть несколько авторов.

Поэтому, чтобы определить связь N:N, применяется следующая технология:

1. Создается вспомогательная сущность, иногда называемую сущностью-связкой. Обычно названия для таких сущностей получают путем составления названий связываемых сущностей, но можно подобрать и другое имя. Например, если бы нам нужно было хранить несколько авторов для каждого из учебников, то пришлось бы вводить сущность “Авторство”.

2. Новая сущность связывается с двумя исходными отношениями типа один-ко-многим.

В нашей базе данных достаточно хранить фамилию, имя и отчество только одного автора для каждого учебника, поэтому в учебном примере нет таблицы “Авторство”.

Модель данных находится в третьей нормальной форме (3NF), если онанаходится в 2NF, и все связи между сущностями определены, причём с использованием внешних ключей. Т.е. каждая связь создаётся при помощи атрибута одной из сущностей, значение которого соответствует идентификатору другой сущности.

При изменении структуры базы данных нужно внимательно следить – не пришло ли время выделить новую сущность. Так, в нашем примере атрибутов, мешающих нам признать, что модель данных находится в 3NF, нет. Но она может перестанет соответствовать требованиям 3NF, если мы добавим к сущности “Издательство” атрибут “Город”. В одном городе может быть несколько издательств, и одно издательство может иметь несколько представительств в различных городах. В такой ситуации нам придется выделить сущность “Город”, и установить связь “Город”/”Издательство” степени N:N.

Другие нормальные формы

Кроме рассмотренных в основной части данного занятия первых трех нормальных форм существует еще три нормальных формы: четвертая нормальная форма (4NF), нормальная форма Бойса-Кодда (BCNF) и пятая нормальная форма (5NF), которую иногда называют формой проекции-соединения (PJNF). Для понимания определений этих нормальных форм также необходимо знание понятий реляционной алгебры. Поэтому ограничимся перечислением основных свойств нормальных форм:

· каждая последующая нормальная форма в некотором смысле улучшает свойства предыдущей;

· при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

Следует также заметить, что переход к 5NF усложняет структуру БД, что затрудняет операции модификации, поэтому при проектировании БД имеет смысл оценить: какие операции будут производиться чаще, чтобы определить, какая нормальная форма будет наиболее подходящей в данном конкретном случае. В простых информационных системах 5NF используется крайне редко – инженеры-проектировщики обычно ограничиваются 3NF.

 

Индексы

Для оптимизации работы базы данных применяются индексы – специальные структуры данных, которые строит СУБД для того, чтобы потом быстрее находить в таблицах строки, удовлетворяющие запросам. Чаще всего индексы строятся по столбцам (или индексируют столбцы), по которым наиболее вероятен поиск. Например, в таблице “Предмет” БД школьной библиотеки имеет смысл проиндексировать столбец “Название”, т.к. поиск часто производится по названию предмета.

Можно проиндексировать сразу несколько столбцов. Например, в таблице “Автор” БД школьной библиотеки имеет смысл проиндексировать столбцы “Фамилия”, “Имя” и “Отчество”, т.к. авторов чаще всего ищут по фамилии, имени и отчеству.

Эффективность индексов станет заметна, когда количество записей в ваших таблицах вырастет до нескольких сотен.

 

Нереляционные типы БД

Индустрия СУБД прошла довольно длинный путь, прежде чем появилась реляционная модель. Первые СУБД реализовывали так называемые теоретико-графовые модели.

Графом в математике называют конечную совокупность точек (вершин), некоторые из которых соединены друг с другом линиями (ребрами). Изучением графов специальный раздел дискретной математики – теория графов. С помощью графов решаются многие оптимизационные задачи; графы очень часто применяются для организации информации: например, логическая структура файловой системы представлена в виде дерева каталогов (папок) и файлов. Дерево – это один из типов графов, позволяющих смоделировать иерархические отношения. Дерево характеризуется тем, что в нем нет циклов, т.е. замкнутых цепочек вершин.

В мире многие связи соответствуют некоторой иерархии, когда один объект выступает как родительский, а с ним может быть связано множество подчиненных (или дочерних) объектов. Иерархия является естественным способом отображения связей между классами объектов.

Иерархическая модель является самой простой среди всех логических моделей БД, и исторически она появилась первой (с 60-х годов): именно эту модель использовала первая из промышленных СУБД IMS компании IBM.

Иерархическая модель данных строится по принципу иерархии объектов, то есть один тип объекта является главным, все нижележащие – подчиненными. Устанавливается связь «один ко многим», то есть для некоторого главного типа существует несколько подчиненных типов объектов. Иначе, главный тип именуется исходным типом, а подчиненные – порожденными. У подчиненных типов могут быть в свою очередь подчиненные типы. Наивысший в иерархии узел (совокупность атрибутов) называют корневым.

В рамках иерархической модели выделяют язык описания структуры данных – DDL (Data Definition Language), а также язык манипулирования данными – DML (Data Manipulation Language). На сегодняшний день иерархические БД почти не используются.

Еще одна модель БД – сетевая, основанная на обобщенном представлении графа, в котором возможны циклы. Стандарт сетевой модели с описанием ее базовых понятий и формального языка описания был определен в 1975 году организацией CODASYL (Conference of Data System Languages). Сетевая модель гибче иерархической (например, в отличие от иерархической модели, она позволяет моделировать связи “многие-ко-многим”), но отличается более сложным процессом разработки модели.

Сетевая модель данных строится по принципу «главный и подчиненный тип одновременно», то есть любой тип данных одновременно может порождать несколько подчиненных типов (быть владельцем набора) и быть подчиненным для нескольких главных (быть членом набора).

 

Тем не менее, все в мире стремится к простоте – в ответ на настоятельную потребность в переходе от работы с элементами данных, как это делается в графовых моделях, к работе с некоторыми макрообъектами появился реляционный подход. Несмотря на свою простоту и наглядность для пользователей, не ориентирующихся в дискретной математике, он позволяет моделировать как связи типа “многие-ко-многим”, так и иерархические (для этого достаточно связать сущность с самой собой связью типа “один-ко-многим”). Кроме того, развитие формального аппарата представление я манипулирования данными в рамках реляционной модели сделали ее наиболее перспективной для использования в системах представления знаний.

В последнее время все чаще при построении БД используется объектно-реляционный подход, при котором в БД могут храниться не только атрибуты экземпляров сущностей, но и описания действий, которые могут над ними производиться, а также привязывать эти последовательности операций над данными к различным событиям, что позволяет более эффективно поддерживать целостность данных – соответствие информационной модели (включающей структуру данных и сами данные), хранимой в БД, объектам реального мира и их взаимосвязям в любой момент времени.