Verteilte Datenbank- und Informationssysteme

Transkript

1 Verteilte Datenbank- und Informationssysteme Vorlesung im Wintersemester 2013 (Abschnitt Besonderheiten verteilter Datenbanksysteme) Prof. Dr. Andreas Schmietendorf 1

2 Inhalt des Parts Grundprinzipien Regeln für verteilte DBS Architektur verteilter Datenbanken Verteilte Transaktionen 2PC Verteilungsoptionen bei Oracle Prof. Dr. Andreas Schmietendorf 2

3 Übersicht und Einführung Prof. Dr. Andreas Schmietendorf 3

4 Verteilte Verarbeitung I Prof. Dr. Andreas Schmietendorf 4

5 Verteilte Verarbeitung II Applikation bzw. Nutzer koordiniert den Verbindungsaufbau zur DB Die Standorte der Datenbank-Server im Netz müssen bekannt sein Zwischen den DB bestehen keine von der Anwendung unabhängige Beziehungen Es können keine DB-übergreifenden SQL-Anweisungen ausgeführt werden Eine DB-übergreifende Transaktionssicherung wird durch das DBMS nicht gewährleistet Prof. Dr. Andreas Schmietendorf 5

6 Grundprinzip verteilte Datenbank Grundprinzip verteilter Datenbanken ist die Verteilungstransparenz. Ein verteiltes DBS muss sich dem Anwender gegenüber genauso verhalten wie ein nicht verteiltes. Prof. Dr. Andreas Schmietendorf 6

7 Definition verteilte Datenbank Eine verteilte Datenbank ist ein logisch zusammengehörender Datenbestand beschrieben in einem globalen Schema -, der physisch auf mehreren Knoten (Rechner) verteilt ist und mit einem verteilten Datenbankmanagementsystem (kurz VDBMS) oder auch distributed DBMS (kurz DDBMS) verwaltet wird. Prof. Dr. Andreas Schmietendorf 7

8 Grobstruktur eines VDBMS Rechnerknoten B Rechnerknoten A Nur eine Sicht auf die Daten Internet, Intranet, Extranet Rechnerknoten E Rechnerknoten C Rechnerknoten D Prof. Dr. Andreas Schmietendorf 8

9 Verteilte Datenbank Ausgangspunkt: relationales Modell Spezifikation der Datenobjekte des Bezugsbereichs im Rahmen eines relationalen Modells Das DBMS bietet die Möglichkeit mehrere räumlich im Netz verteilte DB zu einer Sicht zusammenzufassen Vorteile/Ziele Nutzer/Anwendung muss nichts von der Verteilung der DB im Netz wissen (Ortstransparenz) Möglichkeit der Ausführung DB-übergreifender SQL- Abfragen und Transaktionen Prof. Dr. Andreas Schmietendorf 9

10 Anforderungen an verteilte Datenbanken Brainstoming Siehe auch: Prof. Dr. Andreas Schmietendorf 10

11 Zwölf Regeln für verteilte DBS I Lokale Autonomie - Jeder Rechner sollte maximale Kontrolle über eigene Daten haben - Zugriff auf diese Daten sollte nicht von anderen Rechnern abhängen Keine Abhängigkeit von zentralen Systemfunktionen - DB-Verarbeitung sollte nicht von zentralen Systemfunktionen abhängen - Gefahr potentieller Leistungsengpässe durch zentrale Systemkomponenten Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-Datenbanksysteme, Addison-Wesley, 1994 Prof. Dr. Andreas Schmietendorf 11

12 Zwölf Regeln für verteilte DBS II Hohe Verfügbarkeit - Unanfälligkeit gegen ggf. auftretende Fehler wie z.b. dem Ausfall eines Rechnerknotens - Möglichkeiten einer Konfigurationsänderung während des laufenden Betriebs (z.b. neue SW oder HW) Ortstransparenz - Verbergen der physischen Lokation von Datenbankobjekten gegenüber dem Benutzer - Der Datenzugriff auf entfernte Daten sollte in gleicher Weise erfolgen, wie der auf lokale Objekte Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-Datenbanksysteme, Addison-Wesley, 1994 Prof. Dr. Andreas Schmietendorf 12

13 Zwölf Regeln für verteilte DBS III Fragmentierungstransparenz - Eine Relation der DB sollte verteilt an mehreren Knoten gespeichert werden können - Die zugrunde liegende Zerlegung der Relation sollte für den Datenbankbenutzer transparent sein Replikationstransparenz - Die replizierte Speicherung von Teilen der Datenbank sollte für den Benutzer unsichtbar bleiben - Die Wartung der Redundanz obliegt ausschließlich der Datenbanksoftware Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-Datenbanksysteme, Addison-Wesley, 1994 Prof. Dr. Andreas Schmietendorf 13

14 Zwölf Regeln für verteilte DBS IV Verteilte Anfragebearbeitung - Innerhalb einer DB-Operation sollte auf Daten mehrerer Rechner zugegriffen werden können - Zur effizienten Bearbeitung von DB-Anfragen sind durch das VDBMS geeignete Techniken bereitzustellen (Query Optimizer) Verteilte Transaktionsverarbeitung (TA-Transparenz) - ACID-Eigenschaften sind auch bei verteilter Bearbeitung einzuhalten - Bereitstellung entsprechender Recovery- und Synchronisationstechniken (verteiltes 2 Phasen Sperrprotokoll) Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-Datenbanksysteme, Addison-Wesley, 1994 Prof. Dr. Andreas Schmietendorf 14

15 Zwölf Regeln für verteilte DBS V Hardware-Unabhängigkeit - Die Datenbank-Verarbeitung sollte auf unterschiedlichen Hardwareplattformen möglich sein - Sämtliche Hardwareeigenschaften sollten gegenüber dem Datenbankbenutzer verborgen bleiben Betriebssystemunabhängigkeit - Die Datenbankbenutzung sollte unabhängig von den eingesetzten Betriebssystemen sein - Verteilte Datenbankmanagementsysteme sollten unterschiedliche Betriebssystemplattformen unterstützen Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-Datenbanksysteme, Addison-Wesley, 1994 Prof. Dr. Andreas Schmietendorf 15

16 Zwölf Regeln für verteilte DBS VI Netzwerkunabhängigkeit - Verwendete Netzwerke und darauf aufsetzende Kommunikationsprotokolle sollten ohne Einfluss auf die Datenbankverarbeitung leiben. Datenbanksystemunabhängigkeit - Es sollte möglich sein, unterschiedliche (Heterogene) Datenbanksysteme an den verschiedenen Rechnern einzusetzen, solange sie eine einheitliche Benutzerschnittstelle (z.b. gemeinsame SQL-Version) anbieten. Quelle: Date, C. J.: in Rahm, E.: Mehrrechner-Datenbanksysteme, Addison-Wesley, 1994 Prof. Dr. Andreas Schmietendorf 16

17 Transaktionstransparenz Bei einer verteilten Transaktion wird auf Datenelemente unterschiedlicher DB, welche auf verschiedenen Rechnerknoten verteilt sind, zugegriffen. ACID-Bedingungen sind im Rahmen eines VDBMS in gleicher Weise einzuhalten wie in einem zentralen DBMS Der Entwickler einer Anwendung sollte eine verteilte TA in gleicher Weise nutzen wie eine lokale TA Auch implizite TA (ausgelöst durch Trigger) sollten von der Transaktionstransparenz profitieren Prof. Dr. Andreas Schmietendorf 17

18 Leistungstransparenz Verteilung von Datenbankobjekten zwecks Erhöhung des Leistungsund Ausfallverhaltens im Gesamtsystem - Verteilte Verarbeitung von Anfragen und Transaktionen soll trotz des Kommunikations-Overheads mit der gleichen Performance erfolgen wie ohne Verteilung - Im Falle replizierter Datenobjekte (kontrollierte Redundanz) sollten Leistungsengpässe eines Knoten durch Knoten mit weniger Last aufgefangen werden können. (Load-Balancing) - Bei paralleler Bearbeitung eingehender Anfragen wird eine Verbesserung der Bearbeitungszeiten angestrebt In Anlehnung an - Rahm, E.: Mehrrechner-Datenbanksysteme, Addison-Wesley, 1994 Prof. Dr. Andreas Schmietendorf 18

19 Architektur verteilter Datenbanken Prof. Dr. Andreas Schmietendorf 19

20 4-Ebenen Architektur für verteilte Datenbanksysteme In Anlehnung an : Conrad, S.: Förderierte Datenbanksysteme, Springer-Verlag, 1997 Prof. Dr. Andreas Schmietendorf 20

21 Externes Schemata im VDBMS Repräsentieren Sichten der Benutzer und Anwenderprogramme (vergleichbar zum zentralen Datenbanksystem) Für Benutzer bzw. Benutzergruppen werden jeweils eigene externe Schemata angelegt Das externe Schemata ist in Art und Funktion für verteilte und zentrale Datenbanksysteme nicht unterscheidbar Für den Benutzer sollte es keinen Unterschied machen, ob er mit einer zentralen oder verteilten Datenbank arbeitet. In der Praxis kann es ggf. dennoch zu kleinen Unterschieden kommen (insbesondere bei heterogenen DBMS) Prof. Dr. Andreas Schmietendorf 21

22 Globales konzeptionelles Schema im VDBMS Beschreibung der durch das DBS zu verwaltenden Daten in ihrer Gesamtheit Abstrakte Beschreibung ohne Berücksichtigung konkreter Implementierungsdetails Ziel beim konzeptionellen Schema im VDBMS ist die Integration der verschiedenen externen Benutzersichten Im verteilten Datenbanksystemen ist das konzeptionelle Schema gleichzeitig die Zusammenfassung aller lokalen konzeptionellen Schemata (Vereinigung) Prof. Dr. Andreas Schmietendorf 22

23 Lokale konzeptionelle Schemata im VDBMS Die lokalen konzeptionellen Schemata ergeben sich aus der Definition der Datenverteilung, die im globalen Verteilungsschema festgelegt sind. (Ausschnitt aus dem globalen konzeptionellen Schema) Enthalten sind folgende Angaben: - Informationen zur auf dem Knoten hinterlegten Fragementen - Allokation und Replikation von Relationsfragmenten Bei fehlender Replikation sind die lokalen konzeptionellen Schemata echte Teilmengen der globalen konzeptionellen Schemata. Die ggf. notwendige Propagierung von Änderungen des lokalen konzeptionellen Schema ist abhängig von der gewählten Katalogarchitektur. Prof. Dr. Andreas Schmietendorf 23

24 Lokale interne Schemata im VDBMS Hier gibt es keine Unterschiede zu den internen Schemata einer zentralen Datenbank. Im Sinne der Knotenautonomie sind Zugriffspfade und Speicherstrukturen auf lokale Erfordernisse abzustimmen. Das interne Schema ist abhängig vom verwendeten Basissystem und von der unterstützten Sprachschnittstelle. Prof. Dr. Andreas Schmietendorf 24

25 Entwurf verteilter Datenbanken Prof. Dr. Andreas Schmietendorf 25

26 Entwurf von VDBMS Quelle: Heuer, A. et al: Datenbanken kompakt, mitp-verlag, Bonn 2003 Prof. Dr. Andreas Schmietendorf 26

27 Entwurf von VDBMS Fragmentierungsschema - Logisch zusammengehörige Informationsmengen in (weitgehend) disjunkte Fragmente zerlegen - Zerlegung erfolgt auf Basis des Zugriffsverhaltens aus den Anwendungen heraus - Daten mit ähnlichen Zugriffsmuster in einem Fragment zusammenfassen Zuordnungsschema (Allokation) Prof. Dr. Andreas Schmietendorf 27

28 Fragmentierung I Einfachster Fall im relationalen DBS - Ganze Relationen als kleinste Verteilungsgranulate - Vorteile: keine explizite Fragmentierung Vereinfachung des Allokationsproblems Geringe Kommunikationskosten bei Oper. auf eine Relation Einfache Gewährleistung von Integritätsbedingungen Massive Nachteile hinsichtlich Lastverteilung, Nutzung von Lokalität, Parallelverarbeitung und Verarbeitungsumfang Prof. Dr. Andreas Schmietendorf 28

29 Arten der Fragmentierung Horizontale Fragmentierung - Logisch zusammengehörige Informationsmengen in (weitgehend) disjunkte Tupelmengen zerlegen Vertikale Fragmentierung - Zusammenfassen von Attributen mit gleichen Zugriffsmustern - Vertikale Zerlegung der Relation durch Ausführung von Projektionen Kombinierte Fragmentierung - Anwendung der horizontalen und vertikalen Fragmentierung auf die selbe Relation Prof. Dr. Andreas Schmietendorf 29

30 Arten der Fragmentierung Horizontale Fragmentierung Vertikale Fragmentierung DB 1 DB 2 DB 3 Prof. Dr. Andreas Schmietendorf 30

31 Arten der Fragmentierung Zuerst horizontale, dann vertikale Fragmentierung Fragm. 2 Fragm. 3 Fragm. 2 Fragm. 3 Zuerst vertikale, dann horizontale Fragmentierung Fragm. 2 Fragm. 3 DB 2 DB 3 DB 1 Prof. Dr. Andreas Schmietendorf 31

32 Regeln für die Fragmentierung Vollständigkeit - Jedes Datenelement (Tupel, Attributswert) der globalen Relation muss in wenigstens einem Fragment enthalten sein. Rekonstruierbarkeit - Zerlegung muss verlustfrei sein - Globale Relation muss aus den Fragmenten vollständig rekonstruiert werden können Disjunktheit - Fragmente sollten möglichst disjunkt sein - Bei vertikaler Fragmentierung kann die Disjunktheit aufgrund der Rekonstruierbarkeit nicht vollständig gewährleistet werden Prof. Dr. Andreas Schmietendorf 32

33 Beispiel für Fragmentierung I Ausgangsbasis: - abstrakte Relation R mit Tupeln r 1,, r 7 - Anwendungen A 1, A 2, A 3 Anwendung A 1 greift aufr 1,r 2,r 3 zu Anwendung A 2 greift aufr 4,r 5,r 6,r 7 zu Anwendung A 3 greift auf r 4,r 5 Prof. Dr. Andreas Schmietendorf 33

34 Beispiel für Fragmentierung II Horizontale Fragmentierung von Relationen in disjunkte Tupelmengen Resultierende Fragmente: R 1 = {r 1,r 2,r 3 } wegenanwendung A 1 R 2 = {r 6,r 7 } wegenanwendung A 2 R 3 = {r 4,r 5 } wegenanwendung A 2 und A 3 Prof. Dr. Andreas Schmietendorf 34

35 Beispiel für Fragmentierung III KNR NAME GEBDAT NL K2 K4 K3 K1 K5 Maier Müller Schmidt Weber Walter B FL FL B DD Globale Relation KUNDE V V KNR K2 K4 K3 K1 K5 NAME Maier Müller Schmidt Weber Walter NL B FL FL B DD KNR K2 K4 K3 K1 K5 GEBDAT KUNDE 2 = π KNR, GEBDAT (KUNDE) KUNDE 1 = π KNR, NAME, NL (KUNDE) H H KNR K5 NAME Walter NL DD KUNDE 11 = σ NL= DD (KUNDE 1 ) H KNR NAME NL K2 Maier B K1 Weber B KUNDE 12 = σ NL= B (KUNDE 1 ) KNR NAME NL K4 Müller FL K3 Schmidt FL KUNDE 13 = σ NL= FL (KUNDE 1 ) Prof. Dr. Andreas Schmietendorf 35

36 Arten von Allokationen Redundanzfreie Allokation - Jedes Fragment ist genau einer Station zugeordnet - N:1 Zuordnung zu von Fragmenten zu Stationen Allokation mit Replikation - Fragmente sind zum Teil repliziert und mehreren Stationen zugeordnet - N:M Zuordnung von Fragmenten zu Stationen Prof. Dr. Andreas Schmietendorf 36

37 Fragmentierung und Allokation Quelle: Fragmentierung und Allokation nach Ceri und Pelagati, aus Kemper, A.;Eickler, A.: Datenbanksysteme, Oldenbourg-Verlag Prof. Dr. Andreas Schmietendorf 37

38 Transparenz im VDBS Unter Transparenz versteht man den Grad an der Unabhängigkeit, den ein VDBMS den Benutzern beim Zugriff auf verteilte Daten vermittelt Quelle: Kemper A. / Eickler A. (2004), Datenbanksysteme, 5. Aufl., München 2004 Prof. Dr. Andreas Schmietendorf 38

39 Transparenz im VDBS Fragmentierungstransparenz - Single-System-Image - Nutzer kennt potentielle Fragmente und Allokationen nicht Allokationstransparenz - Nutzer muss den Ort der Speicherung nicht kennen - Nutzer muss aber die ggf. vorhanden Fragmente kennen Lokale Schema-Transparenz - Gleiche Datenbank-Schemata - Kenntnisse zur Fragmentierung, Allokation und Replikation Prof. Dr. Andreas Schmietendorf 39

40 Transaktionen in verteilten Datenbanken Prof. Dr. Andreas Schmietendorf 40

41 Struktur verteilter Transaktionen Transaktion als Folge von DB-Operationen - BOT begin of transaction - EOT end of transaction - Abbruch laufender Transaktionen durch rollback-anweisung Transaktionen bei verteilten DBS - Beteiligung von einem oder mehreren Rechnerknoten - Erhöhte Fehlermöglichkeiten Verbindungsausfall Nachrichtenverlust Ausfall von Rechnerknoten Transaktionstransparenz Prof. Dr. Andreas Schmietendorf 41

42 Komponenten bei verteilten Transaktionen Heimat- bzw. Koordinator-Knoten (Start der TA BOT) Ressourcen-Manager - Zugriffe auf DBS oder Dateisysteme - Synchronisation & Logging Transaction Manager - Verwaltung und Koordination - Commit-Behandlung Bedarf an Transaktionskennungen Transaktionsbaum - Primärtransaktion (am Heimatknoten ausgeführte Teiltransaktion) - Subtransaktion (Teiltransaktion im Rahmen einer globalen Transaktion) Prof. Dr. Andreas Schmietendorf 42

43 Commit-Behandlungen TM 2 Lineare Commit-Struktur TM 1 TM i TM n Zentralisierte Commit-Struktur Hierarchische Commit-Struktur Prof. Dr. Andreas Schmietendorf 43

44 Zwei Phasen Sperrprotokoll (2PC-Protokoll) Prof. Dr. Andreas Schmietendorf 44

45 2PC Prepare (TA Vorbereitung) Alle an der Transaktion beteiligten Server werden über den Status ihrer Teiltransaktion befragt. Ist eine Teiltransaktion im Prinzip fertig, wird sie in den Prepared-Zustand versetzt. Dieser Zustand ist ein permanenter Zustand, der nur durch das 2PC-Protokoll mit commit oder rollback beendet werden kann. Eine solche Transaktion überlebt auch ein Instanz-Recovery. Prof. Dr. Andreas Schmietendorf 45

46 2PC Commit (TA Abschluss) Die Commit-Phase kann nur eingeleitet werden, wenn alle beteiligten Teiltransaktionen den Übergang in den Prepared-Zustand gemeldet haben. Kann nur eine beteiligte Transaktion diesen Zustand nicht melden, wird die gesamte verteilte Transaktion, d.h. alle Teiltransaktionen, zurückgerollt. Im anderen Fall wird das Commit für die globale Transaktion durchgeführt. Prof. Dr. Andreas Schmietendorf 46

47 Potentielle Problembereiche des 2PC Commit Protokolls Basisprotokoll erfordert pro Agent 4 Nachrichten bei N Knoten 4*(N-1) Jeweils zwei synchrone Schreibvorgänge (außer Ende-Satz) in die Log-Datei für den Koordinator und jeden Agenten synchrone Verarbeitung impliziert ggf. Wartezeiten Hohe Abhängigkeit der Agenten vom Koordinator (Problem: Koordinatorausfall) Performanceprobleme Prof. Dr. Andreas Schmietendorf 47

48 Verteilte Datenbanken mit Oracle Prof. Dr. Andreas Schmietendorf 48

49 Grundlegende Verteiltungsoptionen Replikationsmechanismen - MV Replication mit Snapshots und Triggern - Stream Replication asynchrone Verarbeitung Oracle Streams Advanced Queuing - Oracle-Oracle-Nachrichtenkommunikation - Oracle JMS-Kommunikation - Oracle MQ Series Datenbank-Links Verteilte Transaktionen Prof. Dr. Andreas Schmietendorf 49

50 Verteilte DB mit Oracle Oracle Netzwerkunterstützung - Netzwerktransparenz - Protokoll-Transparenz - Topologie-Transaprenz - Optimierung genutzter Netzwerkverbindungen Oracle RDBMS - Verteilungstransparenz (bezüglich der Datenquellen) - Transaktionstransparenz - Recovery-Transparenz Prof. Dr. Andreas Schmietendorf 50

51 Verteilte DB mit Oracle Prof. Dr. Andreas Schmietendorf 51

52 Verteilte DB mit Oracle SQL* Net Programmierinterface für alle Oracle-Anwendungen Aufgabenstellungen: - Verbindungsauf- und Verbindungsabbau - Benachrichtigungsdienst bei Problemen (z.b. Verbindungsausfall) Oracle* TNS Kern des Oracle Netzwerkes - Auflösung von Zieladressen (Rechnernamen und DB-Instanz) - Genutzte Netzwerkrouten (Oracle* Navigator) - Ggf. benötigte Konvertierungen - Fehlerbehandlung Prof. Dr. Andreas Schmietendorf 52

53 Verteilte DB mit Oracle Weitere Komponenten Oracle* MPI (MultiProtokoll Interchange) - Einsatz in heterogenen Netzwerkumgebungen - Kommunikation zwischen verschiedenen Anwendungen - Verbindung unterschiedlicher Netzwerksysteme Internet TCP/IP, IBM Mainframe LU6.2 DECNet - Finden der kostengünstigsten Verbindung (via Oracle* Navigator) Oracles Gateway-Strategie zur sanften Migration - Zugriff auf non Oracle Datenbanken (z.b. IBM DB2) - Zugriff von Datenbanken anderer Hersteller auf Oracle - Datenreplikation in heterogenen Datenbanken Prof. Dr. Andreas Schmietendorf 53

54 Oracle Gateway -Zugriffsformen Anwendungen greifen auf Fremd-DBS quasi wie auf eine Oracle-DB zu Beim Gateway-Einsatz sind drei Zugriffsformen zu unterscheiden: Oracle-Tools können i.a. direkt über ein SQL*CONNECT-Gateway auf SQL-DBS anderer Hersteller zugreifen, also ohne Involvierung eines Oracle-DBS. SQL*CONNECT erzeugt dabei dyn. SQL- Anweisungen für das Fremd-DBS. Ein indirekter Zugriff liegt vor, wenn ein Oracle-Werkzeug mit einem Oracle-DBS zusammenarbeitet, von dem aus über DB-Links auf externe DB zugegriffen wird. - Ausführung von lesenden Zugriffen auf die Fremd-Datenbank - Zugriff auch auf nicht-relationale DBS oder Dateisysteme möglich Direkter Zugriff auf mehrere Datenbanken ist möglich über Anwendungsprogramme mit eingebettetem SQL-Anweisungen. Prof. Dr. Andreas Schmietendorf 54

55 Oracle Datenbank-Link Prof. Dr. Andreas Schmietendorf 55

56 Verteilte DB mit Oracle Ein konfigurierter Datenbank-Link bietet den Zugriff auf alle Schema- Objekte des entfernten DB-Servers - Tabellen - Views - Stored Procedures (gespeicherte Prozeduren) Gültigkeit eines Datenbank Links - Public: ohne Einschränkungen verfügbarer DB-Link - Private: DB-Link mit eingeschränkten Benutzerkreis Shared Database Links (Reduktion benötigter Service Connections) Prof. Dr. Andreas Schmietendorf 56

57 Verteilte DB mit Oracle Oracle Datenbank-Links Einrichtung von Datenbank-Links durch den DBA Datenbank Links zwischen einer lokalen Datenbank in Berlin und Datenbanken in Berlin und Magdburg CREATE PUBLIC DATABASE LINK BERLIN CONNECT TO B_UNIX; CREATE PUBLIC DATABASE LINK MAGDEBURG CONNECT TO MD_VMS; Vorraussetzung: Eingetragene Nutzer bei den Datenbanken in Berlin (B_UNIX) bzw. Magdburg (MD_VMS). Quelle: Burleson, D. K.: Oracle Datenbank Anwendung, Thomson Publ., 1997 Prof. Dr. Andreas Schmietendorf 57

58 Verteilte DB mit Oracle Aufruf zur Erstellung eines Datenbank- Links unter dem DBMS Oracle Prof. Dr. Andreas Schmietendorf 58

59 Verteilte DB mit Oracle Oracle Enterprise Manager Interaktive Erstellung der Datenbank-Links Bezeichnung des Datenbank-Link Form der Anmeldung auf dem entfernten Datenbanksystem Dienstname der entfernten Datenbank Prof. Dr. Andreas Schmietendorf 59

60 Verteilte DB mit Oracle Verwendung des Datenbank-Links 1 SELECT A.NAME, B.QUANTITY_ORDERED FROM CUSTOMER@BERLIN A, ORDERLINE@MAGDEBURG B Quelle: Burleson, D. K.: Oracle Datenbank Anwendung, Thomson Publ., 1997 Prof. Dr. Andreas Schmietendorf 60

61 Verteilte DB mit Oracle Verwendung des Datenbank-Links 2 SELECT CUSTOMER.NAME, ORDER.ORDER_DATE, ORDERLINE.QUANTITY_ORDERED FROM CUSTOMER@BERLIN, ORDER, ORDERLINE@MAGDEBURG WHERE CUSTOMER.CUST_NUMBER = ORDER.CUSTOMER_NUMBER AND ORDER.ORDER_NUMBER = ORDERLINE.ORDER_NUMBER; Quelle: Burleson, D. K.: Oracle Datenbank Anwendung, Thomson Publ., 1997 Prof. Dr. Andreas Schmietendorf 61

62 Verteilte DB mit Oracle Transparenz durch Einsatz von Views I: Definition einer View CREATE VIEW TABELLE AS SELECT * FROM TAB@BERLIN; SQL-Abfragen ohne Kenntnis des Datenbank-Links UPDATE TABELLE SET PREIS = PREIS * 1,96 WHERE WAEHRUNG = DM; Einschränkung der Zugangsrechte über selektive Vergabe von Rechten für die Nutzer B_UNIX bzw. MD_VMS Prof. Dr. Andreas Schmietendorf 62

63 Verteilte DB mit Oracle Transparenz durch Einsatz von Views II (Interaktionen): Auflösen der View Definition für TABELLE über das DD Identifizierung eines DB-Links hinter der View-Definition Auflösen des DB-Link-Namen und der TNS-Adresse beim Zielrechner Verbindungsaufbau zur Remote-Datenbank SQL-Befehl an die Zieldatenbank senden Ziel-Datenbank führt den SQL-Befehl aus Ergebnis-Rückgabe an den lokalen DB-Server Prof. Dr. Andreas Schmietendorf 63

64 Verteilte DB mit Oracle Security-Aspekte: Über Datenbank-Links (DB-Links) besteht die Möglichkeit, von einer Datenbank innerhalb eines DBMS aus auf die Daten einer anderen Datenbank, gegebenenfalls in einem anderen DBMS, zuzugreifen. Um einen angemessenen Schutz der Daten zu gewährleisten, sollte diese Technik nur im Rahmen eines entsprechenden Berechtigungskonzepts angewendet werden. In diesem Konzept muss unter anderem die Kontrolle der Berechtigungen eines Benutzers bei der Verwendung von DB-Links geregelt werden. Quelle: M 4.71 Restriktive Handhabung von Datenbank-Links Bundesamt für Sicherheit in der Informationstechnik Prof. Dr. Andreas Schmietendorf 64