- •1. Основы построения баз данных 11
- •2. Модели представления данных 22
- •3. ДатАлогические модели данных 38
- •4. Семантическое моделирование 101
- •5. Базы данных в сетях 155
- •6.Современное состояние и 177
- •1. Основы построения баз данных
- •1.1. Архитектура системы баз данных
- •1.2. Жизненный цикл базы данных
- •Контрольные вопросы и задания
- •2. Модели представления данных
- •2.1. Классификация моделей данных
- •2.2. Разновидности инфологических моделей данных
- •Контрольные вопросы и задания
- •3. ДатАлогические модели данных
- •3.1. Иерархические модели
- •Между предками и потомками автоматически поддерживается целостность ссылок. Основное правило: никакой потомок не может существовать без своего родителя, у некоторых родителей не может быть потомков.
- •3.2. Сетевые модели
- •3.3. Реляционные модели
- •3.3.1. Основные понятия реляционной модели
- •3.3.2. Реляционная алгебра
- •3.3.3. Язык запросов по образцу qbe
- •3.3.4. Структурированный язык запросов sql
- •Основные инструкции языка sql
- •Values ("3110", "чп Иванов п.Т.", null)
- •3.4. Проектирование реляционных баз данных
- •Контрольные вопросы и задания
- •4. Семантическое моделирование
- •4.1. Объектно-ориентированное проектирование
- •4.1.1. Представление объектов
- •4.1.2. Описания классов
- •4.1.3. Атрибуты в odl
- •4.1.4. Связи в odl
- •4.1.5. Обратные связи
- •4.1.6. Множественность связей
- •4.1.7. Типы в odl
- •4.1.8. Проектирование с использованием odl
- •Правильность
- •Устранение избыточности
- •4.1.9. Подклассы
- •4.1.10. Множественное наследование в odl
- •4.1.11. Моделирование ограничений
- •Ссылочная целостность
- •Прочие ограничения
- •4.1.12. Переход от объектно-ориентированной модели к реляционной
- •4.2. Диаграммы "сущность-связь"
- •4.2.1. Компоненты диаграмм "сущность-связь"
- •4.2.2. Множественность e/r-связей
- •Многосторонние связи
- •4.2.3. Роли в связях
- •4.2.4. Атрибуты связей
- •4.2.5. Конвертирование многосторонних связей в бинарные
- •4.2.6. Проектирование e/r моделей
- •Простота
- •Типы элементов проекта
- •Определения подклассов
- •Наследование в e/r-модели
- •Моделирование ограничений
- •Ссылочная целостность
- •Слабые множества сущностей
- •Переход от e/r-диаграмм к реляционным проектам
- •Контрольные вопросы и задания
- •5. Базы данных в сетях
- •5.1. Архитектура "клиент-сервер"
- •5.2. Распределенные базы данных
- •5.3. Базы данных в Интернет
- •Контрольные вопросы и задания
- •Контрольные вопросы и задания
- •Информационные ресурсы Internet
- •Словарь терминов
- •Список сокращений
- •Темы рефератов
Типы элементов проекта
Часто приходится выбирать тип элементов проекта, применяемых для представления объектов реального мира. При этом часто выбор заключается в том, что использовать: атрибуты или же классы, множества сущностей. В общем случае атрибут проще реализовать, чем любой класс/множество сущностей или связь. Впрочем, если все делать только с помощью атрибутов, возникнут осложнения.
Пример 4.21. Рассмотрим пример, иллюстрирующий эффект от применения многосторонней связи, и эквивалентный пример с использованием бинарных связей. Связь Договоры между мастером, изделием и двумя цехами (рис. 51) является четырехсторонней и механически конвертируется в множество сущностей Договоры (рис. 54). Имеет ли значение, какой из этих подходов выбирается?
Решение в ODL однозначно, так как многосторонних связей не существует. В E/R-модели приемлем любой подход. Однако незначительное изменение исходной задачи практически вынуждает нас выбирать подход, при котором используется множество связующих сущностей. Для иллюстрации предположим, что в договоре могут фигурировать один мастер, одно изделие, но любое множество цехов. Эта ситуация сложнее той, что изображена на рис. 51, где было всего два цеха, играющие две роли. Сейчас допускается любое число цехов. Один, возможно, выпускает изделие, в другом делается плиссировка и т.д. Таким образом, приписать роли цехам невозможно.
В данном случае оказывается, что множество отношений для связи Договора должно содержать тройки вида
(мастер, изделие, множество цехов),
а сама связь Договоры – не только обычные множества сущностей Мастера и Изделия, но и новое множество сущностей, элементами которого являются множества цехов. Если такой подход допустим, считать множества цехов базовыми сущностями неприемлемо.
Лучше считать множеством сущностей Договоры. Как и на рис. 54, договор связывает мастера, изделие и множество цехов, но теперь число цехов не ограничено. Поэтому между договорами и цехами имеется связь типа "многие-ко-многим", а не "многие-к-одному", как это было бы, если бы договора были настоящим множеством "связующих" сущностей.
Набросок E/R-диаграммы показан на рис. 56. Заметим, что здесь договор связан с единственным мастером и единственным цехом, но с произвольным множеством цехов.
Такая же стратегия проектирования подходит и для ODL. Например, вполне приемлемо следующее описание интерфейса ODL:
interface Договор{
relationship Мастер мастер1;
relationship Изделие изделие1;
relationship Set<Цех> цеха;
};
Здесь объекты договоров имеют три связи: с единственным мастером, с единственным изделием и с множеством цехов. Обратные связи опущены.
Определения подклассов
Как уже было рассмотрено, классы в ODL аналогичны множествам сущностей в E/R-модели. Пусть класс С – это подкласс класса D. Для выражения этого понятия в E/R-модели мы соединяем множества сущностей, соответствующие классам С и D специальной связью isa. Множества сущностей С и D обозначаются обычными прямоугольниками. Атрибуты, или связи, относящиеся только к сущностям С, присоединяются к прямоугольнику С, а атрибуты, применимые к С и D, размешаются у D.
Связь isa обозначается линиями с треугольниками в середине. Вершина каждого треугольника указывает на суперкласс.
Пример 4.22. На рис. 57 показаны множество сущностей Изделия и два его подкласса: Кожаные_изделия и Меховые_изделия.
Треугольники, помеченные isa, указывают от Кожаные_изделия и Меховые_изделия на суперкласс Изделия.
Связи мастером и относится, связывающие Изделия с Мастера и Цеха, не показаны, но предполагается, что есть связь скорняжные_пошивы между Меховые_изделия и Мастера.