Билет №7. 1. Алгоритм перехода от базовой ER-модели к схеме реляционной базы данных

1. Алгоритм перехода от базовой ER-модели к схеме реляционной базы данных. Отображение простых объектов
Для каждого простого объекта и его единичных свойств строится отношение, атрибутами которого являются идентификаторы объекта и реквизиты, соответствующие каждому из единичных свойств (рис. 3.1).

Рис. 3.1. Отображение единичных, множественных и составных свойств

Любой из уникальных идентификаторов объекта является вероятным ключом полученного отношения. Если объект имеет несколько уникальных идентификаторов, необходимо один из них выбрать в качестве первичного ключа. Часто (но не обязательно) в качестве первичного ключа выбирается самый короткий из вероятных ключей. На решение вопроса о выборе первичного ключа (кроме длины ключа) влияют следующие факторы:
1. Стабильность - может ли значение ключа изменяться. Желательно выбирать в качестве первичного ключа атрибуты, которые не изменяются.
2. Мнемоничность - легкость запоминания. Следует отдавать предпочтение тем из вероятных ключей, которые легче запомнить.
Среди названных выше критериев наиболее важным является стабильность. Если объект является зависимой по идентификации сущностью, то ключ соответствующего ему отношения будет составной, включающий идентификатор этого объекта и идентификатор «вышестоящего» объекта или, как говорят, идентификатор «основного» объекта «мигрирует» в таблицу, соответствующую зависимому объекту (рис. 3.2). Если идентификаторов у «главного» объекта несколько, то выбирается один из них, а именно тот, который выбран в качестве первичного ключа «основной» сущности. Полученный таким образом составной идентификатор зависимой по идентификации сущности будет использоваться во всех тех случаях, когда надо отображать связь этого «зависимого» объекта с другими.

Рис. 3.2. Отображение зависимой по идентификации сущности

Связь 1:М можно отображать в структуре БД как путем переноса ключа связанного объекта в таблицу, соответствующую подчиненному объекту (т.е. объекту, стоящему со стороны М), так и другими способами, а ключом таблицы, соответствующей подчиненному объекту, будет являться только идентификатор самого этого объекта. В случае зависимого по идентификации объекта связь 1:М дополнительно в схеме БД отображать не надо.
При создании таблицы в каждом конкретном случае надо решать, что выбрать в качестве ключа: естественный ключ, искусственный ключ, в том числе и созданный системой автоматически, а может быть, если СУБД это позволяет, отказаться от создания ключа вообще.
Если у объекта имеются множественные свойства, то каждому из таких свойств ставится в соответствие отдельное отношение, полями которого будут идентификатор объекта (если у объекта несколько идентификаторов, то тот, который выбран в качестве первичного ключа) и поле, соответствующее множественному полю. Ключ этого отношения будет составным, включающим оба эти атрибута (см. рис. 3.1).
Приведенное выше решение является универсальным. В отдельных случаях могут быть приняты и другие решения. Так, если число экземпляров множественного свойства у каждого из объектов невелико и в процессе обработки не возникает необходимости «выделять» каждое из этих значений, то можно все значения, относящиеся к одному объекту, хранить в одном поле. В этом случае отдельную таблицу для хранения множественного свойства создавать не надо.
Если объект обладает условными свойствами, то при отображении их в реляционную модель возможны следующие варианты:
1) если многие из объектов обладают рассматриваемым свойством, то его можно хранить в базе данных так же, как и обычное свойство, т.е. в той же таблице, в которой бы атрибут хранился, если бы свойство было определенным для всех экземпляров рассматриваемой сущности;
2) если только незначительное число объектов обладает указанным свойством, то для многих записей в файле базы данных при использовании предыдущего решения значение соответствующего поля будет пустым. Для устранения этого недостатка можно выделить отдельное отношение, которое будет включать идентификатор объекта и атрибут, соответствующий рассматриваемому свойству. Это отношение будет содержать столько строк, сколько объектов имеет рассматриваемое свойство. Однако это решение в свою очередь имеет недостатки (в частности, усложнение структуры БД и сложности ее обработки) и применяется сравнительно редко.
На рис. 3.1 использован вариант «а». Если бы было выбрано второе из обсуждаемых решений, то из отношения R1 атрибут С5 следовало бы исключить и создать дополнительно новое отношение R4 (ИО1, С5). Если объект имеет составное свойство, то возможны два способа его отображения в БД:
1) всему составному свойству ставится в соответствие одно поле;
2) каждому из составляющих элементов составного свойства ставится в соответствие отдельное поле.
Выбор варианта будет зависеть, в основном, от характера преимущественной обработки этой информации: так как в большинстве СУБД гораздо проще при реализации запросов объединить поля, чем выделить из единого поля нужную часть, то, в случае если предполагается использование отдельных компонентов составного свойства, лучше использовать вариант 1, в противном случае - вариант 2.
* Универсальным способом отображения связи между объектами является введение вспомогательного связующего файла, содержащего идентификаторы связанных объектов. Ключ этого отношения будет составным. Такое решение является практически единственно приемлемым при наличии связи М:М между объектами. Дополнительными доводами в пользу такого решения является также наличие необязательного класса членства объекта в связи.
Во многих случаях можно использовать другие, более эффективные способы отображения связей в структуре БД. Выбор проектного решения, прежде всего, будет зависеть от типа связи между объектами.
Если между объектами предметной области имеется связь М:М, то для хранения такой информации потребуется три отношения: по одному для каждой сущности и одно дополнительное - для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов (рис. 3.3). Ключ этого отношения будет составным.

Рис. 3.3. Отображение связи М:М

Если между объектами предметной области имеется связь 1:М, то можно, как и в случае связи М:М, использовать отдельную связующую таблицу (рис. 3.4б - вариант 2). В отличие от связи М:М ключом связующей таблицы будет только идентификатор объекта, к которому направлен «единичный» конец связи.

Рис. 3.4. Отображение связи 1:М

Однако если между объектами предметной области имеется связь 1:М и класс принадлежности n-связной сущности является обязательным, то можно использовать только два отношения (по одному для каждой сущности) и не использовать дополнительную связующую таблицу. В отношение, соответствующее 1-связной сущности (т.е. сущности, к которой идет единичная связь), при этом надо дополнительно добавить идентификатор связанного с ней объекта (рис. 3.4б - вариант 1).
Если класс принадлежности n-связной сущности является необязательным, то появляется дополнительный довод в пользу решения о создании для отображения связи третьего отношения, которое будет содержать ключи каждой из связанных сущностей (рис. 3.4б - вариант 2).

Рис. 3.5. Отображение связи 1:1
Наличие между объектами связи типа 1:1 является довольно редкой ситуацией в реальной жизни. В принципе, если связь между объектами 1:1 и класс принадлежности обеих сущностей является обязательным, то для отображения обоих объектов и связи между ними можно использовать одну таблицу (рис. 3.5б - вариант 3). Такое решение потребует меньше всего памяти для своей реализации. Например, если имеются объекты СОТРУДНИК и ПАСПОРТ, то такое решение будет вполне приемлемым. Однако таким решением не следует злоупотреблять. Может случиться, что для каждого из объектов, находящихся в связи 1:1, в дальнейшем потребуется отразить какие-то свои связи или в запросах часто требуется информация отдельно по каждому из объектов, тогда выбранное решение может усложнить или замедлить работу с БД. Если для каждого из этих объектов создаются отдельные отношения, то информацию о связях между ними можно отразить, включив в одно из отношений идентификатор связанного объекта из другого отношения. Причем если класс принадлежности обеих сущностей является обязательным, то (если руководствоваться только типом связи) это можно сделать в любом из отношений (рис. 3.5б - варианты 1, 2).
Если класс членства одного из объектов является необязательными, то идентификатор сущности, для которой класс принадлежности является необязательным, добавляется в отношение, соответствующее тому объекту, для которого класс принадлежности - обязательный.
Если степень связи между объектами равна 1:1 и класс принадлежности каждой из них является необязательным, то, чтобы избежать наличия пустых полей, следует использовать три отношения: по одному для каждой сущности и одно - для отображения связи между ними (рис. 3.5б - вариант 4). В приведенном решении в качестве ключа связующей таблицы обозначен ИО1. С таким же успехом мог быть выбран ИО2.
Альтернативная связь обычно используется при изображении агрегированного объекта и означает, что в действии участвует либо один объект, либо другой, но не оба вместе. Альтернативная связь трудна для ее «автоматического» преобразования в датало- гическую модель. Может быть в связи с этим она отсутствует в большинстве CASE-средств. Естественным кажется путь, при котором в таблице базы данных, соответствующей объекту, к которому идут альтернативные связи, всем этим связям будет соответствовать одно поле, в котором будет зафиксирован идентификатор связанного объекта. В экземпляре записи в этом поле будет записано значение идентификатора того объекта, который участвует в отображаемой связи в каждой конкретной ситуации. Но такое решение имеет множество недостатков, связанных с последующей обработкой таким образом спроектированных таблиц, и его, в большинстве случаев, не рекомендуется использовать.
Другой вариант решения: для отражения связи с каждым из альтернативных классов объектов использовать отдельную таблицу.
Часто объекты, объединенные альтернативной связью, по сути, являются подклассами обобщенного класса. * Отображение агрегированных объектов.
Каждому агрегированному объекту, имеющему место в предметной области, в реляционной модели будет соответствовать отдельное отношение. Атрибутами этого отношения будут являться идентификаторы всех объектов, «задействованных» в данном агрегированном объекте, а также реквизиты, соответствующие свойствам этого агрегированного объекта.
Для отношений, соответствующих агрегированным объектам, ключ будет составной. В большинстве случаев им будет являться конкатенация (соединение) идентификаторов объектов, «участвующих» в этом агрегированном объекте.

Рис. 3.6. Отображение агрегированного объекта

Рис. 3.7. Отображение нескольких агрегированных объектов, имеющих одинаковые связи

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

* Отображение обобщенных объектов.
При отображении обобщенных объектов могут быть приняты разные решения.
Во-первых, всему обобщенному объекту может быть поставлена в соответствие одна таблица базы данных (рис. 3.8б - вариант 1). В этом случае атрибутами этой таблицы будут идентификаторы обобщенного объекта, все единичные свойства, присущие объектам хотя бы одной категории, включая свойство, по которому производится разбиение на подклассы. Ключом таблицы будет один из идентификаторов этого объекта.

Рис. 3.8. Изображение обобщенного объекта

Другим «крайним» вариантом является решение, при котором каждой из категорий объектов нижнего уровня ставится в соответствие отдельное отношение (рис.3.8б - вариант 2). В этом случае каждое отношение будет включать в себя идентификатор объекта (если идентификаторов несколько, то в каждое из отношений будут включены все они; это не приведет к дублированию информации на уровне значений), свойства, присущие родовым объектам, а также свойства, присущие данному подвиду объектов. Свойство, по которому производится разбиение класса на подклассы, в этом случае в качестве поля не включается ни в одно из отношений.
Кроме этих двух «крайних» решений возможны и комбинированные варианты. Например, можно выделить общую таблицу для отображения «родовых» свойств объектов (включающую еще и все идентификаторы объекта) и отдельные таблицы для отображения «видовых» свойств (такой алгоритм используется в системе Design/IDEF). Кроме свойств, присущих видовому объекту, в каждом из этих отношений будет повторен ключевой атрибут «основного» отношения (рис. 3.8б - вариант 3). Другим вариантом проектного решения для отображения обобщенного объекта является использование так называемого «кодированного формата файла», при котором, как и варианте 1, используется одна таблица, но для всех «видовых» свойств каждого из подклассов выделяется одно поле, содержимое которого распознается по значению свойства, по которому производится разбиение класса на подклассы. Выбор конкретного решения будет зависеть от многих факторов, в том числе, насколько часто информация о разных категориях объектов обрабатывается совместно, как велико различие в «видовых» свойствах и т.д.
Приведенный выше алгоритм основывается на предположении, что классификация объектов не являлась «фасетной». Если в обобщенном объекте наблюдается разбиение на подклассы по разным несоподчиненным признакам, то варианты 1 и 3 останутся верны, а вариант 2 должен быть уточнен.
Кроме того, алгоритм не учитывает, что классы могут быть пересекающимися. Для пересекающихся классов нельзя без модификации использовать вариант а) (так как признак классификации у каждого из экземпляров объекта может иметь несколько значений), но может быть использован вариант б).