270 likes | 384 Views
Kap. F: Föderierte Datenbanksysteme. Motivation, Begriffsbestimmungen. Objekte in föderierten DBMS. • Grade der Kooperation. • Fünf-Schichten-Architektur. • Integration von Objekttypen. • Semantische Konflikte. • Integration von Objekten. F.1 Motivation und Begriffsbestimmungen. •.
E N D
Kap. F: Föderierte Datenbanksysteme Motivation, Begriffsbestimmungen Objekte in föderierten DBMS • Grade der Kooperation • Fünf-Schichten-Architektur • Integration von Objekttypen • Semantische Konflikte • Integration von Objekten
F.1 Motivation und Begriffsbestimmungen • Existierende DBMS und existierende Anwendungen beibehalten. Neue DBS- umspannende Anwendungen sollen ent- wickelt werden ("Interoperabilität"). • Zerlegung komplexer Aufgaben in ein- fachere Teilaufgaben. – Autonome Bearbeitung – Parallelisierung – Dezentralisierung – Sicherheit • Rechnernetze vorhanden. Voraussetzung für Zusammenarbeit ge- geben. Aufbau höherer Dienste aus vorhandenen einfacheren möglich.
? . . Produkt- CAD planung Finanz- planung Daten Daten Daten ? . . ORACLE DB 1 Motivation - 2 Anwendungssicht Datenbanksicht Sybase Sybase DB 3 DB 2
Beispiel Uni-Informationssystem Verschiedene Datenbanken: Studenten Fächer Prüfungen Bücher Personen Ausleihe Studenten-DB Bibliothek-DB Exmatrikulation: - Test: Student hat alle Prüfungen abgelegt - Test: Student hat alle Bücher zurückgegeben - Löschen als Bibliotheksbenutzer - Ausstellung des Zeugnisses Nur ein gemeinsamer Zugriff auf alle Daten gewährleistet die konsistente Ausführung aller Operationen!
Grobarchitektur Föderierter Datenbanken … Ausführung globaler und lokaler Anwendungen GA FDBMS LA LA n 1 LDBMS LDBMS … 1 n DB DB 1 2 LDBMSe autonom. LA = lokale Anwendung GA = globale Anwendung
Verteilung, Föderation, Autonomie Verteilung: Globales Schema Orts-, Fragmentierungs- und Replikationstransparenz Föderation: Zusammenschluss von mehreren autonomen Kompo- nentendatenbanksystemen mit ihren Datenbanken zur Unter- stützung systemübergreifender ("globaler") Anwendungen kein globales Schema. Koexistenz globaler und lokaler Anwendungen vollständige vollständige Föderation Integration Autonomie verteilte keine Zusammenarbeit Datenbanken möglich
Verteilung 6 2 7 8 4 1 Autonomie 5 3 Heterogenität Klassifikation Zentral – verteilt integriert – autonom homogen – heterogen ... alle Kombinationen existieren
Grade der Kooperation von loser Föderation Interoperabilität • Datenaustausch, Konversion • Anfragen über mehrere Komponenten-DBMSe • Änderungen in Komponenten-DBMSe • Globale Transaktionen • Globale Sichten • Teilschema-Integration zu engerer Föderation
Fünf-Schichten-Architektur für FDBS External Schema 1 External Schema 2 filter transform Federated Schema construct Export 1 Export 2 filter filter Component 1 Component 2 transform transform Local Schema 1 Local Schema 2 DB1 DB2
+ D1.DEPT F.2 Integration von Objekttypen Fall 1: Gleiche Typen Name Name D2.DEPT DEPT Name
+ Integration von Objekttypen -2 Fall 2: Typ und Subtyp MatNr MatNr DIPLOMAND STUD Fach Fach Dipl.-Arb. MatNr STUD Fach DIPLOMAND Dipl.-Arb.
Name Name INGENIEUR Gehalt SEKRETÄR Gehalt + Typ Stufe Integration von Objekttypen -3 Fall 3: Gemeinsamer Supertyp Name ANG Gehalt SEKRETÄR INGENIEUR Stufe Typ disjunkt Domain nicht disjunkt
+ Integration von Objekttypen -4 Fall 4: Nicht (direkt) integrierbare Typen Name PERSON Gewicht Adresse ? Name WERKZEUG Gewicht Typ Keine Integration!
+ + F.3 Semantische Konflikte (1) Namenskonflikte Synonyme / Homonyme z. B. KUNDE für Kunde KLIENT STUD…für Praktikant STUD…für Student (2) Wertemengen-Konflikte • verschiedene Typen (AHV-NR ist Integer oder String) • verschiedene Masseinheiten DM, Dollar) (Gehalt in SFR, • verschiedene Kodierung (Datum, Zeit)
Deptnr + Name ANGEST AHVNR Semantische Konflikte - 2 (3) Typ-Konflikte, Fall A: Attribut oder Beziehung? DEPT Deptnr (0,*) AD Name (1,1) ANGEST AHVNR
Semantische Konflikte - 3 (3) Typ-Konflikte, Fall B: Entität oder Beziehung? Name PERS (0,*) PB (1,1) Anzahl BESTELLUNG (1,1) WB (0,*) WARE Wnr + Name PERS (0,*) Anzahl B (0,*) Wnr WARE
+ Semantische Konflikte - 4 (3) Typ-Konflikte, Fall C: Rekursive Beziehung oder Subtypen? Mann Name PERS VERH Frau PERS Name VERH VMÄNNER VFRAUEN
+ Semantische Konflikte - 5 (3) Typ-Konflikte, Fall D: Schema oder Metaschema? Oid MNAME (0,*) (1,*) BESCHR MERKMAL WERT OBJEKT Oid OBJEKT KFZ Leistung AHVNR PERS Marke Name Wohn Kennz Besitzer
+ Semantische Konflikte - 6 (3) Typ-Konflikte, Fall D: Schema oder Metaschema? Beispiel auf Instanzebene: OBJEKT Oid MNAME WERT 1 AHVNR 4711 1 Name Hugo 1 Wohn Zürich 2 Kennz ZH-0815 2 Besitzer Franz 2 Marke Citroen 2 Leistung 160 … … … PERS Oid AHVNR Name Wohn 1 4711 Hugo Zürich KFZ Oid Kennz Besitzer Marke Leistung 2 ZH-0815 Franz Citroen 160
F.3 Semistrukturierte Daten im Referenz-modell semantischer Datenmodelle Zur Erinnerung: RMSDM hat folgende Typen (schwarz) Vereinigung Wir fügen einen Vereinigungstyp Ú hinzu
Beispiel im RMSDM OEM dargestellt im RMSDM (s. Vorl)
Erweiterung des Deskriptor-orientierten Datenmodells Jedes Objekt hat eine Beschreibung b, nämlich eine Menge B von Deskriptoren D, jeder Deskriptor D hat Namen N, Typ T, Wert W: O oid b B Oid D W N T Jetzt: Hinzunahme eines Vereinigungstyps zum RSDM (Symbol V) zur Erfassung von Hierarchien variabler Tiefe und allgemeineren Graphen:
Vereinigungstyp O oid b • Ein Objekt hat eine Beschreibung b, die entweder ein (anderes) Objekt ist oder eine Menge B ist von Deskriptoren ist. Ein Deskriptor D ist entweder atomar und besteht aus einem Typ-Wertpaar, oder er ist objektwertig. V Oid B D O N V N A O T W