Les syst`emes de gestion de bases de donn´ees objet
5.3 Fonctionnalit´es des SGBDO
5.3.1 G´en´eralit´es
L’article (( The Object Oriented Database System Manifesto )) [Atkinson et
al., 1989] d´efinit, ce que l’on est en mesure d’esp´erer d’un SGBDO. Nous allons nous appuyer sur cette d´efinition pour pr´eciser les diff´erentes caract´eristiques de ces syst`emes. Les auteurs distinguent les caract´eristiques n´ecessaires (r`egles d’or) que doivent poss´eder lesSGBDO, puis les caract´eristiques optionnelles qui feront en partie le sujet de la section 5.5.
LesSGBDOdoivent satisfaire aux deux crit`eres essentiels :
• ˆetre des syst`emes `a objets et, `a ce titre, permettre la gestion d’objets com-plexes (en fait le terme objet complexe est apparu d`es que les attributs ou champs d’un objet n’´etaient plus contraints `a ˆetre de type atomique), l’iden-tit´e d’objet, l’encapsulation, les notions de types et/ou de classes, d’h´eritage, de surcharge ;
• ˆetre des syst`emes de gestion de bases de donn´ees et, `a ce titre, assurer la persistance des donn´ees, leur gestion en m´emoire secondaire, la concurrence et l’acc`es aux donn´ees via un langage de requˆetes.
Les concepts sp´ecifiques aux bases de donn´ees ne seront pas d´etaill´es ici. Il existe une multitude d’ouvrages les d´ecrivant [Ullman, 1989 ; Date, 1990 ; Gardarin et Valduriez, 1990 ; Kim, 1990 ; Bancilhon et al., 1991 ; Delobel et al., 1991 ; Garda-rin, 1993 ; Benzaken et Doucet, 1993 ; Collet et Adiba, 1993 ; Kemper et Moerkotte, 1994 ; Abiteboul et al., 1995 ; Cattell, 1997]. Les concepts objet sont d´evelopp´es dans les chapitres relatifs aux langages de programmation et aux m´ethodes d’ana-lyse et de conception (cf.chapitres 1, 2, 3, 4 et 8). Nous nous attacherons simplement `a montrer les diverses facettes d’unSGBDO, en pr´ecisant les sp´ecificit´es issues de la combinaison des langages `a objets et des bases de donn´ees.
Plusieurs mod`eles d’objets (plus ou moins formalis´es) ont ´et´e propos´es pour les
SGBDO [Cardelli et Wegner, 1985 ; Maier et al., 1986 ; Abiteboul et Hull, 1987 ; Banerjee et al., 1987 ; Hull et King, 1987 ; Beeri, 1989 ; Hammer et McLeod, 1981] issus des r´eseaux s´emantiques ou des langages de classes [Masini et al., 1989].
Avant d’aborder, plus en d´etail, les fonctionnalit´es des SGBDO, nous allons pr´esenter un exemple succinct relatif `a la gestion simplifi´ee d’un institut de for-mation universitaire, que nous utiliserons dans la suite du propos.
Au sein de l’institut, les personnes regroupent la population ´etudiante et ensei-gnante. Chaque personne a un nom, une liste de pr´enoms et une adresse comportant une rue, un num´ero et une ville. Les ´etudiants poss`edent de plus un num´ero de carte d’´etudiant, les enseignants ont un grade et un salaire. L’institut propose des cours. Chaque cours a un intitul´e et un num´ero, ainsi qu’un volume horaire et un ensemble de cours qui sont pr´erequis. Un cours est enseign´e par un et un seul enseignant et un en-seignant peut assurer plusieurs cours. Un ´etudiant peut suivre plusieurs cours existants, et ´evidemment un cours doit ˆetre suivi par plusieurs ´etudiants. Enfin certains ´etudiants peuvent acc´eder au statut particulier d’Attach´e Temporaire de Recherche (Ater) et, `a ce titre, ils peuvent enseigner.
En utilisant le formalisme de la m´ethode OMT [Rumbaugh et al., 1991] (cf.
chapitre 4), le concepteur propose le diagramme d’objets de la figure 5.3. Ce dia-gramme constitue la repr´esentation du sch´ema conceptuel de la base de donn´ees. Les classesPersonne,Etudiant,Enseignant,AteretCourssont d´ecrites avec leurs attributs et leurs op´erations. Les classesEtudiantetEnseignantsont des sp´ecialisations de la classePersonne; la classeAterest une sp´ecialisation des clas-sesEtudiantetEnseignant. La classeCoursest associ´ee `a la classeEtudiant, `a la classeEnseignantet `a elle-mˆeme. Chaque association est d´ecrite par les verbes qui pr´ecisent comment les classes associ´ees sont li´ees entre elles et par une arit´e conforme au contraintes donn´ees dans le texte initial.
0 0 1 1 0 0 0 1 1 1 00 00 11 11 0 0 1 1 0 0 0 1 1 1 Supprimer Cours enseigne -> est_enseigné_par -> est_suivi_par -> suit -> a_des_prérequis -> est_prérequis_par -> numéro volume_horaire Afficher numéro_carte Enseignant Etudiant salaire grade Afficher_cours_suivis Inscrire Abandonner Personne nom prénoms adresse Créer Lire_nom Embaucher Créer domaine_recherche Ater
FIG. 5.3: Mod`ele objet d’une gestion simplifi´ee d’institut universitaire.
La((traduction))de ce mod`ele dans une syntaxe proche de celle duSGBDO2 [Bancilhon et al., 1991] va servir de base pour ´etayer les divers points ´enum´er´es en introduction (FIG. 5.4).
5.3.2 Etre un syst`eme `a objetsˆ
Nous allons rapidement pr´esenter en quoi lesSGBDOsuivent le paradigme objet. Les concepts sont h´erit´es des langages de programmation par objets (LPO) (cf. cha-pitres 1, 2, 3 et 8), mais la sp´ecificit´e des bases de donn´ees transparaˆıt.
Objets et identification
Le concept essentiel partag´e par tous lesSGBDO est bien sˆur celui d’objet. Un objet est une collection de donn´ees structur´ees identifi´e par une r´ef´erence unique et pouvant r´eagir `a divers stimuli. En d’autres termes, un objet poss`ede une identit´e, un ´etat (valuation de ses propri´et´es statiques ou attributs) et un comportement : il peut r´epondre `a des messages provenant d’autres objets.
Schema Gestion Universitaire Class Personne
tuple (nom : string,
pr´enoms : list(string),
adresse : tuple(rue : string, num : integer, ville : string))
Method Cr´eer (n : string) : Personne,
Lire nom : string End Personne
Class Etudiant inherit Personne
tuple (num´ero carte : integer,
cours suivis : set(Cours))
Method Inscrire (c : Cours),
Abandonner (c : Cours) End Etudiant
Class Enseignant inherit Personne
tuple (grade : string,
salaire : real,
cours enseign´es : set(Cours))
Method Embaucher()
End Enseignant
Class Ater inherit Enseignant,Etudiant
tuple (domaine recherche : string)
End Ater Class Cours
tuple (num´ero : string,
volume horaire : integer, inscrits : set(Etudiant), enseignant : Enseignant, ....)
Method Cr´eer(num : string) : Cours,
Supprimer, Afficher, .... End Cours
Nom : "Lucie"
Objet 2
Oid 2
Nom : "Pierre" Cours_suivis : { Oid3 , Oid4, Oid5}
Cours_suivis : { Oid3 , Oid6, Oid7}
Oid 3
Objet 3
Nom : "base de données", Volume : 50 Oid 1
FIG. 5.5: Pierre et Lucie suivent le mˆeme cours.
L’identit´e unique (object identifier ou oid) traduit simplement le fait que l’ob-jet existe : elle est ind´ependante de l’´etat de l’obl’ob-jet. Tout obl’ob-jet peut, au sein du syst`eme, ˆetre associ´e `a un doublet (oid, ´etat). Il conserve cette identification im-muable au cours du temps tout en admettant que son ´etat puisse ˆetre alt´er´e aussi souvent que n´ecessaire. Ce principe d’identit´e unique ind´ependant de l’´etat, consti-tue, en soi, une nouveaut´e par rapport aux principes desSGBDrelationnels. Ceux-ci, d´enot´es orient´es valeur manipulent, quant `a eux, des propri´et´es identifiantes ou cl´es d´ependantes de la valeur. La pr´esence d’une cl´e dans un sch´ema relationnel assure l’unicit´e des valeurs associ´ees aux attributs qui la constituent, d’o `u l’unicit´e des n-uplets concern´es.
Les objets ayant une identit´e unique, la notion de partage d’objets devient chose naturelle.
`
A titre d’illustration, supposons que Pierre et Lucie soient des ´etudiants inscrits au mˆeme cours. Dans un syst`eme `a objets, les deux objetsPierre etLucieont un cours en commun lecours (oid3, Nom : "base de donn´ees", Volume : 50)(FIG. 5.5). Une mise `a jour sur l’´etat de cet objetcourssera((effective))
pour tous les ´etudiants partageant cet objet.
Dans un syst`eme relationnel, la repr´esentation du fait que Pierre et Lucie soient des ´etudiants inscrits dans un mˆeme cours peut se traduire par les n-uplets suivants :
("Pierre", "bases de donn´ees", 50),("Lucie", "bases de donn´ees", 50). Le partage du cours n’est traduit, implicitement, que par l’´egalit´e de la valeur des attributsnom etvolume. Les mises `a jour peuvent ˆetre faites pour les deux n-uplets s´epar´ement ou non. Pour pallier cette ambigu¨ıt´e nous aurions pu dans le mod`ele relationnel instaurer une((indirection))pour assurer la mise `a jour simul-tan´ee pour tous les ´etudiants qui suivent le mˆeme cours, ce qui aurait alourdi la repr´esentation. Les syst`emes relationnels les plus r´ecents proposent la notion de contrainte d’int´egrit´e r´ef´erentielle exprim´ee entre deux sch´emas relationnels. Cette contrainte lie l’existence et par suite toutes les mises `a jour d’un n-uplet d’une re-lation `a celles d’un autre n-uplet((r´ef´erent))dans une autre relation. En fait, grˆace
Objet 1 : (oid1, [Nom: "Pierre", Cours suivis: {Oid3, Oid4, Oid5}]) Objet 2 : (oid2, [Nom: "Lucie", Cours suivis: {Oid3, Oid6, Oid7}]) Objet 3 : (oid3, [Nom: "BD", Volume: 50])
Objet 4 : (oid4, [Nom: "LPO", Volume: 50])
Objet 5 : (oid5, [Nom: "Syst eme", Volume: 70])
Objet 6 : (oid6, [Nom: "BD", Volume: 50]) Objet 7 : (oid6, [Nom: "Algo", Volume: 30])
Objet 8 : (oid8, [Nom: "Pierre", Cours suivis: {Oid6, Oid4, Oid5}]) Objet 9 : (oid9, [Nom: "Lucie", Cours suivis: {Oid3, Oid6, Oid7}])
Les neuf objets sont distincts c’est-`a-dire qu’ils ont des identit´es diff´erentes. Objets 2 et 9 sont ´egaux en surface et en profondeur.
Objets 1 et 8 sont ´egaux en profondeur mais diff´erents en surface. Objets 1 et 2 sont diff´erents en surface et en profondeur.
FIG. 5.6: ´Egalit´e et copie.
au concept d’objet (et d’identit´e unique), lesSGBDobjets permettent de mettre en œuvre un m´ecanisme de mises `a jour coh´erent qui pr´evient de toute anomalie et qui est proche de l’int´egrit´e r´ef´erentielle des syst`emes relationnels.
L’identification d’objets permet de d´efinir, pour des objets instances d’une mˆeme classe, des op´erateurs de comparaison et de copie :
• identit´e : deux objets identiques correspondent au mˆeme objet. L’objetcours
suivi parPierreest identique `a l’objetcourssuivi parLucie.
• ´egalit´e (de surface et en profondeur) : deux objets sont ´egaux en surface s’ils
ont les mˆemes valuations pour leurs attributs ; ils sont ´egaux en profondeur s’ils ont des((graphes de composition))isomorphes au niveau de chacun de leurs attributs et ont les mˆemes valuations pour leurs attributs terminaux.
• copie (superficielle et profonde) en accord avec les op´erateurs d’´egalit´e
pr´ec´edents.
Les syst`emes relationnels peuvent simuler l’identit´e au sens objet en rajou-tant des identificateurs de n-uplets (notion de surrogate introduite par Codd [Codd, 1979]). Le concept d’identit´e ind´ependante de la valeur avait d´ej`a ´et´e introduit dans lesSGBDnavigationnels qui g`erent pour tout enregistrement ou record un identifiant syst`eme appel´e cl´e d’enregistrement.
De leur cˆot´e, les syst`emes `a objets peuvent rajouter la notion de cl´e d’objet analogue `a celle des syst`emes relationnels traduisant l’obligation d’unicit´e de la valeur pour les attributs d´efinissant cette cl´e pour toute instance cr´e´ee (cf.chapitre 10).
Classes et types
Sans entrer dans une discussion qui d´epasse le cadre de ce chapitre, notons que deux approches diff´erentes existent parmi lesSGBDOselon qu’ils d´erivent de
lan-Valeur / Etat a pour type Type est instance de Objet Classe a ou spécifie possède
FIG. 5.7: Classes et types dans lesSGBDO.
gages comme SMALLTALK, LISP, CLOS ou de langages comme C++. Certains rel`event du tout objet : les classes sont des objets et d´ecrivent un type ; les autres diff´erencient classes et types, objets et valeurs7(cf.chapitre 1).
Comme la terminologie est souvent sujette `a controverses, on peut en quelques lignes d´efinir les termes types et classes tels qu’ils sont admis par la communaut´e bases de donn´ees.
La notion de type correspond `a la notion de type utilis´ee dans les langages de programmation tels que PASCAL, C, etc. Un type est((instanci´e))par des valeurs qui n’ont pas une identit´e au sens de celle des objets.
La notion de classe, elle, recouvre en fait deux versants :
• Une classe est accompagn´ee d’une description en intension (cf.chapitre 12). La sp´ecification de cette description est analogue `a celle d’un type construit auquel on adjoint des op´erations sp´ecifiques. En phase d’ex´ecution, la classe sert `a cr´eer les objets qui sont ses instances.
• Une classe a une composante extensionnelle. Tous les objets instances de la classe constituent son extension. On peut distinguer la notion d’extension
(( propre )) correspondant uniquement aux instance propres de la classe et la notion d’extension((globale))correspondant aux instances de la classe et de celles de toutes ses sous-classes. Pour les SGBDO, ce rˆole d’((entrep ˆot))
assign´e `a la classe est essentiel en phase d’exploitation (les instances devant pour la plupart ˆetre sauvegard´ees sur support physique).
CertainsSGBDont unLDDqui d´efinit des types ind´ependamment des classes et un
LMDqui manipule par suite des valeurs ind´ependamment des objets.
7. Au sens o`u l’on trouve dans cesSGBDOcomme dans certains langages de programmation par objets des types qui ne sont pas des classes et des valeurs qui ne sont pas des objets. Cependant toute classe a un type associ´e.
Class Equipe enseignante set(Enseignant) End Equipe enseignante
FIG. 5.8: Classe collection
Method body Lire nom : string in Class Personne
{return self.nom;}
FIG. 5.9: Code pour Lire nom La description intensionnelle d’une classe comporte :
• Une partie structurelle. ToutSGBDO offre aux concepteurs des mod`eles de donn´ees des constructeurs de structures et collections complexes : n-uplet,
ensemble, multi-ensemble, liste. Le constructeur de n-uplet (tuple) cr´ee une structure compos´ee d’une suite d’attributs. `A chaque attribut est associ´e un domaine de d´efinition qui peut ˆetre (si la distinction classe/type existe) un type ou une classe pr´ed´efinis (entier, r´eel, bool´een, etc.), un type construit ou une classe. Les constructeurs ensemble (set), multi-ensemble (bag), liste (list), tableau (array) cr´eent des structures r´esultant de leur application sur un domaine (mˆeme sens que pr´ec´edemment) (cf. les d´eclarations de classes de la figure 5.1). Ils permettent la d´efinition naturelle de classes((collections))
polymorphes.
La classe Equipe enseignante(FIG. 5.8) est polymorphique au sens o `u son extension pourra regrouper des instances de la classeEnseignantet de la classeAter.
Tout constructeur peut ˆetre appliqu´e `a tout domaine y compris ceux qui sont d´efinis par d’autres constructeurs (cf. la classe Equipe enseignante) o `u
setest appliqu´e au type de la classeEnseignant). Ceci n’´etait pas possible dans le mod`ele relationnel ou le constructeurrelationne s’applique qu’`a la structure cr´e´ee par le constructeurn-uplet.
• Une partie comportementale. Les op´erations ou m´ethodes auxquelles les
ob-jets pourront ˆetre soumis lors de l’invocation de messages sont d´efinies au niveau des classes comme dans un langage de classes ordinaire. Leur sp´ecifi-cation est donn´ee sous forme d’une signature pr´ecisant le nom de l’op´eration (m´ethode) et la liste des divers arguments ( FIG. 5.4). Le code d’impl´ementa-tion des m´ethodes peut ˆetre directement attach´e `a la descripd’impl´ementa-tion de la classe ou d´efini ind´ependamment de la partie sp´ecification.
L’op´erationLire nomde la figure 5.9 est une op´eration accesseur permettant `a une instance de la classePersonned’acc´eder `a son attributnom.
Enfin pour conclure, dans le cadre desSGBDO, l’ensemble des classes (compl´et´e ´eventuellement d’un ensemble de types) relatif au domaine du monde r´eel repr´esent´e constitue la notion de sch´ema conceptuel de base de donn´ees. Ce sch´ema est conserv´e dans la base : selon les syst`emes, la partie comportementale (m´ethodes des classes) est sauvegard´ee avec le sch´ema, donc persiste dans la base, ou bien est((attach´ee))
uniquement aux applications qui l’utilisent.
Comme dans les LPO, l’approche objet dans le contexte des bases de donn´ees supprime la dichotomie programmes/donn´ees puisque l’objet les regroupe dans une
mˆeme entit´e. L’utilisateur final ne doit plus connaˆıtre la structure de donn´ees puis-qu’il ne manipule l’objet que par l’interm´ediaire des m´ethodes qui constituent son interface (encapsulation).
Ce principe d’encapsulation r´epond `a des objectifs pr´ecis en phase de d´evelop-pement (simplification, r´eutilisation) (cf.chapitres 1, 3 et 8). LesSGBDO, comme les syst`emes de repr´esentation de connaissances, n’appliquent pas tous strictement l’encapsulation (cf.chapitre 10) ; la probl´ematique des bases de donn´ees reste tout de mˆeme de((donner acc`es aux donn´ees le plus ais´ement possible)). L’encapsulation stricte semble alors ˆetre contraire aux n´ecessit´es desLMDd´eclaratifs de type SQL. On trouve donc, selon les syst`emes, la d´efinition de divers niveaux d’encapsulation :
• soit l’encapsulation est stricte et tout acc`es (lecture/´ecriture) aux donn´ees d’un objet se fait par appel d’une m´ethode de la classe de l’objet concern´e (c’est un des garants de la r´eutilisation),
• soit l’encapsulation est r´eserv´ee aux ´ecritures, les acc`es en lecture peuvent ˆetre faits directement,
• soit l’encapsulation est partielle : la structure des classes comporte deux par-ties, l’une visible (publique) et l’autre priv´ee (accessible uniquement par l’ap-pel de m´ethodes)(cf.chapitres 2 et 3).
La notion d’encapsulation, dans les SGBDO, peut ˆetre ´etendue au niveau du sch´ema. Certains syst`emes offrent la possibilit´e aux concepteurs d’encapsuler les sch´emas qu’ils d´efinissent. L’objectif est toujours la r´eutilisation. La sp´ecification d’un sch´ema comporte donc la d´efinition de classes exportables vers d’autres sch´emas [Collet et Adiba, 1993]. En fait nous retrouvons ici l’id´ee de biblioth`eque de classes partageables d´ej`a pr´esente dans les LPO (cf.chapitre 2).
Composition et agr´egation
Au sein d’un sch´ema de base de donn´ees, les classes sont impliqu´ees dans plusieurs types d’associations qui peuvent se sp´ecialiser conceptuellement et sont d´esign´ees sous les termes de relation de composition et de relation de
g´en´eralisa-tion/sp´ecialisation.
La terminologie dans le domaine des objets (objets complexes, objets compo-sites, r´ef´erence, composition, agr´egation) est assez vari´ee, non unifi´ee et n´ecessite quelques explications compl´ementaires. La conception d’un objet du monde r´eel consiste `a d´ecrire les diverses propri´et´es (attributs ou champs) de l’objet. Nous avions d´ej`a not´e, que le terme objet complexe est apparu d`es que les attributs ou champs d’un objet n’´etaient plus contraints `a ˆetre de type atomique. Dans le sch´ema de la figure 5.4, la classePersonned´efinit la structure g´en´erale d’objets complexes que seront ses instances.
Les attributs d’un objet peuvent r´ef´erencer d’autres objets ind´ependants : on peut parler alors de relations de d´ependance((faible))entre objets s’il n’y a pas de con-traintes sp´ecifiques d´efinies entre eux. Dans la figure 5.4, la classeEtudiantd´efinit la structure d’objets complexes r´ef´erenc¸ant un ensemble d’instances de la classe
Class Voiture
tuple (num im : string, moteur : Moteur, roues : set (Roue)) End Voiture
FIG. 5.10: Classe composite
Class Personne tuple (nom: string,
...,
voiture : Voiture)) End Personne
FIG. 5.11: Autre classe composite On peut aussi explicitement introduire la notion d’agr´egation groupant des ob-jets composants pour en faire un objet composite. L’objet composite est alors perc¸u comme une entit´e de niveau sup´erieur construite avec des entit´es composantes (hi´erarchie construite avec la relation partie-de).
La classeVoiturede la figure 5.10 illustre la structure g´en´erale d’objets com-posites. Les classes Moteur et Rouesont des classes composantes de la classe
Voiture. Le concepteur, par l’agr´egation, veut que les objets instances de la classe
Voituresoient perc¸us diff´eremment de tas de pi`eces d´etach´ees correspondant `a leurs composantes, instances des classesMoteuretRoue.
Pr´ec´edemment, la classeEquipe enseignantede la figure 5.8 d´efinissait aussi une structure particuli`ere d’objets composites :Enseignantest la classe composant de la classeEquipe enseignante.
Autour de la notion d’objets composites, les mod`eles proposent diff´erentes va-riantes de s´emantiques li´ees `a des r`egles de gestion ou `a des contraintes d’int´egrit´e :
• Un objet composant peut ˆetre ou non partag´e entre plusieurs objets de la mˆeme classe.
La classeVoiturede la figure 5.11 est une classe d’objets composants pour la classePersonne. Le concepteur peut choisir si cette classe constitue ou non un composant partageable, c’est-`a-dire si l’application vis´ee utilise la r`egle de gestion((toute personne peut utiliser une voiture qui peut aussi ˆetre utilis´ee par d’autres personnes))ou si, au contraire((toute personne dispose d’une voiture qui lui est propre)).
• Un objet composant peut ˆetre existentiellement d´ependant ou non de l’objet
composite. Nous retrouvons ici la notion d’int´egrit´e r´ef´erentielle des bases