6 Implementierung komplexer Systeme 6.2 Datenbank-Anbindung Analyse Entwurf Implementierung Test, Integration Wartung Literatur: Balzert LE 24-26, 31 Ambler Kap. 10 Einsatz von Datenbanksystemen Persistente Daten Dateien Programmiersprachenspezifische Mechanismen Datenbanksysteme» relational» objektorientiert» andere, z.b. hierarchisch Anwendungsentwurf entkoppeln von Wahl des Persistenzmechanismus Altsysteme meist relationale oder hierarchische Datenbank Anbindung an moderne Anwendungsprogramme Seite 1
Vergleich RDBS - ODBS relationales DBS Wertidentität Schlüssel und Fremdschlüssel elementare Attributtypen sichtbare Attribute DB-Sprache (SQL) grundsätzlich separat von Programmiersprache Serverorientiert Persistente Daten objektorientiertes DBS Objektidentität komplexe Attributtypen Kapselung (nicht für lesende Zugriffe) Enge Integration zwischen DB-Sprache und Progr.spr. (PL-ODL) Clientorientiert Persistente und transiente Objekte Objektidentität Nachteile der Wertidentifikation von Objekten (Tupeln): Schlüsselattribute können Anwendungssemantik tragen» z.b. Kurzname in Firma : Namenswechsel einer Firma? Wertgleichheit (der Attribute) und Identität nicht unterscheidbar» z.b. grafische Objekte in einem Zeichenprogramm: Objekt 1: Kreis, Farbe blau, Koordinaten (1,1) Objekt 2: Kreis, Farbe rot, Koordinaten (2,1) Ändere Farbe von Objekt 2 in blau Verschiebe Objekt 2 um 1 nach links Verschiedene Objekte mit gleichen Attributwerten Vorteile einer reinen Objektidientifikation: Semantische Klarheit "Opaker" Typ verhindert versehentliche oder fahrlässige Manipulation "Smart Pointers" (Objekt-Caching) Seite 2
Objektorientiertes Design und RDBS Objektorientiertes Design (OOD) wegen Flexibilität und Zukunftssicherheit Relationales Datenbanksystem (RDBS) wegen vorhandener Altsysteme zur Vermeidung von Lizenzkosten und Schulungsaufwand Abbildung von OOD auf RDBS: Abbildung von Klassen auf Tabellen Behandlung von Attributen mit komplexen Typen Abbildung von Assoziationen und Aggregationen Abbildung von Vererbung Softwarehilfsmittel: "Objektrelationale Middleware" Abbildung von Klassen auf Tabellen In der Regel wird jede Klasse auf eine Tabelle abgebildet. Objektidentität wird durch eine zusätzliche Spalte aller Tabellen (surrogate) realisiert. Person Name Adresse Person PersonOID Name Adresse Primärschlüssel: PersonOID create table Person (PersonOID ID not null, name char(40) not null, adresse char(60) primary key (PersonOID)) Seite 3
Optimierungen Häufige Zugriffe über bestimmte Attribute als Sekundärschlüssel create secondary index Person-name on Person (name) Häufung von Zugriffen bei wenigen Objekten (z.b. Stammkunden): horizontale Unterteilung Stammkunden PersonOID Name Adresse Person PersonOID Name Adresse Häufung von Zugriffen bei bestimmten Attributen vertikale Unterteilung Person1 PersonOID Name Person2 PersonOID Adresse Attribute mit komplexen Typen Beispiel Attribut Adresse von Klasse Firma (in ODL): attribute struct AdresseT <String Straße, Integer HausNr, Integer PLZ, String Ort> Adresse; Neue Attributnamen: String AdresseStraße Integer AdresseHausNr Integer AdressePLZ String AdresseOrt Alternative: eigene Tabelle Adressen Eigene Tabellen nötig für Listentypen (ohne feste Grenzen) Seite 4
Abbildung von Assoziationen/Aggregationen 1:1- und 1:m-Assoziationen: OID-Fremdschlüsselattribut in der 'm-klasse' Firma ist Mitarbeiter von 0..1 0..* Kunde Kunde Funktion Umsatz FirmaOID Separate Tabelle Mitarbeiter KundeOID FirmaOID m:n-assoziationen: eigene Tabelle Behandlung von Aggregationen analog Abbildung von Vererbung Vier Ansätze: Je eine Tabelle für Ober- und Unterklassen Oberklassen-Attribute in Unterklassen aufnehmen Unterklassen-Attribute in Oberklassen aufnehmen Vererbungsbeziehung als eigene Tabelle» nur selten, z.b. Mehrfachvererbung mit überlappenden Oberklassen Beispiel: Person Name Adresse Kunde Funktion Umsatz Dozent Honorar Seite 5
Beispiel: Abbildung von Vererbung Je eine Tabelle für Ober- und Unterklasse: Person PersonOID Name Adresse 11 22 Huber Schmidt München Dresden Kunde PersonOID Funktion Umsatz 11 Entwickler 500 Art Kunde Dozent Dozent PersonOID Honorar 22 2000 Einfach und systematisch Gut geeignet für Mehrfachvererbung (aus disjunkten Klassen) Nachteil: Umständliche Navigation für bestimmte Attributwerte Beispiel: Abbildung von Vererbung Oberklassenattribute in Unterklassen aufnehmen ("many subclass approach"): Kunde PersonOID Name Adresse Funktion Umsatz 11 Huber München Entwickler 500 Dozent PersonOID Name Adresse 22 Schmidt Dresden Honorar 2000 Einfacher Zugriff auf Attribute Besonders günstig für abstrakte Klassen Einschränkungen z.b. Name als secondary index für alle Personen nicht möglich Seite 6
Beispiel: Abbildung von Vererbung Unterklassenattribute in Oberklassen aufnehmen ("one superclass approach"): Person PersonOID Art Name Adresse Funktion Umsatz 11 22 Kunde Dozent Huber Schmidt München Dresden Entwickler null 500 null Honorar null 2000 Schlecht strukturiert (keine "3. Normalform") Wenig speichereffizient (null-einträge) Nur geeignet bei wenigen Unterklassen mit wenigen Attributen Objekt-Relationale Middleware Objekte des Anwendungskerns O/R-Middleware RDBMS Abbildungsregeln (Typen für Attribute, Behandlung von Vererbung etc.) Zweiseitiger Entkopplungsmechanismus: Anwendungskern unabhängig von Wahl des Datenbanksystems Middleware einheitlich für alle speziellen Anwendungsklassen Realisierungsmöglichkeiten (Beispiele): Generierung einer anwendungsspezifischen Anpassungsschicht Universelle Schnittstellen (z.b. mit Java-Klasse "Object") Seite 7
Objekt-Relationale Middleware: Details Objekte des Anwendungskerns Laufzeit- Unterstützung Objekt-Cache Repository für anwendungsspezifische Abbildungsregeln RDBMS O/R- Middleware Typische Funktionen eines Middleware-Systems: Generierung von Abbildungsregeln aus (Java-)Klassendefinitionen Interaktive Verfeinerung der Abbildungsregeln Dynamische Modifikation der Abbildungsregeln über (Java-)API Generierung von SQL-DDL Schema aus Abbildungsregeln Generierung von Abbildungsregeln aus SQL-DDL-Schema Generierung von Klassenskeletten aus Abbildungsregeln Implementierungsalternativen Objektrelationale Middleware leistungsfähige und flexible Lösung teuer, komplex, Performanceverlust oft Teil der Infrastruktur (z.b. Application Server, EJB) Standardisierte DBMS-Schnittstellen z.b. SQL-Einbindung in Programmiersprache (Java: JDBC) Festlegung auf relationale Datenbanken mit passender Software Proprietäre DBMS-Schnittstellen unflexibelste Lösung Unter Umständen wegen Performance-Gewinnen sinnvoll Professioneller Softwareentwurf: Abwägen zwischen Alternativen Evtl. Entscheidung mit Experimenten absichern (experimentelles Prototyping) Seite 8