Отображение простых объектов

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ N 9.

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

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

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

Для объекта O1 (см. рис. 2.62, а) отношение может выглядеть следующим образом:

Rl (ИO1, C1, C2, C5, C6). (3.1)

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

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

2. Мнемоничность - легкость запоминания. Поскольку в качестве ключа обычно используются короткие обозначения, то при прочих равных условиях следует отдавать предпочтение тем из вероятных ключей, которые легче запомнить.

Среди названных выше критериев наиболее важным является стабильность. Например, если у объекта КАФЕДРА есть три идентификатора: «Наименование_кафедры_полное», «Наименование_кафедры_краткое» и «Код_кафедры», то даже если «Краткое_наименование» короче других полей, скорее всего в качестве первичного ключа будет выбираться «Код», потому что наименования кафедр подвержены достаточно частым изменениям. Поэтому в алгоритме при выборе первичного ключа в качестве «решения по умолчанию» принимается более короткий идентификатор, но от пользователя требуется либо подтвердить это решение, либо выбрать иной первичный ключ.

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

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

а - фрагмент ER-модели; б - реляционная таблица

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

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

Отображение множественных свойств объекта. Если у объекта имеются множественные свойства, то каждому из них ставится в соответствие отдельное отношение, полями которого будут идентификатор объекта (при наличии у объекта нескольких идентификаторов - тот из них, который выбран в качестве первичного ключа) и поле, отображающее множественное свойство. Ключ этого отношения будет составным, включающим оба эти атрибута. Так, для множественных свойств С3, С4 (см. рис. 2,62, а) будут созданы отношения

R2 (ИO1, C3);

R3 (ИО1, C4).

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

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

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

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

В отношении (3.1) использован вариант 1. Если бы было выбрано второе из обсуждаемых решений, то из отношения R1 атрибут С5 следовало бы исключить и создать дополнительно новое отношение:

R4 (ИO1, C5). (3.2)

Отображение составных свойств объекта. Если объект имеет составное свойство, то возможны два варианта его отображения в БД:

1. Всему составному свойству ставится в соответствие одно поле (3.1).

2. Каждому из составляющих элементов составного свойства ставится в соответствие отдельное поле:

Rl (ИО1, C1, C2, C5, C7, C8). (3.3)

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

2. Возможности ввода информации в реляционных СУБД.

Дата добавления: 2015-04-24