Datawarehousing: Metodologia de Kimball y Herramientas de SQL Server 2005

Introducción

En la actualidad, las tecnologías de la información han automatizado los procesos de carácter típicamente repetitivo o administrativo, haciendo uso de lo que se denomina sistemas de información operacionales. Dichos sistemas resuelven las necesidades de funcionamiento de la empresa, donde sus principales características son la actualización y el tiempo de respuesta.

Las necesidades informacionales (necesidades de funcionamiento de la empresa), son aquellas que tienen por objeto obtener la información necesaria, que sirva de base para la toma de decisiones tanto a escala estratégica como táctica. Estas necesidades se basan en gran medida en el análisis de un número ingente de datos, en el que es tan importante el obtener un valor muy detallado de negocio como el valor totalizado para el mismo. Así también, es fundamental la visión histórica de todas las variables analizadas, y el análisis de los datos del entorno.

Cualquier actividad que realiza la empresa está reflejada de forma minuciosa en sus bases de datos, por lo tanto, esto puede derivarnos en diferentes problemas de tipo informacional. En primer lugar, al realizar consultas masivas de información, se puede ver perjudicado el nivel de servicio del resto de sistemas, dado que las consultas de las que estamos hablando, suelen ser bastante costosas en recursos. Dichas necesidades se ven insatisfechas por la limitada flexibilidad a la hora de navegar por la información y a su inconsistencia debido a la falta de una visión global En esta situación, el siguiente paso evolutivo ha venido siendo la generación de un entorno gemelo del operativo, que se ha denominado comúnmente Centro de Información,

En el Centro de Información, la información se refresca con menor periodicidad que en los entornos operacionales y los requerimientos en el nivel de servicio al usuario son más flexibles. Con esta estrategia se resuelve el problema de la planificación de recursos, ya que las aplicaciones que precisan un nivel de servicio alto usan el entorno operacional y las que precisan consultas masivas de información trabajan en el Centro de Información. La información mantiene la misma estructura que en las aplicaciones operacionales por lo que este tipo de consultas debe acceder a multitud de lugares para obtener el conjunto de datos deseado. El tiempo de respuesta a las solicitudes de información es excesivamente elevado.

Definición de Data Warehouse

Algunas definiciones de Data Warehouse.

• Un almacén de datos (Data Warehouse) es una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza. Es una estructura de datos donde la información contenida esta diseñada para favorecer el análisis y la divulgación eficiente de datos. Los almacenes de datos contienen a menudo grandes cantidades de información que se subdividen a veces en unidades lógicas más pequeñas dependiendo del subsistema de la entidad del que procedan o para el que sean necesario. Dichas unidades se denominan Data Marts.

• Un Data Warehouse es una Base de Datos que contiene:

• Datos empresariales

• Integrar colección de datos históricos

• Datos: dirigidos al usuario, consolidados y consistentes

• Datos estructurados para distribución y consultas

• Un Data Warehouse es un repositorio de datos de muy fácil acceso, alimentado de numerosas fuentes, transformadas en grupos de información sobre temas específicos de negocios, para permitir nuevas consultas, análisis, reportes y decisiones.

Existen dos grandes autores con respecto al tema Data Warehouse: Bill Inmon y Ralph Kimball.

• Bill Inmon: "El Data Warehouse es una colección de datos orientados al tema, integrados, no volátiles e historiados, organizados para el apoyo de un proceso de ayuda a la decisión"

• Ralph Kimball: "El Data Warehouse es una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis; es la unión de todos los Data Marts de una entidad".

Arquitectura de un Data Warehouse

La arquitectura de un Data Warehouse se la utiliza para representar cual es la estructura final de los datos, la forma en que se comunican esos datos, su procesamiento y presentación. La misma esta constituida por diferentes partes que se encuentran interconectadas, las cuales son:

• Base de datos operacional / Nivel de base de datos externo: los sistemas operacionales procesan datos para apoyar las necesidades operacionales críticas. Para hacer eso, se han creado las bases de datos operacionales históricas que proveen una estructura de procesamiento eficiente, para un numero relativamente pequeño de transacciones comerciales bien definidas.

A causa del enfoque limitado de los sistemas operacionales, las bases de datos diseñadas para soportar estos sistemas, tienen dificultad para acceder a los datos para otra gestión o propósitos informáticos. Ciertamente, la meta del Data Warehousing, es liberar la información que es almacenada en bases de datos operacionales y combinarla con la información desde otra fuente de datos, generalmente externa.

• Nivel de acceso a la información: El nivel de acceso a la información de la arquitectura Data Warehouse, es el nivel del que el usuario final se encarga directamente. En particular, representa las herramientas que el usuario final normalmente usa día a día. Actualmente, existen herramientas más y más sofisticadas para manipular, analizar y presentar los datos, sin embargo, hay problemas significativos al tratar de convertir los datos tal como han sido recolectados y que se encuentran contenidos en los sistemas operacionales en información fácil y transparente para las herramientas de los usuarios finales.

Una de las claves para esto es encontrar un lenguaje de datos común que puede usarse a través de toda la empresa

• Nivel de acceso a los datos: El nivel de acceso a los datos de la arquitectura Data Warehouse está involucrado con el nivel de acceso a la información para relacionarse con el nivel operacional. El nivel de acceso a los datos no solamente conecta DBMS"s diferentes y sistemas de archivos sobre el mismo hardware, sino también a los fabricantes y protocolos de red.

Una de las claves de una estrategia Data Warehousing es proveer a los usuarios finales con "acceso a datos universales", significa que, por lo menos, los usuarios finales sin tener en cuenta la herramienta de acceso a la información o ubicación, deberían ser capaces de acceder a cualquier o todos los datos en la empresa que es necesaria para ellos, para hacer su trabajo. El nivel de acceso a los datos es responsable de la interfaz entre las herramientas de acceso a la información y las bases de datos operacionales. En algunos casos, esto es todo lo que un usuario final necesita.

• Nivel de directorio de datos (Metadata): A fin de proveer el acceso a los datos universales, es absolutamente necesario mantener alguna forma de directorio de datos o repositorio de la información Metadata. La Metadata es la información alrededor de los datos dentro de la empresa.

A fin de tener un depósito totalmente funcional, es necesario tener una variedad de Metadata disponibles, información sobre las vistas de datos de los usuarios finales e información sobre las bases de datos operacionales. Idealmente, los usuarios finales deberían de acceder a los datos desde el Data Warehouse o desde las bases de datos operacionales, sin tener que conocer dónde residen los datos o la forma en que se han almacenados.

• Nivel de gestión de proceso: El nivel de gestión de procesos tiene que ver con la programación de diversas tareas que deben realizarse para construir y mantener el Data Warehouse y la información del directorio de datos.

Este nivel puede depender del alto nivel de control de trabajo para muchos procesos (procedimientos) que deben ocurrir para mantener el Data Warehouse actualizado.

• Nivel de mensaje de la aplicación: El nivel de mensaje de la aplicación tiene que ver con el transporte de información alrededor de la red de la empresa. El mensaje de aplicación se refiere también como "subproducto", pero puede involucrar sólo protocolos de red.

• Nivel de DW: En el Data Warehouse (núcleo) es donde ocurre la data actual, usada principalmente para usos estratégicos. Se puede pensar del Data Warehouse simplemente como una vista lógica o virtual de datos.

En un Data Warehouse físico (copias), en algunos casos, muchas copias de datos operacionales y/o externos, son almacenadas realmente en una forma que es fácil de acceder y es altamente flexible.

• Nivel de organización de datos: El componente final de la arquitectura Data Warehouse es la organización de los datos. También denominada gestión de copia o réplica, incluye todos los procesos necesarios como seleccionar, editar, resumir, combinar y cargar datos en el depósito y acceder a la información desde bases de datos operacionales y/o externas.

La organización de datos involucra con frecuencia una programación compleja, donde se están creando las herramientas Data Warehousing para ayudar en este proceso.

Objetivos de un Data Warehouse

Los objetivos fundamentales de un Data Warehouse son:

• Hacer que la información de la organización sea accesible, donde los contenidos del Data Warehouse son entendibles (información correcta y obvia) y navegables (reconocer el destino en la pantalla), y el acceso a e ellos son caracterizados por el rápido desempeño (cero tiempo de espera). Estos requerimientos no tiene fronteras y tampoco limites fijos.

• Hacer que la información de la organización sea consistente. La información de una parte de la organización puede hacerse coincidir con la información de la otra parte de la organización.

• Proporcionar información adaptable y elástica. El Data Warehouse esta diseñado para cambios continuos. Al realizarse nuevas preguntas o agregar datos nuevos sobre el Data Warehouse, los datos existentes y las tecnologías no cambian ni se corrompen.

• Es un seguro baluarte que protege los valores de la información. El Data Warehouse controla el acceso efectivo a los datos, como así también da a los "dueños" de la información gran visibilidad en el uso y abusos de los datos.

• Es la fundación de la toma de decisiones. El Data Warehouse tiene los datos correctos para soportar la toma de decisiones.

Elementos y Procesos básicos de un Data Warehouse

Los elementos básicos de un Data Warehouse son los siguientes:

• Sistema Fuente. Son los sistemas operacionales (Legacy System) de registros que tienen como función capturar las transacciones del negocio.

• Área de tráfico de datos. Es un área de almacenamiento y grupo de procesos, que limpian, transforman, combinan, guardan, archivan, etc., los datos fuentes para ser usados en el Data Warehouse.

• Servidor de presentación. Es la maquina física donde los datos del Data Warehouse son organizados y almacenados por consultas realizada por los usuarios finales, reportes y otra aplicaciones.

• Modelo dimensional. Es una disciplina específica para el modelado de datos que es una alternativa para los modelos de entidad-relación (DER).

• Procesos de negocios. Es un coherente grupo de actividades de negocio que le dan sentido a los usuarios del negocio del Data Warehouse.

• Data Mart. Es un subgrupo lógico del Data Warehouse.

• Data Warehouse. Es la unión de todos los Data Marts que la constituyen.

• Almacenamiento operacional de datos. Es el punto de integración por los sistemas operacionales. Es el acceso al soporte de decisiones de los ejecutivos de una empresa.

• OLAP. Es un estilo dimensional específico de búsquedas y presentación de información, que es ejemplificado por vendedores de OLAP.

• ROLAP. Es un grupo de interfaces de usuarios y aplicaciones que le dan a la base de datos relacional un estilo dimensional.

• MOLAP. Es un grupo de interfaces de usuarios, aplicaciones y propietarios de tecnología de bases de datos que tienen un fuerte estilo dimensional.

• Aplicaciones para usuarios finales. Es una colección de herramientas que hacen las consultas, las analizan y luego presentan la información necesaria y objetiva para el soporte de las necesidades de negocio.

• Herramientas de acceso a datos por usuarios finales. Son los "clientes" del Data Warehouse

• Modelado de aplicaciones. Es un sofisticado tipo de cliente de Data Warehouse con capacidades analíticas que transforma o difiere las salidas del Data Warehouse

• Meta Data. Es toda la información en el "ambiente" del Data Warehouse. No son los datos actuales.

Procesos Básicos del Data Warehouse (ETL)

Los procesos básicos del Data Warehouse son:

• Extracción: es el primer paso de obtener información hacia el ambiente del Data Warehouse. Consiste en extraer los datos desde los sistemas de origen. Cada sistema separado puede usar una organización diferente de los datos o formatos distintos. La extracción convierte los datos a un formato preparado para iniciar el proceso de transformación.

Un parte intrínseca del proceso de extracción es la de analizar los datos extraídos, se realiza un chequeo, el cual verifica si los datos cumplen la pauta o estructura que se esperaba. Si no es así son rechazados.

• Transformación: luego de que la información fue extraída, se pueden realizar diferentes pasos de transformación, como ser: limpieza de la información, botar a la basura lo que consideramos innecesario, seleccionar campos específicos que consideremos necesarios para el Data Warehouse, realizar combinaciones fuentes de datos, etc.

• Carga: al final del proceso de transformación, los datos están en forma para ser cargados. Dependiendo de los requerimientos de la organización, este proceso puede abarcar una amplia variedad de acciones diferentes.

Las formas mas básicas para desarrollar el proceso de carga son dos:

• Acumulación simple: consiste en realiza un resumen de todas las transacciones comprendida en el periodo de tiempo seleccionado y transportar el resultado como una única transacción hacia el Data Warehouse para su almacenamiento.

• Rolling: almacena información resumida a distintos niveles, correspondientes a distintas agrupaciones de la unidad de tiempo o diferentes niveles jerárquicos. (Casos de varios niveles de granularidad)

Metodología de Ralph Kimball

La metodología de Kimball, llamada Modelo Dimensional (Dimensional Modeling), se basa en lo que se denomina Ciclo de Vida Dimensional del Negocio (Business Dimensional Lifecycle). Esta metodología es considerada una de las técnicas favoritas a la hora de construir un Data Warehouse.

En el Modelo Dimensional se constituyen modelos de tablas y relaciones con el propósito de optimizar la toma de decisiones, con base en las consultas hechas en una base de datos relacional que están ligadas con la medición o un conjunto de mediciones de los resultados de los procesos de negocio.

El Modelo Dimensional es una técnica de diseño lógico que tiene como objetivo presentar los datos dentro de un marco de trabajo estándar e intuitivo, para permitir su acceso con un alto rendimiento. Cada Modelo Dimensional esta compuesta por una tabla con una llave combinada, llamada tabla de hechos, y con un conjunto de tablas más pequeñas llamadas tablas de dimensiones. Los elementos de estas tablas se pueden definir de la siguiente manera:

• Hechos: es una colección de piezas de datos y datos de contexto. Cada hecho representa una parte del negocio, una transacción o un evento.

• Dimensiones: es una colección de miembros, unidades o individuos del mismo tipo.

• Medidas: son atributos numéricos de un hecho que representan el comportamiento del negocio relativo a una dimensión.

Cada punto de entrada a la tabla de hechos esta conectado esta conectado a una dimensión, lo que permite determinar el contexto de los hechos.

Una base de datos dimensional se puede concebir como un cubo de tres o cuatro dimensiones (OLAP), en el que los usuarios pueden acceder a un porción de la base de datos a lo largo de cualquiera de sus dimensiones.

Dado que es muy común representar a un modelo dimensional como un tabla de hechos rodeada por las tablas de dimensiones, frecuentemente se le denomina también modelo estrella o esquema de estrella-unión

Otra variante es la que se conoce como snowflake o copo de nieve, en donde se presentan ramificaciones a partir de las tablas de dimensiones y no solo a partir de la tabla de hechos.

Ciclo de Vida Dimensional del Negocio

La metodología propuesta por Kimball, esta compuesta por las siguientes fases:

• Planificación del Proyecto: busca identificar la definición y el alcance que tiene el proyecto de DWH. Esta etapa se concentra sobre la definición del proyecto, donde, a nivel de planificación, se establece la identidad del mismo, el personal, desarrollo del plan de proyecto, el seguimiento y la monitorización.

• Definición de los Requerimientos del Negocio: es un factor determinante en el éxito de un proceso de DWH. Los diseñadores de los Data Warehouse deben tener en claro cuales son los factores claves que guían el negocio para determinar efectivamente los requerimientos y traducirlos en consideraciones de diseño apropiadas.

• Modelado Dimensional: se comienza con una matriz donde se determina la dimensionalidad de cada indicador para luego especificar los diferentes grados de detalle dentro de cada concepto del negocio.

• Diseño Físico: se centra en la selección de las estructuras necesarias para soportar el diseño lógico. Un elemento principal de este proceso es la definición de estándares del entorno de la base de datos. La indexación y las estrategias de particionamiento se determinan en esta etapa.

• Diseño y Desarrollo de la presentación de datos: tiene como principales actividades la extracción, transformación y carga (ETL). Estas actividades son altamente críticas ya que tienen que ver con la materia prima del Data Warehouse que son los datos.

• Diseño de la arquitectura técnica: en esta fase se deben tener en cuenta tres factores: los requerimientos de negocio, los actuales entornos técnicos, y las directrices técnicas y estratégicas futuras planificadas por la compañía, lo que permitirá establecer el diseño de la arquitectura técnica del entorno del Data Warehouse.

El proceso de diseño de la arquitectura técnica esta compuesto de 8 pasos:

• 1. Establecer un grupo de trabajo de arquitectura

• 2. Requisitos relacionados con la arquitectura

• 3. Documento de requisitos arquitectónicos

• 4. Desarrollo de un modelo arquitectónico de alto nivel

• 5. Diseño y especificación de los subsistemas

• 6. Determinar las fases de aplicación de la arquitectura

• 7. Documento de la arquitectura técnica

• 8. Revisar y finalizar la arquitectura técnica

• Selección de productos e instalación: se evalua y selecciona cuales son los componentes necesarios específicos de la arquitectura (plataforma de hardware, motor de la BD, herramienta de ETL, etc).

Luego de realizar la instalación de los componentes previamente evualados y seleccionados, se recomienda una serie de premisas:

• Comprender el proceso de compras corporativas

• Elaborar una matriz de evaluación del producto

• Realizar la investigación de mercados

• Filtrar opciones y realizar evaluaciones mas detalladas

• Manejo de un prototipo

• Selección del producto, instalación y negociación

• Especificación de Aplicaciones para usuario finales: se identifican los roles o perfiles de usuarios para los diferentes tipos de aplicaciones necesarias en base al alcance de los perfiles detectados.

• Desarrollo de aplicaciones para usuario finales: involucra configuraciones de los metadatos y construcción de reportes específicos.

• Implementación: representa el correcto funcionamiento de la tecnología, los datos y las aplicaciones de usuarios finales accesibles para el usuario del negocio.

• Mantenimiento y crecimiento: se basa en la necesidad de continuar con las actualizaciones de forma constante para así lograr la evolución de las metas por conseguir.

• Gestión del proyecto: asegura que todas las actividades del ciclo de vida se lleven a cabo de manera sincronizada.

Herramienta SQL SERVER 2005

SQL Server 2005 es un sistema para la gestión de bases de datos producida por Microsoft basado en el modelo relacional. Microsoft SQL Server 2005 es una completa inteligencia de negocios que ofrece las características, herramientas y funcionalidades para crear tipos clásicos e innovadores de aplicaciones analíticas.

Las herramientas más utilizadas para el desarrollo y administración de SQL Server 2005 son:

• Base de datos relacional: Un motor de base de datos relacional más seguro, confiable, escalable y altamente disponible con el mejor rendimiento y compatible para datos estructurados y sin estructura (XML).

• Servicios de replica: Replica de datos para aplicaciones de procesamiento de datos distribuidas o móviles, alta disponibilidad de los sistemas, concurrencia escalable con almacenes de datos secundarios para soluciones de información empresarial e integración con sistemas heterogéneos, incluidas las bases de datos Oracle existentes.

• Notification Services: Capacidades avanzadas de notificación para el desarrollo y el despliegue de aplicaciones escalables que pueden entregar actualizaciones de información personalizadas y oportunas a una diversidad de dispositivos conectados y móviles.

• Integration Services: Capacidades de extracción, transformación y carga (ELT) de datos para almacenamiento e integración de datos en toda la empresa.

• Analysis Services: Capacidades de procesamiento analítico en línea (OLAP) para el análisis rápido y sofisticado de conjunto de datos grandes y complejos, utilizando almacenamiento multidimensional.

• Reporting Services: Una solución global para crear, administrar y proporcionar tanto informes tradicionales orientados al papel como informes interactivos basados en la Web.

• Herramientas de administración: incluye herramientas integradas de administración para administración y optimización avanzadas de bases de datos, así como también integración directa con otras herramientas. Los protocolos de acceso de datos estándar reducen drásticamente el tiempo que demanda integrar los datos en SQL Server con los sistemas existentes. Asimismo, el soporte de servicio Web nativo está incorporado en SQL Server para garantizar la interoperabilidad con otras aplicaciones y plataformas.

• Herramientas de desarrollo: SQL Server ofrece herramientas integrada de desarrollo para el motor de base de datos, extracción, transformación y carga de datos, minería de datos, OLAP e informes que están directamente integrados con Microsoft Visual Studio para ofrecer capacidades de desarrollo de aplicación de extremo a extremo. Cada subsistema principal en SQL Server se entrega con su propio modelo de objeto y conjunto de interfaces del programa de aplicación (API) para ampliar el sistema de datos en cualquier dirección que sea especifica de su negocio.

Conclusión

  La metodología Kimball conduce a una solución completa en una cantidad de tiempo relativamente pequeña. Además, debido a la gran cantidad de documentación que se puede encontrar y a los numerosos ejemplos aportados en diferentes entornos, permite encontrar una respuesta a casi todas las preguntas que puedan surgir, sobre todo cuando no se dispone de la experiencia previa necesaria.

Por otro lado, este tipo de metodología bottom-up permite que, partiendo de cero, podamos empezar a obtener información útil en cuestión de días y después de los prototipos iniciales, comenzar el ciclo de vida normal que nos ofrezca una solución completa de BI.

Los Data Marts resultantes son fácilmente consultables tanto para los desarrolladores como para los usuarios finales. La relación directa entre los hechos y dimensiones conceden a cualquier usuario la posibilidad de construir consultas muy sencillas, la mayoría de las veces sin tener a mano la documentación de los metadatos.

La metodología de Kimball es ideal para los primeros pasos de implantación de BI a un cliente, cuando la complejidad de almacenamiento de datos no es demasiado grande y donde la infraestructura del BI se encarga de los datos procedentes de un número limitado de fuentes. Sin embargo, cuando el almacén de datos adquiere complejidad, entonces es peligroso forzar el desarrollo de esta metodología. En el mundo del BI, cuando las cosas adquieren gran complejidad, es el momento de introducir nuevos enfoques al problema, como el propuesto por Inmon.

Bibliografía

 Bibliografía utilizada para realizar la monografía

• R. Kimball: The Data Warehouse Toolkit. Ed. John Wiley, 1996.

• R. Kimball: The Data Warehouse Lifecycle Toolkit. Ed. John Wiley, 1998

• http://www.microsoft.com

• http://www.wikipedia.com

Autor:

Musso, Pablo Federico