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.

[fsmrel]

Bonjour,

Je vous joins également le graphe des dépendances fonctionnelles que je n'ai pas réussi à terminer.

Je pense que vous vous focalisez trop sur ce graphe global qui devient beaucoup trop copieux, ce qui dissuade la relecture. Je vous conseille de produire un MCD et de construire des graphes associés à chaque entité-type ou association-type : vous n’aurez pas à tout embrasser d’un coup, mais chaque graphe isolément.

Quant à l’élaboration du MCD, vous pourriez factoriser les données de même type en utilisant le procédé de généralisation :
Un adhérent, un professeur, un membre du bureau ont en commun pas mal d’attributs (nom, prénom, adresse, téléphone, etc.) : vous pouvez en faire un surtype.
Les propriétés spécifiques font alors l’objet de sous-types. Exemple :



Bon courage, et bravo pour la qualité du recueil des données.

[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]

Bonjour et merci pour ces cours d'informatique (vous êtes prof?),

j'espère avoir compris qu'il faut que je ne m'occupe que de la modélisation des données! Dsl par avance si, je reviens sur la programmation malencontreusement.

Pourquoi l’entité-type Ceinture est-elle associée à l’entité-type Personne et l’entité-type Barrette à l’entité-type Adherent ?

Je pensais pouvoir exprimer "que toutes les personnes peuvent avoir une ceinture ou non mais si la personne est membre ou prof, elle ne possede plus de barrettes (car adulte)". Mais bon, celà va commencer à devenir une usine à gaz si je m'attarde sur des détails comme celui là.
Mais bon, j'ai quand même lié Barrette et Ceinture à personne.

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

La cotisation (due) est donnée par EntrId, l'age de l'adhérent et le lien familial ou en fonction de l'appartenance de la personne: si elle est prof ou membre ou les 2, elle ne devra règler que le coût de la licence Fédération (soit 32€ pour cette année). Purée c'est compliqué!!!

a) Évitez les attributs de type Nombre d’années, car vous aurez à recalculer le nombre d'années... annuellement.

En ce qui concerne :
- AdhNbAnnéePratique: les données de cet attribut ne seront pas calculées automatiquement car elles correspondent au nombre d’année de pratique (totale) et non au nombre d’année de pratique uniquement dans notre club. Mais, ceci pourra être mis à jour à partir du moment où l’adhérent était également, adhérent la saison passée.

- MembreNbAnnée et ProfNbAnnée et Membre1èreAnnée et Prof1èreAnnée : une requête s’en chargera donc je les enlève.

b) Mettez au singulier les noms des entités-types.

OK.

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.

J’ai éliminé Entité Cat Prof, Fonction Membre, Sexe, Profil et le Niveau de l’adhérent et les ai ajouté aux entités liées (ça se fera en SQL au moment de la programmation si j’ai bien compris).

Par contre en ce qui concerne, l’entité Ceinture et Barrette, je l’ai laissé (à tort peut être ?).
Car j’aurais souhaité créer une entité « Passage de Grade » qui selon le résultat de l’adhérent au passage de grade (« obtention de la ceinture X et / d’un nombre de barrettes supérieur ») puisse modifier ces derniers. A – que cette modification ne se fasse par une requête mise à jour donc au moment de la programmation ?

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.

Va pour MySQL Workbench, je suis en train de voir comment il fonctionne.

e) Conservez-vous les données au fil des ans ? [/QUOTE]

OUI. La raison de la création de cette BD est justement de pouvoir faire des comparaisons entre les différentes saisons (2007-2008, 2008-2009,…) :
- quels sont les anciens adhérents qui se sont réinscrit ?
- quels sont ceux qui sont parti
- …
et de pouvoir me faciliter l’enregistrement des données (exemple pour un adhérent de la saison 2007-2008, qui est adhérent à nouveau pour la saison 2008-2009, éviter de retaper les informations personnelles le concernant (adresse, date naissance,…) à moins qu’elles ne changent).

Remarque : pour nous une saison commence en septembre et se termine fin août de l’année d’après.

A+!

[fsmrel]

Bonjour,

merci pour ces cours d'informatique (vous êtes prof?)

Je ne suis pas prof, je passe plutôt mon temps sur le terrain, cependant j’ai monté pas mal de cours il est vrai (mais pas de karaté...)

Pourquoi l’entité-type Ceinture est-elle associée à l’entité-type Personne et l’entité-type Barrette à l’entité-type Adherent ?

Je pensais pouvoir exprimer "que toutes les personnes peuvent avoir une ceinture ou non mais si la personne est membre ou prof, elle ne possède plus de barrettes (car adulte)". Mais bon, cela va commencer à devenir une usine à gaz si je m'attarde sur des détails comme celui là.
Mais bon, j'ai quand même lié Barrette et Ceinture à personne.

1) Si des profs et des membres du bureau peuvent être aussi des adhérents, le fait d’établir un lien entre Barrette et Adherent n’empêche donc pas de leur attribuer des barrettes.

2) Un MCD ne permet pas d’exprimer graphiquement toutes les règles de gestion des données. Si l’attribution de barrettes est conditionnée par le profil de l’adhérent, vous pouvez réintégrer l’attribut correspondant aux nombre de barrettes (appelons-le par exemple AdhNbBarrettes) dans l’entité-type Adherent, ou figurera l’attribut AdhProfil (profil de l’adhérent), puisque la valeur du profil n’est pas dérivable, mais fournie par l’utilisateur.

En relation avec cela, les concepts de groupe d’entraînement et de profil sont-ils indépendants ?

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.

La cotisation (due) est donnée par EntrId, l'age de l'adhérent et le lien familial ou en fonction de l'appartenance de la personne: si elle est prof ou membre ou les 2, elle ne devra règler que le coût de la licence Fédération (soit 32€ pour cette année). Purée c'est compliqué!!!

Donc une personne ne peut exister en tant qu’adhérent que du moment où elle a réglé sa cotisation. Concrètement, au niveau tabulaire, Toto pourra exister en tant que Personne (dans la table Personne), mais pas en tant qu’adhérent (dans la table Adherent). Si cela vous pose des problèmes d’organisation dans votre programmation, la personne pourra malgré tout figurer dans la table Adherent, mais alors il faudra prévoir un attribut permettant de préciser si la cotisation est réglée ou non.

J’ai éliminé Entité Cat Prof, Fonction Membre, Sexe, Profil et le Niveau de l’adhérent et les ai ajouté aux entités liées (ça se fera en SQL au moment de la programmation si j’ai bien compris).

Prenons le cas du profil de l’adhérent. Comme dans le cas de la ceinture, certains contrôles seront effectués par SQL, si l’on code par exemple :

Code SQL :

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

1
2
3
4
5
 CREATE TABLE Adherent (
     PsnId      Integer   NOT NULL,
     AdhProfil  Char (16) NOT NULL CHECK (AdhProfil  IN ('enfant', 'adulte'),
    ...
 ) ;

En l’occurrence, puisque c’est l’utilisateur qui décide de la valeur prise par l’attribut AdhProfil, SQL refusera qu’il choisisse autre chose que ’enfant' ou 'adulte'.

Par contre en ce qui concerne, l’entité Ceinture et Barrette, je l’ai laissé (à tort peut être ?)

Pas forcément à tort, tout dépend de que qui suit (que je n’ai pas tout à fait compris).

Car j’aurais souhaité créer une entité « Passage de Grade » qui selon le résultat de l’adhérent au passage de grade (« obtention de la ceinture X et / d’un nombre de barrettes supérieur ») puisse modifier ces derniers.

Qu’entendez-vous par le fait qu’une entité puisse modifier ? Je ne saisis pas.

A – que cette modification ne se fasse par une requête mise à jour donc au moment de la programmation ?

Évitez le style télégraphique. Je suppose que "A -" se lit "A moins" ? Les choses sont déjà assez confuses pour ne pas en rajouter.

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

OUI. La raison de la création de cette BD est justement de pouvoir faire des comparaisons entre les différentes saisons (2007-2008, 2008-2009,…) :
- quels sont les anciens adhérents qui se sont réinscrit ?
- quels sont ceux qui sont parti

La prise en compte des données temporelles n’est pas toujours simple. On pourra regarder cet aspect des choses quand l’aspect intemporel sera stabilisé.


Je joins une ébauche de MLD réalisée avec Workbench.


Bon courage...

[Petitrenardo]

Bonjour Fsmrel, désolé de répondre aussi tardivement mais j'avais un peu laché.

1) le fait d’établir un lien entre Barrette et Adherent n’empêche donc pas de leur attribuer des barrettes.

D'accord.

2) l’attribution de barrettes est conditionnée par le profil de l’adhérent

En fait, à partir du moment ou l'adhérent fera parti des "ados adultes" (AdhProfil), on ne lui attribue plus de barrettes mais seulement une ceinture car il progressera par ceinture (CouleurCeinture) après un passage de grade (j'y reviens plus loin). Idem pour un prof ou un membre du bureau.
Mais passons l'utilisateur indiquera "0" barettes quand il sera nécessaire de l'indiquer.

les concepts de groupe d’entraînement et de profil sont-ils indépendants ?

Non, c'est la même chose. On garde donc AdhProfil (qui représente en réalité le groupe d'entrainement auquel appartient l'adhérent dans tel ou tel entrainement (self ou karaté).

Donc une personne ne peut exister en tant qu’adhérent que du moment où elle a réglé sa cotisation.

Oui, une personne n'est considérée comme adhérent que quand elle a réglé sa cotisation et remis son dossier d'inscription (qui est souvent incomplet malheureusement).

Justement par rapport au dossier d'inscription, il doit contenir la fiche d'inscription remplie (qui nous permet de renseigner la base de données), des enveloppes, le certificat médicale et une photo et le ou les règlements.
- Comment permettre, à l'utilisateur, d'indiquer s'il manque une pièce au dossier?
- En ajoutant un attribut "AdhEnvellope" et "AdhCertif" dans l'entité Adhérent? Ou dans une nouvelle entité "Dossier d'inscription" qui pourait également contenir les attributs "AdhTypeRèglement", "AdhNbRèglement", "AdhCotisationAnnuelleVersée" (si "AdhNbrèglement" = 1) ou "AdhCotisationMensuelle1Versée", 3AdhCotisationMensuelle2Versée",... (si "AdhNbRèglement >1)?

Désolé, si je balance tout en même temps .

Concrètement, au niveau tabulaire, Toto pourra exister en tant que Personne (dans la table Personne), mais pas en tant qu’adhérent (dans la table Adherent).

Oui, c'est le cas d'une personne qui n'est que membre ou que prof.

Qu’entendez-vous par le fait qu’une entité puisse modifier ? Je ne saisis pas.

Concrètement une personne a en début de saison une couleur de ceinture et / ou des barrettes.
Les profs (ou un jury extérieur pour la ceinture noire et plus) font passer des grades aux adhérents. Ils jugent si les adhérents doivent avoir un nombre de barrettes ou une ceinture plus élevée (selon s’ils ont progressé ou non).
J’aurais souhaité qu’en indiquant le résultat du passage de grade (« obtention de la ceinture X et / d’un nombre de barrettes supérieur » ou pas de progression) cela change automatiquement la ceinture et ou le nombre de barrettes de l’adhérent.
Voir Pièce Jointe, je n'ai pas eu encore le temps de me consacrer à MySQL.

Sinon l’utilisateur modifiera la base de données.

Évitez le style télégraphique.

Désolé.

La prise en compte des données temporelles n’est pas toujours simple. On pourra regarder cet aspect des choses quand l’aspect intemporel sera stabilisé.

D'accord.

Sinon comment et ou indiquer les horaires et jours des cours qui sont en fonction de "EntrId", "AdhProfil" et "AdhNiveau"?

Merci et Bonne semaine.

[fsmrel]

Bonjour,

Bonjour Fsmrel, désolé de répondre aussi tardivement mais j'avais un peu laché.

A mon tour, sorry...

En fait, à partir du moment ou l'adhérent fera parti des "ados adultes" (AdhProfil), on ne lui attribue plus de barrettes mais seulement une ceinture car il progressera par ceinture (CouleurCeinture) après un passage de grade (j'y reviens plus loin). Idem pour un prof ou un membre du bureau.
Mais passons l'utilisateur indiquera "0" barettes quand il sera nécessaire de l'indiquer.

Autant sous-traiter cela au programme que vous développerez.

Envoyé par fsmrel
les concepts de groupe d’entraînement et de profil sont-ils indépendants ?

Non, c'est la même chose. On garde donc AdhProfil (qui représente en réalité le groupe d'entrainement auquel appartient l'adhérent dans tel ou tel entrainement (self ou karaté).

Vous dites que les deux concepts ne font qu’un. On ne parlera donc plus de groupe d’entraînement, mais de profil (attribut AdhProfil de l’entité-type Adherent, dont les valeurs possibles sont "adulte", "ado", "enfant"), et à charge de l’utilisateur d’en préciser la valeur pour chaque adhérent (cf. votre message du 12/09/2008).

En revanche, vous dites que profil d’un adhérent représente le groupe d’entraînement auquel appartient cet adhérent dans tel ou tel entrainement (self ou karaté) : Si un adhérent participe au plus à un type d’entraînement, le MLD en cours est correct. Si un adhérent peut participer à plus d’un type d’entraînement, le MLD devrait évoluer :




Mais, pour éviter la relation N-M entre TypeEntrainement et Adherent et revenir à la situation actuelle, selon laquelle pour un adhérent il n’y a qu’un type d’entraînement, vous pouvez combiner ces types (exemple Karaté_Self) au niveau de TypeEntrainement.

une personne n'est considérée comme adhérent que quand elle a réglé sa cotisation et remis son dossier d'inscription (qui est souvent incomplet malheureusement).
Justement par rapport au dossier d'inscription, il doit contenir la fiche d'inscription remplie (qui nous permet de renseigner la base de données), des enveloppes, le certificat médicale et une photo et le ou les règlements.
- Comment permettre, à l'utilisateur, d'indiquer s'il manque une pièce au dossier?
- En ajoutant un attribut "AdhEnvellope" et "AdhCertif" dans l'entité Adhérent? Ou dans une nouvelle entité "Dossier d'inscription" qui pourait également contenir les attributs "AdhTypeRèglement", "AdhNbRèglement", "AdhCotisationAnnuelleVersée" (si "AdhNbrèglement" = 1) ou "AdhCotisationMensuelle1Versée", 3AdhCotisationMensuelle2Versée",... (si "AdhNbRèglement >1)?

Essayons de faire simple. Définissons par exemple une entité-type DossierPiece, permettant d’énumérer les pièces fournies, telles que certificat médical ou photographie.
Définissons par ailleurs une entité-type Reglement ne concernant que les sous.
Pour les kolossales finesses, on verra après, selon que le MLD proposé vous convient ou non.

Les profs (ou un jury extérieur pour la ceinture noire et plus) font passer des grades aux adhérents. Ils jugent si les adhérents doivent avoir un nombre de barrettes ou une ceinture plus élevée (selon s’ils ont progressé ou non).
J’aurais souhaité qu’en indiquant le résultat du passage de grade (« obtention de la ceinture X et / d’un nombre de barrettes supérieur » ou pas de progression) cela change automatiquement la ceinture et ou le nombre de barrettes de l’adhérent.
Voir Pièce Jointe, je n'ai pas eu encore le temps de me consacrer à MySQL.
Sinon l’utilisateur modifiera la base de données.

Raisonnablement, ça sera à la charge de votre programme de mettre à jour la base de données (plutôt qu’à l’utilisateur), en fonction des résultats des passages de grades. A charge seulement de l’utilisateur de déclencher le processus de mise à jour.

Concernant la pièce jointe : il manque les cardinalités, merci de compléter.

comment et ou indiquer les horaires et jours des cours qui sont en fonction de "EntrId", "AdhProfil" et "AdhNiveau"?

Faisons simple.

On met en oeuvre trois entités-types : TypeEntrainement, Profil, Niveau. Une relation ternaire entre ces trois entités-types permet de définir une référence pour les horaires des cours ainsi que pour les adhérents.

Dans l’hypothèse où l’entité-type Adhérent est dotée des trois attributs correspondants, on obtient ceci :

[Petitrenardo]

Bonsoir fsmrel,

Merci de continuer à me répondre: grâce à vous la base de données avance grandement.
J'ai quasiment compris le fonctionnement de MySQL Workbench. En fait c'est simple mais j'ai quand même recherché des instructions (que je n'ai pas trouvé d'aileurs) avant de m'y mettre.

Seulement, je voulais vous demander:
- les cardinalités ne se lisent pas comme sur le MCD (c'est l'inverse)?
- quelle est la différence entre les liens (entre les entités) en tirêts ceux en trait plein?

Mais, pour éviter la relation N-M entre TypeEntrainement et Adherent et revenir à la situation actuelle, selon laquelle pour un adhérent il n’y a qu’un type d’entraînement, vous pouvez combiner ces types (exemple Karaté_Self) au niveau de TypeEntrainement.

C'est ce que je pensais faire, seulement, j'ai peur que cela ne fonctionne plus avec la suite:
- un professeur assure un ou plusieurs CoursType (1,N)
- un CoursType peut être assuré par un ou plusieurs professeurs (1,N)

Concrètement:
- le lundi: Nicolas assure les cours Karaté (enfants débutants puis enfants gradés)
- le mardi: Nicolas, Patrick ou Mike (ils tournent toutes les semaines) assurent les cours de Karaté (adultes débutants puis gradés)
- le mercredi: Yoann assure le cours de karaté enfants débutants
- le jeudi: Patrick assure le cours de karaté enfants gradés, Mike les cours de karaté adultes (débutants puis gradés)
- le vendredi: 3 profs tournent (comme le mardi) pour assurer les cours de self defense.

Pour les kolossales finesses, on verra après, selon que le MLD proposé vous convient ou non.

ça me va très bien.

A+. Je répondrai plus tard pour la suite.

[fsmrel]

Bonsoir,

J'ai quasiment compris le fonctionnement de MySQL Workbench. En fait c'est simple mais j'ai quand même recherché des instructions (que je n'ai pas trouvé d'aileurs) avant de m'y mettre.

Pourtant l’aide en ligne est pas mal documentée...

quelle est la différence entre les liens (entre les entités) en tirêts ceux en trait plein?

Cela est justement précisé dans l’aide.
Les traits pleins correspondent à une identification relative et les traits avec des tirets correspondent à une simple référence. Je m’explique :

Dans les rapports entre deux entités, soit ces entités sont autonomes, soit l’une est plus faible et n’est jamais qu’une propriété de l’autre. Considérez par exemple les entités-types CoursType et CoursHoraire : la seconde est une propriété (multivaluée) de la première : la suppression effective d’une instance CoursType entraîne la disparition de ses instances CoursHoraire. Ce rapport de dépendance se traduit par l’indentification relative de CoursHoraire : la clé de CoursType étant composée des attributs EntrId, ProfilId et NiveauId, la clé de CoursHoraire est composée des mêmes attributs, plus l’attribut CoursHoraireId, lequel permet de décliner les différents horaires pour un cours type donné. Le mickey proposé par Workbench pour symboliser l'identification de CoursHoraire relativement à CoursType est alors le trait continu (x:n Identifying relationship).

Considérez maintenant les entités-types CoursType et Adherent : la seconde n’est en aucune façon une propriété de la première. La suppression d’une instance CoursType est interdite tant qu’un adhérent y fait référence, c'est-à-dire tant qu’on n’a pas associé les adhérents à d’autres types cours. Vous observerez que la clé de l’entité-type Adherent est uniquement composée de l’attribut PsnId. Les attributs EntrId, ProfilId et NiveauId (accompagnés d’un losange rougeâtre) ne sont présents que pour former une clé étrangère, c'est-à-dire garantir l’intégrité référentielle, selon laquelle il existe toujours un type de cours pour chaque adhérent. Le mickey proposé par Workbench pour lier CoursType et Adherent est alors le trait discontinu (x:n Non identifying relationship).

les cardinalités ne se lisent pas comme sur le MCD (c'est l'inverse)?

Oui et non.

Considérez le bout de MCD merisien suivant :



Les choses se lisent ainsi :

— Une instance de CoursType participe de 0 à n fois à l’association-type InscrireAdherent.
— Une instance de Adherent participe au moins et au plus une fois à l’association-type InscrireAdherent.

Considérons que votre lecture du graphique suive un parcours allant de la gauche vers la droite. Votre œil détecte d’abord l’entité-type CoursType, puis en suivant le fil, ne s’arrête qu’à la détection d’un objet-type, en l’occurrence l’association-type, InscrireAdherent. La lecture marque alors une pause et vous pouvez en rester là, selon que vous éprouvez ou non le besoin d’aller voir ce qu’il y a de l’autre côté du mur. Quoi qu’il en soit, la cardinalité 0,n permet de savoir qu’une instance de CoursType participe de 0 à n fois à l’association-type InscrireAdherent.


Considérons maintenant une version non merisienne du même bout de MCD :


Comme précédemment, par balayage de gauche à droite, votre œil détecte d’abord l’entité-type CoursType, puis en suivant le fil, ne s’arrête qu’à la détection d’un objet-type, en l’occurrence l’entité-type Adherent. La cardinalité qui est cette fois-ci carrément accolée à Adherent permet de savoir qu’une instance de CoursType est en relation avec plusieurs instances de Adherent (voire zéro).
Ma méthode vaut ce qu’elle vaut, mais en tout cas me permet de passer sans difficulté d’une représentation merisienne à une autre représentation sans que mes yeux se croisent.

Mais, pour éviter la relation N-M entre TypeEntrainement et Adherent et revenir à la situation actuelle, selon laquelle pour un adhérent il n’y a qu’un type d’entraînement, vous pouvez combiner ces types (exemple Karaté_Self) au niveau de TypeEntrainement.

C'est ce que je pensais faire, seulement, j'ai peur que cela ne fonctionne plus avec la suite:
- un professeur assure un ou plusieurs CoursType (1,N)
- un CoursType peut être assuré par un ou plusieurs professeurs (1,N)

D’accord. La combinaison Karaté+Self est satisfaisante pour traiter par exemple des cotisations, mais ne l’est pas concernant le travail des professeurs. On dira donc que cette combinaison disparaît, ce qui n’empêche pas qu’un professeur assure aussi bien des cours de self que de karaté. Mais comme les élèves peuvent aussi suivre des cours de self et/ou de karaté, le diagramme peut devenir le suivant en ce qui les concerne :



Ou le suivant, si l’on tient compte des horaires des cours :



Même chose pour les professeurs, d’autant que d’après les exemples que vous donnez, l’entité-type Professeur est en relation avec l’entité-type CoursHoraire plutôt qu’avec l’entité-type CoursType :




Dans ces conditions, si les entités-types Adherent et Professeur sont en relation avec CoursHoraire plutôt qu'avec CoursType, CoursHoraire peut absorber CoursType, sauf si la clé {EntrId, ProfilId, NiveauId} sert à définir les triplets licites, donc interdire les triplets illicites (s'ils existent).

[Petitrenardo]

Bonjour,
Merci pour les explications, je mourrais moins con!

Pourtant l’aide en ligne est pas mal documentée...

J'ai pas trouvé ou alors elle est en anglais but i don't speak english very well.

me permet de passer sans difficulté d’une représentation merisienne à une autre représentation sans que mes yeux se croisent.

La combinaison Karaté+Self est satisfaisante pour traiter par exemple des cotisations, mais ne l’est pas concernant le travail des professeurs.

Pour les cotisations, j'y reviendrais plus tard car c'est compliqué.

On dira donc que cette combinaison disparaît,

On est donc dans la situation suivante: EntrId n'aura pour valeur que "Karaté", "Self Défense" (pas Karaté_self).
Sinon est-ce que le MLD répond à :
- un adhérent n’a pas forcément le même niveau en Karaté et en Self (exemple : il peut être débutant en Karaté et gradé en self). Le niveau de l’adhérent varie donc en fonction de l’entrainement. Seulement pour les horaires le MLD est juste, dans le sens où les horaires sont bien déterminées par EntrId, ProfilId et NiveauId.

Dans ces conditions, si les entités-types Adherent et Professeur sont en relation avec CoursHoraire plutôt qu'avec CoursType, CoursHoraire peut absorber CoursType.

Je reviens à mon fameux passage de grade
Je vous joints une nouvelle PJ en SQL (Diagram1), il se peut fortement qu'il y ait des erreurs dessus. (bon ba ça sera en format word car il veut pas du format .mwb et comme je ne sais pas faire à partir d'une adresse URL).

De plus, il ne répond pas totalement à ce que je cherche à obtenir: il doit permettre de modifier la couleur de ceinture ou le nombre de barrettes (ou aucun changement), selon le résultat au passage de grade (cf message du 12/10). Si cela est possible?

Ps: je n'ai pas encore placé Nbbarrettes et CouleurCeinture dans mon MLD qui dépendront de ce qu'il y a au dessus (je pense).

J'ai rajouté AdhNbAnnéesPratiques et AdhClubFréquenté dans l'entité Type AdhCours (dans le diagramme global).
Ps: ne vous souciez pas du datatype des propriétés qui sont faux (j'ai pas réussi à y effacer).

A+. Bonne fin de journée!

Ps: je n'ai pas encore placé Nbbarrettes et CouleurCeinture dans mon MLD qui dépendront de ce qu'il y a au dessus (je pense).

J'ai rajouté AdhNbAnnéesPratiques et AdhClubFréquenté dans l'entité Type AdhCours (dans le diagramme global).
Ps: ne vous souciez pas du datatype des propriétés qui sont faux (j'ai pas réussi à y effacer).

A+. Bonne fin de journée!

[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+.