
- •Общие сведения Сведения об эумк
- •Методические рекомендации по изучению дисциплины
- •Рабочая учебная программа
- •Учреждение образования
- •«Белорусский государственный университет
- •Информатики и радиоэлектроники»
- •Пояснительная записка
- •Содержание дисциплины
- •1. Название тем лекционных занятий, их содержание, объем в часах.
- •2 Перечень тем ипр их наименование и объем в часах
- •3 Перечень тем контрольных работ их наименование и объем в часах
- •4. Курсовая работа, ее характеристика
- •Перечень тем курсовых работ
- •5. Литература
- •5.1 Основная
- •5.2 Дополнительная
- •6. Перечень компьютерных программ, наглядных и других пособий, методических указаний и материалов и технических средств обучения
- •7. Учебно-методическая карта дисциплины
- •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. Многоуровневая структура баз данных
- •Indexed р#
- •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.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
- •InnoDb в MySql 5.1
- •2.7.3. Сетевые структуры
- •3.1.4. Стандарты разработки бд/субд
- •3.1.5. 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.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.4.15. Обратное проектирование бд
- •3.4.16. Итог
- •3.5. Повышение качества бд на стадии проектирования
- •3.5.1. Памятки разработчикам бд
- •3.5.2. Показатели качества бд
- •Практическая часть
- •Указания по выбору варианта
- •Индивидуальные практические работы Индивидуальная практическая работа № 1 Общие сведения
- •Практическая часть
- •Указания по выбору варианта
- •Индивидуальная практическая работа № 2 Общие сведения
- •Указания по выбору варианта
- •Практическая часть
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НФ) отношение должно быть разбито на три: {Продавец, Фирма}, {Фирма, Вид товара}, {Продавец, Вид товара}.