Datubāzu normalizācija: definīcija, normālās formas un piemēri

Uzzini datubāzu normalizācijas definīciju, pirmās trīs normālās formas, praktiskus piemērus un padomus, kā uzlabot datu integritāti un efektivitāti.

Datu bāzu normalizācija ir datubāzu projektēšanas pieeja, ko 1970. gados ieviesa Edgars F. Kods. Tā attiecas galvenokārt uz relāciju datubāzēm, kurās informācija tiek glabāta atsevišķās grupās — tabulās. Lai no tām iegūtu noderīgu informāciju, tabulas tiek savstarpēji saistītas ar saitēm (piemēram, ārējām atslēgām). Piemēram, skolēnus var glabāt vienā tabulā, bet klases — citā; lai parādītu, kurā klasē skolēns ir reģistrēts, tiek izmantota saite no skolēna ieraksta uz klases ierakstu. Skolēnam var būt saistība ar daudzām klasēm un klasei — ar daudziem skolēniem (daudz pret daudz).

Tradicionālā alternatīva ir plakanā datubāze, kurā visi dati ir salikti vienā kopā līdzīgā veidā kā izklājlapā. Plakanās struktūras trūkumi ir:

• daudz tukšu laukumu, ja daži ieraksti nesatur noteiktu informāciju;
• informācijas atkārtošanās (redundance), kas palielina datubāzes apjomu;
• atjaunināšanas, ievietošanas un dzēšanas anomālijas — vienas vērtības maiņa jāveic daudzās vietās;
• lielāka iespējamība kļūdu rašanās, jo dati nav centralizēti un atomizēti.

Relāciju datubāzes, sadalot datus loģiskās tabulās, samazina kļūdu iespējamību un nepieprasa lieku vietu, ja tās ir pareizi projektētas. Lai to nodrošinātu, pielieto datubāzu normalizāciju — sistēmisku metodi tabulu struktūras veidošanai.

Kas ir normalizācijas mērķis

• Samazināt redundanci — katra informācijas vienība tiek glabāta vienā vietā.
• Novērst anomālijas — atjaunināšanas, ievietošanas un dzēšanas problēmas.
• Saglabāt datu integritāti — caur atslēgām, integritātes ierobežojumiem un funkcionālajām atkarībām.
• Veicināt saprotamību — skaidri definētas tabulas ar viennozīmīgiem laukiem un atbildībām.

Normālās formas — īss pārskats

Datu bāzu normalizācijā ir vairākas normālās formas (NF). Katrai formai ir noteikumi, kuriem jāpieturas, lai novērstu noteiktu veidu atkarības un anomālijas. Kods sākotnēji definēja trīs pamatformas: pirmo (1NF), otro (2NF) un trešo (3NF). Vēlāk pievienotas papildu formas — Boyce–Codd NF (BCNF), ceturtā (4NF) un piektā (5NF). Zemāk ir izskaidrojums ar piemēriem.

Pirmā normālā forma (1NF)

Prasība: katrs laukam tabulā jābūt atomiskam — nedrīkst būt vairākas vērtības vienā laukā un nav sarakstu/iesaiņotu struktūru. Tabulas ieraksti ir homogenas rindas, bet laukos glabā tikai vienu vērtību.

Piemērs problēmai: ja tabulai "Skolēni" ir laukos "Klases" ar vērtību "1A, 2B", tā nav 1NF. Risinājums — katra klase jāievieto atsevišķā ierakstā vai jāizveido saistīta tabula, kas pārstāv attiecību starp skolēnu un klasēm.

Otrā normālā forma (2NF)

Prasība: jābūt 1NF, un visiem neatslēgas laukiem jābūt pilnībā atkarīgiem no visas primārās atslēgas. Šī forma attiecas galvenokārt uz tabulām ar kompozītu (salikto) atslēgu.

Piemērs:

• Tabula "KurssReģistrācija" ar primāro atslēgu (StudentID, CourseID) un laukiem StudentName un CourseName. StudentName ir atkarīgs tikai no StudentID — daļēja atkarība no kompozītās atslēgas. Tas pārkāpj 2NF.
• Risinājums: izveidot atsevišķas tabulas "Studenti" (StudentID → StudentName) un "Kursi" (CourseID → CourseName), bet "KurssReģistrācija" atstāt tikai attiecībām (StudentID, CourseID).

Trešā normālā forma (3NF)

Prasība: jābūt 2NF, un nav atkarību, kuras ir transitīvas (t.i., neatslēgas lauks nedrīkst būt atkarīgs no citas neatslēgas kolonnas). Citiem vārdiem, neatslēgas lauki nedrīkst dot informāciju par citām neatslēgas laukiem.

Piemērs transitive dependency:

• Tabulā "Darbinieki" ar laukiem EmployeeID (primārā atslēga), DeptID, DeptName; DeptName ir atkarīgs no DeptID, nevis tieši no EmployeeID. Tas ir transītīvs atkarības pārkāpums.
• Risinājums: izveidot tabulu "Departamenti" (DeptID → DeptName) un glabāt tikai DeptID "Darbinieki" tabulā kā ārējo atslēgu.

Boyce–Codd normālā forma (BCNF)

BCNF ir spēcīgāka par 3NF: prasa, lai katras funkcionālās atkarības determinantam būtu jābūt kandidātatslēgai. Praktiski tas nozīmē, ka pat dažas sarežģītākas atkarības, kuras 3NF var pieļaut, BCNF neatļauj.

Ceturtrā un piektā normālā forma (4NF, 5NF)

4NF risina vairāku vērtību atkarības (multi-valued dependencies). Ja objektam var būt neatkarīgi vairāki atkārtoti atribūti, tie jāizšķir atsevišķās tabulās. 5NF (piešķiršanās / savienojumu normālā forma) attiecas uz situācijām, kur pilnīga rekonstrukcija no mazākām tabulām var prasīt sarežģītus savienojumus, un tiek nodrošināts, lai nevajadzētu nekorektus vai liekus savienojumus, lai atjaunotu sākotnējo informāciju.

Tipiski piemēri ar soli-pa-solim sadalījumu

Sāksim ar ne-normālu (plakanu) tabulu "MācībuReģistrs":

• StudentID, StudentName, StudentAddress, CourseID, CourseName, TeacherName, Grade

Problēmas: CourseName un TeacherName tiek atkārtoti katrā reģistrācijā; StudentAddress atkārtojas, ja students reģistrējas vairākos kursos. Atjaunināšanas anomālijas: ja pasniedzēja vārds mainās, jāatjaunina visi ieraksti.

Normālās formas piemērs sadalot:

• "Studenti": StudentID → StudentName, StudentAddress
• "Kursi": CourseID → CourseName, TeacherID
• "Pasniedzēji": TeacherID → TeacherName
• "Reģistrācijas": StudentID, CourseID → Grade (attiecību tabula)

Šādi dati tiek atomizēti, redundance samazināta un datu atjaunināšana kļūst drošāka.

Funkcionālās atkarības un atslēgas

Normalizācija balstās uz funkcionālajām atkarībām — ja A funkcionāli nosaka B (raksturojums A → B), tad B vērtība ir unikāli noteikta A vērtības(s). Identificējiet kandidātatslēgas (unikālu ierakstu komplektu) un primāro atslēgu, pēc tam analizējiet visas funkcionālās atkarības, lai noteiktu, kur nepieciešamas papildu tabulas.

Praktiski padomi un kompromisi

• Normalizācija parasti uzlabo datu integritāti un samazina izmaksas ilgtermiņā, bet var palielināt vaicājumu skaitu (vairāk savienojumu — JOIN), kas ietekmē veiktspēju.
• Dažreiz tiek izmantota denormalizācija (apzināta informācijas kopēšana vai apvienošana) veiktspējas optimizācijai, taču to jāveic piesardzīgi ar skaidriem integritātes noteikumiem un atjaunināšanas stratēģijām.
• Indeksēšana, kešošana un pareiza vaicājumu optimizācija bieži vien ir labāki risinājumi nekā pārlieka denormalizācija.
• Praktiskā pieeja: parasti normalizē līdz 3NF vai BCNF, ja vien nav pamatotu iemeslu denormalizēt daļas veiktspējas dēļ.

Soli normālas datubāzes izveidē

• 1) Nosakiet visas nepieciešamās informācijas vienības un to atribūtus.
• 2) Identificējiet funkcionālās atkarības un kandidātatslēgas.
• 3) Pārvērtējiet tabulu struktūras, sadalot laukus tā, lai tiktu ievērotas 1NF–3NF prasības.
• 4) Pārbaudiet sarežģītākas atkarības un, ja nepieciešams, pielietojiet BCNF/4NF/5NF principus.
• 5) Testējiet reālus vaicājumus, uzraugiet veiktspēju un apsveriet selektīvu denormalizāciju, ja nepieciešams.

Noslēgums

Datu bāzu normalizācija ir fundamentāla metode, kas palīdz izveidot uzticamas, efektīvas un saprotamas relāciju datubāzes. Lai gan pastāv kompromisi starp normalizācijas pakāpi un vaicājumu veiktspēju, pamatprincipi — atomaritāte, novērst daļējas un transītīvas atkarības — paliek nemainīgi. Pārdomāts modelis, pareizas atslēgas un ierobežojumi, kā arī rūpīga testēšana nodrošinās datubāzes kvalitatīvu darbību ilgtermiņā.

Jautājumi un atbildes

J: Kas ir datubāzes normalizācija?

J: Kas ir plakanā datubāze?

J: Kā relāciju datubāzes samazina kļūdu iespējamību?

J: Kas ir normālās formas?

J: Kādi ir daži trūkumi, kas saistīti ar atbilstību noteiktiem normālo formu kritēriju kopumiem?

Meklēt pēc burta