Fundamentar el diseño de un almacén de datos en los conceptos de negocio es una aproximación que nos acerca a un modelado exitoso. Esto permitirá que nuestro modelo sea sostenible y extensible a lo largo de los años de evolución de la empresa. Me refiero a alcanzar una integración empresarial global (geográficamente) y considerando todos los sistemas de información fuente. Lo relevante es determinar los conceptos de negocio y para estos establecer correctamente las llaves de negocio (o business keys), que son la identificación de cada instancia de un concepto de negocio. Estos son los pilares sobre los cuales se sostiene nuestro modelo.
Los conceptos de negocio existen en un tipo de tablas llamadas hub. Para identificarlos una práctica común es consultar al negocio en función de qué campos localizan la información dentro del sistema, y cómo diferencian un resultado de otro.
Por ejemplo,
- Si hablamos de una empresa de telecomunicaciones, sin duda que realizan búsquedas en el sistema por número de teléfono. Hemos encontrado un primer concepto de negocio. Teléfono. Y al mismo tiempo su llave de negocio, el número de teléfono.
- Buscan a las personas por código de identificación único gubernamental (CUI en Guatemala). Hemos encontrado otro concepto de negocio. Persona (CUI).
- Buscan facturas por su número de serie. Listo, otro concepto de negocio. Factura (numero_serie).
Otro ejemplo,
- Una empresa de microfinanzas que localiza sus créditos por un número de crédito único. Bien, concepto de negocio Crédito (numero_credito).
- Revisan los resultados de sus promotores los cuales identifican por su nombre. Bueno, listo, nuevo concepto de negocio Promotor(nombre).
- Y que hay del lugar donde sucede todo, la agencia. Pues también el negocio evalúa eso. Otro concepto de negocio. Agencia.
Y otro ejemplo,
- Una empresa de tarjeta de crédito que busca por número de tarjeta de crédito. Sí, acertaron. Tarjeta como concepto de negocio.
Seguimos,
- Un e-commerce, localiza sus órdenes por número de orden.
Con estos ejemplos nos podemos guiar para empezar a identificar los conceptos de nuestro negocio.
¿Y qué es eso de llave de negocio (Business key)? Pues muy sencillo, es la identificación de una instancia de un concepto de negocio que no es propensa a cambiar.
Concepto -> Llave de negocio
Teléfono -> Número de teléfono
Persona -> Código Único de Identificación (CUI Guatemala)
Crédito -> 05008570568
Promotor-> Brian Estrada
Agencia -> Ciudad capital zona 5
Tarjeta -> 543683924792939
Estas llaves no necesariamente deben ser solamente un campo/valor, es probable encontrar ejemplos donde dos campos participen en la formación de un business key, se le conoce como un composite key, también conocidos como smart keys (segmentos de información con significado propio que se unen para formar un identificador).
Alcance
Además es necesario reconocer el alcance de un business key. Por ejemplo, pensemos en una empresa transnacional de productos de belleza que le asigna códigos a sus vendedoras. Esos códigos solamente son válidos en su país de origen. Entonces existe la vendedora 1034 en Nicaragua y la vendedora 1034 en Costa Rica. Si solamente colocamos 1034 como llave de negocio para el concepto vendedora estaríamos considerando como una única vendedora y en realidad son dos distintas. La solución para escenario es generar NI-1034 y CR-1034 como nuestra llave de negocio. Los alcances pueden ser globales, organizacionales o de aplicación.
Mutación
Mutación
Como nuestro data warehouse durará por muchos años y el mundo cambia pues claro que pueden suceder mutaciones en la llave de negocio. Vamos a seguir con los ejemplos, en Guatemala desde alrededor de 1931 se estableció la cédula de vecindad para la identificación de sus ciudadanos, la cual constaba de un número de orden y un número de registro (Ej: A01 138598), pero resulta que para el año 2010 ya no cumplía su cometido por lo que el gobierno decide que será reemplazao por el DPI el cual consta de un código único de identificación del estilo (2574 85950 0705). Sin duda, en nuestras empresas podemos reconocer el concepto "Persona" y como llave de negocio muy útil el número de identificación que asigna el gobierno del país por lo que en Guatemala por mucho tiempo nuestra llave de negocio fue número de cédula (Orden + Registro) y luego se transformó al CUI. La solución es un same-as link (este objeto será definido en una próxima entrada).
Irregularidades
Identifiqué el concepto de negocio pero la llave de negocio es distinta en cada sistema. ¿Qué hago? Ejemplo: En un sistema de fábrica de créditos se realizan consultas a buró a fin de obtener la historia de un cliente y determinar si es apropiado otorgarle un crédito. Se consulta empleando el número de identificación tributaria (NIT), fecha de nacimiento y nombre. Pero en continuidad con el ejemplo anterior, hemos dicho que a las personas se les identifica por código único de identificación (CUI). La solución es un same-as link.
Una circunstancia muy común a tener en cuenta es que no todos los sistemas proveen los business keys de forma consistente. Ejemplo: el negocio especifica que a los promotores se les identifica por nombre. Al obtener el nombre de promotor desde cada sistema resulta la siguiente inconsistencia "Brian Estrada" y "Brian Steve Estrada". Cuando se utilicen estos valores como identificación se considera al mismo promotor como dos promotores distintos. La solución es un same-as link.
Llaves surrogadas
Irregularidades
Identifiqué el concepto de negocio pero la llave de negocio es distinta en cada sistema. ¿Qué hago? Ejemplo: En un sistema de fábrica de créditos se realizan consultas a buró a fin de obtener la historia de un cliente y determinar si es apropiado otorgarle un crédito. Se consulta empleando el número de identificación tributaria (NIT), fecha de nacimiento y nombre. Pero en continuidad con el ejemplo anterior, hemos dicho que a las personas se les identifica por código único de identificación (CUI). La solución es un same-as link.
Una circunstancia muy común a tener en cuenta es que no todos los sistemas proveen los business keys de forma consistente. Ejemplo: el negocio especifica que a los promotores se les identifica por nombre. Al obtener el nombre de promotor desde cada sistema resulta la siguiente inconsistencia "Brian Estrada" y "Brian Steve Estrada". Cuando se utilicen estos valores como identificación se considera al mismo promotor como dos promotores distintos. La solución es un same-as link.
Llaves surrogadas
En los modelos de los sistemas de información se le instruyó a los desarrolladores el uso de llaves surrogadas en las tablas, es así que la persona Brian Estrada tiene el cod_persona = 105. El uso del valor 105 no es recomendable, pues el propósito de estas llaves de negocio será unir la información de múltiples sistemas, y seguramente esas llaves surrogadas no se comparten entre sistemas. Existe una diferencia de este ejemplo con el de productos de belleza mencionado anteriormente al utilizar el valor 1034 como llave de negocio, ¿Por qué? Es posible hacer uso de este si así lo lo emplea el negocio. En ese ejemplo se menciona explícitamente que el negocio le asigna ese código a la vendedora y ella lo usa para comprar su producto (imaginando un modelo de ventas AVON o algo así).
Un ejemplo de lo poco recomendado sobre el uso de llaves surrogadas. Imagine que tiene el sistema de facturación, se registra los empleados y la tabla de empleados tiene el campo empleado_id 1, 2, 3...N. Por otro lado, se tiene un sistema de recursos humanos con su tabla empleados con el campo empleado_id 1, 2, 3...N. Y aún no termina, también se tiene un CRM con su tabla empleados con el campo empleado_id 1, 2, 3...N. Es muy posible que la llave surrogada sea distinta en cada sistema.
Llaves de negocio débiles
Llaves de negocio débiles
¿Las weak business keys? ¿Qué es eso? Vamos a ver. Imagina que estás a punto de comprar vivienda para la cual una empresa te genera una contrato de compra-venta. Sí, acabamos de descubrir el concepto de negocio contrato. Resulta que estas inconforme con ese contrato y después de algunas negociaciones han llegado a generar una nueva versión. Ahora identifiquemos la llave de negocio, ¿es el número de contrato o el número de contrato y la versión?. En definitiva depende mucho del negocio. Muy probable que versión será una llave de negocio débil y no será parte de la llave de negocio contrato. La versión será un Pegged-Link
Otras consideraciones
Otras consideraciones
Pero, ¿Qué sucede si no existe una llave de negocio disponible? Bien, debo decir que aún no me he topado con esta situación, sin embargo Dan Linstedt nos facilita algunas sugerencias:
- Observa si puedes combinar un conjunto de campos para encontrar un identificador único. De ser posible que sean descriptivos.
- Utiliza la llave surrogada del sistema fuente como llave de negocio, siempre y cuando el sistema de información lo tenga disponible para uso del negocio (al menos presente en las UI), de lo contrario algo puede salir muy mal. Solo imagínate que deciden hacer una migración de sistema y luego no se asignan los mismos índices. Problema grave!!
- No hay tercera opción. En este caso estas en un problema pues parece que ni el negocio al buen ojo es capaz de diferenciar una instancia de la otra de ese concepto de negocio.
Zero Records
Existen ocasiones donde se presenta la inexistencia de una relación de tipo asociativa. En estos caso s suele ser de utilidad el contar con un registro pivote que permita la apropiada ejecución de inner joins sin perder ninguna información. Para esto podemos definir el hash key 0x32 que representa un dato vacío que será utilizado para identificar la inexistencia de una llave de negocio. Generalmente estos casos se presentan cuando la llave foránea permite nulls en los sistemas de información o una tabla con relación de muchos-a-muchos no contiene una relación.
Business Hub
Cuando utilizamos una Same-as-link es posible que construir un hub sin duplicados, este hub derivado se considera un business hub.
Existen ocasiones donde se presenta la inexistencia de una relación de tipo asociativa. En estos caso s suele ser de utilidad el contar con un registro pivote que permita la apropiada ejecución de inner joins sin perder ninguna información. Para esto podemos definir el hash key 0x32 que representa un dato vacío que será utilizado para identificar la inexistencia de una llave de negocio. Generalmente estos casos se presentan cuando la llave foránea permite nulls en los sistemas de información o una tabla con relación de muchos-a-muchos no contiene una relación.
Business Hub
Cuando utilizamos una Same-as-link es posible que construir un hub sin duplicados, este hub derivado se considera un business hub.