KĀDA IR TREŠĀ NORMĀLĀ FORMA? (DATU BĀZES) - TEHNOLOĢIJAS - 2025

Trešais normāla forma (datu bāzes) ir relāciju datu bāzes projektēšanas metode, kur dažādas tabulas, kas veido tā ne tikai atbilst otro normālu formu, bet visas tās atribūti vai lauki ir tieši atkarīgi no primāro atslēgu.

Izstrādājot datu bāzi, galvenais mērķis ir izveidot precīzu datu, to savstarpējo attiecību un atbilstošo datu ierobežojumu attēlojumu.

Avots: pixabay.com

Lai sasniegtu šo mērķi, var izmantot dažas datu bāzes projektēšanas metodes, starp kurām ir normalizēšana.

Šis ir datu organizēšanas process datu bāzē, lai izvairītos no dublēšanās un iespējamām anomālijām datu ievietošanā, atjaunināšanā vai novēršanā, tādējādi ģenerējot vienkāršu un stabilu konceptuālā modeļa dizainu.

Sākumā tiek pārbaudītas atribūtu funkcionālās attiecības vai atkarība. Tie apraksta kādu datu īpašību vai to attiecības.

Normālas formas

Normalizācijā tiek izmantota testu sērija, ko sauc par normālām formām, lai palīdzētu noteikt šo atribūtu optimālu grupēšanu un galu galā izveidotu atbilstošu attiecību kopumu, kas atbalsta uzņēmuma prasības attiecībā uz datiem.

Tas ir, normalizācijas tehnika ir veidota ap normālas formas jēdzienu, kas nosaka ierobežojumu sistēmu. Ja attiecības atbilst noteiktas normālas formas ierobežojumiem, tiek uzskatīts, ka attiecības ir šajā normālajā formā.

Pirmā normālā forma (1FN)

Tabula tiek uzskatīta par 1FN, ja visi atribūti vai lauki tajā satur tikai unikālas vērtības. Tas ir, katra atribūta katrai vērtībai jābūt nedalāmai.

Pēc definīcijas relāciju datu bāze vienmēr tiks normalizēta līdz pirmajai normālajai formai, jo atribūtu vērtības vienmēr ir atomu. Visas attiecības datu bāzē ir 1FN.

Tomēr, vienkārši atstājot datu bāzi, tā tiek stimulēta virkne problēmu, piemēram, atlaišana un iespējamās jaunināšanas kļūmes. Lai labotu šīs problēmas, tika izstrādātas augstākas normālas formas.

Otrā normālā forma (2FN)

Tas nodarbojas ar apaļu atkarību noņemšanu no galda. Tiek apgalvots, ka saistība ir 2FN, ja tā ir 1FN, un turklāt katrs lauks vai atribūts, kas nav atslēgas, pilnībā ir atkarīgs no primārās atslēgas, vai precīzāk, tas nodrošina, ka tabulai ir viens mērķis.

Atribūts, kas nav atslēga, ir jebkurš atribūts, kas neietilpst attiecību primārajā atslēgā.

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

Tas nodarbojas ar pārejas posma atkarību novēršanu no tabulas. Tas ir, noņemiet ne-atslēgas atribūtus, kas nav atkarīgi no primārās atslēgas, bet gan no cita atribūta.

Transitīvā atkarība ir funkcionālās atkarības veids, kurā lauka, kas nav atslēga, vai atribūta vērtību nosaka cita lauka vērtība, kas arī nav atslēga.

Jums jāmeklē atkārtotas vērtības atribūtos, kas nav atslēgas, lai pārliecinātos, ka šie atribūti, kas nav atslēgas, nav atkarīgi no kaut kā cita, izņemot primāro atslēgu.

Tiek uzskatīts, ka atribūti ir savstarpēji neatkarīgi, ja neviens no tiem nav funkcionāli atkarīgs no citu apvienojuma. Šī savstarpējā neatkarība nodrošina to, ka atribūtus var atjaunināt individuāli, nedraudot ietekmēt citu atribūtu.

Tāpēc, lai attiecības datu bāzē būtu trešajā normālajā formā, tām jāatbilst:

- Visas 2FN prasības.

- Ja ir atribūti, kas nav saistīti ar primāro atslēgu, tie ir jānoņem un jānovieto atsevišķā tabulā, abas tabulas saistot ar svešas atslēgas palīdzību. Tas ir, nevajadzētu būt pārejošām atkarībām.

Trešās normālās formas piemēri

1. piemērs

Ļaujiet tabulai būt STUDENTAM, kuras galvenā atslēga ir studenta identifikācija (STUDENT_ID) un kuru veido šādi atribūti: STUDENT_NAME, STREET, CITY un POST_CODE, kas atbilst 2FN nosacījumiem.

Šajā gadījumā STREET un CITY nav tiešas saistības ar primāro atslēgu STUDENT_ID, jo tie nav tieši saistīti ar studentu, bet ir pilnībā atkarīgi no pasta indeksa.

Tā kā students atrodas vietā, kuru nosaka CODE_POSTAL, STREET un CITY ir saistītas ar šo atribūtu. Šīs otrās atkarības pakāpes dēļ šie atribūti nav jāuzglabā STUDENTU tabulā.

Izveidojiet jaunu tabulu

Pieņemsim, ka vienā pasta indeksā ir vairāki studenti, un tabulā STUDENT ir ļoti daudz ierakstu un ir jāmaina ielas vai pilsētas nosaukums, tad šī iela vai pilsēta ir jāatrod un jāatjaunina visā tabulā. STUDENTS.

Piemēram, ja jums jāmaina iela “El Limón” uz “El Limón II”, jums visā STUDENT tabulā būs jāmeklē “El Limón” un pēc tam tas jāatjaunina uz “El Limón II”.

Meklēšana milzīgā tabulā un atsevišķa vai vairāku ierakstu atjaunināšana prasīs daudz laika, un tāpēc tie ietekmē datu bāzes darbību.

Tā vietā šo informāciju var glabāt atsevišķā tabulā (POSTCARD), kas saistīta ar tabulu STUDENT, izmantojot atribūtu POST_CODE.

POST tabulā būs salīdzinoši mazāk ierakstu, un šī POST tabula būs jāatjaunina tikai vienreiz. Tas automātiski tiks atspoguļots STUDENTU tabulā, vienkāršojot datu bāzi un vaicājumus. Tātad tabulas būs 3FN:

2. piemērs

Ļaujiet šo tabulu izmantot kā Project_Num lauku kā galveno atslēgu un ar atkārtotām vērtībām atribūtos, kas nav atslēgas.

Tālruņa vērtība tiek atkārtota katru reizi, kad tiek atkārtots pārvaldnieka vārds. Tas ir tāpēc, ka tālruņa numurs ir atkarīgs tikai no otrās pakāpes projekta numura. Tas tiešām ir atkarīgs vispirms no menedžera, un tas, savukārt, ir atkarīgs no projekta numura, kas veido pārejošu atkarību.

Atribūts Project_Manager nevar būt iespējamā atslēga tabulā Projekti, jo viens un tas pats pārvaldnieks pārvalda vairāk nekā vienu projektu. Risinājums tam ir atribūta noņemšana ar atkārtotiem datiem (tālrunis), izveidojot atsevišķu tabulu.

Atbilstošie atribūti jāsagrupē kopā, izveidojot jaunu tabulu, lai tos saglabātu. Dati tiek ievadīti un tiek pārbaudīts, vai atkārtotās vērtības neietilpst primārajā atslēgā. Primārā atslēga tiek iestatīta katrai tabulai, un, ja nepieciešams, tiek pievienotas svešas atslēgas.

Lai izpildītu trešo parasto formu, problēmas risināšanai tiek izveidota jauna tabula (Pārziņi). Abas tabulas ir saistītas caur Project_Manager lauku:

Atsauces

1. Teradata (2019). Pirmā, otrā un trešā parastā forma. Iegūts no: docs.teradata.com.
2. Pamācību kauss (2019). Trešā normālā forma (3NF). Paņemts no: tutorialcup.com.
3. Datu bāzes izstrāde (2015). Trešā parastā forma (3NF) - datu bāzes normalizēšana. Paņemts no: databasedev.co.uk.
4. Relāciju DB dizains (2019). Ievads trešajā normālajā formā. Paņemts no: relationaldbdesign.com.
5. Manekeni (2019). SQL pirmā, otrā un trešā parastā forma. Paņemts no: dummies.com.