PS Informationssysteme in vernetzten Systemen1 Database Interoperability UND Gegenwärtige...

PS Informationssysteme in vernetzten Systemen

1

Database InteroperabilityUND

Gegenwärtige Forschungsschwerpunkte

Michael Rinner, 9901425


2

Interoperability – Inhalt

ÜberblickDatenbank IntegrationDurchführen von AbfragenTransaktionsmanagementObjekt-Orientierte Technologien


3

Interoperability - Überblick

Homogene verteilte DB SystemeHeterogene verteilte DB SystemeVerteilte Multi-DBMS:

Bestehen aus mehreren unterschiedlichen DB Typen mit jeweils unterschiedlichen DBMS

Bieten Interoperabilität zwischen den DBs


4

Interoperability – Database IntegrationSchemata aus verschiedenen Datenbanken werden zu einem einzigen universellen DB-Schema zusammengefasstWird als Global Conceptual Schema bezeichnetDesign von Multi-DBMS ist Bottom-up

DB Integration erfolgt in zwei Schritten: Schema Übersetzung Schema Integration

Schema Übersetzung: Ein bestimmtes Schema wird auf ein anderes abgebildet. Das

Produkt wird als kanonische Zwischenform bezeichnet

Schema Integration: Identifikation der Komponenten einer DB und Bestimmung ihrer

Beziehungen zueinander Wahl der bestmöglichen Repräsentation Integration der kanonischen Zwischenformen in ein globales Schema


5

Interoperability – Database Integration


6

Ein Schema wird auf ein anderes Schema abgebildet

Für das Globale konzeptuelle Schema muss ein

Zieldatenmodell festgelegt werden

Gemeinsamkeiten zwischen dem Ursprungsmodell und dem Zielmodell müssen herausgearbeitet werden

Interoperability – Schema Translation


7

Generiert das globale konzeptuelle Schema, indem es die kanonischen Zwischenformen zusammenfasst

Beschäftigt sich mit:

Identifikation der Komponenten einer DB und ihren Beziehungen

Auswahl der bestmöglichen Repräsentationsform für das globale konzeptuelle Schema

Integration der kanonischen Zwischenformen

Interoperability – Schema Integration


8

Interoperability - Integrationsmechanismen

Integrationsmechanismen

Binäre Integration Zwei verschiedene Schemata werden zur gleichen Zeit integriert

N-äre Integration Mehrere verschiedene Schemata werden zur gleichen Zeit integriert

One-Pass Integration Alle vorhandenen Schemata werden zur gleichen Zeit integriert

(Sonderform N-äre Integration)Trade-Off zwischen Komplexität und Informationsgehalt Je mehr Schemata zur gleichen Zeit integriert werden, desto mehr

Information ist zur Integrationszeit vorhanden. Allerdings werden die Vorgänge dadurch auch immer komplexer und schwieriger zu automatisieren


9



10


Schema Integration umfasst zwei zentrale Begriffe: Homogenisierung

Bestimmung der strukturellen und der semantischen Probleme jeder Teildatenbank

Ziel: Teildatenbanken sollen sowohl semantisch, als auch strukturell vergleichbar sein, wenn sie integriert sind

Semantische Konflikte – Problem mit Benennung von Einheiten Synonyme und Homonyme Zwei identische Entitäten, unterschiedlicher Name – Synonym Zwei unterschiedliche Entitäten, gleicher Name – Homonym

Strukturelle Konflikte Typ Konflikte Abhängigkeitskonflikte Schlüssel Konflikte Verhaltenskonflikte


11


Homogenisierung Bestimmung von Homonymen und Synonymen und die Bestimmung von

strukturellen Konflikten erfordert die Bestimmung von Beziehungen zwischen einzelnen Schemata

Sie können identisch sein Eine Schema kann eine Teilmenge eines anderen Schemas sein Ein Schema kann eine Elemente enthalten, die auch in einer anderen

Menge enthalten sind Sie können disjunkt sein

Integration Verschmelzung und Restrukturierung der Zwischen Schemata zu einem

einheitlichen globalen Schema Informationen aus den Zwischenschemata müssen übernommen

werden Drei Dimensionen

Komplett Minimal Verständlich


12

Interoperability – Behandlung von Abfragen

Optimierung von Abfragen in homogenen verteilten DBMSs: Aufspalten der Abfrage Suchen der betreffenden Daten Globale Optimierung Lokale Optimierung

Architektur des Multi-DBMS spielt entscheidende Rolle Zusätzliche Softwareschicht über den lokalen DBMS

Optimierung von Abfragen in Multi-DBMS komplexer, weil Fähigkeiten der lokalen DBMS unterschiedlich Kosten für die Durchführung unterschiedlich Problem beim Verschieben von Daten zwischen DBMS Fähigkeiten für lokale Optimierung sehr unterschiedlich


13

Interoperability - Autonomie

Autonomie der Teil-DBMS in folgenden Formen

Autonomie bei der Kommunikation Autonomie beim Design Autonomie bei der Ausführung

Autonomie sollte nicht beeinträchtigt werden, stellt aber großes Hindernis in Heterogenen Verteilten Systemen dar.


14

Interoperability – verteilte Abfragen


15

Interoperability – Optimierung von Abfragen 1

Arten Heuristik basierte Ansätze Kosten basierte Ansätze

Kosten basierte Ansätze Bushy Join Trees Left Linear Join Trees

Left Linear Join Trees liefern in zentralisierten Datenbanken sehr gute Ergenisse, sind aber für Multi-DBMS nur bedingt geeignet, da sie keine Möglichkeiten für parallele Abarbeitung bieten.


16



17

Lösung: Es werden Bushy Join Trees zu den gleichen Kosten wie Left Linear

Trees erzeugt!? – Zauberei? Zuerst werden Left Linear Trees erzeugt und dann zu Bushy Join

Trees umgebaut

Globale Kostenfunktion – 3 verschiedene Ansätze

Teil DBMS wird als Black Box betrachtet. Ergebnisse von Testabfragen werden als Richtwerte herangezogen

Ableitung der Kostenfunktion aus dem bestehenden Wissensstand unter Berücksichtigung der Informationen über jedes Teil-DBMS

Beobachtung des Laufzeitverhaltens – dynamisches Sammeln und Auswertung von Information



18

Interoperability – Transaktionsmanagement 1

Herausforderung für Multi-DBMS: Durchführung von globalen Update-Operationen (INSERT, DELETE,

UPDATE), ohne die Autonomie der Teilsysteme einzuschränken

Autonomie der Teil-DBMS Execution Autonomie Design Autonomie

Jedes Teil-DBMS hat einen eigenen Lokalen Transaktions Manager (LTM) und eine Multi-DBMS Software SchichtTransaktionsmanager der Multi-DBMS Schicht heißt Global Transaction Manager (GTM)

Zwei Arten von Transaktionen in einem Multi-DBMS: Lokale Transaktionen Globale Transaktionen


19

Concurrency Control (Kontrolle des gleichzeitigen Zugriffs) Jeder LTM ist für die korrekte Ausführung der Transaktionen in

seiner eigenen DB verantwortlich

Jeder LTM ist außerdem dafür verantwortlich, dass sein Transaktionsplan serialisierbar ist und Fehler rückgängig gemacht werden können

Jeder LTM hält sich an die Ausführungsreihenfolge, die vom GTM festgelegt wird

Der GTM ist verantwortlich für die globale Steuerung von Transaktionen (Deadlocks!)

Interoperability – Transaktionsmanagement 2


20

Interoperability – Objekt-Orientierung

Objektorientierung spielt eine wichtige Rolle im Bereich Architektur und als objektorientierte DBs

Zwei wichtige OO-Konzepte: Kapselung Spezialisierung/Generalisierung

Zahlreiche OO-Plattformen zur Entwicklung von verteilten Systemen können auch zur Verbindung von Datenbanksystemen herangezogen werden:

CORBA DCOM COM OLE Etc.


21

Interoperability - OMAObject Management Architecture (OMA) ist eine verteilte Architektur der Object Management Group (OMG) zur Erstellung verteilter Umgebungen

OMA definiert Objekt Modell Interaktionsmodell mit Method Invocations Services

Ein OMA Modul besteht aus Applikationsobjekten Common Object Request Broker (CORBA) Common Object Services (COSS)


22

Interoperability - CORBA


23

Interoperability - CORBACORBA – wichtigster Mechanismus von OMAObject Request Broker (ORB) – regelt die Kommunikation zwischen den Objekten im Netzwerk

Bietet folgende Grundfunktionalitäten: Target Object Location Message Delivery Method Binding

Außerdem bietet CORBA noch Services für: Naming Query Concurrency Transaction Event Life Cycle Relationship Etc.


24

Interoperability - CORBA


25

Interoperability – CORBA und Database Interoperability

Unterstützt Heterogenität durch Interface Definitionen (IDL)CORBA und COSS bieten einfache Datenbank Services

Transaction Services Backup- und Recovery Services Concurrency Services Query Services


26

Current Issues - Inhalt

ÜberblickDatenübertragungData WarehousingWorld Wide Web (WWW)Push-based TechnolgiesMobile Datenbanken


27

Grundlage – Technologische Veränderungen

Entwicklung von Breitband Netzwerken Aufkommen des Internets Decision Support Systems Bewältigung riesiger Datenmengen

Online Transaction Processing (OLTP) Online Analytical Processing (OLAP) Data Warehousing

Änderungen im Datenzugriffsverhalten Repräsentation von Informationen im Internet

Current Issues - Überblick


28

Current Issues – GrundlagenDatenübertragung Drei verschiedene Gesichtspunkte: Übertragungsmodus

Pull-only Push-only Hybrid

Übertragungshäufigkeit Periodisch Bedingt Ad-hoc Unregelmäßig

Kommunikationsmethoden Unicast (one-to-one) Multicast (one-to-many)


29

Current Issues - Grundlagen


30

Current Issues – Data WarehousingData Warehousing – Soll den Entscheidungsprozess erleichtern

Wichtiges Anwendungsgebiet für verteilte DBs: Decision Support Systems

Vorläufer und Technologien: Online Transaction Processing (OLTP) Online Analytical Processing (OLAP)

Aggregation von DatenZugriffe auf Daten generell read-only


31

Current Issues – Data Warehousing


32

Current Issues – Data Warehousing Architekturen

Besteht aus einer oder mehreren QuelldatenbankenQuell-DBs beinhalten operationale Daten (nicht aufbereitet)Werden in einer Zieldatenbank zusammengefasst (Warehouse)Integration ist ähnlich zur Integration von Multi-DBMS

Zwei verschiedene Typen Zentralisierter Ansatz

Datamarts Dezentralisierter Ansatz

OLAP Datenmodell Multidimensional Aggregation als wichtigste Methode zur Datenmanipulation

OLAP Servers Multidimensional OLAP (MOLAP) – direkter Zugriff auf mehrdimensionale

Datenstrukturen Relational OLAP (ROLAP) – verwendet Methoden von relationalen DBs


33

Current Issues – Data Warehousing Architekturen


34

Das Web wächst exponentiell

Anzahl und Art der Applikationen nimmt ständig zu

Schnelle Entwicklung führt zu Problemen Sicherheit Zugriff auf die „richtigen“ Informationen

Verteilte DBs werden immer wichtiger Stichwort: Strukturierung von Information

Current Issues - WWW


35

Current Issues - WWWArchitektur und Protokolle

Web Architektur: Client/ServerHTTP und TCP/IP HTTP ist effizient (große Anzahl zustandsloser Verbindungen) Bietet nur unzureichende Unterstützung für Sessions

Uniform Resource Locator (URL)HTML (Hypertext Markup Language) Weitgehend plattformunabhängig

XML (Extended Markup Language) Bietet eine klarere Trennung zwischen Datenstrukturierung und

Präsentation Stärker plattformunabhängig als HTML Erleichtert den Suchprozess durch Strukturinformation in Dokumenten Standard für den Datenzugriff


36

Zugriff auf Datenbanken im WebThree-Tier-Architektur

Kann auf eine N-Tier-Architektur verallgemeinert werden

Current Issues - WWW


37

Current Issues - WWWWeb ist eine Sammlung von unstrukturierten Dokumenten Welche Formen der Strukturierung kommen vor?

Unstrukturiert (Bilder, einfache Texte) Semistrukturiert (HTML, XML) Voll Strukturiert (relationale oder objektorientierte DBs)

Semistrukturierte Daten Darstellung als Graph

Knoten sind Objekte Kanten sind Referenzen

Object Exchange Model (OEM) Document Object Model (DOM)

Datenintegration im Internet Einsatzgebiet für Multi-DBMS große Anzahl an Datenquellen Unterschiedlich stark strukturiert Unterschiedliche Fähigkeiten

Forschung erst am Anfang – Datenbanken nicht für Speicherung geeignet


38

Current Issues – WWW

Integration von Information aus dem Internet erfordert integrierte globale Sicht Anzahl der Datenquellen sehr hoch Datenquellen sehr dynamisch Datenquellen sind sehr unterschiedlich (DBMS, Files, etc.) Daten können unstrukturiert oder semistrukturiert sein

Wrapper Exportiert Informationen über die Datenquelle, das verwendete

Schema, die Daten und die Abarbeitung von AbfragenMediator Zentralisiert die Informationen, die Wrapper liefern und bereitet sie

in einer einheitlichen Sicht auf (global data dictionary) Zerlegt Benutzerabfragen in Teile (welche die Wrapper ausführen)

und baut die Antwort aus den Teilergebnissen zusammen


39


• Keine Vorgaben, wie die Datenquellen beschreiben sollen

• Keine Vorgaben, wie Mediator mit den Daten umgehen soll

• Weit verbreitete Abstraktion für die Integration von Information


40

Gegenwärtige Forschungsschwerpunkte

Mediator-Wrapper Architektur

Gleichartiger Zugriff auf heterogene Datenquellen im Internet

Zugriff auf semistrukturierte Daten

Verhindern von Ausfällen des Gesamtsystems, wenn eine Datenquelle ausfällt - Fehlertoleranz



41

Current Issues – Push-based ApproachAntwort auf Probleme in traditionellen Pull-based SystemenPull-based?

Client fordert Information vom Server an – Server selbst ist passiv

Problem Benutzer muss selbst wissen, wo er Information findet Asymmetrie im Web – wird vom Pull-based Approach nicht berücksichtigt

Asymmetrie im Netz Unterschiedliche Bandbreite bei Up- und Downstream Unterschiedliche Anzahl von Clients und Servern in DS (Serverüberlastung) Datenfluß vom Server zum Client umfangreicher als umgekehrt Data Volatility

Probleme bei Push-based Ansätzen Server muss die Bedürfnisse der Clients kennen Cache Management auf Client Seite schwierig


42

Current Issues – Push-based ApproachDelivery Schedule (Zeitplan für Datenübertragungen)

Server muss wissen, wann jeder Client welche Infos benötigt

Broadcast Disk – Daten werden übertragen, wenn sie verfügbar sind

Flat Disk – Gleichzeitige Übertragung aller Daten in konstanten abständen – Problem: „hot“ und „cold“ Pages

Skewed – Zufällige Übertragung von Seiten, wobei Hot Pages eine höhere Übertragungswahrscheinlichkeit haben

Multi-Disk – Hot Pages werden häufiger übertragen, aber in unregelmäßigen Abständen


43

Client Cache Management Update-Zeitplan ist ein Kompromiss Aufgabe: So viele benötigte Seiten wie möglich im Cache

halten Traditionelle Ansätze (LRU): „Hottest Pages“ werden

gecached Problem 1: Muss die Kosten für das Ersetzen einer Seite

berücksichtigen Problem 2: Jeder Client hat eigene „Hot Pages“ Problem 3: Müssen nicht mit globalen „Hot Pages“

übereinstimmen Lösung: Cache sollte jene Seiten beinhalten, die global

„cold“, aber lokal „hot“ sind

Current Issues – Push-based Approach


44

Durchführen von Updates Add, Delete und Update Operationen Entfernen von Seiten aus dem Update Schedule Konsistenzprobleme auf der Clientseite Ansätze zur Lösung des Problems

Latest Value Quasi-Caching Periodisch Serializability Opportunistic

Problem mit Updates ist noch großteil unverstanden!!!!!

Current Issues – Push-based Approach


45

Current Issues – Mobile DatenbankenZentrales Thema: Einsatz von Datenbanken in Wireless Networks

Wireless Network besteht aus Einer „Wireline“ (fixed) Network Bachbone Mehreren Kontrollstationen die über diese verbunden sind Jede Kontrollstation kontrolliert die Kommunikation mit Mobilen

Einheiten innerhalb seiner Zelle Daten können sowohl im Netzwerk, als auch auf mobilen Einheiten

liegen„Walkstation“ CaseProbleme mit Wireless Networks: Kommunikation: Ausfälle von Einheiten, schlechte Verbindungen,

Echo, geringe Bandbreite Mobilität: Adress Migration Portabilität: Beschränkungen für Equipment


46

Current Issues – Mobile Datenbanken


47

Current Issues – Mobile DatenbankenWeitere Probleme mit mobilen Einheiten Batteriebetriebene Geräte haben eine begrenzte Lebensdauer Verfügbarkeit ist nicht immer gegeben Problem mit der Verfolgung von mobilen Einheiten im Netzwerk

Directory Management Hängt eng mit Architektur zusammen Optimale Verteilung der Einheiten? – Zentrale Frage Wie sollen Mobile Einheiten lokalisiert werden?

Jede Mobile Einheit hat eine Heimatstation, die seine gegenwärtige Position kennt

Suchen mit Hilfe von Broadcasts in einem bestimmten Bereich des Netzwerks

Zurücklassen der Adresse zu der die Station geht Wie sollen Daten im Netzwerk verteilt werden, damit optimal darauf

zugegriffen werden kann?


48

Caching in Wireless Networks

Query Shipping System – Leistungsschwache Einheiten Berechnung werden stationär durchgeführt Daten danach an die mobilen Einheiten gesendet

Semantic Caching

Granularität – Resultat einer Abfrage Weniger Netzwerk Traffic Geringerer Platzbedarf Unterstützt Ortsbasierende Ersetzungsstrategien

Cache Kohärenz Automatische Updates vom Server Benachrichtigungen über Gültigkeit der Daten



49

Broadcast Data

Broadcasting von Basisstationen an mobile Einheiten wirkt Performance steigernd

Sehr regelmäßiger Broadcast Schedule nötig

Inhalt der übertragenen Daten sollte dynamisch und adaptiv sein

Tuning time Wie lange muss ein Client auf einem Kanal horchen, bis die Information

kommt

Air-Cache Approach Ändert den Inhalt einer Broadcast Disk dynamisch, je nach der

Zugriffsfrequenz der Daten



50

Abarbeitung und Optimierung von Abfragen sind sehr stark von der Mobilität der Einheiten beeinflusstProblem:

Ortsabhängigkeit von Abfragen im Zusammenhang mit mobilen Einheiten Traditionelle DBMS unterstützen nur ortsabhängige Abfragen („location

transparency“) Location Dependent Data (LDD)

Gleiche Abfrage an verschiedenen Orten führt zu unterschiedlichen Ergebnissen „Spatial Replication“

Lösung: Lokale Abfragen werden mit Ortsspezifischen Informationen Abfrage wird dabei an einen bestimmten Ort gebunden

Optimierung: Bestimmung von Kosten der Kommunikation sehr schwer! Hohe Kosten durch Network Traffic, schlechte Bandbreite, etc. Statische Optimierungsmethoden können nicht angewandt werden


PS Informationssysteme in vernetzten Systemen1 Database Interoperability UND Gegenwärtige...

Documents

Transcript of PS Informationssysteme in vernetzten Systemen1 Database Interoperability UND Gegenwärtige...