Discussion :

[mathematix]

Bonjour,

Je suis entrain de modéliser une base de données des ventes d'articles.
Les conversations avec le client ont fait référence à des entités telles que:

- devis (DV)
- bons de livraison (BL)
- factures (FC)
- bons de retour (BR)
- etc...

Remarque donné par le client: certains documents peuvent être transformer en d'autres. Exemple: Devis ==> BL, Devis ==> Facture, BL ==> Facture ...

Je cherche la meilleure façon de modéliser cette base de données.

Naturellement, j'ai pensé à concevoir une table pour chaque type de document. C'est-à-dire, la table DEVIS, la table BL, la table FACTURE, etc...

Une autre approche c'est de mettre le tout dans une même table (une méga-entité) que j'appellerai DOCUMENTS avec clé primaire = DOC_ID et un attribut DOC_TYPE = {DV, BL, FC, BR, ...} pour différencier entre devis, factures etc...

Qu'est-ce que vous proposez comme "meilleure modélisation" pour ce cas?

Merci d'avance !!!

[seabs]

Bonjour,

Fais une recherche dans cette rubrique, il existe de nombreux exemples.

Ton problème semble se rapprocher de cette conversation.

http://www.developpez.net/forums/d90...e-facturation/

Vas vers les derniers messages, tu auras une présentation suffisamment précise pour t'aider à construire ton projet.

En tout état de cause, l'entité unique est une très mauvaise solution, car il te sera impossible de normaliser ta table unique. Alors, bon courage pour les mises à jours, les suppressions, etc. Il est indispensable pour ne pas dire obligatoire de créer différentes entités.

Quand, tu auras fait une première ébauche de ton MCD, tu le mets sur le forum en présentant des points de difficultés, questions, etc. Tu auras toujours une ou plusieurs personnes pour t'aider à finaliser ton projet.

A+

[Richard_35]

Bonjour Mathematix et Seabs,

Une autre approche c'est de mettre le tout dans une même table (une méga-entité) que j'appellerai DOCUMENTS avec clé primaire = DOC_ID et un attribut DOC_TYPE = {DV, BL, FC, BR, ...} pour différencier entre devis, factures etc...

==> comme Seabs, je te le déconseille fortement...

J'atouerais aux remarques judicieuses de Seabs que, avec le temps, tu auras sans doute besoin d'ajouter des attributs (champs, en final) propres à certaines entités (tables, en final) et pas à d'autres. De ce fait, tu aurais, dans la même table, des champs toujours NULL pour une entité, toujours renseignés pour d'autres... bref, à terme, ingérable...

[CinePhil]

tu auras sans doute besoin d'ajouter des attributs (champs, en final) propres à certaines entités (tables, en final)

Non ! Une table est composée de colonnes et de lignes ! Les champs sont à la campagne ou dans les formulaires !

Et en Merise, on parle plutôt de propriété que d'attribut mais c'est vrai que je ne le sais que depuis peu de temps et il me semble bien qu'on m'a enseigné le contraire : attributs en Merise, propriétés en UML alors que c'est l'inverse !

[Richard_35]

Non ! Une table est composée de colonnes et de lignes !

==> c'est vrai. C'est la terminologie SQL qui est devenu la norme, et c'est très bien comme cela.

Il n'empêche que quand nous parlons de champs et d'enregistrements (ou de records), nous arrivons, malgré tout, à nous comprendre.

[CinePhil]

==> c'est vrai. C'est la terminologie SQL qui est devenu la norme, et c'est très bien comme cela.

Il n'empêche que quand nous parlons de champs et d'enregistrements (ou de records), nous arrivons, malgré tout, à nous comprendre.

Mais autant employer les bons termes !

[mathematix]

Merci pour les liens, et les commentaires.

J'ai voulu mettre l'accent plus sur l'aspect "Héritage" dans la relation entre:
DOCUMENT
et
{Devis, BL, Facture, Avoir...).

En fait, si on conçoit une table pour chaque entité {Devis, etc...}, alors, la réponse à une question du type:

Donner la liste de tous les documents de la journée "2011/09/17" ne serait pas très élégante, du moins pas très pratique...

C'est pour cette raison que j'ai pensé à une même table ENTETE_DOCUMENT qui jouera le rôle d'une entête commune pour tous les documents (avec un code spécial: DEV, FAC, BL, AVO..., puis il y a une spécialisation vers chaque entité.

Votre avis?

[CinePhil]

Remarque donné par le client: certains documents peuvent être transformer en d'autres. Exemple: Devis ==> BL, Devis ==> Facture, BL ==> Facture ...

Comme tu l'écris toi-même, c'est une "remarque donnée par le client", dans son langage non informaticien. En plus, je trouve douteux qu'un devis se transforme en BL ! Il faut une commande entre les deux ! Et un document ne se transforme pas en un autre ; on utilise les informations d'un document pour en générer un autre.
Et là où se concept de "transformation" de document risque de coincer c'est par exemple lorsqu'il y aura plusieurs livraisons ou plusieurs factures pour une seule commande.

J'ai voulu mettre l'accent plus sur l'aspect "Héritage" dans la relation entre:
DOCUMENT
et
{Devis, BL, Facture, Avoir...).

Ce n'était pas évident d'après ton premier message ! Le concept d'héritage n'y est même pas mentionné !

Mais le concept d'héritage reste intéressant et peut être applicable ici, tous les documents que tu cites peuvent en effet avoir des propriétés communes telles que l'identifiant du client. À étudier plus en détail avec ton cas concret.
De quel domaine commercial s'agit-il ? Des produits à l'unité ? Des services sur-mesure ? Des produits de catalogue ou des prototypes ? Des oeuvres immatérielles ?

[Richard_35]

Bonjour à tous,

Et là où se concept de "transformation" de document risque de coincer c'est par exemple lorsqu'il y aura plusieurs livraisons ou plusieurs factures pour une seule commande.

==> effectivement, la détermination des cardinalités entre tes entités feront, sans doute, tomber d'eux-mêmes ton idée de "méga-entité".

J'ajouterais que les "etc..." et "..." revêtent une certaine importance et produiront, sans doute, le même résultat que précédemment annoncé.

[mathematix]

Je vais revoir plus profondément les relations entre les entités que j'ai citées, et surtout le côté "Transformation de document" et "Affectation de doc".

- Transformer(Devis, Commande)
- Générer(Commande)_à_partir_(Devis)
- Affecter(BL1, BL2, ...)_à_(Commande) ...

Ce sont actions/métiers qui doivent être revues et simplifiées.

Merci pour le partage d'idées.

[Richard_35]

Bonjour Mathematix,

Ce sont actions/métiers qui doivent être revues et simplifiées.

==> effectivement.

Attention aux relations 1,n entre les détails de tes documents, comme le souligne l'exemple :

Et là où se concept de "transformation" de document risque de coincer c'est par exemple lorsqu'il y aura plusieurs [lignes] livraisons ou plusieurs [lignes] factures pour une seule [lignes] commande.