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. 


No hay comentarios.:

Publicar un comentario