Постреляционные моделей данных
Реляционные БД не приспособлены для хранения объектов:
объекты могут содержать сложные структуры данных, а также указатели на другие объекты;
у объектов есть методы, соответственно, необходимо предусмотреть какой-то способ хранения методов.
Объектно-ориентированные модели данных (ООСУБД) – позволяют хранить объекты.
Объектно-ориентированные СУБД не имели коммерческого успеха, т.к. требовали преобразования существующих данных в объектно-ориентированный формат.
Компании отказывались делать такое преобразование, т.к. оно являлось весьма дорогостоящим и выигрыш от него не покрывал понесенных затрат.
Но потребность в постоянном хранении объектов никуда не исчезла, особенно в связи с развитием объектно-ориентированного программирования.
В связи с этим производители реляционных СУБД стали расширять возможности своих продуктов, чтобы наряду с обычным хранением реляционных данных обеспечить постоянное хранение объектов.
Объектно-реляционные модели данных (ОРСУБД) – позволяют хранить объекты наряду с хранением реляционных данных.
В частности, такие возможности предоставляет СУБД Oracle.
Преобразование концептуальной модели данных в реляционную модель данных
Концептуальная модель данных, выполненная с помощью ER-диаграммы, позволяет описать структуры данных и их связей в представлении пользователей.
Это представление необходимо преобразовать в реляционную модель данных, которая не зависит от конкретной реляционной СУБД.
Соответствие между основными элементами рассматриваемых моделей
Элемент ER-диаграммы |
Элемент реляционной модели |
Сущность |
Отношение (таблица) |
Атрибут сущности |
Атрибут (столбец, поле) отношения |
Связь |
Дублирование атрибутов (столбцов, полей) связываемых отношений |
Представление связи «один-к-одному»:
Каждая сущность (класс) представляется отношением.
Ключ одного из отношений помещается в другое отношение.
СОТРУДНИК
-
НомерСотрудника
Имя
Должность
…….
АВТОМОБИЛЬ
-
Номер
Производитель
Модель
НомерСотрудника
…….
Замечание:
Представление связи 1:1 можно было выполнить, создав копию ключа отношения АВТОМОБИЛЬ в отношении СОТРУДНИК. Но это было бы нерационально, т.к. большинство сотрудников не имеет служебных автомобилей, т.е. в столбце НомерАвтомобиля отношения СОТРУДНИК было бы много пустых ячеек.
Внешний ключ – атрибут (или группа атрибутов), представляющий собой копию первичного ключа другого отношения.
В предыдущем примере НомерСотрудника в таблице АВТОМОБИЛЬ является внешним ключом по отношению к таблице СОТРУДНИК.
«Подозрительные» связи 1:1 – обязательность связи в обоих направлениях;
– высока вероятность, что сущности отражают различные аспекты одного и того же объекта, особенно, если они имеют одинаковый ключ;
– сущности следует объединять в одно отношение.
СОТРУДНИК
-
НомерСотрудника
Имя
Должность
…….
АДРЕС_СОТРУДНИКА
-
НомерСотрудника
Улица
Дом
Квартира
Эти отношения целесообразно объединить:
СОТРУДНИК
-
НомерСотрудника
Имя
Должность
Улица
Дом
Квартира
Представление связи «один-ко-многим»:
Каждая сущность представляется отношением.
Ключ отношения, находящегося на стороне 1, помещается в отношение, находящееся на стороне М (внешний ключ).
ОБЩЕЖИТИЕ
-
Название
Адрес
КоличествоМест
…….
СТУДЕНТ
-
НомерСтудента
ИмяСтудента
……
НазваниеОбщежития
…….
Поле НазваниеОбщежития в таблице СТУДЕНТ является внешним ключом по отношению к таблице ОБЩЕЖИТИЕ.
Представление связи «многие-ко-многим»:
Каждая сущность представляется отношением.
Создается третье отношение, представляющее связь как таковую (отношение пересечения).
Ключ третьего отношения (отношения пересечения) является комбинацией ключей связываемых отношений.
СТУДЕНТ
-
НомерСтудента
ИмяСтудента
….
КЛУБ
-
НомерКлуба
Адрес
….
ДОСУГ
-
НомерСтудента
НомерКлуба
…..
Замечание:
Отношение пересечения может иметь, а может не иметь неключевых атрибутов.
Например, в отношение ДОСУГ можно включить неключевой атрибут ЧислоПосещений, значение которого определяется полностью композитным ключом отношения.
Представление подтипов:
Надтип представляется отношением.
Подтипы представляются отношениями.
К каждому отношению подтипа добавляется ключ надтипа.
КЛИЕНТ
-
НомерКлиента
ИмяКлиента
СуммаКОплате
ФИЗИЧЕСКОЕ_ЛИЦО
-
НомерКлиента
Адрес
НомерСоциальнойСтраховки
ТОВАРИЩЕСТВО
-
НомерКлиента
ИмяУправляющего
Адрес
ИНН
КОРПОРАЦИЯ
-
НомерКлиента
ДоверенноеЛицо
Телефон
ИНН