(Microsoft PowerPoint - DB15 \226 Zusammenfassung.ppt)

Themen des Kurses
Einführung:
Zweck, Aufbau, Benutzung und Entwicklung von Datenbanken
Datenbankmanagementsysteme
Konzept, Typen, Leistungsumfang, Aufbau
Entwurf von Datenbanken:
Semantische Datenmodellierung:
ERM, EERM, UML
Datenmodelle:
Historische Datenmodelle
Das relationale Datenmodell
Objektorientierte Datenmodelle
Implementierung von Datenbanken
Integritätssicherung, Sichten, Rechte
Softwareschnittstellen:
Datenbanken und Java
(c) schmiedecke 06
DB15 - Zusammenfassung
2
... das DBMS
• Datenbank (Datenbasis, engl. Data Base):
struktutrierter Datenbestand auf einem Speichermedium,
typischerweise mit zugehörigen Benutzern, Zugriffsrechten etc.
• Datenbank-Management-System (DBMS):
Software zur Verwaltung von Datenbanken, bietet Benutzern
komfortablen und abgesicherten Zugriff auf die Datenbanken.
Administration von Benutzern und Rechten.
(c) schmiedecke 06
DB15 - Zusammenfassung
3
Datenunabhängigkeit
• Datenunabhängigkeit bedeutet Entkopplung von Datenhaltung und
Datennutzung
• Logische Datenunabhängigkeit:
•
Anwendungsprogramme müssen nicht die komplette logische Realisierung der
Datenstruktur kennen, um mit den Daten arbeiten zu können.
• Physische Datenunabhängigkeit:
•
Anwendungsprogramme müssen die interne Datenorganisation (Speicher, Datei)
und die Zugriffsmöglichkeiten nicht kennen, um mit den Daten arbeiten zu
können.
• Was müssen Anwendungsprogramme kennen?
•
abstrakte logische Struktur und ein Zugriffskalkül
d.h. Datenmodell und DB-Sprache
• Entkopplungsbeispiel Milch:
•
•
Max muss nicht wissen, wie viel die Kuh frisst, von der die Milch stammt, damit
ihm die Cornflakes schmecken.
Der Landwirt produziert und liefert Milch, ohne je von Max gehört zu haben.
Beide kooperieren
über den
Handel
und über Geld.
(c) –schmiedecke
06
DB15
- Zusammenfassung
4
Was ist ein Datenmodell?
• Kalkül zur Strukturierung von Informationen (Daten)
• Bietet Konzepte zur
– Datenabstraktion (Benennung von Teilmengen)
– Datensuche (Navigation, Retrieval)
– Datenmanipulation
• Beispiel Binäre Baumstruktur:
– Benennung von Knoten und Teilbäumen
– Traversierungsalgorithmen, Suchstrategien
– Baumoperationen zum Einhängen und Restrukturieren
(Balancieren)
• Konzepte sind unabhängig von der Implementierung (Verkettete
Listen, Indextabellen, ...)
(c) schmiedecke 06
DB15 - Zusammenfassung
5
Datenmodelle
•
Verschiedene Abstraktionsstufen:
– Mengen, Objekte, Wissensräume, ...
ohne Bezug zur Implementierung
(oder Implementierbarkeit)
semantische Datenmodelle
(oder abstrakte Datenmodelle)
ERM, EERM, UML-Klassenmodell
– Listen, Bäume, Netze, Tabellen, ....
Implementierungs-Referenzmodell liegt zugrunde
(Implementierbarkeit gesichert)
logische Datenmodelle
(oder konkrete Datenmodelle)
HDM, NDM, RDM, ORDM, OODM
– Zeigerstrukturen, Indexdateien, Hashtabellen, Datenblöcke ...
Implementierung,
Abbildung auf Speichermedien
physische Datenmodelle
(oder interne Datenmodelle)
(c) schmiedecke 06
DB15 - Zusammenfassung
6
Logische Datenmodelle
•
sind die Basis der Arbeit mit einer Datenbank
•
stellen einen Mittelweg zwischen Realweltabbildung und
Implementierung dar
•
zur "technisch" für den Entwurf komplexer Datenbanken
•
zu "abstrakt" für eine unmittelbare Abbildung auf
Speichermedien.
(c) schmiedecke 06
DB15 - Zusammenfassung
7
Hierarchisches Datenmodell
Datenstruktur
Betrieb
Name
Anschrift
Re-Nr
Anzahl
(c) schmiedecke 06
Leitung
Status
Status
Nr
Ort
Artikel
Typ
Nr
Gesamtpreis
Glasur
Dekor
Dekor
Artikel
Glasur
Preis
Einzelpreis
DB15 - Zusammenfassung
8
Netzwerkdatenmodell
Datenstruktur
Betrieb
Name
Re-Nr
Anschrift
Status
Ort
Status
Leitung
Typ
Gesamtpreis
Dekor
Nr
Artikel
Glasur
Preis
Anzahl
(c) schmiedecke 06
DB15 - Zusammenfassung
9
Netzwerk-Datenmodell
Diskussion
Charakteristika:
• Datenstrukturen in Form von Netzwerken (n Wurzeln, n Vorgänger)
• Navigation über definierte Zugriffspfade
• alle Beziehungen darstellbar (zusätzliche Zeiger)
Vorteile:
• redundanzfrei
• auch M:N-Beziehungen effizient darstellbar
Nachteile:
• Komplexität, Handhabbarkeit
• schwer überschaubar, schwer änderbar
• nur “vorgedachte” Abfragen schnell realisierbar ->
“Navigationspfad”
(c) schmiedecke 06
DB15 - Zusammenfassung
10
Das Relationale Datenmodell
Struktur und Beispiel-Datensätze
Geschäftspartner
$
',
& #( )
$)
*
+
,
-
#
'
+
-
.
+
/
)
0& 1
Märkte
!
!
&
*
'
&
'
"#$
%
)+
%
(
!
'
#( )
'
#( )
'
#( )
'
!
#
$
#
$
(c) schmiedecke 06
!'
%
Produkte
#
&
#( )
Wird angeboten auf
%
#
)+
Struktur
Daten
"
DB15 - Zusammenfassung
$
11
Das Relationale Datenmodell
Diskussion
Charakteristika:
• Datenstrukturen als zweidimensionale Tabellen
• Objekte / Entitäten
Zeilen
• Attribute
Spalten
• Verknüpfung von Tabellen über Attributübernahme
Vorteile:
• Einfachheit, alle Beziehungen darstellbar
• redundanzarme Datenspeicherung (kontrollierte Redundanz)
• einfach erweiter-, änder-, abfragbar
• keine Zugriffspfade, sondern frei definierbare Abfragen
• Relationenalgebra, Integritätsbedingungen, NFL, SQL
Nachteile:
• Probleme bei komplexen Datenstrukturen
• Performance bei Abfragen über viele Tabellen
(c) schmiedecke 06
DB15 - Zusammenfassung
12
Das objektorientierte Datenmodell
Struktur
Betrieb
-Name
-Ort
-Geschäftsführung : Geschäftspartner
*
1
1..*
1
Geschäftspartner
Serie
Produkt
-Name
-Anschrift
-Status
+StatusÄndern()
-Artikelnr
-Bezeichnung
-Preis
+preisÄndern()
+ausSortimentEntfernen()
1
0..*
-Typ
-Dekor
-Glasur
1
1..*
1
0..*
Auftrag
-Datum
-Status
-Gesamtpreis
+PositionHinzufügen()
+StatusÄndern()
(c) schmiedecke 06
Auftragsposition
-Anzahl
1
1..*
DB15 - Zusammenfassung
13
Das objektorientierte Datenmodell
Diskussion
Charakteristika:
• Sachverhalte der Realsphäre “natürlich” abbilden (ohne Zerlegung wie bei
klassischen DM)
• Abbildung komplex zusammengesetzter Daten möglich
• Speicherung der Zugriffsoperationen auf den Daten gemeinsam mit Daten
2 Wege zur OODB:
• Ergänzung objektorientierter Programmiersprachen um Konzepte zur
dauerhaften Datenhaltung in DBS (Persistenz, Transaktionen,
Sperrmechanismen, etc.), keine Ad-hoc-Anfragen
OODM
• Erweiterung Relationaler DBMS um objektorientierte Konzepte
ORDM
(SQL-1999)
Vorteile:
• alle Beziehungen darstellbar
• effizienter Zugriff (Laufzeitsysteme, DB-Systeme)
• einfache Änder-, Erweiterbarkeit
Nachteile:
• Standard (ODMG´97), aber Klasse von Modellen mit großen Unterschieden
• schmiedecke
Handhabung06zwar kompliziert,
aber
zunehmend etabliert
Frameworks.
(c)
DB15
- Zusammenfassung
14
Architekturmodelle
Zwei grundsätzlich Aufgaben,
beantwortet durch zwei Referenz-Architekturen
1.
2.
•
•
•
•
•
Datenorganisation
Abbildung der Daten auf Datenträger
Modellierung, Strukturierung und Speicherung
Beschreibung von Konsistenzbedingungen
Drei-Ebenen-Schema-Architektur (1975)
Funktionen
Spezifikation und Zusammenhang der
Systemkomponenten
Außen- und Innen-Schnittstellen
Drei-Ebenen-System-Architektur (1978)
(c) schmiedecke 06
DB15 - Zusammenfassung
15
Drei-Ebenen-Schema-Architektur
Anw.a
externe
Ebene
Anw.b
Anw.m
externes Schema 1
konzeptuelle
Ebene
interne
Ebene
(c) schmiedecke 06
Anw.n
externes Schema n
Konzeptuelles Schema
Logisches Schema
Log. Schema 2
Internes Schema
DB15 - Zusammenfassung
16
Drei-Ebenen-Systemarchitektur
(c) schmiedecke 06
DB15 - Zusammenfassung
17
Quelle:http://www.kreissl.info/diggs/db_01.php
Wie entwirft man eine
Datenbank?
• Datenbankentwurf = Schema-Entwurf!
• DBMS-Festlegung ist nicht Voraussetzung,
geht aber in spätere Phasen ein.
RealweltModellierung
(c) schmiedecke 06
Abbildung auf
Datenmodell
DB15 - Zusammenfassung
Abbildung auf
DBMS
18
Was ist semantische
Datenmodellierung?
• Datenverständnis und Info-Strukturierung
• Semantik = Bedeutung
• d.h. bedeutungs-orientierte Struktur
(Gegensatz zu implementierungs-orientiert)
• Verwendung mathematischer Kalküle
(z.B. Mengenalgebra)
• Phasenzuordnung: Analyse
(c) schmiedecke 06
DB15 - Zusammenfassung
19
ERM-Modellierung
P. Chen 76
• Abstraktion von zeitvarianten Aspekten:
– Entitäten – Entitätstypen
– Beziehungen - Beziehungstypen
• Graph. Sprache
• Einfaches mathematisches Modell:
Relationenalgebra
(c) schmiedecke 06
DB15 - Zusammenfassung
20
Modellierung geschieht unter
bestimmten Aspekten
• UoD – Universe of Discourse
– ist es relevant, dass ein Angehöriger auch einmal Patient
war?
– ist es relevant, dass der Patient Arzt ist?
• Zeitpunkt / Zeitraumdarstellung
– soll die Datenbank jeweils nur den momentanen Zustand
enthalten, oder auch vergangene?
• .... (wir kommen darauf zurück)
(c) schmiedecke 06
DB15 - Zusammenfassung
21
Existenzabhängigkeit
• Kardinalität (1,1) oder (1,n)
• bedeutet
–
–
–
–
Kunde existenzabhängig von Vertreter
Kunde existenzabhängig von Auftrag
Auftrag existenzabhängig von Kunde
Auftrag existenzabhängig von Status
(c) schmiedecke 06
DB15 - Zusammenfassung
22
Elemente der Datenmodelle
RDM
ERM:
• Entitätstypen,
• Beziehungstypen,
• AttributWertebemengen,
• Spezialisierungen.
(c) schmiedecke 06
•
•
•
•
Relationen (Tupelmengen)
Schlüssel
Integritätsbedingungen
Attribut-Wertemengen
R(Attr1, Attr2,..,AttrN)
Integritätsbedingung 1
…
IntegritätsbedingungN
DB15 - Zusammenfassung
23
Die wichtigsten Begriffe des RDM
Datenbankschema - Menge von Relationenschemata
Relationenschema - Objekttyp im UoD, Relation (+ evtl. Integritätsbedingungen)
R(Attr1, Attr2,..,AttrN)
Integritätsbedingung 1
…
Integritätsbedingung N
Attribut
- Objekteigenschaft (mit Wertebereich)
Relation
- Teilmenge des kart. Produkts der Attribut-Wertebereiche,
R(Attr1, Attr2,…,AttrN) ⊂ W(Attr1)xW(Attr2)x…xW(AttrN)
- grundlegende Datenstruktur des RDM (Tabelle)
Rel.-Schema
Tupel
Tupel
Attr1
Attr2
…
AttrN
W11
W12
…
W1N
W21
W22
…
W2N
Relation
- Tabellenzeile
- Objekt des Objekttyps
Integritätsbedingg.- Beschreibung der zulässigen Tupel einer Relation
(c) schmiedecke 06
DB15 - Zusammenfassung
24
Abbildung des ERM auf das RDM
•
Primäres Transformationsziel:
•
Weitere Ziele
•
Formale Transformationsregeln
•
Faustregeln
– Gleichwertigkeit
– d.h. Erhaltung der Informationskapazität:
im relationalen Datenbankschema sollen genauso viel Daten zulässig sein wie im
ERM
– Entscheidend ist die Abbildung der Beziehungen und anwendungsspezifischen
Integritätsbedingungen
–
–
–
–
minimale Redundanz
minimale Anzahl von Relationen
minimaler Verlust an Semantik
Natürlichkeit/Verständlichkeit des resultierenden Schemas
– geeignet für die automatische Transformation
– minimale Redundanz angestrebt
– Ergebnis oft unübersichtlich, schwer durchschaubar
– erfordern Sachkenntnis des Übersetzers
– flexible Lösungen zugunsten der Lesbarkeit
– minimale Relationenzahl angestrebt
(c) schmiedecke 06
DB15 - Zusammenfassung
25
Inkonsistente Zwischenzustände
• Referentielle Integrität gefährdet bei:
– INSERT:
Eintrag eines "Kindes" vor dem "Vater" unzulässig
– UPDATE:
Ändern eines Primärschlüssels macht Referenzen ungültig
– DELETE:
Löschen des "Vaters" hinterlässt "Waisen"
• Inkonsistente Zwischenzustände nicht immer vermeidbar:
– Existenzabhängigkeit fordert "not null"-Fremdschlüssel
– Was wird bei einer Spende zuerst eingetragen, der Spender oder
die Konserve?
– Problem auch bei abgeleiteten Attributen
Spender
(c) schmiedecke 06
(1,*)
(1,1)
Konserve
DB15 - Zusammenfassung
26
Umgang mit inkonsistenten
Zwischenzuständen
• Spezifizierte "referentielle Aktionen" der DB:
– Restriktives Vorgehen
– automatische Anpassung
• Verzögerte Bedingungsprüfung:
– um inkonsistente Zwischenzustände zu "überbrücken"
(c) schmiedecke 06
DB15 - Zusammenfassung
27
Anomalien
Strukturen in einem DB-Schema, die durch DML-Operationen zu
Widersprüchen in der Datenbasis führen können, heißen
Anomalien.
• Insert-Anomalie:
– Einfügen neuer Datensätze erfordert Daten, die eigentlich aus einem
anderen Zusammenhang stammen
• Udate-Anomalie:
– Änderung eines Datensatzes führt zu Widersprüchen in anderen
Datensätzen
• Delete-Anomalie:
– Beim Löschen gehen Daten verloren, die erhalten bleiben sollten.
(c) schmiedecke 06
DB15 - Zusammenfassung
28
1. Normalform (1NF)
Beispiel 1
Termin
Zeit
Platz
Verwendung
Name
Vorname
PLZ
Ort
Tel.
04.04.04
8:00
B
Vollblut
Meier
Sepp
13465
Berlin
030-8080808
0177-8080808
04.04.04
8:30
B
Vollblut
Schulze
Lisa
123353
Berlin
030-4445566
0331-678967
02.03.04
12:00
P
Plasma
Petersen
Jutta
31224
Peine
05171-5544
05171-5599
0176-2221122
1.Normalform:
In einer Relation gibt es nur atomare Attribute
Transformation:
- Strukturierte Attribute: Aufteilung auf mehrere Spalten
- Listenattribute:
eigene
Tabelle Name
Verwendung
Vorname
PLZ
Termin
Zeit
Platz
Ort
04.04.04
8:00
B
Vollblut
Meier
Sepp
13465
Berlin
04.04.04
8:30
B
Vollblut
Schulze
Lisa
123353
Berlin
(c) schmiedecke 06
Termin
Zeit
Platz
Tel.
04.04.04
8:00
B
030-8080808
8:00
B
0177-8080808
DB15 - Zusammenfassung
04.04.04
29
2. Normalform (2NF)
Beispiel 1
Termin
Zeit
Platz
Verwendung
Name
Vorname
PLZ
Ort
04.04.04
8:00
B
Vollblut
Meier
Sepp
13465
Berlin
04.04.04
8:30
B
Vollblut
Schulze
Lisa
13353
Berlin
02.03.04
12:00
P
Plasma
Petersen
Jutta
31224
Peine
Problem:
Platz B ist nur für Vollblut-Spenden, Platz P nur für Plasma.
Damit tritt die Verwendung redundant auf.
2.Normalform:
Die Relation ist in der 1NF, und alle Nicht-Schlüssel-Attribute sind vom
gesamten Primärschlüssel voll-funktional abhängig.
(c) schmiedecke 06
DB15 - Zusammenfassung
30
3. Normalform (3NF)
Beispiel 1
Termin
Zeit
Platz
Name
Vorname
PLZ
Ort
04.04.04
8:00
B
Meier
Sepp
13465
Berlin
04.04.04
8:30
B
Schulze
Lisa
13353
Berlin
02.03.04
12:00
P
Petersen
Jutta
31224
Peine
3.Normalform:
Die Relation ist in der 2NF, und es existieren keine transitiven
Abhängigkeiten unter Nicht-Schlüssel-Attributen.
Transformation:
Auslagerung in eine extra Relation.
Termin
Zeit
Platz
Name
Vorname
PLZ
04.04.04
8:00
B
Meier
Sepp
13465
04.04.04
8:30
B
Schulze
Lisa
13353
(c) schmiedecke 06
DB15 - Zusammenfassung
PLZ
Ort
13465
Berlin
13353
Berlin
31224
Peine
31
Relationenalgebra
• Klassische Mengenoperationen (Vereinigung, Durchschnitt, etc.)
können auf Relationen angewendet werden,
• wenn sie vereinigunsverträglich sind,
d.h. vom selben Grad und je Attribut typverträglich.
• Die Algebra ist abgeschlossen, d.h. das Ergebnis einer
Relationenoperation ist wieder eine Relation.
• Zweck: Ableitung von Relationen aus Relationen als Grundlage
für Anfragen.
∪ Stammspender
Neuspender
Spender
SpenderNr
Name
SpenderNr
Name
SpenderNr
Name
2884
Marten Harms
2653
Bert Winter
2884
Marten Harms
2885
Sonja Selig
2544
Renate Sommer
2885
Sonja Selig
2653
Bert Winter
2544
Renate Sommer
(c) schmiedecke 06
DB15 - Zusammenfassung
32
Konzept der aktiven DB
• ECA-Prinzip:
– Event, Condition, Action
Spezifizierte DB-Zustände
Ereignis
ggf. automatische Aktion
• Ereigniskonzept:
– beliebig viele unabhängige ECA-Spezifikationen
pro Ereignis
(c) schmiedecke 06
DB15 - Zusammenfassung
33
Aktionsspezifikation in SQL
• Constraints: Assertions, Checks
– deskriptiv
"Aktion" besteht im Zurückweisen einer
Operation
– Bedingungen, unter denen DML-Operationen
zurückgewiesen werden
• Referentielle Aktionen
– operational
– Reparaturmaßnahmen bei Verletzung der referentiellen
Integrität
• Trigger
– operational
– Mit DML-Operationen verknüpfte frei programmierbare
Aktionen
(c) schmiedecke 06
DB15 - Zusammenfassung
34
Integritätsbedingungen
• inhärente Integritätsbedingungen
– durch das DBMS abgesichert
• externe oder semantische Integritätsbedingungen
– inhaltlich
– teilweise veränderbar ohne Auswirkungen auf das Schema
• statische Integritätsbedingungen
– dürfen zu keinem Zeitpunkt verletzt werden
• transitionale und dynamische Integritätsbedingungen
– zeitliche Einschränkung der Überprüfung
– müssen nicht immer oder nur in bestimmten Situationen
eingehalten werden
(c) schmiedecke 06
DB15 - Zusammenfassung
35
Integritätssicherung
•
•
•
•
DB-Aktionen sollten der Integritätssicherung dienen.
Es ist in der Regel nicht sinnvoll, die (gesamte) Geschäftslogik durch DBAktionen zu implementieren!
DB als gemeinsamer Datenbestand verschiedener Anwendungen mit
unterschiedlicher Geschäftslogik – Integrität als gemeinsame Eigenschaft.
Evtl. Subsystem zur Implementierung gemeinsamer Geschäftsregeln
mehrerer Anwendungen.
Anwendung2
Anwendung1
Anwendung3
Subsystem
Anwendung4
DB
(c) schmiedecke 06
DB15 - Zusammenfassung
36
Trigger
• Aktion aufgrund der Zustandsänderung einer Tabelle
- lokal angesiedelt
- ausgelöst durch das DBMS
- nicht beschrieben, sondern "programmiert"
• Wann?
- Aufgrund von UPDATE, INSERT oder DELETE
- Vor oder nach der Änderung (BEFORE / AFTER)
• Wie?
- einmalig
- oder zeilenweise (FOR EACH ROW)
- dann Zugriff auf alte und neue Werte:
REFERENCING OLD AS alt NEW AS neu
• Was?
- Frei programmierbare SQL-Anweisung
- Frei programmierbare Anweisungen in der prozeduralen SQL-Erweiterung
(SQL-1999: SQL/PSM
Oracle: PL/SQL oder SQLJ, MySQL: T-SQL)
(c) schmiedecke 06
DB15 - Zusammenfassung
37
Anwendungen mit
Datenbanken
GUI
GUI
AnwendungsProgrammODBC
ProgrammPakete
GUI
AnwendungsProgrammODBC
ProgrammPakete
Prozedurale
SQL-Erweiterungen
Embedded SQL
(c) schmiedecke 06
DB15 - Zusammenfassung
38
Was ist ODBC?
•
Open Data Base Connectivity
•
Funktioniert als Vermittlungsschicht zwischen
DBMS und Anwendungsprogramm:
– generische Programmierschnittstelle (API) zur Interaktion mit einer (beliebigen)
SQL-Datenbank
– ODBC: Microsoft-Entwicklung
– Normierung als CLI/SQL
– Implementierungen heißen ODBC-Treiber
– Von praktisch allen relationalen DBMS implementiert ("ODBC-Datenbanken")
– Treiber Bestandteil von Windows ab Windows 2000/NT
– Herstellung und Verwaltung der DB-Verbindung
– "Versand" von SQL-Anweisungen
(incl. Datenkonvertierung)
– "Empfang" von SQL-Ergebnissen und
Fehlermeldungen
Anwendung
ODBC
DBMS
(c) schmiedecke 06
DB15 - Zusammenfassung
39
Was ist SQLJ?
• SQLJ ist eine SQL-Einbindung in die Programmiersprache Java
als SQL (nicht als String).
• Verwendung eines SQL-Precompilers
• Syntax: SQL-Anweisungen beginnen mit
#sql und sind in { } eingeschlossen.
public String findBook (String isbn)
throws SQLException {
String title;
#sql { Select title into :title From book
Where isbn = :isbn };
return title;
}
(c) schmiedecke 06
DB15 - Zusammenfassung
40
Objektrelationale Erweiterungen
• NF2 – Non First Normal Form
–
–
–
–
Mengenwertige Attribute
LOBs
Tabellenwertigen Attribute
Typdefinition
• ORDB – Objekt-relationale Datenbank
–
–
–
–
Typhierarchie und Vererbung
Objektidentität
Operationsdefinition
(Polymorphie)
(c) schmiedecke 06
DB15 - Zusammenfassung
41
...das war doch eine Menge Stoff...
...den Sie jetzt "drauf haben"!