Discussion :

[pit9.76]

sachant que l'entité "date" du MCD ne devient pas une table , que devient elle dans la base de donnée , comment la modeliser pour pouvoir l'utiliser ?

[Fabien Celaia]

Toute entite cree en MCD devient une table en MPD. Maintenant, votre SGBDR peut considerer DATE comme un mot reserve et empecher sa creation. Avec quel outil de modelisation travaillez-vous ? Sur quel SGBDR voulez-vous generer votre script ?
En tout etat de cause, je redirige votre requete sur le forum Modelisation.

[pit9.76]

notre prof nous a di que l'entité date ne devenait pas une table,
comme par exemple une association ayant une cardinalité maximale = à 1 ne devient pas une table mais il ya juste migration de son identifiant .

je voulais savoir que devenait l'entité date ?

[baboune]

si je comprends bien ton probleme ton entité date est en faite ce que l'on appelle une table parametre. elle est composé seulement de la date.

MCD
ces tables apparraissent seulement dans les relations par exemple :

tu as :
tbl_matériel (code_mat, lib_mat)
tbl_client(code_cli, nom_cli)
date (ta table parametre)

et tout ca attaché par une association par exemple assoc_achat

MLD
tbl_matériel (code_mat, lib_mat)
tbl_client(code_cli, nom_cli)
assoc_achat(date, code_cli, code_mat)

la table parametre "date" ne figure plus sur le MLD enfin tu peux la laisser mais ca ne sert à rien.

en espérant que j'ai répondu a ta question

[Nanci]

C'est la problématique de la modélisation du temps, maintes fois développé dans la littérature, en particulier dans un bouquin bien connu

Je résumes...
1/ au niveau MCD
1.1/ Date modélisé comme une simple propriété
C'est le plus fréquent; la date est une simple information de positionnement dans le temps d'un événement.
Ex: date de commande, date de naissance, date de signature, etc...

1.2/ Date modélisée par une entité
N'est nécessaire que pour le suivi de phénomènes au cours du temps. le temps devient alors une "dimension"
Ex: suivi de production, suivi de temps de travail, planning...
Dans la pratique, il vaut mieux nommer l'entité par la fraction de temps gérée; l'identification dépendant de cet intervalle de temps; la date identifiant une journée.
Ex: Jour, Semaine, Module horaire (cas des emplois du temps scolaire)

Lorsque l'on doit modéliser explicitement le temps, alors il n'intervient que dans des relations n-n ou n-aires. Une entité Date impliquée dans une relation binaire 0n-11 est plus que suspect !

2/ Transformation en MLD
Sans commentaire lorsque la Date est une propriété....

Les entités temporelles (Jour, Semaine, Mois, ...) deviennent normalement des tables !
Remarque: je ne comprends bien la remarque

notre prof nous a di que l'entité date ne devenait pas une table,

Ou plutôt c'est un "raccourci".

En effet, ces tables temporelles ne contiennent généralement que l'identifiant (Jour identifié par Date) et suite à la transformation ont généré des clés étrangères dans les tables associées.
Cette "migration" effectuée, on peut alors se poser la question de l'intérêt de conserver une telle table. Sa suppression relève alors de l'optimisation (pas de contenu autre que la clé, pas de nécessité de contrainte référentielle).
Voilà pourquoi, une table Jour (Date) est assez fréquemment supprimée.

Mais, si la table "temporelle" contenait des attributs spécifiques
Ex Nombre d'heures disponibles dans la Semaine, Journée ouvrable, ..
alors cette optimisation serait pour le moins innoportune !

PS: Désolé de rappeler encore que les MCD ne contiennent pas de tables !

[startout]

Une table "DATE" n'est utilise que si on souhaite historisé.
Sinon les dates ne sont que des attributs... en tout cas, c'est comme ça que je fais tout le temps

[Nanci]

Attention, le mécanisme d'historisation et le fait d'utiliser une entité (et non une table...!) Date relèvent de principes différents.
L'historisation indique que l'on souhaite, pour une occurence d'une entité, conserver les valeurs antérieures prises par certaines propriétés. La date est alors celle du changement de valeur
Ex: on peut historiser l'adresse d'une Personne. On a alors l'adresse courante, et les adresses antérieures avec les dates de changement.

L'entité Date s'utilise dans le cas de suivi de phénomène ou d'activité. Le temps est alors une dimension à part entière, et les valeurs du temps sont généralement régulières (les jours, les semaines, les mois,...). En reliant une entité à une entité "temporelle" (jour, semaine, ...), on réalise un suivi chronologique d'une propriété initialement rattachée à l'entité "non temporelle".
Ex: si la Personne veut suivre quotidiennement son poids, on modélisera
Personne --1,n --(suivi)--0,n--Jour
avec poids comme propriété de (suivi)

Par contre, au niveau du MLD relationnel, on aboutira dans les deux cas à une table Date mais dont l'origine sémantique est nettement diférente.

Si on veut faire du MCD, alors il faut l'utiliser correctement et non comme un substitut du MLD; il vaut mieux alors s'exprimer directement en relationnel.

[pit9.76]

merci baboune c'est exactement ca !