Base de données.

1. Conception de la base de données

1.1. La cible et le but

Les utilisateurs de la base de données que nous devons réaliser sont une population très précise : cette base s’adresse principalement à une équipe de chercheurs en médecine, et plus précisément en pédopsychiatrie. Les médecins n’ayant couramment pas une grande pratique des ordinateurs et d’Internet, il faut absolument que notre interface soit claire et intuitive. D’autre part, la base de données sera exploitée après ce stage par d’autres programmeurs et il faut donc que les tables soient faites de manière claire et que les champs les composant soient compréhensibles, une tierce personne devant pouvoir à tout moment s’en servir et éventuellement la modifier et l’améliorer.

1.2. Conception des tables

La modélisation a été délicate car les nombreuses informations fournies n'étaient pas triées. La base de données comporte des tables très riches en informations, qui sont reliées entre elles. L’équipe de Necker nous a fourni toutes les informations que notre base de données devrait traiter, ainsi que les diverses manipulations réalisables. Ces informations ont été souvent modifiées par les cliniciens au cours du temps et nous avons dû nous adapter constamment à ces diverses demandes, ce qui remettait couramment en question notre conception initiale.

Nous avons voulu faire le schéma relationnel le plus simple possible, afin d’accélérer les requêtes puisqu’elles seront très nombreuses. Les différentes tables regroupent les entités « bébé », « parent », « frère ou sœur », « interaction » et « séquence ». Le lien entre les notions de « bébé » et de « frère » est d'ordinaire simple mais se révèle moins simple lors de la modélisation. En effet, il faut créer une nouvelle table « fratrie » qui leur permettra d'avoir accès l'une à l'autre car on a une relation de type <n, m>. Ces liens sont fait grâce à des identifiants uniques d'autres tables: des clés étrangères.

Schéma relationnel de la base de données

Il a fallu tout d'abord déterminer les différents types d'utilisateurs. Pour le projet PILE, les seules personnes qui ont accès aux données sont les chercheurs, les responsables de la saisie des informations d'ordre général et les visiteurs « officiels », autorisés à regarder dans la base. Afin de différencier leur navigation dans la base de données, nous avons déterminé une page de connexion et l'identifiant de l'utilisateur est enregistré dans une variable de session jusqu'à ce que cette dernière soit fermée. La différence majeure dans la navigation concerne principalement les droits: seul un chercheur, par exemple, peut intervenir dans l'enregistrement d'une interaction ou d'une séquence dans la base de données. Toutes les informations concernent des bébés, c'est la raison pour laquelle, il est utile de connaître l'identifiant du bébé pour lequel on veut enregistrer une donnée. Pour cela, nous avons choisi de passer cet identifiant dans l'url à chaque changement de page.

2. Architecture

Le site s’articule autour de deux grandes parties: l’une concernant la création, la consultation et la modification de fiches bébé, l’autre permettant la création, la consultation et la modification des séquences et des interactions.

Nous avons choisi une présentation avec des onglets car elle sépare bien les informations selon leur thème. Lors de la création, l'utilisateur doit obligatoirement entrer les informations concernant un bébé.

Nous avons choisi une navigation par étapes: un utilisateur ne peut pas enregistrer un parent si le bébé ne l'a pas été antérieurement, ni un frère ou une sœur si le bébé et les parents ne sont pas dans la base par exemple. Ce type de navigation nous permet de contrôler l'ordre des saisies car il n'y a aucun intérêt à enregistrer un adulte s'il n'a pas d'enfant enregistré. Dans cette partie, on peut enregistrer un bébé, ses parents et ses frères ou sœurs.

Lors de la consultation, il est possible, pour un chercheur, d'éditer les données ou d'en rajouter alors que tout autre utilisateur ne pourra que consulter les données. L'utilisateur recherche un enfant dans la base en tapant son nom. Le fruit de cette recherche apparaît à l'écran sous forme de liens. Si l'on clique sur un de ces liens, on arrive à une page qui possède les mêmes onglets que dans la partie « création Fiche bébé ».

3. Implémentation

Nous avons utilisé My SQL pour gérer la base de données et PHP pour écrire les différents scripts. La partie graphique est écrite en HTML dans des fichiers dont l'extension est .tpl (pour template).

Nous avons respecté la contrainte de séparation de fichiers codés en sq l, php et htm l pour rendre le code plus lisible par autrui.

Afin de séparer les requêtes SQL du code php, des librairies de fonctions utilisant des requêtes SQL ont été codées. Une partie a été programmée pendant la définition de l'architecture du site et le reste a été complété par la suite pendant que l'interface graphique se construisait. Ces fonctions regroupent toutes les recherches d'informations et les mises à jour de la base.

Nous avons créé un fichier template (.tpl) qui sert de modèle à la plupart des pages Web: il contient tous les éléments qui peuvent composer une page. En effet, la présentation des pages est commune: elles ont la même en-tête, le même menu ou la même disposition en onglets. Afin de rendre dynamique la génération de listes déroulantes, nous avons créé une table « paramètres » qui regroupe les réponses par groupe. Il ne reste plus qu'à déterminer quel groupe de réponses la liste doit fournir. Ce procédé nous a été utile pour afficher des formulaires.

Les fichiers php ne sont donc constitués que de traitement des informations de la base de données et de gestion des sessions et connexion. Le fichier php doit gérer l'interface selon le type d'utilisateur et récupérer les données entrées par celui-ci.

Le traitement pour l'enregistrement d'un bébé fait donc appel à deux fichiers qui sont propres au traitement du bébé (le fichier php et sa librairie), à un fichier général pour l'affichage et à d'autres fichiers de librairies générales.

4. Sécurité

Pour ce qui est de la sécurité au niveau de la conception d'un site Internet, il faut faire attention à divers éléments. En effet lorsqu'on navigue sur une page, des informations sont constamment interceptables par quiconque. Le créateur d'un site se doit donc de faire attention à limiter les fuites éventuelles que des utilisateurs pourraient avoir à subir.

Les urls des sites que l'on visite sont stockées un peu partout: dans les favoris, quand on envoie un lien dans un mail, etc. Dans notre cas, les données nécessitent de rester confidentielles : elles ne doivent pas sortir du projet PILE, mais les données personnelles à un chercheur ne doivent pas non plus être vues par les autres chercheurs.

Voici quelques problèmes rencontrés au niveau des passages de variables dans l'url:

• l'historique du navigateur Internet stocke les liens sur lesquels un internaute est allé, et donc l'identifiant éventuel d'un internaute. Si le poste utilisé est un poste où beaucoup de personnes différentes ont accès (un cybercafé par exemple), n'importe qui peut récupérer dans l'historique l'adresse dans laquelle la session d'un précédent visiteur est identifiée. Il faut donc faire extrêmement attention aux valeurs passées dans l'url.
• les liens dans les favoris peuvent aussi rendre des informations privées accessibles. Le fait d'enregistrer une page alors qu'on est en cours de session stocke de la même manière que précédemment des informations personnelles contenues éventuellement dans l'adresse.
• lorsqu'on est sur un forum, il arrive de conseiller un lien aux autres internautes. Ce lien contient là aussi éventuellement des informations confidentielles et n'importe qui accédant au forum peut y en prendre connaissance.

Pour palier à ces problèmes, on limite la durée de vie des sessions après un certain temps de non utilisation. On filtre (en regardant l'adresse IP) l'accès à une page en n’autorisant que la machine qui l'avait initialement ouverte à y retourner. Mais il est cependant préférable de ne pas autoriser le passage de l'identifiant de session dans l'url.

Mis à part les problèmes de passage de valeurs dans l'url, on peut aussi rencontrer des problèmes au niveau des cookies, mais normalement, les cookies d'une session sont effacés dès que le navigateur est fermé.

Au niveau du php, que nous utilisons, il existe une vulnérabilité à cause de la fonction system() qui permet d'accéder aux commandes système. Il est donc facile de détourner une adresse en tapant un lien qui va directement dans un répertoire important (/dev, /bin, /include...). Pour cela, on peut protéger par exemple le symbole « / », en le codant par une chaîne de caractères quelconque.

2.5. Captures d’écran

Page de connexion

Début d’une séquence.

2.6. Bilan

La base de données est accessible par Internet, mais de manière sécurisée. Seul un chercheur ayant un login et un mot de passe peut s’y connecter, une fois connecté ce dernier ne peut que consulter les fiches concernant les séquences vidéos que lui a remplies. Les sessions sont donc uniques et personnalisées, offrant ainsi un accès très limité aux informations. De plus aucune variable importante n’est passée dans les adresses et quelqu’un ayant obtenu l’adresse d’une des pages et voulant s’y connecter directement se verrait renvoyé à la page de connexion n’ayant pas de session à ce moment là.

La base de données achevée, nous avons pu nous consacrer à la localisation des mains des bébés filmés dans la cellule vidéo.