
- •Содержание
- •Глава 1. Основные понятия 6
- •Глава 2. Модели данных 19
- •Глава 3. Функциональные зависимости 46
- •Глава 4. Нормализация 54
- •Глава 5. Методология концептуального проектирования 69
- •Глава 6. Методология логического проектирования баз данных реляционного типа 75
- •Глава 7. Методология физического проектирования реляционных бд 93
- •Глава 8. Язык структурированных запросов sql. 107
- •Предисловие
- •Глава 1. Основные понятия
- •1.1. Информационные системы с базами данных.
- •1.2. Функции и возможности субд
- •1.3. Программные компоненты субд
- •1.4. Архитектура среды базы данных
- •1.5. Реляционные объекты данных: терминология
- •1.6. Формальные определения
- •1.6.1. Домены
- •1.6.2. Отношения
- •1.7. Целостность реляционных данных
- •1.7.1. Потенциальные ключи
- •1. Свойством уникальности.
- •2. Свойством не избыточности.
- •1.7.2. Первичные и альтернативные ключи
- •1.7.3. Внешние ключи
- •1.7.4. Ссылочная целостность
- •1.7.5. Правила внешних ключей
- •Глава 2. Модели данных
- •2.1. Элементы er-модели
- •2.1.1. Множество сущностей
- •2.1.2. Атрибуты
- •2.1.3. Связи
- •2.1.4. Рекурсивная связь
- •2.1.5. Атрибуты связей
- •2.2. Структурные ограничения
- •2.2.1. Связь "один-к-одному"
- •2.2.2. Связь "один-ко-многим"
- •2.2.3. Связь "многие-ко-многим"
- •2.2.4. Степень участия
- •2.2.5. Многосторонние связи
- •2.2.6. Слабые множества сущностей
- •2.3. Проблемы er-моделирования (Материал данного параграфа не обязателен для изучения)
- •2.3.1. Ловушки разветвления
- •2.3.2. Ловушка разрыва
- •2.4. Ееr-модель
- •2.4.1. Суперклассы и подклассы типов сущностей
- •2.4.2. Наследование атрибутов
- •2.4.3. Специализация
- •2.4.4. Генерализация
- •2.4.5. Ограничения, накладываемые на процедуры специализации и генерализации
- •2.4.6. Категоризация
- •2.5. Реляционные модели
- •2.5.1. От er-диаграмм к реляционным схемам
- •2.5.2. От er-связей к к отношениям
- •2.5.3. Объединение отношения
- •2.5.4. Преобразование слабых множеств сущностей
- •Глава 3. Функциональные зависимости
- •3.1.Основные определения
- •3.2. Тривиальные и нетривиальные зависимости
- •3.3. Замыкание множества зависимостей
- •3.4. Правила вывода Армстронга
- •3.5. Неприводимое множество зависимостей
- •Примеры
- •Глава 4. Нормализация
- •4.1. Декомпозиция без потерь
- •4.2. Первая, вторая и третья нормальные формы.
- •Вторая нормальная форма (2нф).
- •Третья нормальная форма ( 3нф ).
- •Нормальная форма Бойса-Кодда
- •4.3. Многозначные зависимости
- •4.4. Четвертая нормальная форма (4нф)
- •4.5. Пятая нормальная форма (5нф)
- •4.6. Итоговая схема процедуры нормализации
- •4.7. Альтернативный набор определений нфбк, 4нф и 5нф
- •4.8. Выделим цели процесса нормализации
- •4.9. Другие нормальные формы
- •Глава 5. Методология концептуального проектирования
- •5.1. Источники представления пользователей о предметной области
- •5.2. Определение типов сущностей
- •5.3. Определение типов связей
- •5.4. Определение атрибутов
- •5.5. Определение доменов атрибутов
- •5.6. Определение потенциальных и первичных ключей
- •5.7. Генерализация и специализация типов сущностей
- •5.8. Создание диаграммы "сущность-связь"
- •5.9. Обсуждение локальных концептуальных моделей данных с конечными пользователями
- •Глава 6. Методология логического проектирования баз данных реляционного типа
- •6.1. Преобразование локальной концептуальной модели данных в локальную логическую модель
- •6.1.1. Удаление связей типа m:n
- •6.1.2. Удаление сложных связей
- •6.1.3. Удаление рекурсивных связей
- •6.1.4. Удаление связей с атрибутами
- •6.1.5. Удаление множественных атрибутов
- •6.1.6. Перепроверка связей типа 1:1
- •6.1.7. Удаление избыточных связей
- •6.2. Наборы отношений локальных логических моделей данных
- •6.2.1. Сильные типы сущностей
- •6.2.2. Слабые типы сущностей
- •6.2.3. Бинарные связи типа "один-к-одному" (1:1)
- •6.2.4. Бинарные связи типа "один-ко-многим" (1:м)
- •6.2.5. Связи типа "суперкласс/подкласс"
- •6.2.6. Документирование созданных отношений и атрибутов внешних ключей
- •6.3. Проверка модели с помощью правил нормализации
- •6.4. Проверка модели в отношении транзакций
- •6.5. Создание диаграмм "сущность-связь"
- •6.7.1. Слияние локальных логических моделей данных в единую глобальную модель данных
- •6.7.1.1. Анализ имен сущностей и их первичных ключей
- •6.7.1.2. Анализ имен связей
- •2. Слияние эквивалентных сущностей с различными первичными ключами
- •3. Слияние сущностей с различными именами, имеющих одинаковые или различные первичные ключи
- •7.1.1. Oписание на языке sql стандарта iso 1992 (sql2)
- •Листинг 1. Операторы языка sql, предназначенные для создания таблицы
- •7.1.2. Реализация с использованием триггеров
- •Пример 1
- •7.1.3. Реализация с использованием уникальных индексов
- •Пример 2
- •7.2. Реализация бизнес-правил предприятия в среде целевой субд
- •7.3. Организация эффективного хранения данных
- •7.3.1. Анализ транзакций.
- •7.3.2. Выбор файловой структуры.
- •Последовательные файлы
- •Хешированные файлы
- •Индексно-последовательные файлы
- •Двоичные деревья
- •7.3.3. Определение вторичных индексов.
- •7.3.4. Анализ необходимости введения контролируемой избыточности.
- •7.3.5. Определение требований к дисковой памяти.
- •Последовательные файлы
- •Хешированные файлы
- •7.4. Разработка механизмов защиты
- •7.4.1. Разработка пользовательских представлений (видов).
- •7.4.2. Определение прав доступа.
- •7.5. Организация мониторинга и настройка функционирования системы
- •Глава 8. Язык структурированных запросов sql.
- •Операторы ddl
- •Типы данных
- •Создание файла бд
- •Создание (определение) таблиц
- •Определение столбцов
- •Примеры создания таблиц
- •Удаление таблиц
- •Модификация структуры таблиц
- •Операторы, изменяющие информацию в бд
- •Добавление новых данных.
- •Удаление существующих данных.
- •Обновление существующих данных.
- •Запрос информации из бд
- •Инструкция select
- •Предложение select.
- •Предложение from.
- •Запросы
- •Порядок выполнения многотабличных запросов
- •Виды объединений
- •Предложение where.
- •Условия отбора
- •Составные или сложные условия отбора
- •Предложение group by.
- •Предложение having.
- •Предложение order by.
- •Применение оператора select в инструкции insert
6.1.6. Перепроверка связей типа 1:1
В процессе определения сущностей могли быть созданы две различные сущности, которые на самом деле представляют один и тот же объект в предметной области приложения. Например, могли быть созданы две сущности: Отделение и Департамент, которые на самом деле представляют один и тот же тип объекта. Другими словами, имя Отделение является синонимом имени Департамент. В подобном случае следует объединить эти две сущности в одну. Если первичные ключи объединяемых сущностей различны, выберите один из них в качестве первичного, а другой укажите как альтернативный ключ.
6.1.7. Удаление избыточных связей
Связь является избыточной, если одна и та же информация может быть получена не только через нее, но и с помощью другой связи. Всегда следует стремиться создавать минимальные модели данных, и поэтому, если избыточная связь не является очевидно необходимой, ее следует удалять. Установить, что между двумя сущностями имеется больше одной связи, довольно просто. Однако из этого еще не следует, что одна из двух связей обязательно является избыточной, поскольку обе они могут представлять различные объединения, реально существующие в организации.
При устранении избыточности доступа большое значение имеют временные показатели. Например, рассмотрим ситуацию, когда необходимо смоделировать связи между сущностями Мужчина, Женщина и Ребенок, как показано на рис. 6.6.
Рис. 6.6. Пример множественных связей, не являющихся избыточными
Очевидно, что между сущностями Мужчина и Ребенок имеется два пути доступа: один — через непосредственную связь Является_отцом и другой — через связи Женаты и Является_матерью. На первый взгляд кажется, что связь Является_отцом является избыточной. Однако это утверждение может оказаться ошибочным по двум причинам. Во-первых, отец может иметь детей от предыдущего брака, а мы моделируем только текущий брак отца (через связь 1:1). Во-вторых, отец и мать могут быть вообще не женаты, или отец может быть женат на женщине, которая не является матерью данного ребенка (или же мать может быть замужем за мужчиной, который не является отцом ребенка). Поэтому все существующие взаимоотношения не могут быть смоделированы без использования связи типа Является_отцом.
По завершении данного этапа мы получили упрощенную локальную концептуальную модель данных, из которой удалены все структуры, реализация которых в среде реляционных СУБД затруднительна.
Поэтому на данном этапе правильнее будет называть улучшенную локальную концептуальную модель локальной логической моделью данных.
6.2. Наборы отношений локальных логических моделей данных
На данном этапе нам предстоит на основе созданных локальных логических моделей данных определить наборы отношений, необходимые для представления сущностей и связей, входящих в представления отдельных пользователей о предметной области приложения.
Для описания структуры создаваемых отношений мы воспользуемся языком DBDL (Database Definition Language), широко используемым в реляционных СУБД. Описание отношения на языке DBDL начинается с присвоенного ему имени, за которым следует помещенный в скобки список имен его простых полей. Затем указывается первичный ключ отношения и все его альтернативные и/или внешние ключи. После описания внешних ключей может указываться ссылочный первичный ключ, если таковой имеется.
Связи одних сущностей с другими типами сущностей представляются с помощью механизма первичных и внешних ключей. Для принятия решения о том, откуда взять и куда поместить значения атрибута(ов) внешнего ключа, предварительно следует установить, какая из участвующих в связи сущностей является родительской, а какая — дочерней. Родительской считается сущность, которая передает копию набора значений своего первичного ключа в отношение, представляющее дочернюю сущность, где эти значения будут играть роль внешнего ключа.