Discussion :

[apprenant16]

Une réflexive que tu peux appeler "cosigne" sur Membre

Oui, sauf que là chaque année les signataires peuvent changer après renouvellement du bureau. Je pense à une autre Feuille de données Signataires, non ?

[fouedusa]

Bonsoir;

Plusieurs questions dans ma tête.

qu'est ce qu'un membre ?

tu as dis qu'il y a deux signataires sur un chèque, et que les signataires sont des membres ???
===> un prêt peut avoir plusieurs membre.

Raconte nous stp l'histoire du prêt dés le début, avec des exemples si c'est possible.

quelles sont les règles de gestion ??

Bon Dev.

[apprenant16]

Salut fouedusa, j'explique :

nous somme un groupe et nous nous sommes associés pour constituer une association. Nous sommes donc les membres de l'association.
Au sein du groupe, on choisit les membres du bureau dont le Président et le Trésorier. Ces deux derniers sont les signataires des documents qui engagent l'association, donc vont signer conjointement les chèques des montants des prêts (dans le cas présent), etc.

Chaque année, le bureau est renouvelé, donc le Président de cette année peut ne pas être celui de l'année à venir, idem pour le Trésorier.

Qui dit prêt, dit ressources disponibles et les ressources de l'association proviennent de subventions reçues et des cotisations des membres. Je pense qu'il est intéressant d'intégrer ça aussi dans l'analyse en créant un fichier Revenus.

L'association, en plus des prêts, peut faire des dépenses diverses pour un évènement quelconque. Un Fichier Dépenses peut également être nécessaire.

Ainsi, je vais pouvoir suivre ma disponibilité, suivre les prêts, les remboursements, les prêts en souffrance, etc.

Voilà de façon général l'idée de cette application.

Est-ce que c'est mieux pour mon explication ?

[Voroltinquo]

Oui, sauf que là chaque année les signataires peuvent changer après renouvellement du bureau. Je pense à une autre Feuille de données Signataires, non ?

Dans ce cas tu peut créer une table Bureau qui hérite de Membre via PK_Membre avec un booléen Trésorier avec un contrôle sur le nombre de trésorier, ou alors pour généraliser une colonne Fonction (Président, trésorier, ....)

[apprenant16]

Dans ce cas tu peut créer une table Bureau qui hérite de Membre via PK_Membre avec un booléen Trésorier avec un contrôle sur le nombre de trésorier, ou alors pour généraliser une colonne Fonction (Président, trésorier, ....)

Bonne idée, je suis pour la création de la table Bureau avec les différentes fonctions. Je suppose qu'il faut ajouter un champ année pour gérer l'année de création du bureau, car l'année prochaine ça va changer. Ou bien c'est pas la bonne idée ?

[apprenant16]

Voici une nouvelle version tenant en compte les signataires et le bureau. Le champ signataire de la table Bureau est booléen.

Vous en pensez-quoi ? merci encore

[Voroltinquo]

Bonne idée, je suis pour la création de la table Bureau avec les différentes fonctions. Je suppose qu'il faut ajouter un champ année pour gérer l'année de création du bureau, car l'année prochaine ça va changer. Ou bien c'est pas la bonne idée ?

Pour prendre en compte l'année il faut créer une table de relation entre Membre et Bureau et dans cette table mettre l'année d'exercice

[fouedusa]

Bonsoir;

Comment que je vois les choses.

Bureau (idBureau_PK, DateDébut, DateFin, Observation, ...)

Bureau (1,N) <-------> (0,N) Membre

ce qui va engendrer un autre fichier (Relation Père/Père)

----------------------------------------------------------------
Proposition 1
Le nouveau fichier on le relie avec le fichier PosteOccupé

NouveauFichier (1,1) <------> (0,N) PosteOccupé

Proposition 2
Supprimer le fichier PosteOccupé
Ajouter une rubrique PosteOccupé de type combo dans le nouveau fichier, elle aura comme valeurs ( Président, Trésorier, ...)
----------------------------------------------------------------

Reste une question, dans le cas où, le Président ou bien le trésorier doit être changer au cours de l'exercice suite à une faute commise par l'un ou l'autre, dans ce cas je te propose de créer un nouveau Bureau même s'il doit contenir la majorité des membre de l'ancien Bureau

Bon Dev.

[apprenant16]

Bonsoir,

@ fouedusa : super, je vais intégrer cette proposition pour voir ce que cela donne. Je reviens avec le schema.

Une question : la clé primaire de la table Père doit-elle porter le même nom exactement sur la table fille en clé secondaire.
Exemple :

Si on a IdMembre_PK dans table 1, alors dans table 2 la clé secondaire devra porter exactement le même nom IdMembre_PK et non IdMembre_FK ?

je pose cette question, car au moment de tester l'analyse, je vois des erreurs :

Erreur :Identificateur 'COMBO_IDMembre_PK' inconnu ou inaccessible.
FEN_Fiche_Bureau.SC_Fiche.BTN_VISION_COMBO_IDMembre_FK, Clic sur FEN_Fiche_Bureau.SC_Fiche.BTN_VISION_COMBO_IDMembre_FK, ligne 6, colonne 15

[fouedusa]

Oui le même nom mais elle ne sera pas une clé unique dans le fichier résultant plutôt c'est une clé doublon.

Conseil : il faut lire l'autoformation de WinDev, tu vas trouver comment créer une relation entre deux fichiers

Bon Dev.

[apprenant16]

Super, merci pour la disponibilité et votre aide.

Je vais mettre à jour l'analyse et revenir avec la nouvelle version.

Conseil : il faut lire l'autoformation de WinDev, tu vas trouver comment créer une relation entre deux fichiers

Je l'ai sous le coude, je vais lire davantage avant de revenir.

bonne nuit aussi

[Voroltinquo]

Bonsoir;

Comment que je vois les choses.

Bureau (idBureau_PK, DateDébut, DateFin, Observation, ...)

Bureau (1,N) <-------> (0,N) Membre

ce qui va engendrer un autre fichier (Relation Père/Père)

----------------------------------------------------------------
Proposition 1
Le nouveau fichier on le relie avec le fichier PosteOccupé

NouveauFichier (1,1) <------> (0,N) PosteOccupé

Proposition 2
Supprimer le fichier PosteOccupé
Ajouter une rubrique PosteOccupé de type combo dans le nouveau fichier, elle aura comme valeurs ( Président, Trésorier, ...)
----------------------------------------------------------------

C'est ce que j'ai écrit dans le post #27 mis à part que le poste, les date doivent être dans la table de relation. Un membre fait parti d'un bureau donné pendant une période avec tel poste

[Voroltinquo]

Voilà ce que donne l'analyse modifiée

Un bureau est élu pour une période donnée l'exercice, c'est le nom du bureau.Il faut le considérer comme l'ensemble des élus.
Pendant cet exercice les élus peuvent changer de poste (démission, décès ....) d'où les dates dans la table de relation et non dans le bureau.
La signature est liée à la fonction, bien souvent le trésorier et le président d'où le booléen dans la table fonction

[apprenant16]

Bonsoir,

@ Voroltinquo : je vais prendre en compte tes remarques, et générer une nouvelle analyse.

Sinon AK et NDX : ils ont une signification particulière dans l'analyse ? s'agit-il des index ?

Merci

[Voroltinquo]

AK pour Alternative Key, un candidat à la PK qui n'a pas été retenu. NDX pour index.
C'est une convention qui m'est propre. Cela facilite parfois la relecture du code comme le péfixage des variables

[apprenant16]

AK pour Alternative Key, un candidat à la PK qui n'a pas été retenu. NDX pour index.
C'est une convention qui m'est propre. Cela facilite parfois la relecture du code comme le péfixage des variables

Ok, merci pour l'explication. Je vais mettre à jour ma version de l'analyse et revenir.

[apprenant16]

Bonjour,

Je viens de mettre à jour l'analyse. Je n'arrive pas à reproduire le même schéma proposé par Voroltinquo Maintenant en testant l'outil de création de relations automatique, j'obtiens le résultat ci-dessous. Est-ce que les cardinalités entre Bureau et Membre_Bureau sont correctes pour vous ?

[apprenant16]

Salut,

Après ajustement, voici une nouvelle version que je soumet à votre validation.

[Voroltinquo]

1-Tu as 2 PK dans ta table Membre
2-A quoi correspond ton index full text ?

[apprenant16]

Salut,

1-Tu as 2 PK dans ta table Membre

J'ai corrigé, et comme tu me l'avais indiqué plus haut, je ferais le test sur la présence de doublon au moment de la saisie.

2-A quoi correspond ton index full text ?

C'est suite à ta réponse ici, et comme sur le modèle que tu avais proposé je voyais NDX, j'ai pensé qu'il faut mettre le champ en Index.

AK pour Alternative Key, un candidat à la PK qui n'a pas été retenu. NDX pour index.
C'est une convention qui m'est propre. Cela facilite parfois la relecture du code comme le péfixage des variables

Ou bien ce n'est pas ça ?

Le nouveau schéma est là :