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

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

S { S#, SNAME, STATUS, CITY } PRIMARY KEY { S# }

P { P#, PNAME, COLOR,

WEIGHT, CITY } PRIMARY KEY

{ P# }

SP { S#, P#, QTY }

PRIMARY KEY { S#, P# }

FOREIGN KEY { S# } REFERENCES S

FOREIGN KEY { P# } REFERENCES P

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

На перший погляд цей проект бази здається цілком прийнятним І дійсно, в ньому передбачені три змінні відносини (s, P і SP), необхідні для подання всієї розглянутих даних, а в змінні відносини включені відповідні атрибути Зокрема, здається цілком очевидним, що атрибут CITY для міста постачальника повинен бути визначений у змінній відносини S, атрибут COLOR для кольору деталі – у змінній відносини Р, атрибут QTY для кількості деталей – у змінній відносини SP і тд Але на чому заснована така впевненість Причини, якими обумовлений вибір саме такого проекту бази даних, можна зрозуміти, змінивши його певним чином Припустимо, наприклад, що атрибут CITY видалений з змінної відносини постачальників S і доданий в змінну відносини поставок SP (Проте інтуїтивно це дія сприймається як помилкове, оскільки поняття місто

постачальника очевидним чином повязане з постачальниками, а не з поставками) На рис 121 представлений приклад вмісту змінної відносини поставок, зміненої подібним чином (вихідний варіант наведено на рис 111 в главі 11)

Примітка Щоб уникнути плутанини, повязаної з початкової змінної відносини SP, якої ми оперували раніше, ця змінена мінлива відносини буде далі позначатися SCP, як і в главі 11

На рис 121 можна легко помітити істотний недолік цього проекту – надмірність А саме, в кожному кортежі змінної відносини SCP для постачальника з номером S1 міститься інформація про те, що цей постачальник знаходиться в Лондоні в кожному кортежі змінної відносини SCP для постачальника з номером S2 наведено дані про те, що цей постачальник знаходиться в Парижі, і тд Інакше кажучи, відомості про місто, в якому знаходиться конкретний постачальник, повторюються відносно стільки разів, скільки поставок виконує даний постачальник Ця надмірність, в свою чергу, призводить до деяких інших проблем Наприклад, після оновлення даних1 про місцезнаходження постачальника з номером S1 в одному з кортежів може бути вказаний Лондон, а в іншому – Амстердам Таким чином, для створення гарного проекту слід дотримуватися принципу по одному факту в одному місці (Тобто уникати надмірності даних)Предметом нормалізації, по суті, стає всього лише формалізація подібних простих ідей, проте це має бути формалізація, яка дійсно буде мати велике практичне

значення при проектуванні бази даних

Звичайно, як вже згадувалося в главі 6, самі відносини в реляційної моделі завжди нормалізовані Можна сказати, що змінна відносинитакож нормалізована, оскільки її можливими значеннями є нормалізовані відносини Отже, в

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

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

Рис 121 Приклад значень даних у змінній відносини SCP

Однак деяка змінна відношення може бути нормалізованої в зазначеному сенсі і все ще мати певними небажаними властивостями Прикладом може служити змінна відносини SCP, показана на рис 121 Принципи подальшої нормалізації дозволяють розпізнати подібні випадки і привести такі змінні відношення до більш прийнятній формі У разі змінної відносини SCP ці принципи дозволили б точно встановити її недоліки і вказати на необхідність її розбиття на дві більш прийнятні змінні відносини: одну з атрибутами S # і CITY, а іншу з атрибутами s #, P # і QTY

Нормальні форми

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

На рис 122 показано кілька нормальних форм, які визначені до теперішнього часу Перші три (1НФ, 2НФ і ЗНФ) були описані Коддом (Codd) [116] Як видно з рис 122, все нормалізовані змінні відносини знаходяться в 1НФ, деякі змінні відносини в 1НФ також знаходяться в 2НФ, і деякі змінні відносини в 2НФ також знаходяться в ЗНФ Мотивом, яким керувався Кодд при введенні додаткових визначень, було те, що друга нормальна форма більш бажана (В сенсі, який буде розяснено нижче), ніж перша, а третя, в

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

Рис 122 Рівні нормалізації

У [116] наведено також опис процедури нормалізації, за допомогою якої змінна відносини в деякій нормальній формі, наприклад в 2НФ, може бути перетворена в кілька змінних відносини в іншій, більш бажаною нормальній формі, наприклад в ЗНФ (У вихідному варіанті ця процедура визначена тільки до третьої форми, але, як буде показано в наступному розділі, вона може бути послідовно розширена аж до пятого нормальної форми) Таку процедуру можна охарактеризувати як послідовне приведення заданого набору змінних відношення до деякої все більш бажаною формі Слід зазначити, що ця процедура оборотна, тобто завжди можна використовувати її результат (наприклад, безліч змінних відносини, що знаходяться в ЗНФ) для зворотного перетворення (у вихідну змінну відносини, що знаходиться в 2НФ) Можливість виконання зворотного перетворення є досить важливою характеристикою, оскільки це означає, що в процесі нормалізації зберігається інформація (не відбувається її втрата)

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

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

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

формою (ПСНФ) її називають також Петой нормальною формою або 5НФ Як показано на рис 122, деякі змінні відносини в НФБК знаходяться також в 4НФ, а деякі змінні відносини в 4НФ знаходяться також в 5НФ

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

Структура глави

Призначення даної глави – надати опис концепції подальшої нормалізації до рівня нормальної форми Бойса-Кодда включно Решта форми будуть розглянуті в розділі 13 Загалом, матеріал буде викладатися за таким планом Після цього трохи затягнувся введення в розділі 122 описується фундаментальна концепція декомпозиції без втрат і демонструється важливе значення поняття функціональної залежності (ФЗ) у цій концепції (Дійсно, поняття функціональної залежності є основою виділення трьох нормальних форм Кодда і нормальної форми Бойса-Кодца) Далі, в розділі 123, докладно розглядаються три початкові нормальні форми і на прикладі деякої змінної відносини демонструється, як виконується нормалізація аж до досягнення ЗНФ У розділі 124 буде зроблено невеличкий відступ в цілях обговорення питання альтернативних декомпозицій, тобто проблеми вибору найкращою декомпозиції для конкретної змінної відносини, якщо, звичайно, такий вибір можливий У розділі 125 обговорюється НФБК, а в розділі 126 розглядаються особливості роботи з атрибутами, приймаючими відносини в якості значень Нарешті, в розділі 127 наводиться короткий резюме і дається кілька заключних зауважень

Важливо зазначити, що далі виклад ведеться не настільки суворо, як раніше, і в своїх міркуваннях автор в основному покладається на інтуїтивне розуміння Подібний підхід може бути виправданий тим, що такі поняття, як декомпозиція без втрат, нормальна форма Бойса-Кодда та інші, незважаючи на їх таємничі і загадкові назви, по суті дуже прості та загальнодоступні У багатьох роботах, на які є посилання в цій книзі, цей матеріал викладається в більш суворої формі Хороший підручник можна знайти в [125]

Крім того, слід зробити ще два попередніх зауваження

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

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

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

2 Як згадувалося вище, процедура нормалізації буде використана як основа при описі різних нормальних форм Однак це не означає, що на практиці створення проекту бази даних буде виконуватися за допомогою цієї процедури Насправді, найімовірніше, для цього буде використана описана в главі 14 схема низхідного проектування Ідеї ​​нормалізації можна використовувати на наступних етапах для перевірки того, що отриманий в результаті проект не порушує, всупереч очікуваному, будь-яких її принципів Як би там не було, процедура нормалізації є зручним способом опису цих принципів Тому для спрощення викладу в цьому розділі буде прийнято корисне допущення про те, що проектування виконується за допомогою процедури нормалізації

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

*

*