Entités séparées ou une méga-entité?

Version imprimable

18/09/2011, 18h22
mathematix

Entités séparées ou une méga-entité?

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 !!!
18/09/2011, 22h28
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+
19/09/2011, 10h17
Richard_35

Bonjour Mathematix et Seabs,

Citation:

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...
19/09/2011, 10h21
CinePhil

Citation:

Envoyé par Richard_35

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 !
19/09/2011, 10h47
Richard_35

Citation:

Envoyé par CinePhil

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.
19/09/2011, 10h52
CinePhil

Citation:

Envoyé par Richard_35

==> 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 !:roll:
19/09/2011, 18h49
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?
19/09/2011, 23h27
CinePhil

Citation:

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.

Citation:

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 ?
20/09/2011, 10h01
Richard_35

Bonjour à tous,

Citation:

Envoyé par CinePhil

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é.
20/09/2011, 18h53
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.
21/09/2011, 10h09
Richard_35

Bonjour Mathematix,

Citation:

Envoyé par 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 :

Citation:

Envoyé par CinePhil

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.