Download
1 / 16
160 likes | 302 Views
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.
E N D
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.
u 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.
