Los principales objetivos de este artículo se orientan hacia la construcción de un Datawarehouse que está dirigido fundamentalmente a responder de manera rápida a las solicitudes de análisis de los directivos de las empresas. Un lugar importante en la construcción del Datawarehouse lo ocupa el área de transformación de los datos, la cual varía en su complejidad en dependencia de los requerimientos del problema.
Palabras claves: datawarehouse, back room, área de transformación de datos, modelo dimensional
Para aquellos que desarrollan y mantienen los sistemas de datos haciéndolos disponibles para los directivos de las empresas, el término DataWareHouse o también conocido como Almacén de Datos, ofrece la solución como ubicación central para que todos puedan acceder a la información con los reportes necesarios, dando respuesta a necesidades de diferentes tipos de usuarios.
El Datawarehouse (en lo adelante nos referiremos como DWH) surgió con el objetivo de hacer consultable la información que se tiene de una empresa tanto de meses como de años anteriores.
El DWH organiza y orienta los datos desde la perspectiva del usuario final, mientras que los sistemas operacionales organizan sus datos desde la perspectiva de la aplicación, para lograr eficiencia en el acceso a datos.
Los principales objetivos de un Datawarehouse son:
- Comprender las necesidades de los usuarios por áreas dentro del negocio.
- Determinar qué decisiones se pueden tomar con la ayuda del DWH
- Seleccionar un subconjunto del sistema de fuentes de datos que sea el más efectivo y procesable para presentar el DWH.
- Asegurar que los datos sean precisos , correctos y confiables y que mantengan la consistencia .
- Monitorear continuamente la precisión y exactitud de los datos y el contenido de los reportes generados.
- Publicar los datos.
¿Por qué se justifica construir un Datawarehouse?
Generalmente, los sistemas transaccionales o OLTP usan estructuras normalizadas, en las cuales se optimizan las inserciones y actualizaciones de artículos e incluso algunas selecciones, pero es menos probable que el sistema se organice de forma tal que produzca reportes eficientes para datos resumidos con cierta jerarquía. Y es aquí donde debería usarse el DWH, que usa los datos relevantes de fuentes existentes y los combina en una estructura que ha sido optimizada para las selecciones.
Esta es la razón por la cual se construye un datawarehouse para solucionar la problemática de tener un sistema fuente transaccional corriendo sobre un servidor Novell. Esta información se necesita que esté consultable para los clientes de la empresa de forma remota y sin embargo, por problemas de seguridad no puede estar directamente disponible desde el mismo sistema fuente. El datawarehouse ha sido la solución propuesta para que la información sea utilizada por una aplicación cliente de acceso remoto. De esta forma se aprovecha la forma en que se organizan los datos en el almacén en el modelo dimensional y se brinda a la Gerencia un grupo de informaciones organizadas en cubos multidimensionales que les permite profundizar en el análisis de la información y ver su variación en el tiempo.
Un DWH debe tener cuatro características que son primarias . Es una colección de datos orientada a un tema , integrada, variable en el tiempo y no volátil que sea útil para la toma de decisiones.
Es orientada a un tema porque tiene en cuenta los procesos de negocio de la empresa que se deseen priorizar. Es integrado porque agrupa a todos los sistemas operacionales en un sistema de información con formatos y códigos consistentes. Es variante en el tiempo porque los datos se organizan y almacenan en jerarquías en el tiempo, lo que permiten análisis comparativos de estados actuales y de períodos anteriores. Es no volátil porque se usa principalmente para operaciones de recuperación de información y no para actualizaciones.
Los DWH están en la categoría de los sistemas para el soporte de decisiones (DSS) que tienen como objetivos medir y controlar el desarrollo de las variables importantes del negocio, buscando identificar, proyectar y predecir tendencias a partir de los datos acumulados.
Los datos que se manejan en el DWH son informacionales , esto significa que son datos resumidos y periódicos a diferencia de los datos operacionales.
Cuáles pudieran ser consultas típicas en este sistema para la toma de decisiones de la empresa?.
- ¿Cuál ha sido el total de ingresos de los clientes por meses y años?
- ¿Cuáles han sido los pagos realizados por los clientes y por qué conceptos?
- ¿Cuáles han sido las principales cadenas hoteleras que aportan a sus Casas Matrices?
Con la creación de un DWH, se persigue un sistema de fácil comprensión y de rápida ejecución que significa datos de alta calidad, con un diseño que permita los cambios y además, una salvaguarda segura para proteger la información.
Partes del DWH
El DWH necesita de tres áreas bien diferentes entre sí pero que se integran para lograr un buen funcionamiento:
- Los sistemas origen o fuentes legados .
- El área de transformación de los datos (en lo adelante nos referiremos como ATD)
- El Servidor de presentación del DWH
(Ver Anexo1)
Las fuentes legados son los sistemas de procesamiento que capturan las transacciones del negocio. Deben ser sistemas confiables y consistentes , aunque entre ellos hay marcadas diferencias en los formatos y las estructuras de los datos. Quedan fuera del DWH por lo que no tenemos el control sobre el contenido de sus datos.
El área de transformación de los datos (ATD) consta tanto del área de almacenamiento como del conjunto de procesos que se usan frecuentemente para la extracción, transformación y carga de los datos . Es generalmente la parte más compleja de esta arquitectura. Es todo lo que se presenta entre la fuente externa y el área de presentación de los datos.
El servidor de presentación es la fuente consultable de datos de la empresa. Es donde se organizan los datos del DWH , se almacenan y están disponibles para hacer consultas, reportes y acceder mediante aplicaciones.
Concretamente, el área de transformación de datos puede estar constituida por un grupo de servicios de transformación de datos que pueden ser implementados para mantener actualizada la información del almacén haciendo algunas transformaciones a los datos.
El DWH se soporta sobre el modelo dimensional a diferencia de los sistemas de bases de datos que están basados en el modelo Entidad-Relación. Este modelo contiene la misma información que el modelo E/R pero empaqueta los datos en un formato simétrico cuyo objetivo es ganar una mayor comprensión del usuario y garantizar la ejecución rápida y eficiente de las consultas. A diferencia del modelo E/R, el modelo dimensional no necesita anticipar las consultas que se van a realizar y es muy elástico a los cambios que se produzcan en los patrones de los usuarios.
El modelo dimensional divide el mundo de los datos en dos grandes tipos: las medidas y las descripciones del entorno de estas medidas. Las medidas, que generalmente son numéricas, se almacenan en las tablas de hechos y las descripciones de los entornos que son textuales se almacenan en las tablas de dimensiones. Las tablas de hechos son las tablas primarias en el modelo dimensional y contiene los valores del negocio. Los hechos más comunes son valores numéricos . Cada tabla representa una interrelación muchos – muchos y contiene dos o más llaves extranjeras que acoplan con sus respectivas tablas de dimensiones.
Las tablas de dimensiones son las compañeras de las tablas de hechos. Cada dimensión se define por su llave primaria que sirve para mantener la integridad referencial en la tabla de hechos a la que se acopla. Los atributos de estas tablas sirven de base a las solicitudes que se hacen al DWH.
Las tablas de dimensiones contienen información jerárquica que permitirán la realización de las agregaciones o las profundizaciones.
En el Anexo # 2 se muestra un modelo dimensional propuesto para una institución financiera basado en un esquema de estrella.
Para conformar la tabla de hechos se tuvo en cuenta el hecho principal del problema que es la operación financiera de un cliente, la cual se mide por el importe de la operación. En la operación intervienen además del código del cliente que hizo la operación, el desglose de la cuenta, la moneda en que se hizo, el concepto y la fecha y sobre estas descripciones se conformaron las dimensiones que se actualizan de los clasificadores del sistema fuente.
Para acceder al servidor de presentación se implementan las herramientas de acceso de datos del usuario final. Estas herramientas constituyen el cliente del DWH que mantiene una interacción con el servidor enviando a éste solicitudes SQL y devuelve los resultados ya sea en pantalla , o en un reporte o un gráfico o alguna otra forma superior de análisis para el usuario. Estas herramientas pueden ser tan simples como las consultas ad-hoc o tan complejas como la minería de datos . Las consultas ad-hoc se establecen cuando el usuario forma sus propias consultas manipulando directamente las tablas relacionales y sus conexiones . Se usa solamente por un 10% de todos los usuarios finales del DWH ya que el resto prefiere usar las aplicaciones.
Para dar uso al almacén y acceder de forma remota a esa información, se implementa una aplicación cliente basada en tecnología web aprovechando la ventaja de que esta aplicación se puede invocar desde cualquier máquina haciendo conexión remota independientemente del sistema operativo que tenga implantado. Las consultas que hace la aplicación al servidor de los datos se realizan invocando procedimientos almacenados que están en el servidor y que agilizan notablemente dichas consultas.
Otra de las herramientas que se utilizan en el Servidor de Presentación es el Procesamiento Analítico en Línea (OLAP), el cual permite crear vistas multidimensionales de los datos sobre las bases de datos tradicionales.
El procesamiento analítico en línea se puede ver como la síntesis, análisis y consolidación de grandes volúmenes de datos empresariales en la perspectiva de múltiples dimensiones tales como el tiempo, los clientes, las cadenas, las operaciones financieras, etc. Este análisis en línea de los datos puede utilizar fórmulas matemáticas y análisis estadísticos para consolidar y resumir los datos.
Los requerimientos del negocio son los que dirigen la arquitectura de diseño de un DW por lo que se debe tener bien claro todos los asuntos del negocio, las estrategias, los procesos, la disponibilidad y las expectativas de ejecución del negocio.
La arquitectura del DWH se convierte en el esquema de producción . Esta no es un plan de proyectos o una lista de tareas. Es el "qué" se debe hacer y no cómo y por qué. Desarrollar una arquitectura es difícil, pero posible y decisiva para el éxito del DWH. Está dirigida por el negocio, es decir, los requerimientos del negocio traen implicaciones técnicas sobre la arquitectura. Por ejemplo: las actualizaciones nocturnas conllevan a adecuar el procesamiento en el ATD; si se quiere tener una disponibilidad a nivel mundial se requiere de servidores distribuidos o paralelos; etc.
Back Room o Area de transformación de datos
El área técnica de una arquitectura de DWH se divide en dos subconjuntos: el back room y front room . El back room es la parte responsable de preparar los datos y el front room de entregarlos a los usuarios.
El back room es el área donde tienen lugar los procesos de transformación de los datos y coincide con el área de transformación de datos.
El principal interés de los administradores de las Base de datos y de sistema en esta parte es resolver el problema de tomar los datos correctos del punto A al punto B y hacer las transformaciones apropiadas en un tiempo adecuado.
Los almacenes de datos, en su mayoría, se encuentran en el back room del DWH en pequeños y medianos tamaños. Lo que usted necesita para su diseño depende en gran medida de los requerimientos de su problema y la complejidad de los procesos de extracción y transformación que va a desarrollar.
A modo de resumen, podemos plantear que para crear la arquitectura del back room es decisivo comprender la naturaleza de las fuentes de datos y qué formas van a tomar.
El área de transformación de datos es el banco de trabajo del DWH. Su propósito es dejar el dato listo para el servidor de presentación, ya sea un DBMS relacional o un motor OLAP.
Una característica distintiva de esta área es que aquí se crean las tablas de dimensiones, las cuales se replican en todos los mercados de datos que lo requieran.
Una vez que los datos se extraen del sistema fuente, se le aplican una serie de transformaciones para convertirlos en algo presentable a los usuarios y de valor para el negocio.
Los procesos en el ATD están guiados en esencia por metadatos que incluyen las reglas del negocio. Los metadatos se usan con herramientas administrativas para guiar las extracciones de los datos, transformaciones, archivo y carga en los mercados de datos y en el esquema del DWH.
Los metadatos se definen como datos acerca de los datos. Son como el mapa de carretera hacia los datos.
Se plantea que el proceso de creación y manejo de los datos en el DWH está formado por varios pasos de los cuales en su mayoría involucran metadatos y el DWH en su totalidad depende de ellos.
El catálogo de metadatos juega un papel decisivo en la arquitectura del DWH , ya que suministra los parámetros y la información que permite que la aplicación realice sus tareas; contiene un conjunto de información de control del DWH, su contenido, sus fuentes de origen y sus procesos.
Hasta este punto, el catálogo de datos es sólo un concepto lógico y cualquier cambio en él se reflejará en toda la arquitectura y estará disponible para todos los servicios a la vez.
En la mayoría de los casos, no es muy práctico traer toda la información a un solo lugar. Los metadatos existen en varias herramientas, programas y utilitarios que hacen que el DWH funcione.
Kimball [4] presentó un grupo de transformaciones que pudieran ser incluidas en el DWH que vamos a crear:
- Integración: implica generar llaves sustitutas para las dimensiones, mapear las llaves de un sistema con otro y mapear los códigos con las descripciones completas.
- Mantenimiento lento en los cambios en las dimensiones : identificar los valores que han cambiado y crear las llaves sustitutas asociadas es un proceso que encierra trucos en lugar de hechos matemáticos.
- Chequeo de integridad referencial : la integridad referencial significa que los datos en una tabla estén en correspondencia con sus iguales en la otra tabla. La integridad referencial se pudiera manejar a nivel de base de datos en vez de cómo parte del proceso de transformaciones pero reduciría su flexibilidad.
- Denormalización : convertir una jerarquía de tablas separadas en una dimensión es un proceso estándar de transformación del DWH. Este proceso consiste en abandonar las reglas de normalización y permitir los datos repetitivos con el objetivo de dar mayor comprensión y fácil ejecución a las consultas.
- Limpieza y depuración : limpiar los datos. Este es un proceso complejo especialmente con aquellos DWH que tienen que ver con entidades externas como clientes, compañías, doctores y pacientes, pero ya existen proveedores que ofrecen herramientas y servicios específicos para ello.
- Conversión del tipo de datos : Hacer transformaciones a bajo nivel que conviertan un tipo de datos o formato en otro. Por ejemplo: convertir las representaciones numéricas, de carácter de una base de datos a otra.
- Asignaciones y cálculos : Hacer transformaciones se aplican a las reglas del negocio que se identifican durante el proceso. Un ejemplo pudiera ser llevar a mayúsculas el campo nombre del usuario para hacer más legibles los reportes.
- Agregación : se maneja en el proceso de carga, en dependencia de los recursos que estén disponibles en cada etapa.
- Auditoría del contenido de los datos : Procesar sumas de chequeo, contadores de filas y chequearlos contra las fuentes para alertar cuando no se correspondan. Es imposible chequear todo, pero sí algunas pruebas sólidas ahorrarían gasto de tiempo y errores.
- Valores nulos : Identificar cuales son los valores sustitutos para los nulos y desarrollar reglas para manejarlos en las bases de datos.
Integridad referencial
El DWH como sistema de base de datos, debe mantener la integridad referencial y para implementarla, se procesan primero las dimensiones antes que los hechos. Se crean llaves sustitutas en el fichero de las dimensiones antes de cargarlo en el mercado de datos. La identificación de estas llaves consiste en una búsqueda en el fichero de forma secuencial.
Cada llave del DWH debe ser una llave sustituta pues debe ser flexible a los cambios en las descripciones y a las condiciones anormales que se produzcan en la fuente de datos, es por ello que se plantea que las llaves productoras pueden ser reusadas y reformateadas.
La correspondencia entre las llaves productoras y los valores de las dimensiones se lleva a cabo con una simple revisión a través de los datos fuentes y los datos de la tabla de dimensión.
Seguridad en el back room
La seguridad no es tan importante en el back room como en el front room. Esto se debe a que el back room es una actividad que tiene que ver con el desarrollo de aplicaciones y son suficientes las reglas de seguridad estándar de los sistemas. Sin embargo, debemos prestar atención al proceso de movimiento de los datos ya que si éstos se van a mover a través de la red aunque sea interna, siempre se paga caro y se corren riesgos. Es importante asegurarse de que se está utilizando un utilitario de transferencia de ficheros que use un protocolo seguro.
Otro aspecto a tener en cuenta en esta área es determinar quién va a tener accesos de administración al servidor de DWH y al software. Con respecto a este tema, Kimball [3] plantea que se ven situaciones donde no hay uno en el equipo que tenga privilegios de administración y otros casos, donde todo el mundo tiene acceso a todo. Ninguna de las dos es la correcta, porque en el primer caso si sucede una situación anormal en la máquina donde está el DWH, se necesitan privilegios de administración para resetearla y reiniciar todo de nuevo. Con respecto al segundo caso, lo general es no darle acceso a todo el mundo pues el servidor de DWH debe estar estrictamente controlado y solo se otorgan privilegios de administración a algunos miembros del equipo de DWH.
El concepto de DWH está teniendo una gran aplicación en la actualidad para el desarrollo de las empresas, como almacén de datos. Sus objetivos incluyen la reducción de los costes de almacenamiento y una mayor velocidad de respuesta frente a las consultas de los usuarios. Estos pueden ahora analizar y realizar preguntas sobre años, más que sobre meses de información.
Para diseñar una buena arquitectura de DWH es necesario como primer paso conocer bien los requerimientos del negocio y hacer un estudio profundo de las fuentes externas que nos van a suministrar los datos. Además, hacer un buen diseño del área de transformación de datos, cuáles son las transformaciones que se van a realizar y cómo se va a implementar el modelo dimensional con sus tablas de hechos y de dimensiones es el segundo paso a seguir.
Resumiendo los beneficios de la arquitectura del DWH :
- Provee un esquema de organización – cuáles son los componentes que la forman, cómo ellos se interrelacionan, quién es el dueño de cada parte y cuáles son las prioridades.
- Mejora la flexibilidad – permite que rápidamente se añadan nuevas fuentes de datos.
- Desarrollo rápido y reuso – los desarrolladores de DWH son más capaces de comprender el proceso de DWH , los contenidos de las bases de datos y las reglas del negocio más rápidamente.
- Herramientas de comunicaciones – define y comunica la dirección y el alcance de las expectativas , identifica los roles y responsabilidades y comunica los requerimientos al proveedor.
En general, podemos plantear que el Datawarehouse representa una oportunidad para estrechar las relaciones de las empresas con los clientes.
[1] Hadley L., "Developing a Data Warehouse Architecture", extraido el 28 de febrero de 2003 de http://www.users.qwest.net/~lauramh/resume .
[2] Kimball R., " Build your DataWarehouse one piece at a time" , Datawarehouse Designer, Octubre 2002. Extraido el 4 de marzo del 2003 de http://www.iemagazine.com/021030
[3] Kimball R., "Is Data Staging Relational?" DBMS, April 1998 . Extraido el 26 de febrero de 2003 de http://www.dbmsmag.com
[4] Kimball R., Laura Reeves, Margy Ross & Warren Thornthwaite, The Data Warehouse Life Cycle Toolkit, New York : John Wiley & Sons, 1998.
Para ver el gráfico seleccione la opción "Descargar" del menú superior
ANEXO # 2 ALMACEN DE DATOS – ESQUEMA DE ESTRELLA
MODELO DIMENSIONAL
Para ver el gráfico seleccione la opción "Descargar" del menú superior
Datos de la autora:
Dialys Nerely Pérez de Armas
Estudios realizados: Licenciada en Cibernética Matemática