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

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

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

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

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

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

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

• Задіювати якомога більше обмежень на колонки реляційних таблиць для реалізації правил обробки даних без процедурного коду.

• Задіювати тригери бази даних для процедурного введення правил обробки даних, зокрема, для підтримки посилальної цілісності даних.

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

• Використовувати вимоги продуктивності при прийнятті остаточного вибору про розподіл коду.

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

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

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

Прикладами правил для даних є наступні:

• Стать людини може бути або чоловічою або жіночою. Це правило може бути введене за допомогою обмеження CHECK у визначенні колонки таблиці бази даних.

• Кожне замовлення має бути призначене для одного і тільки одного покупця. Це правило для даних можна ввести за допомогою обмежень PRIMERY KEY або NOT NULL.

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

Прикладами правил для процесів є наступні:

• Розмір зарплати не повинен перевищувати 160000 рублів. Це правило слід реалізувати в застосуванні, в нім нічого не говориться про вміст і визначення бази даних. Воно виражає твердження про те, що може бути, а чого не може бути.

• Тільки керівник може санкціонувати виплату преміальних. У момент санкціонування платежу застосування повинне перевірити наявність у користувача належних прав, тобто чи керівник він.

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

Прикладами правил для інтерфейсу є наступні:

• Усі коди валют повинні роз'яснюватися. Це специфікація вимог замовника до візуалізації кодів валют.

• Номери відділів і підрозділів не повинні показуватися. Це також є вимогою замовника системи відносно візуалізації даних в застосуванні.

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

Усі торговельні операції, вироблювані в неділю, враховуються в бухгалтерських книгах за наступний понеділок.

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

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

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

Зупинимося коротко на основних принципах розміщення бізнес-логіки в модулях застосування бази даних.

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