Objektorienterte databasesystemer (OODBS)

Transkript

1 Objektorienterte databasesystemer (OODBS) Inneholder lysark laget av Arthur M. Keller, Vera Goebel, Pål Halvorsen og Ragnar Normann INF Ragnar Normann, Ifi, UiO Ark 1 av 43

2 Oversikt OO begreper og OODBS egenskaper objektidentitet/objektidentifikator (OID) objekter & verdier ekstensjon (forekomstene av en klasse) komplekse objekter og typekonstruktører operatorer programmeringsspråkkompatibilitet (sømløshet) innkapsling (information hiding) type/klassehierarkier, arv og polymorfisme INF Ragnar Normann, Ifi, UiO Ark 2 av 43

3 Datamodeller & databasesystemarkitekturer - Kronologisk Oversikt - Nettverksdatamodellen (1964) Den hierarkiske datamodellen (1968) Relasjonsdatamodellen (1970) Objektorienterte datamodeller (~ 1985) Objektrelasjonelle datamodeller (~ 1990) Semistrukturerte datamodeller (XML 1.0) (~ 1998) INF Ragnar Normann, Ifi, UiO Ark 3 av 43

4 OO-begreper og OODBS-egenskaper INF Ragnar Normann, Ifi, UiO Ark 4 av 43

5 Objektorienterte begreper Modeller interesseområdet (miniverdenen, Universe of Discourse, UoD) som en samling av samarbeidende enheter, kalt objekter Abstraksjon og autonomi: objekt: <verdi, {operatorer> (operatorene implementeres som metoder) verdi: datastruktur innkapsling (skjuling av informasjon) krav om oppførsel fra andre objekter Klassifikasjon: felles beskrivelse (intensjon) samling av likeartede objekter (ekstensjon, klasse) Taksonomi: super-/subklasser arv av egenskaper polymorfisme INF Ragnar Normann, Ifi, UiO Ark 5 av 43

6 Hensikten med OO-datamodell UoD og OODB data model database? record oriented data model 1:N object oriented data model 1:1 database database INF Ragnar Normann, Ifi, UiO Ark 6 av 43

7 Fordeler med OO-datamodellering UoD objektorientert datamodell 1:1 database Naturlighet (sammenlignet med tradisjonelle datamodeller) meningsfull abstraksjon / høy modularitet kontroll med kompleksitet separasjon av grensesnitt og implementasjon Evolusjonær systemdesign inkrementell programmering gjenbrukbarhet INF Ragnar Normann, Ifi, UiO Ark 7 av 43

8 Objektorienterte databasesystemer OODBS = DBS med OO-datamodell OO-database = samling av objekter Objekt = <OID, verdi, {operatorer> Hvert objekt har sine egne spesifikke egenskaper INF Ragnar Normann, Ifi, UiO Ark 8 av 43

9 OODBS og objektverdier Objekt = <OID, verdi, {operatorer> Eksempel på verdi: class athlete { text name; integer salary; V1 = tuple of (name: Solskjær, salary: ) V2 = tuple of (name: Berg, salary: ) V3 = tuple of (name: Dæhli, salary: ) O1 = <, V1, > O2 = <, V2, > O3 = <, V3, > INF Ragnar Normann, Ifi, UiO Ark 9 av 43

10 OODBS og objektoperatorer Objekt = <OID, verdi, {operatorer> Verdioperatorer: Prosessering av hele objekter - avhengig av aktuell struktur Endring av verdier Generiske operatorer: Prosessering av individuelle objektnivåer - struktur er irrelevant Ett-nivå / multi-nivå operatorer (sammensate objekter) Også: seleksjon, navigasjon,... INF Ragnar Normann, Ifi, UiO Ark 10 av 43

11 Egenskaper i et OODBS Må ha: objektidentitet komplekse (sammensatte) objekter typer/klasser brukerdefinerte typer språkkompletthet innkapsling arv: type/klassehierarkier polymorfismer: overlasting/redefinisjon/ sen binding... alt ortogonalt Bør ha: objektversjoner spesifikk realisering (implementasjon) av begreper distribusjon (klient/server arkitekturer) visse prosesseringsaspekter, f.eks. nye transaksjonsmekanismer regel-baserte mekanismer (aktive/deduktive muligheter)... og mye mer INF Ragnar Normann, Ifi, UiO Ark 11 av 43

12 Objektidentifikatorer (OID) Objekter eksisterer uavhengig av sine (nåværende) verdier enhver modifikasjons resulterer i samme objekt ingen misvisende referanser til objekter identitet =/= likhet (begge må kunne uttrykkes) OIDer kan ikke baseres (pålitelig) på ordinære verdier skaffet til veie av applikasjonen (verdiorientering)... men på surrogater: OIDer er (system-vidt) entydige uforanderlige i hele objektets levetid ikke brukt om igjen etter sletting vanligvis generert og håndtert av systemet generiske objektoperatorer: sammenligning av objekter gjenfinning av objekter... basert på OID INF Ragnar Normann, Ifi, UiO Ark 12 av 43

13 Komplekse (sammensatte) Objekter Vi har to typer komplekse objekter: Ustrukturerte: lange felt (BLOBer - binary large objects) Strukturerte: INF Ragnar Normann, Ifi, UiO Ark 13 av 43

14 Typer / klasser Intensjon (felles beskrivelse av likedanne objekter) Klasse Op1 Op2 Opprettelse av instanser instansiering Ekstensjon (mengde av eksisterende instanser) Brukerne kan selv definere sine egne typer objekt_1 objekt_2 objekt_3 Op1, Op2 Op1, Op2 Op1, Op2 INF Ragnar Normann, Ifi, UiO Ark 14 av 43 instansiering

15 Innkapsling Synlig for brukerne av klassen Definisjon av operatorenes grensesnitt Skjult for brukerne av klassen Definisjon av verdityper (datastruktur for objekttilstanden) Implementasjon av operatorene INF Ragnar Normann, Ifi, UiO Ark 15 av 43

16 Arv: Type/klassehierarkier Objekttyper er ikke alltid uavhengig av hverandre: generalisering/spesialisering subtyper/supertyper Instanser av subtyper arver egenskaper fra supertyper Former: enkel arv (typehierarki), multippel arv (typelattice) Fordeler ved arveprinsippet: gjenbruk av kode reusability (når operatorer arves) representasjon av tilleggssemantikk designdisiplin (stegvis forfining) INF Ragnar Normann, Ifi, UiO Ark 16 av 43

17 Polymorfisme: Overlasting, redefinisjon, sen binding Overlasting: bruk av samme navn for forskjellige operatorer (i forskjellige typer) Redefinisjon: reimplementasjon av operatorer på et lavere nivå i typehierarkiet Sen binding: bind et operatornavn til en assossiert implementasjon senere, dvs. individuelt for hvert objekt ved run-time print_geometric_object (o: g_obj) (implementert for sirkler, rektangler, triangler osv) for all x do print_geometric_object(x); vs. for all x do case x is circle: print_circle(x); x is rectangle: print_rectangle(x); x is triangle: print_triangle(x); otherwise exception handling); INF Ragnar Normann, Ifi, UiO Ark 17 av 43

18 ODL (Object Description Language) INF Ragnar Normann, Ifi, UiO Ark 18 av 43

19 Oversikt ODL (Object Definition Language) klasser attributter relasjoner metoder typesystemer ekstensjoner nøkler arv INF Ragnar Normann, Ifi, UiO Ark 19 av 43

20 Objektorientert DBMS standardisering ODMG: Object Data Management Group en OO standard for databaser ODL: Object Description Language design i OO-stil OQL: Object Query Language SQL-likt spørrespråk mot OO-databaser med et ODL-schema INF Ragnar Normann, Ifi, UiO Ark 20 av 43

21 ODL klassedeklarasjoner Klassedeklarasjoner omfatter: Navn på klassen Key deklarasjon av nøkler, ikke påkrevd Extent navn på mengden som til enhver tid består av de eksisterende objektene av klassen Element deklarasjon(er): et element er et attributt, en relasjon, eller en metode Syntaks: class <name> { <elements = attributes, relationships, methods> INF Ragnar Normann, Ifi, UiO Ark 21 av 43

22 Attributter: ODL Elementdeklarasjoner: Syntaks: attribute <type> <name>; Eksempel: name addr license Bars Attributter - I involverer ikke-objektverdier som heltall og tekststrenger class Bars { attribute string name; attribute Struct addr { string street, string city address; attribute Enum lic { full, beer, none licensetype; INF Ragnar Normann, Ifi, UiO Ark 22 av 43

23 ODL Elementdeklarasjoner: Attributter - II Strukturerte typer har navn og en liste av felt-type par attribute Struct addr {string street, string city address; Enumerte type har navn og en liste med verdier attribute Enum lic {full, beer, none licensetype; Hvorfor navngir vi strukturer og enumerasjoner? name addr license name addr Bars Frequents Drinkers class Drinkers { attribute string name; attribute Struct Bars::addr address; NOTE 1: Reuse of the Struct addr attribute in the class Bars NOTE 2: Elements from another class is indicated by <class>::<name> INF Ragnar Normann, Ifi, UiO Ark 23 av 43

24 ODL Elementdeklarasjoner: Relasjoner - I Relasjoner forbinder objekter; de er referanser Syntaks: relationship <type> <name>; Eksempler: relationship Set<Person> haskids; relationship Person haswife; relationship Set<Car> owncars; INF Ragnar Normann, Ifi, UiO Ark 24 av 43

25 ODL Elementdeklarasjoner: Relasjoner - II Relasjoner kommer i inverse par Eksempel: Serves mellom Beers og Bars er representert av en relasjon i Bars som angir hvilke ølmerker som selges, og en relasjon i Beers som angir hvilke barer som selger det. Bars Serves Beers class Bars { relationship Set<Beers> serves inverse Beers::servedAt; class Beers { relationship Set<Bars> servedat inverse Bars::serves; INF Ragnar Normann, Ifi, UiO Ark 25 av 43

26 ODL Elementdeklarasjoner: price Prices Relasjoner - III Bare binære relasjoner er støttet: Flerveis relasjoner krever en egen forbindelsesklasse BBP Bars Serves Beers NOTE 1: Inverses for thebar, thebeer must be added to Bars, Beers The- Bar The- Beer The- Price Bars Beers Price class Prices { attribute real price; relationship Set<BBP> tobbp inverse BBP::thePrice; class BBP { /*beers-bars-prices*/ NOTE 2: relationship Bars thebar inverse... might in this case use only relationship Beers thebeer inverse... attribute price attribute relationship float Price price; theprice inverse Prices::toBBP; INF Ragnar Normann, Ifi, UiO Ark 26 av 43

27 ODL Elementdeklarasjoner: Relasjoner - IV Mange-til-mange relasjoner har en set-type i hver retning Bars Serves Beers class Bars { relationship Set<Beers> serves inverse Beers::servedAt; class Beers { relationship Set<Bars> servedat inverse Bars::serves; INF Ragnar Normann, Ifi, UiO Ark 27 av 43

28 ODL Elementdeklarasjoner: Relasjoner - V Mange-til-en relasjoner har en set-type for en-siden og et klassenavn for mange-siden Manufacturer made by Beers class Manufacturer { relationship Set<Beers> producebeers inverse...; class Beers { relationship Manufacturer producedby inverse...; INF Ragnar Normann, Ifi, UiO Ark 28 av 43

29 ODL Elementdeklarasjoner: Relasjoner - VI En-til-en relasjoner har klassenavn for begge Manufacturer Bestseller Beers class Manufacturer { relationship Beers isbestsellingbeer inverse...; class Beers { relationship Manufacturer hasbestsellingbeer inverse...; INF Ragnar Normann, Ifi, UiO Ark 29 av 43

30 ODL Elementdeklarasjoner: Metoder Et stykke eksekverbar kode som kan brukes av objektene i klassen Parametrene kan være av typene: in, out og inout Objektet er selv en skjult parameter Metoden kan returnere en verdi Metoden kan kreve unntaksbehandling (raise exceptions) Bare signaturene blir definert i ODL-klassene; koden skrives i et vertsspråk og er ikke en del av ODL Eksempel: class Bars {... void availablebeers(out Set<Beers>);... INF Ragnar Normann, Ifi, UiO Ark 30 av 43

31 ODLs typesystem Basistyper: integer, real, float, character, string, enumerated types, boolean, m.fl. Typekonstruktører: Struct en struktur, dvs. en liste av type navn -par Samlingstyper (Collection types): Set<T> uordnet mengde av (forskjellige) objekter av type T Bag<T> uordnet samling objekter av type T; duplikater er tillatt List<T> ordnet samling objekter av type T; duplikater er tillatt Array<T> ordnet, indeksert samling objekter av type T; duplikater er tillatt Dictionary<S,T> mengde av objektpar av type S,T En type i en relasjon kan bare være en klasse eller en samling av en klasse INF Ragnar Normann, Ifi, UiO Ark 31 av 43

32 ODL-nøkler I ODL trenger ikke klasser å ha nøkler. OID-en skiller mellom objekter som har samme verdier i sine elementer Nøkler angis med key (eller keys) og en liste av attributter som utgjør nøkkelen Flere lister kan angis for å definere flere alternative nøkler Parenteser brukes for å gruppere medlemmene i flerverdi-nøkler: key(a 1,a 2,, a n ) = en nøkkel med n attributte keys a 1,a 2,, a n = hver a i er en nøkkel, og hver av dem kan være en flerverdinøkkel, dvs. at a i =(b 1,b 2,, b k ) Eksempel: en enkeltverdinøkkel: class Beers (key name) { attribute string name; Eksempel: to to-verdi nøkler: class Courses (key (dept, number), (room, hours)) {... Når vi har skrevet og sagt attributter ovenfor, er det egentlig feil; både relasjoner og metoder kan inngå i nøkler INF Ragnar Normann, Ifi, UiO Ark 32 av 43

33 Instansierbare klasser og ekstenssjoner i ODL Det er forskjell mellom klassedefinisjonen og mengden av eksisterende objekter (ekstensjonen) av en klasse I OQL angir vi ekstensjonen med kodeordet extent etterfulgt av et navn på mengden av objekter En klasse kan bare instansieres, dvs. at man kan lage objekter av klassen, hvis den er definert med kodeordet class Eksempel: class Student (extent students key SSN){... INF Ragnar Normann, Ifi, UiO Ark 33 av 43

34 ODL signaturklasser ODL gir støtte for signaturklasser, som essensielt er klasser uten egne objekter Nyttig når vi har flere klasser med forskjellig ekstensjon men felles egenskaper; eksempelvis er både studenter og lærere personer Signaturklasser defineres med nøkkelordet interface Signaturklasser kan ikke instansieres og brukes bare som en hjelp til å definere andre klasser. Derfor er det meningsløst å bruke nøkkelordene extent og key i klassedefinisjonen til en signaturklasse Eksempel: interface Person { attribute integer SSN; class Student : Person (extent students key SSN){... class Teacher : Person (extent teachers key SSN){... INF Ragnar Normann, Ifi, UiO Ark 34 av 43

35 ODL subklasser og arv - I En subklasse arver alle egenskapene fra sin superklasse, f.eks. får objektene i klassen Ales alle attributter og relasjoner til klassen Beers Superklasser angis ved å prefikse med: colon (:) for signaturklasser nøkkelordet extends for instansierbare klasser Eksempel: Ales er øl med farge class Ales extends Beers { attribute string color; name Beers isa Ales color manf Signaturklasser kan bare arve fra andre signaturklasser INF Ragnar Normann, Ifi, UiO Ark 35 av 43

36 ODL subklasser og arv - II Multippel arv: color manf Angis med nøkkelordet extends og en liste av klasser separert med kolon (:). Eksempel: class Amphibian extends car:boat {... Navnekonflikter er ikke tillatt, og det er brukerens ansvar å unngå dem INF Ragnar Normann, Ifi, UiO Ark 36 av 43 car isa color amphibian Alle klasser kan arve fra vilkårlig mange signaturklasser, men en (instansierbar) klasse kan bare arve fra en instansierbar klasse, så en klasse kan ikke være ekstensjon av mer enn én klasse boat isa manf

37 ODL Eksempel - I name number money hours controls Project works on SSN name Person addr manages isa Department works for Employee name number addr salary INF Ragnar Normann, Ifi, UiO Ark 37 av 43

38 ODL Eksempel - II name number money hours SSN name addr controls Project works on Person manages Department Employee works name number addr for salary isa interface Person { attribute integer SSN; attribute string name; attribute Struct address { string street, string city addr; NB: Signaturklasse (interface) ingen extent eller key INF Ragnar Normann, Ifi, UiO Ark 38 av 43

39 ODL Eksempel - III name number money hours SSN name addr controls Project works on Person manages Department Employee works name number addr for salary isa NOTE 1: Arver alle egenskaper fra signaturklassen Person NOTE 2: Relasjoner defineres som inverse par NOTE 3: Mange-siden i en relasjon er en set-type NOTE 4: En-siden er ikke en set-type class Employee : Person (extent employees key SSN) { attribute integer salary; relationship Department works_for inverse Department::has_Emp; relationship Department manages inverse Department::manager; relationship Set<Project> works_on inverse Project::members; INF Ragnar Normann, Ifi, UiO Ark 39 av 43

40 ODL Eksempel - IV name number money hours SSN name addr controls Project works on Person name Department number addr manages works for Employee salary class Department (extent departments key number) { attribute integer number; attribute string name; attribute Struct Person::address addr; relationship Employee manager inverse Employee::manages; relationship Employee has_emp inverse Employee::works_for; relationship Set<Project> controls inverse Project::contr_by: INF Ragnar Normann, Ifi, UiO Ark 40 av 43 isa MERK gjenbruk av address fra klassen Person

41 ODL Eksempel - V name number money hours SSN name addr controls Project works on Person manages Department Employee works name number addr for salary isa class Project (extent projects key number) { attribute integer number; attribute string name; attribute integer money; relationship Department contr_by inverse Department::controls; relationship Set<Employee> members inverse Employee::works_on; INF Ragnar Normann, Ifi, UiO Ark 41 av 43

42 ODL Eksempel - VI name number money hours SSN name addr controls Project works on Person Department manages works name number addr for salary NOTE 1: Bare binære relasjoner er tillatt Employee NOTE 2: Inverse må legges til i Project og Employee the project Project class WorkingHours { attribute integer hours; relationship Project theproject inverse Project::emp_hours; relationship Employee theemployee inverse Employee::proj_hours; INF Ragnar Normann, Ifi, UiO Ark 42 av 43 isa Working Hours hours the employee Employee

43 Oppsummering OO konsepter og OODBS egenskaper støttet av ODL: klasser: signatur- og instansierbare klasser superklasser/subklasser arv relasjoner typesystem ekstensjoner nøkler INF Ragnar Normann, Ifi, UiO Ark 43 av 43