Besonderheiten verteilter Datenbanksysteme - Userpage
Besonderheiten verteilter Datenbanksysteme - Userpage
Besonderheiten verteilter Datenbanksysteme - Userpage
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Verteilte Datenbank- und<br />
Informationssysteme<br />
Vorlesung im Sommersemester 2009<br />
(Abschnitt <strong>Besonderheiten</strong> <strong>verteilter</strong> <strong>Datenbanksysteme</strong>)<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 1
Übersicht und Einführung<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 2
Verteilte Verarbeitung I<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 3
Verteilte Verarbeitung II<br />
• Applikation bzw. Nutzer koordiniert den Verbindungsaufbau<br />
zur DB<br />
• Die Standorte der Datenbank-Server im Netz müssen<br />
bekannt sein<br />
• Zwischen den DB bestehen keine von der Anwendung<br />
unabhängige Beziehungen<br />
• Es können keine DB-übergreifenden SQL-Anweisungen<br />
ausgeführt werden<br />
• Eine DB-übergreifende Transaktionssicherung wird<br />
durch das DBMS nicht gewährleistet<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 4
Grundprinzip verteilte Datenbank<br />
Grundprinzip <strong>verteilter</strong> Datenbanken ist die<br />
Verteilungstransparenz. Ein verteiltes DBS<br />
muss sich dem Anwender gegenüber<br />
genauso verhalten wie ein nicht verteiltes.<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 5
Definition verteilte Datenbank<br />
Eine verteilte Datenbank ist ein logisch zusammengehörender<br />
Datenbestand – beschrieben in einem<br />
globalen Schema -, der physisch auf mehreren Knoten<br />
(Rechner) verteilt ist und mit einem verteilten<br />
Datenbankmanagementsystem (kurz VDBMS) oder<br />
auch distributed DBMS (kurz DDBMS) verwaltet wird.<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 6
Grobstruktur eines VDBMS<br />
Rechnerknoten<br />
B<br />
Rechnerknoten<br />
A<br />
Nur eine Sicht<br />
auf die Daten<br />
Internet, Intranet,<br />
Extranet<br />
Rechnerknoten<br />
E<br />
Rechnerknoten<br />
C<br />
Rechnerknoten<br />
D<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 7
Verteilte Datenbank<br />
Ausgangspunkt: relationales Modell<br />
• Spezifikation der Datenobjekte des Bezugsbereichs im<br />
Rahmen eines relationalen Modells<br />
• Das DBMS bietet die Möglichkeit mehrere räumlich im<br />
Netz verteilte DB zu einer Sicht zusammenzufassen<br />
Vorteile/Ziele<br />
• Nutzer/Anwendung muss nichts von der Verteilung der<br />
DB im Netz wissen (Ortstransparenz)<br />
• Möglichkeit der Ausführung DB-übergreifender SQL-<br />
Abfragen und Transaktionen<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 8
Anforderungen an<br />
verteilte Datenbanken<br />
Brainstoming<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 9
Zwölf Regeln für verteilte DBS I<br />
• Lokale Autonomie<br />
- Jeder Rechner sollte maximale Kontrolle über eigene Daten<br />
haben<br />
- Zugriff auf diese Daten sollte nicht von anderen Rechnern<br />
abhängen<br />
• Keine Abhängigkeit von zentralen Systemfunktionen<br />
- DB-Verarbeitung sollte nicht von zentralen Systemfunktionen<br />
abhängen<br />
- Gefahr potentieller Leistungsengpässe durch zentrale<br />
Systemkomponenten<br />
Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-<strong>Datenbanksysteme</strong>, Addison-Wesley, 1994<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 10
Zwölf Regeln für verteilte DBS II<br />
• Hohe Verfügbarkeit<br />
- Unanfälligkeit gegen ggf. auftretende Fehler wie z.B. dem<br />
Ausfall eines Rechnerknotens<br />
- Möglichkeiten einer Konfigurationsänderung während des<br />
laufenden Betriebs (z.B. neue SW oder HW)<br />
• Ortstransparenz<br />
- Verbergen der physischen Lokation von Datenbankobjekten<br />
gegenüber dem Benutzer<br />
- Der Datenzugriff auf entfernte Daten sollte in gleicher Weise<br />
erfolgen, wie der auf lokale Objekte<br />
Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-<strong>Datenbanksysteme</strong>, Addison-Wesley, 1994<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 11
Zwölf Regeln für verteilte DBS III<br />
• Fragmentierungstransparenz<br />
- Eine Relation der DB sollte verteilt an mehreren Knoten<br />
gespeichert werden können<br />
- Die zugrunde liegende Zerlegung der Relation sollte für den<br />
Datenbankbenutzer transparent sein<br />
• Replikationstransparenz<br />
- Die replizierte Speicherung von Teilen der Datenbank sollte für<br />
den Benutzer unsichtbar bleiben<br />
- Die Wartung der Redundanz obliegt ausschließlich der<br />
Datenbanksoftware<br />
Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-<strong>Datenbanksysteme</strong>, Addison-Wesley, 1994<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 12
Zwölf Regeln für verteilte DBS IV<br />
• Verteilte Anfragebearbeitung<br />
- Innerhalb einer DB-Operation sollte auf Daten mehrerer Rechner<br />
zugegriffen werden können<br />
- Zur effizienten Bearbeitung von DB-Anfragen sind durch das<br />
VDBMS geeignete Techniken bereitzustellen (Query Optimizer)<br />
• Verteilte Transaktionsverarbeitung (TA-Transparenz)<br />
- ACID-Eigenschaften sind auch bei <strong>verteilter</strong> Bearbeitung<br />
einzuhalten<br />
- Bereitstellung entsprechender Recovery- und Synchronisationstechniken<br />
(verteiltes 2 Phasen Sperrprotokoll)<br />
Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-<strong>Datenbanksysteme</strong>, Addison-Wesley, 1994<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 13
Zwölf Regeln für verteilte DBS V<br />
• Hardware-Unabhängigkeit<br />
- Die Datenbank-Verarbeitung sollte auf unterschiedlichen<br />
Hardwareplattformen möglich sein<br />
- Sämtliche Hardwareeigenschaften sollten gegenüber dem<br />
Datenbankbenutzer verborgen bleiben<br />
• Betriebssystemunabhängigkeit<br />
- Die Datenbankbenutzung sollte unabhängig von den<br />
eingesetzten Betriebssystemen sein<br />
- Verteilte Datenbankmanagementsysteme sollten<br />
unterschiedliche Betriebssystemplattformen unterstützen<br />
Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-<strong>Datenbanksysteme</strong>, Addison-Wesley, 1994<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 14
Zwölf Regeln für verteilte DBS VI<br />
• Netzwerkunabhängigkeit<br />
- Verwendete Netzwerke und darauf aufsetzende<br />
Kommunikationsprotokolle sollten ohne Einfluss auf die<br />
Datenbankverarbeitung leiben.<br />
• Datenbanksystemunabhängigkeit<br />
- Es sollte möglich sein, unterschiedliche (Heterogene)<br />
<strong>Datenbanksysteme</strong> an den verschiedenen Rechnern<br />
einzusetzen, solange sie eine einheitliche Benutzerschnittstelle<br />
(z.B. gemeinsame SQL-Version) anbieten.<br />
Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-<strong>Datenbanksysteme</strong>, Addison-Wesley, 1994<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 15
Transaktionstransparenz<br />
• Bei einer verteilten Transaktion wird auf Datenelemente<br />
unterschiedlicher DB, welche auf verschiedenen<br />
Rechnerknoten verteilt sind, zugegriffen.<br />
• ACID-Bedingungen sind im Rahmen eines VDBMS in<br />
gleicher Weise einzuhalten wie in einem zentralen DBMS<br />
• Der Entwickler einer Anwendung sollte eine verteilte TA<br />
in gleicher Weise nutzen wie eine lokale TA<br />
• Auch implizite TA (ausgelöst durch Trigger) sollten von<br />
der Transaktionstransparenz profitieren<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 16
Leistungstransparenz<br />
• Verteilung von Datenbankobjekten zwecks Erhöhung des<br />
Leistungs- und Ausfallverhaltens im Gesamtsystem<br />
- Verteilte Verarbeitung von Anfragen und Transaktionen soll trotz<br />
des Kommunikations-Overheads mit der gleichen Performance<br />
erfolgen wie ohne Verteilung<br />
- Im Falle replizierter Datenobjekte (kontrollierte Redundanz)<br />
sollten Leistungsengpässe eines Knoten durch Knoten mit<br />
weniger Last aufgefangen werden können. (Load-Balancing)<br />
- Bei paralleler Bearbeitung eingehender Anfragen wird eine<br />
Verbesserung der Bearbeitungszeiten angestrebt<br />
In Anlehnung an - Rahm, E.: Mehrrechner-<strong>Datenbanksysteme</strong>, Addison-Wesley, 1994<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 17
Architektur <strong>verteilter</strong><br />
Datenbanken<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 18
4-Ebenen Architektur für verteilte<br />
<strong>Datenbanksysteme</strong><br />
In Anlehnung an : Conrad, S.: Förderierte <strong>Datenbanksysteme</strong>, Springer-Verlag, 1997<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 19
Externes Schemata im VDBMS<br />
• Repräsentieren Sichten der Benutzer und Anwenderprogramme<br />
(vergleichbar zum zentralen Datenbanksystem)<br />
• Für Benutzer bzw. Benutzergruppen werden jeweils eigene externe<br />
Schemata angelegt<br />
• Das externe Schemata ist in Art und Funktion für verteilte und<br />
zentrale <strong>Datenbanksysteme</strong> nicht unterscheidbar<br />
• Für den Benutzer sollte es keinen Unterschied machen, ob er mit<br />
einer zentralen oder verteilten Datenbank arbeitet.<br />
• In der Praxis kann es ggf. dennoch zu kleinen Unterschieden<br />
kommen (insbesondere bei heterogenen DBMS)<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 20
Globales konzeptionelles<br />
Schema im VDBMS<br />
• Beschreibung der durch das DBS zu verwaltenden Daten in ihrer<br />
Gesamtheit<br />
• Abstrakte Beschreibung ohne Berücksichtigung konkreter<br />
Implementierungsdetails<br />
• Ziel beim konzeptionellen Schema im VDBMS ist die Integration der<br />
verschiedenen externen Benutzersichten<br />
• Im verteilten <strong>Datenbanksysteme</strong>n ist das konzeptionelle Schema<br />
gleichzeitig die Zusammenfassung aller lokalen konzeptionellen<br />
Schemata (Vereinigung)<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 21
Lokale konzeptionelle<br />
Schemata im VDBMS<br />
• Die lokalen konzeptionellen Schemata ergeben sich aus der Definition<br />
der Datenverteilung, die im globalen Verteilungsschema festgelegt<br />
sind. (Ausschnitt aus dem globalen konzeptionellen Schema)<br />
• Enthalten sind folgende Angaben:<br />
- Informationen zur auf dem Knoten hinterlegten Fragementen<br />
- Allokation und Replikation von Relationsfragmenten<br />
• Bei fehlender Replikation sind die lokalen konzeptionellen Schemata<br />
echte Teilmengen der globalen konzeptionellen Schemata.<br />
• Die ggf. notwendige Propagierung von Änderungen des lokalen<br />
konzeptionellen Schema ist abhängig von der gewählten<br />
Katalogarchitektur.<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 22
Lokale interne Schemata<br />
im VDBMS<br />
• Hier gibt es keine Unterschiede zu den internen Schemata einer<br />
zentralen Datenbank.<br />
• Im Sinne der Knotenautonomie sind Zugriffspfade und<br />
Speicherstrukturen auf lokale Erfordernisse abzustimmen.<br />
• Das interne Schema ist abhängig vom verwendeten Basissystem<br />
und von der unterstützten Sprachschnittstelle.<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 23
Katalogverwaltung bei<br />
verteilten Datenbanken<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 24
Katalogverwaltung I<br />
• Schemadaten zum Datenbank-Aufbau<br />
• Metadaten für<br />
- Zugriffsberechtigungen<br />
- Passwörter<br />
- Statistiken über:<br />
• Relationengrößen<br />
• Werteverteilungen<br />
• Zugriffshäufigkeiten<br />
• Übersetzung, Optimierung und Ausführung von DB-Anfragen<br />
• Unterscheidung zwischen lokalen und globalen Katalog<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 25
Katalogverwaltung II<br />
• Lokaler Katalog<br />
- Entspricht weitgehend dem Katalog eines zentralisierten DBS<br />
- Enthält das lokale konzeptuelle und das lokale interne Schema<br />
• Globaler Katalog<br />
- Enthält globales konzeptuelles- und das Verteilungsschema<br />
- Gewährleistet die Verteilungstransparenz<br />
- Systemweite Verwaltung von Benutzern und Zugriffsrechten<br />
- Unterstützt die verteilte Transaktionsverwaltung<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 26
Zentraler Katalog<br />
Katalogverwaltung III<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 27
Katalogverwaltung IV<br />
Zentralisierter Katalog<br />
• Alle globalen Katalogdaten zentral gespeichert<br />
• Vorteile<br />
- Relativ einfache Realisierung<br />
• Nachteile<br />
- Hoher Kommunikationsaufwand<br />
- Ggf. Leistungs- und Verfügbarkeitsengpass<br />
- Beeinträchtigung der Knotenautonomie<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 28
Replizierter Katalog<br />
Katalogverwaltung V<br />
Rechnerknoten<br />
B<br />
DB-Katalog<br />
Rechnerknoten<br />
A<br />
DB-Katalog<br />
Internet, Intranet,<br />
Extranet<br />
Rechnerknoten<br />
E<br />
DB-Katalog<br />
Rechnerknoten<br />
C<br />
Rechnerknoten<br />
D<br />
DB-Katalog<br />
DB-Katalog<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 29
Katalogverwaltung VI<br />
Replizierter Katalog<br />
• Jeder Knoten besitzt vollständig Kopie der Katalogdaten<br />
• Vorteile<br />
- Lesende Katalogzugriffe sind stets lokal<br />
- Keine Kommunikationsverzögerungen<br />
• Nachteile<br />
- Aufwändige Änderungsoperationen (insb. bei geografisch<br />
verteilten Systemen)<br />
- Datenschutzrechtlich bedenklich<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 30
Mehrfachkataloge<br />
Katalogverwaltung VII<br />
Cluster – Ort C<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 31
Katalogverwaltung VIII<br />
Mehrfachkataloge<br />
• Partitionieren der Rechner in mehrere Cluster<br />
• Je Cluster enthält ein Knoten den vollst. glob. Katalog<br />
• Vorteile<br />
- Kompromiss aus zentralis. und replizierten Katalog<br />
- Reduzierter Änderungsaufwand<br />
• Nachteile<br />
- Kommunikation bei jedem Zugriff auf globale Katalogdaten<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 32
Partitionierter Katalog<br />
Katalogverwaltung IX<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 33
Katalogverwaltung X<br />
Partitionierter Katalog<br />
• Globaler Katalog wird unter allen Rechnern partitioniert<br />
gespeichert<br />
• Globales konzeptuelles Schema ergibt sich als<br />
Vereinigung der lokalen konzeptuellen Schema<br />
• Vorteile<br />
- Hoher Grad an Knotenautonomie<br />
• Nachteile<br />
- Kommunikation bei nicht-lokalen Daten<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 34
Entwurf <strong>verteilter</strong><br />
Datenbanken<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 35
Entwurf von VDBMS<br />
Quelle: Heuer, A. et al:<br />
Datenbanken kompakt,<br />
mitp-Verlag, Bonn 2003<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 36
Entwurf von VDBMS<br />
• Fragmentierungsschema<br />
- Logisch zusammengehörige Informationsmengen in<br />
(weitgehend) disjunkte Fragmente zerlegen<br />
- Zerlegung erfolgt auf Basis des Zugriffsverhaltens<br />
aus den Anwendungen heraus<br />
- Daten mit ähnlichen Zugriffsmuster in einem<br />
Fragment zusammenfassen<br />
• Zuordnungsschema (Allokation)<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 37
Fragmentierung I<br />
• Einfachster Fall im relationalen DBS<br />
- Ganze Relationen als kleinste Verteilungsgranulate<br />
- Vorteile:<br />
• keine explizite Fragmentierung<br />
• Vereinfachung des Allokationsproblems<br />
• Geringe Kommunikationskosten bei Oper. auf eine Relation<br />
• Einfache Gewährleistung von Integritätsbedingungen<br />
• Massive Nachteile hinsichtlich Lastverteilung, Nutzung<br />
von Lokalität, Parallelverarbeitung und Verarbeitungsumfang<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 38
Arten der Fragmentierung<br />
• Horizontale Fragmentierung<br />
- Logisch zusammengehörige Informationsmengen in<br />
(weitgehend) disjunkte Tupelmengen zerlegen<br />
• Vertikale Fragmentierung<br />
- Zusammenfassen von Attributen mit gleichen Zugriffsmustern<br />
- Vertikale Zerlegung der Relation durch Ausführung von<br />
Projektionen<br />
• Kombinierte Fragmentierung<br />
- Anwendung der horizontalen und vertikalen Fragmentierung auf<br />
die selbe Relation<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 39
Arten der Fragmentierung<br />
• Horizontale<br />
Fragmentierung<br />
• Vertikale<br />
Fragmentierung<br />
DB 1 DB 2 DB 3<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 40
Arten der Fragmentierung<br />
• Zuerst horizontale,<br />
dann vertikale<br />
Fragmentierung<br />
Fragm.<br />
2<br />
Fragm.<br />
3<br />
Fragm.<br />
2<br />
Fragm.<br />
3<br />
• Zuerst vertikale, dann<br />
horizontale<br />
Fragmentierung<br />
Fragm. 2<br />
Fragm. 3<br />
DB 2<br />
DB 3<br />
DB 1<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 41
Regeln für die Fragmentierung<br />
• Vollständigkeit<br />
- Jedes Datenelement (Tupel, Attributswert) der globalen Relation muss<br />
in wenigstens einem Fragment enthalten sein.<br />
• Rekonstruierbarkeit<br />
- Zerlegung muss verlustfrei sein<br />
- Globale Relation muss aus den Fragmenten vollständig rekonstruiert<br />
werden können<br />
• Disjunktheit<br />
- Fragmente sollten möglichst disjunkt sein<br />
- Bei vertikaler Fragmentierung kann die Disjunktheit aufgrund der<br />
Rekonstruierbarkeit nicht vollständig gewährleistet werden<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 42
Beispiel für Fragmentierung I<br />
• Ausgangsbasis:<br />
- abstrakte Relation R mit Tupeln r 1 , …, r 7<br />
- Anwendungen A 1 , A 2 , A 3<br />
• Anwendung A 1 greift aufr 1 ,r 2 ,r 3 zu<br />
• Anwendung A 2 greift aufr 4 ,r 5 ,r 6 ,r 7 zu<br />
• Anwendung A 3 greift auf r 4 ,r 5<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 43
Beispiel für Fragmentierung II<br />
Horizontale Fragmentierung von Relationen in<br />
disjunkte Tupelmengen<br />
Resultierende Fragmente:<br />
• R 1 = {r 1 ,r 2 ,r 3 } wegenAnwendung A 1<br />
• R 2 = {r 6 ,r 7 } wegenAnwendung A 2<br />
• R 3 = {r 4 ,r 5 } wegenAnwendung A 2 und A 3<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 44
Beispiel für Fragmentierung III<br />
KNR NAME GEBDAT NL<br />
K2<br />
K4<br />
K3<br />
K1<br />
K5<br />
Maier<br />
Müller<br />
Schmidt<br />
Weber<br />
Walter<br />
04.02.1963<br />
08.02.1973<br />
14.04.1967<br />
27.02.1993<br />
02.12.1943<br />
B<br />
FL<br />
FL<br />
B<br />
DD<br />
Globale Relation<br />
KUNDE<br />
V<br />
V<br />
KNR<br />
K2<br />
K4<br />
K3<br />
K1<br />
K5<br />
NAME<br />
Maier<br />
Müller<br />
Schmidt<br />
Weber<br />
Walter<br />
NL<br />
B<br />
FL<br />
FL<br />
B<br />
DD<br />
KNR<br />
K2<br />
K4<br />
K3<br />
K1<br />
K5<br />
GEBDAT<br />
04.02.1963<br />
08.02.1973<br />
14.04.1967<br />
27.02.1993<br />
02.12.1943<br />
KUNDE 2 =<br />
π KNR, GEBDAT (KUNDE)<br />
KUNDE 1 =<br />
π KNR, NAME, NL (KUNDE)<br />
H<br />
H<br />
KNR<br />
K5<br />
NAME<br />
Walter<br />
NL<br />
DD<br />
KUNDE 11 =<br />
σ NL=’DD’ (KUNDE 1 )<br />
H<br />
KNR NAME NL<br />
K2 Maier B<br />
K1 Weber B<br />
KUNDE 12 =<br />
σ NL=’B’ (KUNDE 1 )<br />
KNR NAME NL<br />
K4 Müller FL<br />
K3 Schmidt FL<br />
KUNDE 13 =<br />
σ NL=’FL’ (KUNDE 1 )<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 45
Arten von Allokationen<br />
• Redundanzfreie Allokation<br />
- Jedes Fragment ist genau einer Station zugeordnet<br />
- N:1 Zuordnung zu von Fragmenten zu Stationen<br />
• Allokation mit Replikation<br />
- Fragmente sind zum Teil repliziert und mehreren<br />
Stationen zugeordnet<br />
- N:M Zuordnung von Fragmenten zu Stationen<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 46
Fragmentierung und Allokation<br />
Quelle:<br />
Fragmentierung und Allokation<br />
nach Ceri und Pelagati,<br />
aus Kemper, A.;Eickler, A.:<br />
<strong>Datenbanksysteme</strong>, Oldenbourg-Verlag<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 47
Transparenz im VDBS<br />
”Unter Transparenz versteht man den Grad an der<br />
Unabhängigkeit, den ein VDBMS den Benutzern beim<br />
Zugriff auf verteilte Daten vermittelt“<br />
Quelle: Kemper A. / Eickler A. (2004), <strong>Datenbanksysteme</strong>, 5. Aufl.,<br />
München 2004<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 48
Transparenz im VDBS<br />
• Fragmentierungstransparenz<br />
- Single-System-Image<br />
- Nutzer kennt potentielle Fragmente und Allokationen nicht<br />
• Allokationstransparenz<br />
- Nutzer muss den Ort der Speicherung nicht kennen<br />
- Nutzer muss aber die ggf. vorhanden Fragmente kennen<br />
• Lokale Schema-Transparenz<br />
- Gleiche Datenbank-Schemata<br />
- Kenntnisse zur Fragmentierung, Allokation und Replikation<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 49
Transaktionen in verteilten<br />
Datenbanken<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 50
Struktur <strong>verteilter</strong> Transaktionen<br />
• Transaktion als Folge von DB-Operationen<br />
- BOT – begin of transaction<br />
- EOT – end of transaction<br />
- Abbruch laufender Transaktionen durch rollback-Anweisung<br />
• Transaktionen bei verteilten DBS<br />
- Beteiligung von einem oder mehreren Rechnerknoten<br />
- Erhöhte Fehlermöglichkeiten<br />
• Verbindungsausfall<br />
• Nachrichtenverlust<br />
• Ausfall von Rechnerknoten<br />
• Transaktionstransparenz<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 51
Komponenten bei<br />
verteilten Transaktionen<br />
• Heimat- bzw. Koordinator-Knoten (Start der TA – BOT)<br />
• Ressourcen-Manager<br />
- Zugriffe auf DBS oder Dateisysteme<br />
- Synchronisation & Logging<br />
• Transaction Manager<br />
- Verwaltung und Koordination<br />
- Commit-Behandlung<br />
• Bedarf an Transaktionskennungen<br />
• Transaktionsbaum<br />
- Primärtransaktion (am Heimatknoten ausgeführte Teiltransaktion)<br />
- Subtransaktion (Teiltransaktion im Rahmen einer globalen Transaktion)<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 52
Commit-Behandlungen<br />
TM 1<br />
TM 2<br />
TM i<br />
Lineare Commit-Struktur<br />
TM n<br />
Zentralisierte Commit-Struktur<br />
Hierarchische Commit-Struktur<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 53
Zwei Phasen Sperrprotokoll<br />
(2PC-Protokoll)<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 54
2PC – Prepare (TA Vorbereitung)<br />
Alle an der Transaktion beteiligten Server werden über<br />
den Status ihrer Teiltransaktion befragt. Ist eine<br />
Teiltransaktion „im Prinzip fertig“, wird sie in den<br />
Prepared-Zustand versetzt. Dieser Zustand ist ein<br />
permanenter Zustand, der nur durch das 2PC-Protokoll<br />
mit commit oder rollback beendet werden kann. Eine<br />
solche Transaktion überlebt auch ein Instanz-Recovery.<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 55
2PC – Commit (TA Abschluss)<br />
Die Commit-Phase kann nur eingeleitet werden, wenn<br />
alle beteiligten Teiltransaktionen den Übergang in den<br />
Prepared-Zustand gemeldet haben. Kann nur eine<br />
beteiligte Transaktion diesen Zustand nicht melden, wird<br />
die gesamte verteilte Transaktion, d.h. alle<br />
Teiltransaktionen, zurückgerollt. Im anderen Fall wird<br />
das Commit für die globale Transaktion durchgeführt.<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 56
Potentielle Problembereiche des<br />
2PC – Commit Protokolls<br />
• Basisprotokoll erfordert pro Agent 4 Nachrichten<br />
bei N Knoten 4*(N-1)<br />
• Jeweils zwei synchrone Schreibvorgänge (außer Ende-Satz) in die<br />
Log-Datei für den Koordinator und jeden Agenten<br />
synchrone Verarbeitung impliziert ggf. Wartezeiten<br />
• Hohe Abhängigkeit der Agenten vom Koordinator (Problem:<br />
Koordinatorausfall)<br />
Performanceprobleme<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 57
Verteilte Datenbanken mit Oracle<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 58
Verteilte DB mit Oracle<br />
• Oracle Netzwerkunterstützung<br />
- Netzwerktransparenz<br />
- Protokoll-Transparenz<br />
- Topologie-Transaprenz<br />
- Optimierung genutzter Netzwerkverbindungen<br />
• Oracle RDBMS<br />
- Verteilungstransparenz (bezüglich der Datenquellen)<br />
- Transaktionstransparenz<br />
- Recovery-Transparenz<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 59
Verteilte DB mit Oracle<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 60
Verteilte DB mit Oracle<br />
SQL* Net<br />
• Programmierinterface für alle Oracle-Anwendungen<br />
• Aufgabenstellungen:<br />
- Verbindungsauf- und Verbindungsabbau<br />
- Benachrichtigungsdienst bei Problemen (z.B. Verbindungsausfall)<br />
Oracle* TNS<br />
• Kern des Oracle Netzwerkes<br />
- Auflösung von Zieladressen (Rechnernamen und DB-Instanz)<br />
- Genutzte Netzwerkrouten (Oracle* Navigator)<br />
- Ggf. benötigte Konvertierungen<br />
- Fehlerbehandlung<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 61
Verteilte DB mit Oracle<br />
Weitere Komponenten<br />
• Oracle* MPI (MultiProtokoll Interchange)<br />
- Einsatz in heterogenen Netzwerkumgebungen<br />
- Kommunikation zwischen verschiedenen Anwendungen<br />
- Verbindung unterschiedlicher Netzwerksysteme<br />
• Internet TCP/IP,<br />
• IBM Mainframe LU6.2<br />
• DECNet<br />
- Finden der kostengünstigsten Verbindung (via Oracle* Navigator)<br />
• Oracles Gateway-Strategie zur sanften Migration<br />
- Zugriff auf „non“ Oracle Datenbanken (z.B. IBM DB2)<br />
- Zugriff von Datenbanken anderer Hersteller auf Oracle<br />
- Datenreplikation in heterogenen Datenbanken<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 62
Oracle Gateway -Zugriffsformen<br />
Anwendungen greifen auf Fremd-DBS quasi wie auf eine Oracle-DB zu<br />
Beim Gateway-Einsatz sind drei Zugriffsformen zu unterscheiden:<br />
• Oracle-Tools können i.a. direkt über ein SQL*CONNECT-Gateway<br />
auf SQL-DBS anderer Hersteller zugreifen, also ohne Involvierung<br />
eines Oracle-DBS. SQL*CONNECT erzeugt dabei dyn. SQL-<br />
Anweisungen für das Fremd-DBS.<br />
• Ein indirekter Zugriff liegt vor, wenn ein Oracle-Werkzeug mit einem<br />
Oracle-DBS zusammenarbeitet, von dem aus über DB-Links auf<br />
externe DB zugegriffen wird.<br />
- Ausführung von lesenden Zugriffen auf die Fremd-Datenbank<br />
- Zugriff auch auf nicht-relationale DBS oder Dateisysteme möglich<br />
• Direkter Zugriff auf mehrere Datenbanken ist möglich über<br />
Anwendungsprogramme mit eingebettetem SQL-Anweisungen.<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 63
Verteilte DB mit Oracle<br />
• Ein konfigurierter Datenbank-Link bietet den Zugriff auf alle Schema-<br />
Objekte des entfernten DB-Servers<br />
- Tabellen<br />
- Views<br />
- Stored Procedures (gespeicherte Prozeduren)<br />
• Gültigkeit eines Datenbank Links<br />
- Public: ohne Einschränkungen verfügbarer DB-Link<br />
- Private: DB-Link mit eingeschränkten Benutzerkreis<br />
• Shared Database Links (Reduktion benötigter Service Connections)<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 64
Verteilte DB mit Oracle<br />
Oracle Datenbank-Links<br />
• Einrichtung von Datenbank-Links durch den DBA<br />
• Datenbank Links zwischen einer lokalen Datenbank in Berlin und<br />
Datenbanken in Berlin und Magdburg<br />
CREATE PUBLIC DATABASE LINK BERLIN<br />
CONNECT TO B_UNIX;<br />
CREATE PUBLIC DATABASE LINK MAGDEBURG<br />
CONNECT TO MD_VMS;<br />
• Vorraussetzung: Eingetragene Nutzer bei den Datenbanken in Berlin<br />
(B_UNIX) bzw. Magdburg (MD_VMS).<br />
Quelle: Burleson, D. K.: Oracle Datenbank Anwendung, Thomson Publ., 1997<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 65
Verteilte DB mit Oracle<br />
Aufruf zur Erstellung eines Datenbank-<br />
Links unter dem DBMS Oracle<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 66
Verteilte DB mit Oracle<br />
Oracle Enterprise Manager<br />
• Interaktive Erstellung<br />
der Datenbank-Links<br />
• Bezeichnung des<br />
Datenbank-Link<br />
• Form der Anmeldung<br />
auf dem entfernten<br />
Datenbanksystem<br />
• Dienstname der<br />
entfernten Datenbank<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 67
Verteilte DB mit Oracle<br />
Verwendung des Datenbank-Links 1<br />
SELECT A.NAME, B.QUANTITY_ORDERED<br />
FROM CUSTOMER@BERLIN A,<br />
ORDERLINE@MAGDEBURG B<br />
Quelle: Burleson, D. K.: Oracle Datenbank Anwendung, Thomson Publ., 1997<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 68
Verteilte DB mit Oracle<br />
Verwendung des Datenbank-Links 2<br />
SELECT CUSTOMER.NAME, ORDER.ORDER_DATE,<br />
ORDERLINE.QUANTITY_ORDERED<br />
FROM CUSTOMER@BERLIN, ORDER,<br />
ORDERLINE@MAGDEBURG<br />
WHERE<br />
CUSTOMER.CUST_NUMBER = ORDER.CUSTOMER_NUMBER<br />
AND<br />
ORDER.ORDER_NUMBER = ORDERLINE.ORDER_NUMBER;<br />
Quelle: Burleson, D. K.: Oracle Datenbank Anwendung, Thomson Publ., 1997<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 69
Verteilte DB mit Oracle<br />
Transparenz durch Einsatz von Views I:<br />
• Definition einer View<br />
CREATE VIEW TABELLE AS<br />
SELECT * FROM TAB@BERLIN;<br />
• SQL-Abfragen ohne Kenntnis des Datenbank-Links<br />
UPDATE TABELLE<br />
SET PREIS = PREIS * 1,96<br />
WHERE WAEHRUNG = DM;<br />
• Einschränkung der Zugangsrechte über selektive Vergabe von<br />
Rechten für die Nutzer B_UNIX bzw. MD_VMS<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 70
Verteilte DB mit Oracle<br />
Transparenz durch Einsatz von Views II (Interaktionen):<br />
• Auflösen der View Definition für TABELLE über das DD<br />
• Identifizierung eines DB-Links hinter der View-Definition<br />
• Auflösen des DB-Link-Namen und der TNS-Adresse beim Zielrechner<br />
• Verbindungsaufbau zur Remote-Datenbank<br />
• SQL-Befehl an die Zieldatenbank senden<br />
• Ziel-Datenbank führt den SQL-Befehl aus<br />
• Ergebnis-Rückgabe an den lokalen DB-Server<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 71
Verteilte DB mit Oracle<br />
Security-Aspekte:<br />
„Über Datenbank-Links (DB-Links) besteht die Möglichkeit, von einer<br />
Datenbank innerhalb eines DBMS aus auf die Daten einer anderen<br />
Datenbank, gegebenenfalls in einem anderen DBMS, zuzugreifen.<br />
Um einen angemessenen Schutz der Daten zu gewährleisten, sollte<br />
diese Technik nur im Rahmen eines entsprechenden<br />
Berechtigungskonzepts angewendet werden. In diesem Konzept<br />
muss unter anderem die Kontrolle der Berechtigungen eines<br />
Benutzers bei der Verwendung von DB-Links geregelt werden.“<br />
Quelle: M 4.71 Restriktive Handhabung von Datenbank-Links Bundesamt für Sicherheit in der<br />
Informationstechnik<br />
SoSe 2009<br />
Verteilte DBS<br />
Prof. Dr. Andreas Schmietendorf 72
![[UNBEGRENZTE MÖGLICHKEITEN?] - Userpage](https://img.yumpu.com/22343335/1/184x260/unbegrenzte-moglichkeiten-userpage.jpg?quality=85)
Change language