De tredje normala formen (databaser) är en relationsdatabasdesignteknik, där de olika tabellerna som utgör den inte bara uppfyller den andra normala formen utan alla deras attribut eller fält beror direkt på den primära nyckeln.
När du utformar en databas är huvudmålet att skapa en korrekt representation av data, förhållandena mellan dem och relevanta data begränsningar..
För att uppnå detta mål kan vissa tekniker för databasdesign användas, bland annat normalisering.
Detta är en process för att organisera data i en databas för att undvika uppsägningar och möjliga avvikelser vid införande, uppdatering eller eliminering av data, 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 någon egenskap hos data eller förhållandet mellan dem.
Artikelindex
Normalisering använder en serie tester, kallade normala former, för att identifiera den optimala grupperingen av dessa attribut och i slutändan fastställa en lämplig uppsättning relationer som stöder ett företags datakrav.
Det vill säga normaliseringstekniken är uppbyggd 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 relationen vara i den normala formen.
En tabell sägs vara i 1FN om alla attribut eller fält inom den endast innehåller unika värden. Det vill säga varje 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 atomära. Alla relationer i en databas finns i 1FN.
Att bara lämna databasen så här stimulerar dock ett antal problem, till exempel redundans och eventuella uppgraderingsfel. Högre normala former utvecklades för att rätta till dessa problem..
Det handlar om att eliminera cirkulära beroenden från en tabell. En relation sägs vara i 2FN om den är i 1FN och också varje icke-nyckelfält eller attribut beror helt på primärnyckeln, eller mer specifikt, det säkerställer 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.
Det handlar om att ta bort övergående beroenden från en tabell. Ta bort de icke-nyckelattribut som inte beror på primärnyckeln utan på ett annat attribut.
Ett transitivt beroende är en typ av funktionellt beroende där värdet på ett icke-nyckelattribut eller -fält bestäms av värdet på ett annat fält som inte heller är nyckel..
Sök 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 är funktionellt beroende av en kombination av andra. Detta ömsesidiga oberoende säkerställer att attribut kan uppdateras individuellt utan risken att påverka ett annat attribut..
För att en databasrelation ska vara i tredje normala form måste den därför följa:
- Alla krav på 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 främmande nyckel. Det vill säga det borde inte finnas några övergående beroenden.
Låt tabellen vara STUDENT, vars primära nyckel ä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 ett direkt förhållande till primärnyckeln STUDENT_ID, eftersom de inte är direkt relaterade till eleven utan är helt beroende av postnumret.
Eftersom studenten är lokaliserad 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 STUDENT-tabellen.
Antag att det finns flera studenter i samma postnummer, med STUDENT-tabellen som har en enorm mängd poster, och det är nödvändigt att ändra namnet på gatan eller staden, då måste denna gata eller stad hittas och uppdateras i hela bordet. STUDENT.
Om det till exempel krävs att du ändrar 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".
Att söka i en stor tabell och uppdatera enstaka eller flera poster tar lång tid och påverkar därmed databasens prestanda.
Istället kan dessa detaljer förvaras i en separat tabell (POSTCARD) som är relaterad till STUDENT-tabellen med attributet POST_CODE.
POST-tabellen kommer att ha relativt färre poster och denna POST-tabell behöver bara uppdateras en gång. Detta kommer automatiskt att återspeglas i STUDENT-tabellen, vilket förenklar databasen och frågorna. Så borden kommer att vara i 3FN:
Låt följande tabell användas med fältet Project_Num som primärnyckel och med upprepade värden i attribut som inte är nycklar.
Telefonvärdet upprepas varje gång en chefs namn upprepas. Detta beror på att telefonnumret bara har andra graders beroende av projektnumret. Det beror verkligen på chefen först, och detta beror i sin tur på projektnumret, vilket gör ett övergående beroende.
Attributet Project_Manager kan inte vara en möjlig nyckel i tabellen Projekt eftersom samma chef hanterar mer än ett projekt. Lösningen för detta är att ta bort attributet med upprepad data (Telefon), skapa en separat tabell.
Motsvarande attribut måste grupperas tillsammans och skapa en ny tabell för att spara dem. Datan matas in och det verifieras att de upprepade värdena inte ingår i primärnyckeln. Primärnyckel ställs in för varje tabell och främmande nycklar läggs till vid behov.
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:
Ingen har kommenterat den här artikeln än.