Discussion :

[rallus]

Bonjour à toutes et à tous,

Malgré mes quelques recherches à travers les tutoriels et forums, je n'ai pas pu trouver mon bonheur (ou je suis tout simplement passé à coté en pensant que le sujet été trop éloigné de ce que je recherche et par conséquent si quelqu'un trouve un lien ou un topic qui m'aurais échappé, je suis preneur).
De manière générale, la modélisation ne me pose pas de soucis particulier, mais j'admets qu'une partie d'un projet me donne du fil à retordre.

Je souhaiterais que les membres d'un site puissent être notifiés par mail lorsqu'un nouveau événement, correspondant à leurs critéres, soit ajouté au site.
Dans ce cas précis, le site fait référence à des événements de boîte de nuit, et les critères cités précédement sont au nombre de 3: La localisation de l'événement, le type de musique, et le théme de la soirée.
Par exemple, toto veut être notifié lorsqu'une boîte de nuit dans sa région (critére 1), va passer de la dance ou de l'electro (critére 2), avec une soirée mousse (critére 3) vient d'être ajouté au site (j'invente hein ).

Bref, j'ai donc à la base 4 entités avec id* comme PK:
- Membre (idMembre, login, ...)
- Localisation (idLocalisation, region, ...)
- TypeMusique (idTypeMusique, nomMusique, ...)
- ThemeSoiree (idThemeSoiree, nomTheme, ...)

Et ma question est donc la suivante:
Comment modéliser l'entité "AlerteMail" qui permet de stocker les critéres d'un membre de manière efficace?

Ma première idée consiste à créer l'entité "AlerteMail" avec uniquement une clé primaire idAlerteMail.
Ensuite de relier l'entité "AlerteMail" avec l'entité Membre (1..* donc la cardinalité 1 prés de l'entité "AlerteMail" et la cradinalité * prés de l'entité Membre), Localisation (*..*), TypeMusique(*..*) et ThemeSoiree(*..*).
Mais je crains qu'avec une telle modélisation, cela fasse des jointures inutiles par la suite ou une perte de performance non négligeable.

Qu'en pensez-vous?

[CinePhil]

toto veut être notifié lorsqu'une boîte de nuit dans sa région

Il te faut donc une association entre le membre et la région et entre la boîte de nuit et la région.
MCD :
Membre -1,1----localiser----0,n- Region -0,n----situer----1,1- BoiteNuit

E/R :
Membre >o--------------------------| Region |----------------------------o< BoiteNuit

Tables :
Region (rgn_id, rgn_nom)
Membre (mbr_id, mbr_id_region, mbr_login...)
BoiteNuit (btn_id, btn_id_region, btn_nom...)

va passer de la dance ou de l'electro

Il te faut une association entre la boite et le type de musique.

MCD :
BoiteNuit -0,n----passer----0,n- TypeMusique

E/R :
BoiteNuit |------o< BoiteNuit_TypeMusique >o-----| TypeMusique

Tables :
TypeMusique (tmq_id, tmq_libelle)
BoiteNuit_TypeMusique (btm_id_boite, btm_id_type_musique)

avec une soirée mousse

Ici je m'interroge sur la simultanéité du type de musique et de la soirée mousse. Dois-tu avertir le membre s'il y a une boîte de sa région qui programme une soirée mousse au cours de laquelle il y aura de la dance ou de l'électro ? Ou bien dois-tu avertir le membre s'il y a une boîte de sa région qui programme habituellement de la dance et de l'électro et qui a programmé une soirée mousse ?

Dans les deux cas, il te faudra une association entre la boîte de nuit et le type de soirée, avec probablement la date de la soirée.
MCD :
BoiteNuit 0,n----programmer----0,n- TypeSoiree
[Date] -0,n-----------------|

Date est ici une entité fictive qui ne sera implémentée que si tu as besoin de gérer un calendrier. Ici, cela détermine seulement que la date participe à l'identification de l'association.

E/R :
BoiteNuit |--------o< Programmation >o------| TypeSoiree

TypeSoiree (tsr_id, tsr_libelle)
Programmation (prg_id_boite, trg_id_type_soiree, trg_date)

La date se retrouve dans la clé primaire de Programmation car une boîte de nuit peut évidemment programmer plusieurs fois le même type de soirée mais à des dates différentes.

Et pour enregistrer les critères de choix du membre, il te faut aussi des association entre le membre et le type de musique d'une part, entre le membre et le type de soirée d'autre part.

MCD :
Membre -0,n----Preferer----0,n- TypeMusique
|-------------0,n----Souhaiter----0,n- TypeSoiree

E/R :
Membre |----o< PreferenceMusicale >o----| TypeMusique
|-----------------o< SouhaitSoiree >o------| TypeSoiree

Tables :
PreferenceMusicale (pms_id_membre, pms_id_type_musique)
SouhaitSoiree (ssr_id_membre, ssr_id_type_soiree)

Comment modéliser l'entité "AlerteMail"

En as-tu réellement besoin ?
Il s'agit plus d'un processus - le fait d'avertir par mail les membres concernés lors de l'enregistrement d'une soirée pour une boîte de nuit.

Si tu veux mémoriser le fait que ce processus a eu lieu, tu peux créer l'association suivante :
E/R :
Membre |----o< Alerte >o----| Programmation

Je suis passé directement au schéma E/R car Programmation est une table associative et il aurait fallu modifier le MCD précédent en transformant l'association programmer en entité type associative Programmation pour pouvoir pointer une association dessus.

Tables :
Alerte (alr_id_membre, alr_prg_id_boite, alr_prg_id_type_soiree, alr_prg_date)

[rallus]

Tout d'abord merci beaucoup pour cette aide pour le moins rapide!

Il te faut donc une association entre le membre et la région et entre la boîte de nuit et la région.

Il te faut une association entre la boite et le type de musique.

il te faudra une association entre la boîte de nuit et le type de soirée

Bien compris mon capitaine!

Dois-tu avertir le membre s'il y a une boîte de sa région qui programme une soirée mousse au cours de laquelle il y aura de la dance ou de l'électro ? Ou bien dois-tu avertir le membre s'il y a une boîte de sa région qui programme habituellement de la dance et de l'électro et qui a programmé une soirée mousse ?

Je ne m'étais pas vraiment aperçu d'une éventuelle diffèrence d'interprétation. Le deuxième cas semble plus approprié.

Et pour enregistrer les critères de choix du membre, il te faut aussi des association entre le membre et le type de musique d'une part, entre le membre et le type de soirée d'autre part.

C'était surtout cette partie qui me semblait plus délicate car en plus des 3 entités citées (Membre, Type de musique et Type de soirée) je rajouterais une association entre membre et région pour stocker la préférence du membre concernant la ou les régions de son choix.

Comment modéliser l'entité "AlerteMail"

En as-tu réellement besoin ?
Il s'agit plus d'un processus - le fait d'avertir par mail les membres concernés lors de l'enregistrement d'une soirée pour une boîte de nuit.

Entiérement d'accord! Ce que j'avais besoin été de stocker les préférences d'un membre et je suis parti du mauvais pied en voulant tout stocker dans une seule entité ("alerteMail" pouvant être renommé en "preferenceMembre" pour une meilleure compréhension) qui resultait d'une association entre 4 entités (Membre, type de Musique, type de Soirée, Région), alors qu'il est plus simple de bien séparer les informations dans des tables diffèrentes (résultant d'associations diffèrentes dans le modéle E/A)!

Dans tous les cas, j'y vois déjà beaucoup plus clair et je marque donc un grand "Résolu" et je remercie sincérement CinePhil pour sa réponse à la fois pertinente et juste