Discussion :

[seabs]

Bonjour,

Depuis quelque temps, des amis qui sont trésoriers dans des associations me demandent de leur établir une comptabilité simple pour permettre de présenter les comptes et établir les documents de synthèse pour la fin de l’exercice. Certes, il existe des produits sur le marché, mais les associations ou clubs de sports, avec des moyens de plus en plus limités, sont de l’obligation de réaliser des économies sur tous les tableaux.
Pour cette raison, j’ai décidé de répondre favorable à leur demande. Mon objectif reste local et mon intention n’est nullement de le mettre à disposition de tiers inconnus.

Cette technique n’étant pas incluse dans mon métier de base, mais simplement une passion pour certaines choses techniques utiles. Mon dernier*MCD important remonte à quelques années, d’où ma crainte d’oublier un point important avec des conséquences ultérieures difficiles à régulariser.

Voici le résumé de mon approche.

Ma première étape est la rédaction d’un MCD pour rédiger la base de données adaptée à l’objectif fixé. Vous trouvez ci-dessous le schéma qui a été développé avec Looping.



Les règles de gestion que j’ai rédigées ne sont peut-être pas rigoureusement dans les règles de l’art, mais elles doivent permettre de comprendre les choix faits dans la rédaction du MCD. Pour certaines lignes, je fournis des explications complémentaires pour vous aider dans l’analyse des solutions retenues.

Règles de gestion

Identification du dossier
I01 Permettre de créer plusieurs dossiers
I02 Distinguer les particuliers des associations pour l’identification
I03 Le code SIRET et APE n’existe pas pour les particuliers, sauf s’il s’agit d’autoentrepreneurs 1)

Définition des exercices
E01 Un dossier peut comporter un ou plusieurs exercices
E02 La présence de deux exercices dans la même année est rare, mais cela peut arriver pour des raisons diverses. Mise en place du mois et de l’année pour identifier l’exercice 2)
E03 Date de début et date de fin d’exercice doivent être connues

Présentation des journaux
J01 Il existe plusieurs types de journaux (Trésorerie, OD, Achats, Ventes, etc.)
J02 Les journaux d’achats ou de ventes doivent permettre de présenter la TVA sur les factures
Par contre, les particuliers et certains autoentrepreneurs n’ont aucune obligation de TVA 3)

Plan comptable
P01 Un dossier comporte obligatoirement un plan comptable
P02 Un plan comptable ne peut pas être commun, il doit être attaché à un seul dossier
P03 Un numéro de plan créé et affecté ne peut plus être supprimé, même dans la situation de remise à zéro 4)
P04 Sur un exercice suivant, le numéro du plan, si non utilisé, peut être neutralisé. Il restera dans le plan comptable, mais ne sera plus présenté dans la liste affectable. 5)
P05 Le numéro de plan doit être unique, d’où une utilisation comme index. 6)
P06 Chaque ligne du plan comptable est attachée à une sous-classe, laquelle sous-classe dépend d’une classe.
P07 Chaque ligne du plan sera rattachée à la ligne des états (bilan et compte de résultat). Dans l’immédiat, la mise en place des états n’est pas prévue dans ce MCD. En attendant l’évolution, le sigle NAF sera inclus (non affecté).

Schéma des écritures
E01 Les écritures doivent être attachées à un journal et à numéro de plan comptable
E02 Certaines écritures nécessitent de connaître les quantités. Cependant, cette possibilité n’est pas nécessaire pour toutes les lignes d’écriture.
E03 Il est obligatoire de savoir si l’écriture saisie est un débit ou un crédit. Exemple*: D pour débit et C pour crédit.
E04 Les comptes*40 fournisseurs et 41*clients et autres tiers, il doit être possible de procéder à un lettrage des écritures. Le but est de démontrer que le total des débits et le total des crédits marqués en lettrage donnent un solde zéro et que l’écriture est soldée.
Le lettrage peut faire l’objet d’une entité séparée. Ce n’est pas le choix utilisée. 7)
E05 Pour les journaux mentionnés avec TVA (Achats et Ventes), il doit être possible de saisir le montant de la TVA et son taux. Cette approche pourra conduire à saisir plusieurs lignes pour une même facture, si celle-ci comporte plusieurs taux (voir note complémentaire ci-dessous).
Il est possible de mettre en place une centralisation de la TVA (option retenue dans le MCD).
E06 La saisie des quantités est parfois utile, mais pas dans tous les journaux. En réalité, cela dépend du contexte de l’environnement individuel ou association. Il est possible de répéter l’approche de la TVA, mais ce n’est pas celle retenue dans l’immédiat.
E07 Les quantités saisies doivent être qualifiées pour permettre une interprétation objective (kg, L, m2, etc.)
Comptabilisation TVA dans les écritures
Il existe deux méthodes (voir plus) pour comptabiliser la TVA dans un journal d’achats ou un journal de ventes.



Les points qui sont inclus dans les règles de gestion et qui nécessitent une information complémentaire.

1) Il serait possible de créer une entité séparée pour enregistrer le SIRET et APE, sachant qu’un particulier ne possède pas cette immatriculation.

2) Il me semble que la date du début de l’exercice serait suffisante pour assurer son identification, d’où une simplification de cette entité. Votre avis me permettra de prendre la décision définitive.

3) Pour la TVA, il peut exister des approches différentes, d’où l’idée de prévoir une option si le journal doit ou ne doit pas enregistrer la TVA*;

4) Un numéro du plan comptable, au niveau détail, peut être supprimé seulement, s’il n’a jamais enregistré un montant. Pour traiter correctement cette possibilité, me dire si je dois prévoir une ligne complémentaire dans mon MCD (numéro déjà utilisé et coché avec un booléen).

5) Il est possible qu’un numéro créé au cours d’un exercice ne soit plus utilisé ultérieurement. Cependant, et compte tenu de la remarque au 4, il existera toujours dans le plan comptable. La mise en place d’une neutralisation interdisant l’affichage me semble plus que nécessaire, mais elle est obligatoire.

6) La ligne de plan comptable unique est imposée, d’où son utilisation comme index. À long terme, ce choix présente le risque d’être modifié et rendre la correction dans la base quasi impossible. Il me semble qu’une réorganisation générale du plan comptable rendra caduc les logiciels de comptabilité existants (merci de votre avis).

7) Le lettrage des écritures concernant les clients et les fournisseurs est obligatoirement pour permettre une utilisation plus agréable. Cependant, ce lettrage n’est pas nécessaire pour toutes les écritures. Il serait préférable d’ajouter une entité pour traiter ce point (merci de me donner votre sentiment).

D'avance merci pour votre aide.
Amicalement.

[fsmrel]

Bonjour seabs,

Je répondrai par bribes, car mon pc est bien vieux et s’arrête au bout de 5 minutes....

Bel effort de communication de votre part.

Il serait possible de créer une entité séparée pour enregistrer le SIRET et APE, sachant qu’un particulier ne possède pas cette immatriculation.

Pour les auto-entrepreneurs on pourrait définir un sous-type de Identif_Indiv, doté des attributs SIRET et APE.

 

Il me semble que la date du début de l’exercice serait suffisante pour assurer son identification

L’entité-type Exercice comporte l’identifiant candidat {Exe_Debut, Exe_Fin} ce qui fait que deux dossiers distincts ne peuvent avoir la même valeur pour cet identifiant...

Si pour un exercice donné l’année suffit, autant remplacer Exe_Id par Exe_Debut avec identification relative par rapport à Dossier.

 

Les attributs Exe_An_Debut et Exe_An_Fin sont redondants si leur valeur est celle qu’on trouve dans Exe_Debut.

[fsmrel]

Bonjour seabs,

P06 Chaque ligne du plan comptable est attachée à une sous-classe, laquelle sous-classe dépend d’une classe

Selon vote MCD, c’est le plan comptable lui-même qui dépend d’une sous-classe. Dans ces conditions, il manque une entité-type Plan_Ligne, faisant le lien entre le plan et la sous-classe.

Association Affecter : la patte connectant Dossier et Affecter est porteuse d’une cardinalité o,n, un dossier peut donc comporter plusieurs plans. Remplacer 0,n par 0,1 (en théorie 1,1, mais Looping refuse).

Association Lier : la patte connectant Dossier_Plan et Lier est porteuse d’une cardinalité 1,1(R) : évitez l’identification relative (ou évitez la du côté Affecter) sinon l’identifiant de Dossier_Plan est composé des deux attributs Dos_Id, Pla_Numero.

Avec le modèle conceptuel suivant :

Looping produit le code SQL suivant :

Code SQL :

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

1
2
3
4
5
6
7
8
 CREATE TABLE Dossier_Plan(
   Dos_Id INT,
   Pla_Numero SMALLINT NOT NULL,
   CONSTRAINT Dossier_Plan_PK PRIMARY KEY(Dos_Id),
   CONSTRAINT Dossier_Plan_AK UNIQUE(Pla_Numero),
   CONSTRAINT Dossier_Plan_Dossier_FK FOREIGN KEY(Dos_Id) REFERENCES Dossier(Dos_Id),
   CONSTRAINT Dossier_Plan_Plan_FK FOREIGN KEY(Pla_Numero) REFERENCES Plan(Pla_Numero)
);

A suivre...

[seabs]

Bonjour fsmrel,

Toujours aussi actif et surtout efficace.

"Envoyé par fsmrel
Pour les auto-entrepreneurs on pourrait définir un sous-type de Identif_Indiv, doté des attributs SIRET et APE.

Effectivement, il s’agit pourtant d’une évidence, mais le déclic a été absent au moment de la création.

"Envoyé par fsmrel
L’entité-type Exercice comporte l’identifiant candidat {Exe_Debut, Exe_Fin} ce qui fait que deux dossiers distincts ne peuvent avoir la même valeur pour cet identifiant.
Si, pour un exercice donné l’année suffit, autant remplacer Exe_Id par Exe_Debut avec identification relative par rapport à Dossier.

Après avoir rédigé, je me suis bien rendu compte qu’il était possible de simplifier. J’avais déjà un doute au moment de la rédaction.
Par contre, je ne suis pas certain d’avoir eu le réflexe de l’identification relative

Voici le MCD partiel après les rectifications faites suivant vos recommandations


Pour les remarques faites dans votre réponse d’hier, je vais examiner en détail les corrections à effectuer.

Encore merci pour vos interventions, lesquelles sont toujours très pertinentes.

A plus ...

[fsmrel]

Bonjour,

Dans la mesure où le SIRET ne vaut que pour les associations et les auto-entrepreneurs, on peutt s’orienter vers le MCD suivant garantissant l’unicité du Siret et l’interdiction de NULL :

Le sous-type Dos_Indiv ne vaut que pour les particuliers non auto-entrepreneurs. Le sous-type Dos_Assoc_Auto vaut pour les associations et les auto-entrepreneurs. Le sous-type Dos_Auto permet de connaître le nom et le prénom des auto-entrepreneurs sans qu’on ait à gérer de contrainte particulière concernant ces attributs (présents par ailleurs dans Dos_Indiv).

Entité-type Exercice : A propos de Exe_Fin, comment justifiez-vous la surclé {Exe_Debut, Exe_Fin} ?
Quid si on se contente de la clé {Exe_Debut} ?

Mon pc chauffe, à plus tard...

[seabs]

Bonjour,

"envoyé par fsmrel
Dans la mesure où le SIRET ne vaut que pour les associations et les autoentrepreneurs, on peut s’orienter vers le MCD suivant garantissant l’unicité du Siret et l’interdiction de NULL*:

Remarque très pertinente, j’ai retenu votre solution.

"envoyé par fsmrel
Entité-type Exercice : À propos de Exe_Fin, comment justifiez-vous la surclé {Exe_Debut, Exe_Fin}*?
Quid si on se contente de la clé {Exe_Debut}*?

Uniquement la date début pourrait-être une solution, mais, dans ce cas, il serait d’inclure un trigger ou autre. Je vais expliquer ma démarche et les raisons.
En principe, un exercice est de 12 mois, mais une disposition de l’entreprise peut le réduire ou l’allonger. En général, il n’est possible d’avoir ouvert, dans la base, que deux exercices.
L’exercice passé N-1,
L’exercice en cours N.
Il est donc nécessaire de connaître la limite maximum afin de ne pas enregistrer une écriture au-delà de la fin d’exercice. Il serait donc possible d’inclure dans l’entité exercice le nombre de mois pour déterminer la limite. Oui mais voilà, il y a des personnes compliquées. Dans ma carrière, j’ai vu une entreprise dont la date de clôture était le 1er novembre de chaque année. Le nombre de mois n’est plus opérationnel. C’est pour cette raison que la date de fin d’exercice me paraît une bonne solution qui assure la couverture de toutes les options. Exemple : clôture au 15 octobre de chaque année.
Voilà ma réflexion.

À plus pour tes remarques d’hier.
Merci pour ton aide

[fsmrel]

Bonsoir,

Uniquement la date début pourrait-être une solution

Je n’ai parlé de l’évacuation de la date de fin que dans la clé, elle reste présente en tant qu’attribut dans l’entité-type Exercice, cf. ma 1ère réponse :

Nihil obstat ?

--------------------------------
A propos du lettrage.

Plusieurs scénarios sont possibles.

Pour les écritures à lettrer, je propose de leur dédier un sous-type, même chose pour les écritures lettrantes. Dans le MCD ci-dessous, une écriture peut être lettrée par une seule autre écriture, et une écriture peut en lettrer d’autres. J’ai fait cette hypothèse, mais à vous de rectifier...

Notez l’exclusion (X) dans le sous-typage : une écritr ne peut pas s’auto_lettrer

--------------------------------------

N.B. concernant le sous-typage : attention aux contraintes. Par exemple vous utilisez la contrainte de totalité (T) pour les dossiers, il faut plutôt une contrainte de partitionnement (XT), sinon un dossier peut être à la fois celui d’un particulier et d’une association, etc.

[seabs]

Bonjour,

"

"Envoyé par fsmrel
Je n’ai parlé de l’évacuation de la date de fin que dans la clé, elle reste présente en tant qu’attribut dans l’entité-type Exercice, cf. ma 1ère réponse :

Dans Looping, il me semble ne pas avoir considéré Exe_Fin comme une sur clé. J’ai simplement mentionné que la date de fin d’exercice devait être unique. Pour confirmer mes dires, je vous remets un résumé de la rubrique sous la forme d’image JPEG.



Ma maîtrise de Looping n’étant pas totale, il est possible que mon analyse soit inexacte. En tout état de cause, je suis d’accord avec votre remarque.

Pour le lettrage, je vais examiner votre proposition, car mon approche initiale me paraissait erronée, surtout après la relecture faite après l’envoi de l’approche dans le 1er MCD.

Il me reste également à traiter le plan comptable, j’ai commencé, mais ma réflexion n’est pas terminée.

Bonne journée et à plus…

[seabs]

Bonjour,

Mon avis pour le lettrage

J’ai examiné votre proposition, j’ai quelques difficultés à tester si cela répond à ma demande. Pour cela, il me serait nécessaire de créer des tables provisoires afin de vérifier.

Il faut savoir qu’au niveau du lettrage, nous avons quatre situations, car j’ai exclu les lettrages partiels pour me limiter aux lettrages complets. Certains logiciels du marché effectuent des lettrages partiels. Si les lettrages partiels sont nombreux, nous arrivons rapidement dans un capharnaüm inextricable.

Dans la pratique, nous avons :

1. un paiement pour une facture
2. plusieurs paiements pour une facture
3. un paiement pour plusieurs factures
4. plusieurs paiements pour plusieurs factures (généralement un relevé payé en plusieurs fois)

Pour les comptabilités situées dans l’objectif, il s’agit d’entreprises ou associations modestes avec une activité globale d’environ 200 K€ à 300 K€ annuel. En général, plus 90 % des factures sont payées dans un délai de 8 jours à 30 jours.

En tenant compte des ces éléments, je pensais à quelque chose de plus simple dont je présente ci-après MCD partiel.



Dans mon idée
L’opération de lettrage serait provisoire tant que le solde ne serait pas zéro. Lorsque le solde zéro est atteint, il y aura une validation effectuée, sinon le lettrage sera abandonné. Bien entendu, ce dernier point ne concerne pas le MCD.
En conséquence, sauf erreur de ma part, ce qui est courant, mon schéma semble répondre aux objectifs des comptabilités à traiter.

Merci d'avance pour toutes vos précisions, lesquelles me conduisent à vérifier de nombreux points que j'avais oubliés.

A plus...

[fsmrel]

Hello !

A propos de l’attribut Exe-Fin

Si vous utilisez une contrainte d’unicité pour l’attribut Exe-Fin (cf. l’image que vous proposez pour la rubrique Exe_Fin), observez que Looping produit le code SQL suivant (ce que pour ma part je n’avais pas vérifié, sorry) :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE Exercice(
   Dos_Id INT,
   Exe_Debut DATE,
   Exe_Fin DATE NOT NULL,
   CONSTRAINT Exercice_PK PRIMARY KEY(Dos_Id, Exe_Debut),
   CONSTRAINT Exercice_AK UNIQUE(Exe_Fin),
   CONSTRAINT Exercice_Dossier_FK FOREIGN KEY(Dos_Id) REFERENCES Dossier(Dos_Id)
);

Au vu de la clé primaire {Dos_Id, Exe_Debut}, deux dossiers distincts, d1 et d2 peuvent avoir la même date de début, mais la clé alternative {Exe_Fin} interdit que ces deux dossiers puissent avoir la même date de fin, ce qui est plutôt restrictif. En supprimant cette clé alternative, l’interdiction disparaît, mais il est vrai qu’un dossier donné peut alors comporter deux exercices distincts avec même date de fin.

Force est de constater qu’avec Looping l’identification relative ne joue pas pour les clés alternatives. On soumettra plus tard ce cas à Paprick...

En attendant, comme la règle de gestion est que deux exercices d’un dossier donné ne peuvent pas avoir la mem date de fin, alors il faudra modifier manuellement le code SQL pour la contrainte Exercice_AK, en y remplaçant (Exe_Fin) par (Dos_Id, Exe_Fin).

Le lettrage

Je pensais qu’au moins un paiement (Ecr_Lettrant) servait à lettrer une facture (Ecr_A_Lettrer), mais ces données sont-elles parties prenantes dans les écritures ?

[seabs]

Bonjour,

envoyé par fsmrel
Si vous utilisez une contrainte d’unicité pour l’attribut Exe-Fin (cf. l’image que vous proposez pour la rubrique Exe_Fin), observez que Looping produit le code SQL suivant (ce que, pour ma part je n’avais pas vérifié, sorry)*

Après la lecture de vos remarques sur ce sujet, je me pose plusieurs questions, lesquelles sont sans réponse.

Le principe est le suivant*:

Un dossier peut comporter plusieurs exercices (certes, cela n’est pas un scoop), mais les contraintes sont les suivantes.

La date de début d’un exercice ne peut pas être inférieure à la date de clôture du précédent (exception pour le 1er exercice, mais cela va de soi)
La date de l’exercice suivant est obligatoirement la date de clôture du précédent + un jour.

Exemple*:

• 1er exercice — 01/01/2025 au 31/12/2025
• 2ème exercice — 01/01/2026 au 31/12/2026
• 3ème exercice — 01/01/2027 au 30/09/2027 (Exercice de 9 mois pour l’exemple)
• 4éme exercice — 01/10/2027 au 30/09/2028

etc.

Or, avec la clé primaire (Dos_Id, Exe_Debut), il est possible de donner à un exercice une date de début inférieure à celle de la date de clôture. La modification au niveau de la date de clôture ne va pas corriger la difficulté.

Personnellement, je ne suis pas en mesure de trouver la solution uniquement avec le MCD, j’avais pensé mettre en place un trigger pour gérer ces difficultés.

Maintenant, si vous avez une autre approche, je suis preneur, et ceci, même si cela modifie profondément le MCD en cours.

Le lettrage

Après réflexion, les données de lettrage n’ont rien à voir dans l’entité des écritures. En effet, toutes les écritures ne sont pas concernées par cette opération. Ce traitement concerne uniquement certains comptes, pour ceux-ci, il sera nécessaire d’inclure une marque pour autoriser le rapprochement (lettrage) de certaines écritures liées à ce compte.

Avec tous les points examinés, il existe déjà un important travail de test afin de vérifier la bonne application.

Dans un premier temps, je vais mettre en place la création du dossier, l’identification, la gestion des exercices et la création des journaux.
Puis mise en place de l’entité plan comptable et entité écriture

Je constate que l’absence de pratique, depuis 2 ou 3 ans sur la création de MCD, m’a conduit à quelques oublis pourtant évidents.

Encore merci pour ton aide, je reviendrai lorsque j’aborderai à la seconde partie.
Cordialement

[Paprick]

Bonjour,

Hello !
A propos de l’attribut Exe-Fin
Si vous utilisez une contrainte d’unicité pour l’attribut Exe-Fin (cf. l’image que vous proposez pour la rubrique Exe_Fin), observez que Looping produit le code SQL suivant (ce que pour ma part je n’avais pas vérifié, sorry) :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE Exercice(
   Dos_Id INT,
   Exe_Debut DATE,
   Exe_Fin DATE NOT NULL,
   CONSTRAINT Exercice_PK PRIMARY KEY(Dos_Id, Exe_Debut),
   CONSTRAINT Exercice_AK UNIQUE(Exe_Fin),
   CONSTRAINT Exercice_Dossier_FK FOREIGN KEY(Dos_Id) REFERENCES Dossier(Dos_Id)
);

Au vu de la clé primaire {Dos_Id, Exe_Debut}, deux dossiers distincts, d1 et d2 peuvent avoir la même date de début, mais la clé alternative {Exe_Fin} interdit que ces deux dossiers puissent avoir la même date de fin, ce qui est plutôt restrictif. En supprimant cette clé alternative, l’interdiction disparaît, mais il est vrai qu’un dossier donné peut alors comporter deux exercices distincts avec même date de fin.
Force est de constater qu’avec Looping l’identification relative ne joue pas pour les clés alternatives. On soumettra plus tard ce cas à Paprick...
En attendant, comme la règle de gestion est que deux exercices d’un dossier donné ne peuvent pas avoir la mem date de fin, alors il faudra modifier manuellement le code SQL pour la contrainte Exercice_AK, en y remplaçant (Exe_Fin) par (Dos_Id, Exe_Fin).

Inutile de modifier le code manuellement !
En effet, il est normal qu'en déclarant la rubrique "Exe_Fin" comme UNIQUE, Looping propose une clé alternative en considérant que seule la rubrique est impliquée.
Pour obtenir une AK composée avec (Dos_Id, Exe_Fin), il suffit de déclarer l'index correspondant.

• Tout d'abord, vérifier dans la fenêtre "Propriétés", partie "MLD-LDD", que l'option "Proposer index composé" est à "Oui".
• Dans la déclaration de la rubrique "Exe_Fin", en cochant la case "UNIQUE", une zone "Index" apparait : indiquer le nom de l'index en question ("ExeF" par exemple).
• Ouvrir ensuite la fenêtre du lien 1,n en face le 1,1 ; cocher la case "Clé étrangère dans index" et indiquer le nom du même index ("ExeF" dans mon exemple).

On obtient alors le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE Exercice(
   Dos_Id INT,
   Exe_Debut DATE,
   Exe_Fin DATE NOT NULL,
   CONSTRAINT PK_Exercice PRIMARY KEY(Dos_Id, Exe_Debut),
   CONSTRAINT AK_Exercice_ExeF UNIQUE(Dos_Id, Exe_Fin),
   CONSTRAINT FK_Exercice_Dossier FOREIGN KEY(Dos_Id) REFERENCES Dossier(Dos_Id)
);

Cela te convient François ?

[fsmrel]

Salve !

Force est de constater qu’avec Looping l’identification relative ne joue pas pour les clés alternatives. On soumettra plus tard ce cas à Paprick...

Paprick a magnifiquement répondu, merci à lui !

j’avais pensé mettre en place un trigger pour gérer ces difficultés

Avec SQL on n’y coupe pas…

Avec tous les points examinés, il existe déjà un important travail de test afin de vérifier la bonne application.

Pour le moment on mettra donc le lettrage en sommeil…


Les cycles dans les bases de données

Soit une écriture e1, cette écriture concerne (détermine) le journal j1. Ce journal j1 est inclus (détermine) dans l’exercice x1. Cet exercice x1 détermine le dossier d1. Transitivement, e1 détermine donc d1.

D’autre part cette écriture e1 est attachée (détermine) à un plan p1. Ce plan p1 est lié (détermine) à un dossier d2. Transitivement, e1 détermine d2.

Mathématiquement parlant, e1 peut déterminer d1 et d2, mais dans le cadre de l’application, on doit clairement vérifier l’égalité d1 = d2. Au stade SQL il serait prudent de s’en assurer au moyen d’une contrainte, sous la forme d’un trigger.

La chose est relativement simple avec Tutorial D :

CONSTRAINT C1
JOIN {Dossier, Exercice, Journal, Ecriture, Plan, Dossier_Plan} (Dos_Id) =
JOIN {Dossier, Dossier_Plan, Plan, Ecriture} (Dos_Id) ;

Simplifiable (Plan est ici inutile) :

CONSTRAINT C1
JOIN {Dossier, Exercice, Journal, Ecriture, Dossier_Plan} (Dos_Id) =
JOIN {Dossier_Plan, Ecriture} (Dos_Id) ;


Avec SQL, c’est vous qui voyez

Pour ma part, je commencerai par identifier Exercice relativement à Dossier, Journal relativement à Exercice et Ecriture relativement à Journal. De la sorte, pour chaque écriture je connaîtrai directement son dossier.
Votre opinion ?

[seabs]

Bonjour,

" Envoyé par fsmrel
Pour ma part, je commencerai par identifier Exercice relativement à Dossier, Journal relativement à Exercice et Ecriture relativement à Journal. De la sorte, pour chaque écriture je connaîtrai directement son dossier.

Cette approche me paraît celle à suivre, intuitivement, c’était mon idée.

" Envoyé par fsmrel
La chose est relativement simple avec Tutorial D*:

Là, je dois reconnaître la nécessité absolue de reprendre ton tutoriel du 07/09/2008 mis à jour le 14/07/2011, page*111 pour me rafraîchir la mémoire. Pour tout dire, j’ai tout oublié.

Tout cela va me demander quelques jours, car ctuellement, je mets à jour une application en cours d’utilisation. Après, je me lance dans ce projet.

Encore merci pour ton travail, lequel me permet d’éviter des erreurs grossières et, en même temps, me permet d’effectuer une révision de la modélisation.
Merci également à Paprick pour Looping logiciel pratique et facile à comprendre, mais aussi pour sa réponse pour la clé alternative.

À bientôt...

[fsmrel]

Ave !

Là, je dois reconnaître la nécessité absolue de reprendre ton tutoriel du 07/09/2008 mis à jour le 14/07/2011, page*111 pour me rafraîchir la mémoire. Pour tout dire, j’ai tout oublié.

Même pas grave. J’ai commis l’an dernier un article traitant de Tutorial D, dont je recommande la lecture . Cf. https://www.developpez.net/forums/d2.../#post12092316.

Cet article a bien plu a escartefigue

Bon courage pour la mise à jour en cours