Informatik

Vi vil i det følgende tage udgangspunkt i en konkret case og vil modellere databasen, så de tabeller med data, der indgår i databasen, er relateret til hinanden. Dette kaldes en relationel database.

Database til televirksomhed

En nystartet televirksomhed ønsker at oprette en database i forbindelse med deres opstart. De skal bruge en database til at drive deres virksomhed, som tilbyder telefon- og internetabonnementer samt salg af mobiltelefoner til både privat- og mindre erhvervskunder. 

De skal bruge databasen til at få overblik over deres kunder, varer, abonnementer, ansatte og lignende. De ønsker kort sagt et it-system, der kan opbevare de relevante data, og som kan bruges til at administrere de opgaver, der løbende kommer. 

Entiteter og attributter

For at analysere problemet og for at systemudvikleren (jer) kan blive sat grundigt ind i opgaven med at udvikle en it-løsning, laver televirksomhedens it-chef og systemudvikleren en brainstorm sammen.

1. De starter med at finde alle de mulige entiteter, som database skal give overblik over. Husk at en entitet er en enhed, der ofte er en enhed i fysisk forstand, fx en kunde, et teleabonnement eller en mobiltelefon. 
2. Dernæst skal I finde på alle de attributter, som hver entitet skal have. Som en regel skal attributterne navngives med entitetens navn efterfulgt af attributten, fx medlemsNavn, medlemsAdresse, osv. Husk at en attribut er en egenskab ved en entitet, fx navn og adresse. 

Måske er det nemmere at forstå entiteter, hvis vi ser nærmere på tabellen privatkunde med eksempler på 20 kunder. Attributterne bliver til kolonner i tabellen og rækkerne er eksempler på entiteter, i det her tilfælde konkrete kunder i databasen.

Øvelse i E/R-modellering 2

Som det ses på denne indledende model, er entiteterne tildelt hver sin boks og der kan tilføjes attributter nedenunder. Der er mangler en del entiteter og disses attributter. Disse skal I selv tilføje i jeres egen udgave. Desuden er der ikke tilføjet relationer. Dem kommer vi til senere. 

• Udfyld ovenstående model med flere entiteter og passende attributter. Husk at navngive attributterne korrekt (se ovenstående).
• Sørg for, at der er mindst 6 entiteter. Sørg også for, at der er mindst to attributter til hver entitet.

Relationer

I sidste afsnit fik vi analyseret vores database med formålet at finde de entiteter og attributter, der skal med i televirksomhedens database. Nu skal vi fortsætte vores E/R-model over entiteterne og attributterne og se nærmere på de relationerne, der skal være imellem vores entiteter. Vi fortsætter med modellen fra forrige øvelse. 

Relationerne betyder kort sagt, at der er en forbindelse mellem to entiteter. Det har en en betydning for nøglerne, som vi skal se nærmere på senere. Det er derfor meget vigtigt, at vi for skabt de rigtige relationer mellem de forskellige entiteter. 

Øvelse i E/R-modellering 3

Start med at “tegne” en simpel streg mellem de entiteter, som skal have en relation til hinanden. Tænk over om det giver mening, og om det er nødvendigt, at der er en relation mellem entiteterne. Det er ikke alle entiteter, som har en relation med hinanden.

Kardinalitet

Kardinalitet hjælper med at definere relationen mellem entiteterne i en numerisk kontekst, dvs. hvor mange forekomster af en entitet der kan eller skal relatere til en anden entitet.

Lad os se nærmere på eksemplet fra før, hvor vi havde entiteterne privatKunde og teleAbonnement. Her er kardinaliteten en-til-mange, fordi en kunde kan have mange teleabonnementer (fx til flere familiemedlemmer) men teleabonnementer må kun kunne købes af en kunde, for at sikre at man ikke sælger det samme abonnement til mere end en kunde.

Som I kan se, er der mange forskellige slags kardinaliteter. De vigtigste for os er En og Mange. Og de vigtigste relationer er derfor også en-til-en, en-til-mange, mange-til-en og mange-til-mange. Desuden ser vi også på om, der nødvendigvis skal være en relation. Når vi bruger nul-eller-en og nul-eller-mange skal der ikke nødvendigvis være en relation, men der kan være en relation. Det kan være vigtigt, at skelne mellem skal eller kan. Se mere om dette i eksemplet nedenfor.

I kan se mere om relationer og kardinaliteter i videoen (2:17-5:19) nedenfor.

Eksempel på en udfyldt E/R-model til en webshop

Eksemplet viser en forsimplet webshop, hvor der er en entitet for kunder, varer, ordrer og lager. Ordre forbinder kunde og vare, og lager bruges til at give overblik over placering, så man kan finde varerne, når de sælges.

Der er brugt kardinaliteterne nul-eller-mange-til-en-og-kun-en mellem kunde og ordre, for at vise at en kunde kan have en ordre, men behøvedes ikke. Men en ordre skal have en kunde og må ikke have flere. Se nærmere på de andre kardinaliteter og tænk over hvorfor de er lavet som de er…

Primærnøgler og fremmednøgler

En primærnøgle (Primary Key, markeres med PK i E/R-modellen) er en attribut i en tabel, der har en unik værdi og bruges til at identificere en enhed i tabellen. En primærnøgle kan f.eks. være et kundeId, ordreId, vareId og lagerId, som vi brugte i eksemplet ovenfor. En primærnøgle skal være unik, og må ikke ændres. En primærnøgle er også obligatorisk, dvs. alle enheder i en tabel SKAL have en primærnøgle.

En fremmednøgle (Foreign Key, markeres med FK i E/R-modellen) bruges til at skabe en relation mellem entiteterne. en fremmednøgle er en primærnøgle fra en anden tabel, som bruges i en anden (fremmed) tabel og som derfor henviser tilbage til den anden tabel. I eksemplet ovenfor er der brugt fremmednøgler i entiteten ordre, hvor kundeId og vareId er fremmednøgler, fordi de optræder i en anden tabel end de oprindelige tabeller kunde og vare.

Når du bruger en fremmednøgler i en anden tabel, skaber du en relation mellem de to tabeller. Dvs. hvis der er tegnet en relation i E/R-modellen, skal der også bruges fremmednøgler i én af de 2 tabeller.

Regler som navngivning af entiteter (tabeller) og attributter (kolonner)

Der er regler for, hvordan nøgler skal navngives og skrives. De navngives altid med tabellens navn først efterfulgt af enten Id eller nummer, fx kundeId, teleAbonnementId, internetAbonnementId, etc. 

Nøgler sammenskrives lige som alle andre kolonnenavne enten i camelCase eller snake_case. 

camelCase: kundeId

snake_case: kunde_id eller kunde_Id

Normalisering – regler for databaser

Når man normaliserer en database sikrer man, at data er organiseret logisk og effektivt, så man undgår problemer og har en klar struktur i databasen.

Normalisering hjælper med at:

• Reducere gentagelser af data (så der ikke er unødvendige kopier af de samme oplysninger flere steder i databasen).
• Forbedre dataintegriteten (så ændringer kun skal foretages ét sted, hvilket reducerer fejl).
• Gøre databasen mere effektiv at opdatere og vedligeholde.