![](media/image1.wmf){width="1.125in" height="0.5625in"}TU Wien

![](media/image2.wmf){width="0.7104166666666667in" height="0.75in"}

Business Informatics Group

Institut für Softwaretechnik und Interaktive Systeme

Seminar Grundlagen wissenschaftlichen Arbeitens

Multimedia und Datenbanksysteme

Leitung: Wolfgang Hoschek

Elisabeth Kiss 0206088

Susanne Kiss 0206087

Wien, 10. April 2003

Inhaltsverzeichnis:

[**1 Multimedia (Kap. E2) 2**](#multimedia-kap.-e2)

[1.1 Einleitung 2](#einleitung)

[1.2 Charakteristika und Paradigmen 2](#charakteristika-und-paradigmen)

[1.3 Grundlegende Konzepte 4](#grundlegende-konzepte)

[1.3.1 Synchronisation 4](#synchronisation)

[1.3.2 Dienstgüte 6](#dienstgüte)

[1.3.3 Ströme 8](#ströme)

[1.3.4 Zeitkapseln 8](#zeitkapseln)

[1.3.5 Konfigurationsverwaltung 9](#konfigurationsverwaltung)

[1.4 Handhabung von Multimediadaten 9](#handhabung-von-multimediadaten)

[1.4.1 Interaktion 9](#interaktion)

[1.4.2 Codierung 10](#codierung)

[1.4.3 Codierung von digitalem Video 11](#codierung-von-digitalem-video)

[1.4.4 Speicherung 13](#speicherung)

[1.4.5 Interpretation 13](#interpretation)

[1.5 Systemunterstützung 14](#systemunterstützung)

[1.5.1 Netwerke und Kommunikationsdienste
14](#netwerke-und-kommunikationsdienste)

[1.5.2 Betriebssysteme 15](#betriebssysteme)

[1.6 Hypertext / Hypermedia 16](#hypertext-hypermedia)

[1.6.1 Grundbegriffe 16](#grundbegriffe)

[1.6.2 Das Dexter-Modell 17](#das-dexter-modell)

[1.6.3 Weitergehende Aspekte 17](#weitergehende-aspekte)

[1.6.4 Das World-Wide-Web als Hypertextsystem
18](#das-world-wide-web-als-hypertextsystem)

[1.7. Zusammenfassung 19](#zusammenfassung)

[2 Datenbanksysteme 20](#datenbanksysteme)

[2.1 Anforderungen und Eigenschaften
20](#anforderungen-und-eigenschaften)

[2.2 Datenmodelle und Datendefinition
20](#datenmodelle-und-datendefinition)

[2.2.1 Konzepte 21](#konzepte)

[2.2.2 Das Relationenmodell 22](#das-relationenmodell)

[2.2.3 Datenmodelle mit Objektkonzepten
25](#datenmodelle-mit-objektkonzepten)

[2.3 Datenzugriff und -manipulation 27](#datenzugriff-und--manipulation)

[2.3.1 Konzepte 28](#konzepte-1)

[2.3.2 Anfragesprachen 28](#anfragesprachen)

[2.3.3 Sichten 31](#sichten)

[2.4 Steuerung und Überwachung 32](#steuerung-und-überwachung)

[2.4.1 Zugriffsschutz 32](#zugriffsschutz)

[2.4.2 Konsistenzsicherung 34](#konsistenzsicherung)

[2.4.3 Transaktionen 35](#transaktionen)

[2.4.4 Verteilung 37](#verteilung)

[2.5 Zusammenfassung: 38](#zusammenfassung-1)

[3 Referenzliste 38](#referenzliste)

[3.1 Multimedia 38](#multimedia)

[3.2 Datenbanksysteme 39](#datenbanksysteme-1)

# 1 Multimedia (Kap. E2)

## Einleitung

Nach einer Definition von Steinmetz ist ein Multimedia-System durch
**die rechnergestützte koordinierte Handhabung mehrerer, zumindest
teilweise zeitabhängiger Medien** gekennzeichnet. Medien sind dann
zeitabhängig wenn für deren Darstellung ein inhärenter Zeitbegriff
wesentlich ist, z.B. Audio und Video koordiniert.

Die *Realzeitanforderungen* sind in zweierlei Hinsicht, für
Multimediasysteme schwächer als für gewöhnliche Realzeitsysteme.

1.  Der Ressourcenbedarf ist vorhersehbar, wenn mit konstanter Rate
    Bedienzeiten konstanten Umfangs angefordert werden.

2.  Überschreitungen von Fristen, werden meist nicht als fehlerhaftes
    Verhalten interpretiert, sondern als graduelle Verschlechterung der
    Medienqualität.

Medien mit den genannten Eigenschaften werden in der
Multimedia-Literatur meist als *isochron* bezeichnet. Computergenerierte
Medien werden meist so modelliert, dass sich ein nicht-isochroner
Datenstrom ergibt, z.B. Animationen, maschinenlesbare Aufzeichnungen
interaktiver Bildschirmsitzungen und interaktive virtuelle Welten. Bei
der Entwicklung von Multimedia-Software treffen zwei Arbeitsbereiche
aufeinander, zum einen treffen die gestalterische Arbeit eines Autors
oder Designers und zum anderen die ingeneursmäßig oder algorithmisch
geprägte Tätigkeit eines Software-Entwicklers aufeinander. Man
unterscheidet daher zwischen so genannten Autorenwerkzeugen
(Autorensysteme, Hypermediasysteme, Ergebnis = *Dokument*) und
Software-Entwicklungsumgebungen (Mikrowelten oder *Frameworks*).

## Charakteristika und Paradigmen

**Autorensysteme** erlauben die Erstellung von Multimedia-Dokumenten,
dies sind jene die bei den Endbenutzern interaktiv dargestellt werden.
Dazu wird meist eine der folgenden drei Metaphern verwendet:

-   **Zeitleisten-Metapher:** Bei jener werden ähnlich wie bei einem
    komfortablen Videoschnittsystem Medienfragmente miteinander zu einem
    fortlaufenden Film kombiniert.

-   **Karten-Metapher:** Hierbei werden Präsentationen als Stapel von
    Karteikarten aufgefasst, sequentielles Lesen und Sprünge zu
    entfernten Karten sind intuitiv erfassbar.

-   **Flussdiagramm-Metapher:** Hierbei werden Elemente eines
    Steuerflusses wie Videopräsentation, Abfrage oder Verzweigung zu
    einem Dokument verknüpft. Häufig werden Elementtypen graphisch durch
    anschauliche Sinnbilder unterschieden.

**Hypermediasysteme** erlauben die flexible Verknüpfung von
Informationseinheiten (Dokumentfragmente) mittels Verweisen und
erweitern entweder die Karten-Metapher oder lehnen sich stärker an das
Konzept des herkömmlichen Textdokuments an. Der Begriff Mikrowelten
bezeichnet „geschlossene" Entwicklungsplattformen für Einzelrechner. Sie
vereinen ein universelles Multimedia-Datenformat mit Werkzeugen und
Laufzeitunterstützung gemäß einer umfassenden Architektur. Als
*Framework* bezeichnet man zunehmend offene Entwicklungsplattformen für
Multimedia-Anwendungen, Entwicklungen kommen bisher vor allem aus dem
akademischen Bereich.

**Anwendungen:** Anwendungsfelder betreffen praktisch das *ganze*
Spektrum der Informatik. Neben der Multi/Hypermedia-Dokumentbearbeitung
spielen hauptsächlich verschiedene Varianten von so genannten
**Telemedia-Anwendungen** eine Vorreiterrolle:

-   **Multimedia-Mitteilungssysteme:** Jene erweitern elektronische
    Mitteilungsdienste (electronic mail) zur Unterstützung für
    zeitabhängige Medien.

-   **Schreibtisch-Videokonferenzen**: Eine geeignete Verteilung von
    Medienströmen an viele Teilnehmer und geeignete Begleitwerkzeuge
    stellen hierbei ein Problem dar. Begriffe für geeignete
    Begleitwerkzeuge:

    1.  *Whiteboard*

    2.  *Application-Sharing*

    3.  *Konferenzmanagement*

    4.  *Kooperationsbewusste Anwendungen*

```{=html}
<!-- -->
```
-   **Digitales Fernsehen:** (Video-on-Demand-Verteilsysteme). Wird
    besonders dann schwierig wenn einzelne Teilnehmer ganz individuell
    Videos abrufen können. Near-Video-on-Demand bündelt solche Zugriffe
    und erlaubt den Abruf aber nur in Zeitrastern und macht
    Videorecorder-ähnliche Bedienung (, , , , ) unmöglich, da pro
    Zeitraster mehrere Teilnehmer bedient werden.

```{=html}
<!-- -->
```
-   **Kiosk-Systeme:** Diese kombinieren Multi- bzw. Hypermediadokumente
    und einfache Benutzerschnittstelle.

## Grundlegende Konzepte

Es werden fünf Kernbereiche unterschieden, für die ein Multimedia
Unterstützungssystem Konzepte und Modelle an der Schnittstelle zur
Anwendung anbieten sollte:

*Synchronisation, Dienstgüte, Ströme, Zeitkapseln* und
*Konfigurationsverwaltung*

„*Unterstützungssystem*" steht dabei für ein multimediafähiges
Betriebssystem, Netz oder ein Werkzeug im oben genannten Sinne. \[Gibbs
95, IMA 95\].

### Synchronisation

Die Literatur versteht unter (Medien-) Synchronisation die zeitliche,
inhaltliche und räumliche Abstimmung mehrerer Medien in einer
Multimedia-Darstellung; die räumliche Anordnung beschränkt sich
natürlich auf visuelle Medien. Neben der so genannten
**Interobjektsynchronisation** mehrerer Medien muss auch die so genannte
**Intraobjektsynchronisation** der Verarbeitungseinheiten eines
einzelnen zeitabhängigen Mediums gewährleistet werden. Zeitbezogene
Aspekte von Synchronisationsspezifikation sind problematischer als
räumliche, inhaltliche Synchronisation wirft kaum Multimedia-spezifische
Fragen auf. Zu den Anforderungen an Methoden zur
Synchronisationsspezifikation gehören Intuitivität, Erhaltung der
logischen Einheit von Medienobjekten, Hierarchiebildung und
Ausdrucksstärke, weiters sollten Details der Synchronisation festgelegt
werden können, z.B. Kohärenz (lippensynchrones Audio-Video ist genauer
zu synchronisieren als ein Video mit Hintergrundmusik).

**Hierzu wichtige Methoden:**

**Abbildung 1:** Referenzpunkt-methode

> **Abbildung 2:** Hierarchisch

**Abbildung 3:** Petrinetz

Parallel zum Video **V** läuft zunächst ein lippensynchrones Audio
**A**, dann Hintergrundmusik **M**. Dann wird am Schaltknopf I eine
Benutzereingabe erwartet, bevor zwei Bilder **B1** und **B2** je **3s**
lang gezeigt werden, **V1** und **V2** sind zwei Hälften von **V**.

Bei der hierarchischen Spezifikation ist im Kern nur zeitlich parallele
und zeitlich sequentielle Anordnung von Meiden möglich, dort werden
Medien als Blätter eines Baumes angeordnet. Ein gemeinsamer
Vater-Knoten, gibt an, dass alle darunter liegenden Medien (Blätter)
oder Gruppen von Medien (Zwischenknoten) gleichzeitig oder alle zeitlich
nacheinander dargestellt werden, man unterscheidet zwei Arten von
Unterbäumen. Hauptnahteil dieser Methode ist, dass Medienobjekte bei nur
teilweiser zeitlicher Überlappung unnatürlich zerteilt werden müssen.

Balkenorientierte Methoden, bei allen drei Varianten dieser Methode
werden zeitabhängige Medien graphisch durch einen Balken „von links nach
rechts" dargestellt, meist auf einem mehrdimensionalen Koordinatensystem
(Referenzachsen-Methode). Jene Achsen müssen sich nicht immer auf
zeitlich äquidistante Maßeinheiten beziehen und erlauben im Gegensatz
zur Zeitachsen-Methode interaktive Objekte unbekannter Dauer. Die
Referenzpunkt-Methode kommt weitgehend ohne Koordinatensystem aus, da
Medien relativ zueinander angeordnet werden, zeitabhängige Medien die in
die Spezifikation involviert sind, geben den zeitlichen Ablauf vor, nur
wo jene fehlen werden Zeitgeber-Objekte als Zeitachsen benutzt. (z.B.
Dia Show).

-   **Ereignistabellen** wurden in einigen Systemen und Standards
    eingesetzt, wobei eine Matrix aus Medien und auslösenden
    Ereignissen, Folgeereignisse eingetragen werden, diese umfassen
    unter anderem Starten eines Zeitgebers oder Beginn oder Ende einer
    Mediendarstellung.

-   **Skriptsprachen** zeichnen sich naturgemäß durch höheren
    Lernaufwand, aber auch besondere Ausdruckskraft aus, es können
    Standard-Operationen auf den Medien in den Sprachumfang einbezogen
    werden.

-   **Formalere Methoden** sind u.a. Petrinetz-Erweiterungen, jene
    werden jedoch bei nichttrivialen Aufgaben schnell unübersichtlich.

-   **Intervallbasierte Methoden**, man betrachtet die Präsentation
    eines Mediums als Zeitintervall, so können zwei solcher Intervalle A
    und B in verschiedenen Beziehungen zueinander stehen. Eine einfache
    Betrachtung unterscheidet sechs Möglichkeiten. (A liegt zeitlich
    vollständig vor B, B folgt unmittelbar auf A, B folgt A überlappend,
    B läuft vollständig während A ab, A startet B, A beendet B).

    -   **Ausdrucksstärkere Methoden** beziehen die Verzögerungen
        zwischen Anfang oder Ende von A oder Ende von B mit ein und
        berücksichtigen eine oder mehrere solcher Verzögerungen in
        verschiedenen Beziehungstypen.

### Dienstgüte

Die Dienstgüte bezeichnet *quantifizierbare* Eigenschaften eines
Dienstes, deren Eigenschaften als Dienstgütemerkmale oder --Parameter
bezeichnet werden. Der Begriff ist dann von Bedeutung, wenn der
Dienstnutzer die Dienstgütemerkmale mitbestimmen kann. Merkmale wie
Durchsatz und Restfehlerrate werden seit Jahren für
Kommunikationsdienste betrachtet, sind in konventionellen Netzen aber
nur beschränkt variabel. Bildauflösung oder Pixelfehlerrate können
dagegen auf Grund der Toleranz und Subjektivität der menschlichen
Wahrnehmung stark variiert werden, folgende drei Charakteristika sind
von Bedeutung.

-   **Stochastik**: Dienstgütemerkmale sind meist statistische Größen,
    von denen z.B. Maxima, Mittelwerte oder andere Verteilungskenngrößen
    interessieren.

-   **Konkurrenz:** Dienstgütemerkmale konkurrieren offensichtlich mit
    den abstrakten Kosten im Sinne einer Optimierungsfunktion
    untereinander, Langfristig wird and leistungsfähigen
    Unterstützungssystemen gearbeitet, die die dynamische Optimierung
    der Dienstgüte voll automatisieren.

-   **Schichtung:** Die subjektive Güte eines Videos auf Benutzersicht,
    z.B. bildschirmfüllendes, ruckfreies, lippensynchrones Video, ist
    eine Funktion von objektiven Dienstgütemerkmalen auf der Sicht der
    Datenrepräsentation wie Auflösung, Farbtiefe und Bildwiederholrate
    sowie Codierungs-Spezifika wie Quantisierung, Abfolge von I-, P- und
    B-Frames usw. jene sind wiederum eine Funktion von
    Dienstgütemerkmalen in den Schichten der Kommunikationsdienste und
    des Betriebssystems einschließlich der Peripheriegeräte.

**Farbtiefe**: Mit der *Farbtiefe* wird gemessen, wie viel
Farbinformation für die Anzeige oder die Ausgabe jedes Bildpixels
verfügbar ist. Eine größere Farbtiefe (mehr Bitinformation pro Pixel)
bedeutet mehr Farben und eine präzisere Farbdarstellung in dem digitalen
Bild. Ein Pixel mit einer Farbtiefe von 1 Bit hat z. B. zwei mögliche
Werte: Schwarz und Weiß. Ein Pixel mit einer Farbtiefe von 8 Bit hat
2^8^ bzw. ca. 256 mögliche Werte. Ein Pixel mit einer Farbtiefe von
24 Bit hat 2^24^ bzw. ca. 16 Millionen mögliche Werte. Die Farbtiefe
liegt i. d. R. zwischen 1 und 64 Bit pro Pixel, Lab-, RGB-, Graustufen-
und CMYK-Bilder enthalten meist 8 Bit Daten pro Farbkanal. Dies
entspricht einer Lab-Farbtiefe von 24 Bit (8 Bit x 3 Kanäle), einer
RGB-Farbtiefe von 24 Bit (8 Bit x 3 Kanäle), einer Graustufen-Farbtiefe
von 8 Bit (8 Bit x 1 Kanal) und einer CMYK-Farbtiefe von 32 Bit (8 Bits
x 4 Kanäle). \[ABDOBE 00\]

**Dienstgütemerkmale** beschreiben das Vorhandensein oder Fehlen von
Fähigkeiten wie *Multicast* (Gruppensenden). Quantitative Merkmale
werden durch numerische stochastische Parameter beschrieben.
Dienstgütermerkmale in Klassen eingeteilt:

-   **Durchsatz** (Datenrate, Bandbreite): für Vermittlungsrechner
    können Mittel- und Spitzenwerte der „Pakete pro Sekunde"
    interessanter sein als „Bits pro Sekunde"

-   **Verzögerung:** In diese Klasse fallen die beiden wohl wichtigsten
    Multimedia-spezifischen Merkmale:

    -   **Jitter** (Zittern): ist definiert als zeitlicher Versatz
        zwischen dem Bearbeitungsende einer Verarbeitungseinheit und dem
        zugehörigen Normalwert (z.B. bei Video mit 25 Hz Bildrate
        gegenüber demjenigen „Fünfunzwanzigstelsekunden-Tick", der der
        Bildnummer entspricht).

    -   **Skew:** bezeichnet den Versatz synchronisierter Medienströme
        gegeneinander, der bei der Bearbeitung (Übertragung und
        Präsentation) entsteht. Die Summe der maximalen Jitter aller
        synchronisierten Ströme begrenzt den maximalen Skew.

```{=html}
<!-- -->
```
-   **Zuverlässigkeit:** Restfehlerrate als Wahrscheinlichkeit eines
    verfälschten Bits trotz Fehlerkorrekturmechanismen und die
    Zellenverlustrate als Wahrscheinlichkeit, dass in einem
    zellenbasierten Netz die gesamte Zelle nicht ankommt, zählen zu
    dieser Klasse.

Während die drei genannten Klassen allgemein gelten, können einzelne
Merkmale komponentenspezifisch sein, z.B. Zykluszeit und
Prozessorauslastung für Betriebssysteme, dies gilt auch für einige
Multimedia-spezifische Parameter, die die maximale Positionierzeit
zwischen Videobild und dem zugehörigen Audioblock (für
Peripheriegeräte).Dienstgütemerkmale beeinflussen unmittelbar
Medienparameter, z.B. Auflösung, diese Parameter bezeichnet man zusammen
auch als *Medienqualität*.

### Ströme

Bei *isochronen* Medien unterscheidet sich vor allem die Datenübergabe
zwischen Komponenten einer Multimedia-Anwendung von der herkömmlichen
Parameterübergabe bzw. Datenübergabe. Man will nicht jede einzelne
Datenübergabe (z.B. für jedes Videobild) ausprogrammieren, sondern die
Summe aller Datenübergaben in ihrem zeitlichen Ablauf spezifizieren. Zur
Gewährleistung isochronen Verkehrs sind umfangreiche Vorarbeiten, wie
Ressourcenreservierung notwendig, dies legt verbindungsorientierte
Datenübertragung nahe. Hierfür hat sich der Begriff *Strom* (*stream*)
eingebürgert. Verbindungslose Programmiersprachen und --paradigmen
werden für verteilte Systeme derzeit bevorzugt, z.B. objektorientierte
Programmierung oder Prozedurfernaufruf. Jene decken sich schlecht mit
dem verbindungsorientierten Strom-Konzept. Die Funktionalität von
Strömen ist in verschiedenen Unterstützungssystemen unterschiedlich und
betrifft u. a. folgende Aspekte: Strom-Verwaltung, Manipulation,
Unterstützung von Gruppenkommunikation (Multicast), Unterstützung von
Strömen über mehrere zwischen geschaltete Softwarekomponenten hinweg
(multihop).

### Zeitkapseln

Die Zeitabhängigkeit von Medien und Multimedia-Darstellungen schlägt
sich auch auf die Anwendnungsprogrammierung durch. Der Programmierer
erhält die Möglichkeit, Zeitabhängigkeit für die Prozesse der Anwendung
auszudrücken, hierbei werden meist Leichtgewichtprozesse verwendet, der
dabei entstehende Prozessbegriff wird als Zeitkapsel bezeichnet. Häufig
wird Peripherie wie z.B. Kamera, Bildschirm etc. homogen in das
Zeitkapsel-Modell einbezogen. Im einfachsten Fall werden Zeitgeber,
anwendungs- oder prozessweite definiert. Fortgeschrittene Konzepte
erlauben eine sog. *synchrone Programmierung*, wobei Zeitkapseln in
einer speziellen Programmiersprache als endliche Automaten spezifiziert
werden. Nachteil ist neben der erforderlichen speziellen
Programmiersprache die Tatsache, dass nur Steuerprozesse als Zeitkapseln
programmiert werden können. Der Programmierer besitzt jedoch keinen
Hinweis darüber, wie häufig solche Zeitüberschreitungen zur Laufzeit zu
erwarten sind, bekannte Modelle für Zeitkapseln sind daher noch
entwicklungsbedürftig.

### Konfigurationsverwaltung

Werden Multimedia-Anwendungen als Kombination von Programm-Komponenten
und Strömen zusammengefasst, dann benötigt der Programmierer eine
Möglichkeit zum Aufbau von Anwendungen aus verteilten Komponenten. Dies
wird von **Frameworks** unterstützt, wobei sich bemängeln lässt dass:

-   fast immer drei wesentliche Klassen von Komponenten unterschieden
    werden: für Produktion, Transformation und Konsum von Medien, jeder
    Ansatz erfindet jedoch hierfür ein eigenes Modell

-   kaum ein Abstraktionsniveau angeboten wird, das die medien- und zum
    Teil hardwareabhängigen Aspekte der Komponenten zu verdecken
    gestattet.

-   fast immer nur der Aufbau einer konkreten Konfiguration ermöglicht
    wird, anstatt z.B. die Anzahl der Komponenten eines bestimmten Typs
    erst zur Laufzeit festlegen zu müssen und dynamisch ändern zu
    können, die Softwaretechnik für verteilte Anwendungen hat hier vor
    Jahren schon einen wesentlich höheren Stand erreicht.

## Handhabung von Multimediadaten

### Interaktion

Multimedia-Interaktion erfordert, zumindest bis zur breiten Einführung
digitaler Endgeräte, den Umgang mit analogen Signalen. Dabei werden
Komponenten aus der Audio-Video-Technik verwendet, die sich von
vergleichbarer Computerperipherie teilweise stark unterscheiden, z.B.
Zwischen der Bildwiedergabe im Fernsehen und auf dem Computerbildschirm
bestehen folgende Unterschiede:

1.  **Zeilenmodus:** Beim Fernsehen wird jedes Bild in zwei gröbere
    Halbbilder zerlegt, die mit doppelter Bildwiederholrate dargestellt
    werden, so wird bei gleich bleibenden Bandbreitenbedarf das Flimmern
    deutlich reduziert, beim Computer werden Vollbilder benutzt, wodurch
    geometrische Strukturen nicht flackern.

2.  **Bildwiederholrate:** Beim Fernsehen werden 50 Halbbilder pro
    Sekunde dargestellt, beim Computer 70 oder mehr Vollbilder pro
    Sekunde.

3.  **Farbraum:** Beim Fernsehen wird die YUV-Farbdarstellung, bei
    Computerbildschirm die RGB-Farbdarstellung benutzt.

**RGB Farbdarstellung:** Der RGB-Modus z.B. von *Photoshop* verwendet
das RGB-Modell und weist jedem Pixel einen Intensitätswert zwischen 0
(Schwarz) und 255 (Weiß) für die einzelnen RGB-Komponenten in einem
Farbbild zu. Eine hellrote Farbe kann z. B. einen R-Wert von 246, einen
G-Wert von 20 und einen B-Wert von 50 haben. Wenn die Werte aller drei
Komponenten gleich sind, ergibt dies ein neutrales Grau. Beträgt der
Wert aller Komponenten 255, entsteht reines Weiß, und bei einem Wert von
0 reines Schwarz. RGB-Bilder stellen mit drei Farben oder Kanälen bis zu
16,7 Millionen Farben auf dem Bildschirm dar; die drei Kanäle
ermöglichen Farbinformationen von 24 (8 x 3) Bit pro Pixel. (In Bildern
mit 16 Bit pro Kanal entspricht dies 48 Bit pro Pixel und somit mehr
Farben.) Das RGB-Modell ist der Standardmodus für neue Bilder in
Photoshop und wird zudem von Computerbildschirmen für die
Farbdarstellung verwendet. Bei Verwendung anderer Farbmodi wie z. B.
CMYK wechselt Photoshop daher zur Farbanzeige vorübergehend in den
RGB-Modus. RGB ist zwar ein Standard-Farbmodell, der genaue Farbbereich
kann jedoch je nach Anwendung oder Anzeigegerät variieren. \[ABDOBE 00\]

Zwei wichtige Tendenzen und deren Folgen für Softwaretechnik und
Anwendungsgebiete seien hier erwähnt:

-   Vor allem für visuelle Medien wird weiterhin versucht, die
    „Realitätsnähe" der Repräsentation zu verbessern, hinsichtlich
    Qualität (Farbtiefe, Auflösung usw.) Dimensionalität (2D → 3D) und
    Zeitabhängigkeit (Bild → Video).

-   Die zunehmende Diversifikation interaktiver Komponenten, vom
    „Organizer" im Taschenformat bis zur interaktiven Tafel, erhöht die
    Bedeutung **multimodualer Interaktion**. Eine Modalität sei hier
    definiert als „Art und Weise der Interaktion" welche sich auf die
    benutzten Sensor-Aktor-Kanäle bezieht (z.B. Audio, Video), auf die
    Signalrepräsentation (z.B. Sprache, Gestik) und die verwendeten
    Metaphern (z.B. Formulare, Menüs). \[Taylor 89\]

Multimedia-Anwendungsdaten sind somit von multimodualer
Anwendungskontorlle (d.h. der Benutzeroberfläche) zu unterscheiden.

### Codierung 

Hierbei spricht man häufig von dem Kunstwort *Codec*, welches von
*Co*mpressor/*Dec*ompressor oder En*co*der/*Dec*oder herrühren kann. Es
bezeichnet Kompressionsverfahren zusammen mit weitreichenden Aspekten,
die für den reibungslosen Austausch von komprimierten Multimediadaten in
offenen Systemen wichtig sind.

Leistungsanpassung: Standardisierte Codecs sollen meist möglich breit
einsetzbar sein. Sie sollen auch mit Software-Codecs auf langsamen PCs
oder über langsame Internet-Verbindungen nutzbar sein. Ein Beispiel:
JPEG beruht auf Kompression im Frequenzbereich mittels DCT. Um den
Betrachter einen Grobeindruck von Bildern zu erlauben, während die
Dekompression oder die Übertragung noch im Gange ist, wird der sog.
Progressive Modus in zwei Varianten angeboten.

### Codierung von digitalem Video

Es gibt zwei Gruppen von Standards: Digitales Video, gegebenenfalls mit
begleitendem Audio, stellt als Einzelmedium die höchsten Anforderungen
an die Multimediatechnik. Die ISO-Standards der **MPEG**-Serie
spezifizieren Parameter, Arbeitsweise und Datenstrukturen von
Audio/Video-Codecs. In der sog. Systemdefinition spezifizieren sie die
Integration in ein Dateiformat bzw. in einen Transportstrom zur
Übertragung. Die **H.26x**-Standards der International
Telecommunications Union ITU -- H.261 und H.263 -- beschränken sich auf
Video. Für Audio und die Integration in Telefonnetz-basierte
Videokonferenzen gelten weitere Normen. Qualitätsunterschiede zwischen
Digitalvideos innerhalb eines Standards betreffen die Parameterwahl und
vor allem den codiererseitigen Aufwand für die Suche nach
Bewegungsvektoren, da das Suchverfahren nicht genormt ist.

**Die H.26x-Serie**: H.261 Codierer beschränken die Suche auf einen
kleinen Radius oder suchen gar keine Bewegungsvektoren, zudem sind nur
I- und P-, keine B-Frames definiert. Diese Beschränkungen hat H.263
nicht. Bitströme mit verfahrensbedingt schwankender Datenrate werden
üblicherweise zu einem *isochronen* Strom geglättet, indem ein
sendeseitiger Puffer bei Erreichen eines Schwellenwertes gröbere
Quantisierung anfordert.

**Die MPEG-Serie**: H.263 konkurriert als Format für Internet-Videos mit
dem ältesten der vier MPEG-Standards MPEG 1. Dort sind jedoch nur hohe
Bildwiederholraten (24 bis 60 Hz) definiert. Die Verzögerung für
Übertragung und Decodierung darf bei MPEG bis zu einer Sekunde betragen,
und Codierer müssen überhaupt nicht in Echtzeit arbeiten, so dass sich
dieser Standart nicht ohne weiteres für Videokonferenzen eignet.

Der **MPEG-Videostrom** ist hierarchisch in sechs Ebenen gegliedert:

-   **Ebene 1:** Die kleinste Einheit bilden die entropiecodierten
    8∙8-Blöcke.

-   **Ebene 2:** Darüber liegen Makroblöcke aus 4 Blöcken der
    Luminanz-(Y)-Ebene, den zu diesem 16∙16-Feld gehörenden
    Bewegungsvektoren (0-2 je nach Frame-Typ) sowie je einem Block der
    unterabgetasteten U- und der V-Ebene.

-   **Ebene 3:** Hier werden Makroblöcke zu sog. Slices zusammengefasst
    und mit übergreifenden Parametern wie
    Quantisierungstabellenkennungen versehen.

-   **Ebene 4:** Hier werden mehrere Slices zu einem Einzelbild
    (picture) zusammengefasst und mit Verwaltungsdaten wie der
    eindeutigen Bildnummer innerhalb des Videos versehen.

-   **Ebene 5:** Hier werden Bilder zu Gruppen zusammengefasst (group of
    pictures GOP), GOPs enthalten üblicherweise die Abfolge von einem
    I-Frame zum nächsten, also z.B. die weitverbreitete IBBPBBPBB-Folge.
    Da B-Frames im Allgemeinen nicht ohne den nachfolgenden I- oder
    P-Frame decodiert werden können, wird ...B~i-1~ B ~i-1~\|
    I~i~B~i~B~i~P^1^~i~B~i~B~i~P^2^~i~B~i~B~i~\| I~i+1~... umsortiert zu
    ... I~i~B~i-1~B~i-1~\|
    P^1^~i~B~i~B~i~P^2^~i~B~i~B~i~I~i+1~B~i~B~i~\|...

-   **Ebene 6:** Die oberste Ebene wird Sequence-Layer genannt, eine
    Sequenz umfasst dabei eine Menge von GOPs, für die dem Decodierer
    vorab in den Sequenz-Verwaltungsdaten die gemeinsame (geglättete)
    Bitrate und der vorzuhaltende Puffer mitgeteilt wird. Der so
    hierarchisierte Videostrom wird in der MPEG-Systemdefinition mit den
    Audioströmen zu „Packs" verschränkt und mit Zeitstempeln versehen.

**Intelligente Endgeräte:** MPEG-4 ist sein Januar 1999 gültige Norm.
Ursprünglich sollte sein Schwerpunkt auf der Unterstützung niedriger
Bitraten liegen, Parallelarbeiten an H.263 für Video und neuere
GSM-Codecs für Sprachübertragung zeigten sich dann aber als kaum zu
überbieten. Daher wendete sich das Gremium den Themen Interaktivität und
Synthetisierung von Medienströmen zu.

**Beispiel Synthetisierung:**

Fernsehübertragung eines Tennisspieles. Dort könnte man sich vorstellen,
den Hintergrund (Platz, Zuschauer) als Panoramabild mit geringer
Wiederholrate (z.B. mit Wavelet-Kompression) zu übertragen und die
aktuelle Kameraeinstellung als Parameter des darzustellenden
Bildausschnittes laufen zu senden. Der Tennisspieler mit Schläger könnte
als freigestelltes Objekt ohne Hintergrund mit normaler Wiederholrate,
aber geringerem Datenvolumen gesendet werden. Der Ball könnte ebenfalls
freigestellt werden und mit hoher Wiederholrate, aber auch als
mathematischer Ausdruck codiert werden. Im Empfänger würden die drei
Ebenen zusammengefügt. Weiter stelle man sich mehrere parallel
übertragene solcher Multi-Ebenen-Ströme vor, die über ein Kabelnetz an
viele Haushalte gehen. Per Schaltfläche (als weitere Ebene in das
synthetisierte Fernsehfeld integriert), könnte der Fernsehzuschauer den
Wechsel zu einem anderen Strom d.h. einer anderen Kameraposition
anfordern. Kommentare mit unterschiedlichen Schwerpunkten oder Sprache,
Platzgeräusche und Hintergrundmusik könnten vom Zuschauer ebenfalls
interaktiv individuell gemischt werden.

**Weitere Entwicklung**: Für Studios und Sender wird als Teil von MPEG-4
ein Werkzeugkasten angeboten. Er enthält Funktionen wie die Extraktion
und Bewegungsschätzung freizustellender Objekte aus dem
Fernsehkamera-Input. Dieses Problem ist nach heutigem Stand der Technik
allerdings noch nicht befriedigen gelöst; man kann sich in zukünftigen
Studios aber sehr wohl einen Satz virtueller digitaler Requisiten als
AVOs vorstellen und daran ermessen, dass MPEG-4 der Filmproduktion neue
Wege weist.

### Speicherung

Unter den Speichermedien hat die **CD-ROM-Familie** eine besonders große
Bedeutung, da verschiedene Unterarten (*CD-ROM/XA, CD-I, CD-Video und
DVD*) speziell für Multimedia ausgelegt wurden, dies betrifft sowohl
spezielle Dateiformate (z.B. ADPCM-codiertes Audio bei CD-I) als auch
die Speicherorganisation (z.B. für die verschränkte Speicherung von
synchron abzuspielenden Audio- und Videodateien in CD-ROM/XA). Als weit
verbreitete Wechselmedien mit wahlfreiem Zugriff eignen sich besonders
zum Multimedia-Datentransport.

Speicherorganisationen wurden insbesondere für
**Video-on-Demand-Server** intensiv erforscht. Dort ist vor allem die
Verteilung von Videos auf Speicherhierarchien interessant, wenn z.B.
Hunderte von Haushalten gleichzeitig auf dasselbe aktuelle Video
zugreifen, aber auf Grund versetzbarer Anfangszeiten an verschiedenen
Stellen. Hier reicht es meist nicht, mehrere Kopien bereit zu halten;
weit verbreitet ist das sog. „striping": das Video wird in Schnipsel
zerstückelt. Diese Schnipsel werden z.B. auf eine „Durchsatz-Hierarchie"
aus einem Kabelverteilnetz mit *n* Servern mit je *m* Controllern mit je
*q* Platten verteilt, wobei aufeinander folgende Schnipsel auf
verschiedenen Platten gespeichert werden. Dadurch wandert der einzelne
Zuschauer bei seinem Zugriff zyklisch dir Peripherie ab und die (einem
Zufallsprozess gleichenden) vielen Konsumenten desselben Videos
verteilen sich auf die gesamte Server-Hardware. Weitere Probleme
betreffen die große Zahl anzubietender Videos bei extrem variierender
Nachfrage, schnellen Vor- und Rücklauf und wahlfreie Zugriffe auf
interaktive Videos.

### Interpretation

**Indizierung durch Medienanalyse:** In umfangreichen Forschungsarbeiten
wird versucht, höhere Semantik aus der signalorientierten
Medienpräsentation zu extrahieren, z.B. durch Sprachanalyse,
Handschrift-Erkennung, Bildverstehen oder automatische Erzeugung
charakteristischer Sinnbilder für Video \[Multimedia Systems 95\].

**Beispiel Sprache:** Für Sprachverstehen werden heute hierarchische
Verfahren eingesetzt, die aus phonetischer, syntaktischer und -- in
Ansätzen -- semantischer Analyse bestehen. Die phonetische Analyse als
unterste Ebene betrachtet Phoneme als kleinste „akustische" Einheiten
bzw. Diphonge (Doppellaute) und deren Verkettungen. Sie werden mit
Buchstaben bzw. Wörtern und deren zuvor gespeicherten charakteristischen
Wellenformen verglichen. Wie beim menschlichen Sprachverstehen werden
nicht oder schlecht entscheidbare Alternativen auf der nächsthöheren
Ebene betrachtet („Vieh" und „Fieber" syntaktisch, „das Q" und „die Kuh"
semantisch). Unter „wordspotting" versteht man die Suche nach
Schlüsselwörtern in längeren Audioaufzeichnungen zur Indizierung.

**Beispiel Video:** Die Forschung im Bereich Videoanalyse wendet sich
zunehmend sehr anspruchsvollen Aufgaben zu. Innerhalb einer Filmszene
kann erwartet werden, dass sich der Bildinhalt von einem Einzelbild zum
nächsten nur graduell ändert, bei einem harten Schritt dagegen ist mit
einem drastischen Wechsel zu rechnen. Beim Bildvergleich kann der
YUV-Farbraum unter Weglassung der Luminanzebene Y vorteilhaft sein, weil
er plötzliche Helligkeitsänderungen durch Blitzlichkameras oder
Blendenänderung der Videokamera als Fehlerquelle weitgehend ausschließt.
Einfache aber wirkungsvolle Schnitt-Erkennungsverfahren arbeiten mit
Farbhistogrammen als Merkmalen. Dazu werden die Millionen möglicher
Farben in *n* Klassen, sog. *Bins,* eingeteilt und die Pixel eines
Bildes quasi in die Bins einsortiert, es entsteht ein Histogramm H\[1
... n\] vom Umfang der Bin-Anzahl. Der Vergleich zweier Bilder B und B'
kann nun in der Summe der Bin-weisen Histogramm-Unterschiede bestehen:

Überschreitet der Wert *Diff* einen bestimmten Schwellwert, so wird ein
Szenenwechsel im Film (harter Schnitt) angenommen. Fehler durch sich
schnell bewegende Objekte können ausgeschlossen werden, indem das Bild
mehrere (z.B. neun) Regionen zerteilt wird und ein Quorum von Quadranten
einen Schwellwert überschreiten muss.

## Systemunterstützung

### Netwerke und Kommunikationsdienste

Um *isochrone* Medienströme zuverlässig zu unterstützen, müssen für den
gesamten Datenpfad vom Ursprung bis zur Senke lückenlos
Dienstgütegarantien gegeben werden. Heutige Multimedia-PCs und
Telemedia-Anwendungen berücksichtigen dies meist nicht, sondern beruhen
auf der Hoffnung, dass keine Ressourcenknappheit auftritt. An der
Schnittstelle zwischen Anwendungsprogramm und Netzt werden nicht nur
zusätzliche Dienstgüte-Parameter relevant, die Bedeutung verschiebt sich
auch zum Teil:

-   **Durchsatz:** war früher Hauptanliegen der Netzbetreiber, wird nun
    wichtige Anwender-Forderung.

-   **Bitfehlerrate:** Auf optischen Medien sinkt jene beträchtlich,
    Anwendungen sind zum Teil weniger anfällig, in schnellen
    zellenvermittelten Netzten wie ATM steigt hingegen die
    **Zellenverlustrate**.

Multimedia-Kommunikation erfordert zunächst auf den unteren Schichten
isochronen Datenverkehr und garantierten Durchsatz, was jedoch in
lokalen Netzten mit Mehrfachzugriff (zufallsgesteuerter Wettbewerb
Ethernet) nicht möglich ist. Auf den höheren Schichten und bezüglich der
gesamten Schichtenstruktur des OSI-Referenzmodelles treten Probleme im
Zusammenhang mit Hochgeschwindigkeitsnetzen und Multimedia auf.

### Betriebssysteme

Die wichtigste Multimediaerweiterung für Betriebssysteme betrifft die
geeignete Prozessorzuteilung \[Steinmetz 95\]. Die Abbildung illustriert
zwei wichtige Verfahren:

Der *Earliest-Deadline-First*-(EDF)-Algorithmus teilt aus der
Bereitmenge immer den Prozess mit der frühesten Frist (deadline) ein.
EDF ist optimal in dem Sinne, dass ein geeigneter Plan gefunden wird,
falls einer existiert. Da bei jedem Eintritt eines Prozesses in die
Bereitmenge neu geplant werden muss, hat er eine hohe
Berechnngskomplexität und erscheint für kontinuierliche Medien mit
deterministischen Betriebsmittelanforderungen überdimensioniert, *EDF*
ist auch für klassische Realzeitprobleme geeignet.

Ratenmonotone (*RM*) Planung basiert auf einschränkenden Annahmen:

1.  Pro Prozess fällt die Frist einer Bearbeitung mit der Ankunft der
    nächsten Anforderung zusammen.

2.  Nur die Bearbeitung kontinuierlicher Medienströme ist zeitkritisch.

3.  Pro Bearbeitung wird dieselbe Bearbeitungszeit angefordert

Unter diesen Bedingungen genügt es gemäß RM, jedem zeitkritischen
Prozess niedrigster Priorität trifft eine Anforderung zeitgleich ein,
mit Anforderungen für alle anderen Prozesse.

## Hypertext / Hypermedia

### Grundbegriffe

Papierbasierte textuelle Information ist inhärent sequentiell.
Nichtsequentielle Strukturen und Beziehungen wie Hierarchien, Fußnoten
und Querverweise müssen textuell ausgedrückt werden und behelfen sich
mit sekundären Ordnungsmerkmalen wie Seitenzahlen, was jedoch nicht
sequentielles Lesen, wie z.B. blättern, sehr erschwert. Grundidee des
Hypertext-Konzeptes ist es, nicht sequentielle Strukturen in
computerbasierten Dokumenten sichtbar zu machen. Die zentralen Begriffe
sind dabei *Knoten, Link, Anker* und *Netz*. \[Nielsen 95\]

Die Information wird in kleine semantisch zusammenhängende
Informationseinheiten, sog. Knoten oder **nodes**, zerlegt. Beziehungen
aller Art zwischen diesen Knoten werden durch explizite Verweise den so
genannten *Links*, repräsentiert. Wesentlich ist die Möglichkeit, Links
über eine leistungsfähige, meist graphische Benutzeroberfläche leicht
aktivieren zu können. Meist beginnen und enden Links an bestimmten
Ausschnitten des Knotens, diese werden als *Quell-* oder *Zielanker*
bezeichnet. Ein vollständiges Dokument wird bei der beschriebenen
Vorgehensweise zu einem zusammenhängenden Graphen aus Knoten und Links.

Für das Lesen von Hypermedia-Dokumenten sind die Begriffe *Stöbern,
Navigieren* und *Abfragen* relevant. Stöbern oder browsing entspricht
dem Blättern in Papierdokumenten mit dem Ziel, einen Überblick zu
gewinnen und relevante Knoten zu finden. Navigieren bezeichnet
planmäßiges Durchlaufen und Lesen von Knoten und ähnelt dem Lesen in
Papierdokumenten. Abfragen, ein weniger breit akzeptierter Begriff, soll
für die Formulierung sog. Hypertext-Queries stehen, die inhalts- und
strukturorientierte Aspekte verknüpfen. So könnte eine einfache Abfrage
wie: (\<[node where]{.underline} author =/= ´X´\>\<[link-]{.underline}\>
\[\<[node]{.underline}\>\<[link-]{.underline}\>\]\* \<[node]{.underline}
[where]{.underline} author = ´X´\>)

alle direkten und indirekten externen Verweise auf Dokumente des Autors
X suchen, *author* ist als inhaltsorientiertes Attribut außerhalb des
Systemmodelles zu verstehen.

### Das Dexter-Modell

Das Dexter-Modell dient als Referenzarchitektur für Hypertextsysteme
\[CACM 94\]. In seiner *Laufzeitschicht* wird die Interaktion mit dem
Hypertext-Leser abgehandelt, und die von ihm initiierten Operationen
werden koordiniert und ausgeführt, bzw. weitergeleitet. Die
*Speicherschicht* verwaltet und speichert alle Links als Quell- und
Zielknoten-Indentifikation sowie Ankerinformation, nicht aber die
Knoteninhalte. Für jeden Medientyp ist eine sog. *Komponente* zuständig,
in der *Komponentenschicht* werden also die Knoteninhalte gehalten. Da
im Kontext verschiedener Medientypen gegebenenfalls verschiedene
Ankertypen verwendet werden, werden diese in der Komponentenschicht
definiert und in der Speicherschicht verwaltet. Sollen z.B. in
editierbarem Text Anker an eine Textauswahl gebunden werden, so muss der
Anker selbst im Text gespeichert werden und nur eine eindeutige
Ankeridentifikation in der Speicherschicht gehalten werden. Sollen
dagegen Grafiken in einem Standardformat gespeichert werden, das keine
Anker kennt, so muss die Ankerinformation in der Speicherschicht
gehalten werden. Will der Leser interaktiv einem Link folgen, so
übergibt die aktuelle Komponente die Quellanker-Identifikation und
übergibt diese der Komponentenschicht. Zielknoten und --Anker werden
dargestellt.

**Abbildung 5:** *Dexter-Referenzmodell*, Definition für Link und Anker
in *EBNF*

### Weitergehende Aspekte

**Offene Linksysteme:** Es erscheint sinnvoll, beliebige
Softwarewerkzeuge verschiedener Hersteller in ein Hypermediasystem
einzubeziehen. Dabei können als Knoten so unterschiedliche Artefakte
vorkommen, wie Kalendereinträge eines Plannungswerkzeuges, E-mails oder
Quelltexte eines syntaxgesteuerten Editors. Daher muss neben der
Akertypdefinition auch die Darstellung der Artefakte den Werkzeugen
überlassen werden. Mechanismen sind anzubieten, um die
Benutzerschnittstelle der Werkzeuge um Operationen zu erweitern und die
Interaktion mit dem eigentlichen Hypertextsystem abzuwickeln. Dieses
ausdrucksstarke Konzept fand bislang mangels breit akzeptierten Standard
leider wenig Verbreitung.

**Wissensverarbeitung:** Hypertext-Konzepte eignen sich zur
Wissensrepräsentation nut semantischen Netzen, falls benutzerspezifische
Knoten- und Linktypen sowie möglichst verschiede Abstraktionsebenen von
Netzen unterstützt werden.

**Dynamik:** Dynamische Knoten, Links und Netze können die Verschmelzung
von Autoren und Softwareentwicklertätigkeit unterstützen.

**Verteilung:** Die Internetanwendung World-Wide-Web trennt
Benutzerschnittstelle und Knoten/-Link-Verwaltung nach dem
Client-/Server-Konzept. Verteilte Netze werden nur insofern unterstützt,
als Knoten beliebige Linkinformationen vollständig enthalten, wodurch
Clients bei Interpretation eines Knotens Links zu anderen Servern
anbieten können.

**Multimedia-Integration:** Typische Hypermediasysteme erfüllen nicht
die Multimedia-Definition, da sie die Synchronisation mehrerer, auch
zeitabhängiger Medien nicht unterstützen. Meist kann für synchronisierte
Multimediadarstellungen ein spezieller Medientyp eingeführt werden, doch
kontrolliert dann die zugehörige Komponente diese Darstellungen, die
Einzelmedien bleiben dem Hypermediasystem verborgen.

### Das World-Wide-Web als Hypertextsystem

**Einordnung:** Der Name des Kommunikationsprotokolls zwischen
WWW-Clients und --Servern, „hypertext transfer protocoll, http",
kennzeichnet WWW als Hypertext-System. Korrekter kann man es als
Standard für Internet-weit zugängliche Textdokumente bezeichnen mit
schrittweise verbesserter Hypertext-Funktionalität. Die meisten Knoten
sind Textdokumente im sog. Hypertext-Markup-Language- (HTML-) Format. In
Markup-Sprachen wird die Textformatierung durch in den Text
eingesteuerte Kommandos, die Markups, gesteuert. HTML-Markups werden als
***Tags*** bezeichnet und kennzeichnen üblicherweise Anfang und Ende
eines zu formatierenden Elements.

**WWW als Textverarbeitungssystem:** Betrachtet man WWW als
Markup-Textsystem, so hat HTML Schwachstellen. Zunächst fällt auf, dass
HTML direkte Layout-Anweisungen nicht von logischen
Formatierungshinweisen trennt. Hochwertige Markup-Textsysteme wie der
ISO-Standard SGML unterscheiden zwischen Markup-Sprache,
Dokumenttyp-Definitionen, dort werden die für einen Dokumenttyp
zulässigen Markups oder Tags und zulässige Dokumentenstrukturen ähnlich
der BNF einer Programmiersprache definiert, als Dokumenten und
Formatierungsstil-Dateien.

**WWW als Hypermediasystem:** Betrachtet man WWW als Hypermedia-System,
so bringt die HTML-Lastigkeit weitere Nachteile. HTML verleitet dazu,
große Dokumente statt semantisch „atomarer" Knoten zu verfassen. Ein
HTML-Dokument wird damit quasi zu einem Metaknoten, Absätze oder
Unterkapitel sind mit Knoten vergleichbar. Damit aber entsteht ein Bruch
zwischen Hypertexten als vernetzten HTML-Dokumenten und Sub-Hypertexten
in HTML-Dokumenten. Bei letzteren dominiert die hierarchische logische
Dokumentenstruktur, die als Baum mit Querverweisen interpretiert werden
kann. Das Dexter-Referenzmodell wird nicht realisiert, das Links in
Textdokumente eingebettet sind anstatt in einer getrennten Schicht
untergebracht sind, entsprechend können Links nicht rückwärts travesiert
werden, und Konsistenz ist nicht gewährleistet. Quellanker sind nur für
Text und wenige weitere Medien definiert, die meisten Medien werden
dadurch zu „Sackgassen" der Hypertext-Navigation. Zielanker sind nur
rudimentär implementiert, meist führen URLs an den Anfang des
bezeichneten Zielknotens. Knotentypen werden nur auf einer
systeminternen niedrigen Stufe unterschieden, nämlich als Medientypen,
benutzerdefinierte Knoten- und Linktypen dagegen nicht unterstützt.

## 1.7. Zusammenfassung

Es zeigt sich, dass Multimedia in Zukunft immer mehr an Bedeutung
gewinnen wird, da der Mensch danach strebt, Information nicht nur
aufzunehmen sondern auch zu erleben, was durch Multimedia möglich wird.
Schon heute begegnet uns Multimedia täglich, entweder auf der offenen
Straße auf sogenannten „interaktiven" Plakaten, in der Arbeit bei
Onlinekonferenzen oder in der Schule, wo man versucht die Kreide gegen
das elektronische Whiteboard einzutauschen. Multimedia macht Information
lebendig, und man kann nur mehr in wenigen Bereichen vollständig darauf
verzichten. Wie bereits erwähnt, ist vor allem das World Wide Web Basis
für die zukünftige Verwendung von Multimedia, aber auch das Fernsehen
wird immer interaktiver werden. Man wird vom Zuschauer zum Teilnehmer.
Durch spezielle Autorensysteme ist es bereits heute möglich individuelle
und interaktive Dokumente zu erstellen ohne eine spezielle
Programmierkenntnis, auch dies trägt dazu bei, dass immer mehr
Multimedia benutzen aber auch selbst „erschaffen".

# 2 Datenbanksysteme

**Einleitung**

Es ist beinahe bei allen Automatisierungsaufgaben der Informatik
erforderlich, dass Programme Daten inspizieren oder bearbeiten können,
die irgendwann produziert worden sind, und dass umgekehrt von ihnen
selbst erarbeitete oder aus der Umwelt aufgenommene Daten für künftige
Verwendungen langfristig aufbewahrt werden. Dafür müssen sog.
Hintergrundspeicher, wie etwa CDs eingesetzt werden, während die Inhalte
von Programmvariablen im Hauptspeicher abgelegt werden und damit bei
Programmende verloren gehen. Da die in diesem Zusammenhang
durchzuführenden Aufgaben in analoger Weise bei zahlreichen
Softwaresystemen anfallen, werden sie sinnvollerweise als vorgefertigte
Standardsoftware realisiert. Neben den einfachen
Dateiverwaltungssystemen spielen dabei Datenbankverwaltungssysteme die
zentrale Rolle.

## 2.1 Anforderungen und Eigenschaften 

Datenbankverwaltungssysteme (database management systems, kurz DBMS)
sind Softwareprodukte für die dauerhafte, integre und
anwendungsunabhängige Speicherung und Verwaltung sowie die flexible und
bequeme Verwendung von großen, mehrfachbenutzbaren integrierten
Datenbasen.

-   Datenbasis, Datenbank

```{=html}
<!-- -->
```
-   Dauerhaftigkeit

```{=html}
<!-- -->
```
-   Integrität

```{=html}
<!-- -->
```
-   Anwendungsunabhängigkeit

```{=html}
<!-- -->
```
-   Flexibilität und Bequemlichkeit

```{=html}
<!-- -->
```
-   Größe

```{=html}
<!-- -->
```
-   Mehrfachbenutzbarkeit

```{=html}
<!-- -->
```
-   Integration

> Zur Erfüllung dieser Anforderungen muss ein Datenbankverwaltungssystem
> Leistungen in drei Bereichen erbringen:

-   Datenmodell und Datendefinition

-   Datenzugriff und -manipulation

-   Steuerung und Überwachung

## 2.2 Datenmodelle und Datendefinition

Daten repräsentieren Information der Anwendungswelt. Während Information
als Bezeichner mit einer zugeordneten Bedeutung aufgefasst werden, sind
Daten bloße Bezeichner. Computer, Software und Datenbanksysteme können
nicht mit Informationen, sondern nur mit Daten umgehen. Ohne weitere
Vorkehrungen ergebe sich die Bedeutung vorhandener Daten lediglich aus
der Art und Weise ihrer Verwendung. Nicht zuletzt wegen der geforderten
Anwendungsunabhängigkeit ist dies für Datenbanken unbefriedigend. Aus
diesem Grund sehen Datenbanksysteme vor, dass die Bedeutung der
gespeicherten Daten soweit wie möglich beschreiben und ebenfalls in der
Datenbank abgelegt wird. Außer den Daten selbst (Primärdaten) gibt es
auch \"Daten über Daten\", sog. Metadaten. Damit nun keine endlose Kette
von Daten und ihren Beschreibungen entsteht, muss die Semantik der
Metadaten ein für allemal festgelegt sein und somit eine lehr-, lern-
und implementierbare Konvention darstellen. Damit die Metadaten auch
maschinell gut verarbeitbar sind, wird ein formales Rahmenwerk für
Datenbeschreibungen benötigt, das sog. Datenmodell. Die Festlegung
konkreter Datenbeschreibungen heißt Datendefinition.

### 2.2.1 Konzepte

Ein Datenmodell ist ein Satz von abgestimmten Konzepten zur Beschreibung
der Repräsentation von Information durch Daten. Es geht nun darum
jeweils für eine Menge \"gleichartiger\" Sachverhalte der Realwelt eine
einzige Beschreibung zu verfassen (also etwa für alle
Lehrveranstaltungen und nicht einzeln für eine bestimmte Vorlesung
beispielsweise). Ein Datenmodell umfasst daher zunächst folgende
Bestandteile:

-   Einfache Datentypen und Konstruktoren für zusammengesetzte
    Datentypen.

-   (Inhärente und implizite) Konsistenzregeln, die mögliche
    gesetzmäßige Einschränkungen hinsichtlich der Zulässigkeit von Daten
    zum Ausdruck bringen.

-   ![](media/image4.png)Bennenungskonventionen, nach denen die
    Bezeichnung von Datenbankelementen erfolgt: Die aussagekräftige Wahl
    von Bezeichnern stellt einen wesentlichen Teil der Datenbeschreibung
    dar.

**Abbildung 6:** Begriffszusammenhänge

Außerdem ist für jedes Datenmodell von vornherein festgelegt, Elemente
welcher Datentypen als unabhängig erzeugbare Einheiten auftreten können:
In die Datenbank können nur solche Elemente eingefügt werden; \"aus der
Vogelperspektive\" betrachtet machen sie den Inhalt der Datenbank aus.
Ein Datenmodell findet seinen sprachlichen Ausdruck in einer
Datendefinitionssprache (data definition language; DDL) oder dem
DDL-Anteil einer umfassenderen Datenbanksprache. Das Datenmodell legt
außerdem fest, welche Operationen auf Datenbankinhalte angewandt werden
können. Für eine konkrete Datenbank sind nun mit den Mitteln des
Datenmodells die gewünschten Datentypen und Konsistenzregeln zu
definieren, bevor entsprechende Datenelemente eingefügt werden können.
Das Resultat wird Schema genannt. Damit ergeben sich die in **Abbildung
7** dargestellten Zusammenhänge. Auf der linken Seite findet sich die im
Fachgebiet seit langem eingeführte und auch hier verwendete
Terminologie. Präziser wären jedoch die auf der rechten Seite notierten
Begriffe, da ein ![](media/image5.png)Schema eben gerade ein \"Modell\"
der Datenbankdaten darstellt. Damit die einleitend geforderte
Anwendungsunabhängigkeit in allen Aspekten gewährleistet werden kann,
folgen moderne Datenbanksysteme der in **Abbildung 8** dargestellten
sog. 3-Schema-Architektur.

**Abbildung 7:** 3-Schema-Architektur

Das bisher erläuterte Datenbankschema entspricht dabei dem sog.
Konzeptuellen Schema, in welchem die gesamte integrierte Datenbank
einheitlich beschrieben wird. Einzelne Anwendungen arbeiten aber mit
einem externen Schema, das den jeweils benötigten Teil der Datenbank
beschreibt. Externe Schemata werden aus dem vorher zu erstellenden
konzeptuellen Schema nach bestimmten Gesetzmäßigkeiten hergeleitet.
Selbstverständlich kann es vorkommen, dass für mehrere Anwendungen
dasselbe externe Schema geeignet ist. Für beide Arten von Schemata kommt
gewöhnlich dasselbe Datenmodell zum Einsatz. Das interne Schema
beschreibt die Gesamtdatenbank aus dem Blickwinkel der internen,
speichermäßigen Repräsentation.

### 2.2.2 Das Relationenmodell

Das Relationenmodell ist das bekannteste und in heutigen DBMS am
weitesten verbreitete Datenmodell. Eine Datenbank in diesem Modell
besteht aus einer Anzahl sog. Relationen, die Mengen von Tupeln sind.
Ein Tupel ist seinerseits ein Datensatz, nicht weiter untergliedbarer
Attributwerte. Relationen lassen sich als Tabellen auffassen. Wegen der
Mengeneigenschaften dürfen nie zwei gleiche Zeilen auftreten und die
Reihenfolge der Tabellenzeilen ist unerheblich.

  ----------------------- ------------------ ------------- ------------------ ------------- ------ -------------- ------------- --------------- ---------------- -------------- --
  **Dozent**                                                                                                                                                                    

  **Nachname**                               **Vorname**   **Adresse**                                            **Telefon**                   **PNr**                         

                                                                                                                                                                                

  Schauer                                    Helmut        Winterthurerstr.                                       257 4340                      654.44.414.122                  
                                                           190                                                                                                                  

  Tell                                       Wilhelm       Winterthurerstr.                                       257 4312                      287.50.327.224                  
                                                           190                                                                                                                  

  Garbers                                    Hermann       Blümlisalpstr. 10                                      257 3735                      356.40.123.345                  

  Wehrli                                     Hans Peter    Plattenstr. 14                                         257 3922                      873.51.284.529                  

                                                                                                                                                                                

  **Lehrveranstaltung**                                                                            **Hörsaal**                                                                  

  **LV#**                 **Titel**                                           **Hörsaal**          **Hörsaal#**                 **Kapazität**                    **Lage**       

                                                                                                                                                                                

  322                     Datenbanksysteme                                    150                  150                          350                              Hauptgebäude   

  325                     Software                                            104                  180                          120                              Hauptgebäude   
                          Engineering                                                                                                                                           

  223                     Informatik, Teil 1                                  180                  104                          160                              Hauptgebäude   

  226                     Informatik, Teil 3                                  330                  330                          600                              Irchel         

  235                     Marketing                                           180                  109                          45                               Hauptgebäude   

  314                     Stochaistik                                         109                                                                                               
  ----------------------- ------------------ ------------- ------------------ ------------- ------ -------------- ------------- --------------- ---------------- -------------- --

  --------------------------------------------------- -------------------
  **liest**                                           

  **Doz**                                             **LV#**

                                                      

  654.44.414.122                                      325

  654.44.414.122                                      223

  287.50.327.224                                      322

  287.50.327.224                                      226

  356.40.123.345                                      314

  873.51.284.529                                      235
  --------------------------------------------------- -------------------

**Tabelle 1** Einfache Beispielrelationen

-   Struktur

> Ausgangspunkt sind Mengen von atomaren (also aus Sicht der Datenbank
> nicht weiter unterteilbaren) Werten, denen jeweils eine bestimmte
> Bedeutung unterstellt ist. Ein Relationenschema R(A~1~, A~2~,
> \....A~n~ ) besteht aus einem Relationennamen R und einer Liste von
> Attributen A~1~, A~2~, \....,A~n~. Jedes Attribut A~i~ ist der Name
> einer Rolle, welche eine bestimmte Domäne D im Relationenschema
> spielt: D = dom(A~i~). n heißt der Grad der Relation. Eine Relation r
> zu einem Relationenschema R, auch als r(R) notiert, ist eine Menge von
> n-Tupeln r = {t~1~,t~2~, \....,t~m~}. Jedes n-Tupel ist eine geordnete
> Liste von Werten t = \<w~1~, w~2~, \....,w~n~\>, wobei jeder Wert
> entweder ein Element der zugehörigen Domäne A~i~ oder der spezielle
> Wert NULL ist, welcher stellvertretend für unbekannte Werte oder die
> Information \"nicht zutreffend\" steht (nicht die Zahl \"0\"). Die
> Relation r heißt auch Instanz von R.
>
> ![](media/image6.png)Anders ausgedrückt ist eine Relation r(R) eine
> Teilmenge des Kreuzprodukts der Domänen, die R definieren: r(R)
> dom(A~1~) x dom(A~2~) x \... x dom(A~n~). Jedem Relationenschema ist
> zu jedem Zeitpunkt genau eine Relation zugeordnet.

Da sich die reale Welt verändert, müssen in einer Datenbank häufig neue
Tupel dazukommen, vorhandene müssen gelöscht oder in ihren
Attributwerten verändert werden. Zu einem Relationenschema wird es also
im Laufe der Zeit verschiedene Relationen geben.

#### Konsistenzregeln

-   Domänenbeschränkungen

```{=html}
<!-- -->
```
-   Schlüsselbeschränkungen

```{=html}
<!-- -->
```
-   Gegenstandsintegrität

```{=html}
<!-- -->
```
-   Referentielle Integrität

#### Datenbanksprache

Das Relationenmodell liegt den meisten der heute eingesetzten DBMS zu
Grunde. Dabei müssen die erläuterten abstrakten Konzepte ihren Ausdruck
in korrekter Syntax und Semantik finden. Hierfür hat sich die genormte
Datenbanksprache SQL durchgesetzt (structured query language). Nun wird
an Hand eines Teiles des Beispiels aus Bild 3 gezeigt, wie Definition
von Relationen in SQL erfolgt. Folgende Anweisungen spezifizieren die
beiden Relationen Lehrveranstaltung und Hörsaal:

(1) CREATE TABLE Lehrveranstaltung (

\(2\) LV# INTEGER PRIMARY KEY,

\(3\) Titel VARCHAR (50) NOT NULL UNIQUE DEFAULT \'unbekannt\',

\(4\) Hörsaal# INTEGER,

\(5\) CONSTRAINT Hörsaal_FS FOREIGN KEY (Hörsaal#) REFERENCES Hörsaal

);

\(6\) CREATE TABLE Hörsaal (

\(7\) Hörsaal# INTEGER PRIMARY KEY,

\(8\) Kapazität INTEGER CHECK (Kapazität \> 0)

\(9\) Lage VARCHAR (20) CHECK Lage IN (\'Hauptgebäude\', \'Irchel\',
\'Häldeliweg\')

);

Für die Definition der Attribute steht eine Vielzahl von Datentypen zur
Verfügung. In diesem Fall wird zu jedem Attribut der Name der
gewünschten Domäne angegeben. Konsistenzbedingungen können entweder
separat wie in Zeile 5 oder zusammen mit dem jeweiligen Attribut wie in
den Zeilen 2, 3, 7, 8 und 9 festgelegt werden. Die separate Form ist
zwingend, falls mehr als ein einzelnes Attribut betroffen ist. Allen
Konsistenzbedingungen kann auch ein Name zugeordnet werden. In Zeile 3
wird verlangt, dass die Werte für den Titel einer Lehrveranstaltung
eindeutig zu sein haben und dass der Wert NULL hierfür ausgeschlossen
ist. Für Primärschlüsselattribute gilt natürlich die
Eindeutigkeitsforderung implizit. Zeile 8 legt fest, dass die
Sitzplatzkapazität von Hörsälen positiv sein muss, Zeile 9 schränkt die
zulässigen Lageangaben von Hörsälen auf die drei aufgezählten Werte ein.
Zeile 5 erklärt das Attribut Hörsaal# als Fremdschlüssel, der sich auf
die Relation Hörsaal bezieht. Schließlich sagt Zeile 3 aus, dass die
Standardvorbesetzung für das Attribut Titel der Wert \"unbekannt\" ist;
er wird gespeichert, wenn beim Einfügen eines neuen Tupels kein
entsprechender Wert vom Benutzer genannt wird. Konsistenzbedingungen
müssen zu allen Zeitpunkten erfüllt sein. Mit der Definition eines
Relationenschemas wird auch eine Instanz angelegt. Diese anfangs
\"leere\" Relation ist auf jeden Fall konsistent. Anschließend muss ein
SQL-konformes DBMS bei jeder Änderung an der Datenbank überprüfen, ob
ihre Durchführung eine der spezifizierten Bedingungen verletzten würde.
Ist dies der Fall, wird das DBMS die Ausführung der entsprechenden
Operation in der Regel ablehnen. Lediglich für referentielle
Integritätsbedingungen sind auch andere Lösungen denkbar und bisweilen
sinnvoll. Beispielsweise könnte man für einen Fremdschlüssel den Wert
NULL einsetzten, wenn das Tupel mit dem ursprünglich referenzierten
Primärschlüssel gelöscht wird. Dies könnte im Beispiel etwa durch die
folgende Erweiterung von Zeile 5 erreicht werden:

(5) CONSTRAINT Hörsaal_FS FOREIGN KEY (Hörsaal#)

REFERENCES Hörsaal

ON DELETE SET NULL

Darüber hinaus bestehen weitere Optionen wie das kaskadierende Löschen
des referenzierenden Tupels oder der Eintrag eines Standardwertes (für
den dann die Existenz eines Tupels mit entsprechendem
Primärschlüsselwert garantiert sein muss).

Obwohl ein Schema das Rückgrat jeder Datenbank darstellt und vorhanden
sein muss, bevor überhaupt Daten in das System eingebracht werden
können, ist die Notwendigkeit von späteren Änderungen am Schema nicht
auszuschließen. Dies hat Rückwirkungen auf die zu diesem Zeitpunkt
bereits existierende Datenbank. SQL bietet in diesem Zusammenhang
Anweisungen zur Änderung und sogar Beseitigung der Definition
vorhandener Relationen.

(1) ALTER TABLE Hörsaal

ADD COLUMN Video CHARACTER(1) CHECK Video IN ( \'J\', \'N\');

(2) ALTER TABLE Hörsaal

DROP COLUMN Lage;

(3) DROP TABLE Hörsaal;

In (1) wird die Relation Hörsaal um ein Attribut erweitert, das angibt,
ob eine Videoanlage vorhanden ist oder nicht; man beachte, dass die
gewählte Typkonstruktion den eigentlich benötigten, aber im aktuellen
SQL-Standard nicht angebotenen Typ Boolean ersetzen soll. In (2) wird
ein vorhandenes Attribut einer Relation gelöscht, in (3) ein
Relationenschema zusammen mit der Relation selbst aus der Datenbank
entfernt. Beim Löschen von Attributen oder ganzen Relationen ist darauf
zu achten, dass sämtliche weiter existierenden Konsistenzbedingungen
eingehalten bleiben; insbesondere gilt dies für referentielle
Integrität.

### 2.2.3 Datenmodelle mit Objektkonzepten

Das Paradigma der Objektorientierung - charakterisiert durch die
Grundkonzepte Objekte und Klassen. Objektidentität, Methoden, Kapselung,
Taxonomien und Vererbung - hat sich in den letzten Jahren in vielen
Teilbereichen der Informatik durchgesetzt. Insbesondere für
Systemanalyse, -entwurf und Implementierung findet es auch in der Praxis
großen Widerhall. Es liegt daher nahe, entsprechende Konzepte auch für
Datenmodelle in DBMS vorzusehen. Dies wird insbesondere von den
Anwendern objektorientierter Programmiersprachen gefordert, die den
\"nahtlosen\" Transport von Objekten zwischen Sprachsystem und Datenbank
verlangen, während beim Einsatz rationaler und anderer konventioneller
Datenmodelle in fast allen Fällen erst eine mühsame und Aufwand
verursachende \"Zerlegung\" in deren Grundstrukturen erforderlich wird.

#### Objektorientierte Datenmodelle

Die seit Ende der achtziger Jahre angebotenen sog. Objektorientierten
Datenbanksysteme (OODBMS) oder Objektdatenbanksysteme (ODBMS) fußen auf
einem objektorientierten Datenmodell, welches die bekannten Konzepte der
Objektorientierung mehr oder minder \"in Reinkultur\" enthält:

-   Eine objektorientierte Datenbank besteht aus Objekten, welche
    Instanzen im Datenbankschema definierter Klassen sind. Objekte
    bestehen aus einem Wert, der sich im Laufe der Zeit verändern kann,
    und aus einer Reihe von Methoden, welche beim Versand entsprechender
    Botschaften an das Objekt ausgeführt werden; sie können sowohl
    Ergebnisse nach außen liefern, als auch den Wert des Objekts
    verändern.

-   Jedes Objekt ist jederzeit von jedem anderen unterscheidbar, d.h.
    Objektidentität ist durch systemtechnische Maßnahmen garantiert.

-   Die bei strikter Sichtweise der Objektorientierung verlangte
    Einkapselung von Methoden und Zustand wirft für Datenbanksysteme
    Probleme auf. Schließlich ist es hier ein wichtiges
    Grunderfordernis, Objekte assoziativ, d.h. aufgrund von
    Bestandteilen ihres Wertes auswählen zu können. Objektorientierte
    Datenmodelle lösen dieses Problem entweder dadurch, dass sie für
    alle Bestandteile des Objektwertes automatisch Botschaften und
    zugehörige Methoden zum Lesen und Schreiben erzeugen, oder indem sie
    zulassen, den Wert oder ausgewählte Teile davon als \"öffentlich\"
    und damit auch - trotz Einkapselung im übrigen - als les- und
    schreibbar zu deklarieren. Der Klassendefinierer hat damit die
    Freiheit, je nach Anforderung strikte, teilweise oder überhaupt
    keine Einkapselung der Objektwerte zu verlangen. Alle öffentlichen
    Wertteile können in diesem auf gleiche Weise verwendet werden, wie
    etwa die Attribute relationaler Tupel.

-   Objektwerte können komplex aufgebaut werden. Im Gegensatz zu den
    \"flachen\" Tupeln der relationalen Welt können hier mit
    entsprechenden Konstruktoren beliebige Tupel, Mengen, Listen und
    mehr aufgebaut werde, wobei Schachtelungen selbstverständlich
    zugelassen sind. Zudem stehen neben numerischen, alphanumerischen
    usw. Werten auch Referenzen auf andere Objekte als zusätzliche
    atomare Werte zur Verfügung, aus denen Tupel, Mengen, Listen usw.
    zusammengesetzt werden können. Objektidentität bietet die dafür
    erforderliche Grundlage. Auf diese Weise können vernetzte
    Objektstrukturen unmittelbar im Datenmodell wiedergegeben werden.
    Als wichtiger Spezialfall wird manchmal noch zusätzlich das
    Modellierungskonzept \"komplexes Objekt\" angeboten, mit dem die
    Assoziation von Objekten zu einem Gesamtobjekt ausgedrückt werden
    kann, welches dann auch als Ganzes manipulierbar ist.

-   Taxonomien aus der Anwendungswelt können durch entsprechende
    Klassenhierarchien direkt ausgedrückt werden, wobei das Prinzip der
    Vererbung benutzt wird.

Objektorientierte unterscheiden sich von konventionellen Datenmodellen
vor allem in folgenden Aspekten. Zum einen können dank der Konzepte
\"komplexe Werte\" und \"Referenzen\" auch komplexe Strukturen der
Anwendungswelt direkt und ohne künstliches Aufbrechen dargestellt
werden. Ähnliches gilt wie bereits erwähnt für Taxonomien. Zum anderen
kann nun auch die für den Umgang mit Objekten jeweils Funktionalität
klassenspezifisch zum Bestandteil der Datenbank gemacht werden. Bei
früheren Datenmodellen stand lediglich generische Standardfunktionalität
zur Verfügung, wodurch ein größerer Teil der Entwicklungsarbeit in die
Anwendungssoftware abgeschoben wurde.

#### Objektrelationale Datenmodelle

Neueste Entwicklungen versuchen, relationale und objektorientierte
Datenmodelle sog. Objektrelationalen Datenbanksystemen unter einen Hut
zu bringen. Hierbei besteht die Grundidee darin, die relationalen
Grundstrukturen um einige neue Konzepte zu erweitern. Eine
objektrelationale Datenbank besteht demzufolge weiterhin aus einer Menge
von Relationen. Allerdings steht für deren inneren Aufbau eine Reihe
zusätzlicher, im \"reinen Relationenmodell\" unbekannter Konzepte zur
Verfügung:

-   Benutzer können sog. Abstrakte Datentypen (ADTs) definieren. Hierbei
    handelt es sich im Wesentlichen um das Äquivalent von Klassen in
    objektorientierten Datenmodellen, wobei strikte Einkapselung
    durchgesetzt wird. Domänen für Attribute von Relationen können damit
    auch durch einen ADT und nicht nur durch die üblichen vordefinierten
    einfachen Domänen wie Zahlen, Zeichenketten oder Datumsangaben
    spezifiziert werden. Man beachte jedoch, dass Instanzen von ADTs
    Werte sind, also keine Objektidentität besteht.

-   Für Tupel kann die Vergabe von Objektidentifikatoren verlangt
    werden. Dies ist bei der Definition einer Relation allerdings
    explizit anzugeben. Als zusätzliche Domäne sind dann auch Verweise
    auf die Tupel einer solchen Relation erlaubt. Ein Attribut eines
    Tupels einer Relation kann damit als Wert einen Verweis auf ein
    Tupel einer Relation aufweisen, womit die von objektorientierten
    Datenmodellen bekannten Objektstrukturen nachgebildet werden können.

-   Im Gegensatz zum eigentlichen Relationenmodell können nunmehr
    Relationenschemata und Relationen separat definiert werden, womit
    prinzipiell auch mehrere Relationen zu einem einzigen
    Relationenschema möglich werden. Zudem können bei der Definition von
    Tupeltypen auch Konstruktoren für Mengen und Listen verwendet
    werden. Über die bekannten \"flachen\" Tupel hinaus können damit
    auch Tupel mit Substrukturen aufgebaut werden.

-   In der Datenbank kann Programmcode in Form sog. \"stored
    procedures\" gespeichert und dann unter der Regie des DBMS
    ausgeführt werden. Damit ist es möglich, mit den eigentlichen Daten
    assoziierte Basisfunktionalität ebenfalls zum Bestandteil der
    Datenbank und damit für alle Anwendungen verfügbar zu machen. Als
    Programmiersprache kann entweder die verfügbare Datenbanksprache
    oder eine allgemeine Programmiersprache verwendet werden. Damit
    besteht ein den Methoden der Objektorientierung entsprechendes
    Konzept, wenngleich es hier mehr oder minder allein stehend und
    nicht der Definition von Klassen fest zugeordnet ist.

-   Sowohl für ADTs als auch für Tupeltypen können taxonomische
    Strukturen mit Vererbung aufgebaut werden.

-   Als weitere Domäne werden sog. Lange Felder (BLOBs - binary large
    objects) angeboten. Damit kann umfangreiche unstrukturierte
    Information in der Datenbank selbst untergebracht und in
    weitestgehend gleicher Weise wie \"übliche Attribute\" verwendet
    werden, etwa um gerasterte Bilder oder Videosequenzen zu speichern.

## 2.3 Datenzugriff und -manipulation

Datenbanken sind als Spiegelbild eines Ausschnitts der realen Welt
häufig Veränderungen unterworfen: Neue Datenelemente müssen eingefügt,
vorhandene gelöscht oder in ihren Details verändert werden. Zudem ist es
der Hauptzweck von Datenbanken, dass ihr Inhalt den Benutzern zu
beliebigen Zeitpunkten wieder zugänglich gemacht werden kann. Letzteres
bezeichnet man als Datenzugriff, die vorgenannten Änderungen an der
Datenbank als Datenmanipulation. Die Sprachmittel hierzu werden in
Datenmanipulationssprachen (data manipulation language, DML) dargeboten.

### 2.3.1 Konzepte

Für den Datenzugriff und die meisten Aspekte der Datenmanipulation
müssen die betroffenen Daten aus der Gesamtheit der vorhandenen Daten
ausgewählt werden. Aus Sicht des Datenbankbenutzers sind die
entsprechenden Daten in aller Regel durch Eigenschaften festgelegt, die
sie haben müssen. Beispielsweise interessiert man sich für alle
Angestellten, die in einer bestimmten Abteilung arbeiten und ein Gehalt
beziehen, das über einem gegebenen Wert liegt. Bei einem Datenzugriff
sind die entsprechenden Datenelemente dem Benutzer anzuzeigen oder dem
Anwendungsprogramm zur weiteren Bearbeitung zu übergeben, bei einer
Datenmanipulation sind diese Elemente zu modifizieren oder aus der
Datenbank zu löschen.

-   Alle Teile die von der Struktur her \"passen\" werden nach der Reihe
    aus der Datenbank geholt und der Benutzer oder das
    Anwendungsprogramm entscheidet ob die gefundenen Daten erwünscht
    sind.

-   Durch entsprechende Befehle an das DBMS wird dort von Datenelement
    zu Datenelement \"navigiert\", wobei strukturelle Information wie
    etwa die Zugehörigkeit von Angestellten zu Abteilungen ausgenutzt
    wird. Soweit unterstützt liefert das DBMS nun die gewünschten
    Datenelemente.

-   Der Benutzer formuliert dem DBMS gegenüber möglichst präzise die
    Eigenschaften, die die gewünschten Daten aufweisen sollen; das
    System liefert die Menge der sich qualifizierenden Daten zurück.

![](media/image7.png)**Abbildung 8:** Prinzip deskriptiver Anfragen

Die erste Möglichkeit entspricht dem Arbeiten mit Dateien und wird den
Anforderungen an ein Datenbanksystem nicht gerecht. Die zweite
Möglichkeit findet sich vor allem in Datenmodellen mit ausgeprägten
Strukturen zwischen den Datensätzen, die demzufolge eine größere Anzahl
von Operatoren für Navigation und Zugriff anbieten; ein ansehnlicher
Teil der Arbeit bleibt damit immer noch dem Benutzer überlassen. Im
dritten Fall spricht man von deskriptiven Anfragen; sie beruhen auf
einem stark mengenorientierten Vorgehen, dessen Prinzip in **Abbildung
9** skizziert ist.

### 2.3.2 Anfragesprachen

-   Daten auffinden. Das SQL-Grundmuster für Anfragen an eine Datenbank
    lässt sich wie folgt skizzieren:

> SELECT \<was?\>
>
> FROM \<woher?\>
>
> WHERE \<mit welchen Eigenschaften?\>

In der Select-Klausel ist anzugeben, von welchen Attributen das
Anfrageergebnis die Werte enthalten soll; diese Attribute bilden
implizit ein Tupel, das Anfrageergebnis ist damit selbst wieder eine
Relation. In der From-Klausel wird spezifiziert, welche Relationen zum
Ergebnis beitragen oder zu seiner Ermittlung benötigt werden. In der
Where-Klausel schließlich wird prädikativ festgelegt, welche
Eigenschaften erfüllt sein müssen, damit Tupel in die Ergebnisrelation
aufgenommen werden können; zur Formulierung dieses Prädikats können
weitere geschachtelte SQL-Anfragen verwendet werden. Interessiert man
sich beispielsweise für Nummer und Lage aller Hörsäle mit mehr als 300
Sitzplätzen, so ist zu schreiben

SELECT Hörsaal#, Lage FROM Hörsaal WHERE Kapazität \>300;

Die Ergebnisrelation enthält bei Anwendung auf die Datenbank aus Bild 3
die beiden Tupel (150, Hauptgebäude) und (330, Irchel). Soll das
Ergebnis alle Attribute der Ausgangsrelation enthalten, so kann man dies
abkürzen:

SELECT \* FROM Dozent WHERE Adresse = \'Plattenstrasse 14\';

Sind keine besonderen Bedingungen zu erfüllen, wird die Where-Klausel
einfach weggelassen; in diesem Fall wird für die Auswertung \"WHERE
true\" unterstellt.

Komplexere Anfragen kommen insbesondere dann zustande, wenn die
Ergebnisattribute aus mehreren Relationen stammen oder wenn die zu
erfüllende Bedingung weitere Relationen einbezieht. Dies ist vor allem
dann der Fall, wenn Relationen über Primär- und Fremdschlüssel
korreliert werden (\"join\"):

SELECT V. Titel FROM Lehrveranstaltung AS V, liest AS L,

> Dozent AS D

WHERE D. Nachname = \'Tell\' AND D. PNr = L.Doz

AND L.LV# =V.LV#;

In diesem Fall werden die Titel aller Lehrveranstaltungen ermittelt, die
Dozent \"Tell\" abhält. Durch das Schlüsselwort \"AS\" werden V, L und D
als sog. Qualifikationsvariablen für die jeweils davor genannte Relation
definiert; sie sind immer dann erforderlich, wenn in einer Anfrage
gleichnamige Attribute aus mehreren Relationen angesprochen werden
müssen. In anderen Fällen können sie auch weggelassen werden. Als
Beispiel für eine geschachtelte Anfrage dient \"ermittle die Titel aller
Lehrveranstaltungen, welche in Hörsälen mit mehr als 150 Plätzen
stattfinden\":

SELECT Titel FROM Lehrveranstaltung

WHERE Hörsaal# IN (SELECT Hörsaal# FROM Hörsaal

WHERE Kapazität \> 150);

Dieses Bild zeigt auch, dass in SQL häufig dasselbe Ergebnis auf
unterschiedliche Weise erzielt werden kann. Folgende Anweisung ist der
eben gezeigten gleichwertig:

SELECT Titel FROM Lehrveranstaltung AS V, Hörsaal AS H

WHERE V.Hörsaal# = H.Hörsaal# AND H.Kapazität \> 150;

Ein relationales DBMS soll dabei so implementiert sein, dass es nicht
nur hinsichtlich des erzielten Ergebnisses, sondern auch hinsichtlich
der Effizienz der Anfrageausführung völlig unerheblich ist, welche
Formulierung der Anwender wählt. Das DBMS wird hierzu für jede Anfrage
intern einen Ausführungsplan erarbeiten, der auf einer möglichst
günstigen Strategie beruht (Anfrageoptimierung). Zusätzliche
Funktionalität erhält SQL dadurch, dass sog. Aggregatfunktionen zur
Verfügung gestellt werden, welche die Berechnung von Summen (SUM),
Durchschnitten (AVG), Maxima (MAX) und Minima (MIN) zahlartiger
Datenbankinhalte durch das DBMS selbst ermöglichen; ebenso können auf
diese Weise Anzahlen vorhandener Tupel mit bestimmten Eigenschaften
erfragt werden (COUNT):

SELECT SUM(Kapazität) FROM Hörsaal WHERE Lage =

\'Hauptgebäude\';

SELECT COUNT(\*) FROM Dozent;

In diesem Beispiel wird die Gesamtanzahl der Dozenten ermittelt und als
Ergebnisrelation dargestellt. Möchte man im vorgehenden Fall nicht nur
die Sitzplatzkapazität der Hörsäle im Hauptgebäude kennen lernen,
sondern eine Liste mit der jeweiligen Gesamtkapazität aller
Einzelstandorte erhalten, so kann dies durch eine zusätzliche
Gruppierungsklausel erreicht werden:

SELECT Lage, SUM(Kapazität) FROM Hörsaal GROUP BY Lage;

Das Ergebnis in diesem Beispiel die Tupel (Hauptgebäude, 675) und
(Irchel, 600). Schließlich kann durch eine ergänzende Ordnungsklausel
dafür gesorgt werden, dass eine Ergebnisrelation nach bestimmten
Kriterien geordnet ausgegeben wird (ASC spezifiziert aufsteigende - in
diesem Fall lexikographische - Ordnung):

SELECT Nachname, Vorname, Telefon FROM Dozent

ORDER BY Nachname, Vorname ASC;

Soll die Mengeneigenschaft von Anfrageergebnissen garantiert werden, ist
dies explizit zu erzwingen:

SELECT DISTINCT Lage FROM Hörsaal WHERE Kapazität \> 150;

*Daten ändern*

UPDATE Lehrveranstaltung SET Titel = \'Betriebssysteme\',

Hörsaal# = 104

WHERE LV# = 314;

UPDATE Hörsaal SET Kapazität = Kapazität \* 1.05 WHERE Lage =

\'Hauptgebäude\';

*Daten löschen*

DELETE FROM Hörsaal WHERE Lage = \'Hauptgebäude\';

DELETE FROM Lehrveranstaltung;

*Daten einfügen*

INSERT INTO Lehrveranstaltung (LV#, Titel)

VALUES (217, \'Graphische Datenverarbeitung\');

Für die nicht spezifizierten Attribute tritt in diesem Fall der Wert
NULL oder ein bei der Schemadefinition angegebener Standardwert in
Kraft; spätere Update-Anweisungen sind natürlich möglich. Mit der
Insert-Anweisung können auch ganze Mengen von Tupeln auf einmal
eingefügt werden. Definiert man etwa eine neue Relation

CREATE TABLE Standorte (

Ort VARCHAR (20) CHECK Lage IN (\'Hauptgebäude\', \'Irchel\',
\'Häldeliweg\')

Kapazität INTEGER CHECK (Kapazität \> 0)

);

dann kann diese erfüllt werden mit

INSERT INTO Standorte

SELECT Lage, SUM(Kapazität) FROM Hörsaal GROUP BY Lage;

### 2.3.3 Sichten

Sichten (views) sind ein Konzept, um Teile gespeicherter Relationen oder
anderer Sichten \"durch ein dynamisches Fenster\" zu betrachten.

CREATE VIEW HG_Hörsaal

AS SELECT \* FROM Hörsaal WHERE Lage = \'Hauptgebäude\';

CREATE VIEW Vorlesungsverzeichnis (LVNR, Titel, Ort, HS)

AS SELECT LV#, Titel, Nachname, Lage, LV.Hörsaal#

FROM Lehrveranstaltung AS LV, Dozent AS D, Hörsaal AS

HS, liest AS L

WHERE LV.Hörsaal# = HS.Hörsaal# AND LV.LV# = L.LV# AND

L.Doz = D.PNr;

CREATE VIEW VVZ_Irchel

AS SELECT \* FROM Vorlesungsverzeichnis WHERE Ort =

\'Irchel\';

CREATE VIEW Standorte (Ort, Kapazität)

AS SELECT Lage, SUM(Kapazität) FROM Hörsaal GROUP BY Lage;

Die vorletzte Sichtdefinition baut selbst auf einer anderen Sicht auf.
Das letzte Beispiel zeigt eine bessere Lösung der im vorherigen
Abschnitt gezeigten Situation. Die Definition einer Sicht führt in jedem
Fall lediglich zur Ablage ihrer Definition; es werden keinerlei
Datenstrukturen zur Aufnahme von Tupeln angelegt, und zu diesem
Zeitpunkt findet auch keinerlei Herleitung von Tupeln aus den
Basisrelationen statt. Während Änderungen an Sichtdefinitionen nicht
möglich sind, können vorhandene Sichten gelöscht werden:

DROP VIEW Standorte;

Anfragen an Sichten können völlig analog zu Anfragen auf Basisrelationen
formuliert werden; auch die Einbeziehung von Basisrelationen ist dabei
möglich:

![](media/image8.png) SELECT \* FROM Vorlesungsverzeichnis;

SELECT Ort FROM Standorte WHERE Kapazität 1000;

SELECT Titel FROM Lehrveranstaltung

WHERE Hörsaal# IN (SELECT Hörsaal# FROM HG_Hörsaal);

Das Prinzip der Bearbeitung einer solchen Anfrage lautet, dass das DBMS
die in einer From-Klausel genannte Sicht durch ihre Definition ersetzt
und dann die derart modifizierte Anfrage ausführt, welche nur noch
Basisrelationen anspricht.

Sichten vereinfachen die Formulierung von Anfragen, da ein Teil der
sonst erforderlichen Bedingungen, Korrelationen usw. bereits in der
Sichtendefinition vorformuliert und damit vom Systembenutzer nicht mehr
anzugeben ist; für ihn besteht der Eindruck, als wäre die Sicht eine
weitere gespeicherte Relation. Zusammen mit den
Zugriffsschutzmechianismen können Benutzern damit gerade diejenigen
Teile der Datenbank zugänglich gemacht werden, die sie für ihre Aufgaben
benötigen und verwenden dürfen. Das führt implizit zu externen Schemata
gemäß der 3-Schema-Architektur. Allerdings sind Relationen und Sichten
hinsichtlich ihrer Verwendbarkeit nicht völlig gleichwertig. Da Sichten
dynamische Fenster zur Betrachtung gespeicherter Relationen sind, müssen
sich Datenmanipulationsoperationen auf die jeweiligen Basisrelationen
auswirken. Je nach Sichtendefinition kann diese \"Rückwärtsabbildung\"
jedoch mehrdeutig oder unsinnig sein. Problemfälle sind insbesondere
Sichten, welche Schlüsselattribute der Basisrelationen nicht enthalten,
Teile aus mehreren Relationen zusammenfassen oder Attribute enthalten,
deren Werte durch Aggregatfunktionen aus den Basisrelationen errechnet
werden. Insert-, Delete- und Update-Operationen sind daher nur für
solche Sichten erlaubt, die die problemlose Zuordnung von Änderungen zu
Basisrelationen erlauben. Manche DBMS gehen den einfacheren Weg und
verbieten die Manipulation auf Sichten völlig.

## 2.4 Steuerung und Überwachung

### 2.4.1 Zugriffsschutz

In der realen Welt besteht eine Vielzahl von impliziten und expliziten
Festlegungen, wer welche Information in welcher Weise und unter welchen
Bedingungen zur Kenntnis nehmen, verwenden oder gar ändern darf. Trotz
der Integration verschiedenster Daten in einer Datenbank darf der
Einsatz dieses technischen Hilfsmittels nicht dazu führen, dass
eigentlich verbotene Datenzugriffe und -manipulationen möglich werden.
Zugriffskontrollmechanismen in Datenbanksystemen dienen diesem Zweck;
bei adäquatem Einsatz wehren sie nicht nur die durch rechnergestützte
Informationssysteme hervorgerufenen neuen Gefahren weitestgehend ab,
sondern erlauben in vielen Bereichen sogar einen besseren
Informationsschutz, als dies bei manuell gehaltenen Datensammlungen der
Fall ist. Zur Erläuterung wird wiederum das relationale Datenmodell und
SQL als Datenbanksprache betrachtet. Zugriffsschutz in Rechnersystemen
allgemein wird unter dem Grundparadigma \"wer darf womit was tun?\"
betrachtet. Subjekte sind hier in erster Linie sie einzelnen Benutzer
eines DBMS. Sie werden zunächst als zugelassenen Benutzer im System
registriert, erhalten eine Kennung und müssen sich bei jeder Anmeldung
zu einer Sitzung identifizieren. Das System prüft dann an Hand von
Passwörtern oder weitergehenden Mechanismen, ob ein Benutzer tatsächlich
der ist, als der er sich ausgibt. Darüber hinaus werden oft auch
Benutzergruppen registriert, denen einzelne Benutzer ihren Aufgaben
entsprechend dynamisch zugeordnet werden können. Ein spezielles Subjekt
kann Verwendung finden, wenn ein Privileg uneingeschränkt allen
Benutzern zuerkannt werden soll. Als weiter Subjekte kommen auch
Programme in Frage.

Durch das Sichtenkonzept ist ein sehr feiner, inhaltsorientierter und
abgestufter Zugriffsschutz möglich:

-   Da Sichtendefinitionen auf Select-Anweisungen aufbauen, können
    Schutzobjekte auf der Basis von Datenbankwerten (und nicht nur auf
    Grund von Datenbehältern) definiert werden.

-   Während Relationen oft groß sind und damit recht grobe
    Schutzeinheiten darstellen, können Sichten zu beliebig kleinen und
    damit feinen Schutzeinheiten definiert werden.

-   Auf Basis ein und derselben Relation können bei Bedarf zahlreiche
    verschiedene Sichten definiert werden.

-   Sichten können durch Korrelationen verschiedener Relationen
    definiert sein. Dadurch sind Einheiten schützbar, die in dieser Form
    physisch in der Datenbank gar nicht existieren.

Die Vergabe von Zugriffsrechten erfolgt dynamisch. Nach einer
Initialisierungsphase gelten hierfür im wesentlichen folgende Regeln:

-   Wer eine Relation erzeugt, erhält alle Privilegien dafür.

-   Wer eine Sicht definiert, erhält als Rechte an ihr die Schnittmenge
    aller Rechtemengen, die er an den Basisrelationen hat.

-   Wer bestimmte Rechte besitzt, kann diese unter gewissen
    Voraussetzungen an andere weitergeben.

-   Einmal erteilte Rechte können von demjenigen, der sie erteilt hat,
    wieder zurückgenommen werden.

-   Jede Rechtevergabe kann mit oder ohne Weitergabeoption erfolgen.
    Erhält man ein Recht ohne diese, so kann man es selbst zwar nutzen,
    aber nicht anderen weitergeben.

Die letzten drei Regeln erlauben im Prinzip eine dezentralisierte
Autorisierung, indem kein zentraler Administrator benötigt wird, dem
alle Autorisierungen übertragen sind. Bei durchgängigen Verzicht auf die
Weitergabeoption kann jedoch mit diesem Mechanismus die Wirkung einer
zentralisierten Autorisierung erzielt werden.

Als repräsentatives Beispiel für die sprachliche Formulierung von
Autorisierungen dient wiederum SQL, wo die Anweisungen für explizite
Rechteverteilung und Rechterückruf wie folgt lauten:

GRANT \<Privilegienliste\> ON \<Objekt\> TO \<Subjektliste\>

\[WITH GRANT OPTION\];

REVOKE \[GRANT OPTION FOR\] \<Privilegienliste\> ON \<Objekt\>

FROM \<Subjektliste\>\[RESTRICT/CASCADE\];

Die Teile in den eckigen Klammern sind optional. In der Privilegienliste
können einzelne Rechte aufgezählt werde; All Privileges an dieser Stelle
bedeutet \"alle zutreffenden und verfügbaren Rechte\", also insbesondere
alle Rechte, die überhaupt weitergegeben werden können. Analog zählt die
Subjektliste alle gewünschten Subjekte auf, oder sie enthält die Angabe
Public. Durch die Revoke-Anweisung kann statt früher vergebener Rechte
auch nur die Weitergabeoption für diese zurückgenommen werden. Generell
kann bei Revoke durch die Option Cascade erreicht werden, dass
eventuelle Weitergaben des betreffenden Rechts an Dritte rekursiv
ebenfalls zurückgerufen werden - es entsteht in diesem Fall ein
Autorisierungszustand, als ob das ursprüngliche Grant nie stattgefunden
hätte. Restrict prüft lediglich, ob transitive Rechteweitergaben
stattgefunden haben; wenn ja, wird ein Fehler gemeldet.

Die Zugriffskontrolle eines DBMS arbeitet gewöhnlich nach dem Prinzip
des positiven Schutzsystems: Alles ist verboten, was nicht explizit
erlaubt ist. Zu diesem Zweck prüft das DBMS bei jeder Operation, ob sie
im Rahmen der aktuell vorliegenden Autorisierungen zulässig ist oder
nicht. Nur im Falle einer erfolgreichen Prüfung wird die Operation auch
tatsächlich ausgeführt, andernfalls erfolgt eine Fehlermeldung.
Wichtigste Voraussetzung für das Funktionieren eines
Zugriffsüberwachungssystems ist seine Unumgehbarkeit. Hierzu muss bei
der Realisierung dafür gesorgt werden, dass kein Zugriff auf
Datenbankdaten am DBMS vorbei möglich ist. Zudem muss der im System
gespeicherte Autorisierungszustand sicher sein, so dass er nur im Rahmen
der genannten Regeln verändert werden kann. Je nach Systemumgebung
können weitere Maßnahmen wie die verschlüsselte Speicherung der
Datenbank auf dem Hintergrundspeicher angezeigt sein.

### 2.4.2 Konsistenzsicherung

Der Inhalt einer Datenbank soll die modellierte Umwelt möglichst korrekt
und widerspruchsfrei repräsentieren. Hierzu bieten neben den
Strukturierungskonzepten des Datenmodells Konsistenzregeln und ihre
Überwachung durch das DBMS Unterstützung. Bereits bei der Erläuterung
von Datenmodellen und den Mitteln zur Datendefinition wurden einige
einfache Konsistenzregeln wie Domänenbeschränkungen,
Schlüsselbeschränkungen, Gegenstandsintegrität und referentielle
Integrität besprochen. Allerdings können die Sachverhalte der Realwelt
auch komplexere Regeln verlangen. Damit diese nicht völlig in die
Verantwortung der Anwendungsprogrammierer abgeschoben werden müssen,
stehen beispielsweise für relationale Datenbanken weitere
Systemmechianismen zur Verfügung, die hier erläutert werden:
Zusicherungen (assertions) und Auslöseregeln (trigger). Mit einer
Zusicherung kann eine Bedingung spezifiziert werden, deren Einhaltung
vom DBMS geprüft wird und deren Verletzung bewirkt, dass die hierfür
verantwortliche Operation rückgängig gemacht wird. Für die Formulierung
der Bedingung stehen alle Sprachmittel der Where-Klausel von Anfragen
zur Verfügung; aus diesem Grund kann sie sich auch über mehrere
Relationen erstrecken. Im hier verwendeten Beispiel sei angenommen, dass
für Vorlesungen des Dozenten Tell immer ein Hörsaal zugeteilt werden
muss, der am Irchel oder im Hauptgebäude liegt und mindestens 300 Plätze
aufweist. Eine entsprechende Zusicherung könnte lauten:

CREATE ASSERTION Tell_Bedingung

CHECK (NOTEXISTS ( SELECT \* FROM Lehrveranstaltung

WHERE LV# IN ( SELECT LV# FROM liest,

Dozent

WHERE Doz = PNr AND Nachname = \'Tell\')

AND Hörsaal# IN ( SELECT Hörsaal# FROM Hörsaal

WHERE Kapazität \< 300

OR (Lage ≠ \'Hauptgebäude\'

AND Lage ≠ \'Irchel\'))))

BEGIN

. . .

END;

Diese Regel löst immer dann eine Prüfung der enthaltenen Bedingung (When
\...) aus, wenn neue Tupel in die Relation Lehrveranstaltung eingefügt
oder vorhandene dort verändert werden. Statt \"dann\" müsste es wegen
der Angabe After genauer \"nachdem\" heißen. An der Stelle von After
hätte auch Before stehen können. Unter der Annahme, die vorliegende
Realweltregel könnte dadurch verletzt werden, dass die Kapazität von
Hörsälen reduziert wird, wäre übrigens eine weitere Auslöseregel der
Form

CREATE TRIGGER Tell_Trigger_2 AFTER UPDATE ON Hörsaal \...

erforderlich. Man beachte, dass in Tell_Trigger die Bedingung nun gerade
umgekehrt wie bei der vorhergehenden Zusicherung formuliert wurde. Ist
sie erfüllt, wird die zwischen Begin und End zu formulierende Aktion
ausgeführt. Dort können je nach System weitere DBMS-Operationen oder
sogar beliebige Programme stehen.

### 2.4.3 Transaktionen

Für Konsistenzregeln wurde bisher stillschweigend angenommen, dass sie
stets gelten müssen, das heißt, jede einzelne
Datnemanipulationsoperation hat sie einzuhalten. Dies ist jedoch nicht
immer möglich, da eine aus Anwendungssicht sinnvolle Arbeitseinheit mit
der Datenbank oft nicht durch eine einzige Datenbankoperation formuliert
werden kann, womöglich aber erst alle Operationen einer solchen
Arbeitseinheit zusammen einen konsistenten Übergang bewirken.
Beispielsweise ist in einer Bankanwendung die Datenbank erst dann wieder
konsistent, wenn einer Abbuchung von einem Konto eine Gutbuchung auf
einem anderen gegenübersteht; dies erfordert jedoch jeweils eigene
Änderungsoperationen an der Datenbank. Das Konzept der Transaktion
ermöglicht es Anwendern , solche Arbeitseinheiten dem DBMS gegenüber zu
definieren. Hierzu stehen Operationen wie begin_TA und end_TA zur
Verfügung. Die bisher besprochenen Konsistenzregeln müssen dann übrigens
als verzögert deklariert werden, damit ihre Überprüfung bis an das Ende
einer Transaktion aufgeschoben wird.

![](media/image9.png)

**Abbildung 9:** Grobprinzip Transaktionskonzept. DB = Datenbank, TA =

Transaktion

In Bild 9 ist das Grobprinzip einer Transaktion dargestellt. Sie startet
als Folge einer begin_TA-Operation zum Zeitpunkt t~s~ in einem
konsistenten Datenbankzustand. Solange sie nicht erfolgreich beendet ist
, kann sie jederzeit implizit oder explizit abgebrochen werden. Das DBMS
wird in diesem Fall die betroffenen Teile der Datenbank in den Zustand
DB(t~s~) zurücksetzen. Mit einer end_TA-Anweisung tut die Anwendung
kund, dass die Transaktion aus ihrer Sicht erfolgreich beendet werden
kann. Das DBMS überprüft dann, ob dies auch aus seiner Sicht der Fall
ist. Falls nein, wird auch in diesem Fall zurückgesetzt. Andernfalls
gilt die Transaktion als \"festgelegt\", und der Datenbankzustand
DB(t~c~) wird so gesichert, dass er im Falle einer späteren
Fehlersituation rekonstruierbar ist. Die Anwendung kann sich also auf
die Wirkung von ihr erfolgreich beendeter Transaktionen verlassen,
sobald sie vom System eine Meldung über die erfolgte Festlegung erhalten
hat. Die Garantie von Rücksetzbarkeit und Dauerhaftigkeit von
Transaktionen erfordert systemseitig eine geeignete Kombination von
Datenbankabzügen und die Protokollierung von Transaktionsoperationen
oder den Ausgangs- und Endzuständen betroffener Datenbankteile. Hieraus
müssen bei Rücksetzen und beim Wiederanlauf nach Fehlern die jeweiligen
konsistenten Datenbankzustände sicher rekonstruiert werden. \"Sicher\"
bedeutet hier, dass selbst bei einem Fehler während der
Rekonstruktionsphase die genannten Leistungen garantiert bleiben. Es
existieren vielerlei Vorgehensweisen, die entsprechende Funktionalität
bei möglichst geringen Leistungseinbußen während des regulären Betriebs
erbringen. Konkurrenzsteuerung erfordert, dass bei parallel laufenden
Transaktionen Zugriffe auf dasselbe Datenbankelement nur nach bestimmten
Regeln erfolgen dürfen, so dass keine inkorrekten Ergebnisse in der
Datenbank entstehen oder als Ergebnisse nach außen dringen können. Das
heute übliche Korrektheitskriterium ist dabei das der
Serialisierbarkeit: Die verzahnte Ausführung mehrerer Transaktionen darf
nur solche Ergebnisse liefern, die auch bei einer möglichen
sequentiellen Ausführung dieser Transaktionen entstehen könnten. Dieser
Effekt kann erreicht werden, wenn alle Transaktionen die von ihnen
benötigten Datenbankelemente vor der eigentlichen Benutzung sperren und
sich dadurch synchronisieren. Günstigerweise unterscheidet man zwischen
Lese- und Schreibsperren. Die Idee dabei ist, dass zwei lesende
Transaktionen keine Gefahr für die Korrektheit darstellen, dass aber
eine schreibende Transaktion sich potentiell nicht mit anderen
Transaktionen verträgt. Auf dieser Grundlage kann man eine
Verträglichkeitsmatrix zwischen aktuell gesetzten und angeforderten
Sperren für Datenelemente aufstellen, die das Verhalten der
DBMS-Sperrkomponente steuert. Kann einer Transaktion eine gewünschte
Sperre im Augenblick nicht gewährt werden, wird sie in einen
Wartezustand versetzt, bis das betreffende Datenelement wieder verfügbar
ist. Auch hier sind vielerlei Details zu beachten, und es existieren
vielerlei Alternativen für den DBMS-Implementierer.

Die folgende Liste gibt einige Anregungen:

-   Alle Transaktionen müssen sich an bestimmte Protokolle hinsichtlich
    des Sperrens und Entsperrens von Datenelementen, der dafür zu
    wählenden Zeitpunkte usw. halten. Dies muss jedoch nicht dem
    Transaktionsprogrammierer überlassen bleiben, sondern kann fest in
    den Transaktionsmechanismus eingebaut werden.

-   Es besteht ein enger Zusammenhang zwischen möglichem
    Parallelitätsgrad und der Größe von Sperrgranulaten; hierunter
    versteht man die Arten von Datenbankelementen, die überhaupt von
    Transaktionen gesperrt werden können. Sowohl logische (Relationen,
    Tupel, einzelne Attribute) als auch physische Datenelemente (Blöcke,
    Dateien) kommen in Frage. Bei (wenigen) größeren Sperrgranulaten
    fällt naturgemäß weniger Systemaufwand an als bei (vielen)
    kleineren. Allerdings wird dadurch auch die Parallelität
    eingeschränkt, da es schnell zu impliziten Sperre von logischen
    Datenelementen kommt, die die jeweilige Transaktion überhaupt nicht
    anspricht.

-   Durch die weitere Differenzierung von Sperrmodi (über Lesen und
    Schreiben hinaus) können alternative Verträglichkeitsmatrizen
    definiert werden, die die Anzahl in Konflikt stehender
    Sperranforderungen herabsetzen und dadurch bessere Parallelität
    ermöglichen.

-   Für die Implementierung von Sperrverfahren benötigt man außer der
    genannten Verträglichkeitsmatrix eine Liste aller augenblicklich
    gesetzten Sperren und Angaben darüber, welche Transaktion welche
    Sperre gesetzt hat. Zudem müssen Warteschlangen gehalten werden, in
    denen die auf Sperrfreigaben wartenden Transaktionen verzeichnet
    sind. Für die Verwaltung dieser Warteschlangen können
    unterschiedliche Grundsätze angewendet werden.

-   Es ist denkbar, dass Transaktionen wechselseitig auf die Freigabe
    von Sperren warten, die die jeweils andere Transaktion schon gesetzt
    hat. Durch die Verwendung spezieller Protokolle lassen sich solche
    Verklemmungen prinzipiell vermeiden. Allerdings entstehen dabei
    starke Einschränkungen, so dass man solche Situationen in der Regel
    lieber hinnimmt und entsprechend behandelt. Zu diesem Zweck muss das
    Eintreten einer Verklemmung erst einmal entdeckt werden. Das System
    führt daher Buch über die Abhängigkeit laufender Transaktionen im
    Sinne von \"Transaktion 1 wartet darauf, dass Transaktion 2 eine
    Sperre freigibt\". Wird in dem so entstehenden Graphen ein Zyklus
    gefunden, liegt eine Verklemmung vor. Sie kann beseitigt werden,
    indem (mindesten) eine der beteiligten Transaktionen abgebrochen und
    zurückgesetzt wird.

### Verteilung

Datenbanken sollen nicht immer zentral in einem Rechner verwaltet
werden, sonder in einem Rechnernetz und damit auch geographisch verteil
sein können. Trotzdem soll die Anwendung meist soweit wie möglich von
den Details der Verteilung abgeschirmt bleiben, Verteilungstransparenz.
Ein verteiltes Datenbanksystem im engeren Sinn liegt dann vor, wenn eine
logisch integrierte Datenbank im bisherigen Sinn physisch auf mehrere
Knoten eines Rechnernetzes verteilt ist, über ein verteiltes DBMS aber
so verwaltet wird, dass sie von den Benutzern wie in einem
zentralisierten System verwendet werden kann. Hierzu muss die Software
des verteilten DBMS an jedem Knoten vorhanden sein und alle Teilsysteme
müssen miteinander kooperieren. Grundsätzlich fallen in einer solchen
Umgebung zunächst dieselben Aufgaben wie in einem zentralisierten DBMS
an. Darüber hinaus sind aber vor allem in drei Bereichen zusätzliche
Probleme zu lösen.

**Verteilungsentwurf:** Zuerst muss in einem verteilten Datenbanksystem
entschieden werden, welches die Einheiten der Verteilung sein sollen. Im
Falle rationaler Datenbanken entscheidet man sich aus
Praktikabilitätsgründen für Teile von Relationen, die durch horizontale
oder vertikale Fragmentierung zustande kommen können.

Strukturell sind alle Fragmente selbst wieder Relationen und können
daher in den einzelnen Knoten auch wie gewohnt als solche verwaltet
werden. Horizontale Fragmentierung bedeutet, dass eine Ausgangsrelation
auf Grund bestimmter Kriterien in Teilmengen der vorhandenen Tupel
zerlegt wird. Bei der vertikalen Fragmentierung werden die einzelnen
Fragmente durch verschiedene Teilmengen der ursprünglich vorhandenen
Attribute festgelegt, wobei die Schlüsselattribute der Ausgangsrelation
in jedem Fragment vorhanden sein müssen.

**Ausführung verteilter Anfragen und Manipulationsoperationen:**
Anfragen an die verteilte Datenbank werden jeweils an einen der
beteiligten Knoten gestellt und betreffen Relationen und Sichten des
globalen Schemas. Nun sind aber gar nicht diese Relationen gespeichert,
sondern einzelne Fragmente, die daraus entstanden sind. Eine Anfrage
wird also häufig mehrere Fragmente betreffen, die in verschiedenen
Knoten gespeichert sind. Bei der Bearbeitung derartiger Anfragen muss
also an Hand des Katalogs ermittelt werden, welche Fragmente beteiligt
sind und wo sie sich befinden. Bei repliziten Fragmenten kann noch
dahingehend optimiert werden, dass ein möglichst günstig verfügbares
Fragment ausgewählt wird. Anschließend werden einzelne Fragmentanfragen
an die beteiligten Knoten übermittelt und dort wie im Falle eines
zentralisierten DBMS bearbeitet. Die so erzielten Teilergebnisse
gelangen schließlich wieder an den Ausgangsknoten und müssen dort zum
eigentlich verlangten Gesamtergebnis zusammengefügt werden.

**Bearbeitung verteilter Transaktionen**: Hierzu muss die
Konkurrenzsteuerung nunmehr den Verteilungsaspekt der zu sperrenden
Dateneinheiten berücksichtigen. Das ist kein besonderes Problem, solange
keine Replikate existieren. Andernfalls ist sicherzustellen, dass bei
Datenbankänderungen jeweils alle betroffenen Replikate gesperrt werden.
Dies ließe sich recht einfach dadurch erreichen, dass es eine zentrale
Sperrinstanz im Gesamtsystem gibt, die allerdings schnell zu einem
Engpass werden kann. Günstiger ist es schon, wenn für jedes Fragment
eine sog. Primärkopie ausgezeichnet wird, diese ist dann in jedem Fall
zu sperren, egal welche Kopie aktuell verwendet werden soll. Funktional
am günstigsten, aber leider realisierungstechnisch auch am
aufwendigsten, sind voll verteilte Sperrverfahren.

## Zusammenfassung:

Datenbankverwaltungssysteme sind Softwareprodukte die eine dauerhafte
und anwendungsunabhängige Speicherung, Verwaltung und bequeme Verwendung
von großen, mehrfachbenutzbaren integrierten Datenbasen ermöglichen.

Datenbanksysteme erleichtern uns das Leben, was früher mühsam mit der
Hand geschrieben und sortiert hat werden müssen gelingt uns jetzt per
Mausklick. Man kann bestimmte Daten einfach durch die Eingabe von
Suchkriterien aus hunderten von Daten finden. Mit Hilfe der
Datenbanksprache SQL lassen sich viele Konzepte zur Erstellung von
Datenbanken realisieren. Neue Datenbanksysteme wie die Objektorientierte
und Objektrelationale ermöglichen eine noch bessere Verwaltung von
Daten.

Man kann auch verhindern das \"Unbefugte\" Zugriff zu geheimen Daten
bekommen, nur wer beispielsweise eine Relation erzeugt hat hat auch das
Zugriffsrecht auf diese. Durch das Sichtenkonzept zum Beispiel ist ein
sehr feiner, inhaltsorientierter und abgestufter Zugriffsschutz möglich.

# 3 Referenzliste

## Multimedia

\[Gibbs 95\] Gibbs.S.J.: Tsicheritzis.D.C.: Multimedia program ming,
objects, enviroment and frameworks, New York: ACM Press 1995.

\[Steinmetz 99\] Multimedia-Technologie: Grundlagen, Komponenten und
Systeme. 2. Aufl. Berlin: Springer Verlag 1999.

\[Steinmetz 95\] Steinmetz. R.: Analyzing the multimedia operating sys
tem. IEEE MultiMedia 2/1 (1995) 68-83.

\[Taylor 89\] Taylor, M.M.: Néel. F.: Bouwhuis, D.G. (eds.).: The
structure of multimodual dialogue. Amsterdam:

Elsevier Science-Verlag 1997.

\[Multimedia Systems 95\] Multimedia Systems, 3 (1995) 1. Berlin:
Springer-Verlag 1995.

\[Nielsen 95\] Nielsen, J.: Multimedia and hypertext: the internet and
be yond. Cambridge, MA: AP. Professional 1995.

\[CACM 94\] Communications of the ACM (special issue on hyper-me dia) 37
(1994) 2.

\[Abdobe 00\] Adobe® Photoshop® 6.0 Handbuch für Windows® und Macintosh,
how to work with modern graphic-

systems, 2000.

##  Datenbanksysteme

\[Berson 97\] Berson. A.: Smith,S.J.: Data warehousing, data mining, and
OLAP, New York: Mc Graw-Hill 1997

\[Cattell 94\] Cattell, R.G.G.: Object data management --
object-oriented and extended relational database systems. Revised
Edition. Reading, Mass.: Addison-Wesley 1994

\[Conrad 97\] Conrad, S.: Föderierte Datenbanksysteme - Konzepte der
Datenintegration. Berlin: Springer 1997

\[Dittrich 96\] Dittrich, K. R.: Gatziu, S.: Aktive Datenbanksysteme -
Konzepte und Mechanismen. Bonn: International Thomson Publishing 1996

\[Gray 93\] Gray, J.: Reuter, A.: Transaction processing - concepts and
techniques. San Francisco: Morgan Kaufmann 1993

\[Melton 93\] Melton, J.: Simon, A. R.: Understanding the new SQL: a
completeguide. San Francisco: Morgan Kaufmann 1993

\[Paton 99\] Paton, N. W.: Active rules in databasesystems. New York:
Springer 1999