•  4.1 Аналіз функціональної моделі предметної області бази даних
• 4.2 Визначення функцій
•  4.3 Відображення функцій у модулі
•  4.4 Системні модулі
•  4.5 Розміщення логіки обробки
•  4.6 Загальні принципи розроблення специфікацій модулів

 4.1 Аналіз функціональної моделі предметної області бази даних

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

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

При розгляді ієрархії функцій розробникові БД варто звернути увагу на такі моменти:

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

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

4.2 Визначення функцій

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

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

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

При виконанні аналізу функцій корисно мати деяку таблицю (матрицю) "Функція-Сутність", яка повинна дати відповідь на наступні питання:

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

Процес аналізу взаємодії функції й сутності прийнято позначати абревіатурою CRUD (Create, Reference, Update, Delete - створення, посилання, модифікація, видалення).

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

 4.3 Відображення функцій у модулі

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

Як правило, вирішення завдання відображення функцій у модулі виконується в чотири етапи:

1. Аналіз роботи функції.
2. Побудова моделі сутностей, що підтримує ці функції.
3. Почати проектування фізичної структури зі створення схеми, що підтримує розроблену модель сутностей.
4. Завершити проектування розробкою специфікацій модулів, які реалізують функції на запропонованій схемі БД.

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

При відображенні функцій у модулі необхідно отримати схему, що ставить у відповідність кожної функції певний модуль.

 4.4 Системні модулі

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

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

Розробник БД самостійно вирішує питання розроблення специфікації системних модулів.

 4.5 Розміщення логіки обробки

Під час розроблення серверного коду необхідно дотримуватись простих правил:

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

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

Правила для даних формулюють вимоги, якім повинні задовольняти дані, діють для кожного екземпляру даних та виводяться з моделі даних.

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

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

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

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

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

 4.6 Загальні принципи розроблення специфікацій модулів

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

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

Специфікація повинна обов’язково містити такі компоненти:

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