
- •1. Введение в курс
- •1.1. Введение в базы данных, содержание и цели курса, основные понятия
- •1.1.1. О чём этот курс
- •1.1.2. Основные определения
- •1.1.3. Способы организации знаний в базах знаний
- •1.1.4. Применение баз знаний
- •1.1.5. Виды моделей баз данных
- •2. Теория баз данных
- •2.1. История развития представлений о базах данных
- •2.1.1. Области применения вычислительной техники
- •2.1.2. Базы данных и информационные системы
- •2.1.3. История развития баз данных
- •2.1.4. Этапы развития баз данных
- •2.2. Основные термины и определения теории бд, виды бд и их отличия
- •2.2.1. Классификация бд
- •2.3. Реляционные бд, понятие сущности и связи
- •2.3.1. Общие определения
- •2.3.2. Факты о реляционной модели данных
- •2.3.3. Достоинства реляционной модели данных
- •2.3.4. Недостатки реляционной модели данных
- •2.3.5. Целостность бд
- •2.3.6. Отношения
- •2.3.7. Кортежи и отношения
- •2.3.8. Связи
- •2.3.9. Ключи отношений
- •2.3.10. Ссылочная целостность
- •2.3.11. Консистентность данных
- •2.4. Многоуровневая архитектура баз данных, понятие физического и логического уровней баз данных
- •2.4.1. Определения
- •2.4.2. Многоуровневая структура баз данных
- •2.4.3. Постоянная и переменная длина записи
- •2.4.4. Способы представления данных
- •2.4.5. Простейший вариант – плоский файл
- •2.4.6. Факторизация по значениям поля
- •2.4.7. Индексирование по полям
- •2.4.8. Комбинация простых представлений
- •2.4.9. Использование цепочек указателей
- •2.4.10. Многосписочные структуры
- •2.4.11. Инвертированная организация
- •2.4.12. Иерархическая организация
- •2.4.14. Промежуточный итог
- •2.4.15. Методы индексирования
- •2.4.16. Индексирование по комбинации полей
- •2.4.17. Селективный индекс
- •2.4.18. Индексация по методу сжатия
- •2.4.19. Фронтальное сжатие
- •2.4.20. Сжатие окончания
- •2.4.21. Символьные указатели
- •2.4.23. Индексно-последовательная организация
- •2.4.24. Сбалансированные деревья
- •2.4.25. Ведение файла
- •2.4.26. Хэширование
- •2.4.28. Итог
- •2.5. Алгоритмы хэширования
- •2.5.1. Введение
- •2.5.2. Хэширование
- •2.5.2. Факторы эффективности хэширования
- •2.5.3. Размер участка памяти
- •2.5.4. Плотность заполнения
- •2.5.5. Алгоритмы хэширования
- •2.5.6. Размещение записей в области переполнения
- •2.5.7. Итог
- •2.6. Механизмы обработки и хранения данных в бд
- •2.6.1. Введение
- •2.6.2. Механизмы обработки и хранения данных в ms-sql 6.0-6.5
- •2.6.3. Механизмы обработки и хранения данных в ms-sql 7.0 и более поздних версиях
- •2.6.4. Метод доступа isam
- •2.6.5. Метод доспута MyIsam
- •2.6.6. Метод доступа vsam
- •2.6.7. Включение записей в *sam-файлы
- •2.6.8. Размещение индексов для *sam-файлов
- •2.6.9. Метод доступа InnoDb
- •2.6.10. Итог
- •2.7. Физическое представление древовидных и сетевых структур
- •2.7.1. Введение
- •2.7.2. Древовидные структуры
- •2.7.3. Сетевые структуры
- •2.7.4. Итог
- •3.1.4. Стандарты разработки бд/субд
- •3.1.5. Sql и его стандарты
- •Часть 1 – sql/Структура (sql/Framework) – определяет общие требования соответствия и фундаментальные понятия sql.
- •3.1.6. Использование методологии idef1x
- •3.1.7. Пример логической и физической схемы в ErWin
- •3.1.8. Минимальный набор стандартных таблиц
- •3.1.8. Итог
- •3.2. Средства автоматизированного проектирования бд
- •3.2.1. Введение
- •3.2.2. Case-технологии
- •3.2.3. Достоинства case-технологий
- •3.2.4. Промежуточные выводы и определения
- •3.2.5. Методологии структурного моделирования
- •3.2.6. Методология sadt (idef0)
- •3.2.7. Методологии информационного моделирования
- •3.2.8. Нотация Чена
- •3.2.9. Нотация Мартина
- •3.2.10. Нотация ide1x
- •3.2.11. Нотация Баркера
- •3.2.12. Язык информационного моделирования
- •3.2.13. Case-средства
- •3.2.14. Процесс создания модели бд в ErWin
- •3.2.15. Процесс создания модели бд в Sparx ea
- •3.2.16. Итог
- •3.3. Особенности проектирования бд на логическом и физическом уровнях
- •3.3.1. Введение
- •3.3.2. Модель бд
- •3.3.4. Банки данных
- •3.3.5. Модели данных
- •3.3.6. Этапы проектирования бд
- •3.3.7. Проектирование бд: внешний уровень
- •3.3.8. Проектирование бд: инфологический уровень
- •3.3.9. Проектирование бд: даталогический уровень
- •3.3.10. Уровни sql
- •3.3.11. Проектирование бд: физический уровень
- •3.3.12. Итог
- •3.4. Прямое и обратное проектирование бд
- •3.4.1. Введение
- •3.4.2. Понятие нормализации
- •3.4.3. Требования нормализации
- •3.4.4. Примеры аномалий
- •3.4.5. Нормальные формы
- •3.4.6. Зависимости
- •3.4.6. Первая нормальная форма
- •3.4.7. Вторая нормальная форма
- •3.4.8. Третья нормальная форма
- •3.4.9. Нормальная форма Бойса-Кодда
- •3.4.10. Четвёртая нормальная форма
- •3.4.11. Пятая нормальная форма
- •3.4.12. Доменно-ключевая нормальная форма
- •3.4.13. Ещё раз, кратко, все нормальные формы
- •3.4.14. Ещё раз, кратко, в ErWin
- •3.5.2. Показатели качества бд
- •3.5.3. Итог
3.4.10. Четвёртая нормальная форма
Отношение находится в 4НФ, если оно находится в 3НФ или НФБК и не содержит многозначных зависимостей.
Многозначная зависимость не является функциональной и существует в том случае, когда из факта, что в таблице содержится «строка со значением некоторого поля, равным X», следует, что в таблице обязательно существует «строка со значением некоторого поля, равным Y».
Т.о., отношение находится в 4НФ, если все его зависимости являются функциональными.
Предположим, что рестораны производят разные виды пиццы, а службы доставки ресторанов работают только в определённых районах города.
Составной ключ таблицы такого отношения включает три поля:
{Ресторан, ВидПиццы, РайонДоставки}.
Такая таблица не соответствует 4НФ, так как существует многозначная зависимость:
{Ресторан} →→ {Вид пиццы}
{Ресторан} →→ {Район доставки}
То есть, например, при добавлении нового вида пиццы придётся внести по одной новой записи для каждого района доставки.
Возможна логическая аномалия, при которой определённому виду пиццы будут соответствовать лишь некоторые районы доставки из обслуживаемых рестораном районов.
Для предотвращения аномалии нужно разбить многозначную зависимость – разместить независимые факты в разных таблицах.
Переработаем такое отношение…
Рисунок 3.4.10.1 – Отношение, НЕ находящееся в 4НФ
… в такую схему:
Рисунок 3.4.10.2 – Схема БД, соответствующая 4НФ
К слову, здесь мы видим ещё один способ решения ситуации, возникшей при нормализации до НФБК: когда у таблиц все поля являются частями составных первичных ключей.
Мы можем создать отдельную промежуточную таблицу.
3.4.11. Пятая нормальная форма
Отношение находится в 5НФ, если оно находится в 4НФ и любая многозначная зависимость соединения в нём является тривиальной.
Пятая нормальная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных.
Это связано со сложностью определения самого наличия зависимостей соединения, поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.
Зависимость соединения
Отношение R (X, Y, ... ,Z) удовлетворяет зависимости соединения * (X, Y, ... ,Z) в том и только в том случае, когда R восстанавливается без потерь путём соединения своих проекций на X, Y, Z.
Иными словами: если отношение R декомпозировать на набор отношений, поработать с такой БД, а потом вдруг восстановить отношение R из имеющегося набора отношений, то результат должен быть таким же, как если бы мы работали с исходным отношением R.
Очень редко таблица, находящаяся в 4НФ, не соответствует 5НФ.
Это те ситуации, в которых реальные правила, ограничивающие допустимые комбинации атрибутов, никак не выражены в структуре таблицы (например, правила определённого бизнеса).
В таком случае, если таблица не приведена к 5НФ, бремя обеспечения логической целостности данных отчасти переляжет на приложение, отвечающее за добавление, удаление и изменение данных таблицы.
В этом случае существует риск возникновения аномалий данных. Пятая нормальная форма исключает возникновение таких аномалий.
Предположим, что продавец может торговать продукцией нескольких фирм, ассортимент у фирм различен, причем продавец может предлагать только часть товаров конкретной фирмы.
Отношение {Продавец, Фирма, Вид товара} соответствует 4НФ, однако не отражает ограничения, связанного с ассортиментом продукции фирм. Может возникнуть кортеж, в котором фирме будет соответствовать вид товара, который она не выпускает.
В данном случае (для приведения к 5НФ) отношение должно быть разбито на три: {Продавец, Фирма}, {Фирма, Вид товара}, {Продавец, Вид товара}.