3 Folien/Seite
Werbung
6 Implementierung komplexer Systeme 6.2 Datenbank-Anbindung Analyse Entwurf Implementierung Literatur: Technische Universität Dresden Test, Integration Wartung Balzert LE 24-26, 31 Ambler Kap. 10 Prof. Hußmann Softwaretechnologie II 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 Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Vergleich RDBS - ODBS relationales DBS objektorientiertes DBS Wertidentität Schlüssel und Fremdschlüssel Objektidentität elementare Attributtypen komplexe Attributtypen sichtbare Attribute Kapselung (nicht für lesende Zugriffe) DB-Sprache (SQL) grundsätzlich separat von Programmiersprache Enge Integration zwischen DB-Sprache und Progr.spr. (PL-ODL) Serverorientiert Clientorientiert Persistente Daten Persistente und transiente Objekte Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Seite 1 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) Technische Universität Dresden Prof. Hußmann Softwaretechnologie II 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" Technische Universität Dresden Prof. Hußmann Softwaretechnologie II 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)) Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Seite 2 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 Person PersonOID Name Adresse Name Adresse • Häufung von Zugriffen bei bestimmten Attributen – vertikale Unterteilung Person1 PersonOID Name Technische Universität Dresden PersonOID Person2 Prof. Hußmann Adresse Softwaretechnologie II 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) Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Abbildung von Assoziationen/Aggregationen • 1:1- und 1:m-Assoziationen: – OID-Fremdschlüsselattribut in der 'm-Klasse' Firma 0..1 Kunde ist Mitarbeiter von 0..* Funktion Umsatz – Separate Tabelle Mitarbeiter KundeOID Kunde FirmaOID FirmaOID • m:n-Assoziationen: – eigene Tabelle • Behandlung von Aggregationen analog Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Seite 3 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 Dozent Kunde Funktion Umsatz Honorar Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Beispiel: Abbildung von Vererbung • Je eine Tabelle für Ober- und Unterklasse: Person Kunde Adresse Art PersonOID Name 11 Huber München Kunde 22 Schmidt Dresden Dozent PersonOID Funktion 11 Entwickler Dozent PersonOID 22 Umsatz 500 Honorar 2000 – Einfach und systematisch – Gut geeignet für Mehrfachvererbung (aus disjunkten Klassen) – Nachteil: Umständliche Navigation für bestimmte Attributwerte Technische Universität Dresden Prof. Hußmann Softwaretechnologie II 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 Honorar 22 Schmidt Dresden 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 Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Seite 4 Beispiel: Abbildung von Vererbung • Unterklassenattribute in Oberklassen aufnehmen ("one superclass approach"): Person PersonOID 11 22 Art Name Adresse Funktion Kunde Huber München Entwickler Dozent Schmidt Dresden null Umsatz Honorar 500 null null 2000 – Schlecht strukturiert (keine "3. Normalform") – Wenig speichereffizient (null-Einträge) – Nur geeignet bei wenigen Unterklassen mit wenigen Attributen Technische Universität Dresden Prof. Hußmann Softwaretechnologie II 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") Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Objekt-Relationale Middleware: Details Objekte des Anwendungskerns Objekt-Cache LaufzeitUnterstützung Repository für anwendungsspezifische Abbildungsregeln O/RMiddleware RDBMS • 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 Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Seite 5 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) Technische Universität Dresden Prof. Hußmann Softwaretechnologie II Seite 6
