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 ?

@+

[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+