DB2-DBMS-Typen - schmiedecke.info

1. Einführung:
1.2 Typen von DBMS
Auswertung der Praxis
Dieselbe DB auf 3 verschiedenen DBMS
Bis auf kleinere Unterschiede (z.B. Literale) egal, womit man
arbeitet
Äquivalent:
Gleiches Datenmodell (Relationale Datenbanken)
Ist das Datenunabhängigkeit?
– Sogar auf höherer Stufe...
– Dank SQL-Normung sogar unabhängig vom DBMS
– In der Praxis werden Prototypen oft mit einem einfachen
(kostenlosen) DBMS entwickelt und dann auf das ProduktionsDBMS migriert.
Datenunabhängigkeit setzt früher an:
– Unabhängigkeit der Anwendung von der logischen und physischen
Datenstruktur – und umgekehrt.
© schmiedecke 06
DB2 – DBMS-Typen
2
Datenhaltung in Dateien
Anwendung
Anw. 1
Datenbestand
der Anwendung
1
2
Anw. 2
Anw. 3
Daten in
1-5
Datum 1
Datum 2
Datum 3
3
• Logische Datenstruktur im
Anwendungsprogramm
"verdrahtet"
• Physische Abbildung auf
Dateiformat im Anwendungsprogramm "verdrahtet"
4
5
© P.Sauer
Änderung im Programm
Änderung der Dateistruktur
Gegenseitige Gefährdung der
Anwendungen
© schmiedecke 06
DB2 – DBMS-Typen
3
Datenhaltung in Gemeinsamer Datenbasis
• Vereinbarte Datenstruktur
• evtl. gemeinsame externe
Spezifikationsdatei
Anw. 1
Anw. 2
Datenbasis
Anw. 3
• Vereinbartes Speicherund Dateiformat
• evtl. Abstraktion durch
Lese-Schreib-Werkzeug
I/O
Anw. n
© schmiedecke 06
Spez.
Durch Auslagerung von
Datenstrukturbeschreibung
und Dateizugriff wächst die
Datenunabhängigkeit
DB2 – DBMS-Typen
4
DBMS
Anw. 1
Anw. 2
DBMS
Anw. 3
Datenbasis
DD.
Anw. n
• Gemeinsamer Zugriff auf
änderbare formale
Beschreibung der
logischen Datenstruktur
(DD) in genormten
Datenmodell ("logisches
Schema")
• Zugriff auf die physischen
Daten nur über die
abstrakte logische Struktur
Programme sind
unabhängig von der
logischen und physischen
Strukturierung der Daten
© schmiedecke 06
DB2 – DBMS-Typen
5
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 Anwendungprogramme 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.
© schmiedecke 06
DB2 – DBMS-Typen
6
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, ...)
© schmiedecke 06
DB2 – DBMS-Typen
7
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)
© schmiedecke 06
DB2 – DBMS-Typen
8
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.
© schmiedecke 06
DB2 – DBMS-Typen
9
Datenbestand Keramische Werkstatt
Bestellungen:
• Datum
• Name
• Strasse
• PLZ, Ort
• Produktbez.
• Preis
• Anzahl
Kunden:
• Name
• Strasse
• PLZ, Ort
• Konto
Marktstände:
• Markt
• Produkte
• Bestellungen
• Umsatz
• Erlös
Märkte:
• Ort
• Veranstalter
Lagerposten:
• Termin
• Produkt
• Charge
• Anzahl
Rohstoffe:
•Bezeichnung
•Lieferant
•Preis
Produkte
• Bezeichnung
• Größe
• Glasur
• Dekor
• Preis
Buchhaltung
Lagerverwaltung
Werbung
Materialeinkauf
© schmiedecke 06
DB2 – DBMS-Typen
10
Hierarchisches Datenmodell
Datenstruktur
Betrieb
Name
Anschrift
Re-Nr
Anzahl
© schmiedecke 06
Leitung
Status
Status
Nr
Ort
Artikel
Typ
Nr
Gesamtpreis
Glasur
Dekor
Dekor
Artikel
Glasur
Preis
Einzelpreis
DB2 – DBMS-Typen
11
Hierarchisches Datenmodell
Beispiel-Datensätze
Keram.Werkstatt
Max Mayr
Max
Hansen
206
Hanne
30
grau
Privatkunde
Jürgens
Bestellung
31
ohne
grau
Fisch
Galerist
164,40
3016
Teller
6,15
3017
Schale
12,10
3025
Teekanne
50,75
2
3125
Teekanne
grau
Fisch
53,70
6
3016
Teller
grau
ohne
6,15
6
3117
Schale
grau
Fisch
12,30
Kauf
60
Schmidt
Großhändler
Joseph
217
Lindau
361,80
2816
© schmiedecke 06
Teller
blau
Möve
6,30
DB2 – DBMS-Typen
12
Hierarchisches Datenmodelle
Diskussion
Charakteristika:
historisch erstes Modell(1969 IMS)
Datenstrukturen als Bäume
Navigation entlang des Baumes zum Zugriff
Realisierung der Zusammenhänge durch Zeiger (typischerweise)
Vorteile:
günstig für 1:N-Beziehungen (z.B. Stücklisten, Personaldateien, ...)
Abfragen, die den Baumstrukturen folgen, sehr effizient und schnell
einfache Speicherstrukturen (sequentiell)
Nachteile:
Redundanz
M:N-Beziehungen direkt nicht darstellbar -> Auflösung in 2x 1:NBeziehungen
Änderungen sehr aufwendig
“Quer”-abfragen nicht unmittelbar möglich
© schmiedecke 06
DB2 – DBMS-Typen
13
Netzwerkdatenmodell
Datenstruktur
Betrieb
Name
Anschrift
Re-Nr
Status
Ort
Leitung
Status
Typ
Gesamtpreis
Dekor
Nr
Artikel
Glasur
Preis
Anzahl
© schmiedecke 06
DB2 – DBMS-Typen
14
Netzwerk-Datenmodell
Beispiel-Datensätze
Keram.Werkstatt
Max Mayr
Max
Hansen
217
206
Bestellung
Kauf
Großhändler
Hanne
Joseph
Lindau
Schmidt
30
Privatkunde
Jürgens
grau
31
ohne
grau
Fisch
Galerist
164,40
3016
Teller
6,15
3017
Schale
12,10
3025
Teekanne
50,75
2
3116
Teller
6,30
6
3117
Schale
12,80
6
3125
Teekanne
53,60
361,80
20
© schmiedecke 06
DB2 – DBMS-Typen
15
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”
© schmiedecke 06
DB2 – DBMS-Typen
16
Das Relationale Datenmodell
Struktur und Beispiel-Datensätze
Geschäftspartner
$
',
& #( )
$)
*
+
,
-
#
'
+
-
.
+
/
)
0& 1
Märkte
!
!
&
*
'
&
'
"#$
%
&
!'
#( )
)+
Wird angeboten auf
%
(
%
!
'
#( )
'
#( )
'
#( )
'
Produkte
!
%
#
#
$
#
$
)+
Struktur
Daten
"
#
© schmiedecke 06
$
DB2 – DBMS-Typen
17
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
© schmiedecke 06
DB2 – DBMS-Typen
18
Das objektorientierte Datenmodell
Struktur
Betrieb
-Name
-Ort
-Geschäftsführung : Geschäftspartner
*
1
1..*
1
Geschäftspartner
-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()
© schmiedecke 06
Serie
Produkt
Auftragsposition
-Anzahl
1
1..*
DB2 – DBMS-Typen
19
Das objektorientierte Datenmodell
Beispieldatenstruktur
KeramischeWerkstatt : Betrieb
Name = KeramWerkstatt
Ort = Lindau
Geschäftsführung : Geschäftspartner
Teller : Produkt
MaxMayr : Geschäftspartner
Name = Max Mayr
Anschrift = Dorfkern7 Lindau
Status = Großhändler
107720 : Auftrag
Datum = 10-08-06
Status = gekauft
Gesamtpreis = 381,80
HanneHansen : Geschäftspartner
Pos1 : Auftragsposition
Name = Hanne Hansen
Anschrift = ImWald 9 Serrau
Status = Privatkunde
Anzahl = 20
JosephJürgens : Geschäftspartner
Name = Joseph Jürgens
Anschrift = Markt22 Karmen
Status = Galerist
© schmiedecke 06
118833 : Auftrag
Datum = 02-09-06
Status = bestellt
Gesamtpreis = 164,40
DB2 – DBMS-Typen
Artikelnr
Bezeichnung
Preis
KlSchale : Produkt
Artikelnr
Bezeichnung
Preis
Serie30 : Serie
Typ = 30
Dekor = ohne
Glasur = grau
Seria31 : Serie
Typ = 31
Dekor = Fisch
Glasur = grau
Schale : Produkt
Artikelnr = 3117
Bezeichnung = Schale gr.
Preis = 13,09
20
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 06
Handhabung zwar kompliziert, DB2
aber– DBMS-Typen
zunehmend etabliert
Frameworks.
21
Beispiel für direkte OODB-Anbindung
durch Persistenz-Framework
public persistent class Produkt {
public persistent int Artikelnr;
public persistent String Bezeichnung;
public persistent double Preis;
public static double MwSt;
// ...
public atomic void PreisAendern(double Preis)
{ ... }
// ...
}
© schmiedecke 06
DB2 – DBMS-Typen
22
Physische Datenmodelle
Regeln die Abbildung der logischen Struktur auf Speichermedien
– Implementierbarkeit durch Referenzmodelle gesichert
– in Anwendungsfall oft Optimierungsbedarf
Kriterien: Zugriffs- und Platzeffizienz
Datenschutz und Datensicherheit
Immer mehrere Ebenen:
– Abbildung im Speicher
– Ablage auf externen Medien (Platte, früher auch Band)
Oft Gesamtredundanz (RAID-Systeme)
Konzepte zur Datensicherung/Archivierung/Versionierung
Konzepte zur Transaktionssicherung
© schmiedecke 06
DB2 – DBMS-Typen
23
Administration und Tuning
Administrator kann das physische Modell beeinflussen:
Beispiele aus Relationalen Datenbanken:
– Wahl zwischen Implementierungsmodellen
(z.B. MySQL: ISAM, MyISAM, MERGE, HEAP, BerkeleyDB,
InnoDB)
– Caching-Verhalten (HEAP!)
– Initial- und Standardgröße von Dateien, Datenblöcken, Pages
– Datei-Organisation: index-sequentiell, Hash, Tree
– Dateiformat:
- CSV, binär, XML, proprietär ....
– Tabellen-Indexe zur Zugriffsbeschleunigung
Die Verwaltung von Rechten und Transaktionen erfolgt auf dieser
Abstraktionsebene:
Zugriffe auf Dateien (nicht auf Tabelle und Attribute)
© schmiedecke 06
DB2 – DBMS-Typen
24
Weiter mit SQL....
INNER und OUTER JOIN
Aggregatfunktionen
GROUP und ORDER
Abfragen über mehrer Tabellen (Joins)
SELECT [DISTINCT] Auswahlliste
FROM Quelle1, Quelle2, Quelle3, ...
WHERE Where-Verbundklausel
AND Where-Klausel
;
JOIN nach SQL-86
Intuitive Formulierung nach SQL-86:
!
"
$
© schmiedecke 06
#
"
% &'(
DB2 – DBMS-Typen
26
Abfragen über mehrer Tabellen (Inner Joins)
SELECT [DISTINCT] Auswahlliste
FROM Quelle1 JOIN Quelle2
ON Where-Verbundklausel
AND Where-Klausel
;
JOIN nach SQL-92
Benutzung des JOIN-Operators:
) *
"
$
#
"
% &'(
Vereinfachungen bei gleichen Spaltennamen und evtl. Eindeutigkeit
) *
+ * ,
!
% &'(
+
!
© schmiedecke 06
) *
% &'(
DB2 – DBMS-Typen
27
Abfragen über mehrer Tabellen (Outer Joins)
SELECT [DISTINCT] Auswahlliste
FROM Quelle1 OUTER JOIN Quelle2
ON Where-Verbundklausel
AND Where-Klausel
;
JOIN nach SQL-92
OUTER JOIN bedeutet, dass auch Zeilen gelistet werden, für die die
Verknüpfung nicht gilt – ggf. mit NULL-Wert für die fehlenden Attribute:
+
"
) *
#
"
+
"
© schmiedecke 06
#
(
) *
-1
"
DB2 – DBMS-Typen
..
23
..
/
4
0
5 .6 7 0
"
0
(
28
Aggregatfunktionen
Funktionen, die eine Spalte zu einem Wert aggregieren:
2 (
2 .*"
2
(/
2
2 "
SELECT-Anweisungen mit Aggregatfunktionen aggregieren eine
Tabelle zu einer Zeile
– meistens nur eine Spalte selektiert
© schmiedecke 06
DB2 – DBMS-Typen
skalares Ergebnis
29
Aggregatfunktionen
SELECT Funktion1(Spalte1), Funktion2(Spalte2),...
FROM Quelle
WHERE Where-Klausel
;
Zeilenwertiges Select
SELECT Funktion (Spalte)
FROM Quelle
WHERE Where-Klausel
;
Skalares Select
8 , 9,
:
!
;
.
<=
."! 5 7 ; 8 , 9* 7 . :
<(
;
."* 7 . ; 8 , 9
0
1
:
0
;
."
;
0
%
* 9
:
2
!
© schmiedecke 06
.
<=
3
<(
DB2 – DBMS-Typen
30
Aggregatfunktionen
!
+
9
(
+
9?:
(
;
+
9?:
;
$
© schmiedecke 06
# ;
:
;
5> ;
4
5> ;
7.
.
;
.;(
DB2 – DBMS-Typen
31
Gruppieren
SELECT Funktion1(Spalte1), Funktion2(Spalte2),...
FROM Quelle
WHERE Where-Klausel
GROUP BY Spalte ;
SELECT Funktion1(Spalte1), Funktion2(Spalte2),...
FROM Quelle
WHERE Where-Klausel
GROUP BY Spalte
HAVING Bedingung;
$
,
8, 9
+
@ $
:
;
."
Gruppiertes Aggregat
Gruppiertes Teil-Aggregat
0
;
$
(
!
$
8, 9
:
;
."
;
0
,
+
@ $
! 8* , , .
© schmiedecke 06
$
.
;=
= ;(
DB2 – DBMS-Typen
32
Sortieren
SELECT Spalten
FROM Quelle
WHERE Where-Klausel
GROUP BY Spalte [DESC | ASC];
oder: ORDER BY Spalte [DESC | ASC]
GROUP BY sortiert
ORDER BY sortiert
SELECT Funktion1(Spalte1), Funktion2(Spalte2),...
FROM Quelle
WHERE Where-Klausel
GROUP BY Spalte-n
HAVING Bedingung
ORDER BY Spalte-m;
Gruppiert, aggregiert und
sortiert dann um.
0
$
,
+
$
, .
@ $
@ ;
© schmiedecke 06
8, 9
."
;$
:
;
."
;
$
!
(
DB2 – DBMS-Typen
"
33