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НФ.