Discussion :

[Locus51]

Bonjour à toutes et à tous,

Je poste pour vous faire part de mon projet de créer un applicatif web de gestion des adhérents pour une association (Php - MySQL).

Je suis actuellement dans une phase de modélisation des données, après avoir recueilli le maximum de contraintes de gestion. Cependant, étant débutant en développement, j'ai sans doute du mal à avoir une pensée synthétique au premier coup d'œil sur un projet comme celui-ci.

J'aimerais avoir l'avis des plus expérimenté(e)s sur le MCD suivant :
(note : - modélisé avec analyseSI)



La relation réflexive concernant la parenté sur les adhérents n'apparait pas correctement car AnalyseSi ne me permet pas de la schématiser.

Ensuite, malgré une redondance d'informations apparente sur les tables adhérents et animateurs, je les ai séparées pour que ce soit plus facile au niveau applicatif, après je me trompe peut être.

Enfin, mes soucis principaux sont au niveau des circularités apparentes du schéma, j'aimerais savoir si cela pose une problème ensuite quand on passe au code. Et, il y a également le problème des tarifs, je pensais faire une table exclusivement réservée aux tarifs mais je me suis aperçu que le tarif dépendait des plusieurs choses, à savoir :
- la catégorie d'activité (encadrée par des professionnels ou des bénévoles)
- la durée (une même activité peut avoir plusieurs durées avec des tarifs correspondants)
- la catégorie d'adhérents (adultes - enfants - étudiants - chômeurs, etc..)
- la valeur de la cotisation de l'année en cours

Sur ces points, je sollicite donc vos avis les plus éclairés, car il existe certainement une ou plusieurs manières de s'y prendre pour obtenir un MCD correct avant de passer au code.

Je vous remercie par avance du temps que vous prendrez à me répondre et je ne manquerais pas de vous fournir tous renseignements complémentaires nécessaires à la compréhension du projet et de mon Modèle.

[JPhi33]

Bonjour Locus51,

Voici mes premières réflexions.

(note : - modélisé avec analyseSI)

Ce n'est pas le meilleur, mais il a l'avantage d'être gratuit.

La relation réflexive concernant la parenté sur les adhérents n'apparait pas correctement car AnalyseSi ne me permet pas de la schématiser.

Ce type d'associations doit être 0,n--0,n et nécessite une modélisation rigoureuse incluant un rôle sur chaque patte. Prenons l'exemple d'un père (a1) et de ses deux fils (a2 et a3). La table issue de l'association devra comporter les lignes suivantes :

Code :

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

1
2
3
4
5
6
idAdhérent idAdhérent TypeParenté
a1         a2         père
a1         a3         père
a2         a1         fils
a3         a1         fils

Mettons les liens "frère" de côté. La première ligne comporte la parenté "père" car a1 est le père de a2. Mais le TypeParenté pourrait très bien être "fils" car a2 est le fils de a1.
Pour résoudre ce dilemme, il est nécessaire de nommer les pattes de l'association afin d'identifier le rôle de chaque idAdhérent dans la table résultante. Par exemple, on peut nommer les pattes :
- "exerce" pour exprimer qu'un adhérent exerce un lien de parenté sur d'autres adhérents
- "est_but" pour exprimer qu'un adhérent est but de liens de parenté provenant d'autres adhérents

Les colonnes de clé idAdhérent de la table deviennent, respectivement, idAdhérent_exerce et idAdhérent_est_but. Ainsi, la première ligne exprime sans ambiguïté que "a1 est père de a2" (a1 exerce le lien de parenté père sur a2).

Ensuite, malgré une redondance d'informations apparente sur les tables adhérents et animateurs, je les ai séparées pour que ce soit plus facile au niveau applicatif, après je me trompe peut être.

Non, tu ne te trompe pas, il FAUT les séparer, ce sont des concepts différents, ils ne jouent pas le même rôle dans le MCD, par exemple :
- un adhérent effectue des réglements mais pas un animateur,
- un animateur anime des activités mais pas un adhérent qui, lui, participe a des activités

Par contre, il y a un moyen d'optimiser cette modélisation en généralisant Animateur et Adhérent en Personne, par exemple. Toutes les propriétés communes (nom, prénom, etc.) sont alors factorisées dans cette entité générale.
Remarque : AnalyseSI ne permet pas de modéliser la généralisation/spécialisation (qui permet de mettre en oeuvre l'héritage).

Enfin, mes soucis principaux sont au niveau des circularités apparentes du schéma, j'aimerais savoir si cela pose une problème ensuite quand on passe au code.

Il n'y a pas de "circularité" dans le schéma (ou alors elle m'échappe).

Et, il y a également le problème des tarifs, je pensais faire une table exclusivement réservée aux tarifs mais je me suis aperçu que le tarif dépendait des plusieurs choses, à savoir :
- la catégorie d'activité (encadrée par des professionnels ou des bénévoles)
- la durée (une même activité peut avoir plusieurs durées avec des tarifs correspondants)
- la catégorie d'adhérents (adultes - enfants - étudiants - chômeurs, etc..)
- la valeur de la cotisation de l'année en cours

La modélisation de l'association Tarif est tout à fait correcte.

[Locus51]

Bonjour JPhi33,

Merci de ta réponse qui vient m'éclairer surtout au niveau de la relation réflexive. Ton explication m'aide à y voir plus clair.

Un ami informaticien m'a encouragé à télécharger la version d'essai de powerAMC 15 qui est apparemment plus indiquée pour finaliser mon modèle.

Je vais également voir pour l'optimisation, la création d'une table "personnes" avec une distinction des rôles. Je suis curieux de voir ce que cela va donner au niveau du modèle physique à ce niveau car je n'en ai pas la moindre idée pour l'instant.
Je vais en profiter pour relire quelques toturiels à ce sujet.

Je reposterai sans doute en ce sens.

[fsmrel]

Bonsoir,

(note : - modélisé avec analyseSI)

Ce n'est pas le meilleur, mais il a l'avantage d'être gratuit.

Il y a aussi Open ModelSphere (je me sers ici de la version 3.1) qui lui aussi est gratuit et qui permet de modéliser les réflexives et l’héritage (sans toutefois proposer un graphisme ad-hoc (ce qu’il permet toutefois avec la notation UML)). En prime, l’outil permet de dériver le MCD en MLD, puis de générer le script SQL de création des tables.

Réflexive, MCD



Reflexive, MLD


Exemple de code SQL généré par L’outil :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
CREATE TABLE Adherent 
(
    IdAdherent     INTEGER NOT NULL,
    NomAdherent    NVARCHAR(64) NOT NULL,
    PrenomAdherent NVARCHAR(64) NOT NULL,
    PRIMARY KEY (IdAdherent)
);
CREATE TABLE Parente 
(
    IdAdherentParent INTEGER NOT NULL,
    IdAdherentEnfant INTEGER NOT NULL,
    PRIMARY KEY (IdAdherentParent, IdAdherentEnfant)
);
ALTER TABLE Parente
  ADD 
    FOREIGN KEY (IdAdherentParent)
      REFERENCES Adherent;
 
ALTER TABLE Parente
  ADD 
    FOREIGN KEY (IdAdherentEnfant)
      REFERENCES Adherent;

Héritage, MCD



N.B. Voir la discussion avec dxerty quant à la façon de procéder d’un point de vue technique.

Héritage, MLD

(Je ne sais pas pourquoi l’outil oublie de marquer IdPersonne comme clé étrangère concernant la table Adherent, petit bug ? Mais ça n’est pas grave, la génération SQL est correcte...)




Code SQL généré :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
CREATE TABLE Personne 
(
    IdPersonne INTEGER NOT NULL,
    NomPersonne NVARCHAR(64) NOT NULL,
    PrenomPersonne  NVARCHAR(64) NOT NULL,
    PRIMARY KEY (IdPersonne)
);
CREATE TABLE Adherent 
(
    IdPersonne INTEGER NOT NULL,
    AttributSpecifique  NVARCHAR(64) NOT NULL,
    PRIMARY KEY (IdPersonne)
);
CREATE TABLE Animateur 
(
    IdPersonne INTEGER NOT NULL,
    DateEmbauche DATE NOT NULL,
    PRIMARY KEY (IdPersonne)
);
ALTER TABLE Adherent
  ADD CONSTRAINT Adh_PSN_FK 
    FOREIGN KEY (IdPersonne)
      REFERENCES Personne
        ON DELETE CASCADE;
 
ALTER TABLE Animateur
  ADD CONSTRAINT Anim_Psn_FK 
    FOREIGN KEY (IdPersonne)
      REFERENCES Personne
        ON DELETE CASCADE;

Un ami informaticien m'a encouragé à télécharger la version d'essai de powerAMC 15 qui est apparemment plus indiquée pour finaliser mon modèle.

Évidemment, avec Power AMC on a des fonctionnalités que n’offre pas Open ModelSphere, mais la version d’essai ne dure que ce que durent les versions d’essai (et encore...), et au final le DDL SQL est le même.

Si au bout de 15 jours vous êtes amené à faire évoluer votre modèle, que ferez-vous avec un Power AMC inutilisable ? Quinze jours ça passe très vite...

Je vais également voir pour l'optimisation, la création d'une table "personnes" avec une distinction des rôles. Je suis curieux de voir ce que cela va donner au niveau du modèle physique à ce niveau car je n'en ai pas la moindre idée pour l'instant.
Je vais en profiter pour relire quelques toturiels à ce sujet.

Avec ce qui précède, vous pouvez vous faire une idée quant à la façon de traiter de l’héritage. Par ailleurs, dans une discussion avec Heledir (entre autres), un certain nombre de points sont détaillés aux différents niveaux, pas à pas.

Je reste à votre disposition si vous essayez Open ModelSphere et s’il vous pose des problèmes (mais je n’en suis pas un fin spécialiste, disons que j’ai des réminiscences de SilverRun que j’ai un peu utilisé il ya une quinzaine d’années...)

Ce type d'associations doit être 0,n--0,n et nécessite une modélisation rigoureuse incluant un rôle sur chaque patte. Prenons l'exemple d'un père (a1) et de ses deux fils (a2 et a3). La table issue de l'association devra comporter les lignes suivantes :

Code :

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

1
2
3
4
5
6
idAdhérent idAdhérent TypeParenté
a1         a2         père
a1         a3         père
a2         a1         fils
a3         a1         fils

Mettons les liens "frère" de côté. La première ligne comporte la parenté "père" car a1 est le père de a2. Mais le TypeParenté pourrait très bien être "fils" car a2 est le fils de a1.

Je ne suis pas spécialement d’accord avec cette solution, du fait de la redondance qui comme toute redondance présente des risques si elle n’est pas contrôlée au niveau des opérations (INSERT, UPDATE DELETE), et souvent elle ne l’est pas, disons par ignorance.

Je préfère pour ma part la structure suivante :

Parenté {IdAdherentParent, IdAdherentEnfant}

Et la valeur de table :

Code :

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

1
2
3
4
idAdhérentParent idAdhérentEnfant
a1               a2         
a1               a3

Sachant que la 1re colonne est utilisée par convention pour les parents (disons le père et/ou la mère ou tout responsable parental) et la deuxième pour les enfants. La troisième colonne disparaît.


Au niveau des opérations, il sera très simple de savoir qui sont les enfants d’Untel, qui sont les parents de Totor, quels sont les enfants d’une même fratrie.

J’aurais même plutôt tendance à transformer une des 0,N en 0,1 (rôle Enfant), c'est-à-dire transformer le graphe en hiérarchie.

MCD



MLD

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
CREATE TABLE Adherent 
(
    IdAdherent INTEGER NOT NULL,
    NomAdherent NVARCHAR(64)NOT NULL,
    PrenomAdherent NVARCHAR(64) NOT NULL,
    PRIMARY KEY (IdAdherent)
);
CREATE TABLE Parenté 
(
    Adherent INTEGER NOT NULL,
    IdAdherentParent INTEGER NOT NULL,
    TypeParenté CHARACTER(3) NOT NULL,
    PRIMARY KEY (Adherent)
);
CREATE TABLE TypeLienParenté 
(
    TypeParenté CHARACTER(3) NOT NULL,
    PRIMARY KEY (TypeParenté)
);
ALTER TABLE Parenté
  ADD FOREIGN KEY (Adherent) REFERENCES Adherent;
 
ALTER TABLE Parenté
  ADD FOREIGN KEY (IdAdherentParent) REFERENCES Adherent;
 
ALTER TABLE Parenté
  ADD FOREIGN KEY (TypeParenté) REFERENCES TypeLienParenté;

Popositions :

Code :

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

1
2
3
4
5
idAdhérent IdAdherentParent TypeParenté
 a2          a1             enfant
 a3          a1             enfant
 a4          a1             épouse

Mais bien sûr, tout ça se discute.


En attendant, bonnes fêtes de Pâques à tous,

François

[Locus51]

Merci fsmrel pour ta réponse détaillée.

C'est bien la qualité des réponses qui m'a poussée en autre à m'inscrire sur le forum !

Je vais regarder dans la semaine pour ModelSphere.

J'ai aujourd'hui essayé MySQL Workbench Community. J'avoue ne pas encore avoir tout testé, par contre la mise en relation avec la bdd est fort agréable.

[JPhi33]

Bonsoir,

Je ne suis pas spécialement d’accord avec cette solution, du fait de la redondance qui comme toute redondance présente des risques si elle n’est pas contrôlée au niveau des opérations (INSERT, UPDATE DELETE), et souvent elle ne l’est pas, disons par ignorance.

Certes, mais si on lit bien la suite :

Pour résoudre ce dilemme, il est nécessaire de nommer les pattes de l'association afin d'identifier le rôle de chaque idAdhérent dans la table résultante. Par exemple, on peut nommer les pattes :
- "exerce" pour exprimer qu'un adhérent exerce un lien de parenté sur d'autres adhérents
- "est_but" pour exprimer qu'un adhérent est but de liens de parenté provenant d'autres adhérents

Les colonnes de clé idAdhérent de la table deviennent, respectivement, idAdhérent_exerce et idAdhérent_est_but. Ainsi, la première ligne exprime sans ambiguïté que "a1 est père de a2" (a1 exerce le lien de parenté père sur a2).

C'est-à-dire :

Parenté {idAdhérent_exerce, idAdhérent_est_but}

ou, pour simplifier :

Parenté {idAdhérent1, idAdhérent2}

A moins qu'il s'agisse d'une autre redondance ?

J’aurais même plutôt tendance à transformer une des 0,N en 0,1 (rôle Enfant), c'est-à-dire transformer le graphe en hiérarchie.

La hiérarchie risque de ne pas couvrir tous les cas (ou plus difficilement). En effet, on ne dit pas que les liens de parenté sont tous du type parent/enfant ; on ne dit rien du tout d'ailleurs, et Locus51 devrait nous éclairer sur ce point.

Prenons l'exemple de 3 frères (a1, a2, a3) dont les parents ne sont pas adhérents. Avec le graphe, on peut associer chaque adhérent à ses deux frères :

Code :

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

1
2
3
4
5
6
7
8
idAdhérent1 idAdhérent2
a1          a2
a1          a3
a2          a1
a2          a3
a3          a1
a3          a2

Avec la hiérarchie, on peut y arriver aussi mais la reconstitution de la fratrie va s'avérer plus complexe :

Code :

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

1
2
3
4
5
idAdhérent idAdhérentParent
a1         a2
a2         a1
a3         a1

[Locus51]

Bonjour JPhi33, fsmrel,

Je suis tout à fait d'accord avec fsmrel sur le plan modélisation de la relation réflexive, le fait d'externaliser le type parenté, nous permet d'éviter une redondance.

Néanmoins, avec le cas de l'exemple de la fratrie citée par JPhi33, cela me semble effectivement plus difficile à gérer au niveau de l'applicatif par la suite.

Je penche plutôt pour la première solution (celle de JPhi33) car malgré cette redondance, il me semble plus aisé de gérer ce type de relation au niveau code.

Après étant un grand débutant, je pense qu'il va falloir que je fasse quelques essais sur le papier. Sachant que l'on m'impose d'utiliser un système de filtres à partir de la sélection d'un adhérent. La redondance sera très importante sur une table à plus de mille entrées (adhérents). Je pense qu'il faut que je fasse un choix entre l'une ou l'autre de ces solutions en fonction de :
- ce que l'on va me demander au niveau de la gestion de ces relations (on m'a parlé d'un système de filtres donc...il faut que je creuse)
- la manière que je vais avoir de coder la gestion de la relation, car dans l'exemple de la fratrie cela peut devenir à mon avis, assez difficile.

C'est ma première impression à chaud, dès que j'aurais fini complètement le modèle physique, je pense commencer par gérer une classe objet autour de l'adhérent et de ses types de relations avec les autres.

Je vais me pencher sur ModelSphere en gardant à l'esprit ce que vous venez de me dire. Dès que j'aurais un peu plus réfléchis sur ce point, je vous en ferais part de nouveau.

Cette relation réflexive est décidément très intéressante à réaliser pour le débutant que je suis. Je vous remercie de votre aide très précieuse.

Locus51.

[JPhi33]

Bonjour,

Je suis tout à fait d'accord avec fsmrel sur le plan modélisation de la relation réflexive, le fait d'externaliser le type parenté, nous permet d'éviter une redondance.

Avec cette réponse de Locus51, je viens de comprendre de quelle redondance il s'agit : celle sur le type de parenté. Effectivement, il faut éliminer cette redondance par externalisation du type de parenté (voir les diagrammes de fsmrel).

Voici le MCD complet :

Code :

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

1
2
3
4
5
6
7
8
     +------0,n-----+
     |              |
     |              |
[ Adhérent ]   ( Parenté )--1,1----(CIF)----0,n->[ TypeParenté ]
     |              |
     |              |
     +------0,n-----+

Attention, la CIF entre l'association Parenté et l'entité TypeParenté n'est pas modélisable directement avec Open ModelSphere.

Le MLD correspondant est :

Adhérent(idAdhérent, ...)
TypeParenté(idTypeParenté, LibelléTypeParenté)
Parenté(idAdhérent1#, idAdhérent2#, idTypeParenté#)

(idAdhérent1 et idAdhérent2 référencent idAdhérent de la table Adhérent.)

[Locus51]

Bonsoir,

J'en profite pour reposter et vous montrer le mcd que j'ai refait avec Open ModelSphere. Merci fsmrel pour me l'avoir conseillé, je ne le connaissais pas du tout.

C'est rapide à la prise en main et gratuit. Bref, avant d'aller plus loin, cad la génération du MPD, il serait bon surtout au niveau héritage que j'ai la confirmation que je m'y prends de la bonne manière, outre le fait de ce qui a été expliqué auparavant à moins que je l'ai mal compris...

En vérifiant le modèle j'obtiens tout un tas d'avertissement de ce genre : "Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.", et je saisis assez mal ce que cela signifie. Si l'un de vous pouvait m'éclairer.

Ensuite, j'ai la partie de tout ce qui est rattachée à l'adhérent, je vais regarder ce que cela donne au niveau du modèle physique généré pour voir si c'est valable. N'hésitez pas à le commenter de long en large, même au niveau des détails car votre aide m'a permis d'avancer énormément.



Cordialement,

Locus51.

[JPhi33]

il serait bon surtout au niveau héritage que j'ai la confirmation que je m'y prends de la bonne manière, outre le fait de ce qui a été expliqué auparavant à moins que je l'ai mal compris...

La représentation graphique est correcte mais il faut voir ce que cela donne au niveau MLD après génération, notamment pour les clés primaires des entités ADHERENTS et ANIMATEURS.
Que signifie le soulignement des cardinalités 1,1 des associations Etre_Adhérent et Etre_Animateur ?

En vérifiant le modèle j'obtiens tout un tas d'avertissement de ce genre : "Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.", et je saisis assez mal ce que cela signifie. Si l'un de vous pouvait m'éclairer.

La navigabilité est un concept du diagramme de classes UML dont on n'a rien à faire dans un MCD. Elle indique la possibilité pour une instance d'une classe (donc un objet) de voir (navigable) ou pas (non navigable) le ou les objets cible du lien.
Mais dans l'aide d'OMS relative au MCD, on peut lire : "Navigabilité du rôle : indique si l’entité est parent ou enfant.". Je n'ai pas vérifié quel est l'impact de ce concept sur la génération du MLD.

[fsmrel]

Bonsoir,


Désolé les amis, j’arrive un peu en retard, mais, concernant DVP (forum Schéma), j’ai été bien occupé avec Yacine.

Attention, la CIF entre l'association Parenté et l'entité TypeParenté n'est pas modélisable directement avec Open ModelSphere.

Au niveau du MCD, on peut éventuellement utiliser un pense-bête comme ci-dessous (nom de l'arc)...


Mais au niveau du MLD, il est bien sûr impératif de faire disparaître l’attribut TypeParenté de la clé primaire de la table Parenté. Pour cela agir au niveau de l’explorateur :

Modèle converti > Entités > Parenté > Clés primaires/uniques > Clé primaire/unique > Attributs > TypeParenté > délier.

Ou plus simplement : Cliquer sur l’icône de la clé dans la barre d’outils et la drag/droper sur la même icône dans la table TypeParenté.

Au résultat :

Que signifie le soulignement des cardinalités 1,1 des associations Etre_Adhérent et Etre_Animateur ?

Souligner les cardinalités 1,1 permet de signifier à l’AGL que l’on fait de l’identification relative.

1) Dans mon message du 04/04/2010, 01h43, voir la remarque :

N.B. Voir la discussion avec dxerty quant à la façon de procéder d’un point de vue technique.

2) En conséquence, voir effectivement la discussion avec dxerty.

En vérifiant le modèle j'obtiens tout un tas d'avertissement de ce genre : "Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.", et je saisis assez mal ce que cela signifie. Si l'un de vous pouvait m'éclairer.

Comme dit JPhi33, la navigabilité a à voir avec UML et n’a rien à faire dans le MCD. Mais puisque ModelSphere effectue malgré tout des contrôles, on règle le problème en agissant au niveau des arcs :



Par exemple, l’association Participer est dotée de deux arcs, l’un se nommant [Activité - Participer] et l’autre [Adhérent -Participer]. A chacun est associé un rôle :

Activite Rôle pour le 1er, correspondant à la cardinalité 0,N.
Adherent Rôle pour le 2e, correspondant à la cardinalité 1,1.

La case Navigabilité doit être cochée pour Adherent Rôle et décochée pour Activite Rôle.
Dans le cas général, l'AGL exige qu’au moins et au plus un rôle soit navigable.


J’ai d’autres choses à dire, mais il se fait tard...

[Locus51]

Bonjour,

Je vais faire la génération du MLD aujourd'hui avec la manipulation de dxerty.

Merci pour les précisions au niveau de la réflexive et des avertissements générés, je vais faire la manipulation également pour la clef. Par contre, en ce qui concerne, la remarque de fsmrel :

"Activite Rôle pour le 1er, correspondant à la cardinalité 0,N.
Adherent Rôle pour le 2e, correspondant à la cardinalité 1,1."

Autant pour le 1er, je comprends autant pour le deuxième, j'ai plus de mal.
Pourquoi pas une cardinalité 1,N ? Un adhérent peut participer à une ou plusieurs activités ?

[Locus51]

Je viens de faire la génération du MLD.
Je vous mets le schéma en lien, car il commence à être important.
Il y a des parties que j'ai du mal à comprendre au niveau de la génération, notamment au niveau de la table adhérents, j'ai une clef primaire sans nom qui traîne et à chaud je ne vois pas à quoi elle peut bien correspondre.

Egalement, dans la table personnes, j'ai un clef étrangère FK1 sans nom et personnellement, je n'en compte que 3 FK et pas 4.

Bon, je vais regarder à tête reposée en fin d'après-midi. Je finis de coder le module d'administration pour l'instant.

lien du schéma : http://img63.imageshack.us/i/mldrendu01.jpg/

A bientôt,
Locus51.

[fsmrel]

Pourquoi pas une cardinalité 1,N ? Un adhérent peut participer à une ou plusieurs activités ?

J’avais perdu de vue votre MCD et dans celui que je me suis concocté vite fait sur le gaz pour traiter du problème de la navigabilité, j’ai utilisé une cardinalité 1, 1. Cette cardinalité est purement fantaisiste, votre 1,N n’est absolument pas remise en cause.

Je vais regarder vos autres problèmes. En attendant, sachez que l’AGL me perturbe dans sa façon de générer les MLD. Je n’ai pas trouvé le moyen (et je ne pense pas qu’il en existe un) de lui demander de mettre à jour un MLD existant suite à modification du MCD : on ne peut que créer un nouveau MLD, ce qui s’avère pénible si on a déjà effectué un certain nombre de manips sur le MLD précédent et qu’il faut se les recoltiner à chaque modification...

[fsmrel]

au niveau de la table adhérents, j'ai une clef primaire sans nom qui traîne et à chaud je ne vois pas à quoi elle peut bien correspondre.

Partons de ce MCD :



Et procédons à la dérivation en MLD. Le résultat obtenu est le suivant :




Du point de vue de l’AGL, il est normal que la clé primaire de la table Adherent soit vide (idem concernant la table Animateur), car l’attribut composant cette clé entre aussi dans la composition de la clé étrangère référençant la table Personne, or la génération des clés étrangères n’est pas automatique (ce qui peut effectivement paraître curieux) et nous devons lui demander (très poliment) d’effectuer cette génération.

Allons-y :

Outils > Modèle de données > Générer les clés étrangères

Au résultat :


Et cette foi-ci clés primaires et étrangères sont présentes. Il y a même du rab, puisque l’AGL a créé des cycles qu’il va falloir rompre.

On fait donc le ménage dans la table Personne :

a) Suppression de la clé étrangère (Adherent Personne IdPersonne)
b) Suppression de l’attribut lui-même Adherent Personne IdPersonne.

Même chose bien sûr concernant la clé étrangère ciblant la table Animateur.
Pour supprimer les deux clés étrangères en une fois, on peut passer par l’arborescence de l’explorateur :

Modèle de données (converti) > Entités > Personne > Clés étrangères

Clic droit sur Clés étrangères et choisir « supprimer ». Au résultat :



Supprimer ensuite dans Personne les attributs qui composaient les clés étrangères, Adherent Personne IdPersonne et Animateur Personne IdPersonne :



Si cela n’a pas déjà été fait (ce qui est le cas ici), Renommer les colonnes ayant des noms à rallonge (tables Adherent et Animateur) :



Supprimer les informations redondantes concernant les clés primaires et étrangères (cartouches du bas) :

Format > Styles du projet > Données >Données - normal > Affichage de la structure

Décocher « Clé primaire » et « Clé étrangère »

Et tant qu’à faire, en profiter pour remettre de l’ordre dans les colonnes :



J'espère ne pas m'être planté dans les copier/coller...

[Locus51]

Bonjour fsmrel,

Merci de ton aide. Je vais mettre à jour le MLD suivant les indications fournies.
Je reposterai par la suite si j'ai encore des questions sur Open Modelsphere.