Discussion :

[Petitrenardo]

Bonjour à tous,
Bon apparement mon poste a disparu entre la nuit du 29/07 et du 30/07 donc je réédite.

Voici mon problème: je souhaite réaliser une base de données pour un club de karaté, dont je suis le président, pour faciliter sa gestion.

J'ai fait un dictionnaire de données à partir de plusieurs documents Word et Excel avec lesquels j'ai essayé d'en tirer les variables, mais je pense qu'il comporte quelques erreurs.
Je vous joins également le graphe des dépendances fonctionnelles que je n'ai pas réussi à terminer.

Merci d'avance pour votre aide.

[Petitrenardo]

Merci de votre réponse.

Vous avez sans doute raison: je me perd dans mon graph mais même en décomposant (exemple en ne m'occupant que des inscriptions et des entrainements), je n'y arrive pas.

Je vous joints le document qui (je pense) me pose des difficultés au niveau de la recherche des champs et des DF ainsi que les règles de gestions le concernant (ce que je n'arrive pas à traduire non plus):
- un adhérent peut choisir de pratiquer du karaté ou de la self ou les 2
- un adhérent va devoir payer la cotisation selon le choix de l'entrainement, son age (- de 16 ans = enfant) et une cotisation dégressive selon s'il y a plusieurs membre de sa famille inscrit.
- un adhérent est classé selon l'activité qu'il a choisi, son groupe d'entrainement (enfant ou ados/adulte) et selon son niveau (débutant ou gradé).

Si vous pouvez plus m'aider ça serait vraiment cool.
Merci d'avance.

[Petitrenardo]

J'ai oublié la PJ.

[fsmrel]

Bonsoir Petitrenardo,



Pour commencer, je vous propose l’ébauche suivante de MCD (outil Power AMC) :

un adhérent peut choisir de pratiquer du karaté ou de la self ou les 2

On définit une entité-type TypeEntrainement qui donnera lieu par la suite à une table dont les lignes prendront les valeurs "karate", "self", "karate + self".
Ainsi vous pourrez connecter un adhérent sur ce qu’il aura choisi.
Puisque vous ne pouvez pas vous passer des dépendances fonctionnelles, elles sont les suivantes :

{PsnId} → {PsnNom, PsnPrenom, PsnAdresse, PsnCeintureDebutSaison, DateNaissance}

plus (pour les personnes qui sont des adhérents) :

{PsnId} → {AdhNiveau, AdhLieuiNaissance, AdhSexe},

et, conséquence du lien avec TypeEntrainement :

{PsnId} → {EntrId}

Sans oublier au sein de TypeEntrainement :

{EntrId} → {EntLibelle}

On sait donc retrouver le type d’entraînement pour un adhérent : "karate" ou "self", ou "karate + self".

Concernant les cotisations :

D'après ce qui précède, vous connaissez le type d’entraînement de l’adhérent. Pour calculer son âge, vous vous basez sur sa date de naissance (attribut DateNaissance). Même chose pour son profil : adulte, ado, enfant.

L’entité-type associative LienFamilial vous permet de connecter un adhérent (rôle Est Adhérent) à un autre adhérent (rôle APourParent).
Pour les dépendances fonctionnelles, on visualise le MLD dérivé du MCD :





Si un adhérent est rattaché à un autre adhérent, sachant que la valeur de l’atribut PsnId (Adherent) est égale à celle de l’attribut PsnId (LienFamilial), on sait retrouver le parent de rattachement :

{PsnId} → {PsnIdParente}

Le lien APourParent permettant de remonter à PsnId (parente). On obtient la DF :

{PsnIdParente} → {PsnId}

mais la valeur de PsnId est évidemment celle du parent alors qu'avant il s'agissait d'un enfant ou (d'un compagnon...)

Tout ceci est un peu compliqué, c’est pourquoi je ne vous conseille pas l’approche analytique (c'est-à-dire la mise en évidence des dépendances fonctionnelles), mais une approche synthétique, consistant à produire un MCD dans lequel les entités-types et leurs associations sont représentées.

Ceci fait, nous pourrons passer au niveau tabulaire et illustrer par l’exemple.

Bon courage.

[Petitrenardo]

Bonjour Fsmrel,

Merci grâce à vous ça commence à prendre forme.

Par contre, j'ai quelques questions :
1) Peut on créer des tables (Table Niveau, Fonction,…) associées à une autre table pour éviter la saisie d’un enregistrement ? L’utilisateur n’aura plus qu’à le sélectionner (liste déroulante)? Voir PJ. J'ai differencier Barette et ceinture de la Table Personne car ces 2 critères peuvent evoluer après un passage de grade.

2) "L’âge sera calculé à partir de DateNaiss": à l’aide d’une requête ou dans un formulaire ?

S’agissant du profil de l’adhérent : enfant, adulte ados (je ne connais pas les âges déterminant tel ou tel profil) : l’utilisateur de la BD le sélectionnera donc pour chaque adhérent.

3) Est-ce que LienFamilial est une association réflexive ?

4) S’agissant du MLD : pouvez vous m’indiquer ce que signifie « pk », « fk », « fk2 » ?
Est-ce qu’il correspond (linéairement) à :
Personne (PsnID, PsnNom,…)
Adhérent (PsnId, AdhNiveau,…, EntrId #)
Type entrainement (EntrId, EntrLibelle)
Professeur (PsnId, ProfCatégorie)
Membre Bureau (PsnId, MembreFonction)
Lien Familial (PsnId, PsnIdParente)

6) Est ce que le MCD répond à ça:
Un prof peut être adhérent ou non
Un prof peut être Membre du Bureau
Un adhérent peut être membre du bureau.
Une pers peut être à la fois prof, adhérent et Membre du bureau.
Une personne est adhérente à partir du moment où elle a réglé une cotisation (que la licence pour les profs et membres du bureau ou cotisation complète pour adhérents « normaux »).

J’essaie de m’y retrouver mais c’est vrai que l’histoire des parents est un peu compliquée.
Dsl mais g un peu du mal à me défaire de la méthode analytique (je ne connais que ça) mais je vais faire un effort.

A+.

[fsmrel]

Bonsoir,

Peut on créer des tables (Table Niveau, Fonction,…) associées à une autre table pour éviter la saisie d’un enregistrement ?

Plutôt que de définir un attribut Niveau pour l’entité-type Adherent, on peut bien sûr établir un lien entre celle-ci et une entité-type Niveau. Cela dit, je subodore que vous n’avez pas dissocié les données (le quoi) des traitements (le comment). Nous ne traitons ici que de la description des données, des liens qu’elles entretiennent, je dirais de manière statique, platonicienne, sans avoir à se préoccuper de la programmation, c'est-à-dire de l’organisation d’une requête SQL qui peut différer selon la structure pour les données (et encore, par le mécanisme des vues, cette structure peut être présentée en sorte qu’une requête SQL y soit insensible). En tout cas, une chose est sûre : la programmation ne peut être la cause d’une remise en cause de la structure des données.

J'ai differencier Barette et ceinture de la Table Personne car ces 2 critères peuvent evoluer après un passage de grade.

Pourquoi l’entité-type Ceinture est-elle associée à l’entité-type Personne et l’entité-type Barrette à l’entité-type Adherent ?
Cela dit, supposons que toutes les personnes aient une ceinture et des barrettes (quitte à ce que le nombre de celles-ci puisse être égal à zéro). A l’instant T1, Petitrenardo a la ceinture C1 et il a B1 barrettes. A l’instant T2, on remplace la valeur B1 par la valeur B2 : ceci n’a pas d’incidence sur C1. De même, si ultérieurement, disons à l’instant T3, il change de ceinture, on remplace la valeur C1 par la valeur C2. Je suppose que la valeur B2 sera remplacée par la valeur B3. Mais là encore, où est le problème ? En quoi la structure du MCD est-elle impactée ? Comme plus haut, que les attributs Ceinture et Barrette fassent partie de l’entité-type Personne ou soient remplacés par des liens avec des entités-types Ceinture et Barrette ne change rien à l’affaire, c’est bonnet blanc et blanc bonnet.

"L’âge sera calculé à partir de DateNaiss": à l’aide d’une requête ou dans un formulaire ?

A nouveau, ceci est complètement indépendant de la modélisation des données. Quand le MCD sera stabilisé, donc le MLD et les tables qui en seront dérivées, vous pourrez poser la question sur les forums où l’on s’intéresse à la programmation pour poser la question : "Voilà, j’ai des tables dont la structure est la suivante : ... est-il préférable de passer par un formulaire, etc.?"
En tout état de cause, je dirais qu’une requête chargée de fournir l’âge d’une personne comporte simplement une soustraction, puisque l’on connaît la date de naissance et la date du jour.

Est-ce que LienFamilial est une association réflexive ?

Oui

S’agissant du MLD : pouvez vous m’indiquer ce que signifie « pk », « fk », « fk2 » ?

Comme je vous l’ai précisé, j’ai utilisé l’outil Power AMC et pour lui :

"pk" est l’abréviation de "primary key", à traduire par clé primaire. La clé primaire est à la table ce que l’identifiant est à l’entité-type.
Ainsi, l’attribut PsnId de la table Personne, compose à lui seul la clé primaire de cette table.
De la même façon, l’attribut PsnId de la table Adherent, compose à lui seul la clé primaire de cette table.

"fk" est l’abréviation de "foreign key", à traduire par clé étrangère. Le but de la manœuvre est de définir une contrainte selon laquelle les valeurs prises par les attributs de certaines tables doivent aussi être des valeurs prises par les attributs homologues dans d’autres tables.

Par exemple, supposons qu’il existe dans la table Personne la ligne suivante :

<314, Petitrenardo, ...>

où 314 est la valeur de l’attribut PsnId et "Petitrenardo" la valeur de l’attribut PsnNom.
Si Petitrenardo est un adhérent, alors la table Adherent comportera une ligne

<314, ...>

où 314 est la valeur de l’attribut PsnId pour cette ligne dans cette table. Non seulement cette valeur 314 est unique dans cet attribut de cette table (contrainte de clé primaire), mais encore doit-elle exister dans la table référencée, à savoir Personne (contrainte de clé étrangère).

De la même façon, si Petitrenardo a choisi le type d’entraînement 17, la ligne ci-dessus ressemblera à ceci :

<314, 17, ...>

mais ceci ne sera possible que si 17 est une valeur de clé primaire de la table TypeEntrainement.

Vous aurez remarqué que la table Adherent comporte plus d’une clé étrangère : Power AMC les différencie par un mickey ad-hoc : fk1, fk2, etc.

Concernant la table LienFamilial :
Supposons que Petitrenardo soit le fils de Grandgoupil, tous deux adhérents. La table Personne ressemble par exemple à ceci :

<182, Grandgoupil, ...>
<314, Petitrenardo, ...>
...

La table Adherent ressemble à ceci :

<182, 14, ...>
<314, 17, ...>

Et la table LienFamilial :

<314, 182>

pour les attributs respectifs PsnId, PsnIdParente : là encore, on a deux clés étrangères contraignant à ce que les valeurs soient cohérentes par rapport à celles des valeurs prises par la clé primaire de la table Adherent.

Est-ce qu’il correspond (linéairement)

Je ne sais pas ce que vous entendez par "linéairement", mais si on remplace cet adverbe par "tabulairement" (vision des choses sous forme de table), je réponds affirmativement. (en supposant au passage que le symbole "#" dans "Entrid#" soit l’équivalent du mickey "fk").

Est ce que le MCD répond à ça:
Un prof peut être adhérent ou non
Un prof peut être Membre du Bureau
Un adhérent peut être membre du bureau.
Une pers peut être à la fois prof, adhérent et Membre du bureau.

Oui.
Mais il est recommandé que les sous-types soient exclusifs. Par exemple, Si le surtype s’appelle FigurePlane et les sous-types Polygone et Ellipse, on a tout bon. Le problème peut être d’ordre philosophique, mais pour le cas qui nous intéresse, il est plutôt relatif à la façon de manipuler les objets.
Ainsi, en produisant une vue PsnAdherent (jointure des tables Personne et Adherent) l’utilisateur voit la structure suivante :
{PsnId, PsnNom, PsnPhoto, ..., AdhLieuNais, AdhNbAnneesPratique, AdhDernierClubFrequente} sans se douter que sous le capot, ces attributs sont ventilés dans des tables distinctes. L’utilisateur voit l’adhérent comme un tout.
Même chose si l’on produit une table PsnProfesseur :
{PsnId, PsnNom, PsnPhoto, ..., Prof1reAnnee, ProfCategorie}. L’utilisateur voit le professeur comme un tout.
Il faut réfléchir maintenant, à savoir si ces vues suffisent pour traiter le cas du professeur qui est adhérent ou s’il faut une vue nouvelle, qui soit la jointure des deux précédentes :
{PsnId, PsnNom, PsnPhoto, ..., AdhLieuNais, AdhNbAnneesPratique, AdhDernierClubFrequente, , Prof1reAnnee, ProfCategorie}.

Une personne est adhérente à partir du moment où elle a réglé une cotisation

Autrement dit, vous devez d’abord faire figurer la partie Cotisations dans le modèle.


Remarques diverses.

a) Évitez les attributs de type Nombre d’années, car vous aurez à recalculer le nombre d'années... annuellement. C’est comme pour l’âge des personnes. Une requête chargée de fournir le nombre d’années pour un professeur comporte simplement une soustraction dont les opérandes sont l’année en cours (fournie automatiquement par le système) et l’année de début de pratique du professeur. Même principe pour les années de pratique des adhérents.

b) Mettez au singulier les noms des entités-types. Une entité-type est comme un prédicat :
La personne identifiée par PsnID a pour nom PsnNom, pour prénom PsnPrenom, ....

c) Si une entité-type comme Ceinture ne comporte qu’un attribut, elle peut être absorbée par l’entité-type à laquelle elle est associée, en l’occurrence Personne. Dans ce cas-là, Personne est à doter d’un attribut Ceinture, auquel on associe la liste des valeurs possibles. Cette liste fera l’objet d’une contrainte au niveau SQL :

Code SQL :

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

1
2
3
4
5
Create TABLE Personne (
 PsnId     Integer   not null,
 Ceinture  Char (16) not null check (Ceinture in ('blanc', 'jaune', 'orange'),
...
)

d) Votre schéma tient à la fois du MCD et du MLD. Il serait temps que vous vous dotiez d’un outil de modélisation.
Par exemple, MySQL Workbench, qui tient plus du MLD que du MCD, mais il est gratuit.
Voyez par exemple :
http://www.developpez.net/forums/d57...e/#post3404931

Les mickeys sont évidemment différents. Par exemple, au lieu du mickey <fk>, on a un losange rougeâtre, mais on s’y fait vite.


e) Question :

Conservez-vous les données au fil des ans ?

[Petitrenardo]

Bonsoir,

Vous voulez plus me répondre .
Peut être que je vous en trop demandé?
Pourtant vos réponses me sont très utiles et me permettent d'avancer dans mon projet et même d'apprendre beaucoup de choses!

Merci d'avance pour votre réponse.

[fsmrel]

Bonjour,

Je ne vous oublie pas, mais j'ai plein de fers au feu.

Une question se pose. Selon le dernier MLD que je vous ai proposé, on ne connaît les niveaux, types d'entraînement et profils des adhérents qu'une fois définis les liens avec les horaires des cours (cf. table AdhCours). Est-ce que cela n'est pas gênant ?

Désolé pour le retard...

[Petitrenardo]

Bonjour,

Pas grave pour le retard, c'est juste un peu plus dur pour se remettre dedans.

Pour la question, je ne comprend pas, désolé.
Je peux juste vous dire celà (si ça peut vous aider et en même temps ça fait un rappel):
-les horaires et jours des cours sont définis grâce aux niveaux, types entrainement et au profils: exemple les cours de Karaté (types entrainement) des enfants (profil) débutants (niveau) ont lieu un certains jour à une certaine heure.
- le type d'entrainement choisi par l'adhérent, son profil et son niveau (qui peut être différent selon l'entrainement choisi exemple: Gradé en karaté et débutant en self) nous permet de "savoir " les heures de cours pour un adhérent.

Après je peux pas vous dire si celà pose un problème avec le MLD que vous m'avez proposé (je suis un peu perdu).

A+.

[fsmrel]

Selon le MLD, les horaires (table CoursHoraire) doivent exister dans la base de données avant que l’on puisse y engranger (table AdhCours) le type d’entraînement, le niveau et le profil d’un adhérent quel qu'il soit. Ma question était donc : est-ce jouable ? (dans la mesure où les horaires seraient effectivement définis avant la saisie des informations concernant les adhérents : type d'entraînement, niveau, profil).

[Petitrenardo]

Salut,

C'est bon , ça ne posera pas de problème dans la mesure ou les horaires des cours sont définis (définitivement) à la fin de la saison pour la saison suivant, donc bien avant de renseigner les informations concernant les adhérents de la nouvelle saison.

Après, je ne sais pas si ce MLD conviendra si la base de données est utilisée pour plusieurs saisons (en gardant les données des saisons précédentes: vous m'avez déjà dit que l'on traitera le temporel une fois l'intemporel bien défini).

A+.