Caracterización universal de relaciones entre personas y organizaciones

Área: Transformación Digital

Toda empresa u organización necesita  un modelo de datos que recoja relaciones entre personas y organizaciones: una base de datos de clientes, una lista de contactos, de proveedores, etc. Pero en un entorno de transformación digital, tenemos que considear esas entidades de una forma muy abierta, ya que vamos hacia escenarios en que el cliente puede ser a la vez proveedor, contacto social, partner, colaborador…. le damos una vuelta de tuerca a este asunto, analizando un modelo con vocación de ser una solución universal.

Modelos Básicos de relación entre personas y organizaciones. Características y carencias

La expresión más simplista de la relación persona-organización, la que haríamos en nuestra primera semana de estudio de bases de datos, tendría un aspecto similar a éste:

updm-1

En este modelo, existen unas organizaciones con sus datos y unas personas con sus datos, y cada persona está relacionada con la organización que corresponda. Lógicamente, al poco tiempo nos daremos cuenta de las tremendas limitaciones que plantea este modelo, y lo primero que detectaremos será que con él, una persona sólo puede pertenecer a una organización, y además no conservamos ninguna referencia sobre el momento, la duración, o la justificación de esa pertenencia.

Así que en nuestra segunda semana iríamos un poco más allá y buscaríamos un modelo que permita sortear en cierto modo este problema. Eso nos llevará probablemente a algo así:

updm-2

Con este esquema hemos saltado nuestro primer escollo, ya que ahora tenemos una tabla donde podemos establecer relaciones entre una personas y varias organizaciones, o entre una organización y varias personas. Además, disponemos de algo de información sobre ese enlace, como la fecha en la que se produjo, y el rol (que en este caso podríamos definir como el papel que juega la persona en la organización).

Sin embargo, pronto nos daríamos cuenta de que tenemos todavía problemas. Por ejemplo, en un modelo así, el Rol es un dato que proablemente debamos estandarizar, para evitar convertirlo en un campo de texto. Algo así:

updm-3

Sin embargo, tampoco aquí podremos estar satisfechos. Podríamos seguir detallando problemas de caracterización de las relaciones y con ello seguir introduciendo modificaciones, pero cuando lo has hecho 100 veces y has llegado a 100 modelos de datos diferentes para otros tantos proyectos, te das cuenta de que tal vez estás haciendo algo mal. Además, si lo hacemos probablemente agotaremos la paciencia de la mayoría de lectores, a quienes todo lo dicho hasta ahora probablemente le parecen auténticas obviedades.

Así que vamos con el meollo de la cuestión: ¿existe un patrón universal que me permita modelar cualquier relación entre personas y organizaciones?.

El objetivo de este artículo es describir un patrón que tiene esa vocación, y que probablemente está muy cerca de conseguirlo.

El Modelo Universal de Datos para Personas y Organizaciones

Este patrón, cuyo nombre original está en inglés (Universal Person and Organization Data Model) es una propuesta de Joseph Newcum basada en un libro de Martin Fowler, y su primera afirmación ya da al traste con todo ese germen de modelo de datos con el que arrancaba este artículo. Y es que nos dice:

LAS PERSONAS Y LAS ORGANIZACIONES NO SON ENTIDADES DIFERENTES, SINO ATRIBUTOS DE LA RELACIÓN ENTRE DOS PARTES

Toma ya. Un replanteamiento de raíz.

Profundizando, esto viene a decir que tenemos que pensar antes en la relación que en sus integrantes. Porque si así lo hacemos, veremos que una relación puede establecerse entre personas, entre organizaciones, o entre personas y organizaciones.

De tal forma, unas y otras (personas y organizaciones) son en esencia lo mismo, son las PARTES de la relación. Y cuando esa relación se establezca, las personas u organizaciones implicadas pasarán a ser caracterizadores de esa relación.

Así, describir una relación entre partes implicará detallar:

  • Qué tipo de relación es
  • Qué partes participan en ella (sean personas u organizaciones)
  • Qué rol juega cada una de ellas en la relación
  • Cuándo se inicia y termina esa relación
  • Cualquier otro modificador relevante y específico de esa relación

Esto puede modelarse así:

updm-4

Y a resultas de ello, tenemos:

  • Una lista de PARTES. Algunas serán personas, otras organizaciones. Todas nuestras personas y organizaciones estarán por tanto descritas, con sus características básicas y COMUNES, en esa tabla (luego hablamos de las características comunes y las que no lo son, de momento quedémonos con el nombre, pues toda persona y toda organización tienen al menos eso en común, un nombre)
  • Una tabla de relaciones, verdadero meollo de este germen del modelo, en el que tenemos:
    • El tipo de relación, que por escalabilidad sacamos a una tabla externa. Serían tipos como “relaciones entre la empresa y sus proveedores” o “relaciones entre clientes y la empresa”, “relaciones entre unos clientes y otros”…
    • Dos partes implicadas, que almacenamos en los campos “FromParty” y “ToParty”, es decir, de quien a quien se establece la relación (de Pedro a Juan, de Cubic Factory a Google, de Ana a Joaquín..)
    • El Rol que caracteriza a esa relación, que también por escalabilidad sacamos a tabla independiente. Cuestiones como “ser marido”, “ser cliente”, “ser empleado”..

De ese modo, ya podemos describir múltiples tipos de relaciones como éstas:

IDTipo de relaciónDe (o desde)HaciaRolFecha inicioFecha fin
1EmpleoRobertoCubic FactoryEmpleado01/01/201531/12/2015
2MatrimonioRobertoAnaMarido10/05/2002
3Relación comercialCubic FactoryGoogleCliente01/05/2010
4Relación comercialCubic FactoryGoobleProveedor05/06/201506/09/2015

Nótese cómo ahora las partes pueden jugar diferentes papeles en las relaciones: Cubic puede ser cliente de Google (consumimos Adwords) pero a la vez puede ser proveedor de Google (nos han encargado un nuevo modelo de datos para su buscador… ojalá jeje).

En definitiva, tenemos ya un sistema que nos permite caracterizar bajo un modelo sencillo cualquier relación unidireccional o bidireccional entre las partes.

Lógicamente, una base de datos no es sólo una descripción de relaciones sino también toda la colección de datos que caracterizan a cada una de esas partes. Ahora iremos con ello.

Caracterización de las Partes en el Universal Person Data Model

En nuestra primera aproximación al concepto de las partes como atributos de la relación, nos habíamos quedado únicamente con el nombre como dato específico de la parte. Ahora veremos cómo universalizar los atributos de una parte.

A modo de ejemplo, que podríamos extender después a otro tipo de atributos, seguiremos con el caso del nombre:

  • Para empezar, nos encontramos con que algo tan sencillo como el “nombre”, en realidad puede encerrar mucha mayor complejidad:
    • En el caso de las personas, tienen más de un nombre. Tienen también apellidos, pueden tener prefijos (Sr/Sra), pueden tener sufijos, e incluso nombres diferentes en función del uso (Carlos Martínez en el trabajo, Charly para los amigos)
    • En el caso de las organizaciones, también pueden tener más de un nombre: razón social, nombre comercial
    • Además, en ambos casos el uso de un nombre u otro está ligado a determinadas situaciones e incluso a momentos temporales.

Lo que haremos entonces será sacar el nombre (y en general cualquier atributo de parte) de la tabla de definición de esa parte, y convertirlo en una tabla de datos relacionados con la parte.

En dicha tabla podremos recoger varios nombres para cada parte, caracterizar cada uno de ellos por diferentes campos, y establecer en qué casos (función del nombre) se utilizará cada uno de los nombres que esa tabla albergue en relación a esa parte. Algo así:

updm-5

Podríamos aplicar patrones similares a otras tipologías de datos, pero en ocasiones deberemos cambiar algo el enfoque. Pongamos como ejemplo algo tan habitual como los DATOS DE CONTACTO:

  • Tenemos tendencia natural a pensar en una dirección o un número de teléfono como localizadores de una persona o una organización.
  • Pero en realidad, más bien son casos concretos de modos de localización de esa persona u organización.
  • Así, una persona u organización puede ser localizable por diferentes vías:
    • Vías físicas: incluimos aquí su dirección postal, las instrucciones de “como llegar”…
    • Vías telemáticas: son aquellas a través de las cuales podremos localizar a esa persona u organización a través de diferentes medios telemáticos:
      • Sus números de teléfono
      • Sus direcciones web
      • Sus emails
      • Sus perfiles sociales
      • Etc

Esto no es dificil de modelizar, una vez hemos caido en ello. Pero de nuevo es una vuelta de tuerca, que dejamos para un artículo posterior, ya que nos aleja de nuestro foco, que es dar a conocer el modelo como tal. Y la esencia de este modelo está en la relación entre partes, más que en la definición posterior de las colecciones de datos asociadas a cada una de ellas.

Si te interesa profundizar en este potente modelo de datos (y sabes inglés) ahí van un par de referencias básicas:

Y si necesitas ayuda para definir un modelo similar a éste para tu organización, nuestro servicio de Transformación Digital de empresas puede ser una gran opción !

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*