Vorlesung 10

WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
Vorlesung #10
Physische Datenorganisation
„Fahrplan“
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 60 Minuten #10, 30 Minuten #11
 Einführung und Motivation
 Trennung der logischen und der physischen
Ebene einer Datenbank
 Speichermedien (Platten, RAID usw.),
Speicherhierarchien (Cache, Hauptspeicher,
Hintergrundsspeicher usw.)
 Abbildung von Relationen auf den
Hintergrundsspeicher
 Unterstützung eines Anwendungsverhaltens
 Physische Datenorganisation in SQL
 Fazit
© Bojan Milijaš, 07.12.2012
Einführung und Motivation
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 Die Benutzung und somit die Akzeptanz einer Datenbank wird
maßgeblich durch die Antwortzeiten des Systems bestimmt.
 Selbst eine sehr gut modellierte Datenbank(anwendung) wird
von Benutzern nicht akzeptiert, wenn sie langsam ist.
 Eine effiziente physische Organisation der Daten und der
Zugriffe ist die Voraussetzung für akzeptable Datenbanken.
 Physische Organisation der Daten muss unabhängig von
logischen Schema-Veränderungen bleiben, um SystemÄnderungen und vor allem System-Wachstum effizient
unterstützen können. Man hat die Wahl zwischen mehreren
physischen Entwürfen und kann das Optimale wählen.
 Die heute marktbeherrschenden (objekt)relationalen
Datenbanken haben sich auch dank effizienter physischen
Implementierung und der strikten Trennung zwischen der
logischen und der physischen Ebene durchgesetzt.
© Bojan Milijaš, 07.12.2012
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
Externes
Schema
- Sicht 1
Physische
Ebene
Logische Ebene
Wiederholung: DBMS
3 -Abstraktionsebenen
© Bojan Milijaš, 07.12.2012
Externes
Schema
- Sicht 2
Externes
... Schema
- Sicht n
Konzeptionelles
Schema
Physische Speicherung
– internes Schema
3 Abstraktionsebenen
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 Ebene 1 (externe): Sichten – Datenbank
VIEWs
 Ebene 2 (konzeptionelle) : Relationen–
Datenbank Tabellen mit ihren logischen
Attributen
 Ebene 3 (interne): Datenstrukturen bzw.
Speicherstrukturen – Datenbank Tabellen mit
ihren physischen Attributen
© Bojan Milijaš, 07.12.2012
Externes
Schema
- Sicht 1
Physische
Ebene
Logische Ebene
DBMS –
3 Abstraktionsebenen
© Bojan Milijaš, 07.12.2012
Externes
Schema
- Sicht 2
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
...
Konzeptionelles
Schema
Physische Speicherung
– internes Schema
Externes
Schema
- Sicht n
Beispiel: logische und
physische Datenunabhängigkeit
Studenten
Logische Ebene
CREATE VIEW ProfVorlesung
AS
SELECT Name, Titel
FROM Professoren, Vorlesungen
WHERE PersNr = gelesenVon;
Internet-Besucher
CREATE VIEW ProfVorlesung
AS SELECT Name, Titel
ProfVerlesung
FROM Dozenten
NATURAL JOIN lesen
NATURAL JOIN Kurse;
Professoren Vorlesungen
Physische
Ebene
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
lesen
Kurse
Dozenten
IOT lesen
PT lesen CT lesen,Kurse
© Bojan Milijaš, 07.12.2012
Erläuterung zum Beispiel
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 Man hat mehrere Möglichkeiten, eine
Relation („logische“ Tabelle mit ihren
Attributen) als eine „physische“ oder DBMSTabelle zu implementieren. Die Abkürzungen
bedeuten (keine Standard-Abkürzungen)




IOT – Index Organized Table
HT – Heap Table
CT – Clustered Tables
PT – Partitioned Tables
 SQL Code Beispiele am Ende der Vorlesung!
© Bojan Milijaš, 07.12.2012
Speichermedien und
Speicherhierarchien
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 Es gibt eine Zugriffslücke 105 zwischen dem
Haupt- und dem Hintergrundsspeicher, die
vor allem an mechanische Vorgänge
innerhalb eines Plattenstapels
zurückzuführen ist
 RAID Systeme sind fehlertoleranter und
performanter als einzelne Platten
... weiter Folien Kemper 7.2 – 7.22
© Bojan Milijaš, 07.12.2012
Puffer-Verwaltung
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 Hauptspeicher ist nicht nur viel schneller
sondern auch viel kleiner als
Hintergrundsspeicher  nicht genug Platz für
alle Seiten
 Ständiges Ein-/ und Auslagern der Seiten mit
dem Ziel möglichst viele aktuelle oder in der
nächsten Zukunft gebrauchte Seiten im
Hauptspeicher bereit zu halten
... Kemper 7.24 – 7.25
© Bojan Milijaš, 07.12.2012
Abbildung von Relationen auf
den Sekundarspeicher
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 Die Tupel einer Relation (Zeilen, Rows)
werden so abgespeichert, dass sie nicht über
die Grenzen einer Seite hinausgehen.
 Jeder Tupel enthält eine Tupel-ID, jede Seite
eine interne Datensatztabelle
 Beim Wachstum der Tupel muss reorganisiert
d.h auf andere Seiten umgezogen werden
... Kemper 7.26 – 7.29
© Bojan Milijaš, 07.12.2012
Indexstrukturen
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 ISAM – Index Sequential Access Method
 Vom Prinzip her wie ein Daumenindex eines
Wörterbuchs mit Indexseiten und Datenseiten
 Schlechtes Verhalten bei UPDATE Operationen
 Hinzufügen einer weiteren Indirektion (eines
weiteren Zeigers)  B-Bäume
© Bojan Milijaš, 07.12.2012
Unterstützung des
Anwenderverhaltens
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 Für unterschiedliche Arten von Abfragen und/oder
Veränderungsoperationen eignen sich
unterschiedliche Zugriffstechniken unterschiedlich gut
 Beispiel: Exact Match Query vs. Range Query
--exact
SELECT Name
Besser mit Hashing!
FROM Professoren
WHERE PersNr = 4711;
-- range
SELECT Name
+Baum!
Besser
mit
B
FROM Professoren
WHERE Gehalt BETWEEN 40000 AND 50000;
© Bojan Milijaš, 07.12.2012
WS 2012/13
Unterstützung des
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
Anwenderverhaltens (2)
 Es gibt noch weitere Möglichkeiten, die
Zugriffe bzw. Speicherung der Daten
effizienter zu gestalten
 BITMAP und BITMAP JOIN Index
 nur für lesende Zugriffe
 wird bei Data Warehousing vorgestellt
 Partitionierung
 Tabelle wird in unterschiedliche Partionen
aufgeteilt, die unterschiedlich voneinander
physikalisch verwaltet werden können
 wird bei verteilten Datenbanken vorgestellt
© Bojan Milijaš, 07.12.2012
Physische Dateiorganisation
in SQL
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 So gut wie keine Standardisierung
CREATE INDEX SemesterInd ON
Studenten(Semester);
DROP IINDEX SemesterInd;
 Zu beachten sind die Eigenschaften des jeweiligen
DBMS, so legt z.B. Oracle für jedes
Primärschlüsselattribut automatische einen Index an
© Bojan Milijaš, 07.12.2012
Physische Dateiorganisation
in ORACLE
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
(2 von ca. 60 Klauseln)
CREATE TABLE { segment_attributes_clause [
data_segment_compression ]
| ORGANIZATION
{ HEAP [ segment_attributes_clause ] [
data_segment_compression ] |
INDEX [ segment_attributes_clause ]
index_org_table_clause |
EXTERNAL external_table_clause } |
CLUSTER cluster ( column[, column ]... ) }
physical attributes clause:
[{ PCTFREE integer | PCTUSED integer | INITRANS integer |
MAXTRANS integer | storage_clause } [ PCTFREE integer |
PCTUSED integer | INITRANS integer |
MAXTRANS integer | storage_clause ]... ]
© Bojan Milijaš, 07.12.2012
Fazit
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
 Bedeutung der strikten Trennung der logischen und
physischen Ebene einer Datenbank und deren
positive Auswirkung auf die Performance und
Flexibilität der Datenbank
 Speichermedien (RAM, Platte, RAID, Bänder)
 Speicherhierarchien, Zugriffslücke, Notwendigkeit der
Pufferverwaltung
 Ideen für die Unterstützung des Anwenderverhaltens
 (so gut wie keine) SQL Standards
© Bojan Milijaš, 07.12.2012
WS 2012/13
Datenbanksysteme
Mi 15:15 – 16:45
R 2.007
Vorlesung #9
Ende