
- •Содержание
- •Глава 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
3.1.Основные определения
Для большей наглядности рассматриваемых нами идей к атрибутам отношения Поставки (см. рис. 3.1) добавим атрибут ГОРОД, представляющий город соответствующего поставщика. Новому отношению присвоим имя Поставки_из_города.
Рис. 3.2. Таблица отношений Поставки_из_города
Пусть R – это отношение, а X и Y – произвольные подмножества множества атрибутов отношения R. Тогда Y функционально зависит от Х тогда и только тогда, когда каждое значение множества Х отношения R связано в точности с одним значением множества Y отношения R. ФЗ записывается так:
Х ® Y
и читается как «Х функционально определяет Y» или «Y функционально зависимо от Х».
Если два кортежа отношения R совпадают по значению Х, они также совпадают по значению Y. Таблица отношений Поставки_из_города удовлетворяет определению ФЗ. В частности, можно записать:
Левая и правая части символической записи ФЗ иногда называют детерминантом и зависимой частью соответственно.
Подчеркнем один важный момент, связанный с тем, что было сказано выше.
Следует различать а) значения переменной отношения в определенный момент времени, т.е. экземпляр; б) набор всех возможных значений, который данная переменная отношений может принимать в различные моменты времени. Рассмотренная выше ФЗ относилась к пункту а), т.е. к отдельным значениям отношения.
Однако при рассмотрении переменных отношений наибольший интерес представляют ФЗ, выполняющиеся для всех возможных значений данной переменной. Так, например, ФЗ
Код_поставщика ® ГОРОД
выполняется для всех возможных значений Поставки_из_города , поскольку в любой момент времени данному поставщику соответствует в точности один город и любые два кортежа отношения Поставки_из_города в один и тот же момент времени и с одним и тем же номером поставщика должны соответствовать одному и тому же городу.
Утверждение, что данная функциональная зависимость выполняется «всегда» (т.е. при всех возможных значениях Поставки_из_города ), является ограничением целостности для отношения Поставки_из_города , поскольку накладываются ограничения на все допустимые значения Поставки_из_города .
Если Х является потенциальным ключом отношения R, например, Х является первичным ключом, то все атрибуты Y отношения R должны быть обязательно функционально зависимы от Х. В обычном отношении Товар необходимо, чтобы выполнялась зависимость
Товар ® {Код_товара, Наименование, ЦВЕТ, ВЕС, ГОРОД}
Если отношение R удовлетворяет ФЗ А ® В, и А не является потенциальным ключом, R будет характеризоваться некоторой избыточностью. Например, в случае отношения Поставки_из_города.
{Код_поставщика} ® {ГОРОД} сведения о том, что каждый данный поставщик находится в данном городе, будут повторяться много раз.
Как отмечалось, ФЗ является ограничением целостности, поэтому при каждом обновлении данных СУБД все они должны быть проверены. Следовательно, для заданного множества ФЗ S желательно найти также множество Т, которое было бы гораздо меньшего размера, чем множество S, причем каждая ФЗ множества S могла бы быть заменена функциональной зависимостью множества Т. Если такое множество будет найдено, то СУБД достаточно будет контролировать выполнение ФЗ из множества Т, что автоматически подразумевало бы соблюдение всех функциональных зависимостей из множества S.
Поэтому задача поиска подходящего множества Т представляет большой практический интерес, так как позволяет отыскать самые удачные схемы отношений.