Известно много моделей данных (родословная моделей данных представлена на Рис. 5). С двумя моделями: реляционной и многомерными кубами – мы познакомились в предыдущей главе.
Рис. 5. Родословная моделей данных
Предшественниками реляционной модели, наиболее распространенной в наши дни, были иерархические и сетевые базы данных.
Иерархические базы данныхпредставляют собой иерархию экземпляризируемых классов. Связи между классами бинарны, неименованы, без атрибутов. Запись-потомок имеет только одного предка. Пример схемы иерархической базы данных приведен на Рис. 6.
Рис. 6. Пример схемы иерархической базы данных
Пример запроса к иерархической базе данных: для данного отдела найти всех продавцов (построить дерево). Пример ограничения целостности: не существует менеджера без отдела.
Главный недостаток модели заключается в том, что предметные области с трудом описываются иерархиями. В рассматриваемый пример невозможно добавить сущность «покупатель», связанную с продажами.
В сетевых базах данныхзаписи объединяются в сеть за счет ссылок друг на друга. В отл. от иерархий, запись может иметь много предков. Пример схемы сетевой базы данных приведен на Рис. 7.
Рис. 7. Пример схемы сетевой базы данных
Запросы: перейти от предка к потомку по некоторой связи, от потомка к предку по связи, включить или исключить из связи. Например, для заданного продавца найти его коллег (переход от продавца к отделу по связи «работает в», а затем – от отдела к продавцам по связи «состоит из»).
Пример схемы реляционной базы данных приведен на Рис. 3. В реляционных базах данных таблицы связаны отношениями «один к одному», «один ко многим», «многие ко многим». Связь «один ко многим» означает то, что одной записи в первой таблице может соответствовать несколько записей в другой таблице. Связи в реляционных базах данных неименованы и без атрибутов.
Обобщением иерархической, сетевой и реляционной моделей данных является диаграмма «сущность-связь» Чена.Долгое время она оставалась не реализованной в СУБД, но, за счет своей наглядности, активно применялась на этапе логического проектирования базы данных. В настоящее время диаграмму «Сущность-связь» поддерживает СУБД Adabas. В этой модели между классами сущностей существуют именованные n-арные связи с атрибутами. Объект может принадлежать к нескольким сущностям. Сущности могут входить в связь в нескольких ролях. Сущности обозначаются прямоугольниками, а связи – ромбиками. Связи также как и сущности могут иметь атрибуты. Атрибуты обозначаются овалами. Пример диаграммы «Сущность-связь» приведена на Рис. 8.
Рис. 8. Пример диаграммы «Сущность-связь»
Диаграмма «Сущность-связь» легко преобразуется в реляционную модель. Сущностям соответствуют таблицы, связям с арностью больше двух и связям с атрибутами также соответствуют таблицы. Бинарные связи «многие ко многим» заменяются на вспомогательные таблицы, соединенные со связываемыми таблицами двумя связями «один ко многим».
Популярность объектно-ориентированной парадигмы (ООП) привела к появлению объектно-ориентированных (ООБД) и объектно-реляционных баз данных (ОРБД). В объектно-реляционных базах данныхпоявляются дополнительные связи «наследование» и «агрегация». В качестве объекта может рассматриваться атрибут или строка таблицы. Существуют методы – функции, которые могут обрабатывать строки без явной их передачи в качестве параметра.
СУБД «продажи» может быть преобразована в ОРБД следующим образом: создается класс «человек», который связями наследования связан с таблицами «продавцы» и «покупатели». В него переносятся атрибуты, общие для таблиц «покупатели» и «продавцы» - фамилия, имя, отчество и паспортные данные. Паспортные данные – сложный атрибут, для которого создается свой класс. Предположим, что покупатель в одном заказе может заказать несколько разных товаров. Тогда таблица продажи превращается в две таблицы – «Заказ» и «Строка заказа». «Заказ» содержит номера покупателей, продавцов, стоимость и дату, а «Строка заказа» - номера товаров и их количество. Таблицы «Заказ» и «Строка заказа» связаны между собой связью агрегация.
Объектно-ориентированные базы данныхфактически представляют собой объектно-ориентированные языки программирования, например, С++, Java или Smalltalk, в которые добавлена перманентность объектов – возможность объектов сохранять свои свойства между выполнениями программы. Долгое время в них не было триггеров и транзакций. Теперь эти возможности появились в некоторых ООБД.
Некоторые исследователи решили добавить связи наследования и агрегации к диаграмме «Сущность-связь». Таким образом, появились ранние средства проектирования: нотации Коада-Йордана, Шлаера-Меллора, Рамбо, Буча. Затем некоторые из этих исследователей объединились и создали UML – универсальный язык моделирования, который является наиболее распространенным средством объектно-ориентированного проектирования, позволяющего описать структуры как баз данных, так и объектно-ориентированных приложений (изучается в курсе «Проектирование информационных систем»).
В диаграмме «сущность-связь» связи могут иметь атрибуты, что делает их похожими на сущности. Для большего учета семантики создателем реляционной модели – Коддом была предложена расширенная реляционная модель - RM/T. В ней не делается разница между сущностями и связями. Связи могут соединять связи.
В интеллектуальных информационных системах традиционно применяются семантические сети (разновидностью которых можно считать «Сущность-связь» Чена), фрейм-слот, логические и продукционные модели. В последнее время появились гибридные модели, соединяющие эти модели с архитектурами баз данных – интеллектуальные и дедуктивные базы данных и онтологии (изучаются в курсе «Представление знаний в информационных системах»).
Д/З 3. Для предметной области из Д/З 1 составьте диаграмму «Сущность-связь» Чена (учтите таблицы из Д/З 2). Придумайте объектно-реляционное расширение модели со связями наследования и агрегации.
Вопросы для самопроверки:
Поставьте плюсы в следующей таблице там, где, по-вашему, ответы верны:
