Simulation komplexer technischer Anlagen

Präsentation zum Thema: "Simulation komplexer technischer Anlagen"—  Präsentation transkript:

1 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

2 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

3 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

4 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

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

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

7 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

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

9 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

10 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.

11 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.

12 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).

13 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.

14 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

15 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.

16 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

17 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

18 Abstraktion und Mächtigkeit der Datenbank-Modelle

19 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

20 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

21 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

22 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

23 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.

24 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

25 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.

26 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.

27 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

28 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

29 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

30 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

31 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

32 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.

33 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.

34 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

35 OODB - Unterschiedliche Entwicklungsansätze für Anwendungen

36 Vergleich relational - objektorientiert

37 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.

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

39 Aussichten für OODBS 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.

40 Aussichten für OODBS 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.

41 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.