WS 98/99; Simulation, Kp. 6 1
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Simulation komplexer technischer Anlagen
Teil II: Elemente zum Bau virtueller Anlagenkomponenten
Kapitel 6:Speicherung von Objekten
Inhalt
• Datenmodelle
• Datenbanksysteme
• Dienste durch Datenbanksysteme
• Anforderungen an objektorientierte Datenbanksysteme - Das Manifesto
• Wege zur Entwicklung objektorientierter Datenbanksysteme
WS 98/99; Simulation, Kp. 6 2
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Vorbemerkungen
ProblemstellungObjekte werden von Programmen generiert, modifiziert und vernichtet. Sollen sie den Programmlauf überleben, müssen sie persistent gemacht werden. Dies kann durch Ablage der Objekte als Files oder in Datenbanken geschehen. Insbesondere wenn man es mit einer Vielzahl von Objekten zu tun hat, bietet es sich an, für das Objekt-Management Datenbanken zu verwenden. Zwei Lösungen der damit verbundenen Problematik sind möglich.
1. Objektstrukturen werden auf Strukturen existierender Datenbanken (etwa relationale DB) abgebildet. Zur Erhöhung der Performance ist es dann nötig, Konstrukte einzuführen, die Objektsichten unterstützen.
2.Objekte werden als Grundlage verwendet (ODB). Dann ist es notwendig, Mechanismen zu entwickeln, die Ähnliches leisten, wie die, die den Siegeszug der relationalen Datenbanken ermöglichten.
Ziel der VortragseinheitZunächst werden wichtige Eigenschaften moderner Datenbanken aufgeführt. Vor diesem Hintergrund werden dann Forderungen an objektorientierte Datenbanksysteme (Manifesto) erläutert.
LiteraturAtkinson, M.; Bancilhon, F.; DeWitt, D.; Dittrich, K.R.; Maier, D.; Zdonik, S.: The Object-Oriented Database System Manifesto. Proc.Int. Conf. on Deductive and Object-Oriented Databases (DOOD), Kyoto, Japan, Dec. 1989.
WS 98/99; Simulation, Kp. 6 3
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Grundbegriffe• Datenbasis:
Menge von Daten, die nach einem logischen Kriterium zusammengehören und als identifizierbare Einheit auf einem externen Medium gespeichert werden.
• Datenbank-Managementsystem (DBMS):Software für dauerhafte, zuverlässige, unabhängige Verwaltung und komfortable, flexible Benutzung von großen, integrierten, mehrfachbenutzbaren Datenbasen
• Datenbank:Sammlung gespeicherter operationaler Daten, die von Anwendungssystemen benötigt werden
• Datenstrukturierung - Datenmodellierung - DatenbankentwurfZusammenfassung von Daten in Datenobjekte
• KonsistenzDaten in einer Datenbasis beschreiben, Weltausschnitte der Anwendung vollständig und widerspruchsfrei
• MehrfachbenutzerbetriebKonkurrierende Zugriffe beeinträchtigen Integrität der Datenbasis nicht
• Datensicherung - TransaktionskonzeptFehler bei System und Bedienung stören
Unverletzlichkeit der Daten nicht
Datenbank = Datenbasis + DBMS
WS 98/99; Simulation, Kp. 6 4
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Verbindung von Programmenund Daten
• Traditionelle ModellierungProgramm verwendet nur eigene Daten
verwaltet seine Daten
stellt elementare Operationen bereit
Programm: Daten:restliche Interpretation elementare Datentypen
Semantik der Daten elementare Datenstrukturen
elementare Operationen
WS 98/99; Simulation, Kp. 6 5
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Verbindung von Programmenund Daten
• Datentausch über FilesDaten können von mehreren Programmen verwendet werden
Dateiformat, Dateiname, Zugriffsstruktur aller Programme bekannt (Schnittstelle)
WS 98/99; Simulation, Kp. 6 6
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Verbindung von Programmenund Daten
• Datentausch über Datenbank
Standardisierte Zugriffsmechanismen
Datenwartung und Datenhaltung unabhängig vom Programm
Datenbanken können verteilt sein
WS 98/99; Simulation, Kp. 6 7
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Daten in ingenieur-wissenschaftlichen Anwendungen
• DatenartenStammdatenPrimärdatenabgeleitete Daten
Zu beschreibende Objekteumfangreichkomplex strukturiertleicht veränderbar (Entwurfsvarianten)leicht kombinierbar (Konfiguration)leicht erweiterbar (Entwicklung)
• Datenquellen und Verarbeitungräumliche Verteilungorganisatorische Verteilungzeitliche Verteilungerfordern große Zahl von Schnittstellen
• Zusammenfassungvielfältige Strukturen mit relativ wenigen Datenobjekten gleicher Struktur
WS 98/99; Simulation, Kp. 6 8
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Datenmodelle
• Abstraktionsmechanismen zur Abbildung eines Weltausschnittsstrukturelle Aspekte - Datentypen
- Konstruktoren
funktionale Aspekte - Operatoren
• Beispiele gebräuchlicher Datenmodelleabstrakte Datentypen
Objekte
hierarchisches Modell
Relationen-Modell
WS 98/99; Simulation, Kp. 6 9
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Hierarchisches Modell
Festlegung der Ordnungsbeziehungen zwischen Datensegmenten
• Beispiel:
Datenbanksatz aus Stammsegment A und abhängigen Segmenten B - C
Regeln zur Verarbeitung -
Abbildung auf lineare Liste: A; B1, B2, B3; C; D1, E; D2, D3.
• Physischer Pointer
Verknüpfung von Segmenten innerhalb einer Datenbank
• Logischer Pointer
Verknüpfung von Datenbanksätzen aus verschiedenen Datenbanken
WS 98/99; Simulation, Kp. 6 10
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Das relationale Modell - GlossarRelationale Datenbanken sind in Tabellen organisiert. Jede Tabelle ist durch einen Schlüssel gekennzeichnet. SQL dient zur Definition, Manipulation und Kontrolle der Tabellen.
Datenbanken (DB)Eine Menge von miteinander in Verbindung stehenden Daten für eine oder mehrere Anwendungen. Die Daten stehen normalerweise vielen Benutzern zur Verfügung.
RDB (Relationale Datenbank)Eine relationale Datenbank stellt Daten in Form von Tabellen dar.
RDBMSRelationale Datenbank-Management-Systeme
TabelleBei einer RDB werden Daten in Form von Tabellen organisiert. Die Tabelle besteht aus einer festen Anzahl von Spalten (Attributen). Die Reihen der Tabelle enthalten die Datensätze der DB. Eine Tabelle ist mit Daten der gleichen Art gefüllt.
BasistabellenBasistabelle wird auch einfach als “Tabelle oder wirkliche Tabelle” im Gegensatz zur virtuellen Tabelle bezeichnet. Sie existiert wirklich in der Datenbank, hat einen
Namen, kann verändert oder auch gelöscht werden (diese Vorgänge bedingen ebenfalls das Ändern oder Löschen der auf sie angewandten Indexes und Views). SchlüsselDer Primärschlüssel identifiziert jede Zeile in einer Tabelle eindeutig. Dieser Schlüssel kann aus einer einzigen Spalte in der Tabelle bestehen oder aus mehreren Spalten zusammengesetzt sein. Wegen der erforderlichen Eindeutigkeit sollte er nach Möglichkeit aus einer Zahl (zum Beispiel Kunden- oder Artikelnummer) und nicht aus einem Textstring (Name oder Artikelbezeichnung) bestehen. Der Fremdschlüssel (foreign key) ist eine oder mehrere Spalten in einer Tabelle, die in einer anderen Tabelle
Primärschlüssel sind (nötig für die Verknüpfung von Tabellen). INDEXEin Index dient zur beschleunigten Datensuche und kann in Oracle dazu verwendet werden, die Eindeutigkeit der Datensätze zu garantieren. Im Gegensatz zum Schlüssel, der nur eine logische Einheit darstellt, existiert der Index wirklich. Für eine Tabelle kann es eine oder auch mehrere Indexe geben. Er kann über eine oder auch mehrere Spalten gebildet werden. Ein Index beschleunigt die Abfrage, verzögert jedoch die Neueingabe von Sätzen.
VIEWViews sind Tabellen, die in Wirklichkeit nicht vorhanden sind (virtuelle Tabellen). Mit ihnen kann man wie mit echten Tabellen arbeiten. Sie enthalten Daten aus einer oder mehreren Basis-Tabellen. Views werden zur Vereinfachung der Arbeit mit SQl und zu Sicherungs- und Anzeigezwecken definiert.
SQL (Structured Query Language) Abfragesprache für relationale (in Tabellen organisierte) DB-Systeme. SQL wird interaktiv; über Kommandodateien (Programme) und integriert in andere Programme (SQL FORMS) angewendet. SQL arbeit nicht prozedural, das heißt es wird angegeben, was geschehen soll und nicht wie. In einem einzelnen Befehl können eine oder mehrere Tabellen anstelle eines einzelnen Datensatzes abgearbeitet werden.
WS 98/99; Simulation, Kp. 6 11
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Das relationale Modell
• EntitätUnterscheidbare Objekte mit Eigenschaften (Attributen), Instanzen sind alle Ausprägungen einer Entität.
• Attribute (Ai)sind beschreibende und identifizierbare Aspekte von Entities bzw. Relationships der abzubildenden Miniwelt.
• Wertebereich W (Ai)ist die Menge von Werten, aus der alle Ausprägungen des Attributs Ai stammen.
WS 98/99; Simulation, Kp. 6 12
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Das relationale Modell
• Relationen R(A1, ... An)bestehen zwischen Instanz und Attributen. Durch Angabe des Namens R und der beteiligten Attribute A1 ..., An ist eine Relation in ihrer Struktur zeitinvariant festgelegt. Ihre extensionale Festlegung durch die Menge der Ausprägungen lautet:
Nimmt sie konkrete Werte an, spricht man von Tupel.
• Relationshipbeschreibt Beziehungen zwischen Entitäten (im Entity-Relationship-Modell können auch Beziehungen Eigenschaften haben).
R A A W A xW A x xW An( , ,..., ( ), ( ) ... ( )1 2 1 2
WS 98/99; Simulation, Kp. 6 13
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Das relationale Modell• Tabellen
sind Listen, in denen allen Instanzen einer Entität Attribute zugeordnet sind. Die Tabellen bestehen aus einer festen Anzahl von Spalten. Die Zeilen einer Tabelle enthalten die Datensätze der relationalen Datenbank. Sie heißen unnormalisierte Relationen.
In der Regel ist redundante Speicherung erforderlich.
Attribute
Entität
MA* Name Beruf Fähigkeit (F) Alter
Mitarbeiter 1
1
1
2
3
Meier
Meier
Meier
Huber
Schmitt
Sekretärin
Sekretärin
Sekretärin
Organisator
Kontorist
Stenographie
Maschinenschreiben
Datenerfassung
Systemanalyse
Buchhaltung
25
25
25
30
32
1. Normalform (NF) einer Relation.
WS 98/99; Simulation, Kp. 6 14
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Das relationale Modell• Schlüssel
bezeichnen die Instanzen einer Entität.
Primärschlüssel identifzieren jede Zeile einer Tabelle eindeutig. Fremdschlüssel beziehen sich auf eine oder mehrere Spalten in einer Tabelle, die in einer anderen Tabelle Primärschlüssel sind. Sie verknüpfen Tabellen und minimieren Redundanz.
(2. Normalform: nur Schlüssel redundant)
2. Normalform einer Relation
MA*-F MA* Fähigkeit
1 Stenographie
1 Maschinenschreiben
1 Datenerfassung
2 Systemanalyse
3 Buchhaltung
Entität MA* Name Beruf Alter
1 Meier Sekretärin 25
2 Huber Organisator 30
3 Schmitt Kontorist 32
WS 98/99; Simulation, Kp. 6 15
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Das relationale Modell
• Indexdient zur beschleunigten Datensuche (index-sequentiell).
• Viewsind virtuelle Tabellen, die bestimmte Sichten auf die Daten erlauben und dadurch Abfragen einfacher machen.
• SQL(Structured Query Language) Abfragesprache für relationale Datenbanksysteme. Interaktiv, nicht prozedural (Kommandosprache, die angibt, was geschehen soll, nicht aber wie).
Ergebnis einer SQL-Abfrage ist eine Menge von Tupeln mit den vorgegebenen Eigenschaften.
WS 98/99; Simulation, Kp. 6 16
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Eigenschaften des relationalen Modells
• Sammlung von Tabellen- Primärschlüssel / Fremdschlüssel
- Wertebereich - Attribut
• Information (Relationen) durch Werte- ausschließlich durch den Inhalt der Daten
- keine physische Verbindungen
- keine bedeutungsvolle Ordnung
• Vorteile- Einfachheit
- strenge theoretische Grundlage
- keine Bindung an Zugriffspfade und Speichertechnologie
- keine Aussage über die Realisierung
- hoher Grad an Datenunabhängigkeit
- symmetrisches Datenmodell, d.h. keine bevorzugte Zugriffsrichtung
WS 98/99; Simulation, Kp. 6 17
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Eigenschaften des relationalen Modells
• Hauptmerkmale der relationalen Datenbank-Schnittstelle (Standard Query Language SQL)- deskriptiver Charakter
- Mengenorientierung
- Qualifikation aufgrund von Werten / nicht Position
- hoher Grad und Prozeduralität
- hohes Auswahlvermögen: relational vollständig
WS 98/99; Simulation, Kp. 6 18
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Abstraktion und Mächtigkeit der Datenbank-Modelle
Verararbeitungsrege ln an den D atenAD T´sVererbung von E igenscha ftenAnstoß der Verararbeitung der M essages
Kenntnis der Beziehung zwischen Daten
rekursive O pera tionen
Abb. kom plexer Strukturen
In tegritä tsrege ln
abs trak te D atenopera tionen
logische D atenunabhäng igke it
Relationenm odell
NF2-Modell
Entity/Relationship-M odell
Objektorientierte Datenbanken
WS 98/99; Simulation, Kp. 6 19
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Geschichte der Datenbanksysteme
1960 File-Systeme
1970 Codasyl
Hierarchische DBMSs
ADTs als Verbindung von Programmiersprache und DBMS
1980 Relationale DBMSs
1990 Objektorientierte DBMSs Ansatz
Relationale DBMSs dominant
Verteilte DBMSs (Client/Server)
Embedded SQL als Verbindung von DBMS und Programmiersprache
WS 98/99; Simulation, Kp. 6 20
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Charakteristika von DBMS
• Datenintegrationalle Daten unter einem Dach
• Datenstrukturierung - DatenmodellierungDatenbankentwurf kann anwendungsbezogen erfolgen
• KonsistenzWeltausschnitte der Anwendung
vollständig und widerspruchsfrei
• Mehrbenutzerbetrieb
konkurrierende Zugriffe beeinchträchtigen Integrität der Datenbasis nicht
• Datensicherung - TransaktionskonzeptFehler bei System und Bedienung stören Unverletzlichkeit der Daten nicht
• DatenunabhängigkeitProgramm unabhängig von Lokalität der Daten und ihrer strukturellen Interpretation
WS 98/99; Simulation, Kp. 6 21
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Konsistenz
• Logisch richtige und widerspruchsfreie Modellierung- physikalische Gesetze
- technologische Grenzen
- Auftragsmerkmale
• Lokale KonsistenzKonsistenz eines Objekts
• Globale KonsistenzKonsistenz eines Systems
• Modifikationen des Transaktionskonzepts- Zugriffssynchronisation
- Konsistenzsicherung
- Datensicherung
WS 98/99; Simulation, Kp. 6 22
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Transaktionskonzept
System übernimmt Verantwortung für korrekte und vollständige Abarbeitung einer Sequenz von DatenbankoperationenBeispiel 1: Normalfall BOT
SELECT ...
UPDATE ...
INSERT ...
SELECT ...
COMMIT ...
Beispiel 2: Freiwilliger Abbruch BOT
SELECT ...
UPDATE ...
ROLLBACK ...
Beispiel 3: Erzwungener Abbruch BOT
SELECT ...
UPDATE ...
INSERT
Systemfehler
WS 98/99; Simulation, Kp. 6 23
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Transaktionskonzept
ACID-PrinzipAtomicity: Eine Transaktion wird ganz oder gar nicht ausgeführt.
Consistency: Eine Transaktion schließt alle inhaltlich zusammengehörenden Befehle ein.
Isolation: Änderung einer unvollständigen Transaktion sind für die Umwelt unsichtbar.
Durability: Änderungen einer abgeschlossenen Transaktion gehen durch evtl. nachfolgende Fehler nicht mehr verloren.
Folgerung: Benutzer kennt Zustand des Systems.
Verteilte Datenbanken unabhängig von lokalen Störungen.
WS 98/99; Simulation, Kp. 6 24
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Dienste durch DBMS
Systematische Persistenz: Daten überleben Transaktionen und Sitzungen
Disk-Verwaltung: Techniken zur Steigerung der Performance
(Buffer, Cluster, Index, Query-Optimierung)
Mehrbenutzerkonzepte: Jeder Nutzer sieht sich als alleiniger Kunde
Datensicherheit - Transaktionskonzepte
Datenschutz: Individuelle Nutzerrechte werden garantiert
Datenbanksprachen (Query, SQL): als einfaches Interface zur Datenbank
WS 98/99; Simulation, Kp. 6 25
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Defizite existierender Datenbanksysteme -1
• Datenbanksysteme behandeln nur Fakten; die Kombination mit allgemeingültigen Regeln wird nicht unterstützt.
• Datenbanksysteme verwalten üblicherweise nur Daten als Ausprägungen fest vorgegebener generischer Typen (Relationen, Hierarchien, Sets u.ä.). Die Definition anwendungsspezifischer Typen mit ihren jeweiligen Operationen, Konsistenzbedingungen usw. wird nicht unterstützt.
Dementsprechend fehlen auch Möglichkeiten zur Einführung anwendungsspezifischer Zugriffspfade und Synchronisierungsverfahren.
• Heutige DBMS bieten meist nur eng begrenztes Leistungswachstum über die Kapazität eines Rechnerknotens hinaus, z.B. durch automatische Lastverteilung auf mehrere Rechner.
• Die Flexibilität verteilter DBMS ist immer noch relativ eingeschränkt, insbesondere im Hinblick auf die Verwaltung von Replikaten, dynamische Lastbalanzierung und automatische Konfigurations-anpassung.
WS 98/99; Simulation, Kp. 6 26
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Defizite existierender Datenbanksysteme -2
• Allgemeine verteilte Verarbeitungsmuster, wie langlebige Aktivitäten, Kooperation von Benutzern an verschiedenen Rechnern u.ä., werden nicht unterstützt.
• Die Unterstützung von Benutzern ohne DB-Kenntnisse ist mangelhaft.
• Die Einbettung der DB-Anfragesprache in eine normale Programmiersprache ist generell nicht gut gelöst.
• Die gezielte Optimierung einer DB-Anwendung auf unterschiedliche Lastprofile ist nur sehr eingeschränkt möglich.
• Den spezifischen Charakteristika von PCs und Workstations (hohe Autonomie, geringe Sicherheit) wird nicht ausreichend Rechnung getragen.
WS 98/99; Simulation, Kp. 6 27
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Anforderungen an Objekt-Management
Notwendige Konzepte (golden rules) nach Manifesto:Komplexe Objekte (Objekt-Konstruktoren)
Objektidentität
Objektkapselung (information hiding)
Objekttypen, Klassen
Typ-Hierarchien (einfache Vererbung)
Verfeinerung und dynamisches Binden von Operationen
Turing-Vollständigkeit
Erweiterbarkeit
Persistenz
Hintergrundspeicher-Verwaltung (Zugriffsunterstützung)
Mehrbenutzerkontrolle
Recovery
Ad-hoc-Anfragesprache
Dazu optimale Konzepte
spezifische Konzepte
WS 98/99; Simulation, Kp. 6 28
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Umgang mit Objekten
Datenmodellzur Beschreibung der Datenstrukturen
Verhaltensmodellzur Einbindung von Methoden
Persistenzmodellzur Verwaltung von Änderungen
Namensmodellzur Identifikation von Objekten
Dies erfordert
Verbindung von DB und Programmen
WS 98/99; Simulation, Kp. 6 29
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
ODB 1 - DatenmodellZusammengesetzte Objekte analog ADTs
Identität durch Namen (in Regel verborgen) nicht Inhalt
Generalisierung durch Beschreibung gleichartiger Datenobjekte (Mengen von Objekten) über ADTs
Vererbung zur besseren Strukturierung
Beispiel:
Zwei Objekte
Student (Name, Alter, Semester)
Angestellter (Name, Alter, Abschluß, Stellung)
werden dargestellt durch Basisklasse Person
Person (Name, Alter)
Student (Semester) Angestellter (Abschluß, Stellung)
und Unterklassen Student und Angestellter
WS 98/99; Simulation, Kp. 6 30
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
ODB 2 - Verhaltensmodelle
Kapselung von Daten und Methoden über Interface
DATA
PROGRAMS
Generalisierung durch Zusammenfassung von gleichartigen ADTs zu Klassen
Vererbung von Methoden (wiederbenutzbarer Code)
Late Bindung - Zuordnung von Methoden und Prozeduren zur Laufzeit
Vollständigkeit - alle Methoden können ohne externe Hilfsmittel realisiert werden
Erweiterbarkeit - Klassen aus Klassenbibliotheken können erweitert werden
WS 98/99; Simulation, Kp. 6 31
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
ODB 3 - Namensmodelle
Aufgabe Zugang zu DB
Identifikation der Objekte
Strategien
Relationale Strategie:
Jede Klasse kennt Menge ihrer Objekte
Zugang über Mengenname
Programmstrategie:
Jedes Objekt erhält eigenen Namen
Zugang über Objektname
Klassen-Orthogonalität
Jedes Objekt ist eindeutig identifizierbar
WS 98/99; Simulation, Kp. 6 32
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
ODB 4 - Persistenz
Das Persistenzmodell spezifiziert, wie lokale und permanente Objekte
erzeugt,
modifiziert,
vernichtet
werden.
Attribute können
immer (relationale DB),
in Abhängigkeit der Klassendefinitionen,
in Abhängigkeit der Objektidentität,
in Abhängigkeit der Erzeugermethode
persistent gemacht werden.
WS 98/99; Simulation, Kp. 6 33
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Verbindung Programmiersprache und DBMS
• Programm mit DB im KernspeicherPersistenz über Massenspeicher
Datenmodell ADT
Verhaltensmodell Programm
Namensmodell durch Entwickler oder Anwender
• Datenbank mit ProgrammiersprachePersistenz ist systematisch
Datenmodell ist beschränkt (z.B. Mengen und Tupel)
Verhaltensmodell fehlt
Namensmodell Relation hat Namen
• Kopplung von Programmen und DBMSZwei Prozesse, zwei Namensräume, zwei Programmierparadigmen
Zugang DB durch Prozeduraufrufe
Datenkonversion von Programm zu DB (meist verschiedene Datentypen)
Aber alle Lösungen können realisiert werden.
WS 98/99; Simulation, Kp. 6 34
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Was ist eine objektorientierte Datenbank ?
1. Ein objektorientiertes System mit den gleichen Charakteristiken wie C++.– Abstrakte Datentypen, Objekte, Nachrichten, Vererbung
2. Eine Datenbank mit den gleichen Datenbankfunktionen wie die kommerziell verfügbaren DBMSs.
– Speicherverwaltung, Transaktionen, Schema-Evolution, Anfragemöglichkeiten, Sicherheit
WS 98/99; Simulation, Kp. 6 35
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
OODB - Unterschiedliche Entwicklungsansätze für Anwendungen
WS 98/99; Simulation, Kp. 6 36
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Vergleich relational - objektorientiert
Relationale Datenbanken Objektorientierte Datenbanken
Primäres Ziel ist Datenunabhängigkeit Primäres Ziel sind Kapselung und Klassenunabhängigkeit
Unterschiedliche Entwurfsmodelle: Modell für Datenstrukturund Zugriff, repräsentiert durch Joins und Tabellen, istverschieden vom Modell aus Analyse, Design undProgrammierung
Konsistentes Modell: Modell für Analyse, Design undProgrammierung ist dasselbe. Anwendungen werden direktdurch Klassen der ODBMS repräsentiert.
Nur Daten werden gespeichert. Daten mit ihren Zugriffsfunktionen werden gespeichert.
Daten-Sharing stellt die Daten unterschiedlichen Prozessenzur Verfügung.
Kapselung der Daten stellt den Zugriff über geeigneteFunktionen sicher.
Datenbank ist passiv: starres, vorgeplantes Verhalten. Datenbank ist aktiv: Objekte umfassen Daten mitZugriffsfunktionen, die zustandsabhängig reagieren.
Jede Tabelle wird isoliert dargestellt. Joins legenBeziehungen fest.
Objekte können in beliebig komplexen Beziehungen(Vererbung, Teil_von) stehen.
SQL als Abfragesprache und zur Datenmanipulation. OO-Anforderung führt bei Anfrage Zugriffsfunktionen derObjekte aus. Als Standard dient ODMG-93.
Unterschiedliche Zugriffsmodelle: Modell für die Darstellungvon Zugriffen und Joins differiert von der Darstellung ausAnalyse und Design. Die Umsetzung übernimmt SQL.
Einheitliches Zugriffsmodell: Modell aus Analyse, Design undProgrammierung ist auch für die Darstellung von Zugriffenund Datenmanipulation gültig.
WS 98/99; Simulation, Kp. 6 37
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Wege der Entwicklung von OODBMS -2
• Relationale Systeme werden um objektorientierte Eigenschaften erweitert. Für den Anwender äußert sich das vor allem darin, daß die
Anfragesprache zusätzliche Konstrukte zur Strukturierung und Manipulation von Daten enthält.
• Objektorientierte Systeme werden um die positiven Eigenschaften des relationalen Modells erweitert.
• Interoperable Systeme, die keine Integration der Datenmodelle versuchen, sondern beide Systeme unverändert lassen und dem Anwender eine einheit-liche Sicht auf die unterschiedlichen Datenmodelle geben.
WS 98/99; Simulation, Kp. 6 38
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Wege der Entwicklung von OODBMS -2
Sind die Lösungswege äquivalent ?
Antwort: Nicht wirklich, da sie die Optimierungsaspekte auf unterschiedliche Schwerpunkte setzen.
WS 98/99; Simulation, Kp. 6 39
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Aussichten für OODBS -1
Auch wenn in den administrativen Anwendungen noch einige Zeit die relationalen Datenbanksysteme zum Einsatz kommen, paßt das objektorientierte Datenmodell in diesem Anwendungsbereich mindestens so gut wie das relationale.
Für den Erfolg objektorientierter Datenbanken spricht aber die gemeinsame Sprache von Systemanalytikern, Modellierern, Datenbank-Designern, so daß Ver-ständigungsprobleme wohl seltener werden.
Die Objektorientierung ist eine Mischung aus bewährten Ideen, so zum Beispiel die Kombination des ADTs mit der anwendungssystem-übergreifenden Daten-modellierung.
WS 98/99; Simulation, Kp. 6 40
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Aussichten für OODBS -2
Ob sich die Erweiterungen relationaler Datenbanksysteme oder objektorientierter Datenbanksysteme durchsetzen werden, ist heute nur schwer abzuschätzen.
Interoperable Systeme stellen zwar eine Art Ideallösung dar, ihre Verfügbarkeit wird allerdings noch ein paar Jahre dauern.
Daß Datenbanken in Zukunft aber objektorientierte Eigenschaften haben werden, ist sicher.
WS 98/99; Simulation, Kp. 6 41
Universität StuttgartIKE Institut für Kernenergetik
und Energiesysteme
Durchgängigkeit der Methodik -2
Stratege /Zieldefinition
Analyse
Design
Realisierung
Implementierung
Bruch
Bruch
abstrakte Zielfaktoren
konkrete Konstruktionselemente der Analyse Structured Analysis
Pseudo Code
Von der Zielumgebumgabhängige Generatoren
und Entwicklungs-Tools
technische Einflüsse und Optimierungsmaßnahmen
detaillierte, fachliche Beschreibungen
Phase
Die Brüche zeigen den Wechsel von einer Methode zu einer anderen. Meist bedeutet dies, daß bei Änderungen eines Entities der unteren Ebene nicht auf die Definitionen des entsprechenden Entities der darüberliegenden Ebene durchgegriffen werden kann.