Discussion :

[Crackerz]

Bonsoir,

Je me pose une question sur bon nombre d'exemple que j'ai pu voir concernant les MCD concernant les factures et devis, pourquoi généralement les Facture et devis sont présenté comme des entité à part ?
Une Facture ressemble fortement à un devis à quelques attribut près, pourquoi ne pas les regrouper ?

Document
id
typeDocument
date paiement
etc...

Devis
id (clé primaire et étrangère vers Document)
....

Facture
id (clé primaire et étrangère vers Document)
....

Dans ce contexte l'héritage est-elle à bannir ?

[fsmrel]

Bonjour Crackerz,


Encore faut-il qu’il y ait un devis pour chaque facture : ça n’est pas les cas dans la discussion « Gestion Facturation et devis » ouverte par Benallasiham, où l’on facture les clients fidèles sans avoir établi de devis.

Maintenant, une fois qu’un devis est signé par les deux parties, la facture devra lui être égale, ce qui incite à procéder légitimement à une généralisation (factorisation, regroupement des données communes) en une entité-type DOCUMENT et ne conserver dans les entités-types DEVIS et FACTURE que les données qui leur sont propres (date de fin de de devis, numéro de devis ?)

Nonobstant l'exemple de Benallasiham, a priori, rien ne s’oppose donc à ce vous mettiez en route le processus de l’héritage...

[Crackerz]

Bonjour fsmrel,

Merci pour votre réponse, comment faîtes vous pour savoir si l'héritage est une bonne solution en fonction de n'importe quelle contexte ? Personnellement, si A est un B alors il y aura de l'héritage mais votre réflexion semble aller plus loin que ça...

Reprenons un exemple d'héritage que vous m'avez vous même fait part sur l'entité client :
http://www.fsmwarden.com/developpez_...ritage_MCD.png

Si je rajoute une entité Modérateur (au hasard) puis-je (auriez-vous fait) faire ainsi ?

Membre(père)

Client(enfant-père de entreprise et utilisateur) Modérateur(enfant)

Ceci n'est qu'un exemple si vous avez mieux pour me faire comprendre dans quel contexte nous devons utiliser l'héritage je suis preneur, ces vous le pro

Merci fsmrel.

[fsmrel]

Bonsoir Crackerz,

Si je rajoute une entité Modérateur (au hasard) puis-je (auriez-vous fait) faire ainsi ?

Membre(père)

Client(enfant-père de entreprise et utilisateur) Modérateur(enfant)

Il y a de très fortes chances, dans la mesure où les attributs des sous-types peuvent être mis en commun.

Je rappelle aussi que la factorisation des attributs c’est bien, mais celle des associations c’est pas mal non plus, voire leur spécialisation, quand par exemple une association ne concerne qu’un sous-ensemble de d’acteurs.


Quoi qu’il en soit, il faut rester vigilant. Il y a plus de 20 ans, j'avais expliqué l'héritage à un concepteur, dans le domaine de l'Assurance. Avec enthousiasme, celui-ci produisit un MCD où l'on trouvait une entité-type Intervenant (intervenant dans un sinistre), faisant l'objet d'une quinzaine de sous-types : Assuré, Victime, Témoin, Ambulancier, Commissaire, Voleur, etc. Un truc à utiliser une liasse de papier A3 pour représenter un MCD « mille-pattes »¹... En fait, à part l’assuré les autres intervenants ne jouaient qu’un rôle tout à fait secondaire : on s'est contenté d'associer l'entité Intervenant à une entité Rôle (un intervenant pouvant au besoin jouer plusieurs rôles), avec redistribution des propriétés (que je n’ai plus en tête, il y a prescription...)
En l'espèce, nous avons appliqué l'heuristique papoue : comment comptent les papous ? Ils comptent ainsi : un, deux, beaucoup ! Ainsi, se votre côté, si vous dénombrez plus de trois ou quatre sous-types pour un surtype, remettez les choses à plat et réfléchissez à une éventuelle solution de repli du genre de celle que j'ai évoquée.


Un bon exemple de généralisation/spécialisation : voyez la discussion avec frm013, au sujet des entreprises, magasins, employés, directeurs, etc. à partir du post #26, en passant par #46, #51, #58 (ce fut un peu long...)

____________________________

¹ J’en profite pour relayer l’annonce passée dans le numéro 61 de l’OS à Moelle, bien qu’elle ne soit pas de la 1re fraîcheur (juillet 1939) : « Mille-pattes cherche partenaire sérieux pour numéro de claquettes. »

[Crackerz]

Merci

[StringBuilder]

L'approche qui est présentée, sans la notion d'héritable, c'est celle qui est utilisée dans l'ERP Generix, que je connais bien.

Le modèle des données physique se résume à un nombre très restreint de tables, malgré un MCD "évolutif à l'infini".

En effet, on trouve une table "événement", qui peut être de types différentes (devis,commande,livraison,facture,retour,avoir,...) aussi bien en vente qu'à l'achat, ainsi que pour les transferts dépôt à dépôt, les flux directs fournisseur/client, etc., avec autant de possibilités que désiré (on peut créer autant de types d'événement qu'on veut, avec toute la chaîne de hiérarchie désirée).

On retrouve la même chose avec les "tiers", dans lesquels on retrouve aussi bien les clients que les fournisseurs, les dépôts, les points de vente, les sociétés juridiques, toujours avec des types qu'on peut créer par paramétrage.

Le gros avantage, c'est qu'avec très peu de tables, on peut représenter énormément d'entités (MCD parlant) et surtout qu'on peut faire évoluer le MCD en rajoutant simplement des types et en adaptant quelques paramètres.
On n'a ainsi pas besoin de réécrire les binaires pour mettre en place de nouveaux flux complexes, c'est un vrai bonheur.

Le revers de la médaille, c'est qu'on se coltine alors des requêtes bien plus complexes (on doit se coltiner les types dans toutes les requêtes, on doit les évaluer dynamiquement en fonction du contexte et du paramétrage, etc.)
Et au final, on se retrouve avec des tables mammouth, très lourdes, généralement bourrées de colonnes nulles (car même si un devis ressemble à une commande qui ressemble à une livraison, etc.) à chaque fois on a des propriétés spécifiques.

Pour limiter les colonnes nulles, on se lance alors dans la mise en place d'un méta-modèle pour gérer des propriétés dynamiques (dans Generix, c'est ce qu'on appelle les "zones datées", qui permettent d'ajouter -pour une date donnée- autant de propriétés qu'on veut à chacune des tables du modèle physique, dans un contexte donné : par exemple, la ZOD101 d'un client sera son numéro d'adhérant tandis que la ZOD101 d'un fournisseur sera son agrément ISO-9001 et que la ZOD101 d'une commande sera un flag de validation des remises).

A nouveau, je vous laisse imaginer le bordel des requêtes.

Comme dans tous les métamodèles, il y a le pour et le contre.

Personnellement, je suis très mitigé entre les deux.

Autant je ne reprendrais pas les yeux fermés le modèle de Generix, qui présente de grosses lacunes au niveau performances, autant je suis persuadé que la mise en place d'un méta-modèle est LA solution pour avoir un code applicatif facilement maintenable et évolutif.

Reste ensuite à voir quel est le besoin : pour un spécifique jetable (c'est à dire qui tourne dans un unique contexte), c'est à bannir, car bien plus consommateur en ressources. Pour un logiciel qui doit être revendu dans des contextes différents (Generix se retrouve aussi bien dans les hôpitaux que les loueurs de matériel ou les chaînes de négoce et coopératives agricoles, avec des problématiques TRÈS différentes), c'est un plus énorme, surtout quand on sait que les tarifs sur le terrain pour les chefs de projets qui vont le paramétrer tournent entre 1000€ et 3000€ par jour selon les profils : moins on a de choses à réécrire, et moins on doit faire rentrer des carrés dans des trous ronds, et moins la note finale est élevée pour le client. Ensuite, il y a un compromis à trouver pour ne pas se retrouver avec un système trop lent, car c'est le principal revers des méta-modèles.