Ошибкой нормализации является

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

Нормализация
– процесс проверки и реорганизации
сущностей и атрибутов с целью удовлетворения
требований к реляционной модели базы
данных. Нормализация позволяет: 1) быть
уверенным, что каждый атрибут определен
для своей сущности, 2) значительно
сократить объем памяти для хранения
информации и 3) устранить аномалии в
организации хранения данных. В результате
проведения нормализации должна быть
создана структура данных, при которой
информация о каждом факте хранится
только в одном месте. Процесс нормализации
сводится к последовательному приведению
структуры
данных к нормальным формам — формализованным
требованиям к организации данных.
Известно 6 нормальных форм:

• первая нормальная
  форма (1NF);

• вторая нормальная
  форма (2NF);

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

• нормальная форма
  Бойса — Кодда (усиленная 3NF);

• четвертая нормальная
  форма (4NF);

• пятая нормальная
  форма (5NF).

Нормальные
формы основаны на понятии функциональной
зависимости (в дальнейшем будем
использовать термин “зависимость”).

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

Полная функциональная
зависимость.
Атрибут В сущности Е полностью
функционально зависит от ряда атрибутов
А сущности Е тогда и только тогда, когда
В функционально зависит от А и не зависит
ни от какого подряда А.

На рис. 6 в сущности
Сотрудник
значения атрибутов Фамилия,
Имя
и Отчество
однозначно определяются значением
атрибута Табельный
номер, т.
е. атрибуты Фамилия,
Имя
и Отчество
зависят от атрибута Табельный
номер.
Функциональные зависимости определяются
бизнес-правилами предметной области.
Так, если оклад сотрудника определяется
только должностью, то атрибут Оклад
зависит от атрибута Должность;
если оклад зависит еще, например, от
стажа, то такой зависимости нет. В
нижеследующих примерах будем считать
для определенности, что такая зависимость
есть.

Рис.
6. Ненормализованная сущность Сотрудник

Рассмотрим подробнее
первые четыре нормальные формы.

Первая нормальная
форма (1NF).
Сущность находится в первой нормальной
форме тогда и только тогда, когда все
атрибуты содержат атомарные значения.
Среди атрибутов не должно встречаться
повторяющихся групп, т.е. несколько
значений для каждого экземпляра. На
рис. 6 атрибуты Телефон
и Хобби
являются нарушением первой нормальной
формы. Что будет, если у сотрудника
несколько рабочих телефонов? Запись
значения колонки через разделитель,
например “124-56-78, 124-56-79, 124-56-90” или
“Аквалангист, мотоциклист, шахматист”,
приводит к ряду проблем, например,
размера поля может не хватить для
хранения данных (нельзя увеличивать
список телефонов до бесконечности).
Сущность, приведенная на рис. 7, не
является решением проблемы. Что будет,
если у сотрудника появится четвертый
телефон или третье хобби? Эту информацию
будет негде хранить.

Рис.
7. Ненормализованная сущность Сотрудник

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

Для приведения
сущности к первой нормальной форме
следует:

• разделить сложные
  атрибуты на атомарные;

• создать новую
  сущность;

• перенести в нее
  все “повторяющиеся” атрибуты;

• выбрать возможный
  ключ для нового РК (или создать новый
  РК);

• установить
  идентифицирующую связь от прежней
  сущности к новой, РК прежней сущности
  станет внешним ключом (FK) для новой
  сущности.

На рис. 8 показана
сущность Сотрудник,
приведенная к первой нормальной форме.

Рис. 8. Сущность
Сотрудник,
приведенная к первой нормальной форме

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

Рис. 9. Сущность
Проект

Предположим,
сущность Проект
содержит информацию о проекте, которым
руководит сотрудник, причем информация
содержится как непосредственно о
проекте, так и о руководителе проекта
(рис. 9). Атрибуты Фамилия,
Имя, Отчество
и Должность
зависят только от атрибута Табельный
номер руководителя,
но вовсе не от Наименования
проекта.
Другими словами, имеется зависимость
только от части ключа.

Для приведения
сущности ко второй нормальной форме
следует:

• выделить атрибуты,
  которые зависят только от части
  первичного ключа, создать новую сущность;

• поместить атрибуты,
  зависящие от части ключа, в их собственную
  (новую) сущность;

• установить
  идентифицирующую связь от прежней
  сущности к новой (рис. 10).

Рис. 10. Сущность
Проект,
приведенная ко второй нормальной форме

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

• Обновления
  (UPDATE). Имеет
  место дублирование данных о сотруднике,
  если он руководит несколькими проектами.
  Если данные о сотруднике изменяются,
  необходимо менять несколько записей
  (по числу ведомых проектов).

• Вставки (INSERT).
  Невозможно ввести данные о сотруднике,
  если он в данный момент не руководит
  проектами.

• Удаления (DELETE).
  Если сотрудник временно прекращает
  руководство проектами, данные о нем
  теряются.

На рис. 10 показана
сущность Проект,
приведенная ко второй нормальной форме.

Третья нормальная
форма (3NF).
Сущность
находится в третьей нормальной форме,
если она находится во второй нормальной
форме и никакой неключевой атрибут не
зависит от другого неключевого атрибута
(не должно быть взаимозависимости между
неключевыми атрибутами).

На рис. 8 сущность
Сотрудник
находится во второй нормальной форме
(имеется только один атрибут первичного
ключа, поэтому не может быть зависимости
неключевых атрибутов от части ключа),
но неключевой атрибут Оклад
зависит от другого неключевого атрибута
— Должности.

Для приведения
сущности ко третьей нормальной форме
следует:

• создать новую
  сущность и перенести в нее атрибуты с
  одной и той же зависимостью от неключевого
  атрибута;

• использовать
  атрибут(ы), определяющий эту зависимость,
  в качестве первичного ключа новой
  сущности;

• установить
  неидентифицирующую связь от новой
  сущности к старой (рис. 11).

Рис.11. Сущность
Сотрудник,
приведенная к третьей нормальной форме

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

Третья
нормальная форма также позволяет
избежать ряда аномалий:

• Обновления
  (UPDATE). Имеет
  место дублирование данных об окладе,
  если должность занимают несколько
  сотрудников. Если оклад, соответствующий
  должности, меняется, необходимо менять
  несколько записей (по числу сотрудников
  на одной должности).

• Вставки (INSERT).
  Невозможно ввести данные об окладе,
  соответствующем должности, если в
  данный момент нет сотрудника, занимающего
  эту должность.

• Удаления (DELETE).
  В случае удаления из таблицы сотрудника,
  занимающего уникальную должность,
  данные об окладе теряются.

Четвертая
нормальная форма (4NF)
требует отсутствия многозначных
зависимостей между атрибутами.

В примере на рисунке
12 а преподаватель читает лекции по
нескольким предметам и курирует несколько
групп студентов. Одна группа студентов
может изучать несколько предметов,
одному предмету могут обучаться несколько
групп студентов. Имеется многозначная
зависимость между атрибутами Предмет
и Группа.
При этом возможна аномалия: если у
преподавателя появляется новая группа,
приходится добавлять несколько записей,
по числу читаемых предметов.

Рис. 12. Иллюстрация
четвертой нормальной формы.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

An insertion anomaly. Until the new faculty member, Dr. Newsome, is assigned to teach at least one course, their details cannot be recorded.

An update anomaly. Employee 519 is shown as having different addresses on different records.

• UNF: Unnormalized form
• 1NF: First normal form
• 2NF: Second normal form
• 3NF: Third normal form
• EKNF: Elementary key normal form
• BCNF: Boyce–Codd normal form
• 4NF: Fourth normal form
• ETNF: Essential tuple normal form
• 5NF: Fifth normal form
• DKNF: Domain-key normal form
• 6NF: Sixth normal form

Price

1. ^ «The adoption of a relational model of data … permits the development of a universal data sub-language based on an applied predicate calculus. A first-order predicate calculus suffices if the collection of relations is in first normal form. Such a language would provide a yardstick of linguistic power for all other proposed data languages, and would itself be a strong candidate for embedding (with appropriate syntactic modification) in a variety of host languages (programming, command- or problem-oriented).» Codd, «A Relational Model of Data for Large Shared Data Banks» Archived June 12, 2007, at the Wayback Machine, p. 381
2. ^ Codd, E.F. Chapter 23, «Serious Flaws in SQL», in The Relational Model for Database Management: Version 2. Addison-Wesley (1990), pp. 371–389
3. ^ Codd, E.F. «Further Normalisation of the Data Base Relational Model», p. 34
4. ^ ^{a b} Codd, E. F. (June 1970). «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685. S2CID 207549016. Archived from the original on June 12, 2007. Retrieved August 25, 2005.
5. ^ ^{a b c d} Codd, E. F. «Further Normalization of the Data Base Relational Model». (Presented at Courant Computer Science Symposia Series 6, «Data Base Systems», New York City, May 24–25, 1971.) IBM Research Report RJ909 (August 31, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972.
6. ^ Codd, E. F. «Recent Investigations into Relational Data Base Systems». IBM Research Report RJ1385 (April 23, 1974). Republished in Proc. 1974 Congress (Stockholm, Sweden, 1974), N.Y.: North-Holland (1974).
7. ^ Date, C. J. (1999). An Introduction to Database Systems. Addison-Wesley. p. 290.
8. ^ Darwen, Hugh; Date, C. J.; Fagin, Ronald (2012). «A Normal Form for Preventing Redundant Tuples in Relational Databases» (PDF). Proceedings of the 15th International Conference on Database Theory. EDBT/ICDT 2012 Joint Conference. ACM International Conference Proceeding Series. Association for Computing Machinery. p. 114. doi:10.1145/2274576.2274589. ISBN 978-1-4503-0791-8. OCLC 802369023. Archived (PDF) from the original on March 6, 2016. Retrieved May 22, 2018.
9. ^ Kumar, Kunal; Azad, S. K. (October 2017). Database normalization design pattern. 2017 4th IEEE Uttar Pradesh Section International Conference on Electrical, Computer and Electronics (UPCON). IEEE. doi:10.1109/upcon.2017.8251067. ISBN 9781538630044. S2CID 24491594.
10. ^ ^{a b c} «Database normalization in MySQL: Four quick and easy steps». ComputerWeekly.com. Archived from the original on August 30, 2017. Retrieved March 23, 2021.
11. ^ «Database Normalization: 5th Normal Form and Beyond». MariaDB KnowledgeBase. Retrieved January 23, 2019.
12. ^ «Additional Normal Forms — Database Design and Relational Theory — page 151». what-when-how.com. Retrieved January 22, 2019.
13. ^ ^{a b} Date, C. J. (December 21, 2015). The New Relational Database Dictionary: Terms, Concepts, and Examples. «O’Reilly Media, Inc.». p. 138. ISBN 9781491951699.
14. ^ Date, C. J. (December 21, 2015). The New Relational Database Dictionary: Terms, Concepts, and Examples. «O’Reilly Media, Inc.». p. 163. ISBN 9781491951699.
15. ^ «normalization — Would like to Understand 6NF with an Example». Stack Overflow. Retrieved January 23, 2019.
16. ^ Microsoft Corporation. Columnstore Indexes: Overview. https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview . Accessed March 23, 2020.

An insertion anomaly. Until the new faculty member, Dr. Newsome, is assigned to teach at least one course, their details cannot be recorded.

A deletion anomaly. All information about Dr. Giddens is lost if they temporarily cease to be assigned to any courses.

• UNF: Unnormalized form
• 1NF: First normal form
• 2NF: Second normal form
• 3NF: Third normal form
• EKNF: Elementary key normal form
• BCNF: Boyce–Codd normal form
• 4NF: Fourth normal form
• ETNF: Essential tuple normal form
• 5NF: Fifth normal form
• DKNF: Domain-key normal form
• 6NF: Sixth normal form

Price

1. ^ «The adoption of a relational model of data … permits the development of a universal data sub-language based on an applied predicate calculus. A first-order predicate calculus suffices if the collection of relations is in first normal form. Such a language would provide a yardstick of linguistic power for all other proposed data languages, and would itself be a strong candidate for embedding (with appropriate syntactic modification) in a variety of host languages (programming, command- or problem-oriented).» Codd, «A Relational Model of Data for Large Shared Data Banks» Archived June 12, 2007, at the Wayback Machine, p. 381
2. ^ Codd, E.F. Chapter 23, «Serious Flaws in SQL», in The Relational Model for Database Management: Version 2. Addison-Wesley (1990), pp. 371–389
3. ^ Codd, E.F. «Further Normalisation of the Data Base Relational Model», p. 34
4. ^ ^{a b} Codd, E. F. (June 1970). «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685. S2CID 207549016. Archived from the original on June 12, 2007. Retrieved August 25, 2005.
5. ^ ^{a b c d} Codd, E. F. «Further Normalization of the Data Base Relational Model». (Presented at Courant Computer Science Symposia Series 6, «Data Base Systems», New York City, May 24–25, 1971.) IBM Research Report RJ909 (August 31, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972.
6. ^ Codd, E. F. «Recent Investigations into Relational Data Base Systems». IBM Research Report RJ1385 (April 23, 1974). Republished in Proc. 1974 Congress (Stockholm, Sweden, 1974), N.Y.: North-Holland (1974).
7. ^ Date, C. J. (1999). An Introduction to Database Systems. Addison-Wesley. p. 290.
8. ^ Darwen, Hugh; Date, C. J.; Fagin, Ronald (2012). «A Normal Form for Preventing Redundant Tuples in Relational Databases» (PDF). Proceedings of the 15th International Conference on Database Theory. EDBT/ICDT 2012 Joint Conference. ACM International Conference Proceeding Series. Association for Computing Machinery. p. 114. doi:10.1145/2274576.2274589. ISBN 978-1-4503-0791-8. OCLC 802369023. Archived (PDF) from the original on March 6, 2016. Retrieved May 22, 2018.
9. ^ Kumar, Kunal; Azad, S. K. (October 2017). Database normalization design pattern. 2017 4th IEEE Uttar Pradesh Section International Conference on Electrical, Computer and Electronics (UPCON). IEEE. doi:10.1109/upcon.2017.8251067. ISBN 9781538630044. S2CID 24491594.
10. ^ ^{a b c} «Database normalization in MySQL: Four quick and easy steps». ComputerWeekly.com. Archived from the original on August 30, 2017. Retrieved March 23, 2021.
11. ^ «Database Normalization: 5th Normal Form and Beyond». MariaDB KnowledgeBase. Retrieved January 23, 2019.
12. ^ «Additional Normal Forms — Database Design and Relational Theory — page 151». what-when-how.com. Retrieved January 22, 2019.
13. ^ ^{a b} Date, C. J. (December 21, 2015). The New Relational Database Dictionary: Terms, Concepts, and Examples. «O’Reilly Media, Inc.». p. 138. ISBN 9781491951699.
14. ^ Date, C. J. (December 21, 2015). The New Relational Database Dictionary: Terms, Concepts, and Examples. «O’Reilly Media, Inc.». p. 163. ISBN 9781491951699.
15. ^ «normalization — Would like to Understand 6NF with an Example». Stack Overflow. Retrieved January 23, 2019.
16. ^ Microsoft Corporation. Columnstore Indexes: Overview. https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview . Accessed March 23, 2020.