Déploiement de l’entrepôt sur une BDBO OntoDB

Afin d’évaluer la faisabilité de la conception physique, nous avons déployé notre entrepôt sur la BDBO OntoDB qui suit une architecture de type III. Ce type d’architecture comporte quatre principales parties distinctes : le méta-schéma ontologique, le schéma ontologique, le méta-schéma des données et le schéma des données. La nouvelle BDBO OntoDB que nous avons créée implémente le schéma de l’ontologie conceptuelle. L’articulation entre l’ontologie conceptuelle et l’ontologie linguistique (qui est externe à OntoDB) reste valide et se fait via des labels. Nous avons commencé par étendre le méta-schéma ontologique par le modèle pivot des besoins que nous avons défini. Cette extension est illustrée en figure 7.6. Le schéma de l’entrepôt est ensuite traduit en un schéma relationnel horizontal (schéma logique supporté par OntoDB). L’extension du méta-schéma d’OntoDB avec le schéma de l’entrepôt (Modèle pivot) se réalise par la création d’une table Entity pour chaque classe du schéma pivot. OntoDB fournit son

Figure 7.6 – La BDBO OntoDB étendue par le schéma pivot de l’entrepôt

propre langage de définition et de manipulation des Ontologies [81] qui est le langage OntoQL. Nous avons ainsi commencé par définir des requêtes OntoQL pour l’extension du méta-schéma d’OntoDB. Voici la syntaxe de la requête qui permet la création des entités :

CREATE Entity #[nom de l’entité] ([nom d’attribut, type d’attribut (Property)])

Dans ce qui suit, nous présentons des exemples de quelques requêtes OntoQL définies afin d’étendre le méta-schéma d’OntoDB avec les entités du schéma pivot de l’entrepôt :

Create Entity #Task(#its_properties REF (#Property) Array)

Create Entity #Criteria (#its_properties REF (#Property) Array)

Create Entity #Result(#its_properties REF (#Property) Array)

Create Entity #Location(#its_properties REF (#Property))

Create Entity #Time(#its_properties REF (#Property))

Create Entity #Requirement(#Property (#Requirement_ID Int, #Requirement_Name String, #Description String, #Purpose_Req String, #Context_Req String, #Priority_Req String, #Status String, #Type_Req String),

#ResponsibleOf REF(#Actor), #HasTask REF (#Task), #HasCriteria REF (#Criteria),

#HasLocation REF (#Location),

#ExpressedIn REF (#Time), #Achieves REF (#Result))

Le chargement des instances ontologiques dans ce schéma étendu s’est fait via le processus ETL. Cette implémentation a nécessité la traduction des opérateurs ETL en requêtes OntoQL de la même façon que pour la BDBO Oracle.

L’extraction des besoins à partir de l’entrepôt s’effectue avec des requêtes d’interrogation

OntoQL dont la syntaxe générale est la suivante [81] :

hquery speci f icationi ::= hselect clauseih f rom clausei[hwhere clausei]

[hgroup by clausei][hhaving clausei][horder by clausei] [hnamespace clausei][hlanguage clausei]

Nous remarquons que la structure d’une règle OntoQL ressemble à la structure d’une règle SQL. La règle est composée d’un ensemble d’attributs appartenant à l’un des types suivants : primitif, collection, référence ou une classe ontologique.

Par exemple, la requête suivante permet l’extraction des besoins provenant d’une source située géographiquement en France:

Select g.#Description_Req from #Requirement g, Lacation L where L.#State="French";

Nous décrivons dans la section suivante notre approche d’analyse multidimensionnelle de l’en-trepôt déployé, en définissant et en utilisant un cube sur les besoins entreposés. Cette étape d’analyse constitue la dernière phase du cycle de vie d’un projet d’entreposage.

4 Exploration et analyse des besoins entreposés

Notre approche couvre également la phase d’exploitation des besoins qui permet aux déci-deurs de faire diverses analyses sur les besoins entreposés.

La première solution est d’effectuer des analyses via des requêtes Sparql. Plus précisément,

nous avons utilisé des requêtes SPARQL endpoints⁶⁹. SPARQL endpoints est un service du

protocole SPARQL qui permet aux utilisateurs d’interroger une base de connaissances via le langage SPARQL. SPARQL endpoints est conçu avec une interface conviviale vers une base de connaissances. Nous avons défini des requêtes de type agrégation.

4. Exploration et analyse des besoins entreposés Exemple 19

L’exemple suivant montre une requête d’agrégation qui permet de calculer le nombre de besoins que contient l’entrepôt :

CONSTRUCT {

?req dw:ReqCount ?ReqCount. ?req dw:Requirement ?IDReq.

?req dw:Task ?task. ?req dw:Actor ?IDActor. ?req dw:Location ?LocId.} WHERE {

?req rdf:type s:Requirement . ?req s:Requirement ?IDReq .

?req s:Task ?task . ?req s:Actor ?IDActor . ?req s:Location ?LocId .}

Exemple 20

Le second exemple ci-dessous permet au décideur de calculer le nombre de besoins exprimés par un concepteur situé géographiquement a PARIS (France) et de les regrouper de façon ordonnée par période. La requête SPARQL correspondant à ce besoin est la suivante :

PREFIX qb: <http://purl.org/linked-data/cube\#> PREFIX req: <http://req.org/schemas/>

SELECT ?req ?loc ?time (COUNT(?REQ) AS ?requirementcount)

WHERE {

{ ?li a qb:Observation;

qb:dataSet <http://req.org/data/dataset-aggview2>;

req:Location ?loc ; req:Time ?time ; req:revenue ?REQ.} FILTER(?Loc \= ’PARIS’)}

GROUP BY ?loc ?time

ORDER BY ?time DESC(?requirementcount)

Pour l’exploitation de notre entrepôt de besoins, nous avons aussi recours à une solution al-ternative ne nécessitant pas une maitrise de la technologie d’entreposage. Cette solution consiste

à utiliser QB4OLAP70qui est un vocabulaire supportant les analyses OLAP. Ce langage est basé

sur le Data cube vocabulary (QB) qui est le vocabulaire fourni par le W3C pour la publication des données multidimensionnelles en utilisant le standard RDF.

Le vocabulaire utilisé dans QB4OLAP étend le vocabulaire de QB et offre la possibilité

de définir les cubes OLAP dans RDF. Il offre également la possibilité de mettre en oeuvre

les opérateurs OLAP (par exemple : Roll-up, Slice, and Dice) comme des requêtes SPARQL directement applicables sur des représentations RDF.

Dans ce qui suit, nous présentons quelques requêtes QB4OLAP qui permettent la définition du cube multidimensionnel de besoins.

prefix req: <http://www.owl-ontologies.com/OntoReqUnivWordnet.owl\#> PREFIX qb: <http://purl.org/linked-data/cube\#>

PREFIX qb4o: <http://purl.org/olap\#>

//Definir le cube des besoins et ses dimensions req:RequirementCube a qb:DataStructureDefinition; rdfs:label "Requirement" ;

rdf:type req:Requirement. //Dimensions

qb:component qb:dimension req:Location. qb:component qb:dimension req:Time. qb:component qb:dimension req:Actor. qb:component qb:dimension req:Task. qb:component qb:dimension req:Criterion. qb:component qb:dimension req:Result. qb:component qb:measure req:context. //Définition des mesures

qb:component qb:measure req:RquirementCount; qb4o:AggregateFuction qb4o:Count; rdf:predicate req:IDreq;

qb:component qb:measure req:ResultReqAvg; qb4o:AggregateFuction qb4o:avg ; rdf:predicate req:IdResult;

//Définition des attributs

qb:component qb:attribute req:DescriptionReq. qb:component qb:attribute req:PriorityReq. qb:component qb:attribute req:Status. qb:component qb:attribute req:TypeR. qb:component qb:attribute req:context.

Les données obtenues dans une structure QB4OLAP reçoivent des faits qui peuvent être sto-ckés sous la forme des instances qb:Observation (dans la terminologie OLAP cela correspond à des faits indexés par des dimensions). Toutes les instances de dimension sont stockées sous forme de triplets. Les valeurs agrégées pour les mesures sont calculées sur la base des types de fonctions qb4o:AggregateFunction (une fonction d’agrégation peut être AVG, COUNT, MAX, MIN, SUM). Chaque instance du fait représente un point dans l’espace multidimensionnel formé par les dimensions. Pour chaque point, un ensemble de valeurs de mesure est enregis-tré.

Par exemple, la requête QB4OLAP correspondant au besoin cité précédemment (qui permet au décideur de calculer le nombre de besoins exprimés par un concepteur situé géographique-ment a Paris (France) et de les regrouper de façon ordonnée par période) :

<http://www.owl-ontologies.com/OntoReqUnivWordnet1.owl\#R1> a qb:Observation;

qb:dataSet req:RequirementDataWarehouse;

req:RequirementCount 36;

req:Country <http://www.owl-ontologies.com/OntoReqUnivWordnet1.owl\#21> .

req:CountryName "Paris".

5 Evaluation : ETL et raisonnement

Notre évaluation concerne les performances du processus ETL ainsi que le mécanisme de raisonnement (partie importante du processus ETL). Nous commençons par rappeler

l’envi-ronnement d’implémentation utilisé. Nous effectuons cette évaluation pour les deux scénarios

5. Evaluation : ETL et raisonnement