Traduction des opérateurs ETL

Afin de peupler le schéma de l’entrepôt par les instances des sources, nous avons exploité l’algorithme ETL que nous défini. Chaque opérateur est représenté par une requête Sparql. Dans ce qui suit, nous donnons la requête correspondante à chaque opérateur ETL. Notons que nous considérons req comme le nom de l’espace de stockage du schéma de l’entrepôt . Nous illustrons nos propos avec des exemples extraits de l’étude de cas présentée précédemment, où l’url de l’ontologie est la suivante :

PREFIX req:< htt p : //www.owl − ontologies.com/OntoReqUnivWordnet.owl# >.

– l’opérateur Retrieve : l’opérateur Retrieve permet de récupérer les instances "instances-Besoin" appartenant à l’une des classes "ClassREQ" de l’entrepôt. La traduction de l’opé-rateur en SPARQL donne :

Select ?instancesBesoin# Where

{?instancesBesoin# rdf:type ESBFSpace:ClassREQ}

Exemple 10

Pour récupérer l’ensemble des besoins intégrés, nous utilisons la requête suivante : PREFIX req:<http://www.owl-ontologies.com/OntoReqUnivWordnet.owl\#>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#>

\\RETREIVE: permet de récupérer l’ensemble des besoins. Select ?instancesREQ where

{?InstancesREQ rdf:type req:Requirement}

– l’opérateur Extract : l’opérateur Extract permet l’extraction (projection verticale) des ins-tances "instanceBesoin" de la classe "ClassREQ" en utilisant certaines composantes du besoin avec une condition (Condition) sur des propriétés (DataProperty). Cet opérateur se traduit en SPARQL comme suit :

Select ?instancesBesoin ?Property where

{?InstancesBesoin# prefix:property ?Property ?Property Condition}

Exemple 11

Extraire les besoins (InstanceREQ) et leurs priorité, tel que ces besoins ont la priorité (Prio-rity_Req) la plus élevée (High), se traduit en SPARQL par :

PREFIX req:<http://www.owl-ontologies.com/OntoReqUnivWordnet.owl\#>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#>

\\EXTRACT: permet d’effectuer une projection sur les des besoins fonctionnels suivant une condition Condition.

3. La conception physique de l’entrepôt {?instanceREQ# req:hasPriority ?Priority\_Req

?InstanceREQ# rdf:type req:Requirement.?InstanceREQ req:Priority_Req=’high’}

– l’opérateur Union : l’opérateur Union permet l’unification des besoins "instanceBesoin"

appartenant à des classes de sources différentes "ClassREQ1" et "ClassREQ2", avec ou

sans conditions. Cet opérateur se traduit en SPARQL comme suit : Select ?instancesBesoin# where

{?InstancesBesoin# rdf:type prefix1:ClassREQ1}. Union

{?InstancesBesoin# rdf:type prefix2:ClassREQ2}. Exemple 12

l’union des besoins (InstanceREQ) que contiennent des relations de contenance entre eux dans l’ESBF se traduit en SPARQL par :

PREFIX req1:<http://www.owl-ontologies.com/ontoS1.owl\#> PREFIX req2:<http://www.owl-ontologies.com/ontoS2.owl\#>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#>

\\UNION: permet l’union des besoins fonctionnels Select ?instanceREQ# where

{?instanceREQ# rdf:type req1:ClassREQ}. Union

{?InstancesREQ# rdf:type req2:ClassREQ}.

– l’opérateur Merge : l’opérateur Merge permet la fusion des besoins "instanceBesoin" ap-partenant à deux classes "ClassREQ1" et "ClassREQ1" de la même source, avec ou sans conditions. Cet opérateur est utile lorsque l’on souhaite fusionner des besoins dans la staging area. Cet opérateur se traduit en SPARQL comme suit :

Select ?instancesBesoin# where

{?InstancesBesoin# rdf:type prefix:ClassREQ1}. Union

{?InstancesBesoin# rdf:type prefix:ClassREQ2}.

Exemple 13

PREFIX req:<http://www.owl-ontologies.com/OntoReqUnivWordnet.owl\#>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#>

\\MERGE: permet de fusionner les besoins fonctionnels dans la même source Select ?instanceREQ# where

{?instanceREQ# rdf:type req:ClassREQ1}. Union

{?InstancesREQ# rdf:type req:ClassREQ2}.

– l’opérateur Join : l’opérateur Join permet la jointure des besoins ayant des relations entre eux. Cet opérateur se traduit en SPARQL comme suit :

Select ?instancesBesoin1 ?instancesBesoin2 where {?InstancesBesoin1 rdf:type prefix:ClassREQ.

?InstancesBesoin2 rdf:type prefix:ClassREQ.}.

Exemple 14

La jointure des besoins (InstanceREQ) sur la base des relations d’ordonnancement (Re-quires) entre eux se traduit en SPARQL par :

PREFIX req:<http://www.owl-ontologies.com/OntoReqUnivWordnet.owl\#>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#>

Select ?instancesREQ1 ?instancesREQ2 where

{?instancesREQ1 rdf:type req:Requirement.

?instancesREQ2 rdf:type req:Requirement.}.

{?instancesREQ1 req:Require ?instancesREQ2}

– l’opérateur DD : l’opérateur DD, que nous avons défini pour les besoins fonctionnels, permet la détection et la suppression des besoins "instanceBesoin" en doubles appartenant à la classe "ClassBesoin" de l’ESBF. Cet opérateur se traduit en SPARQL par :

Select Distinct ?instancesBesoin# where

{?InstancesBesoin# rdf:type ESBFSpace:ClassREQ.?InstanceBesoin#}

Exemple 15

Supprimer les besoins (InstanceREQ) en double appartenant à la classe "Requirement" de l’ESBF se traduit en SPARQL par :

PREFIX req:<http://www.owl-ontologies.com/OntoReqUnivWordnet.owl\#>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#>

\\DD: permet de détecter et de supprimer les besoin fonctionnels en double.

Select Distinct ?instanceREQ where

{?InstanceREQ rdf:type req:Requirement.?InstanceREQ}

– l’opérateur Aggregate : l’opérateur Aggregate permet l’agrégation des besoins sur la base

d’une fonction F (F={COUNT, AVG, MIN, MAX, SUM, etc.}), appartenant à la classe

"ClassBesoin". Cet opérateur se traduit en SPARQL comme suit : Select (Count(?instancesBesoin) AS?count)

where

{?InstancesBesoin rdf:type prefix:ClassREQ} Group By ?InstancesBesoin

Exemple 16

Calculer le nombre de besoins (InstanceREQ) de l’entrepôt se traduit en SPARQL par : PREFIX req:<http://www.owl-ontologies.com/OntoReqUnivWordnet.owl\#>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#>

\\AGREGATE: permet l’agrégation des besoins suivant une fonction F.

Select (Count(?InstancesREQ) AS?count) where

{?InstancesREQ rdf:type req:Requirement} Group By ?InstancesREQ

3. La conception physique de l’entrepôt – l’opérateur Filer : l’opérateur Filter permet de filtrer les besoins (instancesBesoin) auto-risant uniquement ceux qui vérifient certaines conditions "Cond". Cet opérateur se traduit en SPARQL par la requête :

Select ?instancesBesoin# ?P where

{?instancesBesoin# rdf:type prefix:ClassREQ ?instancesBesoin# prefix:property ?P

FILTER (?P, "Cond")}

Exemple 17

Filtrer les besoins (instanceREQ) dans la classe "Requirement" de l’entrepot autorisant

seulement les besoins que contiennent l’action Action=create se traduit en SPARQL par :

PREFIX req:<http://www.owl-ontologies.com/OntoReqUnivWordnet.owl\#>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#>

\\FILTER: permet de filtrer l’ensemble de besoins entrants selon la propriété P. Select ?instanceREQ# ?Action where

{?InstanceREQ rdf:type req:Requirement ?InstanceREQ req:hasAction ?Action FILTER (?Action, "create")}

– l’opérateur Store : l’opérateur Store permet de stocker (charger) les besoins (instancesBe-soin) dans la data staging ou dans l’entrepôt final. Cet opérateur se traduit en SPARQL par la requête :

INSERT {prefix:ClassREQ ?instancesBesoin}

Exemple 18

La requête Sparql pour stocker les besoins dans la classe "Requirement" de l’entrepôt se traduit en SPARQL par :

PREFIX req:<http://www.owl-ontologies.com/OntoReqUnivWordnet.owl\#>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#>

INSERT {req:Requirement ?instancesREQ}

Par ailleurs, pour implémenter les opérateurs de raisonnement (identification, inférence et vérifi-cation de la consistance), nous avons mis en place des déclencheurs (triggers) qui implémentent la base de règles de raisonnement que nous avons définie. Nous présentons dans ce qui suit des exemples des triggers appliqués :

– l’opérateur Identification : l’exemple suivant illustre le code qui permet d’identifier les relations de conflits entre les besoins :

Create or replace TRIGGER REQUIREMENT\_RELATION\_IDENTIFICATION BEFORE INSERT OR DELETE OR UPDATE ON university\_rdf\_data BEGIN

//Création de la base des règles d’identification EXECUTE SEM\_APIS.CREATE\_RULEBASE(’identif\_rb’);

EXECUTE SEM\_APIS.CREATE\_RULES\_INDEX(’rdfs\_rix\_university’, SEM\_Models(’university’),SEM\_Rulebases(’OWLPRIME’,’identify\_rb’)); //Insertion de la règle définie

INSERT INTO mdsys.semr\_identif\_rb VALUES(’rule’,’(?R1 :ComposedOfTask ?T1) (?R2 :ComposedOfTask ?T2) (?T1 :TaskComposedOfAction ?A1) (?T2 :TaskComposedOfAction ?A2) (?A1 :Antonym ?A2)’, NULL,

’(?R1 :conflictwith ?R2)’, SEM\_ALIASES(SEM\_ALIAS(’’, ’http://www.owl-ontologies.com/OntoReqUnivWordnet1.owl\#’))); Commit;

//Génération des relations en exploitant la règle définie EXECUTE SEM\_APIS.CREATE\_ENTAILMENT(’rdfs\_rix\_university’, SEM\_MODELS(’university’),SEM\_RULEBASES(’OWLPRIME’,’identify\_rb’)); END;

– l’opérateur Inference : l’exemple suivant illustre un code qui permet d’inférer les relations

Refinesentre les besoins :

Create or replace TRIGGER REQUIREMENT\_RELATION\_INFERENCE BEFORE INSERT OR DELETE OR UPDATE ON university\_rdf\_data BEGIN

//Création de la base des règles d’inférence EXECUTE SEM\_APIS.CREATE\_RULEBASE(’infer\_rb’);

//Index qui associent la base de règles au modèle de l’ontologie EXECUTE SEM\_APIS.CREATE\_RULES\_INDEX(’rdfs\_rix\_university’, SEM\_Models(’university’),SEM\_Rulebases(’OWLPRIME’,’infer\_rb’)); //Insertion de la règle définie

INSERT INTO mdsys.semr_infer_rb VALUES(’1_ruleS’,’(?R1 :refines ?R2) (?R2 :refines ?R3)’, NULL, ’(?R1 :refines ?R3)’, SEM_ALIASES( SEM_ALIAS(’’,’http://www.owl-ontologies.com/OntoReqUnivWordnet1.owl\#’))); Commit;

//Génération des relations en exploitant la règle définie EXECUTE SEM\_APIS.CREATE\_ENTAILMENT(’rdfs\_rix\_university’, SEM\_MODELS(’university’),SEM\_RULEBASES(’OWLPRIME’,’infer\_rb’)); END;

– l’opérateur CheckConsistency: l’exemple suivant illustre un code qui permet de vérifier la consistance des relations entre les besoins :

Create or replace TRIGGER REQUIREMENT\_RELATION\_CHCKCONSISTENCE BEFORE INSERT OR DELETE OR UPDATE ON university\_rdf\_data BEGIN

//Création de la base des règles de vérification de la consistance EXECUTE SEM\_APIS.CREATE\_RULEBASE(’consist\_rb’);

//Index qui associent la base de règles au modèle de l’ontologie EXECUTE SEM\_APIS.CREATE\_RULES\_INDEX(’rdfs\_rix\_university’, SEM\_Models(’university’),SEM\_Rulebases(’OWLPRIME’,’consist\_rb’));

//Insertion de la règle définie

INSERT INTO mdsys.semr_consist_rb VALUES(’1_ruleSC’,’(?R1 :equal ?R2)

(?R1 :contain ?R2)’, NULL, ’(?R1 :inconsistencywith ?R2)’, SEM_ALIASES( SEM_ALIAS(’’,’http://www.owl-ontologies.com/OntoReqUnivWordnet1.owl\#’))); Commit;

//Génération des relations en exploitant la règle définie EXECUTE SEM\_APIS.CREATE\_ENTAILMENT(’rdfs\_rix\_university’, SEM\_MODELS(’university’),SEM\_RULEBASES(’OWLPRIME’,’consist\_rb’)); END;

3. La conception physique de l’entrepôt En suivant les mêmes étapes, nous avons réalisé la phase de conception physique en utilisant la BDBO OntoDB comme expliqué ci-dessous.

Dans le document Donner une autre vie à vos besoins fonctionnels : une approche dirigée par l'entreposage et l'analyse en ligne (Page 183-188)