5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und...

44
P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5. Schema-Architekturen verteilter Datenbanksysteme 5.1 Allgemeine Vorbemerkungen r Ziel der Schema-Architektur (generell): m Bereitstellung der Sicht eines globalen Schemas ( globale Relationen) m Bereitstellung von externen Sichten (Views) auf das globale Schema m "Verstecken" (vor dem Benutzer / AP) n von Heterogenitäten in den lokalen Schemata/Datenmodellen n der Partitionierung der globalen Relationen (ggf.) n der Allokation der Partitionen/Relationen n von redundanten Speicherungen von Partitionen (ggf.) m Bereitstellung von Informationen (für Query-Processor / DBA) über n die Partitionierung der globalen Relationen n die physischen Speicherungsorte von Partitionen n evtl. redundant gespeicherte Partitionen n die anzuwendende Kopien-Update-Strategie ( später)

Transcript of 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und...

Page 1: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-1

5. Schema-Architekturen verteilterDatenbanksysteme

5.1 Allgemeine Vorbemerkungen

r Ziel der Schema-Architektur (generell):

m Bereitstellung der Sicht eines globalen Schemas(⇒ globale Relationen)

m Bereitstellung von externen Sichten (Views) auf das globaleSchema

m "Verstecken" (vor dem Benutzer / AP)

n von Heterogenitäten in den lokalen Schemata/Datenmodellen

n der Partitionierung der globalen Relationen (ggf.)

n der Allokation der Partitionen/Relationen

n von redundanten Speicherungen von Partitionen (ggf.)

m Bereitstellung von Informationen (für Query-Processor / DBA)über

n die Partitionierung der globalen Relationen

n die physischen Speicherungsorte von Partitionen

n evtl. redundant gespeicherte Partitionen

n die anzuwendende Kopien-Update-Strategie ( später)

Page 2: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-2

r Aktuell realisierte Formen der 3-Schema-Architektur

ANSI/SPARC-Konzept

Heutige Realisierungsformen

Rel.DB: Views

CODASYL: Subschema

IMS: Program Communication Block (PCB)

Rel. DB: Indexe, Cluster, Modify ... to Hash, BTree, ISAM, ...

CODASYL: Link to Owner, Chain-Mode, ...

IMS: HISAM, HIDAM, ...

Rel. DB: Basis-Relationen + Ref. Integrity

CODASYL: Schema

IMS: Data Base Definition (DBD)Logical Data Base

KonzeptuellesSchema

ER-Schema

ExternesSchema

InternesSchema

+

PhysischesSchema

LogischesSchema

Transformation Transformation

TransformationTransformation

Abb. 5-1: Realisierte Formen der 3-Schema-Architektur

Page 3: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-3

5.2 Homogene, prä-integrierte DBSe

r Von vornherein als verteiltes DBMS ausgelegt("grüne Wiese")

Gründe (z.B.):

m Performance-Gründe

m Ausfallsicherheit

m Inkrementelle Erweiterbarkeit

m ...

r Dadurch keine "Altlasten" (keine existierenden APe)

r Ausgangssituation:

m Vorgegebene globale Relationen

m davon abgeleitete Partitionierung und Allokation

r Dadurch keine Heterogenität in den lokalen Schemata

m gleiches Datenmodell

m strukturell homogen

m semantisch homogen

Page 4: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-4

r Dadurch einfache Schema-Architektur möglich

APG1

AP AP AP APG2 G3 G4 Gn

LokalesInternes Schema(LIS-B)

LokalesInternes Schema(LIS-A)

LokalesKonzeptuelles

Schema(LKS-A)

LokalesKonzeptuelles

Schema(LKS-B)

Knoten A Knoten B

Globale externe Schemata

Globales Schema

Abb. 5-2: Schema-Grobarchitektur bei homogenen,prä-integrierten verteilten DBMSen

Page 5: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-5

r Globales Schema: Intern wiederum in 3-Schema-Architektur

m Globales konzeptuelles Schema (GKS)

⇒ die (globale) "Außensicht"

m Globales Partitionierungs-Schema (GPS)

⇒ die Partitionierung der Relationen des GKS(nur intern sichtbar)

m Globales Allokations-Schema (GAS)

⇒ die physische Plazierung der Partitionen(redundant / nicht-redundant)

Page 6: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-6

Knoten A Knoten B Knoten C

Abteilung (....)

Angest1 (....)Lagerort (....)Lieferant2 (....)Teile (....)

Abteilung (....)Inventar (....)Lieferant (....)

Teile (....)

LKS-A

Angest2 (....)Lieferant (....)Lieferant2 (...)

Teile (....)

LKS-B LKS-C

Abteilung1

Abteilung2

Angest1

Angest2

Inventar

Lagerort

Lieferant1

Lieferant2

Teile1

Teile2

AbtNr <= 300

AbtNr > 300

-

-

-

-

LiefNr <= 200

LiefNr > 200

TeileNr <= 500

TeileNr > 500

AbtNr, AbtName, Bereich, MgrPersNr, Budget

AbtNr, AbtName, Bereich, MgrPersNr, Budget

PersNr, AngName, AbtNr, Anschrift

PersNr, Gehalt

InvNr, Bezeichnung, AnschJahr, AktWert, AbtNr

TeileNr , LagerNr

LiefNr, LiefName, Stadt

LiefNr, LiefName, Stadt

TeileNr , LiefNr, Preis

TeileNr , LiefNr, Preis

Partition Attribute SelektionsPräd.Partitionen

ABTEILUNG

ANGEST

INVENTAR

LAGERORT

LIEFERANT

TEILE

Abteilung1 È Abteilung2

Angest1 NJN Angest2

Inventar

LagerortLieferant1 È Lieferant2 Teile1 È Teile2

MappingGlobRelationGlobaleRelationen

GPS

GlobaleRelation

Abteilung

Abteilung

Angest

Angest

Inventar

Lagerort

Lieferant

Lieferant

Teile

Teile

GlobalerKatalog

ABTEILUNG ( AbtNr, AbtName, Bereich, MgrPersNr, Budget )

ANGEST ( PersNr , AngName, Gehalt, AbtNr, Anschrift )

INVENTAR ( InvNr, Bezeichnung, AnschJahr, AktWert, AbtNr )

LAGERORT ( TeileNr , LagerNr )

LIEFERANT ( LiefNr, LiefName, Stadt )

TEILE ( TeileNr, LiefNr, Preis )

Abteilung@KnotenA

Abteilung@KnotenC

Angest1@KnotenA

Angest2@KnotenB

Inventar@KnotenC

Lagerort@KnotenA

Lieferant@KnotenB, Lieferant@KnotenC

Lieferant2@KnotenA, Lieferant2@KnotenB

Teile@KnotenA

Teile@KnotenB, Teile@KnotenC

Partition LocalName PrimarySite

Abteilung1

Abteilung2

Angest1

Angest2

Inventar

Lagerort

Lieferant1

Lieferant2

Teile1

Teile2

KnotenA

KnotenC

KnotenA

KnotenB

KnotenC

KnotenA

KnotenB

KnotenA

KnotenA

KnotenC

...

...

...

...

...

...

...

...

...

...

...

Allokation

GAS

GKS

Abb. 5-3: Globales Schema (Gesamtsicht)

Anmerkung: Die Attribut-Typen sind hier in LKSi, GPS und GKSder Übersichtlichkeit halber weggelassen worden

Page 7: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-7

GlobalerKatalog

ABTEILUNG ( AbtNr, AbtName, Bereich, MgrPersNr, Budget )

ANGEST ( PersNr, AngName, Gehalt, AbtNr, Anschrift )

INVENTAR ( InvNr, Bezeichnung, AnschJahr, AktWert, AbtNr )

LAGERORT ( TeileNr, LagerNr )

LIEFERANT ( LiefNr, LiefName, Stadt )

TEILE ( TeileNr, LiefNr, Preis )

GKS

Abteilung1

Abteilung2

Angest1

Angest2

Inventar

Lagerort

Lieferant1

Lieferant2

Teile1

Teile2

AbtNr <= 300

AbtNr > 300

-

-

-

-

LiefNr <= 200

LiefNr > 200

TeileNr <= 500

TeileNr > 500

AbtNr, AbtName, Bereich, MgrPersNr, Budget

AbtNr, AbtName, Bereich, MgrPersNr, Budget

PersNr , AngName, AbtNr, Anschrift

PersNr , Gehalt

InvNr , Bezeichnung, AnschJahr, AktWert, AbtNr

TeileNr, , LagerNr

LiefNr, LiefName, Stadt

LiefNr , LiefName, Stadt

TeileNr , LiefNr, Preis

TeileNr , LiefNr, Preis

Partition Attribute SelektionsPrädikat

Partitionen

ABTEILUNG

ANGEST

INVENTAR

LAGERORT

LIEFERANT

TEILE

Abteilung1 È Abteilung2

Angest1 NJN Angest2

Inventar

Lagerort

Lieferant1 È Lieferant2

Teile1 È Teile2

MappingGlobRelation

GlobaleRelationen

GPS

GlobaleRelation

Abteilung

Abteilung

Angest

Angest

Inventar

Lagerort

Lieferant

Lieferant

Teile

Teile

Abb. 5-4: Globales Allokations-Schema und globales konzeptuelles Schema

Page 8: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-8

Abteilung@KnotenA

Abteilung@KnotenC

Angest1@KnotenA

Angest2@KnotenB

Inventar@KnotenC

Lagerort@KnotenA

Lieferant@KnotenB, Lieferant@KnotenC

Lieferant2@KnotenA, Lieferant2@KnotenB

Teile@KnotenA

Teile@KnotenB, Teile@KnotenC

Partition LocalName PrimarySite

Abteilung1

Abteilung2

Angest1

Angest2

Inventar

Lagerort

Lieferant1

Lieferant2

Teile1

Teile2

KnotenA

KnotenC

KnotenA

KnotenB

KnotenC

KnotenA

KnotenB

KnotenA

KnotenA

KnotenC

...

...

...

...

...

...

...

...

...

...

...

Allokation

GAS

Knoten A Knoten B Knoten C

Abteilung (....)

Angest1 (....)Lagerort (....)Lieferant2 (....)Teile (....)

Abteilung (....)Inventar (....)Lieferant (....)Teile (....)

LKS-A

Angest2 (....)Lieferant (....)

Lieferant2 (...)Teile (....)

LKS-B LKS-C

Abb. 5-5: Lokale konzeptuelle Schemata und globales Allokations-Schema

Page 9: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-9

5.3 Heterogene, prä-integrierte DBSe

r Kommt (bislang?) nur in rudimentärer Form vor

r I.d.R. Spezialsysteme mit zugekaufter DBMS-Komponente

r Beispiel: CAD-Systeme mit DB-Komponente

m Geometrische Objekte, interne Objekt-Darstellung

⇒ Datenhaltung in CAD-Dateisystem

m Verwaltungsdaten(Bemaßungen, Werkstoffdaten, Stückliste, ...)

⇒ relationale Datenbank

r Häufig keine echte Integration ⇒ "Hybrid-Lösung"

VerwaltungsinformationMeta-DatenStücklisten

Geometrie-Daten...

CAD-Anwendungssystem

Datenbanksystem CAD-System

....

Abb. 5-6: CAD-DB-"Integration": Hybrid-Lösung

Page 10: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-10

r "Hart verdrahtete" Integration

m Kein gemeinsames "Datenmodell"

m Auf Implementierungsebene Heterogenität voll sichtbar

m "Verstecken" der Heterogenität nur durch Anwendungssystem

m Kein echtes verteiltes Informations-System

r Mögliches Problem: Unterschiedliches Recovery-Verhalten imFehlerfall

Page 11: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-11

r Mögliche zukünftige Entwicklung

m "Spezial"-DBMSe als "Systembausteine"

n Standard-DBMS

n Geo-DBMS

n Image-DBMS

n Video-DBMS

n Knowledge-Base-Management System

n ...

m Durchführung von Spezialaufgaben durch jeweiligesSpezial-DBMS

m An sich wünschenswert: Nach außen hin wie ein monolithischesDBMS

Probleme:

n Auf einander abgestimmte, äquivalente Basis-Funktionalitätenmüssen in allen Systemen verfügbar sein

l Synchronisation

l Recovery

l Transaktions-Management

l ...

n Gemeinsames Datenmodell, gleiche Basis-Operationen

l Überhaupt realisierbar?

l Überhaupt anstrebenswert?

Page 12: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-12

5.4 Allgemeines zu post-integriertenSystemen

5.4.1 Koexistenzproblematik und allgemeineSchema-Architektur

p Ausgangssituation: Existierende DBSe

p Nachträgliche Integration in verteiltes DBMS

p Dadurch i.d.R. existierende APe für lokale DBSe;APe müssen weiterhin ablauffähig bleiben

m Investitionsschutz

m "Über-Nacht-Portierung" i.d.R. nicht möglich

p Tolerierbar (falls möglich): Neuübersetzung

p Nicht tolerierbar: (Größere) Eingriffe in Quelltexte

p Konsequenz: Für existierende Anwendungen muß nach wievor das "alte" Schema bzw. die "alte" Sicht verfügbar sein.

Page 13: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-13

p Bei voll-integrierten lokalen Datenbanken im Prinzip folgendeVorgehensweise möglich:

1. Festlegung eines neuen einheitlichen (globalen)konzeptuellen Schemas 1

2. Anpassung der Abbildung konzeptuell ⇒ intern

3. "Simulation" des alten konzeptuellen Schemas durchBereitstellung der "alten" Sichten

KS - 1 KS - 2

IS - 1 IS - 2

ES 11 ES 12 ES 13 ES 21 ES 22

KS - neu

IS - 1 IS - 2

ES 22ES 21ES 13ES 12ES 11

= zu ändernde Schemata / TransformationenLegende: ES = externes Schema KS = konzeptuelles Schema IS = internes Schema

Traf

o K

Sneu

- IS

1

Traf

o K

Sneu

- IS

2

Traf

o ES

11-

KS

neu

Traf

o ES

12- K

Sne

u

Tra

fo E

S13-

KS

neu

Traf

o ES

21-

KSn

eu

Traf

o ES

22-

KSn

eu

Traf

o ES

11- K

S1

Traf

o ES

12-

KS

1

Tra

fo E

S13-

KS1

Tra

fo E

S21-

KS2

Traf

o E

S22-

KS2

Traf

o K

S1- I

S1

Traf

o K

S2- I

S2

Abb. 5-7: Realisierung des glob. konzeptuellen Schemas (1)

p Problem: Gleichzeitige Änderung aller vorhandenenkonzeptuellen Schemata erforderlich (⇒ Aufwand!)

1 d.h. ein gemeinsames Schema für alle lokalen DBMS

Page 14: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-14

p Gängige Lösung: Lokale Repräsentationsschemata

AP

AP

AP

Lokale Externe

Schemata(LES-B)

LokalesInternes Schema(LIS-B)

B1

B2

Bm

APA1

AP

AP

A2

An

Lokale Externe

Schemata(LES-A)

LokalesInternes Schema(LIS-A)

LokalesRepräsentations

Schema(LRS-A)

Knoten A Knoten B

LokalesKonzeptuelles

Schema(LKS-A)

LokalesKonzeptuelles

Schema(LKS-B)

LokalesRepräsentations

Schema(LRS-B)

globale AnwendungsprogrammeAPG1 AP AP AP AP

G2 G3 G4 Gn

Globale externe Schemata

Globales Schema

...

lokaleAnwendungsprogramme

Abb. 5-8: Realisierung des globalen konzeptuellen Schemas (2)

Page 15: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-15

5.4.2 Schema-Integration

p Ziel: Abbildung der lokalen Schemata in ein einheitliches("integrierendes") globales Schema

p Typischer Ablauf in vier Phasen:

1. Prä-Integrationsphase:Festlegung der Vorgehensweise,Ermittlung der Entities und Beziehungen

2. Vergleichsphase:Ermittlung von Namens- und Strukturkonflikten

3. Vereinheitlichungsphase:Festlegung des Zielschemas

4. Restrukturierungs- und Zusammenfassungsphase:Festlegung der lokalen Repräsentationsschemata underforderlichen Abbildungen

Page 16: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-16

5.4.2.1 Prä-Integrationsphase

p Binäre Integration vs. n-stellige Integration

S2S1

S1 S3^

S2^ S4

S3^ ...

...

S1 S2 S3 S4 ...

S

a) binäre Integration

b) n-stellige Integration

Legende :S = lokales Schemai

S, S = integriertes (Teil-)Schemai^ ^

Abb. 5-9: Vorgehensweisen bei der Schema-Integration

Page 17: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-17

5.4.2.2 Vergleichsphase

p Ermittlung von Namens- und Strukturkonflikten

p Namenskonflikte: Homonyme und Synonyme

eingebaut_in

Homonyme

Ausstattung

Haus

Ausstattung

gehört_zu

Abteilungen

plaziert

Synonyme

Klient

Auftrag

Kunde

hat

Kredit

Abb. 5-10: Homonyme und Synonyme

Page 18: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-18

p Konfliktarten auf

m Strukturebene (Typebene)

n Typkonflikte (Modellierung als Attribut vs. als Entity)

n Beziehungskonflikte (1:1 vs. n:m)

n Schlüsselkonflikte (unterschiedliche Primärschlüssel)

n Verhaltenskonflikte (kaskadierendes vs. manuelles Löschen)

m Instanzebene: Ambiguitätsproblem

n Mehrfachspeicherung mit unterschiedlichen Primärschlüsseln inden lokalen DBS

n Verwendung desselben Primärschlüsselwertes (jeweils lokal) fürglobal unterschiedliche Entities

m funktionaler Ebene: unterschiedliche DB-Operationen

Knoten A Knoten B

LiefRel LiefNr Name ... LiefRel LiefNr Name ...

1826 ABC-Firma ... 1977 ABC-Firma ...

2157 GHI -Firma ... 2157 DEF-Firma ...

3984 JKL -Firma ... 3572 MNO-Firma ...

4013 PQR-Firma ... 3795 VWX-Firma ...

5119 STU-Firma ... ... ... ...

... ... ...

Abb. 5-11: Beispiel für auftretende Ambiguitäts-Probleme

Page 19: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-19

5.4.2.3 Vereinheitlichungsphase

p Entscheidung darüber, wie mit den zuvor erkannten Namens-und Strukturkonflikten verfahren werden soll.

m Homonyme: Evtl. Namenserweiterung (als Präfix Entitytypund/oder Schemaname)

m Strukturkonflikte: Umformungen erforderlich:2

n Entities in Attribute oder Beziehungen

n Beziehungen in Entities

n Attribute in Entities oder Beziehungen

Dadurch oftmals nur noch lesender Zugriff möglich(siehe Abschnitte 5.5 und 5.6)

m Ambiguitätsprobleme (auf Instanzebene)

Im Prinzip zwei Vorgehensweisen möglich:

1. Einführung eines neuen, global eindeutigen Schlüssels

2. Globale Verwendung von lokal erweiterten Schlüsseln

2 Eine ausführliche Diskussion dieses Problems findet sich inBatini, C.; Lenzerini, M.; Navathe, S.B.: A Comparative Analysis of Methodologies for DatabaseSchema Integration, ACM Computing Surveys, Vol. 18, No. 4, Dec. 1986, S. 323-364 und inLarson, J.A.; Navathe, S.B.; Elmasri, R.: A Theory of Attribute Equivalence in Databases withApplication to Schema Integration. IEEE Transactions on Software Engineering, Vol. 15, No. 4,April 1989, S. 449-463

Page 20: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-20

GlobLiefTab GlobLiefNr Name ... KnotenA_ID KnotenB_ID

1001 ABC-Firma ... 1826 1997

1002 DEF-Firma ... 0 2157

1003 GHI-Firma ... 2157 0

1004 JKL-Firma ... 3984 0

1005 MNO-Firma ... 0 3572

1006 PQR-Firma ... 4013 0

1007 STU-Firma ... 5119 0

1008 VWX-Firma ... 0 3795

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

Abb. 5-12: Globale Schlüssel-Umsetzungstabelle (1) 3

GlobLiefTab LiefNr KnotenID Name ...

1826 A ABC-Firma ...

1977 B ABC-Firma ...

2157 A GHI-Firma ...

2157 B DEF-Firma ...

3572 B MNO-Firma ...

3795 B VWX-Firma ...

3894 A JKL-Firma ...

4013 A PQR-Firma ...

5119 A STU-Firma ...

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

Abb. 5-13: Globale Schlüssel-Umsetzungstabelle (2)

3 Bei großer Knotenanzahl oder häufigen Änderungen hinsichtlich Knotenzu- und -abgängenwäre sicherlich eine Modellierung der 1:n-Beziehung zwischen globalem Schlüssel und lokalenSchlüsseln mittels einer eigenen („Abbildungs“-)Tabelle vorteilhafter.

globaler Schlüssel

Page 21: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-21

5.4.2.4 Restrukturierungs- und Zusammenfassungsphase

p Endgültige Entscheidung über das globale Schema

p Entwurfsziele: Globales Schema soll

m vollständig

m minimal (⇒ Redundanzfreiheit auf Schemaebene)

m verständlich

sein.

Page 22: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-22

5.4.3 Updates über post-integrierte DB-Schemata

p Hier noch prinzipielle Betrachtungen(konkrete Durchführung siehe Kapitel 6)

p Zuvor Betrachtung von Konflikten i.w. auf Typebene

p Zusätzlich potentiell weitere Konflikte auf Ausprägungsebenemöglich

m Seien L1 und L2 Entitiymengen und dom(PKL1) und dom(PKL2)die Wertebereiche ihrer Primärschlüssel.

m Für die Entitymengen L1 und L2 kann dann gelten:

n Disjunktheit: dom(PKL1) ∩ dom(PKL2) = ∅

l kein Informationsverlust bei Integration

l jedem globalen Entity eindeutig ein lokales Entity zuordenbar

l damit Update über das globale Schema in vollem Umfangprinzipiell möglich

n Überlappung: dom(PKL1) ∩ dom(PKL2) ≠ ∅

l kritisch bzgl. Einfügeoperationen

l "Abhilfe":

- Zuordnungstabelle à la abgeleitete horiz. Partitionierung(aber hoher Aufwand!)

- Einfügeregeln

l Relativ unkritisch: Reine Wertänderungen und Löschungen

n Enthaltensein: dom(PKL1) ⊆ dom(PKL2) (oder umgekehrt)

l Problemstellung i.w. wie bei Überlappung

Page 23: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-23

a) Disjunktheit b) Überlappung c) Enthaltensein

G

L 1 L 2 L 2

G

L 1

G

L 1 L 2

Abb. 5-14: Beziehung zwischen Entity-Mengen

Page 24: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-24

5.5 Homogene, post-integrierte DBSe

p Im folgenden Betrachtung von struktureller Heterogenität

p In einfachen Fällen Mächtigkeit der Relationen-Algebra bzw.SQL ausreichend

p In komplizierteren Fällen jedoch mächtigere Abbildungs-sprache erforderlich (siehe unten)

p Integration von Relationen unterschiedlicher Stelligkeit

m falls nur lesender Zugriff zu unterstützen:Entweder "kleinster gemeinsamer Nenner" oder"Vereinigungsmenge" (⇒ Nullwerte, "Dummy-Attribute")

m Problem: Änderungen / Einfügungen

Bei Aufrechterhaltung von Verteilungstransparenzgrundsätzliche Versorgung der "Dummy-Attribute" notwendig

p Verschärfung des Problems bei unterschiedlichen Werte-bereichen (z. B. Knoten A numerisch, Knoten B Text)

lokale Attribute

globale Attribute

"Dummy"-Attribute

G11 G12 G13 G14 G15

L15L14L13L12L11 L21 L22 L23 L24 L25 L31 L32 L33 L34 L35

Abb. 5-15: Homogenisierung struktureller Heterogenität (1)

Page 25: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-25

p Behandlung von erheblichen Strukturabweichungen

Beispiel 5-1:

An zwei Knoten A und B werden Aktienbestände verwaltet.

Knoten A habe die Aktien in der folgenden Form gespeichert:

Aktien Firma Menge Kaufdatum KursHP 1.000 92.05.10 ...IBM 2.000 92.08.13 ...Sun 1.500 93.02.18 ...Unilever 500 92.08.09 ...Henkel 800 93.03.18 ....... ... ... ...

Knoten B hingegen habe folgende Form gewählt:

HP-Aktien Menge Kaufdatum Kurs500 93.01.10 ...

... ... ...

IBM-Aktien Menge Kaufdatum Kurs1.500 91.12.15 ...

... ... ...

Sun-Aktien Menge Kaufdatum Kurs1.000 93.03.10 ...

... ... ...

Sonstige-Aktien Firma Menge Kaufdatum KursUnilever 1.000 93.01.20 ...Ciba 1.500 92.11.02 ....... ... ... ...

Page 26: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-26

m Elegante Lösung: (Prädikaten-)Logik-basierteTransformationssprachen

Beispiel 5-2:

Zu bilden sei die globale Relation

glob_aktien(Firma,Kaufdatum,Menge,Kurs)

Mögliche Formulierung der Abbildung LKS → LRS: 4

Knoten A:

glob_aktien(Firma,Kaufdatum,Menge,Kurs) :-aktien(Firma,Menge,Kaufdatum,Kurs).

Knoten B:

glob_aktien(Firma,Kaufdatum,Menge,Kurs) :-aktienbestand(X),X ≠ sonstige_aktien,Firma = X,X(Menge,Kaufdatum,Kurs). 5

glob_aktien(Firma,Kaufdatum,Menge,Kurs) :-aktienbestand(X),X = sonstige_aktien,sonstige_aktien(Firma,Menge,Kaufdatum,Kurs).

aktienbestand(hp).aktienbestand(ibm).aktienbestand(sun).aktienbestand(sonstige_aktien).

4 In Anlehnung an die Sprache 'F-Logic', vgl. hierzu G. Lausen, B. Marx: Eine Einführung inFrame-Logik, in: G. Vossen, K.-U. Witt: Entwicklungstendenzen bei Datenbanksystemen,Oldenbourg-Verlag, 1991, S. 173-2025 Man beachte, daß die freie Variable X hier mit einem Funktor unifiziert wird. Dies wäre z.B. inPROLOG nicht möglich.

Page 27: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-27

5.6 Heterogene, post-integrierte DBSe

r Ausgangs-Situation ähnlich wie bei homogenen,post-integrierten DBSen

r Zusätzlich jedoch: Unterschiedliche Datenmodelle

r Ziel (weiterhin): Globale Sicht als ein DBS

r Problem: Bereitstellung einer voll-funktionalen relationalen 6

LRS-Schicht (Schema + Operationen)

r Einfacher Fall: Nicht-relationales DBMS stellt bereits selbstSQL-Schnittstelle bereit 7

⇒ Problem reduziert sich auf Beschreibung des verfügbarenSQL-Subsets, wie z.B.

n kein Update, keine DDL-Operationen (wie z.B. CREATE TABLE)

n Beschränkung auf "einfache" SELECT-Ausdrücke(z.B. keine Exists-Klausel, kein Join, kein Group By, etc.)

n ...

r Im allgemeinen Fall:

m Bereitstellung einer "homogeniesierenden" LRS-Schicht

m Bereitstellung von relationalen LRS-Operationen

m Beschreibung des verfügbaren SQL-Subsets (siehe oben)

6 Wir legen hier (wie derzeit üblich) das relationale Datenmodell als "globales Datenmodell"zugrunde (vgl. Fußnote 1, Kapitel 3). Im Prinzip könnte man sich hier jedoch auch ein anderes -insbesondere ein mächtigeres - "operationales" Datenmodell vorstellen (siehe später).7 wie z.B. UDS/SQL

Page 28: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-28

r Beispiel 5-3: Anschluß einer IMS-Datenbank

Gegeben Kurs-Datenbank (siehe Vorlesung DBS)

1

n

1

KursNr Titel

KURS

nAngNr

Datum

Ort

ANGEBOTVORAUS

wirdangeboten

setztvoraus

VorNr

Abb. 5-16: Kurs-Datenbank in ER-Darstellung (Ausschnitt)

IMS Data Base Definition (Ausschnitt):

DBD NAME=KursDB

SEGM NAME=Kurs, BYTES=36

FIELD NAME=(KursNr,SEQ), BYTES=3, START=1

FIELD NAME=Titel, BYTES=33, START=4

SEGM NAME=Vorauss, PARENT=Kurs, BYTES=3

FIELD NAME=(VorNr,SEQ), BYTES=3, START=1

SEGM NAME=Angebot, PARENT=Kurs, BYTES=21

FIELD NAME=(AngNr,SEQ), BYTES=3, START=1

FIELD NAME=DATUM, BYTES=6, START=4

FIELD NAME=Ort, BYTES=12, START=10

SEGM ...

•••

END

Page 29: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-29

Bereitzustellende relationale Schemata: (bezogen auf Ausschnitt)

Kurs(KursNr, Titel)Angebot(AngNr, KursNr, Datum, Ort)

Ausprägungen:

Kurs KursNr Titel

G08 Grundlagen I

G10 Grundlagen II

P13 C-Programmierung

I09 Datenbanken

Angebot AngNr KursNr Datum Ort

1 G08 01-13-1993 München

2 G08 02-24-1993 Bremen

1 G10 02-01-1993 München

2 G10 02-15-1993 Hamburg

1 P13 05-28-1993 Ulm

2 P13 07-01-1993 Essen

1 I09 03-27-1993 Stuttgart

2 I09 04-23-1993 Hamburg

3 I09 05-29-1993 München

Page 30: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-30

Unterstützung von SELECT * FROM Kurs

1. Definition eines geeigneten Program Communication Blocks (PCB)

PCB DBDNAME=KursDBSENSEG NAME=Kurs, PROCOPT=G

•••

END

2. Materialisierung der kompletten Kurs-Relation

DEFINE Kurs ( KursNr : CHAR[3]; Titel : VARCHAR[20] )ASVAR KursSegment ...BEGINResultBuffer.Create(KursNr, Titel) /* Initialisierung eines leeren Resultat- */

/* Puffers mit Kurs-Tupel-Struktur */GU KursIF NOT "record found" THEN exit("no records found");ResultBuffer.next;ResultBuffer.KursNr := KursSegment.KursNr;ResultBuffer.Titel := KursSegment.Titel;

LOOP GN Kurs IF NOT "record found" THEN exit("no more records found"); ResultBuffer.next; ResultBuffer.KursNr := KursSegment.KursNr; ResultBuffer.Titel := KursSegment.Titel;ENDLOOP;

ENDDEFINE Kurs;

Page 31: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-31

Unterstützung von SELECT * FROM Angebot

1. Definition eines geeigneten PCBPCB DBDNAME=KursDBSENSEG NAME=Kurs, PROCOPT=GSENFLD KursNrSENSEG NAME=Angebot, PROCOPT=G

•••

END

2. Materialisierung der kompletten Angebot-RelationDEFINE Angebot ( AngNr : INT; KursNr : CHAR[3];

Datum : DATE; Ort : VARCHAR[20] )ASVAR KursSegment ... AngebotSegment ...BEGINResultBuffer.Create(AngNr, KursNr, Datum, Ort)GU Kurs *D

AngebotIF NOT "record found" THEN exit("no records found");ResultBuffer.next;ResultBuffer.AngNr := AngebotSegment.AngNrResultBuffer.KursNr := KursSegment.KursNr;ResultBuffer.Datum := AngebotSegment.Datum;ResultBuffer.Ort := AngebotSegment.Ort;

LOOP GN Kurs *D

Angebot IF NOT "record found" THEN exit("no more records found"); ResultBuffer.next; ResultBuffer.AngNr := AngebotSegment.AngNr ResultBuffer.KursNr := KursSegment.KursNr; ResultBuffer.Datum := AngebotSegment.Datum; ResultBuffer.Ort := AngebotSegment.Ort;ENDLOOP;

ENDDEFINE Angebot;

Page 32: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-32

Unterstützung von SELECT *FROM AngebotWHERE KursNr = :KursNr AND AngNr = :AngNr

1. Definition eines geeigneten PCB

(wie oben)

2. Generierung des entsprechenden Angebot-Tupels

DEFINE Angebot2 ( AngNr : INT; KursNr : CHAR[3];Datum : DATE; Ort : VARCHAR[20] )

ASVAR KursSegment ... AngebotSegment ...

BEGINResultBuffer.Create(AngNr, KursNr, Datum, Ort)GU Kurs *D (KursNr = :KursNr)

Angebot (AngNr = :AngNr)IF NOT "record found" THEN exit("no records found");ResultBuffer.next;ResultBuffer.AngNr := AngebotSegment.AngNrResultBuffer.KursNr := KursSegment.KursNr;ResultBuffer.Datum := AngebotSegment.Datum;ResultBuffer.Ort := AngebotSegment.Ort;

ENDDEFINE Angebot2;

Page 33: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-33

Unterstützung von SELECT *FROM AngebotWHERE KursNr = :KursNr AND Ort = :Ort

1. Definition eines geeigneten PCB

(wie oben)

2. Generierung der entsprechenden Angebot-Tupel

DEFINE Angebot3 ( AngNr : INT; KursNr : CHAR[3];Datum : DATE; Ort : VARCHAR[20] )

ASVAR KursSegment ... AngebotSegment ...BEGINResultBuffer.Create(AngNr, KursNr, Datum, Ort)GU Kurs *D (KursNr = :KursNr)

Angebot (Ort = :Ort)IF NOT "record found" THEN exit("no records found");ResultBuffer.next;ResultBuffer.AngNr := AngebotSegment.AngNrResultBuffer.KursNr := KursSegment.KursNr;ResultBuffer.Datum := AngebotSegment.Datum;ResultBuffer.Ort := AngebotSegment.Ort;

LOOP GN Kurs *D (KursNr = :KursNr)

Angebot (Ort = :Ort) IF NOT "record found" THEN exit("no more records found"); ResultBuffer.next; ResultBuffer.AngNr := AngebotSegment.AngNr ResultBuffer.KursNr := KursSegment.KursNr; ResultBuffer.Datum := AngebotSegment.Datum; ResultBuffer.Ort := AngebotSegment.Ort;ENDLOOP;

ENDDEFINE Angebot3;

Page 34: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-34

Unterstützung von SELECT *FROM AngebotWHERE KursNr = :KursNr AND Datum = :Datum

1. Definition eines geeigneten PCB

(wie oben)

2. Generierung der entsprechenden Angebot-Tupel

DEFINE Angebot4 ( AngNr : INT; KursNr : CHAR[3];Datum : DATE; Ort : VARCHAR[20] )

ASVAR KursSegment ... AngebotSegment ...BEGINResultBuffer.Create(AngNr, KursNr, Datum, Ort)GU Kurs *D (KursNr = :KursNr)

Angebot (Datum = :Datum)IF NOT "record found" THEN exit("no records found");ResultBuffer.next;ResultBuffer.AngNr := AngebotSegment.AngNrResultBuffer.KursNr := KursSegment.KursNr;ResultBuffer.Datum := AngebotSegment.Datum;ResultBuffer.Ort := AngebotSegment.Ort;

LOOP GN Kurs *D (KursNr = :KursNr)

Angebot (Datum = :Datum) IF NOT "record found" THEN exit("no more records found"); ResultBuffer.next; ResultBuffer.AngNr := AngebotSegment.AngNr ResultBuffer.KursNr := KursSegment.KursNr; ResultBuffer.Datum := AngebotSegment.Datum; ResultBuffer.Ort := AngebotSegment.Ort;ENDLOOP;

ENDDEFINE Angebot4;

Page 35: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-35

Unterstützung von INSERT INTO Angebot VALUES ( :AngNr, :KursNr, :Datum, :Ort )

1. Definition eines geeigneten PCBPCB DBDNAME=KursDBSENSEG NAME=Kurs, PROCOPT=GSENFLD KursNrSENSEG NAME=Angebot, PROCOPT=G,I

•••

END

2. Bereitstellung der Insert-Funktion

DEFINE Angebot5 ( AngNr : INT; KursNr : CHAR[3];Datum : DATE; Ort : VARCHAR[20] )

ASVAR KursSegment ... AngebotSegment ...BEGINGU Kurs (KursNr = :KursNr)IF NOT "record found" THEN exit("parent does not exist");GNP Kurs

Angebot(AngNr = :AngNr)IF "record found" THEN exit("duplicate key");

AngebotSegment.AngNr := :AngNr;AngebotSegment.Datum := :Datum;AngebotSegment.Ort := :Ort;GU Kurs (KursNr = :KursNr)GHNP AngebotINSRT;

ENDDEFINE Angebot5;

Page 36: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-36

r Bereitstellung von "LRS-Operationen" 8:

1. Vorübersetzte Operationen

+ Effizienz

- Eingeschränkte Funktionalität (Rest muß durch vDBMS erledigtwerden)

- dadurch kompliziertere Abbildung von globalen Anweisung auflokale Anweisungen

2. Dynamisch erzeugte IMS-Anweisungen (+ Kontrollstrukturen)

+ I.d.R. mehr funktionale Mächtigkeit

- aufwendigere Implementierung der LRS-Operationen

- Effizienz (echte Programmübersetzungen zur Ausführungszeit)

3. Ideallösung: Semantisch höheres operationales Datenmodell,das alle zu integrierenden Datenmodelle umfaßt

Leider in der vollen Allgemeinheit nicht (nie?) verfügbar

Möglicher Ansatz für Integration SQL + IMS: NF2-Relationen

n Globales operationales Datenmodell: NF2-Relationen

n Integration von SQL-Systemen: "Flache" Relation ist Spezial-Falleiner NF2-Relation

n Integration von IMS-Systemen: LRS-Darstellung von IMS-Hierarchien als NF2-Relationen (= geschachtelte Relationen) 9

8 Gilt i.w. auch für CODASYL-Systeme9 K. Küspert, A. Perkhoff, A.: AIM-P-IMS: Konzepte einer NF2-Modell- und Sprachoberfläche fürein hierarchisches Datenbanksystem, in: U.W. Lipeck, S. Braß, G. Saake (Hrsg.):Kurzfassungen des 2. Workshops "Grundlagen von Datenbanken", Volkse, Juni 1990, TUBraunschweig, Bericht Nr. 90-02, S. 57-60

Page 37: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-37

{ Kurse }

KursNr Titel { Angebote } { Vorauss }

AngNr Datum Ort VorNr

G08 Grundlagen I 12

01-13-199302-24-1993

MünchenBremen

G10 Grundlagen II 12

02-01-199302-15-1993

MünchenHamburg

P13 C-Programmierung 12

05-28-199307-01-1993

UlmEssen

G08G10

I09 Datenbanken 123

03-27-199304-23-199305-29-1993

StuttgartHamburgMünchen

G08G10P13

Beispiel 5-4: Ausgabe alle Angebote (incl. KursNr + Titel) nach Vorgabe der KursNr

Ergebnis als geschachtelte Relation: Ergebnis als "flache" Relation: 10

SELECT x.KursNr, x.Titel, x.AngeboteFROM x IN KurseWHERE x.KursNr = :KursNr

SELECT x.KursNr, x.Titel, y.AngNr, y.Datum, y.OrtFROM x IN Kurse, y IN x.AngeboteWHERE x.KursNr = :KursNr

10 Vertiefungsliteratur zu NF2-Relationen (u.a.): P. Pistor, R. Traunmüller: A Database Language for Sets, Lists, and Tables, Vol. 11, No. 4,1986, pp. 323-336 sowie P. Dadam et al.: A DBMS Prototype to Support Extended NF2 Relations: An Integrated View on Flat Tables andHierarchies, Proc. ACM-SIGMOD Conf., Washington, D.C., May 1986, pp. 356-367

Page 38: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-38

r Übungsaufgabe 5-1:

Überlegen Sie sich eine mögliche IMS-Implementierung zur Unterstützungvon

UPDATE AngebotSET Ort = :OrtWHERE KursNr = :KursNr AND AngNr = :AngNr

r Übungsaufgabe 5-2:

Überlegen Sie sich eine mögliche IMS-Implementierung zur Unterstützungvon

DELETEFROM AngebotWHERE KursNr = :KursNr AND AngNr = :AngNr

r Übungsaufgabe 5-3:

Überlegen Sie sich die Realisierung der besprochenen Abbildungen ineinem CODASYL-DBMS

Page 39: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-39

r Anmerkungen

m Nachträgliche Integration existierender, heterogener DB-Schemata aufwendige Aufgabe

m "Bastel-Lösungen" nur bei "kleinen" Lösungen sinnvoll

m Allgemein einsetzbare Ansätze gefordert

m Derzeit wieder sehr aktuelles Forschungsgebiet 11

n Erarbeitung der theoretischen Grundlagen

n Bereitstellung von Integrations-Werkzeugen

m Allgemeines Problem: "Automatische" Konversionen erfordernhohen Grad an semantischem Wissen 12

n einfache funktionale Abhängigkeiten

n mehrwertige funktionale Abhängigkeiten

n Attribut-Äquivalenzen

n ...

m Diese Information - insbesondere in "alten" DB-Systemen - inden seltensten Fällen explizit vorhanden

11 Eine Auswahl von etwas "breiter" angelegten Artikeln ist in der Ergänzenden Literatur amEnde dieses Kapitels angegeben.12 Hier besteht eine gewisse Problem-Verwandtschaft zur Relationen-Synthese beimDatenbank-Entwurf

Page 40: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-40

5.7 Realisierung des globalen Kataloges

r Katalog = Schema

+ statistische Information

+ Autorisierung

+ ...

r Zugriff auf Katalog(ausschnitt) wird benötigt bei jederÜbersetzung einer DB-Anfrage

1. Relation "Angest" bekannt?

SELECT

FROM

WHERE

PersNr, AngName, Anschrift

Angest

MgrPersNr = 3456

2. Alles Attribute von Angest?

3. Konstante typverträglich mit Wertebereich von MgrPersNr?

4. Ist "Angest" partitioniert? Wo ist "Angest" allokiert? Zugriffsbeschränkungen?

Abb. 5-17: Bedeutung des (globalen) Kataloges

Page 41: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-41

r Globaler Katalog, nicht-redundant gespeichert

m Vorteile:

n kein Kopien-Aktualisierungs-Problem

n geringster Speicherplatzbedarf

m Nachteile:

n Kommunikation für jede Anfrage erforderlich (Aufwand)

n Potentieller Flaschenhals (Performance)

n kritische Ressource (Ausfallsicherheit)

r Globaler Katalog, voll-redundant gespeichert

m Kritisch, falls häufige Aktualisierungen erforderlich

r Globaler Katalog, teil-redundant gespeichert

"Cluster"-Kataloge

Page 42: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-42

r Verzicht auf expliziten globalen Katalog

Beispiel: R*-Ansatz 13

m "Geburtsort" aus Relationsnamen ableitbar (Präfix)

m "Geburtsort" führt Buch über jeweils aktuellen Speicherungsort

m Knoten besorgen sich für Anfragebearbeitung den aktuellenKatalogeintrag (für betroffene Relationen)

m Knoten heben Katalogeintrag + Speicherungsort für spätereAnfragebearbeitungen auf (caching)

m Übersetzte (Teil-)Anfragen führen Katalog-Zeitstempel mit

m Der ausführende Knoten überprüft, ob

n gewünschte Relation noch lokal vorhanden ist

n der mitgegebene Katalog-Zeitstempel noch aktuell ist

n falls nicht ⇒ Zurückweisung der Anfrage⇒ Neu-Übersetzung der Anfrage

m Bewertung:

+ Sehr hoher Grad an lokaler Autonomie

+ Benutzungsgesteuerte Aktualisierung der lokalenKatalogauschnitte

- Keine einheitliche Realisierung globaler Sichten

- Weniger gut geeignet für partitionierte Speicherung("wer führt Buch?")

13 D. Daniels et al.: An Introduction to Distributed Query Compilation in R*: Proc. 2ndSymposium on Distributed Databases, Berlin, Sept. 1982, (Distributed Databases, H.J.Schneider (ed.), North-Holland, 1982)

Page 43: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-43

5.8 Ergänzende Literatur

r S. Conrad: Föderierte Datenbanksysteme – Konzepte derDatenintegration. Springer-Verlag, 1997

r J. Geller, Y. Perl, E. Neuhold, A. Sheth: Structural Schema Integration withFull and Partial Correspondence Using the Dual Model, InformationSystems, Vol. 17, No. 6, 1992, pp. 443-464

r D.K. Hsiao: Federated Databases and Systems: Part I - A Tutorial on TheirData Sharing, VLDB Journal, Vol. 1, No. 1, July 1992, pp. 127-179

r J.A. Larson, S.B. Navathe, R. Elmasri: A Theory of Attribute Equivalence inDatabases with Application to Schema Integration, IEEE Transactions onSoftware Engineering, Vol. 15, No. 4, April 1989, pp. 449-463

r C. Batini, M. Lenzerini, S.B. Navathe: A Comparative Analysis ofMethodologies for Database Schema Integration, ACM ComputingSurveys, Vol. 18, No. 4, Dec. 1986, S. 323-364

r A.P. Sheth, J.A. Larson: Federated Database Systems for ManagingDistributed, Heterogeneous, and Autonomous Databases, ACMComputing Surveys, Vol. 22, No. 3, Sept. 1990, pp. 183-236

r S. Spaccapietra, Chr. Parent, Y. Dupont: Model Independent Assertionsfor Integration of Heterogeneous Schemas, VLDB Journal, Vol. 1, No. 1,July 1992, pp. 81-126

Page 44: 5. Schema-Architekturen verteilter Datenbanksysteme · P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme 5. Schema-Architekturen verteilter Datenbanksysteme 5-1 5.

P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-44