- •Системы управления базами данных введение
- •1. Компоненты субд
- •1.1. Типы и структуры данных
- •1.1.1. Основные типы данных.
- •1.1.2. Обобщенные структуры или модели данных.
- •1.2. Методы доступа к данным.
- •1.2.1.Методы поиска по дереву.
- •1.2.2.Хеширование.
- •2. Представление данных
- •2.1. Представление данных с помощью модели "сущность-связь".
- •2.1.1.Назначение модели.
- •2.1.2.Элементы модели.
- •2.2.Диаграмма "сущность-связь".
- •2.3. Целостность данных.
- •3. Дореляционные модели представления данных.
- •3.1.Иерархическая модель данных.
- •3.1.1.Структура данных.
- •3.1.2.Операции над данными, определенные в иерархической модели:
- •3.1.3.Ограничения целостности.
- •3.2.Сетевая модель данных
- •3.2.1.Структура данных.
- •3.2.2.Операции над данными.
- •3.2.3.Ограничения целостности.
- •4. Реляционный подход к представлению данных
- •4.1.Реляционная модель данных
- •4.1.1.Структура данных.
- •4.1.2.Свойства отношений.
- •4.2.Теория нормальных форм.
- •4.2.1.Функциональные зависимости.
- •4.2.5. Bcnf - нормальная форма Бойса-Кодда.
- •4.2.6. Многозначные зависимости и четвертая нормальная форма (4nf).
- •4.2.7. Зависимости по соединению и пятая нормальная форма (5nf).
- •4.3.Ограничения целостности
- •4.3.1.Целостность сущностей.
- •4.3.2.Целостность ссылок
- •4.4. Реляционная алгебра
- •4.4.1. Операции обработки кортежей.
- •4.4.2. Операции обработки отношений.
- •4.5. Реляционное исчисление.
- •4.6.Язык sql
- •4.7. Вопросы практического программирования.
- •4.8.Навигационный подход к манипулированию данными и персональные субд.
- •4.9.Транзакции, блокировки и многопользовательский доступ к данным.
- •4.10. Определение степени соответствия субд реляционной модели.
- •5. Проектирование реляционных баз данных.
- •5.1. Этапы проектирования данных
- •5.2.Инструментальные средства проектирования информационных систем.
- •5.4.Концептуальное моделирование.
- •5.5.Правила порождения реляционных отношений из модели "сущность-связь"
- •5.5.1. Бинарные связи
- •5.5.3. Иерархические связи.
- •5.6. Проектирование реляционной базы данных на основе декомпозиции универсального отношения.
- •5.7.Обзор некоторых case-систем.
- •5.7.1. Power Designer компании Sybase.
- •5.7.2. Silverrun компании Silverrun Technologies Ltd.
- •5.7.3. BpWin и erWin компании LogicWorks.
- •5.7.4. Designer/2000 компании Oracle.
- •6. Классификация субд.
- •6.1.Ограничения реляционных баз данных.
- •6.2.Постреляционные субд.
- •6.3.Объектно-ориентированные субд.
- •6.3.1. Объектно-ориентированная парадигма.
- •6.3.2. Объектно-ориентированные субд.
- •6.3.3. Стандарт odmg.
- •6.3.4. Объектные расширения реляционных субд. Язык sql-3.
- •6.4. Объектно-реляционные субд.
- •6.5.Нечисловая обработка и ассоциативные процессоры.
- •7. Представление данных по принципу технологии "клиент-сервер".
- •7.1.Архитектура "клиент-сервер".
- •7.1.1. Основные понятия.
- •7.1.2. Модели взаимодействия клиент-сервер.
- •7.1.3. Мониторы транзакций.
- •7.2.Обработка распределенных данных.
- •7.3.Структура сервера базы данных.
- •8.Базы знаний.
- •8.1. Понятие системы баз знаний.
- •8.2.Структура и функции системы баз знаний.
- •8.3.Инструментальные средства построения систем баз знаний.
5.5.Правила порождения реляционных отношений из модели "сущность-связь"
5.5.1. Бинарные связи
Тип связи |
Правило построения отношений |
(1,1):(1,1) |
Требуется только одно отношение. Первичным ключом данного отношения может быть ключ любой из сущностей. |
(1,1):(0,1) (1,1):(0,n) |
Для каждой сущности создается свое отношение, при этом ключи сущностей служат ключами соответствующих отношений. Кроме того, ключ сущности с обязательным классом принадлежности добавляется в качестве внешнего ключа в отношение, созданное для сущности с необязательным классом принадлежности. |
(0,1):(0,1) |
Необходимо использовать три отношения: по одному для каждой сущности (ключи сущностей служат первичными ключами отношений) и одно отношение для связи. Отношение, выделенное для связи, имеет два атрибута - внешних ключа - по одному от каждой сущности. |
(0,1):(0,n) (0,1):(1,n) |
Формируются три отношения: по одному для каждой сущности, причем ключ каждой сущности служит первичным ключом соответствующего отношения, и одно отношение для связи. Отношение, выделенное для связи, имеет два атрибута - внешних ключа - по одному от каждой сущности. |
n : m |
В этом случае всегда используются три отношения: по одному для каждой сущности, причем ключ каждой сущности служит первичным ключом соответствующего отношения, и одно отношение для связи. Последнее отношение должно иметь среди своих атрибутов внешние ключи, по одному от каждой сущности. |
5.5.2. N - арные связи.
Общее правило: для представления n-сторонней связи всегда требуется n+1 отношение. Например, в случае трехсторонней связи необходимо использовать четыре отношения, по одному для каждой сущности (причем ключ сущности служит первичным ключом соответствующего отношения), и одно для связи. Отношение, порождаемой для связи, будет иметь среди своих атрибутов ключи от каждой сущности.
5.5.3. Иерархические связи.
К сожалению, надо признать, что реляционная модель мало подходит для отображения отношений наследования между сущностями (иерархических связей). Напомним, что в таких связях дочерние сущности наследуют все атрибуты родительской, и каждая из них обладает своим уникальным набором дополнительных атрибутов.
В этом случае возможны два варианта построения реляционных отношений. Согласно первому для иерархической структуры создается одно отношение, которое содержит атрибуты связи и всех сущностей. Недостаток такого способа - для каждого кортежа часть атрибутов всегда будет неопределена. Более того, этот факт является требованием целостности сущности, следовательно, для СУБД должны быть явно указаны несколько списков атрибутов (по числу дочерних сущностей), причем определенные значения могут быть присвоены только членам одного из них. Реляционная модель не поддерживает такого ограничения, на практике его реализуют с помощью триггеров.
По второму способу генерируется по одному отношению для каждой дочерней сущности. Каждое из этих отношений включает атрибуты родительской сущности и связи кроме атрибутов - дискриминантов. Недостатком данного способа является невозможность получить в одном запросе список всех заказчиков.
Следует отметить, что построенные таким образом реляционные отношения, не являются окончательной схемой базы данных. Их необходимо проверить на избыточные функциональные зависимости и привести к NFBK или нормальной форме более высокого порядка.