7.7 Оцінка спроектованих нфбк-відношень

Перевірка НФБК-відношень, які розглядаються як кінцевий проект на предмет наявності невиявлених проблем, включає такі основні кроки :

1. Складаються списки функціональних залежностей дня кожного відношення. Ці списки перевіряються на двох направленнях:

- одна і таж функціональна залежність не повинна з'являтися більше, ніж в одному відношенні;

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

2. Здійснюється перевірка на присутність надлишкових відношень. Відношення є надлишковим якщо :

- всі його атрибути можуть бути знайдені в одному або другому відношенні набору, що проектується;

- всі його атрибути можуть бути знайдені в відношенні, котре може бути отримане з інших відношень запропонованого проектного набору за допомогою серії JOIN - операцій над цими відношеннями. Якщо встановлена надлишковість відношення, його потрібно видалити з проектного набору. Наприклад, перший тип надлишковості присутній в такому наборі спроектованих відношень:

R1(<А>,В);

R2(<В>,С,Y,Z);

RЗ(<А>,В,K).

Очевидно, що відношення R1 є надлишковим, оскільки всі його атрибути присутні в відношенні RЗ.

Другий тип надлишковості можна проілюструвати на такому наборі відношень :

R1(<А>,С,X);

R2<D,К>,F);

R3(<D>Е,G,H);

R4(<А,В>,D);

R5(<А,В,Е>,G);

R6(<В>,С,У,Z).

Тут надлишковим є відношення R7, оскільки застосування операції JOIN над RЗ та R4 (із загальним атрибутом D) дав відношення :

R7 (А,В,D,Е,H),

котре містить всі атрибути, присутні в R7.

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

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

Розглядаючи отримані при проектуванні бази даних матеріального забезпечення підприємства відношення, можна помітити, що:

- ні одна функціональна залежність (ФЗ) не повторюється більше одного разу;

- цей набір ФЗ є мінімальним.

Аналіз відношень показує, що не можна вказати серед них жодного, всі атрибути якого були б підмножиною атрибутів іншого відношення. Крім того, неможливо об’єднати будь-які два відношення так, щоб у результаті були отримані всі атрибути третього відношення. Тобто, жодне з відношень не є надлишковим, що свідчить про правильність проведення проектування.

Кінцеві відношення набудуть такого вигляду.

Особа (ідентифікаційний код , ПІБ, адреса, рік народження);

Види кредитів (річні проценти, назва кредиту, максимальна сума) ;

Кредит (код кредиту, сума кредиту, дата надання, дата завершення, річні проценти, ідентифікаційний код) ;

Щомісячна оплата (дата, час, сума, код кредиту).