Реляційні шаблони – ЧАСТИНА 3

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

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

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

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

Принципи проектування сутностей і атрибутів

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

■ Кожна сутність бази даних повинна описувати одну річ.

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

■ Кожен атрибут повинен описувати свою сутність і ніяку іншу, повязану з нею

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

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

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

Нормалізована модель бази даних має такі переваги перед ненормалізованного:

■ підвищена цілісність даних унеможливлює подвійне зберігання одних і тих же даних

■ скорочення суперечок за блокування ресурсів і покращена багатокористувальницька конкуренція

■ менші розміри файлів

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

Простота і нормалізація

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

Перша нормальна форма (1НФ)

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

■ Кожна одиниця даних представлена ​​в скалярному атрибуті Згідно Мерриама-Вебстера, скалярним називається значення, яке можна уявити точкою на шкалі

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

■ Всі дані повинні бути представлені унікальними атрибутами Кожен атрибут повинен мати унікальне імя і унікальне призначення Сутність не повинна містити повторювані атрибути Якщо деякий атрибут повторюється або сутність охоплює надто широку предметну область, значить, обєкт неправильно спроектований

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

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

Як приклад перших нормальної форми розглянемо список базових таборів і турів бази даних туристичної фірми Cape Hatteras Adventures У табл 23 представлені дані про базові таборах, які порушують першу нормальну форму Повторюваний атрибут туру не є унікальним

Таблиця 23 Порушення першої нормальної форми

BaseCamp

Tourl

Tour2 Tour3

Ashville

Appalachian Trail

Blue Ridge Parkway Hike

Cape Hatteras

Outer Banks Lighthouses

Freeport

Bahamas Dive

Ft Lauderdale

Amazon Trek

West Virginia

Gauley River Rafting

Щоб виправити цю модель і привести її до першої нормальної формі, зведемо повторювані групи атрибутів туру в єдиний унікальний атрибут (табл 24) Після цього ми перемістимо всі повторювані значення в унікальні елементи Сутність BaseCamp містить

унікальний елемент для кожного базового табору, а атрибут BaseCampID (ідентифікатор базового табору) сутності Tour посилається на первинний ключ сутності BaseCamp

Таблиця 24 База даних, яка задовольняє першій нормальній формі

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

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

■ Використання одного або двох чисел для кожного елемента даних вказує на те, що база даних скоро подолає діапазон допустимих значень

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

■ Бізнес-правила важко програмувати і підтримувати

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

Друга нормальна форма (2НФ)

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

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

Прикладом бази даних, що порушує другу нормальну форму, є база даних телефонних номерів базових таборів туристичної компанії Cape Hatteras Adventures, додана в сутність BaseCampTour (табл 25) Припустимо, що первинний ключ являє собою обєднання атрибутів BaseCamp і Tour і що телефонні номери закріплені саме за таборами, а не за турами

Таблиця 25 Порушення другої нормальної форми

BaseCamp (ПК)

Tour (ПК)

BaseCampPhoneNumber

Ashville

Appalachian Trail

828-555-1212

Ashville

Blue Ridge Parkway Hike

828-555-1212

Cape Hatteras

Outer Banks Lighthouses

828-555-1213

Freeport

Bahamas Dive

828-555-1214

Ft Lauderdale

Amazon Trek

828-555-1215

West Virginia

Gauley River Rafting

828-555-1216

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

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

Сутність Tour Сутність BaseCamp

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

Таблиця 26 Приведення до другої нормальної форми

BaseCamp (ПК)

Tour (ПК)

BaseCamp (ПК)

PhoneNumber

Ashville

Appalachian Trail

Ashville

828-555-1212

Ashville

Blue Ridge Parkway Hike

Cape Hatteras

828-555-1213

Cape Hatteras

Outer Banks Lighthouses

Freeport

828-555-1214

Freeport

Bahamas Dive

FtLauderdale

828-555-1215

FtLauderdale

Amazon Trek

West Virginia

828-555-1216

West Virginia

Gauley River Rafting

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

Третя нормальна форма (ЗНФ)

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

Як і друга нормальна форма, третя дозволяється переміщенням незалежного атрибута в нову сутність

Продовжуючи працювати з прикладом бази даних турфірми Cape Hatteras Adventures, призначимо кожному базового табору відповідального екскурсовода Атрибут BaseCampGuide належить сутності BaseCamp, однак якщо імя екскурсовода супроводжує будь-яка додаткова інформація, третя нормальна форма порушується (табл 27)

Таблиця 27 Порушення третьої нормальної форми

BaseCamp (ПК)

Сутність BaseCamp BaseCampPhoneNumber

LeadGuide

DateOfHire

Ashville

828-555-1212

Jeff Davis

1/5/1999

Cape Hateras

828-555-1213

Ken Frank

15/4/1997

Freeport

828-555-1214

Dab Smith

7/7/2001

Ft Lauderdale

828-555-1215

Sam Wilson

1/1/2002

West Virginia

828-555-1216

Lauren Jones

1/6/2000

Атрибут DateOf Hire (дата прийому на роботу) описує екскурсовода, а не базовий табір, отже, він не напряму залежить від первинного ключа сутності Ця залежність є транзитивної через атрибут LeadGuide

Сутність BaseCamp Сутність LeadGuide

BaseCamp (ПК) LeadGuide LeadGuide (ПК) DateOfHire

Створення сутності Guide і переміщення атрибутів екскурсовода в неї усуває порушення третьої нормальної форми, а також прояснює логічну модель (табл 28)

Таблиця 28 Приведення до третьої нормальної форми

Ashville

Jeff Davis

Jeff Davis

1/5/1999

Cape Hatteras

Ken Frank

Ken Frank

15/4/1997

Freeport

Dab Smith

Dab Smith

7/7/2001

FtLauderdale

Sam Wilson

Sam Wilson

1/1/2002

West Virginia

Lauren Jones

Lauren Jones

1/6/2000

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

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

Нормальна форма Бойса-Кодда (BNCF)

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

Четверта нормальна форма (4НФ)

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

Як приклад представимо наступну ситуацію

1 У якості складового первинного ключа використовуються атрибути BaseCamp (базовий табір) і LeadGuide (відповідальний екскурсовод)

2 Атрибути Event і Guide зведені разом в якості первинного ключа

3 Оскільки обидва ключа використовують екскурсовода, всі три зведені в єдину сутність

Наведений приклад порушує четверту нормальну форму

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

Пята нормальна форма (5НФ)

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

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

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

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

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

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

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

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

Реляційна алгебра

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

Реляційна алгебра містить вісім реляційних операторів

■ Обмеження Повертає рядки, які задовольняють заданій умові

■ Проекція Повертає з набору даних задані стовпці

■ Твір Реляційне множення повертає всі можливі комбінації даних з двох наборів

■ Злиття Реляційне додавання і віднімання, яке обєднує по вертикалі дві таблиці, розміщуючи одну над іншою і вирівнюючи стовпці

■ Перетин Повертає рядки, спільні для двох наборів даних

■ Різниця Повертає рядки, унікальні для одного набору даних

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

■ Ділення Повертає рядки, точно збігаються у двох наборах даних

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

■ Підзапити Це подібний з обєднанням, але більш гнучкий механізм Результати підзапиту можуть використовуватися замість вираження, списку або набору даних у зовнішньому запиті

На формальній мові реляційної алгебри:

■ таблиця або набір даних називається відношенням або суттю

■ рядок називається кортежем ,

■ стовпець називається атрибутом

Додаткова реляційної алгебри ми застосуємо на практиці в главах 9 і 10

інформація

Резюме

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

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

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*