Chap II

Bases de données orientées objets
Chapitre II: Concept du modèle

objet et principaux apports
ON PARLERA DE:
II. Concepts du modèle objet et principaux apports :
II.1) Identité
II.2) Structure complexe
II.3) Méthodes et encapsulation
II.4) Hiérarchie de généralisation / spécialisation
II.5) Population et persistance
II.6) Polymorphisme
INTRODUCTION AU MODÈLE OBJET
❖ Il y a eu plusieurs tentatives pour créer des SGBDs orientés

objet, on peut citer:
Prototypes Systèmes commerciaux
Orion développé au MCC GemStone Object Server de
GemStone Systems
OpenOODB à Texas Instruments ONTOS DB d'Ontos
Iris des laboratoires Hewlett- Objectivity/DB d'Objectivity Inc
Packard
ENCORE/ObServer de Versant Object Database et
l'Université de Brown FastObjects de Versant corporation
(et Poet)
Ode d'AT&T Bell Labs ObjectStore d'Object Design
Ardent Database de Ardent
❖ Une base de données OO peut étendre l'existence des objets

afin qu'ils soient stockés de façon permanente dans une base
de données, et donc les objets deviennent des objets
persistants qui existent au-delà de la fin du programme et
peuvent être récupérés plus tard et partagés par d'autres
programmes.
❖ Cela nécessite l'incorporation d'autres caractéristiques bien
connues des systèmes de gestion de bases de données, telles
que des mécanismes d'indexation pour localiser efficacement
les objets, le contrôle de la concurrence pour permettre le
partage d'objets entre des programmes simultanés, et la
récupération en cas de défaillance.
❖ Nous allons décrire les concepts clés utilisés dans de

nombreux systèmes de bases de données objet et qui ont été
incorporés par la suite dans les systèmes objet-relationnels et
le standard SQL.
❖ Il s'agit notamment de l'identité des objets, de la structure des
objets et des constructeurs de types, de l'encapsulation des
opérations et de la définition des méthodes dans le cadre des
déclarations de classes, les mécanismes de stockage des
objets dans une base de données en les rendant persistants,
les hiérarchies de types et de classes et l'héritage.
CONCEPTS DES BASES DE DONNÉES ORIENTÉES
OBJET: IDENTITÉ D’OBJET
❖ L'un des objectifs d'une BDO est de maintenir une correspondance

directe entre les objets du monde réel réel et les objets de la base
de données afin que les objets ne perdent pas leur intégrité et leur
identité et qu'ils puissent être facilement identifiés et exploités.
❖ Ainsi, une identité unique est attribuée à chaque objet indépendant
stocké dans la base de données.
❖ Cette identité unique est généralement mise en œuvre par le biais
d'un identifiant d'objet (OID) unique, généré par le système.
❖ La valeur d'un OID peut ne pas être visible pour l'utilisateur externe
mais elle est utilisée en interne par le système pour identifier chaque
objet de manière unique et pour créer et gérer les relations entre les
objets.
Propriétés d’un OID

❖ L'OID doit être immuable, c'est-à-dire que la valeur de l'OID d'un
objet particulier ne doit pas changer. Cela permet de préserver
l'identité de l'objet du monde réel représenté.
❖ Il ne doit être utilisé qu'une seule fois ; autrement dit, même si un
objet est supprimé de la base de données, son OID ne doit pas être
attribué à un autre objet..
❖ Ces deux propriétés impliquent que l'OID ne doit dépendre d'aucune
valeur d'attribut de l'objet, puisque la valeur d'un attribut peut être
modifiée ou corrigée.

❖ Nous pouvons comparer cela avec le modèle relationnel, où
chaque relation doit avoir un attribut de clé primaire dont la
valeur identifie chaque tuple de manière unique.
❖ Si la valeur de la clé primaire est modifiée, le tuple aura une
nouvelle identité, même s'il représente toujours le même objet du
monde réel. Par ailleurs, un objet du monde réel peut avoir des
noms différents pour les attributs clés dans différentes relations,
ce qui rend difficile de s'assurer que les clés représentent le
même objet du monde réel (par exemple, en utilisant l'Emp_id
d'un EMPLOYÉ dans une relation et le Ssn dans une autre).
❖ Il est également inapproprié de baser l'OID sur l'adresse physique
de l'objet dans le stockage, puisque l'adresse physique peut changer
après une réorganisation physique de la base de données.
OBJET: IDENTITÉ D’OBJET //

❖ Certains SGBD l’ont fait et ils placent des pointeurs dans l’ancienne adresse pour ramener vers la
nouvelle.
❖ Il est plus courant d'utiliser des entiers longs comme OIDs puis d'utiliser une forme de table de
hachage pour faire correspondre la valeur de l'OID à l'adresse physique actuelle de l'objet stocké.
❖ Certains des premiers modèles de données OO exigeaient que tout - d'une simple valeur à un objet
complexe - soit représenté comme un objet. Ainsi, chaque valeur de base, telle qu'une valeur de
nombre entier, une chaîne de caractères ou une valeur booléenne, possède un OID. Cela permet à
deux valeurs de base identiques d'avoir des OID différents, ce qui peut être utile dans certains cas.
Par exemple, la valeur entière 50 peut parfois être utilisée pour désigner un poids en kilogrammes et
parfois pour désigner l'âge d'une personne. On pourrait alors créer deux objets de base avec des
OID distincts, mais les deux objets auraient pour valeur 50. Bien qu'utile en tant que modèle
théorique, ce n'est pas très pratique, car cela conduit à la génération d'un trop grand nombre d'OIDs.
C'est pourquoi la plupart des ODB permettent de représenter à la fois des objets et des littéraux.
❖ Chaque objet doit avoir un OID immuable, alors qu'une valeur littérale (un entier, une chaîne de
caractères ou une valeur booléenne) n'a pas d'OID et sa valeur se suffit à elle-même. Ainsi, une
valeur littérale est généralement stockée dans un objet et ne peut être référencée à partir d'autres
objets. Dans de nombreux systèmes, des valeurs littérales structurées complexes peuvent
également être créées sans avoir d'OID correspondant si nécessaire.
OBJET: STRUCTURES COMPLEXES
❖ Objectif : représentation directe des objets du monde réel
❖ Monde réel : Personne
nom
prénoms
adresse (rue, n°, ville, codeNPA)
enfants (prénoms, sexe, dateNais)
❖ En relationnel : 4 relations, N tuples
Personne (n°, nom, adresse_rue, adresse_n°,
adresse_ville, adresse_codeNPA)
Personne_prénom (n°P, n°prénom, prénom)
Personne_enfant (n°P, n°enfant, sexe, dateNais)
Person_enfant_prénom (n°P, n°enfant, n°prénom, prénom)
❖ Dans les systèmes de bases de données traditionnels, les

informations relatives à un objet complexe sont souvent dispersées
dans un grand nombre de relations ou d'enregistrements, ce qui
entraîne une perte de correspondance directe entre un objet du
monde réel et sa représentation dans la base de données.
❖ Dans les BDO, un type complexe peut être construit à partir d'autres
types par imbrication de constructeurs de types. Les trois
constructeurs les plus basiques sont atom, struct (ou tuple), et
collection.
Atom:
❖ Un constructeur de type a été appelé le constructeur d'atomes, bien
que ce terme ne soit pas utilisé dans la dernière norme objet. Cela
inclut les types de données de base intégrés au modèle objet, qui
sont similaires aux types de base de nombreux langages de
programmation : entiers, chaînes de caractères, nombres à virgule
flottante, types énumérés, booléens, et ainsi de suite. Ces types de
données de base sont appelés types à valeur unique ou atomiques,
car chaque valeur du type est considérée comme une valeur unique
atomique (indivisible).
Struct:
❖ Un deuxième constructeur de type est appelé le constructeur struct (ou
tuple). Il permet de créer des types structurés standard, tels que les tuples
(types d'enregistrements) dans le modèle relationnel de base.
❖ Un type structuré est constitué de plusieurs composants et est aussi
parfois appelé type composé ou composite.
❖ Plus précisément, le constructeur struct n'est pas considéré comme un
type, mais plutôt comme un générateur de types, car de nombreux types
structurés différents peuvent être créés.
❖ Par exemple, deux types structurés différents peuvent être créés : struct
Name<FirstName : string, MiddleInitial : char, LastName : string>, et struct
CollegeDegree<Major : string, Degree : string, Year : date>.
❖ Remarquez que les constructeurs de type atom et struct sont les seuls
disponibles dans le modèle relationnel original (de base).
Collection:
❖ Les constructeurs de type collection (ou multivalué) comprennent les
constructeurs de type: set(T), list(T), bag(T), array(T) et dictionary(K,T).
❖ Ils permettent à une partie d'un objet ou d'une valeur littérale d'inclure une
collection d'autres objets ou valeurs si nécessaire.
❖ Ces constructeurs sont également considérés comme des générateurs de
types car de nombreux types différents peuvent être créés. Par exemple,
set(string), set(integer) et set(Employee) sont trois types différents qui
peuvent être créés à partir du constructeur de type set.
❖ Tous les éléments d'une valeur de collection particulière doivent être du
même type. Par exemple, toutes les valeurs d'une collection de type
set(string) doivent être des valeurs de type chaîne de caractères.
Collection:
❖ Le constructeur set crée des objets ou des littéraux qui sont un ensemble
d'éléments distincts {i1, i2, ... , in}, tous du même type. (K,T).
❖ Le constructeur bag (également appelé multiset) est similaire à un ensemble,
sauf que les éléments d’un bag ne doivent pas nécessairement être distincts.
❖ Le constructeur list crée une liste ordonnée [i1, i2, ... , in] d'OIDs ou de valeurs
du même type. Une list est similaire à un bag, sauf que les éléments d'une
liste sont ordonnés et que l'on peut donc se référer au premier, deuxième ou
jème élément.
❖ Le constructeur array crée un tableau unidimensionnel d'éléments du même
type. La principale différence entre un array et une list est qu'une list peut
contenir un nombre arbitraire d'éléments, alors qu'un array a généralement
une taille maximale.
❖ Le constructeur dictionary crée une collection de paires clé-valeur (K, V), où la
valeur d'une clé K peut être utilisée pour récupérer la valeur correspondante V
Collection:
❖ La principale caractéristique d'un type collection (ou multivalué) est que ses
objets ou valeurs seront une collection d'objets ou de valeurs du même
type qui peuvent être non ordonnés (comme set ou bag) ou ordonnés
(comme une list ou array).
❖ Le constructeur de type tuple est souvent appelé type structuré, car il
correspond à la construction struct des langages de programmation C et
C++ .
Exemple (syntaxe symplifiée de l’ODL(object definition
language) standard de l'ODMG:
define type EMPLOYEE
tuple ( Fname: string;
Minit : char;
Lname: string;
Ssn: string;
Birth_date: DATE;
Address: string;
Sex: char;
Salary: float;
Supervisor: EMPLOYEE;
Dept: DEPARTMENT);
Exemple 1 (syntaxe symplifiée de l’ODL(object definition language)
standard de l'ODMG:
define type DATE
Les attributs qui font référence à
tuple (Year: integer;
d'autres objets - tels que Dept de
Month: inteer;
EMPLOYEE ou Projects de
Day : integer;); DEPARTMENT - sont essentiellement
des OIDs qui servent de références à
define type DEPARTMENT d'autres objets pour représenter les
tuple ( Dname: string; relations entre les objets.
Dnumber: integer;
Mgr: tuple ( Manager: EMPLOYEE; Start_date: DATE; );
Locations: set(string);
Employees: set(EMPLOYEE);
Projects: set(PROJECT); );
OBJET: ENCAPSULATION
❖ La notion d'encapsulation est l'une des principales caractéristiques des

langages et systèmes OO. Il est également lié aux concepts de types de
données abstraits et de masquage de l'information dans les langages de
programmation. Dans les modèles et systèmes de base de données
traditionnels, ce concept n'était pas appliqué, car il est d'usage de rendre la
structure des objets de la base de données visible aux utilisateurs et aux
programmes externes.
❖ Par exemple, dans le modèle relationnel, les opérations de sélection,
d'insertion, de suppression et de modification des tuples sont génériques et
peuvent être appliquées à n'importe quelle relation de la base de données.
❖ La relation et ses attributs sont visibles aux utilisateurs et aux programmes
externes qui accèdent à la relation en utilisant ces opérations.
❖ Certaines opérations peuvent être utilisées pour créer (insert) ou détruire
(delete) des objets ; d'autres opérations peuvent mettre à jour l'état de
l'objet ; d'autres encore peuvent être utilisées pour récupérer des parties
de l'état de l'objet ou pour appliquer certains calculs.
❖ D'autres opérations encore peuvent effectuer une combinaison de
récupération, de calcul et de mise à jour. En général, la mise en œuvre
d'une opération peut être spécifiée dans un langage de programmation
polyvalent qui offre souplesse et puissance dans la définition des
opérations.
❖ Les utilisateurs externes de l'objet n'ont connaissance que de l'interface
des opérations, qui définit le nom et les arguments (paramètres) de
chaque opération. L'implémentation est cachée aux utilisateurs externes ;
elle comprend la définition de toutes les structures de données internes
cachées de l'objet et l'implémentation des opérations qui accèdent à ces
structures.
❖ La partie interface d'une opération est parfois appelée signature, et
l'implémentation de l'opération est parfois appelée méthode.
❖ Pour les applications de base de données, l'exigence selon laquelle tous
les objets doivent être complètement encapsulés est trop stricte.
❖ Une façon d'assouplir cette exigence est de diviser la structure d'un objet
en attributs visibles et cachés (variables d'instance).
❖ Les attributs visibles peuvent être vus par les utilisateurs et les
programmeurs de la base de données et leur sont directement accessibles
via le langage d'interrogation.
❖ Les attributs cachés d'un objet sont complètement encapsulés et ne sont
accessibles que par des opérations prédéfinies.
❖ La plupart des SGBOs utilisent des langages d'interrogation de haut niveau
pour accéder aux attributs visibles.
❖ Nous décrirons plus tard le langage d'interrogation OQL qui est proposé
comme langage d'interrogation standard pour les DBO
❖ Le terme class est souvent utilisé pour faire référence à une définition de type,
ainsi qu'aux définitions des opérations pour ce type.
❖ L’exemple 2 montre comment les définitions de type de l’exemple 1 peuvent
être étendues avec des opérations pour définir des classes.
❖ Un certain nombre d'opérations sont déclarées pour chaque classe, et la
signature (interface) de chaque opération est incluse dans la définition de la
classe.
❖ Une méthode (implémentation) pour chaque opération doit être définie
ailleurs à l'aide d'un langage de programmation.
❖ Les opérations typiques incluent l'opération du constructeur d'objet (souvent
appelée new), qui est utilisée pour créer un nouvel objet, et le destructeur de
l'objet, qui sert à détruire (delete) un objet.
❖ Un certain nombre d'opérations de modification d'objet peuvent également
être déclarées pour modifier les états (valeurs) de divers attributs d'un objet.
❖ Des opérations supplémentaires permettent de récupérer des informations sur
l'objet.
define class EMPLOYEE
type tuple (Fname : string; Exemple 2 :

Minit : char;
Lname : string;
Birth_date: DATE;
Address: string;
Sex: char;
Salary: float;
Supervisor: EMPLOYEE;
Dept: DEPARTMENT; );
operations age : integer;
create_emp: EMPLOYEE;
destroy_emp: boolean;
end EMPLOYEE;
define class DEPARTMENT
Exemple 2 :
type tuple (Dname : string;
Dnumber : integer;
Mgr : tuple ( Manager: EMPLOYEE;
Start_date: DATE; );
Locations: set(string);
Employees: set (EMPLOYEE);
Projects : set(PROJECT); );
operations no_of_emps : integer;
create_dept: DEPARTMENT;
destroy_dept: boolean;
assign_emp(e: EMPLOYEE): boolean; (* adds an employee to the department *)
remove_emp(e: EMPLOYEE): boolean; (* removes an employee from the department *)
end DEPARTMENT;
❖ Une opération est généralement appliquée à un objet en utilisant la notation

pointée.
❖ Par exemple, si d est une référence à un objet DEPARTMENT, nous pouvons
invoquer une opération telle que no_of_emps en écrivant d.no_of_emps.
❖ De même, en écrivant d.destroy_dept, l'objet référencé par d est détruit
(supprimé).
❖ La seule exception est l'opération constructeur, qui renvoie une référence à
un nouvel objet DEPARTMENT. Il est donc habituel dans certains modèles OO
d'avoir un nom par défaut pour l'opération du constructeur qui est le nom de la
classe elle-même, bien que cela n'ait pas été utilisé dans l’exemple 2. (Des noms
par défaut pour les opérations de constructeur et de destructeur existent dans le langage de
programmation C++. Par exemple, pour la classe EMPLOYEE, le nom du constructeur par
défaut est EMPLOYEE et le nom du destructeur par défaut est ~EMPLOYEE. Il est également
courant d'utiliser l'opération new pour créer de nouveaux objets.)
❖ La notation pointée est également utilisée pour faire référence aux attributs
d'un objet - par exemple, en écrivant d.Dnumber ou d.Mgr_Start_date.
OBJET: PERSISTANCE
❖ Un SGBDOO est souvent étroitement associé à un langage de

programmation orienté objet LPOO.
❖ Le LPOO est utilisé pour spécifier les implémentations des méthodes
(opérations) ainsi que d'autres codes d'application.
❖ Tous les objets ne sont pas destinés à être stockés de façon permanente
dans la base de données.
❖ Les objets transitoires existent dans le programme en cours d'exécution et
disparaissent une fois le programme terminé.
❖ Les objets persistants sont stockés dans la base de données et persistent
après la fin du programme. Les mécanismes typiques pour rendre un objet
persistant sont le nommage et l'accessibilité.
OBJET: PERSISTANCE Exemple 3 :
6
OBJET: PERSISTANCE
❖ Notez la différence entre les modèles de base de données traditionnels et
les DBOOs à cet égard: Dans les modèles de base de données
traditionnels, tels que le modèle relationnel, tous les objets sont supposés
être persistants.
❖ Par conséquent, lorsqu'une table telle que EMPLOYEE est créée dans une
base de données relationnelle, elle représente à la fois la déclaration de type
pour EMPLOYEE et un ensemble persistant de tous les enregistrements
EMPLOYEE (tuples).
❖ Dans l'approche OO, une déclaration de classe de EMPLOYÉ spécifie
uniquement le type et les opérations d'une classe d'objets.
❖ L'utilisateur doit définir séparément un objet persistant de type
set(EMPLOYEE) dont la valeur est la collection de références (OID) à tous
les objets persistants EMPLOYEE, si cela est souhaité, voir exemple3.
❖ Cela permet aux objets transitoires et persistants de suivre les mêmes
règles que les déclarations de type et de classe de l'ODL et du LPOO. En
général, il est possible de définir plusieurs collections persistantes pour la
même définition de classe, si on le souhaite.
OBJET: HIÉRARCHIE ET HÉRITAGE
❖ Notez la différence entre les modèles de base de données traditionnels
et les DBOOs à cet égard: Dans les modèles de base de données
traditionnels, tels que le modèle relationnel, tous les objets sont supposés
être persistants.
❖ Par conséquent, lorsqu'une table telle que EMPLOYEE est créée dans une
base de données relationnelle, elle représente à la fois la déclaration de
type pour EMPLOYEE et un ensemble persistant de tous les
enregistrements EMPLOYEE (tuples).
❖ Dans l'approche OO, une déclaration de classe de EMPLOYÉ spécifie
uniquement le type et les opérations d'une classe d'objets.
❖ L'utilisateur doit définir séparément un objet persistant de type
set(EMPLOYEE) dont la valeur est la collection de références (OID) à tous
les objets persistants EMPLOYEE, si cela est souhaité, voir exemple3.
❖ Cela permet aux objets transitoires et persistants de suivre les mêmes
règles que les déclarations de type et de classe de l'ODL et du LPOO. En
général, il est possible de définir plusieurs collections persistantes pour la
même définition de classe, si on le souhaite.
OBJET: PERSISTANCE
❖ Le mécanisme de nommage consiste à donner à un objet un nom

persistant unique au sein d'une base de données particulière. Ce nom
d'objet persistant peut être donné par une instruction ou une opération
spécifique du programme, comme le montre l’exemple 3.
❖ Les objets persistants nommés sont utilisés comme points d'entrée dans
la base de données par lesquels les utilisateurs et les applications peuvent
commencer leur accès à la base de données.
❖ Il est évident qu'il n'est pas pratique de donner des noms à tous les objets
d'une grande base de données comprenant des milliers d'objets, c'est
pourquoi la plupart des objets sont rendus persistants en utilisant le
deuxième mécanisme, appelé accessibilité.
❖ Le mécanisme d'accessibilité fonctionne en rendant l'objet accessible à
partir d'un autre objet persistant. Un objet B est dit accessible à partir d'un
objet A si une séquence de références dans la base de données mène de
l'objet A à l'objet B..
OBJET: PERSISTANCE
❖ Si nous créons d'abord un objet persistant nommé N, dont l'état est un

ensemble d'objets d'une certaine classe C, nous pouvons rendre les objets
de C persistants en les ajoutant à l'ensemble, ce qui les rend accessibles
depuis N. Ainsi, N est un objet nommé qui définit une collection
persistante d'objets de la classe C. Dans la norme du modèle objet, N est
appelé l'extension de C.
❖ Par exemple, nous pouvons définir une classe DEPARTMENT_SET (voir
Exemple 3) dont les objets sont de type set(DEPARTMENT). Nous
pouvons créer un objet de type DEPARTMENT_SET, et lui donner un nom
persistant ALL_DEPARTMENTS, comme illustré dans l’exemple 3. Tout
objet DEPARTMENT qui est ajouté à l'ensemble ALL_DEPARTMENTS en
utilisant l'opération add_dept devient persistant du fait qu'il est accessible
depuis ALL_DEPARTMENTS.
❖ La norme ODL de l'ODMG donne au concepteur du schéma la possibilité
de nommer un extent dans le cadre de la définition de la classe.
OBJET: TYPES DE HIÉRARCHIE ET HÉRITAGE
Modèle simplifié pour l'héritage:

❖ Une autre caractéristique principale des BDOs est qu'ils permettent les
hiérarchies de types et l'héritage.
❖ Nous utilisons un modèle OO simple dans cette section - un modèle dans
lequel les attributs et les opérations sont traités uniformément - puisque les
attributs et les opérations peuvent être hérités.
❖ Dans le chapitre suivant, nous discuterons du modèle d'héritage de la
norme ODMG.
❖ L'héritage permet de définir de nouveaux types basés sur d'autres types
prédéfinis, ce qui conduit à une hiérarchie de types (ou de classes).
Pour simplifier:
❖ Nous utilisons le terme function pour désigner à la fois les attributs et les
opérations, car ils sont traités de manière similaire dans une introduction de
base à l'héritage.
❖ Dans sa forme la plus simple, un type comporte un nom de type et une liste
de functions visibles (public).
❖ Lorsque nous spécifions un type dans cette section, nous utilisons le format
suivant, qui ne spécifie pas les arguments des functions, pour simplifier la
discussion: TYPE_NAME: function, function, … , function
❖ Par exemple, un type qui décrit les caractéristiques d'une PERSONNE peut
être défini comme suit : PERSON: Name, Address, Birth_date, Age, Ssn
Atribute Operation
❖ Le concept de sous-type (subtype) est utile lorsque le concepteur ou

l'utilisateur doit créer un nouveau type qui similaire mais non identique à un
type déjà défini. Le sous-type hérite alors de toutes les functions du type
prédéfini, que l'on appelle le supertype. Par exemple, supposons que nous
voulions définir deux nouveaux types EMPLOYÉ et ÉTUDIANT comme suit:
EMPLOYEE: Name, Address, Birth_date, Age, Ssn, Salary, Hire_date, Seniority
STUDENT: Name, Address, Birth_date, Age, Ssn, Major, Gpa
❖ Puisque STUDENT et EMPLOYEE comprennent toutes les functions

définies pour PERSON plus quelques functions supplémentaires qui leur
sont propres, nous pouvons les déclarer comme étant des sous-types de
PERSON
❖ Uniquement les functions spécifiques comme Seniority ou Major doivent
être définies
Grade ponit average: score pour indiquer la

moyenne de vos résultats Ancienneté
❖ Par conséquent, nous pouvons déclarer STUDENT et EMPLOYEE comme

suit :
EMPLOYEE subtype-of PERSON: Salary, Hire_date, Seniority
STUDENT subtype-of PERSON: Major, Gpa
❖ Prenons un autre exemple, celui d'un type qui décrit des objets en
géométrie plane : GEOMETRY_OBJECT: Shape, Area, Reference_point
❖ On veut définir les sous-types:
❖ RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height
❖ TRIANGLE S subtype-of GEOMETRY_OBJECT: Side1, Side2, Angle
❖ CIRCLE subtype-of GEOMETRY_OBJECT: Radius spécifie les coordonnées

d'un point qui détermine
l'emplacement de l'objet
Type énuméré qui prend les valeurs: ‘triangle’, Method
‘rectangle’, ‘circle’…
❖ Notez que l'opération Area peut être mise en œuvre par une méthode
différente pour chaque sous-type, puisque la procédure de calcul de l'aire
est différente pour les rectangles, les triangles et les cercles.
❖ De même, l'attribut Reference_point peut avoir une signification différente
pour chaque sous-type ; il peut s'agir du point central pour les objets
RECTANGLE et CIRCLE et le point de sommet entre les deux côtés
donnés pour un objet TRIANGLE.
❖ Notez que les définitions de type décrivent des objets mais ne génèrent
pas d'objets par elles-mêmes.
❖ Lorsqu'un objet est créé, il appartient généralement à un ou plusieurs de
ces types qui ont été déclarés. Par exemple, un objet cercle est du type
CIRCLE et GEOMETRY_OBJECT (par héritage).
❖ Chaque objet devient également membre d'une ou plusieurs collections
persistantes d'objets (ou extents), qui sont utilisées pour regrouper des
collections d'objets qui sont stockées de manière persistante dans la base
de données.
Contraintes sur les extents correspondant à une hiérarchie de type:
❖ Dans la plupart des BDOs, un extent est défini pour stocker la collection
d'objets persistants pour chaque type ou sous-type.
❖ Dans ce cas, la contrainte est que chaque objet d'un extent qui correspond
à un sous-type doit également être membre de l'extent qui correspond à
son supertype.
❖ Certains systèmes de bases de données OO ont un type de système
prédéfini (appelé classe ROOT ou OBJECT CLASS) dont l'extent contient
tous les objets du système.
❖ Nous verrons que dans le modèle ODMG, l'utilisateur peut ou non spécifier
un extent pour chaque classe (type), en fonction de l'application.
❖ Le modèle ODMG fait la distinction entre l'héritage de type, appelé
héritage d'interface et désigné par deux points ( :), et l'héritage d’extent,
une contrainte désignée par le mot-clé EXTEND.
Héritage multiple et héritage sélectif :
❖ L'héritage multiple se produit lorsqu'un certain sous-type T est un sous-
type de deux types (ou plus) et hérite donc des functions (attributs et
méthodes) des deux supertypes.
❖ Par exemple, nous pouvons créer un sous-type
ENGINEERING_MANAGER qui est un sous-type à la fois de MANAGER
et de ENGINEER.
❖ On aura un treillis de types plutôt que d'une hiérarchie de types.
❖ Un problème qui peut survenir avec l'héritage multiple est que les
supertypes dont le sous-type hérite peuvent avoir des functions distinctes
du même nom, ce qui crée une ambiguïté
Héritage multiple et héritage sélectif : L'héritage multiple

❖ Par exemple, MANAGER et ENGINEER peuvent tous deux avoir une
function appelée Salary. Si la fonction Salary est implémentée par des
méthodes différentes dans les sous-types MANAGER et ENGINEER, il
existe une ambiguïté quant à savoir lequel des deux est hérité par le sous-
type ENGINEERING_MANAGER.
❖ Il est toutefois possible que ENGINEER et MANAGER héritent tous les
deux de Salary du même super-type (tel que EMPLOYEE) situé plus haut
dans le treillis. La règle générale est que si une function est héritée
d'un supertype commun, elle n'est héritée qu'une seule fois.
❖ Dans ce cas, il n'y a aucune ambiguïté; Le problème ne se pose que si les
functions sont distinctes dans les deux supertypes.
Héritage multiple et héritage sélectif : L'héritage multiple

❖ Il existe plusieurs techniques pour traiter l'ambiguïté dans l'héritage
multiple:
1. Une solution consiste à demander au système de vérifier l'ambiguïté
lors de la création du sous-type et de laisser l'utilisateur choisir
explicitement la function à hériter à ce moment-là.
2. Une deuxième solution consiste à utiliser une valeur par défaut du
système.
3. Une troisième solution consiste à interdire complètement l'héritage
multiple en cas d'ambiguïté de nom, en obligeant l'utilisateur à changer
le nom d'une des functions dans l'un des supertypes. En fait, certains
systèmes OO ne permettent pas du tout l'héritage multiple. Dans la
norme ODMG, l'héritage multiple est autorisé pour l'héritage
d'opération des interfaces, mais il n'est pas autorisé pour l'héritage
EXTENDS des classes..
Héritage multiple et héritage sélectif : L'héritage sélectif

❖ Il se produit lorsqu'un sous-type n'hérite que de certaines des functions
d'un supertype. D'autres fonctions ne sont pas héritées.
❖ Dans ce cas, une clause EXCEPT peut être utilisée pour énumérer les
fonctions d'un super-type qui ne doivent pas être héritées par le sous-type.
❖ Le mécanisme d'héritage sélectif n'est généralement pas fourni dans les
bases de données BDO, mais il est utilisé plus fréquemment dans les
applications d'intelligence artificielle.
OBJET: POLYMORPHISME DES OPÉRATIONS
(SURCHARGE DES OPÉRATEURS)
❖ Une autre caractéristique des systèmes OO en général est qu'ils prévoient

le polymorphisme des opérations, qui est également connu sous le nom
de surcharge d'opérateurs.
❖ Ce concept permet au même nom ou symbole d'opérateur d'être lié à deux
ou plusieurs implémentations différentes de l'opérateur, selon le type
d'objets auxquels l'opérateur est appliqué.
❖ Un exemple simple tiré des langages de programmation peut illustrer ce
concept. Dans certains langages, le symbole d'opérateur "+" peut avoir une
signification différente lorsqu'il est appliqué à des opérandes (objets) de
types différents. Si les opérandes de "+" sont de type entier, l'opération
invoquée est une addition d'entiers. Si les opérandes de "+" sont de type
virgule flottante, l'opération invoquée est l'addition de virgules flottantes.
Si les opérandes de "+" sont de type set, l'opération invoquée est l'union
de set. Le compilateur peut déterminer l'opération à exécuter en fonction
des types d'opérandes fournis..
OBJET: POLYMORPHISME DES OPÉRATIONS
(SURCHARGE DES OPÉRATEURS)
❖ Pour les BDOs, on peut donner l’exemple de GEOMETRY_OBJECT et la

méthode Area.
❖ Le SGDBO doit sélectionner la méthode appropriée pour la fonction Area
en fonction du type d'objet géométrique auquel elle est appliquée.
❖ Dans les systèmes fortement typés, cela peut être fait au moment de la
compilation, puisque les types d'objets doivent être connus. On parle alors
de liaison précoce (ou statique). Cependant, dans les systèmes à typage
faible ou inexistant (comme Smalltalk, LISP, PHP et la plupart des langages
de script), le type de l'objet auquel une fonction est appliquée peut ne pas
être connu avant l'exécution. Dans ce cas, la fonction doit vérifier le type de
l'objet au moment de l'exécution, puis invoquer la méthode appropriée.
On parle souvent de liaison tardive (ou dynamique).
❖
OBJET: PERSISTANCE
❖ Un SGBDOO est souvent étroitement associé à un langage de

programmation orienté objet LPOO.
❖ Le LPOO est utilisé pour spécifier les implémentations des méthodes
(opérations) ainsi que d'autres codes d'application.
❖ Tous les objets ne sont pas destinés à être stockés de façon permanente
dans la base de données.
❖ Les objets transitoires existent dans le programme en cours d'exécution et
disparaissent une fois le programme terminé.
❖ Les objets persistants sont stockés dans la base de données et persistent
après la fin du programme. Les mécanismes typiques pour rendre un objet
persistant sont le nommage et l'accessibilité.

Chap II

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chap II

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

Bases de données orientées objets

Chapitre II: Concept du modèle

❖ Il y a eu plusieurs tentatives pour créer des SGBDs orientés

❖ Une base de données OO peut étendre l'existence des objets

❖ Nous allons décrire les concepts clés utilisés dans de

❖ L'un des objectifs d'une BDO est de maintenir une correspondance

Propriétés d’un OID

Propriétés d’un OID

Propriétés d’un OID

❖ Dans les systèmes de bases de données traditionnels, les

tuple ( Fname: string;

❖ La notion d'encapsulation est l'une des principales caractéristiques des

type tuple (Fname : string; Exemple 2 :

operations age : integer;

Mgr : tuple ( Manager: EMPLOYEE;

Employees: set (EMPLOYEE);

operations no_of_emps : integer;

assign_emp(e: EMPLOYEE): boolean; (* adds an employee to the department *)

remove_emp(e: EMPLOYEE): boolean; (* removes an employee from the department *)

❖ Une opération est généralement appliquée à un objet en utilisant la notation

❖ Un SGBDOO est souvent étroitement associé à un langage de

❖ Le mécanisme de nommage consiste à donner à un objet un nom

❖ Si nous créons d'abord un objet persistant nommé N, dont l'état est un

Modèle simplifié pour l'héritage:

❖ Le concept de sous-type (subtype) est utile lorsque le concepteur ou

❖ Puisque STUDENT et EMPLOYEE comprennent toutes les functions

Grade ponit average: score pour indiquer la

❖ Par conséquent, nous pouvons déclarer STUDENT et EMPLOYEE comme

STUDENT subtype-of PERSON: Major, Gpa

❖ TRIANGLE S subtype-of GEOMETRY_OBJECT: Side1, Side2, Angle

❖ CIRCLE subtype-of GEOMETRY_OBJECT: Radius spécifie les coordonnées

Héritage multiple et héritage sélectif : L'héritage multiple

Héritage multiple et héritage sélectif : L'héritage multiple

Héritage multiple et héritage sélectif : L'héritage sélectif

❖ Une autre caractéristique des systèmes OO en général est qu'ils prévoient

❖ Pour les BDOs, on peut donner l’exemple de GEOMETRY_OBJECT et la

❖ Un SGBDOO est souvent étroitement associé à un langage de

Centres d'intérêt liés

Vous aimerez peut-être aussi