VAD ÄR DEN TREDJE NORMALA FORMEN? (DATABASER) - TEKNOLOGI - 2025

Den tredje normala formen (databaser) är en relationell databasdesignteknik, där de olika tabellerna som komponerar den inte bara överensstämmer med den andra normala formen, utan alla dess attribut eller fält beror direkt på den primära nyckeln.

När man utformar en databas är huvudmålet att skapa en exakt representation av data, förhållandena mellan dem och begränsningarna för de data som är relevanta.

Källa: pixabay.com

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

Detta är en process för att organisera data i en databas för att undvika uppsägningar och möjliga avvikelser i infogning, uppdatering eller eliminering av uppgifterna, vilket genererar en enkel och stabil design av den konceptuella modellen.

Det 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.

Normala former

Normalisering använder en serie tester, så kallade normala former, för att identifiera den optimala grupperingen av dessa attribut och i slutändan upprätta en lämplig uppsättning relationer som stöder ett företags datakrav.

Det vill säga normaliseringstekniken är byggd kring begreppet normal form, som definierar ett system med begränsningar. Om en relation uppfyller begränsningarna för en viss normal form, sägs förhållandet vara i den normala formen.

Första normala formen (1FN)

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

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

Att bara lämna databasen som denna stimulerar emellertid ett antal problem, såsom redundans och möjliga uppgraderingsfel. Högre normala former utvecklades för att korrigera dessa problem.

Andra normala formen (2FN)

Det handlar om att ta bort cirkulära beroenden från en tabell. En relation sägs vara i 2FN om den är i 1FN och dessutom beror varje icke-nyckelfält eller attribut helt och hållet på den primära nyckeln, eller närmare bestämt säkerställer det att tabellen har ett enda syfte.

Ett icke-nyckelattribut är alla attribut som inte ingår i den primära nyckeln för en relation.

Tredje normalform (3FN)

Det handlar om att eliminera transitive beroenden från en tabell. Det vill säga ta bort de icke-nyckelattributen 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 för ett icke-nyckelfält eller attribut bestäms av värdet på ett annat fält som inte heller är nyckeln.

Du bör leta efter upprepade värden i icke-nyckelattribut för att säkerställa att dessa icke-nyckelattribut inte beror på något annat än den primära nyckeln.

Attribut sägs vara ömsesidigt oberoende om ingen av dem funktionellt beror på en kombination av andra. Denna ömsesidiga oberoende säkerställer att attribut kan uppdateras individuellt utan risken att påverka ett annat attribut.

För att ett förhållande i en databas ska vara i tredje normala form måste det därför följa:

- Alla krav i 2FN.

- Om det finns attribut som inte är relaterade till den primära nyckeln, måste de tas bort och placeras i en separat tabell, som relaterar båda tabellerna med hjälp av en utländsk nyckel. Det vill säga att det inte bör finnas några övergående beroende.

Exempel på tredje normalform

Exempel 1

Låt tabellen vara STUDENT, vars huvudnyckel är studentens identifiering (STUDENT_ID) och består av följande attribut: STUDENT_NAME, STREET, CITY och POST_CODE, som uppfyller villkoren för att vara 2FN.

I det här fallet har STREET och CITY inte en direkt relation med den primära nyckeln STUDENT_ID, eftersom de inte är direkt relaterade till eleven, men är helt beroende av postnumret.

Eftersom studenten är belägen på den plats som bestäms av CODE_POSTAL, är STREET och CITY relaterade till detta attribut. På grund av denna andra beroendegrad är det inte nödvändigt att lagra dessa attribut i STUDENT-tabellen.

Skapa en ny tabell

Anta att det finns flera studenter i samma postnummer, där STUDENT-tabellen har en enorm mängd poster, och det krävs att du ändrar namnet på gatan eller staden, då måste denna gata eller stad hittas och uppdateras i hela tabellen STUDERANDE.

Om du till exempel behöver ändra gatan "El Limón" till "El Limón II" måste du söka efter "El Limón" i hela STUDENT-tabellen och sedan uppdatera den till "El Limón II".

Sökning i en enorm tabell och uppdatering av enskilda eller flera poster kommer att ta lång tid och påverkar därför databasens prestanda.

I stället kan dessa detaljer förvaras i en separat tabell (POSTCARD) som är relaterad till STUDENT-tabellen med POST_CODE-attributet.

POST-tabellen kommer att ha jämförelsevis färre poster och denna POST-tabell behöver bara uppdateras en gång. Detta återspeglas automatiskt i STUDENT-tabellen, vilket förenklar databasen och frågorna. Så tabellerna kommer att vara i 3FN:

Exempel 2

Låt följande tabell användas med Project_Num-fältet som primärnyckel och med upprepade värden i attribut som inte är nycklar.

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

Attributet Project_Manager kan inte vara en möjlig nyckel i projekttabellen eftersom samma chef hanterar mer än ett projekt. Lösningen för detta är att ta bort attributet med upprepade data (Telefon) och skapa en separat tabell.

Motsvarande attribut måste grupperas tillsammans, skapa en ny tabell för att spara dem. Uppgifterna matas in och det verifieras att de upprepade värdena inte ingår i den primära nyckeln. Den primära nyckeln ställs in för varje tabell och vid behov läggs utländska nycklar till.

För att följa den tredje normala formen skapas en ny tabell (Managers) för att lösa problemet. Båda tabellerna är relaterade genom fältet Project_Manager:

referenser

1. Teradata (2019). Första, andra och tredje normala formulär. Hämtad från: docs.teradata.com.
2. Tutorial Cup (2019). Tredje normalform (3NF). Hämtad från: tutorialcup.com.
3. Database Dev (2015). Tredje normalformulär (3NF) - Normalisering av din databas. Hämtad från: databasedev.co.uk.
4. Relational DB Design (2019). Introduktion till tredje normalform. Hämtad från: relationaldbdesign.com.
5. Dummies (2019). SQL första, andra och tredje normala formulär. Hämtad från: dummies.com.