Лекція № 2
Інфологічне моделювання БД – 6 год
Етапи проектування та моделювання БД
Основи проектування БД
Етапи проектування та моделювання БД та їх цілі
Проектування БД як ітераційний процес створення моделей даних та БД
Основні завдання проектування БД
Основні підходи до проектування БД
Основні етапи проектування БД
Проектування БД та моделювання. Моделі баз даних, що застосовуються на різних етапах проектування.
Поняття та типи моделей даних. Моделі даних та концептуальне проектування
Користувацька модель бази даних
База даних як модель користувацької моделі
Концептуальна (понятійна) модель. Інфологічна (семантична) модель
Моделі реалізації БД
1. Проектування БД
1.1. Етапи проектування та моделювання БД та їх цілі
У найширшому розумінні термін “розробка БД” застосовується для опису процесу проектування БД та її реалізації. БД є сховищем інтегрованих та логічно взаємопов'язаних даних, яке є частиною інтелектуальної сисеми (ІС). Проектування БД – це проектування цього сховища, тобто створення набору описів цього сховища, достатніх для його реалізації. Головна функція БД – забезпечення ефективного прийняття рішень у тій чи іншій предметній галузі, тому ефективність проекту БД буде оцінюватися за показниками досягнення результату виконання ГФ БД у співвідношенні до витрат на це досягнення.
Ефективність проектування вимагає мінімізації кількості цих описів та обрання такого їх синтаксису, який забезпечив би найекономічніший та найшвидший доступ до даних та їх представлення у найбільш зручному для користувача вигляді.
Відповідно основна мета проектування БД полягає у створенні мінімального набору описів БД, що забезпечують ефективну реалізацію ГФ БД у межах даної ІС з урахуванням цілей та обмежень замовника (час, кошти, доступність тощо)..
Етап реалізації БД містить у собі створення структури збереження даних, завантаження інформації у БД та забезпечення управління даними.
Всі ІС мають свій життєвий цикл (System Development Life Cycle), який складається з 5 основних етапів:
планування (первинна оцінка та дослідження здійсненності);
аналіз (вимоги користувача; оцінка існуючої системи; логічне проектування системи);
детальне проектування системи (детальна специфікація системи);
реалізація (кодування, тестування і відлагодження; встановлення та налагодження);
супроводження (оцінка; обслуговування; розширення).
При цьому життєвий цикл розробки систем є скоріше ітеративним, ніж послідовним, і передбачає повернення на попередні етапи у разі отримання певних результатів на наступних.
Життєвий цикл БД своєю чергою містить 6 етапів.
Етап початкової розробки, у межах якого виконуються наступні дії:
аналіз діяльності фірми (аналіз робочого середовища, предметної галузі; аналіз цілей та завдань фірми; аналіз структури компаній, набору та ієрархії користувачів БД);
постановка задачі та окреслення обмежень (які проблема треба вирішувати, що можна і чого не можна робити, дослідження бізнес-правил (правила виконання операцій з інформацією та об'єктами, що в ній відбиваються) та їх сукупності – ділового регламенту);
визначення цілей;
визначення сфери дій (набір фрагментів предметної галузі у відповідності з експлуатаційними вимогами) та обмежень (грошові і часові ресурси тощо).
На етапі початкової розробки проектувальник досліджує такі питання, як:
у чому проблема (хто користувачі і що їм треба);
яке рішення проблеми;
яка інформація потрібна для отримання рішення.
Етап проектування БД, у межах якого виконуються наступні дії:
Інфологічне проектування (створення інфологічної об'єктної моделі);
Вибір типу концептуальної (об'єктної) моделі та відповідногих до ней моделей організації даних та типів БД і СУБД;
Логічне проектування БД зі створенням моделі типу моделі записів;
Вибір програмного забезпечення БД, у першу чергу СУБД ;
Приведення логічної моделі БД у відповідність з вимогами конкретної СУБД (перейменування сутностей та атрибутів, встановлення індексів та конкретизація типів даних, формування набору записів тощо);
Фізичне проектування.
На етапі проектування вирішуються завдання:
як структуризувати дані, щоб ефективно отримати правильні рішення;
як отримати доступ до даних;
як перетворити дані, щоб забовільнит вимоги всіх учасників проектної конфігурації – замовника (користувачів); проектувальника та наявне програмне і апаратне забезпечення.
Етап реалізації та завантаження БД, у межах якого виконуються наступні дії:
Встановлення СУБД;
Створення Бд;
Завантаження чи конвертування даних;
Етап тестування та оцінки БД, у межах якого виконуються наступні дії:
Тестування БД;
Оцінка БД і прикладних програм;
5. Етап функціонування БД, зміст якого складає організація необхідних інформаційних потоків
Етап супроводження БД, у межах якого виконуються наступні дії:
Супроводження СУБД;
Внесення змін у БД;
Розвиток БД.
Правильно спроектована БД спрощує управління даними і стає цінним постачальником інформації. Погано спроектована БД стає нагромаджувачем надлишкової інформації й утрудняє виявлення помилок у даних чи сама їх породжує. Кепський проект БД прирікає организацію, яка цю БД використовує, на банкрутство, тим самим «анулюючи» і себе, і експлуатуючу його організацію. Тому іноді говорять, що поганий проект БД сам себе «виправляє».
1.2. Проектування БД як ітераційний процес створення моделей даних та БД
Трирівневе представлення предметної області. Для успішної реалізації проекту бази даних об'єкт проектування повинен бути насамперед адекватно описаний, повинні бути побудовані повні і несуперечливі функціональні й інформаційні моделі бази даних. Проектування БД починається з аналізу і визначення границь предметної галузі, об'єкти і процеси якої підлягають відображенню в ИС відповідно до вимог замовника. У теорії проектування інформаційних систем предметну область прийнято розглядати у виді трьох представлень, тобто на трьох рівнях абстракції, що одержали назву чи схем представлень ANSI/SPARC, за назвою їхніх інститутів, що розробили. Ціль трирівневого представлення – у відділенні користувацького представлення від фізичного. Цих рівнів три:
представлення предметної області в тому вигляді, як вона реально існує і використовується безпосередніми учасниками процесів у ній (користувачами);
представлення предметної області в тому вигляді, як її сприймає людина, що проектує інформаційну систему підтримки процесів у певній предметній області (мається на увазі проектувальник бази даних)
представлення предметної області в тому вигляді, як вона може бути описана за допомогою символів.
Рівень, на якому сприймають дані користувачі (представлення даних з погляду кожного і всіх конкретних користувачів) називається зовнішнім. СУБД і ОС сприймають дані на внутрішньому рівні. Концептуальний рівень представлення даних призначений для відображення зовнішнього рівня на внутрішній і забезпечення необхідної їхньої незалежності друг від друга. Концептуальний рівень задає узагальнююче представлення БД; описує те, які дані зберігаються в БД, а також, які між ними існують зв'язки.
Концептуальний рівень підтримує зовнішнє представлення в тому сенсі, що будь-які доступні користувачу дані повинні міститися чи можуть бути обчислені на цьому рівні. Однак цей рівень не містить ніяких відомостей про методи збереження даних. Наприклад, опис сутності повинен містити відомості про типи даних атрибутів (цілочисельний, дійсний, символьний і т.д.), але не повинен включати відомостей про організацію збереження даних, наприклад, про об'єм зайнятого простору в байтах.
Внутрішній рівень дає фізичне представлення бази даних. Він показує, як інформація зберігається в БД і призначений для досягнення оптимальної продуктивності. На цьому рівні зберігається опис структур даних і окремих файлів; розподіл дискового простору для збереження даних, опис подробиць збереження записів із указівкою їхнього реального розміру в байтах, відомості про розташування записів і відомості про стискання даних і обраних методах їхнього шифрування.
Нижче внутрішнього рівня знаходиться фізичний, котрий контролюється ОС, але під управлінням СУБД.. Поділ функцій СУБД і ОС на цьому рівні нечіткий і змінюється від системи до системи. Цей рівень складається тільки з відомих ОС елементів (наприклад, покажчиків того, як реалізоване послідовний поділ і т.д.).
Схеми даних. Загальний опис БД називається схемою БД, а сукупність збереженої в ній у конкретний момент часу інформації – станом БД. Схему БД іноді називають змістом БД, а стан – деталізацією. Відповідно до трирівневої архітектури представлень про предметну галузь виділяють три основні схеми БД – зовнішню, внутрішню і концептуальну. Інакше кажучи, дані, використовувані для опису предметної галузі, представляються у вигляді трирівневої схеми (так називана модель ANSI/SPARC):

Зовнішнє представлення (зовнішня схема) даних є сукупністю вимог до даних з боку деякої конкретної функції, виконуваної користувачем. Концептуальна схема є повною сукупністю усіх вимог до даних, отриманою з користувацьких представлень про реальний світ. Вона описує всі елементи даних і зв'язку між ними, а також указує необхідні обмеження для підтримки цілісності даних. Внутрішня схема - це сама внутрішня структура бази даних, що містить визначення збережених записів, методи представлення, опису полів даних, відомості про індекси й обрані методи хеширования. При цьому внутрішня схема будується поступово, шляхом послідовного обліку вимог моделі організації даних, типу СУБД і, нарешті, конкретної СУБД до представлення даних, їхньої структури і маніпулюванню ними. Нарешті, на фізичному рівні у внутрішню схему вводяться обмеження, що накладаються конкретним апаратним забезпеченням.
Зовнішніх схем існує багато (скільки видів користувачів), концептуальних і внутрішніх (на кожнім кроці проектування)– по одній. Різниця меду ними видна з прикладу:
Проектування БД зводиться до послідовного створення набору моделей, що адекватно відображають представлення користувачів про предметну галузь у внутрішню і потім – фізичну (для неряліційних БД) схеми даних.
СУБД відповідає за установлення відповідності між цими трьома видами схем, а також за перевірку їхньої несуперечності. Іншими словами, СУБД повинна переконатися в тому, що кожну зовнішню схему можна вивести з концептуальної, а внутрішня схема відбиває концептуальну (а через неї і зовнішні) схему адекватно.
Основні завдання проектування БД
Основна мета проектування бази даних - це скорочення надмірності збережених даних, а отже, економія об'єму використовуваної пам'яті, зменшення витрат на багаторазові операції відновлення надлишкових копій і усунення можливості виникнення протиріч через збереження в різних місцях відомостей про один й той самий об'єкт. Результатом проектування БД є перетворення опису предметної галузі у внутрішню схему БД.
При проектуванні бази даних вирішуються три основних проблеми:
Проблема адекватного відображення предметної галузі та інформаційних потреб користувачів у концептуальній моделі. Цю проблему називають проблемою інфологічного проектування баз даних, на якому створюють змістовні концептуальні моделі..
Проблема знаходження способу адекватного відображення об'єктів предметної галузі в абстрактні об'єкти моделі даних так, щоб це відображення не суперечило семантиці предметної галузі, і було, по можливості, найкращим (ефективним, зручним тощо)? Цю проблему називають проблемою логічного проектування баз даних.. Ціль логічного етапу проектування - організація даних, виділених на попередньому етапі, у форму, прийняту в обраній СУБД чи СУБД обраного класу.
Проблема забезпечення ефективності виконання запитів до БД, тобто як, з урахуванням особливостей конкретної СУБД, розташувати дані у зовнішній пам'яті? Це проблема фізичного проектування баз даних. Мета цього етапу - вибір раціональної структури збереження даних і методів доступа до них.
У ході проектування БД доводиться вирішувати наступні задачі:
виявлення і представлення даних і зв'язків між ними, необхідних для всіх основних областей застосування даного додатка і будь-яких існуючих груп його користувачі;
створення моделі даних, здатних підтримувати виконання будь-яких необхідних трансакцій операцій обробки даних;
розробка попереднього варіанта проекту, структура якого дозволяє задовольнити всі основні вимоги з боку продуктивності системи.
Основні підходи до проектування БД
Існують 2 основних підходи до проектування БД – висхідний і нисхідний.
При висхідному підході робота починається із самого нижчого рівня – рівня визначення атрибутів (тобто опису властивостей елементів предметної галузі, відображуваних у БД), що на основі аналізу існуючих між ними зв'язків групуються в певні відношення між сутностями. Підхід добре підходить для проектування невеликих БД, у яких атрибутів небагато і їх легко установити відразу.
Для складних БД більш придатною стратегією є нисхідний підхід. Він починається з розробки моделей даних, утримуючих кілька високорівневих сутностей і зв'язків і полягає в поступовому переході до сутностей більш низького рівня і зв'язкам між ними. Цей підхід демонструється в концепції «сутність-зв'язок».
Найчастіше використовуються комбіновані стратегії проектування, наприклад, підхід «зсередини назовні» і «змішана стратегія проектування». Підхід «зсередини назовні» схожий на висхідний, але відрізняється від нього початковою ідентифікацією набору всіх основ