Discussion :

[cadao]

Bonjour,

Dans un MPD, il y a 3 tables
1 table « mère » OPERATIONCOMPTABLE et 2 tables « filles » CREDIT et DEBIT.

Mon DBA dit que

La table CREDIT n’a aucun intérêt en tant que table physique (elle contient 3 colonnes qui sont des clés étrangères). La table DEBIT ne gère physiquement qu’un n° de chèque (elle contient 8 colonnes dont 7 sont des clés étrangères). D’un point de vue fonctionnel, l’opération comptable est forcément un mouvement de crédit ou un mouvement de débit : la gestion d’une opération comptable dans la table OPERATIONCOMPTABLE est forcément associé à la gestion d’un débit dans la table DEBIT ou d’un crédit dans la table CREDIT (donc pas d’existence seule possible de la table OPERATIONCOMPTABLE).

Et il propose

Aucun intérêt à gérer 1 table mère + 2 tables filles (complexité de gestion à gérer plusieurs tables)
Proposition :
solution idéale d’un point de vue modélisation des données dans une base relationnelle (selon moi) : regrouper les spécificités au niveau de la table mère
(1 seule table + ajout d’un indicateur sens de l’opération ; la couche de mapping objet java/élément SQL permet de s’abstraire des données ne concernant pas la sous-classe traitée, DEBIT ou CREDIT)

Je suis tout à fait d'accord avec lui, et vous ?

Merci d'avance de votre contribution.

Cadao

[Richard_35]

Bonjour Cadao,

Intéressante question.

En fait, tout est dans

La table CREDIT .../... contient 3 colonnes qui sont des clés étrangères

et dans

La table DEBIT ne gère physiquement qu’un n° de chèque (elle contient 8 colonnes dont 7 sont des clés étrangères)

qui précise qu'il y a des attributs à stocker différents selon qu'il s'agit d'un débit ou d'un crédit.

Si tout est dans la même table, pour les crédits, tous les attributs concernant les débits seront "nuls" et inversement pour les débits.

Il faudrait étudier la pertinence des attributs de chacun.

[cadao]

Bonjour Richard_35,

Merci votre analyse, voici les trois tables

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
CREATE TABLE OPERATIONCOMPTABLE
(
  VERSION                         NUMBER(6)     DEFAULT 0  NULL,
  ID                              NUMBER(20)    NOT NULL,
  CODEETABLISSEMENT               VARCHAR2(8 BYTE)     NULL,
  DATECREATION                    TIMESTAMP(6)      NULL,
  DATEMODIFICATION                TIMESTAMP(6)      NULL,
  MOISCOMPTABLE                   VARCHAR2(7 BYTE)     NULL,
  MONTANTPARTDISPONIBLE           NUMBER(19,2)      NULL,
  MONTANTPARTPARTIESCIVILES       NUMBER(19,2)      NULL,
  MONTANTPECULELIBERATION         NUMBER(19,2)      NULL,
  MONTANTTOTAL                    NUMBER(19,2)      NULL,
  OBSERVATION                     VARCHAR2(50 BYTE)     NULL,
  COMPTE_OPERATIONSCOMPTABLES_FK  NUMBER(20)        NULL,
  OPERATIONCOMPTABLE_RESERVE_FK   NUMBER(20)        NULL,
  DATESUPPRESSION                 TIMESTAMP(6)      NULL,
  TYPEECRITURE                    VARCHAR2(64 BYTE)     NULL
)
 
CREATE UNIQUE INDEX OPERATIONCOMPTABLE_PK ON OPERATIONCOMPTABLE
(ID)
LOGGING
NOPARALLEL;
 
-------------------------------------------------------------------------
CREATE TABLE CREDIT
(
  CREDIT_OPERATIONCOMPTABLE_FK    NUMBER(20)    NOT NULL,
  LN_MODEVERSEM_MODEVERSEMENT_FK  VARCHAR2(16 BYTE)     NULL,
  CREDIT_CONTREECRITUREDEBIT_FK   NUMBER(20)        NULL
)
 
 
ALTER TABLE CREDIT ADD (
  CONSTRAINT CREDIT_PK
  PRIMARY KEY
  (CREDIT_OPERATIONCOMPTABLE_FK)
  USING INDEX CREDIT_PK);
 
ALTER TABLE CREDIT ADD (
  CONSTRAINT CREDIT_CONTREECRITUREDEBIT_FK 
  FOREIGN KEY (CREDIT_CONTREECRITUREDEBIT_FK) 
  REFERENCES CONTREECRITUREDEBIT (CONTREECRITUREDEBIT_DEBIT_FK),
  CONSTRAINT CREDIT_OPERATIONCOMPTABLE_FK 
  FOREIGN KEY (CREDIT_OPERATIONCOMPTABLE_FK) 
  REFERENCES OPERATIONCOMPTABLE (ID),
  CONSTRAINT LN_MODEVERSEM_MODEVERSEMENT_FK 
  FOREIGN KEY (LN_MODEVERSEM_MODEVERSEMENT_FK) 
  REFERENCES LN_MODEVERSEMENT (CODE));
 
  -------------------------------------------------------------
  CREATE TABLE DEBIT
(
  DEBIT_OPERATIONCOMPTABLE_FK     NUMBER(20)    NOT NULL,
  NUMEROCHEQUE                    VARCHAR2(32 BYTE)     NULL,
  FICHEBENEFICIAIRE_DEBIT_FK      NUMBER(20)        NULL,
  DECLARATION_DEBIT_FK            NUMBER(20)        NULL,
  LN_MODEREGLEM_MODEREGLEMENT_FK  VARCHAR2(16 BYTE)     NULL,
  LN_MODERE_MODEREGLMTCLOTURE_FK  VARCHAR2(16 BYTE)     NULL,
  DEBIT_CONTREECRITURECREDIT_FK   NUMBER(20)        NULL,
  DEBIT_OPERATIONLIVRET_FK        NUMBER(20)        NULL
)
LOGGING 
NOCOMPRESS 
NOCACHE
NOPARALLEL
MONITORING;
 
 
CREATE UNIQUE INDEX DEBIT_PK ON DEBIT
(DEBIT_OPERATIONCOMPTABLE_FK)
LOGGING
NOPARALLEL;
 
 
ALTER TABLE DEBIT ADD (
  CONSTRAINT DEBIT_PK
  PRIMARY KEY
  (DEBIT_OPERATIONCOMPTABLE_FK)
  USING INDEX DEBIT_PK);
 
ALTER TABLE DEBIT ADD (
  CONSTRAINT DEBIT_CONTREECRITURECREDIT_FK 
  FOREIGN KEY (DEBIT_CONTREECRITURECREDIT_FK) 
  REFERENCES CONTREECRITURECREDIT (CONTREECRITURECREDIT_CREDIT_FK),
  CONSTRAINT DEBIT_OPERATIONCOMPTABLE_FK 
  FOREIGN KEY (DEBIT_OPERATIONCOMPTABLE_FK) 
  REFERENCES OPERATIONCOMPTABLE (ID),
  CONSTRAINT DEBIT_OPERATIONLIVRET_FK 
  FOREIGN KEY (DEBIT_OPERATIONLIVRET_FK) 
  REFERENCES OPERATIONLIVRET (ID),
  CONSTRAINT DECLARATION_DEBIT_FK 
  FOREIGN KEY (DECLARATION_DEBIT_FK) 
  REFERENCES DECLARATION (ID),
  CONSTRAINT FICHEBENEFICIAIRE_DEBIT_FK 
  FOREIGN KEY (FICHEBENEFICIAIRE_DEBIT_FK) 
  REFERENCES FICHEBENEFICIAIRE (ID),
  CONSTRAINT LN_MODEREGLEM_MODEREGLEMENT_FK 
  FOREIGN KEY (LN_MODEREGLEM_MODEREGLEMENT_FK) 
  REFERENCES LN_MODEREGLEMENT (CODE),
  CONSTRAINT LN_MODERE_MODEREGLMTCLOTURE_FK 
  FOREIGN KEY (LN_MODERE_MODEREGLMTCLOTURE_FK) 
  REFERENCES LN_MODEREGLEMENTCLOTURE (CODE));

[Richard_35]

D'après ce que je comprends (sauf défaut de reverse engineering mental...) :

Code :

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

1
2
3
OPERATIONCOMPTABLE ---0,1---[être crédit]----1,1--- CREDIT
        |
        --------------0,1---[être débit]-----1,1--- DEBIT

avec :

• OPERATIONCOMPTABLE(ID, ... [attributs communs aux débits et aux crédits])
• CREDIT(#CREDIT_OPERATIONCOMPTABLE, #LN_MODEVERSEM_MODEVERSEMENT,#CREDIT_CONTREECRITUREDEBIT)
• DEBIT(#DEBIT_OPERATIONCOMPTABLE, NUMEROCHEQUE, #FICHEBENEFICIAIRE_DEBIT, #DECLARATION_DEBIT, #LN_MODEREGLEM_MODEREGLEMENT, #LN_MODERE_MODEREGLMTCLOTURE, #DEBIT_CONTREECRITURECREDIT, #DEBIT_OPERATIONLIVRET)

La structure en trois tables me semble justifiée car, comme indiqué précédemment, si les débits et crédits sont dans la même table, alors, pour les crédits, [NUMEROCHEQUE, #FICHEBENEFICIAIRE_DEBIT, #DECLARATION_DEBIT, #LN_MODEREGLEM_MODEREGLEMENT, #LN_MODERE_MODEREGLMTCLOTURE, #DEBIT_CONTREECRITURECREDIT, #DEBIT_OPERATIONLIVRET] seront nuls et, pour les débits, [#LN_MODEVERSEM_MODEVERSEMENT,#CREDIT_CONTREECRITUREDEBIT] seront nuls. Cela prend de la place disque pour rien et, bien pire encore, il y aurait pléthore de "bonhomme null". En conséquence, les requêtes devront tester, sans cesse, tel ou tel champ = null...

[seabs]

Bonjour,

Je ne suis pas un spécialiste de la modélisation, mais je suis d'accord avec ton DBA. En effet, je ne vois pas la nécessité de créer trois entités pour enregistrer une écriture comptable (40 ans d'expérience dans le métier, ça vous marque pour le reste de votre vie).

Personnellement, ma table Ecriture aurait le schéma suivant

Ecriture(EcritId, NoPlanComptable#, EcritDate, EcritNoPiece, EcritLibelle, EcritSens, EcritValeur)

La colonne EcritSens contiendrait 1 si débit et -1 si crédit. Cette approche permet de distinguer, dans les calculs, les valeurs de débit et de crédit. Le calcul se fait simplement par EcritSens * EcritValeur = + / - suivant la situation.

Il n'existe plus de NULL car chaque ligne comptable comprend obligatoirement une somme qui un débit ou un crédit

Bien entendu, cette écriture sera Foreign Key avec le plan comptable.

PlanComptable ---0,n---[Appartenir]----1,1--- Ecriture

Pour un examen plus attentif, il serait bien que tu nous communiques ton MCD, MLD ou MPD plutôt que tes tables

@+

[Richard_35]

Bonjour Seabs,

Je suis d'accord avec toi... dans l'absolu.

Mais, dans le cas qui nous occupe, je n'ai pas compris où tu stockes les champs spécifiques au crédits et ceux spécifiques aux débits (voir posts #3 et #4).

[seabs]

Bonjour,

@Richard

Mais, dans le cas qui nous occupe, je n'ai pas compris où tu stockes les champs spécifiques au crédits et ceux spécifiques aux débits (voir posts #3 et #4).

Toutes le valeurs sont incluses dans la colonne EcritValeur et corrélativement il est mis 1 si un débit ou -1 si un crédit dans la colonne EcritSens.

Ensuite, il suffit de créer une VUE pour reconstituer les débits et les crédits.

Code :

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

1
2
3
4
5
6
SELECT E.EcritId, E.NoPlanComptable, E.EcritDate, E.EcritNoPiece, E.EcritLibelle, 
  CASE WHEN E.EcritSens = 1 THEN E.EcritValeur END AS vDebit,
  CASE WHEN E.EcritSens = -1 THEN E.EcritValeur END AS vCredit
FROM ECRITURE E 
  INNER JOIN PLAN P ON E.NoPlanComptable = P.NoPlanComptable

Lorsqu'il est nécessaire d'effectuer des calculs, dans une REQUETE ou dans une VUE, avec les valeurs enregistrées, nous pouvons écrire :

Code :

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

1
2
   SUM(EcritValeur * EcritSens) as vSolde

Tout ceci fonctionne parfaitement, car déjà tester dans plusieurs applications.

Maintenant, il convient d'adapter ce schéma au cas présenté.

D'ailleurs, à ce sujet, il me semble que les NULL sont possibles dans pratiquement toutes les colonnes. Je pense, que si cela est le cas, il serait peut être nécessaire de vérifier la mise en place d'une valeur par défaut et de supprimer la possibilité du NULL ou plus simplement l'obligation d'entrer une valeur.

Exemple : MOISCOMPTABLE avec possibilité d'inclure un NULL ne me paraît pas très satisfaisant ?

@+

[Richard_35]

Bonjour à toi Seabs (et à Cadao, si toujours présente),

Toutes les valeurs sont incluses dans la colonne EcritValeur .../...

==> par concaténation ?

[seabs]

Bonjour,

Effectivement, Cadao semble ne plus répondre.

@Richard

==> par concaténation ?

Non, aucune concaténation.

Parmi les règles de gestion de la comptabilité, il y a celle-ci :

Une ligne d'écriture ne comporter qu'une seule valeur qui est un débit ou un crédit. Ainsi, aucune écriture ne peut comporter une valeur au débit et une valeur au crédit en simultané.

Si nous reprenons, un livre d'écritures comptables, nous aurons :

Code :

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

1
2
3
4
5
6
    Date        NO Compte      libellé                 Débit            Crédit
15/12/2011       600000        Ecriture n° 1        10 000.00
15/12/2011       601000        Ecriture n° 2         2 500.00
15/12/2011       445660        Ecriture n° 3         2 450.00
15/12/2011       401000        Ecriture n° 4                           14 950.00

Cette présentation est une règle normée dans la présentation comptable.

La traduction, en simplifiant, dans la table des écritures sera :

Code :

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

1
2
3
4
5
6
7
EcritId  NoPlanComptable   EcritDate   EcritLibelle      EcritSens   EcritValeur 

    1          600000      15/12/2011  Ecriture n° 1       1           10 000.00
    2          601000      15/12/2011  Ecriture n° 2       1            2 500.00
    3          445660      15/12/2011  Ecriture n° 3       1            2 450.00
    4          401000      15/12/2011  Ecriture n° 4      -1           14 950.00

Je n'ai donc aucune concaténation à effectuer.

Une comptabilité n'aura jamais, dans l'état actuel du droit comptable, une ligne avec le schéma ci-après

Code :

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

1
2
3
4
5
6
    Date        NO Compte      libellé                 Débit            Crédit
15/12/2011       600000        Ecriture n° 1        12 000.00           2 000.00
15/12/2011       601000        Ecriture n° 2         2 500.00
15/12/2011       445660        Ecriture n° 3         2 450.00
15/12/2011       401000        Ecriture n° 4                           14 950.00

Je pense avoir répondu à tes interrogations.
@+

[Richard_35]

Bonjour Seabs et excellente année 2012,

Oui, oui, entièrement d'accord et je sais tout cela. Mais je ne pense pas que le débat soit sur ce plan.

Je pense avoir répondu à tes interrogations.

==> eh bien, non.

Revoyons la structure des tables DEBIT et CREDIT :

• CREDIT(#CREDIT_OPERATIONCOMPTABLE, #LN_MODEVERSEM_MODEVERSEMENT,#CREDIT_CONTREECRITUREDEBIT)
• DEBIT(#DEBIT_OPERATIONCOMPTABLE, NUMEROCHEQUE, #FICHEBENEFICIAIRE_DEBIT, #DECLARATION_DEBIT, #LN_MODEREGLEM_MODEREGLEMENT, #LN_MODERE_MODEREGLMTCLOTURE, #DEBIT_CONTREECRITURECREDIT, #DEBIT_OPERATIONLIVRET)

Nous voyons que les entités DEBIT et CREDIT ont des attributs propres et, par conséquent, la séparation des tables me semble judicieuse. Certains de ces attributs sont, en plus, des clés étrangères.

En revanche, effectivement, il faut mettre en place un contrôle (trigger) qui empêche l'enregistrement d'un crédit et d'un crédit pour une même opération comptable :

• OPERATIONCOMPTABLE(ID, ... [attributs communs aux débits et aux crédits])

Ce qui respecte ta juste remarque :

Une ligne d'écriture ne comporter qu'une seule valeur qui est un débit ou un crédit. Ainsi, aucune écriture ne peut comporter une valeur au débit et une valeur au crédit en simultané.

[seabs]

Bonjour,

@Richard_35
Je te remercie de tes vœux 2012 et te présente les miens en retour.

En ce qui concerne notre débat, je veux bien tout, mais il me semble que le DBA et Cadao ne soit pas d'accord. Il doit y avoir une raison.

Et il propose

Aucun intérêt à gérer 1 table mère + 2 tables filles (complexité de gestion à gérer plusieurs tables)
Proposition :
solution idéale d’un point de vue modélisation des données dans une base relationnelle (selon moi) : regrouper les spécificités au niveau de la table mère
(1 seule table + ajout d’un indicateur sens de l’opération ; la couche de mapping objet java/élément SQL permet de s’abstraire des données ne concernant pas la sous-classe traitée, DEBIT ou CREDIT)

Je suis tout à fait d'accord avec lui, et vous ?

Comme nous ne connaissons pas les règles de gestion, nos seules informations sur la modélisation s'appuient sur la présentation de tables qui, pour ma part, me paraissent issues d'une modélisation discutable.

Je ne vois pas pourquoi, il existe plus d'informations pour les débits que pour les crédits. Exemple : un bénéficiaire au débit et aucun tiers au crédit ? Et pourtant si nous avons un fournisseur au débit (Paiement), nous aurons un client au crédit (Encaissement).

Les tables ne traitent que les opérations financières, quid des achats, des ventes, des opérations diverses, etc

Notre ami semble ignorer, dans sa modélisation, que la comptabilité s'appuie sur un plan comptable ce qui le conduit, très certainement, vers l'ajout de colonnes.

Tant que nous n'aurons pas l'avis de Cadao, il me semble difficile d'aller plus loin dans notre discussion.

@+

[Richard_35]

Certes (et merci pour tes "retours de voeux").

Il n'empêche qu'au problème posé, et en ne se tenant qu'à cet énoncé, le fait que les crédits et les débits aient leurs propres attributs justifie la présence des deux entités.

Effectivement, la remise en cause de ces attributs propres, et, en final, leur suppression, justifierait une unique entité OPERATIONCOMPTABLE.

[pachot]

Bonjour,

Une opération étant soit un crédit, soit un débit, il faut une table OPERATION qui a un type d'opération Débit ou Crédit.

Je ne connais pas de SGBD où on puisse implémenter ça dans 2 tables de manière performante. Un trigger devrait vérouiller toute la table CREDIT lorsqu'on rentre un DEBIT, pour être sûr que personne n'est en train de rentrer un CREDIT avec le même numéro d'opération.

Il y a des attributs communs qui seront dans OPERATION. Le mode de versement et la FK vers la contre écriture, c'est commun aux 2.

Il a a des attributs spécifiques qu'on peut mettre dans OPERATION et d'autres qu'on peut mettre dans une tables spécifiques DETAIL_DEBIT. Un NULL n'est pas un problème dans un SGBDR. Il peut même avoir une taille nulle. Le choix ne peut se faire qu'en connaissant la manière dont seront interrogées les données. Par exemple, si on demande toutes les opérations qui sont soit des crédits soit des débits en espèce, ce serait dommage d'avoir à faire une jointure. Et puisque ces informations sont toutes des FK vers d'autres tables, dommage de faire une référence vers une référence au lieu d'un lien direct.

Et ce serait DETAIL_DEBIT qui référencerait OPERATION et non l'inverse. Il n'ont sûrement pas le même cycle de vie (purge/archivage des détails tout en gardant l'opération par exemple). DETAIL_DEBIT aurait une contrainte sur la FK vers opération, qui serait aussi sa PK.


L'avis du DBA se base sur ce qui fonctionne bien sur un SGBDR: éviter de multiplier tables, index, jointures inutiles et utiliser les NULL qui sont très bien implémentés. C'est très bien pour un MPD, pour l'implémentation sur un SGBDR.

La théorie relationelle et/ou la modélisation objet peuvent par contre préférer de nombreuses entités, des généralisations/spécialisations, et pas de NULL. C'est très bien pour un MCD, modèle métier. Avoir un héritage qui définit bien les concepts d'opération, d'opération de crédit et d'opération de débit est très utile pour modéliser et discuter tous les interlocuteurs. Pour les comptables, débit et crédit sont 2 choses différentes. Pour d'autres utilisateurs, ce sont toutes des opérations avec un montant positif ou négatif. Le fait d'éclater dans des concepts différents permet de parler aux deux.

Mais le MCD doit au final s'implémenter sur un SGBD et doit être performant, évolutif, scalable, accepter la concurrence d’accès, vérifier l'intégrité des données, etc. Les contraintes sont très bien gérées dans ces contextes (unique, référence, not null, etc.) Ce serait dommage de mettre des triggers qui vérouillent des tables entières pour assurer un intégrité. Ce serait dommage de rajouter une FK et un index pour éviter un null qui prend 0 octets. Et avec une seule table, lorsqu'on va saisir un mouvement en 2 opérations (débit et contre écriture de débit) elles seront ensembles. Dans le même bloc de disque. Dans la même page de cache. Et c'est plutôt bien, vu qu'on va souvent les interroger ensemble. Ce serait dommage d'éclater au niveau physique ce qui va être accédé ensemble. Et puis si on veut au contraire les éclater physiquement, pas besoin de toucher au modèle logique: il suffit de partitionner sur le type d'opération.

Cordialement,
Franck.

[Richard_35]

Bonjour Franck (et excellente année 2012),

Je n'ai pas bien compris.

Une opération étant soit un crédit, soit un débit, il faut une table OPERATION qui a un type d'opération Débit ou Crédit.

==> tu sembles préférer une seule table OPERATION.

Il a a des attributs spécifiques qu'on peut mettre dans OPERATION et d'autres qu'on peut mettre dans une tables spécifiques DETAIL_DEBIT.

==> tu sembles ajouter une table DETAIL_DEBIT qui comporterait les attributs spécifiques aux débits.

A moins que je n'ai rien compris, ce qui est somme toute possible, cela semble contradictoire, non ?

Reprenons le cas de Cadao (si elle est toujours avec nous...) :

Option "une seule table" :

OPERATIONCOMPTABLE(ID, Debit_Credit (D/C), #CREDIT_LN_MODEVERSEM_MODEVERSEMENT,#CREDIT_CONTREECRITUREDEBIT, DEBIT_NUMEROCHEQUE, #FICHEBENEFICIAIRE_DEBIT, #DECLARATION_DEBIT, #DEBIT_LN_MODEREGLEM_MODEREGLEMENT, #DEBIT_LN_MODERE_MODEREGLMTCLOTURE, #DEBIT_CONTREECRITURECREDIT, #DEBIT_OPERATIONLIVRET)

• il faut préfixer (ou suffixer) tous les champs par CREDIT ou DEBIT pour savoir si l'attribut se rapporte à un crédit ou à un débit (ou aucun, pour les attributs communs) ;
• il y a redondance d'information entre le flag Debit_Credit et le "remplissage" des attributs propres à ces deux écritures. A moins de supprimer ce flag et de tester le sens (+/-) du montant de l'écriture ;
• dans le code, il faut penser à initialiser tous les champs DEBIT, s'il s'agit d'un CREDIT et initialiser tous les champs CREDIT, s'il s'agit d'un DEBIT ;
• faire attention aux futurs ajouts de champs ;
• malgré tout, il y a une certaine quantité de champs qui resteront NULL suivant le sens de l'écriture.

Option "trois tables" :

OPERATIONCOMPTABLE(ID, ... [attributs communs aux débits et aux crédits])
CREDIT(#CREDIT_OPERATIONCOMPTABLE, #LN_MODEVERSEM_MODEVERSEMENT,#CREDIT_CONTREECRITUREDEBIT)
DEBIT(#DEBIT_OPERATIONCOMPTABLE, NUMEROCHEQUE, #FICHEBENEFICIAIRE_DEBIT, #DECLARATION_DEBIT, #LN_MODEREGLEM_MODEREGLEMENT, #LN_MODERE_MODEREGLMTCLOTURE, #DEBIT_CONTREECRITURECREDIT, #DEBIT_OPERATIONLIVRET)

• il faut prévoir un trigger qui empêche l'enregistrement d'un crédit et d'un crédit débit pour une même opération comptable ;
• il faut verrouiller l'opération comptable pour éviter d'entrer dans une saisie de crédit pendant qu'un autre utilisateur saisit un débit (et inversement.

Conceptuellement, l'option "trois tables" me semble plus judicieuse et plus facile à maintenir. Mais, les deux solutions fonctionneront, en final.

[CinePhil]

Un NULL n'est pas un problème dans un SGBDR.
L'avis du DBA se base sur ce qui fonctionne bien sur un SGBDR: éviter de multiplier tables, index, jointures inutiles et utiliser les NULL qui sont très bien implémentés.

Si fsmrel passe par là, il va sortir son rasoir et sa sulfateuse !

il faut prévoir un trigger qui empêche l'enregistrement d'un crédit et d'un crédit pour une même opération comptable ;

Puisque la table CREDIT hériterait de la table OPERATION_COMPTABLE, sa clé primaire serait également une clé étrangère référençant l'opération comptable. Impossible alors de référencer deux fois la même opération.

il faut verrouiller l'opération comptable pour éviter d'entrer dans une saisie de crédit pendant qu'un autre utilisateur saisit un débit (et inversement.

Pourquoi ?
Le processus qui crée le crédit ou le débit crée en même temps l'opération grâce à un trigger, ou bien le processus qui crée l'opération récupère son identifiant pour ensuite l'affecter à la création du crédit ou du débit correspondant.

Dans les deux cas, puisqu'il qu'il y a héritage de l'opération, il faut créer l'opération en premier et une fois qu'elle est créée, aucun problème pour qu'une autre soit créée.

[pachot]

Bonjour Richard,

En fait je ne comparais pas les 2 options 1 table ou 3 tables. je montrais seulement les questions à se poser pour modéliser.

Il me paraît évident d'avoir une table OPERATIONCOMPTABLE.
Il est par contre possible d'avoir certaines colonnes spécifiques dans une autre table.

J'en profite pour commenter les remarques. Ce n'est pas pour critiquer point par point, mais pour vérifier que le modèle proposé tient la route.

Option "une seule table" :

il faut préfixer (ou suffixer) tous les champs par CREDIT ou DEBIT pour savoir si l'attribut se rapporte à un crédit ou à un débit (ou aucun, pour les attributs communs) ;

Pas nécessairement. Le nom de l'attribut peut être générique même s'il n'est utilisé que dans un cas. Un numéro de chèque est un numéro de chèque. On le renseigne que pour les débits si l'on veut, mais ça reste un numéro de chèque.
CREDIT_CONTREECRITUREDEBIT et DEBIT_CONTREECRITURECREDIT ce sont des pléonasmes. La contre écriture d'un débit est toujours un crédit et inversement. L'attribut d'une opération, c'est juste CONTREECRITURE
Idem pour CREDIT_LN_MODEVERSEM_MODEVERSEMENT et DEBIT_LN_MODEREGLEM_MODEREGLEMENT. Toute opération a un mode de paiement. C'est une colonne commune MODE_PAIEMENT.

Et une subtilité pour faire en sorte que la contre écriture d'un débit ne puisse pas être un débit: le type d'opération (D/C) devrait faire partie de la clé de OPERATIONCOMPTABLE. Donc la FK vers la contre écriture, c'est (CONTREECRITURE_TYPE,CONTREECRITURE_ID) et on a une contrainte du genre CHECK ( TYPE <> CONTREECRITURE_TYPE )

il y a redondance d'information entre le flag Debit_Credit et le "remplissage" des attributs propres à ces deux écritures.

Pour moi c'est indispensable d'avoir cette redondance. Sur le flag, on peut partitionner, indexer, référencer, avoir des histogrammes, etc. Pas sur le "remplissage" sauf peut-être avec des virtual columns. Je ne vois pas d'inconvénient à cette redondance:
- 2 octets de stockage pour gagner beaucoup en performance et lisibilité.
- pas d'erreur avec une contrainte d'intégrité qui vérifie que le type et le remplissage sont compatibles.

dans le code, il faut penser à initialiser tous les champs DEBIT, s'il s'agit d'un CREDIT et initialiser tous les champs CREDIT, s'il s'agit d'un DEBIT ;

Contrainte d'intégrité. Au lieu de IS NOT NULL c'est TYPE = CASE when champ_debit is null and champ_credit is not null THEN 'C' ELSE ...

malgré tout, il y a une certaine quantité de champs qui resteront NULL suivant le sens de l'écriture.

Et ? Quel problème cela post-t-il ?
En plus, ici, je pense qu'il n'y a que le crédit qui peut avoir des infos nulles. On les met à la fin et c'est zéro octets.

Option "trois tables" :

il faut prévoir un trigger qui empêche l'enregistrement d'un crédit et d'un crédit pour une même opération comptable ;il faut verrouiller l'opération comptable pour éviter d'entrer dans une saisie de crédit pendant qu'un autre utilisateur saisit un débit (et inversement.

Exact, avec 3 tables la table OPERATION peut porter le verrou au niveau enregistrement. et on peut faire ça par trigger.
C'est quand même plus couteux: chaque insertion va mettre à jour 2 tables, verrouiller 2 enregistrements et maintenir au minimum 2 indexes. 2 fois plus de travail, c'est des temps de réponse 2 fois plus longs. Sur une saisie, on ne le voit pas. Mais sur 100 utilisateurs concurrents, ou sur un batch d'import, c'est plus gênant.

Lorsque je parlais de l'impossibilité de gérer l'intégrité par trigger, je pensais à une solution "2 tables: CREDIT et DEBIT". Cette solution pourrait tenir la route mais impossible de gérer un numéro d'opération unique sur les 2 tables.

Cordialement,
Franck.

[cadao]

Bonjour le groupe,

Tout d'abord, je vous présente tous mes voeux pour l'année 2012 et que la paix et la joie soient avec vous ainsi que votre chère famille.

Etant absente et revenue seulement hier, j'ai pu parlé avec le DBA, l'architecte, à propos de ce sujet, voici la conclusion :

En fait, dans le cadre de ce projet, il en faut une table opération comptable et 2 table filles CREDIT et DEBIT, car pour chaque de ces entités, il y a ses propres opérations, par exemple

CREDIT -> MODE VERSEMENT
-> ECRITURE CREDIT
DEBIT -> MODE REGLEMENT
-> DECLARATION


Voilà, encore une fois, je tiens à vous remercie, grâce à vous, ma connaissance en matière de conception est (sera) enrichie.

CaDao

[fsmrel]

Bonsoir,


Dans cette affaire, les différentes positions sont légitimes, ô combien...

Notamment la position de seabs du fait de son approche unificatrice et imparable :

Ecriture (EcritId, NoPlanComptable#, EcritDate, EcritNoPiece, EcritLibelle, EcritSens, EcritValeur)

Notamment, la position de Richard quand à son refus de mettre tous les œufs dans le même panier (un numéro de chèque, une fiche bénéficiaire ne concernent que les débits, etc.) et sa volonté de faire la chasse au bonhomme Null qui est le grand inhibiteur des optimiseurs des SGBD.

Pourquoi ne pas procéder à l'union des points de vue ? Dans le diagramme ci-dessous, la vision seabsienne est prise en compte au sein de l’en-tête de la table OPERATION_COMPTABLE, tandis que les spécificités chères à Richard font l’objet de tables dédiées (je n’ai pas tout fait figurer, d’où les pointillés, car il y a bien des indéterminations dans le système proposé par cadao) :




Vous noterez, cadao, que Null est banni systématiquement et il y a là un défi que vous avez à relever quant à la structure de vos propres tables...

Vos opinions sur ce début de représentation alternative ?

[pachot]

Bonsoir,

et sa volonté de faire la chasse au bonhomme Null qui est le grand inhibiteur des optimiseurs des SGBD.

Je ne comprends pas. Quel problème concret sur quel SGBD ?

Merci,
Franck.

[seabs]

Bonjour,

@fsmrel

Je suis tout à fait d'accord avec cette présentation du MCD.

C'est une modélisation dans ce style que je viens de conduire pour mettre en place une gestion prévisionnelle de la trésorerie dans une PME. Comme vous, j'ai évacué les informations complémentaires dans les entités annexes. Ainsi, tous les Null ont disparu.

Maintenant, à @cadao de choisir ce qui lui convient le mieux.

A+