« SPARQL Protocol and RDF Query Language/Requêtes de découverte » : différence entre les versions
Contenu supprimé Contenu ajouté
Page créée avec « {{ébauche informatique}} {{Chapitre | idfaculté = informatique | titre = Requêtes de découverte | titre_leçon = SPARQL | numéro = 7 | niveau = 13 |... » |
Aucun résumé des modifications |
||
Ligne 10 :
}}
Dans cette leçon, nous allons décrire comment un administrateur et demain un agent intelligent peuvent découvrir des données pour les utiliser. Pour finir, nous indiquerons quelques pistes pour imaginer les moyens à mettre en œuvre pour fabriquer des applications robustes bien que les données évoluent au grès d'une [[w:méthode agile|méthode agile]].
== Introduction : la méthode agile appliquée aux données ==
Quant on choisit un système d'information c'est un peu comme une voiture, on se renseigne avant sur le prix des pneus, l'assurance, les options, etc.
Il y a une chose qu'on chiffre très mal en amont c'est le temps non pas du développement du système mais le temps que pourra prendre une modification du système. Est-ce que la personne qui l'a développé sera encore là ? Est-ce que la documentation est suffisante ? Quel délai pour se réapproprier le système ? La qualité de service ? La plateforme de développement à mettre en œuvre est-elle aussi documentée ? Etc.
Nous allons essayer de comparer les méthodes actuelles pour modifier une base de données et comprendre pour quoi SPARQL va simplifier la manière de développer des applications.
=== Avec une base de données SQL ===
[[Fichier:Database-excel.png|thumb|500px|Exemple de table avec des colonnes]]
Dans une base de données classique de type SQL, on découvre la structure des données sous forme de tables avec des colonnes à travers une application comme PHPMyAdmin ou à travers quelques requêtes de descriptions. <br/>
Est-ce suffisant pour comprendre la structure d'une base de données pour pouvoir la modifier ?<br/>
Bien souvent "Non", avant de modifier une base de données, on cherche la documentation. On regarde la date de la documentation ainsi que la date des derniers scripts SQL de mise-à-jour et bien souvent la documentation est périmée. <br/>
On commence alors une enquête policière pour deviner pourquoi cette structure existe. Rapidement, on fait un plan de la base de données au format A3. Une fois qu'on a le plan sous les yeux, on est obligé d'étudier table par table à quoi correspond chaque colonne.<br/>
Quand les noms des colonnes sont fantaisistes (une colonne avec le nom par exemple: custom1,custom2), on est alors obligé d'ouvrir le code qui insère des données les colonnes concernées.
Le coût pour modifier une base de données peut être réduit avec une documentation adéquate mais il existe un coût incompressible pour s'assurer du bon fonctionnement du système après modification.
=== Avec un mapping objet-relationnel ===
Les systèmes se complexifiant, on commence à arrêter d'essayer de comprendre une base de données avec plus de 50 tables. On fait maintenant le plan des objets métiers qui servent à faire abstraction de la base de données.<br/>
Cela permet de réduire la complexité de l'analyse (moins de tables à étudier) mais les systèmes étant plus complexe, cela ne change pas le coût final incompressible à chaque mise à jour.
=== Avec SPARQL ===
Il n'est pas indispensable de définir une structure avec SPARQL avant de commencer à enregistrer les données. Ce sont les données et les liens entre elles qui en dessinent la logique. Les liens entre les données (les prédicats) sont des données comme les autres qui peuvent changer au grès des insertions de données.<br/>
Les nouvelles données avec une structure différente ne remplacent en rien les données précédentes avec leur propre structure. Un objet peut être décrit avec deux structures différentes dans la même base de données.<br/>
Le coût de mise à jour de la base de données devient nul car l'insertion de nouvelles données ne demande pas la remise à plat du système en production.
Des applications peuvent cohabiter pendant des années et utiliser la même base de données.
Par exemple :
#Une application A est développée. Elle utilise le format A.
#Ensuite, une application B est développée. Elle utilise le format B.
#L'application B remplace l'application A progressivement et pour le faire, un script passe les objets du format A au format B les uns après les autres sans interruption de services des applications A et B.
=== Et demain ? ===
Le coût de mise à jour de la base de données devient nul avec SPARQL ou plutôt presque nul. En réalité, quand une application est remplacé par une autre, il faudra restructurer la base de données avec un autre programme pour migrer les objets d'un format à un autre. Toutes les données étant toutes visibles au même endroit, il n'y pas de problèmes de migration mais juste des réécritures de données.
Cela est parfaitement envisageable quand l'environnement du système est sous contrôle mais dés lors que l'on utilise des données extérieures, une application est soumise à l’aléa des changements de formats de données.
Il faut demain que les programmes puissent être développés de manière robuste pour s'adapter à la structure des données. Par exemple, si les données sources changent, il faut qu'une alerte puisse arriver par mail à l'administrateur pour modifier les paramètres de descriptions des sources de données. Ici l'administrateur est l'agent intelligent du système. Demain, des robots ou agents intelligents pourront sans intervention humaine découvrir des données, les utilisés et en redécouvrir de plus pertinente, etc.
A travers les requêtes DESCRIBE et les requêtes SELECT, SPARQL pose les bases de nouveaux programmes logiques qui devront savoir s'adapter et raisonner en fonction des données dont ils disposent.
{{Bas de page
| |||