Нормализация

1НФ — первая нормальная форма

Собственные типы данных СУБД считаются атомарными, исключение могут составлять массивы, в том числе символьные (текстовые) и байтовые. Следует также понимать, что атомарность может быть относительна выбранного взгляда со стороны предметной области и контекста. Например, телефонный номер в базе данных маркетинга содержится в одной колонке, тогда как у телефонных операторов он разделяется на номера АТС, шлейфов и т.п. Колонки для хранения комментариев, подлежащих последующей обработке приложением, также отчасти нарушают принцип атомарности.

По этой же причине не стоит рассматривать отдельно целую и дробные части действительного числа или даже пару «дата-время»: дальнейшая детализация не имеет смысла с точки зрения моделируемой области, где они атомарны.

Предположим, мы нарушили 1НФ и стали хранить фамилии, имена и отчества клиентов в одной колонке. Пока операторы вносили информацию, эта ошибка проектирования особенно не мешала, Однако, на следующем этапе понадобилась отчётность, в которой ФИО клиентов выводились бы в виде фамилии и инициалов. Оказалось, что некоторые записи вместо «Сидоров Петр Иванович» содержат «Петр Иванович Сидоров», в других отчества нет вовсе, в третьих фамилия двойная и не всегда записана через тире, в четвёртых после фамилий расставлены запятые… Эту проблему пришлось решать программированием совсем нетривиальной логики с элементами распознавания по словарю. Было потрачено много времени и средств, но в отчётности нет-нет да и проскакивали непонятные значения типа «Оглы П.Б.Б.».

Следует отметить, что при добавлении к этому учёту клиентов- иностранцев, проектировщиков логической схемы БД не спасла бы и более структурированная форма из трёх колонок для раздельного хранения фамилий, имён и отчеств. Потому что это проблема уровня концептуального проектирования и соответствующих моделей: необходим синтез не привязанной к модели данных структуры, способной вмещать в себя комбинации имён людей разных стран и культур.

Нормальные формы

В создании и развитии теории нормализации принимали участие многие учёные. Однако первые три нормальные формы и концепцию функциональной зависимости предложил Э. Кодд.

Первая нормальная форма (1NF)

Основная статья: Первая нормальная форма

Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.

В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1НФ.

Вторая нормальная форма (2NF)

Основная статья: Вторая нормальная форма

Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме и каждый неключевой атрибут неприводимо (функционально полно) зависит от её потенциального ключа.

Третья нормальная форма (3NF)

Основная статья: Третья нормальная форма

Переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме, и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых.

Нормальная форма Бойса — Кодда (BCNF)

Основная статья: Нормальная форма Бойса — Кодда

Переменная отношения находится в нормальной форме Бойса — Кодда (иначе — в усиленной третьей нормальной форме) тогда и только тогда, когда каждая её нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.

Четвёртая нормальная форма (4NF)

Основная статья: Четвёртая нормальная форма

Переменная отношения находится в четвёртой нормальной форме, если она находится в нормальной форме Бойса — Кодда и не содержит нетривиальных многозначных зависимостей.

Пятая нормальная форма (5NF)

Основная статья: Пятая нормальная форма

Переменная отношения находится в пятой нормальной форме (иначе — в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения.

Доменно-ключевая нормальная форма (DKNF)

Основная статья: Доменно-ключевая нормальная форма

Переменная отношения находится в ДКНФ тогда и только тогда, когда каждое наложенное на неё ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную отношения.

Шестая нормальная форма (6NF)

Основная статья: Шестая нормальная форма

Переменная отношения находится в шестой нормальной форме тогда и только тогда, когда она удовлетворяет всем нетривиальным зависимостям соединения. Из определения следует, что переменная находится в 6НФ тогда и только тогда, когда она неприводима, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Каждая переменная отношения, которая находится в 6НФ, также находится и в 5НФ.

Введена К. Дейтом в его книге, как обобщение пятой нормальной формы для хронологической базы данных.

Третья нормальная форма

Отношение находится в 3НФ, если не существует тройки:

• ключа $X$,
• $Y\subseteq R$,
• непервичного атрибута $H\notin Y$,

для которой выполняются:

• $X\rightarrow Y\in F^+$;
• $Y\rightarrow H\in F^+$;
• $Y\rightarrow X\notin F^+$.

Если такую тройку можно найти, то схема не находится в 3НФ.

Если схема отношения находится в 3НФ, то в большинстве случаев эта схема отношения не обладает . Но существуют условия, когда схема в 3НФ обладает этими аномалиями. Хотя, встречаются они редко. Вот они:

• схема отношения имеет 2 или больше ключей,
  • и любые 2 из них являются составными,

Пример 1

Пусть $R = (A, B, C, D)$, $F = (A\rightarrow B, AC\rightarrow D)$ и $\rho = R$

Доказать, что это отношение не находится в 3НФ.

Доказываем:

1)

$i = 0$, $X_0 = ABCD$

2)

$(BCD)^+ = BCD\neq R$

$(ACD)^+ = ACDB = R$, $X = ACD$, $i = 1$

3)

$i$, как видим, возросло, значит опять 2)

2)

$(CD)^+ = CD\neq R$

$(AD)+^ = ADB\neq R$

$(AC)^+ = ACBD = R$, $X_2 = AC$, $i = 2$

3)

$i$, как видим, возросло, значит опять 2)

2)

$C^+ = C\neq R$

$A^+ = AB\neq R$

3)

$i$ не возросло, значит $X = X_2 = AC$ — это ключ. Причём, можно показать, что он единственный.

Теперь предполагаем тройку:

• $X = AC$
• $Y = A\subseteq R$
• $H = B$ — непервичный атрибут, $B\notin X$

Проверям три условия для неё:

1)

$X\rightarrow Y$, так как $AC\rightarrow A$ по 1 аксиоме Армстронга;

2)

$Y\rightarrow H$, $A\rightarrow B$ по условию;

3)

$Y\nrightarrow X$, $A\nrightarrow AC$

$A^+ = AB$, $AC\nsubseteq A^+$

Таким образом, найдена тройка, для которой выполняются все три условия, а значит отношение не находится в 3НФ.

Пример 2

Декомпозируем эту схему отношения $R$ на две схему отношений.

$R = (A, B, C, D)$

$F = (A\rightarrow B, AC\rightarrow D)$

$\rho = (AB, ACD) = (R_1, R_2)$

Если $R_1$ и $R_2$ находятся в 3НФ, то значит всё $\rho$ будет в 3НФ.

Сначала покажем 3НФ у $R_1 = (AB)$, $F = (A\rightarrow B)$:

• $X = A$ — выберем ключом
• $Y$, $X\rightarrow Y$, $Y\nrightarrow X$

$Y = B$, $A\rightarrow B$, $B\nrightarrow A$

невозможно подобрать непервичный атрибут $H\notin Y$, потому что непервичным может быть только $B$.

Таким образом, нельзя подобрать необходимую тройку. Значит, $R_1$ находится в 3НФ.

Теперь покажем 3НФ у $R_2 = (ACD)$, $F = (AC\rightarrow D)$:

• $X = AC$ — выберем ключом
• $Y$, $X\rightarrow Y$, $Y\nrightarrow X$

а) $A$ — что-то как-то не выполняется;

б) $C$ — что-то как-то не выполняется;

в) $D$ — что-то как-то не выполняется;

г) $AD$ — что-то как-то не выполняется;

д) $CD$ — что-то как-то не выполняется.

$H\notin Y$, $H = D$

а) $Y = A$, $Y\nrightarrow H$

б) $Y = C$, $Y\nrightarrow H$

в-д) $H\in Y$

Ключ схемы отношения

Ключ схемы отношения – это подмножество исходной схемы, состоящая из одного или нескольких атрибутов, которые задают уникальность значений в кортежах отношений.

Если атрибут $A_i\in R$ входит в какой-либо ключ схемы отношения $R$, то он называется первичным. А если не входит ни в один, то называется непервичным.

Пусть

$R = (A_1 … A_n)$ — некоторая схема отношения.

$F$ — множество ФЗ.

Тогда

$X\subseteq R$ называется ключом схемы, если выполняются:

• $X\rightarrow A_1 … A_n\in F^+$
• $\forall Z\subset X$, $Z\rightarrow A_1 … A_n\notin F^+$. То есть $X$ содержит минимальное число атрибутов, для которых выполняется предыдущее свойство.

Алгоритм построения ключа

Базируется на определении ключа. Позволяет построить только один ключ.

1)

$i = 0$, $X_0 = A_1 … A_n$

2)

цикл по атрибутам $A_j$ в $X_i$

Если $(X_i — A_j)^+ = R$, то $X_{i+1} = X_i — A_j$, $i = i + 1$ и выйти из цикла;

иначе продолжить цикл

3)

если $i$ возросло, то перейти к шагу 2);

иначе $X = X_i$ — это найденный ключ.

Пример построения ключа

Пусть $R = (A, B, C, D)$, $F = (AB\rightarrow DC, BC\rightarrow AD)$

Надо построить ключ.

1)

$i = 0$, $X_0 = ABCD$

2)

$(X_0 — A)^+ = (BCD)^+ = BCDA = R$, значит $X_1 = BCD$, $i = 1$

3)

$i$, как видим, возросло, значит опять 2)

2)

$(CD)^+ = CD\neq R$

$(BD)^+ = BD\neq R$

$(BC)^+ = BCAD = R$, $X_2 = BC$, $i = 2$

3)

$i$, как видим, возросло, значит опять 2)

2)

$C^+ = C\neq R$

$B^+ = B\neq R$

3)

$i$, как видим, не возросло. Значит, $X = BC$ — ключ. Но не единственный, $X = AB$ — тоже ключ, просто у нас получился сначала этот.

Значит, $A,B,C$ — первичные атрибуты, а $D$ — непервичный.

Пример

Пример приведения отношения ко второй нормальной форме

Пусть в следующем отношении первичный ключ образует пара атрибутов {Филиал компании, Должность}:

R

Филиал компании	Должность	Зарплата	Наличие компьютера
Филиал в Томске	Уборщик	20000	Нет
Филиал в Москве	Программист	40000	Есть
Филиал в Томске	Программист	25000	Есть

Допустим, что зарплата зависит от филиала и должности, а наличие компьютера зависит только от должности.

Существует функциональная зависимость Должность → Наличие компьютера, в которой левая часть (детерминант) является лишь частью первичного ключа, что нарушает условие второй нормальной формы.

Для приведения к 2NF исходное отношение следует декомпозировать на два отношения:

R1

Филиал компании	Должность	Зарплата
Филиал в Томске	Уборщик	20000
Филиал в Томске	Программист	25000
Филиал в Москве	Программист	40000

R2

Должность	Наличие компьютера
Уборщик	Нет
Программист	Есть

Литература

На русском языке

• Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
• Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-университет информационных технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2.

Переводная

• Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: Вильямс, 2005. — 1328 с. — ISBN 5-8459-0788-8 (рус.) 0-321-19784-4 (англ.).
• Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: Вильямс, 2003. — 1436 с. — ISBN 0-201-70857-4.
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс = Database Systems: The Complete Book. — Вильямс, 2003. — 1088 с. — ISBN 5-8459-0384-X.

На английском языке

C. J. Date. Date on Database: Writings 2000–2006. — Apress, 2006. — 566 с. — ISBN 978-1-59059-746-0, 1-59059-746-X.

Это заготовка статьи о программировании. Вы можете помочь проекту, дополнив её.

Вторая нормальная форма

Последнее обновление: 02.07.2017

Во второй нормальной форме каждый столбец в таблице, который не является ключом, должен зависеть от ключа.

Ключевой момент второй нормальной формы — полная функциональная зависимость. Она предполагает, что атрибут В полностью функционально зависим от атрибута А,
если атрибут В функционально зависит от полного значения атрибута А, а не от какого-либо подмножества значений из атрибута А.
То есть, если атрибут А составляют несколько значений, скажем, А1 и А2, то атрибут В полностью функционально зависит от А, если он зависит и от А1 и от А2
(А1, А2 → В).

Если атрибут В зависит только от какого-либо подмножества из атрибута А, например, только от А1, то имеет место частичная функциональная зависимость.

Эта форма применяется к тем таблицам, которые имеют составной первичный ключ, то есть где первичный ключ состоит из нескольких атрибутов.
Если в таблице несоставной первичный ключ, то в этом случае считается, что все остальные атрибуты автоматически находятся в полной функциональной зависимости от первичного ключа.

Вторая нормальная форма применяется только к тем таблицам, которые находятся в первой нормальной форме. После применения второй формы все столбцы таблицы зависят от первичного ключа.

Возьмем сформированную в прошлой теме таблицу StudentCourses после применения первой нормальной формы:

StudentId	Name	CourseId	Course	Date	TeacherId	Teacher	Position
1	Том	1	Математика	11/06/2017	1	Смит	Профессор
1	Том	2	JavaScript	14/06/2017	2	Адамс	Ассистент
2	Сэм	3	Алгоритмы	12/06/2017	2	Адамс	Ассистент
3	Боб	1	Математика	13/06/2017	1	Смит	Профессор

На данный момент эта таблица имеет составной первичный ключ StudentId+CourseId. Какие функциональные зависимости от ключевых атрибутов здесь можно выделить:

StudentId, CourseId → Date

StudentId → Name

CourseId → Course, TeacherId, Teacher, Position

От обоих частей составного ключа StudentId+CourseId зависит только арибут Date — дата, в которую студент с идентификатором StudentId поступил на курс с
идентифкатором CourseId.

Атрибут Name зависит только от части составного ключа — от атрибута StudentId, так как зная идентификатор студента, можно сказать, какое у него имя. В данном случае имеет факт частичной зависимости.

Атрибуты Course, TeacherId, Teacher, Position зависит от другой части ключа — от атрибута CourseId. Зная значение CourseId,
можно сказать, как называется курс, какой у курса преподаватель, какую должность он занимает. Опять же здесь частичная
зависимость.

Наличие частичных зависимостей говорит о том, что таблица не находится во второй нормальной форме. И для перехода к этой форме
необходимо переместить атрибуты, которые не входят в первичный ключ, в новую таблицу вместе с копией части первичного ключа, от которой
они функционально зависят.

В нашем случае из одной таблицы получатся три. Таблица Students:

StudentId	Name
1	Том
2	Сэм
3	Боб

Таблица Courses:

CourseId	Course	TeacherId	Teacher	Position
1	Математика	1	Смит	Профессор
2	JavaScript	2	Адамс	Ассистент
3	Алгоритмы	2	Адамс	Ассистент

И таблица StudentCourses:

StudentId	CourseId	Date
1	1	11/06/2017
1	2	14/06/2017
2	3	12/06/2017
3	1	13/06/2017

Итогом стало образование связи многие ко многим (много студентов — много курсов) между таблицами Students и Courses через таблицу StudentCourses .

Таким образом, база данных перешла во вторую нормальную форму.

НазадВперед

Пример

Пример приведения отношения ко второй нормальной форме

Пусть в следующем отношении первичный ключ образует пара атрибутов {Филиал компании, Должность}:

R

Филиал компании	Должность	Зарплата	Наличие компьютера
Филиал в Томске	Уборщик	20000	Нет
Филиал в Москве	Программист	40000	Есть
Филиал в Томске	Программист	25000	Есть

Допустим, что зарплата зависит от филиала и должности, а наличие компьютера зависит только от должности.

Существует функциональная зависимость Должность → Наличие компьютера, в которой левая часть (детерминант) является лишь частью первичного ключа, что нарушает условие второй нормальной формы.

Для приведения к 2NF исходное отношение следует декомпозировать на два отношения:

R1

Филиал компании	Должность	Зарплата
Филиал в Томске	Уборщик	20000
Филиал в Томске	Программист	25000
Филиал в Москве	Программист	40000

R2

Должность	Наличие компьютера
Уборщик	Нет
Программист	Есть

Роль нормализации в проектировании реляционных баз данных

При том, что идеи нормализации весьма полезны для проектирования баз данных, они отнюдь не являются универсальным или исчерпывающим средством повышения качества проекта БД. Это связано с тем, что существует слишком большое разнообразие возможных ошибок и недостатков в структуре БД, которые нормализацией не устраняются. Несмотря на эти рассуждения, теория нормализации является очень ценным достижением реляционной теории и практики, поскольку она даёт научно-строгие и обоснованные критерии качества проекта БД и формальные методы для усовершенствования этого качества. Этим теория нормализации резко выделяется на фоне чисто эмпирических подходов к проектированию, которые предлагаются в других моделях данных. Более того, можно утверждать, что во всей сфере информационных технологий практически отсутствуют методы оценки и улучшения проектных решений, сопоставимые с теорией нормализации реляционных баз данных по уровню формальной строгости.

Нормализацию иногда упрекают на том основании, что «это просто здравый смысл», а любой компетентный профессионал и сам «естественным образом» спроектирует полностью нормализованную БД без необходимости применять теорию зависимостей. Однако, как указывает К. Дейт, нормализация в точности и является теми принципами здравого смысла, которыми руководствуется в своём сознании зрелый проектировщик, то есть принципы нормализации — это формализованный здравый смысл. Между тем, идентифицировать и формализовать принципы здравого смысла — весьма трудная задача, и успех в её решении является существенным достижением.

Свойства «хорошей» схемы БД

Пример 1

Пусть $R = (A, B, C)$, $\rho = (AB, BC) = (R_1, R_2)$ и $F = (A\rightarrow B, B\rightarrow C)$

Обладает ли $\rho$ сохранением ФЗ?

Смотрим:

1)

$H=\varnothing$, $УНП = (A\rightarrow BC, B\rightarrow C)$

2)

$G = (A\rightarrow B, A\rightarrow C, B\rightarrow C)$

3)

$A\rightarrow B$, $AB\subseteq R_1$

$A\rightarrow C$, $AC\nsubseteq R_2$, $H=(A\rightarrow C)$

$B\rightarrow C$, $BC\subseteq R_2$

4) пропускаем, так как не выполнилось условие в 3)

5)

$H$ не пустое.

6)

выполняется ли $A\rightarrow C\in(G-H)^+ = (A\rightarrow B, B\rightarrow C)^+$

$A^+=ABC$, $C\in A^+$, значит $\rho$ обладает сохранением ФЗ.

Пример 2

Пусть $R = (A, B, C)$, $\rho = (AB, AC) = (R_1, R_2)$ и $F = (A\rightarrow B, B\rightarrow C)$

Обладает ли $\rho$ сохранением ФЗ?

1-4)

$H = \varnothing$, $УНП = (A\rightarrow BC, B\rightarrow C)$

$H = (B\rightarrow C))$

5)

$H$ не пустое.

6)

выполняется ли $B\rightarrow C\in(G — H)^+ = (A\rightarrow BC)^+$

$B^+ = B$, $C\notin B^+$, значит $\rho$ не обладает сохранением ФЗ.

Денормализация базы данных

Теория нормальных форм не всегда применима на практике. Например, неатомарные значения не всегда являются «злом», а иногда наоборот. Связано это с необходимостью дополнительного объединения (следовательно, затрат производительности системы) при выполнении запросов, особенно когда производится обработка большого массива информации.

Для баз данных, предназначенных для аналитики, часто выполняют денормализацию, чтобы укорить выполнение запросов.

• < Назад
• Вперёд >

Новые статьи:

• Объединение таблиц – UNION

• Соединение таблиц – операция JOIN и ее виды

• Тест на знание основ SQL

Если материалы office-menu.ru Вам помогли, то поддержите, пожалуйста, проект, чтобы я мог развивать его дальше.

Определение

Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме и каждый неключевой атрибут неприводимо зависит от (каждого) её потенциального ключа.

Неприводимость означает, что в составе потенциального ключа отсутствует меньшее подмножество атрибутов, от которого можно также вывести данную функциональную зависимость. Для неприводимой функциональной зависимости часто используется эквивалентное понятие «полная функциональная зависимость».

Если потенциальный ключ является простым, то есть состоит из единственного атрибута, то любая функциональная зависимость от него является неприводимой (полной). Если потенциальный ключ является составным, то, согласно определению второй нормальной формы, в отношении не должно быть неключевых атрибутов, зависящих от части составного потенциального ключа.

Вторая нормальная форма по определению запрещает наличие неключевых атрибутов, которые вообще не зависят от потенциального ключа. Таким образом, вторая нормальная форма в том числе запрещает создавать отношения как несвязанные (хаотические, случайные) наборы атрибутов.

2НФ — вторая нормальная форма

На первый взгляд кажется, что нарушения 2НФ практически невозможны, потому что чаще всего в качестве первичных ключей используются автоинкрементные целочисленные значения или иные суррогаты для реализации ссылок. Однако, в определении говорится о ключах вообще, а не только о первичных. В отношении может быть несколько ключей, и некоторые из них могут являться составными. Такие ключи следует подвергнуть проверке в первую очередь.

Например, если каждая операция сбыта мебельной продукции в таблице продаж однозначно характеризуется колонками идентификатора товарной позиции, даты продажи и идентификатором покупателя, то нахождение в той же таблице столбца «Тип материала», зависящего непосредственно от товарной позиции, должно немедленно привлечь ваше внимание. Аномалия в данном случае приведёт только к избыточности хранения в виде размера идентификатора, помноженного на число строк таблицы (без учёта индексов)

Но если в той же таблице обнаружится ещё и колонка «Контактный телефон», присущая атрибутике покупателя, то последствия окажутся более серьёзными. Кроме избыточности хранения при ошибке ввода придётся исправлять номер телефона во всех записях о продажах данному покупателю

Аномалия в данном случае приведёт только к избыточности хранения в виде размера идентификатора, помноженного на число строк таблицы (без учёта индексов). Но если в той же таблице обнаружится ещё и колонка «Контактный телефон», присущая атрибутике покупателя, то последствия окажутся более серьёзными. Кроме избыточности хранения при ошибке ввода придётся исправлять номер телефона во всех записях о продажах данному покупателю.

Кроме приведённых примеров, при наличии в таблицах нескольких ключей необходимо, с позиций логики предметной области, определить, являются ли эти ключи присущими данной сущности или же они суть внешние ключи другой сущности, пока ещё не выделенной в процессе проектирования.

Примечания

1. ↑ С. J. Date. What First Normal Form Really Means //С. J. Date. Date on database: Writings 2000—2006, Apress, 2006, ISBN 978-1-59059-746-0
2. Elmasri, Ramez and Navathe, Shamkant B. Fundamentals of Database Systems, Fourth Edition (англ.). — Pearson, 2003. — P. 315. — ISBN 0321204484.: «It states that the domain of an attribute must include only atomic (simple, indivisible) values and that the value of any attribute in a tuple must be a single value from the domain of that attribute.»
3. Darwen, Hugh. Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up? // Relational Database Writings 1989—1991, Addison-Wesley, 1992.

Роль нормализации в проектировании реляционных баз данных

При том, что идеи нормализации весьма полезны для проектирования баз данных, они отнюдь не являются универсальным или исчерпывающим средством повышения качества проекта БД. Это связано с тем, что существует слишком большое разнообразие возможных ошибок и недостатков в структуре БД, которые нормализацией не устраняются. Несмотря на эти рассуждения, теория нормализации является очень ценным достижением реляционной теории и практики, поскольку она даёт научно-строгие и обоснованные критерии качества проекта БД и формальные методы для усовершенствования этого качества. Этим теория нормализации резко выделяется на фоне чисто эмпирических подходов к проектированию, которые предлагаются в других моделях данных. Более того, можно утверждать, что во всей сфере информационных технологий практически отсутствуют методы оценки и улучшения проектных решений, сопоставимые с теорией нормализации реляционных баз данных по уровню формальной строгости.

Нормализацию иногда упрекают на том основании, что «это просто здравый смысл», а любой компетентный профессионал и сам «естественным образом» спроектирует полностью нормализованную БД без необходимости применять теорию зависимостей. Однако, как указывает К. Дейт, нормализация в точности и является теми принципами здравого смысла, которыми руководствуется в своём сознании зрелый проектировщик, то есть принципы нормализации — это формализованный здравый смысл. Между тем, идентифицировать и формализовать принципы здравого смысла — весьма трудная задача, и успех в её решении является существенным достижением.

3НФ — третья нормальная форма

Что такое транзитивная зависимость легко понять на примере уже упоминавшейся выше таблицы продаж — типичного примера ассоциативной таблицы.

Предположим, что продажа каждой товарной позиции имеет своим основанием документ (заказ, счёт и т.д.), а её стоимость характеризуется ценой, количеством и валютой. В этом случае имеем следующие зависимости между атрибутами (колонками):

• «Идентификатор продажи» => «Номер документа»
• «Идентификатор продажи» => «Код валюты»
• «Номер документа» => «Код валюты»

Эти зависимости транзитивны: каждая продажа однозначно определяет свой документ-основание и расчётную валюту, однако, валюта определяется ещё и документом.

Результатом нарушения 3НФ является избыточность хранения и необходимость обновления данных в связанной таблице. Так, если вы оставите колонку «Код валюты» в таблице продаж, то при изменении валюты документа придётся также обновлять все связанные с ним строки продаж.

Литература

На русском языке

• Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
• Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-университет информационных технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2.

Переводная

• Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: Вильямс, 2005. — 1328 с. — ISBN 5-8459-0788-8 (рус.) 0-321-19784-4 (англ.).
• Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: Вильямс, 2003. — 1436 с. — ISBN 0-201-70857-4.
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс = Database Systems: The Complete Book. — Вильямс, 2003. — 1088 с. — ISBN 5-8459-0384-X.

На английском языке

C. J. Date. Date on Database: Writings 2000–2006. — Apress, 2006. — 566 с. — ISBN 978-1-59059-746-0, 1-59059-746-X.

Это заготовка статьи о программировании. Вы можете помочь проекту, дополнив её.

Демормализация в базе данных: «звезда» и «снежинка»

Как можно понять из вышеприведённых примеров, основными целями нормализации являются:

• устранение избыточности при хранении данных, приводящей к увеличению размера БД;
• исключение необходимости модификации данных в связных таблицах для минимизации времени и операций, проводящихся в одной транзакции. Или, как выражаются специалисты, уменьшить толщину транзакции, потому что толстые транзакции мешают при многопользовательской работе взаимными блокировками и увеличением времени отклика системы. Речь об этом пойдёт в отдельной главе.

Но список заявленных целей касается приложений транзакционных.

В приложениях интерактивной аналитической обработки приоритет меняется: на первый план выходит время отклика системы, в ущерб которому данные могут быть избыточны.