Lær ER-diagrammet (Entity Relationship) at kende, dets dele, og hvad der ofte går galt, når du opretter det.
Har du nogensinde lavet en relationel databasemodel? Eller forsøger du måske at oprette din første? Du ved (eller du vil snart finde ud af), at det nogle gange kan være ret svært at oversætte problemer fra den virkelige verden til databaselogik.
Et af de værktøjer, der kan hjælpe dig, er ER-diagrammet. Almindelig viden om databasedesign hævder, at jo bedre dit ER-diagram er, jo lettere vil det være at bygge databasemodellen. Denne vigtige genstand sætter tonen for alle fremtidige frustrationer eller succeser. Med et godt ER-diagram er det ret ligetil at oprette en relationel databasemodel. Selvfølgelig kan der begås fejl i enhver fase af databasemodelleringen. Men at have et godt ER-diagram kan hjælpe dig med at undgå nogle af disse fejl.
Så lad os se, hvad ER-diagrammet er, og hvordan vi kan undgå dets almindelige fejl.
Hvad er et ER-diagram?
"ER Diagram", eller ERD, er en forkortelse for Entity Relationship Diagram. Den kortlægger det problem, der skal modelleres, men på en struktureret måde, der viser relationerne mellem enheder.
Et ER-diagrams byggesten
ER-diagrammer består af følgende elementer:
- Enhed
- Relationer
- Enheds- eller relationsattributter
Det første element i ER-diagrammet er entiteten . Enheden er et objekt eller en forekomst, som vi ønsker at gemme information om. Dybest set er det alt, som vi kan indsamle data om. For eksempel kan vi gemme data om medarbejdere, studerende, lærere, indkøbere, produkter, afdelinger, betalinger, lokationer osv.
Når vi har enheder, er det nødvendigt at skabe relationer . En relation viser, hvordan en enhed er forbundet med og associeret med en eller flere andre entiteter.
Det sidste element i ER-diagrammet er en attribut entitet eller relation . En attribut er en beskrivelse af en ejendom, der tilhører en enhed eller et forhold. Attributter har værdier. Nogle attributter for entiteterne nævnt ovenfor kunne være:
- Medarbejder, elev, lærer, køber – ID, navn, efternavn, fødselsdato, adresse osv.
- Produkt – ID, kategori, beskrivelse, farve, serienummer osv.
- Afdeling – ID, afdelingsnavn, afdelingsleder, antal medarbejdere osv.
- Betalinger – ID, dato og klokkeslæt, beløb.
- Placering – By, postnummer, region, land, kontinent.
Typer af forhold
Før vi kommer ind på de sædvanlige fejl, der findes i ER-diagrammer, er det vigtigt at forstå de mulige relationstyper. De fleste ERD-fejl er grundlæggende fejldefinerede forhold mellem enheder.
Der er tre typer relationer mellem enheder:
- En-til-en (1:1)
- En-til-mange (1:N)
- Mange-til-mange (M:N)
En-til-en-forhold (1:1)
Den første relationstype er en-til-en eller 1:1 . I dette forhold kan en enkelt forekomst af en enhed kun forbindes med en enkelt forekomst af en anden entitet (og omvendt, selvfølgelig).
Lad os sige, at vi har enheden elev med attributterne navn og efternavn . Vi har også enheden id med den eneste attribut id . 1:1 forholdet ville betyde, at én elev kun kan have ét ID-nummer. Det betyder også, at ét ID-nummer kun kan tilhøre én elev.
Dette forhold ses meget sjældent i databaser. Hvis kun ét ID kan forbindes med kun én elev, er det ikke nødvendigt at adskille dem i to forskellige enheder.
Her er et eksempel på dette forhold:
En-til-mange (1:N)-relationer
Den mest almindelige type databaserelation er en-til-mange eller 1:N . En En-til-mange-relation betyder, at hver enkelt forekomst af en enhed kan forbindes med flere forekomster af en anden enhed. Det betyder også, at hver forekomst af den anden enhed kun kan associeres med én forekomst af den første enhed.
For eksempel er der en enhed køber med attributterne id , navn og efternavn . Vi ønsker at etablere et forhold til enheden betaling der har attributterne id , dato og værdi . Dette er et 1:N-forhold, fordi én køber kan foretage en eller flere betalinger. En betaling kan dog ikke foretages af flere købere; det kan kun laves af én køber.
Her er eksemplet:
Dette forhold kan også ses omvendt. I denne situation kaldes det mange-til-en eller N:1 . Selvfølgelig er dette ikke en ny type forhold. Det er det samme som 1:N, men det ses fra den modsatte retning.
Antag som et eksempel, at vi har enheden medarbejder med attributterne id , navn og efternavn . Vi ønsker at etablere medarbejder s forhold til enhedens afdeling der har attributterne id og navn . Forholdet mellem disse to enheder er N:1. Det betyder, at hver medarbejder kun kan arbejde i én afdeling, men flere medarbejdere kan arbejde i samme afdeling.
Mange-til-mange (M:N)-forhold
A Mange-til-mange eller M:N relation betyder, at hver forekomst af den første enhed kan associeres med mere end én forekomst af den anden enhed. Det betyder også, at hver forekomst af den anden enhed kan associeres med flere forekomster af den første enhed.
Lad os se, hvordan det fungerer mellem enhederne elev og foredrag . Lad os sige, at elev har attributterne id , navn og efternavn . Enhedens foredrag har attributterne id og navn . Et mange-til-mange forhold kan fortolkes på følgende måde:En studerende kan deltage i en eller flere forelæsninger, mens en forelæsning kan overværes af en eller flere studerende.
Her er diagrammet for dette eksempel:
I databasemodellering opdeles sådanne relationer normalt i to eller flere 1:N eller N:1 relationer ved at introducere nye entiteter.
Typiske fejl ved oprettelse af et ER-diagram
Mange ER-diagramfejl passer ind i en af disse fire kategorier:
- Ukorrekte relationer mellem enheder
- Brug af en enhedsforekomst i stedet for en enhed
- Forveksling af en attribut med en enhed
- Komplekse attributter
Lad os se på hver enkelt individuelt.
Ukorrekte relationer mellem enheder
De mest almindelige fejl opstår, når man definerer forholdet mellem enheder . Der er normalt ingen fejl i et 1:1 forhold. Det er dog meget let at forveksle et 1:N-forhold med et M:N-forhold. Dette skyldes normalt ikke at forstå kravene stillet af slutbrugeren. Det er vigtigt at have meget klart definerede krav og en dyb forståelse af, hvorfor databasen er nødvendig, og hvordan den vil blive brugt. Hvis vi opretter et ER-diagram med utilstrækkelige data og ufuldstændig forståelse, vil det højst sandsynligt resultere i, at relationer mellem enheder bliver forkert defineret.
Lad os se på et eksempel. Hvis du opretter en database til en bank, vil du højst sandsynligt oprette et ER-diagram med enheden klient med attributterne id , navn og efternavn . Du vil også have en enhed kaldet konto med attributterne id og skriv . Hvis du mangler erfaring i bankbranchen, vil du sikkert tro, at der altid er et 1:N forhold mellem klienten og konto enheder, som vist nedenfor.
En kunde kan have flere konti i én bank. En konto kan dog kun ejes af én kunde. Er dette virkelig sandt? Måske er det, måske er det ikke. Rigtig mange banker tilbyder fælles konti, som kan bruges af flere kunder. Opretter du et ER-diagram for en bank, der tilbyder en sådan service? Hvis banken ikke tilbyder fælles konti, så har du ret:forholdet mellem klient og konto er 1:N. Men hvis banken tilbyder fælles konti, så er forholdet M:N.
Brug af en enhedsforekomst i stedet for en enhed
En anden almindelig fejl er at bruge en enhedsforekomst i stedet for en enhed. En enhedsforekomst er en enkelt forekomst af en bestemt enhed – dvs. en enhed, der faktisk kunne være en egenskab af en større kategori.
Lad os sige, at vi arbejder i en virksomhed, der tildeler mobiltelefoner og bærbare computere til bestemte medarbejdere. Så i vores database ville vi have en enhed kaldet laptop med attributterne id og model og en enhed kaldet medarbejder med attributterne id , navn og efternavn , ret?
Der er et problem her:en bærbar computer er faktisk ikke en enhed - der er også mobiltelefoner at tage højde for. Løsningen er at erstatte entiteten laptop med en mere generel enhed, såsom udstyr . Denne enhed kunne have attributterne ID , skriv , og model , som vist nedenfor. typen kunne bestå af værdier såsom telefon , PC , tablet , og bærbar computer . På denne måde er det ikke nødvendigt at oprette en separat enhed for hver type udstyr.
Du kan finde eksemplet her:
Forveksling af en attribut med en enhed
Den næste almindelige fejl er at forveksle en attribut med en enhed. Lad os sige, at vi har besluttet at oprette en enhed kaldet medarbejder der vil bestå af attributterne id , navn , efternavn , fødselsdato , id_department , navn_afdeling , og head_department . Denne enhed vil få os i problemer, når vi opretter en databasemodel, fordi den består af for mange attributter, der ikke entydigt definerer denne særlige enhed .
Husk, vi definerede enheder som alt, hvad vi kan indsamle data om. Med det i tankerne kan vi se, at den nuværende medarbejder enhed kan opdeles i to enheder:medarbejder og afdeling , som vist nedenfor.
Komplekse attributter
Den sidste almindelige fejl, vi vil tale om, er at inkludere en kompleks egenskab i en enhed. Med andre ord har vi en egenskab, der faktisk burde være dens egen enhed .
Lad os sige, at vi har en enhed kaldet studerende der er defineret af følgende attributter:id , navn , efternavn , fødselsdato , adresse , og eksamen_bestået . Her, eksamen_bestået er en kompleks egenskab, der består af mere end én information, dvs. eksamens-id og -dato og den studerendes score. At lade det være sådan ville være en fejl. I stedet bør vi oprette en ny entitet ud af denne komplekse egenskab . Den nye enhed kunne få navnet eksamener og består af følgende attributter:id , dato , students_id , og score .
Du kan finde eksemplet her:
Fik du nogle nyttige ER-diagramtips?
Disse fire typer fejl er de mest almindelige i processen til oprettelse af ER-diagrammer. Selvfølgelig er der ingen komplet liste over typiske fejl eller typer fejl. I det virkelige liv vil der sandsynligvis ske mange slags fejl. Mangel på planlægning, utilstrækkelig teknisk support og en forhastet databasedesignproces bidrager alle til deres egne problemer. Hvis du nogensinde har oprettet databaser eller deltaget i det fra forretningssiden, har du sikkert oplevet nogle af dem! Alle disse omstændigheder fører til forskellige fejl, hvoraf nogle er helt unikke.
Har du dit eget eksempel på et knap så godt ER-diagram? Eller måske er der nogle andre fejl, som du ofte finder? Fortæl mig det i kommentarfeltet.