Сводка определений и формулировок
Дата добавления: 2014-01-03; просмотров: 5; лекция была полезна: 0 студентам(у); не полезна: 0 студентам(у).
Опубликованный материал нарушает авторские права? сообщите нам...
Заключение
Процесс проектирования реляционной базы на основе метода нормализации преследует две основных цели:
· избежать избыточности хранения данных;
· устранить аномалии обновления отношений.
Обсудим, насколько эти цели актуальны в современных условиях, когда объемы доступных носителей внешней памяти непрерывно возрастают, стоимость их падает, а современные серверы реляционных баз данных способны автоматически поддерживать целостность баз данных. Здесь следует отметить два важных обстоятельства.
Во-первых, теория реляционных баз данных и методы их проектирования были развиты более двадцати лет тому назад. Ситуация в области технологии аппаратуры и программного обеспечения тогда была совсем иной, чем сегодня, и хорошо нормализованные реляционные базы данных весьма способствовали эффективности приложений.
Во-вторых, в то время реляционные базы преимущественно использовались в информационных системах оперативной обработки транзакций (On-Line Transaction Processing – OLTP). Характерные примеры таких систем мы отмечали в Лекции 1 – банковские системы, системы резервирования билетов и мест в гостиницах. Для систем категории OLTP свойственны частые обновления базы данных, и поэтому аномалии обновлений, даже если их корректировка производится СУБД автоматически, могут сильно вредить эффективности приложения.
Сегодня передним краем приложений баз данных являются системы категории оперативной аналитической обработки (On-Line Analytical Processing – OLAP). В подобных системах, в частности, системах поддержки принятия решений, базы данных в основном используются для выборки данных (поэтому аномалиями обновлений можно пренебречь), а объем этих баз настольно огромен, что можно пренебречь избыточностью хранения.
Значит ли это, что подход к проектированию реляционных баз данных методом нормализации утратил свою значимость? Ответ – категорическое НЕТ!
Мир приложений баз данных в настоящее время огромен. Сегодня любое мало-мальски приличное предприятие использует хотя бы одно приложение баз данных – бухгалтерские, складские, кадровые системы. Это системы категории OLTP с частым обновлением данных и достаточно простыми запросами к базе данных, не вызывающими соединений многих отношений. Для небольших компаний равно важны как эффективность их информационных систем, так и стоимость используемых аппаратно-программных средств. Правильно спроектированные, хорошо нормализованные реляционные базы данных помогают решению корпоративных проблем.
Да, любое правильно развивающееся предприятие рано или поздно приходит к использованию систем категории OLAP, например, некоторой разновидности систем поддержки принятия решений (Decision Support System – DSS). В базах данных таких систем обновления очень редки, а запросы могут иметь произвольную сложность, включая соединения многих отношений. Но, во-первых, технологически правильно для системы OLAP поддерживать отдельную базу данных (обычно такие базы данных называют хранилищами данных – DataWarehouse), а во-вторых, основными источниками данных для построения таких хранилищ данных являются базы данных систем OLTP. Так что актуальность правильно спроектированных баз данных OLTP-систем не уменьшается, а постоянно возрастает.
Следует ли из этого, что принципы нормализации непригодны при проектировании баз данных OLAP-приложений? И снова в ответ категорическое НЕТ! Возможно, окончательная схема такой базы данных должна быть денормализована по соображениям повышения эффективности выполнения запросов. Но чтобы получить правильную денормализованную схему, нужно сначала понять, как выглядит нормализованная схема.
Основной вывод этой и предыдущей лекций можно сформулировать следующим образом. Пока мы остаемся в мире реляционных баз данных, для правильного проектирования базы данных необходимо понимать принципы нормализации, воспринимая их не как догму, а как руководство к действию. Кстати, это относится не только к “ручному” проектированию реляционных баз данных, но и к их проектированию с применением семантических моделей данных и CASE-средств, которые мы обсудим в следующих двух лекциях.
Для удобства читателей в заключение мы приводим сводку формулировок определений и теорем, приведенных в последних трех лекциях. Это что-то вроде конспекта материала, посвященного принципам проектирования реляционных баз данных на основе нормализации.
Определение 6.1. Функциональная зависимость
В значении переменной отношения r атрибут Y функционально зависит от атрибута X в том и только в том случае, если каждому значению X соответствует в точности одно значение Y. В этом случае говорят также, что атрибут X функционально определяет атрибут Y (X является детерминантом (определителем) для Y, а Y является зависимым от X). Будем обозначать это как r.X ® r.Y. Конец определения.
Определение 6.2. Тривиальная функциональная зависимость
FD A ®B называется тривиальной, если A ÊB (т.е. множество атрибутов A включает множество B или совпадает со множеством B). Конец определения.
Определение 6.3. Замыкание множества FD
Замыканием множества FD S является множество FD S+, включающее все FD, логически выводимые из FD множества S. Конец определения.
Определение 6.4. Транзитивная функциональная зависимость
FD A ®C называется транзитивной, если существует такой атрибут B, что имеются функциональные зависимости A ®B и B ®C и отсутствует функциональная зависимость C ®A.
Определение 6.5. Замыкание множества атрибутов
Пусть заданы отношение r, множество Z атрибутов этого отношения (подмножество заголовка r, или составной атрибут r) и некоторое множество FD S, выполняемых для r. Тогда замыканием Z над S называется наибольшее множество Z+ таких атрибутов Y отношения r, что FD Z ® Y входит в S+. Конец определения.
Определение 6.6. Суперключ отношения
Суперключом отношения r называется любое подмножество K заголовка r, включающее, по меньшей мере, хотя бы один возможный ключ r. Конец определения.
Определение 6.7. Покрытие множества FD
Множество FD S2 называется покрытием множества FD S1, если любая FD, выводимая из S1, выводится также и из S2. Конец определения.
Определение 6.8. Минимальное множество FD
Множество FD S называется минимальным в том и только в том случае, когда удовлетворяет следующим свойствам:
d) правая часть любой FD из S является множеством из одного атрибута (простым атрибутом);
e) детерминант каждой FD из S обладает свойством минимальности; это означает, что удаление любого атрибута из детерминанта приводит к изменению замыкания S+, т.е. порождению множества FD, не эквивалентного S.*
f) удаление любой FD из S приводит к изменению S+, т.е. порождению множества FD, не эквивалентного S. Конец определения.
Определение 6.9. Минимальное покрытие множества FD
Минимальным покрытием множества FD S называется любое минимальное множество FD SI, эквивалентное S. Конец определения.
Теорема Хита.
Пусть задано отношение r {A, B, C} (A, B и C, в общем случае, являются составными атрибутами), и выполняется FD A ® B. Тогда r = (r PROJECT {A, B}) NATURAL JOIN (r PROJECT {A, C}).
Определение 6.10. Минимально зависимые атрибуты
Атрибут B минимально зависит от атрибута A, если выполняется минимальная слева FD A ® B. Конец определения.
Определение 7.1. Вторая нормальная форма
Переменная отношения находится во второй нормальной форме (2NF) тогда и только тогда, когда она находится в первой нормальной форме, и каждый неключевой атрибут минимально функционально зависит от первичного ключа. Конец определения.
Определение 7.2. Третья нормальная форма
Переменная отношения находится в третьей нормальной форме (3NF) в том и только в том случае, когда она находится во второй нормальной форме, и каждый неключевой атрибут нетранзитивно функционально зависит от первичного ключа. Конец определения.
Теорема Риссанена.
Проекции r1 и r2 отношения r являются независимыми тогда и только тогда, когда
· Каждая FD в отношении r логически следует* из FD в r1 и r2;
· Общие атрибуты r1 и r2 образуют возможный ключ хотя бы для одного из этих отношений.
Определение 7.3. Нормальная форма Бойса-Кодда
Переменная отношения находится в нормальной форме Бойса-Кодда (BCNF в том и только в том случае, когда любая выполняемая для этой переменной отношения нетривиальная и минимальная FD имеет в качестве детерминанта некоторый возможный ключ данного отношения. Конец определения.
Определение 8.1. Многозначная зависимость
В переменной отношения r с атрибутами A, B, C (в общем случае, составными) имеется многозначная зависимость B от A (A ®® B) в том и только в том случае, когда множество значений атрибута B, соответствующее паре значений атрибутов A и C, зависит от значения A и не зависит от значения C. Конец определения.
Лемма Фейджина
В отношении r {A, B, C} выполняется MVD A ®® B в том и только в том случае, когда выполняется MVD A ®® C.
Теорема Фейджина
Пусть имеется переменная отношения r с атрибутами A, B, C (в общем случае, составными). Отношение r декомпозируется без потерь на проекции {A, B} и {A, C} тогда и только тогда, когда для него выполняется MVD A ®® B | C.
Определение 8.2. Четвертая нормальная форма
Переменная отношения r находится в четвертой нормальной форме (4NF) в том и только в том случае, когда находится в BCNF, и все MVD r являются FD с детерминантами – возможными ключами отношения r. Конец определения.
Определение 8.3. Тривиальная многозначная зависимость
В переменной отношения r с атрибутами (возможно, составными) A и B MVD A ®® B называется тривиальной, если либо A Í B, либо A UNION B совпадает с заголовком отношения r.
Определение 8.4. Зависимость соединения
Пусть задана переменная отношения r, и A, B, …, Z являются произвольными подмножествами заголовка r (составными, перекрывающимися атрибутами). В переменной отношения r удовлетворяется зависимость проекции/соединения (Project-Join Dependency – PJD) *( A, B, …, Z) тогда и только тогда, когда любое допустимое значение r можно получить путем естественного соединения проекций этого значения на атрибуты A, B, …, Z. Конец определения.
Определение 8.5. Зависимость проекции/соединения, подразумеваемая возможными ключами
В переменной отношения r PJD *( A, B, …, Z) называется подразумеваемой возможными ключами в том и только в том случае, когда каждый составной атрибут A, B, …, Z является суперключом r, т.е. включает хотя бы один возможный ключ r. Конец определения.
Определение 8.6. Тривиальная зависимость проекции/соединения
В переменной отношения r зависимость проекции/соединения *(A, B, …, Z) называется тривиальной, если хотя бы один из составных атрибутов A, B, …, Z совпадает с заголовком r. Конец определения.
Определение 8.7. Пятая нормальная форма
Переменная отношения r находится в пятой нормальной форме, или в нормальной форме проекции/соединения (5NF, или PJ/NF – Project-Join Normal Form) в том и только в том случае, когда каждая нетривиальная PJD в r подразумевается возможными ключами r. Конец определения.