Проблеми проектування баз даних та їх вирішення

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

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

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

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

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

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

Концептуальне (інфологічне) проектування. Основними задачами інфологічного проектування є визначення наочної області системи і формування погляду на предметну область (ПО) з позицій співтовариства майбутніх користувачів баз даних, тобто інфологічної моделі ПО.

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

Основні підходи до створення інфологічної моделі предметної області:

• функціональний;

• наочний;

• проектування з використанням методу “сутність-звя’зок”.

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

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

Проектування з використанням методу “сутність-звя’зок” (entity-relation, ER-method) є комбінацією двох попередніх. Етап інфологічного проектування починається з моделювання предметної області. Проектувальник розбиває її на ряд локальних областей, кожна з яких (в ідеалі) включає інформацію, достатню для забезпечення запитів окремої групи майбутніх користувачів або вирішення окремої задачі (під задачі). Кожне локальне уявлення моделюється окремо, потім вони об’єднуються.

Вибір локального уявлення залежить від масштабів ПЗ. Звичайно, вона розбивається на локальні області так, щоб кожна з них відповідала окремому зовнішньому додатку і містила 6-7 сутностей.

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

Кожен зв’язок характеризується ім’ям, обов’язковістю, типом і ступенем. Розрізняють факультативні і обов’язкові зв’язки. За типом розрізняють множинні зв’язки “один до одного” (1:1), “один до багатьох” (1:n) і “багато до багатьох” (m:n).

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

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

• кожне поле повинне бути пов’язане з темою таблиці;

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

• у таблиці повинна бути присутня вся необхідна інформація;

• інформацію слід розбивати на якнайменші логічні одиниці.

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

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

Фізичне проектування. Етап фізичного проектування полягає в ув’язці логічної структури баз даних і фізичного середовища зберігання з метою найефективнішого розміщення даних, тобто відображенні логічної структури БД в структуру зберігання. Розв’язується питання розміщення збережених даних в просторі пам’яті, вибору ефективних методів доступу до різних компонентів “ фізичної бази даних ”. Результати цього етапу документуються у формі схеми зберігання на мові визначення даних (DDL). Прийняті на цьому етапі рішення роблять визначальний вплив на продуктивність системи.

Перехід від логічного до фізичного опису моделі складається з наступних кроків:

• всі прості сутності перетворюються у зв’язки, ім’я сутності стає ім’ям відношення;

• кожен атрибут стає можливим стовпцем з тим же ім’ям. Стовпці, що відповідають необов’язковим атрибутам, можуть містити NULL-значення;

• компоненти унікального ідентифікатора сутності перетворюються в первинний ключ відношення;

• зв’язки «багато до одного» стають зовнішніми ключами;

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

• вирішення проблеми наявності підтипів;

• виконання кроків щодо нормалізації отриманих зв’язків. Наявна модель знаходиться в третій нормальній формі;

• вказівка обмежень цілісності проектованої бази даних та короткий опис отриманих таблиць та їх полів.

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