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

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


Концептуальне проектування передбачає виконання наступних кроків:
аналіз вимог до БД із боку користувачів і побудову так називаної користувацької моделі (вивчення і систематизація інформації про користувачів, їхні інформаційні потреби, джерела інформації, реальні інформаційні потоки і бізнес-правила);
виявлення основних об'єктів (сутностей), що підлягають відображенню в моделі, виходячи зі специфіки предметної області, цілей замовника і наявного ділового регламенту;
визначення атрибутів сутностей і їхнє приведення у відповідність із вимогами майбутньої об'єктної моделі;
визначення зв'язків між сутностями і властивостей сутностей;
вибір типу інфологічної (об'єктної) моделі і її побудова. Найчастіше це модель «сутність – зв'язок» (ER-діаграма);
перевірку моделі даних;
побудову розподіленої моделі даних;
вибір моделі організації даних у концептуальній схемі.
Логічне проектування – процес створення моделі використовуваної на підприємстві інформації з урахуванням обраної моделі організації даних, але незалежно від типу цільової СУБД і інших фізичних аспектів реалізації. Ціль етапу – створення логічної моделі даних на рівні моделі записів для досліджуваної частини підприємства шляхом уточнення і перетворення концептуальної моделі з урахуванням особливостей обраної організації даних у цільовий СУБД (наприклад, реляційна чи мережева модель). Для реляційних моделей на цьому етапі фіксується набір і структура таблиць, що представляють сутності, визначаються ключі і проводиться нормалізація таблиць.
Якщо концептуальна модель даних не залежить від будь-яких фізичних аспектів реалізації, то логічна модель даних створюється на основі обраної моделі організації даних у цільовий СУБД. На цьому етапі вже повинне бути відомо, яка СУБД буде використовуватися в якості цільової – реляційна, мережева, ієрархічна чи об'єктно-орієнтована. Однак на цьому етапі ігноруються всі інші аспекти обраної СУБД – наприклад, будь-які аспекти фізичної організації її структур збереження даних і побудови індексів.
У процесі розробки логічна модель постійно тестується і перевіряється на відповідність вимогам користувачів. Для перевірки коректності логічних моделей використовуються спеціальні вимоги. Наприклад, для реляційних моделей – це метод нормалізації. Результатом логічного проектування є організація даних, виділених на попередньому етапі проектування у форму, прийняту для моделі організації даних в СУБД обраного типу. Визначаються також зовнішні обмеження по використанню СУБД.
Логічна модель є основним джерелом інформації на етапі фізичного проектування, а також полегшує експлуатацію і супровід БД, тому що логічна модель дозволяє наочно представити будь-які внесені в БД зміни й оцінити їхній вплив на прикладні програми і використання даних
Фізичне проектування – це процес створення опису реалізації БД на вторинних запам'ятовуючих пристроях із указівкою структур збереження і методів доступу, використовуваних для організації ефективної обробки даних. Фізичний етап проектування забезпечує вибір раціональної структури збереження даних і методів доступу до них, виходячи з арсеналу методів і засобів, що надаються розроблювачу конкретної СУБД.
Логічна модель даних залежить тільки від прийнятої в СУБД моделі організації даних (реляційна, мережева тощо), фізична – від конкретної СУБД, з вибору якої власне і починається етап фізичного проектування. Між логічним і фізичним проектуванням існує нерозривний зворотний зв'язок: рішення, прийняті на етапі фізичного проектування для підвищення продуктивності системи можуть впливати на структуру логічної моделі даних.
Основною метою фізичного проектування БД є опис способу фізичної реалізації логічного проекту БД. У випадку реляційної моделі даних під цим мається на увазі наступне:
створення набору реляційних таблиць і обмежень на них на основі інформації, представленої в глобальній логічній моделі даних;
визначення конкретних структур збереження даних і методів доступу до них, що забезпечують оптимальну продуктивність системи з БД;
розробка засобів захисту створюваної системи.
З погляду трирівневої схеми даних ANSI/SPARC концептуальне проектування - збір, аналіз і редагування вимог до даних, що забезпечує перехід від зовнішньої до концептуальної схеми даних.. Для цього здійснюються наступні заходи:
обстеження предметної області, вивчення її інформаційної структури
виявлення усіх фрагментів, кожний з який характеризується користувацьким представленням, інформаційними об'єктами і зв'язками між ними, процесами над інформаційними об'єктами
моделювання й інтеграція всіх представлень
По закінченню даного етапу одержуємо концептуальну модель, інваріантну до структури бази даних. Найчастіше вона представляється у вигляді моделі "сутність-зв'язок".
Логічне проектування полягає у перетворенні вимог до даних у структури даних. На виході одержуємо СУБД-орієнтовану структуру бази даних і специфікації прикладних програм. На цьому етапі часто моделюють бази даних стосовно до різних СУБД і проводять порівняльний аналіз моделей. Фізичне проектування передбачає визначення особливостей збереження даних, методів доступу тощо.
Різницю рівнів представлення даних у ході проектування показано в табл. 1.
Таблиця 1.
Представлення даних на різних фазах проектування
КОНЦЕПТУАЛЬНИЙ РІВЕНЬ
сутності
атрибути
зв'язки
Представлення аналітика

ЛОГІЧНИЙ РІВЕНЬ
записи
елементи даних
зв'язку між записами
Представлення програміста

ФІЗИЧНИЙ РІВЕНЬ
групування даних
індекси
методи доступу
Представлення адміністратора

В ідеалі фази концептуального і логічного проектування великих систем варто відокремлювати від фази їхнього фізичного проектування. На це є кілька причин:
вони зв'язані з цілком різними аспектами системи: що робити і як робити;
вони виконуються в різний час, оскільки зрозуміти, що треба зробити, треба до того, як вирішити, як це зробити;
вони вимагають зовсім різних навичок і умінь, якими звичайно володіють різні люди.
2. Проектування БД та моделювання. Моделі баз даних, що застосовуються на різних етапах проектування.
2.1. Поняття та типи моделей даних. Моделі даних та баз даних.
Висока продуктивність СУБД дозволяє ефективно експлуатувати дані у тому випадку, якщо структури даних коректні з точки зору даної СУБД та вимог користувача. Тому проектування БД є основним етапом створення БД. Процес проектування БД поля гає у послідовному створенні моделей на різних рівнях абстракції. Модель даних – це інтегрований набір понять для опису даних, зв'язків між ними й обмежень, що накладаються на дані в деякій організації.
Модель даних можна представити як сполучення трьох зазначених нижче компонентів:
структурна частина, тобто набір правил, по яких може бути побудована БД;
керуюча (маніпуляційна) частина. Ця частина визначає набори допустимих операцій з даними (сюди відносяться операції відновлення і добування даних, а також зміни структури бази даних);
набір обмежень підтримки цілісності даних (необов'язково), що гарантують коректність використовуваних даних.
Мета побудови моделі даних полягає в представленні даних у зрозумілому вигляді. Якщо таке представлення можливо, модель даних можна буде легко застосувати при проектуванні БД.
Модель бази даних – це сукупність логічних конструкцій, що застосовується для представлення структури даних та відношень між ними всередині БД. Моделі баз даних підрозділяються на дві категорії: концептуальні моделі та моделі реалізації.
Національний інститут стандартизації США виділяє три різних моделі даних у відповідності з рівнями абстракції: концептуальну, зовнішню та внутрішню. Для відбиття проблем реалізації БД, специфічних для обраної СУБД у внутрішній моделі, до цих рівнів абстракції додається ще один – фізичний. Класифікація НІС США випливає з трьох рівнів абстрагування представлення предметної галузі ANSI-SPARC Для відображення архітектури ANSI-SPARC можна ідентифікувати три основні зв'язані моделі даних:
зовнішню модель даних, що відображає представлення кожного існуючого в організації типу користувачів, що іноді називають предметною областю (Universe of Discourse – Uo) чи користувацькою моделлю (User Model);
концептуальну модель даних, що відображає узагальнене представлення про дані, незалежне від типу обраної СУБД. При цьому виділяють інфологічну, чи власне концептуальну модель, що не залежить від типу обраної СУБД узагалі, і логічну, котра відбиває логічне представлення про дані у вигляді, адекватному моделі організації даних у СУБД визначеного типу, але не залежить від конкретної СУБД (тобто це може бути будь-яка СУБД реляційного типу – Access, FoxPro, DB2 тощо).;
внутрішню модель даних, що відображає концептуальну схему певним чином, зрозумілим обраній цільовій СУБД.
На етапі інфологічного моделювання формують користувацьку та інфологічну об'єктну модель БД, на етапі логічного проектування – моделі реалізації БД на рівні моделей записів, на етапі фізичного проектування – фізичну модель БД.
2.2. Користувацька модель бази даних
Користувацька модель даних. Первинний етап проектування довільної БД – це створення моделі даних в розумінні користувача, або користувацької моделі даних (user data model), чи як його ще називають, моделювання даних. Як при низхідному, так і при висхідному проектуванні цей етап містить виявлення вимог споживачів БД, (наприклад, методом опитування, анкетування, спостереження за діяльність підприємства, вивчення його документації або застосування досвіду аналогічних систем) реєстрацію цих вимог і побудову моделі даних та прототипів на основі цих вимог.
Така модель показує:
які об’єкти повинні зберігатися в БД;
яким чином вони мають бути описані (структуровані);
як вони мають бути пов’язані між собою.
Тобто модель відбиває дані через:
їх склад (набір об’єктів – елементів БД);
їх структуру (набір характеристик, через які описані об’єкти);
взаємозв’язки між ними, які дозволяють встановити вплив зміни одного з об’єктів на інші.
Вимоги споживача БД до моделі даних для споживача (користувача) БД найлегше сформулювати у вигляді результатів, які він хоче отримати в результаті роботи з БД, наприклад, у вигляді форм звітів.
Процес моделювання суттєво ускладнюється у випадках так званих багатокористувацьких систем, оскільки різні користувачі хочуть отримувати різні результати від роботи з БД, що еквівалентно різним моделям даних у представленні різних користувачів. Ці моделі можуть виявитися неузгодженими між собою і з вимогами до процесу проектування БД, що вимагає знаходження в процесі проектування способів усунення цих неузгодженостей.
Таким чином, користувацьку модель даних можна визначити як інтегровану модель вимог до даних (requirements data model). Ця модель є представленням вимог користувача до структури і зв’язку об’єктів, які мають зберігатися в БД. Звідси очевидно, що побудова користувацької моделі розбивається на ряд етапів:
ідентифікацію типу БД стосовно кількості категорій обслуговуваних споживачів (одно чи багатокористувацька модель);
виявлення вимог користувача (чи користувачів – у випадку багатокористувацької моделі) до БД в термінах користувачів;
формування вимог користувача (користувачів) до БД в термінах моделювання даних розробником БД;
у випадку багатокористувацьких БД - виявлення неузгодженостей чи суперечностей у вимогах різних користувачів до БД;
виявлення структури об’єктів моделі та зв’язків між ними.
Ідентифікація типу БД стосовно кількості категорій та кола споживачів. Ідентифікація типу БД стосовно кількості категорій споживачів та кола споживачів вимагає окреслення кола споживачів БД і визначення факту ідентичності чи розбіжності їх вимог до БД. Для виявлення кола споживачів можна провести паспортизацію можливих споживачів, ідентифікувавши категорію споживачів, дані, які їх цікавлять, періодичність звертання до бази, розуміння сутності даних, характер звертання (введення, отримання даних, їх аналіз, вибір окремих даних) тощо.
Коло можливих споживачів випливає з функцій даних, що зберігаються в БД, та результатів їх застосування, обробки, перетворення тощо.
Коло актуальних та потенційних споживачів БД може бути представлене у вигляді переліку або відповідної таблиці (табл. 2).
Таблиця 2.
Коло споживачів БД
Категорія споживачів
Дані, що цікавлять
Операції з даними
Періодичність та права доступу






Модель вимог споживача до БД. Відповідно до своєї специфіки кожна з категорій споживачів БД висуває певні вимоги до цієї БД. Набір цих вимог може бути зведений у таблицю (табл. 3).
Таблиця 3
Набір вимог різних груп користувачів до БД
Категорія споживачів
Мета (результат) застосування БД




Відповідно до цих вимог у БД мають міститися певні об’єкти та відношення між ними, що забезпечують виконання цих вимог.
При розробці моделі БД слід також врахувати, що кожна проектована БД має задовольняти вимогам до певного, обумовленого стандартами ІSO переліку характеристик БД, зокрема вимозі повноти ідентичності даних, що забезпечує функціональну придатність БД та практичність БД, зокрема, зручність використаних всіма категоріями користувачів.
Якщо отримана інформація недостатньо добре структурується такими простими таблицями, доводиться застосовувати спеціальні методи створення специфікацій вимог, серед яких виділяють технологію структурного аналізу і проектування (SAD – Structured Analysis and Design); діаграми потоков даних (DFD – Data Flow Diagrams) та графіки «вхід-процес-вихід» (HIPO – Hierarchical Input Process Output)..
Для багатокористувацьких баз даних необхідно далі виділити протиріччя між вимогами до даних з боку різних груп споживачів. Крім того, для всіх БД слід виділити протиріччя (якщо вони існують) між типом і способом надходження даних та вимогами користувачів до них, а також ідентифікувати можливі помилки, що можуть вноситися у БД з боку оператора. Для отримання гарантій несуперечливості вимог застосовуються CASE-засоби проектування БД.
2.3. База даних як модель користувацької моделі
Всі обмеження файлових систем є наслідком того, що визначення даних міститься усередині додатків, а не зберігається окремо і незалежно від них, а також того, що крім додатків не передбачено ніяких інших інструментів доступу до даних і їхньої обробки. Усунення цих обмежень --при іншому підході, що одержав назву БД.
База даних – це спільно використовуваний набір логічно зв'язаних даних і їхніх описів, призначений для задоволення інформаційних потреб організації. Це єдине, велике сховище даних, що одноразово визначається, а потім використовується спільно багатьма користувачами з різних підрозділів. Замість розрізнених файлів усі дані зібрані з мінімальною часткою надмірності. БД уже не належить одному відділу, а є загальним корпоративним ресурсом. Оскільки БД зберігає не лише дані, але і їхні описи, її іноді називають набором інтегрованих записів із самоописом.
Підхід БД заснований на тому, що структура даних відокремлюється від додатка, що звертається до даних, і зберігається окремо. Додавання чи зміна структур даних не впливає на роботу додатків, крім тих, що залежать безпосередньо від змінюваних компонентів.
Логічна зв'язність даних забезпечується виділенням у ході побудови інформаційних потреб користувачів сутностей, атрибутів і зв'язків. Сутність (entity) – це окремий тип об'єкта, який треба представити в БД; атрибут (attribute)– конкретна його властивість, а зв'язок (relationship)– це те, що поєднує кілька сутностей, показує їх взаємний вплив.
База даних являє собою модель, але не деякої частини реальності, а користувацької моделі (user model) цієї реальності. База даних певної бізнес-системи є моделлю того, як керівники бізнесу уявляють собі свій бізнес, які факти, об'єкти, тимчасові рамки вони вважають важливими. Ступінь деталізації опису даних та структури зв’язків між ними у БД, залежить від того, яка інформація необхідна.
2.4. Концептуальна (понятійна) модель. Інфологічна (семантична) модель
Мета інфологічного етапу проектування полягає в одержанні концептуальних (семантичних) моделей, що відбивають предметну область і інформаційні потреби користувачів, поняття про предмети, факти і події, якими буде оперувати дана інформаційна система.
Концептуальна (понятійна) модель відбиває логічну природу представлених даних, представлення про дані з погляду основних користувачів. Ця модель відбиває семантику даних, тобто основні логічні об'єкти (сутності) моделі даних, та зв'язки між ними, необхідні та достатні для ефективного застосування інформації з точки зору користувача. Концептуальна модель задає структуру даних на рівні “сутність-зв'язок”; відповідно до концептуальних моделей відносять моделі “сутність-зв'язок” (ER-моделі), у яких об'єкт (сутність) задається її атрибутами, та об'єктно-орієнтовані моделі, у яких об'єкт складається з атрибутів та методів. Оскільки створення концептуальної моделі є метою інфологічного етапу проектування БД, то цю модель деколи називають інфологічною. Деколи як окремий етап інфологічного проектування виділяють побудову користувацької моделі, тобто опису вимог до змісту та операцій з даними з точки зору користувачів БД.
На етапі інфологічного проектування, тобто на зовнішньому та концептальному рівнях представлення даних застосовуються так звані об'єктні моделі (object based) даних.
При побудові об'єктних моделей застосовуються такі поняття, як сутність, атрибут та зв'язок. Сутність – це окремий елемент (співробітник, товар, поняття, подія тощо), бізнес-системи, що підлягає представленню у БД. Атрибут – це властивість, що описує певний аспект об'єкту і підлягає фіксації у БД. Зв'язок – це асоціативне відношення між сутностями.
Найпоширенішими типами об'єктних моделей є:
модель "сутність-зв'язок" (entity-relationship model, ER - model);
семантична модель;
функціональна модель (застосовується у стандарті IDEFO);
об'єктно-орієнтована модель.
Як основний інструмент для побудови семантичних моделей даних та уніфікованого представлення даних, незалежного від реалізуючого його програмного забезпечення, на етапі інфологічного проектування найчастіше застосовується неформальна модель "сутність-зв'язок" (entity-relationship model, ER - model). Модель "сутність-зв'язок" ґрунтується на опорній семантичній інформації про реальний світ і призначена для логічного представлення даних у контексті їхнього взаємозв'язку з іншими даними. З моделі "сутність-зв'язок" можуть бути породжені всі існуючі моделі даних (ієрархічна, мережна, реляційна, об'єктна), тому вона є найбільш загальною. Зокрема, об'єктно-орієнтована модель розширює визначення сутності з метою включення у нього не лише атрибутів, що описують стан об'єкту, але й дій, які з ним пов'язані, тобто описують його поведінку. У цьому випадку говорять про те, що об'єкт інкапсулює стан і поведінку.
2.5. Моделі реалізації БД
Модель реалізації, на відміну від концептуальної, націлена на відбиття способу представлення (синтаксису) даних у БД. Вона відбиває те, яким чином мають бути реалізовані структури даних, щоб отримати уявлення про те, що ми моделюємо, тобто адекватно відбити семантику моделі. До моделей реалізації БД відносять ієрархічну, мережеву, реляційну та об'єктно-орієнтовану моделі. Створення моделі реалізації БД на рівні певного типу та конкретної СУБД, чи логічної моделі, є метою етапу логічного проектування БД, а у випадку ієрархічних та мережевих БД – і фізичного.
Моделі реалізації за рівнем абстракції підрозділяються на внутрішні, зовнішні та фізичні моделі даних. Внутрішня модель є результатом адаптації концептуальної моделі до обраної СУБД. Іншими словами, внутрішня модель є представленням БД “з поляду” СУБД. Внутрішня модель вимагає, щоб проектувальник привів властивості та обмеження концептуальної моделі у відповідність з обраною моделлю реалізації бази даних. Оскільки, на відміну від концептуальної моделі, внутрішня модель залежить від специфічного програмного забезпечення, вона є програмно залежною.
Зовнішня модель базується на внутрішній і відбиває представлення кінцевого користувача про конфігурацію даних, де під кінцевими користувачами розуміють людей, що застосовують та розробляють прикладні програми. Кінцеві користувачі оперують додатками у певних підрозділах організації. У кожному підрозділі є власна специфіка, система обмежень та вимог, і у кожному з них використовується певна підмножина інформаційного середовища підприємства. Відповідно, прикладні програмісти, що працюють у різних підрозділах, розглядають свою підмножину даних окремо від внутрішньої моделі (як зовнішнє стосовно неї), з якої вони були отримані. Тому з точки зору прикладного програміста бажано, щоб спеціалісти з моделювання всю множину вимог та обмежень розбивали на функціональні модулі, які можна досліджувати в межах структури зовнішніх моделей. У кожну зовнішню модель включаються всі необхідні сутності, зв'язки, процеси та обмеження, визначені даним підрозділом. Зовнішня модель є підмножиною внутрішньої. При цьому, хоча представлення (views) ізольовані один від одного, вони сумісно використовують спільну сутність.
З точки зору прив'язки до етапу проектування і моделі даниїх найкраще говорити, що до моделей реалізації БД відносять моделі даних на основі записів (логічні моделі) та фізичні моделі.
Моделі даних на основі записів діють на концептуальному (логічному) рівні представлення БД, а фізичні – на внутрішньому рівні. Створення моделі реалізації БД на рівні певного типу та конкретної СУБД, чи логічної моделі, є метою етапу логічного проектування БД, а у випадку ієрархічних та мережевих БД – і фізичного.
У моделях даних на основі записів БД складається з кількох записів фіксованого формату, що можуть мати різні типи. Кожен тип запису визначає фіксовану кількість полів, кожне з який має фіксовану довжину.
Існує три основних типи моделей даних на основі записів:
реляційна (relational);
мережева (network);
ієрархічна (hierarchical).
Реляційна модель заснована на понятті математичних відношень. У ній дані і зв'язки представлені у вигляді таблиць, кожна з який має набір стовпців з унікальними іменами. З погляду користувача БД виглядає як набір таблиць; фізична ж структура БД може бути реалізована за допомогою різноманітних структур збереження.
У мережевій моделі дані представлені у вигляді колекції записів, а зв'язки – у вигляді наборів. Зв'язки в явному вигляді моделюються наборами, що реалізуються за допомогою вказівників. Мережеву модель можна представити як граф із записами у вигляді вузлів графа і наборами зв'язків у вигляді його ребер. Пример – стр. 86 Конноли, Брэгг.
Ієрархічна модель є обмеженим підтипом мережевої моделі. У ній дані також представлені, як колекція записів, а зв'язки – як набори, однак в ієрархічній моделі вузол може мати тільки одного батька. Тобто ієрархічна модель може розглядатися як деревоподібний граф з записами у вигляді вузлів і множинами зв’язків у вигляді ребер. Пример - стр. 87 Конноли, Брэгг.
Логічні моделі – це і є моделі, що базуються на записах. Вони описують структуру БД і модель її реалізації по самому верхньому рівні. Недоліком цих моделей є відсутність засобів для адекватної вказівки обмежень на дані, які є в об'єктних моделях. Основна їхня відмінність від концептуальних моделей у тому, що концептуальні (інфологічні) моделі не залежать ні від яких деталей реалізації, а логічні залежать від базової моделі представлення даних в обраній цільовий СУБД. Оскільки обидві моделі працюють на концептуальному рівні представлення даних, то деякі автори їх поєднують, хоча з погляду проектування БД це невірно.
Більшість систем заснована нині на реляційній парадигмі, ранні системи БД будувалися на мережевій чи ієрархічній. При використанні останніх від користувача потрібно знання фізичної організації БД, до якої він повинен здійснити доступ, у той час як у реляційній БД незалежність від даних значно більша. Якщо у реляційних системах для обробки інформації в БД прийнятий декларативний підхід (тобто вони вказують, які дані слід видобути), то в мережевих і ієрархічних системах – навігаційний підхід (тобто вони вказують, як їх слід витягати).
Фізична модель діє на найнижчому рівні абстракції, описуючи способи зберігання інформації на носіях, наприклад, жорстких дисках. Фізична модель вимагає визначення як пристрою фізичного зберігання, так і методу фізичного доступу, необхідного для отримання даних з фізичного носія. Очевидно, що фізична модель є як програмно, так і апаратно залежною. Використовувані структури зберігання залежать від пограмного забезпечення (СУБД, операційна система) та від типу носія, що підтримується комп'ютером. Вибір певного методу доступу до даних дає змогу оптимізувати роботу з БД кожного типу, проте реляційна модель в основному орієнтована на логічний рівень представлення і переважно не вимагає такого детального фізичного моделювання, як БД ієрархічного та мережевого типів.
Фізичних моделей менше, ніж логічних, самими розповсюдженими серед них є узагальнююча модель і модель пам'яті кадрів (фреймів).
На етапі інфологічного моделювання формують користувацьку та інфологічну об'єктну модель БД, на етапі логічного проектування – моделі реалізації БД на рівні моделей записів, на етапі фізичного проектування – фізичну модель БД.