WS 2014/15 Datenbanksysteme Do 17:00 – 18:30 R 0.005 Vorlesung #11 Physische Datenorganisation

WS 2014/15Datenbanksysteme

Do 17:00 – 18:30R 0.005

Vorlesung #11

Physische Datenorganisation


Do 17:00 – 18:30R 0.005

„Fahrplan“

60 Minuten #11, 30 Minuten #12 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š, 11.12.2014 Vorlesung #11 - Physische Datenorganization 2


Do 17:00 – 18:30R 0.005

Einführung und Motivation

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.



Do 17:00 – 18:30R 0.005

Wiederholung: DBMS 3 -Abstraktionsebenen

...Externes Schema - Sicht 1

Externes Schema - Sicht 2

Externes Schema - Sicht n

Konzeptionelles Schema

Physische Speicherung – internes Schema

Logi

sche

Ebe

neP

hysi

sche

E

bene



Do 17:00 – 18:30R 0.005

3 Abstraktionsebenen

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



Do 17:00 – 18:30R 0.005

DBMS – 3 Abstraktionsebenen

...Externes Schema - Sicht 1

Externes Schema - Sicht 2

Externes Schema - Sicht n

Konzeptionelles Schema

Physische Speicherung – internes Schema

Phy

sisc

he

Ebe

neLo

gisc

he E

bene



Do 17:00 – 18:30R 0.005

Beispiel: logische und physische Datenunabhängigkeit

Internet-BesucherStudenten

ProfVerlesung

Dozentenlesen Kurse

CREATE VIEW ProfVorlesungCREATE VIEW ProfVorlesung AS SELECT Name, TitelAS SELECT Name, Titel FROM DozentenFROM Dozenten NATURAL JOIN lesenNATURAL JOIN lesen NATURAL JOIN Kurse;NATURAL JOIN Kurse;

CREATE VIEW ProfVorlesungCREATE VIEW ProfVorlesung

ASAS

SELECT Name, TitelSELECT Name, Titel

FROM Professoren, VorlesungenFROM Professoren, Vorlesungen

WHERE PersNr = gelesenVon;WHERE PersNr = gelesenVon;

Professoren Vorlesungen

IOT lesenPT lesen CT lesen,Kurse

Phy

sisc

he

Ebe

neLo

gisc

he E

bene



Do 17:00 – 18:30R 0.005

Erläuterung zum Beispiel

Man hat mehrere Möglichkeiten, eine Relation („logische“ Tabelle mit ihren Attributen) als eine „physische“ oder DBMS-Tabelle 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!



Do 17:00 – 18:30R 0.005

Speichermedien und Speicherhierarchien

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



Do 17:00 – 18:30R 0.005

Puffer-Verwaltung

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



Do 17:00 – 18:30R 0.005

Abbildung von Relationen auf den Sekundarspeicher 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



Do 17:00 – 18:30R 0.005

Indexstrukturen

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



Do 17:00 – 18:30R 0.005

Unterstützung des Anwenderverhaltens Für unterschiedliche Arten von Abfragen und/oder

Veränderungsoperationen eignen sich unterschiedliche Zugriffstechniken unterschiedlich gut

Beispiel: Exact Match Query vs. Range Query--exactSELECT Name FROM ProfessorenWHERE PersNr = 4711;-- rangeSELECT NameFROM ProfessorenWHERE Gehalt BETWEEN 40000 AND 50000;

Besser mit Hashing!

Besser mit B+Baum!



Do 17:00 – 18:30R 0.005

Unterstützung des 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



Do 17:00 – 18:30R 0.005

Physische Dateiorganisation in SQL 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



Do 17:00 – 18:30R 0.005

Physische Dateiorganisation in ORACLE(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 ]... ]



Do 17:00 – 18:30R 0.005

Fazit

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



Do 17:00 – 18:30R 0.005

Vorlesung #11

Ende

Documents

WS 2014/15 Datenbanksysteme Do 17:00 – 18:30 R 0.005 Vorlesung #11 Physische Datenorganisation