1.6.2. Процедури логічного проектування

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

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

2. Визначення набору таблиць виходячи з ER-моделі і їх документування. Для кожної сутності ER-моделі створюється таблиця. Ім'я сутності – ім'я таблиці. Здійснюється формування структури таблиць на підставі викладених в параграфі 1.4 правив. Встановлюються зв'язки між таблицями за допомогою механізму первинних і зовнішніх ключів. Структури таблиць і встановлені зв'язки між ними документуються.

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

4. Перевірка логічної моделі даних на предмет можливості виконання всіх транзакцій, передбачених користувачами. Транзакція – це набір дій, що виконуються окремим користувачем або прикладною програмою з метою зміни вмісту бази даних. Так, прикладом транзакції в проекті БАНК може бути передача можливості розпоряджатися рахунками деякого клієнта іншому клієнтові. В цьому випадку в базу даних потрібно буде внести відразу декілька змін. Якщо під час виконання транзакції відбудеться збій в роботі комп'ютера, то база даних опиниться в суперечливому стані, оскільки деякі зміни вже будуть внесені, а інших ще немає. Тому всі часткові зміни повинні бути скасовані для повернення бази даних в колишній несуперечливий стан.

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

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

· обов'язкові дані. З'ясовується, чи є атрибути, які не можуть мати Null-значень;

· обмеження для значень атрибутів. Визначаються допустимі значення для атрибутів;

· цілісність сутності. Вона досягається, якщо первинний ключ сутності не містить Null-значень;

· посилальна цілісність. Вона розуміється так, що значення зовнішнього ключа повинне бути обов'язково присутнім в первинному ключі одного з рядків таблиці для батьківської сутності;

· обмеження, бізнес-правилами, що накладаються. Наприклад, у випадку з проектом БАНК може бути прийняте правило, що забороняє клієнтові розпоряджатися, скажімо, більш ніж трьома рахунками.

Зведення про всі встановлені обмеження цілісності даних поміщаються в словник даних.

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