Нормализација на базите на податоци со минимален вишок - IONOS

Еден од основните концепти на моделирање на релациони податоци е нормализирање. во модел на релациона база на податоци добриот дизајн на базата на податоци се карактеризира со минимум вишок. Причината: излишни податоци доведуваат до семантички аномалии. За возврат, се комплицира автоматската обработка на податоците и одржувањето на базата на податоци. Нормализацијата е стратегија за отстранување на технолошки вишок во релациони бази на податоци. Ние ќе ви покажеме како да го направите тоа.

вишок

  1. Што е нормализација?
  2. Нормализација: Како да ја нормализирате вашата база на податоци
    1. 1. Нормална форма (1NF)
    2. 2. Нормална форма (2NF)
    3. 3. Нормална форма (3NF)
  3. Повеќе нормални форми
    1. Бојс-Код нормална форма (3.5NF)
    2. 4. Нормална форма
    3. 5. Нормална форма
  4. Добрите и лошите страни на нормализацијата

Што е нормализација?

Нормализацијата е пристап кон дизајнирање на базата на податоци што се користи во релациони бази на податоци се користи за да се избегнат технолошки вишок.

Релацискиот модел на база на податоци е најраспространет концепт за компјутерско управување со податоци. Во релациони бази на податоци, информациите се зачувуваат како Евиденција во табели складирани кои се поврзани едни со други преку клучеви. Запис за податоци се состои од неколку вредносни опсези, кои се доделуваат на одредени атрибути преку колони на табели.

Следната табела ги прикажува зачуваните податоци за фактури за фиктивен монтер на компанија. Макс Мустерман нарачал 10 монитори, 12 влошки за глувци и 1 канцелариски стол за неговата компанија. Нарачката од Ерика Мустерфрау вклучува 2 лаптопа и 2 слушалки.

Во базата на податоци на онлајн продавницата, податоците за фактурите се доделуваат на атрибутите број на фактура (Р.Бр.), датум, клиент, број на клиент (К.Бр.), адреса, број на ставка на фактура (П.бр.), напис, број на написот (чл. - Бр.), Број (број) и доделена цена. Секоја линија од табелата се залага за еден запис за податоци. Таков запис се нарекува Тупл назначен.

Делот за базата на податоци прикажан погоре дејствува како а Пример за алош дизајн на база на податоци. На прв поглед се забележува дека табелата има бројни технолошки вишок. Покрај тоа, вредносните опсези во колоните Клиенти и Адреси содржат повеќеценети податоци. Некој зборува за ненормализирана база на податоци.

Главниот недостаток на ненормализираните бази на податоци е зголемената побарувачка на меморија заради непотребни вредности. Покрај тоа, атрибутите што содржат повеќеценети податоци тешко се читаат и се однесуваат едни на други.

Пример: Двајцата клиенти во делот за бази на податоци наведени погоре се со седиште во Мустерхаузен. Но, бидејќи овие информации не беа собрани одделно, базата на податоци не може лесно да се филтрира за клиенти од истата локација.

Со цел да се избегнат двојни и повеќеценети вредносни опсези, постојат три последователни во рамките на моделите на релациони бази на податоци Нормални форми е развиена.

Нормална форма е дефинирана целна состојба. За секоја нормална форма, специфицирани се посебни барања што мора да се исполнат доколку треба да се појави оваа целна состојба. Базата на податоци одговара на 1, 2 и 3 нормален формулар ако се исполнети сите барања за соодветната нормална форма.

Нормализацијата е трансформација на табелата на базата на податоци во нормална форма на повисок степен. Конверзијата во нормална форма на понизок степен се нарекува денормализација.

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

Со цел да се илустрира трансферот на релациона база на податоци во 1, 2 и 3 нормална форма, ќе ги играме одделните фази на Нормализација врз основа на пример од страна на Појдовна точка е делот за базата на податоци наведени погоре.

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

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

  • Сите податоци се атомски.
  • Сите колони во табелата содржат слични вредности.

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

Подолу ќе ја најдете нашата табела со податоци за фактури, во која ги обележавме со црвена боја сите опсези на вредности што не се атомски или не содржат еквивалентни податоци.

Бројните обележувања покажуваат: Нашата почетна табела ги крши и барањата и затоа не одговара на 1-та нормална форма.

Доколку наведениот дел од базата на податоци треба да се нормализира според 1-виот нормален образец, потребна е следнава постапка:

  1. Поделете ги сите повеќеценети податоци во посебни колони.
  2. Проверете ги вредностите во секоја колона за сличност.

За да се донесат записите за податоци во табелата со примери во атомска форма, атрибутите на клиентот и адресата мора да се расчленат на поспецифичните атрибути име и презиме или улица, број на куќа (Х.-Н.р.), поштенски код (поштенски код) и град.

Точката во која вредноста се смета за атомска зависи од контекстот на употребата. На пример, ако не е потребно раздвојување на името и презимето, целото име на една личност исто така може да се смета за атомско. Во пракса, сепак, препорачливо е да се поделат повеќеделни вредности во најмали можни единици.

Колоната за цени содржи информации во евра и центи. Одлучете точно за еден вид спецификација за да креирате слични опсези на вредности.

Резултатот е табела што одговара на 1-та нормална форма, но сепак поради двојни вредности нема ефикасна обработка на податоци дозволено. Затоа се препорачува да се претвори табелата во 2-та нормална форма со цел да се отстранат вишоците.

Првата нормална форма пропишува опсези на атомска вредност и на тој начин овозможува пребарување на базата на податоци. Податоците што се дел од не-атомскиот опсег на вредности не можат да се пребаруваат одделно.

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

Табела што треба да одговара на втората нормална форма мора да ги исполнува сите барања на 1-та нормална форма и исто така да го исполнува следниот услов:

  • Секој атрибут што не е клуч мора да биде целосно функционално зависен од примарниот клуч.

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

Во релациони бази на податоци, клучевите се користат за уникатно идентификување на записи за податоци (tuples). Клуч што овозможува индивидуалните линии на табелата на базата на податоци да бидат единствено именувани Супер клуч наречен. Таквиот клуч може да произлезе од вредностите на една колона или од збирот на вредностите на неколку колони.

Во нашиот пример, можни супер клучни резултати, на пример, од атрибутите број на фактура (Р.-Н.), бројот на клиентот (К.-Н.) и бројот на ставка на фактурата (П.-Н.). Го истакнавме супер клучот во боја во табелата подолу.

Копче што се состои од број на фактура, број на клиент и број на ставка на фактурата со вредностите овозможува, на пример, јасно да се идентификува записот за податоци што претставува купување лаптоп од Ерика Мустерфрау:

Сепак, не се потребни сите детали за избраната суперклука за ваква единствена идентификација. Комбинација од број на фактура и број на ставка на фактурата - т.е. подмножество на супер-клучот - би била доволна за идентификување на индивидуалните записи за податоци. Таквите клучеви со минимален број на атрибути ќе бидат Клучни кандидати или Алтернативен клуч наречен.

Како по правило, за секоја табела е избран еден клучен кандидат за мапирање на табелата. Последователното нумерирање е идеално. Таков клуч се нарекува Примарен клуч го означува и означува редоследот на евиденцијата на податоците.

Како и секој клучен кандидат, примарниот клуч може да биде еден дел или - како во нашиот пример - композитен клуч. Нашата табела со примери користи композитен примарен клуч што произлегува од бројот на фактурата и од бројот на фактурата.

Со цел да се претвори табелата на базата на податоци во 2-та нормална форма, не е важно само да се одредат примарниот клуч и сите не-клучни атрибути, туку и нивната врска едни со други. Следете ги овие чекори:

  1. Проверете дали сите не-клучни атрибути се целосно функционално зависни од примарниот клуч. Таква зависност постои само ако сите атрибути на примарниот клуч се неопходни за уникатно идентификување на не-клучниот атрибут. Ова исто така значи дека табелите со едноделни примарни клучеви автоматски одговараат на 2-та нормална форма ако се исполнети сите барања за 1-та нормална форма.
  2. Пренесете ги сите не-клучни атрибути кои не се целосно функционално зависни од целиот примарен клуч во одделни табели.

Ако погледнете внимателно во табелата со примероци, ќе видите дека Барања за 2-та нормална форма од следниве причини не е исполнето се: Колоната Датум зависи само од бројот на фактурата (Р.-Н.р.), но не и од бројот на ставка на фактурата (П.-Н.). Истото важи и за податоците за клиентите, име, презиме, улица, број на куќа (Н.-Н.), поштенски код и град.

Со цел да ја пренесеме табелата со податоци во 2-та нормална форма, ние ги аутсорсираме сите атрибути што зависат само од бројот на фактурата во посебна табела наречена „Фактура“.