« SPARQL Protocol and RDF Query Language/Requêtes de découverte » : différence entre les versions
Contenu supprimé Contenu ajouté
mAucun résumé des modifications |
|||
Ligne 14 :
== 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.<br/>
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 sera le délai pour se réapproprier le système ? La qualité de service ? La plateforme de développement et de tests à mettre en œuvre est-elle aussi documentée ? Etc.<br/>
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.
Ligne 24 :
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 source des applications qui insère des données dans 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 à représenter le système et ainsi 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 d'appropriation du système à chaque mise à jour.
=== Avec SPARQL ===
Il n'est pas indispensable de définir une structure de données avec SPARQL avant de commencer à enregistrer les données. Ce sont les données et les liens entre
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.
Ligne 40 :
Par exemple :
#Une application A est développée. Elle utilise
#Ensuite, une application B est développée. Elle utilise
#L'application B remplace l'application A progressivement et pour le faire, un script passe les objets
=== 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ée par une autre, il faudra restructurer la base de données avec un autre programme pour migrer les objets d'
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
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.
| |||