Cas pratique :Interim

Les données Une société d'intérim met à disposition de ses clients

des personnels intérimaires. – Contrat signé avec le client qui précise le nombre de

journées*hommes par qualification demandée, la date de début et de fin du contrat et son objet.

– Les personnels de la société ainsi mis à disposition sont individuellement connus (N° matricule, nom, prénom, adresse) et affectés dans les contrats signés.

– Bien que les personnels aient une qualification standard, il peut arriver que celle-ci soit redéfinie dans le cadre de leur affectation à un contrat particulier.

– La facturation est faite au client sur la base d'un tarif journalier propre à chaque qualification, conformément aux clauses du contrat.

Modèle Entité-Association : Première analyse

Candidats à l'existence propre : le contrat, le client, la personne (i.e. l'intérimaire)

Modèle Entité-Association :le problème des qualifications

Qualification = attribut de l'intérimaire. Mais, il existe une nomenclature des qualifications (un "standard").

– Par conséquent, cet attribut va prendre plusieurs fois la même valeur dans des occurrences différentes de PERSONNES et nous allons avoir de la redondance.

– Il semble donc plus intéressant d'en faire une entité.

Modèle Entité-Association :les intérimaires dans le contrat Il faut associer les personnes aux contrats. Cette association

concerne aussi les clients et les qualifications.

Modèle Entité-Association :les intérimaires dans le contrat Simplification évidente qui résulte de la contrainte

d'intégrité fonctionnelle entre contrats et clients. – Si on sait dans quel contrat intervient une personne, le client est

immédiatement déductible : il n'y en a qu'un. – Donc la patte intervenir-client est bien à supprimer.

Par un raisonnement semblable : si on connaît l'interimaire qui intervient dans un contrat, on a la qualification. Donc on doit supprimer la patte intervenir- qualification.

– PAS SI VITE ! Sinon, tout intérimaire intervenant dans un contrat y travaillera au titre de sa qualification STANDARD. Or, celle-ci peut être redéfinie lors d'une affectation à un contrat particulier. Il ne faut donc pas décomposer ici !

Modèle Entité-Association :les intérimaires dans le contrat (fin)

Modèle Entité-Association :le nombre de journées*hommes En première approximation, le nombre de

journées*hommes pour notre société d'intérim est une propriété descriptive des contrats.

– En fait, c'est plus compliqué ici. D'après l'énoncé, on caractérise un contrat par la liste des volumes d'activité pour chaque qualification. Le nombre de journées*homme n'est pas monovalué dans contrats et on ne serait donc pas en 1FN.

– Il faut donc faire autrement. Il se trouve que l'association INTERVENIR mentionne pour chaque contrat la qualification qu'il utilise. On peut donc penser à faire du nombre de journées*hommes une propriété d'intervenir :

Modèle Entité-Association :le nombre de j*h (suite)

Il reste un problème : nous déclarons ainsi que le nb de j*h dépend du contrat et de la qualification, ce qui est correct, mais nous indiquons du même coup qu'il dépend de la personne. Ce qui est évidemment faux : le modèle n'est pas en 2FN.

Modèle Entité-Association :le nombre de j-h (fin) Il faut donc créer une association spécifique et indépendante

entre contrats et qualifications :

Modèle Entité-Association :les factures

Il s'agit d'un objet calculable à partir des autres propriétés du modèle. – il s'agit d'une entité "dérivée".

Le modèle logique des données CLIENTS(Codclient, Nom, Prenom, AdRue, AdVille,

CodePostal) CONTRATS(NumeroContrat, Objet, DateSign,

Datedeb, Datefin, #CodeCli) PERSONNES(Matricule, Nom, Prenom, AdRue, Advil,

CodePostal, #CodeQualif) QUALIFICATIONS(CodeQualif, Libelle, Tarif) INTERVENIR(#NumContrat, #Matricule, #CodeQualif)

EXIGER(#NumContrat, #CodeQualif, Nbjh)

Implémentation du schéma dans le SGBD Access Il faut d'abord DECLARER ce schéma de la base de

données en choisissant l'onglet "TABLES"– ce qui correspond dans un SGBD classique au Langage de

Description des Données (LDD) : par exemple CREATE TABLE en SQL.

– Et qui donne par exemple pour la relation CONTRATS :

Implémentation du schéma dans le SGBD Access (suite) Les tables étant décrites, il

faut maintenant DECLARER les mécanisme de clés étrangères.

Implémentation du schéma dans le SGBD Access (suite) Pour déclarer une clé étrangère :

– positionner le pointeur de souris sur la clé primaire et glisser vers la clé étrangère

– Access reconnaît qu'il s'agit d'un lien du type 1 à plusieurs par exemple entre CLIENTS et CONTRATS

– Il propose la vérification de l'intégrité référentielle : Tout Codecli de CONTRATS doit avoir 1 valeur identique dans Codcli de CLIENTS (sinon ce serait un contrat pour un client inconnu).

Observer que : – les "cardinalités" semblent à l'envers mais il s'agit de cardinalités

des LIENS. Elles se lisent de la façon suivante : un n-uplet de la table CLIENTS est associé à plusieurs n-uplets de la table CONTRATS, inversement un n-uplet de CONTRATS est lié à un seul n-uplet de CLIENTS.

•u

Merci à Morand de l'IUT de Caen