Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
6.5. Характеристика інфологічної
та даталогічної моделі баз даних
Проектування даних пов’язане з багаторівневим їх поданням: зовнішнім, інфологічним, даталогічним, внутрішнім (рис. 6.3).
Зовнішній рівень являє собою вимоги до даних з боку користувачів і прикладних програм. Вимоги користувачів до зовнішнього подання охоплюють сукупність даних, які потрібні для виконання запитів користувачів. Вимоги з боку прикладних прог рам до зовнішнього рівня подання даних — це перелік даних з описом їх взаємозв’язків, які необхідні для реалізації певних функ ціональних задач.
Рис. 6.3. Схема взаємозв’язку рівнів подання даних у БД
Зовнішній рівень являє собою, як правило, словесний опис даних та їх взаємозв’язків і відбиває інформаційні потреби користувачів і прикладних програм. Іноді для опису зовнішнього рівня використовуються матричні або інші формалізовані методи. Опис зовнішнього рівня не виключає наявності дублювання, надлишковості, неузгодженості тощо.
Для того щоб спроектувати зовнішню модель БД, необхідно виконати обстеження ПО, вивчити систему вхідної і вихідної документації, дослідити й вивчити всі фукціональні обов’язки майбутніх користувачів БД.
Американський комітет CODASYL пропонує три рівні: зовнішній, концептуальний, внутрішній. Іноді для зручності проектування вводять допоміжний рівень (проміжний), який називають інфологічним. Він може бути самостійним або функціонувати як складова зовнішнього рівня.
Інтеграція всіх зовнішніх представлень даних виконується на інфологічному рівні. На цьому рівні формується інфологічна (канонічна) модель даних, яка не є простою сумою зовнішніх представлень даних.
Інфологічний рівень являє собою інформаційно-логічну модель (ІЛМ) предметної області, в якій виключена надмірність даних і відображені інформаційні особливості об’єкта управління, без урахування особливостей і специфіки конкретної СУБД.
Мета інфологічного проектування — створити структуровану інформаційну модель ПО, для якої розроблятиметься БД. Під час проектування на інфологічному рівні створюється інформаційно-логічна модель, яка має відповідати таким вимогам:
коректність схеми БД, тобто адекватне відображення модельованої ПО;
простота і зручність використання на наступних етапах проектування, тобто ІЛМ має легко відображатися в моделі БД, що підтримується відомими СУБД (сіткові, ієрархічні, реляційні);
ІЛМ має бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам АБ.
Основною складовою інфологічної моделі є атрибути, які потрібно проаналізувати і деяким чином згрупувати для подальшого зберігання в БД.
Сутність інфологічного моделювання полягає у виокремленні інформаційних об’єктів ПО (файлів), які підлягають зберіганню в БД, а також визначенні характеристик об’єктів і зв’язків між ними. Характеристиками об’єктів є атрибути.
Даталогічний (логічний, концептуальний) рівень формується
з урахуванням специфіки і особливостей конкретної СУБД. На цьому рівні будується концептуальна модель даних, тобто спеціальним способом структурована модель ПО, яка відповідає особливостям і обмеженням вибраної СУБД. Модель логічного рівня, яка підтримується засобами конкретної СУБД, іноді називають даталогічною. Залежно від типів моделей, які підтримуються засобами СУБД, є ієрархічні, сіткові і реляційні моделі баз даних. Найпоширенішими на сучасному ринку програм них продуктів є реляційні СУБД.
Внутрішній рівень пов’язаний з фізичним розміщенням даних у пам’яті ЕОМ. На цьому рівні формується фізична модель БД, яка містить структури зберігання даних у пам’яті ЕОМ, включаючи опис форматів даних, порядок їх логічного чи фізичного упорядкування, розміщення за типами пристроїв, а також характеристики і шляхи доступу до даних.
Від параметрів фізичної моделі залежать такі характеристики функціонування БД: обсяг пам’яті і час реакції системи. Фізичні параметри БД можна змінювати у процесі її експлуатації (не змінюючи при цьому опису інших рівнів) з метою підвищення ефективності функціонування системи.
Структура файлів БД визначається на етапах інфологічного і логічного проектування, а формування структури — на етапі фізичного проектування БД.
Структура файла — це пойменована сукупність логічно взаємозв’язаних атрибутів.
Нормалізація відношень — це ітераційний зворотний процес декомпозиції початкового відношення на кілька простіших відношень меншої розмірності. Під зворотністю процесу розуміють те, що операція об’єднання відношень, здобутих у результаті декомпозиції, має дати початкове відношення. У результаті нормалізації склад атрибутів відношень БД має відповідати таким вимогам:
між атрибутами мають виключатися небажані функціональні залежності;
групування атрибутів не повинно мати збиткового дублювання даних;
забезпечувати обробку і поновлення атрибутів без ускладнень.
Апарат нормалізації був розроблений американським вченим Е.Ф. Коддом. Кожна нормальна форма обмежує тип допустимих залежностей між атрибутами. Кодд виділив три нормальні форми (скорочена назва 1НФ, 2НФ і 3НФ). Найдосконаліша з них — це 3НФ. Тепер уже відомі і визначені 4НФ, 5НФ.
Нормалізація відношень виконується за кілька кроків (рис. 6.4).
Рис. 6.4. Схема етапів нормалізації відношень
1-й крок (1-ша ітерація) — зведення відношень до першої нор мальної форми (1НФ).
Відношення в 1НФ мають відповідати таким вимогам:
усі атрибути відношення мають бути атомарними, тобто неподільними;
усі рядки таблиці мають бути однакової структури, тобто мати одну й ту саму кількість атрибутів з іменами, що відповідно збігаються;
імена стовпців мають бути різними, а значення однорідними (мати однаковий формат);
порядок рядків у таблиці неістотний.
Кожне відношення БД містить як структурну, так і семантич ну інформацію. Структурна інформація задається схемою від ношення, а семантична виражає функціональні зв’язки між атрибутами.
На 2-му кроці (2-га ітерація) нормалізації виявляються ключі атрибути та аналізуються відповідні залежності з метою вилучення неповних функціональних залежностей.
Означення 1. Атрибут Б функціонально залежить від А у від ношенні R тоді, коли в кожний момент часу одному й тому само му значенню А відповідає не більш як одне значення Б. Функціональній залежності відповідає відношення 1:1 між атрибутами.
Означення 2. Атрибут перебуває у повній функціональній залежності, якщо він залежить від усього ключа і не залежить від його складових.
Якщо відношення має неповні функціональні залежності, то виконують його декомпозиції на два чи більше інших відношень, які не мають неповних функціональних залежностей і об’єднання яких дасть початкове відношення.
Нехай у відношенні R (A*, B*, С, D) атрибут С залежить від усього ключа , який складається з атрибутів A*, B* , а атрибут D залежить лише від B*, то тоді D знаходиться у неповній функціональній залежності, яку необхідно усунути шляхом декомпозиції. В результаті декомпозиції отримаємо два відношення:
R1 (A*, B*, С) і R2 ( B*,D).
3-й крок (3-тя ітерація) нормалізації — це вилучення транзитивних залежностей. Відношення в 2НФ має аналізуватися на присутність транзитивних залежностей.
Транзитивна залежність — це залежність між неключовими атрибутами.
Наприклад, дано відношення R (A*, B, C), в якому атрибут B не залежить безпосередньо від ключа, а C залежить від неключового атрибута B, який залежить від А, то тоді С транзитивно залежить від А.
Транзитивні залежності вилучаються також за допомогою декомпозиції відношення на інші два чи більше відношень, які не містять транзитивних відношень і об’єднання яких дасть початкове відношення. У результаті декомпозиції отримаємо два нових відношення R1 (A*, B) та R2 (В*, С).
На 4-му кроці (4-та ітерація) нормалізації виконується аналіз на присутність незалежних багатозначних залежностей у відношенні. Якщо вони є, то виконується декомпозиція відношення.
Багатозначна залежність — це різновид функціональної залежності. Атрибут В знаходиться у багатозначній залежності від атрибута А, тоді коди одному значення атрибута А відповідає багато значень атрибута В. Наприклад, між атрибутами код структурного підрозділу : табельний номер = 1 : Б, так як в одному підрозділі може працювати багато співробітників. Тобто багатозначній залежності відповідає відношення 1:Б між атрибутами.
Існують поняття тривіальної і нетривіальної багатозначної залежності.
Залежність типу Х —>>Y і Y—>>X є тривіальною, а залежність Х —>>Y і Y —>> X — нетривіальною. Присутність нетривіальних багатозначних залежностей у схемі відношення і незалежність їх правих частин зумовлюють комбінаторику правих частин відношення.
Означення 3. Відношення R міститься в 4НФ, коли в структурі багатозначної залежності, яка визначена на множині атрибутів, є лише тривіальні чи такі нетривіальні багатозначні залежності, що ліва частина будь-якої з них є ключем.
Атрибут А багатозначно визначає атрибут В у відношенні R (A*, B, C), якщо В залежить лише від А при будь-яких його комбінаціях з іншими атрибутами відношення.
Якщо у відношенні R(A*,B,C) наявні багатозначні залежності, тобто А—>>В і А—>>С, то воно має бути розкладене на два інших відношення R1 (А, В) і R2 (A, С). Поняття багатозначної залежності складніше, ніж поняття функціональної залежності. Для її виявлення потрібний значно глибший семантичний аналіз атрибутів.
Декомпозиція початкового відношення на кілька інших має гарантувати його оборотність, тобто забезпечувати отримання по чаткового відношення об’єднанням відношень, знайдених у результаті декомпозиції.
Проте не завжди декомпозиція гарантує оборотність. Відношення, яке містить більш як три багатозначні залежності, потребує спеціальних заходів щодо забезпечення оборотності декомпозиції. Для цього існує 5НФ. При декомпозиції з 4НФ дістають такі проекції, щоб кожна з них містила не менш як один можливий ключ і щонайменше один неключовий атрибут початкового відношення.
5НФ усуває надлишковість і водночас аномалії поповнення БД. Насамкінець наголосимо, що нормалізація відношень усуває між атрибутами такі залежності: неповні функціональні, транзитивні, нетривіальні (незалежні) багатозначні. Усуваючи ці залежності, виключаємо дублювання даних і можливість виникнення аномалій при виконанні операцій поповнення, заміни та вилучення даних з БД. Крім того, нормалізована база даних вимагає значно менше пам’яті для її зберігання, ніж ненормалізована база даних.