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
Herunterladen