1.

Probleme mit dem relationalen Datenmodell

1.1 Mengenattribute
Schwäche von relationalen Modellen – keine einfache Möglichkeit Attribute zu definieren

Person (SSN: String, Name: String, PhoneN: {String], Child {SSN}

das SSN bei Child könnte ein Verweis auf eine andere, in der Tabelle bestehende, Person sein
in { } angegebene Werte stellen Mengenwerte dar, könnte so z.B. aussehen
( 111-22-3333, „Emin S“, {123-456-789, 987-123-456}, {000-11-2222, 333-44-
5555} )

von imMENSEm Vorteil wäre es das Attribut Child als Menge von Verweisen auf andere Personen
darzustellen
Person (SSN: String, Name: String, PhoneN: {String}, Child {Person} )
hier würde das Child Attribut wiederrum ein Personenobjekt darstellen, somit wären Abfragen der
Form
SELECT P.Child.Child.PhoneN
FROM Person P
WHERE P.Name = ‘Emin S‘
P.Child.Child.PhoneN ist ein Pfadausdruck

2. Konzeptionelles Objekt Datenmodell

2.1 Objekt ID
jedes Objekt besitzt eine eindeutige unveränderliche Objekt ID, diese wird vom System beim
Erzeugen eines Objektes generiert und zugewiesen <-> Schlüssel im relationalen Modell (vom
Benutzer erzeugt, können sich ändern, nicht unbedingt systemweit eindeutig)

2.2 Objekte und Werte

Ein Objekt ist immer ein Paar der Form (oid, val)
oid = Objekt ID; val = Wert [Primitive(Int, Str, Float), Referenz, Tuple(A1:v1, An:vn), Set{v1,…vn}
Referenz, Tuple, Set = komplexe Datentypen

2.3 Klassen
semantisch gleichartige Objekte werden zu Klassen zusammengefasst (z.B. alle Objekte die Personen
darstellen
Klasse PERSON)
Klasse besteht aus: Typ, Signaturen der Methode, Extent (Menge aller Objekte in der Klasse)
Klassen sind hierarchisch, IS A-Beziehung

2.4 Typen (same shit wie bei 2.2)

2.4.1 Subtyping
manche Typen können von anderen Typen abgeleitet werden und in der Struktur angereichert
werden – d.h. ein abgeleiteter Typ hat die gleiche Struktur wie der ursprüngliche, jedoch enthält er
zusätzliche Strukturelemente
STUDENT_T ist ein Subtyp von PERSON_T

PERSON_T: [SSN: String, Name: String, Adress: [StNum: Integer, StName:

String]]
STUDENT_T: [SSN: String, Name: String, Adress: [StNum: Integer, StName:
String, Rm: Integer], Majors: {String}, Enrolled: {Course}]
STUDENT_T enthält die Struktur von PERSON_T und erweitert diese im Attribut Adress (Tuple) und
um einen neuen komplexen Typ Majors
2.4.2 Datenbankschema und Instanz
Datenbankschema beinhaltet die Spezifikation für alle Klassen (Typ der Klasse, Methoden
Signaturen, Klassenhierarchie, Integritätsbedingungen)
Eine Instanz einer Datenbank ist die Menge aller Objekte zu Klassen, die in einem Schema definiert
sind

3. Objektrelationale Datenbanken
Eine Objektrelationale DB besteht aus einer Menge von Top-Level Klassen mit Tuple Objekten, diese
haben die Form (oid, value).

3.1 Row-Typen
sind gleich zu sehen wie Tuples. In ORDBs kann ein Row Typ auch als Typ eines einzelnen Attributes
eines Tuples auftreten
CREATE TABLE PERSON ( Name CHAR(20), Adress ROW(Number Integer, Street
CHAR(20), ZIP CHAR(5)))

3.1.1 Abfrage
Pfadausdrücke…
SELECT P.Name FROM PERSON P WHERE P.Adress.ZIP = ‘12345‘

3.1.2 Insert/Updates
mittels Row Typ Konstruktor
INSERT INTO PERSON(Name, Adress) VALUES (‘Emin S‘, ROW(666, ‘Hollow Rd.‘,
‘66666‘))
UPDATE PERSON SET Adress.ZIP = ‘55555 ‘ WHERE Adress.ZIP = ‘66666 ‘
UPDATE PERSON SET Adress = ROW(21, ‘Main St‘,‘12345‘) WHERE Adress = ROW(123,
‘Maple Dr.‘, ‘54321‘) AND Name=‘Emin S‘

3.2 Benutzerdefinierte Typen

können aus beliebigen Typen zusammengesetzt werden und können als Typ von Attributen in Tuples
auftreten
Definition eines Typs:
CREATE TYPE PersonType AS (Name CHAR(20), Adress ROW(Number Integer, Street
CHAR(20), ZIP CHAR(5)))

Definition eines Typs unter Verwendung von Vererbung und Methodendeklaration:

CREATE TYPE StudentType UNDER PersonType AS (Id Integer, Status CHAR(2))
METHOD award_degree() RETURNS BOOLEAN
CREATE METHOD award_degree() FOR StudentType LANGUAGE C EXTERNAL NAME
‘file:/home/award_degree‘

Benutzerdefinierte Typen können in 2 Situationen eingesetzt werden

Spezifikation des Domains eines Attributes in
einer Tabelle
CREATE TABLE TRANSCRIPT (Student
StudentType, CrsCode CHAR(6),
Semester CHAR(6), Grade CHAR(1))
Spezifikation des Typs einer gesamten Tabelle
CREATE TABLE STUDENT OF StudentType
Zeilen werden als Objekte betrachtet, Attribut ist
zwar vom gleichen Typ aber kein Objekt

3.3 Objekte
CREATE TABLE STUDENT OF StudentType vs.
CREATE TABLE STUDENT1 (Name CHAR(20), Adress ROW(Number INTEGER, Street
CHAR(20)))
beide sind von der gleichen Struktur aber nur Tuples in STUDENT bekommen eine oid und sind damit
Objekte!
3.4 Abfragen auf Benutzerdefinierte Typen
keine große Herausforderung – wer’s glaubt…
SELECT T.Student.Name, T.Grade FROM TRANSCRIPT T WHERE
T.Student.Adress.Street = ‘Main St‘
Attribut Name ist nicht ein Element des StudentType sondern wird von PersonType geerbt

3.5 INSERT/UPDATE Benutzerdefinierte Typen

INSERT INTO TRANSCRIPT(Student, Course, Semester, Grade) VALUES(NEW
StudentType().Id(111111111).Status(‘G5‘).Name(‘Emin S‘).Adress(ROW(123, ‘Main
St. ‘,‘54321‘)),‘CS532‘ ,‘S2002‘ ,‘A‘)
bzw. ein Update
UPDATE TRANSCRIPT SET Student = Student.Adress(ROW(21, ‘Maple St. ‘,
‘12345‘)).Name(‘Emin S‘), Grade = ‘B‘ WHERE Student.Id = 111111111 AND CrsCode
= ‘CS532‘ AND Semester = ‘S2002‘

3.6 Referenzen
ideal wäre es eine Tabelle mit Studentenobjekten zu haben, auf diese kann dann einfach referenziert
werden
CREATE TABLE STUDENT2 OF StudentType REF IS stud_oid
Tabelle mit Referenz
CREATE TABLE TRANSCRIPT1 (Student REF(StudentType) SCOPE STUDENT2, CrsCode
CHAR(6), Semester CHAR(6), Grade CHAR(1))
hier wird das Attribut Student als Referenz auf ein Objekt des Typs StudentType definiert.
SCOPE schränkt die Referenzen auf die Objekte ein welche in der Tabelle STUDENT2 definiert sind

Um Referenzen in einer Query zu verfolgen wird statt des „.“Operators der „
“ Operator verwendet
SELECT T.Student
Name, T.Grade FROM TRANSCRIPT1 T WHERE
T.Student
Adress.Street = ‘Main St.‘

Einfügen eines Tuples mit einer Referenz durch Verwendung eines Selects und der Self-Referencing-
Spalte
INSERT INTO TRANSCRIPT1 (Student, Course, Semester, Grade) SELECT
S.stud_oid, ‘HIS666‘,‘F1462‘,‘D‘ FROM STUDENT2 S WHERE S.Id = ‘111111111‘

3.7 Vererbung
Tabelle STUDENT vom Typ StudentType und Tabelle PERSON vom Typ PersonType
CREATE TABLE PERSON OF PersonType
CREATE TABLE STUDENT OF StudentType
wird ein Datensatz in STUDENT eingetragen ist er NICHT in PERSON, wäre nur der Fall wenn STUDENT
explizit von PERSON „abgeleitet“ wäre
CREATE TABLE STUDENT OF StudentType UNDER PERSON
PERSON is Supertable von STUDENT und alle Tuples, die in STUDENT eingefügt werden sind
automatisch in PERSON sichtbar

3.8 Collections
Mengentypen = Collections
MULTISET = wie eine Menge, jedoch kann ein Element mehrfach vorkommen
CREATE TYPE CourseType (CrsCode CHAR; Name CHAR; Description CHAR)
CREATE TABLE COURSE OF CourseType
CREATE TYPE StudentType UNDER PersonType AS (Id INTEGER, Status CHAR(2),
Enrolled REF(CourseType) MULTISET)
und wie löst man ein MULTISET auf? Multiset-Attribut in eine einspaltige Tabelle umwandeln
(UNNEST)
SELECT S.Id, S.Adress, C.Name FROM STUDENT S, COURSE C WHERE C.CrsCode IN
(SELECT E
CrsCode FROM UNNEST(S.Enrolled) E)
und versteht das ein Schwein? NEIN!
mit MULTISET kann auch der umgekehrte Weg
gegangen werden
CREATE TABLE TRANSCRIPT2 (Student
REF(StudentType), Course
REF(CourseType), CrsCode CHAR(6),
Semester CHAR(6), Grade CHAR(1))

INSERT INTO STUDENT (Id, Status, Enrolled) VALUES (123456789, ‘H2‘, MULTISET
(SELECT T.Course FROM TRANSCRIPT2 T WHERE T
Id=4711)

4. Der ODMG Standard

beschreibt ein Datenmodell, eine Definitionssprache, eine Abfragesprache, einen
Transaktionsmechanismus, Programmiersprachenbindungen

4.1 Strukturen
Hauptidee: Programmiersprache gleich Datensprache
- Objekte der Programmiersprache können direkt auf Datenbankobjekte abgebildet werden
- einige Objekte der Applikation werden als persistent deklariert – Funktion von Proxies im Bezug zu
den aktuellen DB-Objekten, Änderungen beeinflussen direkt das zugehörige Datenbankobjekt
- Zugriff auf Objekt über OID bringt es direkt aus der DB in den Speicher und die Applikation arbeitet
direkt damit als ob es in der Programmiersprache definiert wurde

4.2 ODL – Object Definition Language

ganz selten genutzt
in ODMG DB wird die Struktur der Hostsprache definiert, verursacht aber Problem, dass man
Konstrukte unterschiedlicher Programmiersprachen interoperabel machen muss

Referenzdatenmodell wird benötigt (da sind alle unterschiedlichen Programmiersprachenkonstrukte
abgebildet)

4.3 ODMG Datenmodell

definiert Klassen, Hierarchien und Typen, zwei Typen von Klassen
- ODMG Klasse (Methoden mit Code, Grundlage für Objekte, einfache Vererbung)
- ODMG Interface (kein Code, keine eigenen Objekte, nur Signatur)
das Modell unterscheidet zwischen Objekten und reinen Werten, beide können eine komplexe
Struktur aufweisen aber nur Objekte haben eine ObjektID

4.4 OQL – Object Query Language

ist wie SQL deklarativ und dem SQL ähnlich

5. Object-Relational Mapping
nicht durchgesetzt – wie lassen sich Objekte auf relationale Strukturen „mappen“?
- Objektserialisierung
- Manuelles Mapping
- Mapping Tools
- OO DB’s

5.1 Software Architektur

erster Schritt in der Einführung einer Mehrschichtenarchitektur (von Anfang
kann gecodet werden)
Dreischichtenarchitektur konkretisiert die Struktur des Anwendungssystems
(Präsentation – Domäne – Speicher); die Domänenschickt repräsentiert das
Anwendungsgebiet
Mapping-Tools werden zwischen DB und Persistance Layer dargestellt