Нормализиране на бази данни с минимална излишък - IONOS

Една от основните концепции на релационното моделиране на данни е нормализирането. в модел на релационна база данни добрият дизайн на базата данни се характеризира с минимум излишък. Причината: Излишните данни водят до семантични аномалии. Това от своя страна усложнява автоматичната обработка на данните и поддръжката на базата данни. Нормализацията е стратегия за премахване на съкращения в релационни бази данни. Ще ви покажем как да го направите.

ionos

  1. Какво е нормализиране?
  2. Нормализация: Как да нормализирате вашата база данни
    1. 1. Нормална форма (1NF)
    2. 2. Нормална форма (2NF)
    3. 3. Нормална форма (3NF)
  3. По-нормални форми
    1. Нормална форма на Бойс-Код (3.5NF)
    2. 4. Нормална форма
    3. 5. Нормална форма
  4. Плюсове и минуси на нормализирането

Какво е нормализиране?

Нормализацията е подход за проектиране на база данни, който се използва в релационни бази данни се използва за избягване на съкращения.

Моделът на релационната база данни е най-разпространената концепция за компютърно подпомагано управление на данни. В релационните бази данни информацията се съхранява като Записи в таблици които са свързани помежду си чрез ключове. Записът на данни се състои от няколко диапазона на стойности, които се присвояват на определени атрибути чрез колони на таблица.

Следващата таблица показва запазените данни за фактури за фиктивен фирмен монтьор. Макс Мустерман поръча 10 монитора, 12 подложки за мишка и 1 офис стол за своята компания. Поръчката от Erika Musterfrau включва 2 лаптопа и 2 слушалки.

В базата данни на онлайн магазина данните за фактурата се присвояват на атрибутите номер на фактура (R.No.), дата, клиент, клиентски номер (K.No.), адрес, номер на фактура (P.No.), артикул, номер на артикул (Art.- №), номер (номер) и определена цена. Всеки ред от таблицата означава един запис на данни. Такъв запис се нарича a Tuple определен.

Показаният по-горе раздел на базата данни действа като a Пример за aлош дизайн на база данни. На пръв поглед се забелязва, че таблицата има множество съкращения. Освен това диапазоните на стойностите в колоните „Клиент“ и „Адрес“ съдържат многозначни данни. Говори се за ненормирана база данни.

Основният недостатък на ненормираните бази данни е увеличените изисквания за памет поради излишни стойности. В допълнение, атрибутите, съдържащи многозначни данни, са трудни за четене и са свързани един с друг.

Пример: И двамата клиенти в раздела с базата данни, изброени по-горе, са базирани в Мустерхаузен. Но тъй като тази информация не беше събрана отделно, базата данни не може лесно да бъде филтрирана за клиенти от едно и също място.

За да се избегнат двойни и многозначни диапазони на стойността, има три последователни в рамките на моделите на релационни бази данни Нормални форми е разработен.

Нормалната форма е дефинирано целево състояние. За всяка нормална форма са посочени специални изисквания, които трябва да бъдат изпълнени, за да се постигне това целево състояние. Базата данни отговаря на 1-ва, 2-ра или 3-та нормална форма, ако са изпълнени всички изисквания за съответната нормална форма.

Нормализирането е преобразуването на таблица на базата данни в нормална форма от по-високо ниво. Превръщането в нормална форма от по-ниска степен се нарича денормализация.

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

За да илюстрираме преобразуването на релационна база данни в 1-ва, 2-ра и 3-та нормална форма, ще играем отделните етапи на Нормализация въз основа на пример от. Отправна точка е изброеният по-горе раздел с базата данни.

1. Нормална форма (1NF)

Таблица в релационна база данни отговаря на 1-ва нормална форма (1NF), ако са изпълнени следните изисквания:

  • Всички данни са атомни.
  • Всички колони на таблицата съдържат подобни стойности.

Запис се счита за атомен, ако всяка информация (всеки факт) е присвоена на отделно поле с данни.

По-долу ще намерите нашата таблица с данни за фактури, в която сме маркирали в червено всички диапазони на стойности, които са или неатомни, или които не съдържат еквивалентни данни.

Многобройните акценти показват: Нашата стартова таблица нарушава и двете изисквания и следователно не отговаря на първата нормална форма.

Ако изброеният раздел на базата данни трябва да бъде нормализиран съгласно първата нормална форма, се изисква следната процедура:

  1. Разделете всички многозначни данни в отделни колони.
  2. Проверете стойностите във всяка колона за сходство.

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

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

Графата Цена съдържа информация в евро и центове. Решете точно един тип спецификация, за да създадете подобни диапазони на стойности.

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

Първата нормална форма предписва атомни диапазони на стойности и по този начин дава възможност за заявки към база данни. Данните, които са част от неатомен диапазон от стойности, не могат да бъдат заявявани отделно.

2. Нормална форма (2NF)

Таблица, която трябва да съответства на 2-ра нормална форма, трябва да отговаря на всички изисквания на 1-ва нормална форма и да отговаря на следните условия:

  • Всеки неключов атрибут трябва да бъде напълно функционално зависим от първичния ключ.

Във въведението релационната база данни е дефинирана като система от отделни таблици, които са свързани помежду си посредством ключове.

В релационните бази данни ключовете се използват за еднозначно идентифициране на записи от данни (кортежи). Ключ, който позволява отделните редове на таблица на базата данни да бъдат уникално именувани Супер ключ Наречен. Такъв ключ може да се получи от стойностите на една колона или от сумата на стойностите на няколко колони.

В нашия пример възможен супер ключ се получава от атрибутите номер на фактура (R.-Nr.), клиентски номер (K.-Nr.) и номер на фактура (P.-Nr.). В таблицата по-долу сме подчертали цветния супер ключ.

Ключ, съставен от номер на фактура, номер на клиент и номер на фактура със стойностите, дава възможност, например, ясно да се идентифицира записът на данните, който представлява покупката на лаптоп от Erika Musterfrau:

Не са необходими обаче всички подробности за избрания супер ключ за такава уникална идентификация. Комбинация от номер на фактура и номер на фактура - т.е. подмножество на суперключа - би била достатъчна за идентифициране на отделните записи на данни. Такива ключове с минимален брой атрибути ще бъдат Ключови кандидати или Алтернативен ключ Наречен.

Като правило за всяка таблица се избира един ключов кандидат за картографиране на таблицата. Последователното номериране е идеално. Такъв ключ се нарича Първичен ключ обозначава и посочва реда на записите на данните.

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

За да конвертирате таблица на база данни във втората нормална форма, е важно не само да се определи първичният ключ и всички неключови атрибути, но и тяхната връзка помежду си. Следвай тези стъпки:

  1. Проверете дали всички неключови атрибути са напълно функционално зависими от първичния ключ. Такава зависимост съществува само ако всички атрибути на първичния ключ са необходими за еднозначно идентифициране на неключовия атрибут. Това също така означава, че таблиците с първични ключове от една част автоматично съответстват на 2-ри нормален формуляр, ако са изпълнени всички изисквания за 1-ви нормален формуляр.
  2. Преместете всички неключови атрибути, които не са напълно функционално зависими от целия първичен ключ, в отделни таблици.

Ако погледнете внимателно таблицата с пробите, ще видите, че Изисквания за 2-ра нормална форма поради следните причини не е изпълнено са: Графата Дата зависи само от номера на фактурата (R.-Nr.), но не и от номера на фактурата (P.-Nr.). Същото се отнася за собственото име, фамилията, улицата, домашния номер (H.-Nr.), пощенския код и града.

За да преобразуваме таблицата с данни във втората нормална форма, ние възлагаме на всички атрибути, които зависят само от номера на фактурата, в отделна таблица, наречена „Фактура“.