Entity Relationship (ER) Diagram Model med DBMS Eksempel

Hvad er et ER-diagram?

Entitetsrelationsdiagrammet (ER-diagrammet) er et effektivt visuelt værktøj til design af relationelle databasestrukturer. Det blev først foreslået af Peter Chen i 1976 og giver et konceptuelt modelleringsgrundlag, der definerer enheder, attributter, relationer og deres kardinaliteter med præcision. Denne vejledning dækker alt fra grundlæggende koncepter til avancerede teknikker og hjælper dig med at mestre design af databaseskemaer.

ER-diagrammer indeholder forskellige symboler, der bruger rektangler til at repræsentere enheder, ovaler til at definere attributter og diamantformer til at repræsentere relationer.

Ved første øjekast ligner et ER-diagram meget et flowdiagram. Et ER-diagram indeholder dog mange specialiserede symboler, og deres betydninger gør denne model unik. Formålet med et ER-diagram er at repræsentere entitetsrammeinfrastrukturen.

ER-modellernes historie

Peter Chen foreslog ER-diagrammet i 1976 i sin skelsættende artikel "The Entity-Relationship Model: Toward a Unified View of Data". Hans mål var at skabe en ensartet konvention, der kunne bruges til både relationelle databaser og netværk. Chen forestillede sig ER-modellen som en konceptuel modelleringstilgang, der ville bygge bro mellem virkelige krav og teknisk databaseimplementering.

Siden da har ER-modellen udviklet sig med forskellige notationssystemer, herunder Chen-notation (originalen), kragefodsnotation (populær i moderne værktøjer) og UML-baserede tilgange. Trods disse variationer forbliver kernekoncepterne konsistente på tværs af alle implementeringer.

Hvorfor bruge ER-diagrammer?

ER-diagrammer giver adskillige fordele til databasedesign og -udvikling:

• Visuel kommunikation: De giver en klar visuel repræsentation, som både tekniske og ikke-tekniske interessenter kan forstå.
• Plan for udvikling: De viser præcis, hvordan tabeller skal forbindes, og hvilke felter hver tabel skal indeholde.
• Oversættelsesklar: ER-diagrammer kan direkte oversættes til relationelle tabeller, hvilket giver dig mulighed for hurtigt at opbygge databaser.
• Fejlforebyggelse: De hjælper med at identificere designfejl og redundanser før implementering, hvilket sparer tid og ressourcer.
• Dokumentation: De fungerer som varig dokumentation, der hjælper nye teammedlemmer med at forstå systemarkitekturen.
• Systemanalyse: De hjælper med at identificere alle enheder, der findes i et system, og relationerne mellem dem.

ER-diagramkomponenter

Hvert ER-diagram er bygget op af tre kernekomponenter: Enheder, Attributter og Relationer. Det er vigtigt at forstå hver komponent og hvordan de interagerer for at skabe effektive databasedesigns.

Eksempler på ER-diagram

For eksempel kan vi i en universitetsdatabase have enheder for Studerende, Kurser og Undervisere. En studerendeenhed kan have attributter som Rollno, Navn og DeptID. De kan have relationer til Kurser og Undervisere.

Enheder

En enhed repræsenterer ethvert objekt i den virkelige verden – levende eller ikke-levende – der kan identificeres tydeligt, og om hvilket der kan lagres data. Det kan være en fysisk ting, en kendsgerning om virksomheden eller en begivenhed, der sker i den virkelige verden. Enheder kan omfatte personer, steder, objekter, begivenheder eller koncepter.

Eksempler på enheder efter kategori:

• Person: Medarbejder, studerende, patient, kunde
• Sted: Butik, bygning, kontor, lager
• Objekt: Maskine, Produkt, Bil, Bog
• Tilfælde: Salg, registrering, fornyelse, transaktion
• Koncept: Konto, Kursus, Afdeling, Projekt

Entitetssæt

Et entitetssæt er en gruppe af lignende enheder, der deler fælles attributter. For eksempel danner alle studerende på et universitet et "studerende" entitetssæt. Enheder repræsenteres i ER-diagrammer ved hjælp af rektangler med entitetsnavnet skrevet indeni.

Enheder repræsenteres af deres egenskaber, som også kaldes attributter. Alle attributter har deres separate værdier. For eksempel kan en studerende-enhed have et navn, en alder og en klasse som attributter.

Stærke enheder vs. svage enheder

Enheder klassificeres som enten stærke eller svage baseret på deres evne til at eksistere uafhængigt. Forståelse af denne sondring er afgørende for korrekt databasedesign.

En stærk enhed har sin egen primære nøgle og kan eksistere uafhængigt. For eksempel kan en "Student"-enhed identificeres entydigt af Student_ID uden at være afhængig af nogen anden enhed.

En svag enhed mangler sin egen primærnøgle og er afhængig af en stærk enhed (kaldet ejerenheden) for sin identifikation. Den bruger en delvis nøgle (diskriminator) kombineret med ejerens primære nøgle for at opnå unikhed. For eksempel afhænger en "transaktions"-enhed i et banksystem af en "konto"-enhed – transaktionsnummeret alene er ikke unikt på tværs af hele databasen, men kombineret med kontonummeret bliver det unikt.

Stærk enhed	Svag enhed
Har sin egen primærnøgle	Har ikke en primærnøgle; bruger delvis nøgle
Repræsenteret af et enkelt rektangel	Repræsenteret af et dobbelt rektangel
Primærnøgle er understreget med en solid linje	Delvis toneart er understreget med stiplet linje
Kan eksistere uafhængigt	Afhænger af ejerenheden for eksistens
Forbundet med enkelt diamantforhold	Forbundet med dobbelt diamant (identificerende forhold)
Eksempel: Studerende, Medarbejder, Produkt	Eksempel: Transaktion, Afhængig, Ordrevare

Relationship

En relation repræsenterer en association mellem to eller flere enheder. Relationer identificeres typisk ved hjælp af verber eller verbalfraser, der beskriver, hvordan enheder interagerer med hinanden. I ER-diagrammer repræsenteres relationer ved hjælp af diamantformer. Eksempel: Tom arbejder i kemiafdelingen.

Enheder deltager i relationer. Vi kan ofte identificere relationer med verber eller verbum.

eksempler:

• Du deltager i dette foredrag
• Jeg holder foredraget
• En studerende deltager i en forelæsning
• En forelæser holder et foredrag

Attributter

En attribut er en egenskab eller et karakteristikum, der beskriver en enhed eller et forhold. Attributter giver de detaljerede oplysninger, der gør hver entitetsinstans unik og meningsfuld. I ER-diagrammer repræsenteres attributter ved hjælp af ovaler (ellipser), der er forbundet med deres overordnede enhed med en linje.

For eksempel kan en Student-enhed have attributter som Student_ID, Name, Date_of_Birth, Email og Phone_Number.

Typer af attributter

Attributtype	Produktbeskrivelse	Eksempel
Simpel (Atomic)	Kan ikke opdeles yderligere i mindre komponenter	Telefonnummer, CPR-nummer, e-mail
Composite	Kan opdeles i mindre underattributter	Fulde navn (fornavn, mellemnavn, efternavn), adresse (gade, by, postnummer)
Afledt	Værdien beregnes ud fra andre attributter; gemmes ikke direkte	Alder (afledt af fødselsdato), samlet pris
Flerværdi	Kan indeholde flere værdier for en enkelt enhed	Telefon Numbers, E-mailadresser, Færdigheder
Nøgleegenskab	Identificerer entydigt hver entitetsinstans (primær nøgle)	Studie-ID, Medarbejder-ID, ISBN

Nøgle Tip: I ER-diagrammer vises nøgleattributter med deres navne understreget. Afledte attributter vises med stiplede ovaler, og flerværdiattributter vises med dobbelte ovaler.

Kardinalitet (relationstyper)

Kardinalitet definerer de numeriske begrænsninger for en relation – specifikt hvor mange forekomster af én enhed, der kan knyttes til forekomster af en anden enhed. Forståelse af kardinalitet er afgørende for at designe effektive databasestrukturer.

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

Én entitet fra sæt A kan højst være associeret med én entitet fra sæt B, og omvendt.

Eksempel: Én elev får tildelt præcis ét studie-ID, og ​​hvert studie-ID tilhører præcis én elev.

2. En-til-mange (1:N)

Én enhed fra sæt A kan være associeret med flere enheder fra sæt B, men hver enhed i B er kun associeret med én enhed i A.

Eksempel: En klasse består af flere elever.

3. Mange-til-en (N:1)

Flere enheder fra sæt A kan associeres med én enhed fra sæt B.

For eksempel hører mange elever til i samme klasse.

4. Mange-til-mange (M:N)

Flere enheder fra sæt A kan associeres med flere enheder fra sæt B, og omvendt.

For eksempel er studerende som en gruppe tilknyttet flere fakultetsmedlemmer, og fakultetsmedlemmer kan være tilknyttet flere studerende.

ER-diagramsymboler og -notationer

ER-diagrammer bruger standardiserede symboler til at repræsentere forskellige komponenter. Selvom der findes flere notationssystemer, er de to mest anvendte Chen-notation og kragefodsnotation.

Chen-notation

Chen Notation, udviklet af Peter Chen i 1976, bruger geometriske former til at repræsentere forskellige elementer:

Symbol	Navn	Repræsenterer
rektangel	Enhed	Stærk enhed (f.eks. studerende, produkt)
Double rektangel	Svag enhed	Enhed afhængig af en anden (f.eks. transaktion)
Ellipse/Oval	Attribut	En enheds egenskab (f.eks. navn, ID)
Double Ellipse	Flerværdiattribut	Attribut med flere værdier (f.eks. Telefon Numbers)
Stiplet ellipse	Afledt attribut	Beregnet værdi (f.eks. alder fra fødselsdato)
Diamant	Relationship	Tilknytning mellem enheder (f.eks. tilmeldinger)
Double Diamant	Identificering af forhold	Forholdet til den svage enhed
Line	Link	Forbinder komponenterne sammen
Understreget tekst	Primærnøgle	Unik identifikator for enhed

Kragefodnotation

Kragefodsnotation (også kaldet IE-notation) bruges mere almindeligt i moderne databasedesignværktøjer. Den bruger forskellige linjeafslutninger til at repræsentere kardinalitet og er særligt effektiv til at vise "mange"-siden af ​​relationer.

Symbol Description	Betydning
Enkelt lodret linje (|)	Obligatorisk én (præcis én)
Cirkel med linje (O|)	Valgfri En (nul eller en)
Kragefod med streg (>|)	Obligatorisk Mange (en eller flere)
Kragefod med cirkel (>O)	Valgfrit Mange (nul eller mere)

Chen-notation vs. kragefod: Hvornår skal man bruge hver af dem

Aspect	Chen-notation	Kragefodnotation
Bedste For	Konceptuel modellering, akademisk brug	Fysisk/logisk modellering, brug i industrien
Attributvisning	Viser alle attributter visuelt	Viser attributter i entitetsboksen
kardinalitet	Bruger tal (1, N, M)	Bruger visuelle symboler
Kompleksitet	Kan blive rodet	Mere kompakt og renere
Værktøjsstøtte	Begrænset understøttelse af moderne værktøjer	Bredt understøttet i værktøjer

Sådan opretter du et Entity Relationship Diagram (ERD)

I denne vejledning til ER-diagrammer (ERD) lærer vi, hvordan man opretter et ER-diagram. Følgende er trinnene til at oprette et ER-diagram:

Lad os studere dem med et Entity Relationship Diagram Eksempel:

På et universitet tilmelder en studerende sig kurser. En studerende skal være tildelt mindst ét ​​kursus. En enkelt professor underviser i hvert kursus. For at opretholde undervisningskvaliteten kan en professor kun levere ét kursus.

Trin 1) Enhedsidentifikation

Vi har tre enheder:

• studerende
• Course
• Professor

Trin 2) Relationsidentifikation

Vi har følgende to forhold:

• Eleven er tildelt et kursus
• Professoren leverer et kursus

Trin 3) Kardinalitetsidentifikation

Fra problemformuleringen ved vi, at:

• En elev kan tildeles flere kurser
• En professor kan kun levere en kursus

Trin 4) Identificer attributter

Du skal studere de filer, formularer, rapporter og data, som organisationen i øjeblikket vedligeholder, for at identificere attributter. Du kan også gennemføre interviews med forskellige interessenter for at identificere enheder. I starten er det vigtigt at identificere attributterne uden at knytte dem til en bestemt enhed.

Når du har en liste over attributter, skal du knytte dem til de identificerede enheder. Sørg for, at en attribut skal parres med præcis én enhed. Hvis du mener, at en attribut skal tilhøre mere end én enhed, skal du bruge en modifikator for at gøre den unik.

Når kortlægningen er færdig, skal du identificere de primære nøgler. Hvis en unik nøgle ikke er let tilgængelig, skal du oprette en.

Enhed	Primærnøgle	Attribut
studerende	Studiekort	Elevnavn
Professor	Medarbejder-ID	Professornavn
Course	Course_ID	Kursusnavn

For Kursusentitet kan attributter være Varighed, Kreditter, Opgaver osv. For nemheds skyld har vi kun betragtet én attribut.

Trin 5) Opret ERD'en

En mere moderne repræsentation af et eksempel på et entitetsrelationsdiagram:

Bedste praksis for effektive ER-diagrammer

Følg disse retningslinjer for at oprette klare, vedligeholdelige og effektive ER-diagrammer:

• Fjern redundans: Fjern dubletter af enheder, attributter eller relationer.
• Brug klare navngivningskonventioner: Brug ensartede, beskrivende navne. Undgå forkortelser.
• Valider i forhold til krav: Sørg for, at diagrammet understøtter alle datalagringsbehov.
• Hold det simpelt: Opret flere diagrammer på forskellige niveauer i stedet for ét rodet diagram.
• Brug farver sparsomt: Brug farver konsekvent til at fremhæve kategorier.
• Dokumentforudsætninger: Medtag noter, der forklarer antagelser om forretningsregler.
• Revmed interessenter: Få forretningsbrugere og det tekniske team til at gennemgå diagrammet.
• Versionskontrol: Vedligehold versioner, efterhånden som designet udvikler sig.

ER-diagrammer vs. UML-klassediagrammer

Selvom både ER-diagrammer og UML-klassediagrammer bruges til datamodellering, tjener de forskellige formål og kontekster. Det er vigtigt at forstå, hvornår man skal bruge hver af dem, for at opnå et effektivt systemdesign.

Aspect	ER diagram	UML klassediagram
Primært formål	Databasedesign	Software-/objektdesign
Fokus	Data og relationer	Objekter, metoder og adfærd
Metoder/Operationer	Ikke understøttet	Fuldt understøttet
Arv	Begrænset (kun i EER)	Fuld støtte
Brug i industrien	Databaseadministratorer, dataanalytikere	Softwareudviklere, arkitekter

Ofte Stillede Spørgsmål