is-Logo

Datenbanken
Datenmodelle

S. Spolwig
Kurs GIN41, 2001


[Home |Datenbanksysteme]

page_dowm

Logische Datenmodelle jenseits des Relationenmodells

Referat von
Norman Niemer

Gliederung:

1. Hierarchisches Datenmodell

2. Netzwerkmodell

3. Objektorientiertes Datenmodell
3.1. ODBMS versus RDBMS
3.2. Anforderungen an ODBMS
3.3. ODMG-Standard
3.4. Das Objektmodell
3.4.1. Allgemeines
3.4.2. Attribute
3.4.3. Beziehungen
3.4.4. Schlüssel
3.4.5. Methoden
3.4.6. Vererbung
3.4.7. Objektidentität
3.5. Datenbankkonzepte

4. Glossar

5. Quellen/Literatur

1. Hierarchisches Datenmodell

- Gliederung als typisches Beispiel für hierarchisches Datenmodell
- einfachste Form eines Datensystems
- in der "Informatikersprache" auch Bäume (Trees) genannt
- natürliche Hierarchien: Personaldatei (Firma/Abteilung/Mitarbeiter), künstliche Hierarchien: Lieferantenkartei    (Artikel/Lieferant/Adresse)
- Arten von Hierarchien:

  • einstufig: genau einem Vaterelement werden ein/mehrere Söhne zugeordnet
  • mehrstufig:
    • Zusammenfügen von mehreren Hierarchien
    • aber: jedes Element darf nur in einer Gruppe Sohnelement sein
    • das Wurzelelement ist selber nirgends Sohnelement (keine Zirkelbezüge)

- Beziehungen:

  • 1:1 - Vater wird Sohn zuordnet
  • 1 : n - Vater werden mehrere Söhne zugeordnet
  • m : n - nicht darstellbar

- wichtig zum Finden, Ändern, Hinzufügen und Löschen von Daten ist das sequenzielle Auslesen:

  • Söhne kommen nach ihrem Vater
  • Söhne kommen vor den Brüdern

- programmiertechnisch erfolgt die Zuordnung nicht über Tabellen wie beim Relationenmodell,
   sondern direkt mit Pointern
- Vorteile: einfaches, effizientes Datenmodell (kommt daher in Directory Servern, Webservern
   und im Index von z.B. mySQL zur Anwendung)
- Nachteile: unflexibel und bei komplexen Umgebungen schwierig zu modellieren

2. Netzwerkmodell

- baut auf dem hierarchischen Modell auf
- Restriktion, dass Entität nur Mitglied in einer Gruppe sein kann, ist aufgehoben -> mehrere Wurzelelemente
   möglich
- Modellierung von m:n-Beziehungen möglich
- da es unpraktikabel bzw. nicht realisierbar ist, die m : n-Beziehung direkt zu modellieren,
   geht man einen Umweg über 2 1:m-Beziehungen (Darstellung: Autor/Beitrag/Buch)
- Zugriff auf die Entitäten erfolgt durch sequenzielles Auslesen der einzelnen Hierarchien
- Vorteile

  • komplexere Umgebungen lassen sich modellieren
  • vermaschte Strukturen sind möglich
  • m:n-Beziehung darstellbar

- Nachteile:

  • Verlust von Einfachheit und Übersichtlichkeit
  • sequenzielles Auslesen komplizierter
  • ineffizienter und demzufolge langsamer

3. Objektorientiertes Datenmodell

3.1. ODBMS vs. RDBMS

- Problempunkte relationaler Datenbanken:

  • Sehr komplexe Objekte und Umgebungen (z.B. CIM, Geoinformationssysteme) lassen sich nur schwer modellieren,
    bzw. müssen auf mehreren Tabellen abgebildet werden, wodurch
    • die Übersichtlichkeit verloren geht
    • Integrität lässt sich schlechter überwachen
    • die Leistung des Datenbanksystems reduziert wird
  • Inkompatibilität zwischen Datenbank und Anwendungsentwicklung/Programmiersprache
  • Es werden nur Datenattribute, aber keine Operationen abgebildet
  • Es gibt keine echte Objektidentität (Identifikation über Schlüssel, die nur das System kennt)

=> Entstehung der objektorientierten Datenbanksysteme

3.2. Anforderungen an ODBMS

- herausgearbeitet von renommierten Forschern -> "The Object-Oriented Database System Manifesto"

- Kernaussage: ein DBMS, erweitert um folgende Konzepte der Objektorientierung

  • Unterstützung für komplexe Objekte (Tupels, Listen, Arrays)
  • Objektidentität
  • Einkapselung/Encapsulation ("Geheimnisprinzip" - private/public)
  • Typen und Klassen
  • Hierarchien von Typen und Klassen (z.B. "Aggregation")
  • Überladen
  • Vererbung

- Daneben soll es auch eine vollständige Datenbank-Programmiersprache geben

3.3. ODMG-Standard

- Mitte 1991 taten sich führende Hersteller von ODBMS zusammen um einen Standard für objektorientierte    Datenbanksysteme zu entwickeln
- 1993 wurde die ODMG Standard Spezifikation 1.0 veröffentlicht (3.0 ist die neueste Version)
- Bestandteile des Standards:

  • Objektmodell: Der ODMG-Standard definiert ein gemeinsames Objektmodell für ODBMSe, bestehend aus objektorientierten Modellierungsmitteln und Datenbankelementen.

  • Object Definition Language (ODL): Die ODL als Objekt-Definitionssprache liefert die Syntax für das Objektmodell. Die ODL kann zur Definition eines Datenbankschemas verwandt werden.

  • Object Query Language (OQL): Die OQL dient zur Bildung von assoziativen Anfragen auf Datenbankobjekten. Die OQL, die sich an den Anfragemöglichkeiten von SQL orientiert, kann sowohl als eigene ODBMS-Schnittstelle als auch innerhalb der Sprachanbindungen verwendet werden.

  • Sprachanbindungen für C++ und Smalltalk: Die Sprachanbindungen sind die Umsetzung des Objektmodells auf eine Programmiersprache und dienen als Datenbankschnittstelle für ODBMS-Applikationen. Die Sprachschnittstellen liefern die Syntax und Semantik zur Definition und Manipulation der (Datenbank-) Objekte. Der Standard umfasst derzeit eine C++-Schnittstelle, eine Java-Schnittstelle und eine Smalltalk-Schnittstelle

Quelle: [1], S. 20f

Damit ist auch automatisch Interoperabilität geschaffen: auf Objekte, die mit der Sprache "A" erzeugt wurden, kann auch mit allen anderen Sprache OD-Sprachen zugegriffen werden.

3.4. Das Objektmodell

- C. Beeri entwickelte (ca. 1989) ein theoretisch fundiertes objektorientiertes Datenbankmodell
- dies beinhaltete im Großen und Ganzen die o.g. Kriterien des ODBMS-Manifestes
- Objektmodell: Datenmodell nach objektorientierten Konzepten => konkrete Modellierung Datenbankschema
 


Objektorientiertes Datenbankschema:


Quelle: [1], S. 231 f

Grafische Notation für ein objektorientiertes Datenbankschema:



- im Relationenmodell erfolgt das Speichern der Daten in Tabellen,
   im ODBMS: Speichern der Daten in Objekten
- Attribute, Beziehungen, Schlüssel ebenfalls zu finden
- starke Orientierung an OOP
- Definition des Objektmodells erfolgt mit der ODL - die konkrete Implementation der Objekttypen, Methoden und    Abfragen erfolgt in der jeweiligen Programmiersprache


Definition des Objekttyps Firma:

interface Firma

( // Typeigenschaften
    extent Firmen
    key (Name, Firmensitz)
)
{ // Instanzeigenschaften

    //Attribute
    attribute String Name;
    attribute Adresse Firmensitz;
    attribute Date Gruendung;
    attribute Short Grosse;

    // Beziehungen
    relationship Set<Produkt> vertreibt;
    relationship Set<Angestellter> beschäftigt inverse angestellt_in;

    // Instanzoperationen
    Boolean einstellen (in Angestellter, in Projekt);
    Boolean entlassen (in Angestellter);
}

Quelle: [1] S. 24

3.4.2. Attribute

- haben einen bestimmten Datentyp, der entweder ein Systemdatentyp oder ein Benutzerdatentyp sein kann
- Mengen, Listen und Arrays sind ebenfalls möglich
- können als private oder public deklariert werden

3.4.3. Beziehungen

- die Beziehungen, wie es sie in den Datenmodellen gibt, existieren in objektorientierten Programmiersprachen nicht
    => eigenständiges Konzept
- alle Arten von Beziehungen lassen sich im Objektmodell realisieren

  • 1:1 - Angestellter leitet/geleitet von Projekt
  • 1:n - Firma beschäftigt/angestellt in Angestellten
  • m:n - Angestellter bearbeitet/bearbeitet von Projekt
  • unidirektional - Firma vertreibt Produkt
  • bidirektional - Firma beschäftigt/angestellt in Angestellten
    (muss im verbundenen Objekttyp analog sein - Wahrung der referentiellen Integrität)

- Beziehungen können nur zwei Objekttypen involvieren und keine Attribute besitzen => zur Lösung muss ein neuer Objekttyp erstellt werden

3.4.4. Schlüssel

- das Schlüsselkonzept der RDBMS findet sich auch in ODBMS wieder
- dient weniger der Objektidentifizierung, sondern zur Sicherung der Eindeutigkeit bestimmter Attributkombinationen

3.4.5. Methoden

- das objektorientierte Paradigma legt Wert auf strikte Trennung von Speicherung von Daten und Manipulation der Daten
- Konzept auch im ODBMS
- da die Implementation in der Programmiersprache erfolgt ergibt sich ein besonderer Vorteil: Möglichkeit der Nutzung    von speziellen Programmieralgorithmen

3.4.6. Vererbung

- identische Verwendung wie in OOP, es ist sogar Polymorphie möglich
- großer Vorteil gegenüber RDBMS

3.4.7. Objektidentität

- wichtige Eigenschaft von ODBMS (wird sowohl im Manifest, als auch im ODMG-Standard gefordert)
- jedem Objekt wird eine ID zugeordnet, die das Objekt eindeutig identifizierbar macht
- Vorteile gegenüber RDBMS

  • die ID ist unabhängig von den Eigenschaften (das Kennzeichen als eindeutiger Primärschlüssel eines Auto-Datentyps ändert sich u.U. doch)
  • die IDs werden automatisch vom DBMS vergeben - die nötige Umgang mit Schlüsseln im RDBMS entfällt

3.5. Datenbankkonzepte

  • Persistenz
  • Berechnungsvollständigkeit
  • Transaktions- und Zugriffskontrolle
  • u.a.


4. Glossar

CIM - computer integrated manufacturing
ODBMS - object database management system
ODMG - object database management group - Forum für Standards der ODMBS
OOP - object oriented programming
OOPL - object oriented programming language
RDBMS - relational database management system

5. Quellen/Literatur

Objektorientierte Datenbanksysteme - Hohenstein/Lauffer/Schmatz/Weikert

[1] Hohenstein/Lauffer/Schmatz/Weikert: Objektorientierte Datenbanksysteme, SS> Vieweg-Verlag, 1996

[2] Heuer, A./Saake, G.: Datenbanken - Konzepte und Sprachen, International Thomson Publishing, 1995

[3] www.odmg.org - Website der ODMG

 



 04. Oktober 2008   ©  Siegfried Spolwig

page_top