Під оптимальною логічною моделлю баз даних розуміють модель, яка не має аномалій, пов’язаних з модифікацією БД, тобто проблем, що можуть виникнути у зв’язку із замінами, вставками і вилученнями даних із БД.
Для створення такої моделі баз даних назалежно від того, яка СУБД використовується — ієрархічна, сіткова чи реляційна — застосовується теорія нормалізації реляційних баз даних. Використання реляційного підходу дає змогу спроектувати оптимальну логічну модель БД, яка потім досить просто трансформується в ієрархічну чи сіткову модель.
В основу реляційних моделей покладено поняття відношення, яке подають у вигляді двовимірної таблиці.
Реляційна БД — це набір взаємопов’язаних відношень. Кожне відношення (таблиця) в ЕОМ подається як файл. Відношення можна поділити на два класи: об’єктні і зв’язкові.
Об’єктні відношення зберігають дані про інформаційні об’єкти предметної області.
Наприклад:
клієнт (код клієнта, назва клієнта, адреса, телефон) є об’єктним відношенням.
В об’єктному відношенні один з атрибутів однозначно ідентифікує окремий об’єкт. Такий атрибут називається первинним ключем відношення. В наведеному відношенні роль ключа виконує атрибут «код клієнта».
Ключ може вмикати кілька атрибутів, тобто бути складеним. В об’єктному відношенні не повинно бути рядків з однаковим ключем - не допускається дублювання об’єктів. Це основне обмеження реляційної моделі для забезпечення цілісності даних.
Зв’язкове відношення зберігає ключі двох або більше об’єктних відношень. Ключі зв’язкового відношення мають на меті встановлення зв’язків між об’єктними відношеннями.
Наприклад, розглянемо ще одне об’єктне відношення БАНК(код банку, назва банку, адреса банку).
Тоді зв’язкове відношення БАНК-КЛІЄНТ (код банку, код клієнта) буде сполучним між двома об’єктними відношеннями БАНК іКЛІЄНТ. У зв’язковому відношенні можуть дублюватися ключові атрибути. Крім ключів, за якими встановлюють зв’язок у зв’язковому відношенні, можуть бути ще й інші атрибути, які функціонально залежать від цього складового ключа.
Ключі в зв’язкових відношеннях називаються зовнішніми ключами, оскільки вони є первинними ключами інших відношень. Реляційна модель накладає на зовнішні ключі обмеження, яке називають посилковою цілісністю. Це означає, що кожному зовнішньому ключеві має відповідати рядок якогось об’єктного відношення.
У реляційній БД накладається ще одне обмеження — відношення мають бути нормалізовані.
Нормалізація відношень — це ітераційний зворотний процес декомпозиції початкового відношення на кілька простіших відношень меншої розмірності. Під зворотністю процесу розуміють те, що опереація об’єднання відношень, здобутих у результаті декомпозиції, має дати початкове відношення. У результаті нормалізації склад атрибутів відношень БД має відповідати таким вимогам:
між атрибутами мають викючатися небажані фукціональні залежності;
групування атрибутів не повинно мати збиткового дублювання даних;
забезпечувати обробку і поновлення атрибутів без ускладнень.
Апарат нормалізації був розроблений Е.Ф. Коддом. Кожна нормальна форма обмежує тип допустимих залежностей між атрибутами. Код виділив три нормальні форми (скорочена назва 1НФ, 2НФ і 3НФ). Найдосконаліша з них — це 3НФ. Тепер уже відомі і визначені 4НФ, 5НФ.
Нормалізація відношень виконується за кілька кроків.
1-й крок (1-ша ітерація) — зведення відношень до першої нормальної форми (1НФ).
Відношення в 1НФ мають відповідати таким вимогам:
усі атрибути відношення мають бути атомарними, тобто неподільними;
усі рядки таблиці мають бути однакової структури, тобто мати одну й ту саму кількість атрибутів з іменами, що відповідно збігаються;
імена стовпців мають бути різними, а значення однорідними (мати однаковий формат);
порядок рядків у таблиці не істотний.
Рис. 27. Схема етапів нормалізації відношень
На 2-му кроці (2-га ітерація) нормалізації виявляються ключі відношення та аналізуються відповідні залежності з метою вилучення неповних функціональних залежностей.
Означення 1. Атрибут Б залежить від А у відношенні R тоді, коли в кожний момент часу одному й тому самому значенню А відповідає не більш як одне значення Б. Функціональній залежності відповідає відношення 1:1 між атрибутами.
Означення 2. Атрибут перебуває у повній функціональній залежності, якщо він залежить від усього ключа і не залежить від його складових.
Якщо відношення має неповні функціональні залежності, то виконують його декомпозиції на два чи більше інших відношень, які не мають неповних функціональних залежностей і об’єднання яких дасть початкове відношення.
3-й крок (3-тя ітерація) нормалізації — це вилучення транзитивних залежностей. Відношення в 2НФ має аналізуватися на присутність транзитивних залежностей.
Транзитивна залежність — це залежність між неключовими атрибутами.
Транзитивні залежності вилучаються також за допомогою декомпозиції відношення на інші два чи більше відношень, які не містять транзитивних відношень і об’єднання яких дасть початкове відношення.
На 4-му кроці (4-та ітерація) нормалізації виконується аналіз на присутність незалежних багатозначних залежностей у відношенні. Якщо вони є, то виконується декомпозиція відношення.
Багатозначна залежність — це різновид функціональної залежності. Їй відповідає відношення 1:Б між атрибутами.
Означення 3. Відношення R міститься в 4НФ, коли в структурі багатозначної залежності, яка визначена на множині атрибутів, є лише тривіальні чи такі нетривіальні багатозначні залежності, що ліва частина будь-якої з них є ключем.
Декомпозиція початкового відношення на кілька інших має гарантувати його оборотність, тобто забезпечувати отримання початкового відношення шляхом об’єднання відношень, знайдених у результаті декомпозиції.
Проте не завжди декомпозиція гарантує оборотність. Відношення, яке містить більш як три багатозначні залежності, потребує спеціальних заходів щодо забезпечення оборотності декомпозиції. Для цього існує 5НФ. При декомпозиції з 4НФ дістають такі проекції, щоб кожна з них містила не менш як один можливий ключ і щонайменше один неключовий атрибут початкового відношення.
5НФ усуває надлишковість і водночас аномалії поповнення БД.
Нормалізація відношень усуває між атрибутами такі залежності: неповні функціональні, транзитивні, нетривіальні (незалежні) багатозначні. Усуваючи ці залежності, виключаємо дублювання даних і можливість виникнення аномалій при виконанні операцій поповнення, заміни та вилучення даних з БД.
Наступним кроком, який виконується після нормалізації відношень є побудова логічної моделі БД.
Логічна модель є основою бази даних, вона повинна відображати взаємозв’язки між реляційними таблицями. Між реляційними таблицями можуть бути наступні типи зв’язків 1:1, 1:Б та Б:Б. Найбільш поширеним зв’язком є зв’язок 1:Б. Зв’язок 1:1 зустрічається рідше, тому що дані між якими існує такий тип зв’язку в переважній більшості випадків входять до складу однієї реляційної таблиці. Зв’язок Б:Б безпосередньо не підтримується в реляційних СУБД. Для реалізації такого зв’язку необхідно створювати додаткову реляційну таблицю, яка буде відігравати роль зв’язкової. Зв’язкова таблиця має обов’язково містити первинні ключі таблиць, між якими встановлюється зв’язок.
Деякі сучасні СУБД мають інструментальні засоби побудови логічної моделі даних.
4.Поняття сховищ даних, моделі архітектура та основи їх створення.
Різновидом баз даних є сховище даних (Data WarenHouse). Поняття сховищ даних виникло зовсім недавно. Необхідність розробки нової концепції сховищ даних обумовлена такими факторами:
· Розвиток інформаційних технологій привів до систем нового типу, які дістали назву систем підтримки прийняття рішень. Ці системи основані на новій технологіі - OLAP-технології. Основою OLAP-технології є реалізація аналітичних запитів.
· Системи підтримки прийняття рішень, основані на формуванні аналітичних запитів, почали конфліктувати з транзакційними системами оперативної обробки даних (OLTP- системами). Одночасне вирішення оперативних і аналітичних запитів на одній базі даних часто призводить до нестачі ресурсів.
· Формування аналітичних звітів на основі традиційних баз даних, які вміщують оперативну інформацію, займає дуже багато часу. Це призводить до того, що менеджери не встигають готувати відповідні рішення на основі отриманих аналітичних звітів.
· Дуже часто на підприємстві чи в організації функціонує декілька OLTP-систем, кожна з яких має свою окрему базу даних, в яких використовуються різні структури даних, способи кодування, одиниці вимірювання. Побудова зведеного аналітичного запиту на основі декількох баз даних є дуже складною проблемою, яка спочатку потребує вирішення проблеми узгодженності даних, що зберігаються в різних базах даних.
Вирішення перерахованих вище проблем було знайдено в розробці концепції сховища даних. Сховище даних має виконувати функції попереднього добору, агрегації та підготовки оперативних даних OLTP-системам. Тобто в сховищі даних зберігаються не первинні дані, а певним чином інтегровані дані, які створюють основу для вирішення аналітичних задач і функціонування систем підтримки прийняття рішень. Взаємозв’язок між системами відбиває рис. 6.6.
Рис. 6.6. Схема взаємозв’язку OLTP та OLAP систем
Таким чином сховище даних (Data WarenHouse) це особлива форма організації бази даних, котра призначена для зберігання в погодженому вигляді агрегованої інформації, що отримується на основі баз даних різних OLTP-систем та зовнішніх джерел.
Сховища даних характеризуються предметною орієнтацією, інтегрованістю, підтримкою хронології, незмінністю і мінімальною надлишковістю
Предметна орієнтація. Дані в сховищі даних організовані у відповідності до основних напрямків діяльності підприємства чи фірми (замовники, продажі, склад і т.п.).
Інтегрованість. Первинні дані оперативних баз даних перевіряються, певним чином добираються, приводяться до одного виду, необхідною мірою агрегуються (тобто обраховуються сумарні показники) і завантажуються у сховище даних.
Підтримка хронології. Це дозволяє проводити аналіз зміни показників у часі.
Незмінність. Це є суттєвою відмінністю даних, що зберігаються у сховища даних, від оперативних даних. Оперативні дані можуть дуже часто змінюватись, з даними сховища можливі лише операції їх первинного завантаження, пошуку та їх читання.
Мінімальна надлишковість. Забезпечується тим, що перш ніж завантажувати дані до сховищ, їх фільтрують і певним чином очищають від таких даних, які не потрібні і не можуть бути використані в OLAP-системах.
Сховища даних можуть включати такі компоненти: віртуальне сховище даних, корпоративне сховище даних, кіоски чи вітрини даних.
Віртуальне сховище даних — це репозитарій метаданих, які описують джерела надходження інформації, структуру даних сховища, методи агрегації та завантаження даних, відомості про структуру бізнес-понять та інші дані про дані, що зберігаються у сховищі.
Корпоративні сховища даних (enterprіse data warehouses) вміщують інформацію, зібрану із певної множити оперативних БД, яка характеризує всю корпорацію і необхідна для виконання консолідованого аналізу діяльності корпорації в цілому.
Кіоски чи вітрини даних (data marts)це певна підмножина корпоративних даних, які характеризують конкретний аспект діяльності корпорації, наприклад роботу якогось її підрозділу. Кіоск може отримувати дані з корпоративного сховища даних (залежний кіоск) чи бути незалежним, і тоді джерелом поповнення його даними будуть оперативні БД.
В останні часи з’явилось поняття глобального сховища даних, в якому сховище даних розглядається як єдине джерело інтегрованих даних для всіх вітрин даних.
Найбільш вдалою формою представлення даних, що надасть можливість багатовимірної їх параметризації є подання даних у вигляді неплоскої реляційної моделі, а багатовимірної моделі. В основу OLАP-систем покладено поняття гіперкуба, тобто багатовимірного куба, у комірках якого зберігаються необхідні для аналізу дані.
Проте нині існує три варіанти побудови систем на основі сховищ даних: MOLAP (Multіdіmensіonal OLAP), ROLAP (Relatіonal OLAP) і HOLAP (Hybrіd OLAP). В MOLAP-системі гіперкуб реалізується як спеціальна модель нереляційної структури, яка швидше забезпечує доступ до даних, ніж реляційні моделі, але вимагає додаткових витрат пам’яті.
В ROLAP — системах гіперкуб це лише користувацький інтерфейс, який моделюється на традиційній реляційній базі даних. Дані в сховищі представляються у вигляді моделі, що дістала назву «зірка» (star schema). Ця модель складається з таблиць двох типів: однієї таблиці даних, що аналізуються, тобто фактів (fact table) — центр зірки і декількох таблиць, які характеризують певні виміри цих фактів (demensіon table). Таблиця фактів вміщує числові характеристики якогось напрямку діяльності компанії чи фірми, наприклад обсяги продажу, а також ключі таблиць вимірів. Таблиці вимірів містять додаткові характеристики ключових полів, як правило, це довідкові дані, наприклад дані про назву товару, назву його виробника, тип товару та інші. Зауважимо, що дані таблиць вимірів денормалізовані.
Якщо ж таблиці вимірів нормалізовані, то така модель називається «сніжинкою» (snowflake schema). В ROLAP– системах зберігаються агреговані дані.
HOLAP-системи — це комбінований варіант зберігання даних, який використовує обидва типи СУБД. У багатовимірній СУБД зберігаються агрегати даних, а докладні дані, які мають невеликий обсяг, зберігаються в реляційній СУБД.
