IFS2 M2

Transparenz
Interoperabilität
Skalierbarkeit
Transaktionen
Optimierung
 

Applikationsentwickler arbeiten in gleicher Weise mit transienten und persistenten Objekten
 

Persistente Objekte können auch in anderen als der
Erstellungsumgebung verwendet werden

 Speicherung ist vom konkreten Persistenzmechanismus unabhängig

Laufzeitumgebung und persistenter Speicher sind austauschbar
 

Auffinden von persistenten Objekten erfolgt ohne vollständiges Durchsuchen des “Objektpools"
 

Wandle Objekte in einen Bytestrom um

Lege Bytestrom in einer Datei ab
 

Nicht gegeben – Klassen müssen von Hand serialisiert/
deserialisiert werden
 

Nein. Feste Bindung an Java (sogar spezielle Versionsbindung)

Nicht gegeben – Objekte müssen vollständig (inkrementelles Laden nicht möglich) im Hauptspeicher deserialisiert werden, um Bedingungen testen zu können
 

Nein

Persistenz durch explizite Kennzeichnung

• Explizite Kennzeichnung persistenter Klassen in einer Konfigurationsdatei
• Bei Instanziierung eines Objekts wird explizit entschieden, ob die Instanz persistent oder transient sein soll

Persistenz durch Erreichbarkeit

• Zu Beginn wird ein „Wurzelobjekt“ in das Programm geladen
• Alle anderen Objekte sind persistent, wenn sie von diesem „Wurzelobjekt“ aus erreicht werden können

Persistenz durch Vererbung

• Alle Instanzen einer Klasse, die von einer bestimmten „Wurzelklasse“ erbt

Alle Instanzen einer Klasse, die von einer bestimmten „Wurzelklasse“ erbt

• Zu Beginn wird ein „Wurzelobjekt“ in das Programm geladen
• Alle anderen Objekte sind persistent, wenn sie von diesem „Wurzelobjekt“ aus erreicht werden können

• Explizite Kennzeichnung persistenter Klassen in einer Konfigurationsdatei
• Bei Instanziierung eines Objekts wird explizit entschieden, ob die Instanz persistent oder transient sein soll

Transparenz – kein Paradigmenbruch bei Speicherung

•  Abbildung komplexer Objekte wesentlich einfacher als in RDBS
• Relationale Modellierung und Mapping entfällt

Performance-Vorteile bei sehr komplexen Modellen

• Gute Eignung für große Objekte („BLOBs“)

ODBS deutlich weniger verbreitet als RDBS

•  „Einsatzrisiko“
•  Immense Datenbestände in relationaler Form vorhanden
• Oft ist ein gemeinsamer Zugriff mit anderen nicht OO-Systemen auf gemeinsame Datenbanken nötig (Umgang mit Altlasten)

DB-Unabhängigkeit u. Abfragesprachen mangelhaft

•  Typsystem einer Programmiersprache wird als Datenbankmodell verwendet, oft Low-Level Programmierung
• Oftmals keine Sichten, Rechtevergabe

ODBS halten sich nur bedingt an den Standard

•  erschwert Interoperabilität und Migration auf ein anderes ODBS

1. Bilde Klassen und Beziehungen auf Relationenschema ab
2. Speichere Objekte in RDBS mit diesem Schema
    

• Speicherverbrauch
• l Einfacher Zugriff auf alle Objekte einer Klasse (Extension)
• l Einfacher Zugriff auf alle Attribute einer Klasse (Intension)
• l Konsistenzsicherung
• l Inserts/Updates
   

1. Union: 1 Tabelle
2. Vertikale Zerlegung: 1 „schmale“ Tabelle pro Klasse
3. Horizontale Zerlegung: 1 „breite“ Tabelle pro Klasse
    

Vorgehen

•  Obertyp und Untertypen werden in einer einzigen Relation zusammengefasst
•  Ein Attribut bestimmt den Untertyp einer Entität
•  Entität, die nicht zu einem der Untertypen gehört, hat für die spezifischen Attribute dieses Untertyps Nullwerte

Vorgehen

• Jeder Entitätstyp wird entsprechend der Attribute in der IST-EIN-Hierarchie zerlegt und in Teilen in den zugehörigen Relationen gespeichert
• Es wird nur der Primärschlüssel dupliziert
   

Vorgehen

•  Jeder Entitätstyp wird durch eine Relation abgebildet
•  Jede Entität ist genau einmal und vollständig in ihrer „Basisrelation“ gespeichert
   

Polymorphie oder Polymorphismus ist ein Konzept in der objektorientierten Programmierung, das ermöglicht, dass ein Bezeichner abhängig von seiner Verwendung Objekte unterschiedlichen Datentyps annimmt.

Wie bei Union

Wie bei Horizontale Zerlegung

1. Eine Tabelle je globalem Attribut
2. Eine Tabelle je Klasse
3. Eine einzeilige Tabelle für alle globalen Attribute
4. Eine mehrzeilige Tabelle für alle globalen Attribute

OO Modell ist mächtiger als relationales Modell

• l Vielfach nur verlustbehaftete Abbildung möglich

Abbildungsprobleme z.B. bei

• l Methoden – stehen nicht zentral in der Datenbank zur Verfügung
• l Objektidentität vs. Primärschlüssel
• l Vererbungshierarchien – alternative Abbildungsmöglichkeiten

Komplexe Objekte müssen in Komponenten zerlegt und auf viele Tabellen verteilt werden

• Zur Rekonstruktion der Objekte sind zeitaufwendige Verbundoder Mengenoperationen notwendig

Ja

Nein

ORDB
 

•  Reife (Speicherverwaltung,Optimierung, Recovery,Zugriffskontrolle)
• Stored Procedures in DBgespeichert und auf Server und Client ausführbar
• Standardkonformität (SQL)
• Verbreitung, etc.

Vorteile:

• Semantisch reiches DM
• Erweiterbarkeit des Typsystems
• Methoden, etc

Vorteile:

• SQL-Standard als Voraussetzung für Herstellerunabhängigkeit
• Bisherige Anwendungen/Daten bleiben unverändert

Evolutionäre Erweiterung relationaler DBS

Aufwärtskompatibilität basierend auf SQL

 Integration objektorientierter Konzepte

•  realitätsgetreuere Datendefinition
•  intuitivere Anfrageformulierung
•  Unterstützung von Non-Standardanwendungen

Vereinigung der Vorteile relationaler und
objektorientierter Konzepte, ohne bewährte SQLKonzepte aufzugeben
 

Geschachtelte Relationen erlaubt
l d.h. relationenwertige Attribute
l "Non-First-Normal-Form" – NF2
 

"Non-First-Normal-Form"
 

Erzeugen eines Tupels mit dem Tupelkonstruktor
l heisst genauso wie der Tupeltypkonstruktor ROW[werteliste]
ROW('Seestrasse', 31, 8008, 'Zürich', 'Schweiz')
 

Zugriff auf ein Tupelfeld mittels Punktnotation
SELECT Name, Anschrift.ORT
FROM MitarbeiterTupeltabelle
 

UPDATE MitarbeiterTupeltabelle
SET Anschrift.Ort = 'Linz'
WHERE Anschrift.Ort = 'Wien;
 

Vergleich zweier Tupel: <,>,=, <>, …

ROW(1, 2, 7) = ROW(1, 2, 7) -- liefert TRUE
ROW(1, 2, 7) = ROW(1, 3, 7) -- liefert FALSE
ROW(1, 2, 7) = ROW(1, NULL, 7) -- liefert UNKNOWN

Datentyp zur Speicherung mehrerer Werte für ein Attribut

Konstruktor: ARRAY[elementliste]

INSERT INTO MitarbeiterTupeltabelle(Sprachkenntnisse)
VALUES (ARRAY['Deutsch', 'Englisch']);
 

Direkter Elementzugriff: myArray[2]
SELECT Sprachkenntnisse[2]
FROM MitarbeiterTupeltabelle;
 

Entschachtelung: UNNEST transformiert Array in Tabelle

SELECT s.*
FROM MitarbeiterTupeltabelle,
UNNEST(Sprachkenntnisse) s (Sprache)

Tabelle „s“ mit
einzigem Attribut
„Sprache“
 

Konkatenation zweier Arrays: ||
ARRAY['Deutsch', Türkisch'] || ARRAY['Englisch']
-- erzeugt ARRAY['Deutsch', Türkisch', 'Englisch']
 

Änderung eines einzelnen Elements
UPDATE MitarbeiterTupeltabelle
SET Sprachkenntnisse[1] = 'Türkisch';
 

Änderung des kompletten Arraywerts
UPDATE MitarbeiterTupeltabelle
SET Sprachkenntnisse = ARRAY['Türkisch'];
 

Kardinalität – Anzahl der Arrayelemente
CARDINALITY(ARRAY['Deutsch', Türkisch'])
-- liefert den Wert 2
 

Vergleich zweier Arrays
möglich g.d.w. ihre Elementtypen vergleichbar sind

Zwei vergleichbare Arrays A1 und A2 sind gleich (A1=A2) g.d.w
(1) sie die gleiche Kardinalität besitzen und
(2) alle Elemente paarweise gleich sind
 

Ungeordnet, mit Duplikaten – Konstruktor:

•  MULTISET(werteliste)
•  Leere Multimenge
•  Mit Werten initialisierte Multimenge

MULTISET()

MULTISET(17, 4, 7, 4)

Entschachtelung

UNNEST-Operator transformiert Multiset in Tabelle

Aus einer Anfrage erzeugte Multimenge
 

MULTISET(SELECT f.nichtAnwesend
FROM MitarbeiterTupeltabelle,
UNNEST(Fehltage) f (nichtAnwesend);
 

Elementtyp wird durch Zeilentyp der Tabelle bestimmt

•  Tabelle hat genau 1 Attribut A1: Elementtyp = Type(A1)
•  Tabelle hat mehr Attribute: Elementtyp = ROW(Type(A1),...Type(An))
   

Duplikateliminierung, Elementtest, Mengenoperatoren, etc.
 

Zur Bildung eines Objekt-IDs (unveränderlich – OID)
l = Referenz auf ein Objekt in einer Objekt-Tabelle 

REF (strukturierter Typ)
[SCOPE gültigkeitsbereich]
 

Gültigkeitsbereich: bestimmte Tabelle(n) oder alle Tabellen
 

Dereferenzierung  -> Operator

liefert EINZELNE Referenzattributwerte
 

SELECT Abteilung->Name
FROM MitarbeiterTupeltabelle;
 

Referenzauflösung DEREF-Operator
 liefert ALLE Attributwerte des referenzierte Objekts

SELECT DEREF(Abteilung)
FROM MitarbeiterTupeltabelle;
 

Referenzauflösung DEREF-Operator
 liefert ALLE Attributwerte des referenzierte Objekts

Dereferenzierung  -> Operator

liefert EINZELNE Referenzattributwerte

Distinct-Typen
l Kopie eines existierenden Datentyps mit neuem Namen
 

Strukturierte Typen
l Typkonstruktor für benannte, strukturierte Datentypen
 

Kopie eines existierenden Datentyps mit neuem Namen

Benutzerdefinierter Datentyp, der eine Kopie eines
Basisdatentyps unter einem neuen Namen ablegt

l Wiederverwendung

l Strenge Typisierung (basiert auf Namensäquivalenz)

l Obligates (!) Schlüsselwort FINAL schließt Subtypbildung aus

l Systemdefinierte Vergleichsoperatoren basierend auf dem Quelltyp

l Cast-Operatoren zur Konversion zwischen Distinct- und Quelltyp
 

Typkonstruktor für benannte, strukturierte Datentypen

Kein Vergleich/Zuweisung von Attributen verschiedener
Distinct-Typen (auch wenn gleicher Basisdatentyp!)
 

CREATE TYPE Dollar AS DECIMAL (12,2) FINAL;
CREATE TYPE Euro AS DECIMAL (12,2) FINAL;
 

CREATE TABLE Konto (
standAusland Dollar,
standInland Euro)
Attribute nicht vergleichbar – Typkonflikt!
 

Explizite Konvertierung zum gemeinsamen Quelltyp

ELECT k.standDollar

FROMKonto k

WHERECAST(k.standDollar AS DECIMAL(12,2)) >
CAST(k.standEuro AS DECIMAL(12,2));

Benutzerdefinierte Cast-Funktion zur Wert-Konvertierung
l Schritt 1:
¡ Stored Procedure definieren, die Konvertierung vornimmt
l Schritt 2:
¡ CREATE CAST (Dollar AS Euro) WITH Name_of_stored_procedure
l Schritt 3:
¡ Erneuter Vergleich auf Basis der benutzerdefinierten Cast-Funktion

Impliziter Aufruf der Cast-Funktion bei Vergleichen möglich
l Definition wie in Schritt 2 oben inkl. Schlüsselwort
„AS ASSIGNMENT“
 

Impliziter Aufruf der Cast-Funktion bei Vergleichen möglich
l Definition wie in Schritt 2 oben inkl. Schlüsselwort
„AS ASSIGNMENT“

l Schritt 1:
¡ Stored Procedure definieren, die Konvertierung vornimmt
l Schritt 2:
¡ CREATE CAST (Dollar AS Euro) WITH Name_of_stored_procedure
l Schritt 3:
¡ Erneuter Vergleich auf Basis der benutzerdefinierten Cast-Funktion

ELECT k.standDollar

FROMKonto k

WHERECAST(k.standDollar AS DECIMAL(12,2)) >
CAST(k.standEuro AS DECIMAL(12,2));

Benutzerdefinierter Datentyp, der einem Objekttyp mit Attributen und Methoden entspricht

CREATE TYPE <typname>
AS (Attributdefinitionsliste)
[[NOT] INSTANTIABLE]
[NOT] FINAL
[Referenzgenerierung [Referenzcasting]]
[Methodendeklarationsliste]
 

wenn er keinen Supertyp besitzt
 

Strukturierte Typ

Optionale Angaben
Instanziierung verbieten (abstrakter Typ)
l FINAL-Klausel erlaubt bzw. verbietet Subtypbildung
l Bestimmen der Referenzgenerierung (OID-Erzeugung) –Angabe nur bei Wurzeltyp möglich – gilt für alle Subtypen!
l Objektverhalten in Methoden kodieren
 

REF IS oid USER GENERATED
 

REF IS oid SYSTEM GENERATED
 

REF IS oid DERIVED (attributliste)
ID wird abgeleitet von anderen Attributen (z.B. PK)
 

1. Attributtyp anderer strukturierter Typen
2. Parametertyp von Methoden, Funktionen und Prozeduren
3.  Typ von SQL-Variablen
4.  Typ von Tabellenspalten
5.  Typ einer gesamten Tabelle

CREATE TYPE AdressTyp AS (
strasse VARCHAR(30),
nr DECIMAL(4),
plz DECIMAL(5),
ort VARCHAR(40),
land VARCHAR(25)
)
NOT FINAL;

CREATE TYPE PersonTyp AS(
name VARCHAR30),
anschrift AdressTyp
ehepartner REF(PersonTyp),
kinder REF(PersonTyp) ARRAY[10]
)
NOT FINAL
REF IS SYSTEM GENERATED;

1. Nutzung des DefaultKonstruktors Typname()
    
2. Definition + Nutzung eines überladenen Konstruktors

CREATE FUNCTION AdressTyp (s VARCHAR(30),

n DECIMAL(4),
p DECIMAL(5),

o VARCHAR(40),
l VARCHAR(25))
RETURNS AdressTyp
RETURN AdressTyp().Strasse(s).Nr(n).PLZ(p).Ort(o).Land(l);

CREATE FUNCTION PersonTyp (n VARCHAR(30), a AdressTyp)
RETURNS PersonTyp
BEGIN
DECLARE p PersonTyp;
SET p = PersonTyp();
SET p.Name = n;
SET p.Anschrift = a;
...
RETURN p;
END;
 

CREATE FUNCTION PersonTyp (n VARCHAR(30), a AdressTyp)
RETURNS PersonTyp
BEGIN
DECLARE p PersonTyp;
SET p = PersonTyp();
SET p.Name = n;
SET p.Anschrift = a;
...
RETURN p;
END;

Subtypdefinition mittels
UNDER-Klausel

•  Subtyp hat einen direkten Supertyp
  • keine direkte Mehrfachvererbung
•  Supertyp muss selbst ein strukturierter Typ sein
•  Subtyp erbt alle Attribute und Methoden des Supertyps
•  Subtyp kann geerbte Methoden überschreiben und überladen

Methoden sind Prozeduren, die zu einem strukturierten Typ gehören
 

Deklaration erfolgt innerhalb der Typdefinition
 

• Überladen von Methodennamen
  •  mehrere gleichnamige Methoden mit unterschiedlichen Parametern
• Dynamisches Binden von überschriebenen Methoden zur Laufzeit
  • Auswahl der Implementierung hängt vom strukturierten Typ ab

 Besonderheiten:

•  impliziter SELF-Parameter (vergleichbar this in C++, Java)
•  getrennte Spezifikation von Signatur und Implementierung
•  automatisch generierte set/get-Methoden für alle Attribute eines Typs – Kapselung!
• l Vergleichs- und Ordnungsoperatoren für Instanzen benutzerdefinierter Typen spezifizierbar

getrennte Spezifikation von Signatur und Implementierung
 

automatisch generierte set/get-Methoden für alle Attribute
eines Typs – Kapselung!
 

mehrere gleichnamige Methoden mit unterschiedlichen Parametern
 

CREATE METHOD AnzahlKinder()
RETURNS INTEGER
FOR PersonTyp
BEGIN
...
END;

Distinct-Typen als Kopien vorhandener Typen
l Strenge Typisierung
l Typkompatibilität über Namensäquivalenz
 

Strukturierte Typen als abstrakte Objekttypen

• l Objekteinbettung vs. Objektreferenzierung
  • ¡ Kopier- vs. Referenzsemantik
• l Kapselung
  • ¡ Implizierte Observer- und Mutator-Methoden für alle Attribute
• l Aggregationshierarchien
  • ¡ Strukturierte Typen zusammengesetzt aus anderen
• l Typhierarchien
  • ¡ Subtypbildung
• l Overloading / Overriding von Methoden plus dynamisches Binden
• l Vergleichbarkeit und Ordnung
   

Typisierte Tabellen

Attribute können nur Basisdatentypen sein und Tupel speichern
 

Tabellentyp wird durch strukturierten Typ festgelegt

Attribute können array-, multimengen-, tupel-, objekt- und 

referenzwertig sein

Attribute von „Typisierten Tabellen“ können array-, multimengen-, tupel-, objekt- und referenzwertig sein

Attribute von Tupel-Tabellen können nur Basisdatentypen sein und Tupel speichern

Zeilen von „Typisierten Tabellen“ bzw. „Objekt-Tabellen“

• Zeilen entsprechen Objekten (Instanzen) des festgelegten Typs
• Zeilen haben OID-Spalte und sind referenzierbar
• Methoden können über
  Dereferenzierung von OIDs auf Zeilen aufgerufen werden
• Integritätsbedingungen spezifizierbar
• Tabellenhierarchien (Subtabellen) sind möglich
• Entsprechen in etwa dem Konzept einer Klasse
   

Zeilen von Tupel-Tabellen

sind Tupeln

Auch Tupel-Tabellen können seit SQL:1999 nicht-atomare Attribute aufweisen
 Allerdings werden weiterhin nur Tupel gespeichert, keine Objekte  D.h. kein OID, keine Methoden, keine Subtabellen, etc.
 

Methoden können über
Dereferenzierung von OIDs auf Zeilen aufgerufen werden
 

Ja

Auch Tupel-Tabellen können seit SQL:1999 nicht-atomare Attribute aufweisen

Subtabellendefinition mittels UNDER-Klausel
 

CREATE TABLE SubTabName OF TypName
UNDER SuperTabName
[(SpaltenName WITH OPTIONS Options)];

SCOPE TypisierteTabelle
| DEFAULT Wert
| Integritätsbedingung
 

Subtabelle hat genau eine direkte Supertabelle
 

Typ der Subtabelle muss ein direkter Subtyp
des Typs der Supertabelle sein

immer eine Untermenge der (tiefen) Extension der
Supertabelle sein

Ja

allerdings nur supertypspezifische Spalten
 

• Subtabelle hat genau eine direkte Supertabelle
  • l keine direkte Mehrfachspezialisierung
  • l Typ der Subtabelle muss ein direkter Subtyp des Typs der Supertabelle sein
•  (Tiefe) Extension der Subtabelle muss imme eine Untermenge der (tiefen) Extension der Supertabelle sein
  • l Instanzen der Subtabelle sind auch Mitglieder der zugehörigen Supertabellen
  • l Alle Zeilen der Subtabelle sind in der Supertabelle sichtbar
  • l allerdings nur supertypspezifische Spalten

Tiefe Extension
l alle Objekte einer Tabelle inkl. der Objekte der Subtabellen

Flache Extension
l ohne Objekte der Subtabellen

SELECT * FROM ONLY(<supertabelle>);