Vanliga ER-diagrammisstag

Lär känna ER-diagrammet (Entity Relationship), dess delar och vad som ofta går fel när du skapar det.

Har du någonsin skapat en relationsdatabasmodell? Eller kanske du försöker skapa din första? Du vet (eller du kommer snart att få reda på det) att det ibland kan vara ganska svårt att översätta verkliga problem till databaslogik.

Ett av verktygen som kan hjälpa dig är ER-diagrammet. Vanlig databasdesignvisdom säger att ju bättre ditt ER-diagram är, desto lättare blir det att bygga databasmodellen. Detta viktiga objekt sätter tonen för alla framtida frustrationer eller framgångar. Med ett bra ER-diagram är det ganska enkelt att skapa en relationsdatabasmodell. Naturligtvis kan misstag göras i vilken fas som helst av databasmodelleringen. Men att ha ett bra ER-diagram kan hjälpa dig att undvika några av dessa misstag.

Så låt oss se vad ER-diagrammet är och hur vi kan undvika dess vanliga misstag.

Vad är ett akutdiagram?

"ER Diagram", eller ERD, är en förkortning för Entity Relationship Diagram. Den kartlägger problemet som ska modelleras, men på ett strukturerat sätt som visar relationerna mellan enheter.

Ett ER-diagrams byggstenar

ER-diagram består av följande element:

• Entitet
• Relationer
• Enhets- eller relationsattribut

Det första elementet i ER-diagrammet är entiteten . Entiteten är ett objekt eller en händelse som vi vill lagra information om. I grund och botten är det vad som helst som vi kan samla in data om. Vi kan till exempel lagra data om anställda, studenter, lärare, köpare, produkter, avdelningar, betalningar, platser etc.

När vi väl har entiteter är det nödvändigt att skapa relationer . En relation visar hur en enhet är kopplad till och associerad med en eller flera andra enheter.

Det sista elementet i ER-diagrammet är en attribut för entitet eller relation . Ett attribut är en beskrivning av en egenskap som tillhör en enhet eller relation. Attribut har värden. Några attribut för de ovan nämnda enheterna kan vara:

• Anställd, elev, lärare, köpare – ID, namn, efternamn, födelsedatum, adress etc.
• Produkt – ID, kategori, beskrivning, färg, serienummer, etc.
• Avdelning – ID, avdelningsnamn, avdelningschef, antal anställda etc.
• Betalningar – ID, datum och tid, belopp.
• Plats – Stad, postnummer, region, land, kontinent.

Typer av relationer

Innan vi går in på de vanliga misstagen som finns i ER-diagram är det viktigt att förstå de möjliga relationstyperna. De flesta ERD-misstag är i huvudsak felaktigt definierade relationer mellan enheter.

Det finns tre typer av relationer mellan enheter:

• En-till-en (1:1)
• En till många (1:N)
• Många-till-många (M:N)

En-till-en-relationer (1:1)

Den första relationstypen är en-till-en , eller 1:1 . I detta förhållande kan en enda instans av en entitet endast kopplas ihop med en enda instans av en annan entitet (och vice versa, naturligtvis).

Låt oss säga att vi har enheten student med attributen namn och efternamn . Vi har också enheten id med det enda attributet id . Förhållandet 1:1 skulle innebära att en elev endast kan ha ett id-nummer. Det innebär också att ett id-nummer kan tillhöra endast en elev.

Detta förhållande ses mycket sällan i databaser. Om endast ett ID kan kopplas till endast en student, finns det ingen anledning att dela upp dem i två olika enheter.

Här är ett exempel på detta förhållande:

En-till-många (1:N)-relationer

Den vanligaste typen av databasrelation är en-till-många eller 1:N . En En-till-många-relation innebär att varje enskild instans av en enhet kan kopplas samman med flera instanser av en annan enhet. Det betyder också att varje instans av den andra enheten kan associeras med endast en instans av den första enheten.

Det finns till exempel en enhet köpare med attributen id , namn och efternamn . Vi vill upprätta en relation med enheten betalning som har attributen id , datum och värde . Detta är ett 1:N-förhållande eftersom en köpare kan göra en eller flera betalningar. En betalning kan dock inte göras av flera köpare; det kan endast göras av en köpare.

Här är exemplet:

Detta förhållande kan också ses tvärtom. I den här situationen kallas det många-till-en eller N:1 . Naturligtvis är detta ingen ny typ av relation. Det är samma som 1:N, men det ses från motsatt håll.

Anta som ett exempel att vi har enheten anställd med attributen id , namn och efternamn . Vi vill etablera anställd s förhållande till enhetens avdelning som har attributen id och namn . Relationen mellan dessa två enheter är N:1. Det betyder att varje anställd bara kan arbeta på en avdelning, men att flera anställda kan arbeta på samma avdelning.

Många-till-många (M:N)-relationer

A Många-till-många eller M:N relation innebär att varje instans av den första enheten kan associeras med mer än en instans av den andra enheten. Det betyder också att varje instans av den andra enheten kan associeras med flera instanser av den första enheten.

Låt oss se hur detta fungerar mellan enheterna student och föreläsning . Låt oss säga att student har attributen id , namn och efternamn . Entitetens föreläsning har attributen id och namn . En många-till-många-relation kan tolkas på följande sätt:en student kan gå på en eller flera föreläsningar, medan en föreläsning kan gå på av en eller flera studenter.

Här är diagrammet för detta exempel:

I databasmodellering delas sådana relationer vanligtvis upp i två eller flera 1:N eller N:1 relationer genom att introducera nya enheter.

Typiska misstag när man skapar ett akutdiagram

Många fel i ER-diagram passar in i en av dessa fyra kategorier:

• Felaktiga relationer mellan enheter
• Använda en entitetsinstans istället för en entitet
• Att blanda ihop ett attribut med en entitet
• Komplexa attribut

Låt oss titta på var och en för sig.

Felaktiga relationer mellan enheter

De vanligaste misstagen uppstår när man definierar förhållandet mellan enheter . Det finns vanligtvis inga misstag i ett 1:1-förhållande. Det är dock väldigt lätt att blanda ihop ett 1:N-förhållande med ett M:N-förhållande. Detta beror vanligtvis på att man inte förstår de krav som slutanvändaren ställer. Det är viktigt att ha mycket tydligt definierade krav och en djup förståelse för varför databasen behövs och hur den kommer att användas. Om vi ​​skapar ett ER-diagram med otillräcklig data och ofullständig förståelse kommer det med största sannolikhet att resultera i att relationer mellan enheter blir felaktigt definierade.

Låt oss titta på ett exempel. Om du skapar en databas för en bank kommer du troligen att skapa ett ER-diagram med enheten klient har attributen id , namn och efternamn . Du kommer också att ha en enhet som heter konto med attributen id och typ . Om du saknar erfarenhet av banksektorn tror du förmodligen att det alltid finns ett 1:N-förhållande mellan klienten och konto enheter, som visas nedan.

En kund kan ha flera konton i en bank. Ett konto kan dock endast ägas av en kund. Är detta verkligen sant? Kanske är det, kanske är det inte. En hel del banker erbjuder gemensamma konton som kan användas av flera kunder. Skapar du ett ER-diagram för en bank som erbjuder en sådan tjänst? Om banken inte erbjuder gemensamma konton, så har du rätt:förhållandet mellan klient och konto är 1:N. Men om banken erbjuder gemensamma konton är förhållandet M:N.

Använda en entitetsinstans istället för en entitet

Ett annat vanligt misstag är att använda en entitetsinstans istället för en entitet. En entitetsinstans är en enstaka förekomst av en viss enhet – det vill säga en enhet som faktiskt kan vara ett attribut av en större kategori.

Låt oss säga att vi arbetar i ett företag som allokerar mobiltelefoner och bärbara datorer till vissa anställda. Så i vår databas skulle vi ha en enhet som heter laptop med attributen id och modell och en enhet som heter anställd med attributen id , namn och efternamn , rätt?

Det finns ett problem här:en bärbar dator är faktiskt inte en enhet – det finns också mobiltelefoner att ta hänsyn till. Lösningen är att ersätta enheten laptop med en mer allmän enhet, som utrustning . Denna enhet kan ha attributen ID , typ och modell , enligt nedanstående. typen kan bestå av värden som telefon , PC , surfplatta och bärbar dator . På så sätt finns det inget behov av att skapa en separat enhet för varje typ av utrustning.

Du hittar exemplet här:

Att blanda ihop ett attribut med en entitet

Nästa vanliga misstag är att blanda ihop ett attribut med en entitet. Låt oss säga att vi har beslutat att skapa en enhet som heter anställd som kommer att bestå av attributen id , namn , efternamn , födelsedatum , id_department , namn_avdelning och head_department . Den här enheten kommer att få oss i problem när vi skapar en databasmodell eftersom den består av för många attribut som inte unikt definierar den här entiteten .

Kom ihåg att vi definierade enheter som allt som vi kan samla in data om. Med det i åtanke kan vi se att den nuvarande anställda entitet kan delas upp i två enheter:anställd och avdelning , enligt nedanstående.

Komplexa attribut

Det sista vanliga misstaget vi kommer att prata om är att inkludera ett komplext attribut i en enhet. Med andra ord, vi har ett attribut som egentligen borde vara dess egen enhet .

Låt oss säga att vi har en enhet som heter studenter som definieras av följande attribut:id , namn , efternamn , födelsedatum , adress , och examen_godkänd . Här, examen_godkänd är ett komplext attribut som består av mer än en information, det vill säga tentamens ID och datum och studentens poäng. Att lämna det så vore ett misstag. Istället bör vi skapa en ny enhet ur detta komplexa attribut . Den nya enheten kan få namnet exams och består av följande attribut:id , datum , students_id , och poäng .

Du hittar exemplet här:

Fick du några användbara ER-diagramtips?

Dessa fyra typer av misstag är de vanligaste i processen för att skapa ER-diagram. Naturligtvis finns det ingen komplett lista över typiska misstag eller typer av misstag. I det verkliga livet kommer sannolikt många typer av misstag att hända. Brist på planering, otillräcklig teknisk support och en förhastad databasdesignprocess bidrar alla till sina egna problem. Om du någonsin har skapat databaser eller deltagit i det från affärssidan, har du förmodligen upplevt några av dem! Alla dessa omständigheter leder till olika misstag, av vilka några är ganska unika.

Har du ett eget exempel på ett inte så bra ER-diagram? Eller kanske det finns några andra misstag som du ofta hittar? Vänligen meddela mig i kommentarsfältet.