Transposition du modèle de l’exemple « newspaper »

Notre objectif n’est pas de simuler un système à base de frames, mais d’examiner le comportement de notre modèle quand il doit faire face à d’importantes demandes de tenue en charge, un domaine dans lequel les modèles à base de frames sont pauvres [58]. Aussi, nous n’avons pas essayé de traduire tous les concepts de ces modèles. Nous nous sommes contentés de ceux disponibles dans Protégé, et plus précisément de ceux exploités par l’exemple choisi.

La plupart des traductions sont simples et directes. La transformation des classes est semblable à celle décrite pour les modèles à objets en section 8.5.2. Une classe et ses slots sont transformés en une facette dont le type est unn-uplet d’attributs. Les classes abstraites deviennent des facettes, alors que les classes normales deviennent des facettes principales.

Tous les types de Protégé sont aisément transposés dans notre système de types. Les seules particula- rités concernent les types multi-valués et les énumérations. Les premiers sont traduits par des ensembles, les secondes par des contraintes sur les valeurs.

D’autre part, comme pour la simulation du modèle entité-association (section 8.5.1), les associations sont réifiées dans des facettes. La hiérarchie de classes, quant à elle, est simplement simulée à l’aide de contraintes d’implication.

Seul un concept ne peut pas être transposé dans le modèle DOAN : les contraintes d’application. Nous avons décidé de les implémenter directement à l’aide de déclencheurs (triggers) sur les tables correspondantes.

Les bases de test. Pour parvenir à tester la tenue à la charge de notre implémentation, nous avons pré- paré cinq versions de la base de connaissance, l’originale, et quatre autres beaucoup plus volumineuses, contenant respectivement :

1. 3 auteurs, 6 journaux, et 9 articles;

2. base originale + 10 auteurs, 100 journaux, et 1,000 articles 123

3. base originale + 10 auteurs, 1,000 journaux, et 10,000 articles, 4. base originale + 100 auteurs, 1,000 journaux, et 100,000 articles, 5. base originale + 100 auteurs, 10,000 journaux, et 1,000,000 articles.

10.2

Résultats

Pour effectuer les tests, nous avons utilisé un Bi-Pentium III à 733 MHz avec 1 Go de mémoire vive, le système d’exploitation Windows 2000 Server opérant le système de gestion de base de données relationnelles (SGBDR) SQL Server 2000 et Java, via le moteur JRE 1.4.2.

Nous avons utilisé deux versions de Protégé-2000 : une fonctionnant de façon standard sur le sys- tème de fichier et une autre fonctionnant avec une base de données via JDBC (Java Database Connec-

tivity) [82]. La version JDBC de Protégé s’appuie sur une unique relation contenant toute la base de

connaissance, modèle inclus. Elle s’appuie elle aussi sur le SGBDR SQL Server 2000.

Une première observation concerne la limitation importante de Protégé en terme de montée en charge. En effet, nous n’avons pas été en mesure de tester la cinquième version de la base de connais- sance (plus d’un million d’instances). Lorsque Protégé s’appuie sur le système de fichier, il doit charger l’intégralité de la base en mémoire, dépassant ainsi les capacités de la machine. À partir de la quatrième version, qui consomme 730 Mo, nous pouvons estimer que l’empreinte mémoire de la cinquième dépasse 6 Go. Dans la version JDBC, les temps de réponse étaient simplement trop importants pour être mesurés. Une autre limite de Protégé est l’importance du temps de chargement nécessaire avant de pouvoir effectuer une requête (au dessus de 25 minutes pour la quatrième version de la base de connaissances, aussi bien pour la version fichier que JDBC).

Nous avons exécuté nos requêtes de test à partir d’un programme Java, utilisant JDBC pour DOAN et l’API Java fournie pour Protégé. De plus, nous avons explicitement parcouru tous les résultats des requêtes de façon à avoir des temps d’exécution comparables. En effet, JDBC ne retourne les résultats qu’à la demande.

Première requête. Examinons tout d’abord une première requête très simple retournant la liste des employés, incluant les auteurs, qui sont bien payés. Comme nous pouvons le voir dans la figure 10.1, les temps de réponse sont corrects pour toutes les versions. Nous pouvons néanmoins déjà observer les faibles performances de la version JDBC de Protégé.

Deuxième requête. Notre seconde requête récupère les articles dont les auteurs sont bien payés, et renvoie un nombre très important de résultats pour les grosses bases de connaissances. Toutefois, il est très peu probable qu’une application nécessite de si gros ensembles résultants. Elle se contentera généralement des premiers résultats en fonction d’un tri prédéterminé. En conséquence, comme le montre la figure 10.2 nous avons aussi testé la même requête en nous contentant de parcourir uniquement les 100 premiers résultats.

Alors que cette requête montre clairement l’incapacité de Protégé à traiter d’importants volumes de données, nous pouvons observer que notre implémentation ne met que 655 millisecondes à répondre avec une base dépassant le million d’instances. Plus important encore, le temps de réponse reste constamment en dessous de la barrière des 10 millisecondes si nous nous contentons des 100 meilleurs résultats.

CHAPITRE 10 — Performances 125 1 s 100 ms 10 ms 1 ms 0.1 ms 5 (73) 4 (73) 3 (13) 2 (13) 1 (7) Response Time

Knowledge Base (number of results)

Our Model Protégé Full Memory Protégé DB Figure 10.1 – Requête no 1 1000 s 100 s 10 s 1 s 100 ms 10 ms 1 ms 0.1 ms 5 (660,004) 4 (66,004) 3 (6,004) 2 (604) 1 (4) Response Time

Knowledge Base (number of results)

Our Model Our Model (max 100 results) Protégé Full Memory Protégé Full Memory (max 100 results) Protégé DB Protégé DB (max 100 results)

Figure 10.2 – Requête no

1000 s 100 s 10 s 1 s 100 ms 10 ms 1 ms 0.1 ms 5 (146,664) 4 (14,664) 3 (1,334) 2 (134) 1 (1) Response Time

Knowledge Base (number of results)

Our Model Our Model (max 100 results) Protégé Full Memory Protégé Full Memory (max 100 results) Protégé DB Protégé DB (max 100 results)

Figure 10.3 – Requête no

3

Troisième requête. Dans cette dernière requête, compliquons encore nos demandes en restreignant la précédente requête aux articles qui sont urgents et dont le nombre de pages est petit. Si l’ensemble résultant est plus faible, la complexité supplémentaire implique des temps de réponse plus lents, comme l’illustre la figure 10.3. Une seule exception à ce constat : la version JDBC de Protégé. En se limitant aux 100 meilleurs résultats, le temps de réponse est plus lent, comme attendu. Il est cependant plus rapide dès lors que tous les résultats sont renvoyés et donc que la restriction par rapport à la requête précédente agit sur leur nombre. Nous observons ici que la communication avec la base de données est le véritable goulot d’étranglement de Protégé.

10.3

Conclusion

Comme nous nous y attendions (cf. section 6.1.5), Protégé est adéquat pour la gestion de petites bases de connaissances, mais ne supporte pas bien le passage à l’échelle. La version s’appuyant sur un fichier exhibe des temps de réponse acceptables mais est rapidement limitée par les ressources mémoire disponibles. La version JDBC n’a pas une telle limitation, mais est, en contrepartie, beaucoup moins efficace.

L’approche choisie par Protégé de s’appuyer sur une unique relation dans le SGBD est simple et flexible. Toutefois, les résultats observés montrent que, bien qu’il rende l’algorithme de traduction en relationnel plus complexe, notre choix d’une structure de données proche du schéma représenté est beau- coup plus efficace.

Notre implémentation relationnelle de DOAN tire pleinement parti des avantages offerts par les SGBDR en terme de tenue en charge et de performances. Elle répond de manière satisfaisante aux besoins exprimés, ne montrant des signes de faiblesse que lorsque des ensembles résultants très volu- mineux ont besoin d’être parcourus. De plus, le concepteur d’application peut avantageusement tirer

CHAPITRE 10 — Performances 127

parti des fonctionnalités des SGBDR pour optimiser le modèle en fonction de ses besoins essentiels (en particulier en créant des index adéquats).

PARTIE

IV