¡Participa de la Maratón Behind the Code, la competencia de programación más desafiante! Inscríbete aqui

Administración de Datos Referenciales (Reference Data Management)

Datos Maestros vs. Datos Referenciales

Sin importar el tipo de industria ya sea banca, telecomunicaciones, gobierno, salud, minorista, entre otros, todo el tiempo se almacenan y analizan datos, los cuales son utilizados para abrir nuevas cuentas, registrar a un nuevo proveedor, introducir nuevos productos y determinar las ofertas asociadas a sus clientes, entre otras cosas. Esta información es la que denominamos datos maestros, la cual se define como los datos que representan el valor más importante y crítico para una organización.

Estos datos, que representan las entidades clave del negocio (dominios) comúnmente participan dentro de diversas transacciones. Dichas transacciones provenientes de varias aplicaciones producen datos, que pueden ser de tipo financiero, logística, entre otros, relacionadas con el negocio en particular participando en distintos flujos desde la ejecución de una orden de compra hasta los cálculos del balance en un estado de cuenta bancario o las horas trabajadas en un desglose de nómina. A esta información se le denomina datos transaccionales.

Los metadatos, cuyo significado ambiguo es el de “datos acerca de los datos”, nos permiten describir la estructura de una entidad en particular, un ejemplo sencillo y común es el de un libro (entidad) y sus metadatos están relacionados con la descripción del mismo: autor, ISBN, año de publicación, editorial, entre otras.

Sin embargo, existe una categoría que encontramos presente en los datos maestros, transaccionales y los metadatos: los datos referenciales.

La definición es muy sencilla y se refiere a todos aquellos datos utilizados para categorizar otros datos usados en las aplicaciones y bases de datos. Comúnmente, están definidos en la forma de una clave (código) y su descripción en un conjunto de valores permitidos. Los datos referenciales son datos de solo lectura utilizados en transacciones y estas no pueden (no deben) modificar ni eliminar sus valores.

Con esta definición los ejemplos más simples y comunes que podemos encontrar son las listas de códigos de países, estados, monedas, entre otras.

Pero, ¿Por qué debería preocuparme?

Generalmente, los datos referenciales sufren cambios de manera poco frecuente; sin embargo, no dejan de ser actualizados con el tiempo, y este mismo factor ocasiona que algunas organizaciones no consideren una práctica en la administración de estos catálogos.

Conforme el número de sistemas crece y nuevos casos de uso son implementados, se vuelve aún mas caótico y riesgoso el poder sincronizar y administrar los datos referenciales dentro del negocio.

Al igual que como sucede con los datos maestros, diferentes aplicaciones utilizan distintos identificadores internos para representar valores de catálogos comunes. Y si estas aplicaciones están desarrolladas en lenguajes o plataformas distintas, se tendrían que mapear para poder representar los mismos valores de referencia.

¡Pero eso no es todo!, en ocasiones el mapeo entre aplicaciones no suele ser tan directo, pues la lógica o el modelo mediante el cual cada aplicación representa sus tablas de códigos contienen variaciones e inconsistencias siendo también un problema relacionado con la calidad de los datos. La siguiente figura representa un ejemplo de este mapeo.

Figure 1. Datos referenciales inconsistentes de códigos de Estado Civil
Alternative text for image

A diferencia de la administración de datos maestros, la administración de datos referenciales no está bien establecida como una disciplina. La dificultad de administrar los cambios sobre datos referenciales se encuentra relacionado a que no existen procesos de gobernabilidad establecidos, lo que ocasiona que las inconsistencias, variaciones, errores en mapeos, entre otros sean aceptados como una realidad del dia a día en las organizaciones.

Supongamos que se quisiera agregar un nuevo código de país, la empresa tendría que evaluar los siguientes cuestionamientos:

  • ¿Qué aplicaciones se afectarán con este cambio?
  • ¿Cuál será el impacto de agregar el nuevo código para cada aplicación y cómo deberá ser efectuado y coordinado?
  • ¿Qué mapeos se verán afectados y cuáles deberán actualizarse?
  • ¿Cuál es la contingencia para la gestión de datos en las aplicaciones que no pueden ser actualizadas o que necesitan ser cambiadas en un cronograma escalonado?
  • ¿Cómo se concilia este cambio con los datos registrados antes del cambio?

Además, existen datos referenciales externos a la organización, es decir, aquellos que son proveídos por un tercero que generalmente se encuentran definidos como estándares, como por ejemplo el estándar ISO 3166-1 que proporciona códigos para nombres de países y así reducir la tasa de error. Muchas organizaciones en el mundo como aquellas que manejan el correo postal, utilizan estos códigos. Ahora bien, si también este estándar llegara a ser actualizado con un nuevo código de país, ¿Cómo será la adopción de la norma modificada por los propietarios de aplicaciones para que sea controlada y administrada en el tiempo?

Otro ejemplo de datos referenciales externos, en este caso en México, se encuentra el Catálogo Nacional de Códigos Postales (SEPOMEX), que es elaborado por Correos de México y se proporciona en forma gratuita para usos particulares, este servicio también es muy utilizado por muchas empresas y organizaciones.

Figure 2. Catálogo Nacional de Códigos Postales (SEPOMEX)
Alternative text for image

Por lo tanto, aún cuando los cambios sean relativamente pequeños, estos pueden ocasionar problemas, pues muy pocas empresas conocen realmente cómo se están utilizando sus datos de referencia en cada una de sus aplicaciones y qué interdependencias existen entre ellos. Así, el impacto de realizar un cambio en algún código en una o más bases de datos y/o aplicaciones puede resultar muy difícil de evaluar y con altos costos asociados a riesgos de negocio: Si los datos de referencia se utilizan de forma incorrecta, las transacciones, aplicaciones o reportes no funcionarían correctamente y los productos o resultados podrían no ser los esperados.

Estructura de los datos referenciales

Pareciera que administrar datos referenciales es un trabajo sencillo cuando solo hablamos de catálogos de datos identificados por una clave y una descripción y/o valor. Sin embargo, existen datos referenciales que pueden tener una estructura más compleja llegando a establecer distintas jerarquías y relaciones entre ellos. Las jerarquías nos permiten definir precisamente las relaciones que existen entre estos valores para un conjunto determinado; y estas jerarquías pueden llegar a definir incluso relaciones entre valores de diferentes conjuntos de datos.

Jerarquías en forma de árbol

La jerarquía de árbol mantiene relaciones de tipo padre-hijo entre los valores dentro de un conjunto de datos donde cada valor es un nodo dentro de la jerarquía. Un ejemplo de este tipo de jerarquía es el estándar de códigos de industria NACE en la cual se representan diferentes subcategorías de actividades industriales.

Figure 3. Códigos NACE representados en InfoSphere MDM RDM Hub
Alternative text for image

En el caso de México, también existen estándares utilizados por el INEGI como el Sistema de Clasificación Industrial de América del Norte 2013 (SCIAN 2013), el cual tiene como objetivo homologar la información económica que se produce en el país, y con ello contribuir a la región de América del Norte. Esta estructura también establece ramas y subramas de códigos estableciendo diferentes sectores.

Figure 4. Ejemplo Lista SCIAN 2013
Alternative text for image

Jerarquías basadas en niveles

Las jerarquías en niveles son muy similares a las de árbol, con la diferencia que cada nivel dentro de la jerarquía es administrado y definido como un conjunto o tablas de datos referenciales independientes. Estructuralmente parecieran ser lo mismo, pero desde una perspectiva de gobierno de datos existen diferencias importantes. Con el modelo basado en niveles se pueden realizar cambios de forma independiente sobre cada conjunto por distintos stewards o administradores de manera que cada área pueda manejar su propio ciclo de vida sobre los cambios. Así, la gestión de datos se mantiene separada a cada nivel. El siguiente ejemplo muestra una jerarquía de tipo Geográfica, donde los subniveles País y Estado son considerados y administrados como otros conjuntos de datos referenciales independientes.

Figure 5. Ejemplo de una estructura basada en niveles
Alternative text for image

Jerarquías complejas

No todas las relaciones entre los datos son de tipo padre-hijo. En ciertos casos, las relaciones entre conjuntos de datos referenciales y los valores dentro de este conjunto se vuelve más compleja, llegando a definir o representar ontologías de estos datos. De manera que se vuelve aún mas complicado administrar las diferentes taxonomías de los términos utilizados por las aplicaciones empresariales.

Figure 6. Modelo para establecer taxonomías en datos referenciales
Alternative text for image

InfoSphere MDM Reference Data Management (RDM)

Como ya habíamos mencionado, los datos maestros son el conjunto común de objetos de negocio más críticos y que son el núcleo de la organización (clientes, productos, cuentas, proveedores, pacientes, etc.). La solución de MDM de IBM además de proveer distintas ediciones que permiten resolver casos de uso y estilos de implementación específicos para cada negocio, tiene el gran potencial de ser multidominio, esto es, que permite administrar diferentes entidades de datos maestros permitiendo extender su funcionalidad a nuevos dominios de información.

IBM InfoSphere MDM RDM Hub es un subcomponente muy particular de la plataforma MDM de IBM e introduce un nuevo dominio de datos que en este caso es el de los datos referenciales.

La solución RDM de IBM ofrece un enfoque MDM para la gestión de datos de referencia a nivel empresarial reduciendo el riesgo del negocio y proporcionando un enfoque más eficiente para la gestión de datos de referencia en toda la empresa. Considera una administración centralizada, auditoría, seguridad y los procesos del ciclo de vida en torno a la gestión y la distribución de los datos de referencia.

Existen tres objetos de dominio principales para modelar datos referenciales: sets, maps y hierarchies. Cada objeto soporta las operaciones CRUD estándar (como cualquier objeto de catálogo), además de el periodo de validez del dato, extensibilidad y el ciclo de vida.

  • Sets: Se refiere a la lista de valores de un elemento de datos para clasificarlos. También se conocen como tablas de códigos, tablas de búsqueda, listas de propiedades, y las listas de valores. El ejemplo común son los códigos de país. También tienen un atributo adicional, para las traducciones. Los nombres de los valores individuales se pueden traducir en cadenas distintas para cada país, por ejemplo, Nurse en inglés y Enfermera en español.
  • Maps: Los mapas son un tipo especial de relación entre conjuntos(sets), en particular, los mapas se utilizan para combinar valores en un conjunto de valores en otro conjunto. Por ejemplo: Los códigos de área telefónicos relacionados con el código de país o estado.
  • Hierarchies: Las jerarquías como se vio en la sección anterior son también una relación entre los valores de datos de referencia, pero son diferentes de un mapa. Un mapa es una lista de las relaciones entre los valores de los diferentes conjuntos, las jerarquías son una relación de los valores dentro de un conjunto y se conocen como conjunto de jerarquías. Las jerarquías pueden ser consumidas por una serie de sistemas de información de la empresa, pero son a menudo utilizadas por los sistemas de inteligencia de negocio, para su uso en los reportes.

InfoSphere MDM RDM Hub incluye servicios adicionales que son específicos para el dominio RDM. Estos servicios abordan el ciclo de vida, la seguridad y la administración de los objetos de RDM.

  • Ciclo de vida El ciclo de vida especifica cómo estos objetos se actualizan con el tiempo, y por quién. Algunos ejemplos de los estados son en proceso, pendiente de aprobación, aprobado, y eliminado.
  • Stewardship: RDM implementa un modelo de administración y de seguridad sobre los objetos de datos de referencia y sus estados del ciclo de vida. Diferentes usuarios pueden tener acceso a los diferentes objetos, basado en el atributo de la propiedad del objeto (que es una lista de grupos que tienen acceso al objeto).
  • Importación y exportación: RDM soporta servicios de importación y exportación de datos de referencia, en diversos formatos como CSV y XML. Para que los datos se conviertan en datos de referencia administrados, deben ser importados en el RDM Hub para que sean gestionados, y luego exportados de nuevo a los sistemas.

La gestión de datos referenciales es un aspecto clave de un programa de gobierno de datos. Un proyecto de RDM puede ser un buen punto de partida para la implementación de una iniciativa de gestión de datos maestros más amplia y estructurada.

Conclusiones

Muchas empresas luchan por mantener un seguimiento de los datos de referencia hoy en día mediante el uso de hojas de cálculo y procesos ad-hoc para registrar los cambios sobre los mapeos de sus datos de referencia, esto conlleva a un enfoque propenso a errores y con un uso intensivo de recursos. Los mapeos de datos de referencia son a menudo hechos con código duro (hard-coded) dentro de los procesos de integración de datos y se hacen de manera desactualizada sin considerar los cambios de los valores de datos de referencia tanto en aplicaciones origen como destino.

Los desajustes en los datos de referencia pueden tener un impacto importante en la calidad de los datos, la integridad de los reportes de inteligencia de negocios (BI), y es una causa común de los problemas en la integración de sistemas.

La falta de control en torno a la administración de datos de referencia puede ser un riesgo de negocio importante. En ocasiones, los datos de referencia se utilizan para conducir los procesos y aplicaciones de negocio clave, y utilizar el conjunto equivocado de datos de referencia puede tener importantes repercusiones futuras.

IBM es líder en el gobierno de datos y en la aplicación de un enfoque de gestión de datos maestros para la administración de datos de referencia. La solución RDM de IBM proporciona un dominio construido y una aplicación completa diseñada específicamente para la gestión de datos referenciales.

Recursos