Теория и практика построения баз данных (1088289), страница 56
Текст из файла (страница 56)
01 САМОЛЕТ (Кежтовдйномец, Тип, Налет) кю»к~ , н« 258 Глава 7. Проектирование баз данных в рамках объектной модели Рейс (нйнвйЯвйсе, Дата, АзропортОтправления, Азрапортназначения, Хеостоеойномер, НомерПилоте) Ограничения ссылочной целостности: Значение атрибута ХвостовойНомер в отношении РЕЙС должно существовать среди значений атрибута ХвостовойНомер в отношении САМОЛЕТ Значение атрибута НомерПилатв в отношении РЕЙС должно существовать среди значений атрибута НомерПипотв в отношении ПИЛОТ б Рис. 7.1Е.
Пример реляционного представления ассоциативного объекта и связанных с ним обьектов: в — ассоциативный обьвкт РЕЙС и связанные с ним обьвкты; б — реляционное представление обьектов САМОЛЕТ, ПИЛОТ и РЕЙС Обратите внимание на различие между ассоциативным отношением на рис. 7.16 и отношением пересечения на рис. 7.11. Принципиальная разница состоит в том, что в ассоциативной таблице хранятся данные, представляюитие некоторый аспект комбинации объектов; отношение же пересечения не содержит данных и существует лишь для того, чтобы указать, какие объекты связаны друг с другом.
Объекты вида родитель/подтип ПРедставление объектов вида Родит'ельггподтип (Родитель носит сгце название гшдтила) аналогично представлению сущностей с подтнпами. Мы вводим одно отношение для родительского объекта и по одному отношению для каждого объекта подтипа. Ключом каждого из этих отношений является ключ родителя. Преобразования семантических объектов в реляционные конструкции, 259 Ограничения ссылочной целостности: Значение атрибута А1 в отношении ОЗ должно существовать среди значений атрибута А1 в отношении 01 Значение атрибута А2 в отношении 03 должно существовать среди значений атрибута А2 в отношении 02 Рис. 7.1б. Общая схема преобразования ассоциативных объектов в отношения На рис 7 16, а представлен родительскии объект ЧЕЛОВЕК, которыи имеет два взаимоисключающих подтипа, СТУДЕНТ н ПРЕПОДАВАТЕЛЬ.
На рис. 7.16, а показано реляционное представление этих трех объектов. Каждый объект представля- ~ тся таблицей, и ключ у всех трех таблиц один и тот же. Отношения на рис. 7.16, б ставят перед нами следующую проблему. Чтобы онределиттч к какому из двух типов относится конкретный человек, прикладной программе придется выполнить поиск и в таблице СТУДЕНТ, и в таолице ПРЕПОДАВАТЕЛЬ. Если соответствующая запись будет обнаружена в таблице СТУДЕНТ, значит, человек является студентом; если в таблице ПРЕПОДАВАТЕЛЬ— значит, человек является преподавателем. Такой способ определения носит косвенный характер и, скорее всего, будет работать медленно, а если человек це принадлежит ни к одному из этих типов (что возможно), то лве таблицы будут нросканированы понапрасну.
Из-за этой проблемы в родительскую таблицу иногда помещается атрибут, указывающий тип. На рис. 7.16, а показаны две разновидности указателя типа. В первом варианте, который представлен в отношении ЧЕЛОВЕК1, юп1 объекта хранит атрибут ТипЧеловека. Возможными значениями этого атрибута являются строки «СТУДЕНТ», ПРОФЕССОР» или «ДРУГОЙ». Приложение может прочесть значение этого атрибута н таким образом определить, принадлежит ли человек к одному из подтипов, и сели да, то к какому. Второй вариант представлен в отношении ЧЕЛОВЕК2, имеющем два дополни~сльных атрибута: ТипСтудент и ТипПрофессор. Каждый из атрибутов является )й? !(/ ;кнзцав)г' ение;ВСГК ТипПреподаватель) е 260 Глава?.
Проектирование баз данных в рамках объектной модели булевой переменной с допустимыми значениями «петипа» и «ложь». Обрати- те внимание, что сели человек может принадлежать только к одяому из возмож- ных типов (как здесь), то когда одно из зтих значений истинно, другое должно быть ложна ЧЕЛОВЕК(Н ме С нойСт х вки, ИмяЧеловека, Телефон) СТУДЕНТ ( о иальнайСт и, Датарождения, СреднийБалл) ПРЕПОДАВАТЕЛЬ (Н о иал нойСт х ки, Звание, Кафедра) Ограничения ссылочной целостности: Значение атрибута НомерСоциальноиСтраховки в отношении СТУДЕНТ должно существовать среди значений атрибута НомерСоциальнойСтраховки в отношении ЧЕЛОВЕК Значение атрибута НомерСоциальнойСтрахавки в отношении ПРЕПОДАВАТЕЛЬ должно существовать среди значений атрибута НомерСоциальнойСтрэховки в отношении ЧЕЛОВЕК е Мкак»~щ.
~"ю'" т '» т'"" '> Рис. 7.1б. Пример реляционного представления объектов виде родитель/подтип: а — родительский объект ЧЕЛОВЕК и обьекты-подтипы СТУДЕНТ и ПРЕПОДАВАТЕЛЬ; б — реляционное представление родителя и подтипов; а — альтернативный вариант реляционного представления Вообще говоря, вариант, прелставлепный в отношении ЧЕЛОВЕК1, более предпочтителен в том случае, когда подтнпы являются взапмоисключаюшимн. Вариант, приведенный в отношении ЧЕЛОВЕК2, больше подходит в ситуациях, когда подтипы не исключают друг друга.
Обшая схема представления подпгпов показана на рис. 7.17. Одно отношение создается для родителя и по одному — для каждого нз подтипов, Ключом всех отношений является идентификатор родителя. Все связи между родителем и подтипами имеют впд 1:1. Обратите внимание на длинную черту, пересекающую линии связи, и на кардинальность группы подтипов.
Кардннальность 0.1.1 Преобразования семантических объектов в реляционные конструкции, 261 ~ппорит о том, что ни один из подтипов не является обязательным, по если он п(шгутствует, допустим максимум один подтип. Ограничения ссылочной целостности: Значение атрибута А1 в отношении 02 должно существовать среди значений атрибута А1 в отношении 01 Значение атрибута А1 в отношении ОЗ должно существовать среди значений атрибута А1 в отношении 02 Рис.
7.17. Общая схема преобразования объектов вида родитель/подтип в отношения (Вспомните, что кардинальность группы записывается в формате г.ш.п, где булево значение, определяющее, является ли группа подттшов необходимой, п1 — минимальное количество подтппов, которые должны иметь значение внутри ~ руппы, а и — максимальное количество подтипов, могущих иметь значение в группе Поэтому, например, в группе пз пяти подтппов кардннальность 1.2А указывает пн го, что группа является необходимой, по крайней мере два атрибута в ней ш шжны иметь значение и значение в ней могут иметь максимум четыре атрибута.) Объекты вида архетип~версия ( )бьскты вида архетип/версия — это обьекты, моделирующие различные итерации, игрени пли зкземпляры основного обьекта. Объекты на рпс.
7.18, и моделируют программные продукты, которые существуют в различных версиях. Г1римерами ш~/(оГттгых продуктов являются М(стево(г 1п(егпес Ехр!огег и !»тегзсаре (Час((!асог. ((римерами версий являются Асеева 2000 и Ассезв 2002. !'еляцпонное представление объекгов ПРОДУКТ и ВЕРСИЯ показано на рпс. 7.18, б. ()лпо отиогпсние введено для объекта ПРОДУКТ н одно — для объекта ВЕРСИЯ, Ключом объекта ВЕРСИЯ является комбинация ключа объекта ПРОДУКТ и локальп»го ключа (НомерВерсии) объекта ВЕРСИЯ. Примеры объектое 263 Подписной абонемент То зиЬзспЬв Мате Аббгезз 01 ВОВЗСЯ~РТ1ОМ Примеры объектов 262 Глава 7.
Проектирование баз данных в рамках объектной модели ПРОДУКТ (Цйаадццй, Описание, СуммаПродвжПродуктв) ВЕРСИЯ (Названная, Нямвелвваозц, ДагаВыходв, СуммвПродажВерсии) Ограничение ссылочной целостности: Значение атрибута Название в отношении ВЕРСИЯ должно существовать среди значений атрибута Название в отношении ПРОДУКТ б Рис.
7.18. Пример реляционного представления объектов вида архетип/версигж а — объект-архетип ПРОДУКТ и объект ВЕРСИЯ; б — их реляционное представление Ограничения ссылачной целостности: Значение атрибута А1 в отношении 02 должно существовать среди значений атрибута А1 в отношении 01 Риа. 7.! 9. Общая схема преобразования объектов вида врхетип/версия в отношения На рис.
7.19 показана общая схема преобразования объектов вида архетип/версия в отношения. Атрибут А1 отношения 02 является и локальньгм, и внешним ключом, а атрибут А2 является только локальным ключом. Чтобы на практике применить описанные понятия, рассмглрим несколько объектов, взятых из реальною бизнеса. Нримерьг расположены по возрастанию уровня сложности. Мы будем моделировать кахстыйг объект и представлять его с помощью отно- нн»ий, используя методы, описанные в этой главе. Ограничения ссылочной целостности для этих объектов вы сформулируете в ответах на вопросы 7.20, 7.21 и 7.22. ) )л рпс. 7.20, а показан подписной абонемент на журнал.
Этот абонемент может быть представлен по крайней мере двумя объектными структурами. Если издатели журнала Е(пе ттгоог(шогЫпй рассматривают подписчика как атрибут подписки, то подписка может быть смоделирована простым объектом, который представлягтся одним отношением, как показано на рис. 7.20, б. Г)Т)Е аоод ййХй й)пгот1апй П 1 уевг (б )ззиез) 1ог )изг $18 С 20% оЯ бгв пеггззшпб рисе. (Оигжбе Ше 0.8.
$21/уеаг.СН.З. 1ипбз, р(еезе) П 2 увагз (12 )ззиез) 1ог )изг $34 С ззчв 24% (Оигмбе Ше Н.З. $4012 уевгзСН.З. 1ипбз, р)евзе) Сйу Гдаге 2)р П Му рвутвпг )з епбозеб. П Р!евзе Ьйг те. Р1евзв згзп ту зиьзспрбол изип П сиггелг галие П лехг гззие.
биЬЦитйзу Гивппвге епбРв1е Агпппие мате Аббгезз Рис. 7.20. Апьтернагивные представления подписки: в — бланк подписки; б — подписка, смоделированная в виде одного абьекгв Примеры обьектов 265 Й!СЕ $ЦПЗР!ЕЗ ССЗТОМЕП Описание продукта 2Б4 Глава?, Проектирование баз данных в рамках объектной модели Если данная компания издает только один журнал и больше никаких публикаций не планирует.
структура па рпс, 7.20, б будет работать. Если же компания выпускает несколько различных изданий и клиент может подписаться более чем на одно из нпх, то данные о клиенте будут дублироваться для каждого издания, на которое этот клиент подписывается. Это будет не только пустой тратой файлового пространства издателя, но н источником раэдражения для клиента, поскольку если он сменит адрес, то будет вынужден подтвердить изменение адреса для каждого выписываемого им издания данного издательства. Если компания выпускает или планирует выпускать несколько изданий, более удачным решением будет смоделировать подписчика в виде отдельного объекта, как показано на рпс. 7.21.