- •Установочный модуль
- •Введение
- •Модуль 1
- •Реляционная алгебра
- •Отсутствующие данные
- •Пустые значения
- •Неопределенные значения
- •Интерпретации
- •Правила вычисления выражений
- •Следствия
- •Проверка условий
- •Реляционные объекты данных
- •Формальные определения
- •Домены и атрибуты
- •Схема отношения
- •Именованное значение атрибута
- •Кортеж
- •Отношение
- •Схема базы данных
- •База данных
- •Операции реляционной алгебры
- •Унарные операции
- •Бинарные операции
- •Варианты операции соединения
- •Производные операции
- •Пример построения выражения реляционной алгебры
- •Понятие базовых и виртуальных отношений
- •Понятие полноты реляционной алгебры
- •Формирование запросов на языке SQL
- •Металингвистические символы
- •Реализация операций реляционной алгебры
- •Пример использования подзапросов
- •Группирующие запросы
- •Упорядочение результатов
- •Вопросы для самоконтроля
- •Упражнения
- •Построение выражений реляционной алгебры
- •Модуль 2
- •Базовые и виртуальные отношения
- •Типы данных
- •Базовые типы данных
- •Типы данных, определяемые пользователем
- •Первичные и кандидатные ключи
- •Создание базовых отношений
- •Индексы
- •Модификация базовых отношений
- •Вставка строк
- •Обновление строк
- •Удаление строк
- •Целостность
- •Декларативная поддержка
- •Пример декларативной поддержки целостности
- •Транзакции и блокировки
- •Триггеры
- •Виртуальные отношения
- •Вопросы для самоконтроля
- •Упражнения
- •Декларативная поддержка целостности
- •Модуль 3
- •Нормальные формы
- •Функциональные зависимости (ФЗ)
- •Правила вывода Армстронга
- •Производные правила вывода
- •Независимость правил Армстронга
- •Полнота системы правил Армстронга
- •Нормальные формы
- •Первая нормальная форма (1NF)
- •Вторая нормальная форма (2NF)
- •Третья нормальная форма (3NF)
- •Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC)
- •Пример построения нормализованных схем отношений
- •Вопросы для самоконтроля
- •Модуль 4
- •Проектирование схем баз данных
- •Уровни логической модели
- •Миграция ключей и виды связей
- •Классификация кластеров
- •Иерархическая рекурсия
- •Абстрактная схема
- •Обобщения
- •Пример реализации иерархической рекурсии
- •Сетевая рекурсия
- •Абстрактная схема
- •Сетевая реализация иерархической рекурсии
- •Обобщения
- •Пример реализации сетевой рекурсии
- •Ассоциация
- •Детализация связей многие-ко-многим
- •Обобщения
- •Пример реализации ассоциации
- •Обобщение
- •Абстрактная схема
- •Пример реализации обобщения
- •Композиция
- •Абстрактная схема
- •Пример реализации композиции
- •Агрегация
- •Абстрактная схема
- •Пример реализации агрегации
- •Унификация атрибутов
- •Вопросы для самоконтроля
- •Упражнения
- •Иерархическая рекурсия
- •Сетевая рекурсия
- •Ассоциация
- •Обобщение
- •Композиция
- •Агрегация
- •Дополнительные главы
- •Технологии баз данных
- •Информационные системы
- •Жизненный цикл ИС
- •СУБД и БД
- •Жизненный цикл БД и средства проектирования
- •Модели данных
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •Постреляционная модель данных
- •Объектно-ориентированные модели данных
- •XML как модель данных
- •Многомерная модель данных (OLAP)
- •Основные функции СУБД
- •Управление данными во внешней памяти
- •Управление буферами оперативной памяти
- •Управление транзакциями
- •Журнализация и восстановление БД после сбоев
- •Поддержка языков баз данных
- •Типовая организация СУБД
- •Модели взаимодействия с БД
- •Модель с централизованной архитектурой
- •Модель с автономными персональными компьютерами
- •Архитектура «файл-сервер»
- •Архитектура «клиент-сервер»
- •Архитектура «клиент-сервер» трехзвенная
- •Распределенные базы данных
- •Технология тиражирования данных
- •Понятие «фрактал»
- •Геометрические фракталы
- •Алгебраические фракталы
- •Стохастические фракталы
- •Системы итерируемых функций
- •Вопросы для самоконтроля
- •Литература
- •Список иллюстраций
- •Список таблиц
5. Проектирование схем баз данных
Наиболее распространенным средством абстрактного представления схем баз данных на логичес- ком уровне является модель «сущность-связь» (ER-модель, Entity-Relationship model). Элементами модели являются классы сущностей, их атрибуты и связи.
Примечание. Далее диаграммы, составляющие графическую основу модели, изображаются в стиле унифицированного языка моделирования UML
Класс сущностей – это как бы «лишенный методов» класс объектов в смысле объектно-ориенти- рованного программирования. Он представляет собой множество реальных или абстрактных «чегото», обладающих общими атрибутами. Отдельный элемент этого множества называется экземпляром класса сущностей.
Каждый класс сущностей может характеризоваться любым числом атрибутов и иметь произвольное число связей с другими классами.
Связь между двумя классами сущностей может характеризоваться наименованием и кратностью роли класса в связи, а также наименованием связи (безотносительно к роли). Типичными кратностями являются:
1)1 – один,
2)0 : : : 1 – не-более-один,
3)0 : : : 1 – много («много» допускает и «ничего»),
4)1 : : : 1 – один-или-более.
Примечание. Символ 1 по техническим причинам может заменяться, например, на n. Более сложные кратности могут быть заданы с помощью списка: так, например, кратность «0 : : : 1; 3 : : : 4; 6 : : : n» означает «любое число сущностей, кроме 2 и 5». Вместо многоточия «: : :» часто используют отточие вида «..»
Связь изображается в виде линии, соединяющей классы сущностей. Согласно диаграмме (рис. 5.1) каждая касса имеет много билетов, а каждый билет находится в одной кассе.
Рис. 5.1.: Диаграмма со связью типа один-ко-многим
Наиболее важными типами связей являются:
1)1 : 1 – один-к-одному,
2)1 : 0 : : : 1 – один-ко-многим (кратко 1:М),
3)0 : : : 1 : 1 – многие-к-одному (М:1, обращение 1:М),
4)0 : : : 1 : 0 : : : 1 – многие-ко-многим (М:М).
Другие важные типы связей получаются заменой кратности один (1) на не-более-один (0 : : : 1). При переходе к физическому уровню классы сущностей преобразуются в таблицы реляционной
базы данных для конкретной СУБД. Связи реализуются с помощью объявлений внешних ключей таблиц, ссылающихся на первичные или кандидатные ключи других таблиц.
5.1. Уровни логической модели
Выделяют три уровня логической модели, различающиеся по глубине представления информации
оструктуре данных. Этим уровням соответствуют диаграммы
1)презентационные,
2)ключевые,
3)полные атрибутивные.
Презентационные диаграммы описывают основные классы сущностей и их связи. Ключи могут не описываться и, соответственно, связи не детализироваться, так что допустимыми являются связи многие-ко-многим, а также составные и многозначные атрибуты. Такие диаграммы используются для презентаций и консультаций с экспертами предметной области.
На презентационных диаграммах классы сущностей удобно именовать в единственном числе, так как атрибуты классов не указываются или указываются в минимальном объеме, так что такой класс сущностей воспринимается скорее как экземпляр класса сущностей
Ключевые диаграммы описывают все классы сущностей и их связи в терминах первичных ключей. Связи многие-ко-многим (0 : : : 1 : 0 : : : 1) детализируются. Многозначные атрибуты преобразуются в классы сущностей. Но однозначные атрибуты все еще могут быть представлены не полностью
или описаны как составные. Таким образом, ключевые диаграммы предполагают в дальнейшем лишь расщепление составных атрибутов и «навешивание» дополнительных атрибутов на описанные классы сущностей.
На ключевых диаграммах классы сущностей удобно именовать во множественном числе, так как атрибуты этих классов более или менее представлены на диаграммах.
Почему ключевые диаграммы основываются именно на первичных ключах?
1.Все проектирование схемы базы данных можно вести так, как будто каждый выделяемый класс сущностей обладает единственным ключом. Просто при последующем переходе к полной атрибутивной диаграмме следует дополнить классы сущностей кандидатными ключами. Например, можно дополнить данные о сотрудниках (с табельным номером в качестве первичного ключа) паспортными данными и ИНН.
2.Первичные ключи не допускают null-значений, и это абсолютно гарантируется всеми СУБД. Идентификация экземпляра класса сущностей с неопределенным идентификатором, понятно, не возможна.
3.Первичные ключи всегда выбираются наиболее лаконичным образом.
4.В качестве первичных часто используются суррогатные ключи, полезные тем, что повышают уровень абстракции рассуждений. Суррогатные ключи осмысленны в пределах одной базы данных. При экспорте данных в другую базу их следует исключить. В свою очередь при импорте данных им могут быть назначены суррогатные ключи базы-импортера.
5.Обычно СУБД поддерживают наибольшую производительность при выполнении связанных запросов в случае использования именно первичных ключей