Описание основных принципов нормализации баз данных

рТПЙУИПЦДЕОЙЕ Й ОБЪОБЮЕОЙЕ ОПТНБМШОЩИ ЖПТН

рПОСФЙЕ ОПТНБМШОПК ЖПТНЩ ВЩМП ЧЧЕДЕОП ьДЗБТПН лПДДПН РТЙ УПЪДБОЙЙ ТЕМСГЙПООПК НПДЕМЙ вд. пУОПЧОПЕ ОБЪОБЮЕОЙЕ ОПТНБМШОЩИ ЖПТН — РТЙЧЕДЕОЙЕ УФТХЛФХТЩ ВБЪЩ ДБООЩИ Л ЧЙДХ, ПВЕУРЕЮЙЧБАЭЕНХ НЙОЙНБМШОХА ЙЪВЩФПЮОПУФШ. хУФТБОЕОЙЕ ЙЪВЩФПЮОПУФЙ РТПЙЪЧПДЙФУС ЪБ УЮЈФ ДЕЛПНРПЪЙГЙЙ ПФОПЫЕОЙК (ФБВМЙГ) ФБЛЙН ПВТБЪПН, ЮФПВЩ Ч ЛБЦДПН ПФОПЫЕОЙЙ ИТБОЙМЙУШ ФПМШЛП РЕТЧЙЮОЩЕ ЖБЛФЩ (ФП ЕУФШ ЖБЛФЩ, ОЕ ЧЩЧПДЙНЩЕ ЙЪ ДТХЗЙИ ИТБОЙНЩИ ЖБЛФПЧ). фБЛЙН ПВТБЪПН, ОПТНБМЙЪБГЙС ОЕ ЙНЕЕФ ГЕМША ХНЕОШЫЕОЙЕ ЙМЙ ХЧЕМЙЮЕОЙЕ РТПЙЪЧПДЙФЕМШОПУФЙ ТБВПФЩ ЙМЙ ЦЕ ХНЕОШЫЕОЙЕ ЙМЙ ХЧЕМЙЮЕОЙЕ ПВЯЈНБ вд. лПОЕЮОПК ГЕМША ОПТНБМЙЪБГЙЙ СЧМСЕФУС ХНЕОШЫЕОЙЕ РПФЕОГЙБМШОПК РТПФЙЧПТЕЮЙЧПУФЙ ИТБОЙНПК Ч вд ЙОЖПТНБГЙЙ.

Описание нормализации

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

Избыточные данные отнимают место на диске и создают проблемы с обслуживанием. Если необходимо изменить данные, которые находятся в нескольких местах, их необходимо изменить точно так же, как во всех местах. Изменение адресов клиентов значительно упрощается, если эти данные хранятся только в таблице Customers, а не в базе данных.

Что такое «несогласованная зависимость»? В отличие от того, что пользователь может искать в таблице Customers по адресу определенного клиента, может не иметь смысла искать зарплаты сотрудников, обращающихся к этому клиенту. Зарплата сотрудника связана с сотрудником или зависит от него, поэтому его следует переместить в таблицу Employees (сотрудники). Несогласованные зависимости могут усложнить доступ к данным, так как путь для поиска данных может отсутствовать или быть нарушен.

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

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

В приведенных ниже описаниях приведены примеры.

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

Условием этой формы является отсутствие зависимости неключевых полей от части составного ключа.

Так как составной ключ в учебной базе наблюдается только в таблице «Сотрудники_Линии», то рассмотрим пример на ней.

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

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

Если соблюдены правила первой нормальной формы, то создание таблицы «Линии» и перенос в нее зависимых столбцов удовлетворяет второй нормальной форме.

Первая нормальная форма

Основным правилом первой формы является необходимость неделимости значения в каждом поле (столбце) строки – атомарность значений.

Рассмотрим таблицы сотрудников и телефонных линий.

Чтобы избавиться от связывающей таблицы «Сотрудники_Линии», мы могли бы записать идентификаторы сотрудников для каждой линии в виде перечня в дополнительном столбце:

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

Организации структуры таблиц с применением дополнительной связывающей избавляет от подобных проблем.

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

• Строки таблиц не должны зависеть друг от друга, т.е. первая запись не должна влиять на вторую и наоборот, вторая на третью и т.д. Размещение записей в таблице не имеет никакого значения.
• Аналогичная ситуация со столбцами записей. Их порядок не должен влиять на понимание информации.
• Каждая строка должна быть уникальна, поэтому для нее определяется первичный ключ, состоящий из одного либо нескольких полей (составной ключ). Первичный ключ не может повторяться в пределах таблицы и служит идентификатором записи.

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

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

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

ИСКЛЮЧЕНИЕ: следование третьей нормальной форме, хотя теоретически желательно, не всегда практично. Если у вас есть таблица Customers и вы хотите устранить все возможные зависимости между полями, необходимо создать отдельные таблицы для городов, почтовых индексов, торговых представителей, классов клиентов и других факторов, которые могут дублироваться в нескольких записях. Теоретически, нормализация стоит пурсинг. Тем не менее, многие небольшие таблицы могут понизить производительность или превышать количество файлов и емкости памяти.

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

Определение

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

В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение.

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

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

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