Объектно-ориентированные базы данных: алгебраические операции.
http://minichden.narod.ru/articles/oodb.htm
Объектная алгебра не столь подробно разработана и не является столь же зрелой, как реляционная алгебра. Но как бы то ни было, такая алгебра существует, и в ней определяются пять фундаментальных операций, сохраняющих объекты: union, difference, select, generate и map. На основе этих фундаментальных операций могут быть определены другие операции, например, intersection. В то время как операции union,difference и map производят, главным образом, отображение «один к одному», операции select и generate производят отображение «один ко многим». Сохранение объектов означает, что алгебраические операции возвращают объекты, принадлежащие к ранее определенным классам базы данных, и не создают новых объектов. Оператор union возвращает объекты, содержащиеся во множестве P или во множестве Q, или в обоих множествах. Оператор difference возвращает набор объектов, принадлежащих множеству P, но не множеству Q. select возвращает подмножество введенного множества. generate генерирует объекты из тех, что принадлежат входному множеству. map возвращает множество объектов, образующихся в результате каждого применения последовательности методов.
Отображение модели сущность-связь в реляционную.
Конспект, стр 21.
Отображение модели «сущность-связь» в реляционную
• По существу описывается предикатным представлением модели «сущность-связь»
• Атрибуты представляются атрибутами
• Множества сущностей -> отношения
• Множества связей -> отношения
• Ключи -> ключи
• Ограничения целостности -> зависимости
• Автоматически получаются отношения в 3НФ
• Операций в ER нет
• Утрачивается различие между сущностями и связями
Использование объектных расширений при отображении модели «сущность-связь»
• Слабые сущности можно представлять вложенными коллекциями
• Агрегирование можно представлять вложенными объектами
• Наследование можно представить в объектной модели
Иерархическая и сетевая модели данных, отображения в другие модели.
Иерархическая модель данных
http://www.mstu.edu.ru/study/materials/zelenkov/ch_3_1.html#3_1_1
– Представление для приложения (внешняя схема всегда иерархическая)
– Связи между хранимыми иерархиями реализуются с помощью указателей
– Доминировала более 25 лет в промышленных приложениях
Система IMS/360, IMS/370
• Доминировала на рынке более 20 лет
• Иерархическое представление во внешней схеме
• Сетевые структуры на концептуальном уровне
• Развитые средства управления структурой хранения
• Выбор типа указателей: абсолютные, относительные, символические
• Сочетание навигации с ассоциативным поиском: условия фильтрации на путях
Сетевая модель данных
http://www.mstu.edu.ru/study/materials/zelenkov/ch_3_2.html
– Обработка отдельных объектов (записей)
– В основном навигационный доступ
– Все объекты имеют фиксированную длину, чтобы можно было обращаться по смещению
• Запись (record) <-> сущность
• Тип записи <-> множество сущностей
• Тип набора <-> множество связей типа 1:m
– Владелец и член набора (master /detail)
• Диаграммы Бахмана (граф типов записей и связей между ними)
Независимость данных в сетевой модели:
• Выбор полей записи (атрибутов) во внешней схеме
• Выбор используемых указателей для организации наборов (односторонние, двунаправленные, со ссылкой на владельца)
Навигация в сетевой модели данных
• Понятие «текущей» записи для каждого типа
• Переходы в наборе:
– От владельца к первому или к последнему
– К следующему, предыдущему, к владельцу
– Поиск по значению последовательным просмотром набора
Операции модификации: создание, обновление, удаление записей, включение записи в набор, исключение из набора
Ограничения целостности в сетевой модели: обязательность членства в наборе, обязательное удаление при удалении владельца
Rob, Coronel, стр 47:
Иерархическая – запись как запись-член только в одном отношении, сетевая – мб в нескольких. Сложность во всём. Нет связи много-много.
Конспект:
Предположим, есть таблица “Города {название, численность_населения, координаты,....}”, где ключом является название города. Тогда в других таблицах мы используем (для реляционного представления, естественно) вот это самое название Санкт-Петербург... А в сетевых моделях только ссылку на структуру, с описанием города.
Иногда делают так называемый суррогатный ключ, то есть заводят отдельную таблицу, там некий номер и название города 佀 в условиях нашего примера. Теперь по всей базе данных мы используем этот номер, что позволяет нам гибко изменять название города.
Надо заметить также, что в сетевой модели все связи записываются статически, в то время как в реляционной есть только таблицы, а связи вычисляются динамически, что даёт, несомненно, большую гибкость, но и требует большей вычислительной мощности.
Отображение модели «сущность-связь» в сетевую
• Множества сущностей и множества связей представляются типами записей
• Связи 1:m представляются наборами
• Связи m:n представляются дополнительным типом записи и двумя наборами (1:m и 1:n)
• Ограничения целостности должны проверяться приложением
Отображение сетевой модели в реляционную и обратно
• Типы записей представляются отношениями
• Необходимы суррогаты для идентификации записей
• Наборы представляются внешними ключами
• Ограничения целостности и операции нужно реализовывать
http://citforum.ru/database/advanced_intro/6.shtml#2.3.2