Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 28)

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

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

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

Рассмотрим рекомендации по переходу от базовой ER-модели к схеме реляционной базы данных для каждого типа элементов ER-модели.

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

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

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

Rl (ИO₁, C₁, C₂, C₅, C₆). (3.1)

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

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

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

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

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

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

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

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

Некоторые СУБД (например, Access, Paradox и др.) позволяют ав­томатически генерировать поле типа «счетчик» в качестве ключа таб­лицы. Этот искусственный код вполне можно создавать для простых объектов, если в предметной области не предполагается использова­ние другой системы кодирования объектов (например, для предприя­тий или иных объектов хозяйственной деятельности в БД все равно в большинстве случаев приходится хранить коды ОКПО, ОКОНХ, ИНН; в этом случае создавать дополнительный код может не иметь смысла). Созданные коды будут в дальнейшем использоваться для связи дан­ного объекта с другими объектами в БД.

Если такой код применять при создании таблицы, соответствую­щей агрегированному объекту, то вряд ли он будет где-то исполь­зоваться в дальнейшем, хотя это утверждение нельзя рассматривать категорично. Например, для агрегированного объекта СДАЧА_ЭКЗАМЕНА каждая попытка может иметь дополнительную информацию (какие вопросы были заданы и т.п.). В этом случае для отображения этой информации может потребоваться отдельная таблица и код «сдачи экзамена» может оказаться полезным.

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

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

R2 (ИO₁, C₃);

R3 (ИО₁, C₄).

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

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

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

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

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

R4 (ИO₁, C₅). (3.2)

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

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

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

Rl (ИО₁, C₁, C₂, C₅, C₇, C₈). (3.3)

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

Отображение связи между объектами

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

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

Рис. 3.2. Отображение связи М:М: а - фрагмент ER-модели;

б - реляционные таблицы

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

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

Если класс принадлежности n-связной сущности является необя­зательным, то появляется дополнительный довод в пользу решения о создании для отображения связи третьего отношения, которое будет содержать ключи каждой из связанных сущностей (рис. 3.3, б - вари­ант 2).

Рис. 3.3. Отображение связи 1:М: а - фрагмент ER-модели;

б - реляционные таблицы

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

Характеристики

Список файлов книги