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

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

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

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

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

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

Проектування БД доцільно виконувати невеликою групою з трьох-чотирьох фахівців. Керує роботою адміністратор бази даних. Різноманітність досвіду фахівців групи дозволяє всебічно опрацювати проект системи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наступна проектна процедура полягає в агрегації атрибутів - компонуванні атрибутів в об'єкти.

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

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

Одержані відношення перевіряються на відповідність третьої нормальної форми. У разі необхідності виконується процедура нормалізації.

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

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

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

Після виділення об'єктів визначаються предметні бази даних.

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

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

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

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

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

У результаті виконання цього кроку з'являється інфологічна модель у вигляді ЕR-діаграми.

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

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