Переваги та недоліки різних ступенів нормалізації
Зберемо воєдино результати аналізу критеріїв, по яких ми хотіли оцінити вплив логічного моделювання даних на якість фізичних моделей даних і продуктивність бази даних:
| Критерій | Відношення слабо нормалізовані (1НФ, 2НФ) | Відношення сильно нормалізовані (3НФ) |
| Адекватність бази даних предметній області | ГІРШЕ (-) | КРАЩЕ (+) |
| Легкість розробки і супроводження бази даних | СКЛАДНІШЕ (-) | ЛЕГШЕ (+) |
| Швидкість виконання вставки, оновлення, видалення | ПОВІЛЬНІШЕ (-) | ШВИДШЕ (+) |
| Швидкість виконання вибірки даних | ШВИДШЕ (+) | ПОВІЛЬНІШЕ (-) |
Як видно з таблиці, більш сильно нормалізовані відношення виявляються краще спроектовані (три плюси, один мінус). Вони більше відповідають предметної області, легше в розробці, для них швидше виконуються операції модифікації бази даних. Правда, це досягається ціною деякого уповільнення виконання операцій вибірки даних.
У слабко нормалізованих відношень єдина перевага - якщо до бази даних звертатися тільки з запитами на вибірку даних, то для слабо нормалізованих відношень такі запити виконуються швидше. Це пов'язано з тим, що в таких відношеннях уже як би зроблене з'єднання відносин і на це не витрачається час при вибірці даних.
На практиці вибір ступеня нормалізації відносин залежить від характеру запитів, з якими найчастіше звертаються до бази даних. Сильно нормалізовані моделі даних добре підходять для так званих OLTP-додатків (On-Line Transaction Processing (OLTP)- оперативна обробка трансакцій), тобто транзакційних БД. Типовими прикладами OLTP-додатків є системи складського обліку, системи замовлень квитків, банківські системи, що виконують операції по переведенню грошей тощо. Основна функція подібних систем полягає у виконанні великої кількості коротких трансакцій. Самі трансакції виглядають відносно просто, наприклад, "зняти суму грошей з рахунка А, додати цю суму на рахунок У". Проблема полягає в тім, що, по-перше, трансакцій дуже багато, по-друге, виконуються вони одночасно (до системи може бути підключено кілька тисяч одночасно працюючих користувачів), по-третє, при виникненні помилки, трансакція повинна цілком відкотитися і повернути систему до стану, що було до початку трансакції (не повинно бути ситуації, коли гроші зняті з рахунка А, але не надійшли на рахунок Б). Практично всі запити до бази даних у OLTP-додатках складаються з команд вставки, оновлення, видалення. Запити на вибірку в основному призначені для надання користувачам можливості вибору з різних довідників. Більша частина запитів, таким чином, відома заздалегідь ще на етапі проектування системи. Таким чином, критичним для OLTP-додатків є швидкість і надійність виконання коротких операцій відновлення даних. Чим вище рівень нормалізації даних уOLTP-додатку, тим він переважно працює швидше і надійніше.
|
|
|
|
|
|
Іншим типом додатків є так звані OLAP-додатки (On-Line Analitical Processing (OLAP) - оперативна аналітична обробка даних), характерні для систем підтримки прийняття рішень (Decision Support System - DSS), сховищ даних (Data Warehouse), систем інтелектуального аналізу даних (Data Mining). Такі системи призначені для визначення залежностей між даними (наприклад, можна спробувати визначити, як зв'язаний обсяг продажів товарів з характеристиками потенційних покупців), для проведення аналізу "що якщо...". OLAP-додатки оперують з великими масивами даних, уже накопиченими в OLTP-додатках, узятими з їхніх електронних таблиць чи з інших джерел даних. Такі системи характеризуються наступними ознаками:
¾ додавання в систему нових даних відбувається відносно рідко великими блоками (наприклад, раз у квартал завантажуються дані за підсумками квартальних продажів з OLTP-додатка);
¾ дані, додані в систему, звичайно ніколи не видаляються;
¾ перед завантаженням дані проходять різні процедури "очищення", пов'язані з тим, що в одну систему можуть надходити дані з багатьох джерел, що мають різні формати представлення для тих самих понять, дані можуть бути некоректні, помилкові;
|
|
|
¾ запити до системи є нерегламентованими і, як правило, досить складними. Дуже часто новий запит формулюється аналітиком для уточнення результату, отриманого в результаті попереднього запиту;
¾ швидкість виконання запитів важлива, але не критична.
Дані OLAP-додатків звичайно представлені у вигляді одного чи декількох гіперкубів, виміри якого являють собою довідкові дані, а в комірках самого гіперкуба зберігаються власнедані. Наприклад, можна побудувати гіперкуб, вимірами якого є: час (у кварталах, роках), тип товару і відділення компанії, а в комірках зберігаються обсяги продажів. Такий гіперкуб буде містити даних про продажі різних типів товарів по кварталах і підрозділам. Ґрунтуючись на цих даних, можна відповідати на питання типу "у якого підрозділу найкращі обсяги продажів у поточному році?", чи "які тенденції продажів відділень Південно-Західного регіону в поточному році в порівнянні з попереднім роком?" Фізично гіперкуб може бути побудований на основі спеціальної багатомірної моделі даних (MOLAP - Multidimensional OLAP) чи побудований засобами реляційної моделі даних (ROLAP - Relational OLAP). В системах OLAP, що використовують реляційну модель даних (ROLAP), дані доцільно зберігати у вигляді слабко нормалізованих відносин, що містять заздалегідь обчислені основні підсумкові дані. Велика надмірність і зв'язані з нею проблеми тут не страшні, тому що відновлення відбувається тільки в момент завантаження нової порції даних. При цьому відбувається як додавання нових даних, так і перерахування підсумків.
|
|
|
Дата добавления: 2016-01-05; просмотров: 22; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!