Друга нормальна форма (2nf), блог про створення сайтів, просування сайтів, заробіток в інтернеті,
Частина 3.7: Друга нормальна форма (2NF)
Привіт, шановні відвідувачі сайту ZametkiNaPolyah.ru. Продовжуємо вивчати бази даних і наше знайомство з бібліотекою SQLite3. Для демонстрації прикладів з цієї частини я буду користуватися менеджером баз даних MySQL Workbench, встановивши його, ви з легкістю зможете повторити всі приклади. За традицією повторюємо визначення другої нормальної форми. Мінлива відносини знаходиться в другій нормальній формі тоді і тільки тоді, коли вона знаходиться в першій нормальній формі і кожен неключових атрибут неприводимого (функціонально повно) залежить від її потенційного ключа.
Розберемо це визначення: щоб база даних знаходилася в другій нормальній формі повинні бути дотримані вимоги першої нормальної форми. Друга нормальна форма. на відміну від першої, вимагає, щоб у наших сутностей обов'язково були ключові атрибути. І третя, сама незрозуміла частина визначення другої нормальної форми. що стосується функціональної залежності, говорить нам: щоб не було надмірності виводь дані в довідники.
Данну таблицю нам необхідно привести до другої нормальної форми
Хочу звернути вашу увагу на те, що база даних може прекрасно працювати без первинного ключа, а ось друга нормальна форма обійтися без нього не може. Давайте тепер на практиці подивимося, як привести ставлення до другої нормальної форми. Почнемо по порядку, у нас є таблиця, яка знаходиться в першій нормальній формі.
Дана таблиця знаходиться в першій нормальній формі
Ми виявили функціональні зв'язку, тепер можна створити таблиці-довідники на основі функціональних зв'язків. Іншими словами: ми просто розіб'ємо нашу таблицю на три.

Дане відношення знаходиться в другій нормальній формі
Наведу приклад приведення до другої нормальної форми у вигляді ER-діаграм.

Перетворення бази даних з першої нормальної форми в другу
Малюнок 23 коштує трохи пояснити. Домовимося: бази даних у нас поділяються найменуванням таблиць, якщо в назві таблиці є 1nf - вона відноситься до бази даних в 1-ій нормальній формі, 2nf - до БД в 2-ой, 3nf - до БД в третій.
Я не випадково виділив червоним на малюнку з діаграмою атрибути ZIP і City, дані атрибути мають транзитивною залежність (залежать не тільки від ключа, а й один від одного), така залежність веде до аномалії (логічним і смисловим помилок). Наприклад, оператор, що наповнює базу даних в поле City записав Одеса, а в поле індекс написав 644000 (індекс Маріуполь), якому значенню я повинен вірити? Щоб нам позбутися транзитивної залежності, необхідно привести нашу базу даних до третьої нормальної формі.