Discussion :

[accessisgood]

Bonjour,

pas de probleme, c'est la partie la plus complexe et je ne suis pas sur qu'elle soit definitive, mais voici l'idee:

le processus se fait en 3 parties:
- a la creation d'un spectacle, on cree autant de T_Place qu'il y a de sieges pour les categories selectionnees du spectacle
- a la reservation, on genere un T_Billet en fonction des categories de sieges disponibles pour le spectacle requis
- il faut ensuite "matcher" un billet avec une place, ce qui se fait manuellement en fonction du spectacle et de la categorie de chacun: on peut faire ce "match" soit par une liste correctement flitree, soit par une interface "user friendly" qui affiche un plan et des couleurs en fonction des places disponibles.
- Une fois que la place est selectionnee, alors, automatiquement, le "Billet consomme une Place", c'est a dire que le systeme indique dans la table des billets la place disponible qui a ete selectionnee (ce qui rend le billet OK pour impression) et juste apres on indique le ID du billet dans la place qui vient d'etre selectionnee (ce qui rend la place indisponible pour les futures reservations, et met a jour le total des places disponibles pour le spectacle et pour la categorie)

Ainsi il y a cette double liaison entre T_Billet et T_Place qui sont des relations 1-> 0 ou 1
T_Billet 1-> 0 ou 1 T_Place
T_Place 1-> 0 ou 1 T_Billet


En tous cas on ne peut pas utiliser l'integrite referentielle classique dans ce cas

[fab.85]

Bonjour,

- a la creation d'un spectacle, on cree autant de T_Place qu'il y a de sieges pour les categories selectionnees du spectacle

A faire manuellement, sauf pour ID_Billet je suppose..

- a la reservation, on genere un T_Billet en fonction des categories de sieges disponibles pour le spectacle requis

Ici je pense que c'est OK pour moi, formulaire réservation déjà créé...

- il faut ensuite "matcher" un billet avec une place, ce qui se fait manuellement en fonction du spectacle et de la categorie de chacun: on peut faire ce "match" soit par une liste correctement flitree, soit par une interface "user friendly" qui affiche un plan et des couleurs en fonction des places disponibles.

Là je ne vois pas encore comment même si j'avais au départ l'idée du schéma qui me semble aussi plus convivial. Je comptais voir du coté IHM concernant la réalisation d'un tel formulaire car 700 places = 700 boutons = 700 événements


Sur le dernier schéma proposé j'ai (peut-être un problème de vu) l'impression qu'entre T_Billet et T_Place c'est ID_Reservation qui est en liaison avec ID_Billet? Est-ce possible? Mes petites connaissances s’arrêtent aux liaisons de champs identiques.

Cordialement,

Fabien.

[accessisgood]

Bonjour,

l'integrite referentielle n'est pas stricte au sens technique du terme

T_Billet.ID_Billet 1→ 0 ou 1 T_Place.ID_Billet (on peut creer un billet sans avoir sa place)
T_Place.ID_Place 1→ 0 ou 1 T_Billet.ID_Place (on peut crer une place sans l'affecter a un billet)


mais elle est stricte voire doublement stricte au sens fonctionnel du terme (la relations est generee durant les transactions utilisateur) car au final

si
T_Billet.ID_Billet =T_Place.ID_Billet
alors
T_Place.ID_Place =T_Billet.ID_Place

[fab.85]

Merci!