Grenzen des relationalen Datenmodells

Transkript

1 Frühjahrsemester 2013 CS243 Datenbanken Kapitel 2: Objektorientierte und Objekt-relationale Datenbanken H. Schuldt Grenzen des relationalen Datenmodells Relationale Datenbanksysteme sind sehr gut geeignet für die Verwaltung von klar strukturierten Daten, die sich einfach auf Relationen abbilden lassen Allerdings gibt es komplexere Anwendungen, bei denen sich das relationale Datenmodell nicht unbedingt gut eignet. Ingenieurwissenschaftliche Anwendungen (z.b. Verwaltung von Volumendaten, CAD-Daten, ) Multimedia-Anwendungen (z.b. Audio-Daten, Video-Daten, etc.)... Als Reaktion hierauf haben sich weitere Datenmodelle herausgebildet Objektorientierte Datenmodellierung: Kombination der strukturellen Repräsentation zusammen mit der operationalen Repräsentation (Verhalten) in einem Objekttyp T OODBMS, Kapitel 2.1 Objektrelationale Datenmodellierung: Erweiterung des relationalen Datenmodells um komplexe, benutzerdefinierte Objekte und benutzerdefinierte Funktionen T ORDBMS, Kapitel

2 Grenzen des relationalen Datenmodells Beispiel: Modellierung von geometrischen Körpern in boundary representation (BREP) Objekte werden durch eine Menge von Polyedern beschrieben, jeder Polyeder besitzt 4 Flächen, jede Fläche drei Kanten, jede Kante ist durch zwei Endpunkte beschrieben. 2-3 Grenzen des relationalen Datenmodells Nachteile des relationalen Entwurfs in Anwendungen wie der vorigen: Segmentierung: Ein Anwendungsobjekt wird in der relationalen Repräsentation auf eine Vielzahl von Relationen verteilt (segmentiert). Bei einem Zugriff auf das Anwendungsobjekt müssen die einzelnen Teile über (teure) Joins zusammengeführt werden. Künstliche Schlüsselattribute: Um die Eindeutigkeit von Tupeln zu erzwingen müssen oftmals künstliche Schlüssel vergeben werden. Diese Schlüssel sind relevant um zusammengehörige Teile über einen Join wieder zusammenführen zu können. Fehlendes Verhalten: Objekte besitzen in der Regel ein anwendungsspezifisches Verhalten. Dies wird in der relationalen Repräsentation nicht berücksichtigt sondern muss ausserhalb des DBMS realisiert werden (Ausnahme: Stored Procedures). Einbettung in Programmiersprachen (Mengenorientierung vs. Satzorientierung): relationale Anfragesprachen sind mengenorientiert. Programmiersprachen verarbeiten jedoch zu jedem Zeitpunkt nur einen Datensatz. Dies wird auch als Impedance Mismatch bezeichnet

3 2.1 Objektorientierte Datenbanken Grundidee objektorientierter Datenbanken (OODBMS) ist es, die Beschreibung des Verhaltens von Anwendungsobjekten mit ihrer Strukturbeschreibung in einer Objekttyp-Definition zu verbinden (und damit die vier zuvor identifizierten Nachteile des Relationenmodells zu überwinden). Operationen werden damit zu einem wesentlichen Bestandteil der Datenbank. Datenstrukturen in der Anwendung Relationale Repräsentation Kopie und Umwandlung Transparenter Zugriff auf OODBMS RDBMS OODBMS 2-5 Objektorientierte Datenbanken Daher findet auch die aus der objektorientierten Programmierung bekannte Objektkapselung in objektorientierten Datenbanken Anwendung Die Operationen, die einem Objekt zugeordnet sind können direkt ausgeführt werden, ohne die strukturelle Repräsentation eines Objekts zu kennen (information hiding). Es muss lediglich die Signatur der Operationen an der Schnittstelle des Objekts bekannt sein. Operation 1 Jedes Objekt ist eindeutig über eine automatisch vom System generierte Objekt-ID repräsentiert (und nicht über ein [künstliches] Schlüsselattribut) Operation 2 Struktur OO- DBMS 2-6 3

4 ODMG: Standard für Objektorientierte DBMS Im Gegensatz zum SQL-Standard für relationale Datenbanksysteme gibt es keinen allgemeingültigen Standard für OO-DBMS Ziel der Object Database Management Group (ODMG), ein Zusammenschluss von Herstellern objektorientierter DB-Produkte, war es, ein einheitliches Objektmodell festzulegen (und damit eine de facto-standard zu definieren) Terminologie: Objekttyp: Beschreibung von Struktur und Verhalten (properties & operations) Objekt: Instanz eines Objekttyp Extension (engl. extent): Menge aller Instanzen eines Objekttyps OID: Objektidentifikator (systemweit eindeutig; bei der Instanziierung vom System vergeben, unveränderlich) 2-7 ODMG-Modell Ursprüngliche Zielsetzung von OODBMS: Kein Impedance Mismatch sondern: Programmiersprache = Datenbanksprache Daher zunächst keine Wirtsprachen-unabhängige Datendefinition, Datenabfrage und Datenmanipulation wie es in SQL ist. Vorteil: homogene Umgebung für Entwurf und Entwicklung von IS Nachteile: eine Datenbank kann nicht von mehreren Anwendungsprogrammiersprachen angesprochen werden ein OODBMS eines Herstellers kann nicht durch ein OODBMS eines anderen Herstellers ersetzt werden, es sei denn, die gleiche Programmiersprache wird verwendet (Widerspruch zur Realität: Smalltalk, C, C++, Java,...) Das ODMG-Modell enthält daher einen Vorschlag für ODL = sprachunabhängige (stand-alone) Objektdefinition OQL = sprachunabhängige (stand-alone) Objekt-Abfragesprache keine OML, stattdessen Standard für C++OML, SmalltalkOML, JavaOML, sowie die Einbettung der ODL und OQL in diese Sprachen 2-8 4

5 Objekt-Definition (ODL): ODMG-Typen Im ODMG-Modell sind einige wichtige Objekttypen vorgefertigt (z.b. Datum, Zeit, Zeitintervall). Ausserdem gibt es einen Set-Konstruktor sowie Bag (Menge mit Duplikaten), List, Array und Dictionary (Liste von Attribut-Wertpaaren) zur Mengendefinition. Alle diese Typen treten zweifach auf: in Kopiersemantik ( Literal_type ) in Referenzsemantik ( Object_type ) Types Literal_type Atomic_literal Collection _literal Structured_literal Object_type Atomic_object Collection_object Structured_object 2-9 Objekt-Definition (ODL): ODMG-Typen Atomic_literal ::= long, short, unsigned long, unsigned short, float, double, boolean, octet, char, string, enum<> Collection_literal ::= set<>, bag<>, list<>, array<>, dictionary<> Structured_literal ::= structure<>, date, time,... Atomic_object ::= benutzerdefiniert durch interface{} und class {} Collection_object ::= Set<>, Bag<>, List<>, Array<>, Dictionary<> Structured_object ::= Structure<>,... Collection_object unterscheidet sich vom Collection_literal durch Referenzsemantik bei Zuweisungen. Analog ist der Zusammenhang zwischen Structured_literal und Structured_object

6 Definition von Atomic_object-Typen interface{} ist die Beschreibung eines Atomic_object-Typs unter Verwendung seiner Struktur ( Properties ) und seines Verhaltens ( Operations ). Zu einem Interface gibt es keine Instanzen. Ein Interface dient der Beschreibung der Schnittstelle mehrerer Typen. class{} ist die Beschreibung eines Atomic_object-Typs unter Verwendung von höchstens einer (Super-)Class-Beschreibung (IS-A), keiner, einer oder mehrerer Interface-Beschreibungen, einer EXTENT und KEY- Festlegung. Deklaration von properties und operations Klassen werden also instanziiert, die Instanzen finden sich dann im Extent (Ausprägung) der Klasse. Durch die Key-Festlegung können Duplikate im Extent verhindert werden. Keys werden nur im Sinne einer Integritätsbedingung verwendet, nicht aber um Objekte zu referenzieren (dies geschieht über deren OID) Attribute, Beziehungen und Methoden Ein Atomic_object Typ wird beschrieben durch Properties: dies sind Attribute und Beziehungen. Ein Attribut (attribute) besitzt einen Wertebereich (häufig mit Literal-Typ). Objektwertige Attribute sind auch zugelassen, es ist jedoch empfehlenswert, diese Attribute als Beziehung zu modellieren. Eine Beziehung (relationship) verweist auf ein Objekt (bzw. auf eine Menge von Objekten). Für die Garantie, dass eine Beziehung auch in umgekehrter Richtung eingehalten wird gibt es die Möglichkeit, gleichzeitig auch die Inverse (inverse) einer Beziehung zu spezifizieren (unabhängig von den jeweiligen Kardinalitäten). Operations: Methoden, die durch ihre Signatur beschrieben werden, insbesondere durch zusätzliche Input ( in ) und Output ( out, inout ) -Parameter. Standard-Inputparameter ist die Objekt-Instanz, auf der die Methode aufgerufen wird

7 ODL-Beispiel Studierende {interface} name : string MatNr : string adr Adresse 1 strasse : string 1 ort : string plz : short adr Angestellter name : string AHVNr : string gehalt 1 Gehalt brutto : float währung erhöhen() Student Doktorand Professor doktorvater 1 rang: Professur setzt_voraus 0.. * 0..* 1 {ordered} 0..* {ordered} dozent hört betreut Vorlesung 1.. * 0..* titel : string nummer:string 0..* liest ist_angeboten() 2-13 ODL-Beispiel: Typdefinitionen class Vorlesung ( extent Vorlesungen key nummer ) { attribute string titel; attribute string nummer; relationship Professor dozent inverse Professor::liest; relationship list<doktorand> betreut_von inverse Doktorand::betreut; relationship list<vorlesung> setzt_voraus inverse Vorlesung::ist_voraussetzung_für; relationship set<vorlesung> ist_voraussetzung_für inverse Vorlesung::setzt_voraus; }; boolean ist_angeboten ( in unsigned short semester );

8 ODL-Beispiel: Typdefinitionen class Gehalt { readonly attribute float brutto; readonly attribute enum Waehrung {CHF,EUR, } waehrung; }; void erhoehen ( in float betrag, in Waehrung curr ); struct Adresse { attribute string attribute string attribute short }; strasse; ort; plz; 2-15 ODL-Beispiel: Typdefinitionen class Angestellter ( extent Angestellte key AHVNr ) { attribute string name; attribute string AHVNr; attribute Adresse adr; attribute Gehalt gehalt; }; class Professor extends Angestellter (extent Professoren) { attribute enum Professur {Ord, Extraord, Asst} rang; relationship set<vorlesung> liest inverse Vorlesung::dozent; };

9 ODL-Beispiel: Typdefinitionen interface Studierende { attribute string name; attribute string MatNr; attribute Adresse adr; }; class Student : Studierende ( extent Studenten key MatNr ) { attribute string name; attribute string MatNr; attribute Adresse adr; attribute set<vorlesung> hört; }; class Doktorand extends Angestellter : Studierende (extent Doktoranden) { attribute string MatNr; attribute Professor doktorvater; relationship set<vorlesung> betreut inverse Vorlesung::betreut_von; }; 2-17 Klassen als Implementierung von Schnittstellen Einer interface-definition werden keine Instanzen zugeordnet. Es wird nur die Art der Eigenschaften und Beziehungen festgelegt. Zu einer class-definition gibt es Instanzen in dem dazu eingeführten Extent. Über die extends-anweisung bekommt daher eine Subclass nicht nur die Art sondern auch die Werte der Properties (also der Attributwerte und Beziehungspartner). Zu jeder Instanz einer subclass gibt es genau eine Instanz in der übergeordneten class. Mehrfachvererbung ist im ODMG-Modell ausgeschlossen. Wenn in einer Interface-Definition I Properties spezifiziert sind, so müssen diese in einer class C, für die C HAS-A I gilt, nachgereicht werden. Man sagt dann auch, dass class C eine Schnittstelle für I implementiert. Dies muss allerdings unterschieden werden von der Implementierung der Schnittstellenoperationen einer Klasse

10 ODMG-Modell vs. Relationales Datenmodell Im relationalen Datenmodell sind nur Tupelmengen erlaubt. Im ODMG-Modell (OO-Datenmodell) sind ebenfalls nur Mengen erlaubt, die aber jetzt Objekte als Elemente haben. Relationenmodell (1NF) Relation: Menge von Tupeln (Ausprägung) Atomares Attribut ODMG-Datenmodell Extent: Menge von Objekten Funktion, die elementaren Wert liefert Funktion, die Menge von Objekten liefert (Tupeltyp) Objekttyp Subtyp Subklasse 2-19 Objektabfragesprache: OQL OQL ist eine SQL-ähnliche Abfragesprache für Objekte, die mit der ODL definiert wurden OQL enthält SQL-92 (den Anfrageteil, ohne DML) OQL enthält Konstrukte für den Zugriff auf einzelne Objekte, nicht nur für Kollektionen. OQL kann auch wie SQL in Programmiersprachen und damit in Anwendungsprogramme eingebettet werden (z.b. in C++, Smalltalk, Java), zusätzlich zu stand-alone -Verwendung. Durch das Bemühen, SQL-kompatibel zu sein, verliert man Eleganz. Die Unterstützung von vielen Collection Types geht auf Kosten der Einfachheit

11 Von der Relationenalgebra zur Objektalgebra Beobachtungen: die Selektion/Filterung ( ) der Relationenalgebra hängt nicht davon ab, dass die Elemente der Mengen Tupel sind. Sie verändern den Typ der Elemente in der Ergebnismenge nicht. Also kann man sie auf Klassen anwenden: Sei S eine Klasse mit Elementen vom Typ T und P ein Prädikat definiert auf Instanzen von T. Dann erhält man eine abgeleitete Klasse S durch Filterung wie folgt S' := filter [P] (S) mit ext(s') = { e in ext(s) P(e) } die Projektion ( ) der Relationenalgebra verändert den Typ. Daher muss bei der Übertragung der Relationenalgebra auf eine Objektalgebra unterscheiden werden, ob Sub- oder Supertypen erzeugt werden und ob Objekte erhalten oder neu erzeugt werden Prinzipien einer Objektalgebra (bzw. OQL) Mengen-orientiert Input: Menge(n) von Objekten Output: Menge von Objekten Objekterhaltend Output-Objekte sind Elemente der Eingabeobjektmenge(n) Objekterzeugend Output-Objekte werden aus den Elementen der Eingabeobjektmenge(n) gebildet Die objekterhaltenden Operationen sollen für Sichtdefinitionen zur Verfügung stehen. Mit diesen Operationen bewegt man sich innerhalb der Objekt-DB. Objekterzeugende Operationen benötigt man u.a. für die Übergabe von Werten an die Aussenwelt Operationssemantik wird definiert über Typ Extent der Resultatmenge

12 OQL: Objekte ansprechen Im Folgenden betrachten wir einige Beispiele der OQL (komplettes Syntax- Diagramm ist am Ende von 2.1 aufgeführt). Wir beschränken uns auf Extent-Namen als Zugang zum OODBMS (es gibt auch persistente Namen von Einzelobjekten) und gehen davon aus, dass die entsprechenden Typdefinitionen unserer Beispiel-DB vorhanden sind. Für alle Anfragen gilt: der Ergebnistyp leitet sich aus der Anfrage ab 1. Gesucht ist die Menge der Namen aller Studierenden: OQL-Anfrage: Ergebnistyp: distinct ( select s.name from s in Studenten ) 2. Gesucht sind die Namen und Matrikelnummern aller Studenten: OQL-Anfrage: Ergebnistyp: select struct ( n:s.name, id:s.matnr ) from s in Studenten 2-23 Zugriff auf Einzelobjekte & Instanziierung 3. Erzeugen einer Instanz vom Typ Professor: OQL-Anweisung: Professor (name: Einstein, AHVNr: 123, rang:ord.) 4. Zugriff auf das neu erzeugte Einzelobjekt über seinen Schlüssel : OQL-Anweisung: element(select p from p in Professoren where p.ahvnr = 123 ) 5. Verwendung eines Objekts beim Generieren eines anderen Objekts (Vorlesung): Vorlesung ( titel: Relativitätstheorie für Dummys, nummer: , dozent: element ( select p from p in Professoren where p.ahvnr = 123 ), betreut_von: select d from d in Doktoranden where d.doktorvater = element ( ),... )

13 Pfadausdrücke und Ausgabe von Werten Sei o Objekt, o.a 1.A A k ist ein Pfadausdruck für A k (...A 2 (A 1 (o))), wenn alle A i Attribute oder Beziehungen sind. Falls A i mengen- (oder bag-, listen-) wertig ist, so muss ein Iterator der Form v i in o.a 1.A 2..A i verwendet werden, der die Elemente der Menge durchläuft. 5. Für alle Doktorierenden soll der Namen, der Name des Doktorvaters, sowie die Namen, Nummern und Dozenten der von ihr/ihm betreuten Vorlesungen ermittelt werden select struct( name: d.name, betreuer: d.doktorvater.name, lectures: select struct ( t: v.titel, n: v.nummer, p: v.dozent.name ) from v in d.betreut ) from d in Doktoranden 2-25 Aufruf von Operationen Operationen ermöglichen die Veränderung der Properties von Objekten 6. Das Gehalt von Professor Einstein soll um 1000 CHF erhöht werden (element (select p from p in Professoren where p.ahvnr = 123 ) ).gehalt.erhoehen(1000,chf) (Methode erhoehen() kann neben Gehalt evtl. auch weitere Properties ändern!) 7. Ermitteln Sie die erste Vorlesung, die Voraussetzung für die Vorlesung Distributed Information Systems ist (unter der Annahme, dass die Nummerierung von Listen bei 0 beginnt): (element ( select v from v in Vorlesungen where v.titel = DIS ) ).setzt_voraus[0]

14 Beispiel 8. Gesucht ist der Name der Studentin / des Studenten mit Mat.Nr. 0815, sowie alle Vorlesungen, die sie/er bei Professoren besucht, die im selben Ort wohnen (Titel der Vorlesung + Name des Dozenten) 2-27 Syntax von Interface und Class <Interface> ::= <InterfaceHeader> { [<InterfaceBody>] } <InterfaceHeader> ::= interface <Identifier> [<InheritanceSpec>] <Class> ::= <ClassHeader> { <InterfaceBody> } <ClassHeader> ::= class <Identifier> [ extends <ScopedName>] [<InheritanceSpec>] [<TypePropertyList>] <InheritanceSpec> ::= : <ScopedName> [, <InheritanceSpec>] <TypePropertyList>::= ( [<ExtentSpec>] [<KeySpec>] ) <ExtentSpec> ::= extent <String> <KeySpec> ::= key [ s ] <KeyList> <KeyList> ::= <Key> <Key>, <KeyList> <Key> ::= <PropertyName> ( <PropertyList> ) <PropertyList> ::= <PropertyName> <PropertyName>, <PropertyList> <PropertyName> ::= <Identifier> <ScopedName> ::= <Identifier> <ScopedName> :: <Identifier>

15 Syntax von Interface und Class <InterfaceBody> ::= <Export> <Export> <InterfaceBody> <Export> ::= <TypeDecl> ; <ConstantDecl> ; <ExceptionDecl> ; <AttributeDecl> ; <RelationDecl> ; <OperationDecl> ; <AttributeDecl> ::= [ readonly ] attribute <DomainType> <Ident.> <DomainType> ::= <SimpleType> <StructuredType> <EnumType> <RelationDecl> ::= relationship <TargetOfPath> <Identifier> inverse <InversePath> <TargetOfPath> ::= <Identifier> <Collection> < <Identifier> > <InversePath> ::= <Identifier> :: <Identifier> <OperationDecl> ::= <OpType> <Identifier> ( [<ParameterList>] ) <OpType> ::= <SimpleType> void <ParameterList> ::= <ParameterD> <ParameterD>, <ParameterList> <ParameterD> ::= [ in out inout ] <SimpleType> <Identifier> 2-29 OQL Syntaxdiagramme define_ ; _program define_ define identifier as Select Expression Basic Simple Expression Comparison Boolean Expression Constructor Accessor Collection Expression Set Expression Conversion

16 OQL Syntaxdiagramme * Select Expression select distinct identifier : as identifier, from identifier as, 2-31 OQL Syntaxdiagramme where group by identifier : as, identifier having order by asc desc

17 OQL Syntaxdiagramme Literals Basic entry_name _name bind_argument from_variable_name ( ) Literals nil true false Integer Float Character String 2-33 OQL Syntaxdiagramme + - * Simple Expression / mod - abs ( )

18 OQL Syntaxdiagramme Comparison comparison op like String and Boolean Expression or not =!= Comparison Op > < >= <= 2-35 OQL Syntaxdiagramme type_name ( ) Constructors type_name struct set ( identifier :, ) bag array list (, ) list (.. ) (, )

19 OQL Syntaxdiagramme. attribute_name Accessor relationship_name -> operation_name * ( ), : first last ( ) function_name (, ) 2-37 OQL Syntaxdiagramme Collection Expression count unique exists sum min max avg ( * ) ( ) in exists comparison op some any all for all identifier in :

20 OQL Syntaxdiagramme intersect Set Expression union except Conversion listtoset element distinct flatten ( ) ( class_name ) Objektrelationale Datenbanken Bei objektrelationalen Datenbanken (ORDBMS) steht, im Gegensatz zum OODBMS-Ansatz, die evolutionäre Erweiterung bestehender relationaler Denkweise im Vordergrund. Dies garantiert unter anderem auch die grössere Unabhängigkeit von Programmiersprachen (die bei OODBMS nicht gegeben ist). Grundlage dieser Evolution ist die Erkenntnis, dass Grundkonstrukte semantischer Datenmodelle und (abstrakte) Benutzerdatentypen nötig sind. Letzteres motiviert auch die Entwicklung einer (4GL-) Sprache für Methodenund Anwendungsentwicklung. Oftmals charakterisiert man ORDBMS mit: ORDBMS = RDBMS + OODBMS Objektrelationale Erweiterungen sind im aktuellen SQL-Standard SQL:1999 (oft auch SQL-99 oder SQL3 genannt) enthalten Ziel: Vorteile von objektorientierten Konzepten einführen, ohne gleichzeitig die bewährten SQL-Konzepte aufzugeben SQL:2003: Erweiterung um zusätzliche objektrelationale Features

21 ORDBMS und SQL:1999 Übersicht Typsystemerweiterung: Erweiterbarkeit, objektorientierte Konzepte Typkonstruktoren für strukturierte Attribute (komplexe Werte) damit Aufgabe der ersten Normalform des Relationenmodells Tupeltypen (ROW Types) Kollektionstypen (Mengen, Multimengen, Listen, Arrays) Benutzerdefinierte Datentypen (UDT) Referenzdatentyp (REF) Subtypen und Subtabellen damit Verwendung objektorientierter Konstrukte bzw. OODBMS-Konstrukten Neue vordefinierte Datentypen Boolean, Binary Large Objects, Character Large Objects Rekursion (Berechnen der transitiven Hülle) Call Level Interface (CLI) dynamisches SQL Erweiterung von SQL zu voller Programmiersprache Trigger: Integrität und Unterstützung aktiver Datenbanken Rollen (roles) für verbesserte Autorisierung Data Warehousing-Operationen 2-41 Die wichtigsten Typen in SQL:1999 Ausgangspunkt: Tabellendefinition (CREATE TABLE): Definition von Zeilen implizit (wie bisher), d.h. durch Angabe eines Schemas explizit durch Row-Typdefinition Definition von Spalten durch vordefinierte Standarddatentypen (wie bisher) durch konstruierte Typen Typkonstruktoren: ROW / REF / ARRAY MULTISET (in SQL:2003) durch benutzerdefinierte Typen (user-defined data types, UDT) aufbauend auf vordefinierten, konstruierten, und/oder bereits existierenden benutzerdefinierten Typen Tabellen sind die einzigen Einstiegspunkte in die Datenbank Instanzen von Typen, die innerhalb einer Tabelle vorkommen, sind automatisch persistent

22 Erweiterte Tupeltabellen Die einfachste Form von Tabellen in ORDBMS wird als erweiterte Tupeltabelle bezeichnet. Erweiterte Tupeltabellen können neben Basisdatentypen in den Spalten folgende Typen verwenden Tupel Kollektionstypen (Mengen, Multimengen, Listen, Arrays) Tabellen (Multimengen von Tupeln) Eingebettete Objekte (strukturierte Werte) Referenzen (referenzierte Objekte) Large Objects (LOBs) Beispiel: Mitarbeiter (erweiterte Tupeltabelle mit nicht-atomaren Attributen) Name Adresse <Strasse, PLZ, Ort> Hobbys Bewerbung Dienstwagen Foto VARCHAR ROW(VARCHAR, INT, VARCHAR) SET(VARCHAR) Dossier(...) REF(Auto) SCOPE Wagen BLOB 'Urs' ROW('Rheinblick', 4004, 'Basel') SET('Literatur', 'Hornussen') Dossier(...) X' ' X'...' atomare Spalte tupelwertige Spalte mengenwertige Spalte objektwertige Spalte referenzwertige Spalte LOB- Spalte 2-43 Typisierte Tabellen (Objekttabellen) Typisierte Tabellen (auch Objekttabellen genannt) werden über einen benutzerdefinierten Typ definiert Die Zeilen in einer solchen Tabelle entsprechen den einzelnen Objekten des benutzerdefinierten Typs (in der Terminologie der Objektorientierung entspricht eine Objekttabelle dem Extent einer Klasse). Auf einzelnen Zeilen (Objekten) können (benutzerdefinierte) Methoden aufgerufen werden Neben den eigentlichen Objekten wird in einer zusätzlichen Spalte noch deren Objekt-ID (OID) verwaltet. Diese wird für Referenzen auf einzelne Objekte benötigt. benutzerdefinierter Typ (Objekttyp) Wagen (Objekttabelle) OID Hersteller Fotos Farbe PS Motor VARCHAR VARCHAR SET(BLOB) VARCHAR INTEGER Object(...) X' ' 'Lada Nova' SET(X'...', X'...') 'Braun' 33 Object(...) OID-Spalte strukturierter Wert (Objektwert)

23 Definition von strukturierten Typen Strukturierte Typen bieten die Möglichkeit zur Spezifikation benutzerdefinierter Typen CREATE TYPE Typname AS ( Attributdefinitionsliste ) [[NOT] INSTANTIABLE] [[NOT] FINAL] [Referenzgenerierungsart] [Methodendeklarationsliste]; CREATE TYPE AddressType AS ( Strasse VARCHAR(30), Ort VARCHAR(40), PLZ INTEGER, Land VARCHAR(25) ) NOT FINAL; vordefinierte Basistypen CREATE TYPE PersonType AS ( Name VARCHAR(30), Anschrift AddressType, Ehepartner REF(PersonType), Kinder REF(PersonType) ARRAY[10] ) NOT FINAL; Subtypen sind möglich benutzerdefinierter Typ konstruierte Typen 2-45 Definition von strukturierten Typen Objektverhalten kann in Methoden kodiert werden Methoden sind Funktionen, die sich auf genau einen strukturierten Typen beziehen Beispiel für eine Methodendeklaration: CREATE TYPE PersonType ( Name VARCHAR(30), Anschrift AddressType, Ehepartner REF(PersonType), Kinder REF(PersonType) ARRAY[10] ) NOT FINAL METHOD AnzahlKinder() RETURNS INTEGER; Realisierung über prozedurale SQL-Spracherweiterungen Überladen: Methodennamen können überladen werden Überschreiben: Methoden können in Subtypen überschrieben werden dynamisches Binden (Auswahl der Implementierung) zur Laufzeit

24 Kapselung von strukturierten Typen Attribute werden vollständig gekapselt für jedes Attribut werden automatisch Observer- und Mutator-Methoden generiert (für get bzw. set der Attributwerte) Observer: METHOD Strasse(AddressType) RETURNS VARCHAR(30); METHOD Ort(AddressType) RETURNS VARCHAR(40); METHOD Plz(AddressType) RETURNS INTEGER; METHOD Land(AddressType) RETURNS VARCHAR(25); Mutator: METHOD Strasse(AddressType, VARCHAR(30)) RETURNS AdressType; METHOD Ort(AddressType, VARCHAR(40)) RETURNS AdressType; METHOD Plz(AddressType,INTEGER) RETURNS AdressType; METHOD Land(AddressType, VARCHAR(25)) RETURNS AdressType; 2-47 Attributzugriff bei Instanzen strukturierter Typen Zugriff auf Attribute ist neben den Observer-Methoden auch über einen Dot-Operator möglich Lesen des Attributwerts: X.Attributname liefert Attribut von Objekt X Setzen des Attributwerts: SET X.Attributname = Wert Pfadausdrücke (navigierende Zugriffe) sind realisierbar durch wiederholte Anwendung des Dot-Operators Beispiel: BEGIN... DECLARE p PersonType; SET p = PersonType(); /* Konstruktor */ SET p.name = Harry Hasler ; SET p.anschrift.ort = Schwamendingen ;... END;

25 Definition von typisierten Tabellen Typisierte Tabellen (Objekttabellen) basieren auf einem strukturierten Typen Instanzen (Zeilen) sind Objekte dieses Typs CREATE TABLE Tabellenname OF Typname ( REF IS OID-Spalte [Referenzgenerierungsart] [, Spaltenoptions- bzw. Tabellenbedingungsliste] ); Beispiel: CREATE TABLE (REF IS oid Ehepartner Kinder Personen OF PersonType SYSTEM GENERATED, WITH OPTIONS SCOPE Personen, WITH OPTIONS SCOPE Personen); Referenzklausel (hier mit SYSTEM GENERATED) bestimmt die Art der Referenzgenerierung (OID-Erzeugung) Scope-Klausel muss für jedes Referenzattribut definiert werden Bestimmt typisierte Tabelle, auf dessen Instanzen referenziert wird 2-49 Definition von Tupeltypen (ROW Types) Ein Tupeltyp besteht aus einer Sequenz von Attribut/Datentyp-Paaren und ist eingebettet innerhalb von Typ- oder Tabellendefinitionen Beispiel: CREATE TABLE PersonenTupelTabelle ( Name ROW ( Vorname VARCHAR(15), Nachname VARCHAR(15)), Anschrift ROW ( Strasse VARCHAR(30), Ort VARCHAR(40), PLZ INTEGER, Land VARCHAR(25)) );

26 Typhierarchie Typhierarchien erlauben die Vererbung von Attributen und Methoden (Sub-/Supertyp-Beziehung) CREATE Type Subtypname UNDER Supertypname AS ( Attributdefinitionsliste ) [[NOT] INSTANTIABLE] [Methodendeklarationsliste]; [[NOT] FINAL] Beispiel: Mitarbeiter als spezielle Personen CREATE TYPE EmployeeType UNDER PersonType AS ( PNr INTEGER, Bewerbung CLOB(50K), Bild BLOB(5M), Vorgesetzter REF(EmplpoyeeType), Projekte REF(ProjectType) ARRAY[10], Gehalt Franken ) NOT FINAL METHOD Gehaltserhöhung() RETURNS Franken; Mehrfachvererbung ist nicht möglich (es gibt maximal einen direkten Supertyp) 2-51 Beispiel: Definition von SQL-Methoden CREATE METHOD AnzahlKinder() RETURNS INTEGER FOR PersonType RETURN CARDINALITY(SELF.Kinder); CREATE METHOD Gehaltserhöhung RETURNS Franken FOR EmployeeType BEGIN DECLARE altesgehalt Franken; SET altesgehalt = SELF.Gehalt; IF (SELF.AnzahlKinder < 3) OR (SELF.AnzahlProjekte < 2) THEN SET SELF.Gehalt = 1,03 * altesgehalt; ELSE SET SELF.Gehalt = 1,05 * altesgehalt; ENDIF IF (SELF.Gehalt > ) THEN SIGNAL 'Gehalt zu hoch'; RETURN SELF.Gehalt; END;

27 Tabellenhierarchie Die Tabellenhierarchie erlaubt extensionale Teilmengen-Beziehungen zwischen Sub- und Supertabelle Alle Instanzen einer Subtabelle sind auch Instanzen der zugehörigen Supertabelle(n) CREATE TABLE Tabellenname OF Typname UNDER Supertabellenname ( [, Spaltenoptions- bzw. Tabellenbedingungsliste] ); CREATE TABLE Mitarbeiter OF EmployeeType UNDER Personen (Vorgesetzter WITH OPTIONS SCOPE Mitarbeiter, Projekte WITH OPTIONS SCOPE Projekt); Der Typ der Subtabelle muss ein direkter Subtyp des Typs der Supertabelle sein 2-53 Beispiel: typisierte Tabellen und Subtabellen Personen OF PersonType OID Name Anschrift Ehepartner Kinder VARCHAR VARCHAR AddressType REF(PersonType) Mitarbeiter OF EmployeeType UNDER REF(PersonType) ARRAY[10] OID Name Anschrift Ehepartner Kinder PNr Bewerbung... Gehalt VARCHAR VARCHAR Address Type REF(Person Type) REF(PersonType) ARRAY[10] INTEGER CLOB... Franken

28 Einfügeoperationen INSERT INTO Personen VALUES ('Hasler', AddressType().Strasse('Luegislandstrasse 12').Ort( 'Zürich').PLZ(8051).Land('CH'), NULL, NULL); erzeugt eine Person INSERT INTO Mitarbeiter VALUES ('Harry', AddressType().Strasse('Rosswiesen 7').Ort( 'Zürich').PLZ(8051).Land('CH'), NULL, NULL, 1234, NULL, NULL, NULL, Franken(5000)); erzeugt einen Mitarbeiter INSERT INTO Mitarbeiter VALUES ('Moritz', AdressTyp().Strasse('Claragraben 22').Ort( 'Basel').PLZ(4051).Land('CH'), NULL, NULL, 6789, NULL, NULL, (SELECT oid FROM Mitarbeiter WHERE Name = 'Harry'), Franken(3500)); erzeugt einen Mitarbeiter Setzen einer Objektreferenz 2-55 ORDBMS: Beispielanfragen SELECT * FROM Personen; SELECT * FROM Mitarbeiter; SELECT * FROM ONLY(Personen); SELECT * FROM Mitarbeiter WHERE Vorgesetzter->Name = 'Harry'; gibt alle Personen zurück, auch die Mitarbeiter gibt alle Mitarbeiter zurück gibt nur die Personen zurück, die keine speziellen Personen (z.b. Mitarbeiter) sind Dereferenzierung über Pfeil-Operator -> SELECT * FROM Mitarbeiter WHERE Vorgesetzter->Anschrift.PLZ = 8051; Dereferenzierung mit anschliessendem Komponentenzugriff SELECT DEREF(Ehepartner) FROM Mitarbeiter; Dereferenzierung mittels DEREF-Operator

29 in der SELECT-Klausel Methoden-/Funktionsaufrufe SELECT FROM Anzahl(Projekte) Mitarbeiter; liefert einen Wert in der WHERE-Klausel SELECT Name FROM Mitarbeiter WHERE Grossverdiener(Gehalt); liefert TRUE oder FALSE in der FROM-Klausel SELECT Name FROM GuteMitarbeiter(); liefert eine Menge von Mitarbeitertupeln SQL:1999 unterstützt diese Variante nicht! 2-57 Vergleich: SQL-92 SQL:99 SQL:2003 SQL-92 Tupeltabellen Basistabellen zur Speicherung von Daten Sichten (Views): abgeleitete Tabellen Typ eines Attributs ist ein Basisdatentyp (1NF) Zeilen (Tupel) setzen sich aus Instanzen der jeweiligen Wertebereiche zusammen MULTISET ROW Basisdatentypen INTEGER, SMALLINT, NUMERIC, DECIMAL, REAL, FLOAT, CHARACTER, DATE, TIME, BIT,... Basisdatentyp Integritätsbedingungen Primär-/Fremdschlüssel, Check-Klauseln Assertions: Bedingungen über mehrere Tabellen Zugriffsrechte (Grants)

30 Vergleich: SQL-92 SQL:99 SQL:2003 SQL:99 (in 1999 verabschiedete Erweiterung von SQL-92; teilweise bereits seit längerer Zeit in kommerziellen DBMS implementiert) SET MULTISET OBJECT ROW ARRAY REF Basisdatentyp Einstiegspunkte in die Datenbank: Typisierte Tabelle: SET(OBJECT(...)) Untypisierte Tabelle: MULTISET(ROW(...)) Subtypbeziehung Untermengenbeziehung Quelle: C. Türker: SQL:99 und SQL:2003. dpunkt.verlag, Vergleich: SQL-92 SQL:99 SQL:2003 SQL:2003 (in 2004 verabschiedete Erweiterung von SQL:99; Erweiterungen grösstenteils (noch) nicht implementiert) SET MULTISET OBJECT ROW MULTISET ARRAY REF Basisdatentyp Einstiegspunkte in die Datenbank: Typisierte Tabelle: SET(OBJECT(...)) Untypisierte Tabelle: MULTISET(ROW(...)) Subtypbeziehung Untermengenbeziehung Quelle: C. Türker: SQL:99 und SQL:2003. dpunkt.verlag,

31 CREATE TYPE AddressType AS ( Strasse VARCHAR(30), Ort VARCHAR(40), PLZ INTEGER, Land VARCHAR(25) ) NOT FINAL; Beispiel (Schema) CREATE TYPE PersonType AS ( Name VARCHAR(30), Anschrift AddressType, Ehepartner REF(PersonType), Kinder REF(PersonType) ARRAY[10] ) NOT FINAL; CREATE TABLE (REF IS oid Ehepartner Kinder Personen OF PersonType SYSTEM GENERATED, WITH OPTIONS SCOPE Personen, WITH OPTIONS SCOPE Personen); 2-61 Beispiel (Schema) CREATE TABLE PersonenTupelTabelle ( Name ROW ( Vorname VARCHAR(15), Nachname VARCHAR(15)), Anschrift ROW ( Strasse VARCHAR(30), Ort VARCHAR(40), PLZ INTEGER, Land VARCHAR(25)) ); CREATE TYPE ProjektType AS ( PName VARCHAR(30), Budget Number(10,2), Leiter REF(EmployeeType), Mitarbeiter REF(PersonType) MULTISET ) NOT FINAL;

32 Beispiel (Schema) CREATE TYPE EmployeeType UNDER PersonType AS ( PNr INTEGER, Bewerbung CLOB(50K), Bild BLOB(5M), Vorgesetzter REF(EmplpoyeeType), Projekte REF(ProjectType) ARRAY[10], Gehalt Franken ) NOT FINAL METHOD Gehaltserhöhung() RETURNS Franken; CREATE TABLE Mitarbeiter OF EmployeeType UNDER Personen (Vorgesetzter WITH OPTIONS SCOPE Mitarbeiter, Projekte WITH OPTIONS SCOPE Projekt); CREATE TABLE (REF IS oid Leiter Mitarbeiter Projekte OF ProjektType SYSTEM GENERATED, WITH OPTIONS SCOPE Mitarbeiter, WITH OPTIONS SCOPE Mitarbeiter); 2-63 Beispiel: Anfragen Wie lauten die Namen aller Projektleiter? Geben Sie die Namen, Wohnort und das Gehalt aller Mitarbeiter von Projekt ABC aus

33 Literatur G. Saake, C. Türker, I. Schmitt: Objektdatenbanken - Konzepte, Sprachen, Architekturen, International Thomson Publishing, 1997 A. Heuer: Objektorientierte Datenbanken - Konzepte, Modelle, Standards und Systeme, Addison-Wesley, 2. Auflage, 1997 C. Türker: SQL:1999 und SQL:2003. dpunkt.verlag, C. Türker, G. Saake: Objektrelationale Datenbanken. dpunkt.verlag, A. Geppert: Objektrelationale und objektorientierte Datenbanksysteme, dpunkt.verlag,