При розробці фізичної моделі даних виникають питання: чи добре спроектовані таблиці? Чи правильно вибрані індекси? Наскільки багато програмного коду у вигляді трігерів і ззбережених процедур необхідно розробити для підтримки цілісності даних?

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

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

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

Критерії оцінки якості логічної моделі даних

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

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

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

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

Легкість розробки і супроводу бази даних

Швидкість виконання операцій оновлення даних (вставка, оновлення, видалення кортежів)

Швидкість виконання операцій вибірки даних

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

База даних повинна адекватно відображати предметну область. Це означає, що повинні виконуватися наступні умови:

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

Зміна полягання предметної області повинна приводити до відповідної зміни полягання бази даних

Обмеження предметної області, відображені в моделі предметної області, повинні деяким чином відображатися і враховуватися базі даних.

Легкість розробки і супроводу бази даних

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

Збережені процедури - це процедури і функції, що збережуться безпосередньо в базі даних у вигляді, що відкомпілювався, і які можуть запускатися користувачами або додатками, що працюють з базою даних. Збережені процедури звичайно пишуться або на спеціальному процедурному розширенні мови SQL (наприклад, PL/SQL для ORACLE або Transact-SQL для MS SQL Server), або на деякій універсальній мові програмування, наприклад, C++, з включенням в код операторів SQL відповідно до спеціальних правил такого включення. Основне призначення ззбережених процедур - реалізація бізнес-процесів предметної області.

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

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

Швидкість операцій оновлення даних (вставка, оновлення, видалення)

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

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