Duale Hochschule
Baden-Württemberg
Prof. Dr. Hans Jürgen Ott

Ausdruck der Skript-Teile
 
Online-Skriptensystem von Prof. Dr. Hans Jürgen Ott
4dmod

Modellierung von Datenbanken und Informationssystemen

Mit diesem Kurs soll die Befähigung vermittelt werden, aus einer konkreten betrieblichen Aufgabenstellung heraus optimale Datenstrukturen für ein konkretes Datenbanksystem in einer konkreten Unternehmenslandschaft zu entwickeln.

Es wird zunächst auf die grundsätzlichen Aufgaben und Strukturen von Datenbanksystemen eingegangen. Dann wird ein semantisches Datenmodell entwickelt (ER-Modell, SERM, SAP-SERM). Dieses wird in in einem durchgängigen Übungsbeispiel in ein Standard-Datenmodell transformiert (RDM; auf HDM und CODASYL-DM wird nur kurz eingegangen), woraus dann das konkrete DB-Schema entsteht.

Die Datenstrukturen werden im Hinblick auf Integrität (semantische Integritätsbedingungen, Normalisierung, referentielle Integrität) und Performance optimiert.

Ein Ausblick auf moderne Entwicklungen bei Datenbanksystemen (z.B. OODBMS, multimediale Datenbanken, deduktive Datenbanken) und dahingehende Migrationsstrategien wird gegeben.

Damit ergibt sich folgende Gliederung:

  1. Grundlagen von Datenbanksystemen: Evolution von Informationssystemen, Datenmodelle, Datenmodellierung, Datenbank-Managementsystem (DBMS)
  2. Semantische Datenmodellierung: Entity-Relationship-Modell (ER-Modell), Strukturiertes ER-Modell (SERM), SAP-SERM
  3. Schema-Bildung: Standard-Datenmodelle
  4. Integritätssicherung: Sematische Integritätsbedingungen, Normalformen
  5. Neuere Datenmodell-Konzepte: NF2, OLAP, Hypermedia-Systeme, Deduktive Datenbanken, OODBMS

Notwendige Vorkenntnisse: Grundlegende Erfahrungen im Umgang mit einem PC-Datenbanksystem (z.B. MS ACCESS).

Kontrollaufgabe:
Ordnen Sie den Ablauf der Erstellung einer Ihrer Datenbankanwendungen in das angegebene Inhaltsraster ein. Haben Sie Punkte übersprungen?

Literatur:
Achilles, Albrecht: SQL. Oldenbourg, Mchn.: 2000. ISBN: 3-486-25475-8.

Albrecht R., Nicol N.: Microsoft Access 2000. Microsoft Press, München: 1999. ISBN: 3860631403.

Bauer A., Günzel H.: Data- Warehouse- Systeme. Architektur, Entwicklung, Anwendung. dpunkt-Verlag, Heidelberg: 2001. ISBN: 3932588762.

Hartwig J.: PostgreSQL - professionell und praxisnah. Addison-Wesley: 2001. ISBN: 3827318602.

Heuer A., Saake G.: Datenbanken Konzepte und Sprachen. mitp: 2000. ISBN: 3826606191.

Kazakos W., Schmidt A., Tomczyk P.: Datenbanken und XML. Konzepte, Anwendungen, Systeme. Heidelberg/Berlin: Springer 2002. ISBN: 354041956X.

Krizanek M.: Dynamische Websites. Webserver, Datenbanken, WebApplication Development - Dynamische Websites mit ColdFusion, PHP, IIS 5.0, Apache, Microsoft SQL Server, MySQL. SmartBooks Publishing AG: 2001. ISBN: 3908491061.

Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

Rauth O., Stickel E.: Konzeptuelle Datenmodellierung. Teubner Verlag: 1997. ISBN: 3815426014.

Sanders R. E.: ODBC 3.5 Developer's Guide. McGraw-Hill Companies 1998. ISBN: 0070580871.

Zehnder C. A.: Informationssysteme und Datenbanken. Teubner Verlag: 1998. ISBN: 3519324806.

© Prof. Dr. Hans Jürgen Ott --> home
41dbgrundlg.htm

Grundlagen von Datenbanksystemen

Eine Datenbank ist heutzutage das Herzstück jedes computergesteuerten Informationssystems.

Definition:
Ein computergesteuertes Informationssystem (IS) ist ein DV-System (Hardware, Software), das in einer Organisation (Unternehmen, Verein,...) jedem Aufgabenträger die für seine Aufgabenerfüllung notwenigen Informationen verfügbar macht.

Folgende IS-Funktionen lassen sich daraus ableiten:

Diese Funktionen sollten folgende Eigenschaften aufweisen, die die Benutzbarkeit bzw. Qualität des IS gewährleisten:

Ein IS kann letzlich nur Daten und Zusammenhänge von Daten speichern und zur Verfügung stellen; die Information ergibt sich "im Kopf" des Nutzers dieser Daten. Der Informationsgehalt von Daten ist - zumindest im betriebswirtschaftlichen Sinn - daher eine subjektive Kategorie, die vom Vorwissen des Informationsempfängers abhängt (Nachrichten, die bereits bekannt sind, stellen keine Information dar). Auch der Informationswert ist subjektiv und von den Interessen bzw. Bedürfnissen des Informationsempfängers abhängig. Diese Subjektivität weit auf folgende notwendige Eigenschaften von Informationssystemen hin:

Die Architektur solcher IS hat sich im Lauf der Zeit im Sinne eines Evolutionsprozesses stark verändert. Dies ging einher mit einer Änderung von Datenmodellen.

Die Kernfunktionalität von Informationssystemen wird durch das Datenbank-Managementsystem (DBMS) abgedeckt, also die Software, die die Verwaltung der Daten erlaubt. Der Markt für DBMS wird derzeit im wesentlichen durch Oracle, IBM und Microsoft dominiert:

Kontrollaufgabe:
Welche Kategorien von Informationen benötigt ein Kreditsachbearbeiter bei einer Bank? Welche Anforderungen ergeben sich daraus für ein computergestütztes Informationssystem?

Literatur:
Heuer A., Saake G.: Datenbanken Konzepte und Sprachen. mitp: 2000. ISBN: 3826606191.

© Prof. Dr. Hans Jürgen Ott --> home
41isev.htm

Evolution von Informationssystemen

Die Entwicklung von Informationssystemen im Zeitablauf vollzog sich mehr oder weniger kontinuierlich, wobei im wesentlichen immer neue Funktionalitäten integriert wurden. Es lassen sich jedoch drei grundlegend unterschiedliche Typen von Informationssystemen herausschälen; jedes existierende Informationssystem stellt eine Kombination dieser Typen dar. Die drei Typen lassen sich bei historischer Betrachtung in eine Reihenfolge bringen:

  1. Desintegration: Informationssystem als Menge von Programmen mit zugehörigen Daten
    Jeder Aufgabenträger im Unternehmen arbeitet mit seinem spezifischen Programm, das einen spezifischen Bestand von Daten benutzt bzw. erstellt.

  2. Datenintegration: Datenbankgestütztes Informationssystem
    Jeder Aufgabenträger arbeitet mit seinem spezifischen Programm; alle Programme greifen auf einen gemeinsamen unternehmensweiten Datenpool zu.

  3. Integration: Integrierte Informationssysteme
    Alle Aufgabenträger benutzen einen gemeinsamen Software-Pool und eine gemeinsame Datenbasis.

Kontrollaufgabe:
Woran könnte es liegen, daß diese Typen von Informationssystemen jeweils zu ihrer Zeit entstanden sind? Warum wurden sie jeweils abgelöst? Ist ein vierter Typ denkbar?

Literatur:
Derigs U., Ems S.: Konzepte für ein unternehmensweites Datenmanagement. In: WISU 12/95, S. 1019 ff.
Zehnder C. A.: Informationssysteme und Datenbanken. Teubner Verlag: 1998. ISBN: 3519324806.

© Prof. Dr. Hans Jürgen Ott --> home
41szenario1.htm

IS als Menge von Programmen mit zugehörigen Daten

Jeder Aufgabenträger im Unternehmen arbeitet bei diesem Typ von Informationssystem mit seinem Programm auf seinem Datenbestand. Für jede Aufgabe eines Aufgabenträgers existiert ein Programm (z.B. FIBU für einen Mitarbeiter im Rechnungswesen). Jedes Programm benutzt eigene Daten entweder

Viele Intranets fallen heutzutage noch in diesen Typ von Informationssystem: Mitarbeiter legen ihre Dokumente (dies entspricht den Daten) als statische Web-Seiten im Intranet-Server ab und generieren darüber ihre eigene Navigation mit eigener Funktionalität wie beispielsweise Volltext-Suche, Nutzungsprotokollierung etc. (dies entspricht den Programmen).

Dieser Typ von Informationssystem verursacht eine Reihe von Problemen:

Diese Probleme werden dadurch verursacht, daß die Daten nicht zentral verwaltet werden, sondern dezentral durch den Aufgabenträger. Sie können vermieden werden, wenn die Daten in einen gemeinsamen Datenpool integriert werden, der durch ein System verwaltet wird. Diese Aufgabe erfüllen Datenbanksysteme.

Kontrollaufgabe:
Was müßte gemacht werden, um die Probleme einer dezentralen Datenhaltung wie beschrieben zu vermeiden?

Literatur:
Derigs U., Ems S.: Konzepte für ein unternehmensweites Datenmanagement. In: WISU 12/95, S. 1019 ff.
Zehnder C. A.: Informationssysteme und Datenbanken. Teubner Verlag: 1998. ISBN: 3519324806.

© Prof. Dr. Hans Jürgen Ott --> home
41szenario2.htm

Datenbankgestütztes Informationssystem

Auch in diesem Szenario arbeitet jeder Aufgabenträger mit seinem eigenen Programm; alle Programme greifen jedoch auf einen gemeinsamen unternehmensweiten Datenpool zu. Dieser Datenpool wird verwaltet durch ein spezielles Programm, das Datenbank Management System (DBMS). Bekannte Datenbank-Managementsysteme sind beispielswese MS Access, Oracle, Informix, IBM DB2 oder PostgreSQL.

Der Begriff "unternehmensweit" assoziiert zunächst, dass alle Daten im gesamten Unternehmen dort verwaltet werden. Diese Vorstellung ist in der Realität nicht praktikabel, da dann die Strukturen in der Datenbank (Datenstrukturen) so komplex werden, dass die Benutzer damit nicht mehr arbeiten können und die geforderte Performance des Datenbanksystems nicht mehr realisierbar ist. In der Praxis integriert man daher nur solche Daten in einer Datenbank, die oft zusammen verwendet werden, d.h. die aus einem einzelnen Unternehmensbereich stammen (Funktionsbereich wie z.B. Vertrieb, Teilunternehmen wie z.B. eine Filiale etc.) und schafft zwischen diesen Bereichen Schnittstellen.

Der Zugriff auf die Daten durch den Benutzer kann erfolgen:

Auch bei dieser Typ von Informationssystem tauchen noch Probleme auf:

Diese Probleme sind durch die dezentrale Erstellung von Programmen verursacht; Abhilfe könnte eine zentralisierte Software-Entwicklung bringen, die dann zu integrierten Informationssystemen führt.

Kontrollaufgabe:
Arbeiten Sie an einem konkreten Unternehmensszenario heraus, welche Vorteile der Einsatz von Datenbanksystemen für einzelne Aufgabenträger bringt.

Literatur:
Derigs U., Ems S.: Konzepte für ein unternehmensweites Datenmanagement. In: WISU 12/95, S. 1019 ff.
Zehnder C. A.: Informationssysteme und Datenbanken. Teubner Verlag: 1998. ISBN: 3519324806.

Datenbanksprachen

Datenbanksprachen

Datenbanksprachen enthalten Anweisungen, um das DBMS zu Aktionen zu veranlassen, die vom Benutzer gewünscht sind. Je nach dem, welcher Typ von Benutzer diese Aktionen ausführen will, kann man die Anweisungen von Datenbanksprachen in folgende Kategorien einteilen (die Beispiele sind jeweils der Sprache SQL entnommen; eine gute Übersicht über Tutorials zu SQL bietet die Computer Zeitung):

Die Datenbanksprachen können textorientiert sein wie beispielsweise SQL oder auch grafisch unterstützt, wie beispielsweise Query by Example (QBE). QBE bedeutet, daß bei einer Datenselektion eine "Mustertabelle" mit Auswahlbedingungen definiert wird, in die das DBMS dann die Daten einträgt, die den Auswahlbedingungen genügen. Die folgende Abfrage in MS Access beispielsweise selektiert aus der Tabelle ABTEILUNG die Leiter der Abteilungen eines Sportvereins (wobei die Abteilung mindestens 2 Mitglieder haben muss) und ordnet den Abteilungsleitern ihre persönlichen Daten zu, die aus der Tabelle MITGLIEDER stammen. Mit abgebildet ist die entsprechende SQL-Anweisung.

QBE und SQL

Kontrollaufgabe:
Analysieren Sie den Befehlsumfang von PostgreSQL. Welche Anweisungen fallen in welche Kategorie von Datenbankanweisungen?

Literatur:
Achilles, Albrecht: SQL. Oldenbourg, Mchn.: 2000. ISBN: 3-486-25475-8.
Hartwig J.: PostgreSQL - professionell und praxisnah. Addison-Wesley: 2001. ISBN: 3827318602.

41odbc.htm

Standardisierter Datenaustausch über ODBC

Open Database Connectivity (ODBC) ist eine Standardschnittstelle für Anwendungsprogramme (API), die den Zugriff auf Datenquellen erlaubt ohne Kenntnis der jeweiligen proprietären Programmierschnittstellen der Systeme, die diese Datenquellen verwalten. Mit dem Zugriff über ODBC ist es (im Prinzip) möglich, Datenbanksysteme auszuwechseln ohne die zugreifenden Programme ändern zu müssen.

Das Anwendungsprogramm des Clients (Datenbanknutzer) greift über einen Datenbanktreiber (Driver) auf die Datenquelle zu. Angesprochen wird der Treiber vom Driver Manager als einer Funktion des Betriebssystems seiner Arbeitsstation.

Zu jedem marktgängigen Datenbanksystem existiert ein Treiber, der i.d.R. vom Datenbankhersteller angeboten wird. Wechselt man das Datenbanksystem aus, so muß man nur den neuen ODBC-Treiber für dieses System installieren und kann darüber ohne Programmänderung auf die Daten zugreifen.

Die Vorteile eines Datenbankzugriffes über ODBC sind also folgende:

Kontrollaufgabe:
Eine ähnliche Funktion wie ODBC erfüllt JDBC als Java-API für SQL-Datenbanksysteme. Arbeiten Sie Gemeinsamkeiten und Unterschiede heraus.

Literatur:
Sanders R. E.: ODBC 3.5 Developer's Guide. McGraw-Hill Companies 1998. ISBN: 0070580871.

41embedded.htm

Einbettung von Datenbankanweisungen in Programmiersprachen

Der Zugriff auf die Daten durch den Benutzer erfolgt direkt aus dem Anwendungsprogramm heraus; dieses enthält Datenbankanweisungen (Beispiel: Embedded SQL), mit denen auf die Datenbank zugegriffen werden kann.

Hierbei entsteht bei prozeduralen Programmiersprachen ("one record at one time") folgendes Problem, wenn sie auf relationale Datenbankysteme zugreifen, die Daten in Form von Tabellen verwalten: Das Ergebnis eines Zugriffs (SELECT) auf eine oder mehrere Tabellen liefert als Ergebnis in jedem Fall wieder eine Tabelle (auch wenn diese nur aus einer Spalte und einer Zeile besteht oder gar ganz leer ist, wenn die gesuchten Daten nicht vorhanden sind). Dieses Ergebnis müsste eigentlich in ein Array eingelesen werden; da man aber das Ergebnis der Abfrage vorher nicht kennt, weiss man nicht, wie gross das Array sein soll. Man geht daher in zwei Schritten wie folgt vor:

  1. Ergebnisdefinition (DECLARE CURSOR): Es wird die Abfrage und damit die Struktur der Ergebnistabelle definiert und der Datensatzzeiger auf den ersten vorhandenen Ergebnis-Datensatz (die erste Zeile der Tabelle) positioniert.

  2. Einlesevorgang (FETCH INTO): In einer Schleife wird jeder Ergebnis-Datensatz auf eine den selektierten Datenbankfeldern entsprechende Menge von Variablen eingelesen.

Folgendes Beispiel verdeutlicht am Beispiel der Spracheinbettung in JAVA (JSQL) dieses Konzept:

JSQL-Beispiel

Auch bei den meisten CGI-Sprachen zur Erzeugung dynamischer Websites findet man diesen Ansatz. Die folgende HTML-Datei erzeugt ein (statisches) Formular, um für eine web-basierte Studieninformation den gewünschten Studienbereich auswählen zu können:

CGI-Beispiel statisch

Bei einer dynamischen Website werden die zum Ausfüllen des Drop-Down-Menüs notwendigen Einträge einer PostgreSQL-Datenbank entnommen. Die Datenbankzugriffe innerhalb des HTML-Codes sind mit PHP programmiert:

CGI-Beispiel PHP

Kontrollaufgabe:
Wie könnte ein Compiler bzw. Interpreter diese eingebetteten Datenbankanweisungen, die ja dem Compiler "unbekannt" sind, behandeln, damit die gewünschten Ergebnisse erhalten werden?

Literatur:

Sayles J. S.: Embedded Sql for DB2 : Application Design and Programming. John Wiley & Sons: 1993. ISBN: 0471588105.

Krizanek M.: Dynamische Websites. Webserver, Datenbanken, WebApplication Development - Dynamische Websites mit ColdFusion, PHP, IIS 5.0,
Apache, Microsoft SQL Server, MySQL. SmartBooks Publishing AG: 2001. ISBN: 3908491061.

41dbaufbau.htm

Aufbau von Datenbanksystemen

Datenbanksysteme (DBS) bestehen aus drei Komponenten:

Datenbanksystem DBS = DB + DD + DBMS

Kontrollaufgabe:
Analysieren Sie das DBMS MS Access. Welche Funktionsklassen enthält es? Wo findet man DB und DD?

Literatur:
Derigs U., Ems S.: Konzepte für ein unternehmensweites Datenmanagement. In: WISU 12/95, S. 1019 ff.
Geppert A. Methodical Construction of Database Management Systems. Verlag Dr. Kovac: 1995. ISBN: 386064212X.

41szenario3.htm

Integrierte Informationssysteme

Integrierte Informationssysteme sind dadurch gekennzeichnet, daß für alle Aufgaben und Aufgabenträger im Unternehmen eine gemeinsame Softwarebasis bzw. Methodenbank (Repository, Entwicklungsdatenbank, Funktionsbibliothek, Objektbibliothek etc.) zur Verfügung steht. Zur Verwaltung dieser Softwarebasis wird wiederum ein spezielles Programm bzw. ein Methodenbank Management System benötigt (Repository Manager, CASE-System, Bibliotheksverwaltung, etc.), das wiederum auf einen Methodenkatalog (Method Dictionary) zugreift. Zur Verknüpfung von Daten und Methoden und als Schnittstelle zum Nutzer benötigt man ein Steuerungssystem.

Integriertes IS

Dieses in den 80er Jahren stark diskutierte Konzept wurde durch die aktuellen Entwicklungen bei objektorientierten Ansätzen weitgehend überholt. Objektorientierte Datenbanksysteme (OODBS) sind in der Lage, sowohl Daten als auch Methoden zentral und konsistent zu verwalten, ohne die Trennung vollziehen zu müssen, um beide Komponenten über ein Steuerungssystem wieder zu verbinden.

OODBS

In Anbetracht der zunehmenden Vernetzung der Unternehmen (Supply-Chain-Management) wird dieses Konzept in Zukunft auf mehrere Unternehmen, auf ganze Branchen, ja vielleicht sogar auf die gesamte Wirtschaft ausgedehnt werden. Erste Ansätze findet man bei B2B-Marktplätzen, wo Anbieter und Nachfrager von Produkten über den elektronischen Marktplatz vernetzt werden. Auch die Firma Microsoft verfolgt mit ihrer .NET-Strategie das Ziel, (Web-)Services über das Internet global verteilt anzubieten.

Dies würde bedeuten, daß man in einer Anwendung Objekte nutzen kann, die irgendwo auf der Welt vorgehalten werden. Dies wiederum setzt voraus, daß es einen Standard gibt, um die richtigen Objekte erkennen und dann in eigene Anwendungen einbauen zu können. Ein solcher Standard wird mit der Objekt Management Architecture (OMA) von der Object Management Group (OMG) entwickelt und gepflegt; in dieser OMG sind alle namhaften DV-Anbieter vertreten, so daß eine breite Akzeptanz dieses Standards gewährleistet ist.

Diese OMA-Architektur besteht aus folgenden zentralen Komponenten:

Kontrollaufgabe:
Welche Funktionalitäten entsprechen in der .NET-Technologie von Microsoft den jeweiligen OMA-Funktionalitäten?

Literatur:
Sayegh A.: CORBA. Köln: O´Reilly 1997. ISBN 3897211564.
Westphal R.: .NET kompakt. Spektrum Akad. Vlg., Hdg.: 2002 ISBN: 3827411858.

© Prof. Dr. Hans Jürgen Ott --> home
41dmodelle.htm

Datenmodellierung, Datenmodelle

Datenmodellierung bezeichnet die Spezifikation (Definition, Entwicklung, Erstellung) und Dokumentation der Datenstruktur für eine bestimmte betriebliche Aufgabe oder einen Aufgabenbereich. Die Datenstruktur-Spezifikation umfaßt dabei die für die Aufgabe benötigten Daten/Informationen (Bezeichnung, Datentyp), die Zusammenhänge zwischen Daten, die Art der Speicherung sowie Sichten verschiedener Benutzer/Aufgabenträger auf diese Daten.

Dabei ist wie folgt vorzugehen:

1. Informationsanalyse: Feststellung der benötigten Daten/Informationen, d.h. Festlegung, welche Daten in der Datenbank zu speichern sind. Damit wird ein Modell des Unternehmens gebildet, welches nur die wesentlichen Informationen enthält.
Spezifikation des Unternehmens-Modells (UM).

2. Strukturbildung: Spezifikation der Datentypen und der Zusammenhänge zwischen Daten mit Hilfe von Datenmodellen.
Spezifikation des Unternehmensdaten-Modells (UDM).

3. Rechnerverständliche Formulierung: Definition, Beschreibung und Implementation der Datenstrukturen mit Hilfe einer Datenbanksprache wie SQL oder xBase.
Spezifikation des Unternehmensdaten-Schemas (UDS).

Hinweis:
In der Literatur über Datenbanken und Datenmodellierung wird der Begriff "Datenmodell" in zweifacher Hinsicht verwendet: Zum einen bezeichnet er eine konkrete Spezifikation eines Datenbereiches ("Datenmodell Vertrieb") und zum anderen die Methode, um diese Spezifikation zu erstellen ( "Relationales Datenmodell").

Kontrollaufgabe:
Erstellen Sie ein einfaches Unternehmensmodell einer Hochschule. Skizzieren Sie UDM und UDS.

Literatur:
Rauth O., Stickel E.: Konzeptuelle Datenmodellierung. Teubner Verlag: 1997. ISBN: 3815426014.

© Prof. Dr. Hans Jürgen Ott --> home
41inhalte.htm

Informationsanalyse: Festlegung der Datenbankinhalte

Die Informationsanalyse bestimmt, welche Daten in welchen Datenfeldern in der Datenbank zu speichern sind. Die erforderlichen Inhalte können prinzipiell auf zwei Arten ermittelt werden:

Empirisches Vorgehen

Hier geht man von bestehenden bzw. bereits verwendeten oder erstellten Datenfeldern aus und übernimmt diese in die Datenbank. Erforderliche Schritte sind:

  1. Analyse bestehender Dokumente und Datenbeschreibungen wie beispielsweise
  2. Katalogisierung der Datenfelder, evtl. mit Data-Dictionary-Tools.

  3. Datenintegration: Bildung der Vereinigungsmenge der Datenfelder durch Zusammenfassung und Fehlerbeseitigung.

Bei der Integration der Datenfelder können folgende Konflikte entstehen:

Integrationskonflikte

Konzeptionelles Vorgehen

Hier gelangt man durch Überlegen und logisches Deduzieren aus der betrieblichen Aufgabenstellung heraus zu einer Aufstellung der Daten, die man benötigt. Ausgangspunkt sind hier die Unternehmensziele, die das betriebliche Aufgabenspektrum bestimmen. Daraus lassen sich Unternehmensstrukturen (Stellen) und -Prozesse (Arbeitsabläufe) ableiten. Man muß nun überlegen, welche Daten diese Prozesse benötigen bzw. welche Daten sie erzeugen.

Beispielsweise könnte eine solche logische Deduktion wie folgt aussehen:

Oberziel Überleben des Unternehmens
Unterziel Umsatz erzielen
Oberaufgabe Werbung treiben
Unteraufgabe Anzeige schalten
benötigte Daten Daten über Anzeigenredaktionen (Name, Adresse, Konto, Preisliste,...), Produktdaten (Bezeichnung, Farbe, Eigenschaften,...), Zielgruppendaten(...),...

Beide Vorgehensweisen haben ihre spezifischen Vor- und Nachteile. Hauptnachteile sind beim

Die angemessene Vorgehensweise besteht daher in einer zyklischen Integration beider Vorgehensweisen:

  1. konzeptionell: Grob-Analyse des Anwendungs- bzw. Aufgabenbereichs.
  2. empirisch: Vergleich mit existierenden Datenfeldern.
  3. konzeptionell: Analyse der überflüssigen/fehlenden Datenfelder
  4. empirisch: Prüfung, ob Datenfelder weggelassen werden können oder ergänzt werden müssen.
  5. ......

Kontrollaufgabe:
Welche Schritte umfaßt das konzeptionelle Vorgehen, welche das empirische Vorgehen bei der Informationsanalyse für eine Kundendatenbank eines Versandhändlers?

Literatur:
Rauth O., Stickel E.: Konzeptuelle Datenmodellierung. Teubner Verlag: 1997. ISBN: 3815426014.

© Prof. Dr. Hans Jürgen Ott --> home
41dmodspec.htm

Spezifikation von Daten mit Datenmodellen

Datenmodelle sind Spezifikationsmethoden für Datenstrukturen. Sie geben Begriffe, Konzepte, Vorgehensweisen, Symbole etc. für das Erstellen des Unternehmensdatenmodells (UDM) vor. Diese Datenmodelle lassen sich in zwei grobe Klassen einteilen:

  1. Semantische Datenmodelle
    Diese Datenmodelle erlauben eine einfache Beschreibung der betrieblichen Realität, also des Unternehmensmodells (UM). Sie besitzen einen hohen semantischen Gehalt, d.h. sie sind in der Lage, das UM weitgehend ohne Informationsverlust zu modellieren bzw. aus dem Modell kann auf die zugrundeliegende reale Situation hinreichend genau geschlossen werden.

    Sie besitzen allerdings den Nachteil, daß ihre Implementation in ein konkretes marktgängiges Datenbanksystem sehr schwierig ist.

  2. Standard-Datenmodelle
    Standard-Datenmodelle beziehen sich auf marktgängige Datenbankmanagementsysteme. Sie erlauben eine einfache Implementation von Datenbankschemata.
    Nachteil dieser Modelle ist, daß sie ein sehr hohes Anstraktionsvermögen erfordern. Die reale Situation, d.h. das UM, muß in die vorgegebenen und weitgehend von den systembedingten technischen Besonderheiten geprägten Begriffs- und Konzeptkatgorien hineingepresst werden.
Semantische Datenmodelle Standard-Datenmodelle
Semantik hoch niedrig
Implementation schwierig einfach
Beispiele Entity-Relationship-Modell

Um die jeweiligen Vorzüge der Modelle nutzen und die Nachteile vermeiden zu können, setzt man am besten beide Modelle aufeinander aufbauend ein.

Man erreicht damit folgendes:

Kontrollaufgabe:
Analysieren Sie ein Unternehmen Ihrer Wahl. Welche Datenmodelle werden eingesetzt? Warum? Vergleichen Sie dort den Modellierungsprozeß heute und vor 20 Jahren.

Literatur:
Rauth O., Stickel E.: Konzeptuelle Datenmodellierung. Teubner Verlag: 1997. ISBN: 3815426014.

© Prof. Dr. Hans Jürgen Ott --> home
41dbms.htm

3-Ebenen-Architektur und Funktionalität von Datenbank-Managementsystem (DBMS)

Datenbankmanagementsysteme (DBMS) bilden die (Software-)Schnittstelle zu Datenbankbenutzern bzw. zu Anwendungsprogrammen, die Daten aus der Datenbank verwenden bzw. dort einstellen. Aus dieser Aufgabenstellung heraus ergibt sich die Frage, welche Teilfunktionalitäten das DBMS enthalten soll, damit die Wünsche der Benutzer damit zufriedengestellt werden können. Das Problem einer Auflistung solcher Teilfunktionalitäten ist meist, daß man als Ergebnis eine unübersichtliche Liste erhält, mit denen man verschiedene marktgängige DBMS nur sehr schlecht vergleichen kann. Notwendig wäre angesichts dessen ein Rahmenkonzept (framework), das es erlaubt, Funktionalitäten zu gliedern und zu systematisieren; anhand dieses Frameworks können dann konkrete DBMS leichter evaluiert und verglichen werden.

Dieser Aufgabe hat sich im American National Standards Committee on Computers and Information Processing (ANSI) das Standards Planning and Requirements Committee (SPARC) in einem Projekt (X3) angenommen; 1978 wurde dazu die ANSI/X3/SPARC-Architektur für Datenbankmanagementsysteme veröffentlicht, die ein solches Rahmenkonzept bereitstellt.

Das ANSI/X3/SPARC-Kommittee ging von folgender Überlegung aus: Oberste Leitlinie sollte die Benutzbarkeit sein, daher muß die Systematisierung auch von den möglichen Benutzern des DBMS ausgehen. Man postulierte daher folgende 3 Typen von Benutzern:

  1. Anwender
    Anwender wollen Daten in die Datenbank eintragen (INSERT), Daten ändern (UPDATE, DELETE) sowie Daten aus der Datenbank selektieren (SELECT). Der Zugriff soll über ein User Interface (GUI) oder eine Programmschnittstelle (API) erfolgen. Desweiteren wollen sie sich aus vorhandenen Datenstrukturen den für sie relevanten Ausschnitt (VIEW) definieren.

  2. Modellierer
    Modellierer erstellen das unternehmensweite Datenmodell sowie das unternehmensweite Datenbankschema. Sie legen fest, welche Daten im Unternehmen insgesamt von Bedeutung sind und mit welcher Struktur sie in der Datenbank abgelegt sein sollen.

  3. Speicherverwalter/Systemprogrammierer
    Diese Benutzer des DBMS benötigen Funktionalitäten, um die Speicherorganisation festlegen. Sie bestimmen, auf welchem Speicherort (Wo?) und welchem Speichermedium (Platte, Band) welche Daten wie physisch abgelegt sind.

Jeder Benutzer hat eine charakteristische Sicht auf die Datenbank und benötigt charakteristische Funktionalitäten vom DBMS; daher versucht die ANSI/X3/SPARC-Architektur, die Funktionalitäten nach diesen Benutzern in 3 Ebenen zu kategorisieren. Dementsprechend wird dieses Architektur-Rahmenkonzept auch 3-Ebenen-Architektur genannt. Jeder Ebene wird eine Rolle eines Administrators zugeordnet, der dafür sorgt, daß die Benutzergruppen ihre Funktionalitäten verfügbar haben. Jede Ebene hat ihre spezifischen Datenstrukturen zu verwalten. Man unterscheidet

  1. Externe Ebene: Funktionalitäten für Anwender (Verwendung von Daten, Zugriffsoperationen, View-Definition)

  2. Konzeptuelle Ebene: Funktionalitäten für Modellierer (Definition und Verwaltung von UDM und UDS).

  3. Interne Ebene: Funktionalitäten für Speicherverwalter (Speicherstruktur definieren).

Wenn Datenbanksysteme so aufgebaut sind, dann erreicht man die spezifischen Vorteile, die datenbankgestützte Informationssysteme auszeichnet:

Kontrollaufgabe:
Analysieren Sie das DBMS MS Access hinsichtlich der 3 Ebenen: Welche Funktionalitäten können welcher Ebene zugeordnet werden?

Literatur:
Heuer A., Saake G.: Datenbanken Konzepte und Sprachen. mitp: 2000. ISBN: 3826606191.

© Prof. Dr. Hans Jürgen Ott --> home
413ekonz.htm

Die Konzeptuelle Ebene: Die Sicht des Informationsmanagers

Die konzeptuelle Ebene des DBMS bietet dem Informationsmanager Funktionen, um das unternehmensweite Datenmodell (UDM) zu definieren bzw. im konzeptuellen Schema zu spezifizieren. Die Rolle bzw. Stelle (im organisatorischen Sinn) des Informationsmanagers wird im ANSI/X3/SPARC-Modell als Unternehmensadministrator bezeichnet. Er sorgt dafür, daß die unternehmensweiten Datenstrukturen korrekt und konsistent sind und daß die Semantik der Daten gewährleistet ist (dass also die festgelegten Datenstrukturen die Realität bzw. das Unternehmensmodell getreu wiedergeben).

Das DBMS bietet dem Unternehmensadministrator folgende Funktionalitäten:

Kontrollaufgabe:
Analysieren Sie das DBMS MS Access hinsichtlich dieser Bestandteile: Wie werden diese Funktionalitäten dort genannt?

Literatur:
Rauth O., Stickel E.: Konzeptuelle Datenmodellierung. Teubner Verlag: 1997. ISBN: 3815426014.

© Prof. Dr. Hans Jürgen Ott --> home
413eex.htm

Die Externe Ebene: Die Sicht des Anwenders

Die externe Ebene eines Datenbankmanagementsystems (DBMS) ist die Ebene der Anwendersichten auf die Datenbank (externe Modelle der Anwender, views). Die Anwender haben ihre spezifische Sicht auf die Datenbank insofern, als sie bestimmte Daten in bestimmten Zusammenhängen und in bestimmten Formaten interessieren. Die Sicht eines Mitarbeiters in der Finanzbuchhaltung beispielsweise unterscheidet sich von der eines Projektleiters oder eines Mitarbeiters in der Personalabteilung; jeder will (und darf) andere Daten generieren, einsehen und ändern. Die Spezifikationen dieser externen Modelle (Wer darf was sehen/benutzen?), d.h. die Formulierung so, daß es das DBMS interpretieren kann, werden externe Schemata genannt. Im DBMS MS Access beispielsweise kann man eine Abfrage (als eine derartige Sicht auf die Daten) mittels QBE (Query by Example; in MS Access als Entwurfsansicht bezeichnet) oder mittels SQL erstellen bzw. spezifizieren.

Die Externen Schemata werden definiert durch den Anwendungsadministrator. Damit sieht das ANSI/X3/SPARC-Modell eine spezielle Rolle bzw. (im organisatorischen Sinn: Stelle) vor, die dem Anwender hilft, solche Views einzurichten und zu verwalten. Kriterien, die einer View-Definition zugrundegelegt werden, sind dementsprechend Anwendungsbezogenheit (Kann der Anwender damit seine betriebliche Aufgabe erfüllen?), Ergonomie (Kann er dies beeinträchtigungsfrei tun? Ist der View benutzbar?) und Datenschutz (Sind Datenschutzbestimmungen erfüllt? Darf er alle Daten, die er sieht, auch sehen?).

Um diese Anforderungen realisieren zu können, muß das DBMS folgende Komponenten enthalten:

Kontrollaufgabe:
Analysieren Sie das DBMS MS Access hinsichtlich dieser Bestandteile: Wie werden diese Funktionalitäten dort genannt?

Literatur:
Rauth O., Stickel E.: Konzeptuelle Datenmodellierung. Teubner Verlag: 1997. ISBN: 3815426014.

© Prof. Dr. Hans Jürgen Ott --> home
413eint.htm

Die Interne Ebene: Die Sicht des Speicherverwalters

Die interne Ebene des DBMS bietet dem Speicherverwalter Funktionen für die physische Datenbankorganisation. Er definiert die Speicherstrukturen (internes Datenbankschema. Was wird wo gespeichert?). Die Rolle des Speicherverwalters wird im ANSI/X3/SPARC-Modell als Datenbankadministrator bezeichnet. Er hat für die Performance (schnelles und ressourcensparendes Arbeiten mit Daten), die Sicherheit (Backups, Recovery) sowie die Verfügbarkeit des Datenbanksystems (Replikate, redundante Systeme) zu sorgen.

Hinweis:
In Stellenanzeigen, Stellenbeschreibungen und Tätigkeitsbeschreibungen findet man den Begriff des Datenbankadministrators häufig. Dabei wird der Begriff jedoch für die unterschiedlichsten Aufgabenbereiche vom Datenschutz über die Viewdefinition bis hin zum Datenbanktuning und Operating verwendet. Das ANSI/X3/SPARC-Konzept legt den Aufgabenbereich des Datenbankadministrators (im Unterschied zum Anwendungsadministrator und Unternehmensadministrator) eindeutig auf die physische Speicherorganisation fest - die betriebliche Stellenbezeichnungspraxis kann jedoch naturgemäß nicht gezwungen werden, diesem Konzept zu folgen.

Beispielsweise muß im internen Schema folgendes spezifiziert werden:

Das DBMS bietet dem Datenbankadministrator dazu folgende Funktionalitäten:

Kontrollaufgabe:
Analysieren Sie das DBMS MS Access hinsichtlich dieser Bestandteile: Gibt es diese Funktionalitäten dort?

Literatur:
Rauth O., Stickel E.: Konzeptuelle Datenmodellierung. Teubner Verlag: 1997. ISBN: 3815426014.

© Prof. Dr. Hans Jürgen Ott --> home
413schemabsp.htm

Beispiele für externe, interne und konzeptuelle Schemata im 3-Ebenen-Modell

Das folgende Bild zeigt, wie aus einem konzeptuellen Schema einer sehr einfachen Personaldatenbank für unterschiedliche Anwender mit spezifischen externen Modellen unterschiedliche externe Schemata abgeleitet werden können. Davon unabhängig wird das interne Schema entwickelt, das die Speicherorganisation definiert.

Schemabeispiele

 

Kontrollaufgabe:
Erstellen Sie analoge Schemabeispiele für eine Vertriebsdatenbank?

Literatur:
Rauth O., Stickel E.: Konzeptuelle Datenmodellierung. Teubner Verlag: 1997. ISBN: 3815426014.

© Prof. Dr. Hans Jürgen Ott --> home
41msaccess.htm

Das PC-Datenbanksystem MS Access

Das DBMS MS Access ist Teil des Office-Pakets von Microsoft. Es ist das derzeit meistbenutzte DBMS auf PCs.

Das zugrundeliegende Datenmodell ist das relationale Modell, d.h. Daten werden in Form von Tabellen betrachtet. Folgende Abbildung verdeutlich das Access-Datenmodell und die bei Access verwendeten Begriffe am Beispiel einer Mitglieder-Datenbank MITGL für einen Sportverein:

Datenmodell MS Access

Entsprechend dem 3-Ebenen-Ansatz von Datenbankmanagementsystemen kann man die Funktionalität von MS Access in folgende Kategorien einteilen:

MS Access bietet eine Reihe von Schnittstellen, um Daten von externen Datenquellen zu importieren (die Daten werden physisch in die Datenbank eingelesen) oder zu verknüpfen (es wird nur eine Verknüpfung zu einem externen Datenbestand erstellt; wenn sich der externe Datenbestand ändert, dann ändern sich gleichzeitig die verknüpften Daten) bzw. zu exportieren:

Kontrollaufgabe:
Bearbeiten Sie die folgende Übung.

Literatur:
Albrecht R., Nicol N.: Microsoft Access 2000. Microsoft Press, München: 1999. ISBN: 3860631403.

41accessueb.htm

Übung zu MS Access: Eine einfache Datenbank für die Organisation

Gegeben sei das folgede Unternehmensszenario:

Der Mitarbeiter Meier arbeitet seit dem 1.1.95 mit 50% seiner Kapazität in dem Projekt DB-DESIGN mit, das am 11.11.94 gestartet wurde. Er gehört seit dem 1.1.90 zur Abteilung EDV-AE7 und zur Kostenstelle 12. Sein Abteilungskollege Rabe arbeitet mit 60% im Projekt TEXT und mit 40% im Projekt DTP. Projektleiter von DB-DESIGN ist Frau Müller. Herr Meier hat zwei Kinder. Heinz wurde am 4.4.89 geboren. Die Mitarbeiter der Abteilung EDV-AE7 haben ihre Büros in den Räumen R101-R120, wobei die Räume R115 und R116 noch mit Kollegen aus der EDV-AE9 geteilt werden müssen. Im Raum R103 sitzen sogar noch Mitarbeiter aus weiteren 5 Abteilungen. Jeder Raum ist mit einem LAN-Anschluß ausgestattet.

Aufgabe:
Erstellen Sie für den Leiter dieser Organisation eine Datenbank-Anwendung unter MS ACCESS, damit er ständig über die wichigsten Betriebsdaten informiert ist.

Literatur:
Albrecht R., Nicol N.: Microsoft Access 2000. Microsoft Press, München: 1999. ISBN: 3860631403.

41dwarehouse.htm

Data Warehouses: Unternehmensweite Datenbestände

Data Warehouses sind Informationssysteme, die systematisch alle unternehmensinternen und externen Daten sammeln, die für Aufgabenträger im Unternehmen interessant sein könnten. Derartige Systeme erreichen Datenvolumina im Terabit-Bereich; daher sind die Anforderungen sowohl an die Systemtechnik wie auch an die Benutzbarkeit nur sehr aufwendig umzusetzen.

Data Warehouses haben Schnittstellen sowohl zu den anderen produktiven Systemen im Unternehmen (PPS-Systeme, Vertriebssysteme, Lagerhaltung, Finanzbuchhaltung etc.), aus denen sie Daten herausfiltern und persistent speichern, um damit Historien bilden zu können (z. B. Auftragseingänge im Lauf der letzten Jahre). Sie sammeln auch externe Daten beispielsweise aus dem Internet. Aus den gesammelten Daten werden weitere Daten abgeleitet (Indizes, Verhältniszahlen, korrelative Zusammenhänge), die von Interesse sein könnten. Durch Data-Mining-Verfahren erhält man (neue) Daten über Zusammenhänge in den vorhandenen Daten.

Auf die Daten kann mit Retrieval-Statements des zugrundeliegenden Datenbank-Management-Systems zugegriffen werden (bei relationalen DBMS üblicherweise SQL). Der Zugriff kann aber auch über OLAP-Datenstrukturen erfolgen; je nach verwendetem Verwaltungs-Tool werden dafür spezielle Abfragebefehle bereitgestellt. Der Zugriff kann aber auch über fest definierte Reports erfolgen.

Kontrollaufgabe:
Welche Daten sollte ein kleines Maschinenbauunternehmen im Data Warehouse speichern?

Literatur:
Bauer A., Günzel H.: Data-Warehouse-Systeme. Architektur, Entwicklung, Anwendung. dpunkt-Verlag, Heidelberg: 2001. ISBN: 3932588762.

© Prof. Dr. Hans Jürgen Ott --> home
42semdb.htm

Semantische Datenmodellierung: Das ER-Modell

Datenmodelle bieten eine Methodik an, um das Unternehmensmodell in das Unternehmensdatenmodell zu transformieren. Wie bereits dargestellt stehen dafür 2 grundsätzliche Klassen von Datenmodellen zur Verfügung: Standard-Datenmodelle und semantische Datenmodelle. Die Vorteile der Verwendung von Semantischen Datenmodellen liegen in einer "natürlichen" Semantik; die Nachteile in einer schwierigen Implementierbarkeit in existierende und marktgängige Datenbankmanagementsysteme.

Den Standard semantischer Datenmodelle stellt derzeit in der Praxis das Entity-Relationship-Modell (ER-Modell, ERM) dar; nahezu alle marktgängigen CASE-Tools bzw. Software-Spezifikations-, -dokumentations- und -entwicklungstools benutzen zur Datenmodellierung das ER-Modell. Es erlaubt eine einfache Modellierung, da es mit einem sehr geringen Vorrat an Modellierungskonstrukten auskommt. Es lehnt sich sehr an Konzepte und Begriffe der allgemeinen Systemtheorie an, d.h. es ist damit möglich, nahezu alle Arten von Systemen datenbezogen zu modellieren.

In diesem Abschnitt werden zunächst grundlegende Bestandteile und Konzepte des ER-Modells dargestellt (Entity, Beziehung, ER-Diagramm). Dann werden spezielle Beziehungskonzepte wie Kardinalität, Rekursion, Gerundium, schwacher Entity-Typ vorgestellt. Schließlich wird das "klassische" ER-Modell erweitert auf strukturiertes ER-Modell (SERM) und SAP-SERM.

Kontrollaufgabe:
Analysieren Sie einige bekannte CASE-Tools. Welche Modellerweiterungen des ER-Modells sind dort jeweils implementiert?

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42erbestandteile.htm

Grundlegende Bestandteile des ER-Modells

Grundlegende Bestandteile des ER-Modells sind:

Im ER-Modell werden jeweils Exemplare und Typen bzw. Kategorien von Entities und Relationen unterschieden. Jedes Exemplar gehört zu einem Typ. In die Datenbank werden die Typen als Tabellen oder Dateien, die Exemplare als Datensätze übernommen.

Grafisches Ergebnis einer ER-Modellierung ist das ER-Diagramm. Darin werden nur Typen dargestellt. Entity-Typen werden als Rechtecke, Beziehungstypen als Rauten dargestellt. Im folgenden Beispiel besteht das Unternehmensmodell aus Mitarbeitern, die in bestimmten Abteilungen beschäftigt sind. Entity-Typen sind demzufolge "MITARBEITER" und "ABTEILUNG", Beziehungstyp ist "arbeitet_in".

Dabei ist darauf zu achten, daß im Diagramm

Kontrollaufgabe:
Erstellen Sie für die Übungsaufgabe zu MS Access das ER-Diagramm.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42entity.htm

Das Entity-Konzept

Ein Entity ist ein Objekt der Realität (bzw. des Unternehmensmodells), über das Daten in der Datenbank gespeichert werden sollen. Entities sind damit Komponenten des Systems, das modelliert werden soll (z.B. ein Unternehmen). Dieser Objekt- bzw. Komponentenbegriff erfordert, daß modellierte Entities

In einer Bibliothek wären relevante Entities beispielsweise das Buch "Hald A., Nevermann W.: Datenbank-Engineering ....", der Ausleiher "Fritz Meier", die Sachbearbeiterin "Ingrid Kopp" oder das Regal "WI g".

Entities können so klassifiziert, d.h. in Klassen oder Kategorien eingeteilt werden, dass sich alle Entities innerhalb einer Klasse bzw. Kategorie mit denselben Eigenschaftsmerkmalen sinnvoll beschreiben lassen. Beispielsweise lassen sich alle Bücher in der Bibliothek mit den Eigenschaftsmerkmalen "Autor" bzw. "Erscheinungsjahr" und alle Ausleiher mit den Eigenschaftsmerkmalen "Name" und "Personalausweisnummer" beschreiben, nicht jedoch umgekehrt. Diese Eigenschaftsmerkmale werden im ER-Modell als Attribute bezeichnet. Die Gesamtheit der Attribute, die eine Klasse von Entities sinnvoll beschreiben kann, wird Entity-Typ genannt; Entity-Typen in einem Bibliotheks-ER-Modell wären beispielsweise "BUCH", "AUSLEIHER", "SACHBEARBEITER" odeer "REGAL".

Ebenfalls wie Entities müssen Attribute folgenden Kriterien genügen:

Ein Entity-Typ BUCH, bestehend aus den Attributen "Autor", "Titel", "Umschlagfarbe" und "Ausleihername", wäre nicht korrekt modelliert: die Umschlagfarbe dürfte für den Bibliotheksbetrieb nicht relevant sein; der Ausleihername kann für nicht ausgeliehene Bücher nicht bestimmt werden.

Der Wert eines bestimmten Entities auf einem Attribut wird als Attributausprägung bezeichnet. Die Domain eines Attributs bezeichnet den Wertebereich, also die Menge aller möglichen Attributausprägungen, die ein Entity in diesem Attribut annehmen kann. In der Programmierung entspricht die Domain dem Datentyp. Die Domain des Attributs "Autor" besteht aus sämtlichen Zeichenkombinationen; die Domain des Attributs "Erscheinungsjahr" aus allen vierstelligen Zahlen, die kleiner als die aktuelle Jahreszahl ist.

Bei einer Umsetzung des ER-Modells in ein Datenbankschema werden (beispielsweise in einem relationalen Datenbanksystem wie MS Access) aus den Entity-Typen Relationen bzw. Tabellen. Die Attribute werden zu Feldern bzw. Spalten. Die Domain eines Attributs definiert den Feld-Datentyp. Die Ausprägungen eines Entities auf allen Attributen wird in der Datenbank als Datensatz repräsentiert (also als Zeile in einer Tabelle).

Entity-Typen werden im ER-Diagramm als Rechteck dargestellt, in die die Bezeichnung des Entitytyps hineingeschrieben wird.

Kontrollaufgabe:
Erstellen Sie für die Übungsaufgabe zu MS Access eine Liste der in der Situationsbeschreibung vorkommenden Entities. Bilden Sie Entity-Typen. Durch welche Attribute werden die Entites beschrieben? Welche Domains haben jeweils die Attribute?

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42key.htm

Schlüsselkategorien im ER-Modell

Attribute oder Kombinationen von Attributen, die dazu geeignet sind, jedes mögliche Entitiy eines Entity-Typs eindeutig zu identifizieren, werden als Schlüssel bezeichnet. Folgende Schlüssel könnten für einen Entity-Typ "BUCH" prinzipiell in Betracht gezogen werden:

  1. <Autor>: ungeeignet, da ein Autor mehrere Bücher geschrieben haben könnte und damit ein Buch nicht eindeutig beschreibbar ist;

  2. <Autor, Titel>: ungeeignet, da von einem Titel mehrere Auflagen vorrätig sein könnten;

  3. <Autor, Titel, Auflage>: ungeeignet, da von einer Auflage mehrere Exemplare vorrätig sein könnten;

  4. <Signatur>: geeignet;

  5. <Signatur, ISBN-Nummer>: geeignet.

Für jeden Entity-Typ in einem ER-Modell muss ein Schlüssel definiert werden. Manchmal eignet sich jedoch keine Attributkombination als Schlüssel. Beispielsweise ist dies der Fall, wenn, wie oben beschrieben, mehrere Exemplare eines Buches vorrätig sind. Dann muss man ein "künstliches" Attribut (beispielsweise Signatur) definieren, das nur dazu dient, Entities unterscheidbar zu machen - und dieses dann zum Schlüssel machen.

Die obigen Beispiele 4 und 5 eignen sich beide als Schlüssel. Von einem minimalen Schlüssel spricht man, wenn keines der Attribute aus dem Schlüssel entfernt werden kann, ohne dass dieser damit die Schlüsseleigenschaft verliert. Minimal wäre daher nur der Schlüssel 4. Minimale Schlüssel sollten immer angestrebt werden.

Existieren mehrere mögliche Schlüsselkandidaten, also mehrere mögliche Attributkombinationen, die Entities eindeutig identifizieren, so wird im ER-Modell ein Kandidat als Primärschlüssel ausgezeichnet; die anderen werden als Sekundärschlüssel bezeichnet. Beispielsweise eignen sich beide Attribute "Bibliotheksausweisnummer" und "Personalausweisnummer" als Schlüssel für den Entity-Typ AUSLEIHER. Tritt ein solcher Fall auf, so entscheidet man sich zweckmäßigerweise für den kleinsten (den mit den wenigsten Attributen, den mit der einfachsten Domain), für den bedeutungsvollsten oder den "gewohntesten".

Manchmal tritt der Fall auf, daß ein Attribut in einem Entity-Typ E1 Primärschlüssel ist und in einem anderen Entity-Typ E2 "einfaches Attribut", d.h. entweder nicht Teil des Schlüssels oder nicht der ganze Schlüssel. Dann wird das Attribut in E2 als Fremdschlüssel bezeichnet. Ein Buch in einer Bibliothek könnte beispielsweise durch ein Attribut "Regalnummer" beschrieben werden; dieses Attribut wäre Primärschlüssel im Entity-Typ REGAL und Fremdschlüssel im Entity-Typ BUCH.

Achtung:
Primär- und Fremdschlüssel müssen nicht gleich bezeichnet sein, sondern dieselbe Eigenschaft ausdrücken! Gleich bezeichnete Attribute in unterschiedlichen Entity-Typen müssen nicht dieselbe Eigenschaft zum Ausdruck bringen.

Kontrollaufgabe:
Markieren Sie in der Entity-Liste der Übungsaufgabe zu MS Access die Primärschlüssel (durch Unterstreichen der Schlüssel-Attribute). Existieren Sekundärschlüssel? Existieren Fremdschlüssel?

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42relations.htm

Beziehungen, Relations

Beziehungen zwischen Entities, über die Informationen abgespeichert werden sollen, die also Teil des Unternehmensmodells sind, werden ebenfalls im ER-Modell dargestellt. Sie bilden als Relations neben Entities das Kernkonzept des ER-Modells.

Auch Beziehungen können zu Klassen zusammengefasst und durch Beziehungstypen beschrieben werden. Dementsprechend existieren Beziehungen zwischen Entities auf der einen Seite und Beziehungstypen zwischen Entity-Typen auf der anderen Seite. In einem ER-Modell für eine Bibliothek könnten beispielsweise folgende Beziehungstypen zwischen Entity-Typen existieren:

  1. "leiht_aus" = <BUCH, AUSLEIHER>
  2. "ist_gekauft_bei" = <BUCH, BUCHHÄNDLER>
  3. "bestellt_von" = < BUCH, BESTELLER>
  4. "steht_in" ) <BUCH, REGAL>

Beziehungen können Attribute haben; eine Beziehung des Typs "leiht_aus" könnte beispielsweise durch das Attribut "Ausleihdatum" beschrieben werden. Beziehungstypen enthalten jedoch keine Schlüssel; jede einzelne Beziehung zwischen Entities kann ja über die Schlüsselausprägungen der beteiligten Entities eindeutig identifiziert werden.

Beziehungstypen werden im ER-Diagramm als Rauten dargestellt, in die die Bezeichnung des Beziehungstyps hineingeschrieben wird.

Kontrollaufgabe:
Erstellen Sie auf der Basis der Entity-Liste aus der Übungsaufgabe zu MS Access eine Liste der relevanten Beziehungstypen? Ordnen Sie Attribute und Domains zu.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42loeserdacc.htm

Lösung ER-Modell Büro

 

ERD Access-Bsp.

© Prof. Dr. Hans Jürgen Ott --> home
42ermueb.htm

Übung ER-Modell Sportverein

Ein Sportverein will eine DV-gestützte Spieler- und Wettkampfverwaltung erstellen lassen. Folgende Informationen sollen verarbeitet werden können:

Es wird zwischen zwei Mitgliedsgruppen unterschieden: Hobbyspieler und Wettkampfspieler. Die erste Gruppe trägt nur vereinsinterne Wettkämpfe aus, welche bei dem zu entwickelnden System nicht von Bedeutung sind. Wettkampfspieler dagegen spielen im Mannschaftsverbund gegen Spieler anderer Vereine. Jeder Spieler verfügt über eine eindeutige Nummer, gleichgültig, ob es sich bei ihm um einen Wettkampfspieler handelt, oder nicht. Diese Spielernummer wird vom Verein vergeben. Jeder Wettkampfspieler muß beim Verband registriert sein. Der Verband teilt jedem Wettkampfspieler eine eindeutige Verbandsnummer zu. Falls ein Wettkapfspieler nicht mehr an Verbandskämpfen teilnimmt, somit also zum Hobbyspieler wird, verfällt seine Verbandsnummer. Hobbyspieler haben keine Verbandsnummer.

Der Sportverein hat mehrere Mannschaften, die an Wettkampfserien teilnehmen. Für jede Mannschaft werden die Liga und der Mannschaftskapitän, welcher auch Wettkampfspieler ist, registriert. Eine Mannschaft besteht aus 6 Spielern. Während eines Wettkampfs spielt jeder Spieler gegen einen Spieler aus einer Mannschaft eines anderen Vereins. Eine Mannschaft setzt sich nicht immer aus den gleichen Spielern zusammen. Falls ein Spieler verhindert ist, muss ein Ersatzspieler für ihn einspringen. Ein Spieler kann einen Wettkampf gewinnen oder verlieren; ein Unentschieden ist nicht möglich. Es soll auch aufgezeichnet werden, wieviele Wettkämpfe ein bestimmter Spieler für eine bestimmte Mannschaft gewonnen oder verloren hat.

Bei regelwidrigem Verhalten eines Spielers verhängt der Verband Bußgelder. Solange ein Spieler an Wettkämpfen teilnimmt, bleiben alle Bußgelder aufgezeichnet (Datum und Betrag), mit denen der Spieler belegt worden ist.

Es sollen nur die Daten der Wettkämpfe und der Bußgelder historisch gespeichert werden; bei allen übrigen Daten ist auf historische Speicherung zu verzichten.

Kontrollaufgabe:
Erstellen Sie die Entity-Typ- sowie die Beziehungstyp-Liste, jeweils mit Attributen und Domains. Ordnen Sie den Entitytypen Schlüssel zu. Erstellen Sie das ER-Diagramm.

© Prof. Dr. Hans Jürgen Ott

42erdsv.htm

Lösung ER-Modell Sportverein

ERD SV

© Prof. Dr. Hans Jürgen Ott --> home
42erbezkonzepte.htm

Spezielle Beziehungskonzepte im ER-Modell

Um den semantischen Gehalt in ER-Modellen zu erhöhen, werden spezielle Beziehungskonzepte eingeführt und die Beziehungen selbst mit mehr Informationsgehalt ausgestattet. Diese speziellen Beziehungskonzepte sind:

Kontrollaufgabe:
Ergänzen Sie das ERD aus dem Sportvereins-Beispiel durch die genannten Beziehungstypen.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42mehrstbez.htm

Mehrstellige Beziehungen

An einer Beziehung können mehr als zwei Entity-Typen beteiligt sein; man spricht in diesem Fall von mehrstelligen Beziehungen. Allgemein wird mit grad(R) die Anzahl der Entities bezeichnet, die in einer einzigen Beziehung des Typs R vorkommen.

Beispiel Bibliothek: Bücher werden von Ausleihern ausgeliehen.

An jeder einzelnen Beziehung zwischen AUSLEIHER und BUCH ist ein Ausleiher und ein Buch beteiligt: grad(leiht_aus)=2

Beispiel Beschaffung: Bestimmte Bauteile für bestimmte Projekte dürfen nur von bestimmten Lieferanten bezogen werden.

An jeder einzelnen Beziehung zwischen TEIL, PROJEKT und LIEFERANT ist ein Bauteil, ein Projekt und ein Lieferant beteiligt: grad(wird_bezogen)=3.

grad(R)=2 grad(R)=3

Zweistellige Beziehungen lassen sich im allgemeinen leichter in Datenbankschemata übertragen als mehrstellige. Man könnte nun auf die Idee kommen und Beziehungen mit grad(R)=n in n zweistelligen Beziehungen modellieren. Damit kann jedoch ein Informationsverlust bzw. eine Informationsverfälschung verbunden sein, wie folgendes Beispiel zeigen soll:

Angenommen, im obigen rechten Beschaffungs-Beispiel mit dem 3-stelligen Beziehungstyp "wird_bezogen" bestehen folgende konkrete Beziehungen

<p1,t1,l1> <p2,t1,l2> <p2,t2,l1>

Bei einer Auflösung in zweistellige Beziehungen erhielte man die Beziehungen

<p1,t1>
<p1,l1>
<t1,l1>

<p2,t1>
<p2,l2>
<t1,l2>
<p2,t2>
<p2,l1>
<t2,l1>

Aus diesen Paar-Beziehungen wiederum könnte man - durch Zusammenfügen der kursiv gedruckten Beziehungen - die 3-stellige Beziehung <p2,t1,l1> ableiten, die jedoch in den Ausgangsbeziehungen nicht existiert.

Kontrollaufgabe:
Ergänzen Sie das ERD aus dem MS-ACCESS-Beispiel durch die genannten Beziehungstypen.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42kardinalitaet.htm

Kardinalität, Komplexitätsgrad der Beziehung

Die Kardinalität eines Beziehungstyps R legt fest, wieviele Entities eines Typs E1 mit wievielen eines Typs E2 verbunden sein können, gesehen über alle Beziehungen des Beziehungstyps R. Man speicht auch von Komplexitätsgrad eines Beziehungstyps.

Folgende Kardinalitätstypen lassen sich unterscheiden:

Kontrollaufgabe:
Ergänzen Sie das ERD aus dem MS-ACCESS-Beispiel durch die genannten Beziehungstypen.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42rekursiv.htm

Rekursive Beziehungen

Rekursive Beziehungen sind Beziehungen zwischen Entities eines einzigen Entity-Typs. Bei dieser Art von Beziehungen ist es zur Veranschaulichung im ER-Diagramm zweckmäßig, jedem Entity in einer Beziehung eine bestimmte Rolle zuzuschreiben: Im linken Beispiel der Datenstruktur eines Organigramms hat ein Mitarbeiter die Rolle des Vorgesetzten und der andere die Rolle der Untergebenen. Im rechten Beispiel einer Stückliste hat ein Bauteil die Rolle des eingebauten Bauteils (Teil) und das andere die Rolle der Baugruppe (Ganzes)


Kontrollaufgabe:
Ergänzen Sie das ERD aus dem MS-ACCESS-Beispiel durch die genannten Beziehungstypen.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42gerund.htm

Gerundium: Sowohl Entity als auch Beziehung

Ein Gerundium ist in einer Beziehung R1 Entity-Typ und gleichzeitig im gleichen Diagramm in einer anderen Beziehung R2 Beziehungstyp. Es ist also eine Art Mischform zwischen Entity- und Beziehungstyp. Dieser Mischformcharakter prägt auch das Symbol für ein Gerundium im ER-Diagramm.

Die Beziehung zwischen einem Buch und seinem Ausleiher enthält alle Daten, die üblicherweise ein Leihschein enthält. Der Leihschein wiederum kann in einem bestimmten Kasten aufbewahrt werden. Der Leihschein ist damit in der Ausleihbeziehung Beziehungstyp und in der Beziehung zwischen Leihscheinen und Aufbewahrungskasten Entity-Typ.

Gerundium

Kontrollaufgabe:
Ergänzen Sie das ERD aus dem MS-ACCESS-Beispiel durch die genannten Beziehungstypen.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42weakentity.htm

Beziehungen mit schwachen Entities

Die Existenz von Entities eines Typs Ew ist abhängig von der Existenz eines Entities des Typs E.

Im Übungsbeispiel zu MS Access tauchte ein solcher Fall auf: Die Kinder eines Mitarbeiters, d.h. die Entities des Typs KIND (Ew) setzen voraus, dass ein Elternteil des Entity-Typs MITARBEITER (E) existiert. In einem solchen Fall wird der Primärschlüssel von E Teil des Primärschlüssels von Ew oder bildet dort den ganzen Primärschlüssel.

Weak Entity

Kontrollaufgabe:
Ergänzen Sie das ERD aus dem MS-ACCESS-Beispiel durch die genannten Beziehungstypen.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42loesermbuerok.htm

Lösung ERM Büro mit Kardinalitäten

Lösung ERM Büro mit Kardinalitäten

© Prof. Dr. Hans Jürgen Ott --> home
42loesermsvk.htm

Lösung ERM Sportverein mit Kardinalitäten

Lösung ERM Sportverein mit Kardinalitäten

© Prof. Dr. Hans Jürgen Ott --> home
42ererweit.htm

ER-Modellerweiterung: SERM

Das ER-Modell stellt eine sehr einfache Modellierungsmethode mit wenigen Komponenten bzw. Einzelkonzepten dar. Dies war auch für die Akzeptanz dieser Methode ausschlaggebend. Diese Einfachheit führt allerdings dazu, dass bei der Anwendung auf komplexe und umfangreiche Aufgabenstellungen die resulierenden Diagramme sehr schnell unübersichtlich und unleserlich werden, wie das folgende Beispiel (SAP-Anwendungsdatenmodell, entnommen aus http://www.fh-giessen.de/fachbereich/w/skripte/mueller/datenmodellierung_und_datenbanksysteme/sld018.htm) zeigen soll:

Dies versucht man dadurch zu vermeiden, dass man Strukturierungsmöglichkeiten einführt. Damit kann man auf einer groben Ebene das System im Überblick betrachten und dann sukzessive feinere Betrachtungen von Strukturierungskomponenten anstellen; man erhält eine Betrachtungshierarchie. Dies erleichtert dann auch die Transformation eines ER-Modells in eine Objektstruktur, die ja - über Vererbungsmöglichkeiten - auch hierarchisch ist.

Im Strukturierten ER-Modell (SERM) hat man folgende Strukturierungsmöglichkeiten zur Verfügung:

Da diese Konzepte in der Objektorientierten Systemanalyse zentral sind und sich dort die Modellierungsmethode UML durchgesetzt hat, wird die UML-Symbolik für die Kennzeichnung dieser Konzepte im ER-Diagramm übernommen.

Kontrollaufgabe:
Transformieren Sie das ER-Modell Sportverein in ein Strukturiertes ER-Modell.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42aggregation.htm

Aggregationsbeziehungen im SERM

Ein Entity a des Entity-Typs A besteht aus mehreren Entities b1, b2, ... des Typs B. Man spricht auch von "consists-of"-Beziehungen. Dieser Strukturierung liegt also immer eine (1:n)-Beziehung zugrunde.

Im Beispiel besteht eine Abteilung aus mehreren Mitarbeitern:

Kontrollaufgabe:
Finden Sie Aggregationsbeziehungen in den ER-Modellen Büro und Sportverein.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42generalisierung.htm

Generalisierungsbeziehungen im SERM

Ein Entity a des Entity-Typs A ist übergeordneter Begriff zu einem Entity b des Typs B bzw. zu Entities c, d, ... anderer Entity-Typen C, D, ... Man spricht hierbei auch von "is-a"-Beziehungen. Der übergeordnete Entity-Typ hat denselben Schlüssel wie die untergeordneten Entity-Typen; diese besitzen aber im allgemeinen zusätzliche Attribute (und die von A nicht!).

Im Beispiel wird zum Ausdruck gebracht, dass Arbeiter und Angestellte Mitarbeiter sind. Die Modellierung in unterschiedlichen Entity-Typen wird dadurch notwendig, dass sich beide Unterkategorien nicht durch dieselben Attribute beschreiben lassen: Beispielsweise haben Arbeiter Lohngruppe und Angestellte Gehaltsklasse als Attribute.

Die Beziehungen sind (1:1)-Beziehungen; auf der Seite der Unterkategorien sind es jeweils Muss-Beziehungen.

Kontrollaufgabe:
Finden Sie Generalisierungsbeziehungen in den ER-Modellen Büro und Sportverein.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42gruppierung.htm

Gruppierungsbeziehungen im SERM

Entities eines Entity-Typs A werden anhand eines bestimmten Attributs in Gruppen eingeteilt und als attribut-identische Entity-Typen B, C, ... modelliert. Diese Unterteilung in Gruppen kann dadurch motiviert sein, dass nur eine Gruppe durch spezielle Beziehungen mit einem anderen Entity-Typ verbunden ist.

Im Beispiel wird der Einfachheit halber angenommen, dass nur Frauen Schwangerschaftsvertretungen haben sollen. Diese Vertretung soll auch nur von Frauen erfolgen können. Dann kann man eine Gruppierung anhand des Attributs Geschlecht wählen, die die Mitarbeiter in Männer und Frauen einteilt. Nur ein Entity des Gruppierungs-Entity-Typs FRAU kann also eine (rekursive) Beziehung mit einem weiteren Entity des Typs FRAU eingehen (der Frau, die sie in der Schwangerschaft vertritt). Die Entity-Typen MITARBEITER, FRAU und MANN haben dieselben Attribute und dieselben Schlüssel.

Die Beziehungen sind (1:1)-Beziehungen; auf der Seite der Gruppen-Entitytypen sind es jeweils Muss-Beziehungen.

Kontrollaufgabe:
Finden Sie Gruppierungsbeziehungen in den ER-Modellen Büro und Sportverein.

Literatur:
Thalheim B.: Entity-Relationship Modeling. Foundations of Database Technology. Springer Verlag 2000. ISBN: 3540654704.

© Prof. Dr. Hans Jürgen Ott --> home
42sapserm.htm

Die Methode SAP-SERM in SAP R/3

Eine noch weitergehendere Modifikation eines Strukturierten ER-Modells stellt das in SAP R/3 verwendete SAP-SERM dar. Die wichtigsten Modifikationen sind:

Zusammenfassen können die Elemente des SAP-SERM wie folgt dargestellt werden:

Folgendes Beispiel eines Datenmodellausschnitts soll die Anwendung veranschaulichen:

Kontrollaufgabe:
Transformieren Sie das ER-Modell Sportverein in ein SAP-SERM.

Literatur:
Moos A., Daues G.: Datenbank- Engineering. Vieweg Verlagsgesellschaft: 1997. ISBN: 3528151838.

© Prof. Dr. Hans Jürgen Ott --> home
42loessermsvk.htm

Lösung: SERM Sportverein

© Prof. Dr. Hans Jürgen Ott --> home
42uebermbib.htm

Übung ER-Modell Bibliothek

Die bisher manuell verwaltete Bibliothek der BA Heidenheim soll auf EDV umgestellt werden. Folgendes ist zu berücksichtigen:

In der Bibliothek können eigene Bücher und Bücher über Fernleihe ausgeliehen werden. Eigene Bücher werden von Buchhändlern im Ort geliefert; Fernleihe-Bücher werden von Fremdbibliotheken bestellt, an den Ausleiher übergeben und nach Ablauf der Ausleihfrist an die Fremdbibliothek zurückgeschickt.

Eigene Bücher werden wie folgt beschafft: Ein Mitarbeiter der BA (Besteller) bestellt die Bücher mittels des folgenden Formulars:

Daraufhin bestellt die Bibliotheksangestellte das Buch für den Besteller zur Ansicht. Wenn sich dieser für den Kauf ausspricht, kauft die Bibliotheksangestellte die vom Besteller angegebene Anzahl an Exemplaren, falls noch ausreichend Mittel zur Beschaffung zur Verfügung stehen. Nach der Lieferung vergibt der Besteller Stichworte zur Identifikation bei Literaturrecherchen. Die Bibliotheksangestellte signiert das Buch und stellt es ins Regal.

Der Ausleihvorgang läuft wie folgt ab: Der Ausleiher sucht sich ein Buch anhand der Buchangaben oder anhand von Stichworten. Ist das Buch am Platz, kann es ausgeliehen werden. Die Bibliotheksangestellte prüft den Ausleiherausweis, übergibt das Buch, überwacht die Ausleihfrist und fordert es gegebenenfalls (telefonisch) wieder zurück (unter Einforderung einer Mahngebühr).

Kontrollaufgabe:
Erstellen Sie die Entity-Typ- sowie die Beziehungstyp-Liste, jeweils mit Attributen und Domains. Ordnen Sie den Entitytypen Schlüssel zu. Erstellen Sie das ER-Diagramm. Machen Sie, wenn notwendig, geeignete Zusatzannahmen hinsichtlich des Anwendungsfalles!

© Prof. Dr. Hans Jürgen Ott

42loesermbib.htm

Lösung zur Übung: ERM Bibliothek

Entity-Typ: fett; Schlüssel: kursiv

Entitytypen

BUCH { Bücher als Verlagsobjekte }
( ISBNNr CHAR(13);
Autoren ARRAY [1..10] of RECORD {Vorname CHAR(10); Nachname CHAR(30)};
Titel CHAR(100);
Auflage INTEGER;
Ort CHAR(20);
Verlag CHAR(30);
Jahr INTEGER
)
EIGENES-EXEMPLAR { Bestands-Exemplare von Büchern }
(Signatur CHAR(10);
ISBNNr CHAR(13);
Preis FIXED(10,2);
Stichworte ARRAY [1..10] of CHAR(20);
Status SET of <"bestellt", "bei_Besteller", "im_Regal", "ausgeliehen", "in_Reparatur", "nicht_auffindbar">;
Präsenz BOOLEAN;
KaufDatum DATUM;
LieferscheinNr CHAR(15);
LieferDatum DATUM;
UeberwAuftragDatum DATUM;
RechNummer CHAR(15);
RechDatum DATUM
)
FERNLEIHE-BUCH { Buch aus einer fremden Bibliothek, über Fernleihe ausgeliehen }
(ISBNNr CHAR(13);
FSignatur CHAR(10);
Autoren ARRAY [1..10] of RECORD {Vorname CHAR(10); Nachname CHAR(30)};
Titel CHAR(100);
Auflage INTEGER;
Ort CHAR(20);
Verlag CHAR(30);
Jahr INTEGER
)
BESTELLER { Besteller, hauptamtlicher Mitarbeiter der BA }
( Kuerzel CHAR(3);
Name RECORD {Vorname CHAR(10); Nachname CHAR(30)};
Anschrift RECORD {Zimmer CHAR(3); Telefon CHAR(20)};
Fachrichtung CHAR(10);
Hauptamtl BOOLEAN
)
AUSLEIHER {aktueller Ausleiher eines Buches }
(AusweisNr CHAR(10);
Name RECORD {Vorname CHAR(10); Nachname CHAR(30)}
Anschrift RECORD {Strasse CHAR(30); PlzOrt CHAR(30); Telefon CHAR(20)}
)
FREMDBIBLIOTHEK { Bibliothek, von der ein Fernleihebuch ausgeliehen wurde }
( Name CHAR(100);
Anschrift RECORD {Strasse CHAR(30); PlzOrt CHAR(30); Telefon CHAR(20)}
)
BUCHHAENDLER { Buchhändler, bei dem ein Buch beschafft bzw. bestellt wurde }
( Code CHAR(10);
Name CHAR(50);
Anschrift RECORD {Strasse CHAR(30); PlzOrt CHAR(30); Telefon CHAR(20)};
BankVb RECORD {Konto CHAR(15); Institut CHAR(20); BLZ INTEGER};
KdNummer CHAR(20)
)


Beziehungstypen

bestellt = <BUCH,BESTELLER> { Bestellung eines Buches beim Bib.-Sachbearbeiter }
( Anzahl INTEGER;
AuftragsDatum DATUM;
NachrichtsDatum DATUM
)

liefert-eigen
= <BUCH,BUCHHÄNDLER> { Lieferung durch Buchhändler }
( BestellDatum DATUM;
LieferDatum DATUM;
AnsichtsDatum DATUM
)
leihtaus-eigen = <EIGENES-EXEMPLAR,AUSLEIHER> { aktuell ausgeliehenes eigenes Buch }
( AusleihDatum DATUM;
MahnDatum DATUM;
)
leihtaus-fremd = <FERNLEIHE-BUCH,AUSLEIHER> { aktuell über Fernleihe ausgeliehenes Buch }
( AnfrageDatum DATUM;
AusleihDatum DATUM;
MahnDatum DATUM;
)
liefert-fremd = <FERNLEIHE-BUCH,FREMDBIBLIOTHEK> { Bibliothekszugehörigkeit des Buches }
( AuftragsDatum DATUM;
LieferDatum DATUM;
Leihfrist DATUM
)


ER-Diagramm

© Prof. Dr. Hans Jürgen Ott --> home
43stddb.htm

Schemabildung: Standard-Datenmodelle

Standard-Datenmodelle sind Datenmodelle, die auf marktgängige Datenbank-Management-Systeme (DBMS) zugeschnitten sind. Die mit ihrer Hilfe erstellten Unternehmensdatenmodelle sind leicht und einfach in Datenbankschemata zu implementieren.

Diese Modelle können in folgende Klassen eingeteilt werden:

  1. Klassische Datenmodelle: Diese in historischer Betrachtung zuerst entstandenen Datenmodelle sind zwar noch in Datenbanksystemen implementiert, die in Unternehmen vorfindbar sind; sie haben aber bei neu angebotenen DBMS praktisch keine Bedeutung mehr. Die bekanntesten Datenmodelle dieser Kategorie sind das Hierarchische Datenmodell (HDM) sowie das Netzwerk-Datenmodell (NDM).

  2. Das relationale Datenmodell (RDM): Dieses Datenmodell stellt den derzeitigen Standard von DBMS an, die angeboten werden. Die bekanntesten Systeme wie ORACLE, DB2, MySQL haben dieses Datenmodell implementiert.

  3. Postrelationale Datenmodelle: Diesen Modellen wird für die Zukunft eine hohe Bedeutung beigemessen; sie dürften das Relationale Datenmodell - zwar nicht generell, aber in weiten Anwendungsbereichen - ersetzen.

Kontrollaufgabe:
Warum wurde eine Kategorie von Datenmodellen jeweils in der Praxis durch eine andere ersetzt? Welche Eigenschaften wurden im Lauf der Zeit wichtiger; bei welchen ließ die Bedeutung nach?

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43hdm.htm

Das hierarchische Datenmodell

Das hierarchische Datenmodell als historisch ältestes Datenmodell von Bedeutung (die Datenbanksprache DL/1 auf diesem System wurde 1966 publiziert) erlangte diese Bedeutung, weil es im Datenbanksystem IMS von IBM, des damaligen Marktführers bei kommerziellen DV-Systemen, implementiert war. IMS war dazu gedacht, die Verwaltung konventioneller Dateisysteme einfacher und konsistenter zu machen.

Die vorrangig eingesetzte Programmiersprache in den 70er Jahren war im kommerziellen Bereich COBOL. Diese Sprache setzt hierarchische Daten- bzw. Dateistrukturen als Eingabe voraus. Dies soll an folgendem Beispiel erläutert werden:

Eine Datei für eine einfache Bibliotheksverwaltung soll alle Informationen des folgenden ER-Modells enthalten:

Ein COBOL-Programm, das beispielsweise die Fragen "Wer hat welches Buch ausgeliehen?", "Wer hat welches Buch bestellt?" oder "Wer hat die Bücher ausgeliehen, die ein bestimmter Besteller bestellt hat?" beantworten soll, könnte einen Datendeklationsbereich der folgenden Form besitzen:

Die Eingabedatei für ein solches Programm besteht aus einzelnen Datensätzen (records), die jeweils die Daten eines Buches und alle mit diesem Buch zusammenhängenden Daten (Wer hat das Buch bestellt? Wer hat es ausgeliehen?) beinhalten. Entsprechend der obigen Deklaration müssen diese Records folgende Struktur aufweisen:

Diese Struktur ist hierarchisch, d.h. jedes Record besteht aus Daten, die einzelne Entities des obigen ER-Modells beschreiben. Entitybezogen ergibt sich folgende Darstellung:

Entitytyp-bezogen ergibt sich folgende Darstellung:

Da die Eingabedatei für ein COBOL-Programm hierarchisch aufgebaut sein muss, muss ein hierarchisches DBMS auch hierarchische Datenstrukturen an dieses Programm übergeben. Demzufolge muss auch das Datenmodell hierarchisch sein, d.h. das Unternehmensmodell muss ebenfalls hierarchisch in das Unternehmensdatenmodell abgebildet werden. Es müssen Strukturelemente vorhanden sein, die die Konstruktion von Hierarchien zulassen und die ihre Entsprechung im ER-Modell haben. Es müssen Programmschnittstellen im DBMS vorhanden sein, die beim Datenzugriff die Traversierung von Hierarchien erlauben.

Im obigen Beispiel muss die Datenstruktur und damit die Datei übrigens nicht zwingend so wie dargestellt aussehen. Auch folgende alternative hierarchische Strukturen enthalten alle zur Beantwortung der genannten Fragen notwendigen Daten:

Kontrollaufgabe:
Welche der alternativen Datenstrukturen ist effizient, um die oben genannten Fragen an das COBOL-Programm beantworten zu können?

Literatur:
Heuer A., Saake G.: Datenbanken Konzepte und Sprachen. mitp: 2000. ISBN: 3826606191.
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43hdmstruc.htm

Strukturelemente des hierarchischen Datenmodells

Die Strukturelemente des Hierarchischen Datenmodells werden an folgendem Beispiel erklärt:

HDM-Element ERM-Entsprechung Beispiel
Segment Entity-Typ BUCH
BESTELLER
AUSLEIHER
Segment-Occurrence Entity Buch "Datenbanksysteme..."
Besteller Ott
Ausleiher Maier
Feld Attribut BUCH: Signatur
BESTELLER: Name
AUSLEIHER: Name

Schlüssel sind im HDM nicht notwendig. Das HDM kennt den Index, der allerdings nur zum schnelleren Finden eines gesuchten Records dient; eine Eindeutigkeit von Datensätzen ist nicht notwendig.

Die Segmente im hierarchischen Datenmodell sind hierarchisch verbunden, d.h. im HDM sind nur (1:1)- bzw. (1:n)-Beziehungen modellierbar, die wie folgt bezeichnet werden: Ein hierarchisch übergeordnetes Segment (z.B. in einer mehrstufigen Hierarchie) wird als parent bezeichnet; das untergeordnete als child; das oberste Segment in einer Hierarchie ist das Root-Segment. Zusammengehörige Segment-Occurences werden als database record bezeichnet; sie bilden den physischen Datensatz (der vom COBOL-Programm eingelesen wird). (m:n)-Beziehungen müssen im HDM durch spezielle Modellkonstrukte abgebildet werden. Beziehungsattribute werden jeweils dem untergeordneten Segment zugeordnet.

Innerhalb eines Segments muß eine Ordnung definiert werden, damit beim Zugriff auf Daten die Reihenfolge der einzelnen Segment-Occurrences bekannt ist. Kriterien für die Bildung dieser Ordnung können sein:

Kontrollaufgabe:
Welche Segmenthierarchien lassen sich aus dem Büro-Beispiel ableiten? Konstruieren Sie einige Beispiel-Datebase-Records. Wie sehen die physischen Record-Strukturen aus?

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43hdmnzm.htm

(m:n)-Beziehungen im Hierarchischen Datenmodell

Da das HDM nur hierarchische, also (1:1)- bzw. (1:n)-Beziehungen zuläßt, muss man bei der Modellierung von (n:m)-Beziehungen diese in hierarchische Beziehungen wie folgt umwandeln:

Hierbei nimmt man ein erhebliches Maß an Redundanz in Kauf: Dieselben Segment-Occurrences (hier: b1, b2) und ihre Attribute findet man gleichzeitig in mehreren Datensätzen. Um dies zu vermeiden, kann man die mehrfach auftretenden Child-Occurrences durch Pointer ersetzen: Die Daten eines Occurrences werden nur in einem Datensatz gespeichert; weitere gleiche Occurrences werden durch Pointer ersetzt, die auf die wirklichen Daten zeigen. Damit wird ein Child in einem Database Record zu einem Logical Child.

Hierbei taucht allerdings das Problem auf, dass es nicht eindeutig ist, in welchem Datensatz ein Occurrence durch einen Pointer ersetzt werden soll. Um diesem Problem zu entgehen, ersetzt man alle untergeordneten Child-Occurrences durch Pointer:

Da (m:n)-Beziehungen im ER-Modell nicht gerichtet sind, ist aber immer noch nicht eindeutig, unter welches (physische) Segment das (logische) Pointer-Segment gesetzt werden soll. Im Beispiel könnte es auch unter B gesetzt werden, d.h. die Pointer und die Beziehungsattribute wären in B-Datensätzen untergebracht. Hier geht man in der Praxis den Weg, dass das "wichtigste" Segment Parent-Segment wird, wobei "wichtig" entweder bedeutet, dass von diesem Segment aus häufiger auf das andere Segment zugegriffen wird als umgekehrt oder dass der Zugriff von dort aus zeitkritischer ist. Beispielsweise würde man in der obigen Hierarchie mit Ausleihern (A) und Büchern (B) bei der Prüfung, ob das Ausleihdatum eines Buches überschritten ist, ausleiherbezogen vorgehen ("Einstieg" in die Hierarchie über Ausleiher); Ausleiher werden dahingehend überprüft, ob sie Bücher ausgeliehen haben und dabei die Frist überschritten ist. Würde man jedoch buchbezogen vorgehen und Bücher regelmäßig überprüfen, ob die Ausleihfrist überschritten ist ("Einstieg" in die Hierarchie über Bücher), so würde man besser das Pointersegment unter B hängen.

Damit sind Zugriffsinformationen wichtig für die Modellierung; dies wiederum durchbricht den 3-Ebenen-Ansatz von Datenbanksystemen: Die externe Ebene bestimmt die konzeptuelle Ebene. Damit wiederum verliert man die für Datenbanksysteme so wichtige Eigenschaft der physischen und logischen Datenunabhängigkeit.

Kontrollaufgabe:
Welche physischen und logischen Segmenthierarchien lassen sich aus dem Büro-Beispiel ableiten?

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43hdmschema.htm

Schemadefinition im Hierarchischen Datenmodell am Beispiel IMS

Angenommen, es liege im Unternehmen eine hierarchische Projektorganisation vor, d.h. Mitarbeiter können nur in maximal einem Projekt mitarbeiten, dann könnte auf einem IMS-Datenbanksystem folgendes, nur aus physischen Hierarchien bestehendes Schema implementiert werden:

Die Datenbank PROJEKTDB1, die diese Hierarchie implementiert, wird durch die Database Description (DBD) beschrieben; der Zugriff auf die Datenbank erfolgt mittels der HIDAM-Methode, d.h. hierarchisch, wobei jeder Datensatz direkt angesprungen werden kann. Es gibt zwei Segmente PROJEKT und ANGEST. Die Segment-Occurences von PROJEKT können über den eindeutigen Wert (U) im Feld PNR angesprungen werden; der Datensatz ist 182 Bytes lang. PNR ist 6 Bytes lang und beginnt auf dem 1 Byte des Datensatzes. Das Beziehungsattribut PROZARBZ (prozentualer Anteil der Arbeitszeit im Projekt) wird dem Segment ANGEST zugeordnet.

Bei einer nichthierarchischen Projektstruktur (Mitarbeiter können in mehreren Projekten zugleich mitarbeiten) muß man eine logische Hierarchie einführen:

Das Segment PA ist ein logisches Child und verweist auf das Segment ANGEST in der Datenbank ANGESTDB.

Kontrollaufgabe:
Formulieren Sie ein IMS-Datenbankschema für das Büro-Beispiel.

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43hdmzug.htm

Datenzugriff und -manipulation im hierarchischen Datenmodell am Beispiel IMS

Der Zugriff auf Daten in Hierarchischen Datenbanksystemen muß immer über das Root-Segment einer Datenbank erfolgen. Von dort aus navigiert man zu den Daten im gefundenen Datensatz, die man sucht. Voraussetzung für das Finden und Auslesen von Daten ist also immer ein Algorithmus, d.h. der Anwender muß prozedural vorgehen.

Im System IMS erfolgt der Zugriff (Retrieval) über Statements, die in der Datenbanksprache DL/1 zusammengefasst wurde. Grundlage aller Datenbankzugriffe bildet ein GU-Statement (Get Unique); damit steigt man in eine Hierarchie ein (Zugriff auf das Root-Segment) und findet einen bestimmten Datensatz. Von dort aus springt man innerhalb eines Datensatzes auf die jeweils nächsten Segmente (GN Get Next), wobei die Ordnung innerhalb des Segments ausgenutzt wird. Folgendes einfache Bibliotheksbeispiel soll dies verdeutlichen:

Analog funktioniert die Datenmanipulation: Auch hier muss zunächst ein Datensatz lokalisiert werden (GU); dann muß der Datensatzzeiger im Datensatz zum richtigen Segment positioniert werden (GN). Dann wird, beispielsweise beim Einfügebefehl (ISRT), ein im I/O-Bereich abgelegtes Datenobjekt an die jeweilige Stelle eingefügt.

Dieses Vorgehen setzt beim Anwender sehr viel voraus:

Beide Punkte führen dazu, dass es Mitarbeitern ohne Programmiererfahrung praktisch unmöglich ist, mit einer hierarchischen Datenbank zu arbeiten. Dies wiederum hatte zur Folge, dass dies auch gar nicht vorgesehen war: IMS hat keine grafische Benutzerschnittstelle; der Zugriff erfolgt ausschließlich über Anwendungsprogramme mit Hilfe von Spracheinbettung. D.h. der Softwareentwickler formuliert die Zugriffsalgorithmen in Programmen, indem er die Anforderungen der Anwender in den Fachabteilungen umsetzt. Dies macht die Nutzung der Daten sehr unflexibel, da die Anwender ihre Anforderung nicht selbst umsetzen können, sondern auf die Umsetzung durch die Softwareentwickler warten müssen.

Ein Vorteil und zugleich ein Problem stellt weiterhin die Beschränkung des Datenmodells auf hierarchische Strukturen dar. Im bereits genannten einfachen Bibliotheksmodell kann die Hierarchie auf alternative Arten formuliert werden:

Bei einer Fragestellung wie "Welche Bücher hat Besteller Ott bestellt?" kommt man in der Bestellerdatenbank recht schnell zum Ergebnis: Man springt direkt auf den Datensatz mit dem Bestellernamen Ott und hat in diesem Datensatz alle Informationen verfügbar. Hat man jedoch eine Ausleiherdatenbank vor sich (die dieselben Daten enthält, jedoch anders strukturiert), so muss man bei dieser Fragestellung alle Datensätze (sequentiell) durchsehen, ob bei einem ausgeliehenen Buch ein Besteller registriert ist, der Ott heißt. Man kann also Hierarchische Datenbanken im Hinblick auf häufige/zeitkritische Abfragen sehr gut "tunen", hat aber immense Probleme, wenn andere Fragestellungen wichtig werden. Damit wird die Inflexibilität solcher Datenbanken noch gesteigert.

Um dieses Problem zu vermeiden, ist in IMS die Formulierung von Sekundärindizes möglich. Diese bilden eine Art logische Hierarchie, deren Root-Segment das Segment bildet, auf das direkt zugegriffen werden soll (im obigen Beispiel das Segment BESTELLER in der Ausleiherdatenbank). Von dort gelangt man dann über eine logische Verbindung zum jeweiligen physischen Datensatz in der Ausleiherdatenbank.

Kontrollaufgabe:
Warum war die Inflexibilität Hierarchischer Datenbanksysteme in den 70er Jahren kaum ein Problem - im Gegensatz zu heute?

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43hdmtrans.htm

Transformation eines ER-Modells ins hierarchische Datenmodell

Die Transformation eines ER-Modells in ein Hierarchisches Datenmodell ist sehr aufwendig. Folgende Schritte müssen durchlaufen werden; zur Veranschaulichung soll das Büro-Beispiel dienen:

  1. Erstellung der Zugriffsmatrix
  2. Erstellung Konzeptionelles Strukturdiagramm
  3. Bildung logischer Hierarchien
  4. Bildung physischer Hierarchien

Aus dem einfachen Beispiel sieht man bereits, dass das Hierarchische Datenmodell zu sehr unübersichtlichen und komplexen Unternehmensdatenmodellen führt.

Kontrollaufgabe:
Transformieren Sie das ER-Modell des Sportvereinsbeispiels in ein Hierarchisches Datenmodell. Machen Sie entsprechende Annahmen hinsichtlich der Zugriffsmatrix.

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43ndm.htm

Das Netzwerk-CODASYL/DBTG-Datenmodell

Das Netzwerkdatenmodell wurde 1971 von der Database Task Group des Committee in Data Systems Languages (CODASYL/DBTG) als Standard publiziert; es wird daher auch als CODASYL/DBTG-Modell bezeichnet. Hinter der Entwicklung dieses Standards stand der Versuch, die Inflexibilität des Hierarchischen Datenmodells (Vermischung von interner und externer Ebene, nur (1:n)-Beziehungen, Abhängigkeit der Performance vom jeweiligen Datenmodell, Zugriff nur durch Anwendungsprogramme) zu beseitigen. Die "Tricks", die benutzt werden müssen, um diese Probleme zu umgehen (Verpointerung, logische und physische Hierarchien, Sekundärindizes), sollten in ein konsistentes und geschlossenes Konzept eingearbeitet werden.

Das Grundprinzip dieses Datenmodells ist daher, dass die mehrstufigen Hierarchien des Hierarchischen Datenmodells in zweistufige Hierarchien aufgelöst werden. Die Zusammensetzung zu einer (COBOL-)Datenstruktur als Eingabe für Anwendungsprogramme erfolgt durch den Anwender selbst, ist also nicht im Datenmodell fest vorgegeben.

Die Entity-bezogenen Strukturelemente orientieren sich daher weitgehend am Hierarchischen Datenmodell; die Beziehungskonzepte wurden jeduch grundlegend geändert. Auch der Datenzugriff ist navigierend und orientiert sich damit weitgehend am Hierarchischen Datenmodell.

Der CODASYL-Standard wurde nach seiner Veröffentlichung als wesentliche Verbesserung gegenüber dem Hierarchischen Datenmodell begrüßt; führende Datenbankhersteller wie Siemens (UDS), Unisys(DMS-1100), Honeywell (IDS) oder DEC(DBMS-10) boten umgehend darauf basierende Datenbankmanagementsysteme an. Dass diese Systeme jedoch nie die Verbreitung und Akzeptanz erfuhren, die ihnen vorausgesagt wurde, lag daran, dass 1970 Codd sein Relationales Datenmodell veröffentlichte; dieses Modell ging hinsichtlich der Flexibilität und Einfachheit in der Modellierung weit über den CODASYL-Standard hinaus.

Kontrollaufgabe:
Arbeiten Sie die Unterschiede zwischen dem Hierarchischen und dem Netzwerkdatenmodell heraus.

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43ndmstruc.htm

Das Netzwerk-CODASYL/DBTG-Datenmodell

Die Strukturelemente des Netzwerk-Datenmodells werden wieder an folgendem Beispiel erklärt:

NDM-Element ERM-Entsprechung Beispiel
Record-Typ Entity-Typ BUCH
BESTELLER
AUSLEIHER
Record-Occurrence Entity Buch "Datenbanksysteme..."
Besteller Ott
Ausleiher Maier
Feld Attribut BUCH: Signatur
BESTELLER: Name
AUSLEIHER: Name

Schlüssel sind auch im NDM nicht notwendig. Das NDM kennt ebenfalls den Index, der allerdings nur zum schnelleren Finden eines gesuchten Records dient; eine Eindeutigkeit von Datensätzen ist nicht notwendig.

Im NDM können wiederum nur (1:n)-Beziehungen, d.h. hierarchische Beziehungen modelliert werden, dies jedoch nur zweistufig. Dabei werden die übergeordnete Record-Occurrence (Owner) sowie die untergeordneten Occurrences (Member) zu einem Set zusammengefasst. Ein Set hat eine Bezeichnung; auf Typebene werden die beteiligten Record-Typen durch einen Pfeil vom Owner- zum Member-Typ gekennzeichnet. Die Beziehungsattribute im ER-Modell werden den Member-Occurrences zugeordnet. Ein Record-Typ kann dabei Owner- und/oder Member-Typ in mehreren Set-Typen sein. Sets können leer sein, d.h. sie haben keine Member. Ein Loop bezeichnet ein Set, in dem Owner und Member aus dem selben Record-Typ stammen.

(n:m)-Beziehungen werden im NDM über Kettrecords modelliert. Der Beziehungstyp wird dabei zum Record-Typ; auf diesen zeigen Pfeile von den an der Beziehung beteiligten Record-Typen. Damit wird die (n:m)-Beziehung in zwei hierarchische Beziehungen zerlegt; den entsprechenden Set-Typen müssen geeignete Bezeichnungen zugrordnet werden.

Innerhalb eines Sets muß eine Set-Ordnung definiert werden, damit beim Zugriff auf Daten die Reihenfolge der einzelnen Record-Occurrences bekannt ist. Kriterien für die Bildung dieser Ordnung können auch hier wieder wie beim HMD sein:

Verbindet man alle Set-Typen zu einem Netz, so erhält man das Bachman-Diagramm, das im Prinzip dem konzeptionellen Strukturdiagramm entspricht; im Büro-Beispiel erhält man folgendes Diagramm:

Dem obigen Beispiel-Diagramm mit Büchern, Ausleihern und Bestellern entspricht schließlich das folgende Datenbankschema:

Kontrollaufgabe:
Erstellen Sie das Bachman-Diagramm für das Sportvereins-Beispiel.

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43ndmzug.htm

Datenzugriff und -manipulation im Netzwerk-Datenmodell

Der Zugriff auf Daten in CODASYL-Datenbanksystemen kann direkt auf jeden Owner in einem Set erfolgen. Von dort aus navigiert man über das zutreffende Member in dem Set zu einem Set eines weiteren Set-Typs, in dem dieses Record-Occurrence vertreten ist. Von diesem Occurrence gelangt man zum Owner des Sets (falls das Occurrence dort ebenfalls Member ist) bzw. zu weiteren Members (falls das Occurrence dort Owner ist) usw.

Im folgenden Beispiel soll die Frage beantwortet werden: "Welcher Fachrichtung gehört der Besteller an, der ein Buch bestellt hat, das Meier ausgeliehen hat?"

Der (im Anwendungsprogramm codierte) Abfrage-Algorithmus lautet - in Pseudocode formuliert- wie folgt:

Wie beim HDM wird auch hier beim Anwender sehr viel vorausgesetzt:

Damit ist der Datenbankzugriff für Programmier-Laien immer noch zu schwierig und umständlich.

Kontrollaufgabe:
Formulieren Sie einen Zugriffsalgorithmus für die Fragestellung "Wann starteten die Projekte, in denen Mitarbeiter aus Abteilung EDV-AE7 arbeiten?" im Büro Beispiel.

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43rdm.htm

Das relationale Datenmodell

Das relationale Datenmodell stellt den gegenwärtigen (Stand: 2001) Standard bei marktgängigen Datenbanksystemen dar. Die bekanntesten und am meisten verbreiteten Produkte sind dabei Oracle und DB2 (IBM).

Dabei werden Daten in Form von Tabellen modelliert; jede Zeile einer Tabelle enthält die Daten eines zu beschreibenden Objekts in allen Attributen; jede Spalte enthält die Daten aller Objekte in einem Attribut. Es wurde 1970 von E.F.Codd veröffentlicht.

Die Bezeichnung "relational" (und nicht etwa "tabellarisch") für das Datenmodell stammt von den mathematischen Grundlagen dieses Modells, der Relationenalgebra. Folgende Begriffe und Konzepte werden dort behandelt:

Übertragen auf das Datenmodell bedeutet dies folgendes: Ein Entity-Typ E in dem ER-Modell, das in ein Relationales Modell transformiert werden soll, besitze k Attribute mit den Domains A1, A2, ... Ak. Dann kann jedes Entity durch eine Attributwert-Kombination e = (a1j, a2j, ..., akj) beschrieben werden. Diese kann als ein Tupel des Kartesischen Produkts K = {A1 x A2 x ... x Ak} aller denkbaren Kombinationen von Ausprägungen aufgefasst werden. Die Menge der Tupel, die tatsächlich auftretende Entities beschreiben, ist somit eine k-stellige Relation R als Teilmenge von K. Ein Tupel entspricht damit im Relationalen Datenmodell einer Zeile einer Tabelle; eine Spalte entspricht den Elementen der Entities in den Domains; die Tabelle selbst stellt die Relation dar.

Aus dieser Mengenbetrachtung von Daten im Relationalen Datenmodell kann man folgern:

Die mathematische Formulierung des Datenmodells prägt sowohl die Strukturelemente des Relationalen Datenmodells als auch die Art und Weise des Zugriffs auf Daten. Zwar mag die streng mathematische Betrachtungsweise etwas ungewohnt sein; die Mengenbetrachtung von Daten führt jedoch - im Gegensatz zu hierarchischen oder netzwerorientierten Datenmodellen - zu einer erheblich flexibleren und einfacheren Modellierung und schließlich zu einem flexibleren und einfacheren Datenzugriff, der die Nutzung von Datenbanksystemen auch für Nicht-Programmierer möglich macht.

Kontrollaufgabe:
Sind in MS Access die Folgen der Mengenbetrachtung wirklich konsequent umgesetzt?

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
43rdmstruc.htm

Strukturelemente des Relationalen Datenmodells

Die Strukturelemente des Relationalen Datenmodells werden wieder an folgendem Beispiel erklärt:

NDM-Element ERM-Entsprechung Beispiel
Relation, Tabelle Entity-Typ BUCH
BESTELLER
AUSLEIHER
Zeile einer Tabelle Entity Buch "Datenbanksysteme..."
Besteller Ott
Ausleiher Maier
Attribut, Feld Attribut BUCH: Signatur
BESTELLER: Name
AUSLEIHER: Name

Schlüssel sind im RDM notwendig, um einzelne Zeilen einer Tabelle unterscheiden zu können.

Bei der Transformation von Beziehungstypen aus dem ER-Modell in das Relationale Modell geht man wie folgt vor, wobei zur Veranschaulichung angenommen wird, dass 2 Entity-Typen A=(A1, A2) mit den Attributen A1 und A2 (davon A1 als Schlüssel) und B=(B1, B2) sowie ein Beziehungstyp R=(R1, R2) vorliegen (dies kann man auch auf rekursive Beziehungen übertragen; B wird dabei durch A ersetzt):

a) (m:n)-Beziehungen; mehrstellige Beziehungen:
Aus dem Beziehungstyp wird eine Relation mit den Primärschlüsseln der beteiligten Entity-Typen als (zusammengesetzter) Schlüssel gebildet:
RA=(A1, A2), RB=(B1, B2), RR=(A1, B1, R1, R2).
Im obigen Beispiel trifft dies für den Beziehungstyp "bestellt" zu.

b) (1:n)-Beziehungen:
Hier sind folgende zwei Fälle zu unterscheiden:

  1. Muss-Beziehungen auf der (n)-Seite: Jedes Entity des hierarchisch untergeordneten Typs (n-Typ) ist mit genau einem Entity des übergeordneten Typs (1-Typ) verbunden.
    Die Beziehungsattribute und der Primärschlüssel des (1)-Typs (im Beispiel: A) werden dem (n)-Typ (im Beispiel: B) zugeordnet. Der Primärschlüssel in RA ist Fremdschlüssel in RB.
    RA=(A1, A2), RB=(B1, B2, A1, R1, R2).

  2. Kann-Beziehungen auf der (n)-Seite:

    Hier ist folgendes abzuwägen:

    Modelliert man wie in Fall a) (Beziehungstyp wird eigenständige Relation), so nimmt man eine zusätzliche Relation in Kauf, die im System verwaltet (Verwaltungsaufwand) und bei einer Abfrage wieder mit anderen verbunden werden muss (Performance). In diesem Fall genügt es allerdings, wenn nur B1 Schlüssel in RR wird, da dieser ja bereits die Tupel eindeutig macht.
    RA=(A1, A2)
    , RB=(B1, B2), RR=(B1, A1, R1, R2).

    Modelliert man wie in Fall b) (Beziehungstyp wird in (n)-Typ abgebildet), so nimmt man NULL-Werte in Kauf, wie das obige Beispiel in der Relation BUCH zeigt.

Bei der Transformation eines ER-Modells in ein Relationales Datenmodell wie dargestellt können sich folgende Probleme ergeben:

Die Definition des Datenbankschemas schließlich besteht darin, dass jede Relation definiert wird; im obigen Fall könnte dies beispielsweise wie folgt aussehen, wenn man den Befehl create der Datenbanksprache SQL in der Version SQL2 dazu benutzt:

Folgende Abbildung spezifiziert den Create-Befehl für das Datenbanksystem PostgreSQL:

SQL-Befel CREATE Im Beispiel wird die Struktur der Film-Datenbank films definiert. Das Attribut code bildet den 5 Zeichen langen Primärschlüssel. Das Attribut title ist maximal 40 Zeichen lang und muss bei jedem Datensatz einen Wert enthalten, darf also nicht leer sein.

Kontrollaufgabe:
Erstellen Sie das Relationenschema (Tabellenstruktur; SQL-Create-Anweisung) für das Sportvereins-Beispiel.

Literatur:
Steiner R.: Theorie und Praxis relationaler Datenbanken. Vieweg Verlagsgesellschaft: 2000 Auflage. ISBN: 3528354275.

© Prof. Dr. Hans Jürgen Ott --> home
43rdmcodd.htm

Die 12 Kriterien von CODD für Relationale Datenbanksysteme

Relationale Datenbanksysteme haben spezifische Vorteile gegenüber Datenbanksysteme, die auf anderen Datenmodellen basieren. Dies hat in der Vergangenheit dazu geführt, dass Anbieter von nichtrelationalen Datenbanksystemen ihre System auf das relationale Modell "umgebogen" haben. Es entstand die Diskussion, unter welchen Umständen denn relationale Datenbanksysteme wirklich die Bezeichnung "relational" zu recht führen.

E.F.Codd als Begründer des relationalen Datenmodells führte daher 1985 12 Kriterien bzw. Regeln ein, die erfüllt sein müssen, damit wirklich von einem relationalen Datenbanlsystem gesprochen werden kann:

  1. Alle Informationen in relationalen Datenbanken werden logisch in Tabellen dargestellt, insbesondere Daten, Tabellendefinitionen, Integritätsbedingungen sowie Sicherheitsinformationen (z. B. Zugangsberechtigungen).

  2. Jeder elementare Wert einer relationalen Datenbank muß logisch durch eine Kombination von Tabellenname, Primärschlüssel und Attributname (Spaltenname) abrufbar sein. Dies bedeutet, daß in einer Tabelle an jedem Schnittpunkt einer Zeile mit einer Spalte nur ein Wert stehen darf.

  3. Nullwerte stellen in Attributen, die nicht Teil eines Primärschlüssels sind, fehlende Information dar und werden durchgängig gleich, insbesondere unabhängig vom Datentyp des Attributes, behandelt. Man kann also nicht beispielsweise in numerischen Feldern das Feld leerlassen, und bei Textfeldern Blanks einfügen.

  4. Die Datenbankstruktur wird in derselben logischen Struktur wie die Daten gespeichert, also in Tabellen. Dies bedeutet, dass das Data Dictionary ebenfalls relational ist.

  5. Ein relationales System enthält eine Abfragesprache, die mindestens die folgenden Funktionen unterstützt:
  6. Views bzw. externe Sichten werden vom System automatisch aktualisiert, wenn in den Ausgangsdaten Änderungen gemacht werden.

  7. Abfrage- und Editieroperationen müssen als Ergebnis ganze Tabellen und nicht nur einzelne Sätze liefern (mengenorientierte Sichtweise).

  8. Der Zugriff auf die Daten muß unabhängig davon sein, wie die Daten gespeichert werden oder wie physikalisch auf sie zugegriffen wird (Physische Datenunabhängigkeit).

  9. Anwendungen und Zugriffe dürfen sich logisch nicht ändern, wenn Tabellen so geändert werden, daß alle Information erhalten bleibt (Logische Datenunabhängigkeit).

  10. Alle Integritätsbedingungen müssen in der Datenbanksprache definierbar sein und sind Teil des konzeptuellen Schemas. Das System muß mindestens die folgenden Integritätsbedingungen prüfen:
  11. Anwendungen für eine nicht-verteilte Datenbank dürfen sich beim Übergang zu einer verteilten Datenbank logisch nicht ändern (Verteilungsunabhängigkeit).

  12. Unterstützt ein relationales Datenbanksystem neben der High-Level-Abfragesprache (z.B. SQL) eine Low-Level-Abfragesprache, so darf diese die Integritätsbedingungen der High-Level-Sprache nicht unterlaufen. Beispiel: Die Low-Level Abfragesprache darf z. B. nicht direkt auf die physikalischen Eigenschaften der gespeicherten Daten zugreifen.

Ende 1990 veröffentlichte E. F. Codd ein Buch über relationale Datenbanken, in dem er die einstigen zwölf Kriterien des relationalen Modells auf 333 Regeln differenziert. Darin wird die Relationalität einer Datenbank bis ins letzte Detail festgeschrieben.

Kontrollaufgabe:
Erfüllt MS Access die 12 Kriterien von Codd für relationale Datenbanksysteme?

Literatur:
Steiner R.: Theorie und Praxis relationaler Datenbanken. Vieweg Verlagsgesellschaft: 2000 Auflage. ISBN: 3528354275.

© Prof. Dr. Hans Jürgen Ott --> home
43rdmloesbuero.htm

Musterlösung RDM Sportvereinsbeispiel

create table HOBBYSPIELER (
HSpielerNummer int primary key
);

create table WETTKAMPFSPIELER (
WSpielerNummer int primary key,
Verbandsnummer int
);

create table WETTKAMPF (
WNummer int primary key,
Datum date,
Ort varchar(80)
);

create table MANNSCHAFT (
MBezeichnung varchar(24) primary key,
Liga varchar(8),
Kaptn int references WETTKAMPFSPIELER [(WSpielerNummer)] on delete CASCADE
);

create table SPIELT (
Spieler int primary key references WETTKAMPFSPIELER [(WSpielerNummer)] on delete CASCADE,
Mannschaft varchar(24) primary key references MANNSCHAFT [(MBezeichnung)] on delete CASCADE,
Wettkampf int primary key references WETTKAMPF [(WNummer)] on delete CASCADE,
Sieg smallint,
Gegenspieler int
);

create table ERH_STRAFE (
Spieler int primary key references WETTKAMPFSPIELER [(WSpielerNummer)] on delete CASCADE,
Wettkampf int primary key references WETTKAMPF [(WNummer)] on delete CASCADE,
Betrag real
);
© Prof. Dr. Hans Jürgen Ott --> home
43loesrdmbib.htm

Lösung zur Übung: ERM Bibliothek

Aus dem ER-Modell des Bibliotheksbeispiels erhält man folgendes relationale Datenbankschema:

CREATE TABLE BUCH (
ISBNNr CHAR(13) PRIMARY KEY,
Autoren CHAR,
Titel CHAR(100),
Auflage INT,
Ort CHAR(20),
Verlag CHAR(30),
Jahr INT
);
CREATE TABLE EIGENES-EXEMPLAR (
Signatur CHAR(10) PRIMARY KEY,
ISBNNr CHAR(13) REFERENCES BUCH [(ISBNNr)] on delete RESTRICT,
Preis NUMERIC(10,2),
Stichworte CHAR,
Status CHAR,
Präsenz INT,
KaufDatum DATE,
LieferscheinNr CHAR(15),
LieferDatum DATE,
UeberwAuftragDatum DATE,
RechNummer CHAR(15),
RechDatum DATE,
AusleiherAusweisNr CHAR(10) REFERENCES AUSLEIHER [(AusweisNr)] on delete RESTRICT,
AusleihDatum DATE,
MahnDatum DATE
);
CREATE TABLE FERNLEIHE-BUCH (
ISBNNr CHAR(13) PRIMARY KEY,
FSignatur CHAR(10) PRIMARY KEY,
Autoren CHAR,
Titel CHAR(100),
Auflage INT,
Ort CHAR(20),
Verlag CHAR(30),
Jahr INT,
FremdBibName CHAR(100) REFERENCES FREMDBIBLIOTHEK [(Name)] on delete RESTRICT,
AuftragsDatum DATE,
LieferDatum DATE,
Leihfrist DATE,
AusleiherAusweisNr CHAR(10) REFERENCES AUSLEIHER [(AusweisNr)] on delete RESTRICT,
AusleihDatum DATE,
MahnDatum DATE
);
CREATE TABLE BESTELLER (
Kuerzel CHAR(3) PRIMARY KEY,
Vorname CHAR(10),
Nachname CHAR(30),
Zimmer CHAR(3),
Telefon CHAR(20),
Fachrichtung CHAR(10),
Hauptamtl INT
);
CREATE TABLE AUSLEIHER (
AusweisNr CHAR(10) PRIMARY KEY,
Vorname CHAR(10),
Nachname CHAR(30),
Strasse CHAR(30),
PlzOrt CHAR(30),
Telefon CHAR(20)
);
CREATE TABLE FREMDBIBLIOTHEK (
Name CHAR(100) PRIMARY KEY,
Strasse CHAR(30),
PlzOrt CHAR(30),
Telefon CHAR(20)
);
CREATE TABLE BUCHHAENDLER (
Code CHAR(10) PRIMARY KEY,
Name CHAR(50),
Strasse CHAR(30),
PlzOrt CHAR(30),
Telefon CHAR(20),
Konto CHAR(15),
Institut CHAR(20),
BLZ INT,
KdNummer CHAR(20)
);
CREATE TABLE bestellt (
(ISBNNr CHAR(13) PRIMARY KEY REFERENCES BUCH [(ISBNNr)] on delete RESTRICT,
BestellerKuerzel CHAR(3) PRIMARY KEY REFERENCES BESTELLER [(Kuerzel)] on delete RESTRICT,
Anzahl INT,
AuftragsDatum DATE,
NachrichtsDatum DATE
);

CREATE TABLE liefert-eigen (
ISBNNr CHAR(13) PRIMARY KEY REFERENCES BUCH [(ISBNNr)] on delete RESTRICT,
BuchhaendlerCode CHAR(10) PRIMARY KEY REFERENCES BUCHHAENDLER [(Code)] on delete RESTRICT,
BestellDatum DATE,
LieferDatum DATE,
AnsichtsDatum DATE
);
© Prof. Dr. Hans Jürgen Ott --> home
43rdmzug.htm

Datenzugriff und -manipulation im Relationalen Datenmodell

Daten-Zugriffe sind im Relationalen Modell direkt auf jede Relation möglich. Auch auf einzelne Tupel einer Relation ist der Zugriff direkt möglich; die Spezifikation des gewünschten Tupels in der Abfrage erfolgt durch eine Attributwertkombination, die das/die gewünschte/n Tupel erfüllen müssen. Man geht damit über von einer prozeduralen, algorithmischen Spezifikation des Zugriffs (wie im HDM oder NDM) zu einer deklarativen Spezifikation; der Suchalgorithmus ist bei Relationalen Datenbanken Teil des DBMS. Der Anwender muss also hierbei nur wissen, was er als Ergebnis haben will (Beschreibung des Ergebnisses) und nicht, wie dieses Ergebnis hervorgebracht werden soll (Navigations-Algorithmus). Dies stellt eine erhebliche Erleichterung in der Formulierung der Abfrage dar und ermöglicht auch Nicht-Informatikern diese Formulierung. Damit erreicht das Datenbanksystem die notwendige Einfachheit und Flexibilität, die Informatik-Laien voraussetzen und entlastet die DV-Abteilung damit von Arbeiten und Aufträgen, die die Anwender jetzt selbst erledigen können (Individuelle Datenverarbeitung).

Das Ergebnis einer Abfrage im Relationalen Datenmodell ist - bedingt durch die mengenalgebraische Sichtweise - immer wieder eine Relation, die jedoch durchaus nur aus einer Spalte und einer Zeile bestehen kann oder gar einen NULL-Wert zurückliefert, wenn keine Tupel vorliegen, die in der Abfrage spezifiziert wurden.

Die Abfrage von Daten erfolgt in der Datenbanksprache SQL mit Hilfe der Anweisung SELECT. In der folgenden Darstellung sind die Optionen des Select-Befehls des Datenbanksystems PostgreSQL dargestellt; sie werden in den folgenden Abschnitten erläutert:

SELECT [ ALL | DISTINCT [ ON ( expression [, ...] ) ] ] * | expression [ AS output_name ] [, ...]
[ FROM from_item [, ...] ]
[ WHERE condition ]
[ GROUP BY expression [, ...] ]
[ HAVING condition [, ...] ]
[ { UNION | INTERSECT | EXCEPT } [ ALL ] select ]
[ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
[ FOR UPDATE [ OF tablename [, ...] ] ]
[ LIMIT { count | ALL } ]
[ OFFSET start ];

wobei from_item spezifiziert werden kann durch

[ ONLY ] table_name [ * ] [ [ AS ] alias [ ( column_alias_list ) ] ] |
( select ) [ AS ] alias [ ( column_alias_list ) ] |
from_item [ NATURAL ] join_type from_item [ ON join_condition | USING ( join_column_list ) ]

und join_type wiederum spezifiziert werden kann entweder durch

[ INNER ] JOIN, LEFT [ OUTER ] JOIN, RIGHT [ OUTER ] JOIN, FULL [ OUTER ] JOIN

oder durch

CROSS JOIN

Die mengenalgebraische Sichtweise des Datenmodells führt nun dazu, dass die Datenbanksprache für mengenorientierte Operationen wie beispielsweise Vereinigung oder Durchschnitt Befehle vorsehen muss; weiterhin werden spezifische Relationenoperationen angeboten. Darüberhinaus sind natürlich die üblichen Datenbank-Operationen wie Insert, Update und Delete sowohl für Tupel als auch für Tabellendefinitionen Teil der Datenbanksprache.

Diese Vielfalt an Operationen macht den Zugriff flexibel; die Einfachheit der Formulierung dieser Operationen in einer Datenbanksprache wie SQL erleichtert den Zugriff. Diese Einfachheit führt wiederum dazu, daß neuartige Möglichkeiten der Zugriffsspezifikation wie beispielsweise QBE möglich werden, die die Spezifikation nochmals erleichtern.

Da der Suchalgorithmus Teil des DBMS ist, kann er natürlich - in Bezug auf reale Zugriffstrukturen - nicht so optimiert werden, wie im HDM. Dies bedeutet, dass es in der betrieblichen Praxis Fälle gibt, wo Hierarchische Datenbanksysteme Relationalen Systemen hinsichtlich der Performance überlegen sind. Mittlerweile existieren jedoch zahlreiche Konzepte und auch Tools für das Tuning von Relationalen Datenbanksystemen, so dass dieser latente Nachteil gegenüber Hierarchischen Datenbanken relativiert wird.

Kontrollaufgabe:
Stellen Sie die Vor- und Nachteile von Relationalen vs. Hierarchischen Datenbanksystemen in einer Tabelle einander gegenüber.

Literatur:
Steiner R.: Theorie und Praxis relationaler Datenbanken. Vieweg Verlagsgesellschaft: 2000 Auflage. ISBN: 3528354275.

© Prof. Dr. Hans Jürgen Ott --> home
43rdmzugmenge.htm

Mengenalgebraisch orientierte Zugriffsoperationen im RDM

SQL im derzeitigen Standard SQL2 sieht folgende Mengenoperationen vor, wobei (zunächst) als Voraussetzung angenommen wird, dass sich diese Operationen auf Relationen beziehen, die identische Attribute haben bzw. deren Attribut-Domains identisch sind. Angenommen werden soll, dass sich diese Operationen auf zwei Relationen KUNDEN_PLZ7 (Kunden im Postleitzahlenbereich 7) und KUNDEN_PLZ8 (Kunden im Postleitzahlenbereich 8) beziehen sollen.

Vereinigung (UNION)

Diese Operation bildet die Vereinigungsmenge der Tupel aus den Ausgangsrelationen; im Beispiel wären dies alle Kunden aus Süddeutschland.
select * from KUNDEN_PLZ7 UNION select * from KUNDEN_PLZ;

Durchschnitt (INTERSECT)

Diese Operation bildet die Schnittmenge der Tupel aus den Ausgangsrelationen; im Beispiel wären dies alle Kunden, die sowohl im Postleitzahlenbereich 7 als auch im Bereich 8 eine Niederlassung haben.
select * from KUNDEN_PLZ7 INTERSECT select * from KUNDEN_PLZ;

Differenz (EXCEPT)

Diese Operation bildet die Differenzmenge der Tupel aus den Ausgangsrelationen; im Beispiel wären dies alle Kunden, die im Postleitzahlenbereich 7, jedoch nicht gleichzeitig im Bereich 8 sitzen.
select * from KUNDEN_PLZ7 EXCEPT select * from KUNDEN_PLZ;

Sind die Relationen nicht kompatibel, d.h. nicht attribut- und domainidentisch, so muss bei der Abfrage ein kompatibler Teilbereich beider Relationen angegeben werden. Angenommen, es liegen folgende Ausgangs-Relationen vor:

Die UNION-Anweisung, die alle lieferbaren Produkte abfrägt, könnte in diesem Fall wie folgt lauten:

select * from LIEFERANTENPRODUKTE
UNION CORRESPONDING BY (ProdBezeichnung, Farbe, Preis)
select * from EIGENPRODUKTE;

Sind gleichnamige Attribute domain-kompatibel, d.h. haben sie identische Domains, dann kann die Attributbezeichnung entfallen; die UNION-Anweisung bezieht sich dann auf alle gleichnamigen Attribute:

select * from LIEFERANTENPRODUKTE
UNION CORRESPONDING
select * from EIGENPRODUKTE;

Kontrollaufgabe:
Finden Sie Fragestellungen im Sportvereins-Beispiel, die mit den genannten Operationen beantwortbar sind.

Literatur:
Steiner R.: Theorie und Praxis relationaler Datenbanken. Vieweg Verlagsgesellschaft: 2000 Auflage. ISBN: 3528354275.

© Prof. Dr. Hans Jürgen Ott --> home
43rdmzugrel.htm

Relationenorientierte Zugriffsoperationen im RDM

Im Relationalen Datenmodell sind drei grundlegende Relationenoperationen möglich, die bei SQL alle in den Optionen des SELECT-Befehls implementiert sind, d.h. alle drei Operationen benutzen denselben Befehl, allerdings mit unterschiedlichen Optionen.

Projektion

Diese Operation wählt bestimmte Spalten aus einer Tabelle bzw. Attribute einer Relation aus:

Bei der Projektion auf Nichtschlüsselattribute kann nun wie hier das Problem auftreten, dass in der Ergebnisrelation identische Tupel enthalten sind (was den mengenalgebraischen Grundlagen des RDM widerspricht). Diesem Problem kann man in SQL mit der Option DISTINCT entgehen:

Selektion

Diese Operation wählt bestimmte Zeilen aus einer Tabelle bzw. Tupel einer Relation entsprechend einer Auswahlbedingung (WHERE) aus, die sich auf Attributausprägungen bezieht:

Bei einer Equi-Selektion, d.h. einer Selektion, bei der die Auswahlbedingung eine Gleichheit in Attributwerten erfordert, tritt das Problem auf, dass in den Auswahlattributen die Tupel identische Ausprägungen enthalten. Diesem Problem kann man in SQL dadurch entgehen, dass man die Selektion mit einer Projektion verbindet und nur die Attribute in die Ergebnisrelation übernimmt, die nicht in der Auswahlbedingung enthalten sind:

Join

Diese Operation verknüpft Relationen mengenorientiert, d.h. jedes Tupel der einen Relation wird mit jedem Tupel der anderen Relation kombiniert, die Ergebnisrelation enthält alle Attribute der Ausgangsrelationen:

Man erhält entsprechend:

Es existieren verschiedene Join-Varianten, die jeweils unterschiedliche Ergebnisse liefern und - je nach Implementation von SQL - unterschiedliche Syntax erfordern.

Kontrollaufgabe:
Finden Sie Fragestellungen im Sportvereins-Beispiel, die mit den genannten Operationen beantwortbar sind.

Literatur:
Steiner R.: Theorie und Praxis relationaler Datenbanken. Vieweg Verlagsgesellschaft: 2000 Auflage. ISBN: 3528354275.

© Prof. Dr. Hans Jürgen Ott --> home
43rdmzugjoin.htm

Join-Varianten im Relationalen Datenmodell

Es existieren verschiedene Join-Varianten, die jeweils unterschiedliche Ergebnisse liefern. Wenn man eine Abfrage für ein bestimmtes Datenbanksystem formuliert, sollte man sich vergewissern, welche Join-Variante implementiert ist bzw. welche Optionen beim SELECT-Befehl angegeben werden müssen, um das gewünschte Ergebnis zu erhalten.

Cross Join

Diese Operation erstellt das Kreuzprodukt der Relationen, d.h. kombiniert jedes Tupel der einen Relation mit jedem Tupel der anderen Relation. Man erhält entsprechend:

 

Theta Join

Diese Operation kombiniert einen Cross-Join mit einer Selektion, d.h. es muss eine Auswahlbedingung angegeben werden, die als Theta-Bedingung bezeichnet wird. Man erhält entsprechend:

 

Equi Join

Diese Operation stellt einen Theta-Join dar, wobei die Auswahlbedingung eine Gleichheit von Attributwerten zweier Attribute fordert; meist stammt ein Attribut von der einen und das zweite Attribut von der anderen Ausgangsrelation. Man verknüpft also über gleiche Spaltenwerte und erhält entsprechend:

 

Natural Join

Diese Operation stellt einen Equi-Join dar, wobei eines der Attribute der Auswahlbedingung entfernt wird, d.h. man kombiniert den Join mit einer Projektion . Man erhält entsprechend:

 

Self Join

Beim Self Join wird eine Relation mit sich selbst verknüpft. Im folgenden Beispiel will man wissen: Wie heißen die Vorgesetzen der einzelnen Angestellten? Man denkt sich dabei zunächst zwei mit der Ausgangsrelation PERSONAL identische Relationen VORGES und UNTERG und verknüpft diese dann so, dass die Werte im Attribut VORGES.AngNr identisch mit den Werten UNTERG.Vorges in sind. In der folgenden SQL-Anweisung wird mit Alias-Namen gearbeitet; UNTERG sowie VORGES sollen die Tabelle PERSONAL bezeichnen, U soll das Attribut UNTERG.Name, also letztlich das Attribut Name der Tabelle PERSONAL bezeichnen.
Self Join

 

Union Join

Beim Union Join werden die Tupel der beiden Ausgangs-Relationen untereinandergesetzt; es bleiben die entsprechenden Tupelwerte der jeweils zur anderen Relation gehörenden Attribute leer (bzw. erhalten den NULL-Wert).

Kontrollaufgabe:
Finden Sie Fragestellungen, die mit den genannten Operationen beantwortbar sind.

Literatur:
Steiner R.: Theorie und Praxis relationaler Datenbanken. Vieweg Verlagsgesellschaft: 2000 Auflage. ISBN: 3528354275.

© Prof. Dr. Hans Jürgen Ott --> home
43rdmzugjoinerg.htm

Mögliche Ergebnisrelationen beim Natural Join

Je nachdem, ob die Join-Attribute Schlüsseleigenschaft besitzen, erhält man unterschiedliche Strukturen von Ergebnisrelationen. Man kann am Beispiel des Natural Join folgende Fälle unterscheiden:

Join-Attribute sind Schlüssel; die beiden Spalten enthalten identische Werte

In diesem Fall werden die Relationen spaltenweise nebeneinandergesetzt. Man erhält dementsprechend im Beispiel (wobei hier Alias-Namen in der Join-Spezifikation verwendet werden, um einerseits gleichnamige Attribute in den Ausgangsrelationen unterscheiden zu können und andererseits die langen Relationennamen nicht jeweils ausschreiben will; D stellt beispielsweise den Alias-Namen von DOZENTEN dar):

 

Join-Attribute sind Schlüssel; die beiden Spalten enthalten unterschiedliche Werte

In diesem Fall muß in der Join-Anweisung angegeben werden, welche Ausgangsrelation "Vorrang" hat, d.h. von welcher Relation alle Informationen in die Ergebnisrelation übernommen werden. Man sollte sich dazu über Voreinstellung beim jeweils benutzten DBMS vergewissern; diese ist meist INNER JOIN. Man erhält - je nach Join-Option - folgende Ergebnisse:

 

Join-Attribute sind keine Schlüssel

In diesem Fall muß man wie beim Cross Join die Tupel kombinieren und in der SELECT-Anweisung jeweils angeben, welche Attribute die Ausgangsrelation haben soll:

Kontrollaufgabe:
Finden Sie Fragestellungen, die mit den genannten Operationen beantwortbar sind.

Literatur:
Steiner R.: Theorie und Praxis relationaler Datenbanken. Vieweg Verlagsgesellschaft: 2000 Auflage. ISBN: 3528354275.

© Prof. Dr. Hans Jürgen Ott --> home
43rdmzugtech.htm

Zugriffstechniken in Relationalen Datenbanksystemen

Man kann auf relationale Datenbanken wie folgt zugreifen:

Kontrollaufgabe:
Stellen Sie die Vor- und Nachteile der verschiedenen Zugriffsverfahren einander gegenüber.

Literatur:
Steiner R.: Theorie und Praxis relationaler Datenbanken. Vieweg Verlagsgesellschaft: 2000 Auflage. ISBN: 3528354275.
Kline K. et.al.: SQL in a Nutshell . O'Reilly: 2005. ISBN: 3897213400.

© Prof. Dr. Hans Jürgen Ott --> home
32normform.htm

Normalisierung von Relationen

Die Normalisierung stellt eine Möglichkeit dar, zu einem redundanzfreien und damit konsistenzfördernden Datenbankdesign zu kommen. Zur Motivation soll folgender - in der Praxis üblicher - Fall dienen:

Die Personalabteilung eines Unternehmens betreibt ein hierarchisches Datenbanksystem, das Auskunft über die für die Produktion wichtigsten Personaldaten gibt. Folgendes Datenmodell sei implementiert:

Ein Datensatz in dieser hierarchischen Personaldatenbank hat dann typischerweise folgendes Aussehen:

In der Praxis geht man nun oft so vor, daß man eine solche Datenstruktur mehr oder weniger direkt in ein Relationenschema überführt; im Beispiel könnte die Relation wie folgt aussehen:

Ein derartiger Aufbau der Tabelle kann zu folgenden Integritätsgefährdungen führen:

a) insert anomaly
Es können inkonsistente Daten eingetragen werden:

  1. zwei Produkten werden drei Produktnamen zugeordnet,
  2. die Abteilung 1 heißt nicht EDV,
  3. das Produkt X gibt es nicht.

Das Datenbankmanagementsystem (DBMS) kann von sich aus nur die Eindeutigkeit des Schlüssels automatisch prüfen, nicht jedoch die Sinnhaftigkeit der Einträge. Dieser Datensatz wird also vom DBMS akzeptiert, da die Werte im Primärschlüssel-Attribut PE# eindeutig bleiben.

b) update anomaly
Die Tabelle enthält viele redundante Daten. Eine Änderung des Abteilungsnamens (Technik statt Physik) führt dazu, daß in allen Datensätzen, die die Abteilungsbezeichnung Physik enthalten, diese Angabe geändert werden muß.

c) deletion anomaly
Ein nicht mehr produziertes Produkt verschwindet aus der Datenbank. Produktinformationen sind nur enthalten, wenn dieses Produkt von einer Person produziert wird. Auch wenn das Produkt im Lager noch vorhanden sein sollte, kann es in der Datenbank nicht mehr gefunden werden.

Es ergibt sich nun die Frage, ob ein Datenbankdesign so erstellt werden kann, daß diese Anomalien nicht mehr auftreten können. Ein Relationenschema, das Anomalien solcher Art vermeidet, befindet sich in Normalform. Der Vorgang, dieses zu erreichen, wird als Normalisierung bezeichnet, also der Vorgang, von einem unnormalisierten über die 1. Normalform (1NF), die 2NF, die 3NF, die BCNF bzw. die 4NF zu einem normalisierten Relationenschema zu gelangen.

Die Normalisierung von Relationen fördert die Integrität dadurch, daß bestimmte Anomalien nicht mehr möglich sind. Dies wird allerdings mit zwei unter Umständen wesentlichen Nachteilen erkauft:

Diese Nachteile haben dazu geführt, dass man sich Gedanken über neue Datenmodelle machte, die es erlauben, Vorteile normalisierter Relationen zu nutzen, ihre Nachteile jedoch zu vermeiden.

Kontrollfrage:
Ein Unternehmen verwaltet seine Produktdaten mit einem hierarchischen Datenbanksystem; das Unternehmen möchte auf ein relationales System migrieren und dort seine Datenstruktur 1:1 aus der hierarchischen Datenbank übernehmen. Bringen Sie dieses Ausgangs-Modell in 3NF. Die hierarchische Datenstruktur ist folgende:

Literatur:
Spielberger J.: Datenmodellierung und relationale Datenbanktechnik. Skript Verlag Kühnel 2001. ISBN: 3907857038.

© Prof. Dr. Hans Jürgen Ott --> home
321nf.htm

1. Normalform (1NF): Atomarisierung

Definition 1NF:
Eine Relation befindet sich in 1. Normalform (1NF), wenn die Werte in allen Attributen atomar sind, d.h. sich sinnvoll nicht weiter zerlegen lassen.

Im Eingangs-Beispiel sind die Werte in den Attributen PR#, PR-Name und Zeit nicht atomar. In einer 1NF-Relation ist
die Anomalie a)1. (eintragen von 2 Teilwerten in PR# und 3 Teilwerten in PR-Name) nicht mehr möglich. Man erlangt dadurch weitere semantische Vorteile, indem man beispielsweise PR# nun - zutreffend - als Zahl vereinbaren kann und nicht mehr als Text vereinbaren muß.

Um eine Relation in 1NF zu bringen, muß man unterscheiden, worauf die Wertezusammenfassung beruht:

Die obige Tabelle würde in 1NF wie folgt aussehen; PR# wird dabei zusätzliches Schlüsselattribut:

Hierbei ergeben sich allerdings zwei Probleme:

  1. Die Redundanz wird erhöht; damit steigt die Gefahr der Inkonsistenz, d.h. insbesondere der Anomalie a) 2.
  2. Nicht beseitigte Anomalien: Folgender Datensatz wird weiterhin vom DBMS akzeptiert, da der Schlüssel <104,12> noch nicht existiert:

Die Ursache dieses Problems liegt in nicht berücksichtigten gegenseitigen funktionalen Abhängigkeiten der Attribute; ein Attribut (oder eine Menge von Attributen) Y ist von einem Attribut (oder einer Menge von Attributen) X dann funktional abhängig, wenn bei 2 Entities, die in den Ausprägungen von X übereinstimmen, die Entities auch in den Ausprägungen von Y übereinstimmen müssen. X wird Determinante genannt, Y die Abhängige; meist bildet die Determinante den Schlüssel. In unserem Fall ergeben sich folgende Abhängigkeiten:

Die Daten sind konsistent nur zu halten, wenn Nichtschlüsselattribute (z.B. Name) und Schlüsselattribute (z.B. PE#) in einer Tabelle gegenseitig voneinander funktional abhängig sind. Konsistenzprobleme der beschriebenen Art treten immer dann auf, wenn Nichtschlüsselattribute von anderen Nichtschlüsselattributen bzw. von Attributen abhängen, die zwar dem Schlüssel angehören, ihn jedoch nicht alleine bilden.

Die Attribute der obigen Tabelle sind durch folgende funktionale Abhängigkeiten gekennzeichnet:

A-Name stellt dabei einen Sonderfall dar. Dieses Attribut ist primär von A# abhängig, aber über A# auch noch von PE#. Derartige Abhängigkeiten werden als transitive Abhängigkeiten bezeichnet. Die weiteren Normalformen sind so definiert, daß nur funktional abhängige Attribute in einer Relation vorkommen.

Kontrollaufgabe:
Ist das Relationenschema aus der Musterlösung für die BA-Bibliothek in 1. Normalform? Wenn nein: Bringen Sie dieses Relationenschema in 1NF.

Literatur:
Spielberger J.: Datenmodellierung und relationale Datenbanktechnik. Skript Verlag Kühnel 2001. ISBN: 3907857038.

© Prof. Dr. Hans Jürgen Ott --> home
322nf.htm

2. Normalform (2NF): Funktionale Abhängigkeiten vom ganzen Schlüssel

Definition 2NF:
Eine Relation befindet sich in 2NF, wenn sie in 1NF ist und jedes Nichtschlüsselattribut nur vom ganzen Schlüssel funktional abhängig ist (und nicht nur von Schlüsselteilen).

Aus der Abhängigkeitsgrafik bei der 1NF sieht man, daß nur Zeit vom ganzen Schlüssel <PE#, PR#> abhängig ist; die restlichen Attribute sind nur von einem Teil des Schlüssels abhängig.

Um eine 1NF- in eine 2NF-Relation zu bringen, muß man die Tabelle teilen, d.h. aus einer Tabelle mehrere Tabellen machen. Man erhält folgende Tabellen:

  • Eine Tabelle, die alle Schlüsselattribute und nur die davon funktional abhängigen Nichtschlüsselattribute enthält.
  • Eine Tabelle für jedes einzelne Schlüsselattribut, die das Schlüsselattribut und nur die davon funktional abhängigen Nichtschlüsselattribute enthält.
  • Bei mehr als zwei Schlüsselattributen eine Tabelle für jede Schlüsselattribut-Kombination, die die Schlüsselattributkombination und nur die davon funktional abhängigen Nichtschlüsselattribute enthält.
 

Auch hier sind noch nicht alle Anomalien beseitigt. Folgender Datensatz kann noch in die Tabelle Person eingetragen werden:

Kontrollaufgabe:
Ist das Relationenschema aus der Aufgabe zur 1NF in 2. Normalform? Wenn nein: Bringen Sie dieses Relationenschema in 2NF.

Literatur:
Spielberger J.: Datenmodellierung und relationale Datenbanktechnik. Skript Verlag Kühnel 2001. ISBN: 3907857038.

© Prof. Dr. Hans Jürgen Ott --> home
323nf.htm

3. Normalform (2NF): Funktionale Abhängigkeiten nur vom Schlüssel

Definition 3NF:
Eine Relation befindet sich in 3NF, wenn sie in 2NF ist und jedes Attribut nur vom Primärschlüssel funktional abhängig ist, d.h. es existieren keine transitiven Abhängigkeiten.

Um eine 2NF- in eine 3NF-Relation zu bringen, muß man die Tabelle nochmals teilen. In obigem Beispiel trifft dies nur für die Relation PERSON zu; alle anderen Relationen sind bereits in 3NF. Man erhält folgende Tabellen:

  • Eine Tabelle, die den Primärschlüssel und nur die davon funktional abhängigen Nichtschlüsselattribute enthält.
  • Eine Tabelle für jedes einzelne Attribut, von dem andere Attribute funktional abhängig sind; die Tabelle enthält dieses Attribut als Primärschlüssel sowie die davon abhängigen Nichtschlüsselattribute.
  • Eine Tabelle für jede Attributkombination, von der andere Attribute funktional abhängig sind; die Tabelle enthält diese Attributkombination als Primärschlüssel sowie die davon abhängigen Nichtschlüsselattribute.
 

Man erhält somit das folgende Relationenschema in 3NF, das die Anomalien der Ausgangstabelle nicht mehr enthält; durch Join-Operationen kann man sich die Ausgangstabelle wieder erstellen und erhält damit auf jeden Fall eine integre Tabelle (sofern die Daten der vier dargestellten Relationen korrekt sind).

In der betrieblichen Praxis begnügt man sich im allgemeinen mit 3NF-Relationen. Es werden in der Datenbankliteratur jedoch noch weitere Normalformen diskutiert, die weitere - zwar nicht so häufig vorkommende, jedoch ebenfalls integritätsgefährdende - Anomalien beseitigen.

Kontrollaufgabe:
Ist das Relationenschema aus der Aufgabe zur 2NF in 3. Normalform? Wenn nein: Bringen Sie dieses Relationenschema in 3NF.

Literatur:
Spielberger J.: Datenmodellierung und relationale Datenbanktechnik. Skript Verlag Kühnel 2001. ISBN: 3907857038.

© Prof. Dr. Hans Jürgen Ott --> home
32bcnf.htm

Boyce-Codd-Normalform (BCNF): Keine weiteren Schlüsselkandidaten.

Boyce-Codd Normal Form Boyce-Codd Normal Form (BCNF) is an extension of 3NF in the case with two or more candidate keys which are composite and overlapping (that is, they have at least one field in common). If these conditions are not fulfilled, 3NF and BCNF are equivalent. A table is BCNF if, and only if its only determinants are candidate keys. In the following table, both {SupplierID, PartID}, as well as {SupplierName, PartID}, are candidate keys. The table is not BCNF since it contains two determinants (SupplierID and SupplierName) which are not candidate keys. (SupplierID and SupplierName are determinants, since they determine each other.) { SupplierID, PartID, SupplierName, Quantity } However, either of the following decompositions is BCNF: { SupplierID, SupplierName } { SupplierID, PartID, Quantity } or { SupplierName, SupplierID } { SupplierName, PartID, Quantity } To achieve BCNF, remove the determinants which are not candidate keys.

Manchmal tritt der Fall auf, dass man in einer Relation mehrere Schlüsselkandidaten hat und diese sich überlappen, d.h.es existieren Sekundärschlüssel bzw. mehrere Attribute oder Attributkombinationen eignen sich als Schlüssel und identifizieren mit ihren Feldwerten Datensätze eindeutig. Die 3NF fordert nur, daß Nichtschlüsselattribute vom Primärschlüssel funktional abhängig sind; dessen Eindeutigkeit wird vom DBMS automatisch geprüft. Nicht jedoch automatisch geprüft werden kann die Eindeutigkeit der anderen Schlüsselkandidaten, also der Sekundärschlüssel.

Wenn in einer 3NF-Relation mehrere Schlüsselkandidaten existieren, hängen die restlichen Attribute ja von allen diesen Schlüsselkandidaten funktional ab. Wenn man nun einen Schlüsselkandidat als Primärschlüssel auszeichnet, dann konstruiert man im Prinzip transitive Abhängigkeiten {Primärschlüssel} <==> {Sekundärschlüssel} <==> {Nichtschlüsselattribute} und erhält einen ähnlichen Problemfall wie der, der durch die 3NF beseitigt wird. Man definiert daher die Boyce-Codd-Normalform (BCNF) als Erweiterung der 3NF wie folgt:

Definition BCNF:
Eine Relation befindet sich in BCNF, wenn sie in 3NF ist und keine transitiven Abhängigkeiten zwischen Schlüsselkandidaten existieren.

Als Beispiel soll folgende Relation LIEFERUNGEN dienen; angenommen wird, dass LieferantName eindeutig sei, d.h. es gibt keine 2 Lieferanten mit demselben Namen:

LieferantID TeileID LieferantName Menge

Schlüsselkandidaten wären hierbei (LieferantID,TeileID) und (LieferantName, TeileID), wobei jedoch LieferantName funktional von LieferantID abhängt. Es ist nun durch das DBMS (aufgrund der Schlüsseleigenschaft) nicht verhinderbar, dass folgende Datensätze in diese Relation eingetragen werden:

LieferantID TeileID LieferantName Menge
0815 4711 Maier 20
0815 4711 Müller 30

Es gibt dann 2 Lieferanten mit unterschiedlichen Namen und gleichzeitig 2 Entities mit "eigentlich" demselben Schlüssel (0815,4711), was durch das DBMS ausgeschlossen werden sollte. Um nun eine 3NF-Relation in eine BCNF-Relation zu transformieren, muß man diese transitiven Abhängigkeiten beseitigen. Dazu bildet man zwei Tabellen:

LieferantID LieferantName
LieferantID TeileID Menge

Kontrollaufgabe:
Ist das Relationenschema aus der Aufgabe zur 3NF in BCNF? Wenn nein: Bringen Sie dieses Relationenschema in BCNF.

Literatur:
Spielberger J.: Datenmodellierung und relationale Datenbanktechnik. Skript Verlag Kühnel 2001. ISBN: 3907857038.

© Prof. Dr. Hans Jürgen Ott --> home
324nf.htm

4. Normalform (4NF): Keine mehrwertigen Abhängigkeiten

Angenommen, in einem Bibliotheksdatenbanksystem sollen Bücher u.a. mit ihrer Signatur, ihren Autoren und einer Menge von Stichworten beschrieben werden. Man könnte dann beispielsweise folgende unnormalisierte Relation definieren:

Daraus könnte man folgende 3NF-Relation bilden; um Eindeutigkeit der Tupel zu gewährleisten, muss man alle Attribute zu Schlüssselattributen machen:

Diese Relation ist durch eine spezielle Form der Redundanz gekennzeichnet: Jedem Wert in einem Schlüssel-Attribut sind Werte in den jeweils anderen Schlüsselattributen mehrfach zugeordnet. Dieser Fall tritt häufig auf, wenn eine Relation mehr als zwei Schlüsselattribute besitzt; man spricht in diesem Fall von mehrwertigen Abhängigkeiten. Diese treten in 4NF-Relationen nicht auf.

Definition 4NF:
Eine Relation befindet sich in 4NF, wenn sie in 3NF ist und keine mehrwertigen Abhängigkeiten existieren.

Im vorliegenden Fall würde man aus der einen Relation zwei Relationen machen, die nur jeweils zwei Schlüsselattribute besitzen:

Kontrollaufgabe:
Ist das Relationenschema aus der Musterlösung für einen Sportverein in 4. Normalform? Wenn nein: Bringen Sie dieses Relationenschema in 4NF.

Literatur:
Spielberger J.: Datenmodellierung und relationale Datenbanktechnik. Skript Verlag Kühnel 2001. ISBN: 3907857038.

© Prof. Dr. Hans Jürgen Ott --> home
43rdmtuning.htm

Datenbank-Tuning bei Relationalen Datenbanksystemen

Nachteil, jedoch zugleich Vorteil von Hierarchischen Datenbanken und Netzwerkdatenbanken ist, dass Zugriffsstrukturen Grundlage der Modellierung des Datenbankschemas sind. Zwar ist die Flexibilität bei Zugriffen damit sehr eingeschränkt; diese Datenmodelle können jedoch gezielt im Hinblick auf tatsächlich existierende Zugriffsstrukturen hin optimiert werden, so dass man eine sehr gute Zugriffsperformance erhält, auf die hin man die Navigationsalgorithmen gut abstimmen kann.

Bei Relationalen Datenbanksystemen dagegen sind die Zugriffsalgorithmen Teil des DBMS; Zugriffsstrukturen spielen bei der Modellierung keine Rolle, sondern ausschliesslich Daten realer Informationsobjekte sowie logische Zusammenhänge zwischen Daten. Dadurch kann naturgemäss das Datenbankschema auf die Zugriffsanforderungen nicht so gut abgestimmt werden. Dadurch wiederum erreichen Relationale Datenbanksysteme bei vergleichbarer Systeminfrastruktur nicht die Performance wie Hierarchische Datenbanksysteme.

Um die Flexibilität und Einfachheit in Modellierung und Zugriff zu bewahren und dennoch eine gute Zugriffsperformance des Datenbanksystems zu gewährleisten, hat man eine Reihe von Möglichkeiten des Datenbanktunings; einige Beispiele dafür sind:

Zur Unterstützung des Datenbankadministrators, des Anwenders bzw. des Systemprogrammierers bieten sich Performance Monitore an (beispielsweise OMEGAMON von der Firma !Candle).

Kontrollaufgabe:
Analysieren Sie den Performance Monitor OMEGAMON für DB2: Welche Funktionen sind enthalten? Welche Performance-Probleme können damit aufgedeckt/beseitigt werden?

Literatur:
Steiner R.: Theorie und Praxis relationaler Datenbanken. Vieweg Verlagsgesellschaft: 2000 Auflage. ISBN: 3528354275.

© Prof. Dr. Hans Jürgen Ott --> home
45dbneu.htm

Neuere Datenmodell-Konzepte

Das Relationale Datenmodell bietet zwar gegenüber älteren Datenmodellen ein großes Maß an Flexibilität und ist einfacher in der Modellierung und in der Anwendung. Dennoch haben sich in den 30 Jahren seit der Veröffentlichung des Modells durch Chen die Rahmenbedingungen für Datenbanken (Anforderungern seitens der Anwender, der Anwendungsprogramme und der zu verwaltenden Daten) geändert, was schließlich zur Entwicklung neuer Datenmodelle geführt hat. Die bekanntesten dieser Ansätze sind:

  1. Komplexe Datentypen: Die eingeschränkten Möglichkeiten hinsichtlich der Datentypen werden erweitert.
  2. Deduktive Datenbanken erzeugen selbständig aus vorhandenen Daten neue Daten.
  3. Die Einbeziehung von Anwendungslogik in das Datenmodell führt zu aktiven Datenbanken, abstrakten Datentypen und objektorientierten Datenbanksystemen.
  4. OLAP-Systeme erlauben die Modellierung sehr umfangreicher Datenbanken.
  5. XML- bzw. Hypermedia-Systeme tragen insbesondere den Anforderungen des Internets Rechnung.

Kontrollaufgabe:
Stellen Sie charakteristische Unterschied der genannten Datenmodellkonzepte in einer Tabelle einander gegenüber.

Literatur:
Apers P.M.G., Blanken H.M., Houtsma M.A.W. (Eds.): Multimedia Databases in Perspective. Berlin: Springer 1998. ISBN: 3540761098.
Cremers A. B., Griefahn U., Hinze R.: Deduktive Datenbanken. Wiesbaden: Vieweg 1994. ISBN: 3528047003.
Kazakos W., Schmidt A., Tomczyk P.: Datenbanken und XML. Konzepte, Anwendungen, Systeme. Heidelberg/Berlin: Springer 2002. ISBN: 354041956X.
Meier A., Wüst T.: Objektorientierte und objektrelationale Datenbanken. Ein Kompass für die Praxis. 2. Aufl. Heidelberg: dpunkt-Verlag 2000. ISBN: 3932588681.
Oehler K.: OLAP - Grundlagen, Modellierung und betriebswirtschaftliche Lösungen. München: Carl Hanser Verlag 2000. ISBN: 3446213090.
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
45kompdatyp.htm

Attribute mit komplexen Datentypen

Eine Entwicklungsrichtung neuer Datenmodelle ging dahin, die verfügbaren Datentypen zur Beschreibung von Attribut-Domains zu erweitern. Hier sind zwei Ansätze zu nennen:

NF2-Modelle

Bei relationalen Datenbanken wird aufgrund der mengenorientierten Sichtweise von Tabellen als Relationen vorausgesetzt, dass jedes Tupel in jedem Attribut genau eine, d.h. mindestens eine und höchstens eine Ausprägung besitzt. Die Forderung nach höchstens einer Ausprägung bedeutet, dass die Datentypen atomar sein sollen, d.h. sinnvoll nicht weiter zerlegt werden können. Man bezeichnet Tabellen, die diese Eigenschaft aufweisen, als Tabellen in 1. Normalform.

Diese Forderung kann bei einem umfangreichen und komplexen Unternehmensmodell zu einem sehr unleserlichen und wenig strukturierten Datenmodell führen. Man hat grosse Schwierigkeiten, beispielsweise ein Strukturiertes ER-Modell in ein Relationenschema zu überführen, ohne dass diese Strukturierungsmöglichkeiten verloren gehen. Man hat nun versucht, diesem Problem dadurch zu entgehen, dass man Datentypen zulässt, die ihrerseits wieder eine komplexere Struktur beinhalten. Damit geht man weg von der Normalform-Forderung was sich in der Bezeichnung dieser Datenmodelle (Non First Normal Form ==> NFNF ==> NF2) ausdrückt.

Diese Modelle bieten

Diese Datentypen müssen nur auf der logischen Ebene, d.h. der Ebene der Anwendersicht, strukturiert sein; sie können durchaus als "flache" Relationen auf einem konventionellen relationalen Datenbanksystem implementiert sein, wie folgendes Beispiel zeigen soll:

Multimedia-Datenmodelle

Datenmodelle, auf die multimedialen Anwendungen zugreifen, müssen Datentypen wie Audio-, Video- und Grafikobjekte verwalten können.

Dies sind meist sehr umfangreiche Objekte, die keine interne Strukturierung durch Anwendungsprogramme erlauben. Sie werden deshalb in Datenbanken als Binary Large Objects (BLOBs) gespeichert und durch den Anwender zu Kategorien zugeordnet; anhand dieser Kategorien können diese Objekte wieder gefunden werden.

Kontrollaufgabe:
Formulieren Sie einen kleinen Ausschnitt aus dem Unternehmensmodell BA-Bibliothek mit Hilfe des NF2-Modells.

Literatur:
Apers P.M.G., Blanken H.M., Houtsma M.A.W. (Eds.): Multimedia Databases in Perspective. Berlin: Springer 1998. ISBN: 3540761098.

© Prof. Dr. Hans Jürgen Ott --> home
45anwlogik.htm

Deduktive Datenbanken

Deduktive Datenbanken leiten mit Hilfe von Regeln aus vorhandenen Daten neue Daten ab. Dies kann zur Laufzeit erfolgen (die neuen Daten werden bei einer Anfrage dynamisch erzeugt) oder persistent, d.h. beim Eintragen neuer Daten oder Regeln durch den Anwender wird geprüft, ob sich aus der neuen Situation weitere Daten ableiten lassen oder Daten aufgrund der neuen Situation angepasst werden müssen; diese Daten werden dann in die Datenbank eingetragen bzw. geändert.

Demzufolge kann man folgende Regelarten unterscheiden, wobei zur Veranschaulichung eine Relation bzw. Tabelle PAPA mit den Attributen (Name, KindName, Geburtsdatum) angenommen werden soll:

Kontrollaufgabe:
Formulieren Sie einen kleinen Ausschnitt aus dem Unternehmensmodell BA-Bibliothek mit Hilfe von Bildungs- und Integritätsregeln.

Literatur:
Cremers A. B., Griefahn U., Hinze R.: Deduktive Datenbanken. Wiesbaden: Vieweg 1994. ISBN: 3528047003.

© Prof. Dr. Hans Jürgen Ott --> home
45anwlogik.htm

Anwendungslogik in Datenbanken

Die bisherigen Datenmodelle gingen immer davon aus, dass nur Daten, d.h. Beschreibungen aktueller oder vergangener Zustände des Unternehmensmodells gespeichert und verwaltet werden. Bereits jedoch bei deduktiven Datenbanken stellen Regeln eigentlich Verfahren bzw. Methoden zur dynamischen Erzeugung von Daten dar. Wie bereits bei der Evolution von Informationssystemen gezeigt, kann es zur Vermeidung von Programmredundanz sowie zur Konsistenzsicherung innerhalb der Programmierung sinnvoll sein, weitergehende Anwendungslogik bzw. Programmcode ebenfalls in einer Datenbank abzulegen. Dieser Code kann einfach wiederverwendet und effizient verwaltet werden.

Man kann folgende Stufen der Einbeziehung von Anwendungslogik in die Datenbank unterscheiden:

  1. Aktive Datenbanken
    Diese Datenbanksysteme erlauben die Definition von Triggern bzw. Stored Procedures. Dies sind Programme bzw. Funktionen, die selbständig bestimmte Datenbankprozesse bzw. Datenbankaktionen auslösen, wenn bestimmte Ereignisse eintreten (z.B. Daten eingetragen werden, ein bestimmtes Datum erreicht ist etc.). Ein Beispiel dafür stellt die Formulierung von Triggern in SQL3 dar; im folgenden Beispiel verhindert ein Trigger, dass Gehaltserhöhungen in einer Tabelle EMPLOYEE größer ausfallen als 20%:
    CREATE TRIGGER Increase
          BEFORE UPDATE OF Salary ON EMPLOYEE
          REFERENCING OLD AS Oldrow NEW AS Newrow
          FOR EACH ROW
          WHEN (Newrow.Salary > Oldrow.Salary * 1.2)
          SET Newrow.Salary = Oldrow.Salary * 1.2;


  2. Attribute mit abstrakten Datentypen (ADT)
    Abstrakte Datentypen bestehen aus (komplexen) Datentypen sowie einer Spezifikation von erlaubten Operationen auf dem Datentyp, die über bisher bereits übliche arithmetische (z.B. Count) oder logische (z.B. ">") Operationen hinausgehen. Die Daten und die darauf anwendbaren Operationen werden gekapselt, d.h.


    Im folgenden Beispiel zur Modellierung eines Ersatzteil-Lagers wird ein ADT keller verwendet. Dieser Datentyp besteht aus einem Namen (Ia4) sowie der Definition von erlaubten Operationen; diese Operationen sollen bewirken, dass


    Die Abfrage
    SELECT Name FROM ERSATZTEIL WHERE Lager= Ia4;
    enthält als Ergebnis lediglich das Teil 4711; dieses "liegt oben".

    Bei abstrakten Datentypen ist man mit folgendem Problem konfrontiert: Wenn ein weiterer Datentyp keller2 definiert werden soll, der die beiden ersten Teile in einem Lager anzeigen soll, so muss man in diesem Datentyp alle Methoden neu definieren, obwohl die Methoden PUSH, POP und EMPTY identisch sind. Dies wiederum führt zu Programmredundanz. Abhilfe schafft hier die nächste Stufe von Datenbanken.

  3. Objektorientierte Datenbanksysteme (OODBS)
    Hier können neben Abstrakten Datentypen auch Klassenhierarchien verwaltet werden. Klassenhierarchien bewirken, dass Daten oder Methoden, die für eine Objektklasse definiert wurden, auf eine andere Klassen vererbt werden können.

Durch diese Datenmodelle verlagert man sukzessive die Anwendungslogik in das Datenbanksystem:


Kontrollaufgabe:
Formulieren Sie Trigger für einen kleinen Ausschnitt aus dem Unternehmensmodell BA-Bibliothek.

Literatur:
Vossen, G.: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. München: Hanser 2000. ISBN: 3486253395.

© Prof. Dr. Hans Jürgen Ott --> home
45oodbs.htm

Objektorientierte Datenbanksysteme

Hier können neben Abstrakten Datentypen auch Klassenhierarchien in der Datenbank verwaltet werden. Dies bedeutet, dass in der Datenbank Daten sowie Methoden (Prozeduren, Funktionen, Applets, etc.) gemeinsam verwaltet werden. Klassenhierarchien bewirken, dass Daten oder Methoden, die für eine Objektklasse definiert wurden, auf eine andere Klasse vererbt werden können.

IBM bietet ein Tutorial an, um mit Hilfe der Modellierungsmethodik UML zu einem objektorientierten Datenbankdesign zu kommen.

Diese gemeinsame Verwaltung von Daten und Methoden in Objektorientierten Datenbanken bringt eine Reihe von Vorteilen:

Da die Unterscheidung von Objektorientierten und Konventionellen Datenbanksystemen manchmal schwer ist, wurden 1989 von Atkinson et al. (analog der 12 Codd'schen Regeln) im Bericht "The Objekt-oriented Database Manifesto" Kriterien formuliert, die ein Objektorientiertes Datenbankmanagementsystem auszeichnen. Die wichtigsten Kriterien, die speziell auf die Unterschiede zu konventionellen Datenbanksystemen abheben, sind:

Entsprechend der "Zwitterstellung" von Objektorientierten Datenbanksystemen zwischen konventionellen Datenbanksystemen und Programmierumgebungen können hinsichtlich ihrer Entstehung die inzwischen marktgängigen OO-Datenbanksmanagementsysteme in folgende Klassen eingeteilt werden:

Auf dem Weg ihrer Evolution von relationalen zu objektorientierten Datenbankmanagementsystemen haben einige marktgängige Systeme der zweitgenannten Klasse einen "Zwischenschritt" als objektrelationale Systeme gewählt. Ein Beispiel dafür stellt das Datenmodell von Informix dar; die dort verwendeten Data Blades sind im Prinzip Objekte, aber mit eingeschränkten Vererbungs- und Kapselungsmechanismen:


Kontrollaufgabe:
Formulieren Sie ein Objektorientiertes Modell für einen kleinen Ausschnitt aus dem Unternehmensmodell BA-Bibliothek.

Literatur:
Meier A., Wüst T.: Objektorientierte und objektrelationale Datenbanken. Ein Kompass für die Praxis. 2. Aufl. Heidelberg: dpunkt-Verlag 2000. ISBN: 3932588681.
M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier und S. Zdonik ``The object-oriented database system Manifesto'' Proceedings of the 1st International Conference on Deductive and Object-Oriented Databases, Kyoto, Seiten 40-57, 1989.

© Prof. Dr. Hans Jürgen Ott --> home
45olap.htm

OLAP-Modelle in Data Warehouses

OLAP-Systeme werden hauptsächlich in Data Warehouses verwendet. Dort hat man das Problem, dass eine Fülle von Daten vorliegt, die durch nicht standardisierte Methoden analysiert werden sollen (Data Mining). Die fehlende Standardisierung der Daten im Data Warehouse erfordert, dass der (analytische) Zugang zu diesen Daten so flexibel wie möglich sein soll; man weiß ja nicht, was der Nutzer will und in welcher Form er es will (Tabelle oder Hierarchie, Einzelwerte oder Summen, Zahlen oder Grafiken usw.). Um die Fülle an Daten dem Anwender so einfach wie möglich zugänglich zu machen, wurde das OLAP-Datenmodell entwickelt (Online Analytical Processing); dieses Modell strukturiert den Datenpool durch eine Reihe von Dimensionen, anhand derer der Anwender Daten finden, aggregieren und weiterverarbeiten kann. Man erhält so einen multidimensionalen Würfel (Hyperwürfel), in den man konkret vorkommende Datenwerte einfügt.

Im folgenden Beispiel soll der Datenpool eines Unternehmens durch die drei Dimensionen Produkte, Regionen und Quartale definiert sein. Die Daten, die in den durch diese Dimensionen aufgespannten Würfel eingefügt werden, sind Umsatzzahlen; das Einfügen funktioniert so, dass jedem Umsatzwert ein Wert in den Dimensionen zugeordnet wird. Jeder Anwender, der diesen Datenpool benutzt, hat eine spezielle Sicht auf die Daten, d.h. ihn betreffen jeweils nur wenige Dimensionen: Der Produktmanager interessiert sich beispielsweise nur für die Umsätze eines bestimmten Produkts in allen Gebieten und allen Quartalen, der Gebietsleiter für die Umsätze in einem bestimmten Gebiet in allen Produkten und allen Quartalen.

Realisiert wird dieses Datenmodell

Kontrollaufgabe:
Formulieren Sie für einen kleinen Ausschnitt aus dem Unternehmensmodell BA-Bibliothek ein OLAP-Schema.

Literatur:
Oehler K.: OLAP - Grundlagen, Modellierung und betriebswirtschaftliche Lösungen. München: Carl Hanser Verlag 2000. ISBN: 3446213090.

© Prof. Dr. Hans Jürgen Ott --> home
45xml.htm

Extensible Markup Language XML

Immer mehr Internet-Dokumente werden in XML codiert; die meisten Browser sind in der Lage, XML zu interpretieren. XML ist in der Anwendung flexibler als HTML: HTML hat eine feste Dokumentstruktur, die in den definierten Tags und im Format festgeschrieben ist (z.B. H1 für die Hauptüberschrift). XML erlaubt die Definition neuer Tags sowie die individuelle Zuordnung von Formaten. Auch die meisten neueren B2B-Datenübertragungsstandards benutzen die XML-Codierung. XML ist vom W3C-Konsortium, dem international anerkannten Standardisierungsgremium für Internet-Technologien, standardisiert. Ein ausfühliches Tutorial über XML findet man bei IBM.

XML (Extensible Markup Language) ist konzipiert als eine Sprache zur Erstellung bzw. Definition von Dokumenten, die über das Internet übertragen werden. Ein Dokument (z.B. eine Rechnung) besteht dabei aus

Struktur-, Format- und Inhaltsinformationen können, müssen dabei aber nicht in derselben Datei lokalisiert sein. Sie können auf verschiedene Dateien verteilt sein, aus deren Name-Extension man auf den jeweiligen Dateiinhalt schliessen kann:

In einer XML-Datei verweisen dabei Links auf die Strukturinformationen und die Formatierungsinformationen. Ein Beispiel zeigt den Zusammenhang zwischen Inhalts- Struktur- und Formatinformationen am Beispiel einer Liste von Büchern in einer Bibliothek.

XML ist ein sehr flexibles Konzept, um Dokumente darzustellen. Die Struktur eines Dokuments kann nicht nur mit Hilfe einer DTD definiert werden, sondern auch mit Hilfe von einer XSD-Datei (XML-Schema-Definition; eine Einführung in XML-Schema ist auf der Website des W3C erhältlich); das Ausgabeformat einer XML-Datei kann nicht nur mit Hilfe von XSL, sondern auch mit Hilfe von den schon aus HTML bekannten CSS (Cascading Style Sheets) definiert werden.

XML-Dokumente haben eine hierarchische Struktur. Derzeit marktführende Datenbanksysteme haben jedoch das Relationale Datenmodell implementiert; die Daten werden dort in der logischen Form einer nicht-hierarchischen Tabelle (flat files, flache Strukturen) modelliert. Für dieses Problem bieten sich prinzipiell 2 Lösungswege an:

Mittlerweile existieren auch Abfragesprachen für XML-Datenbanksysteme wie XSLT oder XQuery, die speziell auf das Information Retrieval in XML-Datenbanken abgestimmt sind.

Kontrollaufgabe:
Formulieren Sie einen kleinen Ausschnitt aus dem Unternehmensmodell BA-Bibliothek mit Hilfe von XML.

Literatur:
Kazakos W., Schmidt A., Tomczyk P.: Datenbanken und XML. Konzepte, Anwendungen, Systeme. Heidelberg/Berlin: Springer 2002. ISBN: 354041956X.
Kevin Williams, IBM: XML Structures for Existing Databases Eleven rules for moving a relational database to XML.
David Mertz: Putting XML in context with hierarchical, relational, and object-oriented models. http://www-106.ibm.com/developerworks/xml/library/x-matters8/index.html

© Prof. Dr. Hans Jürgen Ott --> home
Beispiel für XML-Dokumente

Beispiel für XML-Dokumente

Das folgende Beispiel zeigt den Zusammenhang zwischen Inhalts- Struktur- und Formatinformationen am Beispiel einer Liste von Büchern in einer Bibliothek, die wie folgt aussehen soll:

ISBN-Nummer Buchtitel
354041956X Datenbanken und XML
.... .....
3540668144 Open Internet Security

Die Daten, die diese Liste enthält, stammen aus folgender XML-Datei (bibliothek.xml); die Struktur der XML-Datei ist vorgegeben durch die DTD bibliothek.dtd:

XML-Datei bibliothek.xml

DTD-Datei bibliothek.dtd

<?XML version="1.0"?>
<?XML-stylesheet href="bibliothek.xls" type="text/xls" ?>
<!DOCTYPE bibliothek SYSTEM "bibliothek.dtd">
  <bibliothek>
    <buch>
      <isbn>354041956X</isbn>
      <titel>Datenbanken und XML</titel>
    </buch>
    .......
    <buch>
      <isbn>3540668144</isbn>
      <titel>Open Internet Security</titel>
    </buch>
    
  </bibliothek>
<!ELEMENT bibliothek (buch+)>
die Bibliotheksliste besteht aus mehreren Büchern

  <!ELEMENT buch (isbn, titel)>
  ein Buch besteht aus einer ISBN und einem Autor

    <!ELEMENT isbn (#CDATA)>
    <!ELEMENT titel (#CDATA)>
    
ISBN und Autor sind Text-Daten (Character Data)

Die XSL-Datei bibliothek.xsl, die aus dem obigen XML-Dokument die geforderte Liste hervorbringt, könnte wie folgt aussehen:

XSL-Datei bibliothek.xsl
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
  <html>
    <body>
      <table border="1">
        <tr bgcolor="#CCCCCC">
          <th>ISBN-Nummer</th>
          <th>Buchtitel</th>
        </tr>
        <xsl:for-each select="bibliothek/buch">
          <tr>
            <td><xsl:value-of select="isbn"/></td>
            <td><xsl:value-of select="titel"/></td>
          </tr>
        </xsl:for-each>
      </table>
    </body>
  </html>
</xsl:template>
</xsl:stylesheet>

Die Datenwerte (ISBN und Titel) im obigen Beispiel können nicht nur als Elemente, sondern als Attribute von Elementen dargestellt werden; man erhielte folgenden Dateiaufbau (ob Daten als Attribute oder als Elemente dargestellt werden sollen, kann nicht von vorherein klar entschieden werden; siehe http://www-106.ibm.com/developerworks/xml/library/x-eleatt.html?ca=dnt-59):

XML-Datei bibliothek1.dtd

DTD-Datei bibliothek1.dtd

<?XML version="1.0"?>
<?XML-stylesheet href="bibliothek1.xls" type="text/xls" ?>
<!DOCTYPE bibliothek SYSTEM "bibliothek1.dtd">
  <bibliothek>
    <buch
      isbn="354041956X"
      titel="Datenbanken und XML" />
    .......
    <buch
      isbn="3540668144"
      titel="Open Internet Security" />

  </bibliothek>
<!ELEMENT bibliothek (buch+)>
die Bibliotheksliste besteht aus mehreren Büchern

  <!ELEMENT buch EMPTY>
  ein Buch enthält keine weiteren Elemente

  <!ATTLIST buch
    isbn CDATA #REQUIRED
    titel CDATA #REQUIRED>
    
ISBN und Autor sind Attribute von buch

Kontrollaufgabe:
Welche Vorteile bietet die Attributdarstellung gegenüber der Element-Darstellung?

Literatur:
Kazakos W., Schmidt A., Tomczyk P.: Datenbanken und XML. Konzepte, Anwendungen, Systeme. Heidelberg/Berlin: Springer 2002. ISBN: 354041956X.

© Prof. Dr. Hans Jürgen Ott --> home
45xmler.htm

Ableitung von XML-Datenstrukturen aus dem ER-Modell

Derzeit tritt in der betrieblichen Praxis häufig der Fall auf, dass XML-Dokumente Daten enthalten, die in relationalen Datenbanken gespeichert sind. Man will Daten aus XML-Dateien in relationalen Datenbanken abspeichern oder man will aus den Datein in relationalen Datenbanken XML-Dateien generieren. Voraussetzung dafür ist ein Mapping der XML-Datenstruktur mit dem relationalen Datenbankschema.

Ein einfaches Mapping einer einzelnen Tabelle in ein XML-Dokument orientiert sich an der in HTML üblichen Tabellendefinition:

tablename col1 col2
  val11 val12
  val21 val22
  ... ...

<tablename>
  <row>
    <col1>val11</col1>
    <col2>val12</col2>
  </row>
  <row>
    <col1>val21</col1>
    <col2>val22</col2>
  </row>
  ...
</tablename>

Die Ableitung einer komplexeren Datenstruktur erfolgt am besten über das ER-Modell, das dem relationalen Datenbankschema zugrundeliegt. Aus diesem ER-Modell sind XML-Datenstrukturen (als DTD oder XML-Schema) abzuleiten.

Man geht dabei prinzipiell wie folgt vor:

  1. Modellierung von Entity-Typen: Aus einem Entity-Typ T wird ein Element E einer DTD, das in einem XML-Dokumentm mehrfach vorkommen kann. Ein Element in einem XML-Dokument entspricht also einem Entity, ein Element in einer DTD entspricht einem Entity-Typ.

  2. Modellierung von (1:1)- und (1:n)-Beziehungen: Aus dem Entity-Typ T1, der die "1-Seite" der Beziehung bildet, wird ein Element E1 einer DTD. Aus dem Entity-Typ TN, der die "n-Seite" der Beziehung bildet (bzw. bei (1:1)-Beziehungen der andere Entity-Typ), wird ein Unterelement EN von E1.

  3. Modellierung von (m:n)-Beziehungen: Bei (m:n)-Beziehungen werden die Entity-Typen TN und TM sowie der Beziehungstyp R als Elemente EN, EM und ER modelliert.

  4. Zusammenhängendes Beispiel: Am Beispiel einer Bibliothek wird die Ableitung einer XML-DTD aus einem ER-Modell veranschaulicht

Kontrollaufgabe:
Vergleichen Sie die Transformation von XML-Datenstrukturen aus dem ER-Modell mit der Transformation von hierarchischen Datenstrukturen aus dem ER-Modell. Wo bestehen Gemeinsamkeiten, wo bestehen Unterschiede?

Literatur:
Williams K . et.al.: Professional XML Databases. Wrox Press 2000. ISBN: 1861003587.

© Prof. Dr. Hans Jürgen Ott --> home
45xmler-entity.htm

Modellierung von Entity-Typen in XML

Aus einem Entity-Typ T wird ein Element E einer DTD; besteht der Entity-Typ aus mehreren Entities (was der Regelfall sein wird), so ist er als Unterelement eines Wurzel-Elements zu modellieren, das den Anwendungskontext repräsentiert. Die Attribute von T könnten entweder als Unterelemente von E oder als Attribute von E modelliert werden. Die Schlüsseleigenschaft von Attributen wird nicht in die DTD übernommen.

Dies soll am Beispiel einer Bibliothek veranschaulicht werden; dabei bestehe eine Bibliothek aus Büchern (Entity-Typ buch), von denen die ISBN-Nummer und der Titel bekannt seien (Attribute isbn und titel). Daraus resultieren folgende XML-Dateien:

Modellierung der Attribute als Elemente

<!ELEMENT bibliothek (buch+)>
  <!ELEMENT buch (isbn, titel)>

    <!ELEMENT isbn (#CDATA)>
    <!ELEMENT titel (#CDATA)>

XML-Datei

<?XML version="1.0"?>
<!DOCTYPE bibliothek SYSTEM "bibliothek.dtd">
  <bibliothek>
    <buch>
      <isbn>354041956X</isbn>
      <titel>Datenbanken und XML</titel>
    </buch>
    .......
    <buch>
      <isbn>3540668144</isbn>
      <titel>Open Internet Security</titel>
    </buch>
    
  </bibliothek>

Modellierung der Attribute als Attribute

!ELEMENT bibliothek (buch+)>
  <!ELEMENT buch EMPTY>
  <!ATTLIST buch
    isbn CDATA #REQUIRED
    titel CDATA #REQUIRED>

XML-Datei

<?XML version="1.0"?>
<!DOCTYPE bibliothek SYSTEM "bibliothek1.dtd">
  <bibliothek>
    <buch
      isbn="354041956X"
      titel="Datenbanken und XML" />
    .......
    <buch
      isbn="3540668144"
      titel="Open Internet Security" />

  </bibliothek>

Es liegt letztlich beim Modellierer, welche Modelierung er wählt. Man kann allerdings nachweisen, dass die Modellierung der (ER-) Attribute als (XML-) Attribute Vorteile hat:

Hier wird daher der Attribut-Ansatz verfolgt.

Kontrollaufgabe:
Wandeln Sie Entity-Typen aus dem Unternehmensmodell BA-Bibliothek in eine XML-DTD um.

Literatur:
Williams K . et.al.: Professional XML Databases. Wrox Press 2000. ISBN: 1861003587.

© Prof. Dr. Hans Jürgen Ott --> home
45xmler-1ton.htm

Modellierung von (1:1)- und (1:n)-Beziehungen in XML

Aus dem Entity-Typ T1, der die "1-Seite" der Beziehung bildet, wird ein Element E1 einer DTD. Die Attribute von T1 werden als Attribute von E1 modelliert. Aus dem Entity-Typ TN, der die "n-Seite" der Beziehung bildet (bzw. bei (1:1)-Beziehungen der andere Entity-Typ), wird ein Unterelement EN von E1. Die Attribute von TN werden als Attribute von EN modelliert. Beziehungsattribute werden dem Element EN zugeordnet. Folgendes ER-Modell soll das Szenario repräsentieren, dass ein Ausleiher mehrere Bücher ausleihen kann, ein Buch jedoch nur von einem Ausleiher ausgeliehen werden kann:

DTD bibliothek3.dtd

!ELEMENT bibliothek (ausleiher+)>

  <!ELEMENT ausleiher (buch+)>
  <!ATTLIST ausleiher
    ausweisnr CDATA #REQUIRED
    aname CDATA #REQUIRED>

    <!ELEMENT buch EMPTY>

    <!ATTLIST buch
      isbn CDATA #REQUIRED
      titel CDATA #REQUIRED
      adatum CDATA #REQUIRED >

XML-Datei

<?XML version="1.0"?>
<!DOCTYPE bibliothek SYSTEM "bibliothek3.dtd">
  <bibliothek>
    <ausleiher
      ausweisnr="4711"
      aname="Dieter Müller" >
      <buch
        isbn="354041956X"
        titel="Datenbanken und XML"
        adatum="1.1.2002" />     
      <buch
        isbn="3540668144"
        titel="Open Internet Security"
        adatum="1.1.2003" />

    </ausleiher>
    <ausleiher
      ausweisnr="0815"
      aname="Karl Schulze" >
      <buch
        .......
    </ausleiher>
  </bibliothek>

Kontrollaufgabe:
Wandeln Sie (1:n)-Beziehungen aus dem Unternehmensmodell BA-Bibliothek in eine XML-DTD um.

Literatur:
Williams K . et.al.: Professional XML Databases. Wrox Press 2000. ISBN: 1861003587.

© Prof. Dr. Hans Jürgen Ott --> home
45xmler-mton.htm

Modellierung von (m:n)-Beziehungen in XML

Bei (m:n)-Beziehungen werden die Entity-Typen TN und TM sowie der Beziehungstyp R als Elemente EN, EM und ER modelliert; die (ER-Modell-) Attribute werden wieder als (XML-) Attribute modelliert und den entsprechenden Elementen zugeordnet. Bei der Definition der Strukturbeziehungen der Elemente untereinander hat man prinzipiell zwei Möglichkeiten der Behandlung von (m:n)-Beziehungen, die auch schon beim hierarchischen Datenmodell diskutiert wurden:

Folgendes ER-Modell soll das Szenario repräsentieren, dass ein Besteller mehrere Bücher bestellt haben kann und ein Buch von mehreren Bestellern bestellt worden sein kann:

Modellierung durch Containment

!ELEMENT bibliothek (buch+)>

  <!ELEMENT buch (bestellt+)>
  <!ATTLIST buch
    isbn CDATA #REQUIRED
    titel CDATA #REQUIRED>


    <!ELEMENT bestellt (besteller)>
    <!ATTLIST bestellt
      bdatum CDATA #REQUIRED >

      <!ELEMENT besteller EMPTY>

      <!ATTLIST besteller
        bestid CDATA #REQUIRED
        bname CDATA #REQUIRED>


XML-Datei

<?XML version="1.0"?>
<!DOCTYPE bibliothek SYSTEM "bibliothek4.dtd">
  <bibliothek>
    <buch
      isbn="354041956X"
      titel="Datenbanken und XML" />
      <bestellt
        bdatum="1.1.2002" />
        <besteller
          bestid="007"
          bname="James Bond" />
      </bestellt>
      <bestellt
        bdatum="1.1.2003" />
        <besteller
          bestid="4711"
          bname="Fritz Köln " />
      </bestellt>
    </buch>
    .......
    <buch>
     .......     
    </buch>
    
  </bibliothek>

Modellierung durch ID/IDREF-Pointer

!ELEMENT bibliothek (buch+, besteller+)>

  <!ELEMENT buch (bestellt+)>
  <!ATTLIST buch
    isbn CDATA #REQUIRED
    titel CDATA #REQUIRED>


    <!ELEMENT bestellt EMPTY>
    <!ATTLIST bestellt
      bestIDREF IDREF #REQUIRED
      bdatum CDATA #REQUIRED >

  <!ELEMENT besteller >

  <!ATTLIST besteller
    bestid ID #REQUIRED
    bname CDATA #REQUIRED>

XML-Datei

<?XML version="1.0"?>
<!DOCTYPE bibliothek SYSTEM "bibliothek5.dtd">
  <bibliothek>
    <buch
      isbn="354041956X"
      titel="Datenbanken und XML" />
      <bestellt
        bestIDREF="007"
        bdatum="1.1.2002" />
      </bestellt>
      <bestellt
        bestIDREF="4711"
        bdatum="1.1.2003" />
      </bestellt>
    </buch>
    .......
    <buch>
     .......     
    </buch>

    <besteller
      bestid="007"
      bname="James Bond" />
    <besteller
      bestid="4711"
      bname="Fritz Köln " />
    .......     
  </bibliothek>

Die Containment-Methode hat den Nachteil, dass das XML-Dokument unter Umständen sehr viele redundante Elemente hat. Im Beispiel kann es also sein, dass der besteller "007" in mehreren bestellt-Elementen in mehreren buch-Elementen auftaucht, da er eben mehrere Bücher bestellt hat. Diesen Nachteil vermeidet die ID/IDREF-Methode; diese wiederum hat allerdings einen anderen Nachteil: Zur Überprüfung der korrekten Struktur der XML-Dokumente und zum Auslesen der Daten und Speichern in Datenbanken durch entsprechende DBMS-Funktionen muss das XML-Dokument durch einen Parser (beispielsweise Xerxes beim Apache-Webserver) geparst werden. Mit den gängigen Parse-Methoden DOM und SAX ist dies bei ID/IDREF-Strukturen sehr aufwendig und verringert die Performance. Man wird also bei zeitkritschen Anwendungen die Containment-Methode wählen und insbesondere dann, wenn das übergeordnete Element (im Beispiel: buch) jeweils wenige Unterelemente (im Beispiel: bestellt bzw. besteller) hat, wenn also das Redundanzproblem nicht so groß ist.

Beide Methoden haben dasselbe Grundsatzproblem, das auch schon beim hierarchischen Datenmodell diskutiert wurde: Die Beziehungen im ER-Modell sind ungerichtet, d.h. es ist a priori undefiniert, was im XML-Dokument zum übergeordneten und was zum untergeordneten Element wird. Im obigen Beispiel könnte bei der Containment-Methode auch der besteller als Unterelemente bestellt und diese Elemente wieder buch als Unterelement haben; bei der ID/IDREF-Methode könnte bestellt auch ein Unterelement von besteller sein und in einem Attribut isbnIDREF auf isbn als ID-Attribut von buch verweisen. Hier wird man so vorgehen, dass man die Elemente mit der größten Instanzenmenge als übergeordnete Elemente definiert; wenn also wesentlich mehr Bücher als Besteller vorhanden sind, dann wird man buch als übergeordnetes und besteller als untergeordnetes Element definieren.

Kontrollaufgabe:
Wandeln Sie (m:n)-Beziehungen aus dem Unternehmensmodell BA-Bibliothek in eine XML-DTD um.

Literatur:
Williams K . et.al.: Professional XML Databases. Wrox Press 2000. ISBN: 1861003587.

© Prof. Dr. Hans Jürgen Ott --> home
45xmler-bsp.htm

Beispiel für die Transformation ER-Modell - XML

Am Beispiel einer Bibliothek soll die Ableitung einer XML-DTD aus einem ER-Modell veranschaulicht werden; folgendes ER-Modell soll umgesetzt werden:

ER-Modell --> XML

Folgende Schritte sind bei der Ableitung einer DTD aus dem ER-Modell notwendig:

1. Modellierung der Entity-Typen

Die Entity-Typen werden zu Elementen mit ihren zugeordneten Attributen:

  <!ELEMENT buch EMPTY>
  <!ATTLIST buch
    isbn CDATA #REQUIRED
    titel CDATA #REQUIRED>

  <!ELEMENT ausleiher EMPTY>
  <!ATTLIST ausleiher
    ausweisnr CDATA #REQUIRED
    aname CDATA #REQUIRED>

  <!ELEMENT buchhaendler EMPTY>
  <!ATTLIST buchhaendler
    bhnr CDATA #REQUIRED
    bhname CDATA #REQUIRED>

  <!ELEMENT besteller EMPTY>
  <!ATTLIST besteller
    bestid CDATA #REQUIRED
    bname CDATA #REQUIRED>

2. Modellierung der (1:1)- und (1:n)-Beziehungstypen

Prinzipiell werden die "n-Typen" im ER-Modell untergeordnete Elemente der "1-Typen". Manchmal kann es sinnvoll sein, von diesem Prinzip abzuweichen: Wenn (wie in dem vorliegenden Beispiel) Bücher im Zentrum eines Bibliotheksverwaltungssystems stehen und nicht Ausleiher oder Buchhändler, dann sollte buch auch das übergeordnete Element darstellen (und nicht ausleiher oder buchhaendler als "1-Typen"). Die damit eingehandelte Redundanz (Daten von einem ausleiher kommen bei mehreren buch-Elementen als Unterelemente vor) kann man wiederum durch ID/IDREF-Pointerstrukturen vermeiden (wenn man darauf bedacht ist, möglichst kleine und redundanzfreie XML-Dokumente zu erhalten - möglicherweise auf Kosten der Parse-Performance).

Man erhält im obigen ER-Modell-Beispiel:

  <!ELEMENT buch EMPTY>
  <!ATTLIST buch
    isbn CDATA #REQUIRED
    titel CDATA #REQUIRED
    ausweisnrIDREF IDREF
    adatum CDATA
    bhnrIDREF IDREF #REQUIRED >


  <!ELEMENT ausleiher EMPTY>
  <!ATTLIST ausleiher
    ausweisnr ID #REQUIRED
    aname CDATA #REQUIRED>

  <!ELEMENT buchhaendler EMPTY>

  <!ATTLIST buchhaendler
    bhnr ID #REQUIRED
    bhname CDATA #REQUIRED>


  <!ELEMENT besteller EMPTY>

  <!ATTLIST besteller
    bestid CDATA #REQUIRED
    bname CDATA #REQUIRED>

3. Modellierung der (m:n)-Beziehungstypen

Der Beziehungstyp bestellt im ER-Modell wird untergeordnetes Element des entsprechenden Entity-Typs, der "am bedeutungsvollsten" ist (hier: buch). Der Bezug zum anderen Entity-Typ (hier: besteller) wird wieder über eine ID/IDREF-Pointerstruktur hergestellt.

Man erhält im obigen ER-Modell-Beispiel:

  <!ELEMENT buch (bestellt+)>
  <!ATTLIST buch
    isbn CDATA #REQUIRED
    titel CDATA #REQUIRED
    ausweisnrIDREF IDREF
    adatum CDATA
    bhnrIDREF IDREF #REQUIRED >

    <!ELEMENT bestellt EMPTY>
    <!ATTLIST bestellt
      bestidIDREF IDREF #REQUIRED
      bdatum CDATA #REQUIRED>

  <!ELEMENT ausleiher EMPTY>
  <!ATTLIST ausleiher
    ausweisnr ID #REQUIRED
    aname CDATA #REQUIRED>

  <!ELEMENT buchhaendler EMPTY>
  <!ATTLIST buchhaendler
    bhnr ID #REQUIRED
    bhname CDATA #REQUIRED>

  <!ELEMENT besteller EMPTY>
  <!ATTLIST besteller
    bestid ID #REQUIRED
    bname CDATA #REQUIRED>

4. Komplettierung durch Wurzelelement

Durch Einfügen des Wurzelelements erhält man folgende DTD, der folgendes Beispiel-XML-Dokument entspricht:

!ELEMENT bibliothek (buch+,
 ausleiher+, buchhaendler+, besteller+)>


  <!ELEMENT buch (bestellt+)>

  <!ATTLIST buch
    isbn CDATA #REQUIRED
    titel CDATA #REQUIRED
    ausweisnrIDREF IDREF
    adatum CDATA
    bhnrIDREF IDREF #REQUIRED >

    <!ELEMENT bestellt EMPTY>
    <!ATTLIST bestellt
      bestidIDREF IDREF #REQUIRED
      bdatum CDATA #REQUIRED>

  <!ELEMENT ausleiher EMPTY>
  <!ATTLIST ausleiher
    ausweisnr ID #REQUIRED
    aname CDATA #REQUIRED>

  <!ELEMENT buchhaendler EMPTY>
  <!ATTLIST buchhaendler
    bhnr ID #REQUIRED
    bhname CDATA #REQUIRED>

  <!ELEMENT besteller EMPTY>
  <!ATTLIST besteller
    bestid ID #REQUIRED
    bname CDATA #REQUIRED>

<?XML version="1.0"?>
<!DOCTYPE bibliothek SYSTEM "bibliothek6.dtd">
  <bibliothek>
    <buch
      isbn="354041956X"
      titel="Datenbanken und XML"
      ausweisnrIDREF="0815"
      adatum="1.1.2002"
      bhnrIDREF="M25" />
      <bestellt
        bestIDREF="007"
        bdatum="1.1.2001" />
      </bestellt>
      <bestellt
        bestIDREF="4711"
        bdatum="1.4.2001" />
      </bestellt>
    </buch>
    .......
    <buch>
     .......     
    </buch>

    <ausleiher
      ausweisnr="0815"
      aname="Karl Schulze" />
    .......     
    <buchhaendler
      bhnr="M25"
      bhname="Buchshop Maier" />
    .......
    <besteller
      bestid="007"
      bname="James Bond" />
    <besteller
      bestid="4711"
      bname="Fritz Köln" />
    .......          
  </bibliothek>

Kontrollaufgabe:
Wandern Sie das Unternehmensmodell BA-Bibliothek in eine XML-DTD um.

Literatur:
Williams K . et.al.: Professional XML Databases. Wrox Press 2000. ISBN: 1861003587.

© Prof. Dr. Hans Jürgen Ott --> home
Abfragsprachen für XML-Datenbanken

Abfragsprachen für XML-Datenbanken

Die Abfrage von Daten aus XML-Datenbanksystemen kann zunächst über die enthaltenen XML-Objekte selbst, d.h. direkt erfolgen. Die Abfrage liefert also ein in der Datenbank enthaltenes XML-Objekt so wie es in der Datenbank gespeichert ist (in Analogie zu Relationalen Datenbanksystemen: Man erhält eine Tabelle so, wie sie im konzeptuellen Datenbankschema definiert ist). Oft will man aber die Daten nicht in der logischen Form erhalten, die im konzeptuellen Schema vorgesehen ist, sondern will Auszüge aus Tabellen, will Tabellen verknüpfen bzw. will Daten in einer bestimmten Form dargestellt haben. Dazu benutzt man bei Relationalen Datenbanksystemen Abfragesprachen wie SQL. Solche Abfragesprachen existieren auch für XML; das W3C stellt Spezifikationen bereit (XML Query), die konkrete Abfragsprachen erfüllen sollen.

Die XML-Query-Spezifikation bestand 2003 aus 12 Teilen und stellt damit einen der komplexesten Standards des W3C dar; eine gute Übersicht über die einzelnen Teilstandards bietet http://www.ibm.com/developerworks/xml/library/x-xquery.html?ca=dnt-435. Die wichtigsten Bestandteile dieser Spezifikationen sind:

XSLT, XPath

XSLT ist eine Programmiersprache, um XML-Objekte in andere Objekte wie HTML-, PDF-, RTF- oder weitere XML-Objekte zu transformieren. Die Transformation selbst erfolgt durch Parser wie beispielsweise die Open-Source Produkte Saxon oder Xalan, die auf dieser Sprache basieren, und die Daten direkt aus Datenbanksystemen selektieren können. Mit Hilfe von XSLT kann man also letztlich Daten aus XML-Datenbanken abfragen.

XSLT-Prinzip

Die Aufgabe von XSLT ist vergleichbar mit der von SQL; damit können Tabellen in andere Tabellen transformiert werden, während hier jedoch hierarchische XML-Objekte in andere prinzipiell hierarchische Objekte transformiert werden. Die Transformationsanweisungen sind - neben reinen Formatierungsanweisungen - Teil eines XSL-Stylesheets; in dem Bibliotheksbeispiel werden aus dem Element buch des XML-Objekts bibliothek.xml die Daten von isbn und titel selektiert, um diese dann in Form einer HTML-Tabelle darzustellen. Die Syntax der in die Transformationsanweisungen eingebetteten Daten-Selektionsanweisungen ist durch XPath standardisiert. Im Vergleich zu Relationalen Systemen enspräche dies der Spracheinbettung von SQL (=XPath) in eine Wirtsprache (=XSLT).

XQuery

XQuery baut zum großen Teil auf XPath auf und erweitert dies um zusätzliche Datentypen und Konstrukte wie Sequenzen. XQuery erlaubt die Formulierung von komplexen verschachtelten Abfrageanweisungen analog zu SQL.

Entsprechend dem SELECT-Befehl in SQL kennt XQuery als zentralen Abfrageoperator die FOR-LET-WHERE-RETURN-Anweisung (FLWR). Dabei werden Daten zu Variablen zugeordnet und diese in eine XML-Ergebnisstruktur eingebunden, wie die folgende Beispielabfrage zeigt: Hier werden aus dem Element buch des XML-Dokuments bib.xml Buchtitel extrahiert, der Variable $titel zugewiesen und dann innerhalb eines Elements titelliste ausgegeben.

Abfrage Ergebnis

for $buch in
document("http://www.ba.de/bib.xml")//buch

let $titel := $buch/titel

where $buch/autor = 'Maier'

return
<titelliste>
   { $titel }
</titelliste>

<titelliste>
   <titel>Einführung in UNIX</titel>
</titelliste>
<titelliste>
   <titel>XML-Grundlagen</titel>
</titelliste>

Mit XQuery sind auch Joins möglich. Auch die anderen Sprachkonstrukte von SQL wie INSERT, DELETE und REPLACE haben ihre Entsprechung in XQuery. Unter http://www-106.ibm.com/developerworks/education/r-xxquery.html?n-x-9262 bietet IBM ein Tutorial zu XQuery an.

Kontrollaufgabe:
Stellen Sie Vorteile und Nachteile von XPath und XQuery einander gegenüber..

Literatur:
Kazakos W., Schmidt A., Tomczyk P.: Datenbanken und XML. Konzepte, Anwendungen, Systeme. Heidelberg/Berlin: Springer 2002. ISBN: 354041956X.

© Prof. Dr. Hans Jürgen Ott --> home