Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Нормалізація моделей

Як правило, об'єктний підхід призводить до формування нормализованной моделі бази даних до третьої нормальної форми або вище, і подальша нормалізація не потрібно. Проте, модель необхідно перевірити на коректність її подання відповідно до аналізу предметної області, виявленням деяких аномалій і їх дозволу. З попередніх прикладів залишилося три ситуації, які не дозволяють говорити про точну відповідність моделі бази даних з предметною областю.

Перша ситуація полягає в тому, що сутність "Клієнт", з урахуванням поділу клієнтів на фізичних осіб і організації, які було розглянуто і коректним чином змодельована. Звичайно, якби на попередніх етапах були розглянуті всі функції предметної області, то розробник міг отримати три варіанти вирішення.

  • 1. Нормалізована модель клієнта з поділом на два види із застосуванням зв'язку категоризації, що не потребує подальшої нормалізації.
  • 2. Модель з наявністю класифікатора "Тип клієнта", пов'язаної з суттю "Клієнт", але різні характеристичні атрибути в залежності від типу клієнта приведуть до необхідності нормалізації.
  • 3. Модель, де по суті "Замовлення" з'явиться три атрибута "ІДФ клієнт" від трьох різних сутностей - "Клієнт", "Фізична особа" і "Організація", що потребують додаткової нормалізації.

Друга ситуація відбивається в необхідності обчислення вартості позиції товару, використовуючи атрибути "Ціна товару" і "Кількість". Ці атрибути розміщені в різних сутності, і автоматичний розрахунок по формулі буде неможливий без використання спеціальних механізмів автоматичної обробки даних (тригери).

Третя ситуація вимагає, відповідно до розглядом документа "Замовлення", упорядкування списку товарів в кожному замовленні. Дана умова виникає з документа, але в предметної області може бути припущення, яке не вимагатиме обов'язкового упорядкування товарів в замовленні через відсутність такої необхідності. Тоді ця ситуація не буде вимагати ніякого виправлення, що і буде зроблено в даному прикладі.

Нормалізація суті "Клієнт". За вимогами предметної області клієнтами магазину можуть бути фізичні особи та організації, які характеризуються різними атрибутами. Припустимо, що дана

сутність раніше не розглядалася, і нормалізація вимагає коректного подання цієї сутності (рис. 4.33).

image244

Мал. 4.УЗ. Вихідна сутність "Клієнт"


Зазначений атрибут "Найменування клієнта" є не зовсім коректним, хоча і сформований на основі аналізу документа "Замовлення", але розгляд інших документів і розуміння відмінностей різних клієнтів вимагають більш глибокого розгляду цієї сутності, що призводить до розширення її атрибутивного складу.

Замінивши атрибут "Найменування клієнта" на два атрибути - "Фізична особа" і "Організація", - сформували вказівку на можливе існування двох різних типів клієнтів, що потребують поділу, оскільки кожен з варіантів є самостійним структурним елементом (рис. 4.34).

image245

Мал. 434. Модифіковане відношення "Клієнт"


Ще варто звернути увагу на одну властивість, яка також вимагає нормалізації суті, - це можливість зберігання порожнього значення (табл. 4.18). Оскільки клієнт не може бути одночасно фізичною особою та організацією [1] , то один з атрибутів повинен мати можливість зберігати порожнє значення, але виявити, який це має бути атрибут, неможливо, тому вказане властивість встановлюється на обидва атрибути, що призводить до ситуації, коли клієнт буде створений, а його дані не будуть визначені, що неможливо з огляду на необхідність зазначення найменування клієнта в документах.

Таблиця 4.18

Опис суті "Клієнт"

п / п

сутність

Атрибут

Тип даних

алгоритм

замовчування

обмеження

NULL

1

клієнт

ІДФ клієнта

Ц

-

-

> 0

-

2

Фізична особа

структурний

-

-

-

Про

3

організація

те ж

-

-

-

про



Щоб розуміти, до якого типу належить кожен конкретний клієнт, можна додати технічну сутність, не пов'язану з об'єктами предметної області, з назвою "Тип клієнта" (рис. 4.35).

image246

Мал. 435. Додавання суті "Тип клієнта"


Додавання цієї суті не є обов'язковим і ґрунтується на необхідності вказівки в документі значення типу клієнта. Якщо вказувати його не потрібно, то наявність такої суті не буде обов'язковим. Тим більше, що її наявність жодним чином не впливає на можливості роботи запитів вибірки, з урахуванням того, що клієнт буде розділений на додаткові дві сутності з власними атрибутами.

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

В результаті нормалізації були виділені дві сутності-категорії (рис. 4.36), які відповідають типам організації, з визначенням сукупності атрибутів, якими вони характеризуються. Ці сутності могли бути виділені при розгляді функцій предметної області, і їх з'єднання з сутністю "Клієнт" могло бути оптимизационним дією, вирішуючи проблему існування зв'язку сутності "Замовлення" з трьома сутностями, що описують клієнтів.

image247

Мал. 436. Виділення сутностей-категорій


В ході застосування різних правил нормалізації (рис. 4.37) для сутності "Клієнт" і її похідних сутностей-категорій "фізичним

чсское особа "і" Організація "були сформовані похідні суті -" Організаційно-правова форма "і" Банк ", - структурний наповнення яких визначено, виходячи з аналізу предметної області та атрибутивного складу документів, де застосовуються відповідні значення.

image248

Мал. 437. Нормалізована модель клієнта


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

Таблиця 4.19

Опис ключових груп

п / п

Атрибут

Тип ключа

Тип

даних

унікальність

додатково

1

Організація. ІДФ клієнта

Первинний /

зовнішній

ц

-

сурогатний

2

Організація. Найменування організації

альтернативний

С (150)

індекс

-

3

Організація. Розрахунковий рахунок

те ж

З (25)

обмеження

-

4

Організація. ІДФ організаційно-правової форми

зовнішній

ц

-

-

5

Організація. ІДФ банку

те ж

ц

-

-




п / п

Атрибут

Тип ключа

Тип

даних

унікальність

додатково

6

Організаційно-правова форма. ІДФ організаційно-правової форми

Первинний

Ц (+0

сурогатний

7

Організаційно-правова форма. Найменування організаційно правової форми

альтернативний

С (100)

індекс

8

Організаційно-правова форма. Код організаційно-правової форми

те ж

З (2)

обмеження

9

Банк. ІДФ банку

Первинний

Ц (+1)

-

сурогатний

10

Банк. Назва банку

альтернативний

С (150)

обмеження

-

11

Банк. БИК банку

те ж

З (7)

індекс

-

12

Банк. Кореспондентський рахунок

- "-

З (25)

обмеження

-

13

Фізична особа. ІДФ клієнта

Первинний /

зовнішній

ц

-

сурогатний


Як очевидно з таблиці, деякі ключові атрибути представляються сурогатними, але не обчислюються автоматично, оскільки вони є похідними від ключа сутності-спільності, де вже реалізується авто обчислення значення первинного ключа. Саме тому в сутності-категоріях атрибути мають цілочисельним типом без авто обчислення. Деякі альтернативні ключі мають різні правилами дотримання унікальності. Пояснюється це необхідністю виконувати операції пошуку і сортування даних але цим атрибутам. Такі атрибути характеризуються перевіркою унікальності на основі індексів.

В результаті проведення всіх нормалізаційне операцій буде сформована загальна модель бази даних (рис. 4.38). З огляду на досить невеликий предметної області і розглянутих функцій загальна модель представлена ​​в прийнятно зручному вигляді.

Однак, як вже зазначалося, при наявності великої кількості сутностей і складної предметної області загальна модель бази даних може бути досить об'ємною і складною, що буде заважати орієнтуватися в ній, відповідно дане незручність дозволяється за допомогою функціоналізму, яка була використана в рамках об'єктного підходу.


image249

Мал. 4.38. Підсумкова модель після нормалізації



  • [1] У Росії є форма ведення бізнес-діяльності в вигляді індивідуального підприємця, яким є фізична особа. Тому при такому вигляді клієнта можливе заповнення обох атрибутів, але в даному прикладі ця ситуація не розглядається.
 
<<   ЗМІСТ   >>