Modèle de données d’accès aux données d’une BDBO

Le modèle de données Encore ne peut pas être utilisé pour une BDBO sans adaptation. En effet, alors que le modèle Encore est conçu selon une approche orientée-objet afin de permettre d’accéder aux données depuis un schéma orienté-objet, le modèle de données du langage OntoQL est basé sur le modèle relationnel-objet et permet d’accéder aux données depuis une ontologie. En conséquence, le modèle de données Encore doit être adapté d’une part, à l’approche relationnelle-objet, et, d’autre part, aux différences entre une ontologie et un schéma orienté-objet.

Les approches relationnelles-objets et orientées-objets diffèrent sur leur façon de voir les données. Dans l’approche orientée-objet, toute donnée est considérée comme un objet ayant un identifiant géré par

27Nous utilisons le symbole 2C

le système. Cet identifiant est utilisé pour déterminer si deux objets sont égaux. L’approche relationnelle-objet est différente. Seules les instances des types utilisateur ont un identifiant qui peut être manipulé par un utilisateur. Les instances des autres types de données sont considérées comme des valeurs sans iden-tifiant. Le modèle de données d’une BDBO doit donc distinguer les instances des classes, qui possèdent un identifiant, des instances des autres types de données, qui n’en possèdent pas.

D’autre part, nous avons vu que la principale différence entre un schéma orienté-objet et une ontolo-gie est qu’une ontoloontolo-gie décrit les données alors qu’un schéma orienté-objet les prescrit. Cette distinction nous a conduit à introduire la notion d’extension. Chaque classe peut être associée à une extension qui en stocke les instances. Cette extension peut ne comprendre qu’un sous-ensemble des propriétés appli-cables sur cette classe. Le modèle de données d’une BDBO doit donc également représenter la notion d’extension.

En prenant en compte ces adaptations, le modèle de données qui permet d’accéder aux données d’une BDBO peut-être défini comme un 13-uplets < ADTC, VC, Class, I, Property, directSuperCla-sses, scope, range, Extent, usedProperties, nomination, typeI, valI>où :

– ADTC contient les types primitifs (Int, String, etc.), les classes des ontologies (Class) et les types paramétriques SET, MULTISET, TUPLE, REF et ARRAY (ces deux derniers types sont décrits ultérieurement) ;

– VC est l’ensemble des valeurs des types de ADTC. Il contient les instances des classes (avec un identifiant) et les valeurs des types primitifs et paramétriques (sans identifiant) ;

– Class est l’ensemble des classes de l’ontologie. Comme dans la plupart des modèles d’ontologies, nous supposons l’existence d’une classe racine ObjectC ;

– I est l’ensemble des instances des classes de l’ontologie. Chaque instance possède un identifiant unique dont la valeur est donnée par la propriété oid ;

– Property est l’ensemble des propriétés de l’ontologie. Il contient la propriété oid définie sur la classe racine ObjectC. Cette propriété retourne un entier du type primitif Oid ;

– directSuperClasses : Class → 2^Classassocie une classe à ses super-classes directes ;

– scope : Property → Class et range : Property → ADTCdéfinissent respectivement le domaine et le codomaine de chaque propriété ;

– Extent est l’ensemble des extensions des classes de l’ontologie ;

– usedProperties : Extent → 2Property retourne les propriétés utilisées pour décrire les ins-tances d’une classe (l’ensemble des propriétés qui ont une valeur pour ses insins-tances) ;

– nomination : Class → Extent est une fonction partielle. Elle associe une classe à son éven-tuelle extension. L’ensemble des propriétés utilisées dans l’extension d’une classe doit être un sous-ensemble des propriétés applicables sur cette classe ;

– typeI : I → Extent associe à chaque instance l’extension de la classe à laquelle elle appartient ; – valI : I × Property → VC donne la valeur d’une instance i pour une propriété p qui doit être

utilisée dans l’extension de sa classe de base (p ∈ usedProperties(typeI⁻¹(i))).

Nous avons introduit deux nouveaux types paramétriques dans ce modèle de données : les types ARRAYet REF définis dans le modèle relationnel-objet. ARRAY permet de construire des collections dont

les éléments sont indexés. Il est défini avec la fonction get_value(index) qui permet de retrouver l’élément d’une collection à un index donné. L’utilisation de cette fonction peut être abrégée en utilisant la notation v[index] où v est une valeur de type ARRAY. REF[C] est un type de données constitué de l’ensemble des identifiants des instances d’une classe C. Il est défini avec la fonction DEREF : REF[C] → C qui retourne une instance d’une classe à partir de son identifiant.

Ce modèle de données suivant l’approche relationnelle-objet, les tuples et les collections n’ont pas d’identifiant. Il est donc nécessaire de préciser comment est défini l’opérateur d’égalité sur ces valeurs. Deux tuples sont égaux si et seulement si ils ont les mêmes valeurs d’attributs. Deux collections sont égales si et seulement si elles ont la même cardinalité et si ses éléments sont deux à deux égaux. Pour les collections indexées (ARRAY), les éléments aux mêmes index doivent être égaux.

Exemple. Pour illustrer le modèle de données défini dans cette section, nous présentons la formalisation de l’exemple présenté sur la figure 5.1. Pour simplifier, nous n’avons représenté sur cette figure que les principaux éléments concernant la classe Item de l’ontologie SIOC. Cette classe est associée à une extension nommée par commodité Extent_Item. Elle est constituée des propriétés oid et name et contient une instance. La représentation de ces données en utilisant le modèle de données présenté dans cette section est la suivante :

‘Logo de l’ontologie SIOC’ 1

name oid

Extent_Item

‘Logo de l’ontologie SIOC’ 1

name oid

Extent_Item Container 1 _{has_container} ^Item

Resource name: String has_reply 0..1 ObjectC oid: Oid

F. 5.1 – Exemple de formalisation de la classe Item de l’ontologie SIOC

– ADTC = {Oid, String, REF[Item], REF[Container], Item, Container, Resource, ObjectC } ;

– VC = { 1, ’Logo de l’ontologie SIOC’, $1 } où $1 est l’instance représentée par l’ensemble des couples (propriété, valeur) suivant { (oid, 1), (name, ’Logo de l’ontologie SIOC’) };

– Class = { Item, Container, Resource, ObjectC } ; I = { $1 } ; – Property = { oid, name, has_reply, has_container } ;

– directSuperClasses(Item) = { Resource } ; – scope(oid) = ObjectC ; range(oid) = Oid ;

– scope(name) = Resource ; range(name) = String ;

– scope(has_container) = Item ; range(has_container) = REF[Container] ; – EXTENT = { Extent_Item } ; usedProperties(Extent_Item) = { oid, name } ; – nomination(Item) = Extent_Item ; typeI($1) = Extent_Item ;

– valI($1, oid) = 1 ; valI($1, name) = ’Logo de l’ontologie SIOC’.