Нормализация на бази данни — принципи, нормални форми и примери

Практично ръководство за нормализация на бази данни: принципи, нормални форми (1NF, 2NF, 3NF) и примери за правилен дизайн, по-малко грешки и оптимизация на пространството.

Нормализирането на бази данни е подход за проектиране на бази данни, въведен от Едгар Ф. Код през 70-те години на миналия век. Някои бази данни, известни като релационни бази данни, позволяват данните да се съхраняват в отделни групи. Всяка група обикновено се нарича таблица. За да предоставят полезна информация, тези групи са свързани помежду си. Например учениците могат да се съхраняват в една група, а класовете - в друга група. За да се покаже, че даден ученик е записан в клас, се установява "връзка" от едната група към другата. Един ученик би могъл да има връзка с много класове, във всеки от които е записан, докато един клас би имал връзка с много ученици.

Традиционната алтернатива е "плоската файлова база данни", при която всички данни са групирани заедно като в електронна таблица. Проблемът с плоските файлови бази данни е, че те могат да имат много празни места и има много информация, която трябва да се повтаря за всеки запис. Това означава, че базата данни е по-голяма, отколкото трябва да бъде, и увеличава вероятността в нея да има грешки. Релационните бази данни, като разделят данните на групи, намаляват вероятността от грешки и не заемат повече място, отколкото е необходимо. Но за да работи, тя трябва да бъде добре проектирана.

Нормализирането на бази данни е метод за проектиране на добри релационни бази данни. Съществуват няколко "нормални форми", всяка от които има правила, на които базата данни трябва да отговаря. Първоначално Код е посочил три набора от критерии, на които трябва да отговарят различните бази данни: първа, втора и трета нормална форма.

Ако дадена релация (или "таблица от базата данни") отговаря на определена нормална форма, тя не е уязвима към определени модификации, които биха повлияли на целостта на данните. Недостатъкът на изпълнението на такъв набор от критерии обикновено е, че заявяването на определени данни от базата данни ще стане по-трудно.

Защо нормализираме — цел и проблеми, които се избягват

Целта на нормализацията е да се намали излишъкът (редунданцията) и да се предотвратят аномалии при вмъкване, изтриване и актуализиране на данни. Основните типове аномалии са:

• Аномалия при обновяване (update): при промяна на повтаряща се информация тя трябва да се промени на много места, което води до несъответствия, ако някъде се пропусне.
• Аномалия при вмъкване (insert): невъзможност да се въведе полезна информация без допълнителни, неизползваеми данни (например трябва да се въведе фиктивен запис).
• Аномалия при изтриване (delete): изтриване на един запис може да доведе до загуба на друга свързана информация, която трябва да се запази.

Ключови понятия

• Функционална зависимост: колона B е функционално зависима от колона A (A → B), ако за дадена стойност на A винаги има точно една стойност на B.
• Ключ: минимален набор от колони, който уникално идентифицира реда (candidate key). Един от кандидат-ключовете се избира за primary key.
• Частична зависимост: когато атрибут зависи само от част от композитния ключ (проблем за 2NF).
• Транзитивна зависимост: когато A → B и B → C, следва A → C; това може да причини проблеми за 3NF.

Нормални форми — обобщение и правила

Нормалните форми са стъпков процес: таблица в по-висока нормална форма отговаря и на всички по-ниски форми (при спазване на определения контекст).

Първа нормална форма (1NF)

Правило: всички клетки трябва да съдържат атомарни (неделими) стойности; не се допускат повторяеми групи или списъци в една колона. Таблицата трябва да има добре дефинирани колони и редове.

Пример за нарушение: колона "Телефони" съдържа списък от номера. За да приведем таблицата в 1NF, всеки телефон се прави отделен ред или се създава отделна таблица за телефоните.

Втора нормална форма (2NF)

Правило: таблицата трябва да е в 1NF и всеки неключов атрибут трябва да бъде функционално зависим от целия (композитен) ключ, а не от част от него. 2NF адресира частичните зависимости.

Важно: 2NF се отнася само когато имаме композитен ключ; ако ключът е едноколонен, условието за частична зависимост не възниква.

Трета нормална форма (3NF)

Правило: таблицата трябва да е в 2NF и да няма транзитивни зависимости между неключовите атрибути. Всеки неключов атрибут трябва да зависи единствено и само от ключа.

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

Бойс–Код (BCNF)

Правило: по-строга версия на 3NF. За всяка функционална зависимост X → Y в таблицата, X трябва да е суперключ (т.е. да съдържа ключ). BCNF решава някои случаи, които 3NF оставя.

По-високи нормални форми (4NF, 5NF и др.)

4NF се занимава с мултивалентни зависимости (когато едно поле може да има независими множество стойности). 5NF (проекционно-join нормална форма) разглежда ситуации с join зависимости. В практиката повечето приложения изискват до 3NF или BCNF; 4NF/5NF се използват при специфични сложни случаи.

Критерии при декомпозиция

При нормализиране често правим декомпозиция на една таблица на няколко по-малки. Важните свойства при декомпозиция са:

• Без загуба (lossless-join): след разцепване можем да възстановим оригиналната таблица чрез join без загуба на информация.
• Запазване на зависимости (dependency preservation): функционалните зависимости да могат да се проверяват без нужда от скъпи join операции. В някои случаи се предпочита lossless пред dependency preservation или обратното, в зависимост от изискванията.

Пример — стъпка по стъпка

Илюстрираме с опростен пример: първоначална таблица "Записи" (невалидна структура):

• StudentID, StudentName, CourseID, CourseName, Instructor, Grade

Проблеми:

• Повтаряне на името на студент и информация за курс при множество записвания.
• Актуализация на името на курс или преподавател изисква множество промени.
• Ако изтрием всички записи за курс, губим информация за курса.

Декомпозиция към 3NF/BCNF:

• Students(StudentID (PK), StudentName, други данни) — съхранява уникалните студенти.
• Courses(CourseID (PK), CourseName, InstructorID) — съхранява курсовете; ако е нужно, Instructor може да бъде референция към отделна таблица Instructors.
• Enrollments(StudentID (FK), CourseID (FK), Grade, primary key (StudentID, CourseID)) — връзката студент–курс с оценка.

Така премахваме излишъка, елиминираме частични и транзитивни зависимости и осигуряваме lossless декомпозиция (Enrollments служи като асоциативна таблица).

Практически съображения и компромиси

В реални системи има компромис между нормализацията и производителността. Много заявки изискват joins между нормализирани таблици, което може да забави четенето. Затова често се прилага денормализация на мястото на четене за оптимизация, кеширане или изграждане на агрегирани таблици. Решението зависи от характера на натоварването (често четене срещу чести записи), размера на данните и възможностите на СУБД.

Полезни съвети

• Започнете с правилна нормална структура (до 3NF/BCNF) и оптимизирайте при нужда чрез денормализация контролирано.
• Използвайте индекси за чести заявки, но бъдете внимателни — индекси засягат производителността при запис.
• Документирайте функционалните зависимости и ключовете — това помага при поддръжка и разширяване.
• Тествайте модела за типични операции (вмъкване/изтриване/актуализиране и често срещани заявки) преди пускане в продукция.

Нормализирането е основен инструмент в проектирането на релационни бази данни: то намалява грешките и излишното дублиране, подобрява целостта на данните и улеснява поддръжката. Всяка система обаче налага конкретни решения — добрата практика е да се разберат изискванията и да се намери баланс между нормализация и производителност.

Въпроси и отговори

В: Какво е нормализация на базата данни?

Въпрос: Какво представлява базата данни с плосък файл?

В: Как релационните бази данни намаляват вероятността от грешки?

В: Какво представляват нормалните форми?

В: Какви са някои недостатъци на изпълнението на определени набори от критерии за нормални форми?

Търсене по буква