ОТНОШЕНИЯ

Что такое нормализация отношений

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

Office 365 ProPlus переименован в Майкрософт 365 корпоративные приложения. Для получения дополнительной информации об этом изменении прочитайте этот блог.

Исходный номер статьи базы знаний: 283878

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

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

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

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

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

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

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

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

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

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

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

Что происходит при добавлении третьего поставщика? Добавление поля не является ответом; для этого требуется изменение программ и таблиц, а также нестабильное динамическое количество поставщиков. Вместо этого разместите все сведения о поставщиках в отдельной таблице «поставщики», а затем свяжите запасы с поставщиками с ключом номера номенклатуры или поставщиками для запасов с ключом кода поставщика.

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

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

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

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

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

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

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

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

Другие формы нормализации

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

Нормализация примера таблицы

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

Учеников #ПомощникРасширенное пространствоКлассClass2Class3
1022Джонс412101-07143-01159-02
4123Кузнецов216201-01211-02214-01

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

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

Электронные таблицы часто используют третье измерение, но таблицы не должны. Другой способ просмотреть эту проблему — с отношением «один-ко-многим» не размещать одну сторону и сторону «многие» в одной и той же таблице. Вместо этого создайте другую таблицу в первой обычной форме, удалив повторяющуюся группу (class #), как показано ниже:

Учеников #ПомощникРасширенное пространствоКлассе #
1022Джонс412101-07
1022Джонс412143-01
1022Джонс412159-02
4123Кузнецов216201-01
4123Кузнецов216211-02
4123Кузнецов216214-01

Вторая нормальная форма: устранение избыточных данных

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

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

Учеников #ПомощникРасширенное пространство
1022Джонс412
4123Кузнецов216
Учеников #Классе #
1022101-07
1022143-01
1022159-02
4123201-01
4123211-02
4123214-01

Третья нормальная форма: исключите данные, не зависящие от ключа

В последнем примере функционально заданное место (номер Office помощника) функционально зависит от атрибута Advisor. Решение состоит в том, чтобы переместить этот атрибут из таблицы Students в таблицу факультет, как показано ниже:

Источник

Нормализация отношений в реляционных базах данных

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

Например, рассмотрим БД, состоящую из трех связанных таблиц:

СТУДЕНТ(номер зачетной книжки, Ф., И., О., дата рождения, группа), СЕССИЯ (номер зачётной книжки, оценка1, оценка2. оценка п, результаты сдачи сессии), СТИПЕНДИЯ(результаты сдачи сессии, размер стипендии).

Отношения студент и сессия имеют совпадающие ключи (номер зачетной книжки).

Рис. 4.5. Связывание таблиц через ключи

Таблица СЕССИЯ имеет первичный КЛЮЧ (номер зачетной книжки) и содержит внешний ключ (результаты сдачи сессии), который обеспечивает ее связь с таблицей стипендия (рис. 10.5).

В реляционных базах данных определены три типа связей:

• один к одному (1:1) – любая запись в первой таблице может быть связана только с одной записью второй таблицы и наоборот;

• один ко многим (1:М) – любая запись первой таблицы связана с несколькими записями второй, но любая запись во второй таблице связана только с одной записью первой таблицы;

• многие ко многим (М:М) – каждой записи первой таблицы соответствуют несколько записей второй и наоборот. В явном виде эта связь в реляционных БД не поддерживается, но имеются способы ее косвенной организации путем создания дополнительных таблиц.

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

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

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

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

Различают шесть нормальных форм:

1) 1НФ — первую нормальную форму;

2) 2НФ — вторую нормальную форму;

3) 3НФ — третью нормальную форму;

4) НФБК — нормальную форму Бойса –Кодда;

5) 4НФ — четвертую нормальную форму;

6) 5НФ — пятую нормальную форму.

Каждая нормальная форма определяет ограничения на данные:

• 1НФ, 2НФ, 3НФ – ограничивают зависимость не первичных атрибутов от ключей;

• НФБК – ограничивает зависимость первичных атрибутов;

• 4НФ – формирует ограничения на виды многозначных зависимостей;

• 5НФ – вводит другие типы зависимостей: зависимости соединения.

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

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

Преобразование отношений к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа. Например, отношение СТУДЕНТ (номер зачетной книжки, Ф., И., О., дата рождения, группа) находится в первой нормальной форме. Если бы поля Ф., И., О. были бы объединены в одно, то нормализация отношений состояла бы в фрагментации данного поля. Разработчики БД изначально строят так исходные отношения, чтобы они были в первой нормальной форме.

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

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

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

В случае составного ключа вводится понятие функционально полной зависимости. Функционально полная зависимость не ключевых полей заключается в том, что каждое не ключевое поле функционально зависит от ключа, но не зависит ни от какой части составного ключа. Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждое не ключевое поле функционально полно зависит от составного ключа. Так отношение студент находится во второй нормальной форме, т. к. его не ключевые поля функционально зависят от ключа номер зачетной книжки. Отношение сессия, имеющее составной ключ номер зачетной книжки + результаты сдачи сессии находится в первой нормальной форме, но не находится во второй, т.к. поля оценка1, оценка2. оценка n не находятся в полной функциональной зависимости от составного ключа, а лишь от его составной части. Для перевода этого отношения во вторую нормальную форму необходимо исключить из него поля оценка1, оценка2. оценка n, т. е. исходное отношение надо разбить на два связанных отношения РЕЗУЛЬТАТЫ (номер зачетной книжки, оценка1., оценка2. оценка п) И СЕССИЯ(номер зачетной книжки, результаты сдачи сессии). Связь между ними будет осуществляться по полю номер зачетной книжки (рис. 10.6)

Рис. 10.6. Вторая нормальная форма отношений

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

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

Для устранения транзитивной зависимости описательных полей необходимо произвести «расщепление» исходного информационного объекта. В результате такого расщепления часть полей удаляется из исходного объекта и включается в состав других, новых информационных объектов: СТУДЕНТ(номер зачетной книжки, Ф., И., О., дата рождения, группа), ГРУППА <группа, староста)(рис. 10.7).

Рис. 10.7. Исключение транзитивной зависимости

Источник

Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Закрыть