Vi har to overordnede designkriterier, der frem for alle andre overvejelser skal genfindes i de datamodeller vi udarbejder. Overtrædelse af disse grundlove bringer os på kant med det, at databasen skal være et sandt udsagn om en virksomheds virkelighed. Grunden til at disse designkriterier nævnes allerede nu, er at hvis de ikke indgår i overvejelserne allerede på modelleringstidspunktet, risikerer vi senere at realisere databasen ud fra en defekt model. Der findes værktøjer, der kan afsløre dette, men da projekter i virkelighedens verden af og til har fart på, er det ikke altid disse værktøjer når at komme i anvendelse. En anden grund kan være, at designeren er overbevist om modellens kvalitet og derfor ikke på grund af hastværk, men på grund af selvtilstrækkelighed glemmer at kvalitetssikre. Det gælder selvfølgelig ikke os, men nogle andre. Vi vil derfor alligevel kaste et kort blik på de to problemområder.
Se på følgende tabel læst og udskrevet fra en databasetabel:
select * from t2; +------------------+--------+------------+----------------+ | fag | laerer | uddannelse | antallektioner | +------------------+--------+------------+----------------+ | Interaktion | Niels | MDU | 81 | | Databaser | Niels | MDU | NULL | | Design | Bror | MDU | NULL | | Kommunikation | Bror | NULL | 54 | | Multimedier | Bror | NULL | NULL | | Interaktion 2 | NULL | MDU | 81 | | Interaktion 3 | NULL | NULL | NULL | | Interaktion Afsl | NULL | NULL | NULL | +------------------+--------+------------+----------------+ 8 rows in set (0.00 sec)
Null er ingenting. Dett kommer til udtryk som mangel på data. Hvor er så problemet herover? Hvis der er et problem, hvorfor er det et problem? Er nulls altid et problem?
Som et hint vises her et antal optællinger af antal rækker i den pågældende tabel:
select count(fag) from t2; +------------+ | count(fag) | +------------+ | 8 | +------------+ 1 row in set (0.00 sec)
select count(laerer) from t2; +---------------+ | count(laerer) | +---------------+ | 5 | +---------------+ 1 row in set (0.00 sec)
select count(uddannelse) from t2; +-------------------+ | count(uddannelse) | +-------------------+ | 4 | +-------------------+ 1 row in set (0.00 sec)
select count(antallektioner) from t2; +-----------------------+ | count(antallektioner) | +-----------------------+ | 3 | +-----------------------+ 1 row in set (0.00 sec)
Nu ved vi hvor mange der er! Hvad er så det gennemsnitlige antal lektioner per fag:
select avg(antallektioner) from t2; +---------------------+ | avg(antallektioner) | +---------------------+ | 72.0000 | +---------------------+ 1 row in set (0.01 sec)
Det må vi lige se per uddannelse
select uddannelse, avg(antallektioner) from t2 group by uddannelse; +------------+---------------------+ | uddannelse | avg(antallektioner) | +------------+---------------------+ | NULL | 54.0000 | | MDU | 81.0000 | +------------+---------------------+ 2 rows in set (0.00 sec)
Hm? Sandt udsagn?
Se på følgende tabel læst og udskrevet fra en databasetabel:
select klasse, studid, fag, karakter, semester, laerer, stilling from t1 order by studid, semester; +--------+--------+-------------+----------+----------+--------+--------------+ | klasse | studid | fag | karakter | semester | laerer | stilling | +--------+--------+-------------+----------+----------+--------+--------------+ | 07B | 1 | Interaktion | 4 | 1 | Niels | Underviser | | 07B | 1 | Interaktion | 4 | 2 | Niels | Handelsoverl | | 07B | 1 | Interaktion | 4 | 3 | Niels | Lektor | | 07B | 21 | Interaktion | 4 | 1 | Niels | Lektor | | 07B | 21 | Interaktion | 4 | 2 | Niels | Lektor | | 07B | 21 | Interaktion | 4 | 3 | Niels | Lektor | | 07B | 22 | Interaktion | 2 | 1 | Niels | Lektor | | 07B | 22 | Interaktion | 2 | 2 | Niels | Lektor | | 07B | 22 | Interaktion | 2 | 3 | Niels | Lektor | | 07B | 23 | Interaktion | 7 | 1 | Niels | Lektor | | 07B | 23 | Interaktion | 2 | 2 | Niels | Underviser | | 07B | 23 | Interaktion | -3 | 3 | Niels | Lektor | +--------+--------+-------------+----------+----------+--------+--------------+ 12 rows in set (0.01 sec)
Redundans er her overflødig gentagelse af data. Hvor er så problemet herover? Hvis der er et problem, hvorfor er det et problem? Er gentagelse af data altid et problem?
Entity Relationship Modelling, i daglig tale ER-modellen, bruges til det vi kalder begrebsmæssig datamodelleering. Den række lange ord dækker over et ønske og behov for at forklare hvilke data et system, eller systemudviklingsønske, omfatter. Vi skal forstå hvad skal indgå, og vhordan de indbyrdes sammenhænge er. Samtidig er vi interesserede i, at der overordnet set er er styr på det. Dette betyder igen, at vi ved hvor vores data er, hvad de betyder for os, hvad de betyder for hinanden, og at vi ikke er i tvivl om, at det vi ser er sandheden, so help me god!.
Entiteter er specifikke ting, fysiske eller begrebsmæssige, der indgår i et kommende system, og som vi derfor må fastholde noget viden om. Relationer er associationer mellem entiteter. Sådan!
Relationer er associationer mellem entiteter. I princippet mellem 1 - n entitetsklasser.
Attributter er de egenskaber ved entiteter og relationer, som vi vil vide noget om i betydningen bevare data omkring. I en vis forstand kan de sammenlignes med variabler i programmer, idet de også her tillægges værdier. Det er netop værdier som vi her skriver ned i selve databasen.
