Modélisation de relation d'entité: comment implémenter des "rôles" d'entité?

Question

J'ai récemment lu un peu sur la modélisation de données et j'ai une question sur les rôles qu'une entité peut jouer. Considérons un cas simple où vous avez une société, et une entreprise peut être un fournisseur, un client, un distributeur, etc. ou une combinaison de ces rôles. La société X peut donc être à la fois fournisseur et client. Au niveau des données, vous pouvez avoir une table pour CompanyS, puis des tables pour SupplierS, CustomerS, etc. qui référencent la table Company. Au moins, je pense que c'est ainsi que cela pourrait être représenté.

Ok, donc quelque part dans l'application-land vous avez des classes pour CustomerS et SupplierS et ainsi de suite. Chacun serait composé d'une compagnie, et ensuite tout ce qui est spécial à propos de cette classe en particulier.

Tout va bien et a du sens pour moi tant que nous ne travaillons qu'avec une classe d'entité à la fois. Que se passe-t-il si nous voulons commencer avec une entreprise et voir les rôles qu'elle joue? Donc, dans une application, je pourrais retirer une entreprise et voir qu'elle est un fournisseur et un distributeur.

Maintenant, il y a plusieurs façons de penser à cela, mais je pense que parce que ce domaine est si vieux qu'il doit y avoir des modèles éprouvés pour modéliser ces concepts.

Ainsi, ce que je suis à la recherche d'ici sont des stratégies communes ou des modèles pour modéliser les rôles d'entité au niveau de l'application. Des documents de référence spécifiques sur ce sujet particulier seraient grandement appréciés (que ce soit des blogs ou des livres ou autre).

Answer 1

Je crains, je ne peux pas donner le "modèle commun" comment faire face à ce problème. Mais je pense aussi qu'il n'y a pas du tout le "modèle unique".

La raison en est que la modélisation est en quelque sorte "floue". Je me souviens d'un problème de modélisation assez similaire dans un magazine informatique allemand. C'était une sorte de concours et ils ont montré les différentes solutions qu'ils ont envoyées. Les solutions étaient totalement différentes, mais toutes étaient en quelque sorte valables. Je pense que cela dépend aussi des détails du problème. Parfois, une solution «maigre» est belle ... dans d'autres cas, la solution «gros, gros, grand» doit être faite pour répondre aux besoins des projets ...

Comme, la modélisation est encore une tâche créative avec de nombreux paramètres libres.

Bien sûr, il y a quelques «méta-patterns» qui sont convenus. Par exemple dans le livre "Design patterns" par le célèbre "Gang of Four" et aussi beaucoup d'autres disponibles. Mais il existe encore de nombreux problèmes, où aucune «meilleure» solution convenue n'existe.

Dans votre cas, il serait possible d'utiliser un sous-classement (cela équivaut à une spécialisation). Il pourrait également être possible de faire du «fournisseur», etc., une interface qui pourrait/pourrait ne pas être supportée par une entreprise (ceci pourrait être vu comme une spécialisation optionnelle d'une entité abstraite). Mais il est également possible d'utiliser la composition pour le même problème. Un rôle peut être un objet (Entité) lié par l'entreprise (par exemple avec une relation "has-role").

Answer 2

Je recommanderais d'utiliser l'héritage uniquement en dernier recours. Les relations comme celle-ci ne sont pas simples et sont faciles à entacher un design grâce à une forme d'optimisation précoce. Lorsqu'une entreprise peut être à la fois un fournisseur et/ou un distributeur, vous ne souhaitez pas créer une société avec des attributs de fournisseur ou de distributeur. Au lieu de cela, pensez-y comme vous normaliser une base de données.Vous disposez d'un ensemble de concepts comme suit

• entreprises (CompanyID, nom, attrib1, attrib2)
• Fournisseurs qui sont des entreprises (SupplierID, COMPANYID [clé étrangère], attrib1, attrib2)
• distributeurs (DistributorId, CompanyID, attrib1, attrib2) qui sont également entreprises
• VendorRelationship (RelationshipID, SupplierID, DistributorId, attrib1 , attrib2) si vous avez besoin de suivre les détails de la connexion entre un fournisseur et un distributeur

Cela réduit le couplage entre l'entreprise, le fournisseur et le distributeur.

Un autre exemple de ceci est quand une classe a un état. Plusieurs fois, le modèle conceptuel utilise l'héritage pour montrer comment la classe est une instance d'une classe qui a des enfants polymorphes pour gérer les différents états possibles. Cela provoque des problèmes lorsque vous devez changer l'état de l'instance et vous vous rendez compte que vos pointeurs seront invalidés et/ou les instances affectées peuvent être clonées ou sinon dans des collections qui seraient difficiles ou mises à jour. parce que vous devez créer une nouvelle instance d'une autre classe et ensuite remplacer le pointeur vers la société cible, ce qui peut être difficile s'il y a beaucoup de copies ou si des instances sont contenues dans un conteneur ou une liste. La solution la plus simple et la plus propre est que la classe contienne un élément de type BaseClass ayant les états possibles en tant que fille. De cette façon, lorsque vous voulez changer l'état d'un nobject, il peut être géré en remplaçant simplement l'attribut status par le type concret mis à jour.

Answer 3

Vous pouvez vérifier la conception de la base de données à l'aide de Object Role Modeling. Il utilise fondamentalement les expressions du type que vous utilisez dans votre énoncé de question, affirmant les rôles que les objets (entités) jouent les uns par rapport aux autres. Entre autres capacités, il peut générer une conception de base de données relationnelle complète.

Voici another reference.

Answer 4

La plupart des DBMS ne sont pas adaptées à ce problème, car elles manquent de la flexibilité nécessaire. Je suppose que c'est pourquoi Charles Bachman est venu avec une extension du CODASYLnetwork data model en 1977 en ajoutant le concept de rôle (voir aussi The role data model revisited (PDF)). Cependant, IMHO Bachman était encore trop sous l'influence de la Hierachical data model, pensant en termes d'ensembles de relations propriétaire/membre.

Conceptuellement, le problème en question correspond à un graphique/réseau. Si vous modélisez des entités en tant que noeuds, les arêtes (relations) porteront des étiquettes pour indiquer les rôles. Par exemple, une entité d'ordre aurait une relation "ordonnée par" reliée à une autre entité, qui pourrait être une personne, une société ou autre chose. Lorsque vous suivez une relation "ordonnée par", vous savez que le nœud cible représente une entité qui implémente une interface Orderer.

En langage mathématique, nous avons besoin d'un multigraph dirigé et étiqueté. Vous trouverez cela à la fois dans les bases de données de graphes natifs comme Neo4j (projet open source dans lequel je suis impliqué) ou au RDF. Il existe également des implémentations RDF au-dessus de RDBMS s. Peut-être que le concept de graphique peut également vous donner quelques conseils sur la façon de mettre en œuvre à partir de zéro. Je discute aussi brièvement du concept de rôle dans mon article de blog Flexibility in data modeling.