Що таке нормалізація (або нормалізація)?
Відповіді:
Нормалізація полягає в основному для розробки схеми бази даних таким чином, щоб уникнути повторних і надмірних даних. Якщо частина даних дублюється декількома місцями в базі даних, існує ризик її оновлення в одному місці, але не в іншому, що призводить до пошкодження даних.
Існує ряд рівнів нормалізації від 1. нормальної форми до 5. нормальної форми. Кожна нормальна форма описує, як позбутися якоїсь конкретної проблеми, зазвичай пов’язаної із надмірністю.
Деякі типові помилки нормалізації:
(1) Маючи в комірці більше одного значення. Приклад:
UserId | Car
---------------------
1 | Toyota
2 | Ford,Cadillac
Тут стовпчик "Автомобіль" (який є рядком) має кілька значень. Це ображає першу нормальну форму, яка говорить про те, що кожна клітина повинна мати лише одне значення. Цю проблему ми можемо нормалізувати за допомогою окремого рядка на автомобіль:
UserId | Car
---------------------
1 | Toyota
2 | Ford
2 | Cadillac
Проблема з наявністю декількох значень в одній комірці полягає в тому, що це складно оновити, складно запитувати проти, і ви не можете застосовувати індекси, обмеження тощо.
(2) Маючи зайві не ключові дані (тобто дані повторюються без необхідності в кілька рядків). Приклад:
UserId | UserName | Car
-----------------------
1 | John | Toyota
2 | Sue | Ford
2 | Sue | Cadillac
Ця конструкція є проблемою, оскільки ім'я повторюється для кожного стовпця, навіть якщо ім'я завжди визначається UserId. Це теоретично дає можливість змінити ім’я Сью в один ряд, а не в інший, що є корупцією даних. Проблема вирішується розділенням таблиці на дві частини та створенням зв’язку первинний ключ / зовнішній ключ:
UserId(FK) | Car UserId(PK) | UserName
--------------------- -----------------
1 | Toyota 1 | John
2 | Ford 2 | Sue
2 | Cadillac
Тепер може здатися, що у нас все ще є зайві дані, оскільки UserId повторюються; Однак обмеження PK / FK гарантує, що значення не можна оновити самостійно, тому цілісність є безпечною.
Це важливо? Так, це дуже важливо. Маючи базу даних з помилками нормалізації, ви відкриваєте ризик потрапляння недійсних або пошкоджених даних у базу даних. Оскільки дані "живуть вічно", дуже важко позбутися пошкоджених даних, коли вони вперше увійшли до бази даних.
Не лякайтеся нормалізації . Офіційні технічні визначення рівнів нормалізації досить тугі. Звучить, що нормалізація - це складний математичний процес. Однак нормалізація - це в основному просто здоровий глузд, і ви виявите, що якщо розробити схему бази даних за допомогою здорового глузду, вона, як правило, повністю нормалізується.
Існує ряд помилок щодо нормалізації:
деякі вважають, що нормалізовані бази даних повільніші, а денормалізація покращує продуктивність. Однак це справедливо лише в дуже особливих випадках. Зазвичай нормалізована база даних також є найшвидшою.
іноді нормалізація описується як поступовий процес проектування, і ви повинні вирішити "коли зупинитись". Але насправді рівні нормалізації просто описують різні конкретні проблеми. Проблема, яку вирішують звичайні форми вище 3-го НФ, в першу чергу є досить рідкісними проблемами, тому шанси на те, що ваша схема вже в 5NF.
Чи застосовується це до чого-небудь поза базами даних? Не безпосередньо, ні. Принципи нормалізації досить специфічні для реляційних баз даних. Однак загальна основна тема - що у вас не повинно бути дублікатів даних, якщо різні екземпляри можуть вийти з синхронізації - може застосовуватися широко. Це в основному принцип DRY .
Правила нормалізації (джерело: невідомо)
... Тож допоможи мені Кодд.
Найголовніше, що він служить для видалення дублювання із записів бази даних. Наприклад, якщо у вас є декілька місць (таблиць), де може з’явитися ім’я людини, ви переміщуєте ім'я до окремої таблиці та посилаєтесь на неї скрізь. Таким чином, якщо вам потрібно пізніше змінити ім’я людини, вам доведеться змінити його лише в одному місці.
Це важливо для правильного проектування баз даних, і теоретично ви повинні використовувати її якомога більше, щоб зберегти цілісність ваших даних. Однак, отримуючи інформацію з багатьох таблиць, ви втрачаєте певну продуктивність, і тому іноді ви можете бачити денормалізовані таблиці баз даних (також звані сплющені), що використовуються в критичних для роботи програмах.
Моя порада - почати з хорошого ступеня нормалізації та робити денормалізацію лише тоді, коли це дійсно потрібно
PS також ознайомтеся з цією статтею: http://en.wikipedia.org/wiki/Database_normalization, щоб дізнатися більше про тему та про так звані нормальні форми
Нормалізація процедура, яка використовується для усунення надмірності та функціональних залежностей між стовпцями таблиці.
Існує кілька нормальних форм, як правило, позначених цифрою. Більша кількість означає менше скорочень та залежностей. Будь-яка таблиця SQL знаходиться в 1NF (перша нормальна форма, майже за визначенням). Нормалізація означає зміну схеми (часто розділення таблиць) зворотним способом, надання моделі, яка є функціонально однаковою, за винятком меншої надмірності та залежностей.
Надмірність та залежність даних небажана, оскільки це може призвести до невідповідностей при зміні даних.
Він призначений для зменшення надмірності даних.
Для більш формального обговорення, см Вікіпедії http://en.wikipedia.org/wiki/Database_normalization
Наведу дещо спрощений приклад.
Припустимо базу даних організації, яка зазвичай містить членів сім'ї
id, name, address
214 Mr. Chris 123 Main St.
317 Mrs. Chris 123 Main St.
можна нормалізувати як
id name familyID
214 Mr. Chris 27
317 Mrs. Chris 27
і сімейний стіл
ID, address
27 123 Main St.
Практично нормальна нормалізація (BCNF) зазвичай не використовується у виробництві, але є проміжним етапом. Після того, як ви розмістили базу даних в НФКАХ, наступний крок, як правило , в Де-нормалізує його в логічному порядку , щоб прискорити виконання запитів і зменшити складність деяких загальних вставок. Однак, ви не можете зробити це добре, якщо спочатку не нормалізувати його.
Ідея полягає в тому, що надмірна інформація зводиться до одного запису. Це особливо корисно в таких областях, як адреси, де містер Кріс подає свою адресу як Unit-7 123 Main St., а місіс Кріс перераховує Suite-7 123 Main Street, яка відображатиметься в оригінальній таблиці як дві різні адреси.
Як правило, застосовується техніка - пошук повторених елементів та виділення цих полів в іншу таблицю з унікальними ідентифікаторами та заміна повторених елементів первинним ключем, що посилається на нову таблицю.
Цитуючи дату CJ: Теорія є практичною.
Відхилення від нормалізації призведе до певних аномалій у вашій базі даних.
Відправлення з першої звичайної форми призведе до аномалій доступу, тобто означає, що вам потрібно розкласти та сканувати окремі значення, щоб знайти те, що ви шукаєте. Наприклад, якщо одним із значень є рядок "Ford, Cadillac", як це було дано попередньою відповіддю, і ви шукаєте всі випадки "Ford", вам доведеться розірвати рядок і подивитися на підрядки. Це певною мірою перешкоджає меті зберігання даних у реляційній базі даних.
Визначення Першої нормальної форми змінилося з 1970 року, але ці відмінності поки не потребують вас. Якщо ви проектуєте свої таблиці SQL за допомогою реляційної моделі даних, ваші таблиці автоматично знаходяться в 1NF.
Виїзд з другої нормальної форми і далі викличе аномалії оновлення, оскільки той самий факт зберігається у більш ніж одному місці. Ці проблеми унеможливлюють зберігання одних фактів без збереження інших фактів, які можуть не існувати, а тому повинні бути винайдені. Або коли факти змінюються, можливо, вам доведеться знайти всі площі, де зберігається факт, і оновити всі ці місця, щоб у вас не з’явилася база даних, яка суперечить собі. І коли ви збираєтесь видалити рядок із бази даних, ви можете виявити, що якщо це зробити, ви видаляєте єдине місце, де зберігається факт, який все ще потрібен.
Це логічні проблеми, а не проблеми з продуктивністю або просторові проблеми. Іноді ви можете обійти ці аномалії оновлення шляхом ретельного програмування. Іноді (часто) краще запобігти проблемам, в першу чергу, дотримуючись нормальних форм.
Незважаючи на значення у вже сказаному, слід зазначити, що нормалізація - це підхід знизу вгору, а не підхід зверху вниз. Якщо ви будете дотримуватися певних методологій під час аналізу даних та у своїй ідеальній конструкції, ви можете гарантувати, що конструкція буде відповідати як мінімум 3NF. У багатьох випадках конструкція буде повністю нормалізована.
Там, де ви, можливо, хочете застосувати поняття, викладені в рамках нормалізації, - це коли вам надаються застарілі дані, зі спадкової бази даних або з файлів, що складаються із записів, і дані були розроблені при повному ігноруванні нормальних форм та наслідків відхилення від них. У цих випадках може знадобитися виявити відступи від нормалізації та виправити проект.
Попередження: нормалізація часто викладається з релігійними обертонами, ніби кожен відхід від повної нормалізації - це гріх, образа проти Кодда. (маленький каламбур там). Не купуйте цього. Коли ви дійсно, дійсно вивчите дизайн баз даних, ви не тільки будете знати, як слідувати правилам, але й знатимете, коли їх безпечно порушувати.
Нормалізація - одне з основних понять. Це означає, що дві речі не впливають одна на одну.
У базах даних конкретно означає, що дві (або більше) таблиці не містять однакових даних, тобто не мають надмірності.
На перший погляд, це дійсно добре, тому що ваші шанси зробити деякі проблеми синхронізації близькі до нуля, ви завжди знаєте, де ваші дані і т. Д. Але, напевно, ваша кількість таблиць зросте, і у вас будуть проблеми з перетином даних і отримати деякі підсумкові результати.
Отже, наприкінці ви закінчите дизайн бази даних, який не є чисто нормалізованим, з деякою надмірністю (це буде в деяких можливих рівнях нормалізації).
Що таке нормалізація?
Нормалізація - це ступінчастий формальний процес, який дозволяє нам розкласти таблиці баз даних таким чином, щоб зменшити як надмірність даних, так і аномалії оновлення .
Нормалізація Процес Надано
Спочатку нормальна форма тоді і тільки тоді, коли домен кожного атрибута містить лише атомні значення (атомне значення - це значення, яке неможливо розділити), а значення кожного атрибута містить лише одне значення з цього домену (наприклад: - домен для гендерний стовпчик: "М", "Ж".).
Перша нормальна форма виконує ці критерії:
- Виключіть повторювані групи в окремих таблицях.
- Створіть окрему таблицю для кожного набору пов’язаних даних.
- Визначте кожен набір пов’язаних даних за допомогою первинного ключа
Друга нормальна форма = 1NF + відсутність часткових залежностей, тобто всі неклавішні атрибути повністю функціонально залежать від первинного ключа.
Третя нормальна форма = 2NF + відсутність перехідних залежностей, тобто всі атрибути, які не є ключовими, повністю функціонально залежать безпосередньо від первинного ключа.
Нормальна форма Бойса - Кодда (або BCNF або 3,5NF) - дещо сильніша версія третьої нормальної форми (3NF).
Примітка: - Друга, третя та нормальні форми Бойса – Кодда пов'язані з функціональними залежностями. Приклади
Четверта нормальна форма = 3NF + видалити багатозначні залежності
П'ята нормальна форма = 4NF + усунення приєднаних залежностей
Як говорить Мартін Клеппман у своїй книзі "Проектування інтенсивних додатків":
Література про реляційну модель розрізняє декілька різних нормальних форм, але розрізнення мало практичного інтересу. Як правило, якщо ви дублюєте значення, які можна зберегти лише в одному місці, схема не нормалізується.
Це допомагає запобігти повторенню (і ще гірше конфліктних) даних.
Хоча це може мати негативний вплив на продуктивність.