
- •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.4. Примеры аномалий
Рассмотрим типичные примеры аномалий, возникающих при выполнении операций включения, удаления и модификации данных.
Пусть у нас есть отношение:
ПОСТАВКИ (Поставщик, Адрес, Товар, Количество, Стоимость)
Обновление. Если Поставщик поставляет несколько видов товара, то значение атрибута Адрес повторяется для каждого кортежа и, следовательно, при изменении адреса поставщика необходимо изменить значение этого атрибута во всех этих кортежах. Иначе будет нарушена целостность данных.
Удаление. Если Поставщик прекращает поставку товаров на некоторое время, то кортежи со всеми его поставками удаляются. При этом происходит потеря реквизитов поставщика – Адреса и Наименования.
Вставка. Если договор на поставку уже заключён, а поставка ещё не произведена, то невозможно включить в рассматриваемое отношение значения атрибутов Поставщик и Адрес, поскольку нет сведений о поставках (проблема интерпретации нуль-значений).
Подобные аномалии в данных лишь отчасти дают ответ на вопрос, почему логическая структура реляционной БД может быть неудовлетворительной.
Некоторые проблемы избыточности данных можно разрешить, заменив, например, исходное отношение ПОСТАВКИ на два новых отношения:
отношение
ПОСТАВЩИК (Поставщик, Адрес)
и отношение
ПОСТАВКА (Поставщик, Товар, Количество, Стоимость)
Однако в целом остаётся ряд вопросов, на которые теория реляционных БД не даёт удовлетворительных ответов:
Как найти хорошую замену для плохой схемы отношений?
Как определить, является ли выбранная замена выгодной?
Как создать схему, обеспечивающую наилучшую производительность?
Например, для того чтобы выполнить запрос, использующий данные из двух таблиц, необходимо построить соединение этих таблиц, которое является дорогостоящей операцией с точки зрения числа выполняемых операций ввода/вывода.
3.4.5. Нормальные формы
Теория функциональных зависимостей (ФЗ) позволяет установить определённые требования к схемам отношений в реляционной БД.
Эти требования формулируются в терминах свойств отношений и называются нормальными формами схем отношений.
Каждая нормальная форма отношений связана с определённым классом ФЗ, которые представлены в отношениях.
Одним из очевидных способов устранения потенциальной противоречивости данных в отношениях логической модели реляционной БД является их разбиение на два или более отношения, в каждом из которых присутствует только одна ФЗ.
Это возможно, поскольку теория ФЗ утверждает, что существует минимальное покрытие множества ФЗ базы данных, т.е. минимальный набор ФЗ, из которых можно вывести все остальные.
Каждой ФЗ из минимального покрытия можно отвести по самостоятельному отношению.
Однако:
во-первых, для заданного множества ФЗ может существовать несколько минимальных покрытий (выбор среди возможных альтернатив);
во-вторых, для практики важно иметь наглядный способ построения минимального покрытия.
Процесс устранения потенциальной противоречивости и избыточности данных в отношениях реляционной БД называется нормализацией исходных схем отношений.
Нормализация отношений заключается в выполнении декомпозиции или синтеза отношений и назначении ключей отношений в соответствии с определёнными правилами, гарантирующими целостность отношений БД.
Требование минимальности числа отношений, т.е. построения минимального покрытия ФЗ обычно является опциональным.
Но! На минимальном покрытии, как правило, не может быть достигнута высокая производительность обработки запросов.
Почему нормализация схем отношений важна для проектирования реляционных БД?
Многочисленные испытания показали, что нормализация схем отношений даёт наилучший результат при моделировании предметной области с использованием реляционной модели данных.
При этом не вводится большого числа ограничений, не искажаются данные.
Таким образом, нормализация отношений является методом удаления из отношения ФЗ, которые приводят к аномалиям модификации данных.
Иными словами, нормализация отношений помогает проектировать реляционную БД, которая не содержит избыточных данных и гарантирует целостность данных.
Язык нормальных форм констатирует наличие или отсутствие определённых ФЗ в отношениях реляционной БД и указывает на уровень избыточности и надёжности данных в нормализованных отношениях.
Методы нормализации отношений основываются на применении понятия ФЗ и способов манипулирования ими.
При выполнении реляционных операций над отношениями в БД каждый тип ФЗ может порождать опредёленный тип аномалий, который будет нарушать целостность данных в БД.
Нормальная форма (НФ) представляет собой ограничение на схему базы данных, вводимое с целью устранения определённых нежелательных свойств при выполнении реляционных операций.
Различают несколько типов нормальных форм. Каждая из них ограничивает присутствие определённого класса ФЗ в отношении и устраняет присущие этому классу ФЗ аномалии в выполнении реляционных операций.
Примечание. Глагол «ограничивает» в терминологии баз данных означает набор процедур, направленных на достижение определённых свойств объекта путем сужения области его действия.