КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Сильные типы сущностей
Этап 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; Просмотров: 650; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |