database normalization tutorial
Цей підручник пояснить, що таке нормалізація бази даних та різні нормальні форми, такі як 1NF 2NF 3NF та BCNF, із прикладами коду SQL:
Нормалізація бази даних - це добре відома техніка, яка використовується для проектування схеми бази даних.
Основною метою застосування техніки нормалізації є зменшення надмірності та залежності даних. Нормалізація допомагає нам розбити великі таблиці на кілька маленьких таблиць, визначаючи логічний зв'язок між цими таблицями.
Що ви дізнаєтесь:
- Що таке нормалізація бази даних?
- Висновок
Що таке нормалізація бази даних?
Нормалізація бази даних або нормалізація SQL допомагає нам згрупувати пов'язані дані в одну єдину таблицю. Будь-які атрибутивні дані або опосередковано пов’язані дані розміщуються в різних таблицях, і ці таблиці пов’язані логічним взаємозв’язком між батьківською та дочірньою таблицями.
У 1970 році Едгар Ф. Кодд висунув концепцію нормалізації. Він поділився статтею 'Реляційна модель даних для великих спільних банків', в якій запропонував 'Першу нормальну форму (1NF)'.
Переваги нормалізації СУБД
Нормалізація бази даних забезпечує наступні основні переваги:
- Нормалізація підвищує узгодженість даних, оскільки дозволяє уникнути дублювання даних, зберігаючи дані лише в одному місці.
- Нормалізація допомагає групувати подібні або пов'язані дані за однією і тією ж схемою, що призводить до кращого групування даних.
- Нормалізація покращує пошук швидше, оскільки індекси можна створювати швидше. Отже, нормалізована база даних або таблиця використовується для OLTP (Інтернет-обробка транзакцій).
Недоліки нормалізації бази даних
Нормалізація СУБД має такі недоліки:
- Ми не можемо знайти пов’язані дані, скажімо, про товар чи працівника в одному місці, і ми повинні об’єднати більше ніж одну таблицю. Це спричиняє затримку отримання даних.
- Таким чином, Нормалізація не є хорошим варіантом для транзакцій OLAP (Інтернет-аналітична обробка).
Перш ніж продовжувати далі, давайте зрозуміємо такі терміни:
- Суб'єкт: Сутність - це реальний об’єкт, де дані, пов’язані з таким об’єктом, зберігаються в таблиці. Прикладом таких об’єктів є працівники, кафедри, студенти тощо.
- Атрибути: Атрибути - це характеристики сутності, що дають деяку інформацію про Сутність. Наприклад, якщо таблиці є сутностями, то стовпці є їх атрибутами.
Типи звичайних форм
# 1) 1NF (перша нормальна форма)
За визначенням, сутність, яка не має жодних повторюваних стовпців або груп даних, може бути названа Першою звичайною формою. У першій звичайній формі кожен стовпець унікальний.
Нижче наведено, як виглядала б наша таблиця співробітників та підрозділів, якби у першій нормальній формі (1NF):
| empNum | прізвище | ім'я | deptName | deptCity | deptCountry |
|---|---|---|---|---|---|
| 1001 | Ендрюс | Джек | Рахунки | Нью-Йорк | Сполучені Штати |
| 1002 | Шватц | Майк | Технологія | Нью-Йорк | Сполучені Штати |
| 1009 | Кубок | Гаррі | HR | Берлін | Німеччина |
| 1007 | Гарві | Паркер | Адміністратор | Лондон | Об'єднане Королівство |
| 1007 | Гарві | Паркер | HR | Лондон | Об'єднане Королівство |
Тут усі стовпці таблиць Службовців та Відділів об’єднані в одне, і немає необхідності пов’язувати стовпці, наприклад deptNum, оскільки всі дані доступні в одному місці.
Але такою таблицею з усіма обов’язковими стовпцями в ній буде не тільки важко керувати, але й важко виконувати операції, а також неефективно з точки зору зберігання.
# 2) 2NF (друга нормальна форма)
За визначенням, сутність, яка дорівнює 1NF, та один з її атрибутів визначається як первинний ключ, а решта атрибутів залежать від первинного ключа.
Нижче наведено приклад того, як виглядатиме таблиця співробітників та підрозділів:
Таблиця співробітників:
| empNum | прізвище | ім'я |
|---|---|---|
| 1001 | Ендрюс | Джек |
| 1002 | Шватц | Майк |
| 1009 | Кубок | Гаррі |
| 1007 | Гарві | Паркер |
| 1007 | Гарві | Паркер |
Таблиця відділів:
| deptNum | deptName | deptCity | deptCountry |
|---|---|---|---|
| один | Рахунки | Нью-Йорк | Сполучені Штати |
| два | Технологія | Нью-Йорк | Сполучені Штати |
| 3 | HR | Берлін | Німеччина |
| 4 | Адміністратор | Лондон | Об'єднане Королівство |
Таблиця EmpDept:
| empDeptID | empNum | deptNum |
|---|---|---|
| один | 1001 | один |
| два | 1002 | два |
| 3 | 1009 | 3 |
| 4 | 1007 | 4 |
| 5 | 1007 | 3 |
Тут ми можемо помітити, що ми розділили таблицю у формі 1NF на три різні таблиці. таблиця 'Співробітники' - це сутність, присвячена всім працівникам компанії, а її атрибути описують властивості кожного працівника. Первинним ключем для цієї таблиці є empNum.
Аналогічно, таблиця Департаментів - це сутність усіх відділів компанії, а її атрибути описують властивості кожного відділу. Первинним ключем для цієї таблиці є deptNum.
У третій таблиці ми поєднали первинні ключі обох таблиць. Первинні ключі таблиць службовців та підрозділів у цій третій таблиці називаються зовнішніми ключами.
Якщо користувач хоче вихід, подібний до того, який ми мали в 1NF, тоді користувач повинен об'єднати всі три таблиці, використовуючи первинні ключі.
Зразок запиту буде виглядати, як показано нижче:
SELECT empNum, lastName, firstName, deptNum, deptName, deptCity, deptCountry FROM Employees A, Departments B, EmpDept C WHERE A.empNum = C.empNum AND B.deptNum = C.deptNum WITH UR; # 3) 3NF (третя нормальна форма)
За визначенням, таблиця вважається третьою нормаллю, якщо таблиця / сутність вже у другій нормальній формі, а стовпці таблиці / сутності неперехідно залежать від первинного ключа.
Давайте зрозуміємо неперехідну залежність за допомогою наступного прикладу.
Скажімо таблицю з іменем, Клієнт має наведені нижче стовпці:
CustomerID - Первинний ключ, що ідентифікує унікального клієнта
ЗамовникZIP - Поштовий індекс населеного пункту, в якому проживає клієнт
CustomerCity - місто, в якому проживає клієнт
У наведеному вище випадку стовпець CustomerCity залежить від стовпця CustomerZIP, а стовпець CustomerZIP залежить від CustomerID.
Наведений вище сценарій називається транзитивною залежністю стовпця CustomerCity від CustomerID, тобто первинним ключем. Після розуміння транзитивної залежності, тепер давайте обговоримо проблему з цією залежністю.
Можливий можливий сценарій, коли до таблиці вноситься небажане оновлення CustomerZIP до поштового індексу іншого міста без оновлення CustomerCity, тим самим залишаючи базу даних у несумісному стані.
Для того, щоб вирішити цю проблему, нам потрібно видалити транзитивну залежність, яку можна було зробити, створивши іншу таблицю, скажімо, таблицю CustZIP, яка містить два стовпці, тобто CustomerZIP (як первинний ключ) та CustomerCity.
Стовпець CustomerZIP у таблиці Customer - це зовнішній ключ для CustomerZIP у таблиці CustZIP. Ці відносини гарантують відсутність аномалій в оновленнях, при яких CustomerZIP оновлюється без внесення змін до CustomerCity.
# 4) Звичайна форма Бойса-Кодда (3,5 нормальна форма)
За визначенням, таблиця вважається нормальною формою Бойса-Кодда, якщо вона вже є у Третій нормальній формі, і для кожної функціональної залежності між A та B, A повинна бути суперключем.
Це визначення звучить дещо складно. Спробуймо розбити його, щоб краще зрозуміти це.
- Функціональна залежність: Атрибути або стовпці таблиці називаються функціонально залежними, коли атрибут або стовпець таблиці однозначно ідентифікує інший атрибут (и) або стовпець (и) тієї ж таблиці.
Наприклад, стовпець empNum або Номер працівника однозначно ідентифікує інші стовпці, такі як Ім'я працівника, Заробітна плата працівника тощо в таблиці Співробітник. - Супер ключ: Один ключ або група декількох ключів, які можуть однозначно ідентифікувати один рядок у таблиці, можна назвати Super Key. Загалом, ми знаємо такі ключі, як складові ключі.
Давайте розглянемо наступний сценарій, щоб зрозуміти, коли виникає проблема з третьою нормальною формою, і як приходить на допомогу звичайна форма Бойса-Кодда.
| empNum | ім'я | Порожнеча | deptName | deptHead |
|---|---|---|---|---|
| 1001 | Джек | Нью-Йорк | Рахунки | Реймонд |
| 1001 | Джек | Нью-Йорк | Технологія | Дональд |
| 1002 | Гаррі | Берлін | Рахунки | Самара |
| 1007 | Паркер | Лондон | HR | Елізабет |
| 1007 | Паркер | Лондон | Інфраструктура | Том |
У наведеному вище прикладі працівники з empNum 1001 та 1007 працюють у двох різних відділах. Кожне відділення має завідувача кафедрою. Для кожного відділу може бути кілька керівників відділів. Як і для бухгалтерії, Реймонд і Самара є двома керівниками департаментів.
У цьому випадку empNum та deptName є суперключами, що означає, що deptName є основним атрибутом. На основі цих двох стовпців ми можемо ідентифікувати кожен рядок однозначно.
Крім того, deptName залежить від deptHead, що означає, що deptHead є непростим атрибутом. Цей критерій дискваліфікує таблицю як частину BCNF.
Для вирішення цього питання ми розбиємо таблицю на три різні таблиці, як зазначено нижче:
Таблиця співробітників:
| empNum | ім'я | Порожнеча | deptNum |
|---|---|---|---|
| 1001 | Джек | Нью-Йорк | D1 |
| 1001 | Джек | Нью-Йорк | D2 |
| 1002 | Гаррі | Берлін | D1 |
| 1007 | Паркер | Лондон | D3 |
| 1007 | Паркер | Лондон | D4 |
Таблиця кафедри:
| deptNum | deptName | deptHead |
|---|---|---|
| D1 | Рахунки | Реймонд |
| D2 | Технологія | Дональд |
| D1 | Рахунки | Самара |
| D3 | HR | Елізабет |
| D4 | Інфраструктура | Том |
# 5) Четверта звичайна форма (4 звичайна форма)
За визначенням, таблиця знаходиться у четвертій звичайній формі, якщо вона не містить двох або більше незалежних даних, що описують відповідну сутність.
# 6) П’ята звичайна форма (5 звичайна форма)
Таблицю можна розглядати у П’ятій звичайній формі, лише якщо вона відповідає умовам для Четвертої звичайної форми і може бути розбита на кілька таблиць без втрати будь-яких даних.
що є хорошим завантажувачем музики для android
Часті запитання та відповіді
Q # 1) Що таке нормалізація в базі даних?
Відповідь: Нормалізація бази даних - це техніка проектування. Використовуючи це, ми можемо розробити або перепроектувати схеми в базі даних, щоб зменшити зайві дані та залежність даних, розбиваючи дані на менші та більш відповідні таблиці.
Q # 2) Які існують різні типи нормалізації?
Відповідь: Нижче наведені різні типи методів нормалізації, які можна використовувати для проектування схем баз даних:
- Перша звичайна форма (1NF)
- Друга нормальна форма (2NF)
- Третя нормальна форма (3NF)
- Звичайна форма Бойса-Кодда (3.5NF)
- Четверта нормальна форма (4NF)
- П'ята нормальна форма (5NF)
Q # 3) Яка мета нормалізації?
Відповідь: Основна мета нормалізації - зменшити надмірність даних, тобто дані повинні зберігатися лише один раз. Це робиться для того, щоб уникнути будь-яких аномалій даних, які можуть виникнути, коли ми намагаємось зберігати однакові дані в двох різних таблицях, але зміни застосовуються лише до однієї, а не до іншої.
Q # 4) Що таке денормалізація?
Відповідь: Денормалізація - це техніка підвищення продуктивності бази даних. Цей метод додає надлишкові дані до бази даних, на відміну від нормалізованої бази даних, яка видаляє надмірність даних.
Це робиться у величезних базах даних, де виконання JOIN для отримання даних з декількох таблиць є дорогою справою. Таким чином, надлишкові дані зберігаються в декількох таблицях, щоб уникнути операцій JOIN.
Висновок
Наразі ми всі пройшли три форми нормалізації бази даних.
Теоретично існують вищі форми нормалізації бази даних, такі як Нормальна форма Бойса-Кодда, 4NF, 5NF. Однак 3NF є широко використовуваною формою нормалізації у виробничих базах даних.
Щасливого читання !!
Рекомендована література
- Тестування баз даних за допомогою JMeter
- MongoDB Створення резервної копії бази даних
- MongoDB Створення підручника з бази даних
- 10 найкращих інструментів проектування баз даних для побудови складних моделей даних
- Продуктивність MongoDB: Ефективність блокування, Помилки сторінки та Профілювання бази даних
- Огляд реляційної бази даних Altibase з відкритим кодом
- Профайлер бази даних MongoDB для моніторингу запитів та продуктивності
- Як перевірити базу даних Oracle