Вопрос 4. Этапы проектирования реляционной БД методом «сущность - связь». Даталогическое проектирование. Пример: построить реляционную схему для данной инфологической конструкции

Этапы проектирования реляционной БД методом «сущность – связь». Даталогическое проектирование. Пример: построить реляционную схему для данной инфологической конструкции.

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

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

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

R 1( ИО1 , С1, С2) или R 1( ИО1 , С1) и R 1`( ИО1 , С2)

R 2( ИО2 , С3, ИО1)

R 3( ИО2 , С4, С5)

R 4( ИО3 , С6, С7)

R 5( ИО2, ИО3 )

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) При отображении обобщенных объектов могут быть приняты разные решения:

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

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

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

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

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

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

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

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