Erfaring og veiledning (kontekster)

Nous avons décrit jusqu’ici un modèle capable de gérer des informations évolutives générées par des processus variés. Ces informations correspondent à autant de points de vue sur les documents et les objets métier du système. L’objet de cette section est de fournir un emplacement pour les données concrètes, c’est-à-dire les valeurs de facettes,T . Comme nous allons le voir, le système de types que nous utili- sons pour décrire les facettes,T , est très proche de la proposition de l’Object Data Management Group (ODMG) [22]. Une approche de typage stricte facilite une utilisation automatique des données collectées et analysées, alors qu’un ensemble riche de types fournit l’expressivité nécessaire à leur description.

8.3.1 Différents types

Nous pouvons classer les types de données que nous utilisons en quatre catégories en fonction de leur arité : types atomiques, unaires, binaires etn-aires.

Types atomiques. Les types atomiques sont les types de base du modèle : booléen (boolean), entier (integer), réel (real), caractère (char) et chaîne de caractères (string). À cette liste de base, nous ajoutons le type date. Il peut être facilement simulé en utilisant une composition de types de base, mais nous préférons en faire un type atomique à part entière pour faciliter son utilisation. C’est en effet un type fréquemment utilisé dans les applications de traitement documentaire.

Tous les modèles ont généralement une liste de types de base permettant de construire des types de plus haut niveau. Souvent, ces types sont proches de l’implémentation. Par exemple, le langage C [56] décompose les entiers en short, int et long, et les réels en float, double et long double, en fonction des valeurs maximales désirées. Tandis qu’en SQL [29], l’utilisation de numeric permet d’indiquer la précision désirée.

Dans le cadre de notre modèle, nous préférons nous abstraire de l’implémentation effective et utiliser des types plus génériques. Lors de la traduction dans un modèle particulier (cf. chapitre 9), nous pourrons ainsi exploiter au mieux les types disponibles. Les contraintes ayant été exprimées par le concepteur (par exemple un intervalle de valeurs possibles pour des entiers) nous permettront, de plus, d’affiner notre choix.

Types unaires. Les types unaires représentent tous des collections d’éléments ayant un type donné. Aux côtés des types « classiques » que sont ensemble (set), liste (list) et famille (bag), nous introduisons des types basés sur des graphes : arbre (tree), graphe (graph) et en particulier graphe acyclique orienté (dag).

CHAPITRE 8 — DOAN : Un modèle flexible 83

Ces derniers sont en effet très utiles aux applications d’intelligence économique qui nous intéressent pour représenter notamment des hiérarchies, des organigrammes ou encore des ontologies. Ils pourraient être simulés (ex. : tree(T ) ≡ map(T, T )), mais le fait de les représenter à part entière va nous permettre de répondre à plusieurs questions d’implémentation importantes pour obtenir de bonnes performances (cf. chapitre 9).

Ces collections nous permettent aussi de représenter les attributs multivalués évoqués en section 3.1.1. La distinction entre les types ensemble, liste et famille nous permet de plus de préciser si les valeurs doivent être distinctes ou ordonnées. Des contraintes de cardinalité peuvent ensuite préciser les nombres minimum et maximum de valeurs.

Types binaires. Nous introduisons deux types binaires qui imitent le modèle relationnel et prennent en compte les dépendances fonctionnelles : l’application (map) et la bijection (bijection).

Typesn-aires. Les types n-aires du modèle sont aussi au nombre de deux. Le n-uplet (tuple) nous permet de décrire des compositions de types hétérogènes et donc de représenter les attributs composites introduits en section 3.1.1. La relation (relation), qui imite elle aussi le modèle relationnel, n’est qu’un raccourci pour un ensemble den-uplets (relation(T1, T2, . . . , Tn) = set(tuple(T1, T2, . . . , Tn))).

L’ensemble de ces types permet au concepteur de décrire de façon précise les facettes composant son modèle. Ainsi, avec ce système et d’après la définition (8.2), l’exemple (8.8) est défini par :

facetP ersonne is tuple(pr´enom : string, nom : string)

Pour plus de simplicité, nous pouvons considérer la notion de facette comme un type à part entière et utiliser une syntaxe proche de l’ODMG pour écrire alors :

P ersonne : facet(tuple(pr´enom : string, nom : string))

La composition et l’imbrication de types permet de décrire des facettes plus complexes, comme l’illustre la facette suivante :

Document : facet(tuple(titre : string, date : date,

auteurs : list(auteur : tuple(pr´enom : string, nom : string)), contenu : list(string),

annotations : set(annotation : tuple(auteur : tuple(pr´enom : string, nom : string), contenu : list(string)))))

Nous donnons ici la description de données récoltées sur des documents et leurs auteurs. Plusieurs types complexes sont utilisés dans cet exemple qui montre aussi comment ils peuvent être arbitrairement imbriqués : une facette contenant unn-uplet, dont un attribut est un ensemble de n-uplets, dont un attribut est une liste de chaînes de caractères.

8.3.2 Références

Comme nous l’avons introduit dans le chapitre 2, l’information que nous devons traiter est fortement « connectée ». Cela se traduit par la présence de liens entre les entités via leurs facettes : unDOCUMENT est, par exemple, écrit par un ou plusieursAUTEUR(s), unEMPLOYÉtravaille dans uneENTREPRISE, etc. Parmi les différentes possibilités de représenter les associations que nous avons étudiées en sec- tion 3.1.2, nous avons porté notre choix sur la plus simple : des références unidirectionnelles entre facettes uniquement. Nous introduisons donc le nouveau type ref, limité aux facettes. Le type ref(P ersonne) par exemple, correspond au type des références à des entités supportant la facettePERSONNE. La restriction des références aux facettes nous permet, de plus, d’utiliser le nom de la facettef comme raccourci pour le type ref(f ). On a ainsi pour l’exemple précédent : ref(P ersonne) ≡ P ersonne.

Ce choix nous permet d’utiliser les références comme un type unaire directement disponible pour définir les facettes (sur le même principe que UML, cf. section 4.2). Par contre, si le concepteur veut modéliser une association ayant une arité supérieure à deux, il est nécessaire de la réifier en une facette dont le type sera unn-uplet de références.

Cette approche par réification nous permet de simuler les associations simplement. Elle offre en outre l’avantage d’autoriser la création de facettes sur des instances d’associations et même sur des associa- tions entre associations. Par exemple, une instance de l’associationMARIAGE (entre deuxPERSONNES, unHOMMEet uneFEMME) est CÉLÉBRÉdans une église. L’associationCÉLÉBRATIONlie donc l’asso- ciationMARIAGEà la facetteÉGLISE. Qui plus est, d’autres facettes peuvent aussi être attachées :DATE, TÉMOINS,MUSIQUES JOUÉES, etc.

Reprenons l’exemple de la facette DOCUMENTque nous venons d’introduire au-dessus. Plutôt que d’utiliser de simples chaînes de caractères pour en décrire les auteurs, les concepteurs feront en général le choix de les modéliser. Imaginons que nous disposions d’une facettePERSONNEet d’une facette plus préciseAUTEURl’impliquant. Si les auteurs de documents sont forcément identifiés comme des instances deAUTEUR, mais que toute personne peut écrire une annotation, la facetteDOCUMENTdevient alors :

Document : facet(tuple(titre : string, date : date,

auteurs : list(auteur : AUTEUR), contenu : list(string),

annotations : set(annotation : tuple(auteur : PERSONNE), contenu : list(string)))))

8.3.3 Comparaison ODMG

Les types que nous venons d’introduire sont très proches du modèle ODMG [22]. Nous pouvons en observer une comparaison dans la table 8.1.

L’introduction dans les sections précédentes du type de données facet (avec ses opérations associées – création, attachement, détachement – et ses contraintes) est la principale différence avec le modèle ODMG.

Une autre différence importante est que nous fournissons des types de données abstraits et non des classes avec des méthodes définies par l’utilisateur. Tous les types de DOAN viennent avec les opérations standard permettant de manipuler leurs valeurs (création, destruction, insertion, suppression et modifi- cation). Des points d’insertion sont aussi fournis pour permettre le déclenchement d’une ou plusieurs

CHAPITRE 8 — DOAN : Un modèle flexible 85

ODMG commun DOAN

array, bitstring

integer, boolean, string. . . tuple/struct

list, set, bag, map/dictionary ref

relation, bijection tree, dag, graph

facet

Table 8.1 – Types ODMG et DOAN

actions utilisateur quand une opération standard est exécutée, sur le même principe que certains modèles à base de frames [14, 88] (cf. annexe B).

Une troisième différence est relative à l’ensemble des types standards utilisés. Tout d’abord, nous introduisons des types de données qui imitent le modèle relationnel, c’est-à-dire la relation, la bijection et l’application (cette dernière est aussi disponible en ODMG via le type dictionary). Ensuite, les types à base de graphe sont utiles pour les applications d’intelligence économique envisagées.

Les types spécifiques à ODMG peuvent être simulés : array(T ) ≡ map(integer, T ) et bitstring(T ) ≡

set(T ). La différence se situe au niveau de l’implémentation et non de la spécification, particulièrement pour bitstring.

Enfin, les références (type ref dans ODMG) sont mono-directionnelles dans notre modèle alors qu’elles sont bi-directionnelles dans le modèle ODMG.