ПРИМІТКА З ПРИВОДУ АТРИБУТІВ, МІСТЯТЬ ВІДНОСИНИ В ЯКОСТІ ЗНАЧЕНЬ

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

7 Отримати список номерів постачальників (s #) деталі з номером Р1

8 Отримати список номерів деталей (Р #), що поставляються постачальником з номером S1

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

1 (SPQ WHERE TUPLE {Р # Р # (Р1)} £ PQ {Р #}) {S #}

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp ( ( SPQ WHERE S# = S# (S1) ) UNGROUP PQ ) { P# }

У даному прикладі передбачається, що SPQ – це змінна відносини, допустимими значеннями якої є відносини у формі, аналогічній показаної на рис 1217 Слід зазначити, що в даному випадку не тільки спостерігається значна різниця між формулюваннями запитів, а й самі вони стають набагато складніше порівняно зі своїми аналогами для змінної відносини SP

Ще гірші справи з операціями оновлення Розглянемо наступні дві операції оновлення

1 Ввести відомості про нову поставку 500 штук деталей типу Р5, виконуваної по чальником з номером S6

2 Ввести відомості про нову поставку 500 штук деталей типу Р5, виконуваної по чальником з номером S2

При роботі зі звичайною змінною відносини SP між двома подібними оновленнями немає ніякої принципової різниці, оскільки в обох випадках мова йде про вставці в змінну відносини єдиного кортежу На противагу цьому, при роботі з змінної відносини SPQ виконувані оновлення будуть істотно

11Фактическиподобныепеременныеотношенияраньшедаженесчиталисьдопустимымииназывалисьненормализованными,тененаходящимисявпервой нормальнойформе (смтакжеглаву6)

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

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp INSERT SPQ RELATION

{ TUPLE { S# S# (S61),

PQ RELATION { TUPLE { P# P# ( P5 ) ,

QTY QTY ( 500 )}}} }

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp UPDATE SPQ WHERE S# = S# (S2)

{ INSERT PQ RELATION { TUPLE { P# P# { P5 ) ,

QTY QTY ( 500 ) } } }

Рис 1217 Мінлива відносини SPQ з атрибутом, що містить в якості значень інше ставлення

Змінні відносини (принаймні, базові змінні відносини) переважніше створювати без використання подібних атрибутів, що приймають як значень інші відносини, так як в цьому випадку вони мають більш простий логічною структурою, що істотно спрощує виконання з ними різних операцій Однак це зауваження слід сприймати лише як рекомендацію, але не як обовязкове правило На практиці цілком можуть виникати такі ситуації, коли має сенс використовувати атрибут зі значеннями у вигляді відносин у деякої змінної відносини і навіть у базовій змінної відносини Наприклад, на рис 1218 показано (частково) можливе значення змінної відносини каталогу RVK, в якій зберігаються відомості про змінних відносини деякої бази даних із зазначенням їх потенційних ключів Атрибут ск в цій змінній відносини містить значення у вигляді відносин Причому він одночасно є компонентом єдиного потенційного ключа змінної відносини RVK Визначення цієї змінної відносини на мові Tutorial D може виглядати, як показано нижче

VAR RVK BASE RELATION

{ RVNAME NAME, CK RELATION { ATTRNAME NAME

} } KEY { RVNAME, CK }

Примітка У упр 123 потрібно знайти спосіб усунення атрибутів, значеннями яких є відносини, якщо таке усунення є бажаним (що зазвичай має місце на практиці) 12

Рис 1218 Мінлива відносини RVK, що входить у каталог деякої бази даних

122 РЕЗЮМЕ

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

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

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

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

приведенням до НФБК і до декомпозиції із збереженням залежностей) у деяких випадках може призвести до конфліктної ситуації

На закінчення даної глави вашій увазі пропонується вельми витончене (і абсолютно точне) визначення ЗНФ і НФБК, дане Дзаніоло (Zaniolo) [127] Спочатку наведемо визначення ЗНФ

■ Третя нормальна форма (Визначення Дзаніоло) Припустимо, що дана змінна відношення R, що X є деяким підмножиною атрибутів цієї змінної відносини R і що А є деяким окремим атрибутом змінної відносини R Мінлива відносини R знаходиться в третій нормальній формі тоді і тільки тоді, коли для кожної функціональної залежності X → А у змінній відносини R вірно принаймні одну з таких тверджень

1 Підмножина X включає атрибут А (тобто дана ФЗ тривіальна)

2 Підмножина X є суперключом змінної відносини R

3 Атрибут А входить до складу деякого потенційного ключа змінної від носіння R

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

Джерело: Дейт К Дж, Введення в системи баз даних, 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>

*

*