Pluripass L2 : bases des données                      gilles.hunault "at" univ-angers.fr Exercices de réflexion   Table des matières cliquable   1. Valeurs, unités et codes   2. Stockages autres que chiffres et lettres   3. Internationalisation des labels et des stockages   4. Comment stocker astucieusement les modalités des variables qualitatives ?   5. Gestion des adresses et des codes de département   6. Sauvegarde des mots de passe, une mauvaise idée   7. SQL et NoSQL dont MongoDB   1. Valeurs, unités et codes La structure d'une table dans une base de données décrit le format de stockage des données. Ainsi, int(2) signifie que l'on veut stocker l'information avec un nombre entier sur deux positions. Comment peut-on faire pour stocker l'unité de la donnée ? Par exemple, pour un français, une taille de 1 mètre 75 peut s'écrire 1,75 ou 1.75 ou encore 175 cm. Pour un américain, la taille (ou height) peut s'exprimer en pouces et alors ce sera non plus 175 cm mais 69 inches (ou 69 pouces) qu'il faut conserver. Où et comment stocker cette information d'unité ? De la même façon, un code-sexe peut se coder au choix 0/1 ou 1/2 (plutot que "homme"/"femme") et un code-réponse en "oui"/"non"/"ne se prononce pas" peut se coder par exemple 0/1/2 ou 1/2/3 ou bien même 1/2/9. Où stocker ces correspondances entre codes et labels ? 2. Stockages autres que chiffres et lettres Les informations de bases sont classiquement les chiffres et les lettres mais après réflexion, quels autres types de données pourrait-on sauvegarder dans une base de données ? Par exemple, que trouve-t-on certainement dans les bases de données de TF1 ? Et de Google ? Est-ce plus difficile de stocker ces informations que juste des chiffres et des lettres ? Pourquoi ? 3. Internationalisation des labels et des stockages Bien évidemment les français parlent français et les chinois parlent chinois. De la même façon les français écrivent en français et les chinois écrivent en chinois. Comment ces différentes langues sont-elles codées dans les ordinateurs ? Quelle(s) conséquence(s) cela peut-il avoir sur le stockage des données dans les bases de données  ? Qu'est-ce qui garantit qu'on sera capable de relire les données stockées et en particulier les labels ? 4. Comment stocker astucieusement les modalités des variables qualitatives ? Si on n'utilise qu'un ou deux champs qualitatifs comme SEXE avec les valeurs "femme"/"homme", alors le stockage des modalités peut se faire avec une mini-table de correspondance pour décrire chaque modalité. Par exemple on peut imaginer créer une table labelsSEXE avec juste deux champs, CODE et LABEL, dont le contenu serait : mysql> SELECT * FROM labelsSEXE ; +-------------+----------+ | CODE | LABEL | +-------------+----------+ | 1 | Homme | | 2 | Femme | +-------------+----------+ 2 rows in set (0.00 sec) Si maintenant on a besoin de plusieurs dizaines de champs qualitatifs, il n'est certainement pas efficace de créer autant de mini-tables de correspondance que de champs qualitatifs. Comment faire alors pour disposer efficacement des correspondances entre tous les codes et tous les labels sachant que certains codages sont parfois contradictoires comme 0/1 pour "femme"/"homme" dans un certain contexte et 1/0 pour "femme"/"homme" dans un autre contexte ? 5. Gestion des adresses et des codes de département Un grand "standard" en base de données est la gestion des adresses. Quelles sont les solutions classiques pour la France, si on veut être capable d'accéder facilement à des informations disons, sur les villes ? Quelles parties obligatoires et facultatives doivent constituer une adresse, y compris pour les grandes villes ? 6. Sauvegarde des mots de passe, une mauvaise idée L'accès à des applications sur Internet se fait souvent avec le fameux couple login et mot de passe. Pourquoi est-ce une mauvais idée de sauvegarder tels quels les mots de passe dans une base de données ? Comment fait-on vraiment ? Dans la foulée, expliquer pourquoi les administrateurs peuvent attribuer un nouveau mot de passe mais pas connaitre ou retrouver un ancien mot de passe. Indication : on pourra essayer de se rappeler la définition mathématique d'une fonction injective. 7. SQL et NoSQL dont MongoDB Dans le cours, SQLITE3 a été évoqué comme remplaçant possible de MySQL pour de petites applications et en phase de tests. Quels en sont les points forts et les points faibles ? Utiliser des dialectes de SQL comme MySQL, Postgres ou Oracle suppose que les informations sont toujours structurées de la même façon. Mais si ce n'est pas le cas, est-il facile de rajouter à la volée des champs dans les tables ? Est-ce pertinent d'avoir des centaines de champs pour couvrir toutes les informations possibles alors que la plupart du temps chaque enregistrement ne contient que quelques-unes de ces informations ? En quoi NoSQL et en particulier MongoDB permettent-ils de résoudre ce problème ?

 

 

   Retour à la page principale de   (gH)