Правила агрегації інформаційних об’єктів при інфологічному проектуванні бд.
Порядок виконання процедури агрегації такий.
1. Спочатку серед атрибутiв видiляються тi, мiж якими iснує однозначний зв’язок в обох напрямках (1:1). Такi атрибути агрегуються в один об’єкт, якому присвоюється унiкальне iм’я. Наприклад, атрибути «код матерiалу», «назва матерiалу», «одиниця вимiрювання», об’єднуються в один об’єкт під назвою «МАТЕРIАЛ». Важливим моментом є вибiр iменi об’єкта. Iдентифiкацiя об’єкта якимось iм’ям залежить вiд того, якiй сутностi предметної областi вiдповiдає даний об’єкт. Виконуючи такий аналiз, iнодi необхiдно додатково уточнювати iм’я атрибута для однозначного його семантичного трактування.
При цьому слiд пам’ятати, що в результатi виконання 2.1 один i той самий атрибут може потрапити до кiлькох об’єктiв. Наприклад, код робiтника може бути включений до об’єкта «ПРАЦIВНИК», який уміщує всю довiдкову iнформацiю про працюючих на пiдприємствi, а також до об’єкта «ВИРОБIТОК», що вмiщує данi про щоденний виробiток кожного робiтника.
2. Пiсля багаторазового виконання 2.1 перевiряють атрибути, що залишились, на тип спiввiдношення з видiленими об’єктами; якщо серед них є такi, що знаходяться у спiввiдношеннi 1:1 з видiленими об’єктами, то їх приєднують до вiдповiдних об’єктiв.
3. Якщо серед решти атрибутiв немає таких, якi б знаходились з видiленими об’єктами у спiввiдношеннi 1:1, то необхiдно виконати перевiрку на спiввiдношення 1:Б мiж рештою атрибутів і видiленими об’єктами. При такому типi спiввiдношення може існувати функцiональна залежність, але слiд пам’ятати, що спiввiдношення 1:Б у цьому разі означатиме те, що в екземплярах об’єкта можуть дублюватись значення даного атрибута. Такi атрибути приєднуються до видiлених об’єктiв.
4. Якщо пiсля виконання описаного аналiзу ще залишаться атрибути i серед них немає таких, якi б знаходились з видiленими об’єктами у спiввiдношеннi 1:1 чи 1:Б, то вирiшують питання про створення з решти атрибутiв окремих нових об’єктiв. Не виключена можливiсть, що при цьому може з’явитися об’єкт, який містить лише один атрибут. Це свiдчить про те, що існують недолiки в проектуваннi на зовнiшньому рiвнi. Тому потрiбно виконати дообстеження ПО з точки зору поповнення таких об’єктів атрибутами, яких бракує..
13. Характеристика основних етапів розробки інфологічної моделі.
1. Перший крок, який виконується при iнфологiчному проекту-ваннi, є аналiз атрибутiв на предмет вилучення синонiмiї i омонiмiї. Серед атрибутiв можуть зустрiтися такi, що мають однаковi iмена, але є рiзними за змiстом, тобто омонiми. У цьому разі атрибутам-омонiмам потр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ї перел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дношеннi 1:1 з видiленими об’єктами, то їх приєднують до вiдповiдних об’єктiв. Якщо серед решти атрибутiв немає таких, якi б знаходились з видiленими об’єктами у спiввiдношеннi 1:1, то необхiдно виконати перевiрку на спiввiдношення 1:Б мiж рештою атрибутів і видiленими об’єктами. При такому типi спiввiдношення може існувати функцiональна залежність, але слiд пам’ятати, що спiввiдношення 1:Б у цьому разі означатиме те, що в екземплярах об’єкта можуть дублюватись значення даного атрибута. Такi атрибути приєднуються до видiлених об’єктiв.
Якщо пiсля виконання описаного аналiзу ще залишаться атрибути i серед них немає таких, якi б знаходились з видiленими об’єктами у спiввiдношеннi 1:1 чи 1:Б, то вирiшують питання про створення з решти атрибутiв окремих нових об’єктiв. Не виключена можливiсть, що при цьому може з’явитися об’єкт, який містить лише один атрибут. Це свiдчить про те, що існують недолiки в проектуваннi на зовнiшньому рiвнi. Тому потрiбно виконати дообстеження ПО з точки зору поповнення таких об’єктів атрибутами, яких бракує.
3. Наступним кроком 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ї.
4. Зовнiшнє кодування. На цьому кроцi необхiдно вивчити атрибути з неунiкальними значеннями. Якщо цi атрибути представленi досить довгими текстами, то необхiдно вирiшити питання про доцільність замiни їх на короткi кодовi позначення. У цьому разі в iнфологiчну модель вноситься новий iнформацiйний об’єкт, який доречно назвати «ДОВIДНИК». Вiн буде складатись з коду атрибута та його текстового значення. При цьому в усiх ранiше видiлених об’єктах текстовi значення замiнюються на код.
5. Видiлення запитiв до БД i словесний їх опис. Для того щоб описати запити, необхiдно дослiдити процеси обробки iнформацiї по кожнiй функцiональнiй задачi модельованої предметної областi. Запити видiляють опитуванням користувачiв i з’ясуванням iнформацiйних потреб прикладних програм. Запити описують спочатку словесно, по можливостi чiтко видiляючи всi об’єкти, якi використовуються при виконаннi запиту, а також описуючи запит так, щоб можно було виявити послiдовнiсть переходу вiд одного об’єкта до iншого при виконаннi запиту.
6. Кожний запит необхiдно подати в структурованому виглядi вiдповiдним запитувальним зв’язком. Узагальнена форма запитувального зв’язку така:
,
де Х1, Х2, ..., Хn –– початковi об’єкти, якi потрiбно розмістити в порядку iнформацiйного пошуку чи в порядку зменшення групувальної ознаки об’єктiв;
У –– кiнцевий об’єкт, який уособлює мету реалiзацiї запиту (вiн має бути завжди один).
7. На сьомому кроцi iнфологiчного проектування запитувальні зв’язки перевіряють на вiдповiднiсть умовам канонiчностi.
Канонiчний запитувальний зв’язок –– це такий багатовимiрний зв’язок, у якому:
тип спiввiдношення мiж будь-якими двома початковими об’єктами може бути лише Б:Б;
тип спiввiдношення мiж будь-яким початковим i кiнцевим об’єктaми не може бути Б:1.
Якщо багатовимiрний запитувальний зв’язок не є канонiчним, то виконується ряд перетворень для зведення його до канонiчного вигляду.
Пiсля побудови структурних зв’язкiв проектувальник отримує варiант побудови iнфологiчної моделi предметної областi, який необхiдно перевiрити на повноту й коректнiсть. Перевiрку на повноту виконують для встановлення можливостi реалiзацiї на отриманiй моделi всiх iнформацiйних запитiв з боку прикладних програм і користувачiв. Перевiрка на коректнiсть полягає в спрощеннi та уточненнi моделi на її адекватність предметнiй областi. Під час виконання такої перевiрки виявляють і вилучають надлишкові структурнi зв’язки, а також виконують ряд перетворень структури iнфологiчної моделi.