10 Autonomie und Heterogenität
10.1 Knotenautonomie
Der Zugriff auf mehrere Datenbanken innerhalb einer Transaktion setzt ein Mindestmaß an Kooperationsbereitschaft der beteiligten Knoten und ihrer DBVS voraus, u.a. um die ACID-Eigenschaften wahren zu können. Daraus folgt unweigerlich eine reduzierte Unabhängigkeit oder Autonomie der Rechner (Knotenautonomie, node autonomy) im Vergleich zu ihrer isolierten Nutzung. Verschiedene Arten der Knotenautonomie lassen sich hierbei unterscheiden (siehe auch [SL90]):
- Entwurfsautonomie (design autonomy)
Jeder Knoten entscheidet selbständig darüber, welcher Anwendungsausschnitt in der Datenbank repräsentiert sein soll (Miniwelt) und wie der logische DB-Entwurf (Namenswahl, Datenrepräsentation, Integritätsbedingungen etc.) und physische DB-Entwurf (Speicherungsstrukturen, Indexwahl etc.) dazu aussehen sollen.
- Ausführungsautonomie (execution autonomy)
Lokale Transaktionen, die auf ausschließlich lokalen Daten arbeiten, sollten unabhängig von anderen Rechnern bearbeitbar sein und durch externe Transaktionen möglichst nicht beeinträchtigt werden. Sub-Transaktionen externer Transaktionen sollten weitgehend wie lokale Transaktionen bearbeitet werden.
- Kooperationsautonomie (communication + association autonomy)
Jeder Knoten kann darüber entscheiden, welche Bereiche der lokalen Datenbank für externe Benutzer (Transaktionen) referenzierbar sind und welche Operationen darauf ausführbar sind. Weiterhin entscheiden die LDBS selbständig darüber, in welchem Umfang eine Kooperation mit anderen LDBS unterstützt wird, z.B. zur globalen Anfragebearbeitung oder Transaktionsverwaltung.
- Unabhängigkeit hinsichtlich Wahl des DBVS
Die Entscheidung, welches DBVS zur Verwaltung einer Datenbank eingesetzt wird, soll unabhängig von anderen Knoten getroffen werden können. Damit wird zugleich die Wahl des Datenmodells (relational, hierarchisch, netzwerkartig, objekt-orientiert etc.), der Anfragesprache (SQL-Dialekt, DL/1...) sowie der internen Realisierung (Transaktionsverwaltung, Query-Optimierung, Zugriffspfadtypen etc.) festgelegt.
- Unabhängigkeit hinsichtlich Wahl der Ablaufumgebung
Jeder Knoten kann die Wahl der Hardware, von Betriebssystem sowie sonstiger Software (TP-Monitor, Kommunikationsprotokolle) auf seine lokalen Bedürfnisse abstimmen.
Kooperation und Knotenautonomie sind jedoch keine Alles-oder-Nichts-Eigenschaften, sondern werden von verschiedenen Ansätzen in unterschiedlichem Ausmaß unterstützt. Selbst bei der Realisierung von Verteilten DBS wurde bereits versucht, der Forderung nach Knotenautonomie Rechnung zu tragen, um eine akzeptable Unterstützung geographisch verteilter Systeme zu erreichen. Daher wurden zentralisierte Lösungansätze etwa zur Katalogverwaltung oder zur Synchronisation als inakzeptabel eingestuft. Auch bei der Namensverwaltung wurde die Wahrung einer hohen Autonomie angestrebt (Kap. 4.4). Auf der anderen Seite unterstützen Verteilte DBS nahezu keine Entwurfsautonomie (bis auf den physischen DB-Entwurf). Zur Gewährleistung von Verteilungstransparenz muß ferner jede DB-Operation an allen beteiligten DBS gestartet werden können[46]. Wie wir sehen werden, wird auch bei der Unterstützung heterogener Datenbanken Knotenautonomie in unterschiedlichem Umfang erreicht. Die jeweilige Anwendung entscheidet über den erforderlichen Grad an Knotenautonomie und Kooperation und damit über die Eignung verschiedener Realisierungsalternativen.
[46] Eine besonders enge Kooperationsnotwendigkeit wird eingeführt, wenn Relationen über mehrere Knoten hinweg partitioniert oder repliziert gespeichert werden, da dann bereits Operationen auf einer Relation verteilt auszuführen sind.