ogrammering - kth · bara del objektet. h oncept. för v xitet. 2d1470 22. delar man det måste att...

Objektorienterad programmering

Objektorientering . . .

I literaturen är det svårt att finna en exakt definition av”objektorientering”. Här görs en ”jämförelse” baserad på framfördaåsikter.

• Cardelli och Wegner [1]: Ett språk är objektorienterat endast om det:

◆ stödjer objekt som är dataabstraktioner med ett gränssnitt mednamngivna operationer och ett dolt inre tillstånd

◆ objekt associeras med en objekttyp och◆ typer kan ärva egenskaper från super-typer

2D1470 Bildserie 4 bild 1

Objektorienterad programmering . . .

• Wegner [2] ser tre typer av ”objekt”-språk

◆ Språk som har något som liknar objekt kallas objektbaserade (t.ex.Ada).

◆ Språk som har något som liknar objekt och tillåter definition avklasser kallas klassbaserade (t.ex. CLU och Oberon).

◆ Ett objektorienterat språk ska ha objekt, klasser och arv (t.ex. Simulaand Smalltalk).

Wegner skiljer även på starkt och svagt typade objektorienteradespråk.



• Nierstrasz [3] tycker att de flesta definitioner av vadobjektorientering är är för restriktiva och anser att språk mycket välkan kallas objektorienterade även om de inte stödjer arv. ”Alla språksom kan användas för någon form av inkapsling är väl i viss måmnobjektorienterade.”



• Blair [4]:

◆ inkapsling gruppering av egenskaper med ett väldefinieratgränssnitt för att komma åt egenskaperna.

◆ Klassifikation är ett sätt att gruppera objekt med gemensammaegenskaper. Kan åstadkommas m.h.a. typer, klasser eller prototyper.

◆ Polymorfi eller flexibelt delande är enligt Blair att ett objekt kan hamer än en typ. Overloading, arv och subtypning är olika sätt attåstadkomma polymorfi.

◆ Interpretation är polymorfiresolution där olika typnings- ochbindningsstrategier används



Följande verkar allmänt accepterat som karakteristiskt förobjektorienterade språk [5, 6, 7, 8, 9, 10, 11, 12, 13, 14]

• Objekt . Ett paket med både data och kod. De ska vara förstaklassens värden i den meningen att operationer i språket ska taobjekt eller referenser till objekt som argument och kunna levereraett objekt (ev. via referens) som resultat av en beräkning.

• Arv . Klasser kan organiseras som en hierarki av sub- ochsuperklasser,Om en klass kan ärva mer än en superklass sägs detstödja multipelt arv som i C++ [10, 15, 13] och Eiffel [11]. Annarssägs det stödja enkelt arv som i Simula [16], SmallTalk [17] och Java[8].



• Dynamisk bindning används för att tillåta att koden för en operationväljs under körning medan då statisk bindning används koden väljsvid kompileringstillfället.

• Inkapsling används för att dölja ett objekts inre tillstånd och lokalametoder. Man skiljer dels mellan syntaktiskt och semantiskt skydd,dels mellan klass- och objekt- nivåskydd.



◆ Syntaktiskt skydd erhålls genom syntaktiska element som t.ex.deklaration att vissa delar av objekt ska vara osynliga (private),synliga i subklasser (protected) eller helt synliga (public).

◆ Semantiskt skydd erhålls genom scope-regler. Man skiljer mellan■ första ordningens semantiskt skydd , t.ex. Smalltalks

instansvariabler (som aldrig syns utanför ett objekt).■ andra ordningens semantiskt skydd , varigenom t.ex. lokalt

deklarerade klasser i Simula helt enkelt inte har någon meningutanför aktuellt scope.

◆ Klassnivåskydd används av Java och C++ och innebär att objekt ursamma klass kan se varandras privata delar.

◆ Objektnivåskydd används av t.ex. Simula, Eiffel och Smalltalk.Objektens privata delar syns inte annat än i det egna objektet.


Objektorienterad programmering – extra . . .

Trots att typning, skräpsamling, persistens och reflektion inte ingår iobjektorienteringens begreppsapparat anses de mycket viktiga förobjektorienterade språk [18]:


Objektorienterad programmering – typning . . .

• Typning . Man har två klassifikationssystem – ett som har med vadsom associeras med typ att göra och ett som avser styrkan itypsystemet

◆ I statiskt typade språk är endast identifierare associerade med typ.Då kan kompilatorn direkt avgöra typen på resultat av beräkningar.

◆ I dynamiskt typade språk associeras värdena med typ och dåmåste typkontrollen vänta tills just då en beräkning ska ske.

◆ Med stark typning kan kompilatorn alltid avgöra om ett program ärkorrekt typat. Stark typning kräver statisk typning. De flestaOOP-språken är ”näst intill” starkt typade (Starkt typade utom förnågra få mer flexibla konstruktioner, där typkontrollen sker underkörning.


Objektorienterad programmering – extra . . .

• Skräpsamling . Alla objektorienterade system skapar och kastarmassor av objekt under pågående körning så rensning av minnet ärviktigt.

• Persistens låter programvariablers värden överleva mellankörningarna.

• Linguistisk reflektion tillåter att det körande programmet genererar,kompilerar och integrerar nya subprogram i det körandeprogrammet.

Varje objektorienterat språk har dessutom sin egen mängd med extragodis. Här diskuteras endast de hittills uppräknade begreppen.


ObjektCitat:

• Ett objekt är något identifierbart i samband med en begäran om atten operation ska utföras [19] (??)

• Ett objekt är en mängd operationer som samsas om ett (inre)tillstånd [2].

• I ett objektorienterat system representeras varje föremål i den reellavärlden av ett objekt [20].

• Ett objekt är en mängd inkapslade operationer eller metoder somkan anropas utifrån och ett inre tillstånd som minns effekten av attmetoderna anropas [4].


Objekt . . .

Ett objekt är ett ”paket” med både data och kod, en enhet som kapslarin både egenskaper som utgör objektets inre tillstånd och beteendesom modelleras med hjälp av procedurer och funktioner som kallasmetoder och som definierar hur man får tillgång till det inre tillståndetoch hur detta inre tillstånd ska modifieras.

Objekt ska vara första klassens värden – d.v.s. att operationer skakunna ta objekt eller objektreferenser som argument och leverera ettobjekt (eller en referens till ett objekt) som resultat ev en beräkning.

Objekt kan kommunicera med andra objekt genom anrop av andraobjekts metoder. Objektorienterade program vilar tungt på dennainteraktion som grundläggande metod för programexekvering.


Objekts inre tillstånd

Citat:

• Ett inre tillstånd handlar om den information som måste kommasihåg då ett anrop förändrar alla andra anrops framtida beteende (??)[21].

• Ett objekt består bland annat av ett privat minne som innehållerobjektets inre tillstånd. Detta privata minne består av värdena hos enmängd instansvariabler [22].


Objekts inre tillstånd . . .

De instansvariabler som utgör ett objekts inre tillstånd brukar kallasdess attribut.

Dessa kan vara enstaka värden eller mängder av värden. I det senarefallet krävs någon lagringsstruktur så attributet brukar vara en referenstill lagringsstrukturen.

Den interna strukturen kan alltså vara godtyckligt komplex.

Dessutom kan ett objekts interna struktur helt eller delvis delas medandra objekt. Det krävs då att objektets interna struktur skyddas motoönskad manipulation.


Objekts beteende

Objektens beteende bestäms av de operationer man kan utföra påobjektet. Varje operation implementeras av en metod .

Olika objekt kan ha olika metoder för samma operation p.g.a.arvsmekanismerna.

Det kan också finnas mer än en implementation per operation då vissasystem tillhandahåller overloading .

I vissa språk är metodanrop det enda medlet för att nå objektens inretillstånd medan andra tillåter direkt access till attributen.


Objekts beteende . . .

En metod beskrivs av

• dess signatur , som består av metodnamnet, klassnamnet ochmetodens egen typ (den kartesiska produkten av alla parametrar)och

• dess implementation , som definierar den sekvens av operationersom utförs då metoden anropas.

I de flesta teoretiska sammanhang betraktas mottagarobjektet vara denförsta parametern till ett anrop ( obj 1.add(obj 2)≡ obj 1 + obj 2).



Man kan kategorisera metoder efter avsedd användning

kategori användningkonstruktor Skapar ett nytt objekt,destruktor Förstör ett objekt (återlämnar alla resurser till syst)selektor Återsänder info om inre tillstånd, möjligen

efter någon beräkning,mutator Modifierar inre tillstånd hos ett objektpredikat Utför kontroll baserad på objektets inre tillståndkombinator Mutator + selektor



Metoder uppnår sin effekt genom:

• Parametrar Selektorer har oftast ingen explicit parameter.• Bieffekter Alla metoder som uppdaterar det inre tillståndet

genom bieffekter. Generellt sett ska selektoreroch predikat inte ha bieffekter.

• Returvärden Mutatorer och destruktorer återsänder intevärden medan alla andra metoder gör det.


Multimetoder.

Då ett meddelande skickas är det mottagarobjektets klass som avgörvilken metod som ska anropas. Ibland är det bättre att se en mängdmetodspecifikationer som en specifikation av en enda metod medkontextberoende metodkropp där kontext ges av delsmottagarobjektets klass, dels av antalet och typerna för alla argument.Sådana metoder kallas för överlagrade (överladdade, overloaded) ellerför multimetoder.


Associationer mellan objekt

Objektorienterade program exekverar genom att de sändermeddelanden till varandra och tar emot och bearbetar de svar someventuellt genereras av mottagarobjektet.

För att kunna göra så måste ett objekt kunna hitta alla objekt som detska skicka meddelanden till. Detta sker genom att objektet, bland sinaattribut, har referenser till mottagarobjekten – direkt eller indirekt vianågon lagringsstruktur eller via något annat objekt.

Referenserna utgör associationer mellan objekten i programmet ochobjektens associationer spänner upp en grafstruktur. Det är möjligt attsärskilja olika typer av associationer och därmed ha olika strategier vidimplementationen.


Associationer mellan objekt . . .

Associationerna kan vara tvingande eller inte och i det senare falletkanske det inte finns någon mottagare för meddelandena.

Som nämnts kan det också finnas en mängd mottagare och då krävsen lagringsstruktur som kan vidarebefordra meddelandena.


Aggregat

Ibland är det nödvändigt att betrakta en relation mellan objekt inta barasom en association utan snarare som om det ena objektet vore en delav det andra objektet.

Sådana associationer representerar en ”består-av”-relation ochstämmer väl med ett aggregationskoncept.

Följdaktligen kallas associationer med denna speciella semantik förjust aggregat och används för att bygga sammansatta objekt avgodtycklig komplexitet.


Aggregat . . .

Eftersom komplexa objekt inte kan existera utan att deras delarexisterar betyder användandet av aggregat-notation också att manbestämt sig för att det måste finnas ett refererat objekt och attreferensen i det resulterande programmet inte får ha värdet null.

Association Aggregat


Klasser

Citat (om klasser):

• En klass är en definition av en implementation av metoder och datastrukturer somdelas av en grupp objekt [21, 19].

• En klass är en mall från vilken man kan skapa objekt. Mallen innehållerdefinitionen av inre tillstånd och metoder för objekten [4].

• En klass är den kod som definierar instans variabler och metoder för någraobjekt. De objekt som stämmer med mallen kallas klassens instanser [23].

• En klass används för att beskriva beteendet hos en mängd objekt som har sammasemantik vid operation på samma attribut [24].


Klasser . . .

Citat (om typer):

• En typ är specifikationen av ett protokoll som delas av en mängd objekt kalladetypens instanser [21, 19].

• Typer är från programmerarens synpunkt en mekanism för att klassificera värdenutgående från deras egenskaper och beteende [2].

• Ur typkontrollssynpunkt är typer syntaktiska restriktioner på uttryck för attsäkerställa operationell kompatibilitet [2].

• En typ i ett objektorienterat system sammanfattar de gemensamma egenskapernahos en mängd objekt med samma karaktäristik [25].


Klasser . . .

En klass kan alltså betraktas som

• en mall för att skapa objekt (som i Simula),

• en instans av klassen metaklass

• mängden av alla objekt med identisk inre struktur och beteende


Metaklass

Citat:

• En metaklass är en klass vars instanser är klasser [17].

• En metaklass är en klass klass [4].

• Klassdeskriptorer har egenskaper som har sina egna klasser ochsom kallas metaklasser [26].


Metaklass . . .

Om allt ska vara objekt måste klasser också kunna vara det. Också omklasser måste kunna manipuleras under körning.

Lösningen kan vara att låta klasser vara objekt – instanser avmetaklass, en speciell klass som endast har till uppgift att genererainstanser av klasser och möjligen hantera variabler och metoder somantingen delas av alla objekt ur klassen eller hör till den typ somklassen representerar.


Metaklass . . .

Man kan särskilja fyra olika typer av OOP-språk:

• Alla objekt kan ses som klasser och alla klasser som objekt. Klass- ochmetaklassbegreppen existerar inte.

• Alla objekt är instanser av någon klass men klasser är inte åtkomliga iprogrammen utan existerar bara i programkoden.

• Alla objekt är instanser av metaklass och alla klasser är instanser av metaklass.Metaklass är en klass och därför en instans av sig själv. Så klasser är förstaklassens objekt och åtkomliga i programmen.

• Det finns en hel hierarki av metaklasser som en slags skuggbild av klasshierarkin.Varje metaklass har också en skugghierarki, men den är inte komplett. Vi får eninstansieringshierarki:objekt → klass → metaklass → metaklass metaklass → . . .


Subklassrelationen

Från varje klass kan subklasser härledas. Dessa kan berika klassensinre tillstånd och kan även lägga till och omdefiniera metoder.

Om C′ är subklass till C (C′ ≤C C), så kallas C superklass till C′.

Subklasser kan ha subklasser så subklassrelationen genererar enträdstruktur som kallas en klasshierarki . Varje subklass ärver deninterna strukturen och alla metoder från sin superklass.


Subklassrelationen . . .

Anställd

Person

Om C′ ≤C C och C ≤C C′ så är de samma klass ( C′=CC). Om klasserinte är relaterade till varandra skriver vi C 6=C C′.

Om C′ ≤C C håller men inte C′=CC kallas C′ strikt subklass(C′ <C C).



Vissa system tillåter multipelt arv , där en klass kan ha mer än ensuperklass. I det fallet genererar subklassrelationen en generell grafoch man kan få problem med namnkollisioner.

D

C

A

m1

m1

m1m1

B



Det finns ingen generell lösning utan varje språk med multipelt arv harsin egen:

• Använd ordningen som superklasserna räknats upp i som enprecedensordning och låt den definition som kommer först gälla.

• Överlagra en precedensordning på klasshierarkin och låt den (inågon mening) senaste omdefinieringen gälla.

• Låt användaren välja.

• Låt konflikterande namn ärvas men tvinga fram en explicit”omdöpning” av ett av eller båda namnen.



Vissa system tillåter partiellt arv genom att man kan hindra arvet av enmetod eller ett attribut [3].


Objekts typ . . .

En datatyp kan ses som en mängd värden och en mängd operationersom kan appliceras på värdena. Så en klass kan användas för attimplementera en typ.

Eftersom en klass alltså kan representera en typ kommer varje objektsinterna tillstånd att representera ett värde ur motsvarande domän.

Mängden av synliga metoder utgör mängden av operationer på typen.Man får således en typhierarki som exakt överlagras på klasstrukturen,med typer och subtyper och kan direkt applicera ideerna frånλ-kalkylföreläsningen på den genererade typhierarkin.


Polymorfi

Citat:

• I polymorfa språk har vissa värden (och/eller variabler) mer än entyp [1].

• En funktion är polymorf om den kan appliceras på argument av merän en typ [27].

Många hävdar att OOP ska lösa mjukvarukrisen.

Om det ska kunna gå måste man kunna göra polymorfa moduler.

Polymorfi finns i många former i alla objektorienterade språk.


Abstrakta klasser

En abstrakt klass är en klass som utformats för att tillhandahålla engemensam rot till en mängd klasshierarkier. Den är inte avsedd förinstansiering. I vissa språk, där man har implemeterat abstraktaklasser kan dessa inte instansieras [8]Exempel 1. 1.

const var +

expression

oporopand

− * /


Parameteriserade klasser

En parametriserad klass accepterar klasser som parametrar ochinstanserna är i sig klasser, i analogi med typparametriseradefunktioner.


Virtuella metoder

En metod kallas virtuell om dess innehåll kan omdefinieras isubklasser. Då måste språkets run-timesystem tillhandahålla någonmekanism för dynamiskt val av metod, baserat på typen på anropet.Alla OOP-språk tillhandahåller virtuella metoder. I vissa måste mansäga till att en metod ska vara virtuell, i andra är det default.


Abstrakta metoder

En abstrakt metod används för typkontroll. I vissa språk får den inte haen metodkropp. I Java är det så och dessutom måste en klass sominnehåller åtminstone en abstrakt metod själv vara en abstrakt klass.

Utan abstrakta metoder måste man antingen tillhandahålla”dummy”-metoder som platshållare för typkontrollen eller måste manutföra typkonverteringar för att nå metoderna.


Objektorienterad databasutveckling

• Vanliga termer

• OODB-scheman via ODL

• UML −→ ODL


Objektorienterad databasutveckling. . .

Jag håller mig här till den objektmodell som föreslagits av ODMG(Object Database Management Group).

Därför används också den av ODMG föreslagna standarden fördefinition av objekdatabasscheman, ODL (Object Definition Language)samt det förslag till frågespråk, OQL (Object Query Language) somODMG lagt fram.


ODL

Precis så som SQL-DDL-scheman kan flyttas mellan RDBMS somimplementerar SQL-standarden så kan scheman definierade i ODLflyttas mellan ODBMS som anslutit sig till ODMG-standarden.


Att definiera en klassStudentnamnfödelseDatumadresstel

ålder()medelbetyg()registrera(k,i,t)

följer

följs_av* *

Kurstillfälletermininstitution

studenter(){ordnad} ger* tillhör 1

Kursnamnkodpoäng

studenter()

förkunsk.för

förkunsk.krav

*

*

Bilden visar ett UML-diagram över en del av en databas för ettuniversitet. Låt oss se närmare på klasserna ”Student” och ”Kurs” ochäven på deras attribut.

I ODL skulle man få (till att börja med. . . ) (jag använder VERSALER förreserverade ord — det ska det inte vara).


Att definiera en klass . . .

CLASS Student {ATTRIBUTE STRING nameATTRIBUTE DATE dateOfBirthATTRIBUTE STRING addressATTRIBUTE STRING phone// plus samband och operationer

}

CLASS Course {ATTRIBUTE STRING nameATTRIBUTE STRING codeATTRIBUTE SHORT credit// plus samband och operationer

}


Defintion av attribut

Ett attributs värde är antingen en literal eller en objektidentifierare .

Literaler är egentligen textuella representationer av värden, men härhar man en lite annorlunda ide. Allt som inte är objektidentifierarekallas literaler. Man skiljer dessutom på olika literaler — egentligen tvåhuvudgrupper:

• Atomiska literaler som är konstanter som inte kan delas uppkomponenter.

• Samlingsliteraler som är någon sorts samlingar av literaler


Defintion av attribut . . .

◆ Mängd (set): en oordnad samling av element där det inte kan finnasdubletter.

◆ Bag (bag): en oordnad samling av element där dubletter kanförekomma.

◆ Lista (list): en ordnad samling av element (där dubletter kanförekomma).

◆ Array (array): en (till storleken) dynamisk ordnad samling av elementdär elementen lokaliseras efter position.

◆ Strukturerad literal (structure): ett fast antal namngivna element, därvart och ett kan vara antingen literaltyp eller objekttyp.


Defintion av attribut . . .

Objektmodellen som ODMG-konsortiet stöder identifierar defördefinierade strukturerna (strukturerade literalerna) DATE, INTERVAL,TIME och TIMESTAMP.

Dessutom kan man deklarera egna strukturerade literaler (exempelkommer).

I ODL-schemat på bild 45 är båda name-attributen, adress -, phone - ochcode -attributen alla av strängtyp.

Sådana kan lagra en sekvens av alfanumeriska tecken omgivna avcitationstecken.

Attributet dateOfBirth är av den strukturerade literaltypen datum ochcredit kan ta ett heltal mindre än 2 16.


Användardefinierade strukturer

STRUCT Address {STRING streetAddressSHORT streetNumberSHORT zipCodeSTRING zipArea

}

STRUCT Phone {SHORT areaCodeLONG localNumber

}


Operationer

CLASS Student {ATTRIBUTE STRING nameATTRIBUTE Date dateOfBirthATTRIBUTE Address address // nya defATTRIBUTE Phone phone // nya defSHORT age() // selektor (query)FLOAT averageMerit() // selektor (query)// mutator (update)BOOLEAN register_for(STRING course,

STRING department,STRING semester)

}


Uppräkningar

Man kan också definiera attribut som uppräknade typer (kommersenare).

ATTRIBUTE ENUM x {0, 1, 2, 3, 4, 5, 6, 7, 8}


SambandLägg till sambanden som noterats i bild 44.

CLASS Student {ATTRIBUTE STRING nameATTRIBUTE Date dateOfBirthATTRIBUTE Address addressATTRIBUTE Phone phone// Många-till-många-sambandet ’följer’RELATIONSHIP SET<CourseOccation> takes

INVERSE CourseOccasion::taken_bySHORT age()FLOAT averageMerit()BOOLEAN register_for(STRING course,

STRING department,STRING term)

}


Samband . . .

ODMGs objektmodell kräver att samband specificeras i bådariktningarna.INVERSEanvänds för att binda två operationer till varandra.I ”många-till-någonting”-samband måste lagringsstruktur specificeras.

CLASS CourseOccasion {ATTRIBUTE STRING semesterATTRIBUTE STRING department// Många-till-många-sambandet ’följs_av’RELATIONSHIP SET<Student> taken_by INVERSE Student::takes// Många-till-ett-sambandet ’tillhör’RELATIONSHIP Course belongs_to INVERSE Course::offersSHORT students()

}


Samband . . .

ODBMS skulle automatiskt säkerställa referensintegritet för allasamband som specificeras i ett ODL-schema 1.

Om man t ex tar bort en student kommer ODBMS se till att allareferenser till och från det objektet tas bort i hela databasen.

Om man kopplar en student (ett Studentobjekt) till en mängdkurstillfällen kommer ODBMS att skapa alla inversa referenser.

1Bertino och Martino 1993 samt Catell och Barry 1996


Samband . . .

CLASS Course {ATTRIBUTE STRING nameATTRIBUTE STRING codeATTRIBUTE SHORT creditsRELATIONSHIP LIST<CourseOccasion> offersINVERSE CourseOccasion::belongs_toRELATIONSHIP SET<Course> has_prereqs INVERSE Course::prereq_forRELATIONSHIP SET<Course> prereq_for INVERSE Course::has_prereqsSHORT students()

}

Slutligen måste man definiera vilka namn man har på lagringsplatsen(motsvarigheten till basrelationen i en relationsdatabas). Detta kallasklassens ” extent ” dvs mängden av alla för ögonblicket existerandeinstanser av en klass. Det kompletta databasschemat blir då (till slut)


Slutligt schema . . .

CLASS Student {( EXTENT students)

ATTRIBUTE STRING nameATTRIBUTE Date dateOfBirthATTRIBUTE Address addressATTRIBUTE Phone phoneRELATIONSHIP SET<CourseOccation> takes

INVERSE CourseOccasion::taken_bySHORT age()FLOAT averageMerit()BOOLEAN register_for(STRING course,

STRING department,STRING term)

}



CLASS CourseOccasion {( EXTENT courseoccasions)

ATTRIBUTE STRING semesterATTRIBUTE STRING departmentRELATIONSHIP SET<Student> taken_by

INVERSE Student::takesRELATIONSHIP Course belongs_to

INVERSE Course::offersSHORT students()

}



CLASS Course {( EXTENT courses)

ATTRIBUTE STRING nameATTRIBUTE STRING codeATTRIBUTE SHORT creditsRELATIONSHIP LIST<CourseOccasion> offers

INVERSE CourseOccasion::belongs_toRELATIONSHIP SET<Course> has_prereqs

INVERSE Course::prereq_forRELATIONSHIP SET<Course> prereq_for

INVERSE Course::has_prereqsSHORT students()

}


Objektid som attributvärde

Inget attribut har hittills varit av objekttyp. Antag att vi har definitionen

CLASS Department {( EXTENT departments)

ATTRIBUTE STRING nameATTRIBUTE Address addressATTRIBUTE SHORT floorATTRIBUTE Phone phone

}

Då skulle vi kunna ändra CourseOccasion till


Objektid som attributvärde . . .

CLASS CourseOccasion {( EXTENT courseoccasions)

ATTRIBUTE STRING semesterATTRIBUTE Department departmentRELATIONSHIP SET<Student> taken_by

INVERSE Student::takesRELATIONSHIP Course belongs_to

INVERSE Course::offersSHORT students()

}


Många-till-många samband, nycklar, mängdvärda attribut

(UML-diagram)

ProjUppdrstartDatumslutDatum

uppdrag(a, p)

timmar

ProjektProjIdnamnprioritet

Anställdpnr

anstDatumfärdigheter

namnadresslön

anställ()avskeda()adderaFärdighet(f)

manTimmar()

startDatumslutDatumfärdighetskrav

* *


(OMT-diagram)


manTimmar()


Anställdpnr


namnadresslön


ProjUppdrstartDatumslutDatum

uppdrag(a, p)

timmar


Många-till-många samband, nycklar, mängdvärda attribut . . .

I figuren på bild 61(62) finns ett många-till-många-samband mellananställd och projekt. För att någon anställd skall jobba på ett projektkrävs att det finns dels ett ”anställd”-objekt, dels ett ”projekt”-objekt.Alltså har man modellerat det hela med en associationsklass sominnehåller de specifika ”projektanställnings”-egenskaperna.Situationen är mycket vanlig i både UML- och OMT-modeller. Det ärsvårt att överföra detta till en rimlig implementation oavsett språk och ide flesta fall så är det bättre att tänka sig modellen enligt den på bild64.



har*

ProjUppdrstartDatumslutDatum * 1


Anställdpnr


namnadresslön


1 arb_på

uppdr_åt

uppdrag(a, p)

timmar

för

manTimmar()




Detta kan (enkelt?) överföras till följande databasschema:

CLASS Employee {( EXTENT employees KEY pnr)

ATTRIBUTE STRING pnrATTRIBUTE STRING nameATTRIBUTE Address addressATTRIBUTE LONG salaryATTRIBUTE Date dateHiredATTRIBUTE SET<STRING> skillsRELATIONSHIP SET<Assignment> works_on

INVERSE Assignment::assigned_toVOID hire()VOID fire()VOID addSkill(STRING newSkill)

}



CLASS Assignment {( EXTENT assignments)

ATTRIBUTE Date startDateATTRIBUTE Date endDateATTRIBUTE SHORT hoursRELATIONSHIP Employee assigned_to INVERSE Employee::works_onRELATIONSHIP Project for INVERSE Project::hasVOID assign(STRING emp, STRING proj)

}



CLASS Project {( EXTENT projects

KEY projID)ATTRIBUTE STRING projIDATTRIBUTE STRING nameATTRIBUTE ENUM priority {low, normal, high}ATTRIBUTE Date beginDateATTRIBUTE Date endDateATTRIBUTE SET<STRING> skillsRequiredRELATIONSHIP SET<Assignment> has INVERSE Assignment::forLONG empHours()

}

Skulle någon klass ha komplex nyckel så fungerar det bra i ODL. Man kan ange ettantal nycklar om man skriver KEYSoch en uppräkning av de i nyckeln ingåendeattributen, t ex KEYS {name, address} .


Generalisering

Generalisering motsvarar kategorisering i de semantiska modellerna och finns i UML.Man kan generalisera ett antal begrepp till ett övergripande, t ex om man redan hardefinierat klasserna car , truck och lorry och vid modelleringen skapar dengeneraliserande klassen vehicle får man modellen


Generalisering . . .

Car

...

...

Truck

...

...

Lorry

...

...

Vehicle

...

...



Men man kan naturligtvis planera för en specialisering direkt.

... ... ...... ... ...

...

{disjoint]

Car Truck Lorry

...Vehicle



Båda måste implementeras på samma sätt:

CLASS Vehicle {( EXTENT vehicles

KEY vehicleID)ATTRIBUTE ...

}CLASS Car EXTENDS Vehicle {( EXTENT cars ...}CLASS Truck EXTENDS Vehicle {( EXTENT trucks ...}CLASS Lorry EXTENDS Vehicle {( EXTENT lorries ...}


Abstrakta klasser

Det är inte troligt att man har anledning att instansiera klassen Vehicle .

{disjoint]

Car Truck Lorry

Vehicle......

{abstractt}

... ... ...... ... ...


Abstrakta klasser . . .

Men det blir samma implementation i ODL eftersom ODL inte har någon syntax (ellersemantik) för att förhindra att en klass instansieras. Det är ju också så attsuperklassen måste instansieras i databasen. Avsikten är att man inte skainstansiera Vehicle annat än via subklasserna.


Instansiering

En kurs enligt bild 44 kan skapas med t ex2D1470 course{} .

Då får attributen standardvärden, vilket kanske inte är så bra

2D1470 course {name "Objektorienterade databassystem",code "2D1470",credit 5}


Objektorienterade databassystem

Det man vill uppnå (enligt definitionen på den här kursen) är system som har allaegenskaper hos objektorienterade system och alla egenskaper hos (traditionella)databashanteringssystem.

Objektorienterade databassystem har utvecklats ur fyra världar:

• Komplex-värde-modell (nästlad relationsmodell),

• semantisk modell,

• typteori och

• objektorienterad programmering.


Objektorienterade databassystem . . .

Vi ska titta på några system. Vissa av dem kanske inte längre är aktuella (men ändåintressanta). Det finns ingen standard, ingen koncensus om vad man menar medobjektorienterad modell.

Man kan fokusera på vissa egenskaper hos systemen. Viktiga aspekter är

• objekt och objektidentifierare

• komplexa värden och typer

• klasser

• metoder

• IS-A-hierarkier (arv)

• dynamisk bindning

• inkapsling


GemStone

Direkt utvidgning av Smalltalk.

Tillägg för att göra Smalltalk till en komplett OODBMS.

Applikationsprogram kan skrivas i OPAL (utvidgningen av Smalltalk), C, C++, Javaoch Pascal.

Systemet består av Smalltalk-arbetsstationer (PC, Mac, Tektronix, ...) och enserver-applikation på Vax under VMS eller på någon Unixmaskin.


GemStone . . .

Arbetsstationsom kan köra

Smalltalk


Smalltalk


Smalltalk

...

Gemstoneserver Databas Databas


GemStone . . .

GemStone bygger helt på Smalltalkmodellen, med klasser, metaklasser, objekt,meddelanden. Klasser organiseras i hierarkier med enkelt arv. OPAL används somDDL/DML, programmeringsspråk och kommandospråk. Det finns enprogrammeringsomgivning, OPE (OPAL Programming Environment).


(GemStone) OPE innehåller . . .

• en klass-browser, i vilken man på vanligt Smalltalkmanér kan lägga till, inspekteraoch modifiera GemStone-klasser,

• en filhanteringsmodul (Bulk Loader/Dumper) som överför poster i filer, med fixlängd, till objekt i GemStone-servern och

• en editor (Workspace editor) i vilken man kan skriva OPAL-program och köra dem.

Man tillåter koppling till C och Pascal, vilket medför att man måste tillhandahålla ettgränssnitt, PIM (Procedural interface Modules), så att programmen kan kopplas tillGemStone via s k ”remote procedure calls”.


GemStone . . .

Nätverk

Arbetsstation

Nätverksprogramvara

Workspace editor

Loader/Dumper

Class browser

PIM

C/Pascal

Applikationsprogram

Fönsterhanteringsprogram


Servern består av två delar:

• Gem-processer, som implementerarden virtuella maskinen (standardSmalltalk) och objektminnet.Gem kompilerar och kör metoderskrivna i OPAL samt hanterarautentisering och sessionskontroll

• Stone-process, som hanterarsekundärminne, samtidighetskontroll,accessrättigheter, transkationer ochåterhämtning samt arbetsareor för desessioner som pågår.

Nätverksprogramvara

Gemprocess Gemprocess . . .

Stoneprocess

Filsystem

Databas Databas


ORIONBygger på Common Lisp. Kom först som enanvändarsystem (1984), på en litenLispmaskin, men porterades snabbt till Unix, eftersom man var (nästan) först.Intressant: Multipelt arv, systemmetoder, som kan ärvas eller inte ärvas avobjektklasser (via mult arv) – t o m konflikterande metoder kan ärvas och döpas omför att lösa konflikten (ungefär som i Eiffel), ja t o m kan man se till att ärva metoderfrån systemet som ser till att implementera en konfliktlösningsstrategi.

I Orion finns implementerat idéer som väl täcker ”svaga objekt”-begreppet i RDBMS –det kan ju finnas objekt som inte kan existera utan att ett värdobjekt finns. Schemanär dynamiska i Orion. Ett databasschema kan undergå en ”utveckling” under sinexistens och utan att omkompilering är nödvändig kan ett schema ändras avseende:

• lägga till, ta bort, uppdatera attribut och metoder i objekt• lägga till, ta bort, uppdatera id för objekt• lägga till, ta bort, uppdatera arvskedjor, sammansättning (komplexa objekt) och

associativa relationer (matchning m a p innehåll)


Transaktionshanterare!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Meddelandehanterareaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Filhanterare

Objekthanterare

• Meddelandehanteraren hanterar alla meddelanden som skickas tillOrion-systemet. De är till för att hantera meddelanden till användardefinieradeobjekt och direkt till systemmetoder, samt sökning och modifiering av objekt ochattribut. Systemmetoderna implementerar DDL, DML och transaktionshantering.

• Objekthanteraren sköter schemamodifikation, frågeoptimering, versionskontrolloch multimediainformationshantering

• Filhanteraren tar hand om lagring, allokering och avallokering av sidor i minnet,


håller reda på var på sidorna objekten ligger, kopiering till/från sekundärminnetoch indexhantering.

• Transaktionshanteraren sköter allt som har med transaktioner att göra, inklusivesamtidighetskontroll och återhämtning efter krasch.

Sista versionen av Orion är en distribuerad månganvändarversion.

Intressant är att databasen är delad i en publik och, för varje användare, en privat del.

Man kan ”logga ut” data från den publika DBn och logga in den på sin egen DB.


IRIS

ObjectSQL Editor

GraphicsapplLisp

applC

@@

@@

AAAA

��

��

��

��

IRIS object manager (kernel)

IRIS storage manager

Databas Databas

• kärnan hanterar typer, objekt,operationer, accessrättigheter,optimering och versionshantering

• filhanteraren hanterarsamtidighetsproblem, återhämtning,indexering, databuffertar, clustering

IRIS är inte objektorienterat, så funktioner”hör inte ihop” med sina data, som iklassbaserade system, men man har arvså funktionerna ärvs (är m a o polymorfa!).


IRIS använder ”Object SQL”, ett SQL-liknande frågespråk. Man kan användaobjektidentifierare, användardefinierade funktioner och IRIS systemfunktioner iFROM- och WHERE-klausuler. Intressant:

• Schemarepresentation : Schemata är data, och kan alltså undersökas ochanvändas i program

• Multipla typer : Ett objekt kan ha flera typer – man kan lägga till och ta bortassociationer mellan data och typer.

• Clustering : Endast mellan objekt och dess metoder (betyder att objekt av en typhamnar nära varandra för att vara nära sina metoder).

• Versionshantering : Enkel och manuell. Man specar i sitt program att objekt kan haversioner och man skapar själv nya versioner. Man kan låsa sitt program till vissaversioner av vissa objekt.

IRIS har en funktionell (i o f s behaglig) notation och klassas väl egentligen somfunktionellt.


VBase

Lagringsnivå

Representationsnivå

Abstraktionsnivå

Språknivå

Gammalt system, C med egenobjektorientering ovanpå (före C++ förstaversion).Systemet är byggt som en skiktad strukturungefär som traditionelladatabashanterare.Klasser finns inte i vanlig mening, utanman har fokuserat på begreppet ADT(??).Det finns multipelt arv.


Systemet är delat i två distinkta moduler:

• TDL (Type Definition Language), som hanterar scheman. TDL är ettblockorienterat språk, med i huvudsak statisk typning. Viss typkontroll skjuts upptills under körning.

• COP (C Object Processor) är ett strikt superset till C och används dels för attskriva koden till de operationer som hittas i scheman, dels för att skrivaapplikationsprogram och allt som kan kompileras i C kan kompileras i COP.

Undantagshantering finns (Exceptions). Undantag är typade så man kan definierahierarkier av undantag också. Det finns dessutom ett antal verktyg för att hanteradebugging, grafisk interaktiv editering av objekt, och för att kontrollera den fysiskastrukturen på sekundärminnet.

Clustering finns, man kan definiera inverser till metoder (om metoden uppdaterassker det med inversen också!).

Man kan definiera om vissa systemoperationer lokalt och därmed uppnå


specialiserat uppträdande för vissa objekt, t ex läsa och skriva bildobjekt meddekomprimering och komprimering.


ONTOS

Ontos är efterföljaren till VBase och man har behållit mycket, t ex arktiekturen. Manhar gått över till C++ och härlder persistenta objekt från en persistent rotklass, Entity.Alla objekt som är instanser av någon subklass till Entity kommer att sparas dåprogrammet terminerar.

Utöver vanliga anrop av metoder finns metoder för anrop av textuellt angivnametoder.

Objekt i databasen är passiva (deactivated) och vid anro av metoder i ett objekt”aktiveras” det genom kopiering till programmets runtimeminne.

Man ersätter då pekaren (till persistent objekt och tillbaka in iapplikationsprogrmmet) med en lokal pekare (Swizzling).

Vidare finns ett transaktionsbegrepp likt det i vanliga DBMS.

Utöver all funktionalitet i VBase har man BLOBs.


Riktigt stora datastrukturer bryts ned i mindre objekt och man håller reda på delarnamed b-träds-index.

Det finns ett SQL-liknande frågespråk, men dessvärre görs alla attribut (även gömda)tillgängliga för användaren (men det är vanligt i ODBS).


ObjectStore

ObjectStore är ett C++-system med persistens, lite som ODE, men det ärkommersiellt helt ut. Testa

http://www.informatik.th-darmstadt.de/OS_UG/mirror/prodinfo/onweb/overview.html

där ni kan få senaste nytt om utvecklingen.

Systemet består av en mängd olika hanterare som samarbetar.

Det finns hanterare för bilder, för objekt, för text o s v.

Ingen speciell rotklass för persistenta objekt, utan persistens är något speciellt förvarje objekt, som i ODE, men man har ingen speciell pnew utan new tar ett extra(optional) argument där man anger vilken databas objektet skall hamna i.

Det finns ett speciellt DML och man stödjer objekt-till-objekt-pekare (32-bitsadresser) i persistent minne.


Man håller en cache med aktiva objekt i programminnet. Det finnstransaktionshantering och man gör swizzling med direktkopiering in i programminnetoch hoppar över den i många DBMS-sammanhang så viktiga bufferten för accessadedataobjekt (återkommer om detta).

Långa transaktioner stöds genom versionshantering och samtidighetskontrollen ärper objekt. Ett trevligt system.

Det finns ett antal databashanteringssystem i omlopp:


ADB Matisse Software http://www.matisse.comAllegroStore Franz http://www.franz.comJasmine Computer Associates http://www.cai.com/products/jasmineJasmine Fujitsu Software http://www.fsc.fujitsu.comGBase Object Databases Common LispGemStone/S Gemstone Systems http://www.gemstone.comItasca Object Systems http://www.iprolink.ch/ibex.comMCC Orion (Kim, m fl 1988) Common Lisp – föreg till ItascaneqAccess neoLogics http://neologic.comO2 O2 Technology http://www.o2tech.comObjectStore Object Design http://www.odi.comObjectivity/DB Objectivity http://www.objectivity.comODE AT&T http://www.att.comOntos Ontos Integrator http://www.ontos.comOsmos Unisys http://www.osmos.comPersistence Persistence http://www.persistence.comPoet poet Software http://www.poet.comVersant Versant ODBMS http://www.versant.com


De flesta bygger på C++ eller på någon utökning av C++

Ett par bygger på LISP-utökningar.

Ett par riktigt tidiga är snarast utbyggnader av relationssystem.

VBase (Ontologics 1986) och Vision (Innovative Systems 1988) bygger på enobjektorienterad modell men har ett eget språk för objektorienteringen.

Några är direkta utbygnader av relationssystemen, t ex Stonebrakers Postgres, somär Ingres med abstrakta datatyper och annan godis. Postgres har utvecklats vidareoch såldes till Informix under namnet Illustra. Universal Server bygger på dessa idéer.


Man behöver nya metoder för modellering.

Man behöver nya standarder (OMG är ett försök)

Man behöver nya frågespråk

Man behöver fundera en del över temporala och spatiala problem

Man behöver lösa metadefinitionskonflikter (man struntar i dem fn)


Frågespråk

Frågespråk är viktiga, eftersom användaren tillåts att, på enkelt (??) sätt – genom attspecificera egenskaperna hos svaret och var sökning skall ske – kan leta i databaser.Frågespråk skall vara

• högnivåspråk – så att man lätt kan formulera komplexa operationer

• deklarativa – man specar vad man söker inte hur man skall finna det

• effektiva – det måste finnas utrymme för optimering

• programoberoende – det skall vara lika för alla databaser och applikationsprogram

Fördelen om man uppnår dessa egenskaper är att man förenklarapplikationsutvecklingen och tillåter ovana anvädare att ställa frågor ”ad hoc”.


Fullständighet

Beräkningsmässig fullständighet kräver man av generella programmeringsspråk,medan man i databassammanhang nöjer sig med relationell fullständighet(åtkomstfullständighet) och menar att man skall kunna hitta och manipulera varjevärde i databasen.

Man gör stort nummer av att man lyckas utföra några skäligen enkla aggregeringaröver relationer, men tonar ner det faktum att dessa har begränsad användning.

De flesta DBMS idag har därför tillhandahållit möjligheter att länka in operationer,definierade i andra språk, för att råda bot på detta. Utöver beräkningsmässigfullständighet och åtkomstfullständighet måste man kräva resursfullständighet, d v smöjlighet att nå och utnyttja alla systemets resurser inifrån språket (t ex spela uppvideo eller koppla upp en ”remote access”-länk).


Impedans mismatch

Mycket har skrivits om detta och om att objektsystemen skall råda bot på problemet,men har man nått dit? Uppenbarligen inte. Man måste kunna skriva ”ad hoc”-frågoroch tillåta folk att uttrycka sig ”klumpigt” men ändå snabbt få svar, man måste skrivaeffektiva applikationsprogram. Skriva bra frågespråk för OODBMS är inte lätt.

• Det finns en konflikt mellan frågespråk och objektorienterad abstraktion(inkapsling),

• Det finns inte någon standard på objektorienteringsområdet

• Man hanterar godtyckligt komplexa värden.

Allt bottnar i objektorienteringens brist på hållbara matematiska teorier. Man harförsökt med funktionella frågespråk, men inget har – hittills – vunnit terräng. Det harvisat sig inte vara så lätt som vissa forskare trott.


Egenskaper hos objektorienterade frågespråk

På grund av metoden att överlagra en extra referensstruktur på objekten i enobjektorienterad databas (alla använder metoden), finns två sätt att röra sig idatabasen.

• Vi kan nå ett objekt via dess ID (referens) och sedan navigera genom alla objektsom refereras från det funna objektet.

• Vi kan använda SQL-liknande språk för att kunna hitta objekt baserat på derasegenskaper.


Egenskaper hos objektorienterade frågespråk . . .

Man kan låta de två metoderna komplettera varandra. Traditionella frågespråk är braför att hitta mängder av objekt med liknande egenskaper och, när man väl fått enmängd referenser till objekt, kan man låta applikationsprogrammen navigera genomden graf (de grafer) som spänns upp av alla referenser i de funna objekten.

Man måste också vara på det klara med vad man menar med likhet i olika situationer.• Likhet i refererat värde,• likhet i referens (pekar på samma objekt),• likhet i attributvärden – vad det nu kan komma att betyda.

Det är väsentlig skillnad i semantiken beroende på vad man menar. Därför har man iOODML ofta ett stort antal jämförelsekriterier.


Aggregationshierarkier

Eftersom man med attribut i form av referenser till andra objekt spänner upp trädeller grafer, och eftersom man inkluderar objekten i databasen genom aggregation,kommer man att behöva utökningar av frågespråken för att kunna hitta i dessahierarkier.

Dels behöver man variabler som kan hantera objekt,dels behöver man kunna hitta med avseende på objekt-ID,dels behöver man kunna följa pekare.


Join

I objektorienterade databaser gör man skillnad på implicit join, som härleds ur denhierarkiska strukturen (jämförelse av två objekt vars attribut refererar samma objekt, tex), och explicit join (som i RDBMS) där man jämför två objekt genom objekt-ID ellergenom värden på vissa attribut.

Strukturer liknande dem i nästlade relationsdatabaser (listor av referenser till objekt,t ex) kräver ”nästlade” predikat. De nästlade attributen brukar utgöras av ”långa”referenser eller sökuttryck (path expression).

Annorlunda klassifikation än implict resp explicit join: i s.k. enoperandsfrågorbetraktar man en mängd objekt av samma klass (inkl subklasser) medanfleroperandsfrågor representerar frågor motsvarar ”vanlig” join.


Join . . .

Sökvägsuttryck har en komplicerad semantik trots sin skenbara enkelhet. Vi är vanavid dem från OOP.

for each employee in{emp.manager().department().employees()}...

Obs, att sökvägsuttryck inte ökar uttrycksfullheten i systemet, utan endast är avpraktisk betydelse. Man har ju alternativa möjligheter att söka i databasen. Däremotkan man anse att de ökar språkets konceptuella precision, d v s att man har lättareatt förstå frågor skrivna med sökvägsuttryck.


Instanshierarkier

Arvshierarkier utgör en annan möjlighet att utforska databaser. Oftast kan man viljaundersöka alla objekt ur en klass eller ur en klass och alla dess subklasser.

I de flesta systemen idag är det möjligt, t ex i ORION och ODE.

Eftersom ett objekt ur en subjklass kan ha sina egna attribut utöver de ärvda kan detvara nödvändigt att kunna utforma predikat i stil med

CASE x.class OFclass-1: predikat-1class-2: predikat-2...class-n: predikat-n


Instanshierarkier . . .

där jag antar att alla objekt har en metod class som returnerar objektetsklasstillhörighet. Alternativa predikat kan också användas för att ställa frågoravseende gemensamma attribut i instanshierarkin.

”Hitta alla dokument som, om de är rapporter, handlar om objektdatabaser och, omde är tidningsartiklar, har publicerats i någon datatidning under kategorinobjektdatabaser.”


Rekursiva frågor

Rekursiva frågor, som inte handlar om det transitiva höljet för ett objekt, utan harmed rekursion i vanlig mening att göra blir viktiga eftersom rekursion är ett naturligtinslag i objektorienterade språk ( men inte en del av OO-modellen ).


Cykler i klasshierarkier

Man kan ju inte få cykler i beskrivningen i (nästlade) relationsdatabaser, men iobjektorienterade språk kan man få cykler i metadefinitioner (t ex Smalltalksmetaklass-begrepp) och i aggregeringar över klasshierarkin (objekt refererar objektsom . . . )

Man klassar cykler enligt följande: Antag två klasser C i och C j. En klasshierarki därCi och C j ingår är cyklisk om

• Cj är (indirekt) domän för ett attribut i C i och C i är domän för ett attribut i C j

• Cj är (indirekt) domän för ett attribut i C i och någon super- eller subklass till C i ärdomän för ett attribut i C j


Cykler i klasshierarkier . . .

Man får fyra möjliga typer av cykler. Om heldragen pil betecknar superklass ochstreckad betecknar referens kan de se ut så


Cykler i klasshierarkier . . .

Man måste ta hänsyn till att dessa situationer kan uppkomma när man designarfrågespråk. Det händer ofta att man råkar i bryderi, eftersom det man kallarklasshierarki och aggregations-hierarki ofta bildar grafer snarare än hierarkier. I fleraspråk kan man dessutom ge rekursiva definitioner av klasser (Iris, Orion, O 2).


Metoder

Metoder kan, i frågor, betraktas som härledda attributvärden eller som predikat.

Medan attribut endast representerar värden kan ett metodanrop innebära att metoderanropas i andra objekt, med bieffekter som resultat, eller med resultatet att mängderav objekt deltar i beräkningen.

Kanske uppstår mängder av objekt som överlever endast under själva beräkningen.


Resultat av frågor

I relationsdatabaser är resultatet av en fråga alltid en relation. Det fungerar alltid tackvare att relationsbegreppet är så generellt och flexibelt. Därför kan frågor ävennästlas, så att resultatet av en fråga blir operand i en annan fråga.

Det kan bli kostsamt att ha samma idéer i OO-frågespråk. Det kan betyda att manskapar objekt av klasser som inte existerar, och därför måste vara anonyma. Olikatyper av restriktioner finns därför. Mest restriktivt är Orions frågespråk, medan ODEsCQL tillåter tillverkning av nya, anonyma, klasser (= minst restriktivt).

Anatag följande klasser (schema), för enkelhetens skull uttryckt i O++-liknandenotation.


Resultat av frågor . . .

persistent class salary {int hAmount;Date hFromDate;

public:void salary(int newsal, Date newDate);int amount() {return hAmount;}Date fromDate() {return hFromDate;};

};



persistent class person {PersonalCode hPnr;Name hName;persistent salary *hSal;persistent Department *hDepartment;

public:void person();PersonalCode pnr () {return hPnr;}Name name() {return hName};salary actualSalary() {return hSal;}

};



persistent class Department {public:

Department(Name cName, int cFloor) ...Name name() ...int floor() ...persistent Person *manager;persistent Person *employee[[DEPT_EMPS]];

};



I O++ skulle man skriva ut namn, ålder och lön på alla som tjänar över 20000 imånaden med:

for p in Personsuchthat (p->actualSalary() > 20000)by (p->pnr()) {

cout << "Namn: " << p->name();cout << "Ålder: " << Year(DateOfToday - p->pnr());cout << "Lön: " << p->actualSalary() << endl;

}


Orions frågespråk

enkel_fråga ::= ’select’ målklausul| ’select’ målklausul

’from’ domänklausul| ’select’ målklausul

’where’ kvalifikationsklausul| ’select’ målklausul

’from’ domänklausul’where’ kvalifikationsklausul

Målklausulen beskriver de attribut vars värden skall hämtas,domänklausulen anger en mängd objekt ochkvalifikationsklausulen definierar en mängd predikat som skall vara uppfyllda av deobjekt som hämtas från databasen.


Orions frågespråk . . .

Man arbetar med objektvariabler (ungefär som tupelvariabler i SQL).

Man kan inte skapa nya anonyma objekt, bara hämta objekt ur databasen.

Objektvariabeln refererar till objekt ur klassen i domänklausulen.

Sökvägsuttryck kan introduceras i frågorna.

I Orion skulle man hitta alla som tjänar över 20000 i månaden med:

select :p from Person :p where :p actualSalary > 20000

eller, om man ansåg att det inte kan bli fel:

select from Person where actualSalary > 20000



Det liknar SQL.

Man kan använda sökvägsuttryck, som i Orions notation blir en uppräkning av namn.

Man kan också använda universal- och existenskvantifikatorer.

T.ex. skriver man för att hitta avdelningar, där alla tjänar mer än chefen:

select :d from Department :dwhere each :d employee actualSalary >

:d manager actualSalary



Klassuttryck används för att komma åt instanshierarkier.

klassuttryck ::= (klassuttryck)| (klassuttryck union klassuttryck)| (klassuttryck difference klassuttryck)| klassnamn | klassnamn*

Klassnamn* betyder objekt ur en klass och alla dess subklasser. Om vi antar att detfinns ett okänt antal subklasser till Department så kan man hitta alla chefer genom

select Department* manager



Tänker man sig en klasserna class och sales enligt varuhusdatabasen, där sales harett attribut department och ett mängdvärt attribut items av typen class ×supplyvolume × salesvolume kan man göra join-frågor enligt t ex

select :d from department :d, sales :swhere :d name = :s department nameand each :s items salesvolume > 2500

slutligen har man faktiskt mängder också

fråga ::= (fråga) | fråga union fråga| fråga intersection fråga| fråga difference fråga| enkel_fråga


Frågespråken i Gemstone och O 2

I GemStone kan man endast fråga på objekt vars klass redan är definierad. I varjeklass finns en constraint-klausul. Den får inte vara tom om man skall kunna ställafrågor avseende klassen. Frågor sammanställs av speciella urvalskonstruktioner.

Person select: { p | p.actualSalary > 20000 }

ger alla som tjänar mer än 20000

Person detect: { p | p.actualSalary > 20000 }

ger den första man träffar på som tjänar mer än 20000


Frågespråken i Gemstone och O 2

Person reject: { p | p.actualSalary > 20000 }

ger alla som tjänar mindre än eller lika med 20000

Man kan ge sökvägsuttryck med upprepad punktnotation och sammansatta villkormed ’&’, men jag har inte hittat något sätt att göra disjunktiva frågor (men det gårsäkert).

I O2 har man en helt annan situation.

Frågor sammanställs genom arbete i ett antal grafiska browsers, som assisterar vidskrivandet (om de är struktureditorer vet jag inte). I CO 2 skulle man hitta alla somtjänar över 20000 i månaden med:

select p from p in Person where p.actualSalary > 20000


Frågespråken i Gemstone och O 2 . . .

Man kan filtrera objekt effektivt (men jag hittade inget bra exempel). I O 2 kan manskapa nya klasser genom DDL-delen av språket och dessutom kan frågor genereranya klasser, ge objekt, mängder av objekt, enstaka värden eller mängder av värdentillbaka.

O2 har blivit fullt kommersiellt i företaget O 2 Technology, med vd François Banchilon,systemets skapare.

Dessvärre verkar det som om företaget köpts upp och lagts ner, men det verkar(dessbättre) också som om de anställda har köpt loss delar av företaget och är påväg att rädda produkten O 2.


OSQL, frågespråket i IRIS

Vid design av OSQL (som inte liknar SQL) har man beslutat sig för ett antal mål.OSQL skall:

• baseras på ett enkelt, ortogonalt typsystem med en likaledes enkel, ortogonalobjektmodell

• vara beräkningsmässigt komplett och oberoende av något specifiktapplikationsprogrammeringsspråk

• tillåta deklarativ specifikation av frågor, som kan kompileras och optimeras

• vara utbyggbart (tillåta egendefinierade typer)

• inte ha någon skillnad mellan metadataobjekt och användardefinierade objekt

• tillåta separat definition av gränssnitt och implementation


OSQL . . .

Man talar inte om klasser utan om typer. En enkel bild av systemets element och hurde hänger ihop:

Deltar iBeteende hos

KlassificerarInstans av

SignaturTyperFunktioner

Objekt

Objekt är av tre kategorier:

Literaler: heltal, teckensträngar, binära objekt ...Aggregat: lista, tupel, mmSurrogat: objekt med OID, skapas och utplånas explicit


OSQL – Typer . . .

Typer används för klassifikation av objekt, grundat på deras egenskaper ochbeteende.

Det finns en subtypmekanism och stöd för multipelt arv.

Aggregattyper och aggregatobjekt kan konstrueras från andra genom ett antalaggregattyp- och aggregatobjektkonstruktorer i systemet.

Man kallar mängden av objekt, som är instanser av en viss typ, för typens utvidgning(extension).

Typer definierar också funktioners signatur.


OSQL – Funktioner . . .

Funktioner används för att modellera attribut hos objekt, relationer mellan objekt ochberäkningar (beteende) och just detta skiljer OSQLs modell från andra OO-modeller.

Inget annat system använder funktioner för att modellera både attribut och metoder.

Overloading finns (funktioner kan ha samma namn).

Men funktioner kan uppdatera databasen och en möjlig funktionsresultattyp är void.



Funktioner är av endast ett argument, men då komplexa typer finns så spelarrestriktionen ingen roll.

Avsikten är att funktioner skall verka över någon domän i databasen.

En egenhet är att funktioner kan anges mycket schematiskt:

create function upcase(Char lowcase) -> Char;

för att sedan ges värden i en diskret uppräknad domän – kallas för att uppdaterafunktionen:

upcase(’a’) := ’A’;upcase(’b’) := ’B’;upcase(’c’) := ’C’;upcase(’d’) := ’D’;...



Denna typ av funktion, med en atomär domän, förorsakar att systemet skapar enextra ”skuggfunktion”, som kan uppdateras enligt ovan.

Funktioner har också utvidgningar, nämligen argumentens avbildning påresultatvärdena. Sådana utvidgningar kan anges som en beräkning, eller som enuppräkning enligt ovan, och båda kan lagras i databasen.


OSQL – Typsystemet . . .

Många funktioner, objekt och typer är fördefinierade i OSQL. Supertypen för allatyper är Object.

Bland de fördefinierade finns bla annat:TypeRef typ vars utvidgning är alla typerSurrogate supertyp till alla typer med OIDUsersurrogate supertyp till alla användardefinierade typerType typ vars utvidgning är mängden av alla surrogattyperTransient supertyp till alla transienta typer – alla typer vars instanser är

transienta (transaction, session, cursor, m.fl.)Aggregat supertyp till alla aggregattyper som t.ex. bagtype, settype,

listtype och tupletypeLiterala typer number, char, binary, date, time, ...Void subtyp till alla typer, extension = ∅


OSQL . . .

Det är tydligt att man har i åtanke att kunna implementera objektorienteradedatabashanterare. Systemet avses kunna jobba mot snart sagt varje värdspråk. DMLär ett imperativt språk. Ex:

create function filter(Function f, SetType(Object) arg) -> SetType(Object)as osql begin

declare SetType(Object) r;declare Object e;for e in arg do

if (f(e)) then r := r + e; endif;return r;

end;


OSQL . . .

Frågespråket är baserat på domänkalkyl (naturligtvis) och syntaxen liknar mycketSQL.

Det finns ett transaktions-begrepp och man har OSQL-konstruktioner (funktioner)som används för att realisera constraints regler och triggers.


Objektrelationsdatabaser

Relationsdatabaser kom till för att täcka informationsbehovet hos storaorganisationer

• för redovisning till myndigheter

• för lönehantering

• för orderhantering

Verksamheter som ”enkelt” avbildades på en statisk relationsstruktur.


ObjektrelationsdatabaserDatalogin mutar hela tiden in nya problemområden. Problem som kräver databaseroch vars strukturer är så komplexa (ibland av okänd komplexitet) attrelationsdatabaser inte duger. Eller finns krav på att hantera händelseförlopp(versioner).

Man skapade objektdatabaser. Relationen, som legat till grund fördatabasrevolutionen, reducerades till en av många typer. Men . . .

• mycket kunskap finns i relationstänkandet

• många problem löses fortfarande enklast med relationssystem

• vi vet ingenting om morgondagen problem


ObjektrelationsdatabaserEfter 15 års karantän hade forskningsgrupperna inte kommit överens. Man hadeingen konsensus om hur

• man representerar objekt.

• man lagrar objekt.

• man skickar eller tar emot meddelanden.

• objektens kod skall exekveras

Industrin tröttnade. Man ville också bevara och utnyttja den redan vunna kunskapenom relationssystemen.


ObjektrelationsdatabaserRelationssystemen hade sina fördelar.

• Enkel matematik

• Enkel grundläggande datatyp (relationen)

• Effektiv indexering

• Optimering


ObjektrelationsdatabaserDärför har det utvecklats ett intresse för att använda relationssystem även förkomplexa data.

Komplexa data förekommer i en mängd av olika tillämpningar där man tidigareskaffat sig en väsentlig erfarenhet av RDBMS

• multimediaapplikationer för www

• medicinska system (EKG, röntgenbilder, MRI (magnetic ray imaging)

• geografiska system (och andra spatiala system – hantering av seismiska data,satellitbilder, . . . )

• ekonomiska system (tidserier t.ex.)


ObjektrelationsdatabaserDessutom hade man gått från databashantering till att kunna starta ett program ochfortsätta där man slutade sist man körde programmet. Det behövdes fortfarandeDBMS som fungerade som man var van vid.

Det fanns redan ett forskningsprojekt som utmynnat i en ny modell. Projektet haderedan blivit kommersiellt.

Man vände på steken. Bevara relationen som grundläggande datastruktur ochutvidga istället typsystemet.

Det här krävde mer än tidigare kunnat levereras från DBMS-tillverkarna. Man hadesedan tidigare stored procedures .

Man måste utvidga även dessa möjligheter och göra det effektivare.


ORDBMS – arkitekturer, wrapperMan testade ett antal olika arkitekturer för ORDBMS

WRAPPER

KlientRDBMS


ORDBMS – arkitekturer, wrapper

• Bra användning av existerande system

• Snabbt implementerat

• Snabbt att uppgradera

• Performanceproblem med extra avbildning i wrappern

• Performanceproblem med transformation OO ↔Rel


ORDBMS – arkitekturer, merge via gateway

API

GATEWAYKlient

RDBMS

ODBMS


ORDBMS – arkitekturer, merge via gateway

• Bra stöd för existerande RDB

• Kan snabbt uppgradera från nuvarande system

• Komplicerat att uppgradera

• Kräver effektiva gateways

• Ger ändå performanceproblem


ORDBMS – arkitekturer, universell server

ORDBOR ServerKlient


ORDBMS – arkitekturer, universell server

• Universell server (ska kunna allt)

• Bra stöd för existerande RDB

• Enkelt att uppgradera från nuvarande system

• Måste vara lika effektiv som RDBMS och lika flexibel som OODBMS

• Riskerar att bli en (ineffektiv) kompromiss


ORDBMS – kravenKrav

• Det måste vara möjligt att söka, accessa och manipulera även komplexadatastrukturer inifrån SQL utan att bryta mot RDBMS regler.

• Det är inte möjligt att bygga fullständigt generella system i den meningen attingen tillverkare kan tillhandahålla eller ens förutse alla datatyper som behövsidag eller kommer att behövas i framtiden utan man måste i så fall leverera deverktyg som krävs för att definiera egna datatyper.

• Man måste också tillhandahålla typsystem som är utökningsbara och flexibla.

• Det är inte rimligt för företagen att vänta på att nästa version av DBMS ska täckaderas speciella behov.

• Det är inte rimligt för DBMS-tillverkarna att ge ut en ny och specialiserad versionför varje nytt behov.


ORDBMSVissa DBMS-tillverkare har fastnat för universell server-begreppet och levererarDBMS där man kan plugga in speciella moduler som täcker kundernas krav och somkan pluggas in i nya versioner av DBMS.

Då kan specialiserade tredjepartsföretag bygga sina egna speciella moduler som kanpluggas in i snart sagt varje DBMS (förutsatt att det är ett utbyggbartrelationssystem).

Utbyggbarheten måste vara så att SQL kan användas och datatyperna indexeras. Detkrävs alltså mer än bara möjlighet till egendefinierade datatyper.


Objektrelationsdatabaser, historiaDr Michael Stonebraker och hans forskningslag hade redan blivit kommersiella medframgång. Man hade lanserat Ingres 1980 och efter 5 år hade marknaden börjatanvända RDBMS i större skala.

Stonebrakers ”gäng” hade visioner. De fortsatte med nästa projekt . . .

Postgres kom 1986, är numera GPL under namnet PostgreSQL. Här fanns ett embryotill utbyggbara typsystem, effektiv hantering av procedurer (lagrades direkt i DBMS,exekverades i DBMS eget primärminne).

Illustra kom 1992. Första GIS-systemet, byggt på Postgres. Omedelbar succé.

1996 köpte Informix Illustra och renodlade idéerna samt integrerade dem med sittRDBMS. Det första utbyggbara RDBMS var fött.


Objektrelationsdatabaser, historiaRDBMS-världen fick fnatt. Alla ville vara med. Forskningen ”hängde på”. Snartlevererade många objektrelationssystem , men ingen så generella som Informix”dynamic server”.

Idag har Informix köpts upp av IBM och cirkeln är sluten.

IBM kommer att integrera DB2 och Informix med det bästa från båda världarna islutprodukten och har redan annonserat en rad förbättringar.

Vad är då ett ORDBMS?

Vilka faciliteter finns som inte finns i RDBMS? Vi ska titta lite på detta och sedan sevad de största leverantörerna har hittat på.


ORDBMS – vad är nytt?Redan i RDBMS hade man infört ” Binary Large OBject ”, BLOB , en ny ’datatyp’ somvar en ”binär sträng” av betydande storlek (åtskilliga MB).

En sträng går inte lika bra att hantera som mer komplexa strukturer. Storleken gjordeatt det mesta måste hanteras som en byte-ström. Bristen på struktur gjordedessutom att man måste hantera information om datas egentliga struktur och typmed extra information.

Alltså kan man inte ställa frågor som avser innehållet i en BLOB eller dess struktur.


ORDBMS – vad är nytt?De operationer och algoritmer som krävs för att manipulera dem kan inte hellerställas till förfogande trots att det handlar om rika, komplicerade och välstrukturerade data (bilder, video, html-, xml-, jsp-, hypertext- ochordbehandlingsdokument).

Oftast måste BLOB:en skickas till ett externt program, kanske bara för att konstateraatt innehållet inte är intressant.

Utöver BLOB har man infört CLOB (Character Large OBject). Här finns ju en struktur.Man kan alltså söka i teckensträngen på ett sätt som är omöjligt i en BLOB.

I vissa system fanns andra ”LOB”-typer.


ORDBMS – vad är nytt?Man har utöver BLOB och CLOB lagt till

• ”radtyper” (row types)

• användardefinierade typer och procedurer (funktioner)

• polymorfi

• arv

• referenstyper och objektidentitet

• ”samlingar” : ARRAY, SET, LIST, MULTISET

• triggers

• rekursion

Vi ska titta lite på allt detta. Dessutom ska vi jämföra ORDBMS med OODBMS. Detmesta vi går igenom gäller alla ORDBMS. Exemplen kommer från PostgreSQL.


ORDBMS – vad är fördelen?Stonebraker föreslog en klassifikation utgående från dels sökmöjligheter ochfleranvändarstöd, dels datakomplexitet och utvidgningsmöjligheter.

Filsystem

RDBMS

OODBMS

sökm

öjli

gh

eter

/fle

ran

vän

dar

stö

d

datakomplexitet/utvidgningsmöjligheter


ORDBMS – vad är fördelen?Tar man med ORDBMS blir bilden komplett:

Filsystem

RDBMS ORDBMS

OODBMS

datakomplexitet/utvidgningsmöjligheter

sökm

öjli

gh

eter

/fle

ran

vän

dar

stö

d


ORDBMS – vad är fördelen?

• Återanvändning

• Delning

• De två punkterna ovan ger ökad produktivitet

• Bevarar redan vunnen kunskap (vore antagligen hindrande dyrt att byta tillOODBMS)

• SQL ⊂ SQL2/SQL92 ⊂ SQL3 (⊂ SQL4)


ORDBMS – finns nackdelar?Uppenbar nackdel: man introducerar komplexitet (utan gräns . . . ).Det finns belackare. Man hävdar att:

• man förlorar den uppenbara enkelheten hos RDBMS

• man utvidgar för en marginell användargrupp (inte många drar nytta avutvidgningarna)

• ”purister” inom OO anser att terminologin inte är bra

• världen är inte relationell ”med lite extra komplexa datastrukturer”

• OO-applikationsprogram är inte datacentrerade i samma utsträckning somtraditionella databasapplikationsprogram


Lite mer historia

Man är inte överens om vilken väg utvecklingen ska ta.

Atkinson, m.fl. skrev 1989 ”The Object-Oriented Database System Manifesto” därman hävdar att objektorientering kommer att dominera utvecklingen och gav riktlinjerför vad som måste ingå.

Redan året efter skrev Stonebraker m.fl. ”The Third-Generation Database SystemManifesto” med riktlinjer för hur relationsdatabaserna skulle utvecklas för att behållasin dominans.

Date m.fl. kom två år senare ut med ”The Third Manifesto” där man attackerarframförallt Stonebraker och förkastar SQL (som kallas för ”en perversion”).


Lite mer historiaIdag har vi facit: I stort sett alla leverantörer följer ganska exakt Stonebrakersmanifesto, SQL3 är i princip en hyllning till honom och gänget kring honom.

Stonebraker ligger också bakom pionjärarbetet med Postgres, som finns undernamnet PostgreSQL att hämta gratis från nätet (GPL-licens).

Postgres designades för att möta de nya kraven från industrin och följer idag SQL3.


Postgres

Man ville:

• ha bättre stöd för komplexa objekt,

• ha möjligheter att utvidga systemen med datatyper, accessmetoder ochoperatorer,

• ha stöd för aktiviteter i databaser – triggers, avbrottshantering, meddelanden tillanvändaren, . . .

• förenkla kraschantering (återhämtning),

• kunna använda nya medier (CD, . . . ), nya tekniker (multiprocessorsystem,VLSI-chips . . . ),

• inte göra våld på relationsmodellen.


PostgresMan lade till:

• abstrakta datatyper,

• datypen ’procedure’,

• regler.


PostgresMan lät alla datatyper vara abstrakta, även de traditionella databasdatatyperna, int2,in4, float4, float8, bool, char, date.

Användare kan utvidga typsystemet. Definitionen för t.ex. int4 ger en vink om hur:

DEFINE TYPE int4 IS (internalLength=4,InputProc=CharToInt4,OutputProc=Int4ToChar,Default="0")

En operator:

DEFINE OPERATOR "+" (int4, int4) RETURNS int4IS (Proc=Plus, Precedence=5, Associativity="left")


PostgresRelationer och arv.

Anställd

Person


PostgresI postquel (inte SQL!)

CREATE person (fnamn=char[15], enamn=char[15],kön=char, pnr=char[13]) KEY (pnr)

CREATE anställd(position=char[10], lön=float4,avdelning=char[10], chef=postquel) INHERITS (person)

Lägg till en person

APPEND anställd (pnr="121212-1212", inamn="Ann",enamn="Larsson", kön="K", position="Assistent",lön="20000", avdelning="sport", chef="RETRIEVE (a.pnr) FROM a IN anställd WHERE

position=’chef’ AND avdelning=’sport’")


PostgresDet finns två sätt att komma åt attribut som chef=postquel

I båda fallen använder man en nästlad punktnotation för att komma åt attributen.

I det ena fallet har man en implicit åtkomst av attributvärdet:RETRIEVE (a.pnr, a.fnamn, a.enamn, a.chef.pnr)FROM a IN anställd

I det andra fallet används en explicit åtkomst:EXECUTE (a.pnr, a.fnamn, a.enamn, a.chef.pnr)FROM a IN anställd

OBS att den fråga som lagrades mha APPEND-kommandot körs då frågornaexekveras!


PostgresMan kan använda parametriserade procedur-typer och låte dessa ta värden frånattributen i den ”anropande” tupeln. Procedurtypen:

DEFINE TYPE Chef ISRETRIEVE (anstNr=a.pnr) FROM a IN anställd WHERE

position="chef" AND avdelning=$.avdelning

och definiera tabellen med:

CREATE anställd(position=char[10], lön=float4,avdelning=char[10], chef=Chef) INHERITS (person)

Frågan ställs då med:RETRIEVE (a.pnr, a.fnamn, a.enamn, a.chef.anstNr)FROM a IN anställd


PostgresADT-mekanismen i Postgres postquel är primitiv i jämförelse med OOP-språk. Arvfinns mellan tabeller - inte annat.

Objektidentitet

Varje tupel (tabellrad) får automatiskt en unik identifierare och alltså har varje tabellimplicit ett attribut oid som kan användas i frågor.

T.ex. kan man definiera en typ som refererar till en rad i ”anställd”-tabellen:

DEFINE TYPE anställd(int4) ISRETRIEVE (anställd.all) WHERE anställd.oid=$1

Observera att relationer, attribut, typer och procedurer har separata namnrymder.Därför kan man ha samma namn på en tabell och en typ.


PostgreSQL och andra

PostgreSQL är GPL-varianten av Postgres. Man har övergett PostQuel till förmån förSQL92 med tillägg av delar av SQL99 (SQL3).

PostgreSQL kan fritt laddas ner från internet och är mycket populär bland Linux- ochSolaris-användare.

PostgreSQL finns i de flesta Linuxdistributionerna och kan laddas ner från t.ex.http://www2.se.postgresql.org/sitess.html

Vi tillhandahåller DB2 version 7.1 med fullständig dokumentation.

Man kan också fundera på Oracle, sista versionen, se www.oracle.com

Informix, numera uppköpt av IBM, har den mest eleganta lösningen men det ärosäkert vad som nu kommer att hända.


SQL3

SQL3-standarden är stor och omfattande och delas in i:

1. SQL/Framework, i stort sett SQL < SQL3.

2. SQL/Foundation, regler för nya datatyper, användardefinierade, regler, triggers,transaktioner och ”stored routines”.

3. SQL/CLI (Call Level Inteface), ett API för programspråk.

4. SQL/PSM (Persistent Stored Modules), tillåter att procedurer skrivna i SQL ellernågot 3GL lagras i databasen så att SQL blir beräkningsmässigt komplett.

5. SQL/Bindings tillhandahåller en dynamisk anropsmekanism så att SQL-kod kanbäddas in i andra språk.

Inte alla DBMS som säger sig stödja SQL3 stödjer hela standarden. Det kan finnasskillnader mellan t.ex. PostgreSQL och DB2 (det finns . . . ). Man måste alltså ännubygga applikationer för ett visst system.


SQL3, framtidenMan planerar att lägga till moduler:

• SQL/Transactions. Man lyfter ut transaktioner från SQL/Foundation ochformaliserar dessa tillsammans med ett standardiserat gränssnitt för anrop avtransaktionsprimitiver.

• SQL/Temporal för att hantera historiska data, tidsserier, versioner och andratemporala utvidgningar.

• SQL/Multimedia för spatiala problem, fulltext, stillbilder, generellaanvändardefinierade typer (komplexa tal, vektorer, Euklidiska rymder (2D/3D)generella typer för koordinater, geometri och operationer på dessa)

• SQL/Real-Time för realtidsproblem och modellering av temporalt sett konsistentadata.


SQL3, vi ska titta närmare på

• konstruktorer för ”ROW TYPE” och referenstyper,

• användardefinierade typer som kan delta i super-/subtypsrelationer,

• användardefinierade procedurer, funktioner och operatorer,

• konstruktorer för ”samlingstyper” (ARRAY, SET, LIST, MULTISET),

• stöd för LOB (Large Objects), binära och teckenorienterade (BLOB och CLOB),

• rekursion.


SQL3, ROW TYPEEn ”ROW TYPE” är en sekvens av par av namn och datatyp och motsvarar iEER-modellering ett sammansatt attribut eller en rad i en tabell.

CREATE TABLE person (personnummer CHAR(11),namn ROW (fnamn VARCHAR(25),

enamn VARCHAR(25)),adress ROW (gata VARCHAR(25),

gatunr SMALLINT,postnr CHAR(6),postort VARCHAR(25)));

INSERT INTO person VALUES (’451112-0356’,ROW(’Serafim’,’Dahl’),ROW(’Alphyddevägen’,13,’131 35’,’NACKA’));


SQL3, användardefinierade typer – DISTINCT TYPEDet finns användardefinierade typer ( User-defined types, UDT ) i SQL3. Den enklasteformen är s.k. DISTINCT TYPE, som används för att semantiskt skilja värden avsamma underliggande typ.

CREATE DISTINCT TYPE PersonNummer AS CHAR(11);

CREATE DISTINCT TYPE AnställningsNummer AS CHAR(11);

Försök att hantera en instans av den ena av dessa som om det vore en instans avden andra skulle generera ett fel. Det är egentligen inte syftet eftersom typbegreppet idatabaser endast har som mål att urskilja vilka värden som ska kunna lagras i enkolumn i en tabell med den definierade domänen.


SQL3, UDTEn UDT kan specifieras på så många sätt att det får räcka med ett exempel. Antag attvi vill representera personer:

CREATE TYPE PersonTyp AS (personnummer PersonNummer CHECK (levande(personnummer)),förnamn VARCHAR(15),efternamn VARCHAR(15),FUNCTION ålder(p PersonTyp) RETURNS INTEGER;

RETURN /* kod för beräkning av ålder */END,FUNCTION ålder(p PersonTyp RESULT, pnr Personnummer)

RETURNS PersonTyp/* Sätt pnr i p */RETURN

END)REF IS SYSTEM GENERATEDINSTANTIABLE NOT FINAL;


SQL3, observatörer och mutatorerFör varje attribut i en UDT skapas automatiskt en observator- och enmutatorfunktion. De kan omdefinieras av användaren.

Man vill ha fullständig inkapsling så att all access till attribut går via observatorn ochall manpulation via mutatorn.

Observatorn för attributet förnamn för typen Persontyp är:

FUNCTION förnamn (p PersonTyp) RETURNS VARCHAR(15)RETURN p.förnamn;


SQL3, observatörer och mutatoreroch motsvarande mutator:

FUNCTION förnamn (p PersonTyp RESULT, nyttnamn VARCHAR(15))RETURNS PersonTyp

BEGINp.förnamn = nyttnamn;RETURN p;

END;


SQL3, konstruktorerDet skapas även en konstruktor för instansieringen av typen. Den tar inga argumentoch sätter alla attribut till deras defaultvärden. En användare kan definiera omdefaultkonstruktorn och en vettigare för typen PersonTyp kunde se ut så:

CONSTRUCTOR FUNCTION PersonTyp (pnr Personnummer,fnamn VARCHAR(15),enamn VARCHAR(15))

RETURNS PersonTypDECLARE :p PersonTyp;BEGIN

NEW :p;SET :p.personnummer=pnr;SET :p.förnamn=fnamn;SET :p.efternamn=enamn;RETURN :p;

END;


SQL3, UDR – User Defined RoutineMan behöver kunna inkludera funktioner och procedurer som inte kan skrivas medde inbyggda faciliteterna.

Om man t.ex. lagrat bilder i databasen och vill kunna presentera s.k. thumbnail-bildersom översikt kan det vara bäst att ha rutiner för att kunna generera översiktsbildensnarare än att lagra en översiktsbild (eller flera) per lagrad bild.

En UDR kan definieras som en del av en UDT eller som en del av ett schema. Den kanskrivas i C, C++, Java, . . . eller helt i SQL(3).

Procedurer kan anropas med CALL och om den har parametrar kan dessa vara avtype IN, OUT eller INOUT, ungefär som i ADA.

Funktioner återsänder sina resultat genom att en parameter märkts med ordetRESULT.


SQL3, UDR – User Defined RoutineCREATE FUNCTION thumbNail (IN im ImageType)RETURNS BOOLEANEXTERNAL NAME thumbnail LANGUAGE CPARAMETER STYLE SQLDETERMINISTICNO SQL;

den externa, körbara filen ’ thumbnail ’ måste tillhandahållas av användaren.ORDBMS kommer att länka den, lagra den i datbasen och anropa den vid behov.

’DETERMINISTIC’ betyder att funktionen ska ge samma resutlat för samma input, dvsatt två anrop med samma in-parameter ska ge exakt samma utvärde.

’NO SQL’ betyder att funktionen inte innehåller SQL-satser (i det här fallet kan manalltså inte använda en C-rutin med inbäddade SQL-satser)


SQL3, UDR – polymorfiPolymorfi i skepnad av ”överlagring” finns med följande restriktioner:

• metoder får definiera om metoder med samma namn ifrån superklassen,

• två funktioner med samma namn i samma schema får inte ha samma signatur(d.v.s. inte samtidigt ha samma antal inparametrar med samma namn och typ, ochinte samma uttyp),

• två procedurer med samma namn i samma schema får inte heller ha sammasignatur.


SQL3, UDR – polymorfiIntressant:

Hittar man ingen procedur eller funktion med exakt samma parameteruppsättningsom i anropet försöker man hitta någon anropbar rutin enligt ett slags”närmaste”-match-begrepp.

SQL3, referenstyper och objektidentitet . . .

Precis som i Postgres finns i SQL3 en implicit ’ oid ’ för varje rad i varje tabell.

Avsikten är att den aldrig ska återanvändas (inte ens om objektet tas bort) och dennakan användas för att skapa referenser mellan objekt i databasen. De kan lagras itabeller och ugör alltså en direkt referens till någon specifik rad i någon tabell idatabasen (eller någon databas i den aktuella servern).


SQL3, sub- och supertyperCREATE TYPE anstTyp UNDER PersonTyp AS (

anställningsnummer AnställningsNummer,position VARCHAR(10) DEFAULT ’Assistent’,lön DECIMAL(8,2),avdelning VARCHAR(10),CREATE FUNCTION ärChef (a anstTyp) RETURNS BOOLEANRETURN a.position=’chef’)INSTANTIABLE NOT FINAL;

OBS! att allt , inklusive klausulen ’ REF IS SYSTEM GENERATED’.

En typ anses ha typen av alla sina supertyper. Alltså fungerar typbegreppet som i deflesta OOP-språken.


SQL3, sub- och supertyperDet finns en speciell restriktion som kommer av att man har med databaser att göra.Varje typ måste ha precis en mest specifik typ . Alltså fungerar inte multipelt arv omman inte har en gemensam supertyp högst upp i hierarkin. Det kan kräva en delganska krystad omorganistaion som inte känns så objektorienterat.

Man kan tvingas att skapa många extra klasser.

I sådana lägen kan det vara nödvändigt att hitta en fördelning mellan objektorienteratarv och tabellarv.

Möjligheten att skapa och använda klasser och subklasser är databasprivilegier. Detgäller även rätten att anropa funktioner och procedurer.


SQL3, tabellerFör att inte äventyra bakåtkompabiliteten med SQL2 måste man fortfarande använda’CREATE TABLE’ för att skapa en tabell, även om tabellen bara består av en enda UDT.Tabeller är fortfarande det enda sättet att se till att data består.

Det innebär att det finns många variationer på ’ CREATE TABLE’-satsen.

CREATE TABLE anställd (info anstTyp,PRIMARY KEY (anställningsnummer));

CREATE TABLE anställd OF anstTyp (REF IS anstID SYSTEM GENERATED,PRIMARY KEY (anställningsnummer));


SQL3, tabell med referenserCREATE TABLE beställning (

bestNr BeställningsNummer,vara varuNr NOT NULL,kvantitet INTEGER NOT NULL,enhet VARCHAR(5) NOT NULL,kund PersonNummer NOT NULL,handläggare REF(AnstTyp) SCOPE anställd

REFERENCES ARE CHECKED ON DELETE CASCADE,PRIMARY KEY (bestNr));


SQL3, problemOm vi skapar en tabell ’ kund ’ enligt

CREATE TABLE kund (info PersonTyp,rabattsats SMALLINT,senasteKreditKöp DATE,PRIMARY KEY (personnummer));

så kommer vi att sprida information om personer (’ anstTyp ’ är subtyp till’PersonTyp ’) över två tabeller. Använder vi samma metod ofta så . . .

Det är bättre att skapa tabellen enligt:

CREATE TABLE kund UNDER person(rabattsats SMALLINT,senasteKreditKöp DATE);


SQL3, problemDå kommer den delen av kundinformationen som har med ’ PersonTyp ’ att göra attlagras i persontabellen (förutsatt att den definieras). Om vi sedan tar bort informationfrån kundtabellen så kommer automatiskt motsvarande rad i persontabellen bort.Reglerna är ganska intuitiva:

• När en rad sätts in i en tabell fördelas informationen över alla ”supertabeller”.

• När en rad uppdateras propagerar uppdateringen till alla ärvda kolumner i alla”supertabeller”.

• När en rad uppdateras kommer alla subtabeller att uppdatera motsvarande rader.

• När en rad tas bort kommer detta att propagera till alla sub-/supertabeller.


SQL3, samlingstyperEndast en har implementerats, ’ ARRAY’.

Övriga kommer nog inte förrän i SQL4.

Antag att vi lägger till

anhörig PersonTyp ARRAY(4)

till ’ anställd ’-tabellen. Då kan vi hitta en anställds närmaste anhörig med

SELECT a.anhörig[1].personnummer, a.anhörig[1].förnamnFROM anställd aWHERE a.personnummer=’451112-0356’;

Men man skulle vilja ha ’ SET’ i det här fallet. Man kan ju ha alltifrån ingen anhörig tillhur många som helst.


SQL3, samlingstyperDå skulle man, enligt den föreslagna SQL3-standarden, kunna representera deanhöriga med

anhörig SET(PersonTyp)

och fråga efter de anhöriga med

SELECT n.personnummer, n.förnamnFROM anställd a, TABLE (a.anhörig) nWHERE a.personnummer=’451112-0356’;

och räkna antalet registrerade anhöriga med

SELECT personnummer, förnamn, efternamn, COUNT(anhörig)FROM anställd;


SQL3, Persistent Stored Modules – PSMDet finns tillägg till SQL3 för att man skall få beräkningsmässig fullständighet iställetför bara relationell fullständighet som i SQL och SQL2. Tilläggen omfattar:

• Deklarationer, t.ex.:DECLARE b BOOLEAN;DECLARE a AnstTyp;b = a.ärChef;

• IF-sats: IF ... THEN ... ELSE ... END IF

• CASE-sats, t.ex.:CASE lowercase(x)

WHEN ’a’ THEN SET a = 1;WHEN ’b’ THEN SET a = 2;

SET b = 1;WHEN ’default THEN set b = 2;

END CASE;


SQL3, PSM• Repetitionssatser, där SQL-satsblock kan exekveras och man successivt kan

”loopa” över raderna i resultattabellerna.

◆ FOR x,y AS SELECT a,b FROM tab1 WHERE cond DO...

END FOR;◆ WHILE NOT b DO

...END WHILE;

◆ REPEAT...

UNTIL NOT bEND REPEAT;

• En ’CALL’-sats för anrop av procedurer och en ’ RETURN’-sats som tillåter att ettSQL-sats-resultat kan användas som returvärde från en SQL-funktion.


SQL3, avbrottshanteringDet finns avbrottshantering. Den är lika ordrik som resten av SQL3 (det skall ju varatalspråk . . . ).

Man deklarerar avbrotten och anger vad som ska hända då ett fel uppstår. Man kansedan välja att vara nöjd med sin åtgärd eller skicka avbrottssignalen vidare till yttrenivåer.

DECLARE { CONTINUE | EXIT | UNDO } HANDLERFOR SQLSTATE { sqlStatus | villkorsnamn |

SQLEXCEPTION | SQLWARNING | NOT FOUND }action;

DECLARE villkorsnamn CONDITION[ FOR SQLSTATE sqlStatus ]

En felsignal kan skickas explicit eller skickas igen

SIGNAL sqlStatus; RESIGNAL sqlStatus;


SQL3, triggersEn trigger är en (sammansatt) SQL-sats som exekveras automatiskt av DBMS som enbieffekt till någon händelse. Man deklarerar dem till att utlösas så fort en viss speciellhändelse inträffar. De används till bl.a.:

• kontrollera indata och upprätthålla komplexa integritetskrav,

• skicka meddelanden om uppdateringar (om det behövs),

• upprätthålla transaktionsloggar,

• datareplikation i distribuerade DBMS

CREATE TRIGGER triggernamnBEFORE | AFTER händelse ON tabell[ REFERENCING aliaslista ][ FOR EACH { ROW | STATEMENT } ][ WHEN triggervillkor ]triggerkod


SQL3, triggers – exempelCREATE TRIGGER setnull-triggerBEFORE UPDATE ON anställdREFERENCING NEW ROW AS newrowFOR EACH ROWWHEN newrow.telefonnummer = ’’SET newrow.telefonnummer = NULL

CREATE TRIGGER kontrollera-avdelningBEFORE INSERT ON anställdREFERENCING NEW ROW AS newrowWHEN newrow.avdelning NOT IN

(SELECT namn FROM avdelning)SIGNAL avd-not-found(newrow.avdelning)


SQL3, triggers – exempelCREATE TRIGGER updatera-lagretAFTER INSERT ON beställningREFERENCING NEW ROW AS newrowFOR EACH ROWUPDATE lager SET volym = volym - newrow.kvantitet

WHERE varunummer = newrow.varunummer


ORDBMS, några systemTre av de ledande DBMS-företagen – IBM, Informix och Oracle – har byggt ut sinastandard RDBMS till ORDBMS eller ”universalservrar” (universal server).

Alla tre har – med varsin teknik – byggt ut DBMS så att de kan hantera pluggbaramoduler som utökar datalagringsmöjligheterna (utökat och utbyggbart typsystem)och funktionaliteten hos själva DBMS.

Vi ska titta lite på vart och ett.


DB2 Relational ExtendersIBMs första försök att implementera SQL3 (DB2 vers 5).

SQL3 innehåller regler för att skapa UDT, UDF, LOB (large object), triggers, storedprocedures, och kontroller.

I vers 6 finns abstrakta datatyper (enl SQL3) med möjlighet att deklarera klasser somi objektorienterade språk.

Objekten som skapas ur ”klasserna” kan lagras i basrelationer, inspekteras medhjälp av SQL som vilken DBMS datatyp som helst och hanteras transparent m.h.a.alla vanliga DBMS-faciliteter.


DB2 Relational ExtendersAllt kan hanteras som vilka databastyper som helst från användarens synpunkt. EnDBA kan utgående från fyra medföljande Relational Extenders och från tabeller, UDT,UDF, triggers, stored procedures och restriktioner skapa allt som behövs för atthantera snart sagt varje organisations behov av datalagring.

De som utvecklar nya Relational Extenders använder precis samma verktyg.

All samlad kunskap från RDBMS är forfarande relevant.

SQL3 innehåller verktyg för att skapa objekt med godtycklig komplexitet.


DB2 Relational ExtendersEtt stort antal tredjeparts Relational Extenders finns att tillgå.

De är enkla att installera och aktivera för den eller de databas/-er som ska användadem.

En gång inpluggade är de en integrerad del av DBMS sett från de databaser för vilkade aktiverats.


DB2 Relational Extenders


Informix DataBladesEtt Informix DataBlade är en standard mjukvarumodul som pluggas in i DBMS ochsom utökar dess kapacitet. Ett datablad innehåller

• en ADT,

• ett antal ADF,

• accessmetoder,

• indexeringsmetoder,

• optimeringsmetoder (för sökning) och

• funktionalitet för att manipulera data av den typ som databladet definierar.

Dessutom finns där regler och restriktioner som skall uppfyllas på samma sätt somför de fördefinierade typerna.


Informix DataBladesI Informix Dynamic Server (tidigare universal server) är värden som genereras från enADT första klassens objekt.

Värdena kan

• lagras,

• inspekteras (man kan ställa frågor avseende alla deras delar),

• indexeras,

• skickas till applikationsprogram,

• skickas som funktionsparametrar

o.s.v.

De kan definieras i termer av andra ADT eller fördefinierade typer (eller båda).


Informix DataBladesDet finns tre grundläggande typer av ADT i datablad:

• ”row-types” – En ”row-type” är en SQL3-datatyp som omfattar ett antal kolumnerbaserade på fördefinierade typer eller ADT-er. Genom att en row-type ärver sinaegenskaper från sina komponenter kan de användas för att elegant modellera joinmellan tabeller.

• ”distinct types” används för att modifiera andra datatyper, t.ex. för att specialiseradem.

• ”opaque types” är de mest flexibla. De implementeras i C, C++ eller Java. Man gerfullständiga specifikationer avseende typens instanser skall lagras, indexeras ochbearbetas.


Informix DataBladesUDF kan programmeras i Informix Stored Procedure Language (SPL) eller i C, C++,eller Java. De som programmeras i C, C++, eller Java kompileras och läggs antingen ien delad objektfil eller ett dynamiskt länkbibliotek (DLL). När funktionen anropaslänks objektkodsobjektet in i servern och exekverar i serverns primärminne.

Dynamic Server innehåller sin egen runtimemodul för vart och ett av språken (så mankan välja JRT).

Accessmetoderna hanteras av servern så man kan använda existerande (om depassar) eller implementera nya.


Informix DataBladesInget svårt att implementera nya. Accessmetoderna är definierade som en mängdfunktioner designade för att

• starta indexscanning

• hämta nästa rad (tupel)

• sätta in en tupel

• ta bort en tupel

Så man kan enkelt stoppa in mer specialiserade index som t.ex. R-träd som ju äreffektivare än B-träd då man söker i 2D and 3D spatiala datatyper.


Informix DataBladesDet finns också ”gränssnitt” som låter datablad använda datablad.

Datablad kan också lagras i databasen (naturligtvis) och kan manipulera sin egendefinition.

Detta gör dem till datadrivna och de är lätta att ändra, hantera och bygga ut.

Allt detta finns det stöd för i datablads-API’t.

Det finns också ett utvecklings-”kit” för datablad.


Informix DataBlades


Oracle CartridgesOracle Cartridge är en av nyckelkomponenterna i Oracle Network ComputingArchitecture (NCA).

Övriga är

• klientapplikationer,

• Oracle Universal Application Server och

• Oracle Universal Server.

Alla kommunicerar via öppna standardiserade protokoll med varandra (och alla andrasom använder samma protokoll).


Oracle CartridgesFrån DB-synpunkt är det Oracle Universal Server som tillhandahåller utbyggbara,skalbara datalagringsmöjligheter.

En cartridge är ett pluggbart och mjukvarumässigt hanterbart objekt.

Dess interna struktur definieras genom standard SQL3 och dess gränssnitt motomgivningen m.h.a. OMGs IDL (samma som CORBA använder).

Man kan utveckla cartridges i C, C++, PL/SQL, eller Java.

I NCA-arkitekturen finns tre typer av cartridge (klassifikationen kommer av var deförväntas finnas)


Oracle Cartridges

• Ett data cartridge hanteras i databasservern och har tillgång till vad man kallarden utbyggabara databasservicen ( extensible database services ).

• En applikationserver-cartridge kan hanteras antingen i applikationsservern ellerdatabasservern beroende på hur hårt applikationslogiken är knutna till data somlagras i DBMS. I nuvarande version lagras de i applikationsservern ochkommunicerar med DBMS via Oracles webapplikationsserver för intercartridgekommunikation via CORBA/IIOP (Inter-ORB Protocol).

• En klientcartridge körs på klienten och har tillgång till de vanliga(standardiserade) användargränssnitten.


Oracle CartridgesCartridge-objekt kan kommunicera med varandra via en speciell objekt-bus somkallas Inter-Cartridge Exchange (ICX).

ICX har implementerats som en mängd bibliotek och tjänster. Genom biblioteken harett cartridge-objekt möjlighet till kontakt med andra cartridge-objekt, klientprogram,servrar och andra tjänster.

ICX använder HTTP och IIOP för kommunikation och är kapabelt att utföra en helmassa konverteringar automatiskt.

ICX har gränssnitt mote ActiveX (via brygga), Java (via CORBA/IDL–IIOP-JDBC) ochen mängd andra språk och programvaror.


Oracle Cartridges


Oracle CartridgesOracles cartridge är lika flexibla (erbjuder samma möjligheter) som Informix databladmen via standardiserade gränssnitt.

Man levererar också gränssnitt mot fler språk än Informix.

Det erbjuder fördelar men också performancenackdelar.


Till slutHjärnan bakom det mesta i ORDBMS-världen är, som tidigare nämnts, MichaelStonebraker, som skapade Ingres, Postgres, Illustra och slutligen Informix DynamicServer.

Det tre stora – IBM, Informix och Oracle – har lyckats och kommer att kapa åt sigmarknadsandelar. Trots alla likheter finns det skillnader.

DB2 bygger på SQL3-standarden, Oracle på öppna kommunikationsstandarder (IDLoch CORBA2.0).

Informix å andra sidan har fokuserat på att det är svårt att lägga till klasser i ett – ihuvudsak – relationellt system och tillhandahåller kraftfulla paket för uveckling avdatablad och för att integrera dem i systemet (BladeSmith, Bladepack ochBlademanager)


Andra systemAMOS II (Uppsala Universitets Databaslaboratorium)Caché (InterSystems)Data Access FrameWork / Total (CinCom)Enterprise Application Server (Sybase)KE Texpress (Knowledge Engineering)JBMS (Cloudscape)Lincks (Linköpings Universitet)Matisse (Matisse)Microsoft Repository (Microsoft)ODB-II (Fujitsu)OSMOS (Unisys)Phasme DBMS (Frederic Andres)Polyhedra (Polyhedra)PostgreSQL (UCB)UniSQL (Cincom)


referenser

Referenser

[1] L. Cardelli and P. Wegner. On understanding types, data abstraction andpolymorphism. ACM Computing Surveys , 17(4):471–522, December 1985.

[2] P. Wegner. Concepts and paradigms of object-oriented programming. ACMOOPS Messenger , 1(1):7–87, August 1990.

[3] O. Nierstrasz. A survey of object-oriented concepts. In Object-OrientedConcepts, Databases and Applications . ACM Press and Addison-Wesley, 1989.

[4] G. Blair, J. Gallagher, D. Hutchison, and D. Shepherd, editors. Object-OrientedLangauges, Systems and Applications . Pitman Publishing, 1991. ISBN0-273-03132-5.

[5] S. Abiteboul, R. Hull, and V. Vianu. Foundations of Databases . Addison-Wesley,Reading, Mass., 1995.


[6] G. Castagna. Object-Oriented Programming: A Unified Foundation . Progress inTheoretical Computer Science. Birkhauser, 1997.

[7] R.G.G. Cattell. Object Data Management . Addison-Wesley, Reading, MA, 1991.

[8] H.M. Deitel and P.J. Deitel. Java How to Program . Prentice-Hall, second edition,August 1998.

[9] C. Delobel, P. Richard, and C. Lecluse. Databases: From Relational toObject-Oriented Systems . International Thomson Publishing, 1995.

[10] S.B. Lippman. C++ Primer . Addison-Wesley Publishing Co., second edition,1991.

[11] B. Meyer. Object-oriented Software Construction . Prentice Hall, 1988.

[12] R. Sethi. Programming Languages: Concepts and Constructs . Addison-Wesley,first edition, 1989.

[13] B. Stroustrup. The C++ Programming Language . Addison-Wesley, 1997.

[14] D. Watt. Programming language concepts and paradigms . Prentice-Hall Intl.Series in Computer Science. Prentice-Hall, 1989.


[15] S.B. Lippman. Inside The C++ Object Model . Addison-Wesley Publishing Co.,1996.

[16] S. Dahl and K. Lindqvist. Objektorienterad programmering och algoritmer iSimula (in Swedish) . Studentlitteratur, 1993.

[17] B. Eiderbäck, O. Bälter, and P. Hägglund. Objektorienterad programmering iSmalltalk (in Swedish) . Studentlitteratur, 1995.

[18] T. Reenskaug, P. Wold, and O.A. Lehne. Working with objects: the ooramsoftware engineering method . Manning Publications Co., 1996.

[19] F. Manola. Object model features matrix. Technical report X3H7-93-007v12b,National Committee for Information Technology Standards, 1997.

[20] E. Bertino and L. Martino. Object-oriented database management systems:Concepts and issues. Computer , 24(4):33–47, April 1991.

[21] E. Fong, W. Kent, K. Moore, and C. Thompson (eds). Object data managementreference model. NIST Technical Report, OMG TC Document 92-2-5, NationalInstitute of Standards and Technology, September 1991. Final Report of theANSI X3/SPARC/DBSSG Object-Oriented Database Task Group.


[22] J. Banerjee, H.-T. Chou, J.F. Garza, W. Kim, D. Woelk, N. Ballou, and H.-J. Kim.Data model issues for object-oriented applications. ACM Transactions on OfficeInformation Systems , 5(1):3–26, 1987.

[23] K.B. Bruce, L. Cardelli, G. Castagna, The Hopkins Object Group, G.T. Leavens,and B. Pierce. On binary methods. Theory and Practice of Object Systems ,1(3):221–242, 1996.

[24] P. Cointe. Metaclasses are first class : The ObjVlisp model. In NormanMeyrowitz, editor, Proceedings of the 2nd Annual Conference onObject-Oriented Programming Systems, Languages and Applications (OOPSLA’87), pages 156–167, Orlando, FL, USA, October 1987. ACM Press.

[25] M.P. Atkinson, F. Bancilhon, D. DeWitt, D. Maier, K. Dittrich, and S Zdonik. Theobject-oriented database system manifesto. In First Int. Conf. on Deductive andObject-Oriented Databases, Kyoto , December 1989.

[26] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen.Object-Oriented Modeling and Design . Prentice-Hall, Englewood Cliffs, NewJersey, 1991.


[27] P. Grogono and A. Bennett. Polymorphism and type checking in object-orientedlanguages. ACM SIGPLAN Notices , 24(11):109–115, November 1989.


ogrammering - kth · bara del objektet. h oncept. för v xitet. 2d1470 22. delar man det måste att...

Documents