Entity-Relationship Data Model , også kaldet ER , er en af de forskellige datamodeller, du kan bruge til at ræsonnere om dine data.
Især er det en konceptuel datamodel , da det ikke er knyttet til nogen bestemt implementering. Det er en opgave, der er overladt til den logiske datamodel.
ER-datamodellen er så generel, så højt niveau, at det kan implementeres af en række helt forskellige slags databaser.
Det er fantastisk, fordi du ikke tænker på implementeringsdetaljerne, men i stedet tænker du kun på dine data, og hvordan de er organiseret . Og mens du gør det, er du tvunget til at analysere problemet på måder, som du ikke tænkte på før.
Jeg synes, ER-diagrammer er gode til at hjælpe dig med at analysere et scenarie, hvor data er involveret.
ER-modellen giver dig værktøjerne til ved hjælp af en grafisk notation at repræsentere alle de data, du har brug for at modellere, relationerne mellem de forskellige slags data og den information, der er knyttet til dem.
Der er 2 elementer, der sammensætter en ER-model:
- enhederne
- relationerne
Entiteter er typer af data, såsom elementer eller personer, der har fælles egenskaber.
Relationer er relationerne mellem enheder.
Lad mig give dig et eksempel, lad os tale om bøger og deres forfattere. Vi har 2 enheder :
- bog
- forfatter
En bestemt bog er en forekomst af bogenheden.
Da vi har 2 entiteter, har vi 2 relationer mellem dem. Den ene er forholdet mellem en enkelt bog og forfatterens enhed. Den ene er forholdet mellem en enkelt forfatter og bogens enhed. Hvis vi tænker over det, har vi:
- en bog har en forfatter
- en forfatter kan skrive mange forskellige bøger
Den visuelle notation for enheder
Med dette simple eksempel kan vi begynde at introducere den visuelle notation, der vil hjælpe os med at skabe ER-datamodellen for vores scenarie.
Bemærk:Der er mange forskellige måder at tegne ER-diagrammer på. Jeg vil bruge den, der efter min mening , er mere visuel og giver mere mening.
Enheder er repræsenteret som rektangler med noget tekst i dem for at identificere dem:
Den visuelle notation for relationer
Relationen mellem entiteter er repræsenteret i sin mest grundlæggende form ved at bruge en linje, der forbinder to relationer, og en diamant med noget tekst i for at identificere typen af relation:
Bemærk, at jeg ikke oprettede 2 relationer "bog har forfatter" og "forfatter skrev bog". Jeg lavede en enkelt relation "forfattet" mellem en bog og en forfatter.
Kardinaliteter
Når vi har en relation, skal vi nu angive de involverede tal. I øjeblikket har vi mange spørgsmål:
- Hvor mange forfattere kan en bog have?
- Kan en forfatter skrive flere bøger?
- Skal en forfatter skrive mindst én bog for at blive kaldt forfatter?
- Kan en bog skrives af flere forfattere?
- Kan en bog eksistere uden mindst en forfatter?
Alle de spørgsmål er gode at stille, og i dette tilfælde synes jeg, at svarene er ret indlysende. Og når svaret ikke er indlysende, kan du tænke over problemet og tilføje dine egne begrænsninger.
Der er forskellige måder at visuelt angive kardinaliteter på et diagram. Nogle foretrækker at ændre formen på linjen, når den linker til en enhed.
Jeg foretrækker tal, som gør tingene klarere:
Tallene ovenfor betyder dette:En bog kan forfattes af 1 eller flere forfattere. n betyder et hvilket som helst antal elementer.
Og en forfatter kan have skrevet fra 0 bøger (måske skriver den en nu) til et uendeligt antal bøger.
Det første kaldes et nul-til-mange forhold . Det andet er et en-til-mange forhold .
Vi kan også have:
- en-til-en-forhold
- mange-til-mange-forhold
- nul-til-én-relationer
Attributter
Hver enhed kan have en eller flere attributter.
Lad os sige, at vi vil bruge ovenstående forhold i en boghandel. Hver forfatter har et navn, en biografi, en hjemmeside-URL.
Hver bog har en titel, et forlag, et udgivelsesår, et ISBN. Udgiveren kunne også være en enhed, hvis vi vil. Men vi kan også definere det som en egenskab ved en bog.
Sådan kan vi repræsentere ovenstående information:
Identifier-attributter
Enheder skal identificeres med en unik nøgle. Bogenheden kan identificeres entydigt af ISBN-attributten. Hver bog har et enkelt ISBN (i betragtning af, at vi ikke repræsenterer en enkelt kopi af en bog, men en bogtitel).
Vi identificerer de primære nøgleattributter ved at underlægge dem:
Forfatteren har på den anden side ingen entydig identifikator i øjeblikket. To forfattere kan have samme navn.
Vi skal derfor tilføje en unik nøgleattribut. For eksempel et id attribut:
Identifikatorattributter kan strække sig over flere attributter.
For eksempel identificerer pas-id'et og forfatterlandet personen entydigt og kan erstatte id attribut vi tilføjede:
Hvilken skal man vælge? Det er et spørgsmål om, hvad der giver mere mening i din ansøgning. Hvis vi modellerer en boghandel, kan vi ikke forvente at have land- og pas-id for alle bogforfattere. Vi bruger derfor et tilfældigt id vi vælger og knytter til hver forfatter.
Relationsattributter
Attributter er ikke unikke for enheder. Relationer kan også have attributter.
Overvej, at vi skal modellere et bibliotek. Ud over bog- og forfatterentiteterne introducerer vi nu læserentiteten , en person, der låner bogen for at læse den. Vi tager dens navn og id-kortnummer, når de låner det:
Men vi savner stadig information. Vi er nødt til at vide, hvornår personen har lånt bogen, og datoen for den tilbagelevering, så vi kan gemme oplysningerne om hele historien om en bestemt bog i vores bibliotek. Disse oplysninger tilhører hverken bog- eller læser-enheder; det hører til relationen:
Svage enheder
Vi talte om primære nøgler ovenfor, og hvordan hjælpen unikt identificerer en enhed.
Nogle entiteter er afhængige af andre entiteter for deres eksistens og kaldes svage entiteter .
Antag, at vi skal modellere ordrer til en onlinebutik.
For hver ordre gemmer vi ordre-id'et, som starter fra 1 og stiger over tid, datoen og klokkeslættet, den blev afgivet, og oplysningerne om kunden, så vi ved, hvem vi skal fakturere, og hvor vi skal sende den.
Så skal vi også vide, hvad de har bestilt. Vi opretter en svag enhed "bestilt vare", som repræsenterer hver vare i indkøbskurven på tidspunktet for kassen.
Denne enhed gemmer vareprisen i kassen (så når vi ændrer prisen på produkterne på udsalg, vil det ikke påvirke de ordrer, der allerede er afgivet), mængden af varer, der blev bestilt, og de valgte muligheder. Sig, at vi sælger t-shirts, derfor skal vi opbevare farven og størrelsen på den bestilte t-shirt.
Det er en svag enhed, fordi en bestilt vare enhed ikke kan eksistere uden en ordre enhed.
Rekursive relationer
En enhed kan have et rekursivt forhold til sig selv. Antag, at vi har en person-entitet. Vi kan modellere forældre-barn-forholdet på denne måde:
En person kan få fra 0 til n børn, et børn har 2 forældre (det enkleste scenarie taget i betragtning).
ISA-relationer
ISA står for IS-A, og det er en måde at modellere generaliseringer i ER-modellen på.
Vi bruger det til at gruppere lignende enheder under en fælles paraply. For eksempel kan en forfatter og en læser, i tilfælde af bøger og bibliotekseksempler, generaliseres ved hjælp af en person-entitet.
De har begge et navn, så vi trækker navnet op til personens entitet, og vi håndterer bare det særlige ved at være forfatter eller læser i den tilsvarende enhed:
Ikke-binære relationer
Ikke alle forhold er strengt binære. Lad os tage et lektionsscenarie.
En lektion finder sted i et lokale på skolen i dag kl. 10:00, hvor en lærer taler med en klasse om fysik.
Så en lektion gives på et bestemt tidspunkt af dagen, den involverer et emne, en lærer, en klasse og et lokale.
Vi kan modellere det på denne måde:
