Характеристика інфологічної та датологічної моделей баз даних. Теорія нормалізованих відношень.
Проектування даних пов'язане з багаторівневим їх поданням зовнішнім, інфологічним, даталогічним, внутрішнім. Зовнішній рівень являє собою вимоги до даних з боку користувачів і прикладних програм. Вимоги користувачів до зовнішнього подання охоплюють сукупність даних, які потрібні для виконання запитів користувачів Вимоги з боку прикладних програм до зовнішнього рівня па дання даних -- це перелік даних з описом їх взаємозв'язків, як необхідні для реалізації певних функціональних задач. Зовнішній рівень являє собою, як правило, словесний опис даних та їх взаємозв'язків і відбиває інформаційні потреби користувачів і прикладних програм. Іноді для опису зовнішнього рівня використовуються матричні або інші формалізовані методи. Опис зовнішнього рівня не виключає наявності дублювання, надлишковості, неузгодженості тощо.
Для того щоб спроектувати зовнішню модель БД, необхідно виконати обстеження ПО, вивчити систему вхідної і вихідної документації, дослідити й вивчити всі функціональні обов'язки майбутніх користувачів БД.
Американський комітет CODASYL пропонує три рівні: зовнішній, концептуальний, внутрішній. Іноді для зручності проектування вводять допоміжний рівень (проміжний), який називають інфологічним. Він може бути й самостійним або функціонувати як складова зовнішнього рівня.
Інтеграція всіх зовнішніх зображень виконується на інфологічному рівні. На цьому рівні формується інфологічна (канонічна) модель даних, яка не є простою сумою зовнішніх зображень даних. Інфологічний рівень являє собою інформаційно-логічну модель (ІЛМ) предметної області, в якій виключена надмірність даних і відображені інформаційні особливості об'єкта управління, без урахування особливостей і специфіки конкретної СУБД.
|
|
|
Мета інфологічного проектування -- створити структуровану інформаційну модель ПО, для якої розроблятиметься БД. При проектуванні на інфологічному рівні створюється інформаційно-логічну модель, яка має відповідати таким вимогам:
- коректність схеми БД, тобто адекватне відображення модельованої ПО
- простота і зручність використання на наступних етапах проектування, тобто ІЛМ має легко відображатися в моделі БД, що підтримується відомими СУБД (сіткові, ієрархічні, реляційні);
- ІЛМ має бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам АБ.
Основною складовою інфологічної моделі є атрибути, які потрібно проаналізувати і деяким чином згрупувати для подальшою зберігання в БД. Сутність інфологічного моделювання полягає у виділенні щ. формаційних об'єктів ПО (файлів), які підлягають зберіганню в БД, а також визначенні характеристик об'єктів і зв'язків між ними. Характеристиками об'єктів є атрибути. Даталогічний (логічний, концептуальний) рівень формується з урахуванням специфіки і особливостей конкретної СУБД. На цьому рівні будується концептуальна модель даних, тобто спеціальним способом структурована модель ПО, яка відповідає особливостям і обмеженням вибраної СУБД. Модель логічного рівня, яка підтримується засобами конкретної СУБД, іноді називають даталогічною. Залежно від типів моделей, які підтримуються засобами СУБД, є ієрархічні, сіткові і реляційні моделі баз даних. Найпоширенішими на сучасному ринку програмних продуктів є реляційні СУБД (DBASE 111, FOXBASE, FOXPRO, CLIPPER і т. ін.).
|
|
|
Внутрішній рівень пов'язаний з фізичним розміщенням даних у пам'яті ЕОМ. На цьому рівні формується фізична модель БД, яка містить структури зберігання даних в пам'яті ЕОМ, включаючи опис форматів записів, їхнє логічне або фізичне упорядкування, розміщення за типами пристроїв, а також характеристики і шляхи доступу до даних.
Від параметрів фізичної моделі залежать такі характеристики функціонування БД: обсяг пам'яті і час реакції системи. Фізичні параметри БД можна змінювати в процесі її експлуатації (не змінюючи при цьому опису інших рівнів) з метою підвищення ефективності функціонування системи. Визначення структури масивів БД відбувається на етапах інфологічного і логічного проектування, а формування структури - на етапі фізичного проектування БД. Структура файла -- це пойменована сукупність логічно взаємопов'язаних атрибутів.
|
|
|
Основна ідея нормалізації – розбити великий "не добре" спроектовані зв'язок на кілька "добре спроектованих" зв'язків. У результаті нормалізації склад атрибутів відношень БД має відповідати таким вимогам:
• між атрибутами мають виключатися небажані функціональні залежності;
• групування атрибутів не повинно мати збиткового дублювання даних;
• забезпечувати обробку і поновлення атрибутів без ускладнень.
До значень "недоброго проектування" можна зарахувати: введення, вилучення та аномалії оновлення. Хороший проект БД:
Клієнт (ім'я,адреса, номер телефону)
Резерви (назва*, адреса*, номер*, дата*)
Рейс (номер, дата, час)
Для побудови хорошого проекту БД необхідно:
• мінімізувати аномалії (надмірність);
• ввести / вилучити аномалії;
• забезпечити оновлення аномалій;
|
|
|
• забезпечити чіткий синтаксис / семантику.
• дотримуватись правил цілісності, зокрема:
• • цілісності об'єкта (всі об'єкти унікальні, не може бути ніяких нульових проводок у первинному ключі);
• • цілісності відносин (зовнішній ключ має бути або нульовим, або відповідати розміру первинного ключа у зв'язаній таблиці).
Аномалії введення / вилучення. Що буде, якщо ми вилучимо запис про такого клієнта, який вже зробив попереднє замовлення на рейс? Яким повинно бути рішення?
Аномалії оновлення. Що буде, якщо змінюється адреса клієнта в БД Клієнт? Яким повинно бути рішення?
Апарат нормалізації був розроблений американським вченим Е.Ф.Коддом. Кодд виділив три нормальні форми (скорочена назва 1НФ, 2НФ, ЗНФ). Найдосконаліша з них- ЗНФ. Тепер уже відомі і визначені 4 НФ, 5НФ.
Нормалізація відношень виконується за кілька кроків (рис. 3).
1-й крок (перша ітерація). - зведення відношень до 1НФ.
Відношення в 1НФ мають відповідати таким вимогам:
• усі атрибути відношення мають бути атомарними (неподільними);
• усі рядки таблиці мають бути однакової структури, тобто мати одну и ту саму кількість атрибутів з іменами, що відповідно збігаються;
• імена стовпців мають бути різними, а значення однорідними (мати однаковий формат);
• порядок рядків у таблиці неістотний.
Рис. 3. Схема етапів нормалізації відношень
Кожне відношення БД містить структурну (задається схемою відношення) семантичну (функціональні зв'язки між атрибутами) інформацію.
Приклад. Заробітна плата є атомарним атрибутом, Перелік авторів не атомарним атрибутом. Попередня інформація про заробітну плату не є атомарною.
2-й крок (друга ітерація). Виявляються ключі-атрибути та аналізують відповідні залежності з метою вилучення неповних функціональних залежностей
Означення 1. Атрибут Б функціонально залежить від А у відношенні R тоді, коли в кожний момент часу одному і тому самому значенню А відповідає не більш ніж одне значення Б. Функціональній залежності відповідає відношення 1:1 між атрибутами.
Приклад. ПРОДУКТ (Код продукту, Назва, Кінцева обробка, Приміщення, Ціна).
Код продукту → Назва, Кінцева обробка, Приміщення, Ціна. Назва, Кінцева обробка, Приміщення → Код продукту.
Не можемо мати два продукти з однаковою назвою, які кінцево обробляються та використовуються в одному приміщенні.
Означення 2. Атрибут перебуває у повній функціональній залежності, якщо він залежить від усього ключа і не залежить від його складових
Якщо відношення має неповні функціональні залежності, то виконують його декомпозиції на два чи більше інших відношень, які не мають неповних функціональних залежностей і об'єднання яких дасть початкове відношення.
Основна ідея декомпозиції - розкласти на частини великий "недобре спроектований зв'язок" на декілька малих "добре спроектованих" зв'язків так, щоб
• зберегти властивість розкладення (декомпозиції) без втрат при об'єднанні;
• зберегти залежності (без втрати функціональних залежностей).
Приклад. Візьмемо відношення КЛІЄНТ (Код клієнта, Ім'я, Адреса, № рахунку, Тип, Залишок).
Якщо ми розіб'ємо його на два:
ПОКУПЕЦЬ (Код клієнта, Ім'я, Адреса)
РАХУНОК (Номер рахунку, Тип, Залишок),
то ми втрачаємо інформацію. Однак, якщо КЛІЄНТ розкласти на:
ПОКУПЕЦЬ (Код клієнта, Ім'я, Адреса) та
РАХУНОК (Код клієнта, № рахунку, Тип, Залишок),
то КЛІЄНТ можна реконструювати без жодної втрати інформації.
3-й крок (третя ітерація) нормалізації – це вилучення транзитивних залежностей, тобто залежностей між неключовими атрибутами.
Наприклад, дано відношення R (А*,В,С), в якому атрибут В не залежить безпосередньо від ключа, а Є залежить від неключового атрибута В, який залежить від А, то тоді Є транзитивне залежить від А.
Транзитивні залежності вилучають також за допомогою декомпозиції відношення на інші два чи більше відношень, які не містять транзитивних і об'єднання яких дасть початкове відношення. Внаслідок декомпозиції отримаємо два нових відношення R1 (А*,В) та R2 (В*,С).
Приклад. ПРОДАЖІ (Ціна, Назва товару, Продавець, Область);
Функціональні залежності:
Ціна → Назва товару, Продавець, Область
Продавець → область
У цьому прикладі транзитивною залежністю є Продавець → область.
4-й крок (четверта ітерація) нормалізації - аналіз на присутність незалежних багатозначних залежностей у відношенні. Якщо вони є, то виконується декомпозиція відношення.
Багатозначна залежність - це різновид функціональної залежності. Атрибут В знаходиться у багатозначній залежності від атрибуту А тоді, коли значенню атрибуту А відповідає багато значень атрибуту В. Наприклад, між атрибутами код структурного підрозділу: табельний номер = 1:Б, оскільки в одному підрозділі може працювати багато співробітників. Тобто багатозначній залежності відповідає відношення 1:Б між атрибутами.
Приклад. Візьмемо базу даних Заняття (Курс, Викладач, Книжка), де Заняття (С, t, b) означає, що викладач t може читати курс С і що b - це необхідний підручник для С.
Це означає, що для викладання кожного курсу є набір викладачів і набір придатних підручників, і що ці два набори є незалежними один від одного.
Зважаючи на наведений приклад, багатозначна залежність – це такий тип залежності, який існує, коли у таблиці зв'язків є щонайменше три атрибути (наприклад, А, В та С) і для кожного значення А існує чітко визначений набір значень В і чітко визначений набір значень С, і ці два набори (В і С) є незалежними один від одного.
Для усунення багатофункціональної залежності розіб'ємо базу даних Заняття на дві таблиці:
МОЖЕ ВЧИТИ (Курс, Викладач) та
КНИЖКА КУРСУ (Курс, Книжка)
При такому розбитті ми не втрачаємо ніякої інформації (БД Заняття можна реконструювати на основі цих двох таблиць).
Будь-яку таблицю зв'язків можна без втрат розбити на еквівалентний набір таблиць у 4 НФ (як це зроблено вище).
Декомпозиція початкового відношення на кілька інших має гарантувати його оборотність, тобто забезпечувати отримання початкового відношення, об'єднанням відношень, знайдених внаслідок декомпозиції.
Проте не завжди декомпозиція гарантує оборотність. Відношення, яке містить більш як три багатозначні залежності, потребує спеціальних заходів щодо забезпечення оборотності декомпозиції. Для цього існує 5НФ. При декомпозиції з 4НФ дістають такі проекції, щоб кожна з них містила не менш як один можливий ключ і щонайменше один неключовий атрибут початкового відношення.
Нормалізована БД виключає дублювання даних і можливість виникнення аномалій при виконанні операцій поповнення, заміни та вилучення даних з БД Крім того, нормалізована база даних вимагає значно менше пам'яті для ц зберігання, ніж не нормалізована БД.
Дата добавления: 2019-02-13; просмотров: 397; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!