Принципи та етапи проектування баз даних

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

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

- БД повинна задовольняти актуальним інформаційним потребам;

- дані перед розміщенням у базі повинні перевірятися на досто­вірність;

- доступ до даних різних рівнів повинні мати особи з відповід­ними повноваженнями;

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

Основними етапами проектування є:

1. Визначення мети створення БД.

2. Розробка технічного завдання (ТЗ).

3. Проектування структури БД.

4. Створення експериментального варіанту БД.

5. Аналіз ефективності БД.

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

Як правило, технічне завдання (ТЗ) на проектування БД повинен видавати замовник. Однак, на практиці це відбувається не завжди, бо не кожен із замовників володіє, хоча б у загальних рисах, відповідною термінологією та знає можливості сучасних СУБД. Тому проектувальники БД допомагають замовникам у створенні ТЗ, використовуючи при цьому такі підходи:

- замовнику демонструють роботу подібної БД, а потім узгод­жують можливі відмінності;

- якщо подібна БД відсутня, вивчають предметну область, мо­дель якої буде реалізована у вигляді бази, детально з’ясову­ють потреби замовника та спільно з ним створюють ТЗ.

У технічному завданні вказують:

- дані бази, які є вхідними, та документи, які становлять кінце­вий продукт роботи БД;

- над якими даними слід виконувати нетривіальний аналіз, що вимагає алгоритмізації, або якісь складні обчислення;

- вимоги безпеки, яким повинна відповідати БД;

- інші специфічні вимоги до БД.

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

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

- інформація в таблицях не повинна дублюватися, – якщо зазна­чені відомості зберігатимуться в одному полі однієї таблиці, то їх редагування (заміна) буде відбуватися лише у цьому по­лі, тобто лише в одному місці;

- бажано, щоб дані кожної з таблиць бази, стосувалися лише однієї теми;

- не рекомендується розміщувати в таблицях дані, що утворю­ються внаслідок обчислень;

- інформацію про об’єкт слід “розбивати” на мінімальні одини­ці. Наприклад, поштові реквізити краще розміщувати в окре­мих полях: “Індекс”, “Місто, селище”, “Адреса”.

Закріпивши поля за таблицями, у кожній з них визначають ключове поле. Таким повинно бути поле, дані в якому повторю­ватися не можуть. Наприклад, у таблиці з даними про студентів ключовим полем призначають поле з індивідуальним шифром студента. Якщо в таблиці поля, котрі можна використати як клю­чові, відсутні, то завжди можна ввести додаткове поле типу “Счет­чик”. Завершують “паперовий” етап проектування БД створенням схеми даних, у якій на папері за допомогою олівця креслять лінії зв’язку між таблицями. У реляційних БД між таблицями можливі такі зв’язки:

- один-до-одного. При такому зв’язку кожному елементу поля першої таблиці відповідає один елемент відповідного поля іншої таблиці;

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

- багато-до-багатьох – тип зв’язку, що дає змогу встановити відношення між кількома елементами однієї таблиці та кіль­кома елементами іншої, і навпаки;

- багато-до-одного – тип зв’язку, коли кільком елементам поля першої таблиці відповідає лише один елемент відповідного поля іншої таблиці.

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

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