18.09.2018 Aufbau Integrierter Informationssysteme Einsatz föderativer Datenbanksysteme Falk Ritschel, Stefan Springer, Falko Steponat Martin-Luther-Universität.

Präsentation zum Thema: "18.09.2018 Aufbau Integrierter Informationssysteme Einsatz föderativer Datenbanksysteme Falk Ritschel, Stefan Springer, Falko Steponat Martin-Luther-Universität."—  Präsentation transkript:

1 Aufbau Integrierter Informationssysteme Einsatz föderativer Datenbanksysteme Falk Ritschel, Stefan Springer, Falko Steponat Martin-Luther-Universität Halle-Wittenberg Informatikseminar - Halle © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

2 Gliederung 1. Einleitung 2. Konzeptionelle Architektur
Gliederung 1. Einleitung 2. Konzeptionelle Architektur 3. Wege zu integrierten Datenbanksystemen 4. Erhaltung von integrierten Datenbanksystemen 5. Zusammenfassung - Fazit - Ausblick Einsatz föderativer Datenbanksysteme © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

3 Definitorische Abgrenzung
Gliederung 1. Einleitung Was ist Föderation? Warum FDBS? Definitorische Abgrenzung 2. Konzeptionelle Architektur 3. Wege zu integrierten Datenbanksystemen 4. Erhaltung von integrierten Datenbanksystemen 5. Zusammenfassung - Fazit - Ausblick Einsatz föderativer Datenbanksysteme © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

4 Gliederung Einleitung Föderative DBS Was ist Föderation?
Gliederung Einleitung Was ist Föderation? Eine Grobe Skizze Warum FDBS? Anwendungsszenarien Definitorische Abgrenzung Zentrale DBS Verteilte DBS Multidatenbanksysteme Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

5 1. Was ist Föderation Föderative DBS Föderation:
1. Was ist Föderation Föderation: Bündnis von Staaten oder Teilstaaten EU-Staaten mit unterschiedlicher Struktur (Heterogen) Jedes BL ist quasi eigener Staat BL mit ähnlicher Struktur (Homogen) Teilautonomie unter übergeordneter Instanz Jedes BL mit eigener Gesetzgebung und Rechtssprechung Anerkennung gemeinsamer Regeln: -Verfassung, Bundesgesetze Heterogen & Homogen auch in DB... Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

6 2. Eine Grobe Skizze Föderative DBS Aufgaben der Zusatzschicht:
2. Eine Grobe Skizze Aufgaben der Zusatzschicht: – globale Anfragen und Transaktionen bearbeiten – Zerlegung in Teilanfragen (bei Leseoperationen) – Zusammenfassen der Teilergebnisse – Transaktionsverwaltung Zu integrierende DBS  KomponentenDBS Interne Organisation unverändert Föderierungsdienst : - globale Anfragen auf Gesamtdatenbestand - Transaktionsverwaltung: Synchronisation von glob. Anwdg.  keine Zugriffskonflikte Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

7 2. Eine Grobe Skizze Föderative DBS 1. 2. 3. 4. 5. 18.09.2018
FRAGE: - globale Schreibberechtigung  Konflikte m. lokal DBS? - Behandlung von Redundanzen in lokalen DB Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

8 2. Eine Grobe Skizze Föderative DBS Föderative DBS (FDBS):
2. Eine Grobe Skizze Föderative DBS (FDBS): Menge autonomer, möglicherweise heterogener DBS, die in begrenztem Umfang kooperieren, um externen Benutzern einen zentralen Zugriff auf Teile ihrer Daten zu gestatten. Nebenanforderungen möglichst erfüllen: Verteilungstransparenz Verbergen der Heterogenität DB-Operationen auf mehreren Datenbanken Transaktionskonzept Verteilungstransparenz: ext. Nutzer interessiert nicht in welcher DB die Daten sind Heterogenität: einheitliche Anfragesprache einheitliches Datenmodell automatische Behandlung von semantischer Heterogenität Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

9 3. Warum FDBS Frage: Wozu FDBS? Föderative DBS
3. Warum FDBS Frage: Wozu FDBS? Defizite bei programmierter Verteilung und Fernzugriff auf Datenbanken: innerhalb einer Operation kann nicht auf mehrere Datenbanken zugegriffen werden keine Unterstützung bei der Behandlung semantischer Heterogenität Sem. Heterogenität: nicht übereinstimmendes Verständnis über die Bedeutung und Interpretation von gleichen oder zusammengehörigen Daten sowie die Verwendung dieser - z.B.: gleiche Daten werden nicht als solche erkannt  Später mehr Verteilungstransparenz: Keine unterschiedliche Handhabung egal wo Daten gespeichert sind  Ebenfalls später mehr geringer Grad an Verteilungstransparenz Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

10 Redundanzen Inkonsistenzen
3. Warum FDBS Beispiel 1: Heterogene Hard- & Softwarelandschaft im Unternehmen  Insellösungen Redundanzen Jede Abteilung versch. Anwendungen und Systeme Inkonsistenzen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

11 3. Warum FDBS Föderative DBS Abteilungsübergreifende Abläufe:
3. Warum FDBS Abteilungsübergreifende Abläufe: gleichzeitiger Zugriff auf Daten mehrerer Abtlg. Transaktionsverwaltung: Synchronisation von glob. Anwdg.  keine Zugriffskonflikte Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

12 3. Warum FDBS Föderative DBS Anforderungen: Autonomie der lokalen DB
3. Warum FDBS Anforderungen: Autonomie der lokalen DB Redundanzkontrolle Globale Integritäts- überwachung Transaktionsverwaltung Transparenz Abteilungsübergreifende Abläufe: gleichzeitiger Zugriff auf Daten mehrerer Abtlg. Globale Integritätsüberwachung Mechanismen zur Konsistenzkontrolle redundanter Daten auf globaler Ebene Transaktionsverwaltung: Synchronisation von glob. Anwdg.  keine Zugriffskonflikte Verteilungstransparenz: globale Benutzer/Anwendungen sollten nicht über verteilte Datenspeicherung Bescheid wissen müssen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

13 3. Warum FDBS Migration: Föderative DBS Beispiel 2:
3. Warum FDBS Beispiel 2: Migration: Ablösung von Legacy-Systemen Bestehende Daten und Anwendungen sollen übernommen werden Neuentwicklung der Anwendungen nicht wirtschaftlich Einfache Portierung der Anwendungen oft nicht möglich MIGRATION WEIL: zu hohe Wartungskosten fehlende Unterstützung durch Systemhersteller . Altsystem durch überlastet Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

14 3. Warum FDBS Föderative DBS
3. Warum FDBS Risiko, dass in Übergangszeit neues System nicht stabil läuft Allmähliche Ablösung des Altsystems fortlaufender Betrieb während der Migration muss gewährleistet sein 24h-pro-Tag{ / 7-Tage-die-Woche{Betrieb ! Big-Bang Lösung nicht möglich ! also allmähliche Ablösung in kleinen Schritten Beide Systeme laufen parallel Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

15 INKONSISTENZEN 3. Warum FDBS Föderative DBS
3. Warum FDBS INKONSISTENZEN Datenhaltung wird redundant Beide Systeme laufen parallel Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

16 Geschäftsbetrieb muss nicht eingestellt werden
3. Warum FDBS Zentraler Vorteil: Geschäftsbetrieb muss nicht eingestellt werden Altsystem Neusystem Anwendungs-migration Probleme: Effizienzeinbußen durch globale Schnittstelle Rücktransformation von Neusystem aus Föderation durch interne Transformationen von globaler zur Legacy-Schnittstelle (Anwendung wird noch auf Altsystem ausgeführt) wenn Neusystem nach Migration allein arbeiten soll, d.h. nicht in Föderation globale Anwendungen des Altsystems müssen zu lokalen des Neusystems werden oft Anwendungsportierung notwendig (aufwendig) Daten-migration Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

17 4. Definitorische Abgrenzung
4. Definitorische Abgrenzung Zum Verständnis der FDB-Architektur ist das Verstehen von Basisarchitekturen essentiell: Zentrale DBS Verteilte DBS Multidatenbank-systeme Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

18 4. Definitorische Abgrenzung
Z-DBS 4. Definitorische Abgrenzung V-DBS MDBS enthält Implementierung für konkretes DBS (Speicherungsstrukturen: Listen, Bäume,Indexe) Beschreibt Daten in ihrer Gesamtheit abstrakt und systemunabhängig Vereinigt alle Benutzersichten · externe Sicht: Benutzer / Programme 3-Ebenen-Architektur nach ANSI/SPARC (American National Standards Institute) Für jeden Benutzer eigenes Schema Enthält Beschreibung der Daten die dieser benötigt · konzeptionelle Sicht: ganzes Unternehmen · interne Sicht: System, Maschine Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

19 4. Definitorische Abgrenzung
Z-DBS 4. Definitorische Abgrenzung V-DBS MDBS 3-Ebenen-Schemadarstellung nötig um Datenunabhängigkeit zu gewährleisten Datenunabhängigkeit Kann externe Schemata ändern ohne interne verändern zu müssen Weitgehend andersrum ebenso Für bspw. effizienteren DB-Zugriff möglich internes Schema entsprechend zu ändern ohne Schnittstellen der Anwendungen zu berühren Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

20 4. Definitorische Abgrenzung
Z-DBS 4. Definitorische Abgrenzung V-DBS MDBS 4-Ebenen-Schema-Architektur Verteilte Datenbanksysteme Mit Rechnernetzen entstand Bedarf von verschiedenen Rechnern auf einen Datenbestand zuzugreifen Vorteile: Rechenleistung mehrerer Rechner Zugriffsengpässe zentraler DBS werden vermieden Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

21 4. Definitorische Abgrenzung
Z-DBS 4. Definitorische Abgrenzung V-DBS MDBS 4-Ebenen-Schema-Architektur Verteilte Datenbanksysteme Verteilte Daten sollen von einen DBS verwaltet werden Verteilungstransparenz ist sicherzustellen Verteilungstransparenz: Jeder Anwender denkt er arbeitet mit zentralen DBS Daten von jedem Rechner aus verfügbar Keine unterschiedliche Handhabung egal wo Daten sind Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

22 4. Definitorische Abgrenzung
Z-DBS 4. Definitorische Abgrenzung V-DBS MDBS Integration von: allen externen Schemata aller lokaler konzeptioneller Schemata 4-Ebenen-Schema-Architektur Beschreibung der Daten des einzelnen Rechners Abhängig von Verteilungsstrategie können Redundanzen auftreten 4-Ebenen-Schema-Architektur basiert auf ANSI/SPARC Modell Analog zentralen DBS Datenbeschreibung für einzelnen Benutzer (durch Verteilungstransparenz) Für jeden Rechner eigenes internes UND eigenes konzeptionelles Schema Für Verteilungstransparenz Zusammenfassung lokaler konzeptioneller Schemata zu globalen konzeptionellen Schema Analog zentralen DBS Darauf Aufsetzung der externen Schemata Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

23 4. Definitorische Abgrenzung
Z-DBS 4. Definitorische Abgrenzung V-DBS MDBS Multidatenbanksysteme: Verbund von mehreren DBS Gründe: Aufteilung von komplexen DBS in Teildatenbestände: - effizienter - flexibler (mehrere DBMS) Zu bestehenden DBen soll neue hinzugefügt werden  Ersparnis der Migration Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

24 4. Definitorische Abgrenzung
Z-DBS 4. Definitorische Abgrenzung V-DBS MDBS Komponenten-systeme vollständig auf übergeordneter Ebene verwaltet Komponenten-systeme autonom Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

25 4. Definitorische Abgrenzung
Z-DBS 4. Definitorische Abgrenzung V-DBS MDBS Es existiert nur ein einziges föderiertes Schema Nebeneinander mehrere föderierte Schemata Durch Administrator verwaltet (Kompromisse notwendig) Benutzer stellt Föderation selbst zusammen & verwaltet diese Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

26 4. Definitorische Abgrenzung
Z-DBS 4. Definitorische Abgrenzung V-DBS MDBS Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

27 Gliederung 1. Einleitung 2. Konzeptionelle Architektur
Gliederung 2. Konzeptionelle Architektur 1. Einleitung 3. Wege zu integrierten Datenbanksystemen 4. Erhaltung von integrierten Datenbanksystemen 5. Zusammenfassung - Fazit - Ausblick Import/Export- Schema- Architektur Multidatenbanken- Architektur 5-Ebenen- Schema- Architektur Einsatz föderativer Datenbanksysteme © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

28 Gliederung Konzeptionelle Architektur Föderative DBS
Gliederung Konzeptionelle Architektur Verteilung, Heterogenität, Autonomie Architekturen Import / Export-Schema-Architektur Multidatenbanken-Architektur 5-Ebenen-Architektur Vergleich der Architekturen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

29 1. Verteilung, Heterogenität, Autonomie
1. Verteilung, Heterogenität, Autonomie Verteilung verteilte homogene DBS verteilte föderierte DBS verteilte heterogene föderierte DBS verteilte heterogene DBS homogene föderierte DBS logisch integrierte und homogene DBS Autonomie heterogene integrierte DBS heterogene föderierte DBS Heterogenität Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

30 1. Verteilung Föderative DBS Daten Schema Operationen
1. Verteilung Daten Schema Daten können zentral, verteilt oder partitioniert gespeichert werden Partitionierung soll Redundanz verhindern Replikation möglich aber, muss vom System automatisch kontrolliert werden Verteilung kann beabsichtigt eingeführt werden tritt aber oft auch unkontrolliert auf Operationen man kann auch für Operationen die das Datenbanksystem bereitstellt Verteilungsformen unterscheiden z.B.: wird die Operation auf jedem Rechner oder nur auf einem oder wenigen ausgeführt Schema = Metadaten verhalten sich analog zu den Daten zentrale Speicherung erlaubt aber die Verteilung auf mehrere DB Partitionierung auf mehrere RDB und/oder Rechner verhindert Redundanzen Zur Verbesserung des lokalen Zugriff können Daten auch repliziert werden (Redundanz muss dann jedoch vom System kontrolliert und sichergestellt werden) Verteilung kann quasi historisch wachsen wenn innerhalb eines Unternehmens unabhängig voneinander DB entstanden sind, in denen typischerweise Daten gespeichert sind die zueinander in Beziehung stehen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

31 1. Heterogenität Föderative DBS Heterogene Datenbanksysteme
1. Heterogenität Heterogene Datenbanksysteme Semantische Heterogenität = nicht übereinstimmendes Verständnis über die Bedeutung und Interpretation von gleichen oder zusammengehörigen Daten sowie die Verwendung dieser Daten verschiedene Systemebenen können Heterogenität aufweisen unterschiedl. Datenmodelle sind zentraler Punkt Maße der Modellierungs- konstrukte bedingen bei selben Datenmodell möglicherweise Heterogenitäten verschiedene Integritätsbedingungen werden unterstützt verschiedene Anfragesprachen zu jedem Datenmodell unterschiedliche Genauigkeit numerischer Werte (besonders bei Überprüfung auf Gleichheit) Attribut das den Preis angibt kann ohne zusätzliche Information nicht eindeutig bestimmt werden (Währung?, Mehrwertsteuer?) Unterschiede in der Transaktionsverwaltung bei gleichem Datenmodell Unterschiedliche Datenmodelle: relationales Modell, Netzwerkdatenmodell, Objektorientiertes Datenmodell, XML-Basiertes Datenmodell Derselbe Weltausschnitt wird in verschiedenen Schemata in untersch. Strukturen abgebildet Mehrere Ausdrucksmöglichkeiten für gleichen Sachverhalt (Heterogenität auf Schemaebene) Bestimmte Integritätsbedingungen können durch eine geeignete Modellierung inhärent gemacht werden, andere müssen explizit formuliert werden Transaktionsverwaltung: untersch. Sperr- und Commit-Protokolle sowie verschiedene Recovery-Verfahren Semantische Heterogenität schwerer zu entdecken und zu behandeln Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

32 1. Autonomie Föderative DBS Entwurfsautonomie Kommunikationsautonomie
1. Autonomie Entwurfsautonomie Kommunikationsautonomie einzelne DB sind unabhängig voneinander entworfen worden beim Eintritt in die Föderation sollen die lokalen Schemata erhalten bleiben theoretisch müssten dann die Komponenten-systeme jeder Zeit in der Lage sein ihr lokales Schema zu ändern es ist fraglich ob dieser Grad der Entwurfs-autonomie in FDBS unterstützt werden kann Ausführungsautonomie die einzelnen Systeme entscheiden selbst mit welchem anderen System sie kommunizieren DBS entscheidet selbst ob und wann es in die Föderation eintritt und wann sie diese wieder verlässt es kann auch über die Kommunikation mit anderen Komponentensystemen frei entschieden werden die DBS sind in der Lage selbst zu entscheiden welche Anwendungsprogramme, Anfragen und Änderungsoperationen es ausführt und zu welchem Zeitpunkt sollte ein System innerhalb eines geschlossenen Verbandes von DBS von anderen Systemen direkt oder durch ein übergeordnetes System gezwungen werden bestimmte Aufgaben auszuführen so hat es seine Ausführungsautonomie verloren Wenn durch die Föderierungsebene keine Veränderungen in den lokalen Schemata gemacht werden können ist vollständige Entwurfautonomie gegeben Jede lokale Schemaänderung kann einen nicht unerheblichen Aufwand für die Anpassung bedeuten Kommunikationsautonomie spielt vor allem bei der Import/Export-Architektur eine wichtige Rolle, da dort angenommen wird das die Systeme den Zugriff auf Datenbestände verhandeln Der Zwang, welcher zum Verlust der Ausführungsautonomie führt, kann sich beispielsweise darin äußern das ein System nicht mehr selbst über die Reihenfolge entscheiden kann, in der es anstehende Aufgaben erledigt Zum Beispiel bei der Transaktionsverwaltung in MDBS Jedes System hat eigene Transaktionsdatenverwaltung (bestimmt in welcher Reihenfolge zu erfüllende Aufgaben erledigt werden sollen und wie deren Teilschritte in einander verschränkt werden sollen) Bei Ausführungsautonomie der einzelnen Systeme kann globale übergreifende Transaktionsverwaltung nur sehr begrenzt stattfinden Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

33 1. Autonomie Föderative DBS Einzelsysteme = Komponentensysteme
1. Autonomie Einzelsysteme = Komponentensysteme Wenn durch die Föderierungsebene keine Veränderungen in den lokalen Schemata gemacht werden können ist vollständige Entwurfautonomie gegeben Jede lokale Schemaänderung kann einen nicht unerheblichen Aufwand für die Anpassung bedeuten Datenbestände werden für systemübergreifende Anwendungen verfügbar Bestehende Anwendungsprogramme können unverändert auf KS laufen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

34 1. Autonomie Es wird eine gewisse Autonomie der Komponentensystem gewährleistet. Es wird eine gewisse Autonomie der Komponentensystem gewährleistet. Risiken der Portierung von Daten und Anw. Historisch entstandene Insellösungen FDBS schaffen Abhilfe durch Föderierungsdienst der die Kommunikation mit den isolierten Systemen gewährleistet FDBS bieten durch diesen Dienst globale Datenbankfunktionalität für den Nutzer eng und lose gekoppelte föderierte Systeme benötigen abweichende Funktionalität des Föderierungsdienstes Wichtig weil ... Vielzahl spezifischer Anwendungsprogr. Investitionsschutz Wenn durch die Föderierungsebene keine Veränderungen in den lokalen Schemata gemacht werden können ist vollständige Entwurfautonomie gegeben Jede lokale Schemaänderung kann einen nicht unerheblichen Aufwand für die Anpassung bedeuten Deshalb: Unterscheidung mehrerer Architekturvarianten Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

35 2. Architekturen für FDBS
2. Architekturen für FDBS Import/Export- Schema- Architektur Multidatenbanken- Architektur 5-Ebenen- Schema- Architektur Diese drei Schema-Architekturen zeigen uns die prinzipiellen Unterschiede und Gemeinsamkeiten von einerseits lose gekoppelten und andererseits eng gekoppelten föderierten Datenbanksystemen. lose gekoppelten eng gekoppelten Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

36 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Import / Export - Schema - Architektur beschreibt die vom System verwalteten Daten lokales konzeptionelles Schema unabhängig von der Teilnahme an der Föderation beinhaltet kleinen Teil, der für Informationen über die Teilnahme an Föderation gedacht ist beschreibt die Daten die das System von anderen übernehmen möchte es werden Teile aus dem Exportschema anderer Systeme übernommen diese Übernahme muss verhandelt werden hier ist der Teil der Daten beschrieben den das Datenbanksystem in einer Föderation anderen zur Verfügung stellt Ausschnitt aus privaten Schema es wird festgelegt welches Komponentensystem welche Form des Zugriffs erhält (Lesen, Schreiben, usw.) - es wird nur eine Zugriffskontrolle für die an der Förderation beteiligten Komponentensysteme realisiert (nicht für einzelne Nutzer) Anwendung Anwendung Importschema Exportschema privates Schema Datenbank Importschema privates Schema Exportschema ... Bildung des Exportschemas ist mit dem Festlegen der Abbildungsfunktion zwischen Exportschema und privaten Schema verbunden Analog beim Bilden des Importschemas müssen die Abbildungen zwischen verwendeten Exportschema anderer DB und gebildeten Importschema bestimmt werden Abbildungen sind im laufenden Betrieb z.B. für die Abfragebearbeitung wichtig Anfragen auf das Importschema müssen auf die entsprechenden Exportschemata abgebildet werden Für Exportschema muss Anfrage auf das entsprechende private Schema abgebildet werden Antwort in entgegengesetzter Richtung In der Philosophie die dieser Architektur zugrundeliegt ist das Verhandeln zwischen Komponentensystemen das zentrale Prinzip. Weil: es gibt keine übergeordnete Instanz die etwa Zugriffsrechte zentral verwaltet Für dieses Verhandeln wird ein geeignetes Verhandlungsprotokoll festgelegt. Datenbank Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

37 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Import / Export - Schema - Architektur ... ist Basis für lose gekoppelte föderierte Datenbanksysteme!!! Der Import von Schemabestandteilen legt für jedes System ein eigenes föderiertes Schema fest. Importschema eigenes föderiertes Schema Es existiert keine übergeordnete Instanz!!! Aufgabenerfüllung wird aufgrund von Verhandlungen verteilt jedes System kann dies, für sich, zu jedem Zeitpunkt ändern dies betrifft sowohl einzelne Zugeständnisse als auch die Teilnahme an der Föderation Fraglich erscheint hier woher das Komponentensystem die Verhandlungskomponente nimmt. Modelle, wo quasi ein Verhandlungsprotokoll standardisiert mit jedem DBS ausgeliefert werden soll erscheinen fraglich, da es keinerlei Standards gibt und bisherige Systeme ja sowieso nicht darüber verfügen. Integrationsprobleme werden mehrfach gelöst Datenbankadministrator hat bei dieser Architektur wesentliches im Hinblick auf die Integration zu leisten Durch Unabhängigkeit zwischen Import- und privaten Schema muss jee Anwendung die beide Schemata benutzt diese auch integrieren Die Autonomie der Komponentensysteme bleibt in hohem Maße gewahrt. Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

38 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Multidatenbank - Architektur Ein Benutzer möchte auf verschiedene Datenbanken zugreifen, ohne das ein globales Schema vorhanden ist. Zentrale Annahme: Zu Problemen: Unterschiede in der Bezeichnungsweise führen zu Synonymen und Homonymen sowie Wertinkonsistenzen Alle Probleme lassen sich wegen der Autonomie der beteiligten Systeme nicht vermeiden!!! geeignete Anfrage- und Datenmanipulationssprache Sprache muss alle auftretenden Probleme im Sinne des Nutzers lösen können Er braucht: in mehren DB redundant gespeicherte Daten strukturelle Unterschiede zwischen den einzelnen DB Unterschiede in der Bezeichnungsweise Probleme: Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

39 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Multidatenbank - Architektur Benutzer 1 Benutzer 4 Benutzer 2 Benutzer 3 Benutzer 5 es kann auch sinnvoll sein direkt auf konzeptionelles Schema zuzugreifen z.B. einmalige Anfrage jeder Benutzer kann sich eigenes externes Schema zusammenstellen Zugriff auf konzeptionelles Schema nötig -realisiert eine spezielle Sicht auf das interne logische Schema wenn nur Ausschnitt gezeigt werden soll externes Schema nach ANSI/SPARC ES 1 Datenbank PS n ILS n KS 2 ES n2 ES n1 externe Ebene ... wenn alle verwalteten Daten gezeigt werden sollen (ILS kann entfallen) konzeptionelles Schema nach ANSI/SPARC Gesamtheit der vom System verwalteten Daten konzeptionelles Schema nach ANSI/SPARC AS 1 AS j ... KS 1 KS 2 konzeptionelle Ebene ILS 2 beschreibt die interne Struktur der verwalteten Daten internes Schema nach ANSI/SPARC ES - externes Schema KS - konzeptionelles Schema AS - Abhängigkeitsschema ILS - internes logisches Schema PS - physisches Schema Die Schemata werden drei Ebenen zugeordnet: Die verschiedenen externen Schemata bilden die externe Ebene Die konzeptionellen Schemata bilden zusammen mit den Abhängigkeitsschemata die konzeptionelle Multidatenbankebene Die physischen und internen logischen Schemata bilden die interne Ebene PS 1 PS 2 Datenbank Datenbank Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

40 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Multidatenbank - Architektur Jeder Benutzer ist für die Erstellung seiner integrierten Sicht auf die von ihm benötigten Daten selbst verantwortlich. Explizite Integration konzeptioneller Schemata Direktzugriff auf die versch. konzeptionellen Schemata 1. 2. typische Architektur für lose gekoppelte föderierte Systeme auf übergeordneter Ebene gibt es eine eingeschränkte Funktionalität (Unterschied zu Import/Export-Schema) wichtig ist eine Multidatenbanksprache für Zugriff Komponentensysteme es gibt im Gegensatz zur Import/Export keine Importschemata die von Datenbankadministratoren erstellt und verwaltet werden müssen Explizite Integration: kann dann auf externes Schema zugreifen ohne sich darum kümmern zu müssen woher die Daten Kommen Direktzugriff: hier muss er allerdings innerhalb der Anwendung die jeweils notwendige Integration durchführen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

41 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS 5 - Ebenen - Schema - Architektur -auf einzelne Benutzer zugeschnittene Schnittstelle -möglicherweise anderes Datenmodell als föderiertes Schema -gleiche Funktion wie externes Schema in zentralen DBS Datenbank lokales Schema Exportschema Komponentenschema externes Schema föderiertes Schema Datenbank lokales Schema Komponentenschema Exportschema externes Schema -beschreibt den Ausschnitt aus dem Komponentenschema der der Föderation zur Verfügung gestellt wird -in ein anderes Datenmodell transformiertes Schema -beseitigt die Datenmodellheterogenität -gleiches Datenmodell wie föderiertes Schema -Gesamtheit der durch die Exportschemata einfließenden Daten -globales Datenmodell -potenzielle Integrationsprobleme -konzeptionelles Schema des Komponentendatenbank-systems -implementierungsabhängige Beschreibung der Gesamtheit von Daten Auffälligster Unterschied zu den vorher genannten Architekturen ist das föderierte Schema. Es existiert also ein globales Schema auf übergeordneter Ebene Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

42 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS 5 - Ebenen - Schema - Architektur Es existiert ein globales Schema in dem alle der Föderation zur Verfügung gestellten Daten beschrieben sind. Die 5-Ebenen-Architektur schränkt die Autonomie der Komponentensystem stärker ein als die anderen Architekturen. Die Architektur ist somit prädestiniert in eng gekoppelten föderierten DBS zum Einsatz zu kommen. globales Schema muss von globalen Datenbankadministrator erstellt und gepflegt werden Somit ist auch die eigentliche Integration seine Aufgabe Weder lokale noch globale Nutzer müssen sich um Integration kümmern Die Architektur unterstützt jedoch auch lose Kopllung Das global verwaltete föderierte Schema erlaubt die Realisierung von Datenbankmanagement-Funktionalität auf globaler Ebene. Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

43 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Überschneidung mit ANSI/SPARC (Variante 1) externes Schema externes Schema föderiertes Schema Exportschema Exportschema Komponentenschema (externes Schema) Komponentenschema (externes Schema) Komponenten DBS lokales Schema (konzeptionelles Schema) lokales Schema (konzeptionelles Schema) Komponentenschemata sind externe Schemata der Komponentensysteme Die Exportschemata liegen außerhalb der Komponentensysteme Dadurch haben die Komponentensysteme keine Kontrolle über das Exportschemata Wiederspruch zum Autonomiegedanken der Komponentensysteme (jedes System bzw. seine Admins sollten Exportschema selbst festlegen können) Hier wird das Komponentenschema welches die gleiche Information enthält wie das lokale Schema der Föderation zur Verfügung gestellt Daraus folgt das das gesamte lokale (konzeptionelle) Schema in die Föderation eingeht Es würde dann erst auf globaler Ebene durch Bildung des Exportschemas bestimmt welcher Ausschnitt in die Föderation eingeht internes Schema internes Schema Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

44 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Überschneidung mit ANSI/SPARC (Variante 2) lokales Schema (konzeptionelles Schema) Exportschema externes Schema föderiertes Schema internes Schema Komponentenschema (externes Schema) Komponenten DBS Hier wird das Exportschemata als externes Schema der Komponentensysteme verstanden Dadurch hat jedoch das Komponentenschema keine Entsprechung in der 3-Ebenen-Architektur der Komponentensysteme, da zwischen konzeptionellen und externen Schema nach ANSI/SPARC nichts ist Daraus folgt, das die Komponentenschemata auch nicht in die lokale Organisation der Komponentensystem hineinpassen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

45 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Exportschema Komponentenschema (externes Schema) Warum unterscheidet man Exportschema und Komponentenschema? Zwischen „benachbarten“ Schemata ist immer nur genau eine der folgenden Transformationsoperationen notwendig: Motivation Transformation Filteroperation Integrations- operation Transformation eines ganzen Schemas von einem Datenmodell in ein anderes Datenmodell (zwischen lokalen und Komponentenschema) eine Filteroperation, welche aus einem Schema einen Ausschnitt selektiert (bei Transformation vom Komponentenschema zum Exportschema) eine Integrationsoperation, welche mehrere Schemata in ein integriertes Schema überführt (zwischen Exportschema und föderiertem Schema) Die Unterschiede zwischen Exportschema und Komponentenschema sind also rein technischer Natur Für die Komponentensysteme ist sie daher nicht relevant Man kann beide Schritte zu einem zusammenfassen Damit entspricht der Übergang vom konzeptionellen Schema zu einem externen Schema gemäß ANSI/SPARC in einem Komponentensystem dem Übergang zwischen lokalem Schema und Exportschema in der 5-Ebenen-Architektur Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

46 3. Vergleich der Architekturen
3. Vergleich der Architekturen Tabellarischer Vergleich Import/Export - Architektur Multidatenbank - 5-Ebenen-Schema unterstütze Kopplungsform lose Kopplung lose und enge Kopplung verantwortlich für Integration Benutzer und lokaler Admin. Benutzer globaler Administrator Zugriff auf die Föderation vom lokalen System über globale Schnittstelle über das globale System Unterstützung globaler DBMS keine Teilweise (MultiDB-Sprache) volle DBMS-Funktionalität unterstütze Kopplungsform unterstütze Kopplungsform lose Kopplung lose Kopplung lose und enge Kopplung verantwortlich für Integration verantwortlich für Integration Benutzer und lokaler Admin. Benutzer globaler Administrator Zugriff auf die Föderation Zugriff auf die Föderation von lokalem System über globale Schnittstelle über das globale System Unterstützung globaler DBMS keine Teilweise (MultiDB-Sprache) volle DBMS Funktionalität Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

47 3. Vergleich der Architekturen
3. Vergleich der Architekturen Misch-Architektur für globalen Zugriff lokaler Anwendungen es soll gezeigt werden, das die drei vorgestellten Referenz-architekturen nicht so grundverschieden sind Mischform mit Aspekten aller drei Architekturen Alle Anwendungen laufen lokal, auf einem der Komponentensysteme ab. Grundgedanke es wird dazu eine spezielle lokale Zwischenschicht bereitgestellt diese Schicht muss feststellen welche Anfrageteile lokal behandelt werden können und welche an andere Systeme weitergeleitet werden müssen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

48 Globales konzeptionelles Schema
Komponente Mapping Mapping ImpS ExpS virtuelles konzeptionelles Schema lokales internes Datenbank Mapping ImpS ExpS virtuelles konzeptionelles Schema lokales internes Datenbank ImpS ExpS virtuelles konzeptionelles Schema konzeptionelles Schema der lokalen konzeptionellen Komponente Vermittler für die lokal laufenden Anwendungen die Zugriff auf die Datenbestände anderer DB benötigen dazu wird spezielles integriertes Schema angeboten das das jeweilige lokale konzept. Schema vollständig, und zusätzlich Teile aus Schemata anderer KS beinhaltet werden einerseits zur Zuordnung der Bestandteile von Exportschemata zu Bestandteilen des globalen konzeptionellen Schemas verwendet andererseits zur Abbildung des globalen konzeptionellen Schemas auf die Importschemata diese Funktionen müssen diverse Integrationsprobleme lösen es wird festgelegt welche Bestandteile des globalen konzeptionellen Schemas von der lokalen konzeptionellen Komponente verwendet werden ergibt sich durch die Integration der Exportschemata der lokalen konzeptionellen Komponenten beschreibt alle Daten die die KS über ihre Exportschemata den anderen KS zur Verfügung gestellt haben es wird festgelegt, welche Teile des lokalen konzeptionellen Schemas anderen KS zur Verfügung gestellt werden diese Teile werden in das globale konzeptionelle Schema aufgenommen Lokale konzept. Komponente beschreibt die Gesamtheit der in dem jeweiligen Komponentensystem verwalteten Daten im jeweiligen Datenmodell lokales konzeptionelles Schema internes Datenbank interne Schemata der jeweiligen Komponentensysteme beschreiben die konkrete Implementierung der lokalen konzeptionellen Schemata Lokale DBMS Vergleich

49 3. Vergleich der Architekturen
3. Vergleich der Architekturen Zusammenfassung Föderierte Datenbanksysteme sind eine bestimmte Art von Multidatenbanksystemen! FDBS zeichnen sich durch weiterbestehende Autonomie der Komponentensysteme aus Autonomie, Heterogenität und Verteilung sind Merkmale von FDBS Import / Export 5-Ebenen Multidaten- banken Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

50 Integrationskonflikte
Gliederung 3. Wege zu integrierten Datenbanksystemen 1. Einleitung 4. Erhaltung von integrierten Datenbanksystemen 5. Zusammenfassung - Fazit - Ausblick 2. Konzeptionelle Architekturen Problemstellung Integrationskonflikte Lösungsansätze Einsatz föderativer Datenbanksysteme © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

51 Gliederung Föderative DBS Wege zu integrierten Datenbanksystemen
Gliederung Wege zu integrierten Datenbanksystemen Allgemeine Problemstellung Integrationsstrategien Integrationsprozess Kriterien für Integrationsmethoden Klassifizierung von Integrationskonflikten Einführung Schemakonflikte - Datenkonflikte Lösungsansatz Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

52 1. Allg. Problemstellung Ausgangssituation Föderative DBS
1. Allg. Problemstellung Es liegen mehrere unabhängig voneinander entworfene, heterogene Datenbankschemata der Komponentensysteme vor. Ausgangssituation Problem: Daten sind in KS redundant oder in Beziehungen miteinander LS1 LS2 LS3 globales Schema Es gilt die strukturelle und semantischen Inkompabilitäten zu beheben. Zur Integration von mehr als zwei lokalen Schemata sind verschiedene Integrationsstrategien möglich, welche im folgenden vorgestellt werden. Ziel: Redundanzen vermeiden und Daten korrekt in Beziehung zueinander setzen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

53 1. Integrationsstrategien
1. Integrationsstrategien One-Shot-Integrationsstrategie S S S S S S Sn integriertes Schema IS Integration der Schemata in nur einem Schritt. zu integrierende lokale Schemata Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

54 1. Integrationsstrategien
1. Integrationsstrategien Balancierte binäre Integrationsstrategie integriertes Schema IS teilintegrierte Schemata als Zwischen- ergebnisse Es werden in jedem Schritt genau zwei Schemata integriert Die Reihenfolge spielt bei dieser Strategie eine sehr große Rolle Balancierte binäre Strategie = ein lokales Schema wird immer nur mit einem anderen lokalen Schema integriert Integrationsbaum wird bottom-up aufgebaut Zwei Schemata dürfen immer nur dann integriert werden wenn sie auf der gleichen Ebene im Baum stehen zu integrierende lokale Schemata Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

55 1. Integrationsstrategien
1. Integrationsstrategien Gewichtete binäre Integrationsstrategie integriertes Schema IS Es werden einzelne Schemata bevorzugt Die Folge ist, das man aufgrund einer solchen Bevorzugung, bevorzugte lokale Schemata direkt und nur mit wenigen Veränderungen wiederfindet Bei jedem Integrationsschritt werden Konflikte zwischen den zu integrierenden Schemata aufgelöst Daraus folgt das ein lokales Schema welches viele Integrationsschritte durchläuft mehr verändert wird als eines welches nur einen durchläuft zu integrierende lokale Schemata Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

56 1. Integrationsstrategien
1. Integrationsstrategien n-äre Integrationsstrategien (A - one shot, B - iterativ) integriertes Schema IS B A N-äre Strategie zeichnet sich dadurch aus, das man in jedem Schritt eine beliebige Anzahl von Schemata integrieren kann One-Shot ist Spezialfall Bei iterativen Vorgehen werden immer mehrere lokale oder teilintegrierte Schemata in einem Schritt integriert Somit kann eine beliebige Baumstruktur entstehen zu integrierende lokale Schemata Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

57 Vorintegrationsphase
2. Integrationsprozess 1. Unterscheidungsmöglichkeit Vorintegrationsphase Integrationsphase Bestimmung von Gemeinsamkeiten und Unterschieden Gefundene Übereinstimmungen werden als sogenannte Inter-Schema-Korrespondenzen festgehalten Wird halbautomatisch durch Inter-Schema-Korrespondenz sowie einige Integrationsregeln durchgeführt Interaktion mit Datenbank-administrator immer noch notwendig Bisher war der Übergang von mehreren zu integrierenden Schemata hin zu einem integrierten Schema immer ein abstrakter Schritt. Vorintegrationsphase muss der Datenbankadmin per Hand erledigen Er hat maximal Werkzeugunterstützung Diese greift jedoch bei Synonymen und Homonymen auch nicht Dieser Prozess lässt sich jedoch in mehrere Phasen unterteilen Sie sind unabhängig von den zuvor erwähnten Integrationsstrategien Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

58 2. Integrationsprozess Föderative DBS 2. Unterscheidungsmöglichkeit
2. Integrationsprozess 2. Unterscheidungsmöglichkeit 1. Vorintegration 2. Vergleich der Schemata Auswahl der Integrationsstrategie gegebenenfalls Vergabe Präferenzen Entdecken der Korrespondenzen Finden von möglichen Konflikten 3. Anpassung der Schemata 4. Zusammenführung und Restrukturierung Präferenzen für einige Schemata sind aus unternehmensstrategischen Gesichtspunkten von Bedeutung Zum Beispiel Präferenz der Finanzanwendung gegenüber der Personalverwaltung Dadurch erreicht man das präferiertes Schema so weit wie möglich in das integrierte Schema strukturell eingebettet wird lokale Schemata werden so modifiziert das sie anschließend zusammengeführt werden können für jeden entdeckten Konflikt wird eine Anpassung vorgenommen kann wegen Autonomie nicht auf den lokalen Schemata erfolgen Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

59 3. Kriterien für Integrationsmethoden
3. Kriterien für Integrationsmethoden Vollständigkeit das Ergebnis des Integrationsprozess muss alle Konzepte enthalten, die in irgendeinem lokalen Schema enthalten sind es darf keine im Schema enthaltene Information verloren gehen alle im integrierten Schema enthaltenen Informationen müssen in mindestens einem lokalen Schema semantisch äquivalent enthalten sein Inter-Schema-Beziehungen dürfen die bestehenden Schemata nur konsistent ergänzen Korrektheit Inter-Schema-Beziehungen entstehen während der Integration Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

60 3. Kriterien für Integrationsmethoden
3. Kriterien für Integrationsmethoden Minimalität ist ein real-world-Konzept in mehreren lokalen Schemata modelliert so darf es im integrierten Schema nur einmal repräsentiert sein das integrierte Schema sollte leicht verständlich sein soll Benutzern und Datenbankadministrator die Arbeit erleichtern Verständlichkeit Inter-Schema-Beziehungen entstehen während der Integration Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

61 2. Klassifizierung von Integrationskonflikten
Probleme die in der Vorintegrationsphase beim Vergleich der zu integrierenden Schemata entdeckt werden Aufgrund der Vielzahl von Konflikten ist eine Kategorisierung nötig Vier Klassen von Konflikten Semantische Konflikte Beschreibungskonflikte Heterogenitätskonflikte Strukturelle Konflikte Föderative DBS 1. 2. 3. 4. 5.

62 2. Schemakonflikte - Datenkonflikte
Tabellen – Tabellen - Konflikte Attribut – Attribut -Konflikte Tabellen - Attribut - Konflikte falsche Daten Unterschiedliche Repräsentationen Föderative DBS 1. 2. 3. 4. 5.

63 Schemakonflikte -- Tabellen – Tabellen - Konflikte
verschiede Namen für gleiche Tabellen Tabellennamenkonflikte gleiche Namen für verschiedene Tabellen fehlende Attribute eine Tabelle vs. eine Tabelle Tabellenstrukturkonflikte fehlende, aber implizite Attribute Integritätsbedingungskonflikte viele Tabellen vs. viele Tabellen

64 Schemakonflikte -- Attribut - Attribut - Konflikte
verschiede Namen für gleiche Attribute Attributsnamen- konflikte gleiche Namen für verschiedene Attribute ein Attribut vs. ein Attribut Default – Wert - Konflikte Integritätsbedingungs konflikte Datentypkonflikte Bedingungskonflikte viele Attribute vs. viele Attribute

65 Datenkonflikte nicht korrekte Einträge falsche Daten veraltete Daten
verschiedene Ausdrücke Unterschiedliche Repräsentation verschiedene Einheiten unterschiedliche Genauigkeit

66 3. Lösungsansatz Föderative DBS Zusicherungsbasierte Integration
Welche Bestandteile der zu integrierenden Schemata einander entsprechen oder in irgendeiner für die Integration relevanten Beziehung stehen. unabhängig von einem konkreten Datenbankmodell automatische Auflösung von strukturellen Konflikten ein Ansatz ist die Schemaintegration Föderative DBS 1. 2. 3. 4. 5.

67 3. Lösungsansatz Föderative DBS Schemaintegration Integrate-join
Integration mit Hilfe sogenannter Integrationsregeln immer nur zwei integrierende Schemata bei strukturellen Konflikten wird immer die weniger eingeschränkte Struktur verwendet wichtigste Operation integrate-join Integrate-join 2 Schemata S1, S2, 2 Elemente mit Wertattributen E1, E2 E:= integrate-join(E1, E2, attcor2(A12, A22), ..., attcorj (A1j,A2j)) A1j = A2j A1j  A2j A1j  A2j A1j ≠ A2j Integrationsregeln Schemaelemente zu denen kein Gegenstück existiert äquivalente Objekttypen mit zugehörigen Werteattributen Elementare Links zwischen äquivalenten Schemaelementen Integration von Pfaden die sich aus mehreren Links zusammensetzen Wie ein Objekttyp und ein Wertattribut bzw. ein komplexes Attribut integriert werden Föderative DBS 1. 2. 3. 4. 5.

68 3. Lösungsansatz Föderative DBS Kunden KAdr KName Abnehmer Adresse
bestellt n:m BestMenge versorgt n:m Ware Menge Preis Waren WPreis WarenBez Produzent PAdr PName 1:n produziert 1:n betreut Hersteller HName HAdr Branche Verband VBranche Föderative DBS 1. 2. 3. 4. 5.

69 Gliederung 1. Einleitung 2. Konzeptionelle Architekturen
Gliederung 4. Erhaltung von integrierten Datenbanksystemen 1. Einleitung 5. Zusammenfassung - Fazit - Ausblick 2. Konzeptionelle Architekturen 3. Wege zu integrierten Datenbanksystemen Erhaltung struktureller Konsistenz Erhaltung operationaler Konsistenz Einsatz föderativer Datenbanksysteme © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

70 Gliederung Erhaltung von integrierten Datenbanksystemen Föderative DBS
Gliederung Erhaltung von integrierten Datenbanksystemen Erhaltung struktureller Konsistenz Einfügen oder Löschen von Objekten Updates Erhaltung operationaler Konsistenz Klassischer Transaktionsbegriff Allgemeine Prinzipien erweiterter Transaktionsmodelle Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

71 1. Erhaltung struktureller Konsistenz
1. Erhaltung struktureller Konsistenz Semantisch äquivalente Extension Objektmenge zu lokaler Objektklasse OK1 Objektmenge zu lokaler Objektklasse OK2 Objektmenge zu globaler Objektklasse OKG Semantisch überlappende Extension Objektmenge zu lokaler Objektklasse OK1 Objektmenge zu lokaler Objektklasse OK2 Objektmenge zu globaler Objektklasse OKG Disjunkte, aber zusammengehörige Objektmengen Objektmenge zu globaler Objektklasse OKG Objektmenge zu lokaler Objektklasse OK2 Objektmenge zu lokaler Objektklasse OK1 Semantisch äquivalente lokale Lokales Objekt O1 Globales Objekt OG Lokales Objekt O2 A B C D E Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

72 2. Erhaltung operationaler Konsistenz
Transaktion Zusammenfassung von aufeinanderfolgenden DB Operationen, die eine DB von einem konsistenten Zustand wieder in einen konsistenten Zustand überführt. Ablauf DB BOT konsistente DB EOT DML - Operationen möglicherweise inkonsistente Datenbank A C I D Atomicity eine TA läuft vollständig oder überhaupt nicht Consistency TA läuft unter Konsistenzbedingungen ab Isolation alle TA laufen voneinander isoliert ab Durability alle Ergebnisse einer erfolgreichen TA sind persistent zu machen Föderative DBS 1. 2. 3. 4. 5.

73 2. Klassische Transaktionsbegriff
Transaktionsverwaltung Konsistenz und Isolation  Serialisierbarkeit Atomarität und Dauerhaftigkeit  Recovery Mechanismen read/ write – Modell lesen ri(x) schreiben wi(x), commit ci, abort ai Transaktionsverwaltung bildet einen Abarbeitungsplan (Schedule) Serialisierbarkeit/ Recovery Mechanismen beim parallelen Ablauf mehrer TA muss die DB konsistent bleiben und die TA müssen einen konsistenten Zustand sehen äquivalent zu einem seriellen Ablaufplan wenn Ti beendet wird muss Tj schon beendet sein Problem sind kaskadierende Abbrüche Realisierung durch Sperr Protokolle oder Zeitstempelverfahren Heterogene Transaktionsverwaltung lokale Transaktionsverwaltung unterschiedlich globale Transaktionsverwaltung kennt die jeweiligen lokalen Transaktionsverwaltungen globale Transaktionsverwaltung weiß nichts über die jeweiligen lokalen Transaktionsverwaltungen Föderative DBS 1. 2. 3. 4. 5.

74 2. Erweiterter Transaktionsmodelle
Geschachtelte Transaktion Transaktion ruft selbst wieder eine Transaktion auf ist ein Baum von Transaktionen Wurzel heißt top-level-Transaktion, Knoten oder Blätter sind Subtransaktionen Commit-Regeln, Rollback-Regeln, Sichtbarkeitsregeln Darstellung geschachtelter Transaktionen BEGIN WORK . invoke subtransaction COMMIT WORK Top-level Transaktion Subtransaktion (Stufe 2) Subtransaktion (Stufe 1) Regeln Commit-Regel Rollback-Regeln Sichtbarkeitsregeln Föderative DBS 1. 2. 3. 4. 5.

75 Gliederung 1. Einleitung 2. Konzeptionelle Architekturen
Gliederung 5. Fazit 1. Einleitung 2. Konzeptionelle Architekturen 3. Wege zu integrierten Datenbanksystemen 4. Erhaltung von integrierten Datenbanksystemen Vorteile Nachteile Offene Fragen Einsatz föderativer Datenbanksysteme © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

76 Fazit Föderative DBS Performanz Überwindung der
Fazit Überwindung der Heterogenität in DB Multi-DB-Zugriff DB-Autonomie erhalten Migration am operativen System möglich Performanz Unterschiedliche Anfragesprachen in heterogenen Systemen rein wissenschaftlicher Ansatz Datenaktualität: lokale Redundanzen Inkonsistenzen „Integration on the Fly“ Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

77 ? ? ? ? Fazit Föderative DBS Offene Fragen: Schemaintegration von z.B:
Fazit Offene Fragen: Schemaintegration von z.B: Methoden aus objektorientierten DB Prozeduren aus relationalen DB Berücksichtigung von lokalen und globalen Integritätsbedingungen Überwachung und Sicherstellung der Datenkonsistenz mit tragbaren Effizienzeinbußen ? ? ? ? Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

78 Vielen Dank für Ihre Aufmerksamkeit
Ende der Präsentation Vielen Dank für Ihre Aufmerksamkeit Fazit Offene Fragen: Schemaintegration von z.B: Methoden aus objektorientierten DB Prozeduren aus relationalen DB Berücksichtigung von lokalen Integritätsbedingungen Überwachung und Sicherstellung der Datenkonsistenz mit tragbaren Effizienzeinbußen ? ? ? Wir wünschen der Seminargruppe ein frohes Fest und einen guten Rutsch ins neue Jahr !!! ? Föderative DBS 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

79 Globales konzeptionelles Schema
Globales konzeptionelles Schema Mapping lokales konzeptionelles Schema internes Datenbank ImpS ExpS virtuelles Lokale DBMS Globale konzept. Komponente Vergleicht man diese Mischstruktur mit den drei Referenzarchitekturen so erkennt man das in ihr die Grundprinzipien aller drei Architektur-Modell vereinigt sind. Import / Export Multidaten- banken 5-Ebenen Misch- form © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

80 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Import / Export - Schema - Architektur Anwendung Importschema Exportschema privates Schema Datenbank ... findet sich in der Mischform in der Schicht der lokalen konzeptionellen Komponenten wieder Privates Schema des KS ist hier das lokale konzeptionelle Schema Aus Importschema und lokalem konzeptionellen Schema wird jedoch ein virtuelles konzeptionelles Schema gebildet Damit liegt integriertes Schema vor, welches so nicht in Import/Export gibt Importschemata werden auch nicht direkt aus Exportschemata gebildet sondern es gibt den Umweg des globalen konzeptionellen Schemas Da dieses globale Schema alle Exportschemata umfasst kann ein Importschema relativ leicht als Ausschnitt aus globalen Schema bestimmt werden Alle Integrationsprobleme werden auf die globale Ebene verschoben Innerhalb der lokalen konzeptionellen Komponentenhaben wir damit im wesentlichen ein Import/Export-Schema Import / Export Föderative DBS Multidaten- banken 5-Ebenen Misch- form 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

81 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS Multidatenbank - Architektur Datenbank PS 1 KS 2 ILS 2 PS 2 ES 1 KS 1 ... externe Ebene konzeptionelle Ebene Benutzer 1 Benutzer 4 Benutzer 2 Benutzer 3 Benutzer 5 PS n ILS n ES n2 ES n1 AS 1 AS j ES - externes Schema KS - konzeptionelles Schema AS - Abhängigkeitsschema ILS - internes logisches Schema PS - physisches Schema die lokalen internen Schemata entsprechen dem physischen Schema der MDBA Das lokale konzeptionelle Schema stimmt mit dem internen logischen Schema überein Das virtuelle konzeptionelle Schema ist ungefähr mit dem konzeptionellen Schema in MDBA zu vergleichen Da das virtuelle konzeptionelle Schema zusätzlich auch Schemabestandteile anderer KS umfasst kann es auch als externes Schema der MDBA verstanden werden Import / Export Föderative DBS Multidaten- banken 5-Ebenen Misch- form 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg

82 2. Architekturen von FDBS
Import / Export 5-Ebenen Multidaten- banken 2. Architekturen von FDBS 5 - Ebenen - Schema - Architektur Datenbank lokales Schema Exportschema Komponentenschema externes Schema föderiertes Schema die lokalen Schemata der 5-Ebenen entsprechen hier vollständig dem lokalen konzeptionellen Schema Komponentenschemata sind jedoch nicht so eindeutig zu identifizieren Exportschema aus 5-Ebenen findet seine Entsprechung in den Exportschemata der lokalen virtuellen Komponenten Das föderierte Schema heißt hier globales konzeptionelles Schema Import / Export Föderative DBS Multidaten- banken 5-Ebenen Misch- form 1. 2. 3. 4. 5. © 2001 Falk Ritschel, Sefan Springer, Falko Steponat, MLU Halle-Wittenberg