No. 1 TemaTitelMateriale 1 IS i sundheds-sektorenPatientdatas anvendelighedLynge et al. 2 Registrering af patientdata Berg. Kap. 2 Waiting for Godot. 3.

Præsentationer af emnet: "No. 1 TemaTitelMateriale 1 IS i sundheds-sektorenPatientdatas anvendelighedLynge et al. 2 Registrering af patientdata Berg. Kap. 2 Waiting for Godot. 3."— Præsentationens transcript:

1 No. 1 TemaTitelMateriale 1 IS i sundheds-sektorenPatientdatas anvendelighedLynge et al. 2 Registrering af patientdata Berg. Kap. 2 Waiting for Godot. 3 Relations-databaser Silberschatz Kap 1 (1.1-1.6) 4 Databaser for klinisk kvalitetGreen 5 Modellering af ISModellering Silberschatz Kap 2.1 6 E-R diagrammer Silberschatz Kap 7 (7.1-7.7) 7 Normalisering Silberschatz Kap 8 (8.1-8.3) 8 “Den gode model” 9 Modellering af systemer 10 Dataudtræk og databehandling Udtræk af databaser Silberschatz Kap 3 (3.1-3.7) 11 Modellering med fokus på data-behandling 12 Avancerede forespørgsler i databaser Silberschatz Kap 4 (4.1-4.5) 13 Beslutningsstøtte på baggrund af patientdata 14 Patientdatas tilgængelighed og sikkerhed 15 Opsummering og reflektionResumere kursuslitteraturen

2 No. 2 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: http://helid.digicollection.org/en/d/Js2909e/4.6.2.html. studenter præsentationer/anden opsamling de sidste 30min http://helid.digicollection.org/en/d/Js2909e/4.6.2.html. 5. Modellering af systemer: (WS) Fra database til fuldt IT system: Hvilke krav bør man stille til et blodbanksystem? Ændre dette databasen? Eksempel: https://www.prosang.com/prosang.pdf studenter præsentationer/anden opsamling de sidste 30min https://www.prosang.com/prosang.pdf

3 No. 3 Tema Forventet læringsudbytte af læsning af litteraturen og deltagelse i forelæsninger Forventet læringsudbytte af opgave-løsning, gruppediskussioner og workshops IS i sundheds- sektoren  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 Data- behandling  viden om databasesprog data-kommunikation  metoder til beslutningsstøtte  anvende SQL syntaks og funktioner

4 No. 4 Plan for i dag Opsamling: Forklar jeres ER-diagrammer for hinanden Pause Forlæsning: Normalisering Pause Opgave: ER-model af Ernæringsscreening/vitale værdier database Fra ER-diagram til Schema, enten vitale værdier eller Ernæringsscreening Normalisering af Schema

5 No. 5 Opsamling på opgave fra sidst: Forklar jeres ER-diagram for hinanden

6 No. 6 670

7 No. 7 671

8 No. 8 672

9 No. 9

10 No. 10 Normalisering Fra tabeller udledt fra ER-diagrammer til tabeller på 3. normalform

11 No. 11 Transforming E-R model to tables – repetition from last time Goal: to reduce the E-R model to a collection of relational schemas that express the same as the E-R model Relational schemas from entity sets/relationship sets in E-R model Strong entity set: table with a column for each attribute (key as in E-R model) Weak entity set: table with a column for each attribute and each key attribute in the supporting entity set (key includes foreign key) Relationship set: table with column for each key attribute in the entity sets connected and each attribute of the relationship set NB: redundancy in case of weak entity sets NB: table combination in case of minimum/total participation Attributes Composite attributes are split into simple attributes (each simple is a column) A multivalued attribute is transformed to a table containing the primary key to the entity set that the multivalued attribute described

12 No. 12 Normalization (1) Normalization prevents inappropriate features in relational schemas to be implemented Database instance: drug purchase(cpr, first name, street, date, purchase) Redundancy Same information registered multiple places – name and street Anomalis In case of update (e. g. moving), numerous updates are necessary to avoid inconsistencies (street) In case of deletions (e. g. outdating), unintended deletions may occur (address) CPRFirst nameStreetDatePurchase 111135-2212OdaÆblevej04.01.04Sulfamethizol 020240-6299NielsClara Friisvej13.02.05Marevan 170560-2153SvendAppelsinlunden09.12.04Cipralex 111135-2212OdaÆblevej23.10.04Panodil 0202040-6299NielsClara Friisvej05.06.05Marevan

13 No. 13 Normalization (2) Starts with tables identified from E-R model Will often result in more tables than before normalization Not an algorithm – normal forms are stages of development Several normal forms are found, each building on the previous

14 No. 14 Normalization (3) 1. normal form (independent of outer world) - criteriae A primary key exists that identify each tuple uniquely Attribute domains are atomic Solutions: Primary key is missing: Identify primary keys Attribute domains are not atomic: revise attribute domains

15 No. 15

16 No. 16 Normalization (4) Functional dependency If two tuples, with identical attribute values in the attribute set X, always have identical attribute values in the attribute set A, is A functionally dependent on X (=X determines A functionally) Written as X A, so Cpr Name, Street Some functional dependencies found in a database instance are not consistent with the real world case (e.g. street city) Functional dependencies can be eliminated by splitting off the functionally dependent attributes (A’s) into a new table using X as primary key and a column for each of the A attributes) The primay key determines all other attributes functionally, but no subset of the primary key can do this

17 No. 17 Normalisering (5) 2. normal form - criteriae The table is on 1. normal form Attributes not part of the primary key must be functionally dependent on only the full primary key (not on a subset of the primary key) Solutions: A subset X of the primary key determines attributes A: split the table so the old table is free from A attributes and the new table holds A and X attributes and uses X as primary key

18 No. 18 Normalization (7) 3. normal form - criteriae 2. normal form no non-primary key attributes are transitively dependent on key attributes (N A B) non-primary key attributes are functionally dependent on only primary key attributes no non-primary key attributes are functionally dependent on other non-primary key attributes Solutions: a non-primary key attribute (set) A is functionally dependent on another non- primary key attribute (set) B: split the table so the old table is free from A attributes and the new table holds A and B attributes and uses the B attributes as primary key

19 No. 19

20 No. 20 Normalization (8) CPRFirst nameStreetCityDatePurchase 111135-2212OdaÆblevej, 69000, Aalborg04.01.04Sulfamethizol 020240-6299NielsClara Friisvej, 8 2730, Herlev13.02.05Marevan 170560-2153SvendAppelsinlunde n, 2 9200,Aalborg SV 09.12.04Cipralex 111135-2212OdaÆblevej, 69000, Aalborg23.10.04Panodil 0202040- 6299 NielsClara Friisvej, 8 2730, Herlev05.06.05Marevan

21 No. 21 Afsluttende bemærkninger 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

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