Simulation komplexer technischer Anlagen

Slides:



Advertisements
Ähnliche Präsentationen
Business Engineering Philipp Osl, Alexander Schmidt
Advertisements

Datenbankdesign mit ACCESS.
Datenbanken Einführung.
Folien 2-5, 7-8 © Prof. Dr. Manfred Rössle (FH Aalen)
spezielle Nutzersichten formale Ebene (deskriptive Regeln)
Datenmodellierung Externe Phase Informationsstruktur
Frame-Logik Eine Einführung Andreas Glausch.
Objektorientierte Datenbanken
Objekt – Relationales – Modell Tomasz Makowski IN
Kapitel 4 Datenstrukturen
Das Entity-Relationship-Modell
Java: Objektorientierte Programmierung
Anfragesprachen – Dipl. Ing. Ulrich Borchert / FH Merseburg1/7 Datenbanken werden als Anhäufung von Werten eines Wertebereiches aufgefasst und Datenbankabfragen.
DOM (Document Object Model)
AGXIS – Ein Konzept für eine generische Schnittstellenbeschreibung Dr.-Ing. Ulrich Hussels, RISA GmbH 07. Juni 2005 Workshop Umweltdatenbanken 2005.
Datenbankentwurf mit Hilfe des ER-Modells entwickeln
Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme
Datenbanken Christof Rumpf
EINI-I Einführung in die Informatik für Naturwissenschaftler und Ingenieure I Vorlesung 2 SWS WS 99/00 Gisbert Dittrich FBI Unido
Übung Datenbanksysteme UML
PKJ 2005/1 Stefan Dissmann Ausblick Es fehlen noch: Möglichkeiten zum Strukturieren größerer Programme Umgang mit variabler Zahl von Elementen Umgang mit.
PKJ 2005/1 Stefan Dissmann Rückblick auf 2005 Was zuletzt in 2005 vorgestellt wurde: Klassen mit Attributen, Methoden und Konstruktoren Referenzen auf.
PKJ 2005/1 Stefan Dissmann Zusammenfassung Bisher im Kurs erarbeitete Konzepte(1): Umgang mit einfachen Datentypen Umgang mit Feldern Umgang mit Referenzen.
Access 2000 Datenbanken.
Datenbanken Einführung Merkmale dateiorientierte Datenverwaltung
Normalformen Normalisieren Schlüssel
Seminar: Verteilte Datenbanken
6 Normalformen Normalisieren Schlüssel
Einführung Dateisystem <-> Datenbanksystem
Datenmodellierung - Aufbau einer Datenbank -
DVG Klassen und Objekte
RelationentheorieObjektorientierte Datenbanken AIFB SS Das ODMG-Objektmodell vs. relationales Modell (1/9) ODMG-Objektmodell Literal_type Atomic_literal.
Einführung und Überblick
Grundschutztools
... und alles was dazugehört
Visualisierung objektrelationaler Datenbanken
Simulation komplexer technischer Anlagen
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Objektmodellierung Objekte und Klassen Ein Objekt ist ein Exemplar.
Was umfaßt die CORBA Core Spezifikation? Welche zusätzlichen Komponenten muß ein ORB Produkt beinhalten? Core: CORBA Objekt Modell CORBA Architektur OMG.
Datenbank-entwicklungsprozess
Betrieb von Datenbanken Marco Skulschus & Marcus Wiederstein Datenmanipulation Lehrbuch, Kapitel 4.
OOP-Begriffe Abstraktion Modellieren Klasse Objekt Attribute Methoden
Überblick über die Datenbankproblematik
Vorlesung #2 Datenbankentwurf
SS 2010 – IBB4C Datenmanagement Fr 15:15 – 16:45 R Vorlesung #2 Datenbankentwurf.
Vorlesung #4 Überführung des ER-Modells in das relationale Modell
Vorlesung #4 Überführung des ER-Modells in das relationale Modell
Allgemeines zu Datenbanken
(D.h. „Hallo MausFans!“ auf Japanisch).
Replikation und Synchronisation
DI (FH) DI Roland J. Graf MSc (GIS) U N I V E R S I T Ä T S L E H R G A N G Geographical Information Science & Systems UNIGIS.
Paradigmenwechsel in der Unternehmensmodellierung Prof. Dr. Wolfgang Voigt Dipl.-Ing. Päd. Alexander Huwaldt UML Extrakt UML Seminar, Chemnitz
Freiwillige Feuerwehr der Stadt Perg
Relationales Datenmodell und DDL
verstehen planen bearbeiten
Normalisierungsprozess
Klassen und Klassenstruktur
1 Polymorphe Konsistenzbedingungen (1) Polymorphe Konsistenzbedingungen legen fest, welche Arten von Zustandsbeschränkungen nach einer Konkretisierung.
SS 2014 – IBB4C Datenmanagement Do 17:00 – 18:30 R Vorlesung #2 Datenbankentwurf.
Software Engineering Strukturierte Analyse
Einführung Dateisystem <-> Datenbanksystem
Datenbank System (DBS) - Warum?
Modellierung der Wirklichkeit
SS 2015 – IBB4C Datenmanagement Fr 17:00 – 18:30 R Vorlesung #2 Datenbankentwurf.
WS 2014/15 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #9 SQL Zusammenfassung.
Vom Konzept zur Datenbank
SQL Basics Schulung –
Kapitel 6: Datenbanksysteme
Von Wietlisbach, Lenzin und Winter
Von Wietlisbach, Lenzin und Winter
 Präsentation transkript:

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

Vorbemerkungen Problemstellung Ziel der Vortragseinheit Literatur Objekte 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 Vortragseinheit Zunächst werden wichtige Eigenschaften moderner Datenbanken aufgeführt. Vor diesem Hintergrund werden dann Forderungen an objektorientierte Datenbanksysteme (Manifesto) erläutert. Literatur Atkinson, 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.

Grundbegriffe Datenbank = Datenbasis + DBMS 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 - Datenbankentwurf Zusammenfassung von Daten in Datenobjekte Konsistenz Daten in einer Datenbasis beschreiben, Weltausschnitte der Anwendung vollständig und widerspruchsfrei Mehrfachbenutzerbetrieb Konkurrierende Zugriffe beeinträchtigen Integrität der Datenbasis nicht Datensicherung - Transaktionskonzept Fehler bei System und Bedienung stören Unverletzlichkeit der Daten nicht Datenbank = Datenbasis + DBMS

Verbindung von Programmen und Daten Traditionelle Modellierung Programm verwendet nur eigene Daten verwaltet seine Daten stellt elementare Operationen bereit Programm: Daten: restliche Interpretation elementare Datentypen Semantik der Daten elementare Datenstrukturen elementare Operationen

Verbindung von Programmen und Daten Datentausch über Files Daten können von mehreren Programmen verwendet werden Dateiformat, Dateiname, Zugriffsstruktur aller Programme bekannt (Schnittstelle)

Verbindung von Programmen und Daten Datentausch über Datenbank Standardisierte Zugriffsmechanismen Datenwartung und Datenhaltung unabhängig vom Programm Datenbanken können verteilt sein

Daten in ingenieur-wissenschaftlichen Anwendungen Datenarten Stammdaten Primärdaten abgeleitete Daten Zu beschreibende Objekte umfangreich komplex strukturiert leicht veränderbar (Entwurfsvarianten) leicht kombinierbar (Konfiguration) leicht erweiterbar (Entwicklung) Datenquellen und Verarbeitung räumliche Verteilung organisatorische Verteilung zeitliche Verteilung erfordern große Zahl von Schnittstellen Zusammenfassung vielfältige Strukturen mit relativ wenigen Datenobjekten gleicher Struktur

Datenmodelle Abstraktionsmechanismen zur Abbildung eines Weltausschnitts strukturelle Aspekte - Datentypen - Konstruktoren funktionale Aspekte - Operatoren Beispiele gebräuchlicher Datenmodelle abstrakte Datentypen Objekte hierarchisches Modell Relationen-Modell

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

Das relationale Modell - Glossar Relationale 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. RDBMS Relationale Datenbank-Management-Systeme Tabelle Bei 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. Basistabellen Basistabelle 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üssel Der 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). INDEX Ein 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. VIEW Views 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.

Das relationale Modell Entität Unterscheidbare 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.

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. Relationship beschreibt Beziehungen zwischen Entitäten (im Entity-Relationship-Modell können auch Beziehungen Eigenschaften haben).

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. 1. Normalform (NF) einer Relation.

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

Das relationale Modell Index dient zur beschleunigten Datensuche (index-sequentiell). View sind 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.

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

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

Abstraktion und Mächtigkeit der Datenbank-Modelle

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

Charakteristika von DBMS Datenintegration alle Daten unter einem Dach Datenstrukturierung - Datenmodellierung Datenbankentwurf kann anwendungsbezogen erfolgen Konsistenz Weltausschnitte der Anwendung vollständig und widerspruchsfrei Mehrbenutzerbetrieb konkurrierende Zugriffe beeinchträchtigen Integrität der Datenbasis nicht Datensicherung - Transaktionskonzept Fehler bei System und Bedienung stören Unverletzlichkeit der Daten nicht Datenunabhängigkeit Programm unabhängig von Lokalität der Daten und ihrer strukturellen Interpretation

Konsistenz Logisch richtige und widerspruchsfreie Modellierung - physikalische Gesetze - technologische Grenzen - Auftragsmerkmale Lokale Konsistenz Konsistenz eines Objekts Globale Konsistenz Konsistenz eines Systems Modifikationen des Transaktionskonzepts - Zugriffssynchronisation - Konsistenzsicherung - Datensicherung

Transaktionskonzept System übernimmt Verantwortung für korrekte und vollständige Abarbeitung einer Sequenz von Datenbankoperationen Beispiel 1: Normalfall BOT SELECT ... UPDATE ... INSERT ... COMMIT ... Beispiel 2: Freiwilliger Abbruch BOT SELECT ... ROLLBACK ... Beispiel 3: Erzwungener Abbruch BOT INSERT Systemfehler

Transaktionskonzept ACID-Prinzip Atomicity: 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.

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

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.

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.

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

Umgang mit Objekten Datenmodell Verhaltensmodell Persistenzmodell zur Beschreibung der Datenstrukturen Verhaltensmodell zur Einbindung von Methoden Persistenzmodell zur Verwaltung von Änderungen Namensmodell zur Identifikation von Objekten Dies erfordert Verbindung von DB und Programmen

ODB 1 - Datenmodell Zusammengesetzte 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

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

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

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.

Verbindung Programmiersprache und DBMS Programm mit DB im Kernspeicher Persistenz über Massenspeicher Datenmodell ADT Verhaltensmodell Programm Namensmodell durch Entwickler oder Anwender Datenbank mit Programmiersprache Persistenz ist systematisch Datenmodell ist beschränkt (z.B. Mengen und Tupel) Verhaltensmodell fehlt Namensmodell Relation hat Namen Kopplung von Programmen und DBMS Zwei 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.

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

OODB - Unterschiedliche Entwicklungsansätze für Anwendungen

Vergleich relational - objektorientiert

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.

Wege der Entwicklung von OODBMS -2 Sind die Lösungswege äquivalent ? Antwort: Nicht wirklich, da sie die Optimierungsaspekte auf unterschiedliche Schwerpunkte setzen.

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.

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.

Durchgängigkeit der Methodik -2 Phase Stratege /Zieldefinition abstrakte Zielfaktoren Bruch konkrete Konstruktionselemente der Analyse Analyse Structured Analysis Design Pseudo Code detaillierte, fachliche Beschreibungen Bruch Realisierung Von der Zielumgebumg technische Einflüsse und Optimierungsmaßnahmen Implementierung abhängige Generatoren und Entwicklungs-Tools 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.