Los conceptos de negocio se interrelacionan y están conectados entre si, y ningún concepto de negocio está totalmente aislado. Los conceptos de negocios interactúan en la ejecución de los procesos de negocio, en las actividades diarias de los colaboradores de la empresa. Estas relaciones se modelan mediante una estructura llamada link.
Estos proveen de granularidad al modelo y establecen relaciones atemporales entre dos o más conceptos. Las relaciones pueden ser de carácter asociativo, jerárquico, transaccional o eventos.
Existe una razón muy simple para mantener una relación de muchos-a-muchos entre los conceptos de negocio, queremos absorber de la mejor manera las relaciones sin importar como vayan evolucionando. Es correcto mencionar la siguiente implicación: el modelo no gestiona, obliga o comunica la cardinalidad. Pero la razón por la cual estoy conforme con esto es porque un data warehouse debe expresar lo que sucede en el negocio y no ejecutar reglas de negocio.
Veamos el siguiente ejemplo, actualmente un crédito solamente puede ser otorgado a una persona como política de la empresa, sin embargo, en nuestro modelo es posible establecer un crédito a muchas personas. Bien, de entrada sabemos que entonces si el negocio decide otorgar un crédito a un grupo de personas sin problema podemos absorber ese cambio. Y como no es interés del almacén de datos obligar la ejecución de esa regla de negocio, por el contrario, solamente mostrar lo sucedido, se cumple estupendamente el objetivo.
Cuando modelamos eventos es necesario representar cada ocurrencia dentro del link y nos vemos en la necesidad de agregar degenerated attributes para representar la granularidad. Sigamos con los ejemplos, las transacciones no suelen sufrir alteraciones, así que para generar una reversa lo común es generar una nueva transacción con las mismas características pero con signo opuesto. Entonces debemos preguntarnos, ¿Qué campos de la transacción debo agregar al link para reflejar correctamente todas las transacciones? Para mí suele ser suficiente con agregar la fecha real de transacción con una alta preción (microsegundos).
Transacción, ¿Concepto o Relación? Si el negocio suele rastrear transacciones, osea que tienes algo que resulta con significado, pues sin problema puede ser un concepto de negocio. Pero no se considera apropiado la búsqueda de 5 o 6 campos con el afán de construirlo como un concepto, y entonces en caso de no disponer de un identificar lo más conveniente parece ser modelarlo como link. Ejemplo, cuando pasas tu tarjeta de crédito/débito por un POS se genera una autorización y se imprime un voucher para que coloques tu firma. Si te fijas en ese documento encontrarás un número de autorización que suele ser único en el contexto de la fecha de transacción y tarjeta, muy apto para ser usado como business key en el concepto de autorización de la empresa que procesa esas transacciones. Otro ejemplo puede ser el de un movimiento bancario, que también generar un boleta de depósito o retiro, es posible que establecer el concepto de negocio hub_boleta.
En el caso de las transacciones o eventos, existen ocasiones en que podemos estar al cien por cien seguros que los datos nunca cambiaran ,por ejemplo datos se sensores IoT o transacciones que para generar sus reversas se ingresa una nueva transacción con el signo opuesto.
Los links son estructuras sencillas que brindan flexibilidad al modelo. En el momento que los procesos de negocio evolucionen, el modelo solamente requerirá más links para su adaptación, pues los procesos suelen solamente modificar la forma en que los conceptos interactúan a formas más eficientes.
En el caso de las transacciones o eventos, existen ocasiones en que podemos estar al cien por cien seguros que los datos nunca cambiaran ,por ejemplo datos se sensores IoT o transacciones que para generar sus reversas se ingresa una nueva transacción con el signo opuesto.
Los links son estructuras sencillas que brindan flexibilidad al modelo. En el momento que los procesos de negocio evolucionen, el modelo solamente requerirá más links para su adaptación, pues los procesos suelen solamente modificar la forma en que los conceptos interactúan a formas más eficientes.
Existen variantes en los tipos de links:
- Link: Describe la relación entre dos o más hubs y está acompañado de un satellite que describe su información contextual cambiante en el tiempo. Este satellite posiblemente es un driving key. Las definiciones de satellite y driving key se introducen en posts posteriores. Por ejemplo: el concepto de persona se relaciona con el concepto de línea fija de telefonía (en una empresa de telecomunicaciones). Otra consideración es la granularidad apropiada, con lo que es posible agregar degenerated attributes.
- Link-on-link: Se emplea para modificar una relación entre conceptos de negocio. Este tipo de links no suelen ser deseables porque introducen nuevas variables al modelo y se suele romper copiando los conceptos de negocio expuestos en el link original y añadiendo el nuevo hub que participa en representar la modificación. (Pendiente un ejemplo)
- NoHistorizedLink: Caso común que las transacciones no sufran modificaciones y en caso de realizar ajustes, en el negocio siempre se generan nuevas transacciones con signos opuestos. Los satellites que se adhieran a este link, por tanto, nunca sufrirán cambios en el tiempo. En función de esta consideración y por temas de desempeño, es posible agregar los context attributes directamente al link como degenerated attributes. También es una decisión de diseño importante pues se introducen nuevas variables al modelo. Hay que evaluar el impacto en herramientas de auto-generación.
- NoneDescriptiveLink: Similar a un factless fact table. El interés es describir la existencia de una relación, sin la necesidad de agregar ningún context attribute. Suele ser util para contar las relaciones generadas en los procesos de negocio.
- SameAsLink (SAL): Como se expuso en el post Modelado - Conceptos de negocio, existen ciertos escenarios que llevan a mutaciones o irregularidades en los business keys y es en esos casos que solucionamos utilizando un SAL. En este caso el link referencia dos veces a un mismo hub y una sugerencia es agregar los sufijos _MASTER y _DUPLICATE.
- HierarchicalLink: Al igual que el SAL, este link relaciona dos veces al mismo hub, sin embargo, es con la intención de describir una relación de jerarquía como puede suceder con coordinadores y subordinados. En este caso utilizamos los sufijos _PARENT y _CHILD.
- Computed Aggregated Link: Relaciones que tienen granularidad inferior a otro link con la intención de contener context attributes calculados.
- Exploration Link: Único link que no puede existir en los sistemas de información fuentes. El equipo de data warehouse genera este link por intereses particulares del negocio en temas de data discovery o data mining.
En estructura (excepto posiblemente NoHistorizedLink por los degenerated attributes) todos los links mantienen la misma pero el interés es proyectar la lógica de negocio.