Cas pratique : Interim.

Présentation au sujet: "Cas pratique : Interim."— Transcription de la présentation:

1 Cas pratique : Interim

2 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.

3 Modèle Entité-Association : Première analyse
Candidats à l'existence propre : le contrat, le client, la personne (i.e. l'intérimaire)

4 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é.

5 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.

6 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 !

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

8 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 :

9 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.

10 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 :

11 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".

12 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)

13 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 :

14 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.

15 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.

16 Merci à Morand de l'IUT de Caen