ПЕРША, ДРУГА І третій нормальній формі

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

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

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

Отже, нижче наведено попереднє визначення ЗНФ

■&nbsp&nbsp&nbsp&nbsp Третя нормальна форма {Дуже неформальне визначення) Мінлива отноше ня знаходиться в ЗНФ тоді і тільки тоді, коли її неключових атрибути (якщо вони взагалі існують) є одночасно:

а) взаємно незалежними і

б) неприводимого залежимо ими від первинного ключа

Нижче наведені (неформальні) визначення понять неключові атрибути і

взаємно незалежні атрибути

■&nbsp&nbsp&nbsp&nbsp Неключових атрибут – Це атрибут, який не входить до складу первинного ключа розглянутої змінної відносини

■ Два або більше атрибутів називаються взаємно незалежними, якщо жоден з них функціонально не залежить від будь-якої комбінації інших атрибутів Подібна незалежність увазі, що кожен такий атрибут може обнов ляться незалежно від інших атрибутів

Наприклад, згідно з наведеним вище визначенням, змінна відносини Р (змінна відносини деталей) знаходиться в ЗНФ, а саме, атрибути PNAME (назва деталі), COLOR (колір), WEIGHT (вага) і CITY (місто) є незалежними один від одного (скажімо, колір деталей можна змінювати, не змінюючи їх ваги і тд) і неприводимого залежними по відношенню до первинному ключу {Р #} (номер деталі)

Таке неформальне визначення ЗНФ можна представити ще більш неформально,

таким чином

■&nbsp&nbsp&nbsp Третя нормальна форма {Ще більш неформальне визначення) Мінлива відносини знаходиться в ЗНФ тоді і тільки тоді, коли кожен кортеж складається із значення первинного ключа, що ідентифікує деяку сутність, і безлічі взаємно незалежних атрибутів, в кількості від нуля або більше, деяким чином описують цю сутність

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

Тепер можна повернутися до опису процедури нормалізації і дати визначення першої нормальної форми

ш Перша нормальна форма Мінлива відносини знаходиться в 1НФ тоді і тільки тоді, коли в будь-якому допустимому значенні цієї змінної відносини кожен її кортеж містить тільки одне значення для кожного з атрибутів

Фактично в цьому визначенні всього лише стверджується, що всі змінні відносини завжди перебувають у 1НФ, що, безсумнівно, вірно Однак змінна відносини, яка знаходиться тільки в 1НФ (Тобто не перебуває ні в другий, ні в третій нормальній формі), має структурою, не зовсім прийнятною з деяких причин Для ілюстрації цього факту допустимо, що інформація про постачальників і поставках міститься не в двох змінних відносини S і SP, а в одній, що має наступну структуру

FIRST { S#, STATUS, CITY, P#, QTY } PRIMARY KEY { S#, P# }

Це – розширена версія змінної відносини SCP, наведеної вище, в розділі 121 Її атрибути мають той же зміст, що й раніше, за винятком наступного додаткового обмеження, спеціально введеного в цьому прикладі

CITY  → STATUS

(Іншими словами, атрибут STATUS функціонально залежний від атрибута CITY, І сенс цього обмеження полягає в тому, що статус постачальника визначається його місцезнаходженням, наприклад, всі постачальники з Лондона  повинні мати статус 20) Крім того, для спрощення атрибут SNAME знову ігнорується Первинним ключем змінної відносини FIRST є комбінація атрибутів {S #, Р #}, а діаграма її функціональних залежностей буде мати вигляд, представлений на рис 125

Рис 125 Функціональні залежності у змінній відносини FIRST

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

Для ілюстрації деяких труднощів, повязаних з усуненням цих додаткових стрілок, на рис 126 наведено приклад даних у змінній відносини FIRST Це той же набір значень, який зазвичай використовується нами в прикладах, але значення 30 статусу постачальника з номером S3 замінено значенням 10 згідно із новим обмеженням, згідно з яким значення атрибута CITY визначає значення атрибута STATUS Виникла в результаті надмірність даних цілком очевидна, оскільки в кожному кортежі для постачальника з номером S1 атрибут CITY має значення London і, крім того, в кожному кортежі зі значенням London в атрибуті CITY вказано значення 20 для атрибута STATUS

Надмірність у змінній відносини FIRST призводить до різних аномаліям оновлення, отримав таку назву з історичних причин Під цим маються на увазі певні труднощі, що зявляються при виконанні операцій оновлення INSERT, DELETE і UPDATE Для початку розглянемо надмірність даних поставщікгород, відповідних функціональної залежності S # → CITY Нижче описані проблеми, які виникнуть при виконанні кожної із зазначених операцій оновлення

■&nbsp Операція INSERT Не можна помістити в змінну відносини FIRST інформацію про те, що деякий постачальник знаходиться в певному місті, до тих пір поки цей постачальник не виконає поставку хоча б однієї деталі Дійсно, в таблиці на рис 126 немає відомостей про постачальника з Афін з номером S5, оскільки до тих пір, поки цей постачальник не почне поставку якої-небудь деталі, для нього неможливо буде сформувати значення первинного ключа (Як і в розділі 104 глави 10, у цій главі прийнято достатньо обгрунтоване припущення, що атрибути первинного ключа не можуть мати значний, застосовуваних за замовчуванням)

Рис 126 Приклад даних у змінній відносини FIRST

■&nbsp Операція DELETE Якщо із змінної відносини FIRST видалити кортеж, який є єдиним для деякого постачальника, буде видалена не тільки інформація про поставку постачальником деякої деталі, але також інформація про те, що цей постачальник знаходиться в певному місті Наприклад, якщо із змінної відносини FIRST видалити кортеж із значенням S3 в атрибуті s # і

значенням Р2 в атрибуті Р #, буде втрачена інформація про те, що постачальник з номером S3 знаходиться в Парижі (По суті, проблеми видалення і вставки являють собою дві сторони однієї медалі)

Примітка У Насправді проблема полягає в тому, що у змінній відносини FIRST міститься занадто багато інформації,зібраної в одному місці, тому й втрачається занадто багато інформації при видаленні деяких кортежів Точніше кажучи, змінна відносини FIRST одночасно містить інформацію і про постачання, і про постачальників В результаті видалення інформації про поставку викликає також видалення інформації про постачальника Для вирішення цієї проблеми необхідно розділити інформацію на кілька частин, тобто зібрати відомості про постачання в однієї змінної відносини, а про постачальників – в іншій (саме це і буде зроблено трохи нижче) Отже, процедурі нормалізації можна дати ще одне неформальне визначення: охарактеризувати її як процедура розбиття логічно незвязаної інформації на окремі змінні відносини

■&nbsp Операція UPDATE Загалом, назва міста для кожного постачальника повторюється у змінній відносини FIRST кілька разів, і ця надмірність призводить до виникнення проблем при оновленні Наприклад, якщо постачальник з номером S1 переміститься з Лондона в Амстердам, то необхідно буде відшукати у змінній відносини FIRST всі кортежі, в яких значення S1 і London повязані між собою (для внесення відповідних змін), інакше база даних виявиться в суперечливому стані (в одних кортежах в якості міста, в якому знаходиться постачальник з номером S1, буде вказаний Лондон, а в інших-Амстердам)

Для вирішення всіх цих проблем, як пропонувалося вище, необхідно замінити змінну відносини FIRST двома наступними змінними відносини

SECOND { S#, STATUS, CITY

} SP    { S#, P#, QTY }

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

Легко переконатися, що змінена подібним чином структура даних дозволяє подолати всі перераховані вище проблеми, повязані з виконанням операцій оновлення

■&nbsp&nbsp&nbsp&nbsp Операція INSERT Тепер інформацію про те, що постачальник з номером S5 знахо диться в Афінах, можна помістити в базу даних, вставивши відповідний кортеж в змінну відносини SECOND, причому навіть у тому випадку, якщо він в Нині не постачає ніяких деталей

■&nbsp&nbsp&nbsp&nbsp Операція DELETE Тепер цілком можна виключити інформацію про поставку, в до торою зібрані відомості про постачальника з номером S3 і про деталі з номером Р2 Доста точно видалити відповідний кортеж із змінної відносини SP, причому ін формація про те, що постачальник з номером S3 знаходиться в Парижі, не втрачається

Рис 127 Функціональні залежності в змінних відносини SECOND і SP

Рис 128 Приклади значень даних у змінних відносини SECOND і SP

■&nbsp Операція UPDATE У переробленої структурі назва міста для кожного постачальника вказується всього один раз, оскільки існує тільки один кортеж для даного постачальника у змінній відносини SECOND (первинним ключем цієї змінної відносини є атрибут {S #}) Інакше кажучи, надмірність даних S #-CITY усунена Завдяки цьому тепер можна змінити назву міста Лондон для постачальника з номером si на Амстердам, не ризикуючи привести базу даних в неузгоджене стан, оскільки достатньо змінити назву міста у відповідному кортежі змінної відносини SECOND

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

Тепер можна дати визначення другої нормальної форми6

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

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

Обидві новоутворені змінні відносини (і SECOND, і SP) знаходяться в другій нормальній формі (їх первинними ключами, відповідно, є атрибут

{S #} і комбінація атрибутів {S #, p #}), тоді як змінна відносини FIRST чи не знаходиться в цій формі Всяку змінну відносини, яка знаходиться в першій нормальній формі, але не знаходиться в другій, завжди можна звести до еквівалентного безліч перемінних відносини, що знаходяться в 2НФ Цей процес полягає в заміні змінної відносини в 1НФ відповідним набором проекцій, еквівалентних вихідної змінної відносини, в тому сенсі, що при необхідності її завжди можна буде відновити за допомогою зворотної операції зєднання даних проекцій У нашому прикладі змінні відносини SECOND і SP – це проекціі7 змінної відносини FIRST, а змінна відносини FIRST є зєднанням змінних відносини SECOND і SP по атрибуту S #

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

R {А, В, С, D} PRIMARY KEY {А, В}

/ * Передбачається наявність функціональної залежності А → D * /

Процедура нормалізації передбачає заміну цієї змінної відносини наступними двома проекціями, R1 і R2

R1 { A, D }

PRIMARY KEY { A }

R2 {А, В, С}

PRIMARY KEY {А, В} FOREIGN KEY {A} REFERENCES Rl

Мінлива відносини R завжди може бути відновлена ​​за допомогою зєднання змінних відносини Rl і R2 по зовнішньому ключу і відповідному йому первинному ключу цих змінних відносини

Повернемося до розглянутого прикладу Слід зазначити, що обрана структура змінних відносини SECOND і SP все ще може викликати деякі проблеми

Структура змінної відносини SP цілком задовільна, оскільки вона фактично знаходиться в ЗНФ Тому ми більше не будемо приділяти їй увагу до кінця даного розділу Однак у змінній відносини SECOND неключові атрибути все

7 Якщо не враховувати того факту, що змінна відносини SECOND може містити додаткові кортежі (наприклад, кортеж для постачальника з номером S5), які не матимуть аналога у змінній відносини FIRST (див рис 118) Інакше кажучи, нова структура може містити інформацію, яку неможливо буде представити у вихідній структурі У цьому сенсі нову структуру можна розглядати як більш адекватне представлення реального світу

Глава 12 Подальша нормалізація: форми 1НФ, 2НФ, ЗНФ і НФБК 473

ще не є взаємно незалежними Діаграма функціональних залежностей для неї як і раніше має вигляд більш складний, ніж це потрібно для діаграми ФЗ змінної відносини, що знаходиться в ЗНФ Зокрема, залежність атрибута STATUS від атрибута s #, хоча і є функціональної і дійсно не приводиться, одночасно є транзитивної (Через атрибут CITY) ЦЕ означає, що кожне значення атрибута s # визначає значення атрибута CITY, а значення атрибута CITY в свою чергу визначає значення атрибута STATUS У загальному випадку, як уже було показано в розділі 11, якщо мають місце дві функціональні залежності, А → в і в → с, то має місце і транзитивна функціональна залежність А → С Однак наявність транзитивних залежностей може привести до виникнення описаних нижче аномалій оновлення (В даному випадку основна увага буде зосереджена на надмірності даних місто-статус, відповідної функціональної залежно

CITY  →   STATUS)

■&nbsp Операція INSERT Не можна помістити в базу даних відомості про те, що визна ленний місто характеризується деяким статусом (наприклад, не можна вказати, що всі постачальники з Риму повинні мати статус 50), до тих пір, поки в цьому місті не зявиться конкретний постачальник

■&nbsp Операція DELETE При видаленні із змінної відносини SECOND кортежу для деякого міста, представленого в ній цим єдиним кортежем, будуть видалені не тільки відомості про постачальника з даного міста, але й інформація про те, який статус відповідає самому місту Наприклад, при видаленні з змінної відносини SECOND кортежу для постачальника з номером S5 буде втрачена інформація про те, що для Афін був встановлений статус 30 (І в цьому випадку опе рації вставки і видалення фактично є двома сторонами однієї і тієї ж медалі)

Примітка І знову причиною подібних неприємностей є змішування інформації – мінлива відносини SECOND містить інформацію про постачальників і разом з нею інформацію про міста Для виходу з цієї ситуації слід вчинити так само, як і раніше, тобто розділити змішану інформацію і перенести одну її частину в змінну відносини з відомостями про постачальників, а іншу – в змінну відносини з відомостями про міста

■&nbsp Операція UPDATE У змінній відносини SECOND значення статусу для каж дого міста повторюється кілька разів (тому вона все ще володіє деякою надмірністю) Отже, якщо потрібно буде змінити для Лондона значе ние статусу 20 на 30, то буде потрібно відшукати у змінній відносини SECOND всі кортежі, в яких повязані між собою значення London і 20 (для внесення відповідних змін) В іншому випадку база даних виявиться в проти воречівом стані (в одних кортежах статус для Лондона буде дорівнює 20, а в інших-30)

І знову для вирішення цієї проблеми слід замінити вихідну змінну відносини (в даному випадку SECOND) наступними двома проекціями

SC { S#, CITY }

CS { CITY, STATUS }

Діаграми функціональних залежностей для цих змінних відносини показані на рис 129, а їх вміст – на рис 1210 Зверніть увагу, що інформація про статус Риму (Rome) включена тільки в змінну відносини CS Дане перетворення оборотно, оскільки змінна відносини SECOND може бути отримана за допомогою зєднання змінних відносини SC і CS по атрибуту CITY

Рис 129 Функціональні залежності в змінних відносини SC і CS

Рис 1210 Дані в змінних відносини SC і CS

І цього разу цілком очевидно, що подібна зміна структури змінних відносини дозволяє усунути всі описані вище проблеми в операціях оновлення Читачеві пропонується самостійно розібратися в подробицях вирішення цих проблем Порівнюючи рис 127 і 129, можна помітити, що завдяки подальшій декомпозиції вдалося виключити транзитивною залежність атрибута STATUS ВІД атрибута s # Це дозволило позбавитися від всіх існуючих труднощів Інтуїтивно зрозуміле пояснення полягає в тому, що у змінній відносини SECOND атрибут STATUS відповідає не тієї сутності, яка ідентифікується первинним ключем відношення (тобто номером постачальника), а містить інформацію про місто, в якому в даний час постачальник проводить свої ділові операції Саме змішування цих двох типів інформації в однієї змінної відносини приводило до виникнення описаних вище проблем

Тепер можна дати визначення третьої нормальної форми

■&nbsp&nbsp Третя нормальна форма(У визначенні передбачається наявність тільки одного потенційного ключа, який до того ж є первинним ключем відношення) Мінлива відносини знаходиться в третій нормальній формі тоді і тільки тоді, коли вона знаходиться в другій нормальній формі і жоден неключових атрибут не є транзитивно залежним від її первинного ключаПриміткаПід цим мається на увазі відсутність у змінній відносини транзитивних залежностей Це означає, що в ній відсутні будь взаємні залежності в зазначеному вище сенсі

Змінні відносини SC і CS знаходяться в третій нормальній формі, причому первинними ключами в них є, відповідно, атрибути {S #} і {CITY} Мінлива відносини SECOND чи не знаходиться в третій нормальній формі Мінлива відносини,

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

Підводячи підсумок сказаному, можна відзначити, що другий етап нормалізації полягає у створенні проекцій для усунення транзитивних залежностей Інакше кажучи, нехай дана змінна відношення R, що має наступний вид

R {А, В, С} PRIMARY KEY {A}

/ * Передбачається наявність функціональної залежності В → * /

Процедура нормалізації передбачає заміну змінної відносини R наступними двома проекціями, R1 і R2

R1 {В, С}

PRIMARY KEY {У}

R2 {А, В}

PRIMARY KEY { A }

FOREIGN KEY {У} REFERENCES Rl

Мінлива відносини R може бути відновлена ​​за допомогою зєднання змінних відносини R1 і R2 по зовнішньому ключу і відповідному йому первинному ключу цих змінних відносини

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

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

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

*

*