Vorlesung Informationsintegration

Informationsintegration
Eine sehr kurze Übersicht über
relationale Datenbanken
Ulf Leser
Wissensmanagement in der
Bioinformatik
Was ist Informationsintegration?
• Kurz: Informationsintegration bezeichnet die
Zusammenführung des Inhalts verschiedener
Datenquellen an einer Stelle
• Lang: Informationsintegration bezeichnet die korrekte,
vollständige und effiziente Zusammenführung des
Inhalts verschiedener, verteilter, autonomer und
heterogener Quellen an einer Stelle zu einer
einheitlichen und strukturierten Informationsmenge mit
dem Ziel, eine effektiven Nutzung durch Nutzer und
Anwendungen zu ermöglichen
• Aber: Informationsintegration kann auch auf einer
einzelnen Datenbank sinnvoll sein, wenn deren Inhalt
heterogen ist
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
2
EAI versus Informationsintegration
SCM
ERP
Message
Broker
E-Commerce
Anfrage
CRM
E-Procurement
Integriertes Informationssystem
Oracle,
DB2…
Dateisystem
Web
Service
Anwendung
HTML
Form
Integriertes
Info-system
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
3
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
4
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
5
Warum ist es so schwer?
• System-bedingte Gründe
– Verschiedene Plattformen
– Verteilung, Anfragebearbeitung über mehrere Systeme
– Quellen ändern sich dauernd und „von selbst“
• Semantische Gründe
– Heterogenität auf allen Ebenen (Daten, Schema, Sprachen)
– Semantik von Begriffen ist kontextabhängig
– Semantik ist schwer zu beschreiben
• Soziale Gründe
– Einblick in „fremde“ Datenbanken muss gestattet werden
– Menschen zur Zusammenarbeit überreden
– Einhalten von Verabredungen und Standards
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
6
Eine Schnittstelle
• Integration durch Mediator
– Nimmt Anfrage und berechnet Ergebnis unter Zugriff
auf Quellen
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
7
Ablauf 1
Globale Anfrage
Integrationssystem
Datenquelle 1
Datenquelle 2
Datenquelle 3
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
8
Ablauf 2
Globale Anfrage
Integrationssystem
Anfrageübersetzung,
-optimierung
und -ausführung
Datenquelle 1
Datenquelle 2
Datenquelle 3
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
9
Ablauf 3
Globale Anfrage
Integrationssystem
Anfrageübersetzung,
-optimierung
und -ausführung
Datenquelle 1
Ergebnisintegration
Datenquelle 2
Datenquelle 3
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
10
Ablauf 4
Anfrageergebnis
Globale Anfrage
Integrationssystem
Anfrageübersetzung,
-optimierung
und -ausführung
Datenquelle 1
Ergebnisintegration
Datenquelle 2
Datenquelle 3
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
11
Probleme
• Heterogene Schnittstellen
– Technische Unterschiede
– Unterschiedliche mögliche Funktionsaufrufe / Quellen
• Heterogene Quellformate
– Unterschiedliche Attribute
– Unterschiedlich strukturierte Attribute
– Unterschiedlich benannte Attribute
• Heterogene Daten
– Unterschiedlicher Inhalt der Quellen
– Widersprüche in den Daten
• …
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
12
Inhalt dieser Vorlesung
•
•
•
•
•
•
Relationale Datenbanken
Relationales Modell und Datenbankentwurf
Relationale Operatoren & Algebra
SQL
Anfragebearbeitung
(Integrität und Normalformen)
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
13
Relationale Datenbank
• Relationale Datenbank Management Systeme (RDBMS)
– Serverbasierte Software
– Ein RDBMS – viele RDB
– Aufgaben des Servers
•
•
•
•
•
•
Hauptspeicher- und Sekundärspeicherverwaltung
Transaktionsmanagement
Anfragebearbeitung und –optimierung
Backup und Recovery
Datenkonsistenz
Userverwaltung
– Systeme
• Oracle, DB2 (Informix), Sybase, NCR Teradata, SQL-Server
• PostgreSQL, Interbase, Berkeley-DB, DB4Objects, MySQL, Ingres,
SAP-DB, Monet-DB, ...
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
14
Client-Server
JAVA (JDBC)
JAVA (JDBC)
JAVA (JDBC)
Native (SQL*Plus,
Native (SQL*Plus,
OCI)
Native
(SQL*Plus,
OCI)
OCI)
Andere
Datenbank
Listener
DB1Server
Sekundärspeicher
DB2Server
Sekundärspeicher
Konsistenz
Parallelisierung
Recovery
Lastverteilung
Authentifizierung
Autorisierung
....
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
15
Ein Oracle-Server
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
16
Relationales Datenmodell
• Repräsentation aller Daten in Tabellen
– Tabellenname
– Attribute
– Datentypen
• Vergleich zum UML Datenmodell?
mitarbeiter
p_id
Zeilen/
Rows/
Tupel
vorname
Spalten/Attribute
nachname
alter
adresse
1
Peter
Müller
32
10101 Berlin
2
Stefanie
Meier
34
11202 Berlin
5
Petra
Weger
28
80223 München
7
Andreas
Zwickel
44
80443 München
...
... Wintersemester
...2008/2009 ...
Ulf Leser:
Informationsintegration,
...
17
ER-Modellierung
•
•
•
•
Relationales Modell „semantikarm“
Modellieren in Tabellen wenig intuitiv
Modellierungssprachen: ER, EER, UML, ...
Entity-Relationship Modell
mitarbeiter
– Entitytypen
projekte
p_id
proj_id
vorname
start
– Attribute
– Beziehungen
nachname
arbeitet_in
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
kunde
18
voraussetzen
Uni-Schema
Nachfolger
Vorgänger
N
MatrNr
hören
studenten
Name
M
vorlesungen
N
N
Titel
M
Note
lesen
prüfen
PersNr
1
Name
assistenten
arbeitenFür
N
SWS
M
N
Semester
VorlNr
Stimmt
das
gerade?
Rang
1
professoren
1
Raum
Fachgebiet
PersNr
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
Name
19
Entwicklung des relationalen Schemas
professoren
lesen
1
vorlesungen
N
1:N-Beziehung
• Initial-Entwurf
Vorlesungen : {VorlNr, Titel, SWS}
Professoren : {PersNr, Name, Rang, Raum}
lesen: {VorlNr, PersNr}
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
20
Verfeinerung des relationalen Schemas
1:N-Beziehung
• Initial-Entwurf
Vorlesungen : {VorlNr, Titel, SWS}
Professoren : {PersNr, Name, Rang, Raum}
lesen: {VorlNr, PersNr}
• Verfeinerung durch Zusammenfassung
Vorlesungen : {VorlNr, Titel, SWS, gelesenVon}
Professoren : {PersNr, Name, Rang, Raum}
Regel
Relationen mit gleichem Schlüssel kann man zusammenfassen
aber nur diese und keine anderen!
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
21
Ausprägungen
Vorlesungen
Professoren
Rang Raum
VorlNr
Titel
SWS
Gelesen
Von
5001
Grundzüge
4
2137
5041
Ethik
4
2125
5043
Erkenntnistheorie
3
2126
5049
Mäeutik
2
2125
4052
Logik
4
2125
5052 Wissenschafttheorie
3
2126
5216
Bioethik
2
2126
PersNr
Name
2125
Sokrates
C4
226
2126
Russel
C4
232
2127
Kopernikus
C3
310
2133
Popper
C3
52
2134
Augustinus
C3
309
2136
Curie
C4
36
5259
Der Wiener Kreis
2
2133
2137
Kant
C4
7
5022
Glaube und Wissen
2
2134
4630
Die 3 Kritiken
4
2137
professoren
lesen
1
vorlesungen
N
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
22
So geht es NICHT
Vorlesungen
Professoren
Rang Raum liest
VorlNr
Titel
SWS
5001
Grundzüge
4
5041
Ethik
4
5043
Erkenntnistheorie
3
5049
Mäeutik
2
Logik
4
PersNr
Name
2125
Sokrates
C4
226
5041
2125
Sokrates
C4
226
5049
4052
2125
Sokrates
C4
226
4052
5052 Wissenschafttheorie
3
...
...
...
...
...
5216
Bioethik
2
2134
Augustinus
C3
309
5022
5259
Der Wiener Kreis
2
2136
Curie
C4
36
??
5022
Glaube und Wissen
2
4630
Die 3 Kritiken
4
professoren
lesen
1
vorlesungen
N
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
23
Folgen: Anomalien
professoren
Rang Raum liest
orlesungen
VorlNr
Titel
SWS
5001
Grundzüge
4
5041
Ethik
4
5043
Erkenntnistheorie
3
5049
Mäeutik
2
Logik
4
PersNr
Name
2125
Sokrates
C4
226
5041
2125
Sokrates
C4
226
5049
4052
2125
Sokrates
C4
226
4052
5052 Wissenschafttheorie
3
...
...
...
...
...
5216
Bioethik
2
2134
Augustinus
C3
309
5022
5259
Der Wiener Kreis
2
2136
Curie
C4
36
??
5022
Glaube und Wissen
2
4630
Die 3 Kritiken
4
• Update-Anomalie
– Was passiert wenn Sokrates umzieht?
• Lösch-Anomalie
– Was passiert wenn „Glaube und Wissen“ wegfällt
• Einfügeanomalie
– Curie ist neu und liest noch keine Vorlesungen
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
24
Beziehung „hören“
• m:n Beziehung
• „Brückentabelle“ mit zwei Fremdschlüsseln
vorlesung
vorlesung
student
M
N
hört
v_id
10
11
name
...
...
...
...
...
student
s_id
1
2
name
...
...
...
...
...
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
hört
s_id
1
2
1
2
v_id
10
10
11
11
25
Beziehung „betreuen“
1
studenten
N
betreuen
professoren
1
seminarthemen
Note
betreuen : Professoren x Studenten → Seminarthemen
betreuen : Seminarthemen x Studenten → Professoren
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
26
Erzwungene Konsistenzbedingungen
1. Studenten dürfen bei demselben Professor bzw.
derselben Professorin nur ein Seminarthema „ableisten“
2. Studenten dürfen dasselbe Seminarthema nur einmal
bearbeiten – sie dürfen also nicht bei anderen
Professoren ein schon einmal erteiltes Seminarthema
nochmals bearbeiten.
Es sind aber folgende Datenbankzustände möglich:
–
Professoren können dasselbe Seminarthema
„wiederverwenden“ – also dasselbe Thema auch mehreren
Studenten erteilen
–
Ein Thema kann von mehreren Professoren vergeben werden
– aber an unterschiedliche Studenten
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
27
Wie sieht das relationale Schema aus?
1
studenten
N
betreuen
professoren
1
seminarthemen
Note
• betreuen{ student, professor, thema, note}
• unique( student, professor)
– Jeder Student nur ein Thema pro Professor
• unique( student, thema)
– Jedes Thema nur einmal pro Student
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
28
Ausprägung der Beziehung betreuen
p1
b1
b2
p3
s2
b3
p4
s3
b4
s1
studenten
p2
s4
professoren
t1
b5
Gestrichelte Linien
b6
markieren illegale Ausprägungen
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
t2
t3
t4
seminarthemen
29
• Relationale Operationen
proj_id
p_id
mitarbeiter
vorname
projekte
start
nachname
arbeitet_in
anteil
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
30
Operationen auf Relationen/Tabellen
• Selektion
– Alle Zeilen von Mitarbeiter mit Alter>40 und
Name=„Müller“
• Projektion
– Nur die Mitarbeiter-Spalten Vorname, Nachname
• Kartesisches Produkt
– Alle Zeilen von Mitarbeiter verknüpft mit jeweils allen Zeilen
von Arbeitet_in
• Komposition von Operationen
– Die Spalten Nachname und Proj_id aller Zeilen des
kartesischen Produkts von Mitarbeiter und Arbeitet_in,
bei denen Mitarbeiter.P_ID=Arbeitet_in.P_ID mit
Anteil größer als 10%
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
31
Die relationale Algebra
•
•
•
•
•
•
•
•
•
•
•
•
•
•
σ Selektion
π Projektion
x Kreuzprodukt
⋈ Join (Verbund)
ρ Umbenennung
− Mengendifferenz
÷ Division
∪ Vereinigung
∩ Mengendurchschnitt
⋊ linker Semijoin
⋉ rechter Semijoin
⋈ Left outer join
⋈ Right outer join
⋈ Full outer join
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
32
Der natürliche Verbund (Join)
Gegeben seien:
•R(A1,..., Am, B1,..., Bk)
•S(B1,..., Bk, C1,..., Cn)
R ⋈ S = ΠA1,..., Am, R.B1,..., R.Bk, C1,..., Cn(σR.B1=S. B1
∧...∧ R.Bk = S.Bk(RxS))
R⋈S
R−S
A1
A2
...
R∩S
Am
B1
B2
...
S−R
Bk
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
C1
C2
...
Cn
33
Andere Join-Arten
• Linker äußerer Join
L
R
A
B
C
a1
b1
c1
a2
b2
c2
⋈
Resultat
C
D
E
c1
d1
e1
c3
d2
e2
=
A
B
C
D
E
a1
b1
c1
d1
e1
a2
b2
c2
-
-
• Rechter Semi-Join
L
R
A
B
C
a1
b1
c1
a2
b2
c2
⋉
C
D
E
c1
d1
e1
c3
d2
e2
=
Resultat
A
B
C
a1
b1
c1
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
34
SQL – Grundkonzepte
SELECT
FROM
WHERE
•
•
•
•
•
•
M.nachname, A.arbeitet_in
mitarbeiter M, arbeitet_in A
M.p_id = A.p_id AND
A.anteil > 0.1
SQL: Structured Query Language
ANSI-SQL, SQL-92, SQL-99, SQL-3
Deklarativer Charakter: Was, nicht wie
Vier Grundbefehle: Insert, Update, Delete, Select
DDL versus DML
Andere Sprachen
– Tupel/Domänenkalkül, relationale Algebra, QBE, Datalog
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
35
Insert
• Einfügen von Werten in Tabelle
• Prinzipiell ein Tupel pro Insert
INSERT INTO mitarbeiter VALUES
(1, „Peter“, „Müller“, 38, „10101 Berlin“);
INSERT INTO projekte (proj_id, name, kunde) VALUES
(1, „Stammhaus-BMW“, „BMW“);
• Erweiterungen
– Bulk-Insert
INSERT INTO ... SELECT ...
– Konditionales Insert in mehrere Tabellen
INSERT INTO ... INTO ... INTO ...
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
36
Update
• Ändern von Werten in Tabellen
• Mengensemantik: Ändert mehrere Werte
UPDATE projekte
SET status = „abgebrochen“,
kunde = kunde||“-insolvent“
WHERE kunde=„Grundig“
• Typisches Muster
UPDATE tabelle
SET ... = (SELECT ... FROM ... WHERE)
WHERE id in (SELECT ... FROM ... WHERE)
• Erweiterungen
– UPSERT / MERGE
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
37
Delete
• Löschen von Tupeln in einer Tabelle
DELETE FROM projekte
WHERE status=„abgeschlossen“
• Typisches Muster
DELETE FROM projekte
WHERE id in (SELECT ... FROM ... WHERE)
• Löschen ist eine performancekritische Operation
• DELETE, DROP TABLE, TRUNCATE, Partitionen, ...
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
38
Select
• Selektieren von Werten aus mehreren Tabellen
SELECT
FROM
WHERE
M.nachname, A.anteil
mitarbeiter M, arbeitet_in A
M.p_id = A.p_id AND
a.anteil > 0.1
SELECT
FROM
WHERE
M.nachname, P.name, A.anteil
mitarbeiter M, projekte P, arbeitet_in A
M.p_id = A.p_id AND
A.proj_id = P.proj_id
SELECT
FROM
WHERE
M.nachname, A.anteil
mitarbeiter M, arbeitet_in A
M.p_id = A.proj_id
?
• Ergebnis ist immer eine Tabelle
• Ausführung ist Sache des RDBMS - Optimierung
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
39
Varianten
• Subqueries
– Korreliert oder nicht
– Unkorrelierte Form?
• Self-Join
– „Begrenzte Rekursion“
SELECT
vorname, nachname
FROM mitarbeiter M
WHERE
EXISTS (
SELECT A.p_id
FROM
arbeitet_in A
WHERE A.p_id = M.p_id
SELECT P1.name, P2.name
FROM
projekte P1, projekte P2
WHERE P1.vorgaenger=p2.proj_id AND
P2.status=„abgeschlossen“
• SQL in FROM Klausel
– „In-Line Views“
– Nützlich bei Top-Ten /
Sortieranfragen
– Top Ten Anfragen?
SELECT X.nachname, X.status
FROM
(
SELECT M.nachname, p.status
FROM mitarbeiter, projekte, arbeitet_in
WHERE M.p_id=A.p_id AND
A.proj_id=P.proj_id
) X
WHERE X.status=„Akquisition“
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
40
Unkorrelierte versus korrelierte Unteranfragen
Korrelierte Formulierung – Umformung ?
select s.*
from Studenten s
where exists
(select p.*
from Professoren
where p.GebDatum > s.GebDatum);
Besser: Äquivalente unkorrelierte Formulierung
select s.*
from Studenten s
where s.GebDatum <
(select max (p.GebDatum)
from Professoren p);
• Unteranfrageergebnis kann materialisiert werden
• Unteranfrage braucht nur einmal ausgewertet werden
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
41
Weitere Operationen
• Aggregation und GROUP BY
?
SELECT
FROM
WHERE
GROUP BY
proj_id, COUNT(*), SUM(alter)/COUNT(*)
mitarbeiter M, arbeitet_in A, projekte P
M.p_id=A.p_id AND A.proj_id=P.proj_id
P.proj_id
SELECT
FROM
WHERE
GROUP BY
proj_id, P.name, COUNT(*)
mitarbeiter M, arbeitet_in A, projekte P
M.p_id=A.p_id AND A.proj_id=P.proj_id
P.proj_id
• ORDER BY
SELECT
FROM
WHERE
ORDER BY
P.name, M.nachname
mitarbeiter M, arbeitet_in A, projekte P
M.p_id=A.p_id AND A.proj_id=P.proj_id
P.name, M.nachname
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
42
Views
• Definition von „benannten“ Queries
CREATE VIEW proj_pers AS
SELECT
P.proj_id, P.name,
M.P_id, M.name, M.alter,
FROM
mitarbeiter M, arbeitet_in A, projekte P
WHERE
M.p_id=A.p_id AND A.proj_id=P.proj_id
• Können viel Schreibarbeit sparen
SELECT
FROM
GROUP BY
proj_id, COUNT(*), SUM(alter)/COUNT(*)
proj_pers
proj_id
• Verwendung für tupelgenauen Zugriffsschutz
• Views werden i.d.R. syntaktisch expandiert
• Erweiterungen
– Materialisierte Sichten
– Rekursive Views
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
43
DDL
• DML: Data Manipulation Language
• DDL: Data Definition Language
• Definition von
– Tabellen, Indexen, Views, ...
– Administration: Tablespaces, Segmente, Rollen
– Benutzerverwaltung: User, Gruppen, Rechte, ...
CREATE TABLE mitarbeiter (
p_id
NUMBER,
vorname
VARCHAR2(100),
nachname
VARCHAR2(100),
alter
NUMBER(2) CHECK (alter>0 AND alter<150),
adresse
VARCHAR2(1000)
);
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
44
Anfrageübersetzung und -optimierung
• Prinzipieller Ablauf
–
–
–
–
Parsen der Anfrage (Syntax)
Überprüfen der Schemaelemente („Semantik“)
Expandieren von Views
Berechnung von Ausführungsplänen
• Exponentiell viele
– Wahl des optimalen Ausführungsplans
• Regelbasierter Optimierer
• Kostenbasierter Optimierer - Statistik
– Ausführung
• (Dynamisches Re-Planen?)
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
45
Ausführungspläne
SELECT
FROM
WHERE
M.nachname, A.anteil
mitarbeiter M, arbeitet_in A
M.p_id = A.p_id AND
a.anteil > 0.1
π(nachname, anteil)
π(nachname, anteil)
σ(anteil>0.1)
NLJ(p_id=p_id)
arbeitet_in
mitarbeiter
NLJ(p_id=p_id)
σ(anteil>0.1)
π(p_id,nachname)
arbeitet_in
mitarbeiter
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
46
Ausführungspläne
• Freiheitsgrade
–
–
–
–
Algebraische Anfrageumformung
Joinreihenfolge
Joinmethode (Nested Loop, Sort-Merge, Hash ...)
Access path: Indexzugriff (welcher?), Full-Table-Scan
• 3, 5, 7% Regel
– Operatorreihenfolge
• Kostenbasierter Optimierung
– Einbeziehung von Werteverteilungen, Tabellengrößen, Anzahl
NULL-Werten, Histogrammen, Selektivität, ...
• Heuristische Ziele
– Minimierung von Zwischenergebnissen
– Minimierung von Sekundärspeicherzugriff
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
47
Integrität
• Semantisch konsistenter Zustand der Daten
– Kann nur im Anwendungskontext definiert werden
• Überwachung nach Möglichkeit durch RDBMS
–
–
–
–
Datenmodell selber (Kardinalitäten)
Referentielle Integrität (Fremdschlüssel)
CHECK Constraints in DDL
Trigger
• Zeitpunkt der Überwachung?
– Nach jeder Operation
– Nach jeder Transaktion
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
48
Normalformen
• Attribute hängen funktional voneinander ab
– p_id
→ Vorname, Nachname, Alter ...
– proj_id → Kunde, Status, ...
• Schlüsselkandidaten
– Minimale Menge von Attributen, die alle anderen
Attribute einer Tabelle funktional bestimmen
• Zerlegung nach funktionalen Abhängigkeiten
– Datenbankentwurf
– Ziel: Redundanzfreies Schema ohne Anomalien
– Aber: Performanzsteigerung macht oftmals
Denormalisierung notwendig
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
49
Normalformen
• Relationenschema R, Schlüsselkandidaten P
• Erste Normalform (1NF)
– Alle Attribute von R sind atomar (Adresse!)
– Kann man nicht automatisch überprüfen
– Designentscheidung mit Auswirkung auf alle anderen NFs
• Zweite Normalform (2NF)
– R ist in 1NF
– Kein Attribut A, A nicht Teil eines Schlüssels, hängt von
Teilmenge P‘ ⊂ P funktional ab
– Schlecht: lehrt(p_id,s_id,termin,stud_name)
• Dritte Normalform (3NF)
– R in 1NF
– Kein Attribut A hängt von einem A‘∉P ab
– Schlecht: mitarbeiter(p_id,plz,ort)
Ulf Leser: Informationsintegration, Wintersemester 2008/2009
50