Dans une première phase, nous allons répertorier les "mots" qui semblent importants pour décrire la situation présentée en commençant par le début du texte et en terminant par le document "Business account". Une telle liste pourrait donc être la suivante :

Un examen rapide montrerait qu'il y a des synonymes évidents : on gardera "société" pour "société", budget" pour "budget global", "employés" pour "cadres", ID" pour "numéro interne" et "numéro société". Les termes "psychologues", "consultants" et "formateurs" ne sont en fait que des exemples de "spécialités" qu'ont les conseillers, et nous garderons ce dernier terme pour la suite. On peut s'apercevoir aussi que le problème qui intéresse Monsieur Schuiten n'a rien à voir avec le paiement des conseillers, et donc les données "honoraires" et "avances honoraires" sont superflues et à éliminer. Les termes de "clients", de "prospects" et de "société embauche" font référence au fait que le rôle joué par chaque société vis-à-vis de BTI varie de l'une à l'autre. On verra par la suite ce qu'il y a lieu de faire avec ces mots.

Parmi les mots précédents qui restent après le tri préalable, on peut résumer le cas sous la forme des phrases suivantes :

• Un business account est ouvert quand une entreprise confie à BTI des employés licenciés.

• Un business account regroupe les employés licenciés suite à une affaire conclue avec une entreprise.

• Un employé peut être réembauché par une entreprise à une certaine date.

• Un conseiller est affecté à un business account.

• Un employé est licencié par une entreprise.

• Un employé a un nom, un prénom, un âge, un poste préalablement occupé.

• Un business account a un budget, une date, une situation.

• Une entreprise a un nom, un numéro interne (ID), une adresse, un correspondant avec son nom, sa fonction et son téléphone.

• Un conseiller affecté à un business account y participe pour un certain pourcentage du budget et son travail est dans un certain état d'avancement.

• Une entreprise est cliente, ou prospect, ou encore peut réembaucher des employés.

Des phrases qui décrivent la situation étudiée, il ressort que l'on peut identifier plusieurs données de base candidates au statut d'entité :

• Une entité EMPLOYE semble évidente dans la mesure où tout tourne autour de ces employés que l'on gère, notamment dans le cadre d'une affaire (le business account) et des entreprises dont ils sont issus ou dans lesquelles ils seront réembauchés.

• De la même façon, les entreprises sont aussi des objets de la réalité qui nous intéressent, car BTI fait des affaires avec elles; ou bien elles accueillent les employés licenciés, ou encore constituent une cible potentielle pour des affaires à venir. On a donc une entité ENTREPRISE à prévoir. Toutefois, on peut se poser la question de savoir si en fait il ne faudrait pas prévoir plusieurs entités différentes pour tenir compte d'un statut variable vis-à-vis des activités de BTI. Il y aura lieu par la suite de voir s'il s'avère nécessaire de créer, en place d'une entité unique ENTREPRISE, trois entités qui seraient ENT_CLIENT pour celles qui sont clientes, ENT_PROSPECT pour celles qui n'ont pas encore conclu d'affaires avec BTI et ENT_REEMBAUCHE pour celles dans lesquelles les employés ont été réinsérés.

• BTI gère aussi des conseillers qui interviennent dans une affaire, pour un certain pourcentage du budget et dont on suit l'avancement de la prestation. Il est normal de prévoir une entité CONSEILLER.

• Le business account est un candidat naturel pour le statut d'entité car toute la gestion de BTI repose sur l'information le concernant. On a bien de nombreux business accounts qui jouent un rôle de pivot entre les employés, les sociétés et les conseillers comme le montre la figure 3.8. On aura donc a priori une entité que l'on appellera BUS_ACCOUNT. Néanmoins, ce rôle de pivot que joue le business account pourrait suggérer qu'en réalité il est une association entre les entités EMPLOYE, ENTREPRISE et CONSEILLER. On laissera donc ce point en suspens pour le réexaminer plus tard au vu de l'avancement dans la création du modèle.

A l'issue de cette première analyse, on dispose des quatre entités suivantes :

tout en gardant en mémoire la possibilité de différencier l'entité ENTREPRISE et l'éventualité de considérer l'entité BUS_ACCOUNT comme une association.

Si l'on regarde les phrases décrivant la situation et mettant en jeu les entités précédentes, on arrive à la mise en évidence des associations suivantes :

• "un business account est ouvert quand une entreprise confie à BTI des cadres licenciés" : il y a donc un lien entre les entités BUS_ACCOUNT et ENTREPRISE qui est l'expression d'une affaire conclue. On pourra dire qu'un business account correspond à une société et y voir une association que l'on appellera Correspondre.

• "un business account regroupe les employés licenciés suite à une affaire conclue avec une entreprise" : le verbe "regroupe" suggère l'association entre un business account et des employés dont une entreprise se sépare. On constituera donc une association Regrouper entre EMPLOYE et BUS_ACCOUNT.

• "un employé peut être réembauché par une entreprise" : il s'agit là d'une relation entre un employé et, éventuellement, une entreprise qui le réembauche. On aura donc une association Embaucher entre EMPLOYE et ENTREPRISE.

• "un conseiller est affecté à un business account" : chaque conseiller travaille sur une ou plusieurs affaires exprimées par un business account. Il y a donc une association Affecter qui relie les entités CONSEILLER et BUS_ACCOUNT.

• "un employé est licencié par une entreprise" : on peut repérer ici une association exprimant le fait qu'un employé a été licencié par une entreprise, ce sera donc l'association Licencier entre EMPLOYE et ENTREPRISE.

On arrive donc à la version du modèle de la figure 5, montrant les entités et les associations mises en évidence à ce stade.

Figure 5. Première version du modèle entité-association pour le cas BTI

• Un employé a un nom, un prénom, un âge et un poste occupé à sa date de licenciement.

• Un business account a un numéro, une date d'établissement, un budget, un statut (en cours ou terminé).

• Un conseiller a un nom et une spécialité.

• Une entreprise a un numéro (ID), un nom (raison sociale), une adresse et un correspondant.

Il nous reste maintenant un nombre réduit de "mots" qui n'ont pas encore été pris en compte, à savoir "date d'embauche", "% budget" et "% avancement". Manifestement, il s'agit d'informations nécessaires pour BTI : où les placer ?

Si une affaire se concluait par la réembauche d'un employé, il suffirait de dire que la date de réembauche est un attribut (indéfini provisoirement) de l'entité EMPLOYE. Malheureusement, une embauche à l'essai peut ne pas se concrétiser et BTI a une obligation de résultat. Il est alors nécessaire de prévoir qu'un employé peut être réembauché plusieurs fois, et donc à des dates distinctes. En conséquence, l'information "date d'embauche" sera un attribut de l'association Embaucher qui relie un employé à la(les) entreprise(s) où il se réinsère.

Pour les pourcentages de budget et d'avancement, il s'agit d'informations concernant le fait qu'un conseiller est affecté à un business account. Et ces pourcentages varient selon les conseillers et les business accounts, et pour un conseiller donné, selon les affaires qui lui sont confiées. On en conclut que ces deux informations sont des attributs que l'on nommera Part_Budget et Etat_Avancement de l'association Affecter entre CONSEILLER et BUS_ACCOUNT.

Il reste enfin la question des identifiants des entités. La question de l'identifiant de l'entité ENTREPRISE est simple. BTI utilise ce qu'elle appelle "ID" pour le numéro d'identification d'une entreprise. On suppose que ce numéro est sans équivoque et détermine une et une seule entreprise, et donc qu'il sera l'identifiant de cette entité. Il en va de même pour l'entité BUS_ACCOUNT dont on peut penser que le numéro interne joue le rôle d'identifiant.

Pour les employés, par contre, rien n'existe si l'on s'en tient à la figure 3.8 : un employé n'est identifié que par son nom et son prénom. Comme il a été dit par ailleurs, on a tout intérêt à créer de toute pièce un identifiant Num_Employé, sans sémantique, qui repérera de manière unique tout employé passant par les services de BTI. En ce qui concerne les conseillers, on a le même problème. L'ensemble du nom et du prénom, voire l'utilisation du nom seul, peut suffire comme identifiant compte tenu du faible nombre de conseillers contractés par BTI. On peut penser tout de même que pour les exploitations futures de la base de données, un identifant plus compact et mnémonique serait apprécié. On pourrait prévoir un code de trois lettres initiales de la personne, comme on le fait assez habituellement dans des groupes restreints de personnes, qui servirait d'identifiant sous le terme de Code_Conseiller. C'est ce que l'on fera ici, tout en prévoyant d'interroger Monsieur Schuiten pour vérifier si cette solution est judicieuse.

La lecture du cas et des phrases répertoriées permet de définir sans ambiguïté un certain nombre de cardinalités, telles qu'elles apparaissent dans le modèle final de la figure 6.

Figure 6. Version finale du modèle entité-association du cas BTI

Certaines autres cardinalités méritent quelques explications. L'entité ENTREPRISE intervient dans les trois associations Correspondre, Licencier et Embaucher avec des cardinalités . Les cardinalités minimum de 0 expriment le fait qu'une entreprise peut ne correspondre à aucun business account — elle est donc non cliente et par la même occasion n'a pas licencié d'employé dont BTI s'occupe —, ainsi que le fait qu'une entreprise peut ne pas avoir réembauché des employés. Une entreprise dont toutes ces cardinalités minimum seraient de 0 est donc un "prospect". Et une entreprise peut n'apparaître que par le fait qu'elle a réembauché un ou plusieurs employés. On voit donc que les divers types de relations de BTI avec des entreprises sont exprimés à travers ces cardinalités.

En ce qui concerne l'entité EMPLOYE, les cardinalités "1,1" avec BUS_ACCOUNT disent qu'un employé n'est impliqué que dans un seul business account. Ceci est vrai a priori, mais peut-il se faire que par la suite on le voie réapparaître chez BTI au cours d'un second licenciement dans le cadre d'un nouveau business account ? Si tel était le cas, les cardinalités "1,1" seraient incorrectes... A la réflexion, cette éventualité est fort improbable. Même si elle devait se produire, alors on créerait un nouvel employé qui d'ailleurs n'aurait plus le même profil (âge, poste occupé notamment). Bien qu'il soit nécessaire d'imaginer ce qui peut se produire dans le futur, il est bon aussi de garder le modèle aussi simple que possible.

La dernière remarque concerne les cardinalités "0,n" dans l'association d'un employé à une entreprise qui le réembauche. Elles expriment les possibilités suivantes :

• Il n'y a pas (0) d'occurrence de l'association Embaucher reliant l'employé X à l'entreprise Y : c'est le cas où un employé est en cours de "traitement" chez BTI; il n'a pas encore trouvé d'employeur.

• Il y a une occurrence de l'association Embaucher : c'est donc un employé qui a trouvé un employeur. La date d'embauche permet de dire si cette dernière est définitive — auquel cas on pourra éventuellement archiver cet employé —, ou bien s'il est dans sa période d'essai de trois mois (affaire non soldée).

• Il y a plusieurs occurrences de l'association Embaucher : c'est le cas d'une personne dont plusieurs emplois trouvés n'ont pas débouché sur une embauche définitive. Seule la date la plus récente permet de dire si l'affaire pour cet employé est définitivement soldée.

Les données mises en jeu dans le système d'information de BTI doivent satisfaire un certain nombre de règles de cohérence que le schéma construit ne peut exprimer. On peut en identifier quelques-unes :

• Pour un business account donné, la somme des parts de budget pour tous les conseillers qui lui sont affectés doit être égale à 100%.

• De la même façon, chaque pourcentage d'avancement ne peut excéder 100%.

• Les diverses dates doivent être cohérentes : une date d'embauche dans l'association Embaucher doit être postérieure à la date du business account.

• Le statut d'un business account ne peut prendre la valeur "terminé" que pour autant que les dates de réembauche de tous les employés concernés soient plus vieilles de trois mois que la date présente.

• D'une manière plus subtile, il est nécessaire qu'un employé soit licencié (via l'association Licencier) par la même entreprise que celle qui a conclu (association Correspondre) un business account dans lequel est inclus (association Regrouper) cet employé. Cette dernière contrainte d'intégrité sera d'ailleurs évoquée plus loin au moment de l'application des règles générales de validation d'un modèle.