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)
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
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
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
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)
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
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
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
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
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
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?
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.
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
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)
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
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
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
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
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
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
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.
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
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
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)
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 ....... ... ... ...
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.
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
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
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
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;
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;
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;
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;
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;
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;
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
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
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
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
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
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
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)
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
P. Dadam, 1999 - Verteilte Datenbanken und Client/Server-Systeme5. Schema-Architekturen verteilter Datenbanksysteme 5-44