// Entiteter, attributter og relasjoner
Et ER-diagram beskriver datastrukturen i et system. De tre grunnelementene:
- Entitet – et objekt eller konsept vi lagrer data om. F.eks. STUDENT, KUR, BOMSTASJON
- Attributt – en egenskap ved en entitet. F.eks. navn, dato, belop
- Relasjon – en sammenheng mellom to entiteter. F.eks. STUDENT tar KURS
På eksamen: Du vil se et ferdig ER-diagram i UML-notasjon. Du skal ikke tegne – du skal lese og oversette til relasjonell form.
// Multiplisitet
Multiplisitet angir hvor mange forekomster av en entitet som kan delta i en relasjon:
- 1..1 – nøyaktig én (obligatorisk)
- 0..1 – null eller én (valgfri, maks én)
- 1..* – én eller flere (obligatorisk, ubegrenset)
- 0..* – null eller flere (valgfri, ubegrenset)
Huskeregel: Det første tallet er minimum, det andre er maksimum. Stjernen (*) betyr «mange» (ubegrenset).
Eksempel fra v25-eksamen
SØKER (0..*) ←→ INTERVJU (1..1) UTLYSNING betyr: En søker kan ha null eller mange intervjuer. Hvert intervju tilhører nøyaktig én utlysning.
// Oversettelse ER → Relasjonsmodell
Relasjonsmodellen noteres slik i NTNU-kurset:
TABELLNAVN(primærnøkkel, attributt1, attributt2, fremmednøkkel*)
Understreking = primærnøkkel | * etter navn = fremmednøkkel
1-til-mange (1..* eller 0..*)
FK legges i tabellen på «mange»-siden.
AVDELING(avd_id, avd_navn)
ANSATT(ansatt_id, navn, avd_id*)
Mange-til-mange (*..*)
Lag en koblingstabell med FK til begge tabeller. PK er typisk sammensatt av de to FKene.
STUDENT(student_id, navn)
KURS(kurs_id, kurs_navn)
PÅMELDING(student_id*, kurs_id*, dato)
1-til-1 (1..1 – 1..1)
FK kan legges i hvilken som helst av tabellene – velg den som gir mest mening.
PERSON(person_id, navn)
PASS(pass_id, utløpsdato, person_id*)
Husk: Entitetsintegritet – PK kan aldri være NULL. Referanseintegritet – en FK-verdi må finnes som PK i den andre tabellen (eller være NULL hvis relasjonen er valgfri).
// Svak entitet
En svak entitet kan ikke identifiseres unikt uten sin eier-entitet. Den har en delvis nøkkel som er unik kun innenfor eieren.
BESTILLING(bestilling_id, dato, kunde_id*)
BESTILLINGSLINJE(bestilling_id*, linje_nr, produkt_id*, antall)
Her er BESTILLINGSLINJE svak – linje_nr er kun unik innenfor én bestilling.
// EER – Spesialisering og generalisering
Eksamenrelevant
Spesialisering (top-down): En superklasse deles inn i mer spesifikke subklasser som arver superklassens attributter og kan ha egne.
Generalisering (bottom-up): Felles egenskaper fra flere entiteter løftes opp til en felles superklasse.
Resultatet i diagrammet er det samme – en hierarkisk struktur.
Oversettelse til relmod
Standardmetoden (og den NTNU bruker):
- Superklassen får egen tabell med PK og fellesattributter
- Hver subklasse får egen tabell med sine unike attributter + FK til superklassens PK
-- Superklasse
ANSATT(ansatt_id, navn, epost, ansatt_dato)
-- Subklasser
FAST_ANSATT(ansatt_id*, stillingsprosent, pensjonskasse)
KONSULENT(ansatt_id*, timepris, selskap)
Merk: ansatt_id i subklassene er både PK og FK – det er det som kobler dem til superklassen.
// Eksempel fra eksamen v24 – Bomstasjon
Fra tidligere eksamen
Gitt et ER-diagram med entitetene BOMSTASJON, BOMSELSKAP, PASSERING og KJØRETØY. Slik kan relmod se ut:
BOMSELSKAP(selskap_id, navn, org_nr)
BOMSTASJON(stasjon_id, navn, type, operativ_fra, operativ_til, selskap_id*)
KJØRETØY(reg_nr, kjøretøytype, eier_navn)
PASSERING(pas_id, tidspunkt, belop, stasjon_id*, reg_nr*)
PASSERING er koblingtabell mellom BOMSTASJON og KJØRETØY (M:N), med egne attributter (tidspunkt, belop).
🎯 Øv på ER-spørsmål i quizen →