Інформаційні системи та їх роль в управлінні економікою

5.1. Особливості  проектування БД на зовнішньому  рівні

Етапність проектування БД пов"язана з багаторівневою організацією даних  чи їх подання : зовнішнього, інфологічного, логічного(даталогічного), внутрішнього.

 

 

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

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

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

Існує два підходи  до проектування баз даних на зовнішньому  рівні:

• · від предметної галузі;
• · від запиту.

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

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

Перевагами підходу  «від предметної галузі» є його об’єктивність, системність при відображенні ПО і стійкість інформаційної моделі, можливість реалізації великої кількості  прикладних програм і запитів, у тому числі незапланованих при створенні БД. Недолік цього підходу — значний обсяг робіт, що його потрібно виконати при визначенні інформації, яка підлягає фіксації в БД, що відповідно ускладнює і збільшує термін розробки проекту.

5.2. Інфологічна модель БД 

 

Інфологічний рівень являє собою інформаційно-логічну модель (ІЛМ) предметної області, в якій виключена надмірність даних і відображені інформаційні особливості об’єкту управління, без урахування особливостей і специфіки конкретної СУБД. 
Мета інфологічного проектування — створити структуровану інформаційну модель ПО, для якої розроблятиметься БД. Під час проектування на інфологічному рівні створюється інформаційно-логічна модель, яка має відповідати таким вимогам:

• коректність схеми БД, тобто адекватне відображення модельованої ПО;
• простота і зручність використання на наступних етапах проектування, тобто ІЛМ має легко відображатися в моделі БД, що підтримується відомими СУБД (сіткові, ієрархічні, реляційні);
• ІЛМ має бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам АБ.

Основною складовою  інфологічної моделі є атрибути, які потрібно проаналізувати і деяким чином згрупувати для подальшого зберігання в БД.Сутність інфологічного моделювання полягає у виокремленні інформаційних об’єктів ПО (таблиць), які підлягають зберіганню в БД, а також визначенні характеристик об’єктів і зв’язків між ними. Характеристиками чи властивостями об’єктів є атрибути.

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

Основними складовими елементами інфологічної моделі є інформаційний  об’єкт, атрибут, запит, запитальний  зв’язок, структурний зв’язок.

Інформаційний об’єкт — деяка сутність ПО, яку необхідно відображувати в БД з точки зору прикладної програми чи користувача БД. Це може бути предмет, факт, дія, явище чи поняття. Кожен об’єкт описується його властивостями, тобто його атрибутами. Крім атрибутів та інформаційних об’єктів, складовими частинами інфологічної моделі є інформаційний запит, запитувальний зв’язок і структурний зв’язок.

Інформаційний запит — словесний опис інформаційної потреби користувача чи прикладної програми. 

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

Структурний зв’язок — асоціації, що описують ієрархічні зв’язки між парами інформаційних об’єктів, один з яких виступає як власник, а інший як підпорядкований об’єкт. 

Екземпляр структурного зв’язку — це екземпляр об’єкта власника та певна су- 
купність зв’язаних з ним екземплярів підпорядкованого об’єкта. 

 

Даталогічний (логічний, концептуальний) рівень формується 
з урахуванням специфіки і особливостей конкретної СКБД. На цьому рівні будується концептуальна модель даних, тобто спеціальним способом структурована модель ПО, яка відповідає особливостям і обмеженням вибраної СКБД. Модель логічного рівня, яка підтримується засобами конкретної СКБД, іноді називають даталогічною. Серед типів моделей, які підтримуються засобами СКБД, є ієрархічні, сіткові і реляційні  та об'єктно-орієнтовані  моделі баз даних.

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

 

5.3. Ключі в БД

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

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

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

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

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

З двох логічно пов'язаних таблиць одну називають таблицею первинного ключа або головною таблицею, а іншу таблицею вторинного (зовнішнього) ключа або підпорядковану таблицю. СУБД дозволяють зіставити споріднені записи з обох таблиць і спільно вивести їх у формі, звіті або запиті.

Існує три типи первинних ключів: ключові поля лічильника (лічильник), простий ключ і складений ключ.

Поле лічильника (Тип даних «Лічильник»). Тип даних поля в базі даних, в якому для кожної додається до таблиці запису в полі автоматично заноситься унікальне числове значення.

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

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

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

Якщо виникають труднощі з вибором потрібного типу первинного ключа, то в качеcтве ключа доцільно вибрати поле лічильника. 
 

5.4. Теорія  нормалізації відношень 

 

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

Для створення такої моделі баз даних незалежно від того, яка СУБД використовується — ієрархічна, сіткова чи реляційна — застосовується теорія нормалізації реляційних баз даних. Використання реляційного підходу дає змогу спроектувати оптимальну логічну модель БД, яка потім досить просто трансформується в ієрархічну чи сіткову модель.

Нормалізація відношень — це ітераційний зворотний процес декомпозиції початкового відношення на кілька простіших відношень меншої розмірності. Під зворотністю процесу розуміють те, що операція об’єднання відношень, здобутих у результаті декомпозиції, має дати початкове відношення. У результаті нормалізації склад атрибутів відношень БД має відповідати таким вимогам:

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

Апарат нормалізації був розроблений американським  вченим Е.Ф. Коддом. Кожна нормальна форма обмежує тип допустимих залежностей між атрибутами. Кодд виділив три нормальні форми (скорочена назва 1НФ, 2НФ і 3НФ).  Тепер уже відомі і визначені 4НФ, 5НФ. 
Нормалізація відношень виконується за кілька кроків. 1-й крок (1-ша ітерація) — зведення відношень до першої нормальної форми (1НФ).2-й крок (2-а ітерація) — зведення відношень до другої нормальної форми (2НФ) і тд. 
Основними принципами нормалізації  є

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

Таким чином , нормалізація відношень усуває між атрибутами такі залежності: неповні функціональні, транзитивні, нетривіальні (незалежні) багатозначні. Усуваючи ці залежності, виключаємо дублювання даних і можливість виникнення аномалій при виконанні операцій поповнення, заміни та вилучення даних з БД. Крім того, нормалізована база даних вимагає значно менше пам’яті для її зберігання, ніж ненормалізована база даних. 

 

 

  

 

5.5. Зв"язки  між реляційними таблицями та  послідовність кроків при 

інфологічному  моделюванні предметної області 

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

А між такими таблицями можуть бути наступні типи зв’язків 1:1, 1:Б та Б:Б. Найбільш поширеним  зв’язком є зв’язок 1:Б. Зв’язок 1:1 зустрічається рідше, тому що дані між  якими існує такий тип зв’язку  в переважній більшості випадків входять до складу однієї реляційної таблиці. Зв’язок Б:Б безпосередньо не підтримується в реляційних СУБД. Для реалізації такого зв’язку необхідно створювати додаткову реляційну таблицю, яка буде відігравати роль зв’язкової. Зв’язкова таблиця має обов’язково містити первинні ключі таблиць, між якими встановлюється зв’язок.

Інфологічні моделі мають велике значення при відображенні семантики модельованої предметної галузі. Послідовність робіт при  інфологічному проектуванні наступна: 
1) вилучення синонімії, омонімії та узагальнення атрибутів; 
2) аналіз атрибутів і виділення інформаційних об’єктів;

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

Деякі атрибути можуть включатися до різних інформаційних  об"єктів.Так атрибут КОД ГРУПИ  буде включатися до об"єктів ГРУПИ та СТУДЕНТИ 
3) перевірка об’єктів на відповідність умовам нормалізації;

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

Створення довідників для усунення неунікальності текстових  полів. 
5) виявлення та опис інформаційних запитів до бази даних;

Описуючи запит, потрібно враховувати режим його виконання. Режими бувають одиночними і множинними. Одиночний режим — це такий, коли запит виконується для одного екземпляра початкового об’єкта: наприклад, «Для заданого ПОСТАЧАЛЬНИКА...». Множинний режим означає багаторазове виконання запиту для всіх екземплярів початкового об’єкта чи їх підмножини: наприклад, «Для всіх ПОСТАЧАЛЬНИКІВ...».  
6) формалізований опис інформаційних запитів у вигляді запитувальних зв’язків;