Free Press

Entity Relationship (ER)-datamodellen har eksisteret i over 35 år. Den er velegnet til datamodellering til brug med databaser, fordi den er forholdsvis abstrakt og er let at diskutere og forklare. ER-modeller kan let oversættes til relationer. ER-modeller, også kaldet et ER-skema, repræsenteres ved hjælp af ER-diagrammer.

ER-modellering er baseret på to begreber:

• Entiteter, defineret som tabeller, der indeholder specifikke oplysninger (data)
• Relationer, defineret som associationerne eller interaktionerne mellem entiteter

Her er et eksempel på, hvordan disse to begreber kan kombineres i en ER-datamodel: Prof. Ba (entitet) underviser (relation) i kurset Databasesystemer (entitet).

Resten af dette kapitel vil vi bruge en eksempeldatabase kaldet COMPANY-databasen til at illustrere begreberne i ER-modellen. Denne database indeholder oplysninger om medarbejdere, afdelinger og projekter. Vigtige punkter at bemærke er bl.a.:

• Der er flere afdelinger i virksomheden. Hver afdeling har en unik identifikation, et navn, kontorets placering og en bestemt medarbejder, som leder afdelingen.
• En afdeling styrer en række projekter, som hver især har et unikt navn, et unikt nummer og et budget.
• Hver medarbejder har et navn, et identifikationsnummer, en adresse, en løn og en fødselsdato. En medarbejder er tilknyttet én afdeling, men kan deltage i flere projekter. Vi har brug for at registrere medarbejderens startdato i hvert projekt. Vi har også brug for at kende den direkte chef for hver medarbejder.
• Vi ønsker at holde styr på de pårørende for hver medarbejder. Hver afhængig person har et navn, en fødselsdato og en relation til medarbejderen.

Entitet, Entitetsæt og Entitetstype

En entitet er et objekt i den virkelige verden med en selvstændig eksistens, der kan adskilles fra andre objekter. En entitet kan være

Entiteter kan klassificeres på baggrund af deres styrke. En enhed betragtes som svag, hvis dens tabeller er afhængige af eksistensen

• Det vil sige, at den ikke kan eksistere uden en relation til en anden enhed
• Den primære nøgle er afledt af den primære nøgle i den overordnede enhed
  • Tabellen Ægtefælle i databasen COMPANY er en svag enhed, fordi dens primære nøgle er afhængig af tabellen Medarbejder. Uden en tilsvarende medarbejderpost ville ægtefælleposten ikke eksistere.

En entitet betragtes som stærk, hvis den kan eksistere adskilt fra alle dens relaterede entiteter.

• Kerner er stærke entiteter.
• En tabel uden en fremmed nøgle eller en tabel, der indeholder en fremmed nøgle, som kan indeholde nulls, er en stærk enhed

Et andet begreb, som man skal kende, er entitetstype, som definerer en samling af lignende enheder.

Et enhedssæt er en samling af enheder af en entitetstype på et bestemt tidspunkt. I et entitetsrelationsdiagram (ERD) er en enhedstype repræsenteret ved et navn i en boks. I figur 8.1 er entitetstypen f.eks. EMPLOYEE.

Eksistensafhængighed

En entitets eksistens er afhængig af eksistensen af den relaterede entitet. Den er eksistensafhængig, hvis den har en obligatorisk fremmednøgle (dvs. en fremmednøgleattribut, der ikke kan være nul). I databasen COMPANY er en entitet Ægtefælle f.eks. eksistensafhængig af entiteten Medarbejder.

Styper af enheder

Du bør også være bekendt med forskellige typer af enheder, herunder uafhængige enheder, afhængige enheder og karakteristiske enheder. Disse er beskrevet nedenfor.

Uafhængige enheder

Uafhængige enheder, også kaldet kerner, er databasens rygrad. De er det, som andre tabeller er baseret på. Kerner har følgende egenskaber:

• De er byggestenene i en database.
• Primærnøglen kan være simpel eller sammensat.
• Primærnøglen er ikke en fremmednøgle.
• De er ikke afhængige af en anden entitet for deres eksistens.

Hvis vi henviser tilbage til vores database COMPANY, omfatter eksempler på en uafhængig enhed kundestabellen, medarbejdertabellen eller produkttabellen.

Afhængige enheder

Afhængige enheder, også kaldet afledte enheder, er afhængige af andre tabeller for deres betydning. Disse entiteter har følgende egenskaber:

• Dependente entiteter bruges til at forbinde to kerner sammen.
• De siges at være eksistensafhængige af to eller flere tabeller.
• Mange til mange-relationer bliver til associerende tabeller med mindst to fremmednøgler.
• De kan indeholde andre attributter.
• Fremdnøglen identificerer hver associeret tabel.
• Der er tre muligheder for primærnøglen:
  1. Brug en sammensætning af fremmednøgler for tilknyttede tabeller, hvis de er unikke
  2. Brug en sammensætning af fremmednøgler og en kvalificerende kolonne
  3. Opret en ny simpel primærnøgle

Karakteristiske entiteter

Karakteristiske entiteter giver flere oplysninger om en anden tabel. Disse entiteter har følgende karakteristika:

• De repræsenterer attributter med flere værdier.
• De beskriver andre entiteter.
• De har typisk et en-til-mange-forhold.
• Fremdnøglen bruges til yderligere at identificere den karakteriserede tabel.
• Mulighederne for primærnøglen er som følger:
  1. Brug en sammensætning af en fremmednøgle plus en kvalificerende kolonne
  2. Opret en ny simpel primærnøgle. I databasen COMPANY kan disse omfatte:
     • Medarbejder (EID, Navn, Adresse, Alder, Løn) – EID er den simple primærnøgle.
     • MedarbejderTelefon (EID, Telefon) – EID er en del af en sammensat primærnøgle. Her er EID også en fremmednøgle.

Attributter

Hver enhed beskrives af et sæt attributter (f.eks. Medarbejder = (Navn, Adresse, Fødselsdato (Alder), Løn).

Hver attribut har et navn og er knyttet til en enhed og et domæne af lovlige værdier. Oplysningerne om attributdomæne præsenteres dog ikke i ERD’et.

I entitetsrelationsdiagrammet, vist i figur 8.2, er hver attribut repræsenteret af en oval med et navn indeni.

Typer af attributter

Der er nogle få typer af attributter, som du skal være bekendt med. Nogle af disse skal forblive som de er, men nogle af dem skal justeres for at lette repræsentationen i den relationelle model. I dette første afsnit vil vi gennemgå typerne af attributter. Senere vil vi diskutere at rette attributterne til, så de passer korrekt ind i den relationelle model.

Enkle attributter

Enkle attributter er dem, der er hentet fra de atomare værdidomæner; de kaldes også enkeltværdiattributter. I COMPANY-databasen ville et eksempel herpå være: Navn = {John} ; Alder = {23}

Kompositattributter

Kompositattributter er attributter, der består af et hierarki af attributter. Hvis vi bruger vores databaseeksempel, som er vist i figur 8.3, kan adresse bestå af nummer, gade og forstad. Så det ville blive skrevet som → Adresse = {59 + ‘Meek Street’ + ‘Kingsford’}

Multivalued attributes

Multivalued attributes er attributter, der har et sæt af værdier for hver enhed. Et eksempel på en multivalued-attribut fra COMPANY-databasen, som ses i figur 8.4, er en medarbejders grader: BSc, MIT, PhD.

Afledte attributter

Afledte attributter er attributter, der indeholder værdier, der er beregnet ud fra andre attributter. Et eksempel på dette kan ses i figur 8.5. Alder kan afledes af attributten Fødselsdato. I denne situation kaldes Birthdate for en gemt attribut, som er fysisk gemt i databasen.

Nøgler

En vigtig begrænsning på en entitet er nøglen. Nøglen er en attribut eller en gruppe af attributter, hvis værdier kan bruges til entydigt at identificere en individuel enhed i et enhedssæt.

Typer af nøgler

Der findes flere typer af nøgler. De er beskrevet nedenfor.

Kandidatnøgle

En kandidatnøgle er en simpel eller sammensat nøgle, der er unik og minimal. Den er unik, fordi ingen to rækker i en tabel kan have den samme værdi på noget tidspunkt. Den er minimal, fordi hver kolonne er nødvendig for at opnå entydighed.

Fra vores eksempel med databasen COMPANY, hvis entiteten er Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID), er de mulige kandidatnøgler følgende:

• EID, SIN
• Førnavn og efternavn – under forudsætning af, at der ikke er andre i virksomheden med samme navn
• Navn og DepartmentID – under forudsætning af, at to personer med samme efternavn ikke arbejder i samme afdeling

Sammensat nøgle

En sammensat nøgle er sammensat af to eller flere attributter, men den skal være minimal.

Hvis man bruger eksemplet fra afsnittet om kandidatnøgler, er mulige sammensatte nøgler følgende:

• Førnavn og efternavn – under forudsætning af, at der ikke er andre i virksomheden med samme navn
• Efternavn og afdelings-id – under forudsætning af, at to personer med samme efternavn ikke arbejder i samme afdeling

Primær nøgle

Primærnøglen er en kandidatnøgle, der udvælges af databasedesigneren til at blive brugt som identifikationsmekanisme for hele enhedssættet. Den skal entydigt identificere tupler i en tabel og må ikke være nul. Den primære nøgle angives i ER-modellen ved at understrege attributten.

• En kandidatnøgle vælges af designeren til entydigt at identificere tupler i en tabel. Den må ikke være nul.
• En nøgle vælges af databasedesigneren til at blive brugt som en identifikationsmekanisme for hele enhedssættet. Dette kaldes den primære nøgle. Denne nøgle angives ved at understregning af attributten i ER-modellen.

I følgende eksempel er EID den primære nøgle:

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

Secondary key

En sekundær nøgle er en attribut, der udelukkende bruges til hentning af oplysninger (kan være sammensat), f.eks:

Alternativ nøgle

Alternative nøgler er alle kandidatnøgler, der ikke er valgt som primærnøgle.

Fremme nøgle

En fremmed nøgle (FK) er en attribut i en tabel, der henviser til primærnøglen i en anden tabel ELLER den kan være nul. Både fremmednøgler og primærnøgler skal være af samme datatype.

I nedenstående eksempel på databasen COMPANY er DepartmentID fremmednøglen:

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

Nulls

En null er et særligt symbol, uafhængigt af datatype, som betyder enten ukendt eller uanvendelig. Det betyder ikke nul eller blank. Funktioner af null omfatter:

• Ingen dataindtastning
• Ingen tilladt i den primære nøgle
• Bør undgås i andre attributter
• Kan repræsentere
  • En ukendt attributværdi
  • En kendt, men manglende, attributværdi
  • En “ikke relevant”-tilstand
• Kan skabe problemer, når funktioner som COUNT, AVERAGE og SUM anvendes
• Kan skabe logiske problemer, når relationstabeller er forbundet

BEMÆRK: Resultatet af en sammenligningsoperation er nul, når et af argumenterne er nul. Resultatet af en aritmetisk operation er null, når et af argumenterne er null (undtagen funktioner, der ignorerer nulls).

Eksempel på, hvordan null kan bruges

Brug tabellen Løn (Salary_tbl) i figur 8.6 for at følge et eksempel på, hvordan null kan bruges.

Til at begynde med skal du finde alle medarbejdere (emp#) i Salg (under kolonnen jobName), hvis løn plus provision er større end 30.000.

• SELECT emp# FROM Salary_tbl
• WHERE jobName = Sales AND
• (provision + løn) > 30.000 -> E10 og E12

Dette resultat omfatter ikke E13 på grund af nulværdien i provisionskolonnen. For at sikre, at rækken med nulværdien er medtaget, skal vi se på de enkelte felter. Ved at tilføje provision og løn for medarbejder E13 vil resultatet være en nulværdi. Løsningen er vist nedenfor.

Relationer

Relationer er limen, der holder tabellerne sammen. De bruges til at forbinde relaterede oplysninger mellem tabellerne.

Relationsforholdets styrke er baseret på, hvordan primærnøglen for en relateret enhed er defineret. Der er tale om et svagt eller ikke-identificerende forhold, hvis primærnøglen for den relaterede entitet ikke indeholder en primærnøglekomponent for den overordnede entitet. Eksempler på virksomhedsdatabaser omfatter:

• Kunde(CustID, CustName)
• Order(OrderID, CustID, Date)

Der er tale om et stærkt eller identificerende forhold, når den relaterede enheds primære nøgle indeholder den primære nøglekomponent i den overordnede enhed. Eksempler omfatter:

• Kursus(CrsCode, DeptCode, Beskrivelse)
• Klasse(CrsCode, Afsnit, Klassetid…)

Typer af relationer

Nedenfor er der beskrivelser af de forskellige typer af relationer.

En til mange (1:M)-relation

En en til mange (1:M)-relation bør være normen i ethvert relationelt databasedesign og findes i alle relationelle databasemiljøer. En afdeling har f.eks. mange medarbejdere. Figur 8.7 viser relationen mellem en af disse medarbejdere og afdelingen.

En til en (1:1)-relation

En en til en (1:1)-relation er en relation mellem en enhed og kun én anden enhed og omvendt. Den bør være sjælden i ethvert design af en relationel database. Faktisk kan det indikere, at to enheder faktisk hører til i samme tabel.

Et eksempel fra databasen COMPANY er, at en medarbejder er knyttet til en ægtefælle, og en ægtefælle er knyttet til en medarbejder.

Mange til mange (M:N)-relationer

For en mange til mange-relation skal du overveje følgende punkter:

• Den kan ikke implementeres som sådan i den relationelle model.
• Den kan ændres til to 1:M-relationer.
• Det kan implementeres ved at opdele for at producere et sæt 1:M-relationer.
• Det indebærer implementering af en sammensat enhed.
• Skaber to eller flere 1:M-relationer.
• Den sammensatte enhedstabel skal som minimum indeholde primærnøglerne i de oprindelige tabeller.
• Den forbindende tabel indeholder flere forekomster af de fremmede nøgleværdier.
• Der kan tildeles yderligere attributter efter behov.
• Det kan undgå problemer, der er forbundet med et M:N-forhold, ved at oprette en sammensat enhed eller en broenhed. En medarbejder kan f.eks. arbejde på mange projekter ELLER et projekt kan have mange medarbejdere, der arbejder på det, afhængigt af forretningsreglerne. Eller en elev kan have mange klasser, og en klasse kan indeholde mange elever.

Figur 8.8 viser et andet andet andet aspekt af M:N-relationen, hvor en medarbejder har forskellige startdatoer for forskellige projekter. Derfor har vi brug for en JOIN-tabelle, der indeholder EID, kode og startdato.

Eksempel på kortlægning af en M:N binær relationstype

• For hver M:N binær relation skal du identificere to relationer.
• A og B repræsenterer to entitetstyper, der deltager i R.
• Opret en ny relation S for at repræsentere R.
• S skal indeholde PK’erne for A og B. Disse kan tilsammen være PK’en i tabellen S ELLER disse kan sammen med en anden simpel attribut i den nye tabel R være PK’en.
• Kombinationen af primærnøglerne (A og B) vil udgøre primærnøglen i S.

Unær relation (rekursiv)

En unær relation, også kaldet rekursiv, er en relation, hvor der eksisterer en relation mellem forekomster af det samme enhedssæt. I denne relation er primær- og fremmednøglerne de samme, men de repræsenterer to enheder med forskellige roller. Se et eksempel i figur 8.9.

For nogle entiteter i en unær relation kan der oprettes en separat kolonne, der henviser til primærnøglen i samme enhedssæt.

Ternære relationer

En ternær relation er en relationstype, der involverer mange til mange-relationer mellem tre tabeller.

Referer til Figur 8.10 for et eksempel på kortlægning af en ternær relationstype. Bemærk, at n-ary betyder flere tabeller i en relation. (Husk, N = mange.)

• For hver n-ary (> 2)-relation skal du oprette en ny relation for at repræsentere relationen.
• Primærnøglen for den nye relation er en kombination af primærnøglerne for de deltagende entiteter, der har den N (mange) side.
• I de fleste tilfælde af en n-ary relation har alle de deltagende entiteter en mange-side.

Attribution

Dette kapitel i Database Design (inklusive billeder, medmindre andet er angivet) er en afledt kopi af Data Modeling Using Entity-Relationship Model af Nguyen Kim Anh licenseret under Creative Commons Attribution License 3.0 license

Det følgende materiale er skrevet af Adrienne Watt:

1. Nulls afsnit og eksempel
2. Nøglebegreber
3. Øvelser