Discussion :

[Jiben59]

Bonjour la communauté,

je me tourne vers vous afin d'obtenir votre avis sur mon relationnel de ma base qui permet de gérer plusieurs comptes bancaires en même temps.

Ci-dessous, vous trouverez mon relationnel :


Auriez-vous des remarques sur le relationnel de ma base de données ?

Je me demande, s'il ne faudrait pas intégrer la clé primaire de la table "T_Journal" dans la table "T_SousJournal"

Car la table "T_Journal" se compose ceci :


Et la Table "T_SousJournal" de cette manière :


Je remercie d'avance pour vos remarques.

Dans l'attente de vous lire, je vous souhaite une bonne soirée.

Bien cordialement,
Benjamin.

[marot_r]

Bonjour.

À mon avis tu devrais avoir soit :

T_Journal
CodeJnl

T_SousJournal
CodeSousJnl
CodeJnl

• en jointure avec T_Journal sur CodeJnl
• en jointure avec T_Mouvement sur CodeJnl et CodeSousJnl

soit

T_Journal
CodeJnl

• en jointure avec T_Mouvement sur CodeJnl

T_SousJournal

• CodeSousJnl
• en jointure avec T_Mouvement sur CodeSousJnl

La 1ère structure est plus rigoureuse car tu ne peux assigner qu'un sous-journal associé à un journal donné.
La 2nde permet toutes les combinaisons entre journal et sous-journal.

Aussi j'aurai fait :

T_Banques
RefBanque

T_Titulaires
RefTitutlaires

T_Comptes
RefCompte
RefBanque
RefTitulaire

• En jointure avec T_Banques
• En jointure avec T_Titulaires

Car à priori, on est pas titulaire d'une banque mais d'un compte dans une banque.

Pour info, une relation entre tables de type 1 à 1 est toujours suspecte.

• Soit tout devrait être dans une seule table.
  Si tu as pour tout enregistrement dans une table un et un seul enregistrement dans une autre table, pourquoi les séparer ?
• Soit tu a vraiment beaucoup de champs et tu dois "déborder" dans une autre table.
  Ce qui en soit et aussi suspect et laisse supposer une mauvaise décompostion.
• Soit c'est une erreur pure et simple.

A+

[Jiben59]

Bonsoir marot_r,

tout d'abord je te remercie pour ta réponse.

Je vais essayer de redescendre les points avec toi.

À mon avis tu devrais avoir soit :

T_Journal
CodeJnl

T_SousJournal
CodeSousJnl
CodeJnl

• en jointure avec T_Journal sur CodeJnl
• en jointure avec T_Mouvement sur CodeJnl et CodeSousJnl

soit

T_Journal
CodeJnl

• en jointure avec T_Mouvement sur CodeJnl

T_SousJournal

• CodeSousJnl
• en jointure avec T_Mouvement sur CodeSousJnl

La 1ère structure est plus rigoureuse car tu ne peux assigner qu'un sous-journal associé à un journal donné.
La 2nde permet toutes les combinaisons entre journal et sous-journal.

Je trouve ta première proposition assez correcte à exploiter, mais par contre pourquoi je dois enlever à chacun les noms des journaux et des sous-journaux ?
Ou alors tu me montres les solutions seulement avec les clés primaires pour éviter de marquer tous les champs à chaque fois ?

Aussi j'aurai fait :

T_Banques
RefBanque

T_Titulaires
RefTitutlaires

T_Comptes
RefCompte
RefBanque
RefTitulaire

• En jointure avec T_Banques
• En jointure avec T_Titulaires

Car à priori, on est pas titulaire d'une banque mais d'un compte dans une banque.

J'étais parti du principe qu'un titulaire peut avoir une ou plusieurs banques, et on peut avoir un ou plusieurs comptes au sein d'une banque.

Donc, d'après toi il faut enlever le lien entre la banque et le titulaire et réunir les deux directement dans la table "T_Comptes" ?

Pour info, une relation entre tables de type 1 à 1 est toujours suspecte.

• Soit tout devrait être dans une seule table.
  Si tu as pour tout enregistrement dans une table un et un seul enregistrement dans une autre table, pourquoi les séparer ?
• Soit tu a vraiment beaucoup de champs et tu dois "déborder" dans une autre table.
  Ce qui en soit et aussi suspect et laisse supposer une mauvaise décompostion.
• Soit c'est une erreur pure et simple.

Je te remercie car je n'avais jamais remarqué de 1 à 1, car on préconise toujours le 1 à l'infini par fiabilité.
Il falloir résoudre ce problème alors.


En tout cas, je te remercie pour ton aide marot_r.

Dans l'attente de te lire, bonne soirée à toi.

Bien cordialement,
Benjamin.

[marot_r]

Bonjour.

Ou alors tu me montres les solutions seulement avec les clés primaires pour éviter de marquer tous les champs à chaque fois ?

Oui, il s'agit des champs qui doivent minimalement être présents.
Les autres, je suis sur que tu peux les ajouter par toi-même :-).

J'étais parti du principe qu'un titulaire peut avoir une ou plusieurs banques, et on peut avoir un ou plusieurs comptes au sein d'une banque.
Donc, d'après toi il faut enlever le lien entre la banque et le titulaire et réunir les deux directement dans la table "T_Comptes" ?

Disons que je trouve la solution plus simple et plus souple.
Le défaut de ma solution est le même que pour les journaux.
Elle autorise toutes les combinaisons possibles et tu pourrais donc assigner un numéro de compte à une banque qui n'est pas la bonnne.

Stricto sensu tu as raison, une personne peut être cliente de une ou plusieurs banques et avoir un ou plusieurs comptes dans cette banque.
C'est le terme titulaire qui m'a mellé.

Mais là avec la modélisation que tu as choisie, tu associes le compte à la banque mais tu n'as aucun moyen de savoir à quel client ce compte appartient à moins de n'avoir jamais qu'un seul client par banque.

Si tu veux avoir cette structure il faut faire quelque chose comme :

T_Banques
RefBanque

T_BanqueCompte Une banque peut avoir plusieurs comptes
RefBanqueCompte
RefBanque
RefCompte

T_PersonneBanqueCompte Une personne peut avoir plusieurs comptes dans une banque et un compte dans une banque peut avoir plusieurs personnes.
RefPersonneBanqueCompte
RefBanqueCompte
RefPersonne

Avec cette structure tu ne peux assigner à une personne qu'un compte qui existe vraiment dans la banque choisie.

A+

[Jiben59]

Salut marot_r,

j'espère que tu vas bien.

Pour le premier point j'ai effectué ce que tu m'as conseillé :



Par contre, je n'arrive pas à relier le champs "CodeJrnl" directement avec la table "T_Mouvement" comme tu me préconise :



Je vais regarder pour ton aider pour la banque.
Par cotre, j'arrive à connaître les banques où un titulaire est présent, et les comptes qui détient depuis un formulaire créé pour cela.

Dans l'attente de te lire, bonne journée.

Bien cordialement,
Benjamin.

[marot_r]

Bonjour.

Pour la realtion avec SousJournal,

1. il faut supprimer la relation que tu as déjà créée
2. et sélectionner les 2 champs CodeJnl et CodeSousJnl
3. et les glisser vers ta table des mouvements.

La relation se fait sur les 2 champs et pas seulement un seul.

Pour ton problème de formulaire, je ne sais pas.

Peux-tu poster une copie d'écran de la partie de la fenêtre des relations qui est concerné et aussi du formulaire que tu utilises.

Personnellement, si tu as retenu la solution Banque -> CompteBanque -> PersonneCompteBanque, j'aurai fait :

1. Un formulaire basé sur la table des banques.
2. Un sous-formulaire basé sur la table des CompteBanque
3. un sous-sous-formule (un sous-formulaire dans un sous-formulaire) basé sur la table PersonneCompteBanque.

Mais je ne sais pas ce que toi tu as fais.

A+

[Jiben59]

Merci pour ta réponse marot_r.

Pour la realtion avec SousJournal,

1. il faut supprimer la relation que tu as déjà créée
2. et sélectionner les 2 champs CodeJnl et CodeSousJnl
3. et les glisser vers ta table des mouvements.

La relation se fait sur les 2 champs et pas seulement un seul.

J'ai essayé la procédure, et il m'indique un problème d'index malheureusement :

Peux-tu poster une copie d'écran de la partie de la fenêtre des relations qui est concerné et aussi du formulaire que tu utilises.

Personnellement, si tu as retenu la solution Banque -> CompteBanque -> PersonneCompteBanque, j'aurai fait :

1. Un formulaire basé sur la table des banques.
2. Un sous-formulaire basé sur la table des CompteBanque
3. un sous-sous-formule (un sous-formulaire dans un sous-formulaire) basé sur la table PersonneCompteBanque.

Pour l'instant je n'ai pas encore modifié le relationnel à ce niveau, car j'avais déjà crée un formulaire de cette manière :

Donc, je ne vois pas concrètement ce qui change entre les deux solutions.

Merci pour ton aide en tout cas.

Bien cordialement,
Benjamin.

[marot_r]

Désolé j'ai oublié

Pour la relation, il faut définir un index unique sur CodeJnl et CodeSousJnl dans la table SousJournal.

1. Pour se faire, tu ouvres ta table en modification.
2. Tu cliques sur le bouton des indexes (celui avec l'éclair).
3. Tu te mets sur une ligne vierge et tu mest un nom dans la 1ère colonne (ex : unicite)
4. Dans la 2ième colonne colonne, tu choisi CodeJnl
5. En bas en dessous de la liste des champs tu coches "Unique"
6. Tu te mets sur la 1ère ligne juste en dessous du nom et tu sélectionnes CodeSousJnl dans la 3i:eme colonne.
7. Tu fermes la fenêtre des indexes et tu sauvegardes.

Tu viens de définir un index unique composé.

Donc, je ne vois pas concrètement ce qui change entre les deux solutions.

Si tu as gardé ta 1ère solution pour les banques, elle est fausse de toute façon.

Après quelle solution veux-tu implanter ?

1. La solution avec l'association de la banque à son compte puis à une personne ?
2. ou l'association d'une banque, d'un compte et d'une personne ?

A+

[Jiben59]

[*]Tu te mets sur la 1ère ligne juste en dessous du nom et tu sélectionnes CodeSousJnl dans la 3i:eme colonne.

Marot_r, je ne comprends pas quand tu m'indiques "dans la 3éme colonnes", car la troisième est une colonne de tri.

Si tu as gardé ta 1ère solution pour les banques, elle est fausse de toute façon.

Après quelle solution veux-tu implanter ?

1. La solution avec l'association de la banque à son compte puis à une personne ?
2. ou l'association d'une banque, d'un compte et d'une personne ?

A+

Je n'ai pas envie d'opter pour la premiere car tu m'as indiqué qu'elle manquait de rigueur.

Donc j'éi opté pour la deuxiéme :

T_Banques
RefBanque (1)

T_BanqueCompte Une banque peut avoir plusieurs comptes
RefBanqueCompte (2)
RefBanque (1)
RefCompte : Pourquoi on ajoute une deuxième référence de compte ? Car le (2) définis déjà un compte ?

T_PersonneBanqueCompte Une personne peut avoir plusieurs comptes dans une banque et un compte dans une banque peut avoir plusieurs personnes.
RefPersonneBanqueCompte
RefBanqueCompte (2)
RefPersonne

Avec cette structure tu ne peux assigner à une personne qu'un compte qui existe vraiment dans la banque choisie.

Mais j'ai du pas mal à comprendre la T_PersonneBanqueCompte, car tu indiques qu'un compte dans une banque peut avoir plusieurs personnes, et juste en dessous l'inverse.
Car pour moi une personne peut avoir plusieurs comptes dans une banque, et un compte dans une banque peut avoir qu'une personne.
Car une personne peut être un compte individuel ou un compte commun.


Je te remercie pour tes explications et ton aide en tout cas.

Dans l'attente de te lire, bonne journée.

Bien cordialement,
Benjamin.

[marot_r]

Désolé pour la 3ième colonne, c'est une erreur. Il s'agit de la 2ième colonne, la colonne des champs.

T_BanqueCompte Une banque peut avoir plusieurs comptes
RefBanqueCompte (2)
RefBanque (1)
RefCompte : Pourquoi on ajoute une deuxième référence de compte ? Car le (2) définis déjà un compte ?

Ce n'est pas indispensable mais c'est une habitude que j'ai.
Je mets toujours une clef autonum dans mes tables.
Je m'en sert ou pas mais elle est là au cas où j'en aurai besoin un jour.

Selon moi, une personne ne peut pas être un compte.
Elle peut être titulaire d'un compte individuel ou un compte commun.
Dans le cas d'un compte commun elle est titulaire du compte avec d'autre personne.
Donc on a quelque chose comme :

BanqueA, CompteB, PesronneC 'compte individuel
BanqueA, CompteC, PesronneC 'compte commun
BanqueA, CompteC, PesronneD 'compte commun

et on peut avoir au niveau du compte un indicateur du type EstCommun Oui/Non.
Sinon, on peut aussi dire que tous les comptes qui ont plus d'un titulaire sont communs.
L'indiacteur au niveau du compte peut permettre d'éviter d'assigner plusieurs personne à un compte individuel.
Pas au niveau des données mais par code dans les formulaires.

Tu pourrais aussi décider que tu te moques complétement de savoir qui est titulaire du compte et ne pas décendre au niveau personne.

Tu aurais alors quelque chose comme

RefBanqueCompte (2)
RefBanque (1)
RefCompte
IntituleCompte

Ce qui pourrait être suffisant si tu n'es pas la banque.

A+

[Jiben59]

Salut marot_r,

j’espère que tu vas bien.

Désolé pour la 3ième colonne, c'est une erreur. Il s'agit de la 2ième colonne, la colonne des champs.

Je te remercie pour la précision, et pas besoin de s'excuser.

Par contre j'ai toujours le problème au niveau du message d'erreur sur l'index.

Voici ce que j’ai renseigné en index :

Ce n'est pas indispensable mais c'est une habitude que j'ai.
Je mets toujours une clef autonum dans mes tables.
Je m'en sert ou pas mais elle est là au cas où j'en aurai besoin un jour.

Sauf erreur de ma part, une clé autonum on peut l'ajouter quand on veut et ceci ne provoque pas de problème logiquement ?
Car dans mes autres tables j'en ai pas obligatoirement.

Selon moi, une personne ne peut pas être un compte.
Elle peut être titulaire d'un compte individuel ou un compte commun.
Dans le cas d'un compte commun elle est titulaire du compte avec d'autre personne.

Il faut savoir que le nom titulaire correspond à M XX ou M XX et Mme XX.
Car je gère ce compte bancaire avec ma compagne. Donc il ne peut avoir que 2 personnes dans le maximum logiquement.
Mais personnellement je possède quatre comptes et ma compagne 2.
Et obtenir le nom me permet de le voir directement sur mon tableaux de bord. Car on a le même compte dans la même banque.


Je vous remercie pour votre aide.

Bien cordialement,
Benjamin.

[marot_r]

Bonjour.

Pour l'index unicite il doit comporter 2 champs or là tu n'en as défini qu'un.
Ça ressemble à cela :

Unicite	CodeJnl
	CodeSSJnl
Unique : oui

Pour l'autonum, tu as raison mais je développe pour des entreprises et moins j'ai à toucher une base de production pour faire des modifs à sa structure mieux je me porte donc je le mets systématiquement. Cela ne prends pratiquement pas de place et accessoirment cela permet de savoir dans quel ordre les données ont été remplis ce qui est parfois utile. De plus d'après Microsoft cela améliore les performances mais sincèrement je n'ai jamais vu de différences.

Pour les personnes, je te laisse chosir.
Avec si peu de cas, la solution légère me paraît la meilleure car il y a très peu de chance d'erreur et au pire si tu en trouves tu corriges mais tu peux être plus rigoureux. C'est ton appli, c'est toi qui t'en sert donc au final c'est toi qui décide.

A+

[Jiben59]

Bonjour.

Pour l'index unicite il doit comporter 2 champs or là tu n'en as défini qu'un.
Ça ressemble à cela :

Unicite	CodeJnl
	CodeSSJnl
Unique : oui

Pour l'autonum, tu as raison mais je développe pour des entreprises et moins j'ai à toucher une base de production pour faire des modifs à sa structure mieux je me porte donc je le mets systématiquement. Cela ne prends pratiquement pas de place et accessoirment cela permet de savoir dans quel ordre les données ont été remplis ce qui est parfois utile. De plus d'après Microsoft cela améliore les performances mais sincèrement je n'ai jamais vu de différences.

Pour les personnes, je te laisse chosir.
Avec si peu de cas, la solution légère me paraît la meilleure car il y a très peu de chance d'erreur et au pire si tu en trouves tu corriges mais tu peux être plus rigoureux. C'est ton appli, c'est toi qui t'en sert donc au final c'est toi qui décide.

A+

Bonsoir marot_r,

je te remercie pour ta réponse une nouvelle fois.

J'avais une petite question, d'habitude je coche toujours la case "appliquer l'intégrité référentielle", et cette fois-ci, je ne peux plus le faire, tu en penses quoi ? Ceci n'est pas risqué pour la suite ?


Encore merci pour ton aide.

Bien cordialement,
Benjamin.

[marot_r]

Bonjour.

Oui moi aussi j'active systématiquement l'intégrité référentielle.

Le problème vient probablement des données. Comme tu combines 2 champs, il y a sans doute une combinaison qui n'est pas dans ta table des sous-journaux.

Et les relations doivent être `:

tblJournal -> tblSousJournal -> blMouvement

pas de liaison directe entre tblJournal et tblMouvement.

A+

[Jiben59]

Bonjour.

Oui moi aussi j'active systématiquement l'intégrité référentielle.

Le problème vient probablement des données. Comme tu combines 2 champs, il y a sans doute une combinaison qui n'est pas dans ta table des sous-journaux.

Et les relations doivent être `:

tblJournal -> tblSousJournal -> blMouvement

pas de liaison directe entre tblJournal et tblMouvement.

A+

Pourtant dans ma table T_Mouvements, j'appelle mes champs CodeJrnl et CodeSsJrnl depuis la table T_SousJournal.
Et mon CodeJrnl de la table T_SousJournal Provient de la table T_Journal.

J'ai l'impression que tout est relié ensemble.
Est-ce qu'un code VBA peut bloquer une intégrité ?

Bien cordialement,
Benjamin.

[marot_r]

Bonjour.

J'ai l'impression que tout est relié ensemble.

Oui tout est relié ensemble.
Si tu as déjà des données il se peut que tu ais une association Journal-SousJanal qui n'est pas définie dans la table des sous-journaux.
Si ta table des mouvements est vide alors il y a un problème ailleurs.

Donc attention, il faut que les données soient du même type des 2 bords.
Ex :

• Texte - Texte
• AutoNum - Entier long (oui je sais a priori ce n'est pas le même type mais les autonum sont des entiers long en interne)

Est-ce qu'un code VBA peut bloquer une intégrité ?

Non pas vraiment.
Le VBA s'exécute seulement quand on le lui demande (par exemple quand l'utilisateur appuis sur un bouton ou si un événement se produit dans un formulaire ou un rapport) sinon il est totalement inactif.

A+