- •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.1.4. Связи в odl
Атрибуты объекта играют большую роль, однако иногда важнее знать то, как они связаны с объектами того же самого или другого класса.
Пример 4.3. Допустим, что к описанию класса Изделие из примера 4.1 добавляется свойство, представляющее множество работающих над ним мастеров. Поскольку сами мастера являются классом, описанным в примере 4.2, информацию о них нельзя сделать атрибутом Изделие, так как типы атрибутов не должны быть классами или строиться из классов. Множество занятых при работе над изделием мастеров, – это связь между классами Изделие и Мастер, которая выражается строкой
relationship Set<Мастер> мастера;
в описании класса Изделие. Эта строка может появиться в примере 4.2 после любой из строк – с 1 по 4. Она означает, что в каждом объекте класса Изделие есть множество ссылок на объекты класса Мастер. Множество ссылок называется мастера. Ключевое слово relationship определяет, что мастера содержит ссылки на другие объекты, а ключевое слово Set, предшествующее <Мастер>, показывает, что мастера ссылается на множество объектов Мастер, а не на единственный объект. В общем случае в ODL тип, являющийся множеством элементов другого типа Т, определяется ключевым словом Set и угловыми скобками, выделяющими тип Т.
Вообще говоря, в физических терминах множество мастера можно было бы представить списком указателей на объекты Мастер; сами объекты Мастер физически не появлялись бы в объекте Изделие. Однако на фазе проектирования БД физическое представление неизвестно и важным аспектом связи является то, что из объекта Изделие легко найти мастеров, работающим над данным изделием.
В примере 4.3 показана связь множества объектов (мастеров) с единственным объектом (изделием). Можно установить и связь единственного объекта с объектом описываемого класса. Предположим, например, что в примере 4.3 был задан тип связи Мастер, а не Set<Мастера >, с помощью строки
relationship Мастер к_мастеру;
Это значит, что с каждым изделием связан только один объект Мастер.
4.1.5. Обратные связи
Любая прямая связь подразумевает наличие обратной связи. Например, можно определять не только мастеров, занятых работой над изделиями, но и изделия, над которыми работал данный мастер. Для получения такой информации в объектах Мастер можно добавить строку
relationship Set<Изделия> от_мастера;
к описанию класса Мастер из примера 4.2. Однако в такой строке и сходном описании Изделие не учитывается очень важный аспект связи между изделиями и мастерами, а именно: если мастер S находится в множестве мастера для изделия M, то M находится в множестве от_мастера для мастера S. Это соотношение связей между множествами мастера и от_мастера выражается тем, что в описании каждой связи указывается ключевое слово inverse и имя другой связи. Если одна из связей находится в другом классе, как это обычно и бывает, ссылка на нее делается с помощью имени этого класса, за которым следуют двойное двоеточие (::) и имя связи.
Пример 4.4. Чтобы определить связь от_мастера класса Мастер как обращение связи мастера в классе Изделие, изменим описание класса Мастер следующим образом:
interface Мастер {
attribute string фамилия;
attribute string имя;
attribute string отчество;
attribute Struct Адреса {string город, integer индекс, string улица, string дом, integer квартира} адрес;
relationship Set<Изделие> от_мастера
inverse Изделие::мастера;};
В строке 6 выражено не только описание связи от_мастера, но и то, что данная связь имеет инверсию – Изделие::мастера. Поскольку связь мастера определена в другом классе, ее имени предшествуют двойное двоеточие и имя этого класса (Изделие). Такая нотация широко применяется при ссылках на свойства различных классов.
В примере 4.4 две обратные связи, каждая из которых соединяет объект (изделие или мастера) с множеством объектов. Как упоминалось ранее, есть связи и другого типа, соединяющие объект с единственным объектом другого класса. Понятие обращения связи при этом не изменяется. Общее правило: если связь R для класса С соединяет с объектом х класса С множество объектов y1, y2, ..., уn , то обратная к ней связь соединяет с каждым у объект х (возможно, наряду с другими объектами).
Можно представить связь R класса С с классом D в виде списка пар (или кортежей) отношения. Каждая пара состоит из объекта х из класса С и связанного с ним объекта у из класса D:
C |
D |
x1 |
y1 |
x2 |
y2 |
… |
… |
Если R имеет тип Set<D>, то существует несколько пар с одним и тем же С-значением. Если R имеет тип D, существует только одна пара с заданным С-значением. Тогда обращение R есть множество пар с обращенными компонентами:
C |
D |
y1 |
x1 |
y2 |
x2 |
… |
… |
Заметим, что это правило действует, даже если С и D являются одним и тем же классом. Существуют связи класса с самим собой, например связь "быть подчиненным" класса "сотрудники" с самим собой.