Vad är den tredje normala formen? (Databaser)

De Tredje normalform (databaser) Det är en relationell databasdesignteknik, där de olika tabellerna som komponerar den inte bara uppfyller den andra normala formen, utan alla deras attribut eller fält beror direkt på huvudnyckeln.

När en databas är utformad är huvudmålet att skapa en exakt representation av uppgifterna, om förhållandena mellan dem och begränsningarna på de uppgifter som är relevanta.

Källa: Pixabay.com

För att uppnå detta mål kan vissa databasdesigntekniker användas, bland vilka är standardiseringen.

Detta är en process för att organisera data i en databas för att undvika uppsägningar och möjliga avvikelser i införandet, uppdateringen eller bortskaffandet av data, vilket genererar för det en enkel och stabil design av den konceptuella modellen.

Börjar med att undersöka det funktionella förhållandet eller beroendet mellan attribut. Dessa beskriver vissa egenskaper hos uppgifterna eller förhållandet mellan dem.

[TOC]

Normala former

Standardisering använder en serie tester, kallade normala former, för att identifiera den optimala grupperingen av dessa attribut och slutligen etablera uppsättningen adekvata relationer som stöder datakraven i ett företag

Det vill säga normaliseringstekniken är konstruerad kring begreppet normalt sätt, som definierar ett system med begränsningar. Om en relation uppfyller begränsningarna på ett visst normalt sätt sägs det att förhållandet är på det normala sättet.

Första normala formen (1FN)

Det sägs att en tabell är i 1FN om alla attribut eller fält inom det endast innehåller unika värden. Det vill säga allt värde för varje attribut måste vara odelbart.

Per definition kommer en relationsdatabas alltid att normaliseras till den första normala formen, eftersom attributvärden alltid är atomiska. Alla relationer i en databas finns i 1FN.

Kan tjäna dig: konstant (programmering): koncept, typer, exempel

Att lämna databasen stimulerar dock helt enkelt en serie problem, till exempel redundans och möjliga uppdateringsavvikelser. De högsta normala formerna utvecklades för att korrigera dessa problem.

Andra normala form (2FN)

Det handlar om att eliminera från en tabell de cirkulära enheterna. Det sägs att ett förhållande är i 2FN om det är i 1FN och även varje fält eller attribut inte beror helt på den primära nyckeln, eller mer specifikt, det säkerställs att tabellen har ett enda syfte.

Ett attribut inte nyckel är något attribut som inte är en del av den primära nyckeln för en relation.

Tredje normalform (3FN)

Det handlar om att eliminera transitiva beroenden från en tabell. Det vill säga eliminera icke -key -attribut som inte beror på den primära nyckeln, men på ett annat attribut.

Ett transitivt beroende är en typ av funktionellt beroende där värdet på ett attribut eller fält inte bestäms av värdet på ett annat fält som inte heller är nyckeln.

Upprepade värden bör sökas i de icke -nyckelattributen för att säkerställa att dessa attribut som inte är nyckeln inte bara beror på den primära nyckeln.

Det sägs att attribut är ömsesidigt oberoende om ingen av dem funktionellt beror på en kombination av andra. Denna ömsesidiga oberoende garanterar att attribut kan uppdateras individuellt, utan fara för att påverka ett annat attribut.

Därför måste det följa:

- Alla 2FN -krav.

Kan tjäna dig: IKT i huset

- Om det finns attribut som inte är relaterade till den primära nyckeln, måste de elimineras och placeras i en separat tabell, relatera båda tabellerna genom en extern nyckel. Det vill säga det bör inte finnas något transitivt beroende.

Exempel på tredje normal form

Exempel 1

Vara studenttabellen, vars primära nyckel är identifiering av studenten (id_estudiant) och består av följande attribut: Studentnamn, gata, stad och_postalkod, uppfyller villkoren för att vara 2FN.

I det här fallet har Street och City inte en direkt relation med den primära identitetsnyckeln, eftersom de inte är direkt relaterade till studenten, men de beror helt på postnummer.

Eftersom studenten är belägen av webbplatsen som bestäms av Code_Postal, är Street och City relaterade till detta attribut. På grund av denna andra grad av beroende är det inte nödvändigt att lagra dessa attribut i studenttabellen.

Skapa nytt bord

Anta att det finns flera studenter i samma postkod, med studentbordet med en enorm mängd poster, och det är nödvändigt att ändra namnet på gatan eller staden, då bör denna gata eller stad sökas och uppdateras genom hela bordstudent.

Om det till exempel är nödvändigt att ändra "El Limón" -gatan för "El Limón II", måste den leta efter "El Limón" i hela studentbordet och sedan uppdatera den till "El Limón II".

Hitta i ett enormt tabell och uppdatera de unika eller flera posterna kommer att kräva mycket tid och kommer därför att påverka databasprestanda.

Istället kan dessa detaljer finnas i en separat (vykort) tabell som är relaterad till studenttabellen med hjälp av code_postal -attributet.

Posttabellen kommer att ha en relativt mindre mängd poster och måste bara uppdateras när detta posttabell. Detta återspeglas automatiskt i studenttabellen, vilket förenklar databaserna och konsultationerna. Således kommer borden att vara i 3FN:

Det kan tjäna dig: Metabusters: Egenskaper, typer och exempel

Exempel 2

Vara följande tabell med num_project -fältet som huvudnyckel och med upprepade värden i attribut som inte är nyckel.

Telefonvärdet upprepas varje gång namnet på en chef upprepas. Detta beror på att telefonnumret bara har ett andra graders beroende med projektnumret. Det beror verkligen på chefen, och detta beror i sin tur på projektnumret, vilket gör ett transitivt beroende.

Attributet Manager_Project kan inte vara en möjlig nyckel i tabellprojekten eftersom samma chef hanterar mer än ett projekt. Lösningen för detta är att eliminera attributet med upprepade data (telefon), skapa en separat tabell.

Motsvarande attribut måste grupperas, vilket skapar en ny tabell för att rädda dem. Uppgifterna anges och det verifieras att värdena som upprepas inte är en del av den primära nyckeln. Den primära nyckeln för varje tabell är etablerad och vid behov läggs externa nycklar.

För att möta den tredje normala formen skapas en ny tabell (chefer) för att lösa problemet. Båda tabellerna är relaterade till fältet Manager_project:

Referenser

1. Teradata (2019). Först, andra och tredje normala former. Taget från: docs.Teradata.com.
2. Cup Tutorial (2019). Normal tredje form (3NF). Taget från: tutorialcup.com.
3. Databas Dev (2015). Normal tredje form (3NF) - normalisera din databas. Taget från: DatabaseVev.co.Storbritannien.
4. Relational DB Design (2019). Introduktion till tredje normalform. Taget från: relationalDBDesign.com.
5. Dummies (2019). SQL första, andra och tredje normala former. Taget från: dummies.com.