ЗАГАЛЬНІ ВІДОМОСТІ ПРО денормалізації

До цих пір в цій (і попередньої) чолі в основному передбачалося, що повна нормалізація аж до 5НФ вельми бажана Але на практиці часто можна чути твердження, що для досягнення високої продуктивності системи іноді слід

виконати денормализация При цьому використовуються доводи, подібні перерахованим нижче

6 Повна нормалізація призводить до появи великої кількості логічно не залежних змінних відносини (і передбачається, що аналізовані пере менниє відносини є базовими)

7 Велика кількість логічно незалежних змінних відносини призводить до появи великої кількості окремо збережених фізичних файлів

8 Велика кількість окремо збережених фізичних файлів призводить до появле нию великої кількості операцій введення-виведення

Строго кажучи, ці доводи, звичайно ж, не вірні, оскільки (як багаторазово зазначалося в даній книзі) у визначенні реляційної моделі ніде не стверджується, що базові змінні відносини повинні перебувати у взаємно однозначній відповідності з збереженими файлами Тому денормализация в разі необхідності слід виконувати на рівні збережених файлів, але не на рівні базових змінних отношенія3 Однак в деякому відношенні ці доводи все ж вірні для сучасних продуктів SQL, оскільки саме в них ці два рівня не розділені в необхідного ступеня У цьому розділі термін денормализация буде розглянуто більш докладно

Примітка Матеріал цього розділу в значній мірі грунтується на [136]

Загальне визначення денормалізації

Нагадаємо, що нормалізація змінної відносини R означає її заміну безліччю таких проекцій Rl, R2, .., Rn, що результатом зворотного зєднання проекцій Rl, R2, .., Rn обовязково буде значення R Кінцевою метою нормалізації є скорочення ступеня надмірності даних за рахунок приведення проекцій Rl, R2, .., Rn до максимально високому рівню нормалізації

Тепер можна перейти до визначення поняття денормалізації Нехай Rl, R2, Rn

є множиною змінних відносини Тоді денормалізації цих змінних відносини називається така заміна змінних відносини їх зєднанням R, що для всіх можливих значень i (де i = 1, .., п) виконання проекції R за атрибутами Ri обовязково знову призводить до створення значень Ri Кінцевою метою денормалізації є збільшення ступеня надмірності даних за рахунок приведення змінної відношення R до більш низького рівня нормалізації у порівнянні з вихідними змінними відносини Rl, R2, .., Rn Точніше, переслідується мета скоротити кількість зєднань, які потрібно виконувати у додатку на етапі прогону, оскільки (насправді) деякі з цих сполук вже виконані заздалегідь у складі робіт з проектування бази даних

3 Це зауваження фактично є не зовсім точним денормализация – це операція з змінними відносини, а не з збереженими файлами і тому не може застосовуватися на рівні збережених файлів. Але припущення про те, що деякий аналог денормалізації може виконуватися на рівні збережених файлів, аж ніяк не позбавлене сенсу

Рис 136 Денормалізованние дані про деталі і поставках

Як приклад розглянемо денормализация змінних відносини деталей і поставок для отримання змінної отношенія4 PSQ, представленої на рис 136 Слід зазначити, що змінна відносини PSQ знаходиться в 1НФ, а не в 2НФ

Деякі проблеми денормалізації

Використання поняття денормалізації повязано з деякими цілком очевидними проблемами Перша з них полягає в тому, що починаючи денормализация, важко сказати, коли її слід припинити У випадку виконання нормалізації існують ясні логічні критерії її продовження до тих пір, поки не буде досягнута найвища з можливих нормальних форм Чи слід при виконанні денормалізації прагнути до того, щоб досягти найнижчої з можливих нормальних форм Безумовно, ні, тому не існує ніяких логічних критеріїв точного визначення моменту припинення цього процесу Інакше кажучи, у разі денормалізації колишній підхід (що застосовувався при нормалізації), створений на підставі строго наукової і логічною теорії, замінюється чисто прагматичним і субєктивним підходом

Друге очевидне утруднення повязано з проблемами надмірності і аномаліями оновлення, які виникають через те, що доводиться мати справу з не повністю нормалізованими змінними відносини Ці проблеми досить детально обговорювалися вище Але менш очевидною є проблема вибірки даних, тобто денормализация може суттєво ускладнити виконання деяких запитів Розглянемо як приклад наступний запит: Знайти середня вага всіх деталей певного кольору. При використанні звичайного нормалізованого проекту найбільш підходяща формулювання даного запиту буде виглядати наступним чином

SUMMARIZE P BY { COLOR } ADD AVG ( WEIGHT ) AS AVWT

Але при використанні денормалізованного проекту, показаного на рис 136, це формулювання, яка показана нижче, стає трохи складніше (не кажучи вже про те, що в такій ситуації передбачається наявність принаймні однієї поставки для кожної деталі, що являє собою досить сміливе і в загальному невірне допущення)

4 При використанні нашого традиційного прикладу з змінними відносини постачальниківіпоставок, у разі денормалізації може виникнути проблема, повязана з тим, що в результаті зєднання буде втрачена інформація про постачальника з номером S5 З цієї причини можна припустити, що в процесі денормалізації слід використовувати операції зовнішніх сполук Однак, як показано в главі 19, саме по собі використання зовнішніх зєднань також супроводжується виникненням певних проблем

SUMMARIZE PSQ {Р #, COLOR, WEIGHT} BY {COLOR

} ADD AVG ( WEIGHT ) AS AVWT

(Зверніть увагу на те, що в другій формулюванні запит, ймовірно, буде до того ж виконуватися з більш низькою продуктивністю) Інакше кажучи, загальноприйняту думку про те, що денормализация хороша для вибірки, але погана для оновлення , є невірним, як з міркувань практичної застосовності, так і з міркувань продуктивності

Третя, і найголовніша, проблема формулюється таким чином (Це відноситься до правильної денормалізації, тобто до денормалізації, яка виконується тільки на фізичному рівні, а також до того типу денормалізації, яку іноді доводиться здійснювати в сучасних продуктах SQL) Коли йдеться про те, що денормализация сприяє досягненню високої продуктивності, фактично мається на увазі, що вона сприяє досягненню високої продуктивності деяких конкретних програм Будь-яка вибрана фізична структура, яка чудово підходить для одних додатків з точки зору їх продуктивності, може виявитися абсолютно непридатною для інших Наприклад, припустимо, що кожна базова змінна відносини відображається на один фізично бережене файл, а кожен бережене файл складається з фізично суміжного набору збережених записів, по одній для кожного кортежу відповідної змінної відносини Тоді стосовно даної структурі можна зробити наведені нижче зауваження

■ Припустимо, що зєднання відносин постачальників, поставок і деталей представ лено у вигляді однієї змінної відносини, тобто у вигляді одного зберігається файлу Тоді запит Отримати відомості про всіх постачальниках деталей червоного кольору завдяки обраної фізичної структурі буде, мабуть, виконуватися досить ефективно

■ Проте запит Отримати відомості про постачальників з Лондона при такій физи чеський структурі буде виконуватися менш ефективно в порівнянні зі струк турою, що складається з трьох окремих базових змінних відносини, кожна з яких відображена на фізично окремий бережене файл Справа в тому, що в останньому випадку всі записи з даними про постачальників є фізично суміжними, а в першому випадку дані будуть розподілені на більшій ділянці вуст ройства зберігання і для їх вибірки буде потрібно істотно більше операцій введення-виведення Аналогічні зауваження можна висловити по відношенню до всіх запитам, в яких доступ здійснюється тільки до даних про постачальників, дета лях або постачаннях окремо (без виконання операції зєднання)

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*