Schéma de données pour les entités complexes - quelle approche est plus simple

Question

J'examine un modèle de base de données. J'ai besoin d'aide avec une partie du modèle. À ce stade, je suis juste concerné par le modèle logique, pas par la mise en œuvre. Je veux adopter une meilleure pratique.

Résumé du problème

• La base de données est utilisée par une application qui gère les affaires juridiques pour un cabinet d'avocats.

• Chaque cas a plusieurs parties. (Par parti, je veux dire une certaine unité juridique dans le monde réel qui a un intérêt dans l'affaire.)

• Il existe environ 40 types de parties différentes.

• 2 de ces types peuvent être une seule personne, une seule organisation ou plusieurs personnes et/ou organisations réunies dans n'importe quelle combinaison.

• Les 38 autres types peuvent être une seule personne ou une seule organisation. Chaque cas a toujours 2 parties des types complexes (c'est-à-dire potentiellement une combinaison de personnes et d'organisations).

• Habituellement, il y a 5 à 10 parties au total par cas.

options

1. Chaque partie est modélisé comme potentiellement un combintation d'un certain nombre de personnes et d'organisations. Les tables se présenteront comme suit:

   • Case < - CasePartyAssignment - > Parti
     Lorsque toutes les parties sont potentiellement une combinaison des personnes et des organisations:
   • Parti <- PartyPersonAssignment -> Personne
   • Parti <- PartyOrgAssignment -> Organisation

2. Alternativement, je modélise ceci avec 3 types différents de tables CasePartyAssignment.

   Le premier est le même que 1 ci-dessus, qui couvre le scénario complexe:

   • Case <- CaseComplexPartyAssignment -> ComplexParty

     En outre ajouter des tableaux spécifiques pour les scénarios simples:

   • Affaire <- CasePersonAssignment -> Personne

   • cas <- CaseOrgAssignment -> Organisation

La façon dont je le vois, les deux options ont des avantages et des inconvénients. Par exemple, dans l'option 1, je crée un moyen unique de stocker les données, ce qui en soi est simple en raison de la cohérence. Mais cela signifie que je modélise également une partie que je sais être une personne simple utilisant le PartyPersonAssignment conçu pour modéliser la partie complexe.

Quelqu'un a-t-il des commentaires ou des opinions sur ces options?

Answer 1

Je pense que l'option 1 est plus flexible. Avec l'option 1, vous pouvez ajouter ou supprimer des personnes ou des organisations d'une partie en ajoutant ou en supprimant des enregistrements des tables plusieurs-à-plusieurs, alors qu'avec l'option 2, si vous démarrez avec une seule personne ou une seule organisation configuration, il est un peu plus maladroit de le modifier en un ComplexParty. Je suppose que je préfère garder les cas de coin hors du modèle de données, et essayer d'utiliser simplement un modèle flexible qui peut gérer les cas de coin de la même manière que les cas plus complexes.

Je ne pense pas que ce soit trop mauvais de représenter les cas d'entité unique en tant que Parti, même si la partie n'est pas nécessaire dans ce cas.

Answer 2

Je modélise un peu différemment:

• Personne
• Organisation
• PerOrg: super-type de personne/Organisation, à savoir un LegalEntity
Parti
• : soit une partie complexe ou partie simple
• PerOrgPartyAssignment: la relation entre PerOrg et Party, vous pouvez avoir un ou plusieurs PerOrgs par partie (mais un minimum)
• cas: ici vous n'avez PlantiffParty et DefendentParty

Le concept PerOrg (alias « Tout le monde »/« entité légale »/« Party » ...) est tout à fait un concept puissant pour tous les modèles de données portant sur les relations commerciales . Je l'ai utilisé plusieurs fois et cela finit toujours par simplifier le modèle de données quand il y a des relations apparemment complexes.