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

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

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

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

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

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

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

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

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

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

Опис реквізитів документу “Накладна на відпуск матеріалів”

Назва реквізиту	Ідентифікатор	Тип, особливості	Формат	Формула розрахунку
Назва	NM	текст	А(20)
Номенклатурний номер	NN	ціле число, унікальний	9(5)
Одиниця виміру	OW	змішані символи	X(10)
Ціна	ZN	дійсне число	9(5)
Кількість	KL	дійсне число	9(7)
Сума	SM	дійсне число, розрахунковий	9(5).9(2)	ZN*KL

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

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

· коректність схеми БД, тобто адекватне відображення модельованої ПО;

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

· ІЛМ повинна бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам АІС.

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

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

Існує два підходи до інфологічного проектування: аналіз об'єктів ПО і синтез реквізитів.

Перший підхід, який базується на аналізі ПО, рекомендується використовувати при проектуванні документальних БД, а другий - при розробці фактографічних АІС.

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

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