Сильные типы сущностей

Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных

Цель Определение набора отношений на основе локальной логической модели данных.

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

Для описания структуры создаваемых отношений мы воспользуемся языком DBDL (Database Definition Language), широко используемым в реляционных СУБД. Описание отношения на языке DBDL начинается с присвоенного ему имени, за кото­рым следует помещенный в скобки список имен его простых полей. Затем указыва­ется первичный ключ отношения и все его альтернативные и/или внешние ключи. После описания внешних ключей может указываться ссылочный первичный ключ, если таковой имеется.

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

Связи, которые сущность имеет с другими типами сущностей, представляются с помощью механизма первичных и внешних ключей. Для принятия решения о том, откуда взять и куда поместить значения атрибута(ов) внешнего ключа, предвари­тельно следует установить, какая из участвующих в связи сущностей является роди­тельской, а какая — дочерней. Родительской считается сущность, которая передает копию набора значений своего первичного ключа в отношение, представляющее до­чернюю сущность, где эти значения будут играть роль внешнего ключа.

Для каждой сильной (регулярной) сущности в локальной модели данных создается отношение, включающее все простые атрибуты этой сущности. В случае составных ат­рибутов (например, адреса) в отношение включаются только составляющие их простые атрибуты (такие, как улица, город, почтовый код). Ниже приведен пример состава от­ношения Staff, определенного для логической модели, показанной на рис. 8.7.

Staff (Staff No, FName, LName, Street, City, Postcode, Position, Sex, Salary) Primary Key Staff_No

•

Слабые типы сущностей

Для каждой слабой сущности, присутствующей в логической модели, создается отношение, включающее все простые атрибуты этой сущности. Дополнительно в от­ношение включается атрибут внешнего ключа, соответствующего первичному ключу сущности-владельца. Первичный ключ слабой сущности частично или полностью вы­водится из ключа сущности-владельца. Например, показанная на рис. 8.7 сущность Staff является владельцем слабой сущности Next of_Kin. Описание представляющего эту сущность отношения приведено ниже.

Next_of_Kin (StaffJto, MMame, Address, Tel_No, Relationship)

Priaary Key Staff_No, NMame,

Foreign Key Staff No references Staff(Staff_No)

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

Бинарные связи типа один к одному" (1:1)

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

Связь Staff Manages Branch, показанная на рис. 8.7, является связью типа 1:1, по­скольку каждым из отделений компании руководит единственный член персонала. Сущность Staff участвует в этой связи частично, тогда как сущность Branch — полно­стью. Та сущность, которая участвует в связи частично (Staff), определяется как ро­дительская, а та сущность, которая участвует в связи полностью (Branch), — как до­черняя. Следовательно, копия первичного ключа сущности Staff (родительской), представленного атрибутом Staff Но, пересылается в отношение Branch (дочернее). В результате отношения Staff и Branch должны быть определены следующим образом:

Staff (Staff No, FName, LName, Street, City, Postcode, Position, Sex, Salary) Primary Key "Staff_No

Branch (Branch_No, Address, Tel_No, Fax_No, Manager_Staff_No)

Primary Key Branch_No

Alternate Key Tel_No or Fax_No

Foreign Key Manager_Staff No references Staff(Staff_No)

Обратите внимание на то, что атрибут Staff_No, представляющий руководителя отделения, был переименован в Manager_Staff_No. Это сделано с целью более точно указать назначение данного внешнего ключа отношения Branch.

Бинарные связи типа „один ко многим" (1:М)

Для каждой бинарной связи типа 1:М, установленной в логической модели данных между сущностями Е1 и Е2, необходимо переслать копию атрибутов первичного ключа сущности Е1 в отношение, представляющее сущность Е2, где они будут играть роль внешнего ключа. Сущность, представляющая "единичную" сторону связи определяется как родительская, а сущность,.представляющая "множественную" сторону, —как до­черняя. Как и в предыдущем случае, для представления данной связи необходимо ско­пировать первичный ключ родительской сущности в отношение, представляющее до­чернюю сущность, где этот ключ должен быть описан как внешний. Ниже приведен пример, иллюстрирующий, как связь типа 1:М можно представить в отношениях, соз­данных на базе предложенной выше логической модели данных.

Связь Branch Has Staff, показанная на рис. 8.7, имеет тип 1:М, поскольку в каж­дом отделении работает несколько человек. В этом случае отношение Branch является "единичной" стороной связи и представляет родительскую сущность, тогда как от­ношение Staff является "множественной" стороной связи и представляет дочернюю сущность. Связь между этими двумя сущностями устанавливается путем помещения копии первичного ключа сущности Branch (родительской), представленного атрибутом Branch No, в отношение Staff (дочернее). В результате окончательный вид отношений Staff и Branch должен быть следующим:

Staff (Staff_No, FName, LName, Street, City, Postcode, Position, Sex, Salary, Branch No)

Primary Key Staff_No

Foreign Key Branch_No references Branch (Branch Jlo)

Branch (BranchJto, Address, Tel_No, Fax_No, Manager_Staff_No)

Primary Key Branch No

Alternate Key Tel_No or Fax_Mo

Foreign Key Manager Staff_No references Staff (Staff_No)

Связи типа “суперкласс/подкласс”

Для каждой присутствующей в логической модели данных связи типа "суперкласс/подкласс" сущность суперкласса необходимо определить как родитель­скую, а сущность подкласса — как дочернюю. Существуют различные варианты представления подобных связей в виде одного или нескольких отношений. Выбор наиболее подходящего варианта зависит от ограничений участия и пересечения, на­ложенных на участников связи типа "суперкласс/подкласс" (см. раздел 5.4.5).

Рассмотрим, например, связь типа "суперкласс/подкласс" сущности Property, по­казанную на рис. 7.1, б. Существуют различные способы отображения этой связи.

(Вариант 1}

All_Property (Property_No, Address, Type, Rent, Price)

Primary Key Property_No

(Вариант 2)

Property_for_Rent (Property Jio, Address, Type, Rent)

Primary Key Property_No

Property_for_Sale (Property_No, Address, Type, Price) Primary Key Property_No

(Вариант 3)

Property (Property_No, Address, Type)

Primary Key Property_No:

Property_for_Rent (Property_No, Rent)

Primary Key Property_No

Foreign Key Property_No references Property (Property_No)

Property for Sale (Property_No, Price)

Primary Key Property_No

Foreign Key Property_No references Property(Property_No)

Диапазон возможных вариантов решений простирается от помещения всех атри­бутов суперкласса в единственное отношение (вариант 1) до распределения всех ат­рибутов между тремя различными отношениями (вариант 3). Наиболее подходящий вариант для каждой связи типа "суперкласс/подкласс" определяется ограничениями, специфическими для данной конкретной связи. Связи, которые суперкласс Property имеет с его подклассами, являются тотальными и непересекающимися, поскольку каждый член суперкласса Property обязательно должен быть членом одного и только одного из подклассов (Property_for_Sale или Property_for_Rent). Поэтому самым целе­сообразным решением для связи типа "суперкласс/подкласс" с тотальными и непере­секающимися членами является представление каждого из подклассов в виде от­дельного отношения, содержащего копию первичного ключа суперкласса. Это второй вариант в приведенном выше примере. Однако на окончательное решение могут ока­зать влияние и другие факторы — в частности то, включены или нет отдельные под­классы в различные связи.

Документирование созданных отношений и атрибутов внешних ключей

Документирование состава отношений, созданных на базе каждой из логических моделей данных, осуществляется на языке DBDL. Отметим, что синтаксис языка DBDL может быть расширен с целью указания ограничений целостности для' внешних клю­чей (этап 2.6). Кроме того, следует обновить содержимое словаря данных для отобра­жения сведений о любых новых ключевых атрибутах, определенных на данном этапе.

Дата добавления: 2014-01-04