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