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

Життєвий цикл БД : проектування - реалізація - використання - експлуатація.

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

Сама предметна область
Модель предметної галузі
Логічна модель даних
Фізична модель даних
Власне база даних та програми

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

Модель предметної області. Модель предметної області - це знання про предметної області. Знання можуть бути як у вигляді неформальних знань у мозку експерта, так і виражені формально за допомогою будь-яких засобів. Як такі засоби можуть виступати текстові описи предметної області, набори посадових інструкцій, правила ведення справ у компанії тощо. Досвід показує,що текстовий спосіб представлення моделі предметної області украй неефективний. Набагато більш інформативними і корисними розробки баз даних є описи предметної області, виконані з допомогою спеціалізованих графічних нотаций. Є велика кількість методик опису предметної галузі. З найбільш відомих можна назвати методику структурного аналізу SADT і засновану на ньому IDEF0, діаграми потоків даних Гейна-Сарсона, методику об'єктно-орієнтованого аналізу UML, та ін Модель предметної області описує швидше процеси, що відбуваються в предметній області та дані, що використовуються цими процесами. Від того, як правильно змодельована предметна область, залежить успіх подальшої розробки додатків.

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

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

Логічна модель даних є початковим зразком майбутньої бази даних. Логічна модель будується у термінах інформаційних одиниць, але не прив'язки до конкретної СУБД. Більше того, логічна модель даних необов'язково має бути виражена засобами саме реляційної моделі даних. Основним засобом розробки логічної моделі даних зараз є різні варіанти ER-діаграм (Entity-Relationship, діаграми сутність-зв'язок). Одну й ту саму ER-модель можна перетворити як на реляційну модель даних, і у модель даних для ієрархічних і мережевих СУБД, чи постреляционную модель даних. Проте, т.к. ми розглядаємо саме реляційні СУБД, можна вважати, що логічна модель даних нам формулюється у термінах реляційної моделі даних.

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

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

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

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

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

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

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

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