Программирование >>  Реляционные базы данных 

1 ... 17 18 19 [ 20 ] 21 22 23 ... 125


I Прич11на отсутствия слабых классов в ODL

Вопрос о поиске ключа никогда не возникает в ODL или любой другой объектно-ориентированной модели. Как было показано в разлсле 2.5.2, можно построить ключ путем описания атрибута или атрибутов, хотя это и необязательно. Объект облааает с1юйством целостности объекта и в результате имеет адрес, по которому его можно найти, а ID объекта уникальным образом отличает один объект от другого даже тогда, когда их нс1ЮЗМожио различить по значениям их атрибугов или связям. А E/R-мо.аель ориентирована иа зг1аче-ние , и сущности различимы только по связанным значениям их атрибутов. Поэтому нужно осегаа учитывать, что в Е/Р-моделя.ч сущности любого множества можно различать только по значениям, не обращаясь ни к какой идеитичности объектоп .

2.6.4 Упражнения к разделу 2.6

Упражнение 2.6.1. Один из способов представления студентов н оценок, полученных ими на учебных курсах,- использование китожеств сущностей, соответствующих студентам, курсам и зачислениям . Зачисления образуют множество связующих сущносгей меаду студентами и курсами. Их можно использовать не только для представления того факта, что студент проходит определенный курс, ио для выражения отметок, полученных студентом по данному курсу. Представьте эт-у ситуацию в E/R-диаграмме. указав слабые множества сущностей и их ключи. Является ли ог.метка частью ключа для зачислений?

Упрожнение 2.6.2. Измените упражнение 2.6.1 так, чтобы можно было записывать отметки студентов в каждом случае выдачи заданий по данному курсу. Укажнт е слабые множества сущностей и ключи.

Упражнение 2.6.3. На E/R-диаграмме упражнения 2.3.3 укажите слабые множества сущностей и ключи.

Упражнение 2.6.4. Создайте E/R-диаграммы следующих ситаций, включающих в себя слабые множества сущностей, указывая каждый раз ключи для этих множеств.

а) Coiitsex и />/)о/плелв - множества сущностей. Курс преподается на единственном факультете, но единственным атрибутом курса является его номер. На разных факультетах мо1ут преподаваться курсы с одним и тем же номером. У каждого факультета уникапыюе имя.

! Ь) Leaffies, Teams н Players - миожесгвг сущностей. Имена лиг уникальны. Нн в одной лиге нет двух команд с одним и тем же названием. Ни в одной команде нет двух игроков с одним и те.м же нсмеро.м, но в разных кor,цлax могут быть троки с одним и тем же номером и в разных лигах MOi-ут быть команды с одним и тем же названием.



2.7 Модели, представляющие исторический интерес 61

2.7 Модели, представляющие исторический интерес

в этом рамеле рассматриваются еще две модели и часть относящейся к ним терминологии. Первыми попытками обоснования БД были сетевые и иерархические модели, применявшиеся в коммерческих БД в шестидесятых и семидесятых годах. Они были вытеснены системами, основанными на реляционных людслях, которые рассматриваются в главе 3. Однако многие идеи старых моделей сохранились и в новых объектно-ориентированных подходах к проектированию БД.

2.7.1 Сетевая модель

Сетевую модель можно считать E/R-моделью. ограниченной бинарными связями типа многие-к-олному . Ее основные элементы:

1. Типы логических записей. Они ана/югичны множествам сущностей и состоят из имени типа и списка атрибутов. Элементы типа логических записей называются записями, они аналогичны сущностям в E/R-модели.

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

Пример 2.32. Рассмотрим пример с фильмами и кинозвездами, которые в них играют, в сетевой модели. Кинозвезды и фильмы образуют типы логических записей. Однако связь stars-in между фильмами и кинозвездами - это связь типа многие-ко-многим , поэтому для ее представления в сетевой модели невозможно использовать единственную связь. Необходимо создать новый тип логических записей, называемый Slarsin, который является связующим подобно связующему множеству сущностей, введеннсму в разделе 2.2.5. Каждая запись Slarsin представляет пару кииозвезда-фильм, т.е. кинозвезду и фильм, в котором она играет. Получаем три типа логических записей для сетевой модели:

Stars(name, address) l\/1ovies(title. year, length. filmType) StarsInO

Первый из них имеет два атрибута: имя и адрес кинозве.зды, а второй - четыре атрибута: название, год выпуска, длину и тип фильма. Студия, связанная с фильмом, здесь не рассматривается, хотя в полном проекте эта связь была бы представлена с помощью соединения. В данной модели связующий тип Starsin не имеет атрибутов, но их можно приписать. Например, если записывается гонорар, полученный кинозвездой за огдельный филыи. он будет функцией пары кинозвезда-фильм и атрибутом Starsin. Однако в данном примере результат действия Slarsin проявляется только в связях, в которых этот ТИМ участвует.

В модели две связи. Первая из них направлена от Stars к Starsin, т.е. Stars - это тип владельца, а Starsin - тип члена. Эта связь, называемая TtieStar, соединяет кинозвезду с каждой парой кииозвезда-фильм, в которой она участвует. Вторая связь - TheMovie с типом владельца Movies и типом члена Starsin. Каждая запись о фильме владеет парами фильм-кинозвезда, в которую этот фильм входтгг. Обе связи - это связи типа многие-к-одному . Парой Starsin s) владеют запись Movies лля фильма m и запись Slars лля кинозвезды s. На рис. 2.29 показано, как соединяются связями все три типа логических записей.



Movies

TheMo

Stai-sln

TheStar

Stars

Основной инстинкт

Вспомнить всё

Шерон Стоун

Арнольд Шварценеггер

Рис. 2.29. Зописи и их сввэи

Эта диаграмма не является схемой, а показывает сами отдельные записи н способы их соединения с другими записями с помощью связей. На ней три записи Starsln. Номер I показывает, что Шерон Стоун - кинозвезда в фильме Основной инстинкт . Номер 2 представляет пару Шерон Отун/ Вспо.шитъ все , а номер 3 - пару Арнольд Шварценеггер/ Всиожиить все . Номера не являются реальными частями записей, а используются для ссылки на записи Starsln. Записи Starsln выступают членами обеих связей, а другие записи - владельцами. D

2.7.2 Представление сетевых схем

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

Пример 2.33. Схематическая диаграмма для трех логических типов записей и двух связей из примера 2.32 изображена на рис. 2.30. О

TheStar

TheMovie

(StatJ-- -(tarsln->-(оу1еГ

Рис. 2.30. CeTEBOR аемо для примера с фильмоми

2.7-3 Иерархические модели

Иерархическую модель можно считать ограничением сетевой модели, при ко тором логические типы записей и связи образуют лес (множество деревьев). Если каждая из связей показывает, что тип владельца является предком типа члена, типы логических записей образуют лес деревьев. Проблема с данным ограничением в том, что оно не выполнимо для некоторых сетей. Например, из рис. 2.30 явно, что для логического типа записи Starsln в иерархии нужны были бы два предка: Stars и Movies, поэтому схема на данном рисунке не является лесом.



1 ... 17 18 19 [ 20 ] 21 22 23 ... 125

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика