Citater fra C.J.Date "An Introduction to Database Systems" kapitel 22:
Nogle af de nye faciliteter, som tilsyneladende mangler i DBMS har eksisteret i mange år i de objekt-orienterede programmeringssprog. Det er derfor naturligt at undersøge, om det er en god ide at indarbejde disse faciliteter i databasesystemer og som en konsekvens heraf overveje muligheden for et objekt-orienteret databasesystem. [630]
Det bør aldrig blive brugerens problem at kæmpe med computer-orienterede begreber som bits og bytes (eller records og felter). I stedet bør det være muligt for brugeren at arbejde med objekter og med operationer på disse objekter. Disse begreber ligner mere de forhold i den virkelige verden, som de skal afbilde. [630]
Den grundlæggende ide er at hæve abstraktionsniveauet. [630]
Selvom programmeringssprog og håndtering af databaser bestemt har meget til fælles, er de også på en række væsentlige punkter forskellige. Formålet med et applikationsprogram er således at løse et specifikt problem, hvorimod formålet med en database er at løse en række forskellige problemer, hvoraf nogle måske ikke engang er kendt på det tidspunkt, hvor databasen designes. [631]
Mange af de argumenter, som i 70'erne blev brugt imod de hierarkiske databasesystemer, kan gentages nu i relation til den objekt-orienterede ide. [631]
Der er mange, som mener, at objekt-orienterede teknikker er det rigtige valg til nye typer applikationer som CAD/CAM, CIM, CASE, Geografiske informationssystemer, Videnskabelige og medicinske applikationer, dokumenthåndtering og [Multimedia]. [631]
Formålet med dette kapitel er at introducere de vigtigste begreber i den objekt-orienterede fremgangsmåde, og med særlig vægt på en beskrivelse af begreberne ud fra et database perspektiv. [631]
Mange OO begreber er temmelig upræcise og der er ikke særlig meget enighed om begreberne selv på de mest basale niveauer. Der findes ingen abstrakt, formelt defineret "objekt datamodel" - der er ikke engang enighed om en uformel model. [634]
Der er tilsyneladende megen forvirring omkring abstraktionsniveauerne - og specifikt omkring en skelnen mellem modellen selv og dens implementering. [635]
Det er et grundlæggende princip i den objekt-orienterede fremgangsmåde, at "alt er et objekt". I nogle tilfælde er der tale om, hvad der i en traditionel terminologi ville svare til simple værdier. Andre objekter (typisk brugerdefinerede) er mere komplekse. Disse mere komplekse objekter svarer til variabler af varierende intern kompleksitet. [635]
Ethvert objekt har en type (det objekt-orienterede begreb er klasse). De individuelle objekter omtales undertiden som objektforekomster (instanser) for at kunne skelne dem klart fra de korresponderende objekttyper eller klasser. [635]
Alle objekter er indkapslede. Det betyder, at deres indre struktur ikke er synlig for brugerne af objektet. I stedet ved brugerne kun, at objekterne er i stand til at udføre visse funktioner (også kaldet metoder). [636]
Indkapsling medfører datauafhængighed. [636]
Den private hukommelse består af objektets attributter (instansvariabler). Det offentlige (public) interface består af interfacedefinitioner for de metoder, som er tilknyttet det pågældende objekt. [636]
Hvis foruddefinerede metoder udgør de eneste muligheder for at manipulere med objekter, er det umuligt at lave ad hoc forespørgsler. [636]
Metoderne kaldes ved hjælp af meddelelser. [636]
Ethvert objekt har en unik identitet kaldet Objekt ID eller OID. [637]
OID fungerer som en (begrebsmæssig) adresse, og denne adresse kan bruges andre steder i databasen som (begrebsmæssige) pointere, hvis man ønsker at referere til det pågældende objekt. [637]
OID'erne er ikke direkte synlige for brugerne. [638]
Ethvert lagret objekt indeholder mindst to private instansvariabler - én der indeholder objektets egen OID, og én der indeholder OIDen for det klassedefinerende objekt for det pågældende objekt. Dette hænger sammen med, at såvel objekterne som klassedefinitionerne er lagret i databasen som objekter. Referencen til det klassedefinerende objekt er nødvendig, fordi man her finder de forskellige metoder, der er defineret for den pågældende klasse. Det klassedefinerende objekt og dets tilhørende objektforekomster ser altså meget forskellige ud - de lagrede objektforekomster rummer primært de aktuelle værdier for de pågældende objekter, hvorimod det klassedefinerende objekt primært indeholder koden til de metoder, som alle objektforekomster af den pågældende klasse er fælles om. [640]
Det er velkendt, at der kan opstå problemer i relation til brugerdefinerede nøgler. Der har derfor været argumenteret for, at relationelle DBMS i stedet burde understøtte systemdefinerede nøgler (surrogater). Disse argumenter er meget lig de argumenter, der bruges som begrundelse for OID i objekt-orienterede systemer. Der er dog mindst en tydelig forskel: Surrogater er værdier, og som sådan synlige (tilgængelige) for brugeren. OID'er er adresser eller pointere, og som sådan usynlige for brugeren. [642]
OID konceptet gør ikke de brugerdefinerede nøgler overflødige. Brugernøgler er nødvendige af hensyn til kommunikationen med omverdenen. Internt i databasen kan alle krydsreferencer dog etableres med OID'er. [642]
OID'er er årsag til den ofte hørte kritik, at OO systemer ligner de gamle CODASYL databaser. Det er også rigtigt, at brugen af OID'er fører til en temmelig lav-niveau, pointer-jagtende programmeringsstil, som er meget lig den stil der blev brugt i de tidligere CODASYL systemer. [642]
En objektklasses er grundlæggende det samme som en datatype. [642]
Alle klasser forstår en NEW meddelelse, som medfører oprettelse af en ny forekomst af et objekt af den pågældende klasse. [642]
Fordi objekter kan indeholde pointere (OID'er) til andre objekter i stedet for de andre objekter i sig selv, kan et objekt deles af mange andre objekter. Det samme objekt kan f.eks. samtidig indgå i flere forskellige samlinger (collection). [643]
En objektklasse Y siges at være subklasse
til objektklassen X (superklassen) hvis det gælder,
at et objekt, der tilhører klassen Y, også nødvendigvis
må tilhøre klassen X. Objekter af klassen Y arver
de instansvariabler og metoder, der er defineret for klassen X.
Som en konsekvens heraf kan brugeren altid anvende et objekt af
klassen Y på et sted, hvor man kan anvende klassen X. Herved
opnås den fordel, at man kan genbruge superklassens
kode. Den evne, at samme metode gælder for objekter
af flere forskellige klasser, kaldes polymorfi. [645]
25. april 1997