Dates
ahlem_o
Messages postés
15
Date d'inscription
mercredi 13 juin 2007
Statut
Membre
Dernière intervention
14 juillet 2008
-
27 juin 2007 à 00:45
rethenor Messages postés 48 Date d'inscription mercredi 11 juillet 2007 Statut Membre Dernière intervention 9 mai 2011 - 26 juil. 2007 à 11:14
rethenor Messages postés 48 Date d'inscription mercredi 11 juillet 2007 Statut Membre Dernière intervention 9 mai 2011 - 26 juil. 2007 à 11:14
3 réponses
coucou747
Messages postés
12303
Date d'inscription
mardi 10 février 2004
Statut
Membre
Dernière intervention
30 juillet 2012
44
3 juil. 2007 à 07:15
3 juil. 2007 à 07:15
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, ...
<hr />une recherche sur exalead vous aurait peut-etre evite de poser cette question
In a dream, I saw me, drop dead...
U were there, U cried...
It was just a dream,
if I die, U won't cry, maybe, U'll be happy
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, ...
<hr />une recherche sur exalead vous aurait peut-etre evite de poser cette question
In a dream, I saw me, drop dead...
U were there, U cried...
It was just a dream,
if I die, U won't cry, maybe, U'll be happy
rethenor
Messages postés
48
Date d'inscription
mercredi 11 juillet 2007
Statut
Membre
Dernière intervention
9 mai 2011
26 juil. 2007 à 00:23
26 juil. 2007 à 00:23
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)
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)
rethenor
Messages postés
48
Date d'inscription
mercredi 11 juillet 2007
Statut
Membre
Dernière intervention
9 mai 2011
26 juil. 2007 à 11:14
26 juil. 2007 à 11:14
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...
+-----------+ 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...
