M30 - 1 Object-Based Models Semaine 2 Et 3

4/14/2021
M30-BASES DE DONNEES AVANCEES

2ème Année GINF
Abdelhak BOULAALAM
http://boulaalam.usmba.ac.ma/
abdelhak.boulaalam@usmba.ac.ma
A. BOULAALAM (USMBA/ENSA) BDA – BDO 1
Object Databases: Introduction

 Bref Historique des BDs OO
 Les concepts fondamentaux des caractéristiques des
objets
 Le standard ODMG : Introduction
 ODL
 OQL
1
4/14/2021
M30- Object DB
Object Databases: Introduction
 Bases de données objets (ODBs):

 terme qui fait référence aux BDs avec des fonctionnalités
d'objet.
 Historiquement, les BDs orientées objet (OODB) se sont
d'abord développées comme une approche pour ajouter
de la persistance dans les langages de programmation
orientés objet (OOPL).
 En réponse au développement des OODB:
 la communauté des bases de données relationnelles a
développé des BDs relationnelles objet (ORDB) Elles
étendent le modèle de données relationnelles avec la prise en
charge de nombreux concepts orientés objet similaires.
 le terme BDs objets fait référence aux OODB et ORDB
collectivement.
M30- Object DB
Object Databases: Introduction >> 1- Bref Historique BDO

 Nouveaux besoins et nouvelles applications
 utilisent de grandes quantités de données complexes,
 ce qui est difficile à représenter (en modèle relationnel)
 car la valeur des attributs relationnels est généralement limitée à des valeurs
atomiques simples.
 En pratique, dans les entreprises, les modèles de données conceptuels
EER et UML peuvent être mappées au modèle de données relationnel
pour représenter les données et les contraintes de l'application sous-
jacente.
 Efficacité ORD vs OODB:
 ORDB: modèle plat ... la navigation des associations ... les associations
sont par valeur = Jointures
 OODB, les associations sont intrinsèquement représentées par des
références d'objet, qui font partie intégrante du système de base de
données sous-jacent.
 Les OODB ont été développés en réponse à un besoin de gestion de
données qui ne correspondait pas à la vision traditionnelle du modèle
relationnel orientée table.
2
4/14/2021
M30- Object DB
Object Databases: Introduction >> 1- Bref Historique BDO

 milieu des années 80  Le développement des OOPL ex.
Simula et C ++
 utilisation d'objets, l'encapsulation de la structure et du
comportement des objets grâce à l'utilisation de types abstraits de
données.
 la fusion des données persistantes basées sur les objets avec les
OOPL a fourni la promesse d'un nouveau paradigme de base
de données pour la représentation efficace d'ensembles de
données volumineux et complexes
 Les OODB ne souffrent pas du problème de discordance
d'impédance:
 les types de données de base de données et de langage de
programmation sont alignés dans une vue cohérente des objets en
tant qu'instances de types de données abstraits.
 La norme Object Data Management Group
 Les fonctionnalités relationnelles objet ont été introduites pour
la première fois dans la version SQL: 1999.
M30- Object DB
Object Databases: Introduction >> 2- Concepts fondamentaux
 Un objet est un concept abstrait:

 représentant généralement une entité d'intérêt dans
l'entreprise à modéliser par une application de base
de données.
 Un objet a un état et un comportement.
 L'état d'un objet décrit la structure interne de l'objet
où la structure interne fait référence aux propriétés
descriptives de l'objet.
 Exemple Personne: En regardant une personne comme un
objet, l'état de l'objet peut contenir des informations
descriptives telles qu'un identifiant, un nom et une adresse.
3
4/14/2021
M30- Object DB

 Le comportement d'un objet est l'ensemble des méthodes
utilisées pour créer, accéder et manipuler l'objet.
 Un objet personne, par exemple, peut avoir des méthodes pour
créer l'objet, pour modifier l'état de l'objet et pour supprimer
l'objet.
 L'objet peut également avoir des méthodes pour relier l'objet à
d'autres objets, comme l'inscription d'une personne à un cours
ou l'affectation d'une personne à l'instructeur d'un cours.
 Une méthode a une signature qui décrit le nom de la méthode
et les noms et types des paramètres de la méthode.
 Les objets ayant le même état et le même comportement sont
décrits par une classe.
 Une classe définit essentiellement le type de l'objet où chaque
objet est considéré comme une instance de la classe.
 Une méthode est une implémentation spécifique d'une signature
de méthode.
M30- Object DB
 Compte tenu de cette définition fondamentale

d'un objet, les concepts orientés objet suivants
sont généralement associés à un ODB:
 objets complexes
 identité d'objet
 encapsulation
 extensibilité
 hiérarchies de classes et héritage
 overriding, surcharge et liaison tardive
4
4/14/2021
M30- Object DB
 La capacité de définir des objets complexes à partir

d'objets plus simples est une propriété importante
de l'orientation objet.
 Les objets complexes sont définis à l'aide de
constructeurs, comme un constructeur de tuple qui
combine des objets simples pour créer une forme de
haut niveau d'un objet.
 Exemple de conception technique:
 un avion peut être considéré comme un objet de niveau
supérieur construit à partir d'objets de niveau inférieur,
tels que le corps de l'avion, les ailes, la queue et le
moteur.
M30- Object DB

 Chacun de ces objets peut à son tour être des objets
complexes construits à partir d'autres objets simples ou
complexes.
 D'autres exemples de constructeurs:
 les constructeurs de collection qui définissent des ensembles,
des sacs ou des listes.
 Les ensembles sont des collections d'éléments non ordonnés sans
duplication.
 Les sacs sont des collections non ordonnées qui peuvent contenir des
éléments en double.
 Les listes sont une collection d'éléments séquencés ou ordonnés.
 Un avion, par exemple, a deux objets ailes, qui peuvent être
représentés comme un ensemble. Si les sièges à l'intérieur de
l'avion sont considérés comme des objets, une liste peut être
utilisée pour représenter la séquence ordonnée des sièges.
 Les ODB fournissent une prise en charge inhérente à la
construction d'objets complexes.
5
4/14/2021
M30- Object DB
 Exemple Personne ... 2 instances
Objet personne2
Objet personne1
M30- Object DB
 Les objets sont encapsulés:

 leurs données et méthodes forment une unité et que
l'accès aux données est restreint.
 Seules les propres méthodes de l’objet sont
autorisées à accéder aux données  en les
protégeant des modifications par du code extérieur.
 L’aspect extérieur d’un objet:
 visible du monde extérieur, est appelé son interface
et consiste en une description de l’état de l’objet et
des signatures de ses méthodes.
 Le monde extérieur interagit avec l'objet via son
interface
6
4/14/2021
M30- Object DB
 Chaque objet est encapsulé et les valeurs de ses

attributs sont accessibles au monde extérieur
uniquement via ses méthodes, telles que
getName () et setName ().
 À partir des noms de ces méthodes, nous

pouvons supposer que le programmeur qui a
conçu ces objets a écrit du code pour une
fonction ou une procédure qui renvoie la valeur
de l'attribut name (getName ())
M30- Object DB
 Un (literal) littéral diffère d'un objet en ce qu'il a un

état (valeur) mais pas d'identificateur d'objet.
 Les littéraux atomiques sont les valeurs des types
intégrés de base, mais nous pouvons également avoir
des littéraux structurés.
 En plus des types de données fondamentaux, les
systèmes orientés objet prennent en charge les types
de données définis par l'utilisateur;
 les types structurés tels que les enregistrements, les types
de collections tels que les tableaux, les ensembles et
autres; et les types de référence, qui sont similaires aux
pointeurs dans la programmation.
 De nouveaux types peuvent être créés en
incorporant des types précédemment définis.
7
4/14/2021
M30- Object DB

 Exemple de la classe Person
class Person {
attribute int ID;
attribute string name;
attribute string address;
attribute string phone;
void setName(in string newName); // method
string getName( ); //method
...
}
void setName(in string newName)

{
self.name = newName;
}
M30- Object DB
 Exemple de la classe Person (suite)

Person premierPerson;
Ou
Person premierPerson = new Person();
premierPerson.setName(‘Abdelhak');
string getName( )
{
return name;
}
string employeeName = premierPerson.getName( );
Les methodes peuvent etre surcharger (Meme

principe en C++ ou Java)
8
4/14/2021
M30- Object DB
 Exemple de la classe Person (suite)

Person premierPerson;
Ou
Person premierPerson = new Person();
premierPerson.setName(‘Abdelhak');
string getName( )
{
return name;
}
string employeeName = premierPerson.getName( );
Les methodes peuvent etre surcharger (Meme

principe en C++ ou Java)
M30- Object DB
 Hiérarchies de classe et héritage

 superclasses et de sous-classes, dans lesquelles chaque
sous-classe a une relation étendue avec sa superclasse,
également appelée sa classe de base.
 Nous pouvons interpréter la relation comme signifiant
qu'un objet de la sous-classe est un objet de la classe de
base - «un étudiant est une personne», par exemple.
 Les sous-classes héritent des membres de données, des
relations et des méthodes de leurs superclasses, et elles
peuvent avoir des membres de données, des relations
et des méthodes supplémentaires qui leur sont propres.
9
4/14/2021
M30- Object DB
Notation UML
Exemple:
MovieProfessional et
Celebrity EST UN
Person.
M30- Object DB

 Exemple d’étude
10
4/14/2021
M30- Object DB
Object Databases: Introduction >> 3- Standard ODMG
 Consortium ODMG
 Créé en 1991 par Rick Cattell (SUN, Javasoft) en tant
que sous-groupe d'OMG (Object Management
Group) avec: 02 Tech., Objectivity, Object Design,
Ontos, Versant
 OMG: UML, CORBA,…
 Plus de 50 entreprises en 2000:
 Lucent, Lockheed, CA, Microsoft, Baan, ...
 OBJECTIFS:
 Promotion des SGBD OO (Object-Oriented) ... , avant…
SQL3!
 Création d'un standard d'objet pour la portabilité des
applications
M30- Object DB
 Historique ODMG
 1ère rencontre au SUN avec Rick Catell en
septembre 91
 ODMG 1.0 (1993): 5 éditeurs
 ODL, OQL, Interface C ++, Smalltalk
 ODMG 2.0 (1996): 10 éditeurs
 (Poet, Lucent, Windward, American Man, Barry)
 Interface Java (Java Binding), Meta Model
 ODMG 3.0 (2000)

 Enrichissement de l'interface Java
 Intégration avec OMG et X3H2 (SQL3)
11
4/14/2021
M30- Object DB
 ODMG 3.0: Composants

ODL: Object OML: Object Modelling
Definition Lnaguage Language: C++, SMALLTALK et
JAVA
OQL: Object Query
Language:(SQL like)
ODL et OIF:
langages de
spécification
OIF: (object Interchange

Format) : import/export
M30- Object DB
 ODMG 3.0: « Object-value » paradigme

 CLASSE D'OBJET?
 OID pour objet (et PK pour classe)
 «VALUE» pour SET d'objets (extension)
 ATTRIBUTS
 MÉTHODES
 Pointeurs bidirectionnels entre les classes

 (REF, INVERSE)
 Manipulation: NAVIGATION entre les classes avec
POINTERS
 Héritage
12
4/14/2021
M30- Object DB

 Extension OMG
 Modèle d'objet normalisé par OMG («Tout est OBJET ")
 Modèle de données d'objet pris en charge par IDL
(Interface Definition Language))
 Les bases de données orientées objet nécessitent des
extensions TIPS
M30- Object DB

 TIPS : pour les STRUCTURED DATA stores
 T: Transactions (avec propriétés ACID)
 I: No-procedural Interface (SQL)
 P: Persistency
 S: Structuration (Schema)
13
4/14/2021
M30- Object DB

 TIPS : pour les STRUCTURED DATA stores
 T: Transactions (avec propriétés ACID)
 I: No-procedural Interface (SQL)
 P: Persistency
 S: Structuration (Schema)
M30- Object DB
 Contribution des objets à la gestion des données:

propriétés RICE (Mira96)
R Reusability (Inheritance or polymorphism)
I Identification et Reference (OID : Object Identifier)
C Complex Object construct
E Encapsulation (Methods)
14
4/14/2021
M30- Object DB
M30- Object DB
15
4/14/2021
M30- Object DB
 Contribution des objets à la gestion des données:

propriétés RICE (Mira96)
M30- Object DB
 Recherche en BD ... Propriétés (TIPS):

 T: Transactions de longue durée et éclatées
 I: Interfaces vocales multimédias et neuronales
 P: Big data et DB très léger; lacs de données; gestion de la
mémoire virtuelle; DB de mémoire principale; méthodes
d'accès
 S: Object-relational DBMS (ponts entre ODMG and SQL3)

Données semi-structurées (ponts SparQL et SQL)
Extension SQL pour gérer ML, DL et NO SQL
Optimisation des requêtes
16
4/14/2021
M30- Object DB
 ODMG et propriétés RICE :
R Héritage multiple (C ++)
I OID : Object Identifier
Complex Object construct:

- STRUCTURE
C
- COLLECTIONS :
SET, BAG, LIST, ARRAY, Dictionary
- Bidirectional pointers . REF & INVERSE
E Encapsulation: « Types » with methods
M30- Object DB
 TYPE: Hiérarchie
17
4/14/2021
M30- Object DB
 ODMG: meta-model
M30- Object DB
 ODMG: ODL – Object Definition Language

 ODL est un langage standard pour décrire les schémas en
termes orientés objet, remplissant la même fonction que SQL
DDL.
 Définition d’interface (Interface definiton)
 Spécification du comportement observable par les utilisateurs
(ou d’une partie de celui-là) pour un type d’objets
 Exemple: une interface calculateur modélisant une machine à calculer
INTERFACE CALCULATEUR {
CLEAR();
FLOAT ADD(IN FLOAT OPERAND);
FLOAT SUBSTRACT (IN FLOAT OPERAND);
FLOAT DIVIDE(IN FLOAT DIVISOR);
FLOAT MULTIPLY (IN FLOAT MULTIPLIER);
FLOAT TOTAL();}
18
4/14/2021
M30- Object DB
ODMG: ODL – Object Definition Language

 Déclarations de classe
 Une classe est une description d'objets ayant la même
structure, comprenant les mêmes attributs avec les mêmes
types de données et les mêmes méthodes et relations.
 Spécification du comportement et d’un état observables par
les utilisateurs pour un type d’objets
 Une classe implémente ainsi une ou plusieurs interfaces.
 En plus d’un comportement, une classe définit un état
abstrait.
 Pour mémoriser les états abstraits de ses instances, une classe
possède aussi une extension de classe.  class extent
class classname {
list of attributes, relationships, methods
}
M30- Object DB

 Extent
 L‘extension d'une classe peut être considérée comme
l'ensemble des instances d'objet de cette classe qui sont
stockées dans la base de données à un moment donné.
 En utilisant les termes introduits précédemment, la classe
elle-même fait partie de l’extension de la base de données
...,
 Il est recommandé de choisir un nom pour l'étendue
légèrement différent du nom de la classe.
19
4/14/2021
M30- Object DB

 Extent
 Exemple 1 (Exemple d’etude): Pour la classe Person, nous
avons appelé l'extension people. Les parenthèses peuvent
également contenir le nom de la clé
class Person( extent People key pId)
{
/*définition des attributs */
attribute int pId;
attribute string name;
attribute Struct Addr(string street, string city,
string state, string zip) address;
attribute string phone;
attribute date birthDate;
/* définition des methods */
int findAge();
};
M30- Object DB

 Extent
 Exemple 2: (implémenter une interface )
 Le comportement abstrait pourra être hérité d’une interface.
 une clé au niveau d’une extension de classe  comme en relationnel, il s’agit
d’un attribut dont la valeur détermine un objet unique dans l’extension.
CLASS ORDINATEUR (EXTENT ORDINATEURS KEY ID): CALCULATEUR

{
ATTRIBUTE SHORT ID ;
ATTRIBUTE FLOAT ACCUMULATEUR;
VOID START();
VOID STOP();
};
 Notes:
 Une interface n’a en principe pas d’extension.
 Interfaces et classes sont des spécifications de types. Il est aussi possible de
spécifier des types de valeurs : ceux-ci sont appelés des littéraux.
20
4/14/2021
M30- Object DB

 Attributs
 Les attributs ont un type de données (voir le schéma cf. TYPE: Hiérarchie)
 Une grande variété de types est autorisée dans ODL:
 des types simples
 des types plus complexes qui peuvent être construits à partir d'eux.
 Les types atomiques.
 Les types énumérés sont identifiés par le mot-clé enum, le nom défini par
l'utilisateur du type, une liste de littéraux pour le type entre accolades et le nom
de l'attribut avec ce type.
 On peut aussi avoir des types structurés, identifiés par le mot-clé Struct, le nom
du type, et des accolades contenant chaque attribut avec son type de données.
 Exemple: la classe Person,
 Addr est un type structuré. Depuis que nous avons défini le type, nous pouvons l'utiliser
à nouveau pour d'autres classes, mais nous devons identifier la classe dans laquelle il a
été défini, en utilisant la forme Person :: Addr
 Cette forme étendue est utilisée pour faire référence à n'importe quelle propriété dans
une classe différente.
 Outre Struct, il existe des constructeurs de types pour cinq types de collections, à savoir
Set, List, Array, Bag et Dictionary.
M30- Object DB

 Attributs
 Exemple pour enum
class Faculty extends Person (extent Fac)
{
/*define attributes */
attribute enum FacultyRank{lecturer, instructor, assistant,
associate, professor} rank;
attribute real(8,2)salary;
/*define relationships */
.....
/* define methods */
....
};
21
4/14/2021
M30- Object DB

 Relationships
 objet >> fondamental dans le modèle OO.
 Un objet >> un état et un comportement.
 L'état comprend la structure interne de l'objet, ses attributs descriptifs ou
éléments de données et les relations (Relationships) auxquelles il
participe avec d'autres objets.
 En UML, nous distinguons une association, qui est une relation
unidirectionnelle ou bidirectionnelle entre les classes, et l'agrégation, qui
est un type de relation qui relie un tout à ses parties.
 Les associations, ou connexions binaires entre les classes, sont
représentées par des lignes reliant les classe.
 Le nom de l'association peut éventuellement apparaître sur la ligne.
 Tout attribut descriptif de la relation est indiqué dans une case reliée à
la ligne d'association par une ligne en pointillé...
M30- Object DB

 Relationships
 Le modèle orienté objet représente ces connexions à l'aide de
références.
 Dans ODL, la description d'une relation implique que le système
stocke et gère ces références.
 Les associations permettent de compléter la modélisation des
états des objets.
 L’ODMG préconise le support d’associations binaires,
bidirectionnelles de cardinalité (1:1), (1:N), ou (N:M), sans
données.
 Une association de A vers B définit deux chemins de traversée
inverses, A->B et B->A.
 Chaque chemin doit être défini en ODL au niveau du type
d’objet source par une clause RELATIONSHIP.
22
4/14/2021
M30- Object DB

 Relationships
 L’association pointe vers un seul objet cible ou vers une
collection.
 Elle porte un nom et son inverse doit être déclaré.
 Pour la gestion, le SGBDO doit fournir des opérations
sur associations telles que Add_member,
Remove_member, Traverse et Create_iterator_for.
 De fait, les associations sont simplement des déclarations
abstraites d’attributs couplés, valués par une valeur
simple ou une collection, contenant des identifiants
d’objets réciproques.
M30- Object DB

 Relationships <<persistent>>
Person
 Exemple d’étude: pId
name
address
phone
birthdate
findAge()
<<persistent>>
ClassSection
<<persistent>>
0..* sectionCode
Student
hasStudent schedule
credits 0..*
room
gpa takesClass
getStatus( )
addCredits( )
23
4/14/2021
M30- Object DB

Relationships
class <<persistent>>
Student extends Person (extent Students)
Person
{  Exemple d’étude: pId
/*define attributes */ name
address
attribute int credits; phone
attribute real(3,2) gpa; birthdate
/*define relationships */ findAge()
relationship Set<ClassSection> takesClass Inverse
ClassSection::hasStudent;
... <<persistent>>
/*define methods */ ClassSection
<<persistent>>
string sectionCode
Student getStatus();
0..*
hasStudent
void addCredits(in int numCredits); schedule
credits 0..*
room
gpa
}; takesClass
getStatus( )
addCredits( )
M30- Object DB

 Relationships (Exemple d’étude suite) :
 chaque instance Student peut contenir un ensemble de
références, appelé takesClass, aux instances ClassSection.
 En règle générale, les références sont simplement les OID
des objets associés.
 Le mot-clé Set montre qu'il s'agit d'une relation «plusieurs»
(Un etudiant suis plusieurs cours).
 La relation takeClass  un moyen pour découvrir les cours
suivis par l'étudiant.
 il existe une telle relation inverse, hasStudent, définie pour
ClassSection  Inverse ClassSection :: hasStudent;
 Il faut spécifier également cette relation dans la classe
ClassSection :
24
4/14/2021
M30- Object DB
ODMG: ODL – Object Definition Language<<persistent>>

Course
 Relationships <<persistent>> cNo
cTitle
Person credits
 Exemple d’étude: pId description
name
address changeDesc( )
phone
birthdate 1
findAge() isSection
0..*
<<persistent>> hasSection
Student 0..* <<persistent>>
credits hasStudent 0..* ClassSection
gpa takesClass sectionCode
getStatus( ) schedule
addCredits( ) room
M30- Object DB

 Relationships (Exemple d’étude suite) :
Q2.1: Donner le code ODL pour ClassSection
class ClassSection extends Course(extent

Sections)
{
/*les attributs*/
attribute string sectionCode;
attribute string schedule;
attribute string room;
/*les relationships */
relationship Set<Student> hasStudent Inverse
Student::takesClass;
assists;
};
25
4/14/2021
M30- Object DB

 Méthodes:
 Les déclarations de méthode dans ODL spécifient la
signature type de retour + nom de la méthode +les noms
et types de paramètres, avec un mode identifié comme IN,
OUT ou IN OUT, selon que le paramètre est entré , sortie,
ou les deux.
 En ODL, les classes ont des méthodes automatiques get () et
set (), nous n'avons donc pas besoin de les lister sauf si nous
souhaitons les remplacer.
 Les méthodes des membres de la classe sont appliquées à
une instance de la classe, appelée self dans le code de la
méthode.
 Le code réel de la méthode ne fait pas partie de l'ODL, mais
est écrit dans l'un des langages hôtes.
M30- Object DB

 Exercice ( ODL)
 Soit le schéma graphique de la base de l’exercice
26
4/14/2021
Exercice Semaine 2
Personne
nss
!! nom
prenom Appart
Voiture datenais
vieillir() étage
nveh no
couleur !! dormir() rue
marque code
km ville
rouler()
Employe Sportif
inferieur
fonction
type
salaire *
état
primes Sport
travailler() Pritiquer()
superieur * nom
champ
qualité
EmployeSportif
M30- Object DB

 Exercice ( ODL)
 Donner le code ODL pour voiture
Class Voiture (extent voitures key nveh) {

attribute string nveh;
attribute string couleur;
attribute string marque;
attribute short km;
relationship Personne Appartient inverse

Personne::Possede;
short rouler(in short distance); };
27
4/14/2021
M30- Object DB

 Exercice ( ODL)
 Donner
le code ODL pour Personne
Interface Personne { // interface abstraite
attribute string nss ;
attribute string nom ;
attribute string prenom ;
attribute date datenaissance;
relationship Appart habite inverse
Appart::loge;
relationship Voiture Possede inverse
Voiture::Appartient;
short vieillir();
void dormir()
short age(); };
M30- Object DB

 Exercice ( ODL)
 Donner le code ODL pour Appart
class Appart (extent Apparts) {

attribute struct adresse (short etage,
unsigned short numero, string rue,
unsigned short code, string ville);
relationship Set<personne> loge inverse
Personne::habite; };
28
4/14/2021
M30- Object DB

 Exercice ( ODL)
 Donner
le code ODL pour Employe
class Employe : Personne(extent Employés key
nss) {
attribute enum fonct{ingénieur, secrétaire,
analyste, programmeur, DBA}
fonction;
attribute float salaire ;
attribute list<float> primes ;
relationship Set<Employé> inferieur inverse
supérieur;
relationship Employé supérieur inverse
inférieur;
void travailler(); };
M30- Object DB

 Exercice ( ODL)
 Donner
le code ODL pour Sportif
class Sportif: Personne(extent sportifs key
nss) {
....
relationship list<sport> pratique inverse
Sport::pratiquer_par;
void pratiquer(in Sport f);
};
29
4/14/2021
M30- Object DB

 Exercice ( ODL)
 Donner le code ODL pour EmployeSportif  héritage multiple
en ODL!!!!
 L’héritage multiple n’étant pas possible au niveau des classes  2
solutions possibles:
 Solution 1: les employés sportif sont des employés avec les

propriétés de sportifs répétées.
 Solution 2: On aurait pu éviter cette répétition en définissant une

interface Sportifs, puis une classe implémentant cette interface.
 Le bon choix est probablement de définir des interfaces pour tout

ce qui est visible à l’extérieur, puis de réaliser ces interfaces par
des classes.
M30- Object DB

 Exercice ( ODL)
 Donner
le code ODL pour EmployeSportif
class EmployeSportif extends Employe {
attribute typesport{deutant,moyen,expe} type;
attribute etatsport{debut,fin} etat;
relationship list<Sport> pratiquer inverse

sport::pratiquer_par;
void pratiquer(in Sport s);

};
30
4/14/2021
M30- Object DB

 Relations n-aires et relations M: N avec attributs
 Les relations, dans la plupart des cas, dans ODL sont
binaires
 Comment modéliser une relation ternaire ou d'ordre
supérieur? Faculty
Textbook
Course-Faculty-
Text
Course
M30- Object DB

 Nous pouvons le faire en créant une classe pour la relation
elle-même.
 La définition de classe inclurait au moins trois relations qui
connectent la nouvelle classe aux classes liées à l'origine.
 Code de la classe BookOrder:
Class BookOrder{
relationship Faculty teacher Inverse
Faculty::adoptsText;
relationship TextBook bookFor Inverse
TextBook::usedIn;
relationship Course uses Inverse
Course::usesText;
}
31
4/14/2021
M30- Object DB

 Remarque:
 Si la relation a des attributs descriptifs, ils seront également répertoriés.
 Notez que cette technique est similaire à la façon de mappage en modèle
relationnel.
 Les relations plusieurs-à-plusieurs binaires avec des attributs descriptifs
ne peuvent pas être gérées par cette solution  ne laisse aucune place
aux attributs descriptifs.
 Exemple:
grade
<<persistent>>
<<persistent>> ClassSection
Student 0..*
sectionCode
credits givenStudent
schedule
gpa
0..* room
getStatus( )
addCredits( ) earnedGrade
M30- Object DB

 Exemple suite:
 Grade un exemple d'attribut descriptif. Nous utilisons la même solution que
pour les relations n-aires, en mettant en place une classe pour la relation.
 Nous plaçons les attributs descriptifs en tant qu'attributs de la nouvelle classe, et
nous définissons deux relations un-à-plusieurs entre les deux classes d'origine et
la nouvelle classe (classe Mark)
class Mark (extent Grades)

{
attribute string grade;
relationship ClassSection givenTo Inverse
ClassSection::givenIn;
relationship Student givenStudent Inverse
Student::earnedGrade;
}
32
4/14/2021
M30- Object DB

 Keys
 Les clés sont facultatives dans ODL, car l'identificateur
d'objet unique (OID) attribué automatiquement à
chaque instance d'objet permet au système de distinguer
les instances.
 Cependant, le concepteur peut également choisir
d'identifier les clés candidates.
 Cela se fait au début de la déclaration de classe dans les
mêmes parenthèses que la déclaration d'étendue.
 Une clé peut être un attribut unique ou un composite,
qui est identifié en plaçant des parenthèses autour des
noms des attributs de composant.
M30- Object DB

 Keys
 Exemple:
class Faculty (extent Fac

key facId, socSecNo, (name, department))
Cela signifie que facId est une clé, socSecNo est une clé et
que la combinaison du nom et department est une clé.
En OODB les clés ne sont pas limitées aux attributs.
 lister une relation ou même une méthode comme clé, à condition
qu'elle nous donne des valeurs uniques.
33
4/14/2021
M30- Object DB

 Exercice: (OODB ODL Many-to-many
relationship with an association class.docx )
M30- Object DB

 Exercice 2: (Suite Exemple d’étude) )
34
4/14/2021
<<persistent>>
pId
Person <<persistent>>
name Course
address cNo
phone cTitle
birthdate credits
findAge() description
changeDesc( )
<<persistent>> <<persistent>> 1 1
Student Faculty hasTeacher isSection
credits 0..* 1 rank
gpa advises hasAdvisor salary
getStatus( ) giveRaise( )
addCredits( ) 0..*
0..*
hasStudent hasSection
<<persistent>>
ClassSection
<<persistent>> <<persistent>> 0..*
sectionCode 0..*
Undergraduate Graduate takesClass
schedule teaches
major program room
changeMajor( ) changeProgram( )
0..1
assists
<<persistent>>
TeachingAssistant 0..1
fundingSource hasTA
annualStipend
M30- Object DB

 Exercice 2: (ODL... Faculty)
class Faculty extends Person (extent Fac)
{
Attribute enum FacultyRank{lecturer, instructor,
assistant, associate, professor} rank;
attribute real(8,2)salary;
relationship Set<ClassSection> teaches Inverse
ClassSection::hasTeacher;
relationship Set<Student> advises Inverse
Student::hasAdvisor;
void giveRaise(in float amount) raises (Salary

out of range);
};
35
4/14/2021
M30- Object DB

 Exercice 2: (ODL... Undergraduate)
class Undergraduate extends Student

(extent Undergrads)
{
/*les attributs*/
attribute string major;
/* les methodes*/
void changeMajor(in string newMajor) raises
(Invalid major);
};
M30- Object DB

 Exercice 2: (ODL... Graduate)
class Graduate extends Student

(extent Grads)
{
/*les attributs*/
attribute string program;
/* les methodes */
string changeProgram(in string newProgram)
raises (Invalid program);
};
36
4/14/2021
M30- Object DB

class TeachingAssistant extends Graduate

(extent TAs)
{
/*les attributs*/
attribute string fundingSource;
attribute real(7,2) annualStipend;
/*les relations*/
relationship ClassSection assists Inverse
ClassSection::hasTA;
};
M30- Object DB

class ClassSection extends Course
(extent Sections)
{
attribute string sectionCode;
attribute string schedule;
attribute string room;
relationship Set<Student> hasStudent Inverse
Student::takesClass;
relationship Faculty hasTeacher Inverse
Faculty::teaches;
relationship TeachingAssistant hasTA Inverse
TeachingAssistant::assists;
relationship Set<Mark> givenIn Inverse Mark::givenTo;
};
37
4/14/2021
M30- Object DB

 Exercice 2: TAF/R (partie 1) A rendre par email avant le 18/04/2021)
Un département offre plusieurs cours

Un département a un chef de dept (un faculty)
Dans un département est attaché plusieurs personnes
(n’oublie pas que la classe Person est abstraite)tandis qu’une
personne est attachée à un seul dept.
Un département est caractérisé par un code, un nom, un tel
et un bureau.
Faire une modélisation de ce cahier de charge

Donner le code ODL correspondant.
M30- Object DB

 Exercice 2: TAF/R Partie 2
Les entités faibles vs entité propriétaire forte
Par exemple, supposons que les évaluations de l'enseignement des
membres du corps professoral sont menées par le corps professoral
(faculty) ou par le doyen et que les évaluations sont stockées dans la
base de données. Par souci de simplicité, nous supposons qu'une seule
note est donnée pour chaque évaluation, de sorte qu'une entité
d'évaluation dispose des attributs date, évaluateur et note. Puisqu'il peut
y avoir plusieurs instances avec des valeurs identiques pour les trois
attributs, une entité d'évaluation doit être associée à l'instance Faculty
correcte pour avoir une signification.
Pour cet exemple, nous supposons que le même membre du corps
professoral n'est jamais évalué deux fois le même jour, nous utilisons
donc evalDate comme discriminateur.
38
4/14/2021
M30- Object DB
 ODMG: OQL – langage de requêtes

 OQL spécifie une façon de faire des requêtes sur un
modèle défini par ODL
 optimisation des requêtes
 Indépendance des données
 Requêtes intégrées
 Prise en charge des TIPS
 opérateurs d'enrichissement de données
 Le langage OQL (Object Query Language) utilise
une syntaxe similaire à SQL, mais qui opère sur des
objets et non sur des tables.
M30- Object DB

 Syntaxe:
SELECT [DISTINCT] expression list

FROM fromList
[WHERE condition]
[GROUP BY...[HAVING condition]]
[ORDER BY expression];
39
4/14/2021
M30- Object DB

 Exemple
SELECT s.pId, s.credits
FROM Students s
ORDER BY s.pID;
 L'utilisationde la notation par points appelle la méthode
get () par défaut pour les attributs nommés dans la ligne
SELECT.
 nous pouvons utiliser des méthodes dans la liste
d'expressions, qui récupère le résultat de l'application de
la méthode. On pourrait écrire, par exemple:
SELECT p.name, p.findAge( )
FROM People p
WHERE p.pId = 1001;
M30- Object DB

 Nous pouvons également utiliser une relation
« relationship » dans la liste d'expressions. Cela
récupère l'objet ou l'ensemble d'objets liés à l'objet
«appelant» à travers la relation.
 Exemple
SELECT s.pId, s.takesClass.cNo,

s.takesClass.sectionCode
FROM Students s
WHERE s.pId = '999';
40
4/14/2021
M30- Object DB

 La liste des variables dans la ligne FROM est similaire à
la définition d'un alias dans SQL.
 Habituellement, nous listons le nom d'une étendue et
un identifiant pour le nom de la variable, telle que s ou p.
 La variable est en fait une variable itératrice qui s'étend
sur l'étendue. Il existe d'autres formes pour déclarer une
variable d'itérateur, telles que:
 Exemple
FROM Students s
FROM s IN Students
FROM Students AS s
M30- Object DB

 Dans la clause WHERE, nous sommes limités à une
expression booléenne ayant des constantes et des
variables définies dans la clause FROM. Nous pouvons
utiliser <, <=,>,> =,! =, AND, OR et NOT dans
l'expression, ainsi que IN et les quantificateurs EXISTS
et FORALL.
 Comme en SQL, OQL n'élimine pas les doublons, le
retour est donc un sac (multiset) plutôt qu'un set
« ensemble ».
 Si nous souhaitons éliminer les doublons, on peut ajouter
le mot clé DISTINCT comme en SQL, produisant un
ensemble. Nous pouvons éventuellement ajouter une
clause ORDER BY, comme dans SQL.
41
4/14/2021
M30- Object DB

 Requête 1: trouvez l'ID, le nom et la majeure de tous
les étudiants de premier cycle qui ont entre 60 et 90
crédits, dans l'ordre par nom.
SELECT s.pId, s.name, s.major

FROM Undergrads AS s
WHERE s.credits >=60 AND s.credits<=90
ORDER BY s.name;
M30- Object DB

 Requête 2: Trouvez les noms de toutes les
professeurs du département de biologie.
SELECT f.name
FROM Departments AS d, d.hasFaculty AS f
WHERE d.deptName = 'Biology';
42
4/14/2021
M30- Object DB

 Requête3: La requête précédente peut être exprimée
de manière similaire aux requêtes imbriquées dans
SQL.
SELECT f.name
FROM (SELECT d
FROM d IN Departments
WHERE d.deptName = 'Biology') AS b,
b.hasFaculty AS f;
M30- Object DB

 Requête 4: Trouvez le nom, le rank et le salaire de
toutes les professeurs du département d'anglais et
mettez les résultats dans une structure, par ordre
décroissant de salaire.
SELECT STRUCT(name: f.name, rank: f.rank,
salary: f.salary)
FROM Fac AS f
WHERE f.belongsTo = 'English'
ORDER BY salary DESC;
43
4/14/2021
M30- Object DB

 Requête 5: Trouvez le salaire moyen des membres
du corps professoral du département d'histoire.
AVG (SELECT f.salary

FROM Fac AS f
WHERE f.belongsTo = 'History');
M30- Object DB

 Requête 6: Trouvez le nombre d'étudiants de
premier cycle qui se spécialisent en informatique.
COUNT ((SELECT u
FROM Undergrads AS u
WHERE u.majorsIn = 'Computer Science');
44
4/14/2021
M30- Object DB

 Requête 7: Trouvez le numéro de cours et la section
de toutes les sections de cours qui comptent plus de
30 étudiants.
SELECT s.cNo, s.section

FROM Sections AS s
WHERE COUNT (s.hasStudents >30);
M30- Object DB

 Requête 8: Trouvez les identifiants et les noms de
tous les étudiants dont le programme de premier
cycle majeur ou supérieur est l'informatique.
(SELECT u.pID, u.name

FROM Undergrads AS u
WHERE u.major = 'Computer Science')
UNION
(SELECT g.pID, g.name
FROM Grads AS g
WHERE g.program = 'Computer Science');
45
4/14/2021
M30- Object DB

 Requête 9: Créez une requête définie pour trouver
tous les juniors et utilisez-la pour trouver l'ID et le
nom de tous les juniors.
DEFINE Juniors AS
SELECT s
FROM s IN Undergrads
WHERE s.credits >= 60 AND s.credits<90;
// utilisation
SELECT j.pId, j.name FROM j IN Juniors;
46

M30 - 1 Object-Based Models Semaine 2 Et 3

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

M30 - 1 Object-Based Models Semaine 2 Et 3

Transféré par

Droits d'auteur :

Formats disponibles

4/14/2021

M30-BASES DE DONNEES AVANCEES

A. BOULAALAM (USMBA/ENSA) BDA – BDO 1

Object Databases: Introduction

A. BOULAALAM (USMBA/ENSA) BDA – BDO 2

Object Databases: Introduction

 Bases de données objets (ODBs):

Object Databases: Introduction >> 1- Bref Historique BDO

A. BOULAALAM (USMBA/ENSA) BDA – BDO 4

Object Databases: Introduction >> 1- Bref Historique BDO

Object Databases: Introduction >> 2- Concepts fondamentaux

 Un objet est un concept abstrait:

A. BOULAALAM (USMBA/ENSA) BDA – BDO 6

Object Databases: Introduction >> 2- Concepts fondamentaux

Object Databases: Introduction >> 2- Concepts fondamentaux

 Compte tenu de cette définition fondamentale

A. BOULAALAM (USMBA/ENSA) BDA – BDO 8

Object Databases: Introduction >> 2- Concepts fondamentaux

 La capacité de définir des objets complexes à partir

A. BOULAALAM (USMBA/ENSA) BDA – BDO 9

Object Databases: Introduction >> 2- Concepts fondamentaux

Object Databases: Introduction >> 2- Concepts fondamentaux

 Exemple Personne ... 2 instances

Object Databases: Introduction >> 2- Concepts fondamentaux

 Les objets sont encapsulés:

Object Databases: Introduction >> 2- Concepts fondamentaux

 Chaque objet est encapsulé et les valeurs de ses

 À partir des noms de ces méthodes, nous

Object Databases: Introduction >> 2- Concepts fondamentaux

 Un (literal) littéral diffère d'un objet en ce qu'il a un

Object Databases: Introduction >> 2- Concepts fondamentaux

void setName(in string newName)

A. BOULAALAM (USMBA/ENSA) BDA – BDO 15

Object Databases: Introduction >> 2- Concepts fondamentaux

 Exemple de la classe Person (suite)

string employeeName = premierPerson.getName( );

Les methodes peuvent etre surcharger (Meme

Object Databases: Introduction >> 2- Concepts fondamentaux

 Exemple de la classe Person (suite)

string employeeName = premierPerson.getName( );

Les methodes peuvent etre surcharger (Meme

Object Databases: Introduction >> 2- Concepts fondamentaux

 Hiérarchies de classe et héritage

A. BOULAALAM (USMBA/ENSA) BDA – BDO 18

Object Databases: Introduction >> 2- Concepts fondamentaux

 Hiérarchies de classe et héritage

Object Databases: Introduction >> 2- Concepts fondamentaux

 Hiérarchies de classe et héritage

A. BOULAALAM (USMBA/ENSA) BDA – BDO 20

Object Databases: Introduction >> 3- Standard ODMG

Object Databases: Introduction >> 3- Standard ODMG

 ODMG 3.0 (2000)

A. BOULAALAM (USMBA/ENSA) BDA – BDO 22

Object Databases: Introduction >> 3- Standard ODMG

 ODMG 3.0: Composants

OIF: (object Interchange

A. BOULAALAM (USMBA/ENSA) BDA – BDO 23

Object Databases: Introduction >> 3- Standard ODMG

 ODMG 3.0: « Object-value » paradigme

 Pointeurs bidirectionnels entre les classes

A. BOULAALAM (USMBA/ENSA) BDA – BDO 24

Object Databases: Introduction >> 3- Standard ODMG

 ODMG 3.0: « Object-value » paradigme