ER → relasjonsskjema

Diagram til tabeller

Et godt ER-diagram inneholder all informasjonen vi trenger for å lage et relasjonsskjema. Reglene er mekaniske: gjør X med entiteter, gjør Y med relasjoner, gjør Z med svake entiteter. Du skal ikke tenke kreativt under oversettelsen — den kreative delen var å lage diagrammet i første runde.

Den korte oppskriften

1. Hver sterk entitet → tabell.
2. Hver svak entitet → tabell med sammensatt nøkkel som arves fra eieren.
3. Hver fler-verdig attributt → egen tabell.
4. Hver relasjon → fremmednøkkel-kolonne (1:1, 1:N) eller egen tabell (N:M).
5. ISA-hierarkier → en av tre strategier (vi kommer til det).

Entitet blir tabell

For en sterk entitet E med atomære attributter a₁, a₂, …, aₙ der a₁ er nøkkel:

CREATE TABLE E (
  a1 PRIMARY KEY,
  a2 …,
  …
  an …
);

Eksempel: Student med (studnr, navn, fødselsdato) blir:

CREATE TABLE Student (
  studnr        INT PRIMARY KEY,
  navn          VARCHAR(100) NOT NULL,
  fodselsdato   DATE
);

Når et attributt ikke er atomært

Sammensatt attributt → flate kolonner

adresse(gate, postnr, sted) blir til tre flate kolonner:

CREATE TABLE Person (
  pnr            CHAR(11) PRIMARY KEY,
  adresse_gate   VARCHAR(120),
  adresse_postnr CHAR(4),
  adresse_sted   VARCHAR(60)
);

Fler-verdig attributt → egen tabell

Et attributt som tlf-numre kan ikke representeres som én kolonne (det ville bryte 1NF — atomaritet). Vi lager en egen tabell der nøkkelen er sammensatt av eier-entitetens nøkkel og attributtverdien:

CREATE TABLE Person_tlf (
  pnr      CHAR(11),
  tlf      VARCHAR(20),
  PRIMARY KEY (pnr, tlf),
  FOREIGN KEY (pnr) REFERENCES Person(pnr) ON DELETE CASCADE
);

Relasjon → kolonne eller tabell

Beslutningsregelen

• 1:1 — fremmednøkkel i én av tabellene. Velg den siden med total deltakelse (unngår nullverdier).
• 1:N — fremmednøkkel på N-siden. Den ene siden av relasjonen får en kolonne som peker til den andre.
• N:M — egen tabell med to fremmednøkler som sammen utgjør primærnøkkelen.

1:N-eksempel: Avdeling har Ansatte

Ansatt-tabellen får en fremmednøkkel avd_id til Avdeling:

CREATE TABLE Ansatt (
  ansattnr  INT PRIMARY KEY,
  navn      VARCHAR(80),
  avd_id    INT NOT NULL,            -- total deltakelse
  FOREIGN KEY (avd_id) REFERENCES Avdeling(avd_id)
);

Identitet arves

Svake entiteter blir egne tabeller, men den primære nøkkelen er sammensatt: eierens nøkkel + diskriminatoren. Eierens nøkkel er samtidig fremmednøkkel.

CREATE TABLE Ordrelinje (
  ordrenr   INT,
  linjenr   INT,
  vare_id   INT NOT NULL,
  antall    INT NOT NULL,
  PRIMARY KEY (ordrenr, linjenr),
  FOREIGN KEY (ordrenr) REFERENCES Ordre(ordrenr) ON DELETE CASCADE,
  FOREIGN KEY (vare_id) REFERENCES Vare(vare_id)
);

Tre alternativer for spesialisering

Det finnes ikke ett riktig svar — strategi velges ut fra hvor mange unike attributter subklassene har, og hvilke spørringer som er vanlige.

Universitet → tabeller, helt

La oss kjøre gjennom et lite, men realistisk eksempel. Krav:

• En Avdeling har et navn (unikt) og en bygning. Avdelingen kan eksistere uten ansatte.
• En Lærer jobber i nøyaktig én avdeling. Lærere har lønn, navn, ansattnummer.
• Hver lærer kan ha 0 eller flere telefonnumre.
• Lærere underviser Emner. Et emne kan undervises av flere lærere; en lærer kan undervise flere emner. Per (lærer, emne)-par registreres et semester.
• Pårørende til en lærer er en svak entitet. Identifiseres ved (lærer, navn). Vi lagrer relasjonstype.

Resulterende skjema

CREATE TABLE Avdeling (
  avd_navn  VARCHAR(60) PRIMARY KEY,
  bygning   VARCHAR(40)
);

CREATE TABLE Larer (
  ansattnr  INT PRIMARY KEY,
  navn      VARCHAR(80) NOT NULL,
  lonn      DECIMAL(10,2),
  avd_navn  VARCHAR(60) NOT NULL,        -- total deltakelse
  FOREIGN KEY (avd_navn) REFERENCES Avdeling(avd_navn)
);

CREATE TABLE Larer_tlf (                  -- fler-verdig attributt
  ansattnr  INT,
  tlf       VARCHAR(20),
  PRIMARY KEY (ansattnr, tlf),
  FOREIGN KEY (ansattnr) REFERENCES Larer(ansattnr) ON DELETE CASCADE
);

CREATE TABLE Emne (
  emnekode  CHAR(7) PRIMARY KEY,
  tittel    VARCHAR(100)
);

CREATE TABLE Underviser (                  -- N:M-relasjon med attributt
  ansattnr  INT,
  emnekode  CHAR(7),
  semester  CHAR(5),                       -- 'V2026' f.eks.
  PRIMARY KEY (ansattnr, emnekode, semester),
  FOREIGN KEY (ansattnr) REFERENCES Larer(ansattnr),
  FOREIGN KEY (emnekode) REFERENCES Emne(emnekode)
);

CREATE TABLE Parorende (                   -- svak entitet
  ansattnr  INT,
  pnavn     VARCHAR(80),
  relasjon  VARCHAR(30),
  PRIMARY KEY (ansattnr, pnavn),
  FOREIGN KEY (ansattnr) REFERENCES Larer(ansattnr) ON DELETE CASCADE
);

Tre ansikter til anomali

Selv etter mekanisk reduksjon kan skjemaet ha problemer — typisk fordi ER-diagrammet har slått sammen entiteter som burde vært skilt. Tenk deg dette dårlige skjemaet:

InDep(id, navn, lonn, avd_navn, bygning, budsjett)

Vi har slått sammen Lærer og Avdeling. Hver rad gjentar bygning og budsjett for hver lærer i samme avdeling. La oss se hva som skjer:

Dekomponert versjon

Mekanisk diagnose

Anomalier er ikke tilfeldigheter. De er symptomer på spesifikke mønstre i avhengighetene mellom attributtene. Hvis vi kan beskrive avhengighetene formelt, kan vi bygge en algoritme som oppdager problemene før dataen kommer inn — og som forteller oss hvilken dekomponering som løser dem.

Det formelle språket heter funksjonelle avhengigheter (FD). En FD X → Y sier «hvis du vet X, kan du regne ut Y». I InDep-eksempelet:

• id → navn, lonn, avd_navn — lærer-id bestemmer alt om læreren
• avd_navn → bygning, budsjett — avdelingsnavnet bestemmer alt om avdelingen

Når den andre FD-en holder uten at avd_navn er supernøkkel for hele tabellen, har vi per definisjon et BCNF-brudd. Algoritmen for å splitte er mekanisk: «for hver FD α → β der α ikke er supernøkkel, splitt i (α ∪ β) og (R − (β − α))».