modélisation évènements récurrents

Bonjour,

J'ai actuellement une base avec une gestion des évènements dans la table events. Des personnes peuvent s'inscrire à un ou plusieurs évènements. La relation étant n-n, ces inscriptions sont stockées dans une table enrolments.

Je travaille sur la mise en place de la récurrence d'évènements.

Pour ce faire je vais créer une table Series avec les colonnes adéquates (je peux les données pour la postérité) tandis que les exceptions seront reprises dans la table events. Au final j'ai ma table events qui contient deux nouvelles colonnes SerieID et OccurenceID pour me permettre de gérer les exceptions. Cela donne :

Events :

• EventID : PK
• SerieID : identifiant de la série d'évènements
• OccurenceID : identifiant de l'occurence de la série surchargée

Series:

• SerieID : PK

Enrolments

• UserID : identifiant de l'inscrit
• EventID : identifiant de l'évènement

Jusque là tous va bien sauf que... je dois adapter mes inscriptions pour gérer le cas des inscriptions à toute une série, une inscription à une exception, une désinscription à une occurence de la série.

1ère possibilité très simple : J'ajoute la notion SerieID et OccurenceID dans la table enrolment. Je démultiplie donc l'alimentation de cette table. C'est transparent pour l'utilisateur car chaque action sera traduite par un ou plusieurs accès à cette table.

2ème possibilité : je sèche :(

Avez-vous un retour d'expérience ? ou un conseil ?

Merci

2ème possibilité un peu plus réfléchie : J'ajoute la notion SerieID et OccurenceID et un flag désinscription dans la table enrolment.

Cela me permet d'afficher les inscriptions - les désinscriptions spécifiques.

Je continue à creuser mais si qqun à une meilleure idée je sus preneur.

Bonjour Emmanuel,

Pour récapituler, dans un premier temps, tu as bien :

Code:

---

Serie -0,n---[Composer]---0,n- Event

---

==> non ?

Ensuite, si j'ai bien compris, ton souci provient du fait qu'un utilisateur peut s'inscrire à une série (d’évènements), mais, parfois, en excluant certains évènements de cette série (ou même, peut-être, en incluant certains évènements qui n'appartiennent pas à cette série). C'est bien cela ?

Bonjour Richard,

Hier j'avais uniquement cela :

Une inscription se fait pour un évènement

Code:

---

Events -0,n---[Enrollments]---0,n- Utilisateur

---

Cela a donc donner lieu à la création de la table Enrollements (UserID, EventID)

Aujourd'hui j'ai ajouté ces notions :

Une série est une récurrence d'évènements :

Code:

---

Series -1,1---[Récurrent]---0,1- Events

---

Au final la série va m'afficher plusieurs évènements mais avant tout c'est une généralisation (terme pas trop approprié vu la signification que cela peut avoir) d'un évènement. Un évènement peut être récurrent ou non, la série porte sur un et un seul évènement.

Une Occurence est une exception dans la série (modification de l'évènement ou suppression de l'évènement) à telle date.

Code:

---

Series -0,n---[Contient]---1,1- Occurences

---

Ma problématique :

Un utilisateur peut s'inscrire ou se désinscrire :

• à toute une série => çà c'est OK, c'est une "Serie"
• à une exception dans la série => çà c'est OK, c'est une "Occurence"
• à une partie de la série
• à un évènement non récurrent => çà c'est OK, c'est un "event"

C'est mieux en explication ? :)

Bonjour Emmanuel,

Beaucoup plus clair, en effet : je pensais que les "Series" étaient un ensemble d'"Events" différents. Ce que tu appelles "Series" est donc, si j'ai bien compris, un ensemble de dates pour un même évènement. Dès lors, toujours si j'ai bien compris, je ne comprends pas pourquoi tu passes par une entité "Serie".

Tu aurais donc :

Code:

---

1 2 3

Event -0,n---[Avoir lieu]---(1,1)- Occurence | User --0,n---[Inscrire]-----0,n-------

---

ce qui donnerait :

Event(IDEvent, ...)
Occurence(#IDEvent, DateEvent, Lieu, ...)
User(IDUser, ...)
Inscription(IDUser, #IDEvent, #DateEvent, DateInscription, ...)

L'"Event" étant retrouvé via IDEvent de "Occurence".
Non ?

NB : il est d'usage de nommer les entités au singulier (nous nous doutons que les tables contiendront plusieurs enregistrements, en final).

Bon je vais devoir te donner le contenu de Serie :ccool:

En fait Serie est ce qui permet de déterminer la récurrence de mon évènement : toutes les semaines, tous les 14 de chaque mois, tous les 10 jours...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

SerieID Primary Number EventID Unique Number StartDate DateTime EndDate DateTime RepeatInstances Number PeriodType Number Frequency Number Mo Boolean Tu Boolean We Boolean Th Boolean Fr Boolean Sa Boolean Su Boolean day Number month Number weekdayOfMonth Number

---

Avec mon modèle, je n'ai donc pas de stockage de toutes les occurences de la serie en base, uniquement la date de début et les données me permettant de calculer toutes les dates d'occurence de cette serie.

Donc hormis pour les occurences annulées ou modifiées que nous allons retrouver dans une entité Occurence, les occurences standard n'ont pas d'existences physiques... d'où la problématique soulevée avec une inscription à une partie de la série (donc sur des Occurences qui n'existe pas en tant que tel).

Ta proposition convient mais le nombre de lignes risque de devenir très conséquent dans la table occurence ainsi que dans la table inscriptions. Pour être franc avec toi, j'avais pensé à cette modélisation qui est simple mais je tiquais sur cette volumétrie.

Maintenant si je ne trouve pas d'alternative je finirai par revenir à ce scénario nickel en terme de base de données.

:merci: pour ton aide et tes conseils

On avance... :ccool: : Serie est donc une propriété (existante ou pas) d'un Event.

Suggestion :

Code:

---

1 2 3 4 5

User -0,n---[Inscrire]---0,n- Event -0,1---[Plannifier]---(1,1)- Serie | 0,n | ---[Exclure]---(1,1)- UserEvenExclusion

---

donnant :

User(IDUser, ...)
Event(IDEvent, Nom, Lieu, ...)
Serie(#IDEvent, ... [planification])
Inscription(#IDInscription, #IDEvent, #IDUser, DateInscription, ...) ==> index unique sur {#IDEvent, #IDUser}
UserEvenExclusion(#IDInscription, Date, Motif, ...) ==> si nous voulons aller jusqu'au bout : trigger vérifiant que la date exclue fait bien partie de la planification

C'est toujours plus simple avec deux cerveaux 8-)

Si cela te convient, n'oublies pas le bouton :resolu:.

Bon il me reste des trous dans la raquette :
- Avec le modèle présenté, on ne gère pas les exceptions d'évènement : l'entité Occurrence (nommée SerieEventExclusion dans le modèle). Encore çà, çà va il suffit de l'ajouter.

- Comment peut-on modéliser la gestion des inscriptions à une occurrence. Le modèle ci dessous est OK ?

Code:

---

1 2 3 4 5 6 7 8 9 10

------------0,n- SerieEventExclusion -0,1---[surcharge] | | | 0,n | | User -0,n---[Inscrire]---0,n- Event -0,1---[Planifier]---(1,1)- Serie | 0,n | ---[Exclure]---(1,1)- UserEventExclusion

---

Bonjour Emmanuel,

Hum... il me semble comprendre que tu as besoin d'un calendrier par évènement... mais que tu souhaites t'en passer. Et pour cela, tu souhaites le recalculer à chaque besoin. Cela me semble être une galère... et que dire si une Serie change alors qu'elle contient des inscriptions (une Serie qui passe de "tous les 2ème mardis du mois" à "tous les 2ème mercredis du mois")...

En bref, tu comptes tout résoudre par du code : c'est faisable, mais galère...

Juste pour comprendre, en règle générale :

• un User s'inscrit à un Event pour toute la Serie ==> par exemple UserX s'inscrit à EventY pour tous les 2ème mardis du mois, sauf celui de mai 2012 ;

OU

• un User s'inscrit à un Event pour un élément de la Serie ==> par exemple UserX s'inscrit à EventY ce mardi (qui est un 2ème mardi du mois) ?

Citation:

---

Envoyé par Richard_35

Bonjour Emmanuel,

Hum... il me semble comprendre que tu as besoin d'un calendrier par évènement... mais que tu souhaites t'en passer. Et pour cela, tu souhaites le recalculer à chaque besoin. Cela me semble être une galère... et que dire si une Serie change alors qu'elle contient des inscriptions (une Serie qui passe de "tous les 2ème mardis du mois" à "tous les 2ème mercredis du mois")...

---

Et oui c'est la que le bas blesse :(

Citation:

---

En bref, tu comptes tout résoudre par du code : c'est faisable, mais galère...

---

Pas nécessairement mais c'est vrai que je vais devoir gérer par le code les 8 cas possibles d'inscriptions / desinscriptions

Citation:

---

Juste pour comprendre, en règle générale :

• un User s'inscrit à un Event pour toute la Serie ==> par exemple UserX s'inscrit à EventY pour tous les 2ème mardis du mois, sauf celui de mai 2012 ;

OU

• un User s'inscrit à un Event pour un élément de la Serie ==> par exemple UserX s'inscrit à EventY ce mardi (qui est un 2ème mardi du mois) ?

---

Ben en fait les deux :(. Certains vont s'inscrire à toute la série et d'autres uniquement à tel ou tel occurence.

Donc le modèle que tu présentes avec mon ajout de table est bon. Pour une inscription à une serie, on va créer en base autant d'inscription que d'occurence de la série, en cas d'annulation d'une occurence de la série on peut supprimer ses inscriptions... Seul bémol la volumétrie dans la table enrolments mais çà je pense qu'une base de données c'est fait pour çà non :roll:

Bonjour Emmanuel,

Citation:

---

Envoyé par Emmanuel

.../... je pense qu'une base de données c'est fait pour çà non ?

---

==> exact.

C'est pour cette raison que je ne vois pas pourquoi, compte tenu de toutes les précisions que as apportées, tu ne passes pas par un calendrier classique.

En effet, la structure de ta table Serie est, en fait, la liste des champs d'un formulaire de saisie :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

StartDate DateTime EndDate DateTime RepeatInstances Number PeriodType Number Frequency Number Mo Boolean Tu Boolean We Boolean Th Boolean Fr Boolean Sa Boolean Su Boolean day Number month Number weekdayOfMonth Number

---

qui, après traitement, générerait ce calendrier (tout à fait classique). Cela donnerait, en final :

User(IDUser, ...)
Event(IDEvent, Nom, Lieu (?), ...)
Calendar(#IDEvent, DateEvent, Animateur (?), ...)
Inscription(#IDInscription, #IDUser, #IDEvent, #DateEvent, DateInscription, ...) ==> index unique sur {#IDUser, #IDEvent, #DateEvent}
ou
Inscription(#IDUser, #IDEvent, #DateEvent, DateInscription, ...)

Merci pour ton aide, je vais voir comment intégrer ta proposition dans mon existant :)

A demain

Et bon Dimanche !

J'ajoute que pour obtenir une simple liste des inscriptions d'un User à un Event, avec les dates précises, tu seras obligé de passer par une fonction de calcul de ces dates précises via Serie pour chaque couple User/Event... pas simple... et, sans doute, long...

Alors que la génération d'un calendrier à la validation d'un couple User/Event, via le formulaire de saisie (Serie) implique un seul traitement pour ce couple.

Ci-dessous mon idée de modèle pour prendre en compte la possibilité de surcharger une occurence de ma série.

Code:

---

1 2 3 4 5 6

------ ------------ -0,1---[surcharge] | | | 0,n | | User -0,n---[Inscrire]---0,n- Event -0,1---[Planifier]---(1,1)- Serie

---

User(IDUser, ...)
Event(IDEvent, Nom, Date, ...)
Serie(IDSerie, IDEvent, ...) => volonté de ma part d'isoler les données complémentaire de récurrence.
Inscription(#IDInscription, #IDUser, #IDEvent, DateInscription, ...) ==> index unique sur {#IDUser, #IDEvent}

Comme mes surcharges éventuelles d'évènement se font dans la table Event, une inscription ne se fait que sur un évènement. Avec la rélation surchage qui contient la donnée N°Occurence, j'obtiens la table

Event(IDEvent, Nom, Date, ..., IDSerie, numoccurence)

Donc au final pour la prise en compte de la récurrence : création de la table Serie et ajout de deux colonnes dans la table existante Event. Puis adaptations des traitements.

Avec mes cas d'utilisation j'ai :

Un gestionnaire crée un évènement :

• une série => création d'un enregistrement dans Event pour l'évènement maître (colonnes IDSerie, numoccurence vides), création d'un enregistrement dans Serie pour les données de récurrence. création de N enregistrements dans la table Event - autant d'enreg que d'occurrences dans la série - (colonnes IDSerie, numoccurence alimentées)
• une exception dans la série => simple édition de l'évènement
• un évènement non récurrent => création de l'évènement dans Event

Un gestionnaire modifie un évènement :

• une série => on garde la série mais on supprime les futures occurrences (à partir d'une date pivot). traitement adapté pour les inscriptions éventuelles.
• une exception dans la série => simple édition de l'évènement. traitement adapté pour les inscriptions éventuelles.
• un évènement non récurrent => modification de l'évènement dans Event. traitement adapté pour les inscriptions éventuelles.

Un utilisateur peut s'inscrire ou se désinscrire :

• à toute une série => On détecte que l'évènement est un evt récurrent, on propose à l'utilisateur de s'inscrire pour tous les evt de la Serie (IDSerie)
• à une exception dans la série => inscription sur un évènement
• à une partie de la série => inscription à chacun des évènements
• à un évènement non récurrent => inscription sur un évènement

Grand merci pour ton aide