Patrón de relación de partido. Cómo modelar relaciones

Las relaciones están en todas partes:entre personas, entre organizaciones, entre organizaciones y personas. Piense en ser un empleado de una empresa, ser miembro de un equipo de proyecto o ser una subsidiaria de otra empresa. ¿Existe una forma sencilla de modelar y gestionar con precisión todas estas relaciones? ¿Podemos responder fácilmente a la pregunta '¿Quién conoce a quién?'

Una revisión rápida de las relaciones

Exactamente cómo se derivó este modelo básico se describió en mi artículo anterior, Diseños de listas de materiales (BOM) flexibles y manejables.

En este modelo y en el diseño de BOM convencional, el 1st interactor tiende a ser el Party en la Relationship – empleador en lugar de empleado, líder de equipo en lugar de miembro del equipo, etc.

Así es como se verían los datos (con el papel que juega cada parte entre paréntesis):

Un modelo más sofisticado

Imagine que desea modelar un equipo de desarrollo de proyectos como el siguiente:

Fuente:https://www.edrawsoft.com/template-matrix -organigrama.php

La mayoría de los roles en esta jerarquía de equipo son reales, p. el analista de requisitos informa al analista de sistemas. Otra forma de verlo es que el analista de sistemas administra al analista de requisitos.

Las relaciones entre roles se pueden leer de izquierda a derecha (LTR) o de derecha a izquierda (RTL). Normalmente, es mejor ceñirse a una convención u otra, LTR o RTL, pero en la práctica es posible que haya excepciones a esto.

Además, observe que este diagrama muestra diferentes formas de agrupar roles. Algunos roles son reales, como hemos discutido; otros son lógicos, p. el grupo técnico, el grupo de formación, el equipo central y el equipo de apoyo.

Podemos decir que este diagrama define la estructura del equipo utilizando los roles necesarios para completar el equipo de desarrollo del proyecto. Esto es distinto de una instancia real del equipo, que estaría formado por nombres de personas reales en cada uno de los roles.

Por eso necesitamos un modelo de datos que sea flexible y configurable , como este:

Las tablas amarillas contienen metadatos y las tablas azules contienen datos comerciales .

Configuración de metadatos básicos

Comenzaremos completando el party_type mesa. Esta tabla diferencia si un partido es una persona o una organización.

Antes de hacer mucho más, también necesitamos definir roles en el role_type tabla de metadatos:

Sin duda habrá notado que cada rol pertenece a una persona o a una organización. Para dar una idea de lo que es posible, he agregado algunas organizaciones externas con las que nuestra sociedad limitada ficticia, ABC Software Inc, tiene relaciones.

Adición de metadatos de empleo

La siguiente tarea es definir los pares de roles válidos entre el primer y el segundo interactor. A su vez, esto define los tipos de relaciones que pueden tener las partes. Comencemos a completar la role_type_relationship tabla de metadatos con los roles de los empleados de la empresa. Después de todo, no podemos crear equipos sin tener trabajadores primero:

Suponga que ABC Software Inc. va a contratar a dos empleados, Jane Smith y Alex Jones, para los siguientes roles:

Dando un paso atrás en el tiempo, vería que esta relación comenzó antes de que se contratara a Jane Smith y Alex Jones; tenían que solicitar puestos de trabajo en ABC Software Inc. La relación se habría visto así:

¿Empiezas a ver las posibilidades que el patrón de relación entre partidos apoyos?

No tenemos una tabla llamada applicant y otra tabla llamada employee , como puede encontrarse en otros modelos. Si lo piensa, compartirían muchos de los mismos atributos:nombre, dirección, fecha de nacimiento, etc.; tendrías que copiar los valores de applicant a employee al contratar con éxito. Pero, ¿las personas involucradas se han transformado de una cosa a otra? ¡Por supuesto no! ¡Siguen siendo las mismas personas!

De hecho, solo la relación ha cambiado entre ABC Software Inc. y Jane Smith o Alex Jones. Y esto es precisamente lo que modela el patrón de relaciones partidistas.

Continuación:metadatos del equipo del proyecto

Antes de que podamos crear una party_relationship Para definir el hecho de que Jane Smith administra a Alex Jones, debemos definir la estructura del equipo de desarrollo del proyecto. Esta es solo una cuestión de emparejar los roles principal y secundario para formar una jerarquía válida:

Para todos los roles anteriores, la relación se lee de izquierda a derecha, p. el director del proyecto gestiona el ingeniero de base de datos. Alternativamente, puede adoptar el formato de derecha a izquierda (el ingeniero de la base de datos informa al administrador del proyecto) si esa es su convención preferida.

Finalmente, debemos definir la relación entre nuestros dos nuevos empleados:

Por supuesto, puede tener cualquier número de equipos en la forma de esta jerarquía. En cierto sentido, por lo tanto, party_relationship es una instancia de role_type_relationship . Esto es similar a la forma en que un objeto es una instancia de una clase en la programación orientada a objetos.

Incluyendo metadatos lógicos

Con referencia al diagrama del equipo de desarrollo del proyecto, también podemos definir las siguientes relaciones lógicas entre roles :

Tenga en cuenta que party_relationship nunca es una instancia de una role_type_relationship . Entonces, ¿cuál es el punto de definir relaciones lógicas?

Bueno, probablemente esto se explique mejor con un ejemplo. Imagina que quisieras enviar una carta a todos los empleados que lógicamente son miembros del equipo de soporte. Para crear una lista de correo, debe escribir una consulta que devuelva todos los roles de interactuador del Equipo de soporte LÓGICO 2 unidos a los mismos roles de interactuador REAL 2, unidos a party_relationship , se unió a la party . Esto le permitiría obtener los nombres y direcciones de todos los interesados.

Un caso especial

Es posible que haya notado un par de entradas inusuales en el role_type tabla de metadatos, a saber:

Estas son dos instancias de un caso especial, que ocurre cuando una parte tiene una relación reflexiva consigo misma:

Por ejemplo, para un analista de sistemas autónomo, los interactuadores 1 y 2 en party_relationship referirse de nuevo a la misma party fila:es decir, ambas columnas de clave externa contienen exactamente el mismo party.ID valor.

La importancia de tener contexto

Imagine que tenemos un pequeño equipo de análisis que se forma básicamente a partir de la rama entre el director del proyecto y el empleado técnico:

Cada una de las relaciones aquí también existe en la estructura del equipo de desarrollo del proyecto. Entonces, ¿cómo diferenciamos una relación de gerente de proyecto → analista de sistemas de otra?

Usamos el contexto opcional clave externa entre role_type_relationship y role_type . Para el pequeño equipo de análisis, establecemos el contexto de todas las relaciones en "pequeño equipo de análisis", el elemento de nivel superior. Y hacemos lo mismo con la estructura del equipo de desarrollo de proyectos. Cuando atravesamos la estructura, lo hacemos solo para el tipo de equipo que nos interesa.

Pros y contras del patrón de lista de materiales de relación de grupo

Si ha leído mis otros artículos sobre el tema, probablemente haya adivinado que soy un fanático del patrón de diseño de la Lista de materiales. Es simple, pero muy poderoso. La advertencia es que debe usarse de manera adecuada y debe adaptarse para que su implementación siga siendo manejable.

En esta implementación de relación de partes del patrón BOM, nos aseguramos de que nuestras relaciones sigan siendo precisas definiendo primero las relaciones permitidas entre los interactuadores que existen en nuestro dominio. Esto, por ejemplo, evitaría que el Servicio de Impuestos Internos sea "empleado" como diseñador web en ABC Software Inc.

¿Qué posibilidades surgen de definir las relaciones de esta manera? Bueno, es posible que su organización necesite saber para qué otras organizaciones han trabajado sus empleados y contratistas actuales. Esto ayuda a evitar posibles conflictos de intereses o incluso fraudes. Un ejemplo de esto es una organización de adjudicación. Necesita saber en qué escuelas han enseñado previamente sus evaluadores para asegurarse de que no evalúen los exámenes de esas escuelas. En un modelo de relación partidista, es fácil consultar y obtener esa información.

Por otro lado, es posible que su organización desee almacenar la misma información porque podría presentar oportunidades comerciales. Solo depende de tu dominio.

En resumen, la información que puede obtener de los datos bien estructurados de las relaciones con las partes puede ser invaluable.