 |
2. Розробка iнфологiчної моделi.
|
|
|
|
2. РОЗРОБКА IНФОЛОГIЧНОЇ МОДЕЛI.
2. 1. Логічна модель
Метою інфологічного проектування є створення структурованої моделі предметної області, для якої буде розроблятися база даних. При проектуванні на інфологічному рівні створюється інформаційно-логічна модель, яка повинна відповідати вимогам коректності схеми БД, простоті і зручності використання на наступних етапах проектування.
Інфологічне проектування здійснюється за наступними етапами:
§ вилучення омонімії та синонімії. Це означає, що кожен атрибут повинен мати унікальне ім’я та унікальну семантику для однозначної його ідентифікації, ні синонімії, ні омонімії в даному разі немає.
§ агрегація атрибутів в інформаційні об’єкти. Тобто усі атрибути агрегуються в об’єкти, яким присвоюються унікальні імена;
§ перевірка на відповідність умовам нормалізації; приведення до 3 чи 4 нормальної форми.
§ виділення інформаційних запитів та їх опис;
§ представлення інформаційних запитів у структурованому вигляді.
§ перевірка запитальних зв’язків на відповідність умові канонічності;
§ побудова структурних зв’язків між об’єктами.
В результаті дослідження предметної області в першому роздiлi курсового проекту виявлений перелік атрибутів, що підлягають збереженню в БД:
Перш за все, переходячи до інфологічного проектування треба проаналізувати атрибути на наявність омонімії та синонімії. У переліку атрибутів немає синонімів, тобто – атрибутів, які різні за синтаксисом, але однакові за змістом, проте серед атрибутів зустрічаються омоніми – атрибути однакові за синтаксисом, але різні за змістом. Таким атрибутам слід присвоїти унікальні імена.
|
|
|
Дата: слід виділити дату відкриття рахунку та дату закриття(згідно договору).
Код: код клієнта, код відділення, код валюти, код депозитної програми.
Адреса: адреса відділу, адреса клієнта.
На другому етапі виконується агрегацiя атрибутiв в об’єкти - деякi сутностi реального свiту, що мають сенс з точки зору предметної областi: процес, поняття i т. д. Видiлення об’єктiв виконується на основi аналiзу вiдношень мiж атрибутами. Якщо серед них є такi, що знаходяться в спiввiдношеннi 1: 1, то вони агрегуються в один iнформацiйний об’єкт, якому надається унiкальне iм’я. Пiсля багаторазового виконання цієї операції, в перелiку атрибутiв залишаться такi, що не належать нi одному iз створених об’єктів. Цi атрибути аналiзуються на тип спiввiдношення 1: Б, але вже з видiленими об’єктами. Якщо пiсля цього знов залишились атрибути, не приєднанi нi до одного з об’єктiв, то доцiльно провести дообстеження предметної областi для поповнення перелiку атрибутiв.
Код депозиту*
Назва депозиту
Код валюти*
Назва валюти
Умовне позначення валюти
Код відділу*
Адреса відділу
Вид відділу
Номер угоди*
Дата відкриття рахунку
Дата закриття рахунку
Сума на рахунку
Код клієнта*
ПІБ клієнта
Паспорт серія
Паспорт номер
Ідентифікаційний код
Адреса клієнта
Контактний телефон
Відсоток
Що таке відділ? Можливо Ви маєте на увазі відділення банку.
2. 2 Інформаційні об’єкти та їх характеристика.
Сутність iнфологiчного проектування полягає у визначенні інформаційних об’єктів (сутностей) предметної області, якi підлягають зберіганню в БД, визначенню характеристик об’єктів та структурних зв’язків мiж ними. Результатом iнфологiчного моделювання є iнформацiйно-логiчна модель предметної області та опис її складових елементів. Iнфологiчна модель має задовольняти всі вимоги користувачів та прикладних програм.
|
|
|
Основними складовими елементами інфологічної моделі є:
§ інформаційний об’єкт;
§ атрибут;
§ інформаційний запит;
§ запитувальний зв’язок;
§ структурний зв’язок.
Інфологічне проектування здійснюється за наступними етапами:
§ вилучення омонімії та синонімії. Це означає, що кожен атрибут повинен мати унікальне ім’я та унікальну семантику для однозначної його ідентифікації, ні синонімії, ні омонімії в даному разі немає.
§ агрегація атрибутів в інформаційні об’єкти. Тобто усі атрибути агрегуються в об’єкти, яким присвоюються унікальні імена;
§ перевірка на відповідність умовам нормалізації; приведення до 3 чи 4 нормальної форми.
§ виділення інформаційних запитів та їх опис;
§ представлення інформаційних запитів у структурованому вигляді.
§ перевірка запитальних зв’язків на відповідність умові канонічності;
§ побудова структурних зв’язків між об’єктами.
В основу використовуваного інфологічного моделювання покладено висхідний метод, який оснований на синтезі атрибутів. Цей метод полягає в тому, що спочатку визначаються атрибути, які підлягають збереженню в базі даних, а потім вони групуються в інформаційні об’єкти.
Після аналізу усіх атрибутів та нормалізації інформаційних об’єктів у даному курсовому проекті виділено наступні інформаційні об'єкти та відповідні до них атрибути:
Клієнт: код клієнта, ПІБ клієнта, паспорт серія, паспорт номер, ідентифікаційний код, адрес клієнта, номер телефону
Відділ: код відділу, адреса відділу, вид відділу
Депозит: код депозиту, назва депозиту
Валюта: код валюти, назва валюти, умовне позначення валюти
Відсоток: код депозиту, код валюти, відсоток
Угода: номер угоди, код клієнта, код відділу, код депозиту, дата відкриття рахунку, дата закриття рахунку, сума на рахунку.
Де номер депозитного рахунку?
Увесь перелік атрибутів необхідно проаналізувати та нормалізувати відношення. Нормалізація відношень – це ітераційний зворотній процес декомпозиції початкового відношення на кілька простіших відношень меншої розмірності. Iнформацiйний об’єкт знаходиться в 1-й нормальнiй формi, якщо усi атрибути атомарнi (неподiльнi). Об’єкт у 2НФ не повинен мiстити неповних функцiональних залежностей. Якщо такi залежностi присутнi, то необхiдно виконати декомпозицiю об’єкта з метою їх усунення. На третьому кроцi нормалiзацiї проводиться аналiз на наявнiсть транзитивних залежностей (мiж неключовими атрибутами). Якщо транзитивна залежнiсть iснує, необхiдно роздiлити об’єкт так, щоб усi його атрибути напряму залежали вiд первинного ключа. Цей крок приведе об’єкт до 3НФ. Щоб привести об’єкт до 4НФ потрiбно проаналiзувати його на присутнiсть багатозначних залежностей i, якщо вони є, вилучити iх шляхом декомпозиції.
|
|
|
В результатi видiлення iнформацiйних об’єктiв та операцiй нормалiзацiї, отримуємо наступнi вiдношення, якi знаходяться в 3НФ або 4НФ.
Клієнт(Client)
kod_cl - numeric(6)
fio_cl – varchar(45)
pass_seria - varchar(2)
pass_num - numeric(6)
ident_kod- numeric(10)
adres_cl - varchar(30)
phone_num- varchar(20)
Валюта (Valuta)
kod_val - numeric(6)
name_val - varchar(30)
sign - varchar(10)
Депозити(Deposit)
kod_dep - numeric(6)
name_dep - varchar(30)
Відсоток (Vidsotok)
kod_dep – numeric(6)
kod_val - numeric(6)
vidsotok – numeric(4, 2)
Відділ (Viddil)
kod_vidil - numeric(6)
adres_vidl - varchar(30)
vud_vidil- varchar(10)
Угода(Ugoda)
numb_u - numeric(6)
kod_cl - numeric(6)
kod_vidil - numeric(6)
kod_dep- numeric(6)
date_start – datetime
date_end – datetime
suma_dep – money
Отже, ми спочатку проектуємо нашу базу даних у пакеті Erwin 7. 3 на логічному та фізичному рівнях, створюємо сутності, заповнюємо їх атрибутами, встановлюємо умови на значення та значення за умовчуванням атрибутів, будуємо зв’язки.
Перетворимо наші дані з формату джерела (первинних документів) у формат двовимірних таблиць (вказані вище). Бачимо, що всі відношення в нашій БД перебувають в 1НФ, оскільки усі атрибути відношення унікальні й атомарні (логічно неподільні).
Також всі відношення перебувають у 2НФ, оскільки кожний неключовий атрибут функціонально повно залежить від складового ключа, і у 3НФ, оскільки немає наявних транзитивних залежностей (залежностей між ключовими атрибутами).
Можемо з впевненістю сказати, що наша база даних нормалізована, оскільки відповідає 1НФ, 2НФ, 3НФ.
|
|
|
