Нормализация модели. 
Базы данных: проектирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис 4.10. Нормализация связи заказа с его стоимостью В итоге все атрибуты сущности «Стоимость заказа» будут перемещены в сущность «Заказ», а сама сущность «Стоимость заказа» будет удалена, но причине отсутствия в ней атрибутов и передачи всех свойств в сущность «Заказ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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