Нормализация — это процесс организации данных в базе данных, Она включает в себя создание таблиц и установление связей между ними в соответствии с правилами, разработанными как для защиты данных, так и для повышения гибкости базы данных, устраняя избыточность и несогласованную зависимость.
Избыточность данных. Приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах. Изменение адреса клиента проще реализовать, если эти данные хранятся только в таблице Customers и более нигде в базе данных.
Существует несколько правил нормализации баз данных. Каждое правило называется "нормальной формой". Если соблюдается первое правило, база данных, как говорят, находится в "первой нормальной форме". При соблюдении первых трех правил база данных считается в "третьей нормальной форме". Хотя и другие уровни нормализации возможны, третья нормальная форма считается самым высоким уровнем, необходимым для большинства приложений.
Не используйте несколько полей в одной таблице для хранения похожих данных. Например, для слежения за товаром, который закупается у двух разных поставщиков, можно создать запись с полями, определяющими код первого поставщика и код второго поставщика.
Что произойдет при добавлении третьего поставщика? Добавление поля не является ответом: он требует изменений в программе и таблице и не обеспечивает плавное размещение динамического числа поставщиков. Вместо этого можно поместить все сведения о поставщиках в отдельную таблицу Vendors (поставщики) и связать товары с поставщиками с помощью кодов товаров или поставщиков с товарами с помощью кодов поставщиков.
Пример
| Student | Advisor | Adv-Room | Class1 | Class2 | Class3 |
|---|---|---|---|---|---|
| 1022 | Петров | 412 | 101-07 | 143-01 | 159-02 |
| 4123 | Иванов | 216 | 101-07 | 143-01 | 179-04 |
Таблицы должны иметь только два измерения. Так как один студент изучает несколько курсов, эти курсы следует указать в отдельной таблице. Наличие полей Class1, Class2 и Class3 в приведенных выше записях свидетельствует о неудачном проектировании таблицы. Вместо этого создайте другую таблицу в первой нормальной форме, исключив повторяющуюся группу (Class), как показано в следующем примере:
| Student | Advisor | Adv-Room | Class |
|---|---|---|---|
| 1022 | Петров | 412 | 101-07 |
| 1022 | Петров | 412 | 143-01 |
| 1022 | Петров | 412 | 159-02 |
| 4123 | Иванов | 216 | 101-07 |
| 4123 | Иванов | 216 | 143-01 |
| 4123 | Иванов | 216 | 179-04 |
Обратите внимание на несколько значений Class для каждого значения Student в таблице выше. Class функционально не зависит от Student (первичного ключа), поэтому эта связь не является второй нормальной.
В следующей таблице представлена вторая нормальная форма:
Таблица Students:
| Student | Advisor | Adv-Room |
|---|---|---|
| 1022 | Петров | 412 |
| 4123 | Иванов | 216 |
Таблица Registration:
| Student | Class |
|---|---|
| 1022 | 101-07 |
| 1022 | 143-01 |
| 1022 | 159-02 |
| 4123 | 101-07 |
| 4123 | 143-01 |
| 4123 | 179-04 |
То есть:
Записи не должны зависеть от чего-либо, кроме первичного ключа таблицы (составного ключа, если это необходимо). Возьмем для примера адрес клиента в системе бухгалтерского учета. Этот адрес необходим не только таблице Customers, но и таблицам Orders, Shipping, Invoices, Accounts Receivable и Collections. Вместо того чтобы хранить адрес клиента как отдельный элемент в каждой из этих таблиц, храните его в одном месте: или в таблице Customers, или в отдельной таблице Addresses.
Значения в записи, которые не являются частью ключа этой записи, не принадлежат в таблице. Если содержимое группы полей может относиться более чем к одной записи в таблице, попробуйте поместить эти поля в отдельную таблицу.
Например, в таблицу Employee Recruitment (наем сотрудников) можно включить адрес кандидата и название университета, в котором он получил образование. Однако для организации групповой почтовой рассылки необходим полный список университетов. Если сведения об университетах будут храниться в таблице Candidates, составить список университетов при отсутствии кандидатов не получится. Таким образом, создайте вместо этого отдельную таблицу Universities и свяжите ее с таблицей Candidates при помощи ключа — кода университета.
В последнем примере значения Adv-Room (номер кабинета научного руководителя) функционально зависят от атрибута Advisor. Решить эту проблему можно, переместив данный атрибут из таблицы Students в таблицу Faculty (факультет):
Таблица Students:
| Student | Advisor |
|---|---|
| 1022 | Петров |
| 4123 | Иванов |
Таблица Faculty:
| Имя | Room | Dept |
|---|---|---|
| Петров | 412 | 42 |
| Иванов | 216 | 42 |
Выполнять нормализацию до третьей нормальной формы может быть целесообразно только для часто изменяемых данных. Если при этом сохранятся зависимые поля, спроектируйте приложение так, чтобы при изменении одного из этих полей пользователь должен был проверить все связанные поля.