Discussion :

[equinox08]

bonjour a tous,
Je souhaiterai créer une base de données répondant a ceci:

Gérer une société de la loisir, vous devez donc être capable de répertorier les participants aux différentes activités que votre société propose. Certaines personnes sont inscrites comme clients VIP et on accès a des sortie que les autres ne peuvent pas faire.
Les sorties proposée s doivent pouvoir être distinguée par catégorie de loisir (sport, cinéma, et..) et vous devez pouvoir a tout moment savoir qui participe a quelle sortie.
Ces animation sont toujours encadrées par AU MOINS un membre de votre association.

Etant novice en la matière, j'aimerai avoir vos conseil et vos lumières afin que ma BDD est (la meilleur) structure possible .

Je pensait faire une table Activités, une table Catégorie, une table Client, une table Encadrant et une table Privilège
(voir pièce jointe)
http://hpics.li/574db09

merci d'avance

[bretus]

Bonjour,

Au lieu de deux tables "encadrant"/"client", je ferais plutôt une table "personne" (ou "utilisateur" s'ils peuvent se connecter à l'outil) avec un attribut "type" (énuméré à valeur dans 'encadrant' et 'client').

Pourquoi? C'est plus simple d'ajouter un nouveau type de personne par la suite que si tu manipules plusieurs tables.

[equinox08]

merci de a réponse,

concernant le privilège ?
dois je mettre un attribut privilège dans la table personne ?

J'aimerai plus de précision, et savoir comment cela va être traduit : Ces animation sont toujours encadrées par AU MOINS un membre de votre association.
merci

edit :
est-ce envisageable de créer une autre table "type_personne" (dont il n'y aurait que 3 possibilité : encadrant, client et client VIP) ?

[bretus]

concernant le privilège ?
dois je mettre un attribut privilège dans la table personne ?

C'est plus simple à mon goût oui (voir la notion d’énuméré en UML).

J'aimerai plus de précision, et savoir comment cela va être traduit : Ces animation sont toujours encadrées par AU MOINS un membre de votre association.

C'est une contrainte de cardinalité sur le lien.

Code :

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

1
2
 
Animation[*] -- encadrants[1..*] Personne

[fsmrel]

Bonsoir,


Vous pouvez vous inspirer tout ou partie du diagramme ci-dessous, dans lequel les concepts sont « dépliés » (détaillés) :




La table CLIENT représente les personnes clientes.


La table CLIENT_VIP représente les VIP : elle est une spécialisation de la table CLIENT (voyez l’article MySQL Workbench qui traite de ce sujet). Notez les cardinalités de l’association :

Un client peut être un client VIP et un client VIP est exactement un client.

De même :

Un client peut être un client non VIP et un client non VIP est exactement un client.

Table ACTIVITE_CLIENT_VIP :

Un client VIP peut participer à plusieurs activités quelles qu’elles soient et à une activité quelle qu’elle soit peuvent participer plusieurs clients VIP.


Table ACTIVITE_NON_VIP :

Une activité peut être une activité non VIP et une activité non VIP est exactement une activité.


Table ACTIVITE_CLIENT_NON_VIP :

Un client non VIP peut participer à plusieurs activités non VIP et à une activité non VIP peuvent participer plusieurs clients non VIP.


Table ENCADREMENT :

Un encadrant peut encadrer plusieurs activités et une activité est encadrée par au moins un encadrant.


A noter qu'au stade SQL, un trigger sera à mettre en oeuvre pour s'assurer qu'une personne ne soit pas en même temps VIP et non VIP.