STIC B 525 Travail Final (Frerotte B.).pdf


Aperçu du fichier PDF stic-b-525-travail-final-frerotte-b.pdf

Page 1 2 3 4 5 6 7 8 9 10 11




Aperçu texte


En somme, étant donné les spécificités du domaine d’application, la volonté d’autonomie de l’application et les faibles moyens disponibles, les outils classiques permettant d’assurer la qualité des
données ne pouvaient être utilisés. Des mécanismes détournés ont donc été mis au point afin de
vérifier l’exactitude des données dès l’encodage et ce, à faible coût et sans nécessiter une importante
masse de travail.

Les mécanismes de contrôle internes :
Les premières mesures permettant de s’assurer que les organisateurs d’activités ne commettent
pas d’erreurs en encodant leurs données sur le site web (et donc dans la base de données) se situent
au niveau de la structure même de la base de données. En effet, dès la conception de cette dernière,
de nombreuses contraintes d’intégrités ont été implémentées afin de limiter autant que possible les
éventuelles erreurs.
Pour illustrer ces différentes mesures situées au niveau du schéma de la base de données,
intéressons-nous à une des tables de celle-ci :

On remarque tout d’abord que des noms aussi explicites que possible ont été choisis pour les
tables et les colonnes. Ainsi, comme leur nom l’indique, la table activite sert au stockage des informations concernant les activités dans la base de données, la colonne categorie sert à préciser
à quelle catégorie appartient l’activité, la colonne tarif sert à préciser le prix de l’activité,. . . La
colonne idacti permet quant à elle d’assigner automatiquement un identifiant unique à chaque
activité.
Seules deux colonnes ont un titre relativement ambigu pour des personnes extérieures : titre et
periodetarif. Pour la première, il s’agit bien entendu du nom de l’activité. Cela dit, il fut décidé
arbitrairement de préférer l’appellation « titre » plutôt que « nom » afin de ne pas créer un amalgame avec le nom de l’organisateur. Pour la seconde, il s’agit de la période couverte par le tarif. En
effet, certaines activités sont payées à l’année alors que d’autres se payent au mois, à la semaine
ou à la séance. Pour ces deux colonnes, des notes explicatives ont été insérées dans le code SQL.
Attribuer des noms explicites aux différents éléments d’une base de données n’est pas un mécanisme de contrôle en soi. Cependant, une telle pratique permet de faciliter les processus de
data profiling futurs. Or, on considère souvent le data profiling comme la première étape vers une
meilleure qualité des données, raison pour laquelle cet aspect est mentionné dans cette étude de cas.
Une analyse en profondeur des nombreux types de données offerts par MySQL a en outre permis d’attribuer le type le plus adéquat à chaque colonne. Ce faisant, l’usage des types les plus
génériques (varchar, integer,. . . ) a pu être limité au strict minimum. Ainsi, pour les différentes
4