Проектирование реляционных баз данных

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

Для перехода от ИЛМ к реляционной можно воспользоваться следующими рекомендациями:

1) Для каждого простого объекта и его единичных свойств строится таблица, атрибутами которой являются идентификатор объекта и реквизиты, соответствующие каждому из единичных свойств:

2) Если у объекта имеются множественные свойства, то каждому из них ставится в соответствие отдельная таблица:

3) Если между объектом и его свойством имеется условная связь, то при отображении в реляционную модель возможны следующие варианты:

· если многие из объектов обладают рассматриваемым свойством, то его можно хранить в БД так же, как и обычное свойство;

· если только незначительное число объектов обладает указанным свойством, то при использовании предыдущего решения для многих записей в таблице значение соответствующего поля будет пустым. Для устранения этого недостатка выделяют отдельную таблицу, которая будет включать в себя идентификатор объекта и атрибут, соответствующий рассматриваемому свойству.

4) Если у объекта имеется составное свойство, то составляющие составного свойства либо помещаются в отдельные поля реляционной таблицы, либо в одно поле:

5) Если связь между объектами 1:1 и классы принадлежности обоих объектов являются обязательными, то для отображения данных объектов и связи между ними:

· можно использовать одну таблицу, первичным ключом которой может быть идентификатор любого из двух объектов;

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

6) Если связь между объектами 1:1 и класс принадлежности одного объекта является обязательным, а другого – необязательным, то для каждого из этих объектов используют отдельные таблицы, а идентификатор объекта, для которого класс принадлежности является необязательным, добавляется в таблицу, соответствующую тому объекту, для которого класс принадлежности обязательный:

7) Если связь между объектами 1:1 и класс принадлежности каждого объекта является необязательным, то следует использовать три таблицы: по одной для каждого объекта и одну для отображения связи между ними:

8) Если между объектами предметной области имеется связь 1:М и класс принадлежности n – связного объекта является обязательным, то используют две таблицы: по одной для каждого объекта и в таблицу, соответствующую n – связному объекту, добавляется идентификатор 1 – связного объекта:

9) Если между объектами предметной области имеется связь 1:М и класс принадлежности n - связного объекта является необязательным, то создают три таблицы: по одной для каждого объекта и одну для отображения связи между ними:

10) Если между объектами предметной области имеется связь М:М, то для хранения такой информации потребуется три таблицы: по одной для каждого объекта и одна для отображения связи между ними (классы принадлежности могут быть: оба – обязательными, оба - необязательными, один – обязательный, другой – необязательный):

11) Агрегированному объекту, имеющему место в предметной области, в ДЛМ ставится в соответствие одна таблица, атрибутами которой являются идентификаторы всех объектов, «задействованных» в данном агрегированном объекте, а также реквизиты, соответствующие свойствам этого объекта:

Такое объединение информации в одну таблицу возможно только в том случае, если между объектами имеется связь 1:1. Если же между объектами имеется связь М:1 (или М:М), то выделяют по одной таблице для каждого объекта и одну таблицу для связи:

R1 (ИО1, …)

R2 (ИО2, …)

R3 (ИО3, …)

R4 (ИО1, ИО2, ИО3, С1).

12) При отображении обобщенных объектов могут быть приняты разные решения:

· всему обобщенному объекту может быть поставлена в соответствие одна таблица:

· каждой из категорий ставится в соответствие отдельная таблица, то есть:

R1 (ИО1, С1, С2, С4, С5)

R2 (ИО1, С1, С2, С6, С7).

Кроме этих двух «крайних» решений, возможны и комбинированные варианты. Выбор конкретного решения будет зависеть от многих факторов, в том числе от того насколько часто информация о разных категориях объекта обрабатывается совместно, как велико различие в «видовых» свойствах и др.

13) При отображении составного объекта также возможны разные решения:

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

· если речь идет о составе какой-то организации, то между объектами скорее всего будет связь типа 1:М – в этом случае для отображения связи «целое – часть» можно использовать рекомендации пунктов 8 и 9.

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

Рис. 3.7. ER – модель предметной области

Рассмотрим упрощенный пример предметной области, ER – модель которой изображена на рис. 3.7.

Соответствующая ей даталогическая модель базы данных может иметь следующий вид:

Факультет (Код_фак, Кр_наим_фак, Полн_наим_фак);

Кафедра (Код_каф, Кр_наим_каф, Полн_наим_каф, Код_фак);

Сотрудник (Таб_номер, ФИО, Дата_рождения, Пол, Код_каф, Должность, Уч_степень);

Студент (Таб_номер, ФИО, Дата_рождения, Пол, Код_фак, Дата_поступления, Ступень_обучения);

Ин_яз (Код_языка, наименование_языка);

Знание_ин_яз (Таб_номер, Код_языка, Степень_владения);

Дети (Таб_номер, Имя, Дата_рождения).