- •Технологии бд
- •1. Теоретические основы организации бд. Реляционная модель данных. 2
- •2. Технологии проектирования реляционных бд 24
- •Теоретические основы организации бд. Реляционная модель данных.
- •Подходы к организации баз данных
- •Иерархические базы данных
- •Сетевые базы данных
- •Реляционные базы данных
- •12 Правил Кодда:
- •Введение в реляционную модель данных
- •Основные понятия реляционной модели данных
- •Тип данных
- •Заголовок отношения, кортеж, тело отношения, значение отношения, переменная отношения
- •Первичный ключ и интуитивная интерпретация реляционных понятий
- •Фундаментальные свойства отношений
- •Отсутствие кортежей-дубликатов, первичный и возможные ключи отношений
- •Отсутствие упорядоченности кортежей
- •Отсутствие упорядоченности атрибутов
- •Атомарность значений атрибутов, первая нормальная форма отношения
- •Реляционная модель данных
- •Общая характеристика
- •Целостность реляционных данных
- •Null-значения
- •Трехзначная логика (3vl)
- •Потенциальные ключи
- •Целостность сущностей
- •Внешние ключи
- •Целостность внешних ключей
- •Замечания к правилам целостности сущностей и внешних ключей
- •Операции, могущие нарушить ссылочную целостность
- •Стратегии поддержания ссылочной целостности
- •Технологии проектирования реляционных бд
- •Этапы разработки базы данных
- •Критерии оценки качества логической модели данных
- •Адекватность базы данных предметной области
- •Легкость разработки и сопровождения базы данных
- •Скорость операций обновления данных (вставка, обновление, удаление)
- •Скорость операций выборки данных
- •Проектирование реляционных баз данных на основе принципов нормализации
- •Понятие метода нормализации отношений
- •Декомпозиция без потерь и функциональные зависимости
- •Корректные и некорректные декомпозиции отношений. Теорема Хеза
- •Теорема Хеза.
- •Диаграммы функциональных зависимостей
- •Первая нормальная форма
- •Минимальные функциональные зависимости и вторая нормальная форма
- •Аномалии обновления, возникающие из-за наличия неминимальных функциональных зависимостей
- •Возможная декомпозиция
- •Вторая нормальная форма
- •Нетранзитивные функциональные зависимости и третья нормальная форма
- •Аномалии обновлений, возникающие из-за наличия транзитивных функциональных зависимостей
- •Возможная декомпозиция
- •Третья нормальная форма
- •Независимые проекции отношений. Теорема Риссанена
- •Перекрывающиеся возможные ключи и нормальная форма Бойса-Кодда
- •Аномалии обновлений, связанные с наличием перекрывающихся возможных ключей
- •Нормальная форма Бойса-Кодда
- •Всегда ли следует стремиться к bcnf?
- •Необходимость дальнейшей нормализации
- •Многозначные зависимости и четвертая нормальная форма
- •Аномалии обновлений при наличии многозначных зависимостей и возможная декомпозиция
- •Многозначные зависимости. Теорема Фейджина. Четвертая нормальная форма
- •Лемма Фейджина
- •Теорема Фейджина
- •Зависимости проекции/соединения и пятая нормальная форма
- •N-декомпозируемые отношения
- •Зависимость проекции/соединения
- •Аномалии, вызываемые наличием зависимости проекции/соединения
- •Устранение аномалий обновления в 3-декомпозиции
- •Пятая нормальная форма
- •Заключение
- •Проектирование реляционных баз данных с использованием семантических моделей: er-диаграммы
- •Ограниченность реляционной модели при проектировании баз данных
- •Семантические модели данных
- •Семантическая модель Entity-Relationship (Сущность-Связь)
- •Основные понятия er-модели
- •Уникальные идентификаторы типов сущности
- •Нормальные формы er-диаграмм
- •Первая нормальная форма er-диаграммы
- •Вторая нормальная форма er-диаграммы
- •Третья нормальная форма er-диаграммы
- •Более сложные элементы er-модели
- •Наследование типов сущности и типов связи
- •Взаимно исключающие связи
- •Получение реляционной схемы из er-диаграммы
- •Базовые приемы
- •Представление в реляционной схеме супертипов и подтипов сущности
- •Представление в реляционной схеме взаимно исключающих связей
- •Виды нотаций er-диаграмм
- •Метод Баркера
- •Методология idef1x
- •Заключение
Аномалии обновлений, связанные с наличием перекрывающихся возможных ключей
Например, пусть имеется переменная отношения СЛУЖ_ПРО_ЗАДАН1 {СЛУ_НОМ, СЛУ_ИМЯ, ПРО_НОМ, СЛУ_ЗАДАН}с множеством FD, показанным на Рис. 16 .
Рис. 16 Диаграмма FD отношения СЛУЖ_ПРО_ЗАДАН1
В отношении СЛУЖ_ПРО_ЗАДАН1служащие уникально идентифицируются как по номерам удостоверений, так и по именам. Следовательно, существуют FDСЛУ_НОМСЛУ_ИМЯиСЛУ_ИМЯСЛУ_НОМ. Но один служащий может участвовать в нескольких проектах, поэтому возможными ключами являются{СЛУ_НОМ, ПРО_НОМ}и{СЛУ_ИМЯ, ПРО_НОМ}. На Рис. 17 показано возможное значение переменной отношенияСЛУЖ_ПРО_ЗАДАН1.
Рис. 17. Возможное значение переменной отношения СЛУЖ_ПРО_ЗАДАН1
Очевидно, что, хотя в отношении СЛУЖ_ПРО_ЗАДАН1все FD неключевых атрибутов от возможных ключей являются минимальными и транзитивные FD отсутствуют, этому отношению свойственны аномалии обновления. Например, в случае изменения имени служащего требуется обновить атрибутСЛУ_ИМЯво всех кортежах отношенияСЛУЖ_ПРО_ЗАДАН1, соответствующих данному служащему. Иначе будет нарушена FDСЛУ_НОМСЛУ_ИМЯ, и база данных окажется в несогласованном состоянии.
Нормальная форма Бойса-Кодда
Причиной отмеченных аномалий является то, что в требованиях 2NF и 3NF не требовалась минимальная функциональная зависимость от первичного ключа атрибутов, являющихся компонентами других возможных ключей. Проблему решает нормальная форма, которую исторически принято называть нормальной формой Бойса-Кодда и которая является уточнением 3NF в случае наличия нескольких перекрывающихся возможных ключей.
Определение: Нормальная форма Бойса-Кодда
Переменная отношения находится в нормальной форме Бойса-Кодда (BCNF)в том и только в том случае, когда любая выполняемая для этой переменной отношения нетривиальная и минимальная FD имеет в качестве детерминанта некоторый возможный ключ данного отношения.
Переменная отношения СЛУЖ_ПРО_ЗАДАН1может быть приведена к BCNF путем одной из двух декомпозиций:СЛУЖ_НОМ_ИМЯ {СЛУ_НОМ, СЛУ_ИМЯ}иСЛУЖ_НОМ_ПРО_ЗАДАН {СЛУ_НОМ, ПРО_НОМ, СЛУ_ЗАДАН}с множеством FD и значениями, показанными на Рис. 18, иСЛУЖ_НОМ_ИМЯ {СЛУ_НОМ, СЛУ_ИМЯ}иСЛУЖ_ИМЯ_ПРО_ЗАДАН {СЛУ_ИМЯ, ПРО_НОМ, СЛУ_ЗАДАН}(FD и значения результирующих переменных отношений выглядят аналогично).
Очевидно, что каждая из декомпозиций устраняет трудности, связанные с обновлением отношения СЛУЖ_ПРО_ЗАДАН1.
Рис. 18. Диаграммы FD и значения переменных отношений СЛУЖ_НОМ_ИМЯ и СЛУЖ_НОМ_ПРО_ЗАДАН
Всегда ли следует стремиться к bcnf?
Предположим теперь, что в организации все проекты включают разные задания, и по-прежнему каждый служащий может участвовать в нескольких проектах, но может выполнять в каждом проекте только одно задание. Одно задание в каждом проекте могут выполнять несколько служащих. Тогда переменная отношения СЛУЖ_ПРО_ЗАДАНимеет множество FD, показанное на Рис. 19, и может содержать значение, представленное на том же рисунке.
Рис. 19. Новый вариант переменной отношения СЛУЖ_ПРО_ЗАДАН
В этом отношении существуют два возможных ключа: {СЛУ_НОМ, ПРО_НОМ}и{СЛУ_НОМ, СЛУ_ЗАДАН}. Отношение удовлетворяет требованиям 3NF: отсутствуют неминимальные FD неключевых атрибутов от возможных ключей (поскольку нет не ключевых атрибутов) и отсутствуют транзитивные FD. Однако из-за наличия FDСЛУ_ЗАДАНПРО_НОМэто отношение не находится в BCNF. Поэтому отношениюСЛУ_ПРО_ЗАДАНснова свойственны аномалии обновления. Например (посколькуСЛУ_НОМявляется компонентом обоих возможных ключей), невозможно удалить данные о единственном служащем, выполняющем задание в некотором проекте, не утратив информацию об этом задании.
Можно привести отношениеСЛУЖ_ПРО_ЗАДАНк BCNF, выполнив его декомпозицию на отношения СЛУЖ_НОМ_ЗАДАН {СЛУ_НОМ, СЛУ_ЗАДАН} иПРО_НОМ_ЗАДАН {СЛУ_ЗАДАН, ПРО_НОМ}, и эта декомпозиция решает обозначенные проблемы (теперь можно хранить данные о задании проекта, не выполняемом ни одним служащим). Значения переменных отношенийСЛУЖ_НОМ_ЗАДАНиПРО_НОМ_ЗАДАНпоказаны на Рис. 20.
Рис. 20. Значения переменных отношений СЛУЖ_НОМ_ЗАДАН и ПРО_НОМ_ЗАДАН
Однако возникают новые трудности. Например, система должна запретить добавление в отношение СЛУЖ_НОМ_ЗАДАНкортежа<2934, D>, поскольку заданиеDотносится к проекту1, а служащий с номером2934уже выполняет задание в этом проекте. Так происходит, потому что исходная FD{СЛУ_НОМ, ПРО_НОМ}СЛУ_ЗАДАНне выводится из единственной (нетривиальной) действующей для этих проекций FDСЛУ_ЗАДАНПРО_НОМ, и соответствующее ограничение целостности становится ограничением базы данных.
Тем самым, проекцииСЛУЖ_НОМ_ЗАДАНиПРО_НОМ_ЗАДАНне являются независимыми, а отношениеСЛУЖ_ПРО_ЗАДАНатомарно, хотя и не находится в BCNF. Из этого следует, что при проектировании реляционной базы данных приведение отношения к BCNF не должно быть самоцелью. Нужно внимательно оценивать положительные и отрицательные последствия нормализации.
Наконец, приведем пример, когда наличие двух перекрывающихся возможных ключей не мешает отношению находиться в BCNF. Предположим, что в организации проекты включают одни и те же задания, каждый служащий может участвовать в нескольких проектах, но может выполнять в каждом проекте только одно задание. Тогда переменная отношения СЛУЖ_НОМ_ЗАДАНимеет множество FD, показанное на Рис. 21, и может содержать значение, показанное на том же рисунке.
В третьем варианте отношения СЛУЖ_НОМ_ЗАДАНимеются перекрывающиеся возможные ключи ({СЛУ_НОМ, ПРО_НОМ}и{ПРО_НОМ, СЛУ_ЗАДАН}), однако оно находится в BCNF, поскольку эти ключи являются единственными детерминантами. Легко убедиться, что отношениюСЛУЖ_НОМ_ЗАДАНаномалии обновления не свойственны.
Рис. 21. Третий вариант отношения СЛУЖ_НОМ_ЗАДАН
Нормализация схемы базы данных способствует более эффективному выполнению системой управления базами данных операций обновления базы данных, поскольку сокращается число проверок и вспомогательных действий, поддерживающих целостность базы данных. При проектировании реляционной базы данных почти всегда добиваются второй нормальной формы всех входящих в базу данных отношений. В часто обновляемых базах данных обычно стараются обеспечить третью нормальную форму отношений. На нормальную форму Бойса-Кодда внимание обращают гораздо реже, поскольку на практике ситуации, в которых у отношения имеется несколько составных перекрывающихся возможных ключей, встречаются нечасто.