Discussion :

[Paprick]

Bonsoir à tous,

Les problèmes que vous évoquez, et les questions d'historisation en particulier, relèvent tous de la modélisation conceptuelle de votre système d'information.
Si vous arrivez à traduire vos exigences sous forme de modèle conceptuel de données (MCD), le schéma relationnel de la BD se déduira automatiquement.
Par exemple pour le prix, vous pourrez décider qu'il doit être présent dans le classe d'entités (future table de la BD) PRODUIT, mais aussi dans l'association entre PRODUIT et FACTURE pour en conserver l'historique : vous aurez alors deux rubriques différentes : "Prix courant" et "Prix facturé".
Voici un petit exemple de MCD avec le MLD et le code SQL correspondants :

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
CREATE TABLE Client(   Id_Client COUNTER,
   Nom VARCHAR(50),
   Adresse VARCHAR(80),
   CP CHAR(5),
   Ville VARCHAR(50),
   PRIMARY KEY(Id_Client)
);
 
 
CREATE TABLE Facture(
   NumFac CHAR(8),
   DateF DATE,
   Id_Client INT NOT NULL,
   PRIMARY KEY(NumFac),
   FOREIGN KEY(Id_Client) REFERENCES Client(Id_Client)
);
 
 
CREATE TABLE Produit(
   Réf CHAR(5),
   Libellé VARCHAR(50),
   Prix_courant CURRENCY,
   PRIMARY KEY(Réf)
);
 
 
CREATE TABLE Contenir(
   NumFac CHAR(8),
   Réf CHAR(5),
   Qté SMALLINT,
   Prix_facturé CURRENCY,
   PRIMARY KEY(NumFac, Réf),
   FOREIGN KEY(NumFac) REFERENCES Facture(NumFac),
   FOREIGN KEY(Réf) REFERENCES Produit(Réf)
);

Bonne continuation !

[Sve@r]

Attention aux fausses idées reçues ou aux dogmes appliqués sans réfléchir.

Ce n'est pas une fausse idée, tyrtamos a vulgarisé ce que Merise a définit comme étant les 3 formes normales d'une bdd. Et effectivement cette forme normale implique un principe de "non redondance" ou comment positionner la donnée au plus juste. Bien sûr il y a parfois quelques impossibilités (ex la ville donne le code postal et le code postal donne la ville, souci référencé sous le vocable "Boyce-Codd") mais généralement on y arrive.
Et tyrtamos n'a jamais préconisé de faire ça "sans réfléchir". C'est justement en réfléchissant à la normalisation d'une bdd qu'on peut arriver à la faire coller au mieux au besoin.

La loi française implique donc de dupliquer l'information de l'adresse d'un client à plusieurs endroits... Donc conserver un historique des adresses (dont la majorité sont obsolètes)

Pas besoin d'historique. Suffit d'enregistrer l'adresse dans la table/relation associée à la facture elle-même.

Le dogme "Pas de redondance de données" est un bon principe mais il faut réfléchir à ce qu'on fait et ne pas l'appliquer à la lettre de manière systématique

Il faut savoir faire la part des choses. Si la facture doit mentionner une donnée particulière, donnée qui peut changer avec le le temps, alors la donnée datant de la facture doit-être recopiée dans la facture c'est évident. Cela ne remet pas en cause le principe de "non redondance" qui n'est là que pour éviter qu'une modification d'une donnée qui serait inutilement dupliquée dans deux tables B et C filles de A alors qu'elle aurait pu être unique dans A soit alors modifiée dans B mais pas dans C. Ce principe ne s'applique pas à ton exemple où ta facture a ici un rôle d'archive et ne sera pas impactée (surtout pas) par une modification de l'adresse.

Mais que fais-tu des prix des articles ?
Avec l'inflation, les prix des articles a augmenté.
Si je réédite la facture, je ne dois pas me retrouver avec les nouveaux prix mais bien avec ceux de l'époque.

J'ai eu ce souci dans un truc de gestion de commerce. Mes factures contenaient la référence du produit acheté, la qté achetée et une copie du prix de l'article au moment de l'achat. Et j'avais même pensé à une évolution possible de la TVA donc elle contenait aussi la TVA au moment de l'achat.
L'édition (réédition) de la facture utilisait la référence du produit pour afficher son libellé et les prix recopiés.
Et ma bdd gérait même l'historique des prix. Je pouvais donc faire des stats sur la variation du prix dans le temps. Et j'avais mis des triggers dans ma bdd pour que la modification du prix dans la table des articles soit automatiquement répercutée dans l'historique (c'était carrément le moteur bdd qui gérait) donc côté SQL, je faisais juste un simple "update".
Ci-dessous une copie d'écran (les prix ont été artificiellement générés ce qui explique les variations dans tous les sens)

[popo]

Ce n'est pas une fausse idée, tyrtamos a vulgarisé ce que Merise a définit comme étant les 3 formes normales d'une bdd. Et effectivement cette forme normale implique un principe de "non redondance" ou comment positionner la donnée au plus juste. Bien sûr il y a parfois quelques impossibilités (ex la ville donne le code postal et le code postal donne la ville, souci référencé sous le vocable "Boyce-Codd") mais généralement on y arrive.
Et tyrtamos n'a jamais préconisé de faire ça "sans réfléchir". C'est justement en réfléchissant à la normalisation d'une bdd qu'on peut arriver à la faire coller au mieux au besoin.

- on ne doit jamais avoir une même information à plusieurs endroits de la base de données, car le risque est qu'on mette à jour cette information à un seul endroit et pas dans tous, ce qui produirait une faute d'intégrité de la base. D'où les contraintes à créer entre les tables.

Je constate qu'on ne donne pas le même sens aux mots "on ne doit jamais".

Il faut savoir faire la part des choses. Si la facture doit mentionner une donnée particulière, donnée qui peut changer avec le le temps, alors la donnée datant de la facture doit-être recopiée dans la facture c'est évident. Cela ne remet pas en cause le principe de "non redondance" qui n'est là que pour éviter qu'une modification d'une donnée qui serait inutilement dupliquée dans deux tables B et C filles de A alors qu'elle aurait pu être unique dans A soit alors modifiée dans B mais pas dans C. Ce principe ne s'applique pas à ton exemple où ta facture a ici un rôle d'archive et ne sera pas impactée (surtout pas) par une modification de l'adresse.

Tu ne fais que confirmer mon propos.
Le principe de non redondance ne s'applique pas dans ce cas précis et c'est justement là où je voulais en venir par "dogmes appliqués sans réfléchir".

[Sve@r]

Je constate qu'on ne donne pas le même sens aux mots "on ne doit jamais".

C'est le souci d'un forum dans lequel il manquera toujours l'intonation de la voie, la gestuelle et la réponse immédiate face à son interlocuteur si celui-ci ne réagit pas comme on l'espère. Si dans une discussion je dis "on ne doit jamais" et que l'autre répond "oui mais dans ce cas précis...", je pourrai de suite temporiser/minimiser/relativiser/préciser ; mais pas dans un forum dans lequel le lecteur doit alors faire confiance et "sentir" que si l'écrivain, qui de plus a une certaine notoriété en terme de points et de posts, a écrit "on ne doit jamais" c'était quand-même fortement sous-entendu "de façon générale et les cas particuliers devront être examinés au cas par cas".

[popo]

C'est le souci d'un forum dans lequel il manquera toujours l'intonation de la voie, la gestuelle et la réponse immédiate face à son interlocuteur si celui-ci ne réagit pas comme on l'espère. Si dans une discussion je dis "on ne doit jamais" et que l'autre répond "oui mais dans ce cas précis...", je pourrai de suite temporiser/minimiser/relativiser/préciser ; mais pas dans un forum dans lequel le lecteur doit alors faire confiance

et "sentir" que si l'écrivain, qui de plus a une certaine notoriété en terme de points et de posts, a écrit "on ne doit jamais" c'était quand-même fortement sous-entendu "de façon générale et les cas particuliers devront être examinés au cas par cas".

Je suis d'accord avec la première partie mais pas avec la seconde.
Le lecteur n'est pas dans la tête du rédacteur et ce qui peut paraitre évident pour le rédacteur ne l'est pas forcément sur le lecteur.
J'estime que justement, lorsqu'un expert s'adresse à un novice par écrit, il devrait avoir suffisamment d'expérience pour savoir éviter les radicaux qui pourraient être pris à la lettre.
Encore plus dans le monde du développement où une spécificité non explicitée par le demandeur au départ peut conduire à devoir récrire énormément de choses et retarder la livraison de manière plus ou moins importante.