Einsatz föderativer Datenbanksysteme Gliederung
Werbung
Aufbau Integrierter Informationssysteme 1. Was ist Föderation Föderation: Bündnis von Staaten oder Teilstaaten EU-Staaten mit unterschiedlicher Struktur (Heterogen) Einsatz föderativer Datenbanksysteme Falk Ritschel, Stefan Springer, Falko Steponat BLJedes mit ähnlicher BL ist quasi Struktur eigener (Homogen) Staat Martin-Luther-Universität Halle-Wittenberg Teilautonomie unter übergeordneter Instanz Informatikseminar - Halle - 19.12.2001 1. 2. 3. 4. 5. Gliederung Föderative DBS 5 2. Eine Grobe Skizze 1. Einleitung Aufgaben der Zusatzschicht: 2. Konzeptionelle Architektur – globale Anfragen und Transaktionen bearbeiten 3. Wege zu integrierten Datenbanksystemen – Zerlegung in Teilanfragen (bei Leseoperationen) 4. Erhaltung von integrierten Datenbanksystemen – Zusammenfassen der Teilergebnisse 5. Zusammenfassung - Fazit - Ausblick – Transaktionsverwaltung Einsatz föderativer Datenbanksysteme 2 1. 2. 3. 4. 5. Gliederung Föderative DBS 6 2. Eine Grobe Skizze 1. Einleitung Was ist Föderation? Definitorische Abgrenzung Warum FDBS? 2. Konzeptionelle Architektur 3. Wege zu integrierten Datenbanksystemen 4. Erhaltung von integrierten Datenbanksystemen 5. Zusammenfassung - Fazit - Ausblick Einsatz föderativer Datenbanksysteme 3 1. 2. 3. 4. 5. Gliederung Föderative DBS 7 2. Eine Grobe Skizze 1. Einleitung 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. 1. Was ist Föderation? 2. Eine Grobe Skizze 3. Warum FDBS? 1. Anwendungsszenarien •Nebenanforderungen möglichst erfüllen: –Verteilungstransparenz –Verbergen der Heterogenität –DB-Operationen auf mehreren Datenbanken –Transaktionskonzept 4. Definitorische Abgrenzung 1. Zentrale DBS 2. Verteilte DBS 3. Multidatenbanksysteme 1. 2. 3. 4. 5. Föderative DBS 4 1. 2. 3. 4. 5. Föderative DBS 8 3. Warum FDBS 3. Warum FDBS Frage: Wozu FDBS? • Beispiel 2: Migration: Defizite bei programmierter Verteilung und Fernzugriff auf Datenbanken: Ablösung von Legacy-Systemen innerhalb einer Operation kann nicht auf mehrere Datenbanken zugegriffen werden keine Unterstützung bei der Behandlung semantischer Heterogenität Bestehende Daten und Anwendungen sollen übernommen werden Neuentwicklung der Anwendungen nicht wirtschaftlich geringer Grad an Verteilungstransparenz 1. 2. 3. 4. 5. Föderative DBS 9 1. 2. 3. Einfache Portierung der Anwendungen oft nicht möglich 4. 5. 3. Warum FDBS Föderative DBS 13 3. Warum FDBS • Beispiel 1: Risiko, dass in Übergangszeit neues System nicht stabil läuft – Heterogene Hard- & Softwarelandschaft im Unternehmen Æ Insellösungen Allmähliche Ablösung des Altsystems Redundanzen Beide Systeme laufen parallel Inkonsistenzen 1. 2. 3. 4. 5. Föderative DBS 10 1. 2. 3. 4. 5. 3. Warum FDBS Föderative DBS 14 3. Warum FDBS INKONSISTENZEN Datenhaltung wird redundant Beide Systeme laufen parallel 1. 2. 3. 4. 5. Föderative DBS 11 1. 2. 3. 4. 5. 3. Warum FDBS Anforderungen: -Autonomie der lokalen DB -Redundanzkontrolle -Globale Integritätsüberwachung -Transaktionsverwaltung -Transparenz 1. 2. 3. Föderative DBS 15 3. Warum FDBS AnwendungsAnwendungs Probleme: migration Effizienzeinbußen durch globale Schnittstelle von Neusystem aus •Rücktransformation durch interne Transformationen von globaler zur Legacy-Schnittstelle Föderation Zentraler Vorteil: (Anwendung wird noch auf Altsystem ausgeführt) • wenn Neusystem nach Migration allein arbeiten Geschäftsbetriebsoll,muss nicht eingestellt werden d.h. nicht in Föderation Daten • globaleDatenAnwendungen des Altsystems müssen zu lokalenmigration des Neusystems werden • Æoft Anwendungsportierung notwendig Altsystem (aufwendig) Neusystem 4. 5. Föderative DBS 12 1. 2. 3. 4. 5. Föderative DBS 16 4. Definitorische Abgrenzung Z-DBS V-DBS 4. Definitorische Abgrenzung MDBS 4-EbenenSchemaArchitektur Verteilte Datenbanksysteme Zum Verständnis der FDB-Architektur ist das Verstehen von Basisarchitekturen essentiell: Zentrale DBS 1. 2. Z-DBS Verteilte DBS 3. V-DBS 4. 5. Verteilungstransparenz ist sicherzustellen Multidatenbanksysteme Föderative DBS 17 4. Definitorische Abgrenzung MDBS enthält Implementierung für konkretes DBS (Speicherungsstrukturen: Listen, Bäume,Indexe) •Für jeden Benutzer eigenes Schema •Enthält Beschreibung der Daten die dieser benötigt Verteilte Daten sollen von einen DBS verwaltet werden •Beschreibt Daten in externe Sicht: • • Gesamtheit 3-Ebenenihrer Benutzer / Architektur Programme •abstrakt nach und systemunabhängig ANSI/SPARC 1. 2. Z-DBS V-DBS Z-DBS 3. V-DBS 4. 5. •Vereinigt alle (American • konzeptionelle Benutzersichten Sicht: ganzes National Unternehmen Standards Föderative DBS 18 4. Definitorische Abgrenzung MDBS 5. Föderative DBS ängigkeit zu 3-Ebenen-Schemadarstellung nötig um Datenunabhä Datenunabhängigkeit Datenunabh gewährleisten 4. Definitorische Abgrenzung MDBS 4-EbenenIntegration von: Schemaallen Architektur externen Schemata Darauf Aufsetzung der externen Schemata 1. 2. Z-DBS V-DBS 3. 4. 5. Föderative DBS Multidatenbanksysteme: Verbund von mehreren DBS •Aufteilung von komplexen DBS in Teildatenbestände: - effizienter Gründe: ÆWeitgehend andersrum ebenso - flexibler ÆFür bspw. effizienteren DB-Zugriff möglich internes Schema entsprechend zu ändern ohne Schnittstellen der Anwendungen zu berühren Z-DBS 2. 3. V-DBS 4. 5. Föderative DBS (mehrere DBMS) •Zu bestehenden DBen soll neue hinzugefügt werden Æ Ersparnis der Migration 19 4. Definitorische Abgrenzung MDBS 22 4. Definitorische Abgrenzung MDBS ÆKann externe Schemata ändern ohne interne verändern zu müssen 1. 21 Für jeden DBS Rechner eigenes internes •Analog zentralen Abhängig von Verteilungsstrategie UND eigenes konzeptionelles Schema aller lokaler Datenbeschreibung für einzelnen können Redundanzen auftreten konzeptioneller Benutzer Schemata Für Verteilungstransparenz (durch Verteilungstransparenz) Zusammenfassung lokaler Analog zentralen DBS konzeptioneller Schemata zu globalen konzeptionellen Schema Institute) 2. 4. 4-Ebenen-Schema-Architektur basiert auf Daten ANSI/SPARC Modell Beschreibung der des einzelnen Rechners • interne Sicht: System, Maschine 1. 3. 1. Z-DBS 2. V-DBS 3. 4. 5. Föderative DBS 23 4. Definitorische Abgrenzung MDBS 4-EbenenSchemaArchitektur Verteilte Datenbanksysteme Mit Rechnernetzen entstand Bedarf von verschiedenen Rechnern auf einen Datenbestand zuzugreifen Komponentensysteme vollständig auf übergeordneter Ebene verwaltet Vorteile: Rechenleistung mehrerer Rechner Komponentensysteme autonom Zugriffsengpässe zentraler DBS werden vermieden 1. 2. 3. 4. 5. Föderative DBS 20 1. 2. 3. 4. 5. Föderative DBS 24 Z-DBS V-DBS 4. Definitorische Abgrenzung MDBS 1. Verteilung, Heterogenität, Autonomie Verteilung verteilte homogene DBS verteilte föderierte DBS verteilte heterogene föderierte DBS verteilte heterogene DBS Benutzer Durchstellt Nebeneinander Es existiert nur Administrator Föderation ein mehrere einziges verwaltet selbst föderiertes föderierte (Kompromisse zusammen & Schemata Schema verwaltet notwendig) diese homogene föderierte DBS logisch integrierte und homogene DBS Autonomie heterogene integrierte DBS heterogene föderierte DBS Heterogenität 1. 2. Z-DBS V-DBS 3. 4. Föderative DBS 5. 25 1. 2. 3. 4. Föderative DBS 5. 4. Definitorische Abgrenzung MDBS 29 1. Verteilung Daten Schema • Daten können zentral, verteilt oder partitioniert Operationen gespeichert werden • Partitionierung soll Redundanz verhindern • man kann für Operationen das • Replikation möglich aber, muss vom die System Schema = auch Metadaten Datenbanksystem automatisch kontrolliertbereitstellt werden Verteilungsformen unterscheiden • Verteilung kann beabsichtigt • verhalten sich analog zu eingeführt den Daten werden tritt aber oft auch unkontrolliert auf • z.B.: wird die Operation auf jedem Rechner oder nur auf einem oder wenigen ausgeführt 1. 2. 3. 4. 5. Föderative DBS 26 1. 2. 3. 4. Föderative DBS 5. Gliederung 1. Einleitung 1. Heterogenität Heterogene Datenbanksysteme 5-EbenenSchemaArchitektur MultidatenbankenArchitektur 3. Wege zu integrierten Datenbanksystemen 4. Erhaltung von integrierten Datenbanksystemen 5. Zusammenfassung - Fazit - Ausblick Einsatz föderativer 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 unterschiedl. Datenmodelle aufweisen sind Punkt Maßezentraler der Modellierungskonstrukte bedingen bei selben verschiedene Datenmodell möglicherweise Integritätsbedingungen Heterogenitäten werden unterstützt verschiedene Anfragesprachen zu jedem Datenmodell Unterschiede in der Transaktionsverwaltung bei gleichem Datenmodell 2. Konzeptionelle Architektur Import/ExportSchemaArchitektur 27 1. 2. 3. 4. Attribut das den Preis angibt unterschiedliche Genauigkeit kann ohne zusätzliche numerischer Werte Information nicht eindeutig (besonders bei Überprüfung bestimmt werden (Währung?, auf Gleichheit) Mehrwertsteuer?) 5. Gliederung Kommunikationsautonomie • einzelne DB sind unabhängig voneinander Ausführungsautonomie entworfen worden • die einzelnen Systeme entscheiden selbst mit • beim Eintritt in die Föderation sollen die welchem anderen System sie kommunizieren • die DBS sind in der bleiben Lage selbst zu entscheiden lokalen Schemata erhalten • DBS entscheidet selbst ob und wann es in dieund welche Anwendungsprogramme, Anfragen • theoretisch müssten dann die KomponentenFöderation eintritt und wann sie diese wieder Änderungsoperationen ausführt und zu systeme jeder Zeit in der Lagees sein ihr lokales verlässt welchem Zeitpunkt Schema zu ändern • es kann über die Kommunikation mit sollteauch ein innerhalb eines geschlossenen • es ist•fraglich obSystem dieser Grad der Entwurfsanderen Komponentensystemen frei entschieden Verbandes von DBS von werden anderen Systemen direkt autonomie in FDBS unterstützt kann werden oder durch ein übergeordnetes System gezwungen werden bestimmte Aufgaben auszuführen so hat es seine Ausführungsautonomie verloren 2. Architekturen 1. Import / Export-Schema-Architektur 2. Multidatenbanken-Architektur 3. 5-Ebenen-Architektur 3. Vergleich der Architekturen 3. 4. 5. 31 Entwurfsautonomie 1. Verteilung, Heterogenität, Autonomie 2. Föderative DBS 1. Autonomie 2. Konzeptionelle Architektur 1. 30 Föderative DBS 28 1. 2. 3. 4. 5. Föderative DBS 32 1. Autonomie Einzelsysteme = Komponentensysteme Import / Export Multidatenbanken 5-Ebenen 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 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 Die Autonomie der Komponentensysteme bleibt in hohem Maße gewahrt. Datenbestände Bestehende Anwendungsprogramme werden für systemübergreifende können unverändert Anwendungen auf KS verfügbar laufen 1. 2. 3. 4. 5. Föderative DBS 33 1. Autonomie Es wird eine gewisse Autonomie der Komponentensystem gewährleistet. 1. Import / Export 2. 3. Multidatenbanken 5-Ebenen • eng und lose gekoppelte föderierte Systeme benötigen abweichende Funktionalität des Föderierungsdienstes Vielzahl spezifischer Investitionsschutz Anwendungsprogr. Deshalb: Unterscheidung mehrerer Architekturvarianten 2. 3. 4. 5. Föderative DBS 5. Föderative DBS 37 2. Architekturen von FDBS Multidatenbank - Architektur Ein Benutzer möchte auf verschiedene Datenbanken zugreifen, ohne das ein Zentrale Annahme: globales Schema vorhanden ist. • FDBS Abhilfe durch Föderierungsdienst die Risiken derschaffen Portierung Historischder entstandene Kommunikation mit den isolierten Systemen gewährleistet von Daten und Anw. Insellösungen • FDBS bieten durch diesen Dienst globale Datenbankfunktionalität für den Nutzer Wichtig weil ... 1. 4. 34 2. Architekturen für FDBS Er braucht: Probleme: 1. Import / Export • geeignete Anfrage- und Datenmanipulationssprache • in mehren DB redundant gespeicherte Daten • Sprache muss alle auftretenden Probleme im Sinne des • strukturelle Unterschiede zwischen den einzelnen DB Nutzers lösen können • Unterschiede in der Bezeichnungsweise 2. 3. Multidatenbanken 5-Ebenen 4. 5. Föderative DBS 38 2. Architekturen von FDBS Multidatenbank - Architektur Import/ExportSchemaArchitektur MultidatenbankenArchitektur 5-EbenenSchemaArchitektur Benutzer 1 Benutzer 2 ES 1 KS 1 KS 2 • Diese drei Schema-Architekturen zeigen uns die prinzipiellen Unterschiede und Gemeinsamkeiten von einerseits lose gekoppelten und andererseits eng gekoppelten föderierten Datenbanksystemen. 1. 2. Import / Export Multidatenbanken 3. 5-Ebenen 4. 5. Föderative DBS 35 2. Architekturen von FDBS Import / Export - Schema - Architektur Anwendung Importschema privates Schema Exportschema Datenbank 1. 2. 3. 4. PS 1 PS 2 Datenbank Datenbank 1. Import / Export 2. Multidatenbanken 3. 5-Ebenen ... ... ... ... ... - beschreibt die interne Struktur PS n der verwalteten Daten - internes Schema nachDatenbank ANSI/SPARC 4. 5. ES - externes Schema KS - konzeptionelles Schema AS - Abhängigkeitsschema ILS - internes logisches Schema PS - physisches Schema Föderative DBS 39 2. Architekturen von FDBS Multidatenbank - Architektur -hier ist der Anwendung Teil der Daten beschrieben - beschreibt die vom System verwalteten das Datenbanksystem in einer -den beschreibt die Daten die das System von Daten Föderation anderen zur Verfügung stellt anderen übernehmen möchte - Ausschnitt aus privaten Schema Importschema - lokales konzeptionelles Schema wird festgelegt welches - es werden Teile aus dem Exportschema Komponentensystem welche Form des anderer Systeme übernommen - unabhängig von der Teilnahme an der Zugriffs erhält (Lesen, Schreiben, usw.) Föderation - diese Übernahme muss verhandelt privates Schema Exportschema - es wird nur eine Zugriffskontrolle für die werden - beinhaltet kleinen Teil, der für an der Förderation beteiligten Informationen über die Teilnahme an Komponentensysteme realisiert (nicht für Föderation gedacht ist einzelne Nutzer) Datenbank ... 5. ILS 2 Benutzer 4 - es jeder kann Benutzer auch sinnvoll kann sich Benutzer 3 externes 5 eigenes sein direkt auf Benutzer Schema -realisiert eine spezielle zusammenstellen konzeptionelles Schema Sicht das interne ESzuzugreifen n1 aufauf ES n2 -Zugriff konzeptionelles externe Ebene logische Schema wenn nur Schema -z.B. einmalige nötig Anfrage werden -Ausschnitt wenn alle gezeigt verwalteten Gesamtheit der vom soll gezeigt Daten AS j KS 2 werden AS 1 System verwalteten Daten -externes Schema nach sollen (ILS kann entfallen) konzeptionelle Ebene -konzeptionelles Schema ANSI/SPARC -konzeptionelles Schema nachANSI/SPARC ANSI/SPARC nach ILS n Föderative DBS 36 Jeder Benutzer ist für die Erstellung seiner integrierten Sicht auf die von ihm benötigten Daten selbst verantwortlich. Explizite Integration 1. Schemata konzeptioneller Direktzugriff auf die versch. 2. Schemata konzeptionellen • 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 1. 2. 3. 4. 5. Föderative DBS 40 Import / Export Multidatenbanken 5-Ebenen 2. Architekturen von FDBS Import / Export 5 - Ebenen - Schema - Architektur externes Schema Exportschema Komponentenschema lokales Schema Datenbank 1. 2. Import / Export Multidatenbanken -auf einzelne Benutzer zugeschnittene Schnittstelle -möglicherweise anderes externes Schema Datenmodell als föderiertes Schema föderiertes Schema -gleiche Funktion wie externes Schema in zentralen DBS Exportschema -beschreibt den Ausschnitt aus -in ein anderes Datenmodell dem Komponentenschema -Gesamtheit derSchema durch die der transformiertes -konzeptionelles Komponentenschema Schema des der Föderation zur Verfügung Exportschemata einfließenden -beseitigt die Komponentendatenbankgestellt wird Daten Datenmodellheterogenität systems Datenmodell -globales -gleiches Datenmodell wie lokales Schema -implementierungsabhängige -potenzielle föderiertes Schema Beschreibung der Gesamtheit Integrationsprobleme von Daten Datenbank 3. 4. 5-Ebenen 5. Föderative DBS 41 Multidatenbanken Transformation 1. 2. Die Architektur ist somit prädestiniert in eng gekoppelten föderierten DBS zum Einsatz zu kommen. Das global verwaltete föderierte Schema erlaubt die Realisierung von Datenbankmanagement-Funktionalität auf globaler Ebene. Import / Export Multidatenbanken 3. 4. 5-Ebenen 5. Föderative DBS 42 3. externes Schema Exportschema Exportschema Komponentenschema (externes Schema) Komponentenschema (externes Schema) 1. 2. Import / Export Multidatenbanken 4. 5-Ebenen 5. 45 Import/Export - Multidatenbank - Architektur Architektur 5-EbenenSchema unterstütze unterstütze unterstütze Kopplungsform Kopplungsform Kopplungsform lose lose Kopplung Kopplung lose lose Kopplung Kopplung lose und und enge lose enge Kopplung Kopplung verantwortlich für verantwortlich für Integration Integration Integration Benutzer und und Benutzer lokaler Admin. lokaler Admin. Benutzer Benutzer globaler globaler Administrator Administrator Zugriff auf auf die die Zugriff Zugriff die Föderation Föderation Föderation vomlokalem lokalen von System System über globale globale über Schnittstelle Schnittstelle über dasdas globale über globale System System Unterstützung Unterstützung globaler DBMS globaler DBMS keine keine Teilweise Teilweise (MultiDB-Sprache) (MultiDB-Sprache) volle DBMSvolle DBMS Funktionalität Funktionalität 1. 2. 3. 5. Föderative DBS 46 3. Vergleich der Architekturen • 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 lokales Schema (konzeptionelles Schema) Föderative DBS 4. Alle Anwendungen laufen lokal, auf einem der Grundgedanke Komponentensysteme ab. internes Schema 3. Föderative DBS • es soll gezeigt werden, das die drei vorgestellten Referenzarchitekturen nicht so grundverschieden sind • Mischform mit Aspekten aller drei Architekturen föderiertes Schema internes Schema 5. MischMisch-Architektur für globalen Zugriff lokaler Anwendungen externes Schema Komponenten DBS 4. Integrationsoperation 3. Vergleich der Architekturen 2. Architekturen von FDBS Überschneidung mit ANSI/SPARC (Variante 1) lokales Schema (konzeptionelles Schema) Filteroperation Tabellarischer Vergleich Die 5-Ebenen-Architektur schränkt die Autonomie der Komponentensystem stärker ein als die anderen Architekturen. 2. Komponentenschema (externes Schema) Zwischen „benachbarten“ Schemata ist immer nur genau eine der Motivation folgenden Transformationsoperationen notwendig: Es existiert ein globales Schema in dem alle der Föderation zur Verfügung gestellten Daten beschrieben sind. 1. Exportschema Warum unterscheidet man Exportschema und Komponentenschema? 2. Architekturen von FDBS 5 - Ebenen - Schema - Architektur 2. Architekturen von FDBS 5-Ebenen 43 2. Architekturen von FDBS 1. 2. 3. 4. 5. Föderative DBS Globales konzeptionelles Schema Mapping Mapping Mapping Mapping Mapping Mapping 47 Globale konzept. Komponente Überschneidung mit ANSI/SPARC (Variante 2) externes Schema ImpS externes Schema virtuelles konzeptionelles Schema föderiertes Schema Exportschema Exportschema Komponentenschema (externes Schema) Komponentenschema (externes Schema) lokales Schema (konzeptionelles Schema) Komponenten DBS internes Schema 1. 2. 3. lokales konzeptionelles Schema lokales Schema (konzeptionelles Schema) lokales internes Schema internes Schema 4. 5. Föderative DBS ExpS Datenbank 44 ImpS ExpS ImpS ExpS • es ergibt wirdsich festgelegt, durchSchema die welche Integration Teile des der werden einerseits zur Zuordnung der lokalen • konzeptionelles es wird festgelegt welcheder Bestandteile Exportschemata lokalen konzeptionellen der lokalen Schemas zu Bestandteile vonKomponente Exportschemata konzeptionellen des globalen konzeptionellen Schemas virtuellesKS zur virtuelles konzeptionellen anderen Komponenten Verfügung Bestandteilen des globalen gestellt von der lokalen konzeptionellen konzeptionelles konzeptionelles werden konzeptionellen Schemas verwendet • Vermittler für die lokal werden laufenden Komponente verwendet Schema alle Daten die die Schema • beschreibt KS über Anwendungen die Zugriff auf die ihre • beschreibt diese Exportschemata Teiledie werden in den das anderen globale andererseits zur Abbildung desin KS •Datenbestände Gesamtheit der anderer DB benötigen zur konzeptionelle Verfügung gestellt Schemahaben aufgenommen globalen konzeptionellen Schemas auf dem jeweiligen lokales lokales Importschemata Komponentensystem •die dazu wird speziellesverwalteten integriertes konzeptionelles konzeptionelles Schema angebotender dasjeweiligen das jeweilige Schema Schema •Daten interne Schemata • diesekonzept. Funktionen müssen diverse und lokale Schema vollständig, Komponentensysteme Integrationsprobleme lösen •zusätzlich imlokales jeweiligen TeileDatenmodell aus Schematalokales anderer beinhaltet die konkrete internes internes •KS beschreiben Schema Implementierung der lokalen Schema konzeptionellen Schemata Datenbank Datenbank Lokale konzept. Komponente Lokale DBMS Vergleich 48 3. Vergleich der Architekturen Zusammenfassung 1. Integrationsstrategien OneOne-ShotShot-Integrationsstrategie Föderierte Datenbanksysteme sind eine bestimmte Art von Multidatenbanksystemen! integriertes Schema IS • FDBS zeichnen sich durch weiterbestehende Autonomie der Komponentensysteme aus • Autonomie, Heterogenität und Verteilung sind Merkmale von FDBS Import / Export 1. 2. Multidatenbanken 3. 4. S1 5-Ebenen Föderative DBS 5. S2 S3 S4 S5 S6 ... Sn zu integrierende lokale Schemata 49 1. 2. 3. 4. Gliederung Föderative DBS 5. 53 1. Integrationsstrategien Balancierte binäre Integrationsstrategie 1. Einleitung integriertes Schema IS 2. Konzeptionelle Architekturen 3. Wege zu integrierten Datenbanksystemen Problemstellung Integrationskonflikte teilintegrierte Schemata als Zwischenergebnisse Lösungsansätze 4. Erhaltung von integrierten Datenbanksystemen zu integrierende lokale Schemata 5. Zusammenfassung - Fazit - Ausblick Einsatz föderativer Datenbanksysteme 50 1. 2. 3. 4. Gliederung Föderative DBS 5. 54 1. Integrationsstrategien Gewichtete binäre Integrationsstrategie 3. Wege zu integrierten Datenbanksystemen 1. Allgemeine Problemstellung integriertes Schema IS 1. Integrationsstrategien 2. Integrationsprozess 3. Kriterien für Integrationsmethoden 2. Klassifizierung von Integrationskonflikten 1. Einführung 2. Schemakonflikte - Datenkonflikte 3. Lösungsansatz zu integrierende lokale Schemata 1. 2. 3. 4. 5. Föderative DBS 51 1. 2. 3. 4. 1. Allg. Problemstellung 5. Föderative DBS 55 1. Integrationsstrategien n-äre Integrationsstrategien (A - one shot, shot, B - iterativ) Es liegen mehrere unabhängig voneinander entworfene, heterogene Ausgangssituation Datenbankschemata der Komponentensysteme vor. integriertes Schema IS Problem: Daten sind in KS redundant oder in Beziehungen miteinander LS1 globales Schema LS2 Ziel: Redundanzen vermeiden und Daten korrekt in Beziehung zueinander setzen LS3 1. 2. 3. 4. B A 5. Föderative DBS zu integrierende lokale Schemata 52 1. 2. 3. 4. 5. Föderative DBS 56 2. Integrationsprozess 2. Klassifizierung von Integrationskonflikten 1. Unterscheidungsmöglichkeit • Probleme die in der Vorintegrationsphase beim Vergleich der zu Vorintegrationsphase integrierenden Schemata entdeckt werden Integrationsphase • Aufgrund der Vielzahl von Konflikten ist eine Kategorisierung nötig (1) Bestimmung von Gemeinsamkeiten (1) Wird halbautomatisch durch Interund Unterschieden Schema-Korrespondenz sowie einige Integrationsregeln (2) Gefundene Übereinstimmungen durchgeführt werden als sogenannte InterSchema-Korrespondenzen (2) Interaktion mit Datenbankfestgehalten administrator immer noch notwendig • Vier Klassen von Konflikten – Semantische Konflikte – Beschreibungskonflikte – Heterogenitätskonflikte – Strukturelle Konflikte 1. 2. 3. 4. 5. Föderative DBS 57 1. 2. 3. 4. 5. Föderative DBS 61 2. Schemakonflikte - Datenkonflikte 2. Integrationsprozess 2. Unterscheidungsmöglichkeit 1. Vorintegration 2. Vergleich der Schemata • Auswahl der Integrationsstrategie • gegebenenfalls Vergabe Präferenzen • lokale Schemata werden so modifiziert das sie anschließend zusammengeführt werden können 2. 3. 4. Attribut – Attribut Konflikte Tabellen – Tabellen Konflikte 4. Zusammenführung und Restrukturierung 3. Anpassung der Schemata 1. Schemakonflikte • Entdecken der Korrespondenzen • Finden von möglichen Konflikten Datenkonflikte falsche Daten Tabellen Attribut Konflikte Unterschiedliche Repräsentationen • für jeden entdeckten Konflikt wird eine Anpassung vorgenommen • kann wegen Autonomie nicht auf den lokalen Schemata erfolgen 5. Föderative DBS 58 1. 2. 3. 4. 5. Föderative DBS 62 Schemakonflikte -- Tabellen – Tabellen - Konflikte 3. Kriterien für Integrationsmethoden Tabellennamen konflikte 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 1. 2. 3. 4. 5. verschiede Namen für gleiche Tabellen gleiche Namen für verschiedene Tabellen fehlende Attribute eine Tabelle vs. eine Tabelle Tabellenstruktur konflikte fehlende, aber implizite Attribute Korrektheit Integritätsbedingungskonflikte Föderative DBS 59 viele Tabellen vs. viele Tabellen Schemakonflikte -- Attribut - Attribut - Konflikte 3. Kriterien für Integrationsmethoden Attributsnamenkonflikte • ist ein real-world-Konzept in mehreren lokalen Schemata modelliert so darf es im integrierten Schema nur einmal repräsentiert sein Minimalität • das integrierte Schema sollte leicht verständlich sein • soll Benutzern und Datenbankadministrator die Arbeit erleichtern 1. 2. 3. 4. 5. ein Attribut vs. ein Attribut gleiche Namen für verschiedene Attribute Default – Wert Konflikte Datentypkonflikte Verständlichkeit Föderative DBS verschiede Namen für gleiche Attribute Integritätsbedingungs konflikte 60 viele Attribute vs. viele Attribute Bedingungskonflikte Datenkonflikte Gliederung nicht korrekte Einträge 1. Einleitung 2. Konzeptionelle Architekturen falsche Daten 3. Wege zu integrierten Datenbanksystemen veraltete Daten 4. Erhaltung von integrierten Datenbanksystemen Erhaltung struktureller Konsistenz verschiedene Ausdrücke Unterschiedliche Repräsentation Erhaltung operationaler Konsistenz verschiedene Einheiten 5. Zusammenfassung - Fazit - Ausblick unterschiedliche Genauigkeit Einsatz föderativer Datenbanksysteme 3. Lösungsansatz 69 Gliederung • Zusicherungsbasierte Integration 4. Erhaltung von integrierten Datenbanksystemen • Welche Bestandteile der zu integrierenden Schemata einander entsprechen oder in irgendeiner für die Integration relevanten Beziehung stehen. 1. Erhaltung struktureller Konsistenz 1. Einfügen oder Löschen von Objekten • unabhängig von einem konkreten Datenbankmodell 2. Updates • automatische Auflösung von strukturellen Konflikten 2. Erhaltung operationaler Konsistenz • ein Ansatz ist die Schemaintegration 1. Klassischer Transaktionsbegriff 2. Allgemeine Prinzipien erweiterter Transaktionsmodelle 1. 2. 3. 4. Föderative DBS 5. 1. 66 2. 3. Lösungsansatz 3. A •E:= Schemaelemente zu denen kein Gegenstück • • bei strukturellen Konflikten wird immer die wenigerexistiert integrate-join(E1, E2, attcor 2(A12, A22), ..., attcorj (A1j,A2j)) eingeschränkte Struktur verwendet Objekttypen mit zugehörigen Werteattributen = A2j • •A1jäquivalente • • wichtigste •A Elementare Linksintegrate-join zwischen äquivalenten Schemaelementen A Operation 1. 67 2. 3. Lösungsansatz KName KAdr Name Kunden BestMenge n:m WPreis Preis Menge WarenBez Waren produziert Hersteller Branche 2. 3. 4. 5. VBranche Föderative DBS 5. Föderative DBS 71 2. Erhaltung operationaler Konsistenz Transaktion Ablauf Zusammenfassung von aufeinanderfolgenden DB DB 68 EOT DML - Operationen PName Verband HName 4. DB betreut 1:n HAdr 3. BOT PAdr E konsistente Operationen, die eine DB von einem konsistenten konsistente Zustand DB DB möglicherweise inkonsistente Datenbank wieder in einen konsistenten Zustand überführt. versorgt n:m Ware Produzent 1:n 1. Adresse Abnehmer bestellt D Lokales Lokales Objektmenge zuOlokaler Objektklasse OK1 Objektmenge zu lokaler Objektklasse OK2 Objekt Objekt O2 1 Föderative DBS 5. C C B D C A B Objektmenge zu lokaler Objektklasse OK1 Objektmenge zu lokaler Objektklasse OK2 D E Objektmenge zu lokaler Objektklasse OK1 Objektmenge zu lokaler Objektklasse OK2 von Pfaden die sich aus mehreren Links • •A1jIntegration A2j zusammensetzen • A1j ≠ A2j • Wie ein Objekttyp und ein Wertattribut bzw. ein komplexes Attribut integriert werden 4. B Globales Objekt OG 2j 3. Objektmenge zu globaler Objektklasse OKG Objektmenge zu globaler Disjunkte, aber zusammengehörige Objektmengen Objektklasse OKG Objektmenge zu globaler Semantisch äquivalente lokale Objektklasse OKG • • Integrationsregeln immer nur zweiS1, integrierende Schemata 2 Schemata S2, 2 Elemente mit Wertattributen E1, E2 2. 70 1. Erhaltung struktureller Konsistenz • Integrate-join Integration mit Hilfe sogenannter Integrationsregeln 1. Föderative DBS 5. Semantisch äquivalente Extension Semantisch überlappende Extension Schemaintegration 1j 4. A Atomicity eine TA läuft vollständig oder überhaupt nicht C Consistency TA läuft unter Konsistenzbedingungen ab I Isolation alle TA laufen voneinander isoliert ab D Durability alle Ergebnisse einer erfolgreichen TA sind persistent zu machen 1. 2. 3. 4. 5. Föderative DBS 72 2. Klassische Transaktionsbegriff Fazit Transaktionsverwaltung Serialisierbarkeit/ Recovery Mechanismen • • Offene Fragen: Konsistenz und Isolation Serialisierbarkeit – Schemaintegration von z.B: Heterogene Transaktionsverwaltung •• • • • • • • •• • beim parallelen Ablauf mehrer TARecovery muss dieMechanismen DB konsistent Atomarität und Dauerhaftigkeit lokale Transaktionsverwaltung unterschiedlich bleiben und die TA müssen einen konsistenten Zustand sehen read/ write – Modell globale Transaktionsverwaltung kennt die jeweiligen lokalen äquivalent zu einem seriellen Ablaufplan lesen ri(x) schreiben wi(x), commit ci, abort ai Transaktionsverwaltungen wenn Ti beendet wird muss Tj schon beendet sein Transaktionsverwaltung bildet einen Abarbeitungsplan globale Transaktionsverwaltung weiß nichts über die Problem sind kaskadierende Abbrüche (Schedule) jeweiligen lokalen Transaktionsverwaltungen • Realisierung durch Sperr Protokolle oder Zeitstempelverfahren 1. 2. 3. 4. • 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 5. 73 1. 2. 3. 4. Föderative DBS 5. 2. Erweiterter Transaktionsmodelle Geschachtelte Transaktion Darstellung geschachtelter Transaktionen • Transaktion ruft selbst wieder eine (Stufe Transaktion auf Top-level Transaktion Subtransaktion 1) Regeln Fazit • Offene Fragen: Ende der Präsentation – Schemaintegration von z.B: Subtransaktion (Stufe 2) • Methoden aus objektorientierten DB • Prozeduren aus relationalen DB Aufmerksamkeit Vielen Dank für Ihre • BEGIN WORK BEGIN WORK ist ein Baum von Transaktionen BEGIN WORK • Commit-Regel . . •. Wurzel heißt top-level-Transaktion, Knoten oder Blätter sind invoke subtransaction COMMIT WORK • Subtransaktionen Rollback-Regeln invoke subtransaction – Berücksichtigung von lokalen Integritätsbedingungen . Sichtbarkeitsregeln •.• Commit-Regeln, Rollback-Regeln, Sichtbarkeitsregeln COMMIT WORK invoke subtransaction . COMMIT WORK COMMIT WORK 1. 2. – Überwachung und Sicherstellung der Datenkonsistenz mit tragbaren Effizienzeinbußen BEGIN WORK . 3. 4. Wir wünschen der Seminargruppe ein frohes Fest und einen guten Rutsch ins neue Jahr !!! Föderative DBS 5. 74 Gliederung 1. 2. 3. 4. Föderative DBS 5. Globales konzeptionelles Schema Mapping Mapping Mapping Mapping ImpS 2. Konzeptionelle Architekturen virtuelles konzeptionelles Schema virtuelles konzeptionelles Schema virtuelles konzeptionelles Schema lokales konzeptionelles Schema lokales konzeptionelles Schema lokales konzeptionelles Schema lokales internes Schema lokales internes Schema lokales internes Schema Datenbank Datenbank Datenbank 3. Wege zu integrierten Datenbanksystemen 4. Erhaltung von integrierten Datenbanksystemen 5. Fazit Nachteile Offene Fragen Einsatz föderativer Datenbanksysteme • DB-Autonomie erhalten Import / Export ImpS Multidatenbanken Multidatenbanken Architekturen Import / Export - Schema -2. Architektur 5-Ebenen privates Schema • Datenaktualität: - lokale Redundanzen - Inkonsistenzen Datenbank Globale konzept. Komponente ExpS Lokale konzept. Komponente Lokale DBMS 5-Ebenen Misch79form von FDBS Importschema Importschema • rein wissenschaftlicher Ansatz 78 Anwendung Anwendung • Unterschiedliche Anfragesprachen in heterogenen Systemen • Migration am operativen System möglich ExpS Import / Export • Performanz • Multi-DB-Zugriff ImpS 75 Fazit • Überwindung der Heterogenität in DB ExpS Mapping Mapping 1. Einleitung Vorteile 77 Exportschema ... privates Schema Exportschema Datenbank „Integration on the Fly“ 1. 2. 3. 4. 5. Föderative DBS 76 1. 2. 3. 4. 5. Import / Export Multidaten5-Ebenen Föderative DBS banken Misch80form Import / Export Multidatenbanken 2. Multidatenbank - Architektur Benutzer 1 5-Ebenen Benutzer 4 Benutzer 3 Benutzer 5 Benutzer 2 ES 1 ES n1 KS 1 ... ... ... ... KS 2 ILS 2 PS 1 PS 2 Datenbank Datenbank 1. 2. Import / Export Architekturen von FDBS Multidatenbanken 3. 4. ES n2 KS 2 externe Ebene ... AS 1 AS j konzeptionelle Ebene ILS n ES - externes Schema KS - konzeptionelles Schema AS - Abhängigkeitsschema ILS - internes logisches Schema PS - physisches Schema PS n Datenbank 5. Import / Export Multidaten5-Ebenen Föderative DBS banken 2. Architekturen 5 - Ebenen - Schema - Architektur 5-Ebenen externes Schema Misch81form von FDBS externes Schema föderiertes Schema Exportschema Exportschema Komponentenschema Komponentenschema lokales Schema lokales Schema Datenbank 1. 2. Datenbank 3. 4. 5. Import / Export Multidaten5-Ebenen Föderative DBS banken Misch82form
