Entity Relationship (ER) Diagram Model med DBMS Exempel

Vad är ett ER-diagram?

Entitetsrelationsdiagrammet (ER-diagrammet) är ett kraftfullt visuellt verktyg för att utforma relationsdatabasstrukturer. Det föreslogs först av Peter Chen 1976 och ger en konceptuell modelleringsgrund som definierar entiteter, attribut, relationer och deras kardinaliteter med precision. Denna handledning täcker allt från grundläggande koncept till avancerade tekniker och hjälper dig att bemästra databasschemadesign.

ER-diagram innehåller olika symboler som använder rektanglar för att representera entiteter, ovaler för att definiera attribut och diamantformer för att representera relationer.

Vid första anblicken ser ett ER-diagram väldigt likt ett flödesschema. Ett ER-diagram innehåller dock många specialiserade symboler, och deras betydelser gör modellen unik. Syftet med ett ER-diagram är att representera enhetens ramverksinfrastruktur.

ER-modellernas historia

Peter Chen föreslog ER-diagrammet 1976 i sin banbrytande artikel "The Entity-Relationship Model: Toward a Unified View of Data". Hans mål var att skapa en enhetlig konvention som kunde användas för både relationsdatabaser och nätverk. Chen föreställde sig ER-modellen som en konceptuell modelleringsmetod som skulle överbrygga klyftan mellan verkliga krav och teknisk databasimplementering.

Sedan dess har ER-modellen utvecklats med olika notationssystem, inklusive Chen-notation (originalet), kråkfotsnotation (populär i moderna verktyg) och UML-baserade metoder. Trots dessa variationer förblir kärnkoncepten konsekventa i alla implementeringar.

Varför använda ER-diagram?

ER-diagram ger många fördelar för databasdesign och utveckling:

• Visuell kommunikation: De ger en tydlig visuell representation som både tekniska och icke-tekniska intressenter kan förstå.
• Ritning för utveckling: De visar exakt hur tabeller ska kopplas samman och vilka fält varje tabell kommer att innehålla.
• Klar för översättning: ER-diagram kan direkt översättas till relationstabeller, vilket gör att du snabbt kan bygga databaser.
• Felförebyggande: De hjälper till att identifiera designfel och redundanser före implementering, vilket sparar tid och resurser.
• Dokumentation: De fungerar som bestående dokumentation som hjälper nya teammedlemmar att förstå systemarkitekturen.
• Systemanalys: De hjälper till att identifiera alla enheter som finns i ett system och relationerna mellan dem.

ER-diagramkomponenter

Varje ER-diagram är uppbyggt av tre kärnkomponenter: entiteter, attribut och relationer. Att förstå varje komponent och hur de interagerar är avgörande för att skapa effektiva databasdesigner.

Exempel på ER-diagram

Till exempel, i en universitetsdatabas kan vi ha entiteter för Studenter, Kurser och Föreläsare. En studententitet kan ha attribut som Rollno, Namn och DeptID. De kan ha relationer med Kurser och Föreläsare.

enheter

En entitet representerar vilket verkligt objekt som helst – levande eller icke-levande – som tydligt kan identifieras och om vilket data kan lagras. Det kan vara en fysisk sak, ett faktum om företaget eller en händelse som inträffar i den verkliga världen. Enheter kan inkludera personer, platser, objekt, händelser eller koncept.

Exempel på enheter per kategori:

• Person: Anställd, student, patient, kund
• Plats: Butik, byggnad, kontor, lager
• Objekt: Maskin, Produkt, Bil, Bok
• Händelse: Försäljning, registrering, förnyelse, transaktion
• Begrepp: Konto, Kurs, Avdelning, Projekt

Entitetsuppsättning

En entitetsmängd är en grupp liknande entiteter som delar gemensamma attribut. Till exempel bildar alla studenter på ett universitet en entitetsmängd av typen "Student". Entiteter representeras i ER-diagram med hjälp av rektanglar, med entitetsnamnet skrivet inuti.

Entiteter representeras av sina egenskaper, vilka också kallas attribut. Alla attribut har sina separata värden. Till exempel kan en studententitet ha ett namn, en ålder och en klass som attribut.

Starka enheter kontra svaga enheter

Enheter klassificeras som antingen starka eller svaga baserat på deras förmåga att existera självständigt. Att förstå denna distinktion är avgörande för korrekt databasdesign.

En stark entitet har sin egen primärnyckel och kan existera oberoende. Till exempel kan en "Student"-entitet identifieras unikt med Student_ID utan att vara beroende av någon annan entitet.

En svag entitet saknar en egen primärnyckel och är beroende av en stark entitet (kallad ägarentiteten) för sin identifiering. Den använder en partiell nyckel (diskriminator) kombinerad med ägarens primärnyckel för att uppnå unikhet. Till exempel, i ett banksystem är en "transaktions"-entitet beroende av en "konto"-entitet – transaktionsnumret ensamt är inte unikt i hela databasen, men i kombination med kontonumret blir det unikt.

Stark enhet	Svag enhet
Har sin egen primärnyckel	Har ingen primärnyckel; använder partiell nyckel
Representerad av en enda rektangel	Representerad av en dubbel rektangel
Primärnyckeln är understruken med heldragen linje	Delvis tonart är understruken med streckad linje
Kan existera oberoende	Beror på ägarenheten för existens
Kopplat till en enda diamantrelation	Sammankopplad med dubbel diamant (identifierande relation)
Exempel: Student, Anställd, Produkt	Exempel: Transaktion, Beroende, Order_Item

Förhållande

En relation representerar en koppling mellan två eller flera entiteter. Relationer identifieras vanligtvis med hjälp av verb eller verbfraser som beskriver hur entiteter interagerar med varandra. I ER-diagram representeras relationer med diamantformer. Exempel: Tom arbetar på kemiavdelningen.

Entiteter deltar i relationer. Vi kan ofta identifiera relationer med verb eller verbfraser.

Exempel:

• Du deltar i denna föreläsning
• Jag håller föreläsningen
• En student går på en föreläsning
• En föreläsare håller en föreläsning

attribut

Ett attribut är en egenskap eller karaktäristik som beskriver en entitet eller relation. Attribut ger den detaljerade information som gör varje entitetsinstans unik och meningsfull. I ER-diagram representeras attribut med hjälp av ovaler (ellipser) som är kopplade till deras överordnade entitet med en linje.

Till exempel kan en student-entitet ha attribut som Student_ID, Namn, Födelsedatum, E-postadress och Telefonnummer.

Typer av attribut

Attributtyp	BESKRIVNING	Exempelvis
Enkel (Atomic)	Kan inte delas upp ytterligare i mindre komponenter	Telefonnummer, personnummer, e-postadress
Komposit	Kan delas upp i mindre underattribut	Fullständigt namn (förnamn, mellannamn, efternamn), adress (gata, ort, postnummer)
Härledd	Värdet beräknas från andra attribut; lagras inte direkt	Ålder (härledd från födelsedatum), Totalpris
Flervärderad	Kan innehålla flera värden för en enda enhet	Telefon: Numbers, E-postadresser, Färdigheter
Nyckelattribut	Identifierar varje entitetsinstans unikt (primärnyckel)	Student-ID, Anställd-ID, ISBN

Viktigt tips: I ER-diagram visas nyckelattribut med deras namn understrukna. Härledda attribut visas i streckade ovaler och flervärdesattribut visas i dubbla ovaler.

Kardinalitet (relationstyper)

Kardinalitet definierar de numeriska begränsningarna för en relation – specifikt hur många instanser av en entitet som kan associeras med instanser av en annan entitet. Att förstå kardinalitet är avgörande för att utforma effektiva databasstrukturer.

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

En entitet från mängd A kan associeras med högst en entitet från mängd B, och vice versa.

Exempel: En student tilldelas exakt ett student-ID, och varje student-ID tillhör exakt en student.

2. En-till-många (1:N)

En entitet från mängd A kan associeras med flera entiteter från mängd B, men varje entitet i B är endast associerad med en entitet i A.

Exempel: En klass består av flera elever.

3. Många-till-ett (N:1)

Flera entiteter från mängd A kan associeras med en entitet från mängd B.

Många elever tillhör till exempel samma klass.

4. Många-till-många (M:N)

Flera entiteter från mängd A kan associeras med flera entiteter från mängd B, och vice versa.

Studenter som grupp är till exempel associerade med flera fakultetsmedlemmar och fakultetsmedlemmar kan associeras med flera studenter.

ER-diagramsymboler och notationer

ER-diagram använder standardiserade symboler för att representera olika komponenter. Även om det finns flera notationssystem, är de två mest använda Chen-notationen och kråkfotsnotationen.

Chen-notation

Chen Notation, utvecklad av Peter Chen 1976, använder geometriska former för att representera olika element:

Symbol	Namn	Representerar
rektangel	Entity	Stark enhet (t.ex. student, produkt)
Double rektangel	Svag enhet	Enhet beroende av en annan (t.ex. transaktion)
Ellips/Oval	Attribut	En entitets egendom (t.ex. namn, ID)
Double ellips	Flervärdigt attribut	Attribut med flera värden (t.ex. Telefon Numbers)
Streckad ellips	Härlett attribut	Beräknat värde (t.ex. ålder från födelsedatum)
Diamant	Förhållande	Kopplingar mellan enheter (t.ex. registreringar)
Double Diamant	Identifierande relation	Relation med svag enhet
linje	Länk	Kopplar samman komponenter
Understruken text	Primärnyckel	Unik identifierare för enheten

Kråkafotnotation

Kråkfotsnotation (även kallad IE-notation) används oftare i moderna databasdesignverktyg. Den använder olika radslut för att representera kardinalitet och är särskilt effektiv för att visa "många"-sidan av relationer.

Symbol Description	Betydelse
Enkel vertikal linje (|)	Obligatorisk Ett (exakt ett)
Cirkel med linje (O|)	Valfri Ett (noll eller ett)
Kråkafot med linje (>|)	Obligatorisk Många (en eller flera)
Kråkafot med cirkel (>O)	Valfritt Många (noll eller fler)

Chen-notation vs. kråkfot: När man ska använda varje

Aspect	Chen-notation	Kråkafotnotation
bäst för	Konceptuell modellering, akademisk användning	Fysisk/logisk modellering, industriell användning
Attributvisning	Visar alla attribut visuellt	Listar attribut inuti entitetsrutan
Förekomst	Använder siffror (1, N, M)	Använder visuella symboler
Komplexitet	Kan bli rörigt	Mer kompakt och renare
Verktygssupport	Begränsat stöd för moderna verktyg	Brett stöd i verktyg

Hur man skapar ett Entity Relationship Diagram (ERD)

I den här handledningen om ER-diagram (ERD) ska vi lära oss hur man skapar ett ER-diagram. Följande är steg för att skapa ett ER-diagram:

Låt oss studera dem med ett exempel på entitetsrelationsdiagram:

På ett universitet registrerar sig en student i kurser. En student måste tilldelas minst en kurs. En enda professor undervisar i varje kurs. För att upprätthålla undervisningskvaliteten kan en professor endast ge en kurs.

Steg 1) Enhetsidentifiering

Vi har tre enheter:

• student
• Kurs
• Professor

Steg 2) Relationsidentifiering

Vi har följande två relationer:

• Studenten är delad en kurs
• Professorn levererar en kurs

Steg 3) Kardinalitetsidentifikation

Från problemformuleringen vet vi att:

• En elev kan tilldelas multipel kurser
• En professor kan endast leverera ett Naturligtvis

Steg 4) Identifiera attribut

Du behöver studera de filer, formulär, rapporter och data som för närvarande hanteras av organisationen för att identifiera attribut. Du kan också genomföra intervjuer med olika intressenter för att identifiera entiteter. Inledningsvis är det viktigt att identifiera attributen utan att mappa dem till en viss entitet.

När du har en lista med attribut måste du mappa dem till de identifierade entiteterna. Se till att ett attribut ska paras ihop med exakt en entitet. Om du tror att ett attribut ska tillhöra mer än en entitet, använd en modifierare för att göra det unikt.

När mappningen är klar, identifiera de primära nycklarna. Om en unik nyckel inte är lättillgänglig, skapa en.

Entity	Primärnyckel	Attribut
student	Student-ID	Elevs namn
Professor	Anställnings-ID	Professornamn
Kurs	Course_ID	Kursnamn

För kursentitet kan attribut vara varaktighet, poäng, uppgifter etc. För enkelhetens skull har vi bara betraktat ett attribut.

Steg 5) Skapa ERD:n

En mer modern representation av ett exempel på ett entitetsrelationsdiagram:

Bästa praxis för effektiva ER-diagram

Följ dessa riktlinjer för att skapa tydliga, lättskötta och effektiva ER-diagram:

• Eliminera redundans: Ta bort dubbletter av entiteter, attribut eller relationer.
• Använd tydliga namngivningskonventioner: Använd konsekventa, beskrivande namn. Undvik förkortningar.
• Validera mot krav: Säkerställ att diagrammet stöder alla datalagringsbehov.
• Håll det enkelt: Skapa flera diagram på olika nivåer istället för ett rörigt diagram.
• Använd färg sparsamt: Använd färger konsekvent för att markera kategorier.
• Dokumentantaganden: Inkludera anteckningar som förklarar antaganden om affärsregler.
• Revmed intressenter: Låt affärsanvändare och det tekniska teamet granska diagrammet.
• Versionskontroll: Behåll versioner allt eftersom designen utvecklas.

ER-diagram kontra UML-klassdiagram

Även om både ER-diagram och UML-klassdiagram används för datamodellering, tjänar de olika syften och sammanhang. Att förstå när man ska använda var och en är viktigt för effektiv systemdesign.

Aspect	ER-diagram	UML klassdiagram
Huvudsakliga syfte	Databasdesign	Programvara/objektdesign
Fokus	Data och relationer	Objekt, metoder och beteenden
Metoder/Operationer	Stöds inte	Fullt stöd
Arv	Begränsad (endast i EER)	Fullt stöd
Industrianvändning	Databasadministratörer, dataanalytiker	Programvaruutvecklare, arkitekter

Vanliga frågor