Discussion :

[A.i.A]

Vous êtes vraiment gentil


Je voulais demander autre chose si vous permettez :

L'attribut "Date" doit être unique oui, mais pourquoi clé primaire ?
On m'a dit que ce n'est pas une forme normalisé de mettre une clé primaire d'une association porteuse. (MCD)
- Quel est l'intérêt ?

- Et en fait on peut avoir 2 conversations en même jour, donc on doit ajouter l'heure aussi pour distinguer, on le met associé à la "date_appel" ?


Merci de toute votre aide, voila je l'ai coché "Résolu"

[CinePhil]

L'attribut "Date" doit être unique oui, mais pourquoi clé primaire ?

Je suppose que tu parles de la date dans l'association Appelle ?

La date doit faire partie de la clé primaire de la table associative pour autoriser plusieurs appels entre deux mêmes utilisateurs. Elle ne doit pas être unique toute seule sinon cela voudrait dire qu'il ne peut y avoir qu'un seul appel par date !

Schéma général :
Utilisateur -0,n----Appeler----0,n- Utilisateur

Théoriquement, ça donne les tables suivantes :
Utilisateur (usr_id...)
Appeler (apl_id_appelant, apl_id_appele...)
Il ne donc y avoir qu'une seule fois le couple {1, 2} par exemple.
Tu ne peux donc appeler qu'une seule fois la jolie assistante de direction (ou le bel ingénieur) qu'une seule fois. Choisis bien tes mots !

On m'a dit que ce n'est pas une forme normalisé de mettre une clé primaire d'une association porteuse. (MCD)
- Quel est l'intérêt ?

Pour ajouter la date en clé primaire, afin d'autoriser plusieurs couples d'utilisateurs identiques mais à des moments différents, certains modélisent de cette façon :
Utilisateur -0,n----Appeler----0,n- Utilisateur
Date -0,n----------------|

Je ne modélise ainsi que si je crées réellement un calendrier qui me permettra par exemple de savoir combien d'appels ont été échangés pour chaque jour du mois dernier, même si certains jours il n'y a pas eu d'appel.

Je préfère donc ajouter l'attribut apl_date dans l'association et la marquer comme faisant partie de la clé primaire.
En modélisation textuelle comme je la pratique ici, ça peut se représenter ainsi :
Utilisateur -0,n----Appeler(Date)----0,n- Utilisateur

Ce qui donnera les tables suivantes :
Utilisateur (usr_id...)
Appeler (apl_id_appelant, apl_id_appele, apl_date...)

- Et en fait on peut avoir 2 conversations en même jour, donc on doit ajouter l'heure aussi pour distinguer, on le met associé à la "date_appel" ?

Cet attribut devrait être de type DATETIME.

[A.i.A]

Bonjour,

Ce qui donnera les tables suivantes :
Utilisateur (usr_id...)
Appeler (apl_id_appelant, apl_id_appele, apl_date...)

Oui, c'est ce que j'ai fait en haut, de mettre date_appel comme clé primaire sur le MCD, qui se transforme en clé primaire composé qui rassemble appel_date + les autres clés étrangères qui migrent.

(Notre prof avait dis que le fait de mettre une clé primaire d'une association porteuse dans le MCD n'est pas normalisé mais rien n'empêche de le faire.)

Pour ajouter la date en clé primaire, afin d'autoriser plusieurs couples d'utilisateurs identiques mais à des moments différents, certains modélisent de cette façon :
Utilisateur -0,n----Appeler----0,n- Utilisateur
Date -0,n----------------|

Je ne modélise ainsi que si je crées réellement un calendrier qui me permettra par exemple de savoir combien d'appels ont été échangés pour chaque jour du mois dernier, même si certains jours il n'y a pas eu d'appel

Donc on n'ajoute une autre entité date, que lorsqu'on s'intéresse au stockage d'historique.

Merci pour toutes vos explications.

[CinePhil]

Donc on n'ajoute une autre entité date, que lorsqu'on s'intéresse au stockage d'historique.

Pas forcément pour du stockage d'historique, au sens archivage de données anciennes. Ça n'a même rien à voir a priori !

Restons sur le cas de tes appels...

Soit les données suivantes présentes dans la table.
Appeler (apl_id_appelant, apl_id_appele, apl_date...)
1, 2, '2010-01-02 11:05:12'
1, 5, '2010-01-03 09:18:24'
2, 12, '2010-01-05 15:14:12'
...

Le mois prochain, ton chef te demande le nombre d'appels par jour au mois de janvier.
Tu fais la requête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT apl_date, COUNT(*) AS nombre
FROM Appeler
WHERE apl_date BETWEEN '2010-01-01' AND '2010-01-31'
GROUP BY apl_date
ORDER BY apl_date

Et ton chef revient te voir en te disant qu'il manque le 4 janvier dans le résultat que tu lui as donné !

Si tu as une table des dates, tu peux avoir la totalité des jours d'une période et faire une jointure externe gauche à partir de celle-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT c.cal_date, COUNT(a.apl_date) AS nombre
FROM Calendrier c
LEFT OUTER JOIN Appeler a ON a.apl_date = c.cal_date
WHERE c.cal_date BETWEEN '2010-01-01' AND '2010-01-31'
GROUP BY c.cal_date
ORDER BY c.cal_date

J'ai fait ça un peu vite pour montrer le principe mais pour la condition de jointure il faudra peut-être transtyper apl_date de datetime en date.

En résumé, si tu as besoin de faire des plannings, des statistiques sur tous les intervalles d'une période temporelle... bref, de gérer un calendrier, il faut le modéliser en l'implémenter en BDD. Si par contre les colonnes de dates ne sont que de pures informations de dates sans besoin de continuité temporelle dans leur exploitation, tu n'as pas besoin de l'entité Date dans ton MCD. En tout cas, je trouve ça plus clair comme ça.