Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Друга нормальна форма (2НФ).
Друга нормальна форма (2НФ, 2NF) — нормальна форма використовна нормалізації баз даних. 2НФ первісно була визначена Едгаром Коддом в 1971.[1] Щоб бути в другій нормальній формі, таблиця, що знаходиться в першій нормальній формі, має відповідати додатковим критеріям. А саме: 1НФ таблиця знаходиться в 2НФ тоді і тільки тоді, коли для будь-якого потенційного ключа K і будь-якого атрибута A, який не є частиною потенційного ключа, A залежить саме від цілого потенційного ключа, а не від його частини. Трошки більш формально: 1NF таблиця знаходиться в 2НФ тоді і тільки тоді, коли всі її неключові атрибути функціонально залежні від цілих потенційних ключів. Зауважимо, що коли 1НФ таблиця не має складних потенційних ключів (таких, що складаються більш ніж з одного атрибута), тоді таблиця автоматично знаходиться в 2НФ. Друга нормальна форма (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем не залежали лише від частини ключа: · Схема бази даних повинна відповідати вимогам першої нормальної форми. · Дані, що повторно з'являються в декількох рядках виносяться в окремі таблиці. Наступний важливий крок в процесі нормалізації полягає у знищенні всіх неключових атрибуті, які залежать лише від частини первинного ключа. Такі атрибути називаються частково залежними. Неключові атрибути містять в собі інформацію про дану сутність предметної області, але не ідентифікують її унікальним чином. На цьому етапі досягається повна функціональна залежність усіх атрибутів від ключа за рахунок розбиття даних на кілька таблиць. До основних аномалій відноситься аномалія дублювання даних. Можливе дублювання даних виявляється шляхом встановлення тих атрибутів, які однозначно залежать від інших атрибутів, що не є ключовими (транзитивний зв”язок). Для усунення вказаного недоліку модель приводиться до третьої нормальної форми. 13.Третя нормальна форма (3НФ) — нормальна форма використовна в нормалізації баз даних. 3НФ первісно була визначена Едгаром Коддом в 1971.[1]Визначення: Кодд каже, що таблиця знаходиться в 3НФ тоді і тільки тоді, коли виконуються наступні умови: Відношення R (таблиця) знаходиться в 2НФ Кожен неключовий атрибут відношення R нетранзитивно залежить (тобто залежить безпосередньо) від кожного потенційного ключа в R. Неключовий атрибут R — атрибут, що не є частиною будь-якого потенційного ключа.[2] Транзитивною називають таку функціональну залежність, в якій X → Z (X визначає Z) непрямо, а через X → Y і Y → Z (і невірно, що Y → X).[3] Інше визначення 3НФ тотожне до визначення Кодда, дав Карло Заніоло в 1982. Це визначення стверджує, що таблиця в 3НФ тоді і тільки тоді, коли для кожної її функціональної залежності X → A, вірна хочаб одна з наступних умов: X містить A (тоді X → A це тривіальна функціональна залежність), або X це суперключ, або A - X, різниця множин A і X це ключовий атрибут (тобто, A - X міститься в потенційному ключі) Третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа: Схема бази даних повинна відповідати всім вимогам другої нормальної форми. Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.
Щоб привести базу до третьої нормальної форми, треба:
1. Визначити, в яких полях яких таблиць мається взаємозалежність. Як щойно йшлося, поля, які залежать більше один від одного (як місто від штату), ніж від ряду в цілому. У базі форуму такої проблеми немає. Поглянувши на таблицю повідомлень, побачите, що кожен заголовок, кожне тіло повідомлення ставиться до свого message ID.
2. Створіть відповідні таблиці. Якщо є проблемний стовпець в кроці 1, створюйте роздільні таблиці для нього. Як міста та штати, в прикладі з клієнтами.
3. Створіть або виділіть первинні ключі. Кожна таблиця повинна мати первинний ключ. Для прикладу з клієнтами це будуть city ID і state ID.
4. Створіть необхідні зовнішні ключі, які утворюють будь-яке з відносин. У нашому прикладі потрібно додати state ID в таблицю міст і city ID в таблицю клієнтів. Це зв'яже кожного клієнта з містом та штатом, де вони живуть.
|