Institut Supérieur d’Informatique - Université Tunis El Manar

Module 4 : Standards et langages des bases de données à objets (Section 1)

Riadh ZAAFRANI Novembre 2020

1ère année MP2L

Plan

◼Préambule

◼Le modèle objet de l'ODMG

◼Objets et littéraux

◼Interfaces du modèle objet de l'ODMG

◼Interfaces, classes et héritage

◼Le langage de définition d'objets ODL

◼Le langage de requête objet: OQL

Préambule

très

◼Il est

important de disposer d'un standard pour un système de base de données particulier, parce qu'il assure la portabilité des applications. ◼On définit généralement

la portabilité un comme d'exécuter programme donné sur différents systèmes en n'apportant que des modifications mineures au programme lui-même.

possibilité

Préambule

◼ Dans le domaine des bases de données objet, la portabilité permet à un programme écrit pour accéder à un package SGBDO d'accéder à un autre package SGBDO, pourvu que le standard soit appliqué scrupuleusement.

◼ Il s'agit d'une caractéristique importante aux yeux des utilisateurs, qui hésitent généralement à investir dans une nouvelle technologie si les à un différents standard commun.

fournisseurs n'adhèrent pas

Préambule

◼L'adhésion à des standards présente un autre avantage: elle contribue à l'interopérabilité, qui désigne la capacité d'une application à accéder à plusieurs systèmes distincts.

◼Pour les bases de données, cela signifie que la même application peut accéder à des données stockées dans un package SGBDO et aux données stockées dans un autre type de package.

Préambule

◼Un troisième avantage des standards est qu'ils permettent aux clients de produits des comparer facilement, en commerciaux plus du quelles déterminant standard sont prises en charge par chaque produit.

parties

Préambule

◼Comme nous le savons, l'une des raisons du succès des SGBD relationnels du commerce est le standard SQL.

◼L'absence de standard pour

les SGBDO pendant plusieurs années peut expliquer que certains utilisateurs potentiels aient hésité à se convertir à cette nouvelle technologie.

Préambule

SGBDO,

◼C'est pourquoi un consortium de fournisseurs l'ODMG (Object Data de Management Group), a proposé un standard le nom de ODMG-93 ou connu sous ODMG 1.0.

◼Après révision, il est devenu ODMG 2.0,

que nous allons décrire, dans ce cours.

Préambule

◼ Il est constitué de plusieurs parties: le modèle objet, le langage de définition objet (ODL ou Object Definition Language), (OQL ou le langage de requête objet Object Query Language) et les liaisons (bindings) avec les langages de programmation orientés objet.

◼ Ces dernières ont été spécifiées pour plusieurs langages,

notamment C++, Smalltalk et Java.

◼ Certains fournisseurs ne proposent que des liaisons de toutes les capacités

langages spécifiques sans offrir d'ODL et d'OQL.

Plan

◼Préambule ◼Le modèle objet de l'ODMG

◼Objets et littéraux

◼Interfaces du modèle objet de l'ODMG

◼Interfaces, classes et héritage

◼Le langage de définition d'objets ODL

◼Le langage de requête objet: OQL

Vue d'ensemble du modèle objet de l'ODMG

◼ Le modèle objet de l'ODMG est

le modèle de données sur lequel s'appuie le langage de définition (ODL) et le langage de requête (OQL). ◼ En réalité, ce modèle objet fournit

les types de données, les constructeurs de types et d'autres concepts qui servent en ODL à spécifier des schémas des bases de données objet.

◼ C'est donc un modèle de données standard pour les bases de données orientées objet, tout comme SQL décrit un modèle de données standard pour les bases de données relationnelles.

Plan

◼Préambule

◼Le modèle objet de l'ODMG

◼ Objets et littéraux

◼Interfaces du modèle objet de l'ODMG

◼Interfaces, classes et héritage

◼Le langage de définition d'objets ODL

◼Le langage de requête objet: OQL

Objets et littéraux

◼ Les objets et les littéraux sont les blocs de base du modèle objet. La principale différence entre les deux est qu'un objet possède un identifiant tandis d'objet et un état (sa valeur courante), qu'un littéral n'a qu'une valeur.

◼ Dans les deux cas,

la valeur peut avoir une structure complexe. L'état de l'objet peut changer dans le temps si on modifie sa valeur. Un littéral est en substance une valeur constante, peut avoir une structure complexe mais immuable.

Objets et littéraux

◼ Un objet est décrit par quatre caractéristiques:

◼ un identifiant; ◼ un nom; ◼ une durée de vie; ◼ une structure.

◼ L'identifiant d'objet (ou OBJECT_ID) est un identifiant unique à l'échelle du système. Tout objet doit avoir un identifiant.

◼ En outre, les objets peuvent recevoir facultativement un nom unique dans une base de données particulière. Ce dernier sert à référencer un objet dans un programme.

Objets et littéraux

◼ De toute évidence, il est impossible d'attribuer à tous les objets un nom unique. En général, seuls quelques objets sont nommés, principalement ceux d'objets qui particuliers, tels que les extensions.

contiennent

collections

des

◼ Ces noms sont utilisés comme points d'entrée dans la base de données : en localisant ces objets à l'aide de leur nom unique, l'utilisateur peut accéder aux autres objets qu'ils référencent.

Objets et littéraux

◼ La durée de vie spécifie s'il s'agit d'un objet persistant (autrement dit un objet de la base) ou d'un objet temporaire (un objet appartenant à un programme en cours d'exécution et qui disparaît lorsque ce programme s'achève).

◼ Enfin, la structure d'un objet définit la façon de construit dont constructeurs de types. Elle spécifie s'il s'agit d'un objet atomique ou d'un objet collection.

au moyen

l'objet

est

Objets et littéraux

◼ Dans le modèle objet, un littéral est une valeur qui n'a pas d'identifiant d'objet. Toutefois, cette valeur peut avoir une structure simple ou complexe. Il existe trois types de littéraux: ◼ atomiques, ◼ collections, ◼ structurés.

◼ Les

littéraux atomiques

aux valeurs d'un type de données de base et sont prédéfinis.

correspondent

Objets et littéraux

◼ Les types de données de base du modèle objet sont :

➢ les entiers longs, courts et non signés (spécifiés en ODL par les mots clés Long, Short, Unsigned Long et Unsigned Short),

➢ les décimaux ordinaires et en double précision (Float,

Double),

➢ les booléens (Boolean), ➢ les caractères uniques (Char), ➢ les chaînes de caractères (String) ➢ les énumérations (Enum).

Objets et littéraux

Time,

- Date,

◼Les littéraux structurés sont les structures intégrées Interval, Timestamp - et toutes les structures de types supplémentaires définies par l'utilisateur en fonction des besoins de chaque application. ◼On crée une structure définie par l'utilisateur à l'aide du mot clé ODL Struct, comme en C et en C++.

Objets et littéraux

◼ Les littéraux collections spécifient une valeur qui est la une collection d'objets ou de valeurs, mais collection elle-même n'a pas d'identifiant d'objet.

◼ Les collections du modèle objet sont SET<T>, BAG<T>, LIST<T> et ARRAY<T>, où T est le type d'objets ou de valeurs de la collection.

◼ Un autre type de collection est DICTIONARY<K, V>, une collection d'associations <K, V>, où chaque K est une clé (une valeur de recherche unique) associée à une valeur v. Ce mécanisme peut servir à créer un index sur une collection de valeurs.

Plan

◼Préambule

◼Le modèle objet de l'ODMG

◼Objets et littéraux ◼ Interfaces du modèle objet de l'ODMG

◼Interfaces, classes et héritage

◼Le langage de définition d'objets ODL

◼Le langage de requête objet: OQL

Vue d'ensemble des définitions d'interfaces d'une partie du modèle objet de l'ODMG.

◼ Les listings suivants sont une version simplifiée du modèle objet et proposent une vue simplifiée des composants de base du modèle objet de l'ODMG.

◼ La notation ODMG emploie le mot clé interface. Il est plus approprié, puisqu'il désigne l'interface des types d'objets - nommément leurs opérations, leurs relations et leurs attributs visibles.

◼ Ces interfaces ne sont généralement pas instanciables, mais servent à définir des opérations qui peuvent être héritées par les objets définis par l'utilisateur pour une application particulière.

Listing A. l’interface de base Object, dont tous les autres objets héritent.

▪ interface Object {

…

boolean Object void

same_as (in Object other_object); copy(); delete(); ▪ Dans le modèle objet, tous les objets héritent de l'interface de base Object. En conséquence, les opérations dont héritent tous les objets sont copy (qui crée une nouvelle copie de l'objet), delete (qui supprime l'objet) et same_as (qui compare l'identité de l'objet à celle d'un autre objet)

▪ D'autres opérations, non représentées dans ce listing, sont

définies pour des besoins de verrouillage.

Listing A. L'interface de base Object, dont tous les autres objets héritent.

◼ En général, on applique les opérations aux objets en

utilisant la notation pointée.

◼ Pour comparer par exemple un objet o à un autre objet p, on écrira : o.same_as(p). Le résultat retourné par cette expression est booléen, et vrai si l'identité de p est la même que celle de o, faux sinon.

◼ De même, pour créer une copie p d'un objet o, on

écrira: p = o.copy()

◼ Une solution de rechange à la notation pointée est la

notation fléchée: o->same_as(p).

Listing B. Interfaces standard des littéraux structurés.

◼L'héritage de type, qui sert à définir des relations type/sous-type, est spécifié dans le modèle ODMG au moyen de la notation «:» (deux points), comme en C++. ◼Nous constatons ainsi dans

listings suivants que toutes les interfaces, notamment Collection, Date et Time, héritent de l'interface de base d'Object.

les

Listing B. Interfaces standard des littéraux structurés.

◼ interface Date : Object {

enum

Weekday {Sunday, Monday, Tuesday,

Wednesday, Thursday, Friday, Saturday};

enum

Month{January, February, March, April,

year();

May, June, July, August, September, October, November, December}; unsigned short unsigned short month(); unsigned short … boolean boolean … };

is_equal(in Date other_Date); is_greater(in Date other_Date);

day();

Listing B. Interfaces standard des littéraux structurés.

◼ interface Time : Object {

hour();

… unsigned short unsigned short minute(); unsigned short second(); unsigned short millisecond(); … boolean boolean … Time Time Interval … };

is_equal(in Time other_Time); is_greater(in Time other_Time);

add_interval(in Interval some_Interval); subtract_interval(in Interval some_Interval); subtract_time(in Time other_Time);

Listing B. Interfaces standard des littéraux structurés.

◼ interface Timestamp : Object {

year() ;

day() ; hour();

unsigned short unsigned short month(); unsigned short unsigned short unsigned short minute(); second(); unsigned short unsigned short millisecond(); … Timestamp Timestamp boolean boolean … }

plus(in Interval some_Interval); minus(in Interval some_Interval); is_equal(in Timestamp other_Timestamp); is_greater(in Timestamp other_Timestamp);

Listing B. Interfaces standard des littéraux structurés.

◼ interface Interval : Object {

unsigned short unsigned short unsigned short unsigned short unsigned short … Interval Interval Interval Interval boolean boolean … } ;

day() ; hour(); minute(); second(); millisecond();

plus(in Interval some_Interval); minus(in Interval some_Interval); product(in long some_value); quotient(in long some_value); is_equal(in Interval other_Interval); is_greater(in Interval other_Interval);

Interfaces intégrées pour les objets collections

◼ Le modèle objet reconnaît deux grands types d'objets: les

objets collections et les objets atomiques.

◼ Tout objet collection hérite de l'interface de base

Collection.

◼ Étant donné un objet, l'opération o.cardinality() retourne

le nombre d'éléments de la collection.

◼ L'Opération o.is_empty() retourne vrai si la collection o

est vide, faux sinon.

◼ Les

opérations

et o.remove_element(e) insèrent ou suppriment un élément de la collection o.

o.insert_element(e)

Interfaces intégrées pour les objets collections

◼ L'opération o.contains_element(e) retourne vrai si

collection o contient l'élément e, faux sinon.

◼ L'opération i = o.create_iterator crée un objet itérateur i pour l'objet collection o, qui opère une itération sur chaque élément de la collection.

◼ Le modèle objet ODMG utilise des exceptions pour signaler les erreurs ou les conditions particulières. l'interface L'exception l'opération levée Collection o.remove_element(e) si e n'est pas un élément de la collection o.

ElementNotFound sera

par

Interface Collection

◼ interface Collection : Object {

… exception unsigned long Boolean … boolean void void

Iterator } ;

ElementNotFound{any element; }; cardinality() ; is_empty() ;

contains_element(in any element); insert_element(in any element); remove_element(in any element)

raises(ElementNotFound);

create_iterator(in boolean stable);

Interface des objets itérateurs

◼ Dans l'interface des objets itérateurs, l'opération i.reset() le premier élément de la positionne l'itérateur collection (pour une collection non ordonnée, ce serait un élément arbitraire), et i.next_position() le positionne sur l'élément suivant.

sur

◼ i.get_element() extrait l'élément courant, celui sur lequel

l'itérateur est actuellement positionné.

◼ L'exception NoMoreElements de l'interface Iterator sera levée par l'opération i.next_position() si l'itérateur est positionné sur le dernier élément de collection, et qu'il ne reste plus d'élément sur lequel pointer.

Interface Iterator

◼ interface Iterator {

exception … boolean void any

NoMoreElements();

at_end() ; reset() ; get_element()

raises(NoMoreElements);

void

next_position()

raises(NoMoreElements);

… } ;

Interface SET

◼ Les objets collections sont ensuite spécialisés en Set, List, Bag, Array et Dictionary qui héritent des opérations de l'interface Collection.

◼ Un type d'objet Set<t> peut servir à créer des objets tels que la valeur de l'objet o soit un ensemble d'éléments de type t.

◼ L'interface Set

l'opération p = comprend o.create_union(s), qui retourne un nouvel objet p de type Set<t> qui est l'union de deux ensembles o et s.

Interface SET

◼ D'autres opérations apparentées à create_union et

create_intersection(s)

sont create_difference(s).

◼ Les opérations de comparaison des ensembles comprennent si l'objet o est un sous-ensemble d'un autre objet s, faux sinon.

o.is_subset_of(s),

l'opération

◼ Une opération apparentée à is_subset_of est

is_superset_of(s).

Interface SET

◼ interface Set : Collection {

Set Set Set

create_union(in Set other_set); create_intersection(in Set other_set); create_difference(in Set other_set);

…

… } ;

boolean boolean

is_subset_of(in Set other_set); is_superset_of(in Set other_set);

Interface Bag

◼ Le type d'objet Bag<t> autorise des éléments dupliqués la collection et hérite également de l'interface

dans Collection.

◼ Elle

possède - create_intersection(b), retournent toutes trois un nouvel objet de type Bag<t>.

opérations create_difference

create_union(b), qui

trois

(b)

◼ Par exemple, p = o.create_union(b) retourne un objet p de les

l'union de o et b (en conservant

type Bag qui est doublons). ◼ L'opération

nombre d'occurrences dupliquées de l'élément e dans la collection o.

o.occurrences_of(e)

retourne

Interface Bag

◼ interface Bag : Collection {

unsigned long occurrences_of(in any element); Bag Bag Bag } ;

create_union(in Bag other_bag); create_intersection(in Bag other_bag); create_difference (in Bag other_bag);

Interface List

◼ Un type d'objet List<t> hérite des opérations de l'interface Collection et sert à créer des collections dans lesquelles l'ordre des éléments est important. ◼ La valeur de chaque objet o est une liste ordonnée dont les éléments sont de type t, ce qui permet de référencer le premier, le dernier ou le ie élément de la liste.

◼ Lorsqu'on ajoute un élément à la liste, spécifier la position à laquelle il est inséré.

il faut

Interface List

◼ Si o est un objet de type List<t>,

l'opération o.insert_element_first(e) insère l'élément e avant le premier élément de la liste o, de sorte que e devient le premier élément. L'opération inverse est o.insert_element_last(e).

◼ L'opération

o.insert_element_after(e,i)

insère l'élément e après le ie élément de la liste o et lève l'exception Invalidlndex si aucun ie élément est n'existe o.insert_element_before(e,i).

L'opération

inverse

dans

Interface List

◼ Pour supprimer des éléments de la liste, les opérations

sont e = o.remove_first_element(), e = o.remove_last_element (), et e = o.remove_element_at(i).

◼ Ces opérations suppriment l'élément spécifié de la

liste et retournent l'élément résultant.

◼ D'autres opérations extraient un élément sans le

supprimer de la liste. Ce sont : e = o.retrieve_first_element(), e = o.retrieve_last_element() et e = o.retrieve_element_at(i).

Interface List

◼ Enfin, deux opérations permettent de manipuler

des listes :

◼ Il s'agit de p = o.concat(l), qui crée une nouvelle liste p issue de la concaténation des listes o et l (les éléments de la liste o suivis de ceux de la liste l),

◼ et o.append(l), qui ajoute les éléments de la liste l à la fin de la liste o (sans créer de nouvelle liste).

Interface List

◼ interface List : Collection {

exception Invalid_Index{unsigned_long index; }; any

remove_element_at(in unsigned long position)

raises(InvalidIndex);

any

retrieve_element_at(in unsigned long position)

raises(InvalidIndex);

replace_element_at(in any element, in unsigned long

raises(InvalidIndex);

insert_element_after(in any element, in unsigned long

raises(InvalidIndex); insert_element_first(in any element); remove_first_element() raises(InvalidIndex); retrieve_first_element() raises(Invalidlndex); … concat(in List other_list); append(in List other_list);

void position) void position) void any any List Void };

Interface Array

◼ Le type Array<t> hérite également des opérations de Collection. tableaux, de comparables à des listes ayant un nombre fixe d'éléments.

permet

créer

des

o.replace_element_at(i,e),

◼ Les opérations spécifiques d'un objet o de type Array sont remplace l'élément e, l'élément occupant e=o.remove_element_at(i), qui extrait le ie élément et et e=o.retrieve_element_at(i), qui extrait simplement le ie élément du tableau.

la position i par

remplace

valeur

null,

par

qui

Interface Array

◼Toutes

ces

opérations

lancer l'exception InvalidIndex si i est supérieur à la taille du tableau.

peuvent

◼L'opération o.resize(n) change le nombre

d'éléments du tableau en n.

Interface Array

◼ interface Array : Collection {

Invalid_Index{unsigned_long index; }; remove_element_at(in unsigned long raises(Invalidlndex); retrieve_element_at(in unsigned long raises(Invalidlndex); replace_element_at(in unsigned long

exception any index) any index) void index, in any element) raises(Invalidlndex); void } ;

resize(in unsigned long new_size);

Interface Dictionary

◼Le dernier type d'objets collections est le

type Dictionary<k, v>.

◼Il permet de créer des paires associatives <k,v> où toutes les valeurs de k (la clé) sont uniques, et d'extraire une paire donnée en donnant la valeur de sa clé (semblable à un index).

Interface Dictionary

◼ Si o est un objet collection de type Dictionary<k, v>,

alors :

◼ o.bind (k, v) lie la valeur v à la clé k sous forme

d'association <k, v> dans la collection,

◼ o.unbind(k) supprime de o l'association dont la clé est k, ◼ et v = o.lookup(k) retourne la valeur v associée à la clé k. ◼ Les deux dernières opérations peuvent lever l'exception

KeyNotFound.

◼ Enfin, o.contains_key(k) retourne vrai si la clé k existe

dans o, faux sinon.

Interface Dictionary

◼ struct Association {any key; any value; }; ◼ interface Dictionary : Collection {

exception KeyNotFound{any key; }; void void

bind(in any key, in any value); unbind(in any key)

raises(KeyNotFound);

any

lookup(in any key)

boolean

contains_key(in any key);

raises(KeyNotFound);

};

Hiérarchie d'héritage pour les interfaces intégrées du modèle objet ◼ La figure suivante représente la hiérarchie d'héritage des

constructions intégrées du modèle objet.

Object

Iterator

Collection

Date

Time

Interval

Set

List

Bag

Array

Dictionary

Timestamp

Hiérarchie d'héritage pour les interfaces intégrées du modèle objet ◼ Les sous-types héritent des opérations du supertype. ◼ Les

sont pas directement instanciables, ce qui signifie qu'elles ne permettent pas de créer directement des objets.

collections ne

interfaces

d'objets

◼ En revanche, les interfaces peuvent servir à définir des objets collections définis par l'utilisateur - de type Set, Bag, List, Array ou Dictionary - pour une application particulière.

◼ Quand un utilisateur conçoit le schéma d'une base de données, il déclare les classes et les interfaces d'objets appropriées à son application.

Hiérarchie d'héritage pour les interfaces intégrées du modèle objet ◼ Si une interface ou une classe est l'un des objets collections, par exemple un Set, ce dernier héritera des opérations de l'interface Set.

◼ Par exemple, dans une base de données destinée à une l'utilisateur peut, spécifier une classe pour les objets seront des ensembles

université, Set<Etudiant>, dont d’objets Etudiant.

◼ Le programmeur peut alors utiliser les opérations de Set<t> pour manipuler un objet de type Set<Etudiant>.

Hiérarchie d'héritage pour les interfaces intégrées du modèle objet ◼ Tous les objets d'une collection doivent être du

même type.

◼ En conséquence, même si le mot clé any apparaît dans les spécifications des interfaces collections, cela ne signifie pas que des objets d'un type quelconque peuvent être mélangés dans une même collection, mais que tous les types sont éligibles lorsqu'on spécifie le type des éléments d'une collection donnée.

Objets atomiques (définis par l'utilisateur)

◼ Nous allons maintenant étudier la façon dont on peut construire des types d'objets pour les objets atomiques.

◼ Ceux-ci sont spécifiés à l'aide du mot clé class en

ODL.

◼ Dans le modèle objet,

tout objet défini par l'utilisateur qui n'est pas une collection est qualifié d'objet atomique.

Objets atomiques (définis par l'utilisateur)

◼ Par

exemple, dans une

application UNIVERSITE, l'utilisateur peut spécifier un type d'objet (une classe) pour les objets Etudiant.

◼ La plupart de ces objets seront des objets structurés; un objet Etudiant aura une structure complexe, avec de nombreux attributs, relations et opérations, mais il est toujours considéré comme atomique, parce qu'il ne s'agit pas d'une collection.

◼ Un tel type d'objet est défini sous la forme d’une classe en spécifiant ses propriétés et ses opérations. Les propriétés définissent l'état de l'objet, et sont ensuite décomposées en attributs et relations.

Objets atomiques (définis par l'utilisateur)

◼Nous

trois

types

présentons

de les composants - attributs, relations et opérations - qu'un type d'objet défini par l'utilisateur pour les objets atomiques (structurés) peut posséder, classes les à EMPLOYE et SERVICE.

travers

deux

class Employe

▪ class Employe

( extent key

{

attribute attribute attribute attribute attribute relationship

void

} ;

tous_employes noss )

string string date enum Genre(M,F) short Service inverse reaffecter_emp(in string nouveau_snom) raises (snom_not_valid);

nom; noss; datenaissance; sexe; age; travaille_pour Service::a_emps;

class Service

▪ class Service ( extent key

{

tous_services

snom, snumero )

attribute attribute attribute attribute attribute relationship

snumero;

string snom; short struct Dir_SCE {Employe directeur, date datedebut} dir; set<string> struct Projs {string nomprojet, time heures_hebdo} projs;

sites;

Employe :: travaille_pour;

set<Employe> a_emps inverse ajouter_emp(in string nouveau_enom) raises (enom_not_valid); changer_dir(in string nouveau_nom_dir;

in date datedebut);

void

} ;

Objets atomiques (définis par l'utilisateur)

◼Un attribut est une propriété qui décrit un aspect d'un objet. Sa valeur, généralement un littéral doté d'une structure simple ou complexe, est mémorisée dans l'objet. Mais la valeur d'un attribut peut également être l'identifiant d'un autre objet.

◼On peut même spécifier la valeur d'un attribut via des méthodes qui permettent de la calculer.

Objets atomiques (définis par l'utilisateur)

◼ Les

attributs

noss, datenaissance, sexe et age, et ceux de Service sont snom, snumero, dir, sites et projs.

de Employe

nom,

sont

◼ Les attributs dir et projs de Service ont une structure complexe et sont définis via le constructeur struct. ◼ En conséquence, la valeur dir de chaque objet Service aura deux composants: Directeur, dont la valeur est un OBJECT_ID qui référence l'objet Employe qui dirige le service et datedebut dont la valeur est une date.

◼ L'attribut sites de Service est défini via le constructeur set, puisque chaque objet Service peut avoir un ensemble de sites.

Objets atomiques (définis par l'utilisateur)

◼ Une relation est une propriété qui spécifie que deux

objets de la base sont liés.

◼ Dans le modèle objet de l'ODMG, seules les relations binaires sont explicitement représentées par une paire spécifiées via le mot clé de références relationship.

inverses

dans

lequel

◼ Dans l’exemple, une relation unit chaque Employe au relation il Service travaille_pour de Employe. Dans la direction opposée, chaque Service est lié à l'ensemble d'Employes qui travaillent dans le Service – par la relation a_emps de Service.

travaille

-la

Objets atomiques (définis par l'utilisateur)

◼ Le mot clé inverse spécifie que ces deux propriétés définissent une seule relation conceptuelle dans les deux directions.

◼ Grâce à la spécification de relations inverses, le système de l'intégrité base de données maintient automatiquement référentielle de la relation. Autrement dit, si la valeur travaille_pour d'un Employe e pointe Sur Services, alors la valeur de a_emps de Service doit inclure une référence à dans son ensemble de références.

◼ Si le concepteur de la base désire représenter une relation unidirectionnelle, il doit la modéliser sous forme d'attribut (ou d'opération); exemple: le composant Directeur de l'attribut dir de Service.

Objets atomiques (définis par l'utilisateur)

◼ Outre les attributs et les relations, le concepteur peut faire figurer des

opérations dans les spécifications de types d'objets (ou classes).

◼ Chaque type d'objet peut avoir un certain nombre de signatures d'opérations, qui spécifient le nom de l'opération, les types de ses arguments et éventuellement sa valeur de retour.

◼ Les noms d'opérations sont uniques pour chaque type d'objet, mais on peut les surcharger en faisant apparaître le même nom d'opération pour deux types d'objet distincts.

◼ La signature peut également spécifier les noms des exceptions qui peuvent se produire au moment de l'exécution. L'implémentation de l'opération contiendra le code destiné à lever ces exceptions.

◼ Dans

l’exemple,

seule opération (reaffecter_emp), et la classe Service en a deux (ajouter_emp et changer_dir).

classe Employe

a une

Plan

◼Préambule

◼Le modèle objet de l'ODMG

◼Objets et littéraux

◼Interfaces du modèle objet de l'ODMG ◼ Interfaces, classes et héritage

◼Le langage de définition d'objets ODL

◼Le langage de requête objet: OQL

Interfaces, classes et héritage

◼ Le modèle objet de l'ODMG possède deux concepts pour spécifier des types d’objets : les interfaces et les classes. De plus, il existe deux types de relations d'héritage.

◼ Nous étudierons d’abord les différences et les similitudes entre ces deux concepts. Pour suivre la terminologie de l'ODMG, nous employons le les mot les opérations, et nous parlons d'état pour propriétés (attributs et relations).

comportement

désigner

pour

Interface

◼ Une

interface

du comportement abstrait d'un type d'objets, qui définit les signatures des opérations

spécification

est

les

interface ◼ Bien que puissent d'état (attributs et relations), celles-ci ne peuvent pas être héritées.

spécifications d'une des

comprendre

propriétés

◼ Une interface est également non instanciable ; autrement dit, il est impossible de créer des objets qui correspondent à une définition d'interface.

Classe

d'objet,

◼Une classe spécifie à la fois

le comportement et l'état abstraits d'un est type instanciable, ce qui signifie que l'on peut instances d'objets correspondant à la définition de la classe.

créer des

mais

elle

Interfaces, classes et héritage

◼ Comme les interfaces ne sont pas instanciables, on les utilise principalement pour spécifier des opérations abstraites qui peuvent être héritées par des classes ou d'autres interfaces.

◼ C'est ce qu'on appelle l'héritage de comportement,

et il est spécifié par le symbole « : ».

◼ En conséquence, dans le modèle de l'ODMG, l'héritage de comportement nécessite que le super- type soit une interface, tandis que le sous-type peut être soit une classe, soit une autre interface.

Interfaces, classes et héritage

◼ Une autre relation d'héritage, nommée EXTENDS et spécifiée par le mot clé extends, sert pour l'héritage d'états et de comportements strictement entre classes.

◼ Dans un héritage EXTENDS, le supertype et le sous-type

peuvent tous deux être des classes.

◼ L'héritage multiple via EXTENDS n'est pas permis. Mais l'héritage multiple est autorisé pour l'héritage de comportement via « : ».

◼ Une interface peut donc hériter des comportements de plusieurs autres interfaces et hériter de l'état et du comportement d'au plus une autre classe via EXTENDS.

Extensions

◼ Dans le modèle de l'ODMG, le concepteur d'une base de données peut déclarer une extension pour tout type d'objet défini via une déclaration de classe.

◼ Dans notre exemple, les classes Employe et Service ont respectivement

nommées

des tous_employes et tous_services.

extensions

◼ Cela revient à créer deux objets

-l'un de type Set<Employe> et le second de type Set<Service> - et à les rendre persistants en les nommant tous_employes et tous_services.

Extensions

◼ Dans le modèle de l'ODMG, le concepteur d'une base de données peut déclarer une extension pour tout type d'objet défini via une déclaration de classe.

◼ Dans l’exemple ci-dessus,

les classes Employe et Service ont des extensions nommées respectivement tous_employes et tous_services.

◼ Cela revient à créer deux objets

-l'un de type Set<Employe> et le second de type Set<Service> - et à les rendre persistants en les nommant tous_employes et tous_services.

Clé

◼ Une classe possédant une extension peut avoir une ou plusieurs clés. Une clé regroupe une ou plusieurs propriétés (attributs ou relations) dont les valeurs doivent obligatoirement être uniques pour chaque objet de l'extension.

◼ Par exemple, la classe Employe a pour clé l'attribut noss (la valeur de noss de chaque objet Employe de l'extension doit être unique), et la classe Service a deux clés distinctes: snom et snumero (chaque Service doit avoir un snom et un snumero uniques).

Clé

◼ Dans le cas d'une clé composite constituée de plusieurs propriétés, les propriétés qui forment la clé clé composite se nomme clé composée dans le rapport de l'ODMG

parenthèses. Une

apparaissent

entre

◼ Par exemple, si une classe Vehicule possédant une extension tous_les_vehicules a une clé composée d'une combinaison de deux attributs departement et numero_de_permis, ces derniers seront placés (departement, entre numero_de_permis) dans la déclaration de la clé.

parenthèses

Clé

◼ Dans le cas d'une clé composite constituée de plusieurs propriétés, les propriétés qui forment la clé clé composite se nomme clé composée dans le rapport de l'ODMG

parenthèses. Une

apparaissent

entre

parenthèses

Institut Supérieur d’Informatique - Université Tunis El Manar

Module 4 : Standards et langages des bases de données à objets (Section 1)

Riadh ZAAFRANI Novembre 2020

1ère année MP2L

Merci pour votre attention

Standards et Langages des Bases de Données à Objets

Standards et Langages des Bases de Données à Objets