Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Правила технічної нормалізації

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

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

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

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

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

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

Правило 1. Нормалізація зв'язку один - до - одному

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

image126

Мал. 2.86. Приклад зв'язку один - до - одному, що не вимагає нормалізації

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

даних тільки в тих випадках, коли необхідно відповідні відомості вивести в якості результату вибірки або внести туди дані.

Найчастіше з'являється ситуація, особливо за підсумками нормалізації по переходу від однієї нормальної форми до іншої, коли будуть дві сутності, що володіють зв'язком один - до - одному, і набори атрибутів обох сутностей повинні оброблятися практично при кожному зверненні до бази даних. Наприклад, наявність поділу атрибутів "Найменування" і "Ціна" в різні сутності при описі товару могло статися в результаті розгляду різних документів, де в одному атрибут "Ціна" був представлений, а в іншому - пет. У підсумку представлена ​​модель не є коректною і вимагає нормалізації (рис. 2.87).

image127

Мал. 2.87. Приклад зв'язку один - до - одному, що вимагає нормалізації


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

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

image128

Мал. 2.88. Результат нормалізації зв'язку один - до - одному


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

Правило 2. Нормалізація зв'язку багато - до - багатьох

Це єдиний зв'язок, яка може бути присутнім в логічної моделі, але відсутній у фізичній моделі бази даних. Цей зв'язок необхідно нормалізувати, оскільки вона створює багатозначну залежність між сутностями (рис. 2.89).

image129

Мал. 2.89. Приклад зв'язку багато - до - багатьох


При моделюванні логічної моделі бази даних розробники часто не піклуються про необхідність нормалізації зв'язку багато - до - багатьох. Пояснюється це тим, що після нормалізації діаграма моделі бази даних досить суттєво може бути ускладнена. Однак без нормалізації можлива втрата інформації, як, наприклад, втрачається ціна товару, оскільки у кожного постачальника ціна буде різна. Цей атрибут ( "Ціна товару") пов'язаний з сукупністю даних "Товар" - "Постачальник".

Якщо між двома сутностями встановлено зв'язок багато - до - багатьох (№М), то створюється нова сутність, де ключові атрибути вихідних сутностей об'єднуються в зчеплений первинний ключ, зв'язок між вихідними сутностями розривається, а створюється ідентифікує зв'язок один - до - багатьох (1: Д Г ) від вихідних сутностей до нової сутності.

Це правило вимагає від розробника виконати кілька операцій (рис. 2.90).

  • 1. Створити нову сутність, звану сутність-зв'язкою.
  • 2. Знищити зв'язок багато - до - багатьох між вихідними сутностями.
  • 3. Встановити ідентифікує зв'язок один - до - багатьох від вихідних сутностей до сутності-зв'язці, сформувавши там зчеплений первинний ключ, що складається з атрибутів первинних ключів вихідних сутностей.

image130

Ріс.2.90. Результат нормалізації зв'язку багато - до - багатьох


Як очевидно з прикладу, тепер є можливість додати атрибут "Ціна товару" відповідно до вимог предметної області. Однак, це вимога логічної нормалізації, а в разі технічного підходу сутності-зв'язки не мають додаткові атрибутами, забезпечуючи реалізацію багатозначною залежністю двох і більше сутностей. Правило 3. Нормалізація багатозначною залежності Варіант багатозначною залежності, коли одна сутність багатозначно залежить від кількох інших сутностей, зустрічається в базах даних досить часто (рис. 2.91). По суті, ця модель відображає вихідні структури для застосування нормалізації за правилом для четвертої нормальної форми.

image131

Мал. 2.91. Приклад багатозначною залежності сутностей


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

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

Реалізуючи це правило, розробник розглядає кожну зв'язок багато - до - багатьох незалежно від іншої аналогічної зв'язку, враховуючи особливість функціональної незалежності сутностей одного рівня (детермінант або залежна сутність). В результаті нормалізації (рис. 2.92) але оскільки він розглядався прикладу виходить дві сутності-зв'язки, не пов'язані один з одним, забезпечуючи збереження функціональної

незалежності категорії і постачальника, а модель відносин формує четверту нормальну форму.

image132

Мал. 2.92. Результат нормалізації багатозначною залежності

Правило 4. Нормалізація багатозначною залежності з'єднання Варіант наявності багатозначною залежності двох сутностей зустрічається найбільш часто, але бувають ситуації, коли багатозначна залежність зачіпає більше двох сутностей. Тоді доводиться згадувати про п'ятій нормальній формі, коли екземпляр загальної суті визначається тільки сукупністю всіх ключових атрибутів. В рамках багатозначною залежності сутностей складається аналогічна ситуація (рис. 2.93).

image133

Мал. 2.93. Багатозначна залежність між декількома сутностями

Припустимо, що в рамках моделювання були виділені сутності "Замовлення", "Товари" і "Постачальники". При цьому кожна сутність володіє власним унікальним набором допоміжних атрибутів, залежних тільки від наявного в сутності первинного ключа. З урахуванням особливості даних, які були проаналізовані, всі сутності з кожною іншою сутністю пов'язані зв'язком багато - до - багатьох. Оскільки на поточний момент не розглядається наявність атрибутів, що характеризують товар постачальника в конкретному замовленні, то ніяких інших сутностей, що пов'язують ці три об'єкти предметної області, в моделі бази даних не присутній.

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

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

По суті, такий процес нормалізації формує п'яту нормальну форму (рис. 2.94), тільки представлену чи не безліччю бінарному-складених сутностей-зв'язок, а єдину сутність-зв'язку, де всі ключові атрибути попарно залежні один від одного і забезпечення з'єднання вихідних сутностей, як і представляється в п'ятій нормальній формі, реалізується тільки на рівні всієї сукупності ключових атрибутів, складених в зчеплений первинний ключ.

image134

Мал. 2.94. Результат нормалізації багатозначною залежності


Правило 5. Нормалізація проекції

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

Припустимо, що в процесі аналізу предметної області та моделювання бази даних були виділені дві сутності: "Організації" і "Постачальники". Як очевидно з прикладу, сутність "Постачальники" усіма своїми атрибутами повністю повторюється атрибутами сутності "Організації", тобто сутність "Постачальники" є сутністю-проекцією щодо сутності "Організації".

image135

Мал. 2.95. Приклад суті і її проекції

Якщо з двох сутностей одна є проекцією щодо іншої, тобто всі її атрибути повторюються серед атрибутів більшою суті, то така сутність-проекція видаляється, а які були з нею зв'язку переносяться на велику сутність.

Важливо відзначити, що правило жодним чином не конкретизує необхідність точного збігу не тільки найменування і сенсу атрибутів, але і типів ідентичних атрибутів. Тут виникає деякий правило, полягає в тому, що апріорі вважається точний збіг сенсу і найменувань ідентичних атрибутів, а типи даних повинні бути приводяться, тобто повинна існувати проста можливість перекладу значення атрибута одного типу в аналогічний атрибут іншого типу або з іншими характеристиками без втрати даних. Наприклад, якщо атрибут "ІПН" в одній сутності буде представлений типом CHAR (5), а в іншій - типом INTEGER, то перетворення з CHAR в INTEGER буде проблематичним, оскільки символьно представлене число з провідними нулями (00712) буде представлено числом без провідних нулів (712), а це може привести до неточності представлення даних, сортування і коректності обробки. У той же час, зворотне перетворення з INTEGER в CIIAR (5) також може призвести до втрати даних, якщо число складається більш ніж з п'яти цифр. Це перетворення виконає обрізання отриманого рядка до необхідної кількості символів.

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

В результаті застосування правила нормалізації проекції потрібно враховувати деякі додаткові умови і правила:

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

Правило 6. Нормалізація проекції ключів

У процесі нормалізації формується багато сутностей-зв'язок, багато з яких є проекціями інших сутностей-зв'язок (рис. 2.96).

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

image136

Мал. 2.96. Приклад наявності суті-проекції


Припустимо, що в процесі нормалізації багатозначною залежності з'єднання була утворена сутність-зв'язка "Замовлення товарів", що з'єднує сукупністю атрибутів замовлення, товар і постачальника, а також в результаті нормалізації багатозначною залежності утворилася сутність-зв'язка "Постачальники товарів". В результаті сутність "Постачальники товарів" є проекцією сутності "Замовлення товарів".

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

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


малин оновлення значень зовнішніх ключів. При менш жорсткому правилі (рис. 2.97) НЕ передбачається створення сурогатного ключа, а зв'язок встановлюється без цієї процедури.

image137

Мал. 2.97. Результат нормалізації по менш жорсткого правилом


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

image138

Мал. 2.98. Результат нормалізації щодо жорсткішого правилом



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

Правило 7. Нормалізація ключових блоків

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

Уявімо, що в розглянутої предметної області модель містить дві сутності "Постачальники товарів" і "Замовлення товарів", пов'язані один з одним таким чином, що сутність "Постачальники товарів" є детермінантою, тобто батьківської сутністю. Таке уявлення моделі володіє істотними аномаліями оновлення (рис. 2.99).

image139

Мал. 2.99. Приклад ненормалізованих залежності


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

Аномалія зміни. Зміна одного з ключових атрибутів батьківської сутності "Постачальник товарів" не означає обов'язкове зміна такого ж атрибуту в дочірньої сутності "Замовлення товарів", що призведе до неузгодженості даних в обох сутності (відносинах).

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

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

image140

Мал. 2.100. Результат нормалізації ключів


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

Правила логічного нормалізації

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

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

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

Правило 1. Нормалізація класифікації

Вибудовуючи відносини з предметної області, розробники часто вказують як атрибути такі елементи, які ніяк, крім своїх даних, не представлені. При цьому відомості, які містять відповідні відносини, дуже часто повторюються і їх сукупність становить досить стабільний набір значень. У таких випадках розробники розглядають ці набори значень у вигляді класифікаторів.

Під класифікатором розуміється відношення, значення якого представляються мало змінним або незмінним набором даних.

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

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

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

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

"Організаційно-правова форма" (рис. 2.101). Цей атрибут відповідає таким умовам:

  • • значення є символьними;
  • • сукупність значень відносно досить стабільна і містить часте дублювання по різним екземплярів даних;
  • • сукупність значень визначається нормативними документами, що містять строгий їх перелік, змінюваний тільки при появі нового нормативного документа;
  • • пов'язаний функціональною залежністю з елементом "Організація", характеризуючи кожен екземпляр даних;
  • • потреба у вказівках точного значення, дотримуючись єдність відображення, при вибірці даних.

image141

Мал. 2.101. Приклад суті атрибута класифікації


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

image142

Мал. 2.102. Результат нормалізації класифікації


Застосувавши правило нормалізації, виділяють нову сутність "Організаційно-правова форма", куди розміщений атрибут "Організаційно правова форма" і створений сурогатний ключ числового типу. У вихідній суті відповідний атрибут повинен бути вилучений, оскільки встановлення зв'язку один - до - багатьох приведе до створення зовнішнього ключа, рівного але найменуванню первинному ключу нової сутності.

Важливим елементом такої нормалізації є створення сурогатного ключа саме числового твань, оскільки принципи роботи комп'ютерної техніки засновані на обробці числових значень. Ця умова накладає обмеження на використання символьних атрибутів в якості первинного ключа, за яким зазвичай проводиться встановлення зв'язків і реалізуються багато правила обмеження посилальної цілісності. Процеси обробки в операціях порівняння і сортування символьних даних менш швидкісні порівняно з такими ж операціями над числовими даними.

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

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

image143

Мал. 2.103. Приклад суті з множинними даними


Під ідентифікує сутність атрибутом розуміється такий атрибут, змістове наповнення якого визначає детермінант по функціональному зв'язку з іншими атрибутами сутності і відповідає її смисловим змістом.

У розглянутому прикладі, якщо розглянути набори значень, то неважко помітити, що атрибут "Товар" є класифікатором, пов'язаним з функціонально залежним атрибутом "Ціна". Оскільки в даному прикладі не розглядається постачальник товару, то ціна може бути характеристикою товару і використовуватися в рамках відповідної сутності.

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

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

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

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

image144

Мал. 2.104. Результат нормалізації множинних даних


Крім застосування даного правила до вихідної сутності або до результату нормалізації можна застосувати правило нормалізації класифікації, виділивши сутність "Товари" з атрибутом "Ціна", що є характеристикою товару.

Правило 3. Нормалізація багатозначною залежності Ще одним варіантом множинних даних, де може бути застосована логічна нормалізація, є багатозначна залежність (рис. 2.105), яка може бути ідентифікована розглядом зв'язків між атрибутами і ідентифікацією атрибутів, функціонально залежних від зчіпки багатозначно пов'язаних атрибутів.

image145

Мал. 2.105. Приклад суті з багатозначною залежністю


Припустимо, що по суті "Товари замовлення" є атрибут "Кількість", функціонально залежний від детермінанта, представленого зчіпкою атрибутів "Замовлення" і "Товар", пов'язаних багатозначною залежністю, тобто між ними може бути встановлено зв'язок багато - до - багатьох (рис. 2.106).

image146

Мал. 2.106. Тип зв'язку між замовленням і товаром


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

Якщо сутність містить атрибути, які містять багатозначну залежність, то створюються нові сутності, що відносяться до цих атрибутів, які відповідним чином розміщуються в них, і між сутностями встановлюються зв'язки один - до - багатьох в напрямку від нових сутностей до вихідної, формуючи з вихідної сутності зв'язку з збереженням атрибутів, функціонально залежних від зчіпки вихідних атрибутів.

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

Важливо звернути увагу на те, що розробник при застосуванні цього правила обов'язково повинен звернути увагу на додатково представлені атрибути у вихідній сутності. Цей аналіз повинен виявити атрибути, функціонально залежні від зв'язки вихідних атрибутів (рис. 2.107). Що ж стосується атрибутів, які не задовольняють цим вимогам, то вони повинні бути функціонально пов'язаними з окремими атрибутами сутності і мігрувати в нові сутності разом з ними.

Зазвичай, коли у вихідній суті існує два багатозначно пов'язаних атрибута, процедура нормалізації не викликає проблем. Однак

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

image147

Мал. 2.107. Результат нормалізації багатозначною залежності


 
<<   ЗМІСТ   >>