Datamodellen för entitetsrelationer , även kallad ER , är en av de olika datamodellerna du kan använda för att resonera kring din data.
I synnerhet är det en konceptuell datamodell , eftersom det inte är kopplat till någon särskild implementering. Det är en uppgift som lämnas åt den logiska datamodellen.
ER-datamodellen är så generell, så hög nivå, att den kan implementeras av en mängd helt olika typer av databaser.
Det är bra eftersom du inte tänker på implementeringsdetaljerna utan istället tänker du bara på din data och hur den är organiserad . Och samtidigt som du gör det tvingas du analysera problemet på sätt som du inte tänkt på tidigare.
Jag tycker att ER-diagram är bra för att hjälpa dig analysera ett scenario där data är inblandade.
ER-modellen ger dig verktygen för att med hjälp av en grafisk notation representera all data du behöver för att modellera, relationerna mellan de olika typerna av data och informationen som är associerad med den.
Det finns två objekt som utgör en ER-modell:
- entiteterna
- relationerna
Entiteter är typer av data, som objekt eller personer, som har gemensamma egenskaper.
Relationer är relationerna mellan enheter.
Låt mig ge dig ett exempel, låt oss prata om böcker och deras författare. Vi har 2 enheter :
- bok
- författare
En viss bok är en instans av bokentiteten.
Eftersom vi har två enheter har vi 2 relationer mellan dem. Den ena är relationen mellan en enda bok och författarens enhet. Den ena är relationen mellan en enda författare och bokens enhet. Om vi tänker efter så har vi:
- en bok har en författare
- en författare kan skriva många olika böcker
Den visuella notationen för enheter
Med detta enkla exempel kan vi börja introducera den visuella notationen som hjälper oss att skapa ER-datamodellen för vårt scenario.
Obs:Det finns många olika sätt att rita ER-diagram. Jag kommer att använda den som, enligt min åsikt , är mer visuellt och vettigare.
Entiteter representeras som rektanglar, med lite text i dem för att identifiera dem:
Den visuella notationen för relationer
Relationen mellan entiteter representeras, i sin mest grundläggande form, med hjälp av en linje som förbinder två relationer, och en romb med lite text i för att identifiera typen av relation:
Observera att jag inte skapade 2 relationer "bok har författare" och "författare skrev bok". Jag skapade en enda relation "författad" mellan en bok och en författare.
Kardinaliteter
När vi väl har en relation måste vi nu ange vilka siffror som är involverade. Just nu har vi många frågor:
- Hur många författare kan en bok ha?
- Kan en författare skriva flera böcker?
- Behöver en författare skriva minst en bok för att kallas författare?
- Kan en bok skrivas av flera författare?
- Kan en bok existera utan åtminstone en författare?
Alla dessa är bra frågor att ställa, och i det här fallet tror jag att svaren är ganska uppenbara. Och när svaret inte är uppenbart kan du fundera över problemet och lägga till dina egna begränsningar.
Det finns olika sätt att visuellt indikera kardinaliteter på ett diagram. Vissa föredrar att ändra formen på linjen när den länkar till en enhet.
Jag föredrar siffror, som gör saker tydligare:
Siffrorna ovan betyder detta:en bok kan skrivas av en eller flera författare. n betyder valfritt antal element.
Och en författare kan ha skrivit från 0 böcker (kanske det skriver en nu) till ett oändligt antal böcker.
Den första kallas en noll-till-många-relation . Den andra är en en-till-många-relation .
Vi kan också ha:
- en-till-en-relationer
- många-till-många-relationer
- noll-till-en-relationer
Attribut
Varje enhet kan ha ett eller flera attribut.
Låt oss säga att vi kommer att använda ovanstående förhållande i en bokhandel. Varje författare har ett namn, en biografi, en webbadress.
Varje bok har en titel, ett förlag, ett utgivningsår, ett ISBN. Förlaget kan också vara en enhet, om vi vill. Men vi kan också definiera det som ett attribut för en bok.
Så här kan vi representera ovanstående information:
Identifieringsattribut
Enheter måste identifieras med en unik nyckel. Bokentiteten kan identifieras unikt med ISBN-attributet. Varje bok har ett enda ISBN (med tanke på att vi inte representerar ett enda exemplar av en bok, utan en boktitel).
Vi identifierar de primära nyckelattributen genom att underliggande dem:
Författaren, å andra sidan, har ingen unik identifierare för tillfället. Två författare kan ha samma namn.
Vi måste därför lägga till ett unikt nyckelattribut. Till exempel ett id attribut:
Identifieringsattribut kan sträcka sig över flera attribut.
Till exempel, pass-ID och upphovsmans land identifierar personen unikt och kan ersätta id attribut vi har lagt till:
Vilken ska man välja? Det är en fråga om vad som är mer vettigt i din ansökan. Om vi modellerar en bokhandel kan vi inte förvänta oss att ha lands- och pass-ID för alla bokförfattare. Vi kommer därför att använda ett slumpmässigt id vi väljer och associerar med varje författare.
Relationsattribut
Attribut är inte unika för enheter. Relationer kan också ha attribut.
Tänk på att vi måste modellera ett bibliotek. Förutom bok- och författarenheterna introducerar vi nu läsarenheten , en person som lånar boken för att läsa den. Vi tar dess namn och ID-kortsnummer när de lånar det:
Men vi saknar fortfarande information. Vi behöver veta när personen lånade boken och datumet då de returnerar den, så att vi kan lagra informationen om hela historien om en viss bok i vårt bibliotek. Denna information tillhör varken boken eller läsaren. det tillhör relationen:
Svaga enheter
Vi pratade om primärnycklar ovan och hur hjälpen unikt identifierar en entitet.
Vissa enheter är beroende av andra enheter för sin existens och kallas svaga enheter .
Anta att vi behöver modellera beställningar för en onlinebutik.
För varje beställning lagrar vi beställnings-id, som börjar från 1 och ökar med tiden, datum och tid då den gjordes och informationen om kunden, så att vi vet vem vi ska fakturera och vart den ska skickas.
Då måste vi också veta vad de beställt. Vi skapar en svag enhet "beställd artikel", som representerar varje artikel i kundvagnen vid kassan.
Denna enhet kommer att lagra artikelpriset i kassan (så när vi ändrar priset på produkterna på rean kommer det inte att påverka de beställningar som redan lagts), mängden varor som beställdes och de valda alternativen. Säg att vi säljer t-shirts, därför måste vi lagra färgen och storleken på den beställda t-shirten.
Det är en svag enhet eftersom en beställd artikelenhet inte kan existera utan en beställningsenhet.
Rekursiva relationer
En entitet kan ha en rekursiv relation till sig själv. Anta att vi har en personenhet. Vi kan modellera relationen mellan föräldrar och barn på detta sätt:
En person kan ha från 0 till n barn, ett barn har 2 föräldrar (med tanke på det enklaste scenariot).
ISA-relationer
ISA står för IS-A, och det är ett sätt att modellera generaliseringar i ER-modellen.
Vi använder den för att gruppera liknande enheter under ett gemensamt paraply. Till exempel kan en författare och en läsare, i fallet med böcker och biblioteksexempel, generaliseras med hjälp av en personenhet.
De har båda ett namn, så vi extraherar namnet till personens enhet, och hanterar bara särdragen med att vara författare eller läsare i motsvarande enhet:
Icke-binära relationer
Alla relationer är inte strikt binära. Låt oss ta en lektionsscenario.
En lektion äger rum i ett rum på skolan idag kl 10:00, med en lärare som pratar med en klass om fysik.
Så en lektion ges vid en viss tid på dagen, den involverar ett ämne, en lärare, en klass och ett rum.
Vi kan modellera det på detta sätt:
