Modèle de relation de partie. Comment modéliser les relations

Les relations sont partout :entre les personnes, entre les organisations, entre les organisations et les personnes. Pensez à être un employé d'une entreprise, à être membre d'une équipe de projet ou à être une filiale d'une autre entreprise. Existe-t-il un moyen simple de modéliser et de gérer avec précision toutes ces relations ? Pouvons-nous facilement répondre à la question "Qui sait qui ?"

Un examen rapide des relations

La manière exacte dont ce modèle de base a été dérivé a été décrite dans mon article précédent, Conceptions de nomenclatures flexibles et gérables.

Dans ce modèle et dans la conception de nomenclature conventionnelle, le 1st interactor a tendance à être le Party dans la Relationship – employeur plutôt qu'employé, chef d'équipe plutôt que membre d'équipe, etc.

Voici à quoi pourraient ressembler les données (avec le rôle joué par chaque partie entre parenthèses) :

Un modèle plus sophistiqué

Imaginez que vous souhaitiez modéliser une équipe de développement de projet comme celle-ci :

Source :https://www.edrawsoft.com/template-matrix -organigramme.php

La plupart des rôles dans cette hiérarchie d'équipe sont réels - par ex. l'analyste des exigences rend compte à l'analyste du système. Une autre façon de voir les choses est que l'analyste système gère l'analyste des exigences.

Les relations entre les rôles peuvent être lues de gauche à droite (LTR) ou de droite à gauche (RTL). Il est normalement préférable de s'en tenir à une convention ou à l'autre - LTR ou RTL - mais dans la pratique, vous pouvez constater qu'il y a des exceptions à cela.

Notez également que ce diagramme montre différentes manières de regrouper les rôles. Certains rôles sont réels, comme nous en avons discuté; d'autres sont logiques - par ex. le groupe technique, le groupe de formation, l'équipe centrale et l'équipe d'assistance.

Nous pouvons dire que ce diagramme définit la structure de l'équipe en utilisant les rôles requis pour compléter l'équipe de développement du projet. Ceci est distinct d'une instance réelle de l'équipe, qui serait composée de noms de personnes réelles pour chacun des rôles.

Nous avons donc besoin d'un modèle de données flexible et configurable , comme celle-ci :

Les tableaux jaunes contiennent des métadonnées , et les tableaux bleus contiennent des données d'entreprise .

Configuration des métadonnées de base

Nous allons commencer par renseigner le party_type table. Ce tableau différencie si une partie est une personne ou une organisation.

Avant de faire quoi que ce soit d'autre, nous devons également définir les rôles dans le role_type table de métadonnées :

Vous avez sans doute remarqué que chaque rôle appartient soit à une personne, soit à une organisation. Pour donner une idée de ce qui est possible, j'ai ajouté quelques organisations externes avec lesquelles notre société anonyme fictive, ABC Software Inc, entretient des relations.

Ajout de métadonnées sur l'emploi

La tâche suivante consiste à définir les paires de rôles valides entre le premier et le deuxième interacteurs. À son tour, cela définit les types de relations que les parties peuvent avoir. Commençons à remplir le role_type_relationship table de métadonnées avec les rôles des employés de l'entreprise. Après tout, nous ne pouvons pas créer d'équipes sans avoir d'abord des travailleurs :

Supposons qu'ABC Software Inc. embauche deux employés, Jane Smith et Alex Jones, pour les rôles suivants :

En remontant dans le temps, vous verriez que cette relation a commencé avant que Jane Smith et Alex Jones ne soient embauchés; ils devaient postuler pour des emplois chez ABC Software Inc. La relation aurait ressemblé à ceci :

Commencez-vous à voir les possibilités que le modèle de relation de parti prend en charge ?

Nous n'avons pas de table appelée applicant et une autre table appelée employee , comme on peut le trouver dans d'autres modèles. Si vous y réfléchissez, ils partageraient bon nombre des mêmes attributs - nom, adresse, date de naissance, etc. vous devrez copier les valeurs de applicant à employee en cas d'embauche réussie. Mais les personnes impliquées ont-elles été transformées d'une chose à une autre ? Bien sûr que non! Ce sont toujours les mêmes !

En réalité, c'est seulement la relation qui a changé entre ABC Software Inc. et Jane Smith ou Alex Jones. Et c'est précisément ce que modélise le modèle de relation de parti.

Continuer :Métadonnées de l'équipe de projet

Avant de pouvoir créer une party_relationship tableau pour définir le fait que Jane Smith gère Alex Jones, nous devons définir la structure de l'équipe de développement du projet. Il s'agit simplement d'associer les rôles parent et enfant pour former une hiérarchie valide :

Pour tous les rôles ci-dessus, la relation est lue de gauche à droite – par ex. le chef de projet gère l'ingénieur base de données. Alternativement, vous pouvez adopter le format de droite à gauche (l'ingénieur de la base de données rend compte au chef de projet) si c'est votre convention préférée.

Enfin, nous devons définir la relation entre nos deux nouveaux employés :

Bien sûr, vous pouvez avoir n'importe quel nombre d'équipes sous la forme de cette hiérarchie. Dans un sens, donc, party_relationship est une instance de role_type_relationship . Ceci est similaire à la façon dont un objet est une instance d'une classe dans la programmation OO.

Y compris les métadonnées logiques

En référence au schéma de l'équipe de développement du projet, nous pouvons également définir les relations logiques entre les rôles suivantes :

Notez que party_relationship n'est jamais une instance d'une role_type_relationship . Alors à quoi bon définir des relations logiques ?

Eh bien, cela s'explique probablement mieux par un exemple. Imaginez que vous vouliez envoyer une lettre à tous les employés qui sont logiquement membres de l'équipe de support. Pour créer une liste de diffusion, vous devez écrire une requête qui renvoie tous les rôles d'interacteur LOGICAL Support Team 2 joints aux mêmes rôles d'interacteur REAL 2, joints à party_relationship , rejoint la party . Cela vous permettrait d'obtenir les noms et adresses de toutes les personnes concernées.

Un cas particulier

Vous avez peut-être remarqué quelques entrées inhabituelles dans le role_type table de métadonnées, à savoir :

Voici deux exemples d'un cas particulier, qui se produit lorsqu'une partie entretient une relation réflexive avec elle-même :

Par exemple, pour un analyste système indépendant, les interacteurs 1 et 2 dans party_relationship renvoyer à la même party ligne - c'est-à-dire que les deux colonnes de clé étrangère contiennent exactement le même party.ID valeur.

L'importance d'avoir du contexte

Imaginez que nous ayons une petite équipe d'analyse qui est essentiellement formée de la branche entre le chef de projet et le commis technique :

Chacune des relations ici existe également dans la structure de l'équipe de développement de projet. Alors, comment différencier une relation chef de projet → analyste système d'une autre ?

Nous utilisons le contexte facultatif clé étrangère entre role_type_relationship et role_type . Pour la petite équipe d'analyse, nous définissons le contexte de toutes les relations avec la « petite équipe d'analyse », l'élément de niveau supérieur. Et nous faisons le même genre de chose pour la structure de l'équipe de développement du projet. Lorsque nous parcourons la structure, nous le faisons uniquement pour le type d'équipe qui nous intéresse.

Avantages et inconvénients du modèle de nomenclature de relation de partie

Si vous avez lu mes autres articles sur le sujet, vous avez sans doute deviné que je suis fan du design pattern Bill of Materials. C'est simple, mais très puissant. La mise en garde est qu'il doit être utilisé de manière appropriée et qu'il doit être adapté afin que votre mise en œuvre reste gérable.

Dans cette implémentation de relation de partie du modèle BOM, nous nous assurons que nos relations restent exactes en définissant d'abord les relations autorisées entre les interacteurs qui existent dans notre domaine. Cela empêcherait, par exemple, l'Internal Revenue Service d'être "employé" en tant que concepteur Web chez ABC Software Inc.

Quelles possibilités découlent de la définition des relations de cette manière ? Eh bien, votre organisation peut avoir besoin de savoir pour quelles autres organisations vos employés et sous-traitants actuels ont travaillé. Cela permet d'éviter d'éventuels conflits d'intérêts ou même des fraudes. Un exemple de ceci est une organisation qui récompense. Il doit savoir dans quelles écoles ses évaluateurs ont déjà enseigné pour s'assurer qu'ils n'évaluent pas les copies d'examen de ces écoles. Dans un modèle de relation de partie, il est facile d'interroger et d'obtenir ces informations.

D'un autre côté, votre organisation peut vouloir stocker les mêmes informations car cela pourrait présenter des opportunités commerciales. Cela dépend simplement de votre domaine.

En bref, les informations que vous pouvez obtenir à partir de données bien structurées sur les relations avec les parties peuvent être inestimables.