Tema
Titel
Materiale
1
IS i sundheds-sektoren Patientdatas anvendelighed
2
Registrering af patientdata
Berg. Kap. 2 Waiting for
Godot.
3
Relations-databaser
4
Databaser for klinisk kvalitet
Silberschatz
Kap 1 (1.1-1.6)
Green
5
Modellering af IS
Modellering
6
E-R diagrammer
7
Normalisering
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
15
Opsummering og reflektion
Lynge et al.
Silberschatz
Kap 2.1
Silberschatz
Kap 7 (7.1-7.7)
Silberschatz
Kap 8 (8.1-8.3)
Silberschatz
Kap 3 (3.1-3.7)
Silberschatz
Kap 4 (4.1-4.5)
Resumere kursuslitteraturen
No. 1
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 ERmodelering. 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
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
No. 2
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
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 data-kommunikation
metoder til beslutningsstøtte

anvende SQL syntaks og funktioner
No. 3
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
No. 4
Opsamling på opgave fra sidst: Forklar jeres ER-diagram for
hinanden
No. 5
670
No. 6
671
No. 7
672
No. 8
No. 9
Normalisering
Fra tabeller udledt fra ER-diagrammer til tabeller på 3. normalform
No. 10
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
No. 11
Normalization (1)
Normalization prevents inappropriate features in relational schemas to be implemented
• Database instance: drug purchase(cpr, first name, street, date, purchase)
CPR
First name
Street
Date
Purchase
111135-2212
Oda
Æblevej
04.01.04
Sulfamethizol
020240-6299
Niels
Clara Friisvej
13.02.05
Marevan
170560-2153
Svend
Appelsinlunden
09.12.04
Cipralex
111135-2212
Oda
Æblevej
23.10.04
Panodil
0202040-6299
Niels
Clara Friisvej
05.06.05
Marevan
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)
No. 12
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
No. 13
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
No. 14
No. 15
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
No. 16
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
No. 17
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 nonprimary 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
No. 18
No. 19
Normalization (8)
CPR
First name
Street
City
Date
Purchase
111135-2212
Oda
Æblevej, 6
9000, Aalborg
04.01.04
Sulfamethizol
020240-6299
Niels
Clara Friisvej,
8
2730, Herlev
13.02.05
Marevan
170560-2153
Svend
Appelsinlunde
n, 2
9200 ,Aalborg
SV
09.12.04
Cipralex
111135-2212
Oda
Æblevej, 6
9000, Aalborg
23.10.04
Panodil
02020406299
Niels
Clara Friisvej,
8
2730, Herlev
05.06.05
Marevan
No. 20
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
No. 21
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 [email protected]
-
Hvis I bliver færdige så fortsæt at lave de tabeller jeg lavede på tavlen sidste gang til
3. normalform: apotekseksempel
No. 22