Особа Бере Кредит

Кредит 1

Особа 1 · Кредит 2

Кредит 3

Особа 2 · Кредит 4

Особа 3 · Кредит 5

... Кредит 6

Особа n · Кредит n

КН: ОБОВ'ЯЗК. ТИП ЗВ'ЯЗКУ 1:N КН: ОБОВ'ЯЗК.

Рисунок 3- ER – Діаграма екземплярів сутей Особа і Кредит

Зв'язок Види кредитів – Кредит поданий діаграмою екземплярів на рис. 2, з якого видно, що клас належності суті Види кредитів є необов’язковим, тому що можливі такі види кредитів, які клієнти можуть і не взяти. Клас належності суті Кредит є обов’язковим, тому що кожен оформлений кредит має бути одним з видів суті види кредитів. Тип зв'язку - 1:n, оскільки один вид кредиту може оформити декілька осіб, проте один кредит може бути оформлений лише за одним із видів кредитів.

Види кредитів Визначають Кредит

1 Вид кредитів · · Кредит

2 Вид кредитів · · Кредит

3 Вид кредитів · · Кредит

4 Вид кредитів · · Кредит

......

n Вид кредитів · · Кредит n

КН: НЕОБОВ'ЯЗК. ТИП ЗВ'ЯЗКУ 1:N КН: ОБОВ'ЯЗК.

Рисунок 4 – ER-діаграма екземплярів сутей Види кредитів і Кредит

Зв'язок Кредит – Щомісячна оплата поданий діаграмою екземплярів на рис. 3, з якого видно, що клас належності суті Кредит є не обов’язковим, адже цілком можливо, що клієнт після отримання кредиту може його не погашати. Клас належності Щомісячна оплата є обов’язковим, адже якщо клієнт повертає деяку суму, то боргова сума повинна зменшитись на цю величину. Тип зв'язку - 1:n, адже кредит можна повертати малими сумами протягом вказаного періоду, але якщо клієнт повертає частину кредиту, то кредит на повернуту суму зменшується лише даному клієнтові.

Кредит Оплачується Щомісячна оплата

Кредит 1· · Щомісячна оплата

Кредит 2· · Щомісячна оплата

Кредит 3· · Щомісячна оплата

Кредит 4· · Щомісячна оплата

Кредит 5· · Щомісячна оплата

......

Кредит n · · Щомісячна оплата n

КН: НЕОБОВ'ЯЗК. ТИП ЗВ'ЯЗКУ 1:N КН: ОБОВ'ЯЗК.

Рисунок 5 – ER-діаграма екземплярів сутей Кредит і Щомісячна оплата

Характеристики зв'язків і клас належності розглянутих сутей наведені в таблиці 3.

Таблиця 3–Характеристики зв'язків предметної області “Контроль оплати по кредитах”

Ім'я суті 1	Ім'я суті 2	Тип зв'язку	Ім'я зв'язку	Клас належності
Особа	Кредит	1: N	Бере	Обов., обов.
Види кредитів	Кредит	1: N	Визначають	Необ., обов.
Кредит	Щомісячна оплата	1: N	Оплачується	Необ., обов

З врахуванням вищезгаданого ER-модель досліджуваної предметної області приймає вигляд, що вказаний на рис. 6.

Рисунок 6 – Результуюча ER-модель предметної області “Контроль оплати по кредитах”

7.4 ПРОЕКТУВАННЯ НОРМАЛІЗОВАНИХ ВІДНОШЕНЬ

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

Визначимо різницю між дублюванням даних та надлишковим дублюванням даних. Для цього розглянемо приклад відношень наведений у таблиці 4.

Таблиця 4 – Приклад відношень з ненадлишковим дублюванням даних

Табельний номер робітника	Прізвище начальника
	Бойко
	Луцюк
	Бойко
	Луцюк

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

Розглянемо тепер приклад відношення наведений в таблиці 5.

Таблиця 5 – Приклад відношень з надлишковим дублюванням даних

Табельний номер робітника	Прізвище робітника	Телефон начальника
	Бойко
	Луцюк
	Бойко
	Луцюк

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

- по-перше, при цьому знадобляться додаткові зусилля для визначення "реальних" значень нулів.

- по-друге, якщо у кортежі робітника з табельним номером 125 замінити значення телефону Бойко нулем, то при звільнені співробітника з табельним номером 200 виникне загублена інформації про номер телефону Бойко. Тому в таких випадках виконують заміну одного відношення двома. У нашому прикладі відношення таблиці 6 буде замінено відношенням таблиці 5 та таблиці 7.

Таблиця 6 – Приклад додаткового відношення, що використовується для видалення надлишкового дублювання даних.

Прізвище начальника	Телефон начальника
Бойко
Луцюк

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

Аномалія відновлення обумовлена двома факторами:

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

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

Під функціональною залежністю атрибутів розуміють таке. Нехай дано атрибути А і В. Кажуть, що В функціонально залежить від А, якщо для кожного значення А в будь-який момент часу існує рівно одне пов'язане з ним значення В. Наприклад, в універсальному відношенні, що описує відеотеку, код користувача функціонально залежить від його паспортних даних і навпаки, паспортні дані функціонально залежать від коду користувача. Номер телефону функціонально залежить від коду користувача, але зворотної залежності не існує, якщо припустити, що користувачами відеотеки можуть бути декілька різних членів сім’ї, які мешкають за однією і тією ж адресою.

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

Найбільш розповсюдженою формою нотації функціональних залежностей є така:

А => В

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

Виключення появи аномалій досягається шляхом видалення з відношення небажаних функціональних залежностей, в ході якого здійснюється декомпозиція відношень на ряд інших відношень, що є проекціями вихідного. Таке видалення небажаних функціональних залежностей називається НОРМАЛІЗАЦІЄЮ - покроковим оборотним процесом заміни даного відношення (або даної сукупності відношень) іншою сукупністю відношень, в якій відношення мають більш просту і регулярну структуру. Апарат нормалізації відношень був розроблений Коддом, котрий виділив три нормальних форми подання відношень.

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

Відношення називається зведеним до першої нормальної форми (1НФ), якщо всі його атрибути прості.

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

Відношення знаходиться в другій нормальні формі (2НФ), якщо воно знаходиться в 1НФ і кожний неключовий атрибут функціонально повно залежить від складеного ключа, а не від його частин. В нашій базі даних всі відношення крім Щомісячна оплата не містять складених ключів. Але у відношені Щомісячна оплата ( сума, дата, час ) атрибут Сума функціонально повно залежить від складеного ключа. Тобто, можна зробити висновок, що всі відношення даної бази даних знаходяться в 2НФ.

Відношення знаходиться в третій нормальні формі (3НФ), якщо воно знаходиться в 2НФ і кожен неключовий атрибут нетранзитивно залежить від початкового ключа. Визначимо понятя транзитивності функціональної залежності. Нехай Х, Y та Z - три атрибути деякого відношення. При цьому має місце Х à Y та Y à Z, але обернена відповідність відсутня, тобто Z -/-> Y або Y -/-> X. Тоді говорять, що Z транзитивно залежить від X. У відношеннях бази даних “Контроль оплати по кредитах” не існує транзитивних залежностей, тому можна зробити висновок, що всі відношення знаходяться в 3НФ.

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

4. В тих випадках, коли у відношенні відсутні багатозначні залежності, але є два (або більше) можливих ключів, ЗНФ може мати аномалії операцій.

Розглянемо відношення PROJECT (<Det, Proj>, Post), що описує використання в проектах (Proj) деталей (Det), які поставляються постачальниками (Post). У проекті використовується декілька деталей, але кожна постачається тільки одним постачальником. Кожен постачальник обслуговує тільки один проект, але кожен проект може обслуговуватися декількома постачальниками. В цьому випадку мають місце такі функціональні залежності:

<Det, Proj|> => Post та Post => Proj.

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

У таких випадках використовують "посилену" третю нормальну форму, котру називають також нормальною формою Бойса-Кодда (НФБК).

Атрибут (або комбінацію атрибутів), від якого будь-який інший атрибут залежить функціонально повно, називають детермінантним. Виходячи з того можна дати таке означення посиленої третьої нормальної форми: нормалізована схема відношення знаходиться в НФБК, якщо кожен детермінант є можливим ключем.

5. Існують також четверта та п'ята нормальні форми, обумовлені наявністю у відношенні багатозначних функціональних залежностей. Проте на практиці в більшості випадків обмежуються отриманням відношення в НФБК.

7.5 Отримання попередніх відношень за методом “Суть – зв’язок”

Загальний підхід до проектування баз даних на основі ER-методу включає в себе такі основні кроки:

- побудова діаграми ER-типу, що включає в свій склад всі су­ті і зв'язки даної предметної області;

- побудова набору попередніх відношень з вказанням передбачуваного початкового ключа для кожного відношення;

- підготовка списку всіх атрибутів, що викликають інтерес (котрі не були перераховані як ключі сутей), і призначення кожного з цих атрибутів одному з попередніх відно­шень такі, щоб всі ці попередні відношення знаходились в НФБК. Для виконання цієї задачі необхідно визначити всі міжатрибутні функціональні залежності. У випадку, якщо не вдається привести відношення до НФБК або деяким атрибутам не вдасться знайти логічно обґрунтованих місць, треба переглянути ER-діаграми на предмет видалення ускладнень, що виникли.

Попередні відношення формально генеруються з діаграми ER-типу на основі аналізу класу належності і ступені відношень сутей, на основі таких правил [14].

ПРАВИЛО 1. Якщо ступінь бінарних зв'язків 1:1 і клас належності обов'язковий для обох сутей, гарантується однократне появлення кожного значення сутей в будь-якому екземплярі відношень. Тобто, у відношенні ніколи не буде ні порожньої інформації, ні груп надлишкових даних, що повторюються.

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

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

ПРАВИЛО 2. Якщо ступінь бінарного зв'язку 1:1 і клас належності однієї суті є обов'язковим, а іншої - необов'язковим, то необхідна побудова двох відношень. При цьому ключ суті повинен служити первинним ключемдля відповідного відношення. Крім того, ключ суті, для якої клас належності є обов'язковим, додається як атрибут у відношення, що виділене для суті з необов'язковим класом належності.

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

ПРАВИЛО 3. Якщо ступінь бінарного зв'язку 1:1 і клас належ­ності обох сутей не є обов'язковим, то необхідно використо­вувати три відношення: по одному для кожної суті, ключі котрих служать первинні ключі відповідних відношень, і одне для зв'язку. Первинним ключем цього відношення може бути будь-яка з двох сутей. Серед своїх атрибутів відношення, що виділяється для зв'язку, повинно мати по одному ключу кожної суті.

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

Під час роботи з відношеннями для бінарних зв'язків ступені 1:N фактором, що визначає вибір правила для генерації відповідного набору попередніх відношень, є клас належності n- зв’язаної суті. Клас належності 1-зв'язаної суті у цьому випадку на кінцевий резуль­тат не впливає.

ПРАВИЛО 4. Якщо ступінь бінарного зв'язку 1:N, і клас належ­ності n-зв'язної суті є обов'язковим, то досить використати по одно­му відношенню на кожну суть, при умові, що ключ кожної суті слу­жить як первинний ключ для відповідного відношення. До­датково, ключ 1-зв'язаної суті повинен бути добавлений як атрибут у відношення, що відводиться n- зв’язній суті.

Очевидно, що використання двох відношень в цьому випадку дозволяє усунути дублювання інформації (багатократний опис атрибута 1-зв'язаної суті, зв'язаного з n атрибутами n-зв’язної суті). Крім того, аналогічно правилу 2 забезпечується видалення з відношень пробілів.

ПРАВИЛО 5. Якщо ступінь бінарного зв'язку 1:N і клас належності n-зв’язної суті є необов'язковими, то необхідно формування трьох відношень: по одному для кожної суті, причому ключ кожної суті служить як первинний ключ для відповідного відношення, і одного відношення для зв'язку. Зв'язок повинен мати серед своїх атрибутів ключ суті кожної з зв'язних сутей.

При ступені бінарного зв'язку M:N без залежності від класу належності сутей завжди необхідно використовувати три відношення.

ПРАВИЛО 6. Якщо ступінь бінарного зв'язку M:N, то для зберігання даних потрібні три відношення: по одному для кожної суті, причому ключ кожної суті служить як первинний ключ для відповідного відношення, та одного відношення для зв'язку. Зв'язок повинен мати серед своїх атрибутів і ключ суті кожної зі зв'язних сутей. Виявлення в предметній області тристоронніх зв'язків приводить до необхідності використання чотирьох відношень.

ПРАВИЛО 7. У випадку наявності тристороннього зв'язку завжди використовуються чотири відношення: по одному для кожної суті. Причому ключ кожної суті служить як первинний ключ для відповідного відношення, і одного відношення для зв'язку. Зв'язок повинен мати серед своїх атрибутів ключі суті кожної із зв'язних сутей.

Аналогічно для подання n-стороннього зв'язку необхідно використовувати n+1 попереднє відношення.

Використовуючи наведені правила, перерахунок атрибутів з універсального відношення та сформовану ER-модель предметної області, сформуємо попередні відношення, які описують задачу матеріального забезпечення заводу. Отримані попередні відношення зведемо в таблицю 7.

Таблиця 7–Попередні відношення для опису предметної області “Контроль оплати по кредитах”

Ім'я зв'язку	Правило	Попередні відношення	Додаткові атрибути
Бере		R1(ідентифікаційний код, …)     *R2(код кредиту, …)	ПІБ, адреса, рік народження,   сума кредиту, дата надання, дата завершення, ідентифікаційний код
Визначають		R3(річні проценти, …)     *R4 (код кредиту, …)	назва кредиту, максимальна сума   сума кредиту, дата надання, дата завершення, ідентифікаційний код, річні проценти
Оплачується		R5(код кредиту, …)   R6(дата, час, …)	сума кредиту, дата надання, дата завершення, ідентифікаційний код, річні проценти   сума, код кредиту

У таблиці 7 наведено розподілення неключових атрибутів між отриманими попередніми зв'язками. Знаком “*” помічені відношення, які потрібно видалити. Відношення R2 виключається з розглядання, оскільки вони повністю містяться у відношенні R5. Відношення R4 виключається з розглядання, оскільки воно повністю збігається з R5.

Після видалення відношень позначених * залишились відношення:

- R1(<ідентифікаційний код>, ПІБ, адреса, рік народження);

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

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

- R6(<дата, час>, сума, код кредиту).

Кінцеві відношення, що описують базу даних “Контроль оплати по кредитах”, подані таким набором:

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

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

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

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

7.6 Нормалізація відношень методом декомпозиції

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

1. Розробка універсального відношення для бази даних.

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

3. Визначення того, чи знаходиться розглянуте відношення в НФБК. Якщо так, то проектування закінчується; якщо ні - від­ношення розбивається на два відношення.

4. Повторення кроків 2 та 3 для кожного нового відношення, отриманого в результаті декомпозиції.

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

Нехай відношення R (A, B, C, D, E,...) не зведено до НФБК. Визначається функціональна залежність, наприклад, C → D, з якої відомо, що вона є причиною того, що відношення не знаходиться в НФБК (С є детермінантом, але не є можливим ключем). Створюються два нових відношення: R1 (A, B, C, E,...) та R2 (C, D), де залежна частина функціональної залежності опускається при формуванні R1 та повністю використовується під час формування відношення R2. Тепер необхідно перевірити, чи знаходяться в НФБК відношення R1 та R2. Про відношення R2 (C, D) говорять, що воно є проекцією відношення R. Цей тип декомпозиції називається декомпозицією без втрат при природному з'єднанні. Даний прийом повторюється для кожного нового відношення, отриманого в результаті декомпозиції. Проектування закінчується, коли всі відношення будуть знаходитися в НФБК[1].

Розглянемо функціональні залежності, які присутні між атрибутами універсального відношення, що описує предметну область “Контроль оплати по кредитах” (рис.7).

< ідентифікаційний код >→ адреса, ПІБ, рік народження;

< річні проценти > → назва кредиту, максимальна сума;

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

<дата, час> → сума, код кредиту.

Рисунок 7 – Діаграма функціональної залежності

Універсальне відношення даної курсовій роботі має вигляд:

R (< ідентифікаційний код, річні проценти, код кредиту, дата, час >, адреса, ПІБ, рік народження, назва кредиту, максимальна сума, сума кредиту, дата надання, дата завершення, сума).

Детермінантами відношення є всі ліві частини функціональних залежностей < ідентифікаційний код >, < річні проценти >, <код кредиту >, <дата, час>.

На основі вищеперерахованих правил декомпозиції здійснимо послідовність операцій декомпозиції для отримання відношення в НФБК.

1. Виконаємо проекціювання відношення R, яке породжується всіма функціональними залежностями, що містять атрибут ідентифікаційний код. Отримаємо відношення R1 і R2:

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

R2 (<ідентифікаційний код>, адреса, ПІБ, рік народження).

Відношення R2 знаходиться в НФБК. А відношення R1 не знаходиться.

2. Виконаємо проекціювання відношення R 1, яке породжується всіма функціональними залежностями, що містять атрибут код кредиту. У результаті отримаємо відношення R3, R4:

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

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

Відношення R4 знаходиться в НФБК. Для R3 ця умова не виконується.

3.Виконаємо декомпозицію R3 шляхом проекціювання, породжуваного функціональною залежністю, для якої детермінантом є дата, час. В результаті отримаємо відношення R5, R6:

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

R6 (< дата, час >, сума, код кредиту).

Відношення R5, R6 знаходяться в НФБК, що свідчить про закінчення процедури декомпозиції.

Отже кінцеві відношення знайдені за допомогою методу декомпозиції, мають такий вигляд.

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

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

Кредит ( код кредиту, сума кредиту, дата надання, дата завершення,

річні проценти, ідентифікаційний код); (R4)

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

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. Розгляд відношень з практичної точки зору. Вивчається характер використання відношень в базі даних, що проектуються, і визначається чи будуть вони підтримувати ті типи операцій відновлення та запити, котрі передбачається використовувати.

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

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

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

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

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

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

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

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

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

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

8 РЕАЛІЗАЦІЯ ЗАПИТІВ І ВИХІДНИХ ФОРМ

8.1 Аналіз реалізованих БД запитів

Для збільшення функціональності та зручності у використанні бази даних «Контроль оплати по кредитах» було реалізовано такі запити.

- «СПИСОК БОРЖНИКІВ» За допомогою даного запиту можна отримати список боржників. До списку боржників відносяться ті клієнти, які не погасили кредит до зазначеного терміну.

- «СПИСОК НЕПОГАШЕНИХ КРЕДИТІВ» Розроблений запит дозволяє отримати список клієнтів, які ще не погасили кредит. Даний запит відрізняється від попереднього тим, що він, крім списку боржників, включає ще список клієнтів які не погасили кредит, проте кінцева дата погашення даних кредитів ще не настала.

- «СПИСОК КЛІЄНТІВ, ЯКІ ПОГАСИЛИ КРЕДИТ» Даний запит виводить список клієнтів які не мають кредитних зобов’язань. Тобто, клієнтам із даного списку банківська установа може знову надавати кредит. Даний запит виключає можливість надання клієнту кредит, якщо він не погасив попередній кредит, що є цілком очевидно.

- «СПИСОК КЛІЄНТІВ ЗА АДРЕСОЮ» Даний запит дозволяє визначити список клієнтів, які проживають за певною адресою. Він може бути корисний для визначення густини розподілу клієнтів по території.

8.2 Розробка вихідних форм

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

Розглянемо створені форми.

«ФОРМА РЕЄСТРАЦІЯ» - призначена для реєстрації нових клієнтів. На даній формі одночасно з реєстрацією відбувається оформлення першого кредиту, це зроблено для того, щоб в базі даних не було клієнтів, які не брали жодного кредиту.

«ФОРМА ОФОРМЛЕННЯ КРЕДИТУ» - служить для оформлення кредиту клієнтам, які вже отримували кредит. Також дана форма відслідковує боржників і не надає їм можливості знову отримувати кредит.

«ФОРМА ОСОБА» - за допомогою даної форми можна проглянути інформацію про кожного клієнта.

«ФОРМА ВИДИ КРЕДИТІВ»- дозволяє переглядати, редагувати та добавляти види кредитів, які клієнти можуть отримувати.

«ФОРМА ОПЛАТА КРЕДИТУ»- дозволяє клієнтові повертати кредит малими сумами. Саме за допомогою даної форми і здійснюється погашення кредиту. Форма надає детальну інформацію про клієнта і його кредит, а також автоматично вираховує непогашений залишок.

9 ЗРАЗОК ОФОРМЛЕННЯ ДОДАТКІВ

Дата добавления: 2014-11-16