Physische Datenorganisation · • einfache Suche Nachteile: • optionale Felder in jedem Satz • Felder variabler Länge müssen mit maximaler Länge gespeichert werden. Datenmodellierung

Datenmodellierung Physische Datenorganisation 1

TU Wien

tion

Abt. f. Datenbanken und Artificial Intelligence Institut für Informationssysteme

Physische Datenorganisa


TU Wien

Zielvorstellung

Sätzen bestehen.


Speichern von Dateien, die aus einzelnen


TU Wien

INHALT


1. Sätze und Blöcke

2. Arten der Primärorganisation

3. Arten der Sekundärorganisation

4. Speicherstrukturen für Relationen

5. Join-Algorithmen


Abt. f. Datenbanken und Artificial Intelligence Institut für Informationssysteme TU Wien

1. Sätze und Blöcke

(a) Felder und Blöcke

(b) Sätze mit konstanter bzw. variabler Länge

(c) Aufteilung der Sätze auf Blöcke

(d) Zugriff auf Sätze


TU Wien

(a) Felder und Blöcke

ür die physische

en

tensatz

. 3


Sätze bestehen aus Feldern und werden fSpeicherung auf Blöcke verteilt.

Blöcke bestehen aus:

(a) Header: speichert Kontrollinformation

(b) Teilblöcke: enthalten jeweils einen Da

Header Teilb. 1 Teilb. 2 TeilbBlock


TU Wien

(b) Sätze mit konstanter und variabler Länge

4

8


Konstante Länge:

Variable Länge:

Satz 1 Satz 2 Satz 3 Satz

Satz 5 Satz 6 Satz 7 Satz

Block 1

Block 2

Satz 1 Satz 2 Satz 3 Satz 4

Satz 5 Satz 6 Satz 7

Block 1

Block 2


TU Wien

Sätze mit konstanter Länge

ximaler Länge


Vorteil:

• einfache Suche

Nachteile:

• optionale Felder in jedem Satz

• Felder variabler Länge müssen mit magespeichert werden


TU Wien

Sätze mit variabler Länge

gespeichert wer-

erden

ndig


Vorteile:

• Sätze unterschiedlicher Länge könnenden

• Optionale Felder können gespeichert w

Nachteile:

• Fragmentierung, Reorganisation notwe (Defragmentierung)

• Höherer Suchaufwand


TU Wien

(c) Aufteilung der Sätze auf Blöcke

Satz 4

Satz 8

P

P


Unspanned Records:

Spanned Records:



Block 1

Block 2

Satz 1 Satz 2 Satz 3 Satz 4

Satz 4 (Rest) Satz 6 Satz 7

Block 1

Block 2


TU Wien

Unspanned Records


Vorteile:

• Ein Satz ist in genau einem Block

• Einfache Verwaltung

Nachteile:

• Satzlänge ≤ Blocklänge

• Platzverlust


TU Wien

(d) Zugriff auf Sätze

sel


Grundlegende Zugriffsarten:

• Finden eines Satzes

• Einfügen eines Satzes

• Löschen eines Satzes

Der Zugriff erfolgt

• über den Schlüssel oder

• über die vollständige Adresse oder

• über die Blockadresse und den Schlüs


TU Wien

Pinned Records

r


Seite Offset Meie


TU Wien

Im Block verschiebbare Datensätze


SEITE SCHLÜSSEL

MEIERMEIER

HEADER


TU Wien

Tuple Identifiers (TID’s - System R)

z R


TIDfür R

Sat

Seite P

SeiteNr.

Position innerhalbder Seite


TU Wien

Vereinfachende Annahmen

hl von Feldern

Zugriff auf Blöcke

ltet unbenutzte


• Ein Satz besteht aus einer festen Anza

• Schlüssel analog Relationenmodell

• Blockzugriff über Blockadresse

• Das Speicherverwaltungsystem bietetbestimmter Größe

• Das Speicherverwaltungsystem verwaund gelöschte Blöcke


TU Wien

Primär- und Sekundärorganisation

auptdatei (en-truktur

Zugriffsstruktur


• Primärorganisation: Organisation der Hthält die Daten) und der Hauptzugriffss

• Sekundärorganisation: Eine alternativeneben der primären Zugriffsstruktur


TU Wien

2. Arten der Primärorganisation


(a) Ungeordnete Dateien

(b) Indexsequentiell

(c) Clustered

(d) Hashorganisation

(e) B*-Baum


TU Wien

(a) Ungeordnete Datei


• Einfügen

• Suchen

• Löschen

6 3 5 4 18


TU Wien

(b) Indexsequentiell

nten Zugriff nach


2 Dateien:

• Hauptdatei: enthält die Datensätze

• Indexdatei: ermöglicht einen effiziedem Schlüssel


TU Wien

Speicherungsalternativen - Hauptdatei

.............

.............

.............

.............


.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

.............

(a)

(b)

(c)

.............

.............

.............

.............


TU Wien

Index

atei, deren Sätzeer Schlüsselwertw. die Block-

atei (main file)

ro Block → weni-

Dateien) odern)


Def.: Ein Index I zu einer Datei D ist eine DPaare der Form (vi,bi) darstellen, wobei vi deines Satzes in D ist und bi die Adresse bzadresse dieses Satzes. D wird als Hauptdbezeichnet.

Motivation:

• Indexeintrag kleiner → mehr Einträge pger Lesezugriffe → schnellere Suche!

• Einsatz als Primärindex (bei sortiertenSekundärindex (bei unsortierten Dateie


TU Wien

Einfügen - Indexsequentiell

9


Index

1

11

731

11 12

Einfügen: 14, 13

19 19 20

14

13


TU Wien

Suchen - Indexsequentiell

9

4


Index

1

11

19

731

11 12

19 20

13 1


TU Wien

Löschen - Indexsequentiell

9

4


Index

1

11

731

11 12 13 1

Löschen: 19, 20

19 19 20

20 20


TU Wien

(c) Clustered

ung

chlüssel sortiert indiziertenhiedlichen

r indexsequentiel-


• Abart der indexsequentiellen Speicher

• Hauptdatei ist nicht nach dem Primärs(Sortierung nach “Schlüsselfeld”) → dieFelder der Hauptdatei dürfen in unterscSätzen den gleichen Wert annehmen

• Einfügen, Suchen, Löschen wie bei delen Form


TU Wien

Clustered

EBDAT GEHALT


1112

2333

3344

5555

6666

ABTNR NAME SVNR BERUF G

(INDIZIERTESFELD)

DATEI

6888

1

2

3

4

5

6

8

INDEXDATEI

INDEXFELD

BLOCKZEIGER

( <K(i), P(i)> eintrag )


TU Wien

Clustered

H.

NIL

NIL

NIL

NIL

NIL


ABTNR NAME SVNR BERUF GEB. GE

(INDIZIERTESFELD)

DATEI

12345

INDEXDATEI

INDEXFELD

BLOCKZEIGER

( <K(i), P(i)> eintrag )

111

22

3333

3

44

5555

Blockzeiger

Blockzeiger

Blockzeiger

Blockzeiger

Blockzeiger

Blockzeiger


TU Wien

Clustern mehrerer Dateien

chiedenen Rela-Feldern (cluster-cken gespeichert.

nur einmal ges-

bei Abfragen notwendig


Clustern mehrerer Dateien: Tupel aus verstionen mit gleichen Werten in bestimmten ing attributes) werden in benachbarten Blö

Vorteile:

• prejoin → Abfragen schneller

• geringerer Speicherbedarf - Feld wird peichert

Nachteil:

Relation wird auf mehrere Blöcke verteilt →innerhalb einer Relation sind mehr Zugriffe



(d) Hashorganisation

• Allgemeines

• Hashfunktion

• Einfügen und Suchen

• Externes Hashen:Dynamisches, erweiterbares und lineares Hashen


TU Wien

Allgemeines

wendet, dasalb der Datei.

ets aufgeteilt

hreren Blöcken

verteilt” sein

rsten Block eines


Auf den Schlüssel wird eine Funktion angeErgebnis ist die Position des Satzes innerh

• Die Sätze einer Datei werden auf Buck

• Ein Bucket besteht aus einem oder me

• Die Hashfunktion soll “wirr” und “gleich

• Die Hashtabelle zeigt jeweils auf den eBuckets


TU Wien

Hashfunktion

nn möglich eine


H(s) = s mod nmax

s: Schlüssel

nmax: höchster erwünschter Hashwert, wePrimzahl

Hashfunktion für Beispiel:

H(s) = s mod 2


TU Wien

Einfügen - Hashorganisation

6


tabelle48

15 11

Hash-

0

1

Buckets

12

Einfügen: 13, 16

13

16


TU Wien

Suchen - Hashorganisation

6


tabelle48

15 11

Hash-

0

1

Buckets

12

16


TU Wien

Hashorganisation

endige Reorgani-r anderen Hash-

hing)

ashing)

hl betrachtet


Nachteil: Dateigröße kann nur durch aufwsation geändert werden (Verwendung einefunktion)

Abhilfe: externes Hashen

1. Dynamisches Hashen (dynamic has

2. Erweiterbares Hashen (extendible h

3. Lineares Hashen (linear hashing)

Voraussetzung: Schlüssel wird als Binärza


TU Wien

Dynamisches Hashen

S


0

0

0

1

1

1

0

0

1

1

DIRECTORY

interner Knoten

BlattknotenDATENBUCKET


TU Wien

Dynamisches Hashen

xakt den tatsäch-

ung der Baum-

ilten Hash-Funk-aum


Vorteil:

• Die Dateigröße paßt sich schnell und elichen Anforderungen an

Nachteile:

• Zusätzlicher Aufwand für die Speicherstruktur

• Bei Verwendung einer nicht gleichvertetion entsteht ein schlecht balanzierter B


TU Wien

Erweiterbares HashenKETS


d’=3

d’=3

d’=2

d’=2

d’=3

d’=3

000001010011100101110111

DATENBUC

lokale Tiefe

Tiefe d = 3


TU Wien

Erweiterbares Hashen

ls beim dyna-

rgleichsweiseße an


Vorteil:

• Der Verwaltungsaufwand ist geringer amischen Hashen

Nachteil:

• Das Hash-Directory paßt sich nur in vegroßen Sprüngen von überlinearer Grö


TU Wien

Lineares Hashen

Hashfunktion ver-

plexen Algorith-

funktion (viele


Grundgedanke: es wird eine “skalierbare”wendet:

hj(K) = K mod (2jM)

Vorteil:

• Man benötigt keine externe Struktur

Nachteile:

• Hoher Verwaltungsaufwand durch kommus

• Ungünstig bei schlecht verteilter HashÜberläufe)


TU Wien

(e) B*-Baum

eg-Baum dessenn besitzen:

* - 1 sortierte Dat-

und 2k - 1 Index-hfolgeknoten).steht nur aus


Def.: Ein B*-Baum ist ein geordneter VielwKnoten bzw. Blätter folgende Eigenschafte

STRUKTUR:

• Jedes Blatt enthält zwischen k* und 2kensätze

• Alle Blätter liegen auf gleicher Höhe

• Jeder innere Knoten enthält zwischen keinträge (Schlüssel und Zeiger auf NacDer erste Indexeintrag jedes Knoten beeinem Zeiger.



B*-Baum

ORDNUNGSRELATION:

• Der links von einem Schlüssel s gelegene Zeiger zeigtauf einen Block, von welchem man nur zu Datensätzenmit kleinerem Schlüssel als s gelangen kann

• Der rechts von einem Schlüssel s gelegene Zeiger zeigtauf einen Block, von welchem man nur zu Datensätzenmit größerem oder gleichem Schlüssel als s gelangenkann (der Schlüssel s entspricht dem kleinsten Daten-satzschlüssel des rechten Teilbaumes)



B*Baum

41 169 25 196144 225196121100

9 196

256- - - -

--

8164 -

25

36

64

144

100

49



144

1

1 25



Einfügen - B*Baum

41 169 25 196144 225196121100

9 196

256

B5 B6 B7 B9 B10 B11

- - - -

-B2 B3 B4

B1

-

8164

B8

-

25

36

64

144

100

49

Einfügen: 32

4936

B12

-32

100 -B13

36

64

144 -

-

B14

B15


TU Wien

Löschen - B*Baum

169144 225196

196

256

B10 B11

-

-


64

25 144

41 169 3225 4936 121100

9 36 100

B5 B6 B7 B12 B9

- - - - -

--

- -

-

B2 B3 B13 B4

B1 B14

B15

-

8164

B8

-

81 100 121

144 196

81


TU Wien

3. Arten der Sekundärorganisation

n der primären


Def.: Eine alternative Zugriffsstruktur nebeZugriffsstruktur (Primärorganisation)

(a) Index

(b) Hash

(c) B*-Baum


TU Wien

(a) Index

ERUF GEBDAT GEHALT

I


3516

2348

6841

6525

5163

ABTNR NAME SVNR B

(INDIZIERTESFELD)

DATE

6383

...

...

...

...

...

...

...

1

2

3

4

5

6

8

INDEXDATEI

INDEXFELD

BLOCKZEIGER


TU Wien

(b) Hash

uckets Verweise

ashfunktion

ngskriterium ab-

nötigt


Wie Primärorganisation, nur enthalten die Bauf Datensätze

Anwendungsgebiet:

• Es gibt eine gleichverteilte und wirre H

• Es wird immer das vollständige Ordnugefragt

• Es werden keine Bereichsabfragen be


TU Wien

(c) B*-Baum

Blätter Verweise

ldes


Wie Primärorganisation, nur enthalten die auf Datensätze

Anwendungsgebiet:

• bei vielen unterschiedlichen Werten

• bei Abfragen nach Teilen des Index-Fe


TU Wien

Kriterien für die Anwendung

abgefragt werden

den

ne Attributwerte)


Indiziere Attribute

• die oft in WHERE-Klausen vorkommen

• die häufig auf ihr Maximum / Minimum

• die in Join-Operationen verwendet wer

• mit hoher Selektivität (viele verschiede

Indiziere nicht Attribute

• mit geringer Selektivität

• in kleinen Relationen


TU Wien

4. Speicherstrukturen für Relationen

rukturen

erziellen Syste-


(a) Kriterien zur Auswahl von Speicherst

(b) Füllgrad

(c) Zugriffszeitverhalten

(d) Physische Datenorganisation in kommmen



(a) Kriterien: Auswahl v. Speicherstrukturen

• Ungeordnete Dateien

• Indexsequentiell

• Clustered

• Hashorganisation

• B*-Baum


TU Wien

Ungeordnete Dateien

en)

gmentierung)

Sätzen

urch Reorganisa-


Vorteile:

• Schnellstes Einfügen

• Schnelles Löschen (wenn Satz gefund

• Geringer Platzbedarf (ACHTUNG: Fra

Nachteile:

• Langsam bei Suche nach bestimmten

• Langsam bei Bereichsabfragen

• Der Platz gelöschter Sätze kann nur dtion wiederverwendet werden


TU Wien

Ungeordnete Dateien - Anwendungsgebiet

saufwand lohnt

.B. bei statis-

nutzt werden soll


• Kurze Dateien: zusätzlicher Verwaltungsich nicht

• Wenn oft alle Sätze gelesen werden, ztischen Abfragen

• Wenn der Speichersplatz vollständig ge

• Bei Log-Einträgen


TU Wien

Indexsequentiell

-matching, Bere-gen nach Teil-

neue Sätze wer-Suchoperationendige Reorganisa-


Vorteile:

• Gutes Antwortzeitverhalten bei patternichsabfragen, exakten Abfragen, AbfraSchlüsseln

Nachteile:

• Hauptdatei und Index sind statisch → den in Überlaufblöcken gespeichert →werden langsamer. Abhilfe: zeitaufwentionen


TU Wien

Indexsequentiell - Anwendungsgebiet

eoperationen)


• Bei statischen Dateien (wenige Einfüg

• Wenn flexible Abfragen notwendig sind


TU Wien

Clustered - Vorteile


üssel erfolgen

rden → schneller-



• Sortierung muß nicht nach Primärschl

• Mehrere Dateien können verwoben weer Zugriff


TU Wien

Clustered - Nachteile


• Langsamerer Zugriff auf Einzeldatei

• Aufwendiges Einfügen

• Aufwendiges Löschen


TU Wien

Clustered - Anwendungsgebiet

eoperationen)

ft werden


• Bei statischen Dateien (wenige Einfüg


• Wenn Dateien oft miteinander verknüp


TU Wien

Hashorganisation

n Abfragen

gelesen werden

frage nach Teils-


Vorteile:

• Effizientester Zugriff auf Einzelsätze

• Schnellste Zugriffsmethode bei exakte

Nachteile:

• Bei Bereichsabfragen muß jeder Satz

• Keine Sortierung möglich

• Ungünstig bei pattern-matching und Abchlüsseln


TU Wien

Hashorganisation - Anwendungsgebiet

ach Einzelsätzen

nötigt werden


• Wenn überwiegend exakte Abfragen ngestellt werden

• Wenn nur wenig sortierte Abfragen be


TU Wien

B*-Baum - Vorteile

rlaufprobleme

anisation wieder-

-matching, Bere-e nach Teil-

chgeführt werden


• Dynamische Anpassung → keine Übe

• freigewordener Platz kann ohne Reorgverwendet werden

• Gutes Antwortzeitverhalten bei patternichsabfragen, exakte Abfragen, AbfragSchlüssel

• Bereichsabfragen können effizient dur


TU Wien

B*-Baum - Nachteile

etwas langsamer

esperrt werden


• Hoher Verwaltungsaufwand

• Komplexere Zugriffsstruktur → Zugriffals bei indexsequentiell

• Etwas höherer Platzverbrauch

• Baum muß bei gleichzeitigem Zugriff g


TU Wien

B*-Baum - Anwendungsgebiet


- und Löschoper-



• Bei dynamischen Daten (viele Einfügeationen)



TU Wien

(b) Füllgrad

ite /

* 100

atz


Def.: Als Füllgrad (in %) bezeichnet man

(Anzahl der erwünschten Sätze pro Se

Anzahl der möglichen Sätze pro Seite)

Vorteil teilweiser Füllung:

• gar keine oder weniger Überläufe

Nachteil:

• Datei benötigt (100 / Füllgrad) mehr Pl


TU Wien

(c) Mittleres Zugriffszeitverhalten

ketlänge / 2)

n/ed)

i

Hauptdatei

exdatei


Blockzugriffe:

• Hashorganisation: Hashtabelle + (Buc

• Indexsequentiell (lockerer Index): log2(

• B*-Baum: < 1 + logd(n/e)

• Dichter Index: log2(n/d)

n: Anzahl der Datensätze in der Hauptdate

e: Anzahl der Datensätze pro Block in der

d: Anzahl der Einträge pro Block in der Ind


TU Wien

(d) Physische DO in kommerz. Systemen

ke werden gefüllt

dex

als Zugriffsstruk-

n von Clusters


• Ingres

• Heap: ungeordnete Datei - alle Blöc

• Hash: (interne) Hashorganisation

• Isam: geordnete Datei mit Primärin

• Btree: ungeordnete Datei, B*-Baumtur

• Oracle

• ungeordnete Datei,

• B*-Baum als Zugriffsstruktur

• Clusters

• Hashing in Verbindung mit Definitio


TU Wien

Auswahl von Speicherstrukturen

rstrukturen ab-


Ziel:

Effizienzsteigerung wichtiger Abfragen

Einschränkungen:

Verfügbarkeit mancher physischer Speichehängig von Implementierung

Annahme bei folgender Methode:

Index und Clustering möglich

Dat

enm

odel

lieru

ngP

hysi

sche

Dat

enor

gani

satio

n81

Abt

. f. D

aten

bank

en u

nd A

rtifi

cial

Inte

llige

nce

Inst

itut f

ür In

form

atio

nssy

stem

eT

U W

ien

NIC

HT

VE

RW

EN

DE

TE

FO

LIE

N


TU Wien

(e) Vorgehensweise - Überblick

hätzung der An-

frage


1. Festlegung der Relationen und Absc

zahl der Tupel in jeder Relation

2. Bestimmung häufiger Abfragen

3. Abschätzung der Häufigkeit jeder Ab

4. Erstellung eines JOIN-Graphen

5. CLUSTERs bestimmen

6. INDIZES bestimmen


TU Wien

Bildung von CLUSTERs

endung von

n Werten, spe-

beteiligten Tabel-

il-Tabellen, woZeilen der Detail-

Schlüssel, wenn haben

vorkommen


• Bildung von Clusters bei häufiger VerwTabellen in JOINs

• keine Cluster bei häufiger Änderung voziell der Cluster-Key-Attribute

• keine Cluster, wenn oft auf nur eine derlen zugegriffen werden muß

• Bildung von Clusters über Master-Detaeiner Zeile der Master-Tabelle mehrereTabelle entsprechen

• Attribute eignen sich nicht als Cluster-zuviele Tupel die gleichen Attributwerte

• jede Tabelle darf nur in einem Cluster


TU Wien

Entscheidung über Auswahl von Clusters (1)

bfragen ohneen Abfragen mit

egt, wird die Aus-bellen langsamer


Ausgangssituation:

Verwendung einer bestimmten Tabelle in AJoin und Abfragen mit Join oder in mehrerunterschiedlichen Joins

Problem:

Wird Cluster über mehrere Tabellen angelführung von Abfragen über nur eine der Ta


TU Wien

Entscheidung über Auswahl von Clusters (2)

le Tabellen einertlich häufigerren Joins

en Abfragen sol-inem Cluster ge-

ch häufige Abfra-bellen derjenigenie größeren Ver-


Häufigkeit der Abfragen: Cluster über alAbfrage nur, wenn Abfrage mit Join wesenvorkommt als Abfrage ohne bzw. mit ande

Gemeinsame Tabellen: Bei gleich häufiglen die gemeinsam genutzten Tabellen in ehalten werden

Zahl der Zeilen: Verwenden mehrere gleigen in Joins dieselbe Tabelle, sollten die TaAbfrage in Clusters gehalten werden, die dbundtabellen verursacht



Bildung von Indizes

Indizes über

• Join-Attribute von Cluster-Kandidaten,die bei der Bildung der Clusters nicht berücksichtigt wur-den



Der JOIN-Graph

1. Aus OMT-Diagramm werden jene Klassen und Assozi-

ationen dargestellt, die an häufigen Abfragen beteiligt

sind.

2. Jede Klasse und jede Assoziation, für die ein Relatio-

nenschema definiert wurde, wird mit der geschätzten

Zahl der Tupel versehen.

3. Jede Kante wird mit der Häufigkeit der Abfrage und

den verbindenden Attributen (d. h. mit denjenigen At-

tributen, die in der Abfrage verglichen werden) verse-

hen



Beispiel - Basis: OMT-DiagrammAbteilung Bereich

Angestellter

{Teilmenge} geführt_von

besteht_aus

geleitet_von

verheiratet_mit

Fähigkeiten

Projekt

benötigte_Fähigkeiten

Kind

gehören_zu

Ort

Manager Ingenieur Techniker Sekretär

Berufsbezeichnung

BerufsverbandMitglied_bei

PC

SV-Nr.Name...

AbtNr AbtName BNr BNameFCode FName

PNr PNameVornameGebDatum

ONr, OName

Zahl d. Unter-gebenen

BVBezeichnung PCNr, PCBezeichnung

Ausbildung Anschlägepro Minute

Einsatz-bereich ...

hat

1+

1+

1+

1+

5+


TU Wien

1 a Relationenschemata

, AbtNr, verhSVNr)

r)


Angestellter (SV-Nr, Name, ..., BerufsbezeichnungManager (SV-Nr, Zahl d. Untergebenen, ...)Ingenieur (SV-Nr, Ausbildung, ..., PC-Nr.)Techniker (SV-Nr, Einsatzbereich, ...)Sekretär (SV-Nr, Anschläge p. M., ...)Berufsverband (BVBezeichnung, ...)PC (PCNr, PCBezeichnung)Kind (SV-Nr, Vorname, GebDatum)Bereich (BNr, BName, ..., Leiter-SV-Nr)Abteilung (AbtNr, AbtName, ..., BNr, Leiter-SV-NFähigkeiten (FCode, FName, ...)Projekt (PNr, PName, ...)Ort (ONr, OName, ...)

Mitglied_bei (SV-Nr, BVBezeichnung)Benötigte_Fähigkeiten (SV-Nr, PNr, FCode)Gehören_zu (SV-Nr, PNr, ONr)


TU Wien

1 b Größe der Relationen

n


Relation Zahl d. Tupel/RelatioANGESTELLTER 5000KIND 10000BEREICH 20ABTEILUNG 100FÄHIGKEITEN 150PROJEKT 500ORT 50MANAGER 150INGENIEUR 3500TECHNIKER 1000SEKRETÄR 350BERUFSVERBAND 20PC 3500MITGLIED_BEI 7000BENÖTIGTE_FÄHIGKEITEN 15000GEHÖREN_ZU 20000


TU Wien

2, 3 Häufige Abfragen u. Häufigkeit

r)

ame


(1) monatlich:SELECT PCNr, PCBezeichnungFROM pcWHERE PCNr NOT IN (SELECT PCNr FROM ingenieuORDER BY 1;

(2) täglich:SELECT a.SV-Nr, a.Name, f.FCodeFROM Angestellter a, benötigte_Fähigkeiten fWHERE a.SV-Nr = f.SV-NrORDER BY 1;

(3) mehrmals täglich:SELECT a.SV-Nr, a.Name, g.PNr, p.PName, g.ONr, o.ONFROM Angestellter a, gehören_zu g,

Projekt p, Ort oWHERE a.SV-Nr = g.SV-Nr AND p.PNr = g.PNr

AND o.ONr = g.ONrORDER BY 1;


TU Wien

4 JOIN-Graph

PCr PCBezeichnung

hat

~3500

~3500


Angestellter

Projekt

benötigte_Fähigkeiten

Ort

Ingenieur

SV-Nr.Name...

PNr PName

ONr OName

PCN

Ausbildung

gehören_zu

FähigkeitenFCode FName

monatlichPCNr

täglichSV-Nr. ~5000

~15000

~20000~50

~500

mehrmals täglich

SV-Nr.

ONr

PNr


TU Wien

5 Bestimmung der Clusters (1)

,

pc (PCNr))

,


CREATE CLUSTER ingenieur_pc_cluster(PCNr INTEGER);

CREATE TABLE ingenieur(SVNr CHAR(10) PRIMARY KEY

ausbildung CHAR(20),PCNr INTEGER REFERENCES

CLUSTER ingenieur_pc_cluster (PCNr);

CREATE TABLE pc(PCNr INTEGER PRIMARY KEY

PCBezeichnung CHAR (30))CLUSTER ingenieur_pc_cluster (PCNr);

CREATE INDEX ingenieur_pc_indexON CLUSTER ingenieur_pc_cluster;


TU Wien

5 Bestimmung der Clusters (2)

-Def-

ter”,


CREATE CLUSTER gehören_zu_cluster(SV-Nr CHAR (10),PNr INTEGER,ONr INTEGER);

Hinweis: Reihenfolge der Attribute in der Clusterinition durch SELEKTIVITÄT bestimmt

zu Abfrage 3:Angestellter bereits in Cluster “gehören_zu_clusdaher Definition eines Index für Tabellebenötigte_Fähigkeiten

CREATE INDEX Fähigkeiten_index ONbenötigte_Fähigkeiten (SV-Nr);



Join-Algorithmen

1. Nested-loop Join

2. Join mit Hilfe eines Index

3. Sort-Merge Join

4. Hash Join



Nested-loop Join: primitives Verfahren

...

1 2 nAB BC

...

1 2 n3



Nested-loop Join: verbesserte Lösung

1 2A B B C

1

2



Join mit Hilfe eines Index über BC

...

a

b

c

d...

1 2 3 4 ... nAB BC



Sort-Merge Joinmit Index über beide Dateien

a

b

c

d

a

b

c

d

a

b

c

d

AB BC



Hash-Join

R S

R1...

R4

S1

.

.

S4

.

AB BC



3

11

19

31

5

13

23

7

17

29

3 11 19 31



11

15

19

31

13

17

23

14

29

3 11 15 19

3 5 7

31



U

X

XU

V W

Y Z

V

Z

ZV

X Y



W

Z

V Z

V X Y

U

V

Z

X Y

V Z



C E

FA B C D E G

E

FA B E GD



2345

INDEXDATEI

INDEXWERT

BLOCKZEIGER

B A

NIL

2 15

333

8920

NIL

3 17

4 21

NIL

5 105

18

5 25

NIL

522

5 65 16

35



0

1

2

3

43

7 12

9

6

15

4

8

10 20

1 11

25

18

30

22

35

13

40



0

1

2

3

43

7 12

9

15

4

8

20

111

25

18

30 3540



31 17

0

1

40 32

40 72

0

1

32 66 99

0

131 17 63



40 72

0

1

32 66 99

0

131 17 63

40 72

0

1

32 66 99

0

1

31 63 28

0

1 47 45

0

1

17 49 51



40 72

0

1

32 66 99

0

1

31 63 28

0

1 47 45

0

1

17 49 5140 47 72

0

1

32 66 99

0

117 28 31



40 47 72

0

1

32 66 99

0

117 28 31

40 47 72

0

1

32 66 99

0

1

28 31 95

0

1

0

1

17

36 103



Beispiel:

Gegeben ist eine geordnete Datei mit 35000 Sätzen. Jeder Satz enthält102 Bytes, 26 davon hat der Schlüssel. Ein Block besteht aus 1024 Bytes.Ein Zeiger zu einem Block oder Unterblock ist 4 Bytes lang.

Für eine B*-Baum Organisation werden alle Blöcke so weit wie möglichgefüllt. Berechnen Sie die Anzahl der Blöcke, die für den Index benötigtwerden. Erläutern Sie den Rechenvorgang!

Lösung:

3500 Blöcke für die Datensätze:

Sätze pro Block = = 10

Anzahl Blöcke = = 3500 Blöcke

35 Einträge pro Indexblock: (26 + 4)*34 = 1020 + 4 = 1024

1024 Byte pro Block102 Byte pro Satz

------------------------------------------------------

35000 Sätze10 Sätze pro Block----------------------------------------------------

Documents

Physische Datenorganisation · • einfache Suche Nachteile: • optionale Felder in jedem Satz • Felder variabler Länge müssen mit maximaler Länge gespeichert werden. Datenmodellierung