Для реляционной БД проектирование логической структуры заключается в том, чтобы разбить всю информацию по таблицам, определив состав полей для каждой из этих таблиц.
Для перехода от ИЛМ к реляционной можно воспользоваться следующими рекомендациями:
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-й нормальной форме (вопросы нормализации в пособии подробно не рассматриваются, а выносятся на самостоятельное изучение).
Рассмотрим упрощенный пример предметной области, ER – модель которой изображена на рис. 4.6.
Рис. 4.6. ER-модель предметной области (пример)
Соответствующая ей даталогическая модель базы данных может иметь следующий вид:
Факультет (Код_фак, Кр_наим_фак, Полн_наим_фак);
Кафедра (Код_каф, Кр_наим_каф, Полн_наим_каф, Код_фак);
Сотрудник (Таб_номер, ФИО, Дата_рождения, Пол, Код_каф, Должность, Уч_степень);
Студент (Таб_номер, ФИО, Дата_рождения, Пол, Код_фак, Дата_поступления, Ступень_обучения);
Ин_яз (Код_языка, наименование_языка);
Знание_ин_яз (Таб_номер, Код_языка, Степень_владения);
Дети (Таб_номер, Имя, Дата_рождения).