Datenbank-Sichten und Daten- Repräsentation

Universität Paderborn
Fachbereich 17 - Mathematik/Informatik
Arbeitsgruppe Softwaretechnik
Prof. Dr. W. Schäfer
Warburger Str. 100
33098 Paderborn
Datenbank-Sichten und DatenRepräsentation
Seminarausarbeitung
im Rahmen der Projektgruppe
Entwicklung eines verteilten
multimedia Systems mit Hilfe
von Design Pattern
im Projekt
von
Carsten Reckord
Bergstraße 53
33415 Verl
Paderborn, Juni 2001
ii
i.
KAPITEL 1
Inhaltsverzeichnis
EINFÜHRUNG IN SICHTEN ................................................. 1
1.1 SICHTEN IN RELATIONALEN DATENBANKEN .......................................... 2
1.2 SICHTEN IN OBJEKTORIENTIERTEN DATENBANKEN ................................ 3
1.2.1 Sichten in ODMG 3.0 .............................................................................. 4
1.2.2 Ein Sichtenmodell für O2 ......................................................................... 4
1.2.3 Sichten in Coocoon .................................................................................. 7
1.3 WEITERE ANWENDUNGEN FÜR SICHTEN ................................................ 8
KAPITEL 2
SICHTEN IN VERTEILTEN DATENBANKEN .................. 9
2.1 FRAGMENTIERUNG DURCH SICHTEN .................................................... 11
2.2 SCHEMA-INTEGRATION DURCH SICHTEN .............................................. 11
2.3 MATERIALISIERTE SICHTEN .................................................................. 12
KAPITEL 3
DATENBANKMODELLIERUNG MIT UML .................... 15
3.1 MODELLIERUNG IN UML .....................................................................
3.2 MODELL-INTEGRATION IN UML ..........................................................
3.3 ABBILDUNG AUF RELATIONALE DATENBANKEN ..................................
3.4 SICHTEN IN UML ..................................................................................
16
18
19
21
KAPITEL 4
ZUSAMMENFASSUNG ........................................................ 25
ANHANG A
ARBEITEN MIT RELATIONALEN SICHTEN ................. 27
A.1 SICHTENDEKLARATION IN SQL ........................................................... 27
A.1.1 Sichten-Typen ........................................................................................ 28
A.2 ANFRAGEN AUF SICHTEN ..................................................................... 29
A.2.1 Sichtenauflösung (view resolution): ...................................................... 29
A.2.2 Sichten-Materialisierung (View Materialization) ................................. 30
A.2.3 Einschränkungen für die Sichtendefinition ........................................... 31
A.3 UPDATEOPERATIONEN AUF SICHTEN ................................................... 31
A.3.1 Änderbare Sichten nach ISO-Standard ................................................. 32
A.3.2 Das View Update Problem jenseits des ISO Standards ........................ 34
A.4 ERGÄNZUNGEN ZUM RELATIONALEN SICHTENMODELL ...................... 39
iii
A.4.1 Virtuelle Attribute in SQL3 ................................................................... 39
A.4.2 Objektrelationale Datenbanken und Objektsichten .............................. 39
ANHANG B
LITERATURVERZEICHNIS ............................................... 41
ANHANG C
ABBILDUNGSVERZEICHNIS ............................................. 43
iv
KAPITEL 1
Einführung in Sichten
Die meisten modernen Datenbank-Systeme besitzen eine Drei-Schichten-Architektur, die dem
ANSI/SPARC Datenbank-Modell[BG92] entspricht. Die in diesem Modell definierten Schichten beschreiben unterschiedliche Abstraktionsebenen für die Daten einer Datenbank. Dies sind
im einzelnen das interne Schema, das konzeptionelle Schema und das externe Schema.
externes Schema
1
2
...
n
konzeptionelles Schema
internes Schema
externe Schicht
Benutzersichten
konzeptionelle Schicht
interne Schicht
physische Schicht
Abbildung 1: Die Drei-Schicht-Architektur des ANSI/SPARC-Modells
Das interne Schema dient der Abbildung der Datenbank auf interne Datenstrukturen des Datenbank-Systems und auf das Dateisystem des unterliegenden Betriebssystems. Das konzeptionelle
Schema beschreibt die logische Struktur der Daten in der Datenbank, also die Art und Menge
der gespeicherten Daten, sowie ihre Abhängigkeiten untereinander und Integritätsbedingungen
für die Datenbank. Diese logische Struktur wird in der Regel von dem jeweiligen DatenbankAdministrator angelegt und verwaltet.
Beim Entwurf des konzeptionellen Schemas ist eine Reihe von Rahmenbedingungen zu beachten, die eine effektive und redundanzfreie Speicherung von Daten in der Datenbank sicherstellen sollen, wie zum Beispiel die Normalisierung von relationalen Datenbanken. Das hat zur
Folge, daß in der konzeptionellen Sicht auf eine Datenbank die Daten häufig nicht so strukturiert sind, wie es den Anforderungen der Benutzer entspricht. Zudem haben unterschiedliche
Benutzer häufig unterschiedliche Anforderungen an die Strukturierung dieser Daten und in der
Regel benötigen einzelne Benutzer jeweils nur Zugriff auf einen Teil der Daten in der Datenbank. Das externe Schema des Drei-Schichten-Modells erlaubt daher die Definition sogenannter Benutzersichten auf die Datenbank, um diesen Anforderungen gerecht zu werden.
Eine Benutzersicht (oder einfach Sicht, engl. view) ist eine Darstellung der Daten des unterliegenden konzeptionellen Schemas, die an die Anforderungen individueller Benutzer oder
1
1.1 Sichten in relationalen Datenbanken
Anwendungsfälle angepaßt ist. Sie erlaubt eine Restrukturierung der Daten in eine Form, die
den individuellen Anforderungen gerecht wird und erlaubt eine Fokussierung auf die in dem
jeweiligen Kontext relevanten Informationen durch Ausblendung unwichtiger Daten. Eine
Sicht wird beschrieben durch Anfragen an die Datenbank und reflektiert zu jeder Zeit das
Ergebnis dieser Anfragen.
Ein Benutzer kennt lediglich die für ihn vorgesehene Sicht. Er kann sie abfragen und verändern,
wie eine eigenständige Datenbank, ohne sich mit dem unterliegenden konzeptionellen Schema
auseinandersetzen zu müssen. Durch dieses Konzept bleibt dem Benutzer die konzeptionelle
Komplexität der eigentlichen Datenbank verborgen, wodurch eine signifikante Vereinfachung
im Umgang mit der Datenbank erreicht wird. Zudem wird hierdurch eine weitgehende logische
Unabhängigkeit von dem unterliegenden Schema erreicht. Denn bei Änderungen an dem konzeptionellen Schema, etwa durch das Einfügen neuer Attribute oder strukturelle Änderungen,
können die Sichten meist konstant gehalten werden. Hierzu sind unter Umständen lediglich die
Sichtendefinitionen entsprechend anzupassen.
Desweiteren bieten Sichten einen sehr flexiblen und komplexen Mechanismus zur Zugriffsbeschränkung auf sensible Informationen. So können diese Informationen in einzelnen Sichten
vor dem Benutzer verborgen werden, während sie in anderen Sichten verfügbar sind.
Schließlich wird durch Sichten die Vereinfachung von Anfragen an die Datenbank ermöglicht,
indem häufig auftretende Teilanfragen als Sichten definiert werden. Diese ersetzen dann in der
Formulierung der Anfrage die entsprechende Teilanfrage.
Da das Sichtenmodell von Datenbanken dazu geeignet ist - und meistens dazu verwendet wird
- logische Zusammenhänge zwischen den Informationen in einer Datenbank geeignet zu repräsentieren, kann man solche Sichten als logische Sichten bezeichnen.
In den folgenden Abschnitten werden die Sichtenmodelle für die zwei bedeutendsten Klassen
von Datenbank-Systemen vorgestellt: relationale und objekt-orientierte Datenbanken.
1.1 Sichten in relationalen Datenbanken
Eine relationale Datenbank besteht aus einer Menge von Tabellen, den sogenannten Relationen.
Jede Relation besitzt einen eindeutigen Namen und ist eine Ausprägung eines Relationen-Schemas. Ein solches Relationen-Schema besteht aus einer Liste von Attributen und deren zugehörigen Wertebereichen und zusätzlichen Integritätsbedingungen. Jedes Attribut definiert eine
Spalte der Relation. Die Gesamtheit der Relationen-Schemata aller in einer Datenbank enthaltenen Relationen bildet das konzeptionelle Schema der Datenbank, das häufig auch als Datenbankschema bezeichnet wird [EN94].
Im relationalen Modell hat der Begriff der Sicht eine etwas andere Bedeutung, als die bisher
verwendete. Wie dargestellt, bezeichnet der Begriff der Sicht im Allgemeinen die Gesamtheit
des externen Modells eines Benutzers. Im relationalen Modell jedoch bezeichnet eine Sicht eine
virtuelle Relation. Im Gegensatz zu einer Basis-Relation, die Teil des konzeptionellen Schemas
2
KAPITEL 1
1.2 Sichten in objektorientierten Datenbanken
ist und deren Tupel physisch in der Datenbank gespeichert sind, erscheint eine Sicht dem Benutzer zwar ebenfalls wie eine gewöhnliche Relation, die er genauso benutzen kann, wie eine
Basis-Relation (mit Einschränkungen bezüglich Updateoperationen, siehe Anhang A). Ihr
Inhalt ist jedoch nicht statisch festgelegt und wird auch (mit Ausnahmen, siehe Anhang A) nicht
physisch gespeichert. Stattdessen wird er dynamisch aus einer Datenbank-Anfrage berechnet,
die bei der Definition der Sicht angegeben wird. Bei dieser Anfrage handelt es sich um eine normale Datenbank-Anfrage, die mit Hilfe der relationalen Algebra[EN94] - oder einer darauf
basierenden Anfragesprache, wie SQL[EN94] - auf Basis-Relationen und bestehenden Sichten
formuliert werden kann.
Eine Sicht reflektiert zu jeder Zeit das Ergebnis der sie definierenden Anfrage. Änderungen an
den in der Anfrage verwendeten Relationen werden - im Gegensatz zu einem Snapshot, der stets
das Ergebnis der Anfrage zum Definitionszeitpunkt darstellt - unmittelbar in der Sicht reflektiert. Umgekehrt werden Updateoperationen auf einer Sicht (so sie erlaubt sind, siehe Anhang
A) direkt auf die unterliegenden Relationen umgesetzt.
Die Syntax zur Definition relationaler Sichten, sowie die Erörterung von Problemen bei
Updateoperationen auf relationalen Sichten und Lösungsansätzen hierfür kann Anhang A entnommen werden.
1.2 Sichten in objektorientierten Datenbanken
Objektorientierte Datenbanksysteme (ooDBMS) wenden das objektorientierte Modell, das aus
vielen aktuellen Programmiersprachen bekannt ist, auf konventionelle Datenbanken an.
Objekte der realen Welt werden hierbei auf Datenbank-Objekte abgebildet, die Instanzen von
Klassen sind. Eine Klasse definiert Attribute, die Eigenschaften eines Objektes beschreiben und
so den internen Zustand des Objektes darstellen, zusammen mit Nachrichten und Methoden zur
Abfrage und Veränderung dieses Zustandes. Ein Objekt reagiert auf eine Nachricht durch die
Ausführung der dieser Nachricht zugeordneten Methode. Eine Nachricht definiert also lediglich
eine Schnittstelle für den Aufruf einer Methode, die diese Nachricht implementiert. So ist es
möglich, Methoden außerhalb der Datenbank mit Hilfe von herkömmlichen objektorientierten
Sprachen zu implementieren. Jedes Objekt hat eine eindeutige Objekt-ID zur Identifikation, die
konstant und unabhängig von dem inneren Zustand des Objektes ist. Ferner erlauben die meisten objektorientieretn Datenbanken die Angabe eines Extents für jede Klasse. Ein Extent ist ein
benannter Container, der alle persitenten Instanzen dieser Klasse enthält (Diese werden, im
Gegensatz zu transienten Instanzen, in der Datenbank gespeichert).
Da die Umsetzung dieses Grundkonzeptes in unterschiedlichen objektorientierten Datenkanksystemen stark variiert und es eine Fülle unterschiedlicher Sichtenmodelle für OO-Datenbanken
gibt, sollen hier beispielhaft lediglich das Sichtenmodell des ODMG3.0-Standards und zwei
weitere, etwas komplexere Modelle beschrieben werden.
Einführung in Sichten
3
1.2 Sichten in objektorientierten Datenbanken
1.2.1 Sichten in ODMG 3.0
Der ODMG 3.0-Standard der Object Data Management Group enthält nur eine sehr rudimentäre Unterstützung für Sichten. Die Abfragesprache OQL (Object Query Language) von ODMG
erlaubt lediglich die Definition von benannten Abfragen mit folgender Syntax:
define <name>[(<parameter>[, ...])]
as <query>
wobei <query> eine Standard-OQL-Anfrage bezeichnet, die analog zu SQL die Struktur
select ... from ... where ... hat. Zusätzlich können optionale Parameter angegeben werden, die in der Anfrage verwendet werden können.
Obwohl dies eine Gruppierung von Instanzen mit bestimmten durch die Anfrage bestimmten
Eigenschaften erlaubt, ist eine echte Restrukturierung des konzeptionellen Schemas der Datenbank nicht möglich. So können etwa keine Attribute von Klassen versteckt werden, ohne die
Objektstruktur der Instanzen zu verlieren und stattdessen lediglich einfache Tupel von Attributdaten zu erhalten. Auch eine Erweiterung und Umstrukturierung der Klassenstruktur des konzeptionellen Schemas durch virtuelle Klassen analog zu virtuellen Relationen des relationalen
Modells ist nicht möglich. Daher kann mit diesem Konzept kein externes Schema als Abstraktion von dem konzeptionellen Schema der Datenbank erzeugt werden.
Da häufig angeführt wird, daß objektorientierte Datenbanken eine Erweiterung der Idee herkömmlicher (relationaler) Datenbanken darstellen sollen und als solche mindestens deren Funktionalität und Mächtigkeit zur Verfügung stellen sollten, werden im Folgenden zwei weitere
Sichtenmodelle vorgestellt, die in ihrer Mächtigkeit den Sichten relationaler Datenbanken
ähneln.
1.2.2 Ein Sichtenmodell für O2
Das im Folgenden vorgestellte Sichtenmodell aus [AB91] setzt auf dem objektorientierten
Datenbanksystem O2 auf und erweitert dieses um eine flexible Sichtenstruktur.
Ziel dieses Sichtenmodelles ist ein flexibler Mechanismus zur Restrukturierung der Datenbank
und zur Modifikation des Verhaltens und der Struktur von Objekten. Dazu führen die Autoren
in ihrem Sichtenmodell virtuelle Attribute und virtuelle Klassen ein.
Eine Sicht besteht in diesem Modell aus importierten Klassen von einer oder mehreren Datenbanken, Sichtbarkeitsregeln für die Attribute dieser Klassen, sowie zusätzlichen virtuellen Klassen und virtuellen Attributen. Eine Sichtendefinition hat folgende Form:
create view <name>
{import/hide specifications}
{class/attribute definitions}
Import-Spezifikationen haben die Form
4
KAPITEL 1
1.2 Sichten in objektorientierten Datenbanken
import {class <name>|all classes}
from database <db>
In relationalen Datenbanken hat es ausgereicht, die Attribute einer virtuellen Relation explizit
in der definierenden Anfrage aufzulisten. In objektorientierten Systemen ist so ein Vorgehen
problematisch, da hierdurch auch alle Attribute, die in Unterklassen definiert sind, verborgen
würden. Daher erlaubt dieses Modell explizit das Verstecken von Attributen mit folgender Syntax:
hide attribute <name> in class <class>
wobei <class> eine beliebige (virtuelle oder importierte) Klasse in der Sicht sein kann.
Virtuelle Attribute
Virtuelle Attribute sind Attribute, deren Wert nicht explizit definiert ist, sondern aus dem aktuellen Objektzustand errechnet werden. Hierdurch können zum Beispiel mehrere Attribute einer
Klasse zu einem komplexen Attribut zusammengefaßt werden, wie folgendes Beispiel zeigt:
Eine Klasse Person sei gegeben durch die Attribute name, city, street und zipCode. Dann können letztere drei Attribute zu einem komplexen Attribut address zusammengefaßt werden:
attribute address in class Person
has value
[city: self.city, street: self.street,
zipCode: self.zipCode]
Die Syntax zur Definition eines Attributes lautet
attribute <name>[(<parameter>,[...])]
[of type <type>]
in class <class>
[has value <value>]
Wird die Option has value angegeben, so handelt es sich um ein virtuelles Attribut, ansonsten
um ein normales. Die Angabe von Parametern ist nur für virtuelle Attribute gestattet. Diese
Definition erlaubt außerdem die Behandlung von Methoden als virtuelle Attribute mit Parameter, deren Wert durch den Methodenrumpf berechnet wird.
Virtuelle Klassen
Die Klassenhierarchie der importierten Klassen kann um virtuelle Klassen erweitert werden.
Dazu ist für jede virtuelle Klasse eine Population mit bestehenden oder neuen Objekten, die
Position in der Klassenhierarchie und das Verhalten - also die Menge der unterstützten Nachrichten - zu definieren. In dem Modell ist lediglich die Population explizit anzugeben. Position
und Verhalten werden daraus anhand der enthaltenen Objekte automatisch abgeleitet.
Für die Population virtueller Klassen gibt es mehrere Möglichkeiten:
• Spezialisierung: Die virtuelle Klasse enthält alle Instanzen einer Klasse, die einer bestimm-
ten Bedingung genügen. Diese wird in Form einer Datenbank-Anfrage ausgedrückt.
Einführung in Sichten
5
1.2 Sichten in objektorientierten Datenbanken
• Generalisierung: Die virtuelle Klasse enthält alle Instanzen einer Menge von Unterklassen
• Verhaltensabhängige Generalisierung: Die virtuelle Klasse enthält alle Klassen, die Attri-
bute oder Methoden bestimmten Namens und bestimmter Signatur haben.
• Imaginäre Objekte: Imaginäre Objekte sind neu erzeugte Objekte, deren Attributwerte aus
den Attributwerten bestehender Objekte berechnet werden.
Insgesamt sieht die Definition einer (virtuellen) Klasse wie folgt aus:
class <name> [(<parameter>[,...])]
[includes {<classname>|
like <classname>|
[imaginary] (<query>)}[,...]]
Mit der Option like <classname> werden dabei alle Objekte eingebunden, deren Klassen
mindestens die Attribute und Methoden von <classname> haben. Die optionalen Parameter
können wie bei virtuellen Attributen als Argumente der Datenbankanfrage verwendet werden.
Das Schlüsselwort imaginary muß angegeben werden, wenn das Ergebnis der Anfrage eine
Liste von Attributwerten ist, aus denen ein neues, imaginäres Objekt erzeugt werden soll.
Ansonsten darf in der select-Klausel der Anfrage nur ein einzelnes Objekt angegeben sein. Hier
zwei Beispiele:
class Supported (maxIncome)
includes Senior, Student,
(select a in Adult
where a.income<maxIncome)
class Family includes imaginary
(select [husband:H, wife:H.partner]
from Person H where H.sex=’male’)
Nach der Definition einer virtuellen Klasse und ihrer Population können neue virtuelle Attribute
(und damit auch Methoden) für die Klasse definiert werden. Zum Beispiel
attribute supportAmount in Supported
has value amount(self)
wobei amount eine dem System bekannte Funktion zur Berechnung der Unterstützungshöhe ist.
Virtuelle Klassenhierarchie
Die Klassenhierarchie der Sicht mit allen importierten Klassen und den darauf definierten virtuellen Klassen kann mittels Typinferenz automatisch hergeleitet werden. Sei hierzu C eine virtuelle Klasse, die die Klassen C1...Ck und Instanzen der Klassen Ck+1...Cn enthält. Es gilt:
• Ist D eine Oberklasse aller Ck, so ist D eine Oberklasse von C
• Ci ist Unterklasse von C für alle i ∈ [1,k]
6
KAPITEL 1
1.2 Sichten in objektorientierten Datenbanken
Updateoperationen auf Sichten
Die Sichten, die mit diesem Modell erzeugt werden können, sind hinsichtlich der meisten Operationen updatefähig. Einzige Bedingungen sind, daß bei Mehrfachvererbung Attributnamen
eindeutig aufgelöst werden können (ansonsten entsteht Schizophrenie[AB91]) und alle
Updatemethoden auf imaginären Objekten redefiniert sind, um die entsprechenden Änderungen an den ursprünglichen Objekten vorzunehmen. Die zweite Bedingung entspricht damit der
Idee aus Anhang A, Updates auf relationale Sichten zu ermöglichen durch abstrakte Datentypen mit entsprechenden Updateoperationen.
1.2.3 Sichten in Coocoon
Einen anderen Ansatz verfolgt das COCOON-System [LST91]. Anstatt die Syntax des Datenbanksystems um zusätzliche Konstrukte zu erweitern, wie dies im vorangegangenen System der
Fall ist, wird eine Sicht ähnlich zu SQL durch einen Ausdruck der Form
define view <name> as <query>
definiert. Anders als in SQL oder dem vorangegangenen Beispiel wird in diesem System jedoch
durch eine besondere Eigenschaft der Anfragesprache COOL die Update-Fähigkeit de Sichten
sichergestellt: Objekt-erhaltende Operatorsemantik.
Im Gegensatz zur OQL, die relationale Semantik hat, also Tupel von Werten zurückliefert, liefert COOL existierende Objekte zurück. Hierfür existieren Operationen zur Selektion, Projektion und Erweiterung von Objekten um neue Methoden:
select [<query>](<source>)
project[<attr>[,...]](<source>)
extend[<function-name>:=<expr>[,...]](<source>)
wobei <source> einen Klassennamen oder einen mengenwertigen Ausdruck bezeichnet.
Zusätzlich existieren die Mengenoperationen union, intersect und difference. Ein
mengenwertiger Ausdruck ist ein Klassenname, über den alle Instanzen der Klasse referenziert
werden, eine der oben angegebenen Operationen sowie jede Kombination hieraus mit Hilfe von
Mengenoperationen.
Der Unterschied zur relationalen Semantik von OQL soll anhand eines Beispiels dargestellt
werden: Sei Person eine Klasse mit den Attributen name, sex, age und income. In OQL liefert
die Projektion »select p.name, p.sex from Person p« eine Menge von zweidimensionalen Tupeln mit den Werten der Attribute name und sex der Instanzen von Person. Dieselbe Projektion in COOL, gegeben durch »project[name, sex](Person)«, liefert alle
Instanzen von Person zurück, blendet jedoch alle Attribute außer name und sex aus, so daß darauf nicht zugegriffen werden kann.
Wie gesagt ist durch die Semantik der Abfragesprache sichergestellt, daß alle in COOL möglichen Anfragen zur Definition update-fähiger Sichten genutzt werden können. Denn alle Operationen werden durch die objekterhaltende Semantik direkt auf den realen Objekten ausgeführt.
Einführung in Sichten
7
1.3 Weitere Anwendungen für Sichten
Jede Sicht ist in diesem Modell eine neue Klasse, für die mittels der extend-Operation auch neue
Methoden definiert werden können. Ferner wird in [Tre91] gezeigt, daß auch eine verhaltensabhängige Generalisierung analog zu Abschnitt 1.2.2 möglich ist. Damit bietet auch dieses
Sichtenmodell die Möglichkeit zur flexiblen Restrukturierung des konzeptionellen Schemas.
Im Gegensatz zu dem Sichtenmodell aus Abschnitt 1.2.2 definiert dieses Modell jedoch Sichten
vollständig mit Hilfe der Anfragesprache und ist somit wesentlich einfacher aufgebaut als das
O2-Modell.
1.3 Weitere Anwendungen für Sichten
In der Einleitung ist dargestellt worden, daß ein externes Schema für eine Datenbank sinnvoll
ist, um logische Unabhängigkeit vom konzeptionellen Schema zu erhalten und um die Struktur
der Datenbank an die individuellen Anforderungen einzelner Benutzer anpassen zu können.
Darüber hinaus gibt es aber eine Vielzahl weiterer interessanter Anwendungsgebiete für Sichten:
• Schema-Entwurf durch Sichtenintegration: Eine Möglichkeit, das konzeptionelle Schema
einer Datenbank „bottom up“ zu entwickeln. Die Anforderungen an die Datenbank werden
für alle Benutzergruppen getrennt als Sichten entwickelt. Durch Zusammenfügen dieser
Sichten und Eliminierung möglicher Konflikte zwischen ihnen kann dann das Gesamtschema hergeleitet werden.
• Datenbank-Integration: Daten können aus einer Datenbank in eine andere exportiert wer-
den, indem die unterschiedlichen Schemata der beteiligten Datenbanken mit Hilfe von Sichten auf ein gemeinsames (Teil-)Schema abgebildet werden, über das dann die Daten
ausgetauscht werden können
• Anpassung des Datenmodells: Sichten können genutzt werden, um auf eine Datenbank mit
einem anderen Datenmodell zuzugreifen. So können etwa Objekt-Sichten auf relationale
Datenbanken[BKSW91] (was grob gesagt das Prinzip objektrelationaler Datenbanken ist)
oder relationale Sichten auf objektorientierte Datenbanken definiert werden.
• Visualisierungssysteme: Bei der Visualisierung von Daten einer Datenbank tritt dasselbe
Problem auf, wie bei materialisierten Sichten. Ein Visualisierungssystem sollte stets den
aktuellen Datenstand repräsentieren. Daher muß es bei Änderungen an den Daten entsprechend aktualisiert werden. Dies entspricht dem View Maintenance Problem, das in Anhang
A vorgestellt wird. Einige Visualisierungssysteme bauen daher auf einer Model-View-Controller-Architektur auf, die materialisierte Sichten für das Modell und die zugehörigen
Maintenancealgorithmen für den Controller verwenden.[Lee]
Weitere Anwendungsmöglichkeiten werden in Kapitel 2 im Zusammenhang mit verteilten
Datenbanken erläutert.
8
KAPITEL 1
Sichten in verteilten Datenbanken
KAPITEL 2
Verteilte Datenbanken können aufgefaßt werden als logisch integrierte Datenmengen, die physikalisch über ein Netzwerk verteilt sind. Verteilte Datenbanksysteme sind damit Softwaresysteme zur Verwaltung einer verteilten Datenbank, so daß die Verteilung für den Benutzer
transparent ist. Die meisten verteilten Datenbanksysteme erreichen diese Transparenz durch
eine Architektur, die dem ANSI/SPARC Modell entspricht. Die verschiedenen Klassen von
verteilten Datenbanksystemen lassen sich grob unterteilen in (homogene) verteilte Datenbanksysteme, (heterogene) Multi-Datenbanksysteme und föderierte Datenbanksysteme. Sie unterscheiden sich in der Art der lokalen Datenbanken, auf denen sie aufbauen, und deren
Integration in das SPARC-Modell. Abbildung 2 zeigt die Architekturen dieser drei Klassen[BG92].
1
globale
Benutzersichten
n
1
globale
Benutzersichten
globales
Schema
n
globales
Schema
FragmentierungsSchema
Hilfsschema
1
globale
Benutzersichten
n
AllokationsSchema
Hilfsschema
1
1
lokale
konzeptionelle
Schemata
...
lokale
interne
Schemata
n
1
1
...
n
n
1
lokale
Benutzersichten
lokale DB
a) verteiltes Datenbank-System
Hilfsschema
lokale
konzeptionelle
Schemata
...
lokale
interne
Schemata
n
n
1
1
...
...
n
n
lokale
Benutzersichten
1
1
lokale
konzeptionelle
Schemata
...
lokale
interne
Schemata
1
n
...
n
n
lokale DB
lokale DB
b) Multidatenbank-System
c) Föderiertes Datenbank-System
Abbildung 2: Verteilte Datenbankarchitekturen
9
Architekturen verteilter Datenbanken
(Homogene) Verteilte Datenbanken bestehen aus mehreren gleichartigen lokalen Datenbanken, auf die die Daten eines globalen Schemas aufgeteilt sind. Das Fragmentierungsschema
definiert , wie die Daten des globalen Schemas auf die lokalen Datenbanken aufgeteilt werden
und das Allokierungsschema definiert, in welchen lokalen Datenbanken diese Fragmente
abgelegt sind. Der Zugriff auf die Daten erfolgt ausschließlich über die verteilte Datenbank.
(Heterogene) Multi-Datenbanksysteme bestehen hingegen aus verschiedenartigen Datenbanksystemen mit eventuell unterschiedlichen Datenmodellen. So kann zum Beispiel eine lokale
Datenbank ein hierarchisches Datenmodell verwenden, während eine andere ein relationales
Modell verwendet. Multi-Datenbanksysteme haben häufig ein Hilfsschema, um zum Beispiel
die Umrechnung von Maßeinheiten in verschiedenen lokalen Datenbanken zu ermöglichen.
Einige Systeme haben auch ein Fragmentierungsschema. Multi-Datenbanksysteme werden
meist dort eingesetzt, wo auf bestehende Datenbanken aufgesetzt werden soll. Sie erlauben
daher insbesondere die normale Weiterverwendung der lokalen Systeme durch Benutzer.
Föderierte Datenbanksysteme sind spezielle Multi-Datenbanksysteme, die lediglich die Daten,
die sie mit anderen Datenbanken teilen sollen, in einem Export-Schema definieren. An einem
föderierten System beteiligte Datenbanken können das System jederzeit verlassen oder ihm beitreten. Den lokalen Systemen ist es selbst überlassen, mit Hilfe der zur Verfügung stehenden
Exportschemata ein eigenes globales Schema zu definieren.
Sichten auf verteilte Datenbanken
Wie bereits erwähnt verhält sich eine verteilte Datenbank hinsichtlich Datenbankoperationen
völlig transparent und die Verteilung ist für den Benutzer nicht erkennbar. Anfragen und
Updateoperationen auf der verteilten Datenbank werden vom Datenbanksystem in entsprechende Operationen auf den lokalen Datenbanken umgesetzt. Daher ist auch die Definition
von Sichten mittels Anfragen auf der Datenbank für den Benutzer transparent. Analog zu zentralisierten (nicht-verteilten) Datenbanken wird die definierende Anfrage einer Sicht gespeichert und bei Bedarf durch Sichtenauflösung oder Materialisierung (siehe Anhang A) für
Operationen zur Verfügung gestellt.
Somit gelten für Sichten auf verteilte Datenbanken ebenfalls alle in Kapitel 1 dargestellten
Eigenschaften. In diesem Kapitel soll daher lediglich auf drei spezielle Anwendungsmöglichkeiten von Sichten in verteilten Datenbanksystemen eingegangen werden: die Verwendung von
Sichten zur Beschreibung von Fragmentierung und zur Schema-Integration, sowie die Optimierung der Zugriffszeit durch materialisierte Sichten.
Im weiteren Verlauf dieses Kapitels wird zur einfacheren Darstellung für die Datenbanken ein
relationales Datenmodell angenommen. Alle Ausführungen lassen sich jedoch auch auf andere
Datenmodelle mit entsprechend mächtigen Sichtenmodellen übertragen.
10
KAPITEL 2
2.1 Fragmentierung durch Sichten
2.1 Fragmentierung durch Sichten
In verteilten Datenbanken werden alle Daten auf die unterliegenden lokalen Datenbanken aufgeteilt. Dies wird als Fragmentierung bezeichnet. Hierbei ist es möglich, lediglich die Relationen des globalen Schemas auf die lokalen Datenbanken aufzuteilen. Häufig werden jedoch auch
einzelne Relationen auf mehrere lokale Datenbanken aufgeteilt. Hierzu können etwa vollständige Tupel einer Relation auf unterschiedliche lokale Datenbanken verteilt werden, was als
horizontale Fragmentierung bezeichnet wird. Alternativ kann eine Relation entlang ihrer Attribute aufgetrennt werden, was als vertikale Fragmentierung bezeichnet wird. Eine Kombination
beider Techniken wird als hybride Fragmentierung bezeichnet.
Die Aufteilung einer Relation entlang ihrer Tupel beziehungsweise ihrer Attribute wird auch in
Anhang A beschrieben. Dort erfolgt diese Aufteilung durch die Definition von horizontalen
beziehungsweise vertikalen Sichten. Es liegt daher nahe, dasselbe Vorgehen für die Definition
des Fragmentierungsschemata anzuwenden. Bei der vertikalen Fragmentierung ist lediglich
darauf zu achten, daß alle Fragmente mindestens den Primärschlüssel oder einen vollständigen
Sekundärschlüssel enthalten müssen, damit die Fragmente wieder korrekt zusammengesetzt
(materialisiert) werden können.
Die Definition des Fragmentierungsschemas mit Hilfe von Sichten hat den Vorteil, daß eine
geschlossene Darstellung der verschiedenen Abstraktionsebenen des Datenbanksystems existiert. Von einem zentralen globalen Schema wird sowohl das externe Schema als auch das
Fragmentierungsschema auf dieselbe Weise abgeleitet. Dies erlaubt zudem die Auffassung des
Datenbanksystems als eine einheitliche hierarchische Struktur mit den Fragmenten als Blätter,
von denen Relationen und Sichten abgeleitet werden können[CBS97].
2.2 Schema-Integration durch Sichten
In Abschnitt 1.3 ist bereits erwähnt worden, daß Sichten zur Entwicklung eines komplexeren
Schemas genutzt werden können, ebenso wie zur Integration unterschiedlicher Datenbanken in
ein gemeinsames Schema. Dies entspricht genau dem Problem der Schema-Integration für
Multi-Datenbank-Systeme. Die Schemata unterschiedlicher existierender Datenbanken müssen
in ein einheitliches und konsistentes globales Schema integriert werden. Die Tatsache, daß einzelne lokale Datenbanken eventuell unterschiedliche Datenmodelle verwenden, kann hier vernachlässigt werden, da das Multi-Datenbank-System auf jeden Fall sein eigenes Datenmodell
auf die lokalen Datenmodelle abbilden können muß und umgekehrt.
Der Vorgang der Schema-Integration wird in [BG92] als Serie von Abstraktionsschritten auf
den Daten der lokalen Schemata beschrieben. Da das globale Schema höchstens die Summe der
Daten der lokalen Schemata enthalten kann, in der Regel jedoch weniger, werden in diesen
Abstraktionsschritten sukzessive Details der lokalen Schemata ausgeblendet oder transformiert.
Diese Abstraktionsschritte lassen sich in verschiedene Kategorien unterteilen:
Sichten in verteilten Datenbanken
11
2.3 Materialisierte Sichten
• Aggregationen: Beziehungen zwischen Objekten der lokalen Schemata werden durch ein
abstrakteres Objekt ausgedrückt. Eine Aggregation zwischen Kunde und Händler kann etwa
durch ein Objekt „Vertrag“ repräsentiert werden.
• Generalisierung: Mehrere Relationen mit einer gemeinsamen Teilmenge an Attributen wer-
den in eine Relation mit dieser Attributteilmenge umgesetzt.
• Selektion: Für das globale Modell ist nur ein Teil der Objekte eines Typs interessant. Dieser
Abstraktionsschritt kann analog zur Generalisierung auch als Spezialisierung verstanden
werden.
• Weitere Transformationen zur syntaktischen Anpassung der Schemata, etwa zur Einheiten-
konvertierung oder um unterschiedliche Tabellenstrukturen einander anzupassen.
• Weitere Transformationen zur semantischen Anpassung, etwa um immanente Informatio-
nen lokaler Schemata als explizite Attribute in das globale Schema aufzunehmen. So kann
etwa eine Relation mit Transportrouten in den lokalen Schemata jeweils nur die Zielorte
beinhalten, während als Startort immanent der Standort der lokalen Datenbank angenommen wird. Haben die lokalen Datenbanken unterschiedliche Standorte, so müssen diese in
der globalen Relation berücksichtigt werden.
Diese Transformationen lassen sich in der Regel durch Operationen des globalen Datenmodells
ausdrücken und können damit in Form von Sichten definiert werden. Aggregationen können im
relationalen Modell etwa durch Join und Projektion ausgedrückt werden, Generalisierungen
durch Vereinigung und Spezialisierungen durch Selektionsbedingungen. Damit läßt sich ähnlich zu den Ausführungen in Abschnitt 2.1 die Definition des Multi-Datenbank-Systems in
einem geschlossenen Modell beschreiben.
2.3 Materialisierte Sichten
Wie auch in Anhang A erläutert wird, ist eine dynamische Berechnung des Inhaltes einer Sicht
bei jeder Anfrage durch Sichtenauflösung nicht immer erstrebenswert. Dies ist insbesondere in
verteilten Datenbanken der Fall, da die definierende Anfrage einer Sicht in der Regel eine verteilte Anfrage auf mehrere Datenbanken ist. Besonders für häufig benutzte Sichten bedeutet dies
einen hohen zeitlichen Aufwand und eine signifikante Zunahme des Kommunikationsvolumens
im Netzwerk. Dies ist unter Umständen nicht akzeptabel. Daher werden in verteilten Datenbanken häufig materialisierte Sichten als Alternative zur Sichtenauflösung eingesetzt (siehe
Anhang A). Dadurch werden Netzwerkzugriffe bei Anfragen an eine Sicht eliminiert. Lediglich
bei der Aktualisierung einer Sicht aufgrund von Änderungen an den Basisrelationen entsteht
Netzwerkverkehr und Systemlast. Durch Incremental View Maintenance (siehe Anhang A)
kann beides weiter reduziert werden.
View Maintenance-Algorithmen lassen sich anhand der Informationen klassifizieren, auf die sie
zur Aktualisierung einer materialisierten Sicht zurückgreifen müssen. Im einfachsten Fall haben
die Algorithmen Zugriff auf alle an der Sicht beteiligten Relationen. Ein Beispiel für einen solchen Algorithmus ist der counting-Algorithmus[GM95]. Hierbei wird für jedes Tupel der Sicht
12
KAPITEL 2
2.3 Materialisierte Sichten
dessen Multiplizität mitgespeichert. Änderungen an Tupeln werden durch Änderungen an diesem Zähler ausgedrückt. Einfügen eines neuen Tupels in eine Basisrelation erhöht den Zähler
um eins, Löschen verringert ihn. Änderungen an einem Tupel werden auf Einfüge- und
Löschoperationen abgebildet. Ein Tupel mit einer Multiplizität von Null wird aus der Sicht
gelöscht.
Algorithmen, die nur einen Teil der an einer Sicht beteiligten Relationen benötigen, sind für verteilte Datenbanken meist besser geeignet, da weniger Informationen zwischen den Netzwerkknoten ausgetauscht werden muß. Eine spezielle Unterklasse dieser Algorithmen erlaubt die
Aktualisierung einer materialisierten Sicht nur unter Verwendung der Sicht selbst. Sichten, die
durch einen solchen Algorithmus aktualisiert werden können, werden als self-maintainable
views bezeichnet. Solche Sichten sind in verteilten Datenbanken besonders effizient zu aktualisieren, da sie nur eine Liste der Aktualisierungsoperationen auf ihren Basisrelationen benötigen,
um aktualisiert zu werden.
Häufig lassen sich View Maintenance-Algorithmen zudem mit Algorithmen für das sogenannte
irrelevant update-Problem kombinieren. Diese Algorithmen erlauben bereits im Vorfeld die
Erkennung von Update-Operationen auf den Basisrelationen, die keinen Einfluß auf die Sicht
haben.
Eine große Klasse von Sichten sind die sogenannten SPJ-Sichten (Select-Project-Join). Ihre
definierenden Anfragen sind von der Form
select ti1.aj1,...,tin.ajn
from R1 t1,...,Rm tm
where <cond1> and ... and <condk>
wobei <condi> entweder eine Join-Bedingung von der Form t.a=s.b oder eine Selektionsbedingung in Form eines Vergleiches mit einer Konstanten ist. Für die hierdurch definierte Klasse
von Sichten kann gezeigt werden, daß es sich fast immer um self-maintainable Sichten in Bezug
auf Lösch- und Update-Operationen handelt[GM95].
Anfrage-Optimierung durch materialisierte Sichten
Die Verringerung der Antwortzeiten von Anfragen auf Sichten durch die Verwendung von
materialisierten Sichten und effizienten Aktualisierungsalgorithmen kann aber darüber hinaus
auch für zusätzliche Optimierungen weiterverwendet werden. In [GL01] wird ein Optimierer
für Datenbankanfragen mit Hilfe von materialisierten Sichten vorgestellt. Hierzu werden automatisch eine große Zahl geeigneter SPJ-Sichten erzeugt, so daß viele Datenbank-Anfragen in
Anfragen transformiert werden können, die ausschließlich auf materialisierte Sichten zugreifen. Durch geeignete Index-Strukturen, sogenannte Filter-Bäume, über die definierenden
Anfragen dieser Sichten ist dieses view matching effizient zu realisieren. Es wird gezeigt, daß
durch einen derartigen Optimierer immense Performance-Steigerungen möglich sind, da etwa
80-90 % aller Anfragen durch Anfragen auf materialisierte Sichten ausgedrückt werden können.
Sichten in verteilten Datenbanken
13
2.3 Materialisierte Sichten
14
KAPITEL 2
KAPITEL 3
Datenbankmodellierung mit UML
Wie in Abschnitt 1.2.3 und Abschnitt 2.2 zu erkennen ist, ist ein zentrales Problem des Datenbankentwurfs die Schema-Integration, also die Zusammenführung unterschiedlicher Benutzersichten zu einem zentralen Schema. Der Entwurf einer Datenbank erfolgt meist mit Hilfe von
speziellen Entwurfsdiagrammen für den jeweiligen Datenbank-Typ, etwa Entity-Relationship(ER-) Diagrammen für relationale Datenbanken oder erweiterten ER-Diagrammen (EER-Diagrammen) für objektrelationale oder objektorientierte Datenbanken.
Häufig erfolgt der Entwurf einer Datenbank jedoch nicht isoliert, sondern eingebettet in den
Entwurf einer oder mehrerer Applikationen, die auf die Datenbank zugreifen sollen. Diese
Applikationen werden in der Regel mit Hilfe von objektorientierten Modellierungssprachen
entworfen und in einer objektorientierten Programmiersprache wie C++ oder Java implementiert. Hieraus ergibt sich ein Problem im Zusammenhang mit herkömmlichen Entwurfsmethoden für Datenbanken. Denn die unterschiedlichen Modellierungssprachen für Datenbank und
Applikationslogik erlauben keine geschlossene Modellierung des Systems. Vielmehr müssen
Teile des Applikationsmodelles, die ebenfalls Bestandteil der Datenbank sind, dort entsprechend der eingesetzten Datenbank-Entwurfsdiagramme neu modelliert werden. Dieses Vorgehen hat nicht nur eine Erschwerung von Entwurfsänderungen durch die Umsetzung in zwei
unterschiedlichen Modellen zur Folge. Auch eine Portierung auf eine andere, neuere Datenbanktechnologie, wie etwa von relationalen auf objektorientierte Datenbanken gestaltet sich
sehr schwierig.
Derartige Probleme können vermieden werden, wenn der Entwurf der Applikationslogik und
der Datenbank in einem einzigen Modell mit Hilfe einer einheitlichen Modellierungssprache
erfolgen kann. Diese sollte außerdem eine Abbildung des Modelles auf eine möglichst große
Zahl von Datenbank-Typen erlauben. Wie gesagt wird die Applikationslogik meist objektorientiert entworfen. auch ER- und EER-Diagramme können leicht auf objektorientierte Modelle
abgebildet werden. Auch Verfahren zur Lösung vieler traditioneller Probleme des Datenbankentwurfes, wie der Schema-Integration (siehe Abschnitt 1.2.3 und Abschnitt 2.2), zeigen objektorientierte Ansätze. Daher liegt es nahe, die Datenbank zusammen mit der Applikationslogik
mit einer objektorientierten Modellierungsprache zu entwerfen.
Die Unified Modelling Language [UML] von Grady Booch, James Rumbaugh und Ivar Jacobson ist eine objektorientierte, grafische Modellierungssprache zur Beschreibung statischer und
dynamischer Eigenschaften eines Softwaresystems. Sie ist aus einer Zusammenführung der
Sprachen OMT [Rum94] von Rumbaugh, OOSE [Jac95] von Jacobson und Booch-Diagrammen [Boo94] von Grady Booch entstanden und wurde 1997 erstmals vorgestellt.
15
3.1 Modellierung in UML
In den folgenden Absätzen soll der Entwurf von Datenbankschemata mit Hilfe der UML erläutert werden. Für eine genauere Darstellung der hier vorgestellten Methoden und der sich ergebenden Probleme siehe [Mul99].
3.1 Modellierung in UML
Die Modellierung eines Datenbank-Systems in UML erfolgt grundsätzlich genauso, wie die
Modellierung eines herkömmlichen Software-Systems. Im Gegensatz zu herkömmlichen
Modellierungsmethoden für Datenbanken wird nicht zwischen Datenbank- und Applikationsmodellierung unterschieden.
In einem ersten Schritt werden die Anforderungen an das System in Form von Use-Case-Diagrammen modelliert. Hierbei werden Benutzer - dies können Anwender des Systems oder auch
andere Systemkomponenten sein - als Aktoren in Form von Strichmännchen dargestellt. Alle
Aktionen, die das System diesen Aktoren zur Verfügung stellen soll, werden als Use-Cases in
Form von Ovalen dargestellt. Abbildung 3 zeigt ein solches Use-Case-Diagramm.
Online shop
add Customer
remove Customer
process Order
«uses»
customer
support
remove Order
packager
add Order
identify
customer
Abbildung 3: Use-Case-Diagramm
Für jeden Use-Case können in einem nächsten Schritt mit Hilfe von Kollaborationsdiagrammen
die beteiligten Objekte, ihre Beziehungen untereinander und die Operationen auf diesen Objekten identifiziert und modelliert werden. Abbildung 4 zeigt dies beispielhaft.
1:getOrder
Customer
OrderSystem
Packager
address
1.1:partsInStock
recipient
3.2:removeOrder
1.1.1:inStock
2:getParts
3:ship
Order
parts
Part
Abbildung 4: Kollaborationsdiagramm »process Order«
16
KAPITEL 3
3.1 Modellierung in UML
Sind alle Objekte identifiziert, so kann hieraus eine Klassenhierarchie abgeleitet werden, indem
gleichartige Objekte zu Klassen zusammengefaßt und Klassen spezieller Objekte als Unterklassen allgemeinerer Klassen modelliert werden. Attribute und Methoden der Klassen ergeben sich
aus den Eigenschaften der Objekte in den Kollaborationsdiagrammen und den Kollaborationsnachrichten zwischen den Objekten. In Abbildung 5 ist ein Klassendiagramm zu dem Kollaborationsdiagramm aus Abbildung 4 und dem Use-Case-Diagramm aus Abbildung 3 dargestellt.
Address
+town:String
+Street:String
OrderSystem
livesAt
Person
0..1
0..1 +name:String
orders
n
Customer
Employee
+id:Integer
Packager
+custID:String
+login:String 1
+identify():void
recipient
Order
n +partsInStock():bool
+ship():void
0..1
parts
Part
+inStock():bool
0..1
n
Abbildung 5: Klassendiagramm
Ist so schließlich das gesamte System modelliert, müssen die für die Datenbank relevanten Teile
des Modelles identifiziert werden. Hierzu ist zunächst zwischen persistenten Klassen, deren
Instanzen in der Datenbank gespeichert werden sollen, und transienten Klassen, die lediglich in
der Applikationslogik verwendet werden, zu unterscheiden. So sind etwa in einem MVCModell nur die Modell-Klassen persistent, während die Instanzen der View- und ControllerKlassen ausschließlich in der Applikationslogik benötigt werden. Persistente Klassen werden in
UML durch den Stereotyp «persistent» gekennzeichnet.
Desweiteren muß entschieden werden, ob das dynamische Verhalten einer Klasse, also ihre
Methoden und Signale, in der Datenbank oder in der Applikation realisiert werden soll. Für die
Realisierung in der Applikation spricht hierbei bessere Portabilität des Verhaltens, einfachere
Wartbarkeit und der meist wesentlich größere Funktionsumfang der verwendeten Programmiersprache. Für eine Implementierung in der Datenbank in Form von stored Procedures und Triggern spricht die höhere Performance bei Operationen auf großen Datenmengen und einem
hohen Aufkommen an Transaktionen. Methoden, die auf transienten Daten arbeiten, sollten
immer in der Applikation realisiert werden.
Da die Umsetzung des so entstandenen Datenmodells auf eine objektorientierte Datenbank
direkt erfolgen kann, soll hier nicht näher darauf eingegangen werden. Stattdessen wird in
Abschnitt 3.3 die etwas problematischere Umsetzung in ein relationales Schema skizziert. Für
eine genaue Beschreibung der Umsetzung in Schemata für unterschiedliche Datenbank-Typen
siehe [Mul99].
Datenbankmodellierung mit UML
17
3.2 Modell-Integration in UML
3.2 Modell-Integration in UML
Häufig soll eine Datenbank von mehreren Applikationen oder unterschiedlichen Komponenten
eines großen Software-Systems verwendet werden. Hier bietet es sich an, analog zum Vorgehen
der Sichtenintegration aus Abschnitt 1.3 diese Komponenten und ihre Anforderungen an die
Datenbank nach dem dargestellten Verfahren zunächst einzeln zu modellieren. Für jede Komponente ergeben sich eine Anzahl von Use-Cases und aus jedem Use-Case kann ein Datenmodell entwickelt werden, das einer Sicht auf das Gesamtmodell (sowohl der Datenbank als auch
der Applikationslogik) entspricht.
Diese Modelle müssen anschließend zu einem einheitlichen Gesamtmodell zusammengefügt
werden. Dies entspricht dem in Abschnitt 2.2 erläuterten Problem der Schema-Integration für
verteilte Datenbanken. Auch hier kann die Integration mit Hilfe objektorientierter Techniken in
einigen Schritten erfolgen[Mul99]:
1. Identifikation von strukturellen Ähnlichkeiten in den einzelnen Modellen: Namensähnlichkeiten, ähnliche Beziehungen etc.
2. Mit Hilfe der so gewonnenen Informationen Identifikation von semantischen Gemeinsamkeiten: Unterschiedliche Klassen mit Gemeinsamkeiten in den enthaltenen Informationen,
etc.
3. Integration der gefundenen Ähnlichkeiten in ein Modell:
Beseitigung von Namenskonflikten, Umsetzung semantischer Gemeinsamkeiten der Klassen:
• Gemeinsame Daten in unterschiedlichen Klassen können mit Hilfe von Assoziationen aus-
gedrückt werden (siehe Abbildung 6)
• Ähnliche Klassen können durch Vererbung modelliert werden, wobei gemeinsame Attri-
bute in einer Oberklasse modelliert werden und die unterschiedlichen Details in den entsprechenden Unterklassen (siehe Abbildung 6)
4. Beseitigung verbleibender Inkonsistenzen in den Modellen. Hier muß von Fall zu Fall eine
geeignete Lösung gefunden werden. Eventuell sind auch die einzelnen Modelle entsprechend abzuwandeln. Ein Beispiel für ein solches Problem sind etwa nicht miteinander vereinbare Integritätsbedingungen.
Person
Person
+name:String
+sex:String
+age:Integer
0..1
livesAt
n
Address
Contact
+
+name:String
0..1
contactMethods
n
ContactMethod
+name:String
+sex:String
+age:Integer
0..1
contactMethods
n
ContactMethod
+town:String
+Street:String
Address
+town:String
+Street:String
Abbildung 6: Integration von Klassendiagrammen
18
KAPITEL 3
3.3 Abbildung auf relationale Datenbanken
Das hier beschriebene Verfahren, die Komponenten eines Systems zunächst einzeln zu modellieren, hat zahlreiche Vorteile gegenüber einer geschlossenen Modellierung des gesamten
Systems. Die kleineren Modelle sind zumeist übersichtlicher und einfacher zu erstellen. Durch
die Aufteilung in mehrere Modelle können auch nach der Integration die Komponenten des
Gesamtsystems leichter für eine modulare Entwicklung gruppiert werden. Und aus den einzelnen Modellen sind direkt die unterschiedlichen Benutzersichten für das externe Schema der
Datenbank ableitbar.
3.3 Abbildung auf relationale Datenbanken
Sobald das vollständige Modell einer Applikation und der zugehörigen Datenbank erstellt und
der für die Datenbank relevante Teil, das Datenmodell, festgelegt ist, kann dieses Datenmodell
in ein entsprechendes Datenbank-Schema umgesetzt werden. Während in objektorientierten
Modellen Operationen auf individuellen Objekten ausgeführt werden und Navigation mit Hilfe
von Assoziationen zwischen Objekten erfolgt, arbeiten relationale Datenbanken jedoch mengenbasiert. Operationen werden auf Datenmengen ausgeführt und Navigation erfolgt innerhalb
oder zwischen Mengen von Daten. Aus diesem als impedance mismatch bekannten Problem
ergeben sich zahlreiche Schwierigkeiten bei der Umsetzung eines objektorientierten Modells in
ein relationales Datenbankschema. Im Folgenden soll skizziert werden, wie trotzdem eine recht
einfache Umsetzung eines Teils des Modells möglich ist und welche objektorientierten Modellaspekte nicht oder nur schwer umzusetzen sind.
Klassen und Vererbung
Das objektorientierte Modell besteht aus Klassen und deren Instanzen, den Objekten. Im relationalen Modell werden Informationen dagegen in Form von Relationen, die Tupel von Daten
enthalten, verwaltet. Es liegt nahe, Klassen auf Relationen abzubilden und deren Instanzen als
Tupel ihrer Attributwerte in den Relationen abzulegen. Für jede Klasse kann so eine Relation
in das Datenbankschema aufgenommen werden, die dieselben Attribute hat, wie die darzustellende Klasse. Vererbung kann bei diesem Vorgehen auf unterschiedliche Weisen umgesetzt
werden:
• Jede Vererbungshierarchie wird durch eine Relation dargestellt. Die Relation enthält alle
Attribute der beteiligten Klassen und für Instanzen einzelner Klassen werden nicht definierte Attribute durch null-Werte repräsentiert. Die Hierarchie wird hierdurch geebnet.
• Jede Klasse wird durch eine Relation dargestellt, die alle Attribute der Klasse enthält. Für
jede Instanz einer Klasse existieren Einträge in der zu der Klasse gehörenden Relation und
den Relationen aller Oberklassen.
• Jede Klasse wird durch eine Relation dargestellt, die alle Attribute enthält, die in der Klasse
neu definiert sind, sowie durch eine foreign key-Beziehung zu der Relation der Vaterklasse.
Die Attribute eines Objektes werden entsprechend auf die Relationen für Klasse und Oberklassen aufgeteilt.
Datenbankmodellierung mit UML
19
3.3 Abbildung auf relationale Datenbanken
Die erste Alternative erlaubt einfache Updates und Abfragen. Jedoch ist die Identifikation der
zugehörigen Klasse für ein Tupel der Relation kompliziert und eventuell nicht eindeutig möglich. Dies erschwert die Implementierung von Integritätsbedingungen des OO-Modells. Außerdem wird die Erweiterung der Klassenhierarchie um neue Klassen oder Attribute von Klassen
erschwert. Die letzte Alternative ermöglicht hingegen eine flexible und leicht erweiterbare
Umsetzung der Klassenhierarchie. Jedoch ist das Auslesen der Attribute eines Objektes schwierig, da dies Joins über die Relationen aller Oberklassen des Objektes beinhaltet. Die zweite
Alternative ist ein Kompromiß zwischen den beiden anderen Möglichkeiten. Sie erlaubt eine
etwas flexiblere Umsetzung als Alternative 1 und eliminiert die in Alternative 3 benötigten
Joins. Dafür führt sie aber beträchtliche Datenredundanzen ein, zusammen mit den daraus resultierenden Update-Problemen.
Mehrfachvererbung ist in relationalen Datenbanken nur schwer zu simulieren und sollte nach
Möglichkeit vermieden werden (siehe [Mul99]).
Attribute
Attribute des OO-Modells werden wie gesagt auf Attribute der Relationen abgebildet, die die
Klassen repräsentieren. Im Gegensatz zu UML erlauben relationale Datenbanken nicht die
Definition unterschiedlicher Sichtbarkeiten, so daß Attribute hier grundsätzlich immer als
public umgesetzt werden. Spezielle Wertebereiche oder diskrete Wertemengen können auf
Integritätsbedingungen oder auf Fremdschlüsselbeziehungen zu Wertetabellen abgebildet werden. Diese können entweder eine Abbildung zwischen Programmiersprachen- und DatenbankTypen enthalten, oder direkt die (diskrete) Menge der gültigen Werte eines Attributes definieren. So kann eine solche Wertetabelle etwa den Java-Datentyp String auf den Datenbank-Typ
varchar abbilden oder die Buchstaben „T“ und „F“ als erlaubte Werte zur Repräsentation des
boolean-Datentyps von Java in der Datenbank definieren[Mul99].
Objekt-Identität
Im objektorientierten Modell sind Objekte implizit und unabhängig von ihrem internen
Zustand eindeutig identifizierbar. Um dies auf Tupel in einer relationalen Datenbank abbilden
zu können, muß für jede Relation, die eine Klasse repräsentieren soll, ein geeigneter Primärschlüssel (Objekt Identität, OID) definiert werden. Sind im OO-Modell bereits Attribute für
eine Klasse vorhanden, die Instanzen dieser Klasse eindeutig voneinander unterscheiden, so
können diese verwendet werden. Ansonsten ist ein geeignetes zusätzliches Attribut (etwa eine
Spalte mit eindeutigen Integer-Werten) einzuführen. In der Regel ist die Verwendung eines
zusätzlichen Attributes die bessere Alternative, da dies die Änderung aller Attribute eines
Objektes erlaubt, die in dessen Klasse definiert sind. Ein Attribut der Klasse, das als Schlüssel
definiert ist, kann hingegen nicht geändert werden. Bei Klassenhierarchien ist zu berücksichtigen, daß alle Klassen der Hierarchie dieselben Attribute für ihre OID benutzen sollten und jede
OID innerhalb der Klassenhierarchie eindeutig vergeben sein sollte.
20
KAPITEL 3
3.4 Sichten in UML
Methoden und Signale
Die Möglichkeiten zur Umsetzung von Methoden und Signalen in relationalen Datenbanken
ist relativ beschränkt. Im wesentlichen können Methoden auf stored procedures und Signale
auf Trigger abgebildet werden. Wie Abschnitt 3.1 zeigt, ist es jedoch nicht immer sinnvoll,
Methoden in der Datenbank zu implementieren. Die Implementierung in der Applikationslogik
ist in der Regel flexibler und wird als besseres Design angesehen.
Assoziationen
Assoziationen können mit Hilfe von Schlüsselbeziehungen und Triggern nahezu vollständig
auf relationale Datenbanken abgebildet werden.
Unidirektionale Assoziationen (Referenzen) können direkt auf Schlüssel-FremdschlüsselBeziehungen abgebildet werden. Bei bidirektionalen Beziehungen ist zu beachten, daß beide
Richtungen aus den Relationen extrahierbar sein müssen. Dies kann durch gegenseitige Referenzierung mit Schlüssel-Beziehungen erfolgen, wobei eine Änderung an dem Fremdschlüssel
eines Assoziationspartners mit Hilfe von Triggern eine entsprechende Aktualisierung des
Fremdschlüssels des anderen Partners sicherstellen muß. Alternativ kann die Assoziation wie
eine Referenz umgesetzt werden, wobei die Rückrichtung mit Hile einer entsprechenden Datenbank-Abfrage zu ermitteln ist. Die Kardinalitäten einer Assoziation sind in jedem Fall durch
geeignete Integritätsbedingungen zu gewährleisten. Many-to-many-Assoziationen und n-äre
Assoziationen können mit Hilfe von Assoziationstabellen realisiert werden, die Fremdschlüssel
für alle an der Assoziation beteiligten Klassen enthalten. Auch Assoziationsklassen können
durch entsprechende Assoziationstabellen umgesetzt werden. Aggregation und Komposition
können durch geeignete Trigger auf den beteiligten Fremdschlüsseln umgesetzt werden, wie
etwa kaskadierende Löschoperationen.
Integritätsbedingungen
Da Integritätsbedingungen in UML beliebig komplexe Ausdrücke sein können, ist nicht
gewährleistet, daß diese direkt in Integritätsbedingungen in der Datenbank umgesetzt werden
können. Stattdessen müssen diese häufig mit Hilfe von Triggern und stored procedures realisiert oder sogar in die Applikationslogik verlagert werden.
3.4 Sichten in UML
Die 3-Schicht-Architektur von Datenbanken ermöglicht die Definition von Sichten, die logische Zusammenhänge der Daten im unterliegenden Schema geeignet darstellen. Dies ist möglich, da durch das konzeptionelle Schema der Datenbank eine Zuordnung von semantischen
Informationen aus der Domäne der modellierten Daten zu Attributen in den Relationen gegeben
ist. Man kann hier also von logischen Sichten sprechen (siehe Kapitel 1).
Auch auf UML-Diagrammen ist die Definition von Sichten möglich [Rec01]. Um ein einheitliches Sichtenkonzept für alle UML-Diagrammarten zu gewährleisten, kann ein solches Konzept
aber nur auf den Informationen des UML-Metamodells[UML] basieren, das die Struktur der
Datenbankmodellierung mit UML
21
3.4 Sichten in UML
verschiedenen UML-Diagrammarten definiert. Elemente von UML-Diagrammen werden darin
durch Klassen beschrieben und der mögliche Aufbau der Diagramme durch Assoziationen zwischen diesen Klassen. UML-Diagramme und die darin enthaltenen Elemente sind Instanzen dieser Metamodell-Klassen (Abbildung 8 zeigt das in FUJABA verwendete Metamodell an einem
Beispiel).
Meta-Metamodell
Metamodell
Modell
Benutzerobjekte
Abbildung 7: UML-Metamodell-Architektur
:UMLQualifier
House
no
levels
:UMLClass
:UMLAssoc
name=“levels“
Level
+no : Long
target
name=“House“
:UMLClass
name=“Level“
qualifier
leftRole
rightRole
:UMLRole
:UMLRole
target
qualifierAttrs
attrs
:UMLAttr
name=“no“
Abbildung 8: Klassendiagramm und Metamodell in FUJABA
Da das UML-Metamodell keine semantischen Informationen über das in einem UML-Diagramm dargestellte Modell enthält, ist auf Basis dieser Informationen keine Definition eines
logischen Sichtenmodells möglich.
Jedoch können die Informationen des Metamodells genutzt werden, um ein strukturelles Sichtenmodell zu definieren. Die Darstellung eines UML-Diagrammes als Instanz des Metamodells
resultiert in einer Graphenstruktur (siehe Abbildung 8), dem sogenannten abstrakten Syntaxgraph (ASG, [FNT98]). Durch die Definition von Traversierungsregeln auf diesem Graphen
können Diagrammteile anhand ihrer strukturellen Zusammenhänge identifiziert und in eine
strukturelle Sicht aufgenommen werden. Eine einfache Traversierungsregel kann zum Beispiel
lauten: „Von Klasse A ausgehend sind alle Generalisierungskanten in Richtung der Oberklasse
bis zu einer Tiefe von n zu durchlaufen“.
Die an der Universität GH Paderborn entwickelte UML-Entwicklungsumgebung FUJABA,
deren Entwicklung 1997 im Rahmen einer Diplomarbeit [FNT98] begonnen worden ist, ist im
Rahmen einer Studienarbeit [Rec01] um ein solches Sichtenmodell erweitert worden. Das
22
KAPITEL 3
3.4 Sichten in UML
implementierte Sichtenkonzept ermöglicht die Definition von Traversierungsregeln auf dem
ASG in Form sogenannter Filter. Ein Filter definiert eine Traversierungsregel zur Findung des
1-Kontextes eines ausgezeichneten Knotens im ASG. Der 1-Kontext definiert eine Nachbarschafts-Beziehung zwischen Knoten im ASG. Durch n-fache rekursive Anwendung auf die Elemente des 1-Kontextes kann der n-Kontext eines Knotens ermittelt werden. Eine
Sichtendefinition in FUJABA besteht somit aus der Angabe eines Filters, einer ausgezeichneten
Menge von Diagrammelementen als Startknoten und der Größe des zu berechnenden Kontextes.
Es gibt verschieden Möglichkeiten zur Definition unterschiedlich komplexer Filter in FUJABA.
Einfache Filter können direkt in Java implementiert oder in FUJABA mit UML spezifiziert und
mit Hilfe der Codegenerierungsfunktion von FUJABA als Java-Code exportiert werden. Der
Java-Code kann dann kompiliert und die neuen Filter in die Entwicklungsumgebug geladen
werden.
Um nicht für jeden Spezialfall einer Regel, wie etwa die Verfolgung von Vererbungshierarchien
in Richtung von Unter- oder Oberklassen, einen neuen Filter implementieren zu müssen, erlaubt
FUJABA zudem die Definition parametrisierter Filter. Deren Verhalten kann über zusätzliche
Attribute gesteuert werden. Zur Konfiguration dieser Filter existiert ein generischer Editor, der
die Darstellung und Änderung aller Filter-Attribute ermöglicht.
Sehr komplexe Filter können erzeugt werden, indem einfachere Filter durch Mengenoperationen wie Schnitt- Vereinigungs- und Differenzmengenbildung zu einem Composite-Filter kombiniert werden. Abbildung 8 zeigt die grafische Definition eines solchen Filters inklusive
Auswertungsreihenfolge. Die großen Kästen stellen Filter mit Namen und zu berechnendem
Kontext dar, der kleine Kasten einen Schnittmengenoperator, der ausgefüllte Kreis den Startknoten und die konzentrischen Kreise den Endknoten für die Auswertung..
i:InheritanceFilter
(1)
1.1.1:getResult
1.1.1.1:
getResult
t:TransitionFilter
(2)
1.1:getResult
v
1:getResult
1.1.2:getResult
Abbildung 9: Composite-Filter-Definition und Auswertungsreihenfolge
Die durch dieses Sichtenmodell definierbaren Sichten sind wiederum UML-Diagramme, die
wie ihre Ursprungsdiagramme in FUJABA verändert werden können. Da jede Sicht ein eindeutiges Ursprungsdiagramm hat, können Änderungsoperationen auf den Sichten eindeutig auf das
Ursprungsdiagramm umgesetzt werden. Probleme oder Einschränkungen bei Änderungen, wie
sie etwa in Anhang A für relationale Sichten diskutiert werden, treten nicht auf. Die Sichten in
FUJABA sind als materialisierte Sichten implementiert. Das heißt, daß für jede Sicht ein Diagramm-Objekt in FUJABA angelegt wird, das alle zu der Sicht gehörenden Diagrammelemente
Datenbankmodellierung mit UML
23
3.4 Sichten in UML
enthält. Dieses Sichtendiagramm wird bei jeder Änderung an dem Ursprungsdiagramm mit
Hilfe der Filterregeln der Sichtendefinition neu berechnet.
Das Sichtenmodell in FUJABA ist wie gesagt nicht (oder nur bedingt) zur gezielten Darstellung
logischer Zusammenhänge und semantischer Informationen des jeweiligen Modells geeignet.
Es ermöglicht jedoch die Partitionierung großer Diagramme in mehrere Sichten. Damit erhöht
es die Lesbarkeit und Verständlichkeit umfangreicher und komplexer Spezifikationen, die häufig einige hundert Klassen enthalten können und in denen Diagramme enthalten sind, deren
ASG-Repräsentationen aus mehreren hundert bis einigen tausend Knoten bestehen. Dadurch
wird die Wartung und Modifikation solcher Spezifikationen erheblich erleichtert.
Für weitere Details zu diesem Sichtenmodell, der Definition von Filtern und der Verwendung
von Sichten in FUJABA siehe [Rec01].
24
KAPITEL 3
KAPITEL 4
Zusammenfassung
Datenbank-Schemata sind vielen Rahmenbedingungen bezüglich Effizienz und Redundanzfreihiet unterworfen und vereinen häufig unterschiedlichste Anforderungen in einem Modell.
Daher entspricht ihre Repräsentation der enthaltenen Daten in der Regel nicht den Anforderungen einzelner Benutzer.
Aus diesem Grund erlaubt das ANSI/SPARC-Modell die Definition von Benutzersichten, die
einen gemäß den Anforderungen des jeweiligen Benutzers umstrukturierten Ausschnitt der
Daten aus der unterliegenden Datenbank zeigen. Der Benutzer sieht diese Sicht als in sich
geschlossene Datenbank. Die Sicht repräsentiert jederzeit die Daten der unterliegenden Datenbank und Änderungsoperationen auf der Sicht werden an die Datenbank weitergegeben. Neben
einer geeigneten Darstellung der Datenbankinhalte ermöglicht dies auch eine Zugriffskontrolle
auf Benutzerebene.
Die Definition von Sichten für relationale Datenbanken erfolgt durch Spezifikation einer Datenbankanfrage. Sie ist in Anhang A detailiert beschrieben. Änderungsoperationen sind auf relationalen Datenbanken nur bedingt möglich, da eine eindeutige Transformation auf Änderungen
an der unterliegenden Datenbank nicht immer möglich sind. Anhang A gibt eine Übersicht über
diese Beschränkungen und über Methoden, diese zu lockern, indem für Updateoperationen auf
Sichten eine eindeutige Semantik definiert wird.
Für objektorientierte Datenbanken gibt es keinen Standard für ein einheitliches Sichtenmodell.
Daher sind nur beispielhaft zwei Sichtenkonzepte für unterschiedliche Datenbanken vorgestellt
worden. Im Gegensatz zu relationalen Datenbanken ist hier jedoch die Transformierbarkeit von
Update-Operationen auf Sichten mit Hilfe von objekterhaltender Operatorsemantik sehr einfach
sicherzustellen.
Die Definition und Verwendung von Sichten in verteilten Datenbanken erfolgt analog zum
nicht verteilten Fall. Da Sichten in der Regel durch Anfragen definiert werden und Anfragen
von verteilten Datenbanksystemen transparent umgesetzt werden, ist auch die Verwendung von
Sichten völlig transparent. Da Anfragen auf Sichten in einer verteilten Datenbank meist auf
einer verteilten Anfrage auf den unterliegenden Datenbanken resultieren, werden Sichten in
verteilten Datenbanken meist als materialisierte Sichten realisiert. Diese dienen als Cache für
den Inhalt der Sicht, so daß Performanceverluste durch Netzwerkoperationen vermieden werden.
Für verteilte Datenbanken müssen abhängig von der Datenbankarchitektur Verteilungsschemata definiert oder lokale Schemata zu einem globalen Schema der verteilten Datenbank inte-
25
griert werden. Auch dies kann einfach mit Hilfe von geeigneten Sichtendefinitionen erfolgen,
so daß die Sicht als einheitliches Mittel der Systemadministration dienen kann.
Um die Entwicklung von Datenbanken zusammen mit den hierauf oerierenden Applikationen
in einem geschlossenen Modell zu ermöglichen und die einfache Portabilität des entworfenen
Datenbankschemas auf unterschiedliche Datenbank-Typen sicherzustellen, bietet sich der Entwurf in UML an. In einem UML-Modell kann der Entwurf von Applikationslogik und Datenmodell zusammengefaßt werden, so daß zum Schluß lediglich die für das Datenbankschema
relevanten Teile zu identifizieren und in ein entsprechendes Schema umzusetzten sind.
Abschnitt 3.3 skizziert die Möglichkeiten zur Umsetzung des objektorientierten UML-Modells
in ein relationales Datenbankschema.
26
KAPITEL 4
ANHANG A
Arbeiten mit relationalen Sichten
In diesem Anhang soll die Definition von Sichten in SQL[EN94] und die Behandlung von
Anfragen und Updateoperationen auf diese Sichten erläutert werden. Ferner werden in diesem
Zusammenhang auftretende Probleme und Möglichkeiten zu deren Lösung erläutert. Abschließend wird ein Ausblick auf SQL3 und objektrelationale Datenbanken gegeben.
A.1 Sichtendeklaration in SQL
Die Datendefinitions-Sprache (Data Definition Language, DDL) von SQL92 sieht folgende
Syntax für die Definition einer Sicht vor:
create view <Sichtname> [(<Spaltenname>[,...])]
as <SQL_Anfrage>
[with [cascaded|local] check option]
<Sichtname> steht dabei für den Namen der virtuellen Relation. Die Angabe von Spaltennamen
ermöglicht eine Umbenennung der Spalten der Anfrage. Spaltennamen müssen angegeben werden, falls die Benennung der Spalten der Anfrage nicht eindeutig ist, was zum Beispiel passieren kann, wenn die Anfrage Aggregatfunktionen enthält. Ist die Benennung der Spalten
eindeutig, so ist die Angabe von Spaltennamen optional. Werden Spaltennamen angegeben,
muß ihre Anzahl der Anzahl der Spalten der Anfrage entsprechen. Auf die Direktive with check
option wird in Abschnitt A.2.3im Zusammenhang mit Updateoperationen auf Sichten eingegangen.
Um eine neue Sicht erfolgreich anlegen zu können, muß der Benutzer für alle an der Sicht beteiligten Relationen select-Rechte und für die Domänen aller Attributtypen usage-Rechte haben
(Zu Zugriffsrechten und Domänen/Datentypen in SQL siehe [EN94])
Eine Sicht kann wieder gelöscht werden mit dem SQL-Befehl
drop view <Sichtname> [cascade|restrict]
Hierdurch wird die Definition der Sicht aus der Datenbank gelöscht. Unterliegende Relationen
bleiben unverändert. Mit der cascade-Option werden zusätzlich rekursiv alle Sichten gelöscht,
die diese Sicht in ihrer Definition verwenden. Die restrict-Option verhindert stattdessen das
Löschen von Sichten, auf denen andere Sichten basieren. Wird keine der Optionen angegeben,
ist das Standardverhalten restrict.
27
A.1 Sichtendeklaration in SQL
A.1.1 Sichten-Typen
Obwohl alle Sichten gleich definiert und behandelt werden, bietet sich in der Praxis eine Unterscheidung zwischen verschiedenen Typen an[CBS97]. Diese sollen an einem Beispiel erläutert
werden. Hierzu seien die folgenden drei Relationen-Schemata definiert:
Houses
= (house integer, address char(20),
janitor integer)
Appartments = (appt integer, house integer, size integer,
inhabitant integer, monthlyRent integer)
Persons
= (id integer, forename char(20),
surname char(20))
Zwischen den folgenden Sichtentypen kann unterschieden werden:
Horizontale Sichten
Eine horizontale Sicht ermöglicht die Zugriffsbeschränkung eines Benutzers auf ausgewählte
Tupel einer Relation. Eine solche Sicht wird als horizontal bezeichnet, da sie eine Relation
horizontal - also zwischen ihren Tupeln - aufteilt. Zum Beispiel sollte der Hausmeister von
Haus Nr. 53 nur Informationen über Appartments seines Hauses abfragen können:
create view janitor53Appts as
select * from Appartments
where house=53
Vertikale Sichten
Eine vertikale Sicht ermöglicht die Zugriffsbeschränkung eines Benutzers auf ausgewählte
Attribute einer Relation. Eine solche Sicht wird als vertikal bezeichnet, da sie eine Relation
vertikal - also entlang ihrer Attribute - aufteilt. Zum Beispiel sollte in einem Informationssystem über Appartments der Benutzer nicht den aktuellen Mieter und die monatliche Miete
angezeigt bekommen:
create view infoAppts as
select appt, house, size
from Appartments
Gruppen- und Verbundsichten
In diesem Beispiel wird die Definition einer komplexeren Sicht gezeigt, in der mehrere Relationen miteinander zu einer sogenannten Verbundsicht (engl. join) kombiniert werden und in
der Tupel mit der group-by-Klausel gruppiert werden, um darauf Aggregatfunktionen anzuwenden. Häufig werden Sichten (wie bereits erwähnt) zur Vereinfachung von Anfragen definiert, um häufig auftretende Unteranfragen zu ersetzen. In diesem Beispiel könnte zum
Beispiel die Frage nach der monatlichen Gesamtmiete eines Hauses eine solche Unteranfrage
sein, in deren Kontext eventuell auch häufig die Addresse des jeweiligen Hauses interessant
ist. Das führt dann zu folgender Sichtendefinition:
28
ANHANG A
A.2 Anfragen auf Sichten
create view houseRent (houseNo, address, totalRent) as
select a.house, h.address, sum(a.monthlyRent)
from Houses h, Appartments a
where h.house=a.house
group by a.house
Informationen über die Gesamtmieten und Addressen können mit Hilfe dieser Sicht dann in
einer einfachen Anfrage auf eine einzelne Tabelle formuliert werden.
A.2 Anfragen auf Sichten
Eine Sicht muß per Definition stets das aktuelle Ergebnis der sie definierenden Anfrage reflektieren. Um dies in Anfragen auf einer Sicht sicherzustellen, gibt es im wesentlichen zwei unterschiedliche Möglichkeiten, die im Folgenden kurz erläutert werden sollen.
A.2.1 Sichtenauflösung (view resolution):
Unter Sichtenauflösung versteht man die Integration der Anfrage, die die Sicht definiert, in die
Anfrage, die auf der Sicht ausgeführt werden soll.
Die Auflösung soll anhand des bereits eingeführten Beispiels aus Abschnitt verdeutlicht werden. Eine Anfrage an die Sicht houseRent könnte wie folgt aussehen:
select address, totalRent
from houseRent
where houseNo<=10
order by totalRent
Diese Anfrage wird nun vom Datenbanksystem vor ihrer Ausführung mit der definierenden
Anfrage der Sicht kombiniert. Dies geschieht nach folgenden Regeln:
5. Sichtennamen in der from-Klausel werden durch die from-Listen der definierenden Anfragen ersetzt:
from Houses h, Appartments a
6. Die Attributnamen in der select-Klausel, der where-Klausel, der group by- und havingKlauseln und der order by-Klausel der Anfrage, die Attribute der Sicht bezeichnen, werden
durch Namen der entsprechenden Basisrelationen der definierenden Anfrage ersetzt:
select h.address, sum(a.monthlyRent)
order by sum(a.monthlyRent)
7. Die where-Klausel der Anfrage wird mit der where-Klausel der definierenden Anfrage undverknüpft:
where a.house<=10 and h.house=a.house
8. Die group by- und having-Klauseln der definierenden Anfrage werden der Anfrage hinzugefügt:
Arbeiten mit relationalen Sichten
29
A.2 Anfragen auf Sichten
group by a.house
Enthält die definierende Anfrage der Sicht weitere Sichten, so werden diese Regeln sukzessiv
angewendet, bis nur Basisrelationen in der Anfrage enthalten sind. Die so erhaltene Anfrage auf
Basisrelationen kann nun von dem Datenbank-System ausgeführt werden. Ihr Ergebnis entspricht dem Ergebnis der ursprünglichen Anfrage auf der Sicht.
Dieses Verfahren hat den Vorteil, daß kein Overhead für die Verwaltung der Daten in Sichten
bei Änderung der unterliegenden Relationen entsteht. Der Nachteil ist, daß Anfragen an Sichten
intern in eventuell sehr komplexe Anfragen umgewandelt werden, was lange Antwortzeiten zur
Folge haben kann. Insbesondere in Umgebungen, in denen im Verhältnis zur Änderungshäufigkeit an den Basisrelationen sehr häufig auf Sichten zugegriffen wird, oder wo Anfragen an
Basisrelationen sehr langsam sind (etwa in verteilten Datenbanken, in denen Anfragen an Basisrelationen über ein Netzwerk ausgeführt werden müssen), ist dies unter Umständen nicht akzeptabel. Hier wird häufig das Verfahren der Sichten-Materialisierung (engl. View Materialization)
bevorzugt.
A.2.2 Sichten-Materialisierung (View Materialization)
Eine materialisierte Sicht[GM95] ist eine Sicht, deren Inhalt, wie bei einer Basis-Relation, in
der Datenbank gespeichert wird. Dieser Vorgang wird Materialisierung genannt. Die materialisierte Sicht ist also eine Art Cache für den Inhalt der Sicht. Anfragen auf eine materialisierte
Sicht können dann direkt auf dem Inhalt dieses Caches berechnet werden, als wäre die Sicht
eine Basisrelation. Da die Sicht nicht jedesmal neu berechnet werden muß und die Anfragen
nicht wie oben beschrieben zu komplexeren Anfragen ergänzt werden müssen, ist der Zugriff
auf eine materialisierte Sicht dadurch wesentlich schneller. Ergänzend können für eine materialisierte Sicht genauso wie für eine Basisrelation Index-Strukturen aufgebaut werden, die den
Zugriff weiter beschleunigen.
Der Inhalt einer materialisierten Sicht kann ungültig werden, sobald an einer der Basisrelationen der Sicht Änderungen vorgenommen werden. In diesem Fall muß die Sicht aktualisiert werden. Dieser Vorgang wird als View Maintenance bezeichnet. Wann und wie diese
Aktualisierung stattfinden sollte, ist Thema vieler aktueller Arbeiten ([GM95]). So kann die
Aktualisierung an der Sicht bei jeder Änderung an einer Basisrelation, periodisch in festen
Abständen, bei geringer Auslastung des Systems oder bei der nächsten Anfrage an die Sicht
erfolgen. Jede dieser Optionen hat Vor- und Nachteile. So erzeugt die erste Möglichkeit offensichtlich einen unnötigen Kommunikations- und Rechenoverhead bei mehreren Aktualisierungen an demselben Datum. Die letzte Möglichkeit minimiert diesen Overhead soweit wie
möglich, dafür entstehen aber bei der ersten Anfrage nach Änderungen an den Basisrelationen
eventuell lange Wartezeiten.
In der Regel ist es auch nicht nötig, die Sicht jedesmal vollständig neu zu berechnen. Stattdessen
reicht es häufig, auf Basis der Änderungen an den Basisrelationen die Änderungen an der Sicht
zu berechnen, was als incremental view maintenance bezeichnet wird. Das Problem, zu ent-
30
ANHANG A
A.3 Updateoperationen auf Sichten
scheiden, ob eine Änderung an einer Basisrelation eine Änderung an der Sicht zur Folge hat,
und diese Änderung zu berechnen, ist als incremental view maintenance Problem bekannt.
Eine materialisierte Sicht wird meistens so lange in der Datenbank gehalten, wie auf sie zugegriffen wird. Das heißt, daß die gespeicherten Daten einer materialisierten Sicht erst gelöscht
werden, wenn auf die Sicht für einen gewissen Zeitraum nicht zugegriffen wurde. Wie lang dieser Zeitraum sein sollte, hängt von der Zeit ab, die benötigt wird, um die Sicht neu zu berechnen,
und natürlich von dem zur Verfügung stehenden Speicherplatz. Ein Wert für die Speicherdauer
kann etwa vom Administrator festgelegt oder vom System automatisch abgeschätzt werden.
Auf materialisierte Sichten, ihre Aktualisierung und Anwendungen wird in Kapitel 2 im Zusammenhang mit verteilten Datenbanken noch einmal genauer eingegangen.
A.2.3 Einschränkungen für die Sichtendefinition
Bei der Definition von Sichten ist zu berücksichtigen, daß es einige wichtige Einschränkungen
für die Verwendung bestimmter Sichten in SQL-Ausdrücken gibt[CBS97].
• Wenn in der Definition einer Sicht Spalten mit Hilfe von Aggregatfunktionen definiert wor-
den sind, dürfen diese Spalten in Anfragen auf der Sicht ausschließlich in select- und order
by-Klauseln verwendet werden. Außerdem dürfen diese Spalten nicht als Argument weiterer Aggregatfunktionen verwendet werden.
• Eine Sicht, deren definierende Anfrage Gebrauch von der group by-Klausel macht, kann
nicht mit anderen Sichten oder Basisrelationen zu einer Verbundrelation mittels der joinOperation zusammengefaßt werden.
Desweiteren sollte darauf hingewiesen werden, daß in vielen Datenbank-Systemen die Auswertung der definierenden Anfrage einer Sicht immer auf Basis der Relationenschemata erfolgt, die
bei Definition der Sicht aktuell waren. Wird zum Beispiel eine Sicht definiert durch die Anfrage
select * from Houses
where house<100
und wird nach der Definition dieser Sicht in das Schema der Relation Houses ein weiteres Attribut eingefügt, so erscheint dieses trotzdem nicht in der Sicht.
A.3 Updateoperationen auf Sichten
Während Anfragen auf Sichten relativ unkompliziert sind, stellen Änderungen an den Daten in
einer Sicht häufig ein Problem dar. Um solche Änderungen durchführen zu können, müssen die
Operationen auf einer Sicht in Operationen auf den entsprechenden Basisrelationen transformiert werden können. Das Problem der Herleitung solcher Transformationen ist als View Translation Problem[FC85] bekannt. Da die definierende Anfrage einer Sicht beliebig komplex sein
kann, ist eine Transformation in vielen Fällen garnicht oder nicht eindeutig möglich. Und selbst
Arbeiten mit relationalen Sichten
31
A.3 Updateoperationen auf Sichten
in dem Fall, daß eine solche Transformation eindeutig möglich ist, kann das Ergebnis eventuell
unerwünschte Seiteneffekte auf die veränderte oder eine andere Sicht haben oder sogar Inkonsistenzen in der Datenbank verursachen.
Aus diesen Gründen muß eine Sicht zahlreiche Bedingungen erfüllen, damit Updateoperationen
auf ihr erlaubt sind. Das Grundkonzept dieser Bedingungen ist Folgendes:
Updates auf einer Sicht sind nur dann erlaubt, wenn diese in eindeutiger und wohldefinierter Weise in Updates an den zugrundeliegenden Basisrelationen transformiert werden können.([FC85] und [CBS97])
A.3.1 Änderbare Sichten nach ISO-Standard
Oben genannte Bedingung ist teilweise nicht oder nur in unangemessener Zeit umzusetzen,
weshalb in den meisten aktuellen Datenbanksystemen eine strengere Bedingung zugrunde
gelegt wird:
Damit Updates auf einer Sicht erlaubt sind, muß für jede Zeile oder Spalte einer Sicht
die zugehörige Zeile oder Spalte einer Basisrelation eindeutig identifizierbar
sein.[CBS97]
Auf dieser Basis definiert der ISO SQL Standard einen Katalog von Bedingungen für die definierende Anfrage einer Sicht, so daß eine Sicht genau dann Updateoperationen unterstützen
muß, wenn diese Bedingungen erfüllt sind:
1. Vielfache Vorkommen eines Tupels im Anfrage-Ergebnis werden nicht eliminiert. Die select-Klausel der Anfrage darf also nicht als distinct definiert sein.
2. Jedes Element in der select-Liste ist ein Attributname. Konstanten, Aggregatfunktionen
oder andere Ausdrücke sind nicht erlaubt. Jedes Attribut ist höchstens einmal aufgeführt.
3. In der from-Klausel ist nur eine einzelne Relation definiert. Ist diese Relation eine Sicht, so
muß sie ebenfalls diesen Bedingungen genügen. Dies bedeutet insbesondere, daß Sichten,
die auf Joins, Vereinigungs-, Schnitt- oder Differenzmengen basieren, nicht änderbar sind
4. Die where-Klausel enthält keine geschachtelten Anfragen, die die Relation der from-Klausel verwenden.
5. Es sind keine group by- oder having-Klauseln definiert.
Zusätzlich dürfen Updates keine Integritätsbedingungen der unterliegenden Relationen verletzen. Insbesondere dürfen Attribute der unterliegenden Relationen, die nicht in der Sicht enthalten sind, nicht die Integritätsbedingung not null besitzen. Denn nicht in der Sicht definierte
Attribute werden beim Einfügen neuer Tupel in die Sicht in der Basisrelation durch null-Werte
ergänzt.
Entgegen den Bedingungen des ISO-Standards können auch für eine Vielzahl von Sichten, die
diesen Bedingungen nicht genügen, Updateoperationen sinnvoll transformiert werden, jedoch
32
ANHANG A
A.3 Updateoperationen auf Sichten
mit einem zum Teil erheblichen Mehraufwand. Dies führt zusammenfassend zu einer groben
Einteilung von Sichten in drei Kategorien ([CBS97] und [EN94]):
1. Sichten, die nach dem ISO-Standard änderbar sind. Dies sind im wesentlichen Sichten, die
durch eine einfache Anfrage auf einer einzelnen Basisrelation definiert sind und den Primär-Schlüssel oder einen Sekundär-Schlüssel der Relation enthalten.
2. Sichten, die nicht änderbar sind. Dies sind insbesondere Sichten, deren Attribute alle über
Aggregation definiert sind.
3. Sichten, die nicht den Bedingungen des ISO-Standards genügen, deren Updateoperationen
jedoch trotzdem in wohldefinierter Weise in Updateoperationen auf Basisrelationen transformiert werden können.
Auf die Sichten der dritten Klasse soll im Folgenden noch weiter eingegangen werden.
Zunächst werden jedoch anhand einiger Beispiele die Probleme verdeutlicht, die bei
Updateoperationen auf Sichten auftreten können, die nicht den ISO-Bedingungen genügen.
• Der Effekt der Operation entspricht nicht der Erwartung:
Folgende Sicht entspricht nicht den ISO-Bedingungen, da es sich um eine Verbundsicht auf
mehr als einer Basis-Relation handelt:
create view janitors as
select house, forename, surname
from Houses h, Persons p
where h.janitor=p.id
Das Einfügen eines neuen Tupels (53, „Hans“, „Meier“) in diese Sicht muß transformiert
werden in Einfügeoperationen auf Houses und Persons. Es ergeben sich die Tupel (53, null,
null) und (null, „Hans“, „Meier“). Da aber der Vergleich mit null-Werten per Definition
immer fehlschlägt, wird nicht das gewünschte Ergebnis erreicht, da die Sicht anschließend
das neue Tupel nicht enthält.
• Die Transformation ist nicht eindeutig:
Soll zum Beispiel im Tupel (1, „Peter“, „Müller“) der janitors-Sicht der Vorname
durch „Klaus“ ersetzt werden, so kann diese Operation in unterschiedliche Operationen auf
den Basisrelationen transformiert werden. Eine Möglichkeit ist das Ersetzen des Namen in
der Basisrelation Persons. Ebenso kann aber eine neue Person Klaus Müller angelegt und
Haus 1 als Hausmeister zugewiesen werden.
• Eine Operation erzeugt mehrere Veränderungen auf der Sicht
Wird in dem vorangegangenen Beispiel die erste Möglichkeit zur Transformation gewählt,
so werden alle Tupel der Sicht verändert, die denselben Hausmeister haben.
• Eine Operation erzeugt mehrere Veränderungen auf einer Basisrelation
Ein Überblick über die Mietpreise und Größen der Appartments kann als Sicht deklariert
werden durch
create view apptRents as
select appt, monthlyRent, avg(size) as avgSize
Arbeiten mit relationalen Sichten
33
A.3 Updateoperationen auf Sichten
from Appartments
group by monthlyRent
Eine Erhöhung der Monatsmiete von 1000 DM auf 2000 DM in einem Tupel muß transformiert werden in eine Änderung aller Tupel der Basisrelation mit 1000 DM Miete.
• Eine Operation kannn nicht sinnvoll transformiert werden
In obigem Beispiel ist es nicht möglich, Updates an dem Attribut avgSize sinnvoll zu transformieren, da es sich um einen errechneten Wert handelt.
Ein weiteres Problem ergibt sich, wenn ein Tupel einer Sicht so geändert wird, daß es anschließend nicht mehr der Bedingung der definierenden Anfrage der Sicht genügt. Sind zum Beispiel
in einer Miethausverwaltung zwei Sichten für Sachbearbeiter für Sozial- und Studentenwohnungen und Luxusappartments wie folgt definiert
create view social as
select * from Appartments
where monthlyRent<1000
create view luxurious as
select * from Appartments
where monthlyRent>20000
Der Sachbearbeiter für Sozialwohnungen könnte nun in seiner Sicht die Miete einer Wohnung
von 750 auf 25000 DM ändern. Dies hätte zur Folge, daß die Wohnung nicht mehr in seinen
Aufgabenbereich fällt, aber in der Sicht des anderen Mitarbeiters erscheint. Dieses Verhalten
wird als Migration aus der Sicht bezeichnet[CBS97].
Die Definition des Verhaltens der Datenbank in einem solchen Fall erfolgt in SQL bei der Sichtendefinition durch die with [cascaded|local] check option-Option. Ist diese Option nicht angegeben, sind Updates, die die Migration von Tupeln aus der Sicht bewirken, erlaubt. Ist eine Sicht
mit der Option with local check option definiert, so sind keine Updates auf der Sicht oder einer
auf dieser Sicht definierten Sicht erlaubt, die die Migration eines Tupels aus der Sicht bewirken,
es sei denn das Tupel wird ebenfalls aus der unterliegenden Relation entfernt. Ist die Sicht mit
der Option with cascaded check option oder nur with check option definiert, sind alle Updates
verboten, die ein Tupel aus der Sicht migrieren lassen.
Mit Hilfe der with check option ist es also möglich, eine einfache und effektive Hierarchie von
Integritätsbedingungen für Updates auf Sichten zu definieren. Die Integritätsbedingungen werden dabei durch die Selektionsbedingungen der definierenden Anfragen festgelegt.
A.3.2 Das View Update Problem jenseits des ISO Standards
Neben den Sichten, die den Bedingungen des ISO Standards genügen, gibt es eine Vielzahl weiterer Sichten, für die eine eindeutige Transformation der Operationen möglich ist. Häufig werden hierfür dann aber bei der Definition der Sichten zusätzliche Informationen benötigt, um
mehrdeutige Transformationsmöglichkeiten zu eliminieren und den jeweiligen Updateoperationen für eine Sicht dadurch eine eindeutige Semantik zu geben[FC85]. Hierfür sollen im Folgenden einige Ansätze beschrieben werden.
34
ANHANG A
A.3 Updateoperationen auf Sichten
Dazu soll das View Update Problem aber zunächst formaler beschrieben werden. Hierzu werden sowohl Sichten als auch Updateoperationen als Transformationsoperationen von einem
Datenbank-Zustand in einen anderen interpretiert:
Sei S ein Datenbankschema und V eine Sicht auf S (der Ausdruck Sicht bezeichnet hier wieder
eine Sicht auf die gesamte Datenbank, anstatt einer einzelnen virtuellen Relation). Seien s und
s’ konsistente Zustände von S und v und v’ konsistente Zustände von V, u ein Update von V
und t ein Update von S. Sei ferner f eine Abbildung von konsistenten Zuständen von S auf konsistente Zustände von V (für relationale Datenbanken wäre f also gegeben durch die definierenden Anfragen aller virtuellen Relationen) und USdie Menge aller Updates t, die einen
konsistenten Zustand s von S wieder in einen konsistenten Zustand überführen. Damit t ∈ T als
Transformation von u in Frage kommt, muß gelten:
f(s) = v ∧ u(v) = v' ∧ t(s) = s' ÿ f(s') = u'
t heißt exakte Transformation von u auf S genau dann, wenn t obige Bedingung erfüllt und unter
Berücksichtigung der Integritätsbedingungen von S jeden konsistenten Zustand von S wieder in
einen konsistenten Zustand überführt. t heißt ferner (minimal) akzeptierbar, wenn t den Zustand
von S unverändert läßt für den Fall, daß u den Zustand von V nicht verändert, wenn also gilt:
u(f(s)) = f(s) ÿ t(s) = s
Sei UV die Menge aller erlaubten Updateoperationen auf V. Dann besteht das View Update Problem daraus, eine eindeutige Translations-Abbildung TU zu finden, die jedem u aus UV genau
ein exaktes und akzeptierbares t aus US zuordnet und die distributiv ist in Bezug auf die Hintereinanderausführung von Sichtenupdates u. Dieser Zusammenhang ist in Abbildung 10 noch einmal grafisch dargestellt.
u=u1° u2
v
TU
f
s
v’
u1
t1
u2
TU
f
s’
t2
v’’
f
TU(u1°u2)=TU(u1)°TU(u2)
s’’
t=t1° t2
Abbildung 10: Die Translations-Abbildung TU
Anhand von TU können Sichten damit in drei Kategorien eingeteilt werden[CBS97]:
• nicht updatefähige Sichten, für die kein TU existiert oder mehrere mögliche TU existieren
und keine zusätzlichen Informationen zur Auflösung dieser Uneindeutigkeit gegeben sind.
• partiell updatefähige Sichten, für die ein eindeutiges TU nur für eine Teilmenge der mögli-
chen Updateoperationen existiert
Arbeiten mit relationalen Sichten
35
A.3 Updateoperationen auf Sichten
• (theoretisch) updatefähige Sichten, für die ein eindeutiges TU existiert (theoretisch, da
lediglich eine Aussage über die Existenz von TU gemacht wird, dieses aber in einzelnen
Fällen nicht oder nicht notwendig in akzeptabler Zeit zu finden ist)
Die folgenden Abschnitte zeigen unterschiedliche Ansätze, den Updateoperation auf einer Sicht
eine eindeutige Semantik zu geben und sie so updatefähig zu machen.
Eindeutige Update-Semantik durch abstrakte Datentypen
Eine Möglichkeit, für Updateoperationen auf einer spezielle Sicht eine eindeutige Semantik zu
finden, ist es, diese explizit festzulegen. In diesem Ansatz wird eine Sicht als abstrakter Datentyp betrachtet, der neben der eigentlichen Sichtendefinition eine Definition aller erwünschten
Updateoperationen für die Sicht enthält. Die zu definierenden Operationen werden dabei aus
der Anwendung der Sicht abgeleitet (application orientated operations [FC85]).
Für die in Abschnitt A.3.1 deklarierte Sicht janitors wären zum Beispiel die Operationen
hire, fire, replace und transfer zum Einstellen, Entlassen, Ersetzen und Versetzen eines Hausmeisters denkbar.
Die Einführung von abstrakten Datentypen ist zwar, wie die Klasse der Objekt-Relationalen
Datenbanken (siehe Abschnitt A.4.2) zeigt, für relationale Datenbanken möglich. Jedoch erfordert sie die Definition zusätzlicher Sprachkonstrukte. Zudem ist die Definition und Pflege von
Update-Operationen erforderlich, was die Erzeugung von Sichten deutlich aufwendiger macht.
Andererseits hat dieser Ansatz den Vorteil, daß er eine hohe Flexibilität bei der Transformation
der Updateoperationen auf Basisrelationen ermöglicht. Außerdem folgen weitere Vorteile, wie
eine benutzerfreundlichere Schnittstelle und eine bessere Integritätssicherung durch Kapselung,
von der auch Basisrelationen profitieren können.
Sichtenupdate durch Abhängigkeitsgraphen
Dieser Ansatz verwendet die Abhängigkeits-Struktur der unterliegenden Basis-Relationen, um
Updateoperationen auf Sichten eindeutig zu machen.
Hierzu sind die Sichten und unterliegenden Schemata jedoch einigen entscheidenden Einschränkungen unterworfen:
• Die funktionalen Abhängigkeiten im konzeptionellen Schema müssen auf einzelne Attribut-
paare beschränkt sein und jede Basisrelation muß einen Primärschlüssel haben.
• Update-Operationen sind auf das Löschen und Ersetzen von Tupeln und das Einfügen ein-
zelner Tupel beschränkt.
• Sichten sind von der Form
create view V (c1,...,cn) as
select ti1.aj1,...,tin.ajn
from R1 t1,...,Rm tm
where <cond>
36
ANHANG A
A.3 Updateoperationen auf Sichten
wobei <cond> nur Bedingungen der Form t.a=k und t.a=u.b enthält. Die Attribute ajk werden dann als Erzeugende der Sichtenattribute ck bezeichnet (für k ∈ [1,n] ).
Die Struktur dieser Sichtendefinition und der funktionalen Abhängigkeiten des unterliegenden
Schemas kann dann in Form eines gerichteten Sichtenabhängigkeits-Graphen G(V) dargestellt
werden, der bei der Definition der Sicht automatisch angelegt und berechnet werden kann. Er
hat folgende Form:
• Für jedes Attribut der Relationen R1...Rm, jedes Sichtenattribut c1...cn und jede Konstante k
der Bedingung enthält er einen Knoten mit dem Namen des Attributes bzw. dem Wert de
Konstante
• Für jedes ck existiert eine bidirektionale Kante zu dem erzeugenden Attribut ajk
• Für jede Gleichung der Bedingung existiert eine bidirektionale Kante zwischen den beiden
Operanden
• Für jede funktionale Abhängigkeit Rk: a i → a j des konzeptionellen Schemas existiert eine
Kante (Rk.ai, Rk.aj)
• Für jeden Knoten Rk.a mit einem Pfad zu einem Knoten mit einem konstanten Wert existie-
ren Kanten (Ri.aj, Rk.a) für die Attribute aller Relationen Ri der from-Klausel
Aufgrund der Einschränkungen für Updateoperationen haben diese eine recht einfache Struktur,
so daß mit Hilfe dieser Struktur allgemeine Transformationen für diese Operationen angegeben
werden können, in die dann lediglich die Ausdrücke der jeweiligen konkreten Operationen eingestezt werden müssen. Hierfür gibt es in der Regel mehrere Möglichkeiten, von denen nicht
jede eine exakte Transformation der ursprünglichen Operation ist. Mit Hilfe des Abhängigkeitsgraphen können jedoch die Transformationen eliminiert weden, die keine exakten Transformationen sind. Dies soll anhand eines Beispiels verdeutlicht werden:
Eine einfache Löschoperation hat die Form
delete from V
where cn1=k1 and ... and cnp=kp
Die Transformation dieser Operation hat die allgemeine Form
delete from Ri where Ri.ai in
(select ti.ai
from R1 t1,...,Rm tm
where <cond> and sn1=k1 and ... and snp=cp)
wobei sj das Attribut bezeichnet, das das Sichtenattribut cj erzeugt hat und i ∈ [1,m] beliebig
ist. Damit gibt es m mögliche Transformationen. Es kann aber gezeigt werden, daß nur die
Transformationen exakt sind, für die für alle cj von V ein Pfad zu einem Attribut von Ri exi-
Arbeiten mit relationalen Sichten
37
A.3 Updateoperationen auf Sichten
stiert[FC85]. Für insert- und update-Operationen können ähnliche Regeln gefunden werden[DB82].
Dieses Verfahren hat den Vorteil, daß alle benötigten Informationen bei der Definition einer
Sicht vorhanden sind und keine zusätzliche Arbeit für den Benutzer entsteht. Der Nachteil ist,
daß das Verfahren deutliche Einschränkungen hinsichtlich Schema, Sichten und Updateoperationen macht. Ferner liefert es zwar exakte Transformationen (so solche existieren), jedoch ist
es immernoch nicht-deterministisch, da eventuell mehrere exakte Transformationen gefunden
werden. In diesem Fall sind weitere Informationen und Berechnungsschritte nötig, wie sie etwa
im folgenden Abschnitt vorgestellt werden.
Eindeutige Update-Semantik durch Sichtenkomplemente
Eine weitere Möglichkeit, die Semantik einer Updateoperation eindeutig zu definieren, ist die
Spezifikation der Relationen und Attribute der Datenbank, die durch ein Update der Sicht nicht
verändert werden dürfen. Auf diesem Wege können alle Transformationen der Updateoperation, die dieser Spezifikation nicht genügen, ausgeschlossen werden. In [BS81] wird gezeigt,
daß durch die Spezifikation eines solchen Sichtenkomplements jede Mehrdeutigkeit eliminiert
wird und die Semantik der Updateoperationen damit eindeutig definiert ist. Desweiteren kann
die Translations-Abbildung für die Updateoperationen mit Hilfe des Sichtenkomplements vom
System bestimmt werden, so daß Updates automatisch transformiert beziehungsweise als nicht
transformierbar erkannt und abgelehnt werden können.
Das Kernelement dieses Ansatzes ist wie gesagt das Sichtenkomplement, das zunächst genau
definiert werden soll. Informal kann ein Sichtenkomplement zu einer Sicht V beschrieben werden als eine Sicht V’, die alle Informationen der Datenbank enthält, die in V nicht enthalten
sind. Das heißt, daß aus V und V’ stets die ursprüngliche Datenbank rekonstruiert werden kann.
Formal bedeutet dies für die Sichten V und V’ mit den Abbildungsfunktionen f und f’ (siehe
Abschnitt A.3.2):
Sei f'' = f × f' eine Funktion mit f''(s) = (f(s),f'(s)) . V’ ist ein Komplement zu V, genau dann,
wenn f’’ beschränkt auf konsistenten Datenbankzustände s eine bijektive Abbildung ist.
f’’ bildet also einen Datenbankzustand bijektiv auf die Zustände einer Sicht und ihres Komplements ab. Daher ist es möglich, mittels f’’ von einem konsistenten Datenbankzustand s ein Paar
von zugehörigen Zuständen (v, v’) der Sicht und ihres Komplements zu berechnen und umgekehrt mittels f’’-1, ohne Informationen zu verlieren.
Eine Transformation von Updateoperationen u unter einem konstanten Sichtenkomplement
kann beschrieben werden durch die Suche nach einem Datenbankzustand s’, so daß
f(s') = u(f(s)) ∧ f'(s') = f'(s) gilt. Durch die Definition eines konstanten Sichtenkomplements
V’ ist s’ eindeutig. Existiert s’ für alle konsistenten Zustände s, so heißt u V’-transformierbar.
Die Transformation kann dann erfolgen durch den von V’ induzierten Translator TV’ mit
–1
T V'(u) = f'' ° ( u × I )°f''
wobei I die identische Abbildung bezeichnet.
38
ANHANG A
A.4 Ergänzungen zum relationalen Sichtenmodell
Das Vorgehen für den Umgang mit Sichtenupdates ist dann folgendes: Der Datenbankadministrator gibt - unterstützt vom System - zusätzlich zu einer Sicht ein entsprechendes Komplement
an, das bei Updates auf der Sicht unverändert bleiben soll. Anschließend ist vom System ein
geeigneter Translator zu berechnen, mit dessen Hilfe dann jedes Update auf der Sicht entweder
eindeutig und wohldefiniert in Updates der Basisrelationen transformiert werden kann oder als
ungültig abgelehnt wird.
In der Praxis bleibt das Problem offen, für beliebige Sichten geeignete Komplemente zu finden,
beziehungsweise zu überprüfen, ob eine Sicht das Komplement einer anderen ist. Ferner ist für
den allgemeinen Fall die Berechnung von f’’-1 ein offenes Problem.
In [CP84] ist ein Verfahren zur Berechnung von Komplementen für eine sehr eingeschränkte
Klasse von Sichten (Sichten bestehend aus einer Relation mit einfachen funktionalen Abhängigkeiten als einzige Integritätsbedingungen) in Polynomialzeit und für die Berechnung des
Translators gegeben.
Eine andere Möglichkeit wird in [Chan83] dargestellt. Hier wird das Sichtenkomplement ebenfalls nur auf sehr einfache Sichten (eine Relation, keine Integritätsbedingungen und nur ein relationaler Operator in der Abfragebedingung) angewendet. Ferner wird vorgeschlagen,
Operationen auf komplexere Sichten zusammen mit den Sichtendefinitionen durch einen Interpreter analysieren zu lassen. Der Interpreter soll dann die Operationen als Operationen auf einfachen Sichten interpretieren, die den oben genannten Bedingungen genügen und die durch
Schachtelung die ursprüngliche Sicht repräsentieren.
A.4 Ergänzungen zum relationalen Sichtenmodell
A.4.1 Virtuelle Attribute in SQL3
Zusätzlich zu virtuellen Relationen unterstützt SQL3 eine Erweiterung des relationalen Sichtenmodells: virtuelle Attribute oder virtuelle Spalten. Basisrelationen können um solche virtuellen
Spalten erweitert werden, deren Inhalt ähnlich zu virtuellen Relationen dynamisch durch eine
relationale Datenbankanfrage definiert ist.
A.4.2 Objektrelationale Datenbanken und Objektsichten
Objektrelationale Datenbanken erweitern herkömmliche relationale Datenbanken um ein komplexeres Typsystem mit Objektorientierung. Klassen werden hierbei auf spezielle Relationen sogenannte Objekttabellen - abgebildet, Objekte auf Tupel in diesen Tabellen. Ein Standard für
objektrelationale Datenbanken ist SQL3.
SQL3 unterstützt neben herkömmlichen relationalen Sichten sogenannte Objektsichten. Ebenso
wie herkömmliche relationale Sichten virtuelle Relationen sind, sind Objektsichten virtuelle
Arbeiten mit relationalen Sichten
39
A.4 Ergänzungen zum relationalen Sichtenmodell
Objekt-Tabellen. Sie werden definiert durch eine eine typisierte Sichtendefinition und eventuell
eine zusätzliche Typ- beziehungsweise Klassendefinition für die Objekte in der Objekt-Tabelle.
Eine solche Sichtendefinition kann zum Beispiel folgendermaßen aussehen:
create table employees (
empnum Integer,
name VarChar,
job VarChar )
create type developer (
empno Integer,
name VarChar,
function ...)
create view developerView of developer
with object oid (empno) as
select empnum, name
from employees
where job = ’Developer’
Die Klausel with object oid gibt dabei die Attribute der Objekt-Tabelle an, die ein Objekt eindeutig identifiziert. Aus den Werten dieser Attribute wird dann eine eindeutige Obejkt-ID für
jedes Objekt der Objektsicht errechnet. Die angegebenen Attributnamen müssen daher für die
Sicht mindestens einen Candidate Key bezeichnen. In den meisten Fällen handelt es sich um die
Primärschlüssel-Attribute der unterliegenden Relationen.
Updates auf Objekt-Sichten sind in der Regel genau dann erlaubt, wenn auch Updates auf einer
herkömmlichen Sicht mit der gleichen definierenden Anfrage erlaubt sind. Zusätzlich bietet
sich hier der bereits in Abschnitt A.3 vorgestellte Ansatz an, weitere Updates durch die explizite
Definition von Update-Funktionen für die Objekte der Sicht zu ermöglichen. In Oracle[Ora8i]
wird dies zum Beispiel durch sogenannte instead of-Trigger ermöglicht, die bei Updates an den
Objekten an Stelle der normalen Update-Operation ausgeführt werden.
40
ANHANG A
ANHANG B
Literaturverzeichnis
[Boo94]
Grady Booch. Objektorientierte Analyse und Design. Addison Wesley, 1994.
[EN94]
R. Elmasri and S.B. Navathe. Fundamentals of Database Systems. Benjamin/
Cummings, Redwood City, 2nd edition, 1994.
[FNT98]
T. Fischer, J. Niere, and L. Torunski. Konzeption und Realisierung einer integrierten Entwicklungsumgebung für UML, Java und Story-Driven-Modeling (in german). Master’s thesis, University of Paderborn, Paderborn, Germany, July 1998.
[Jac95]
I. Jacobson. Object oriented software engineering: a use case driven approach.
Addison Wesley, 1995.
[Rum94]
James Rumbaugh. Objektorientiertes Modellieren und Entwerfen. Hanser, 1994.
[UML]
Rational Software Corporation. UML documentation version 1.3 (1999). Online
at http://www.rational.com.
[Rec01]
C. Reckord. Entwurf eines generischen Sichtenkonzeptes für die Entwicklungsumgebung Fujaba. Studienarbeit, University of Paderborn, Paderborn, Germany,
Feb 2001.
[Mul99]
R.J. Muller. Database Design for Smarties - Using UML for Data Modeling. Morgan Kaufmann Publishers, 1999.
[BG92]
D. Bell and J. Grimson. Distributed Database Systems. Addison Wesley, 1992.
[GL01]
J. Goldstein and P. Larson. Optimizing queries using materialized views: A practical, scalable solution. In Proc. of ACM SIGMOD Conf. on Management of Data,
2001.
[BS81]
F. Bancilhon & N. Spyratos. Update semantics of relational views. ACM Transactions on Database Systems, (4) 557--575, 1981.
[AB91]
S. Abiteboul and A. Bonner. Objects and Views. In Clifford and R.King, editors,
Proc. ACM SIGMOD Conf. on Management of Data, pages 238-247, Denver, Co,
May 1991, ACM New York.
41
42
ANHANG B
ANHANG C
Abbildungsverzeichnis
ABBILDUNG 1: DIE DREI-SCHICHT-ARCHITEKTUR DES ANSI/SPARC-MODELLS ................ 1
ABBILDUNG 2: VERTEILTE DATENBANKARCHITEKTUREN ...................................................... 9
ABBILDUNG 3: USE-CASE-DIAGRAMM ................................................................................. 16
ABBILDUNG 4: KOLLABORATIONSDIAGRAMM »PROCESS ORDER« ....................................... 16
ABBILDUNG 5: KLASSENDIAGRAMM ..................................................................................... 17
ABBILDUNG 6: INTEGRATION VON KLASSENDIAGRAMMEN ................................................. 18
ABBILDUNG 7: UML-METAMODELL-ARCHITEKTUR ............................................................ 22
ABBILDUNG 8: KLASSENDIAGRAMM UND METAMODELL IN FUJABA ................................... 22
ABBILDUNG 9: COMPOSITE-FILTER-DEFINITION UND AUSWERTUNGSREIHENFOLGE ........... 23
ABBILDUNG 10: DIE TRANSLATIONS-ABBILDUNG TU ........................................................... 35
43