К

3.3.3. Структурний аналіз моделей інформаційної системи

ожен рівень подання даних АІС можна описати через структурні компоненти і таким чином здійснити структурний аналіз моделей інформаційної системи шляхом декомпозиції кожного рівня подання даних від загального до найменшого складового елемента. Архітектура подання даних та структурний аналіз моделей АІС представлена в таблиці 3.1.

На основі такого представлення можна відслідкувати відображення кожного структурного елемента на певному етапі декомпозиції рівнів архітектури подання даних АІС.

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

Таблиця.3.1

Архітектура та структурний аналіз моделей АІС

Рівень/ деком-позиція	Зовнішній : предметна область (ПО) - предмет дослідження	Інфологіч-ний: на основі знань спеціаліста-предмет-ника	Концепту- альний: на основі моделі даних СУБД	Внутрішній: засобами опису та маніпулю-вання даними СУБД	Фізичний: засобами збереження даних СУБД в пам’яті ЕОС
1	Система об’єктів (процесів, документів) ПО	Інфоло-гічна модель	Концепт- туальна модель	База даних як сукупність файлів даних і програм	Бібліотека на магнітних дисках
2	Об’єкт	Сутність	Структуро-вана таблиця	Форма Запис	Фізичний запис
3	Властивість об’єкта	Реквізит	Атрибут	Поле	Відповідна сукупність комірок пам’яті ЕОС
4	Характерис-тика властивості	Значення реквізиту	Значення атрибуту	Значення поля	Стан комірок пам’яті ЕОС

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

3.4. Проектування та оптимізація структури баз даних

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

Етапи проектування відповідають рівням подання даних у АІС, тобто виконуються певні роботи на зовнішньому, інфологічному, концептуальному і внутрішньому рівнях.

М

3.4.1.Проектування баз даних на зовнішньому рівні

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

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

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

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

Однак узятий окремо кожний із цих методів не може дати достатньо інформації для проектування раціональної структури БД. Тому при проектуванні БД доцільно спільно використовувати ці два підходи.

Якщо схематично представити процес проектування БД на зовнішньому рівні, то він складається з таких робіт:

1. Визначення функціональних задач ПО, що підлягають автоматизованому розв'язанню.

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

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

При опису вказується призначення задачі та її техніко-економічна сутність. Для обґрунтування необхідності її розв'язання необхідно:

• привести періодичність розв'язання задачі і термін видачі вихідної інформації;

• вказати умови, при яких припиняється автоматизоване розв'язання задачі;

• перерахувати зв'язки даної задачі з іншими задачами інформаційної системи та привести інформаційну модель взаємозв'язків задачі;

• оцінити необхідність автоматизованого розв'язання задачі в прикладній чи предметній постановці;

• описати розподіл дій між персоналом і технічними засобами при різних ситуаціях розв'язання задачі;

• привести математичний опис задачі в умовах її автоматизованого розв'язання.

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

3. Вивчення нормативно-довідкових документів. До такої документації належать класифікатори, кошториси, угоди, нормативи, законодавчі акти з податко­вої політики, планова документація тощо.

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

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

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

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

Для закріплення теоретичного матеріалу розробимо проект (модельний) БД в прикладній постановці на прикладі задачі автоматизованого обліку матеріалу (m) в одиницях виміру (o) на складі (s).

Математична постановка такої задачі може бути сформульована наступним чином:

ZZmos = Zmos + Nmos - Wmos, де:

Zmos, ZZmos - залишок матеріалу: відповідно на початок та кінець звітного періоду, Nmos - надходження, Wmos - витрати матеріалу протягом звітного періоду.

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

До документа "Приймальний акт" на отримані матеріали додаються документи:

• "ПОДАТКОВА НАКЛАДНА";

• "НАКЛАДНА".

До документа "Накладна на відпуск матеріалів" додаються документи:

• "ПОДАТКОВА НАКЛАДНА";

• "ТОВАРНО-ТРАНСПОРТНА НАКЛАДНА";

• "ДОРУЧЕННЯ";

• "УГОДА" ( при відпущені матеріалів на основі угоди).

Оскільки при проектуванні БД в предметній постановці аналізуються всі документи, а в прикладній постановці лише ті, які відповідають конкретному запиту, тому в нашому модельному проекті використовуються лише "Приймальний акт" та "Накладна на відпуск матеріалів". В додатках 2 та 3 містяться ескізи форм цих вхідних документів.

Потім складається перелік та опис вхідних повідомлень. Для нашого прикладу вони матимуть наступний вигляд (табл. 3.2):

Таблиця 3.2

Опис вхідних повідомлень

Назва вхідного повідомлення	Іденти-фікатор	Форма подання	Термін надходження	Частота надходження
Приймальний акт	pr_akt	паперовий чи магнітний носій	за 3 дні до кінця місяці	в міру формування
Накладна на відпуск матеріалів	nakl_wid	паперовий чи магнітний носій	за 3 дні до кінця місяці	в міру формування

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

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

Таблиця 3.3