1. Концептуальне проєктування

Проєктування бази даних здійснюється у три етапи:

  1. концептуальне проектування;
  2. логічне проектування;
  3. фізичне проектування.

Мета етапу концептуального проектування — створення концептуальної моделі даних виходячи з уявлень користувачів про предметну область. Для її досягнення виконується низка послідовних процедур. Приклад сутнісної (концептуальної) схеми:

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

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

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

4. Визначення атрибутів та їх документування. Виявляються всі атрибути, що описують сутність створеної моделі ER. Кожному атрибуту надається осмислене ім'я, зрозуміле користувачам. Про кожен атрибут у словник даних містяться такі відомості:

  • ім'я атрибуту та його опис;
  • тип та розмірність значень;
  • значення, прийняте для стандартного атрибута (якщо таке є);
  • може атрибут мати NULL-значення;
  • чи є атрибут зіставним, і якщо це так, то з яких простих атрибутів він складається. Наприклад, атрибут "П.І.Б. клієнта" може складатися з простих атрибутів "Прізвище", "Ім'я", "По батькові", а може бути простим, що містить єдині значення, як-то "Сидорський Євген Михайлович". Якщо користувач не потребує доступу до окремих елементів "П.І.Б.", то атрибут представляється як простий;
  • чи є атрибут розрахунковим, і якщо це так, то як обчислюються його значення.
Java-університет

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

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

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

2. Логічне проєктування

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

Приклад логічної схеми БД.

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

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

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

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

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

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

  • обов'язкові дані. З'ясовується, чи є атрибути, які не можуть мати значення NULL;
  • обмеження для значень атрибутів. Визначаються допустимі значення для атрибутів;
  • цілісність сутностей. Вона досягається, якщо первинний ключ сутності не містить значення NULL;
  • посилальна цілісність. Вона розуміється так, що значення зовнішнього ключа має обов'язково бути присутнім у первинному ключі одного з рядків таблиці для батьківської сутності;
  • обмеження, що накладаються бізнес-правилами. Наприклад, у випадку з проєктом БАНК може бути правило, яке забороняє клієнту розпоряджатися, скажімо, більш ніж трьома рахунками.

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

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

3. Фізичне проєктування

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

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

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

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

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

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

Прийняті рішення щодо викладених питань документуються.

4. Розробка стратегії захисту бази даних. База даних є цінним корпоративним ресурсом, і організації її захисту приділяється велика увага. Для цього проєктувальники повинні мати повне та ясне уявлення про всі засоби захисту, що надаються обраною СУБД.

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

Рішення щодо внесення будь-яких змін до функціонуючої бази даних мають бути обдуманими та всебічно зваженими.