Modèles de données / Solutions  
       En vacances 
 
5. Revue de détail et éléments périphériques du modèle.
 
5.1. Les niveaux de revenu
On peut considérer que le niveau de revenu est une propriété descriptive du salarié. Mais à nouveau :
- on a de la redondance (tous les salariés de niveau A ont la même valeur pour cette propriété)
- on ne peut pas préciser ce que sont ces niveaux A,B,...en donnant les bornes inférieure et supérieure de ce niveau dans l'entité salarié (3ème Forme Normale non respectée). On en fait donc une entité associée à SALARIES.
Le raisonnement est de même nature que pour n° semaine, sauf qu'il s'applique à une propriété d'entité au lieu d'une propriété d'association.

5.2. La période d'ouverture des centres.
Le fait qu'elle soit décidée en début de saison est une information parasite ici : ceci a à voir avec l'activité du système en fonctionnement (i.e. quand fait-on la mise à jour), pas avec la structure des données.
Cependant on n'a pas cette struture elle-même. Mais nous n'en savons pas assez : cette période est-elle commune à tous les centres ou particulière à chaque centre ? Aller voir l'utilisateur, une fois de plus !
 
Si on suppose qu'elle est spécifique à chaque centre, elle donne lieu à une association entre CENTRES et SEMAINES (sinon elle ne serait pas dans le modèle : ce serait une constante, à traiter comme un paramètre du modèle).

Ceci peut faire germer l'idée que nos numéros de semaine ne sont pas aussi clairs qu'ils en ont l'air. La semaine 35 c'est bien joli, mais de quelle année ? Nous sommes conduits à nous poser une question intéressante : quelle est la durée de vie de la future base de données qui supportera ce modèle ? Une saison ou plusieurs saisons ? Tout dépend des besoins de l'application. Si notre statisticien veut faire des comparaisons fréquentes sur plusieurs années, la durée de vie de la base est pluri-annuelle et il nous faut ajouter une entité année. Aller voir le statisticien pour lui poser la question.

On va supposer qu'il nous a dit qu'un bilan annuel suffit. OK. Il faudra penser à une procédure annuelle d'archivage des données et des procédures en début de saison d'initialisation de la BD. Tout ceci renvoie au modèle d'activité.

5.3. Les activités proposées par les centres.
On peut gérer les fréquentations des salariés avec notre modèle mais c'est autre chose que ce que les centres offrent. A priori cela ne sert à rien pour les statistiques, mais cela reste à verifier. Il faut aller requestionner le statisticien.
Supposons qu'il nous dise qu'il veut calculer des indices de succès des politiques des chefs de centre et mettre en évidence les activités proposées auxquelles personne ne va. Il nous faut mettre en place une association PROPOSER entre ACTIVITES et CENTRES.

5.4. Les inscriptions des salariés dans les activités.
Cela ressemble encore à une information parasite : on nous a demandé des statistiques, pas de gérer des inscriptions (ou des intentions des salariés). Méfiance ! Que veulent donc vraiment faire les utilisateurs avec ce système ? Seulement des statistiques ? Veut-on mesurer une sorte d'indice de satisfaction mettant en rapport les inscriptions-demandes et les fréquentations effectives des salariés ? On retourne voir le statisticien.
Comme il veut tout et que "ça ne mange pas de pain" (du moins le croit-il) on va faire une association INSCRIRE entre SALARIES et ACTIVITES. Il faudra cependant prévenir les secrétariats des centres qu'ils doivent saisir des inscriptions en début de semaine (et pas seulement retourner un relevé des fréquentations de fin de semaine). Et, pour ce qui nous concerne, il va falloir élaborer les documents (écran ou papier) ad-hoc.
 
 


Auteur : Bernard Morand  Entité-Association Date de dernière mise à jour : 1/12/1998