[MCD] Gestion d'embauche de dockers [Résolu]

[android32]

Bonjour,
débutant en merise je doit concevoir une application de gestion d'embauche dockers plus précisément sur les différentes statistique d'embauches journaliere-mensuelle-annuelle par société et par hall d'embauche
avec ces règles de gestion suivantes

1-un docker ne peut travailler que pour un et un seul shift par jour
(une journée comporte 2 shift ,le jour et la nuit)

2-un Resp d'embauche peut être un commis mais pas le contraire
3-une fiche d'embauche concerne que 2 personnes le commis et le responsable d'embauche(impossible d’écrire 0;2 avec le logiciel jmerise)



questions
vu mon mcd
1- si je supprime une société(adhérent) automatiquement toutes les embauches reliées doivent disparaitre
est-ce la peine de mettre fiche embauche en identification relative avec l’entité adhérent ?
2-mon entité shift ne possède pas d'identifiant (numérique) cela se fait ?

3-concernant la place de date en tant que propriété dans mon cas ??

4- avec le logiciel Jmerise j'ai utilisé l’égalité dans l’héritage mais j'avoue que je ne sais pas trop ce que cela signifie

des suggestions me seront les bienvenues pour optimiser mon MCD
NB:Mon application ne possédera pas de système de pointage

[fsmrel]

Bonsoir,

Envoyé par android32

un docker ne peut travailler que pour un et un seul shift par jour

En français, qu’est-ce qu’un shift ?

Envoyé par android32

un Resp

Merci d’écrire les mots en entier, c’est la moindre des politesses, vous ne rédigez pas un télégramme.

Envoyé par android32

un Resp d'embauche peut être un commis mais pas le contraire

Qu’est-ce qu’un commis dans votre système ?

Envoyé par android32

si je supprime une société(adhérent) automatiquement toutes les embauches reliées doivent disparaître
est-ce la peine de mettre fiche embauche en identification relative avec l’entité adhérent ?

Sans objet. Le MCD décrit la partie statique, « anatomique » des choses, tandis que la suppression est une opération à prendre en compte à un autre niveau, où l’on s’intéresse au métabolisme des données. Par exemple, vous coderez au niveau SQL :

1) Si l’identification n’est pas relative :

Code SQL :

1
2
3
4
5
6
7
CREATE TABLE FICHE_EMBAUCHE
IdAdhrent           INT         NOT NULL,
IdFiche             INT         NOT NULL,
...
PRIMARY KEY (IdFiche),
FOREIGN KEY (IdAdhrent) REFERENCES ADHERENT
           ON DELETE CASCADE ;

2) Si l’identification est relative :

Code SQL :

1
2
3
4
5
6
7
CREATE TABLE FICHE_EMBAUCHE
IdAdhrent           INT         NOT NULL,
IdFiche             INT         NOT NULL,
...
PRIMARY KEY (IdAdhrent, IdFiche),
FOREIGN KEY (IdAdhrent) REFERENCES ADHERENT
           ON DELETE CASCADE ;

Mais dans les deux cas, c’est le choix que vous faites de la réaction aux stimuli (ON DELETE CASCADE) qui permettra de supprimer les fiches en même temps que l’adhérent. « ON DELETE CASCADE » veut dire : « M. l’adhérent, si vous disparaissez, nous, les fiches, sommes d’accord pour disparaître aussi. »

Cela dit, dans le monde de l'entreprise on ne supprime pas comme ça les fiches d'embauche, les comptables et autres gens vigilants ne le permettraient pas (avant qu'un certain laps de temps légal ne se soit écoulé)...

Envoyé par android32

mon entité shift ne possède pas d'identifiant (numérique) cela se fait ?

Alors à quoi correspond id_shift ? De toute façon, Merise ne se prononce pas sur le type des identifiants. La seule recommandation est qu’un identifiant soit invariant, donc totalement dépourvu de signification.

Envoyé par android32

concernant la place de date en tant que propriété dans mon cas ??

De quelle date parlez-vous ?

Envoyé par android32

avec le logiciel Jmerise j'ai utilisé l’égalité dans l’héritage mais j'avoue que je ne sais pas trop ce que cela signifie

Je ne connais pas Jmerise, mais en Merise proprement dit, le symbole « = » veut dire égalité, identité, donc qu’un commis est un responsable et réciproquement, mais ça ne correspond évidemment pas à vos règles de gestion.


A propos de votre MCD

Les entités-types PERSONNEL et DOCKER peuvent faire l’objet d’une généralisation, afin de factoriser les propriétés communes (ainsi que les relations communes, avec FICHE_EMBAUCHE par exemple).

Une même fiche d’embauche peut concerner plusieurs dockers et plusieurs membres du personnel : curieux...
Paradoxalement, elle peut ne concerner aucune de ces personnes...

Question : au mélange près que vous autorisez, une fiche d’embauche peut concerner plusieurs personnes de la même catégorie (celle des dockers par exemple) ?

La patte connectant SHIFT et la ternaire TRAVAILLER est porteuse d’une cardinalité 0,1 : c’est tout à fait louche. Qu’avez-vous voulu exprimer en procédant ainsi ?

[android32]

En français, qu’est-ce qu’un shift ?

dans mon cas le shift est la periode de travail
en une journne il y'a 2 types de periode de travail :le jour et la nuit
-un docker ne peut donc travailler que soit dans le shift jour soit dans le shift nuit mais pas les 2 shift du meme jour
-pareil pour la fiche d'embauche elle ne concerne qu'un seul shift par jour

Merci d’écrire les mots en entier, c’est la moindre des politesses, vous ne rédigez pas un télégramme.

désolé,
cela représente le responsable d'embauche

Qu’est-ce qu’un commis dans votre système ?

le commis est chargé d'enregistrer les dockers sur une fiche

Alors à quoi correspond id_shift ? De toute façon, Merise ne se prononce pas sur le type des identifiants. La seule recommandation est qu’un identifiant soit invariant, donc totalement dépourvu de signification.

juste une erreur le id_shift est a considérer comme effacer

De quelle date parlez-vous ?

je fais allusion a la date qui est une propriété de fiche d'embauche
vu que mon proget fait allusion au statististique sur une periode donne
je pense mettre la date en entité
pas vous?

Une même fiche d’embauche peut concerner plusieurs dockers et plusieurs membres du personnel : curieux...
Paradoxalement, elle peut ne concerner aucune de ces personnes...

une embauche peut concerne au moins un docker

le commis qui est chargé de l'embauche
et le responsable du centre d'embauche

voici les regles de gestion que je m'etais trouvées
RG4-un docker travaille pour un et un seul adhérent à une date donne
RG5-un docker travail sur un seul shift par jour
RG6-une société peut faxer une ou plusieurs fiches de demande d’embauche
RG7- une embauche concerne un et un seul type d’embauche (acconage ou transit)
RG8- une embauche concerne un ou plusieurs dockers
RG9- a une fiche d’embauche correspond une et une seul période jour ou nuit
RG10- une embauche concerne un et un seul commis et un responsable d’embauche
RG-11 une société peut avoir un ou plusieurs acconages ou transit sur un même shift
RG-10 Un reponsable d’embauche peut etre un commis mais pas le contraire
RG- un docker est un membre du personnel
RG- un docker travaille sur tout type d'embauche
RG- un docker travaille pour une et une seule societe par jour
ces regles cités ci dessus
sont elle toutes des regles de gestions ??

Question : au mélange près que vous autorisez, une fiche d’embauche peut concerner plusieurs personnes de la même catégorie (celle des dockers par exemple) ?

il n'ya qu'une seul catégorie de dockers
un docker ayant exercé dans l'acconage aujourd'hui peut bien se retrouver dans le transit un autre jour
a par cela je ne vois pas de quel catégorie vous voulez parler

La patte connectant SHIFT et la ternaire TRAVAILLER est porteuse d’une cardinalité 0,1 : c’est tout à fait louche. Qu’avez-vous voulu exprimer en procédant ainsi ?

j'ai modifié mon mcd
mais je suis dans l'embarras concernant le fait qu'un responsable d'embauche peut être un commis

[fsmrel]

Bonjour,

Envoyé par android32

il n'ya qu'une seul catégorie de dockers
un docker ayant exercé dans l'acconage aujourd'hui peut bien se retrouver dans le transit un autre jour
a par cela je ne vois pas de quel catégorie vous voulez parler

Quand je parle des catégories de personnes, je veux dire qu’il s’agit de la typologie des personnes :

Catégorie X : les dockers d’une part.
Catégorie Y : les personnes qui ne sont pas des dockers d’autre part (les responsables et les commis).

Selon votre 1er MCD, une fiche d’embauche donnée peut concerner indifféremment des dockers, des responsables et des commis, d’où ma question. Avec votre 2e MCD, vous marquez une distinction selon les rôles des personnes. Cette fois-ci le rôle des commis et des responsables se précise. Considérons la fiche d’embauche F1234 :

1) Cette fiche d’embauche concerne au plus un commis, dont le rôle est de l’enregistrer (plutôt que Concerner2...), tandis qu’elle reçoit un coup de tampon (?) de la part du responsable (merci de remplacer Concerner3 par un verbe explicite, qui facilite la compréhension du MCD).

2) Toujours selon votre 2e MCD, cette fiche concerne de 1 à N dockers. C’est en fait la réponse à la question que je posais : Une fiche peut-elle concerner plus d’un docker ? (Sous-entendu compte non tenu des commis et des responsables). Clairement vous répondez : Oui.

Envoyé par android32

je suis dans l'embarras concernant le fait qu'un responsable d'embauche peut être un commis

Il y a à boire et à manger... Vous écrivez :

(1) Un responsable d'embauche peut être un commis.

(2) Un commis ne peut pas être un responsable.

Autrement dit on peut reformuler (1) et (2) sous forme d’énoncés au sens de la logique classique :

(3) Quelques responsables sont des commis.

(4) Aucun commis n’est un responsable.

Ou encore, si on symbolise « Être responsable » par F et « Être commis » par G, (3) et (4) deviennent respectivement :

(5) : (∃x)(Fx.Gx)

(6) : —(∃x)(Fx.Gx)

Où Fx.Gx se lit : Fx ET Gx et le symbole « — » représente la négation. Les deux énoncés sont contradictoires. C’est comme si vous écriviez : Un colonel peut être capitaine et un capitaine n’est pas colonel...

Conclusion, un responsable ne peut pas être un commis. A mon sens, il faudrait donc plutôt raisonner en termes de rôles : un responsable peut jouer le rôle de commis (enregistrer les fiches), mais un commis ne peut pas jouer le rôle de responsable (tamponner les fiches), tout comme un colonel peut se substituer à un capitaine absent pour signer des papiers, alors qu'un capitaine ne peut pas décider à la place d'un colonel.

Exemple :

M. Charles est commis, il a enregistré les fiches 1, 2 et 3.
M. Robert est responsable d’embauche, il a tamponné les fiches 1, 2 et 3.
M. Robert a aussi joué le rôle de commis et il a enregistré les fiches 4, 5 et 6.
Il a tamponné les fiches 4 et 6, et c’est un autre responsable, M. Raymond qui a tamponné la fiche 5.

Je vous laisse le soin de remplacer le verbe tamponner par celui qui vous convient. Il faut aussi que vous vous prononciez sur la validité des actions réalisées par MM. Charles, Robert et Raymond.


Sous forme de MCD

Je considère l’ensemble des employés de l’entreprise (j’ignore ici les dockers). Il y a deux catégories d’employés (du moins vu de la prise en compte des fiches) :

— Les employés concernés par l’enregistrement et/ou le tamponnage des fiches, que j’ai appelés les embaucheurs (à vous de trouver le nom qui convient).

— Les employés qui ne sont pas concernés par l’enregistrement et le tamponnage des fiches, que j’ai appelés les autres (à vous de trouver le nom qui convient). Si en fait la population des employés se limite aux commis et aux responsables, on peut évidemment simplifier la représentation et évacuer le sous-type AUTRE.

Ensuite, un embaucheur est soit un responsable, soit un commis.

Un embaucheur peut enregistrer des fiches.

Seul un responsable peut tamponner des fiches.

A vous de mettre tout cela sous la forme qui vous convient (si bien sûr vous êtes d’accord avec le principe de la révision que j’ai faite). Incidemment, si le sous-type COMMIS n’a pas de propriétés particulières, il peut dégager (à moins qu’il ne joue d’autres rôles non représentés ici).



Il y a encore pas mal de choses à dire, mais je sui obligé de vous quitter.


A bientôt.

[android32]

j'aimerais avoir votre avis sur le choix de ces 2 phrases comme regle de gestion

-un docker travaille pour un et un seul adhérent à une date donne
-un docker travail sur un seul shift par jour

Sous forme de MCD

Je considère l’ensemble des employés de l’entreprise (j’ignore ici les dockers). Il y a deux catégories d’employés (du moins vu de la prise en compte des fiches) :

— Les employés concernés par l’enregistrement et/ou le tamponnage des fiches, que j’ai appelés les embaucheurs (à vous de trouver le nom qui convient).

— Les employés qui ne sont pas concernés par l’enregistrement et le tamponnage des fiches, que j’ai appelés les autres (à vous de trouver le nom qui convient). Si en fait la population des employés se limite aux commis et aux responsables, on peut évidemment simplifier la représentation et évacuer le sous-type AUTRE.

Ensuite, un embaucheur est soit un responsable, soit un commis.

Un embaucheur peut enregistrer des fiches.

Seul un responsable peut tamponner des fiches.

A vous de mettre tout cela sous la forme qui vous convient (si bien sûr vous êtes d’accord avec le principe de la révision que j’ai faite). Incidemment, si le sous-type COMMIS n’a pas de propriétés particulières, il peut dégager (à moins qu’il ne joue d’autres rôles non représentés ici).

Merci pour cette astuce claire et simple

Conclusion, un responsable ne peut pas être un commis. A mon sens, il faudrait donc plutôt raisonner en termes de rôles :

c'est donc ma formulation qui créait cette difficulté de modélisation

Il faut aussi que vous vous prononciez sur la validité des actions réalisées par MM. Charles, Robert et Raymond.

c'est à dire?

Il y a à boire et à manger...

vraiment....

[fsmrel]

Envoyé par android32

c'est à dire?

Je voudrais savoir si les exemples que j’ai donnés sont valides, par exemple que M. Robert enregistre les fiches 4, 5 et 6, qu’il tamponne lui-même la 4 et la 6, tandis que c’est M. Raymond qui tamponne la 5.
D’après le MCD que j’ai proposé cet exemple est possible et légal, mais confirmez vous ?

Envoyé par android32

j'aimerais avoir votre avis sur le choix de ces 2 phrases comme regle de gestion

-un docker travaille pour un et un seul adhérent à une date donne
-un docker travail sur un seul shift par jour

« Un est un seul » a le sens de « au moins un et au plus un ». Vous pourriez écrire : « A une date donnée, un docker peut ne pas travailler, mais s’il travaille c’est au plus pour un adhérent ». Ou encore : « Si un docker travaille à une date donnée, c’est pour un seul adhérent ».
Vous pouvez retailler ces phrases, l’essentiel est que le lecteur perçoive sans ambiguïté le côté optionnel de la chose. Mieux vaut mettre de la lourdeur plutôt que de rédiger des phrases concises mais ambiguës.

Même chose pour le shift : Si un docker travaille à une date donnée, c’est sur un seul shift. Etc.


Cela dit, j’observe que l’entité-type FICHE_EMBAUCHE est en relation avec l’entité-type DATE. La patte connectant FICHE_EMBAUCHE et S’EFFECTUER est porteuse d’une cardinalité minimum 0 : la durée de l’embauche pourrait alors être de 0 jour ? Quel sens donner à cela ? Pour sa part la cardinalité maximum est N : une fiche pourrait donc faire l’objet d’une durée de plusieurs jours ?

Concernant la fiche, quelle est la signification des attributs dock_dem, dock_emb (quelle relation avec l’entité-type DATE ?)
Shift figure en tant attribut de FICHE_EMBAUCHE : au cas où une fiche porte sur plusieurs jours (cf. l’association-type S’EFFECTUER), le shift serait donc invariant pendant tout ce temps. C’est bien cela ? En tout cas qui peut le plus peut le moins : si les dockers Croquignol, Filochard et Ribouldingue sont embauchés tel jour, ils figurent tous trois sur la fiche d’embauche et leur shift est celui de la fiche : la règle « un docker travaille sur un seul shift par jour » est une conséquence logique de celle qui vaut pour la fiche, selon laquelle, les dockers inscrits sur la fiche travaillent sur le shift mentionné par la fiche.
Maintenant, l'attribut Shift est-il bien à sa place ?


Je subodore qu’il va y avoir une contrainte à mettre en œuvre, selon laquelle un docker ne peut pas figurer à une date donnée sur deux fiches différentes :



La flèche rouge symbolise une contrainte d’intégrité fonctionnelle (CIF) encore appelée contrainte d’unicité, qui veut que pour un docker et une date on ait une seule fiche :

DOCKER X DATE -> FICHE

A suivre...

[android32]

Je voudrais savoir si les exemples que j’ai donnés sont valides, par exemple que M. Robert enregistre les fiches 4, 5 et 6, qu’il tamponne lui-même la 4 et la 6, tandis que c’est M. Raymond qui tamponne la 5.
D’après le MCD que j’ai proposé cet exemple est possible et légal, mais confirmez vous ?

vos exemples vont dans ma logique de conception
merci pour les idées

« Un est un seul » a le sens de « au moins un et au plus un ». Vous pourriez écrire : « A une date donnée, un docker peut ne pas travailler, mais s’il travaille c’est au plus pour un adhérent ». Ou encore : « Si un docker travaille à une date donnée, c’est pour un seul adhérent ».
Vous pouvez retailler ces phrases, l’essentiel est que le lecteur perçoive sans ambiguïté le côté optionnel de la chose. Mieux vaut mettre de la lourdeur plutôt que de rédiger des phrases concises mais ambiguës.

voir pièce jointe

Concernant la fiche, quelle est la signification des attributs dock_dem, dock_emb (quelle relation avec l’entité-type DATE ?)

dock_dem= docker demandé
dock_emb=docker reçu ou embauche
il y'a aussi un attribut déficit=dock_dem -docker_emb

Shift figure en tant attribut de FICHE_EMBAUCHE : au cas où une fiche porte sur plusieurs jours (cf. l’association-type S’EFFECTUER), le shift serait donc invariant pendant tout ce temps. C’est bien cela ?

apres mon interview j'ai été suppris d'apprendre qu'un fiche d'embaue fini toujours dans son temps impartit
par exemple une fiche d'embauche sur un shift jour à une date donnée
fini toujours a temps et n’empiète jamais sur le shift soir du même jour

Je subodore qu’il va y avoir une contrainte à mettre en œuvre, selon laquelle un docker ne peut pas figurer à une date donnée sur deux fiches différentes :

concernant les associations ternaires auriez vous un article qui en parle
car j'ai du mal a les comprendre
Encore merci de votre aide que vous m'apportez

PS concernant l'entite dockers et l'entite fiche embauche je coince

[fsmrel]

Envoyé par android32

voir pièce jointe

Votre MCD n’exprime pas forcément les règles de gestion...

Par exemple, il permet que le docker Croquignol soit inscrit sur la fiche 1234 qui fait référence à l’adhérent Schmoll, alors que le même jour Croquignol a déjà été inscrit sur la fiche 314116 qui fait référence à l’adhérent Yadupour.

Donc, rien de tel que de fournir aussi les règles en français, même quand elles sont un peu lourdes.

Règles en français + exemples (cas de Croquignol) + MCD => on voit à peu près où on va.

Envoyé par android32

dock_dem= docker demandé
dock_emb=docker reçu ou embauche

Hum... Comme manifestement une fiche donnée peut concerner plusieurs dockers (par exemple Croquignol, Filochard et Ribouldingue), quel est le sens de votre phrase ? le statut est à « demandé » tant qu’on n’a pas l’équipe au complet ?

Par ailleurs, pourquoi deux attributs ? Un seul ne suffit pas ? (dock_emb = 0 signifiant demandé et dock_emb = 1 signifiant « équipe au complet) ».

Envoyé par android32

concernant l'entite dockers et l'entite fiche embauche je coince

C’est à cause de la ternaire ?

Je rappelle que j’ai proposé ceci :

A une date donnée, un docker ne peut figurer que sur une seule fiche.

La représentation graphique que j’ai proposée est une représentation classique en Merise. Mais comme PowerAMC ne sait pas prendre en compte les CIF, on peut ruser ainsi : On déguise l’association-type INSCRIPTION en entité-type, on la dote de l’attribut InscrDate (date d’inscription) et on identifie cette entité-type relativement à DOCKER (sans oublier de rendre InscrDate identifiant). L’identifiant de INSCRIPTION est en fait la paire {DockerId, InscrDate}. Si on n’avait pas utilisé l’identification relative, on aurait été refaits, INSCRIPTION ayant alors pour identifiant seulement InscrDate.

Pour mémoire, pour faire comprendre à PowerAMC qu’on met en oeuvre l’identification relative, il faut mettre entre parenthèses la cardinalité 1,1 portée par la patte connectant DOCKER et INSCRIPTION :




Lors du passage au MLD, on constate qu’effectivement INSCRIPTION a bien pour clé primaire la paire {DockerId, InscrDate} :



Autrement dit, à une date donnée on ne peut inscrire un docker que sur une seule fiche. C’est bien ce que vous vouliez ? En tout cas, la conséquence de ceci est que, puisqu’une fiche fait référence à un seul adhérent, à la date InscrDate, un docker ne travaille que pour un seul adhérent.

Maintenant, ceci ne nous prémunit pas contre les recouvrements de périodes si une fiche peut porter sur plusieurs jours.

Au fait, rappelez-moi le rôle de l’attribut Date de la fiche d’embauche : il n’y a plus de date de fin ? La durée d’une embauche a été ramenée à une journée ? Un shift ?

N.B.

Je n'ai pas le temps de parler des ternaires, mais on verra ça la prochaine fois.
N'hésitez pas à plusser en bas à droite quand une réponse vous convient, ça entretient la flamme...

[android32]

Bonjour

Hum... Comme manifestement une fiche donnée peut concerner plusieurs dockers (par exemple Croquignol, Filochard et Ribouldingue), quel est le sens de votre phrase ? le statut est à « demandé » tant qu’on n’a pas l’équipe au complet ?

Par ailleurs, pourquoi deux attributs ? Un seul ne suffit pas ? (dock_emb = 0 signifiant demandé et dock_emb = 1 signifiant « équipe au complet) ».

il arrive des moments ou la structure de placement n'a rrive pas a fournir l'effectif demandé par une societe
dock_dem= effectif demandé par la societe
dock_emb= effectif proposé par la structure d eplacement
deficit= la différence entre les 2

Au fait, rappelez-moi le rôle de l’attribut Date de la fiche d’embauche : il n’y a plus de date de fin ? La durée d’une embauche a été ramenée à une journée ? Un shift ?

concernant date de fin ; le shift l'exprime deja
shift jour=7h30 ---19h30
shift nuit=19h30 7h30
une embauche ne déborde jamais sur le shifft qui suit , elle finie toujours dans le temps qui lui est imparti

a partir e votre relation ternaire
je lis
-un Docker s'inscrit sur 0,n fiche d'embauche a 0,n date
-sur une fiche d'embauche est inscrit 1,n docker a 0,n date
est comme cela que la lecture de la relation ternaire se fait?

[fsmrel]

Bonsoir,

Envoyé par android32

il arrive des moments ou la structure de placement n'a rrive pas a fournir l'effectif demandé par une societe
dock_dem= effectif demandé par la societe
dock_emb= effectif proposé par la structure d eplacement
deficit= la différence entre les 2

D'accord, je comprends mieux.

Envoyé par android32

concernant date de fin ; le shift l'exprime deja
shift jour=7h30 ---19h30
shift nuit=19h30 7h30
une embauche ne déborde jamais sur le shifft qui suit , elle finie toujours dans le temps qui lui est imparti

C’est ce que vous disiez dans votre précédent message. Mais je précise ma pensée :

Supposons que Croquignol, Filochard et Ribouldingue aient été inscrits sur la fiche 1234 qui précise que le shift correspond à la période 7h30 - 19h30. La durée de l’embauche de ce trio a-t-elle pu s’étaler par exemple du lundi au mercredi ? Étant entendu qu’ils n’auront donc travaillé que de 7h30 à 19h30 pendant cette période, alors que selon la fiche d’embauche 2547, une autre équipe (disons Athos, Porthos et Aramis) aura pris leur relais de 19h30 à 7h30.

Question : ce scénario est-il valide ? Sinon, la durée de l’embauche est-elle limitée à une seule journée ? (C'est-à-dire un seul shift).

Envoyé par android32

a partir e votre relation ternaire
je lis
-un Docker s'inscrit sur 0,n fiche d'embauche a 0,n date
-sur une fiche d'embauche est inscrit 1,n docker a 0,n date
est comme cela que la lecture de la relation ternaire se fait?

On n'est pas loin (il manque le 3e cas, celui de la date). Regardons de plus près :


Dans le cas général (absence de CIF)




Cas de FICHE (1,N)

La cardinalité minimum 1 indique qu’une fiche est associée — via la relation INSCRIPTION — à au moins un docker et au moins une date.

La cardinalité maximum N indique qu’une fiche peut être associée à la fois — via la relation INSCRIPTION — à un nombre quelconque de dockers et de dates.

Cas de DOCKER (0,N)

La cardinalité minimum 0 indique qu’un docker est facultativement associé — via la relation INSCRIPTION — à une fiche et une date.

La cardinalité maximum N indique qu’un docker peut être associé à la fois — via la relation INSCRIPTION — à un nombre quelconque de fiches et de dates.

Cas de DATE (0,N)

La cardinalité minimum 0 indique qu’une date est facultativement associée — via la relation INSCRIPTION — à une fiche et un docker.

La cardinalité maximum N indique qu’une date peut être associée à la fois — via la relation INSCRIPTION — à un nombre quelconque de fiches et de dockers.

Dans tous les cas, chaque occurrence d’INSCRIPTION fait mention d’une fiche, d’un docker et d’une date :

Code :

1
2
3
4
5
6
7
8
9
10
11
Fiche    Date    Docker

2578     2011-07-15    Gaston 
2578     2012-12-03    Marcel
2578     2012-12-03    Ribouldingue
2578     2012-12-03    Gaston
7234     2011-07-15    Croquignol
7234     2011-07-15    Gaston
7234     2012-12-03    Croquignol
7234     2012-12-03    Filochard
7234     2012-12-03    Ribouldingue

On voit que l’on peut tricoter les fiches, les dockers et les dates absolument comme on veut.


Cas particulier de la CIF

Comme on le sait, la CIF complète la sémantique et exprime une contrainte d’unicité selon laquelle à une date donnée un docker n’est inscrit que sur une seule fiche :

DOCKER X DATE -> FICHE

Ce qui fait que certaines occurrences ne peuvent pas être inscrites dans la base de données (il y aura un refus parce que la clé sera composée seulement de la paire {DockerId, Date}) :

Code :

1
2
3
4
5
6
7
8
9
10
11
Fiche    Date    Docker

2578     2011-07-15    Gaston 
2578     2012-12-03    Marcel
2578     2012-12-03    Ribouldingue
2578     2012-12-03    Gaston
7234     2011-07-15    Croquignol
7234     2011-07-15    Gaston            (à la date du 2011-07-15 Gaston figure déjà sur la fiche 2578)
7234     2012-12-03    Croquignol
7234     2012-12-03    Filochard
7234     2012-12-03    Ribouldingue      (à la date du 2012-12-03 Ribouldingue figure déjà sur la fiche 2578)

Mais il y a encore quelque chose que je n’ai pas dit... Il est en effet choquant de constater que la fiche 7234 mentionne 2 fois Croquignol pour deux dates différentes, mais on en reparlera la prochaine fois...

[android32]

C’est ce que vous disiez dans votre précédent message. Mais je précise ma pensée :

Supposons que Croquignol, Filochard et Ribouldingue aient été inscrits sur la fiche 1234 qui précise que le shift correspond à la période 7h30 - 19h30. La durée de l’embauche de ce trio a-t-elle pu s’étaler par exemple du lundi au mercredi ? Étant entendu qu’ils n’auront donc travaillé que de 7h30 à 19h30 pendant cette période, alors que selon la fiche d’embauche 2547, une autre équipe (disons Athos, Porthos et Aramis) aura pris leur relais de 19h30 à 7h30.

Question : ce scénario est-il valide ? Sinon, la durée de l’embauche est-elle limitée à une seule journée ? (C'est-à-dire un seul shift).

scenario invalide l'embauche ne tient que sur une seule journne

Cas de FICHE (1,N)


La cardinalité maximum N indique qu’une fiche peut être associée à la fois — via la relation INSCRIPTION — à un nombre quelconque de dockers et de dates.

La cardinalité maximum N indique qu’une fiche peut être associée à la fois — via la relation INSCRIPTION — à un nombre quelconque de dockers, oui
mais pas un nombre quelconque de dates

selon vos 2 schémas la contrainte de CIF se fait remarqué juste par la présence de la flèche rouge
j'aurai pensai qu'il fallait une cardinalité max a 1 pour parler de CIF?

2578 2011-07-15 Gaston
2578 2012-12-03 Marcel

Mais il y a encore quelque chose que je n’ai pas dit... Il est en effet choquant de constater que la fiche 7234 mentionne 2 fois Croquignol pour deux dates différentes, mais on en reparlera la prochaine fois...

vu que l'embauche ne peut tenir sur plus d'une journne ce cas n'est pas possible

[fsmrel]

Bonsoir,

Envoyé par android32

scenario invalide l'embauche ne tient que sur une seule journée

On apprend enfin qu’une embauche ne vaut que pour un jour donné. Il faudra mettre à jour les règles de gestion, notamment RG5 et RG9 car elles ne sont pas incompatibles avec le scénario invalide : en l’état elles sont incomplètes.

Pour éviter toute ambiguïté et savoir exactement à quoi correspond la date dans l’entité-type FICHE_EMBAUCHE : date de création de la fiche ? Quoi d’autre ? Puisqu’il s’agit en réalité de la date d’embauche des dockers, il faut le préciser dans les règles de gestion et, il faudrait renommer l’attribut Date en quelque chose comme DateEmbauche (d’autant plus que « Date » est un mot réservé en SQL et vous auriez droit à une erreur de syntaxe en l’utilisant comme nom de colonne).

Situation actuelle :



Aménager donc.

A noter en passant que CinePhil va vous remonter les bretelles s’il voit que id_fiche_emb est du type CHAR(10), et il faudrait par ailleurs rendre obligatoire chaque attribut.

Envoyé par android32

La cardinalité maximum N indique qu’une fiche peut être associée à la fois — via la relation INSCRIPTION — à un nombre quelconque de dockers, oui
mais pas un nombre quelconque de dates

N’oubliez pas que ce que j’explique correspond — comme vous le demandiez — au cas général des associations-types ternaires. Dans vote cas particulier, la donne change.


Jusqu’ici, la situation est la suivante du point de vue conceptuel :




On peut maintenant mettre en évidence le fait que la durée d’une embauche est la journée (dans les limites d’un shift), en établissant une association (appelons-la : FD) entre FICHE et DATE. On définit en plus une contrainte d’inclusion (I) entre INSCRIPTION et FD, selon laquelle la date portée par une inscription doit être la conséquence logique de la date portée par la fiche correspondante :




PowerAMC produit le MLD brut et incomplet suivant, car on ne sait pas lui faire comprendre les contraintes :





On retouche manuellement la clé primaire de la table INSCRIPTION pour la mettre en conformité avec la contrainte connue, selon laquelle :

A une date donnée, un docker ne peut être inscrit que sur une seule fiche.

Ce qui revient à réduire cette clé primaire à la paire {DockerId, DateEmb}, en notant que pour des raisons de lisibilité, j’ai renommé la colonne DateJour en DateEmb (tables FICHE et INSCRIPTION).

En outre, un docker ne peut pas figurer deux fois sur la même fiche (cf. l’association-type S’INSCRIRE de votre dernier MCD), la paire {FicheId, DockerId} fait donc l’objet d’une clé alternative (alternate key, mickey <ak>) :







Mais concernant la contrainte d’inclusion comme quoi la date d’embauche figurant dans l’en-tête de la table INSCRIPTION (colonne DateEmb) doit être égale à la date d’embauche figurant dans l’en-tête de la table FICHE (colonne DateEmb), elle doit être prise en compte manuellement (assertion selon la norme SQL, triggers si le SGBD ne propose pas l’instruction CREATE ASSERTION). Je rappelle que cette contrainte permet de s’assurer qu’un docker ne peut pas être inscrit sur deux fiches différentes portant la même date.


Code SQL (tables FICHE et DOCKER) :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE FICHE 
(
   FicheId              Int                  NOT NULL,
   DateEmb              Datetime             NOT NULL,
   CONSTRAINT FICHE_PK PRIMARY KEY (FicheId)
) ;
CREATE TABLE DOCKER 
(
   DockerId             Int                  NOT NULL,
   DockerNom            Varchar(64)          NOT NULL,
   CONSTRAINT DOCKER_PK PRIMARY KEY (DockerId)
) ;

Table INSCRIPTION :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE INSCRIPTION 
(
   FicheId              Int                  NOT NULL,
   DockerId             Int                  NOT NULL,
   DateEmb              Datetime             NOT NULL,
   CONSTRAINT INSCRIPTION_PK PRIMARY KEY (DockerId, DateEmb),
   CONSTRAINT INSCRIPTION_AK UNIQUE (FicheId, DockerId),
   CONSTRAINT INSCRIPTION_FICHE_FK FOREIGN KEY (FicheId)
      REFERENCES FICHE (FicheId),
   CONSTRAINT INSCRIPTION_DOCKER_FK FOREIGN KEY (DockerId)
      REFERENCES DOCKER (DockerId)
) ;

Prise en compte par trigger (SQL Server en l’occurrence) de la contrainte comme quoi la date d’inscription d’un docker doit être égale à la date d’embauche figurant dans la fiche d’embauche (ajout d’inscriptions, reste à prendre en compte la modification de la date d’embauche : colonne DateEmb des tables FICHE et INSCRIPTION) :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TRIGGER INSCRIPTION_TRIGGER_INSERT ON INSCRIPTION INSTEAD OF INSERT AS
       DECLARE @N AS INT, @Err AS Varchar(255)
 
SET @N = (SELECT COUNT(*)  
          FROM   INSERTED AS i JOIN FICHE AS f  
                 ON i.FicheId = f.FicheId 
                 AND i.DateEmb <> f.DateEmb) ;
IF @N = 0 
    BEGIN
        INSERT INTO INSCRIPTION SELECT * FROM INSERTED
    END
ELSE
    BEGIN
        SET @Err= 'La date d’inscription d’un docker doit être égale à la date qui figure sur la fiche d’embauche.'
        RAISERROR (@Err, 15, 1)
    END

Un début de jeu d’essai, fiches et dockers :

Code SQL :

1
2
3
4
5
6
7
8
9
10
INSERT INTO FICHE (FicheId, DateEmb) VALUES (2578, '2011-07-15') ;
INSERT INTO FICHE (FicheId, DateEmb) VALUES (7234, '2012-12-03') ;
INSERT INTO FICHE (FicheId, DateEmb) VALUES (7100, '2012-12-03') ;
INSERT INTO FICHE (FicheId, DateEmb) VALUES (7500, '2012-12-20') ;
 
INSERT INTO DOCKER (DockerId, DockerNom) VALUES (1, 'Croquignol') ;
INSERT INTO DOCKER (DockerId, DockerNom) VALUES (2, 'Filochard') ;
INSERT INTO DOCKER (DockerId, DockerNom) VALUES (3, 'Ribouldingue') ;
INSERT INTO DOCKER (DockerId, DockerNom) VALUES (4, 'Gaston') ;
INSERT INTO DOCKER (DockerId, DockerNom) VALUES (5, 'Marcel') ;

Inscription refusée par le trigger :

Code SQL :

INSERT INTO INSCRIPTION (FicheId, DockerId, DateEmb) VALUES (2578, 4, '2010-01-02') ;

Inscriptions validées :

Code SQL :

1
2
3
4
5
 
INSERT INTO INSCRIPTION (FicheId, DockerId, DateEmb) VALUES (2578, 4, '2011-07-15') ;
INSERT INTO INSCRIPTION (FicheId, DockerId, DateEmb) VALUES (7234, 1, '2012-12-03') ;
INSERT INTO INSCRIPTION (FicheId, DockerId, DateEmb) VALUES (7234, 2, '2012-12-03') ;
INSERT INTO INSCRIPTION (FicheId, DockerId, DateEmb) VALUES (7500, 1, '2012-12-20') ;

Non respect de la CIF (à la date ci-dessous, le docker est déjà inscrit sur une autre fiche), l'insert sera refusé (viol PK) :

Code SQL :

INSERT INTO INSCRIPTION (FicheId, DockerId, DateEmb) VALUES (7100, 1, '2012-12-03') ;

Envoyé par fsmrel

Il est en effet choquant de constater que la fiche 7234 mentionne 2 fois Croquignol pour deux dates différentes, mais on en reparlera la prochaine fois.

Vous observerez que la clé alternative permet de faire respecter la règle selon laquelle un docker ne peut pas figurer deux fois sur une fiche.

[android32]

merci de l'aide apportée

[fsmrel]

Bonjour,

Est-ce que ça a marché ?

[android32]

Problème résolue(j'ai pas eu le temps d'utiliser tout les procédés cités ici,mais j'en ais appris bcp )
-J'ai pris la date et le shift comme étant des propriétés de l'entité
-concernant l'héritage il était de type "partition"

J'ai terminé mon logiciel et les clients son super ravis
il reste a m'orienter dans
-le Data Recovery Plan
-et les index avec sql
-et les Triggers(super avantageux)
et je confirme fsmrel , depuis le ventre de sa mère fesait déjà du SGBD relationnel

[fsmrel]

Envoyé par android32

J'ai terminé mon logiciel et les clients son super ravis

Au plaisir de vous revoir