Structure de données

Introduction

Le DRH d'une grande entreprise demande de réaliser un système lui permettant de retrouver facilement ses fiches employés.

Les informations dont il a besoin sont les suivantes : Genre, Nom, Prénom, Code employé, Nombre d'enfant, statut matrimonial, adresse complète, Poste occupé, niveau, rémunération, nom du supérieur.

Cet exemple est l'un des cas les plus simples que l'on peut trouver, a tel point qu'il est souvent livré en exemple avec les bases de données du marché.

Le problème revient donc à définir une structure de données adaptée a la problématique soulevée par le service des ressources humaines. Il est particulièrement important de veiller aux points suivants :

ne jamais stocker plusieurs fois une même information en différents endroits.
Le DRH souhaite pouvoir suivre l'évolution des ses salariés dans le temps (salaire, poste, niveau, supérieur)

Structure la plus simple

L'idée la plus simple lorsque l'on arrive devant ce type de problème consisterait a faire une seule grosse table contenant, les uns a la suite des autres, l'ensemble des données demandées.

On aurait alors sur une ligne de données le Nom de l'employé, son salaire et toutes les informations utiles. Cette structure présente toutefois un défaut : a chaque mise à jour la ligne, par exemple parce que le salarié à changé de supérieur, on perd les anciennes valeurs, puisque le nouveau salaire écrase l'ancien. On pourrait alors imaginer de créer une seconde ligne, dans laquelle on recopierait l'ensemble des champs de la première, avec le nouveau salaire, mais cela générerait de très nombreux doublons, puisque chaque employé apparaîtrait sur plusieurs lignes, l'adresse par exemple serait stockée plusieurs fois, ce qui n'est jamais souhaitable.

Structure a deux tables

Afin d'établir une structure de données cohérente, il convient de dissocier les informations selon leur type, et selon que ce que l'on souhaite faire avec.

On voit assez rapidement qu'il existe deux types d'informations parmi celles que l'on souhaite enregistrer :

Des informations qui sont statiques au cours du temps (Nom, Prenom, Matricule)
Qui peuvent évoluer (Salaire, Groupe, Niveau)
Il est particulièrement important de bien comprendre le sens exact du mot "statique", qui n'est pas a comprendre comme "qui ne change jamais", mais plutôt comme "dont les modifications ne sont pas a prendre en compte pour le DRH".

Ainsi, lorsqu'un employé déménage, cette informations doit être enregistrée par l'entreprise pour lui adresser son courrier, mais elle n'a pas de raison d'être archivée dans le système d'information de l'entreprise. Le fait qu'un employé ait changé d'adresse ou de nom (s'il s'est marié) est sans intérêt dans la base. En revanche, les modification de salaires, groupe et niveau doivent être enregistrées et datées.

Concrètement, cela signifie que l'on doit faire deux tables : Employe et StatutEmploye. Employé contient les informations dont l'évolution n'intéresse pas l'employeur, Statut contient des informations dont l'évolution doit être enregistrée.

On aurait alors :

Sur ce schéma, les symboles 1 et " infini " placés à coté des tables signifient que :

Pour une occurrence d'employé, il existe plusieurs (une infinité) d'occurrence de " StatutEmploye ". Concrètement, un employé donnée peut avoir plusieurs status au cours du temps.
Pour une occurrence de statut, il ne peut correspondre qu'un seul employé. Concrètement, un statut ne correspond qu'a un seul employé.
Avec cette structure de table, on peut donc enregistrer toutes les informations sur les employés, et visualiser leur évolution au cours du temps.

Accroître la complexité

Un puriste des bases de données relationnelles trouverait de nombreuses choses a redire contre cette structure de base. En particulier le fait que la modification d'un des éléments de la liste " StatutEmploye " entraîne nécessairement le ré-enregistrement de l'ensemble des valeurs de la ligne, ce qui crée donc une redondance dans les donnée

Il serait alors possible de préconiser une solution différente, pour laquelle on enregistrerait les informations différemment :

Une table Employe, identique a la précédente
Trois tables EmployeSalaire, EmployeNiveau et EmployeSuperieur, contenant respectivement le salaire, le niveau et le supérieur de l'employé, avec a chaque fois la date a laquelle l'information s'applique.
Cette structure est poussée, et théoriquement plus " propre " par rapport aux principes de bases de données. Aucune information n'est jamais répliquée, toutes les informations sont séparées les unes des autres, chacune selon son type.

Conclusion

On le voit, on peut réaliser trois structures de données pour répondre a un même problème.

Pour choisir la structure adaptée, il convient de garder à l'esprit que :

Moins une structure contient de tables, plus elle est facile a interroger, mais moins elle est souple
Plus une structure contient de tables, plus elle est souple, mais moins elle est facile a interroger.

Le choix de la structure dépend donc énormément du type de requêtes que l'on doit effectuer dessus. En pratique, la structure 2 serait dans la plupart des cas la plus adaptée. Elle autorise une mise a jour des informations en deux requêtes seulement, et permet de garder une trace de l'évolution du statut de l'employé. La structure 3 est plus performante, mais aussi plus lourde a gérer.