Нормализация моделей
Как правило, объектный подход приводит к формированию нормализованной модели базы данных до третьей нормальной формы или выше, и поВперед нормализация не требуется. Тем не менее, модель необходимо проверить на корректность ее представления в соответствии с анализом предметной области, выявлением некоторых аномалий и их разрешения. Из предыдущих примеров осталось три ситуации, которые не позволяют говорить о точном соответствии модели базы данных с предметной областью.
Первая ситуация заключается в том, что сущность "Клиент", с учетом разделения клиентов на физических лиц и организации, не была рассмотрена и корректным образом смоделирована. Конечно, если бы на предыдущих этапах были рассмотрены все функции предметной области, то разработчик мог получить три варианта решения.
1. Нормализованная модель клиента с разделением на два вида с применением связи категоризации, что не потребует дальнейшей нормализации.
2. Модель с наличием классификатора "Тип клиента", связанного с сущностью "Клиент", но различные характеристические атрибуты в зависимости от типа клиента приведут к необходимости нормализации.
3. Модель, где в сущности "Заказ" появится три атрибута "ИДФ клиент" от трех разных сущностей — "Клиент", "Физическое лицо" и "Организация", что потребует дополнительной нормализации.
Вторая ситуация отражается в необходимости вычисления стоимости позиции товара, используя атрибуты "Цена товара" и "Количество". Эти атрибуты размещены в разных сущностях, и автоматический расчет по формуле будет невозможен без использования специальных механизмов автоматической обработки данных (триггеры).
Третья ситуация требует, в соответствии с рассмотрением документа "Заказ", упорядочивания списка товаров в каждом заказе. Данное условие возникает из документа, но в предметной области может быть допущение, которое не будет требовать обязательного упорядочивания товаров в заказе ввиду отсутствия такой необходимости. Тогда эта ситуация не будет требовать никакого исправления, что и будет сделано в данном примере.
Нормализация сущности "Клиент". По требованиям предметной области клиентами магазина могут быть физические лица и организации, характеризующиеся различными атрибутами. Предположим, что данная
|
сущность ранее не рассматривалась, и нормализация требует корректного представления этой сущности (рис. 4.33).
Рис. 4.УЗ. Исходная сущность "Клиент" |
Указанный атрибут "Наименование клиента" является не совсем корректным, хотя и сформирован на основе анализа документа "Заказ", но рассмотрение других документов и понимание различий разных клиентов требуют более глубокого рассмотрения этой сущности, что приводит к расширению ее атрибутивного состава.
Заменив атрибут "Наименование клиента" на два атрибута — "Физическое лицо" и "Организация", — сформировали указание на возможное существование двух различных типов клиентов, что потребует разделения, поскольку каждый из вариантов является самостоятельным структурным элементом (рис. 4.34).
|
Рис. 434. Модифицированное отношение "Клиент" |
Еще стоит обратить внимание на одно свойство, которое также требует нормализации сущности, — это возможность хранения пустого значения (табл. 4.18). Поскольку клиент не может быть одновременно физическим лицом и организацией[1], то один из атрибутов должен иметь возможность хранить пустое значение, но выявить, какой это должен быть атрибут, невозможно, поэтому указанное свойство устанавливается на оба атрибута, что приводит к ситуации, когда клиент будет создан, а его данные не будут определены, что невозможно ввиду необходимости указания наименования клиента в документах.
Таблица 4.18
|
Описание сущности "Клиент"
|
Чтобы понимать, к какому типу относится каждый конкретный клиент, можно добавить техническую сущность, не ассоциированную с объектами предметной области, с названием "Тип клиента" (рис. 4.35).
|
Рис. 435. Добавление сущности "Тип клиента" |
Добавление этой сущности не является обязательным и основывается на необходимости указания в документе значения типа клиента. Если указывать его не требуется, то наличие такой сущности не будет обязательным. Тем более, что ее наличие никаким образом не влияет на возможности работы запросов выборки, с учетом того, что клиент будет разделен на дополнительные две сущности с собственными атрибутами.
Дальнейшее рассмотрение структурных атрибутов требует провести выделение этих элементов в самостоятельные сущности, исключая необходимость хранить много пустых значений по атрибутам соответствующих структурных элементов и позволяя разрешить некоторые аномалии обновления, которые были ранее рассмотрены в части одновременного отсутствия данных по обоим типам клиентов.
В результате нормализации были выделены две сущности-категории (рис. 4.36), соответствующие типам организации, с определением совокупности атрибутов, которыми они характеризуются. Эти сущности могли быть выделены при рассмотрении функций предметной области, и их соединение с сущностью "Клиент" могло быть оптимизационным действием, разрешая проблему существования связи сущности "Заказ" с тремя сущностями, описывающими клиентов.
|
Рис. 436. Выделение сущностей-категорий |
В ходе применения различных правил нормализации (рис. 4.37) для сущности "Клиент" и ее производных сущностей-категорий "Физи-
чсское лицо" и "Организация" были сформированы производные сущности — "Организационно-правовая форма" и "Банк", — структурное наполнение которых определено, исходя из анализа предметной области и атрибутивного состава документов, где применяются соответствующие значения.
|
Рис. 437. Нормализованная модель клиента |
Особо стоит обратить внимание на ключевые атрибуты (табл. 4.19). При рассмотрении классификаторов и сущностей модели было выявлено много альтернативных ключей с различными правилами организации уникальности значений. Поскольку уникальность значений определена на уровне каждого атрибута, то сцепленные альтернативные ключи нецелесообразны.
Таблица 4.19
|
Описание ключевых групп
|
|
№ п/п |
Атрибут |
Тип ключа |
Тип данных |
Уникальность |
Дополнительно |
|
6 |
Организационно правовая форма. ИДФ организационно-правовой формы |
Первичный |
Ц(+0 |
Суррогатный |
|
|
7 |
Организационно-правовая форма. Наименование организационно правовой формы |
Альтернативный |
С (100) |
Индекс |
|
|
8 |
Организационно правовая форма. Код организационно-правовой формы |
То же |
С (2) |
Ограничение |
|
|
9 |
Банк. ИДФ банка |
Первичный |
Ц(+1) |
- |
Суррогатный |
|
10 |
Банк. Наименование банка |
Альтернативный |
С(150) |
Ограничение |
- |
|
11 |
Банк. БИК банка |
То же |
С (7) |
Индекс |
- |
|
12 |
Банк. Корреспондентский счет |
- " - |
С (25) |
Ограничение |
- |
|
13 |
Физическое лицо. ИДФ клиента |
Первичный/ Внешний |
ц |
- |
Суррогатный |
Как очевидно из таблицы, некоторые ключевые атрибуты представляются суррогатными, но не вычисляются автоматически, поскольку они являются производными от ключа сущности-общности, где уже реализуется авто вычисление значения первичного ключа. Именно поэтому в сущностях-категориях атрибуты обладают целочисленным типом без авто вычисления. Некоторые альтернативные ключи обладают различными правилами соблюдения уникальности. Объясняется это необходимостью выполнять операции поиска и сортировки данных но этим атрибутам. Такие атрибуты характеризуются проверкой уникальности на основе индексов.
В результате проведения всех нормализационных операций будет сформирована общая модель базы данных (рис. 4.38). Ввиду достаточно небольшой предметной области и рассмотренных функций общая модель представлена в приемлемо удобном виде.
Однако, как ранее говорилось, при наличии большого количества сущностей и сложной предметной области общая модель базы данных может быть достаточно объемной и сложной, что будет мешать ориентироваться в ней, соответственно данное неудобство разрешается с помощью функционализмами, которая была использована в рамках объектного подхода.
|
Рис. 4.38. Итоговая модель после нормализации |
