sábado, 22 de febrero de 2014

Modelado Dimensional y Data Warehouse

Modelado Dimensional - Capitulo 6 KLC


Introducción:

Luego de pasar por un proceso de Análisis y levantamiento de requerimientos como primera fase de la metodología kimball, es necesario realizar un diseño lógico y físico del repositorio de datos. Para la realización de este diseño es recomendable la utilización de un modelado dimensional de manera que estos datos puedan ser  encontrados por los usuarios de una manera intuitiva y rapida. En el capitulo 6 del libro de KLC se estará explicando el uso del modelado dimensional de tal manera de explicar su funcionamiento ventajas y la diferencia que tiene contra del modelo entidad-relación.


Modelo Dimensional:

       El modelado dimensional es una forma de acercar los datos a la manera en que estos serán convertidos en información útil para los usuarios del negocio. La aplicación del modelo dimensional tiene lugar en la fase de diseño lógico, lo que permite la traducción del esquema resultante del diseño conceptual al plano lógico. El modelo dimensional se describe en el año 1996 por Ralph Kimball, como propuesta para el diseño de almacenes de datos (Data Warehouses), partiendo de la visión multidimensional que los usuarios tienen de los datos empresariales cuando se enfrentan a ellos con propósito de análisis (de análisis multidimensional –OLAP– en concreto).
El análisis multidimensional consiste en analizar los datos que hacen referencia a hechos, sean económicos o de otros tipos, desde la perspectiva de sus componentes o dimensiones (utilizando para ello algún tipo de métrica o medida de negocio).Este modelo tiene en cuenta que para el análisis multidimensional los datos se representan como si estuvieran en un espacio n-dimensional (cubo de datos), permitiendo su estudio en términos de hechos sujetos al análisis (facts, en inglés) y dimensiones que permiten diferentes puntos de vista por los que analizar esos hechos.
El modelo dimensional distingue tres elementos básicos:

  • Hechos: es la representación en el data warehouse de los procesos de negocio de la organización. Por ejemplo: una venta puede identificarse como un proceso de negocio. Los hechos se podrán reconocer además porque siempre tienen asociada una fecha, y una vez registrados no se modifican ni se eliminan (para no perder la historia).
  • Métrica: son los indicadores de negocio de un proceso de negocio. Aquellos conceptos cuantificables que permiten medir nuestro proceso de negocio. Por ejemplo, en una venta tenemos el importe de la misma y la cantidad vendida. Existen métricas derivadas, como el precio unitario, que se obtiene al dividir el importe total por las unidades vendidas.
  • Dimensión: es la representación en el data warehouse de un punto de vista para los hechos de cierto proceso de negocio. Si regresamos al ejemplo de una venta, para la misma tenemos el cliente que ha comprado, la fecha en la que se ha realizado, el producto vendido,… Estos conceptos pueden ser considerados como vistas para este proceso de negocio. Puede ser interesante recuperar todas las compras realizadas por un cliente, o para un producto o familia de productos, o para un lapso determinado.

Las Fortalezas de Modelado Dimensional:

El modelo tridimensional tiene un número de importantes ventajas de almacenamiento de datos que el modelo entidad-relación carece. En primer lugar, el modelo dimensional es un framework estandar predecible. Los escritores de informes, herramientas de consulta e interfaces de usuario pueden todos hacer fuerte suposiciones sobre el modelo tridimensional para que las interfaces de usuario sea más comprensible, y para hacer un proceso más eficiente.
 Por ejemplo , ya que casi todos las limitaciones establecidas por el usuario final proceden de las tablas de dimensiones, una herramienta de usuario final puede proporcionar alto rendimiento "navegar " a través de los atributos de una dimensión a través del uso de índices de bit de vector. Los metadatos pueden usar la cardinalidad conocida de valores en una dimensión para guiar el comportamiento de la interfaz de usuario
El uso de un optimizador de costos, basado en un motor de base de datos puede hacer suposiciones muy fuertes sobre el primer restringir en las tablas de dimensiones, y luego "atacar" a la tabla de hechos de una sola vez con el producto cartesiano de esas claves de tabla de dimensiones que satisfacen las restricciones del usuario. Sorprendentemente, en el uso de este enfoque es posible evaluar la N-maneras arbitrarias donde se une a una tabla de hechos en una sola pasando por el índice de la tabla de hechos. Estamos tan acostumbrados a pensar en la n-forma se une como "hard" que toda una generación de administradores de BD no se dan cuenta de que el n-maneras de unirse al problema es formalmente equivalente a un único tipo de combinación.

La relación entre el modelado tridimensional y modelado Entidad-Relación:


La clave para entender la relación entre el modelado tridimensional y la entidad-relación es que un solo diagrama entidad-relación se descompone en realidad múltiple diagramas de mesa. Piense en un gran diagrama entidad-relación como la representación de todos los posible de procesos de negocio en la empresa. El diagrama entidad-relación maestro puede tener llamadas de ventas, entrada de pedidos, facturas de envío, los pagos de los clientes y de productos devoluciones, todos en el mismo diagrama. En cierto modo, el diagrama entidad-relación en sí flaquea al representar en un diagrama de múltiples procesos que no conviven en datos individuales establecidos en un solo punto en el tiempo coherente. No es de extrañar que el diagrama entidad - relación es demasiado complejo. Así, el primer paso en la conversión de un diagrama de entidad-relación a un conjunto de diagramas de modelado dimensional es para separar el diagrama de entidad-relación en sus procesos de negocio discretos y modelar cada uno por separado.

El segundo paso es seleccionar los muchos-a-muchos en el modelo entidad-relación que contiene hechos que no son clave numérica y aditivos, y designarlos como tablas de hechos. 

El tercer paso es desnormalizar todas las tablas restantes en tablas planas con una sola pieza que se conectan directamente a las tablas de hechos. Estas tablas se convierten en las tablas de dimensiones. En los casos en que una tabla de dimensiones se conecta a más de una tabla de hechos, representamos a esta misma tabla de dimensiones en ambos esquemas, y nos referimos a las tablas de dimensiones como  "Conformada" entre los dos modelos dimensionales.


Data Warehouse - Capitulo 6 Pentaho Solutions


Introducción:

       En un almacén de datos lo que se quiere es contener datos que son necesarios o útiles para una organización, es decir, que se utiliza como un repositorio de datos para posteriormente transformarlos en información útil para el usuario. Un almacén de datos debe entregar la información correcta a la gente indicada en el momento óptimo y en el formato adecuado. El almacén de datos da respuesta a las necesidades de usuarios expertos, utilizando Sistemas de Soporte a Decisiones (DSS), Sistemas de información ejecutiva (EIS) o herramientas para hacer consultas o informes. Los usuarios finales pueden hacer fácilmente consultas sobre sus almacenes de datos sin tocar o afectar la operación del sistema.


     Como define textualmente Ralph Kimball la definición de almacén de datos como:  "una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis". 

       Ahora tenemos que enfocar la importancia de tener un data warehouse dentro de una organización, dando como beneficio final el darle al usuario una búsqueda de datos de manera intuitiva y rápida.

Por que tener un Data Warehouse dentro de una Organizacion?

      Las personas que nunca han estado expuestos al concepto de un almacén de datos,
a menudo se confunden acerca de la necesidad y el propósito de una base de datos especializada para fines de soporte de decisiones. Incluso después de que los datos son integrados, que son beneficios obvios de diferentes sistemas, el rendimiento de las consultas, los sistemas de código de alivio de consultas de larga ejecución y el seguimiento de la historia, se han explicado que no siempre está claro por qué la construcción de un almacén de datos es una buena idea. Bastante a menudo, estos usuarios se han acostumbrado a la recuperación o la obtención de datos de varias fuentes, incluyendo los datos que se les envió por e-mail, que luego de importación en una aplicación de hoja de cálculo que se utilizan para su posterior análisis y presentación de informes. 
No es necesario un data warehouse, ¿verdad? No es tan cierto, de hecho. Vamos a tratar de explicar por qué un almacén de datos es útil, desde la perspectiva de un usuario:

  • Toda la información está en un solo lugar: No más búsqueda bajo varias fuentes dispares de información o tratar de encontrar los archivos más antiguos en un desordenado e-mail sistema o estructura de carpetas. No hay necesidad de ya sea por la combinación de todo estos datos usted mismo, ya está integrado y listo para su uso.
  • Hasta a la fecha de la información: los datos en el almacén de datos son automáticamente cargados y actualizados de forma regular, lo que significa que nunca está fuera de fecha o vera la información antigua.
  • Acceso rápido: El almacén de datos está optimizado para una rápida recuperación de la información. El almacén de datos responde a sus consultas mucho más rápido que almacenes de archivos locales o archivos de correo electrónico.
  • No hay límites de tamaño: las hojas de cálculo se pueden almacenar sólo una cantidad limitada de datos y menudo tendrá que ser dividido en pedazos para acomodar toda la información requerida. Un almacén de datos puede almacenar una cantidad prácticamente ilimitada de datos así que no hay más la descarga de datos a una base de datos local o una nueva hoja de cálculo es requerida.
  • Fácil de entender: El almacén de datos es el modelo en términos de negocio y refleja la forma de ver a su organización. Usted no tiene que descifrar los acrónimos de tres letras que nadie entiende, sino que puede tener nombres claros para todos los elementos de datos.
  • Estandarizacion de datos:Todo se ajusta a las normas, lo que significa que hay es sólo una definición y un conjunto de valores para cada pieza de información. Un buen ejemplo de esto es la codificación de género. Algunos sistemas utilizan 0 y 1, un cierto uso de niños / niñas y otros usos M / F / U (para desconocida). todo traducciones a una sola definición estandarizada han sido atendidos.

Esta lista señala las ventajas de un almacén de datos, pero se basa en un 
importante premisa: que el almacén de datos está diseñado y construido correctamente. 


domingo, 9 de febrero de 2014

Ciclo de vida de Ralph Kimball



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.

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.
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.


¿Por qué es necesario construir un Data Warehouse?
Los sistemas de ingreso de transacciones se ven afectados por las consultas a sus bases de datos. Generalmente poseen informes predefinidos, y cualquier modificación a los mismos debe ser solicitado al departamento de sistemas, que será en definitiva quien evaluará si tiene los recursos humanos disponibles como para realizarlos. El Data Warehouse está separado de los sistemas transaccionales, por lo tanto las consultas no afectan la velocidad de registro de las operaciones. Se actualiza periódicamente, capturando datos de los distintos sistemas transaccionales. Una vez implementado, es importante elegir las herramientas de consulta al Data Warehouse, que permitan un alto grado de autonomía a los usuarios.
La pregunta más común con respecto a los Data Warehouses es:
Ya tengo la información en la base de datos, entonces ¿para qué necesito un repositorio adicional?
La respuesta a esto es que la base de datos, o cualquier otro sistema de archivos que está orientado a los sistemas de producción están diseñadas para tener un respuesta rápida a transacciones relativamente pequeñas: Emitir una factura, registrar un cheque, etc. No están orientadas hacia el proceso masivo de información para reportes.
En cambio el Data Warehouse se construye pensado en que tenga una gran capacidad para obtener reportes que involucren el procesamiento de enormes cantidades de información y en el menor tiempo posible.

Fases del ciclo de vida Kimball






  • Planificación del Proyecto.
Busca identificar  la definición y el alcance del proyecto de Data Warehouse, las justificaciones del negocio y evaluaciones de factibilidad. Se focaliza sobre recursos, perfiles, tareas, duraciones y secuencialidad.
Es independiente al negocio y sus requerimientos. Esta etapa identifica el escenario del proyecto para saber donde surge la necesidad del Data Warehouse. “Antes de comenzar un proyecto de Data Warehouse o Data Mart, hay que estar seguro si existe la demanda y donde la existe. Si no se tiene un solo usuario sponsor y no hay usuarios entusiasmados posponga el proyecto”.
Algunos factores asociados con esta etapa son:
·         Identificación de los tres Sponsors (usuarios).
·         Convincentes motivaciones del negocio.
·         Cooperación entre áreas y negocios de sistemas.
·         Cultura analítica de la organización y,
·         Análisis de factibilidad.

  • Definición de los requerimientos del negocio.
La técnica utilizada para nivelar los requerimientos de los analistas de negocio difiere de los enfoques tradicionalistas guiados por los datos (Inm92) (Gol99). Los diseñadores de los data warehouse deben entender los factores claves que guían al negocio para determinar efectivamente los requerimientos y traducirlos en consideraciones de diseño apropiadas, pues son la base para las tres etapas paralelas subsiguientes focalizadas en la tecnología, los datos y las aplicaciones, por lo cual es altamente critica y el diseño es el centro de atención del BDL (Business Dimensional Lifecyle).
  • Modelado dimensional.
Básicamente se comienza con una matriz donde se determina la dimensionalidad de cada indicador y luego se especifican los diferentes grados de detalle (atributos), dentro de cada concepto del negocio (dimensión), así como la granularidad de cada indicador (variable o métrica) y las jerarquías que dan forma al modelo dimensional del negocio (BDM) o mapa dimensional.
  • Diseño físico.
El diseño físico se focaliza sobre la selección de estructuras necesarias para soportar el diseño lógico. Los elementos principales de este proceso son la definición de convenciones estándares de nombres y seteos específicos del ambiente de la base de datos. La indexación y las estrategias de particionamiento son también determinadas etapas.
Uno de los problemas del modelado dimensional y a su implementación relacional es el llamado n-way join, el hecho de tener que hacer join de cada lookup contra la BT de una por vez. En algunos RDBMS esto se resuelve mediante el seteo de STAR JOIN en el motor mejorando el rendimiento en unas 60 veces por sobre la utilización del join secuencial en un equipo de iguales características. Esta técnica demanda la realización de un producto cartesiano, algunos motores no la proveen, pero en un modelo dimensional es más eficiente que hacer el join entre lookup´s u BT una a una.
  •  Diseño y desarrollo de presentación de datos.
Las principales sub-etapas de esta zona del ciclo de vida son: la extracción, la transformación y la carga (ETL process). Se definen como procesos de extracción a aquellos requeridos para obtener los datos que permitirán efectuar la carga del modelo físico acordado. Los procesos de transformación sirven para convertir o recodificar los datos fuente para cargar el modelo físico. Los procesos de carga de datos sirven para poblar el Data Warehouse. Ralph Kimball propone en esta etapa un PLAN de diez  pasos.
  •  Diseño de la Arquitectura Técnica
Los ambientes de data warehousing requieren la integración de numerosas tecnologías. Se debe tener en cuenta tres factores: los requerimientos del negocio, los actuales ambientes técnicos y las directrices técnicas estratégicas futuras planificadas para de esta forma poder establecer el diseño de la arquitectura técnica del ambiente de data warehousing.
Hay que tener un plan antes de comenzar, no es simplemente reoordenar y explotar la información. Al igual que en una contrucción, los planos sirven para comunicar los deseos entre los clientes y el arquitecto, como así también para medir esfuerzos y materiales necesarios para la obra (comunicación, planificación, flexibilidad y mantenimiento, documentación, productividad y reuso).
  •  Selección de Productos e Instalación
Utilizando el diseño de arquitectura técnica como marco, es necesario evaluar y seleccionar componentes específicos de la arquitectura como ser la plataforma de hardware, el motor de base de datos, la herramienta de ETL o el desarrollo pertinente, herramientas de acceso, etc.
Una vez evaluados y seleccionados los componentes determinados se procede con la instalación y prueba de los mismos en un ambiente integrado de data warehousing.
  •  Especificación de Aplicaciones para Usuarios Finales
Los diferentes roles o perfiles de usuarios determinan la interfase o ventana al warehouse. Herramientas de diseño de reportes y consultas avanzadas para analistas, tableros de control para gerentes, acceso mediante inter/intra net para usuarios internos/externos remotos, envío de información por dispositivos no estándares para usuarios internos/externos, etc.
Se clasifican a los usuarios según su perfil de consulta, desde usuarios con un perfil más estratégico y menos predecibles (power users) hasta usuarios netamente operacionales que consumen una serie de reportes estándares (final users) pasando por los usuarios gerenciales con uso de interfases push-button (EIS users).
  •  Desarrollo de Aplicaciones para Usuarios Finales
Siguiendo a la especificación de las aplicaciones para usuarios finales, el desarrollo de las aplicaciones de los usuarios finales involucra configuraciones del metadata y construcción de reportes específicos.
  •  Implementación
La implementación representa la convergencia de la tecnología, los datos y las aplicaciones de usuarios finales accesible desde el escritorio del usuario del negocio. Hay varios factores extras que aseguran el correcto funcionamiento de todas estas piezas, entre ellos se encuentran la capacitación, el soporte técnico, la comunicación, las estrategias de feedback. Todas estas tareas deben ser tenidas en cuenta antes de que cualquier usuario pueda tener acceso al data warehouse.
  •  Mantenimiento y crecimiento
Data Warehousing es un proceso (de etapas bien definidas, con comienzo y fin, pero de naturaleza espiral) pues acompaña a la evolución de la organización durante toda su historia. Se necesita continuar con los relevamientos de forma constante para poder seguir la evolución de las metas por conseguir. Según afirma Kimball [Kim98], “si se ha utilizado el BDL el data warehouse está preparado para evolucionar y crecer”.
Al contrario de los sistemas tradicionales, los cambios en el desarrollo deben ser vistos como signos de éxito y no de falla. Es importante establecer las prioridades para poder manejar los nuevos requerimientos de los usuarios y de esa forma poder evolucionar y crecer.