2 Grundkonzepte objektbasierter Datenbanksysteme - Public.fh ...

FachhochschuleBraunschweig/WolfenbüttelDipl.-Inform. Holger MärtensObjektbasierte DatenbankenSS 2008Seite122 Grundkonzepte objektbasierter Datenbanksysteme[Geppert]• "objektbasiert" = objektorientiert (OO) oder objektrelational (OR)• zunächst grundlegende Eigenschaften von Objekten (im Sinne der OO-Programmierung (OOP)), dann allgemeine Ansätze zur Einbettung in DBMS• detailliertere Besprechung von OODBMS und ORDBMS in Kap. 4 bzw. 5• Notwendigkeit der Erweiterung des Datenmodells bereits besprochen → Kap. 12.1 Objektorientierung• Begriffe in der OO-Programmierung:o allgemeine OO-Prinzipien festgelegt in sog. Metamodellen,syntaktisch umgesetzt durch Sprachen entspricht (in DB-Terminologie) dem Datenmodello Modell = konkrete Definition einer Menge von Klassen etc. entspricht dem DB-Schemao Begriff "Modell" widersprüchlich verwendet hier: wie in DB-Terminologie2.1.1 Objekte• prozedurale Programmierung (ebenso wie relationales Datenmodell) gekennzeichnetdurch Trennung von Daten und Funktionen/Prozedureno widerspricht der menschlichen Wahrnehmungo erschwert Abbildung des zu modellierenden Umweltausschnitts imRechner• verbesserte Konzeptualisierung durch Objektorientierung [Geppert, Abb. 2-3]o ein Objekt repräsentiert einen (realen oder abstrakten)Umweltgegenstand mit möglichst all seinen (relevanten) Eigenschaften• Objekte besitzeno Zustand = Menge von Attributwerteneinfache Attribute aus Basistypen (int, real, char, string, …)zusammensetzte Attribute durch Konstruktoren (Menge, Liste,Tupel, …)o Verhalten = Operationen, Methoden Interaktion zwischen Objekten durch Nachrichten Nachricht bewirkt Ausführung der entsprechenden Methode Methoden haben (optional) Eingabeparameter undRückgabewerte mit Typen• impliziter Eingabeparameter: das Objekt, dessen Methodeausgeführt wird• Name + formale Parameter + Ergebnistyp = Signaturo Identität = eindeutige Identifizierung und Unterscheidung von anderenObjekten Objekt trägt Objektidentifikator (Objekt-ID, OID)• systemweit eindeutig, während Objektlebensdauer konstant• systemverwaltet, trägt keine Semantikunabhängig von Zuständen (im Unterschied z.B. zum relationalenModell, das Tupel durch ihre Schlüsselwerte identifiziert)vermeidet künstliche Primärschlüssel wie in RDBSIdentität vs. Gleichheit:• Identität: dasselbe Objekt/dieselbe OID

FachhochschuleBraunschweig/WolfenbüttelDipl.-Inform. Holger MärtensObjektbasierte DatenbankenSS 2008Seite13• Gleichheit: gleicher Zustand (Attributwerte) Zuweisungssemantik: referenzbasiert vs. wertebasiert tiefes vs. flaches Kopieren (deep copy, shallow copy)• Kapselung (encapsulation; information hiding)o Zustand eines Objektes für andere Objekte i.a. nicht sichtbar (strikteKapselung) und nur durch Methoden zu lesen oder zu ändern→ Attribute sind "privat"o vgl. abstrakte Datentypeno Kapselung kann eingeschränkt werden (z.B. lesende Zugriffe erlaubt)oder ganz aufgehoben werden ("öffentliche" Attribute)2.1.2 Klassen• Klassen [Geppert, Abb. 2-4, 2-5]o fassen "ähnliche" Objekte (mit gleichem Verhalten und gleichstrukturierten Zuständen) zusammeno Klassendefinition legt somit mögliche Zustände (Attribute undWertebereiche) und Verhalten ihrer Objekte festo Objekte sind Instanzen ihrer Klasse; Erzeugung eines neuen Objektsinstantiiert die Klasseo Intension einer Klasse = Menge ihrer möglichen Instanzen gemäßKlassendefinitiono Extension einer Klasse = Menge der existierenden Instanzen zu einemZeitpunkto Konstruktoren erzeugen neue Instanzen und inititalisieren ihren Zustand• Klassenattribute (statische Attribute)o stets gleich für alle Elemente einer Klasseo aber veränderbar (z.B. Zinssatz für alle Sparkonten einer Bank)o nicht an bestimmte Instanz gebunden• Klassenmethoden (statische Methoden)o analog zu Klassenattributeno Konstruktor ist spezielle Klassenmethode2.1.3 Vererbung• Vererbung (inheritance) [Geppert, Abb. 2-6, 2-8]o Objekte können anderen ähnlich sein, aber z.B. gewisse Einschränkungenoder zusätzliche Eigenschaften aufweiseno Klasse solcher Objekte ist Spezialisierung der allgemeineren Klasse underbt all ihre Eigenschaften (Struktur und Verhalten)Vererbung von Superklasse (Oberklasse) auf Subklasse(Unterklasse)o Substituierbarkeit: Instanzen der Subklasse können alle Operationenausführen, die für Superklasse definiert sind (+ zusätzliche), und sindüberall einsetzbar, wo Instanzen der Oberklasse verlangt sind Folgerung: Elemente der Superklasse können heterogen sein!o Klassifikation: Instanzen der Superklasse werden durch Subklassen inKategorien eingeteilt "feinster Typ" eines Objektes = am weitesten abgeleitete Klasse C,der das Objekt angehört (d.h. es ist nicht Instanz einer Subklassevon C)• auch: feinste Klasse, dynamischer Typ (most specific type,most derived class, dynamic type/class)o Spezialisierung: Subklassen können zusätzliche Eigenschaften definieren

FachhochschuleBraunschweig/WolfenbüttelDipl.-Inform. Holger MärtensObjektbasierte DatenbankenSS 2008Seite14 Alternative: Subklassen werden durch Bedingungen aufexistierenden Attributen bestimmt, z.B. durch Einschränkung desWertebereichso nicht alle diese Varianten in jedem Objekt(meta)modell abgedeckt• Mehrfachvererbung (multiple inheritance) [Geppert, Abb. 2-7]o Subklasse kann von zwei oder mehr Superklassen erbeno dabei mögliche Konflikte durch Attribute gleichen Namens oderMethoden gleicher Signatureinfacher Fall: Vererbung derselben Eigenschaft entlang mehrererPfade aus gemeinsamer "Ober-Oberklasse"(z.B. TeachingAssistant von Person) sonst Auflösung z.B. durch Auswahl oder Umbenennungo Mehrfachvererbung deshalb in vielen Modellen/Sprachen ausgeschlossen z.B. Java, SQL:1999, ODMG• Polymorphieo allgemein: Verwendung eines Operators in unterschiedlichen Kontexten,z.B. "+" für Ganzzahl, Fließkommazahlen, Strings korrekte Operation dann durch Typen der Argumente bestimmt statische Polymorphie, erkennbar durch Compilero in OOP: gleicher Name für verschiedene Methoden derselben Klasse aber unterschiedliche Signatur (Parameteranzahl, -typen) auch: Überladen (overloading)o Spezialform: Überschreiben von Methoden gleicher Signatur durchSubklasse bei Substitution von Subklasseninstanzen für Superklassen soll dieMethode des feinsten Typs verwendet werden dies kann nur zur Laufzeit erkannt werden dynamische Polymorphie = "spätes Binden" (late binding)2.1.4 Abstrakte Klassen und Schnittstellen• abstrakte Klasseno = Klassen, die niemals direkt, sondern nur in ihren Subklassen instantiiertwerdeno Definition allgemeiner Eigenschaften (Attribute und Methoden), die inallen Subklassen vorhanden solleno d.h. Implementierung von Struktur und Verhalten• Schnittstellen (interfaces)o ähnlich wie abstrakte Klasseno definieren aber nur Verhalten (Methoden)o keine Vorgaben für Implementierung, sondern nur SignaturenImplementierung allein den von der Schnittstelle abgeleiteten sog.Implementierungsklassen vorbehalteno (ggf. mehrfache) Vererbung von Schnittstellen an Klassen oder an andereSchnittstellen2.1.5 Objektbeziehungen• Beziehungen [Geppert, Abb. 2-9]o repräsentieren Zusammenhänge zwischen Objekteno werden auf Klassenebene definiert und für einzelne Objekte instantiierto realisiert mit Hilfe der Objektidentifikatoreno allgemeine Beziehungen verbinden zwei oder mehr Objekte

FachhochschuleBraunschweig/WolfenbüttelDipl.-Inform. Holger MärtensObjektbasierte DatenbankenSS 2008Seite15 sind bidirektional (bzw. multidirektional) erlauben Navigation zwischen Objekteno Referenzen gerichtete Beziehungen (unidirektional) referenziertes Objekt "weiß" nicht, daß es referenziert wirdo Aggregation Bildung komplexer Objekte aus Unterobjekten Unterobjekte haben (im Gegensatz zu Attributen) selbstObjekteigenschaften (Identität, Zustand, Verhalten) Arten von Unterobjekten:• existenzabhängig oder -unabhängig• teilbar oder exklusiv• Komposition: exklusiv und (meist) existenzabhängigo Ergebnis: komplexes Beziehungsgeflecht wichtiges Kriterium: Erreichbarkeit von Objekt durch Navigationüber Beziehungeno weitere Beziehungsart: wertebasiert typisch für Nicht-OO-Systeme z.B. einzige Assoziationsmöglichkeit in relationalen DBS widerspricht dem Gedanken der Objektidentität• Typkonstruktoren [Geppert, Abb. 2-10]o Konstruktion komplexer Objektstrukturen aus einfachen Basistypeno typische Konstruktoren: Tupel: Zusammenfassung mehrerer Attribute unterschiedlicherTypen Menge, Liste, Array: Sammlungen homogener Elemente(Kollektionstypen) Referenz: Verweis auf Objekt UnterobjekteTabelle 2-1: Eigenschaften gebräuchlicher TypkonstruktorenTypo möglichst orthogonal zueinander, d.h. in beliebiger Kombination(rekursiv) verwendbar z.B. "Menge von Referenzen auf Listen mit Unterobjekten…" Beispiel: [Rahm, Folie 4-15]2.2 Objekte in DatenbankenAnzahlElementeDuplikateOrdnungHeterogenitätElementzugriffSET — — — variabel IteratorBAG √ — — variabel IteratorLIST √ √ — variabel Iterator/IndexARRAY √ √ — konstant IndexTUPLE √ √ √ konstant Name• Schwächen des relationalen Datenmodells bei der Abbildung komplex strukturierterObjekte• impedance mismatch (Fehlanpassung, "semantische Lücke") zwischenProgrammiersprachen und DBMS

FachhochschuleBraunschweig/WolfenbüttelDipl.-Inform. Holger MärtensObjektbasierte DatenbankenSS 2008Seite16o mengenwertige, deklarative Anfragesprache (DBMS) vs.satzweise, prozedurale Verarbeitung (Anwendung)o Einbettung der Datenbanksprache in die Programmierspracheo abweichende Typsystemeo Abbildung von Programmdaten auf Tupel des DBSbesonders schwierig bei komplex strukturierten Daten in sog."Nichtstandardanwendungen", z.B. aus Ingenieur- undNaturwissenschafteno Struktur in DBS, Verhalten in Anwendung modelliert• Lösungsvorschlag: objektorientierte Konzepte in DBS aufnehmeno reduziert impedance mismatch v.a. gegenüber OO-Programmierspracheno erlaubt mehr Semantik innerhalb der Datenbank (Vererbung, Identität,Verhalten)o effizientere Programmentwicklung und -ausführung• diverse Entwicklungen in den 80er Jahren ohne einheitliche Konzepteo strukturell objektorientierte Datenmodelle (Komplex-Objekt-Modelle) komplexe Datenstrukturen, aber kein benutzerdefiniertesVerhalten z.B. (NF)², MAD, … → Kap. 1.4o verhaltensmäßig objektorientierte Datenmodelle benutzerdefinierte, typspezifische Operationen, aber nursatzorientierte Elementstrukturen Mächtigkeit entspricht etwa relationalem Datenmodell + StoredProcedureso voll objektorientierte Datenmodelle komplexe Strukturen + definierbares Verhalten "echte" OODBMS• 1989: Versuch einer allgemeinen Definition als gemeinsame Basis im"objektorientierten Datenbank-Manifest" (Atkinson et al.: The Object-OrientedDatabase System Manifesto. Proc. 1st Int. Conf. on Deductive and Object-OrientedDatabases, Kyoto, 1989)o geprägt von Konzepten der OO-Programmierung Anforderungen von Nichtstandardanwendungen Erfahrungen mit frühen OODBSo Definition von OODBMS als DBMS mit einem objektorientiertenDatenmodell (OODM) alle bewährten Eigenschaften von DBMS +Modellierungsmächtigkeit der OO-Programmierung2.2.1 Eigenschaften objektbasierter DBMS• Festlegung im OODB-Manifest (s.o.)• notwendige OO-Eigenschaften:o Objekte und Objektidentitäto komplexe Objekteo Typen/Klasseno Kapselungo Klassenhierarchieno Sprachvollständigkeit Datenmanipulationssprache (DML) muß berechnungsvollständigsein, d.h. jeden berechenbaren Algorithmus formulieren können z.B. nicht erfüllt für SQL (ohne prozedurale Erweiterungen)

FachhochschuleBraunschweig/WolfenbüttelDipl.-Inform. Holger MärtensObjektbasierte DatenbankenSS 2008Seite17• z.B. Problem der transitiven Hülle (→ Kap. 1.1)o Überschreiben, Überladen, spätes Bindeno Erweiterbarkeit Unterstützung benutzerdefinierter Typen/Klassen undGleichbehandlung innerhalb des DBMS in relationalen DBS nur vorgegebenes Typsystem• notwendige DBMS-Eigenschaften:o Persistenzo Sekundärspeicherverwaltungo Mehrbenutzerbetriebo Wiederanlauffähigkeit (Recovery)o Anfragesprache möglichst deklarativ, z.B. SQL-ähnlich in frühen OODBMS nicht vorgesehen• optionale OO-Eigenschaften:o Mehrfachvererbung• optionale DBMS-Eigenschaften:o Verteilung Kopplung mehrerer DBS in Netzwerk für Benutzer möglichst transparento Entwurfstransaktionen lange TAen (Stunden, Wochen, Monate) inNichtstandardanwendungen komplexe Struktur (z.B. verschachtelt) Kooperation zwischen Benutzern/Entwerferno Versionen Revisionen: (zeitliche) Entwicklung eines Entwurfsobjektes Konfigurationen: Zusammensetzung eines Entwurfsobjektes ausanderen Entwurfsobjekten Varianten: unterschiedliche Möglichkeiten zum Erreichen einesEntwurfsziels2.2.2 Varianten der Realisierung• OODB-Manifest umschreibt gewünschte Eigenschaften objektbasierter DBMS, läßtaber Art der Implementierung und genaues Datenmodell offen• (mindestens) drei grundlegende Ansätze: [Geppert, Abb. 2-11]o objektorientierte DBMS (OODBMS) "revolutionärer" Ansatz: komplette Neuentwicklung von Modellenund Systemen Wurzeln hauptsächlich in der OO-Programmierung (persistenteProgrammiersprachen) DB-Funktionalität nur konzeptionell von bisherigen RDBMSübernommen große Freiheiten bei der Entwicklung → enge Anlehnung anOODB-Manifest nahtlose Integration in OO-Programmiersprachen (C++, Smalltalk,Java) besonders geeignet für stark OO-geprägte (Nichtstandard-)Anwendungen, z.B. CAD, CASE, Geoinformationssysteme (GIS),wissenschaftliche Anwendungen, … zunächst wenig ausgereift, inzwischen stark verbessert

FachhochschuleBraunschweig/WolfenbüttelDipl.-Inform. Holger MärtensObjektbasierte DatenbankenSS 2008Seite18 Standardisierung durch die Object Data Management Group(ODMG) zahlreiche Produkte auf dem Markto objektrelationale DBMS (ORDBMS) "evolutionärer" Ansatz: allmähliche Weiterentwicklungrelationaler DBMS• können weiter als rein relationale Systeme verwendetwerden• ermöglicht langsame Migration für Anwender realisieren alle Anforderungen des OODB-Manifests Grundkonzept "benutzerdefinierte Typen" als Erweiterung desrelationalen Modells• zunächst nur strukturell erweitert, d.h. ohne Verhalten• später auch benutzerdefinierte Funktionen u.dgl.• schließlich mit allen Eigenschaften von Klassen: Vererbung,Identität, Verhalten, …• nach wie vor in Tabellen organisiert Standardisierung der notwendigen SQL-Erweiterungen in SQL:1999o objektorientierte Aufsätze: OO-Sicht auf relationale DBS Abbildungswerkzeuge: z.B. JavaBlend• Abbildung relationaler Schemata auf Java-Klassen (undumgekehrt) Gateways: Zugriff auf relationale Datenbestände über OODBMS2.3 Beispielanwendung2.3.1 Entwicklung objektbasierter Datenbankanwendungen• allgemeines Vorgehen durchläuft ähnliche Phasen wie im relationalen Fall, jedochzum Teil mit anderen Werkzeugen und Modellen• hier nur kurzer Überblick zur Positionsbestimmung in nachfolgenden Abschnitten2.3.1.1 Entwicklungsphasen• Analyseo Schwerpunkt: Bestimmung und Beschreibung des Anwendungsbereiches(Miniwelt) Was wird modelliert?o Ergebnis: Problembeschreibung als Ausgangspunkt der nächsten Phase(Grenze oft fließend)• konzeptioneller Entwurfo Schwerpunkt: abstrakte Modellierung der Miniwelt Wie wird modelliert? betrachtete Elemente:• Klassen (Zustände, Verhalten, Zustandsübergänge,(statische) Konsistenzbedingungen)• Beziehungen (Assoziation, Spezialisierung, Aggregation;Kardinalitäten)• Wertebereiche• Anwendungen (Abläufe, Ereignisse, (dynamische)Konsistenzbedingungen, Transaktionen)o oft mit graphischem Entwurfswerkzeug, z.B. UML-basiert

FachhochschuleBraunschweig/WolfenbüttelDipl.-Inform. Holger MärtensObjektbasierte DatenbankenSS 2008Seite19 Datenbankaspekte wie Persistenz, Extensionen, Transaktionen,Konsistenzbedingungen, Sichten oft schlecht unterstützt Erweiterungen nötig (z.B. durch DBMS-Hersteller oder manuell)o Ergebnis: konzeptionelles Schema, z.B. in erweiterter UML-Notation• logischer Entwurfo Schwerpunkt: Modellierung der Miniwelt in Datenmodell und Sprache(DDL) des Zielsystems Klassen, Klassenhierarchien, Wertemengen, Extensionen Import anderer Schematao möglichst (teil)automatisiert aus konzeptionellem Schemao Ergebnis: logisches Schema in DDL• Implementierungo Schwerpunkt: Implementierung des Systemverhaltens (Klassenmethodenund Anwendungsprogramme) Klassenmethoden im logischen Schema nur durch Signaturbeschrieben Sprache: DML des DBMS bzw. Programmiersprache derAnwendung• in OODBMS oft identischo möglichst durch Entwicklungsumgebung unterstützto Ergebnis: Code für Methoden und Anwendungen• physischer Entwurfo Schwerpunkt: Optimierung der Systemleistung physische Speicherungsstrukturen, Fragmentierung, Clusterung Zugriffspfade (Indexe)o teils automatisch in Implementierungsphase erledigt (systemabhängig)o Ergebnis: physische Datenbasis• Betrieb/Wartungo Schwerpunkt: Anpassung von Funktionalität und Systemleistung aufgrund neuer Anforderungen → neuer konzeptioneller/logischerEntwurf (Schemaevolution) wegen nachlassender Leistung bei wachsendem Datenbestand,hoher Zugriffslast etc. → neuer physischer Entwurfo Ergebnis: überarbeitete Schemata/Implementierung2.3.2 Beispiel-Datenbankanwendung• Publikationsverzeichnis einer Forschungsgruppe mit Web-Zugriffo als Kopie zum Skript verteilt [Geppert, Kap. 3.8]o deckt Entwicklungsphasen 1 und 2 ab• durchgängiges Beispiel in Kap. 3 und 4o Entwicklungsphasen 3 und 4 jeweils dort behandelt