Правила технической нормализации

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

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

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

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

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

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

Правило 1. Нормализация связи один — к — одному

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

image126

Рис. 2.86. Пример связи один — к — одному, не требующей нормализации

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

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

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

image127

Рис. 2.87. Пример связи один — к — одному, требующей нормализации


Если между двумя сущностями установлена связь один — к — одному (1:1), формирующая полностью совпадающие первичные ключи в обеих сущностях, то такие сущности могут быть объединены в единую сущность с перенесением всех атрибутов обеих сущностей, а исходные сущности удалены.

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

image128

Рис. 2.88. Результат нормализации связи один — к — одному


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

Правило 2. Нормализация связи многие — ко — многим

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

image129

Рис. 2.89. Пример связи многие — ко — многим


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

Если между двумя сущностями установлена связь многие — ко — многим (№М), то создается новая сущность, где ключевые атрибуты исходных сущностей объединяются в сцепленный первичный ключ, связь между исходными сущностями разрывается, а создается идентифицирующая связь один — ко — многим (1 :ДГ) от исходных сущностей к новой сущности.

Это правило требует от разработчика выполнить несколько операций (рис. 2.90).

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

image130

Рис.2.90. Результат нормализации связи многие — ко — многим


Как очевидно из примера, теперь есть возможность добавить атрибут "Цена товара" в соответствии с требованиями предметной области. Однако, это требование логической нормализации, а в случае технического подхода сущности-связки не обладают дополнительными атрибутами, обеспечивая реализацию многозначной зависимостью двух и более сущностей. Правило 3. Нормализация многозначной зависимости Вариант многозначной зависимости, когда одна сущность многозначно зависит от нескольких других сущностей, встречается в базах данных довольно часто (рис. 2.91). По сути, эта модель отражает исходные структуры для применения нормализации по правилу для четвертой нормальной формы.

image131

Рис. 2.91. Пример многозначной зависимости сущностей


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

Если между сущностями установлена связь многие — ко — многим (№.М), при этом одна из сущностей является детерминантом или зависимой от всех других сущностей, т.е. сформирована многозначная зависимость, то для каждой пары сущностей составляется новая сущность-связка, связи многие — ко — многим удаляются, а между каждой парой детерминанта и зависимой сущностью с сущностью-связкой устанавливается идентифицирующая связь один — ко — многим (1:М), формируя в сущности-связке сцепленный первичный ключ, состоящий из первичных ключей детерминанта и зависимой исходной сущности.

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

независимости категории и поставщика, а модель отношений формирует четвертую нормальную форму.

image132

Рис. 2.92. Результат нормализации многозначной зависимости

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

image133

Рис. 2.93. Многозначная зависимость между несколькими сущностями

Предположим, что в рамках моделирования были выделены сущности "Заказы", "Товары" и "Поставщики". При этом каждая сущность обладает собственным уникальным набором вспомогательных атрибутов, зависимых только от имеющегося в сущности первичного ключа. С учетом особенности данных, которые были проанализированы, все сущности с каждой другой сущностью связаны связью многие — ко — многим. Поскольку на текущий момент не рассматривается наличие атрибутов, характеризующих товар поставщика в конкретном заказе, то никаких других сущностей, связывающих эти три объекта предметной области, в модели базы данных не присутствует.

Если между исследуемыми сущностями попарно установлены связи многие — ко — многим (ЛГ:М), образуя многозначную зависимость соединения, то выделяется новая сущность-связка, атрибутивный состав которой формируется из первичных ключей исходных сущностей, имеющиеся связи многие — ко — многим уничтожаются, а между исходными сущностями и сущностью-связкой устанавливается идентифицирующая связь один — ко — многим (1:Л/).

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

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

image134

Рис. 2.94. Результат нормализации многозначной зависимости


Правило 5. Нормализация проекции

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

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

image135

Рис. 2.95. Пример сущности и ее проекции

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

Важно отметить, что правило никоим образом не конкретизирует необходимость точного совпадения не только наименования и смысла атрибутов, но и типов идентичных атрибутов. Здесь возникает некоторое правило, заключающееся в том, что априори считается точное совпадение смысла и наименований идентичных атрибутов, а типы данных должны быть приводимыми, т.е. должна существовать простая возможность перевода значения атрибута одного типа в аналогичный атрибут другого типа или с другими характеристиками без потери данных. Например, если атрибут "ИНН" в одной сущности будет представлен типом CHAR(5), а в другой — типом INTEGER, то преобразование из CHAR в INTEGER будет проблематичным, поскольку символьно представленное число с ведущими нулями (00712) будет представлено числом без ведущих нулей (712), а это может привести к неточности представления данных, сортировки и корректности обработки. В тоже время, обратное преобразование из INTEGER в CIIAR(5) также может привести к потере данных, если число состоит более чем из пяти цифр. Это преобразование выполнит обрезание полученной строки до необходимого количества символов.

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

В итоге применения правила нормализации проекции нужно учитывать некоторые дополнительные условия и правила:

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

Правило 6. Нормализация проекции ключей

В процессе нормализации формируется много сущностей-связок, многие из которых являются проекциями других сущностей-связок (рис. 2.96).

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

image136

Рис. 2.96. Пример наличия сущности-проекции


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

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

Это более жесткое правило, нежели правило, долгое время применяемое в нормализации отношений, но оно позволяет полностью исключить ано-


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

image137

Рис. 2.97. Результат нормализации по менее жесткому правилу


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

image138

Рис. 2.98. Результат нормализации по более жесткому правилу



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

Правило 7. Нормализация ключевых блоков

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

Представим, что в рассматриваемой предметной области модель содержит две сущности "Поставщики товаров" и "Заказ товаров", связанные друг с другом таким образом, что сущность "Поставщики товаров" является детерминантом, т.е. родительской сущностью. Такое представление модели обладает существенными аномалиями обновления (рис. 2.99).

image139

Рис. 2.99. Пример ненормализованной зависимости


Аномалия добавления. При попытке добавить новую запись в отношение "Заказ товаров" обязательно необходимо внести сведения в отношение "Поставщик товаров", что требует, во-первых, строгой последовательности внесения данных в сущности, во-вторых, корректного указания значений ключевых атрибутов в зависимой (дочерней) сущности в соответствии с данными, которые будут использованы для внесения данных в родительскую сущность, в-третьих, необходимо контролировать существование записи в родительской сущности и ее нсдобавление, если она имеется.

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

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

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

image140

Рис. 2.100. Результат нормализации ключей


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

Правила логической нормализации

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

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

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

Правило 1. Нормализация классификации

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

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

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

Если сущность (отношение) имеет атрибут, содержащий повторяющуюся мало изменяемую или неизменяемую в исторической перспективе совокупность значений, является логической характеристикой экземпляра сущности (отношения), т.е. формирует функциональную зависимость от ключевого атрибута сущности (отношения), то такой атрибут выделяется в новую сущность (отношение) с созданием суррогатного ключа, представлением выявленного атрибута классификации и установлением не идентифицирующей связи один — ко — многим (1:Л0 от сущности-классификатора к исходной сущности (отношению).

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

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

"Организационно-правовая форма" (рис. 2.101). Этот атрибут отвечает следующим условиям:

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

image141

Рис. 2.101. Пример сущности атрибута классификации


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

image142

Рис. 2.102. Результат нормализации классификации


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

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

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

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

image143

Рис. 2.103. Пример сущности с множественными данными


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

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

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

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

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

Итогом нормализации стало появление сущности "Заказ" с представленными в нем атрибутами, формирующими его классификационное наполнение, и добавлением атрибута, который может рассматриваться в качестве ключевого (рис. 2.104). Однако этот атрибут, в случае его символьного типа, возможно, нецелесообразно использовать в качестве первичного, тогда для первичного ключа ищется атрибут предметной области. Если в предметной области не существует ключевого атрибута или его нецелесообразно использовать из-за того, что с ним никто не работает, то может быть создан суррогатный ключ числового типа, который позволит обеспечить ссылочную целостность после установления связи с исходной сущностью.

image144

Рис. 2.104. Результат нормализации множественных данных


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

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

image145

Рис. 2.105. Пример сущности с многозначной зависимостью


Предположим, что в сущности "Товары заказа" есть атрибут "Количество", функционально зависимый от детерминанта, представленного сцепкой атрибутов "Заказ" и "Товар", связанных многозначной зависимостью, т.е. между ними может быть установлена связь многие — ко — многим (рис. 2.106).

image146

Рис. 2.106. Тип связи между заказом и товаром


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

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

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

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

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

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

image147

Рис. 2.107. Результат нормализации многозначной зависимости


 
< Пред   СОДЕРЖАНИЕ     След >