dates

slt, le problème est le suivant a une date donnée un employé put occuper une position onnée cad soit présent abscen en congé etc pou formuler mon mcd j'ai du mal esce que sela est juste:
employé(mat, nom , prenom, date_naissance) ou mat= clé primaire
date(date) date=clé primaire
date-employe(date,mat,position) date+mat=clés primaires
puis a chaque insertion parceque j'aurer a remplir un fomilaire je met insert into date-employe value ... ou vous aver une autre idée svp aider moi merci d'avance

Salut

mat correspond a quoi ?

moi j'aurais fait une table employe, et une table etats_jours ou j'aurais mis ces choses : abscences, deplacements, maladies, cones, ...

---

une recherche sur exalead vous aurait peut-etre evite de poser cette question

A ta place, je modéliserais de cette façon:

Tables:
employe(matricule, nom, prenom, date_naiss, etc...) PK=matricule
positions(idpos, libelle)  PK=idpos   //1=présent, 2=congé, 3=...
etre(matricule,idpos,date) PK=(matricule,idpos,date)

PK = Primary Key
NB: Dans la table "etre" (dans telle position) les trois champs ensemble sont PK. Si tu ne mets que matricule+date, cela voudrait dire qu'il pourrait y avoir un matricule (un employé) à une date donnée sans position administrative (présence, congé, ...)

A la saisie 1 formulaire pour saisir 3 infos:
-l'employé (liste déroulante)
-la position (liste déroulante)
-la date (zone de saisie)

Le script de traitement récupère les 2 identifiants + la date saisie pour alimenter la table "etre"

J'espère avoir été clair... :o)

Complément au précédent post...

+-----------+ 1,n    ------    0,n +-----------+
|  EMPLOYES +-------( ETRE )-------+ POSITIONS |
+-----------+        ------        +-----------+
| matricule |           |          | idpos     |
| nom       |           |0,n       | libelle   |
| prenom    |       +-------+      +-----------+
| datenaiss |       | DATES |
| etc...    |       +-------+
+-----------+       | date  |
                    +-------+

Tu as trois objets Merise (EMPLOYES, POSITIONS, DATES) reliés entre eux par une relation (ETRE). Chaque objet a son identifiant (matricule, date, idpos).

Si la relation avait été une-aire (au moins une cmax à 1), il n'y aurait pas eu de création de table mais une migration (l'objet de cmax à 1, récupère en plus de ses champs, les identifiants des objets reliés).

Mais ici la relation étant n-aire (toutes les cmax sont à n) la relation ETRE deviendra une table. L'identifiant d'une relation est obtenu par la concatenation des identifiants de chacun des objets participant à la relation. L'identifiant de la table ETRE sera donc (matricule,date,idpos). Elle pourra, éventuellement, comporter d'autres champs (non clefs primaires) qu'on appellera des propriétés portées par la relation et qui pourrait être par exemple dans ce cas de gestion et si c'était à gérer : un champ "reference" (référence, pièce justifiant éventuellement la position : Demande de congé n° 142, Certificat médical d'arrêt de travail du Dr Martin, ASA pour cause de décès: certificat de décès du 18/06/2007

Les tables seront donc les suivantes :
PERSONNELS(matricule, nom, prenom, date_naiss, ...)
POSITIONS(idpos, libelle)
ETRE(matricule, date, idpos, reference)

Dans ce cas précis, la date, bien qu'objet Merise, Ne donnera pas lieu à la création d'une table.

En effet, lorsqu'on connait l'identifiant d'un objet, on peut accéder aux autres propriétés. (ex: Si je viens dans la table ETRE relever un matricule, une fois muni de celui-ci, je peux retrouver l'enregistrement dans la table PERSONNELS et accéder à ses autres propriétés : le nom, le prénom, la date de naissance, etc...

Mais si je récupère le champ date dans la table ETRE, le fait d'être muni de cet identifiant ne permettra jamais d'accéder à d'autres propriétés car la seule information qui serait contenue dans la table DATES serait justement et seulement la date et que celle-ci est déjà présente dans la relation ETRE.

La table DATES ne sera donc pas crée mais doit être présente sur le MCD pour rappeler que le date doit faire partie de l'identifiant de la relation.

En fait, faire ça en 3 tables seulement, c'est assez cool... et pas la prise de tête...