1. Технологія проектування іс на основі баз даних

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

Існує два підходи щодо побудови 1С на основі бази даних:

• створюються прикладні бази даних у складі ІС, орієнтовані на обчислювальні прикладні задачі. Наприклад, створюється БД для обліку та контролю надходження матеріалів;

• як інформаційна основа ІС створюються проблемні бази да­них, орієнтовані на конкретний клас даних. Наприклад, створює­ться предметна база «Матеріали», призначена для використання у різних прикладних задачах.

Стосовно до ІС підприємств краще використовувати предмет­ні БД.

Проектування БД доцільно виконувати невеликою групою з

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

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

Перший етап призначений для підготовки робіт і установлен­ня контактів між розробниками та замовниками-користувачами.

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

На третьому етапі вибору СУБД проектувальник здійснює: виявлення зовнішніх обмежень, виділення СУБД-претендентів, моделювання бази даних для кожної виділеної СУБД, порівняль­ний аналіз одержаних моделей бази даних.

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

Для побудови інфологічної моделі найчастіше використову­ється методика, що базується на моделі «сутність — зв'язок» або «об'єкт — зв'язок». Така модель визначається термінами: об'єкт, атрибут, структурний зв'язок, запитальний зв'язок.

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

У результаті формування загального уявлення про проблемну сферу проектувальник має дістати відповіді на такі запитання:

1. Який перелік фрагментів проблемної сфери, що охоплює розроблювана ІС?

2. Які фрагменти проблемної сфери необхідно включити при подальшому розширенні ІС?

3. Яке загальне уявлення про кожний фрагмент?

4. Які інформаційні потреби кожного фрагмента (зміст і харак­теристики інформації)?

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

6. Який перелік користувачів? Як часто вони звертаються за інформацією?

7. Яка існує технологія накопичення обробки інформації у проблемній сфері?

8. Яка технічна база для реалізації інформації, частота її над­ходження, швидкість обробки, обсяг, інформаційні потоки?

9. Які і де існують «вузькі місця» в наявній технології, що по­яснюють потребу у створенні ІС?

Цю складну проектну процедуру можна подати послідовністю наступних робіт:

1. Виділити у кожній функціональній сфері підмножини процесів, які можуть вивчатися окремими групами користувачів.

2. Дати визначення кожній підмножині процесів.

3. Розглянути підмножини процесів разом з аналітиками-користувачами й уточнити їх.

4. Побудувати матрицю відображення підмножини процесів на існуючій організаційній структурі із зазначенням ступеня від­повідальності за процес.

5. Розподілити сфери процесів серед аналітиків-користувачів для виконання подальших робіт.

З'ясувавши вимоги до розроблюваної системи, проектуваль­ник має дати відповіді на такі запитання:

1. Яка технічна база для реалізації ІС?

2. Яка загальна система існуючої інформаційної системи і пе­редбачувана взаємодія ІС з її компонентами?

3. Які вимоги ставляться до експлуатаційних характеристик ІС (вимоги до часу, ступеня надійності, вміння настроюватися на можливі зміни у проблемній сфері)?

4. Якою має бути технологія функціонування ІС? Як надходитиме нова інформація? Яка передбачувана взаємодія різних груп користувачів із системою? Як інформація коригуватиметься? Які служби нестимуть відповідальність за вірогідність вихідної ін­формації?

Другий крок розпочинається з ознайомлення проектувальника з усіма різновидами вхідних і вихідних повідомлень: документа­ ми, довідками, запитаннями тощо.

Перше проектне рішення полягає у виборі типу створюваної ІС: фактографічна, документальна чи документально-фактогра­фічна.

Наступна проектна процедура — це агрегація атрибутів, ком­понування атрибутів в об'єкти.

Для кожного об'єкта визначається первинний ключ. Якщо його для деякого об'єкта не можна виділити з його атрибутів, то склад атрибутів необхідно поповнити. В окремому випадку проектувальник може ввести власний Ідентифікатор екземпля­рів об'єкта, наприклад порядковий номер. Так, нехай є об'єкт СПІВРОБІТНИК, до складу якого входять атрибути ПРІЗВИЩЕ, ПОСАДА, ОКЛАД. Жоден з цих атрибутів або їхня сукупність не придатні для первинного ключа. Кандидатом на первинний ключ може бути, наприклад, табельний номер. Одержані відношення перевіряються на відповідність третьої нормальної форми. У разі необхідності виконується процедура нормалізації.

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

Під час кодування в інфологічну схему вводиться додатковий об'єкт КЛАСИФІКАТОР, що містить новий атрибут — короткий код і старий атрибут — текстове значення. У всіх раніше виділе­них об'єктах текстові значення атрибута змінюються на код.

У процесі зовнішнього кодування може бути виділено кілька нових об'єктів типу КЛАСИФІКАТОР для різних атрибутів (на­приклад, класифікатор товарів, посад, одиниць виміру та ін.). Для таких об'єктів виконується процедура узагальнення і в результаті в інфологічній схемі залишиться один об'єкт КЛАСИФІКАТОР з атрибутами: ВИД класифікатора (товари, посади тощо), КОД і ТЕКСТОВЕ ЗНАЧЕННЯ. Після виділення об'єктів визначаються предметні бази даних.

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

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

Приклад 1. Запит «Для всіх ПІДРОЗДІЛІВ видати списки СПІВРОБІТНИКІВ» є множинним і означає, що послідовно для кожного екземпляра об'єкта ПІДРОЗДІЛ обираються підлеглі ек­земпляри об'єкта СПІВРОБІТНИК.

Приклад 2. Редагування запиту. Першочергово запит був сфор­мульований так: «Визначити номенклатуру продукції підприємс­тва із зазначенням використаних матеріалів». Перефразований же запит «Для даного ПІДПРИЄМСТВА видати список ВИРОБІВ із зазначенням для ВИРОБУ використаних МАТЕРІАЛІВ» має одиничний режим.

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

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

Об'єкти ПІДПРИЄМСТВО, УГОДА, ПОСТАЧАННЯ є уза­гальненими; вони повинні мати атрибут, що визначає, до якого процесу відносяться відповідні екземпляри — до завантаження виробів чи до відпуску.