Нормализация модели

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

Анализ связь 1:1. Наиболее простая нормализация выполняется по связи 1:1, поскольку обычно такая связь нормализуется по единственному правилу — объединение в единую сущность (рис. 4.3).

image214

Рис. 43. Выявленная связь 1:1


В рассматриваемом примере имеется только одна связь один — к — одному (1:1) — это связь между разными видами представления стоимости заказа. Учитывая особое условие этой связи — однозначное соответствие с обязательным присутствием обоих значений, применив правило нормализации, получаем, что оба типа связи должны быть объединены, а атрибуты представлены в рамках новой сущности (рис. 4.4).


Обоснование установления типов связей

Типы сущностей

Тип связи/Обоснование

Стоимость

заказа

Символьная

стоимость

заказа

/ ^ _______________________ / Сим воль-

  • ( Стоимость 4 , (
  • 1:1 1 пая стоимость )

заказа / V /

заказа

Прямая связь

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

Номер

заказа

Клиент

(^Ншщр заказа^^ | 1:Л^ | иепт^^^

Прямая связь

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

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




Типы сущностей

Тип связи/Обоснование

Номер

заказа

І Іомер товара

заказа4^ ЛГ:Л/ ^^^^Номер товара^

Косвенная связь

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

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

Номер

заказа

Наименование товара

/ ,, чг., ( Наименование

( Номер заказа ) Л.А/ 1 )

V / -------------------------------------- V товара У

Прямая связь

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



Типы сущностей

Тип связи/Обоснование

І іаименова- ние товара

І Ієна товара

  • ( Наименование . хг ( тт Л
  • 1 :Дг (І Ієна товара

V товара У --------------------------- Ч 1 /

Прямая связь

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

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

Номер

заказа

Дата заказа

(^Номер заказа^ 1:ЛҐ (^Дата заказа^^

Прямая связь

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


Типы сущностей

Тип связи/Обоснование

Стоимость

товара

Количество

товара

( Стоимость Л ( Количество Л V товара / V товара у

Прямая связь

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

Стоимость

заказа

Стоимость

товара

/ Стоимость ( Стоимость

V заказа у —-— V товара у

Косвенная связь

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



image215

Рис. 4.4. Результат нормализации связи 1:1


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

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

Атрибут и соответствующий ему тип сущности "Дата заказа" имеет с ключевым типом сущности единый объект приложения, поэтому сначала рассмотрим эту связь (рис. 4.5). Между номером заказа и датой заказа установлена связь один — ко — многим (1:ДО), и, казалось бы, ничего делать не нужно, но дата является характеристическим атрибутом конкретного заказа, при этом множественность связи направлена на ключевой тип сущности, что говорит о возможной дублируемости именно даты заказа, а не его номера.

image216

Рис. 4.5. Связь между номером и датой заказа


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

image217

Рис. 4.6. Результат нормализации номера и даты заказа


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

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

image218

Рис. 4.7. Связь между заказом и клиентом


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

image219

Рис. 4.8. Нормализованная связь между заказом и клиентом


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

щих итерациях нормализации или, если возникнет такая ситуация, в процессе рассмотрения соответствующих документов. В рассматриваемом примере исследование документов "Счет", "Счет-фактура", "Товарная накладная" и др. приведет к необходимости создания сущности-категории "Организация" и, как следствие, сущности-категории "Физическое лицо".

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

image220

Рис. 4.9. Добавление категоризации при последующем рассмотрении

Интересная ситуация складывается но связи "Номер заказа" и "Стоимость заказа". Оба типа сущностей были преобразованы в сущности "Заказ" и "Стоимость заказа" соответственно. Это преобразование совершенно никак не отразилось на установленной ранее связи между типами сущностей, поскольку обе сущности приобрели свойства исходных типов сущностей. Установленный тин связи один — ко — многим, аналогично варианту рассмотрения связи между номером и датой заказа, приводит к необходимости объединения этих сущностей (рис. 4.10).

image221

Рис 4.10. Нормализация связи заказа с его стоимостью

В итоге все атрибуты сущности "Стоимость заказа" будут перемещены в сущность "Заказ", а сама сущность "Стоимость заказа" будет удалена

но причине отсутствия в ней атрибутов и передачи всех свойств в сущность "Заказ.

Последняя прямая связь сущности "Заказ" с другими сущностями осталась только с типом сущности "Товар" (рис. 4.11). Эта связь имеет тип многие — ко — многим, что, согласно правилам нормализации, должно привести к возникновению сущности-связки.

image222

Рис. 4.11. Связь между заказом и товаром


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

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

image223

Рис. 4.12. Нормализация связи заказа с товаром


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

На предыдущем этапе связь многие — ко — многим можно было не нор- мализовывать, поскольку на тот момент неизвестно было, насколько необ-

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

image224

Рис. 4.13. Нормализация связи товара с ценой

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

image225

Рис. 4.14. Результат нормализации связи цены товара с сущностью "Товар"


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

image226

Рис. 4.15. Результат нормализации номера и количества товара


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

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

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

image227

Рис. 4.16. Установление связи между стоимостью товара и связанными сущностями


image228

Рис. 4.17. Модель базы данных по итогам первой итерации


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

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

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

image229

Рис. 4.18. Нормализованная модель базы данных


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

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