PRÆSENTATION AF ER-DIAGRAMMER OG NORMALISERING

Transkript

1 PRÆSENTATION AF ER-DIAGRAMMER OG NORMALISERING KIRSTINE ROSENBECK GØEG

2 Tema Titel Materiale 1 IS i sundhedssektoren Patientdatas anvendelighed Lynge et al. 2 Registrering af patientdata Berg. Kap. 2 Waiting for Godot. 3 Relations-databaser Silberschatz Kap 1 ( ) 4 Databaser for klinisk kvalitet Green 5 Modellering af IS Modellering Silberschatz Kap E-R diagrammer Silberschatz Kap 7 ( ) 7 Normalisering Silberschatz Kap 8 ( ) 8 Den gode model 9 Modellering af systemer 10 Dataudtræk og databehandling Udtræk af databaser 11 Modellering med fokus på data-behandling 12 Avancerede forespørgsler i databaser 13 Beslutningsstøtte på baggrund af patientdata 14 Patientdatas tilgængelighed og sikkerhed Silberschatz Kap 3 ( ) Silberschatz Kap 4 ( ) 15 Opsummering og reflektion Resumere kursuslitteraturen

3 Plan for modelleringsdelen 1. Modellering : Basis ER-modellering (Entiteter, relationer, atributter, kardinalitet ) baseret på modellering af apotek, opgave: vitale værdier/ernæringsscreening 2. E-R diagrammer : Flere syntaktiske muligheder i ER-modelering. eksemplificeret ved forskellige kliniske database designs, opgave: vitale værdier/ernæringsscreening 3. Normalisering: Fra ER-diagram til Database scema baseret på modellering af apotek. Opgave:vitale værdier/ernæringsscreening 4. Den gode model : (WS) Modellering af blodbank: studenter præsentationer/anden opsamling de sidste 30min 5. Modellering af systemer: (WS) Fra database til fuldt IT system: Hvilke krav bør man stille til et blodbanksystem? Ændre dette databasen? Eksempel: studenter præsentationer/anden opsamling de sidste 30min

4 Tema Forventet læringsudbytte af læsning af litteraturen og deltagelse i forelæsninger Forventet læringsudbytte af opgaveløsning, gruppediskussioner og workshops IS i sundhedssektoren sundhedssektorens informationsinfrastruktur informationssystemer på sygehuse som fx Elektroniske Patient Journaler, PatientAdministrative Systemer, Parakliniske informationssystemer og kliniske databaser anvendelser af nationale registre i sundhedssektoren analysere informationssystemer i relation til brugsscenarier Modellering af IS modellering af informationssystemer design af relationsdatabaser viden om Database Management Systemer anvende E/R diagrammer og normalisering til modellering af klinisk database Databehandling viden om databasesprog datakommunikation metoder til beslutningsstøtte anvende SQL syntaks og funktioner

5 PRÆSENTÉR ER-DIAGRAMMER Send slides til efter forelæsningen, så skal jeg lægge dem på moodle

6 NORMALISERING Fra tabeller udledt fra ER-diagrammer til tabeller på 3. normalform

7 Forarbejde: Fra ER-model til tabeller (i kogebogsform) Formål: At reducerer ER modellen til en samling af relationelle schemas der udtrykker det samme som ER-modellen Relationelle schemas fra entiteter og relationer i ER-modellen Stærk entitet: Tabel med en kolonne for hver attribut, nøgle som i ER-modellen Svag entitet: Tabel med kolonne for hver attribut samt alle nøgleatributter fra den understøttende stærke entitet. Nøglen er fremmednøglen samt evt. diskriminator Relation: Tabel med en kolonne for hver attribut samt alle nøgleattributter fra de entiteter som relationen binder sammen, denne samling af nøgleatributter udgør desuden tabellens nøgle NB: Egentlige relationstabeller eksisterer kun for mange-til-mange relationer, ellers modelleres relationen som del af den entitet der er mange af. Specielle attributter Composite attributes splittes til simple attributter (hver simpel attribut er en kolonne) Multivalued attributes transformeres til en tabel der indeholder nøglen fra entiteten som attributten beskriver

8 Hvorfor normalisering? Normalisering er en teknik til at forbedre et database-design, i forhold til at undgå: Redundans at noget data forekommer mere end én gang Inkonsistens at noget data er i modstrid med andet data CPR Fornavn Gade Dato Køb Oda Blommevej Sulfamethizol Niels Clara Friisvej Marevan Svend Appelsinlunden Cipralex Oda Æblevej Panodil Niels Clara Friisvej Marevan 8

9 Normalisering Hvis man er en haj til database-design og følger reglerne vil man ofte ende med en normaliseret database uden at tænke over det Normalisering er en slags sundhedstjek af dit database-design 9

10 Normalformer Enhver tabel på 3NF er på NF, osv. 3NF 2NF 1NF

11 Funktionel afhængighed: En forudsætning for at forstå normalformer Hvad er funktionel afhængighed? Hvis to rækker med identiske attributværdier i sættet X altid har identiske attributværdier i sættet A, så er A funtionelt afhængig af X (eller sagt på en anden måde: X bestemmer A funtionelt) Skrives som X A, eksempel cpr navn, vej Nogle afhængigheder der kan findes i database-instanser er ikke konsistente med den virkelige verden. Disse defineres ikke som funktionelle afhængigheder fx vej by Funktionel afhængighed kan elimineres ved at separere de funtionelt afhængige atributter (A) ind i en ny tabel, og bruge X som primær nøgle Når vi forstår hvad funktionel afhængighed er, forstår vi også bedre hvad en primær nøgle er: Primærnøglen bestemmer alle de andre attributter funktionelt Intet subset af primærnøglen bestemmer alle de andre attributter funktionelt (så der subsettet nemlig primærnøglen)

12 Tre grader af normalisering første grad 1.Normalform Tabellen skal have en nøgle Attributter er atomiske: Attributter, der er samlinger af forskelligartede informationer, skal splittes af Alle tabellens rækker skal være lige lange 12

13 Tre grader af normalisering første grad (før) Hvorfor skal en tabel have en nøgle? Hvis en tabel ikke har en nøgle, kan vi ikke vide hvad data egentlig refererer til (tvetydighed) Navn Spansk Fransk Dansk Maria Maria Maria

14 Tre grader af normalisering første grad (før) Elevnavn Fag1 Fag2 Fag3 Fag4 Fag5 Fag6 Fag7 Ib Jensen DA TY IT EN Bo Søgård TY EN IT AF SP Anne Høgh EN DA AF Ib Jensen TY EN SP IT DA AF JU Elevnavn er ikke entydigt Ikke alle poster er lige lange 14

15 Tre grader af normalisering første grad (før) Elevnavn Ib Jensen Bo Søgård Anne Høgh Ib Jensen Fag DA, TY, IT, EN TY, EN, IT, AF, SP EN, DA, AF TY, EN, SP, IT, DA, AF, JU Elevnavn er ikke entydigt Ikke alle poster er lige lange 15

16 Tre grader af normalisering første grad (før) Elevnavn Ib Jensen Bo Søgård Anne Høgh Ib Jensen Fag DA, TY, IT, EN TY, EN, IT, AF, SP EN, DA, AF TY, EN, SP, IT, DA, AF, JU Elevnavn er ikke entydigt Ikke alle poster er lige lange 16

17 Tre grader af normalisering første grad (før) Elevnavn Adresse Er atomare attributter altid et krav? Ib Jensen Thomasmindevej, Kartoffelsted Ja, hvis man skal kalde noget første normalform. Bo Søgård Kathrinesmindevej, 16, 1.th 1650 Gulerodsby Typer af problemer: Anne Høgh Chrstoffersmindevej, Pastinakby Ib Jensen Troelsmindevej, Rødkålsborg Et medarbejdernummer? ES1457, hvor de to første cifre er en specifikation af afdelingen Ikke atomic Ikke atomic Cpr-nummer? Vurdér hvornår det er en unødvendig byrde for 17 applikationen

18 Tre grader af normalisering første grad Hvordan løser vi problemerne? Trin 1: Indfør en nøgle Inkludér nok felter til at nøglen bliver entydig Opfind selv nøgle, ofte et løbenummer Trin 2: Indfør ny tabel med fast længde, hvor hver attribut er atomic 18

19 Tre grader af normalisering første grad (efter) Elevnummer Fornavn Efter 1 Ib Jensen DA 1 Ib Jensen TY 1 Ib Jensen IT 1 Ib Jensen EN 2 Bo Søgård TY 2 Bo Søgård EN 2 Bo Søgård IT Alle poster i tabellen er unikke Alle poster i tabellen har længde 3 Tabellen er nu på 1.normalform! 2 Bo Søgård AF 2 Bo Søgård SP og så videre 4 Ib Jensen JU 19

20 Tre grader af normalisering anden grad 2.Normalform Tabellen er på 1.normalform Ingen ikke-nøgle-attributter er funktionelt afhængige af blot en del af nøgleattributterne (Sagt på en anden måde: der må kun være én nøgle i hver tabel, der entydigt afgør indholdet af alle øvrige felter) Det betyder: Nogle informationer kan måske udpeges entydigt med mindre information end den primærnøglen rummer 20

21 Tre grader af normalisering anden grad (før) Elevnummer Elevnavn Fag Timer 1 Ib Jensen DA 2 1 Ib Jensen TY 3 1 Ib Jensen IT 2 1 Ib Jensen EN 4 2 Bo Søgård TY 2 2 Bo Søgård EN 1 2 Bo Søgård IT 4 2 Bo Søgård AF 3 2 Bo Søgård SP 4 og så videre I denne tabel er Elevnummer og Fag nøgle denne kombination er entydig Men Elevnavn udpeges jo entydigt af Elev-nummer alene! Spild at gentage Elevnavn gang på gang 4 Ib Jensen JU 1 21

22 Tre grader af normalisering anden grad Løsningen er oftest at lave nye tabeller, hvor den mindst mulige nøgle bruges I eksemplet: Elevnavn udpeges entydigt af Elevnummer så lav en tabel med kun Elevnummer som nøgle Elevnavn fjernes derfor fra den oprindelige tabel 22

23 Tre grader af normalisering anden grad (efter) Elevnummer Fag Timer 1 DA 2 1 TY 3 1 IT 2 1 EN 4 2 TY 2 2 EN 1 2 IT 4 2 AF 3 2 SP 4 og så videre Elevnummer Elevnavn 1 Ib Jensen 2 Bo Søgård 3 Anne Høgh 4 Ib Jensen Elevnummer -> Elevnavn (Elevnummer, Fag) -> Timer 4 JU 1 23

24 3 grader af normalisering tredje grad 3.Normalform Tabellen er på 2.normalform Ingen ikke-nøgle attributter må være transitivt afhængige af nøgleatributterne. Dvs. at det ikke må være tilfældet at B er funktionelt afhængig af A, og A er funktionelt afhængigt af nøglen N.(N A B) Det betyder: Nogle informationer kan måske udpeges entydigt og ikke-transitivt ved hjælp af anden information end den primærnøglen rummer 24

25 3 grader af normalisering tredje grad (før) Elevnummer Elevnavn Postnummer By 1 Ib Jensen 4100 Ringsted 2 Bo Søgård 4000 Roskilde 3 Anne Høgh 4100 Ringsted 4 Ib Jensen 4000 Roskilde Elevnummer udpeger entydigt Elevnavn, Postnummer og By; d.v.s. 2.normalform OK MEN Postnummer udpeger også entydigt By! 25

26 Tre grader af normalisering tredje grad Løsningen er oftest at lave nye tabeller, hvor den attribut som afhængigheden går over identificeres. I tilfældet (N A B) identificeres A, og A bruges som nøgle i en ny tabel, hvor b udgør de øvrige atributter. I eksemplet: By udpeges entydigt af Postnummer så lav en ny tabel med kun Postnummer som nøgle By fjernes derfor fra den oprindelige tabel 26

27 3 grader af normalisering tredje grad (efter) Elevnummer Elevnavn Postnummer Postnummer By 1 Ib Jensen Bo Søgård Anne Høgh Ib Jensen Ringsted 4000 Roskilde Elevnummer -> Elevnavn, Postnummer Postnummer -> By 27

28 Normalisering i en nøddeskal Vær på vagt, hvis samme information forekommer mange gange er det nødvendigt? 28

29 Normalisering hvad skal der til for at opnå de tre normalformer? CPR First name Street City Date Purchase Oda Æblevej, , Aalborg Sulfamethizol Niels Clara Friisvej, Svend Appelsinlunde n, , Herlev Marevan 9200,Aalborg SV Cipralex Oda Æblevej, , Aalborg Panodil Niels Clara Friisvej, , Herlev Marevan

30 Afsluttende bemærkninger Normalisering skal fjerne redundans og inkonsistens fra databasen. Brug reglerne for normalisering som et sundhedscheck for databasens design En god ER-model og en stringent transformation af ER-modellen til database schemas overflødiggør ofte det meste af normaliseringsprocessen, I skal dog være i stand til at argumentere for at en tabel er på 3. normalform selv om I ikke har lavet ændringer i den Bogen har ikke helt samme betegnelser, i forlæsningen er der en simplificeret måde at forstå normalisering på. Boyce-Codd er en slags 3. normalform, men som tager højde for flere specialtilfælde. Nogen gange er normalisering ikke førsteprioritet. Normalisering: minimerer redundans of muligheder for inkonsistens De-normalisering: Færre tabeller og øger dermed performance Brug jeres sunde fornuft og design tabeller der virker

31 Opgave Fortsæt med at lave ernæringsscreening eller vitale værdier til schemas - Lav tabellerne på 3. normalform og send dem til kirse@hst.aau.dk - Hvis I bliver færdige så fortsæt med at lave de tabeller jeg lavede på tavlen sidste gang til 3. normalform: apotekseksempel