Защо нормализация
Релационният модел не поставя изисквания към съдържанието на релационните схеми — проектантът има голяма свобода, която може да доведе до усложнена обработка, несигурност на информацията и лошо функциониране на ИС. Затова Код формулира изисквания към схемите и съдържанието, известни като нормални форми на РБД.
Нормализация
Процесът на довеждане на базата до изискванията на съответната нормална форма.
Целите: таблиците да са колкото може по-прости, да се избегне ненужното повторение на данни — така се минимизират усилията за въвеждане и се гарантира актуалността им.
Първа нормална форма (1НФ)
Двете изисквания на 1НФ
1. Няма колона, в която стойностите са сложни структури, които могат да се разбият на отделни неделими части (списъци, двойки код+име…).
2. Няма колони, които да са с един и същ смисъл.
Нарушение 1: списък в клетка
Таблица Доставчици с колона „Детайл", в която стои дъно, 2GH; дъно, 4GH; процесор, CPU2; … — списък, чиито елементи на всичкото отгоре са двойки (код, име). Прости питания като „Предлага ли Доставчик=X детайла Y?" изискват разбор на текста. След привеждане в 1НФ новата таблица има по-голяма степен и мощност и заема повече място — но улесненията си струват „недостатъците". Старият прост ключ (Доставчик) вече не стига — нужен е съставен ключ (Детайл, Доставчик).
Нарушение 2: еднотипни колони
Таблица с ключ (Предмет, Клас) и колони Учител1, Учител2 — двете колони съдържат данни от един и същ вид. Нормализацията: стойностите от двете колони се събират в една колона Учител — кортеж с два непразни учителя се разцепва на два кортежа. Старият ключ отново не върши работа и се избира нов.
Втора нормална форма (2НФ)
Ключово
Таблицата е във 2НФ, ако: 1) е в 1НФ; 2) при съставен ключ няма атрибут, който да е смислово зависим само от ЧАСТ от ключа, а не от целия ключ.
Пример: таблица с ключ (Детайл, Доставчик) и колона Име (на детайла). Кодът на детайла еднозначно определя името му — атрибутът Име зависи само от Детайл, не от целия ключ. Решението: отделяме двойката (Детайл, Име) в отделна таблица — каталог, свързващ код на обект с пълното му наименование. Същото важи за (Доставчик, Телефон) — втори каталог. Остава таблицата „доставя" (Доставчик, Детайл) — и трите таблици вече са във 2НФ.
| Таблица | Схема | Роля |
|---|---|---|
| Детайли | (Детайл, Име) | каталог: код → наименование |
| Доставчици | (Доставчик, Телефон) | каталог: доставчик → телефон |
| Доставя | (Доставчик, Детайл) | връзката M:N — кой какво предлага |
Трета нормална форма (3НФ)
Ключово
Таблицата е в 3НФ, ако: 1) е във 2НФ; 2) няма неключов атрибут X, който да е тясно (функционално) свързан с друг неключов атрибут Y.
Иначе при всяко обновяване на Y трябва да се обновява и X. Пример: добавяме към таблицата „доставя" атрибути Цена и Отстъпка%, като отстъпката зависи пряко от цената: до 49 лв. — 5%, до 100 лв. — 8%, над 100 лв. — 10%. Свързаността цена→отстъпка се отделя в отделна таблица (Цена до, Отстъпка%), а колоната за отстъпка отпада от първоначалната.
| Нормална форма | Изискване (накратко) |
|---|---|
| 1НФ | Атомарни стойности; без еднотипни колони |
| 2НФ | 1НФ + нищо не зависи само от част от съставния ключ |
| 3НФ | 2НФ + неключов атрибут не зависи от друг неключов атрибут |
Задачи от учебника (практикум)
1) Довършете нормализацията до 3НФ на разширената таблица „доставя" с цените и отстъпките. 2) Нормализирайте до 3НФ таблицата за заети книги от училищната библиотека — колона „Заети книги" съдържа списъци от вида „УБ234, Иван Вазов, Под игото; УБ1340, Любен Каравелов, Мамино детенце". Всяка книга се идентифицира с библиотечен номер, автор и заглавие.
Какво трябва да запомниш
- Нормализация = довеждане на базата до нормалните форми; целта е простота и без повторения.
- 1НФ: без списъци в клетките, без колони с еднакъв смисъл (Учител1/Учител2).
- 2НФ: без атрибути, зависещи само от част от съставния ключ → отделяме каталози.
- 3НФ: без функционална зависимост между неключови атрибути (Цена → Отстъпка%).
- Каталог = таблица код → пълно наименование.