Objektorientierte Datenbanken Ralf Möller, FH-Wedel Beim vorigen Mal: Anfragesprachen: SQL (kurz) Mehrbenutzerbetrieb und Sperren Transaktionen Anbindung an Programmiersprachen Probleme der relationalen Datenbanktechnologie Heute: Objektorientierte Modellierung

Probleme relationaler Datenbanktechnologie Zwar methodisch saubere aber schwierig zu lernende manuelle Umsetzung des Entwurfsmodells (ERM) in das Implementierungsmodell Zersplitterung von „zusammengehörigen Daten“ durch Normalisierung Joins bei navigierendem Zugriff sehr aufwendig Probleme bei Änderung des Datenmodells wegen fehlender Kapselung Impedance Mismatch Sprache für Integritätsbedingungen meist schwach (hier nicht vertieft)

„Zersplitterung“: Pointierte Darstellung Relationale Modellierung bedingt folgende Sicht: Bevor ein Auto in der Garage abgestellt werden kann, muß es in seine tausend Einzelteile zerlegt und in den dafür vorgesehenen Fächern ablegt werden. Bevor es wieder benutzt werden kann, ist ein komplizierter Zusammenbau erforderlich.

Impedance Mismatch Datenmodellierungsform in Programmiersprachen paßt nicht zu Form in Datenbanken Programmiersprachen: Record/Tupelorientiert Mit hoher Frequenz einfache Operationen durchführen Datenbanksysteme: Mengenorientiert Mit niedriger Frequenz komplexe Operationen durchführen [F. Matthes, J.W. Schmidt]

Objektorientierte Modellierung (1) Was ist ein Objekt? Zusammensetzung von Daten und Operationen Teile der Zusammensetzung sind durch Attribute gekennzeichnet Objekte haben einen Zustand Zugriff nur über wohldefinierte Schnittstellen (Kapselung) Objektspezifische Operatoren Objekte bekommen automatisch eine Identifikation (OID) Orthogonalitätsprinzip Zusammengesetzte Daten wie Elementardaten behandeln soweit sinnvoll Teile (Attributwerte) können wieder Objekte sein

Objektorientierte Modellierung (2) Setze- und Erfragefunktionen für Attributwerte als Spezialfall objektspezifischer Operationen Aktivierung von Operationen durch Nachrichten Software-Engineering-Prinzipien Kapselungsprinzip: Wer darf welche Attribute wo sehen/ändern? Wer darf welche Nachricht an wen senden? Interne Sicht (Attribute) vs. Externe Sicht (Nachrichten) Externe Sicht bedingt höheren Ressourcenverbrauch Festlegung der Attribute und Operatoren nicht für genau ein Objekt, sondern für eine Menge von Objekten gleicher Art Eine solche Menge von Objekten gleicher Art heißt Klasse (vgl. Entity in ERM)

Unified Modeling Language (UML) Der UML-Teil dieser Vorlesung enthält Material von Eckhardt Holz, Humboldt-Universität Berlin Als detaillierter Referenz sei auch „The Unified Modeling Language – Reference Manual“ empfohlen

UML Konzepte Objekte / Instanzen einer Klasse Klassen beschreiben die statische Struktur von Objekten / Instanzen Klassen sind gekennzeichnet durch: Name (aus dem Vokabular der Problemdomäne gewählt) Attribute (beschreiben die Struktur der Instanzen einer Klasse) Operationen (beschreiben das Verhalten der Instanzen einer Klasse) Objekte erzeugen: Instantiieren Automatische Vergabe einer OID

Statische Strukturdiagramme (1)

Basis-Datentypen Beschreibung des Wertebereich von Attributen Integer, short, ... Real String ...

Funktionalität ohne Struktur: Interfaces Nur Beschreibung der Nachrichten die an Objekte gesandt werden können, die das Interface implementieren (d.h. des Protokolls, das die Objekte unterstützen) Keine Beschreibung der Struktur der Objekte Auswahl der konkreten Struktur nach pragmatischen Gesichtspunkten zur Erzeugungszeit einer Instanz

Statische Strukturdiagramme (2)

Relationen: Graphische Notation Komposition Vgl. Relationships in ERM

Relationen: Beispiel für Komposition

Relationen in Strukturdiagrammen: Bedeutung Assoziationen, Aggregationen und Komposition modellieren auf Klassenebene Beziehungen zwischen Instanzen (der beteiligten Klassen) Generalisierungen modellieren Beziehungen zwischen Klassen (d.h. Mengen von Instanzen) Abhängigkeiten haben keine wohldefinierte Semantik

Relationen: detailliertere Beschreibung Multiplizität gibt an, wieviel Objekte an der Relation beteiligt sind Navigierbarkeit beschränkt den bidirektionalen Charakter von Relationen Constraints beschränken den Gültigkeitsbereich von Relationen Rollennamen beschreiben die Endpunkte der Relation

Relationen: Multiplizitäten

Klassen und Objektdiagramme (Beispiel) Kostet Erbringt Erbringt

Multiplizität Jedes Element von Klasse A steht mit mindestens i Elementen der Klasse B in Beziehung ... und mit maximal j vielen Klasse-B-Elementen Analoges gilt für das Intervall k..l Multiplizitätsangabe ist analog zur Funktionalitätsangabe im ER-Modell Nicht zur (min,max)-Angabe: Vorsicht!

Klassen und Assoziationen

Aggregation

Begrenzungsflächenmodellierung von Polyedern

Mehrstellige Relationen

Generalisierung Generalisierung ist eine Relation zwischen einer Superklasse und ihren Subklassen. Zwei Mechanismen: Generalisierung Spezialisierung Gemeinsame Attribute, Operationen und Relationen werden auf dem höchsten anwendbaren Hierarchieniveau gezeigt Generalisierungen können Namen haben (!)

Generalisierung (Beispiel)

Abstrakte Klassen Dienen auf Modellierungsebene zur Beschreibung gemeinsamer Eigenschaften (Attribute und Operationen) Werden nicht instantiiert

Generalisierung: Constraints overlapping, disjoint complete, incomplete

Generalisierung und Vererbung Attribute Vererbung „nach unten“ Sichtbarkeit steuerbar (public, protected, private) Operationen Dynamisches Binden bei Operationen mit gleichem Namen in Unterklasssen speziellste Operation (zuerst) anwenden

Assoziationen: Constraints Subset ...

Zusammenfassung, Kernpunkte UML-Objektbegriff, statische Struktur Objektorientierte Modellierung auf Entwurfsebene Klassen und Instanzen Attribute (inkl. Sichtbarkeit) Methoden Klassenbeziehungen Generalisierung, Zerlegung Auf Klassenebene beschriebene Instanzenbeziehungen Relationen: Komposition, Aggregate, Assoziationen

Was kommt beim nächsten Mal? Objektorientierte Modellierung, Teil 2 Umsetzung in Implementierungsmodell: Java