Hur man mappar E/R-diagram till Relationsmodellen
Förord
Du har, av någon anledning, behov av att skapa en databas. Men hur designar man den? Hur gör man för att slippa redundans (dvs onödig information) i databasen, och finns det några knep så man slipper tänka så mycket när man designar databasen? I denna artikel kommer du få se hur man genom en smart algoritm kan få fram en relationsmodell utan redundans utifrån en E/R-modell. Sen är det bara att föra in det på datorn!Jag antar att du vet vad du ska ha databasen till, och att du har en uppfattning om vilka delar som ska vara med. Till att börja med behöver du göra ett E/R-diagram. Jag går inte närmar in på vad det innebär i denna artikel, då huvudsyftet här är användningen av den algoritm som skall göra om E/R-diagrammet till en normaliserad relationsmodell. Här finns dock en länk till en sida som beskriver hur man ritar E/R-diagram:
http://www.databasteknik.se/webbkursen/er/index.html
När du nu fått ditt E/R-diagram är det dags att använda algoritmen som skall ta fram den logiska databasdesignen som baseras på den konceptuella designen. Jag tror inte att denna algoritm har något namn, men om ni som läser detta känner till något namn på den får ni gärna höra av er. I vilket fall som hellst ser den ut såhär:
Varje stark entitet blir en basrelation där primärnyckeln blir nyckelattributet/nyckelattributen i entiteten.
Har du inte med några svaga entiteter i ditt E/R-diagram är det bara att hoppa över det här steget. Själv har jag aldrig använt svaga entiteter, och har därför alltid hoppat över denna del. Varje svag entitet blir en basrelation som får alla enkla attribut som den svaga entiteten har, och primärnyckeln blir kombinationen av primärnyckeln hos ägandeentiteten och (om det finns) den partiella nyckeln hos den svaga entiteten. Om det råkar vara så att ägandeentiteten också är en svag entitet, så skall denna mappas först för att få ut dess primärnyckel. Se till att ha med regler för uppdatering och borttagning senare när du implementerar modellen, eftersom en svag entitet inte kan existera utan en relaterad ägandeentitet (med andra ord, ha med ON DELETE CASCADE och ON UPDATE CASCADE).
Det finns två sätt att mappa 1 till 1 relationer, varav det första är det jag använt mest:
alt1: Välj en av basrelationerna och låt primärnyckeln i den andra relationen bli en främmandenyckel i denna. Flytta även över (om det skulle finnas) alla enkla attribut i 1 till 1 relationen (alltså attribut som på E/R-diagrammet är kopplade till diamanten/relationen) till denna basrelation.
alt2: Sätt ihop de två entiteterna till en och samma entitet och mappa därefter.
Lägg till som främmandenyckel i basrelationen på N-sidan, primärnyckeln hos den andra basrelationen.
Gör varje N till M relation till en basrelation. Sätt primärnyckeln i varje sådan basrelation till kombinationen av primärnycklarna i de basrelationer denna relation kopplar samman, alternativt kan primärnyckeln vara ett nytt attribut, men primärnycklarna från de sammankopplade basrelationerna måste finnas med som främmandenycklar.
Alla egenskaper hos entiteter blir attribut i den relation de tillhör. Skillnaden för mångvärdes-/flervärdesattribut är att man för varje flervärdesattribut skapar en ny basrelation som innehåller ett attribut som är flervärdesattributet och en främmandenyckel som är primärnyckeln hos den relation som hade flervärdesattributet. Primärnyckeln i denna basrelation blir kombinationen av dessa två attribut.
Om du följt dessa regler borde du nu ha en normaliserad databas utan redundans. Grattis!
http://www.databasteknik.se/webbkursen/er/index.html
När du nu fått ditt E/R-diagram är det dags att använda algoritmen som skall ta fram den logiska databasdesignen som baseras på den konceptuella designen. Jag tror inte att denna algoritm har något namn, men om ni som läser detta känner till något namn på den får ni gärna höra av er. I vilket fall som hellst ser den ut såhär:
Steg 1 - Mappning av starka entiteter
Varje stark entitet blir en basrelation där primärnyckeln blir nyckelattributet/nyckelattributen i entiteten.
Steg 2 - Mappning av svaga entiteter
Har du inte med några svaga entiteter i ditt E/R-diagram är det bara att hoppa över det här steget. Själv har jag aldrig använt svaga entiteter, och har därför alltid hoppat över denna del. Varje svag entitet blir en basrelation som får alla enkla attribut som den svaga entiteten har, och primärnyckeln blir kombinationen av primärnyckeln hos ägandeentiteten och (om det finns) den partiella nyckeln hos den svaga entiteten. Om det råkar vara så att ägandeentiteten också är en svag entitet, så skall denna mappas först för att få ut dess primärnyckel. Se till att ha med regler för uppdatering och borttagning senare när du implementerar modellen, eftersom en svag entitet inte kan existera utan en relaterad ägandeentitet (med andra ord, ha med ON DELETE CASCADE och ON UPDATE CASCADE).
Steg 3 - Mappning av 1 till 1 relationer
Det finns två sätt att mappa 1 till 1 relationer, varav det första är det jag använt mest:alt1: Välj en av basrelationerna och låt primärnyckeln i den andra relationen bli en främmandenyckel i denna. Flytta även över (om det skulle finnas) alla enkla attribut i 1 till 1 relationen (alltså attribut som på E/R-diagrammet är kopplade till diamanten/relationen) till denna basrelation.
alt2: Sätt ihop de två entiteterna till en och samma entitet och mappa därefter.
Steg 4 - Mappning av 1 till N relationer
Lägg till som främmandenyckel i basrelationen på N-sidan, primärnyckeln hos den andra basrelationen.
Steg 5 - Mappning av N till M relationer
Gör varje N till M relation till en basrelation. Sätt primärnyckeln i varje sådan basrelation till kombinationen av primärnycklarna i de basrelationer denna relation kopplar samman, alternativt kan primärnyckeln vara ett nytt attribut, men primärnycklarna från de sammankopplade basrelationerna måste finnas med som främmandenycklar.
Steg 6 - Mappning av attribut
Alla egenskaper hos entiteter blir attribut i den relation de tillhör. Skillnaden för mångvärdes-/flervärdesattribut är att man för varje flervärdesattribut skapar en ny basrelation som innehåller ett attribut som är flervärdesattributet och en främmandenyckel som är primärnyckeln hos den relation som hade flervärdesattributet. Primärnyckeln i denna basrelation blir kombinationen av dessa två attribut.Om du följt dessa regler borde du nu ha en normaliserad databas utan redundans. Grattis!
0 Kommentarer