Discussion :

[tintin02100]

Bonjour actuellement en 1ere année de BTS SIO. J'aimerai dans le cadre d'un projet modéliser un schéma d'un base de donnée afin de pouvoir gerer un club sportif par la suite en c# ou autre.

Voici l'actuel réalisé sous access :



Celui ci est assez clair mais voilà les specifications:

Une association à des Licenciés, qui ont un ID qui correspond à leur numéro de licence. Certains peuvent faire partie du bureau directeur.

Un licencié à une licence [competition, loisirs...]
Un licencié fait une partie d'un categorie [poussin, beijamin, minime...]
Un licencié peut être aussi un juge [regional, departemental...] sur une pratique [sauts, lancers...]
Un licencié pratique une ou plusieurs activité [longueur, hauteur...] et peut avoir des performance [au 100m -> 11'5 au 05/06/2014

Chaque catégorie à un un plusieurs entraîneurs.
Chaque entrainement devra posséder un rapport ainsi que pouvoir connaitre les présents et abent.

On peut stocker les données des licenciés ou entraîneurs [carte d'identité, arrêts maladies, certificats médicaux...]

Donc voilà n'hésiter pas à refaire le schéma ... Votre aide est le bienvenue et je vous en remercie d'avance.

Je vous mets le lien du fichier access : http://88.191.145.50/Test-v3/SSQ.accdb

Valentin MARTIN

[fsmrel]

Bonjour Valentin,

Une association a des licenciés

Si vous traitez de plusieurs associations, la présence de la table ASSOCIATION est justifiée. Si vous ne traitez que de votre seule, unique et préférée association, cette table représente à elle seule l’univers du discours et doit donc disparaître du diagramme.

qui ont un ID qui correspond à leur numéro de licence

Quand on modélise, un identifiant est de préférence invariant, donc non significatif. Bien des entreprises ont dû payer le prix fort pour n’avoir pas tenu compte de ce point essentiel. Voyez l’avertissement d’Yves Tabourier à ce propos. Rien ne vous empêche de mettre en oeuvre des identifiants alternatifs : un identifiant non significatif servant de clé primaire, et le numéro de licence en tant que clé alternative, la seule à la disposition de l’utilisateur pour accéder aux données, l'identifiant non significatif servant de clé primaire restant sous le capot, utilisé pour les jointures de tables.

Certains peuvent faire partie du bureau directeur.

Selon votre diagramme, un licencié peut faire partie de plusieurs bureaux directeurs et un bureau directeur est composé d’un seul licencié.

Par ailleurs, toujours selon votre diagramme, une association peut comporter plusieurs bureaux directeurs. Qu’en est-il ?


La représentation des données à la façon ACCESS ne permet pas de représenter les cardinalités minimales. Ainsi, on ne sait pas si la relation entre LICENCIÉ et LICENCE est une bijection (un licencié a au moins et au plus une licence et une licence appartient au moins et au plus à un licencié) ou une injection (licence facultative), même si seul le 1er cas est le seul sensé. Qu’en est-il ?

=> Avant de passer à un diagramme à la ACCESS, je vous engage à mettre en œuvre un MCD ou un diagramme de classes, ou au moins un MLD au moyen de MySQL Workbench.


Quelques questions :

Qu’est-ce qu’un type de licence ? Cela correspond-il aux exemples que vous donnez : compétition, loisir ?

A quoi correspond la table QUALIFICATION ? Merci de donner des exemples de qualifications des licenciés.

Avec votre système, comment savoir que l’athlète Raoul a adhéré à l’association pendant les années 2007 à 2010, qu’il l’a ensuite quittée pour finalement revenir en 2013 ?


Le lien entre LICENCIÉ et PERFORMANCE est redondant et doit disparaître : on sait le reconstruire grâce aux liens LICENCIÉ - PRATIQUE et PRATIQUE - PERFORMANCE.

Il y a bien d’autres choses à dire, mais un éclairage sur ce qui précède serait déjà utile.