Entity Relationship (ER) Diagram Model med DBMS Eksempel

⚡ Smart oppsummering

Eksempel på enhetsrelasjonsdiagrammodell (ER) med DBMS illustrerer en strukturert metode for å visuelt representere data og deres sammenkoblinger i relasjonsdatabaser. Foreslått av Peter Chen, gir den et konseptuelt modelleringsgrunnlag for å definere enheter, attributter, relasjoner og deres kardinaliteter presist.

🔍 Kjernekonsept: ER-diagrammer definerer databasestruktur gjennom tre kjernekomponenter – enheter, attributter og relasjoner – som sikrer tydelig tilordning mellom dataobjekter og deres interaksjoner.
🧱 Strukturelle symboler: Rektangler betegner enheter, ellipser representerer attributter, og diamanter illustrerer relasjoner; forbindelseslinjer indikerer logiske lenker, med understrekede attributter som markerer primærnøkler.
⚙️ Enhetsklassifisering: Enheter grupperes i sett, som hver identifiseres av unike nøkler eller attributter. Svake enheter mangler uavhengige nøkler og er avhengige av sterke enheter for identifikasjon, ved bruk av doble rektangler og stiplede understreker.
🔗 Definisjon av forhold: Relasjoner uttrykker assosiasjoner mellom enheter (f.eks. «Student melder seg på kurs») og kategoriseres etter kardinalitet – én-til-én, én-til-mange, mange-til-én eller mange-til-mange.
🧩 Attributttyper: Attributter kan være enkle, sammensatte, avledede eller flerverdifulle, og definere distinkte dataegenskaper som navn, datoer og beregnede felt.
🧭 Fremgangsmåte for oppretting av ERD: Identifiser enheter, opprett relasjoner, bestem kardinaliteter, tilordne attributter og definer primærnøkler før du konstruerer det komplette diagrammet.
📈 Optimaliseringspraksis: Fjern overflødigheter, merk alle komponenter og vedlikehold unike enhetsforekomster for klarhetens skyld, og sørg for at diagrammet støtter alle nødvendige krav til datalagring.

Les mer

Hva er et ER-diagram?

Entitetsrelasjonsdiagrammet (ER-diagrammet) er et kraftig visuelt verktøy for å designe relasjonelle databasestrukturer. Det ble først foreslått av Peter Chen i 1976, og gir et konseptuelt modelleringsgrunnlag som definerer enheter, attributter, relasjoner og deres kardinaliteter med presisjon. Denne veiledningen dekker alt fra grunnleggende konsepter til avanserte teknikker, og hjelper deg med å mestre databaseskjemadesign.

ER-diagrammer inneholder forskjellige symboler som bruker rektangler til å representere enheter, ovaler til å definere attributter og diamantformer til å representere relasjoner.

Ved første øyekast ser et ER-diagram veldig likt et flytskjema. Et ER-diagram inneholder imidlertid mange spesialiserte symboler, og betydningene deres gjør denne modellen unik. Formålet med et ER-diagram er å representere enhetsrammeverkets infrastruktur.

Eksempler på ER-diagram — Eksempel på enhetsrelasjonsdiagram

Historien om ER-modeller

Peter Chen foreslo ER-diagrammet i 1976 i sin banebrytende artikkel «The Entity-Relationship Model: Toward a Unified View of Data». Målet hans var å skape en ensartet konvensjon som kunne brukes for både relasjonsdatabaser og nettverk. Chen så for seg ER-modellen som en konseptuell modelleringstilnærming som ville bygge bro mellom virkelige krav og teknisk databaseimplementering.

Siden den gang har ER-modellen utviklet seg med ulike notasjonssystemer, inkludert Chen-notasjon (originalen), kråkefotnotasjon (populær i moderne verktøy) og UML-baserte tilnærminger. Til tross for disse variasjonene forblir kjernekonseptene konsistente på tvers av alle implementeringer.

Hvorfor bruke ER-diagrammer?

ER-diagrammer gir en rekke fordeler for databasedesign og -utvikling:

Visuell kommunikasjon: De gir en tydelig visuell representasjon som både tekniske og ikke-tekniske interessenter kan forstå.
Plan for utvikling: De viser nøyaktig hvordan tabeller skal kobles sammen og hvilke felt hver tabell skal inneholde.
Klar for oversettelse: ER-diagrammer kan oversettes direkte til relasjonstabeller, slik at du raskt kan bygge databaser.
Feilforebygging: De hjelper med å identifisere designfeil og overflødigheter før implementering, noe som sparer tid og ressurser.
Dokumentasjon: De fungerer som varig dokumentasjon som hjelper nye teammedlemmer med å forstå systemarkitekturen.
System analyse: De hjelper med å identifisere alle enheter som finnes i et system og forholdet mellom dem.

ER-diagramkomponenter

Hvert ER-diagram er bygget opp av tre kjernekomponenter: enheter, attributter og relasjoner. Å forstå hver komponent og hvordan de samhandler er viktig for å lage effektive databasedesign.

Eksempler på ER-diagram

I en universitetsdatabase kan vi for eksempel ha enheter for Studenter, Kurs og Forelesere. En studententitet kan ha attributter som Rollnr., Navn og AvdelingsID. De kan ha relasjoner med Kurs og Forelesere.

enheter

En enhet representerer ethvert objekt i den virkelige verden – levende eller ikke-levende – som kan identifiseres tydelig og som det kan lagres data om. Det kan være en fysisk ting, et faktum om bedriften eller en hendelse som skjer i den virkelige verden. Enheter kan inkludere personer, steder, objekter, hendelser eller konsepter.

Eksempler på enheter etter kategori:

person: Ansatt, student, pasient, kunde
Sted: Butikk, bygning, kontor, lager
Gjenstand: Maskin, produkt, bil, bok
Hendelse: Salg, registrering, fornyelse, transaksjon
Konsept: Konto, Kurs, Avdeling, Prosjekt

Enhetssett

Et entitetssett er en gruppe lignende enheter som deler felles attributter. For eksempel danner alle studenter ved et universitet et «Student»-entitetssett. Enheter er representert i ER-diagrammer ved hjelp av rektangler, med enhetsnavnet skrevet inni.

Enheter er representert av egenskapene sine, som også kalles attributter. Alle attributter har sine separate verdier. For eksempel kan en studententitet ha navn, alder og klasse som attributter.

Sterke enheter vs. svake enheter

Enheter klassifiseres som enten sterke eller svake basert på deres evne til å eksistere uavhengig. Å forstå dette skillet er avgjørende for riktig databasedesign.

En sterk entitet har sin egen primærnøkkel og kan eksistere uavhengig. For eksempel kan en «Student»-entitet identifiseres unikt av Student_ID uten å være avhengig av noen annen entitet.

En svak enhet mangler en egen primærnøkkel og er avhengig av en sterk enhet (kalt eierenheten) for identifikasjon. Den bruker en delvis nøkkel (diskriminator) kombinert med eierens primærnøkkel for å oppnå unikhet. I et banksystem er for eksempel en «transaksjons»-enhet avhengig av en «konto»-enhet – transaksjonsnummeret alene er ikke unikt på tvers av hele databasen, men kombinert med kontonummeret blir det unikt.

Sterk enhet	Svak enhet
Har sin egen primærnøkkel	Har ikke en primærnøkkel; bruker delvis nøkkel
Representert av et enkelt rektangel	Representert av et dobbelt rektangel
Primærnøkkelen er understreket med heltrukket linje	Delvis toneart er understreket med stiplet linje
Kan eksistere uavhengig	Avhenger av eierenheten for eksistens
Koblet til forholdet mellom én diamant	Forbundet med dobbel diamant (identifiserende forhold)
Eksempel: Student, Ansatt, Produkt	Eksempel: Transaksjon, Avhengig, Ordrevare

Slektskap

En relasjon representerer en assosiasjon mellom to eller flere enheter. Relasjoner identifiseres vanligvis ved hjelp av verb eller verbfraser som beskriver hvordan enheter samhandler med hverandre. I ER-diagrammer representeres relasjoner ved hjelp av diamantformer. Eksempel: Tom jobber i kjemiavdelingen.

Enheter tar del i relasjoner. Vi kan ofte identifisere relasjoner med verb eller verbfraser.

Eksempler:

Du deltar på denne forelesningen
Jeg holder foredraget
En student deltar på en forelesning
En foreleser holder et foredrag

attributter

Et attributt er en egenskap eller et kjennetegn som beskriver en enhet eller et forhold. Attributter gir den detaljerte informasjonen som gjør hver enhetsforekomst unik og meningsfull. I ER-diagrammer er attributter representert ved hjelp av ovaler (ellipser) koblet til den overordnede enheten med en linje.

For eksempel kan en student-enhet ha attributter som Student_ID, Navn, Fødselsdato, E-post og Telefonnummer.

Typer attributter

Attributttype	Tekniske beskrivelser	Eksempel
Enkel (Atomic)	Kan ikke deles ytterligere inn i mindre komponenter	Telefonnummer, personnummer, e-post
Kompositt	Kan deles opp i mindre underattributter	Fullt navn (fornavn, mellomnavn, etternavn), adresse (gate, poststed, postnummer)
Avledet	Verdien beregnes fra andre attributter; lagres ikke direkte	Alder (avledet fra fødselsdato), totalpris
Flerverdig	Kan inneholde flere verdier for en enkelt enhet	Telefon Numbers, E-postadresser, Ferdigheter
Nøkkelattributt	Identifiserer hver enhetsforekomst unikt (primærnøkkel)	Student-ID, ansatt-ID, ISBN

Nøkkel Tips: I ER-diagrammer vises nøkkelattributter med navnene understreket. Avledede attributter vises i stiplede ovaler, og flerverdiattributter vises i doble ovaler.

Kardinalitet (relasjonstyper)

Kardinalitet definerer de numeriske begrensningene for en relasjon – nærmere bestemt hvor mange forekomster av én enhet som kan knyttes til forekomster av en annen enhet. Å forstå kardinalitet er viktig for å designe effektive databasestrukturer.

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

Én enhet fra sett A kan være assosiert med maksimalt én enhet fra sett B, og omvendt.

Eksempel: Én student får tildelt nøyaktig én student-ID, og hver student-ID tilhører nøyaktig én student.

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

Én enhet fra sett A kan være assosiert med flere enheter fra sett B, men hver enhet i B er bare assosiert med én enhet i A.

Eksempel: Én klasse består av flere elever.

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

Flere enheter fra sett A kan assosieres med én enhet fra sett B.

Mange elever tilhører for eksempel samme klasse.

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

Flere enheter fra sett A kan assosieres med flere enheter fra sett B, og omvendt.

For eksempel er studenter som en gruppe assosiert med flere fakultetsmedlemmer, og fakultetsmedlemmer kan assosieres med flere studenter.

ER-diagramsymboler og notasjoner

ER-diagrammer bruker standardiserte symboler for å representere ulike komponenter. Selv om det finnes flere notasjonssystemer, er de to mest brukte Chen-notasjonen og kråkefotnotasjonen.

Chen-notasjon

Chen-notasjon, utviklet av Peter Chen i 1976, bruker geometriske former for å representere forskjellige elementer:

symbol	Navn	Representerer
rektangel	Entity	Sterk enhet (f.eks. student, produkt)
Double rektangel	Svak enhet	Enhet avhengig av en annen (f.eks. transaksjon)
Ellipse/Oval	Egenskap	En enhets egenskap (f.eks. navn, ID)
Double Ellipse	Flerverdig attributt	Attributt med flere verdier (f.eks. Telefon Numbers)
Stiplet ellipse	Avledet attributt	Beregnet verdi (f.eks. alder fra fødselsdato)
Diamant	Slektskap	Tilknytning mellom enheter (f.eks. registreringer)
Double Diamant	Identifiserende forhold	Forholdet til den svake enheten
linje	link	Kobler komponenter sammen
Understreket tekst	Primærnøkkel	Unik identifikator for enhet

Kråkefotnotasjon

Kråkefotnotasjon (også kalt IE-notasjon) brukes oftere i moderne databasedesignverktøy. Den bruker forskjellige linjeavslutninger for å representere kardinalitet og er spesielt effektiv for å vise "mange"-siden av relasjoner.

symbol Description	Betydning
Enkel vertikal linje (\|)	Obligatorisk én (nøyaktig én)
Sirkel med linje (O\|)	Valgfri én (null eller én)
Kråkefot med strek (>\|)	Obligatorisk Mange (en eller flere)
Kråkefot med sirkel (>O)	Valgfritt Mange (null eller mer)

Chen-notasjon vs. kråkefot: Når skal man bruke hver av dem?

Aspekt	Chen-notasjon	Kråkefotnotasjon
Best For	Konseptuell modellering, akademisk bruk	Fysisk/logisk modellering, bruk i industrien
Attributtvisning	Viser alle attributter visuelt	Viser attributter i enhetsboksen
kardinalitet	Bruker tall (1, N, M)	Bruker visuelle symboler
kompleksitet	Kan bli rotete	Mer kompakt og renere
Verktøysstøtte	Begrenset støtte for moderne verktøy	Bredt støttet i verktøy

Hvordan lage et Entity Relationship Diagram (ERD)

I denne veiledningen for ER-diagram (ERD) skal vi lære hvordan du lager et ER-diagram. Følgende er trinnene for å lage et ER-diagram:

Lag et enhetsrelasjonsdiagram — Trinn for å lage et ER-diagram

La oss studere dem med et Entity Relationship Diagram Eksempel:

På et universitet melder en student seg på kurs. En student må være tildelt minst ett kurs. Én professor underviser i hvert kurs. For å opprettholde undervisningskvaliteten kan en professor bare levere ett kurs.

Trinn 1) Enhetsidentifikasjon

Vi har tre enheter:

Student
Kurs
Professor

Trinn 2) Relasjonsidentifikasjon

Vi har følgende to forhold:

Studenten er tildelt et kurs
Professoren leverer et kurs

Trinn 3) Kardinalitetsidentifikasjon

Fra problemformuleringen vet vi at:

En student kan tildeles flere kurs
En professor kan bare levere en kurs

Trinn 4) Identifiser attributter

Du må studere filene, skjemaene, rapportene og dataene som for tiden vedlikeholdes av organisasjonen for å identifisere attributter. Du kan også gjennomføre intervjuer med ulike interessenter for å identifisere enheter. I utgangspunktet er det viktig å identifisere attributtene uten å tilordne dem til en bestemt enhet.

Når du har en liste over attributter, må du tilordne dem til de identifiserte enhetene. Sørg for at et attributt skal pares med nøyaktig én enhet. Hvis du mener at et attributt skal tilhøre mer enn én enhet, kan du bruke en modifikator for å gjøre det unikt.

Når kartleggingen er ferdig, identifiserer du primærnøklene. Hvis en unik nøkkel ikke er lett tilgjengelig, oppretter du en.

Entity	Primærnøkkel	Egenskap
Student	Student ID	Studentnavn
Professor	Ansatt ID	Professornavn
Kurs	Course_ID	Kursnavn

For Kursenhet kan attributter være Varighet, Studiepoeng, Oppgaver osv. For enkelhets skyld har vi bare vurdert ett attributt.

Trinn 5) Opprett ERD-en

En mer moderne representasjon av et eksempel på et enhetsrelasjonsdiagram:

Beste praksis for effektive ER-diagrammer

Følg disse retningslinjene for å lage tydelige, vedlikeholdbare og effektive ER-diagrammer:

Eliminer redundans: Fjern dupliserte enheter, attributter eller relasjoner.
Bruk tydelige navnekonvensjoner: Bruk konsistente, beskrivende navn. Unngå forkortelser.
Valider mot krav: Sørg for at diagrammet støtter alle behov for datalagring.
Hold det enkelt: Lag flere diagrammer på forskjellige nivåer i stedet for ett rotete diagram.
Bruk farge sparsomt: Bruk farger konsekvent for å fremheve kategorier.
Dokumentforutsetninger: Ta med notater som forklarer antagelser om forretningsregler.
Revmed interessenter: La forretningsbrukere og det tekniske teamet gjennomgå diagrammet.
Versjonskontroll: Vedlikehold versjoner etter hvert som designet utvikler seg.

ER-diagrammer kontra UML-klassediagrammer

Selv om både ER-diagrammer og UML-klassediagrammer brukes til datamodellering, tjener de forskjellige formål og kontekster. Å forstå når man skal bruke hver av dem er viktig for effektiv systemdesign.

Aspekt	ER-diagram	UML klassediagram
Hovedformål	Databasedesign	Programvare-/objektdesign
Fokus	Data og relasjoner	Objekter, metoder og atferd
Metoder/Operasjoner	Støttes ikke	Fullt støttet
Arv	Begrenset (kun i EER)	Full støtte
Bransjebruk	Databaseadministratorer, dataanalytikere	Programvareutviklere, arkitekter

Spørsmål og svar

Et ER-diagram representerer visuelt strukturen til en database ved å definere enheter, deres attributter og relasjoner. Det hjelper designere, utviklere og interessenter med å sikre konsistens, integritet og effektivitet i datamodellering før implementeringen starter.

De to hovedtypene er konseptuelle ER-diagrammer (som skisserer relasjoner og enheter på overordnet nivå uten implementeringsdetaljer) og fysiske ER-diagrammer (som beskriver faktiske databasestrukturer, datatyper, nøkler og begrensninger for implementering).

Slik lager du et ER-diagram: (1) Identifiser nøkkelenheter fra kravene dine, (2) Bestem relasjoner mellom enheter, (3) Tildel kardinaliteter basert på forretningsregler, (4) Definer attributter for hver enhet, (5) Identifiser primærnøkler, og (6) Tegn diagrammet med passende notasjon.

Valget avhenger av konteksten. Chen-notasjon er best for konseptuell design og akademiske sammenhenger, mens kråkefotnotasjon er å foretrekke for logisk/fysisk design i industrielle sammenhenger. De fleste moderne databaseverktøy støtter kråkefotnotasjon.

En sterk entitet har sin egen primærnøkkel og kan eksistere uavhengig. En svak entitet mangler en primærnøkkel og er avhengig av en sterk entitet for identifikasjon, ved å bruke en kombinasjon av eierens primærnøkkel og sin egen delnøkkel (diskriminator).

I skybaserte DBMS-plattformer veileder ER-diagrammer automatisert klargjøring, skalering og spørreorkestrering. De gjør det mulig for AI-drevne verktøy å justere datastrukturer med arbeidsbelastningsforutsigelser og brukeretterspørsel i sanntid, noe som forbedrer systemeffektiviteten.

Selv om generativ AI kan foreslå innledende ER-modeller fra forretningskrav eller eksisterende datasett, er menneskelig tilsyn fortsatt avgjørende for å validere relasjoner, håndheve begrensninger, sikre logisk sammenheng og verifisere samsvar med faktiske forretningsregler i produksjonssystemer.

Mange-til-mange-relasjoner kan ikke implementeres direkte i relasjonsdatabaser. Du må opprette en assosiativ enhet (koblingstabell) som deler M:N-relasjonen i to 1:N-relasjoner. Denne koblingstabellen inneholder fremmednøkler som refererer til begge de opprinnelige enhetene.

Entity Relationship (ER) Diagram Model med DBMS Eksempel

Hva er et ER-diagram?