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

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

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

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

Цели нормализации за пределами 1NF (первая нормальная форма) были сформулированы Коддом следующим образом:

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

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

Аномалия обновления. Одна и та же информация может быть выражена в нескольких строках; поэтому обновления отношения могут привести к логическим несоответствиям. Например, каждая запись в отношении "Employees' Skills" может содержать идентификатор сотрудника, адрес сотрудника и навык; таким образом, изменение адреса для конкретного сотрудника может потребоваться применить к нескольким записям (по одной для каждого навыка). Если обновление выполнено только частично - адрес сотрудника обновляется в некоторых записях, но не в других - тогда отношение остается в несогласованном состоянии. В частности, отношение дает противоречивые ответы на вопрос, каков адрес этого конкретного сотрудника. Это явление известно как аномалия обновления.

Аномалия обновления. Employee 519 показан как имеющий разные адреса в разных записях.

Аномалия вставки. Существуют обстоятельства, при которых определенные факты не могут быть записаны вообще. Например, каждая запись в отношении "Faculty and Their Courses" может содержать идентификатор факультета, название факультета, дату приема на работу и код курса. Поэтому мы можем записать данные любого преподавателя, который преподает хотя бы один курс, но мы не можем записать вновь нанятого преподавателя, которому еще не было назначено преподавать какие-либо курсы, кроме как путем установки кода курса на ноль. Это явление известно как аномалия вставки.

Аномалия вставки. Пока новый преподаватель, Dr. Newsome, не назначен для преподавания хотя бы одного курса, его или ее данные не могут быть записаны.

Аномалия удаления. При определенных обстоятельствах удаление данных, представляющих определенные факты, требует удаления данных, представляющих совершенно разные факты. Отношение "Faculty and Their Courses", описанное в предыдущем примере, страдает этим типом аномалии, поскольку если преподаватель временно прекращает назначаться на какие-либо курсы, мы должны эффективно удалить последнюю из записей, на которых этот преподаватель появляется также удаляя преподавателя, если мы не установили код курса на ноль. Это явление известно как аномалия удаления.

Аномалия удаления. Вся информация о Dr. Giddens теряется, если он или она временно перестает назначаться на какие-либо курсы.

Минимизировать редизайн при расширении структуры базы данных

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

Нормализованные отношения и отношения между одним нормализованным отношением отражают концепции реального мира и их взаимосвязи.

Пример

Запрос и манипулирование данными в ненастроенной структуре данных, такой как следующее представление транзакций по кредитным картам клиентов, не относящихся к 1NF, включает в себя большую сложность, чем это действительно необходимо:

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

Распаковка групп транзакций одного или нескольких клиентов, позволяющая исследовать отдельные транзакции в группе
Вывод результата запроса на основе результатов первого этапа

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

Одним из важных выводов Кодда было то, что структурная сложность может быть уменьшена. Снижение структурной сложности дает пользователям, приложениям и СУБД больше возможностей и гибкости для формулирования и оценки запросов. Более нормализованный эквивалент приведенной выше структуры может выглядеть так:

В измененной структуре ключом является {Cust. ID} в первом отношении, {Cust. ID, Tr ID} во втором отношении.

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

Поиск по этому блогу

Alex tools