Curso de Modelado Dimensional - Capitulo 6 KLC
Introduccion:
En este capítulo se identifica una serie de cuestiones de
modelado tridimensionales avanzados y se proporcionan guías específicas para el
manejo de cada situación. La primera sección trata de un conjunto extendido de tabla de dimensiones y diseños, en la segunda sección se describen problemas específicos
de tabla de hechos. En la última sección se analizan algunas de las más
difíciles preguntas posibles en un entorno de data warehouse.
Tablas de Dimension Extendida:
En esta seccion se describe un numero de situaciones comunes de modelado dimensional en las cuales la construccion de su estructura puede ser de una manera efectiva, y tambien se plantea la situacion en la cual esta estructura puede ser construida de manera equivocada.
- Dimension Mucho-a-Mucho: En una serie de situaciones de diseño clásico de la existencia y el grano de la tabla de hechos es fácilmente entendible y muy fundamental la existencia de cada una de las dimensiones adjuntas a los registros de la tabla de hechos es obvio y no controversial. Pero una de las dimensiones puede legítimamente tener muchos valores. A menudo, la dimensión infractor puede legítimamente tener cero, uno, o muchos valores para un registro dado. El número de valores de la dimensión de tal registro hecho no es cognoscible antes de crear el registro de la tabla hecho. En cierto sentido, el número de valores para esta dimensión es un hecho medido. Llamamos a este tipo de medida a muchos-a-muchos.
- El problema para el diseñador es qué hacer por ejemplo con la dimensión del diagnóstico de un paciente de un hospital. Los pacientes a veces tienen más de un diagnóstico. Los pacientes realmente enfermos en un hospital pueden tener como hasta diez diagnósticos. Para manejar este carácter abierto, no podemos añadir varias dimensiones de diagnóstico en el esquema. No sabemos lo que la cota superior extrema es para el número de diagnósticos, pero tal esquema sería difícil de consultar. O se une a través de las dimensiones son un anatema para los sistemas relacionales y del SQL Agrupar por falla lógica.
- Dimension Mucho-a-uno-a-Mucho: Vale la pena señalar que hay algunas situaciones sencillas donde lo que parece ser obvio en las combinaciones entre las tablas no devuelven los resultados correctos en cualquier sistema relacional. Considere el caso en el que los clientes desean crear pedidos de productos, y los mismos clientes devolver los productos. Hay una relación de uno a varios entre los clientes y el orden, y otra relación uno-a-muchos entre el cliente y el retorno. Las órdenes y las tablas de rendimientos se supone que tienen diferentes cardinalidades. En otras palabras, no todos los retorno se corresponde exactamente con una sola orden.
- Parecería obvio que para crear un informe mostrando los pedidos y devoluciones por parte del cliente se deben unir las mesas entre sí. Esta unión simultánea no devuelve la respuesta correcta en un sistema relacional de gestión de base de datos (DBMS). Afortunadamente, este problema se puede evitar fácilmente. nosotros simplemente emitimos multipass SQL y consultamos la tabla de pedidos y la tabla de rendimientos en separadas consultas, exterior a participar en los dos conjuntos de respuestas sobre el encabezado de fila del cliente.
- Dimension Juego de Role: Un role en un almacén de datos es una situación en la que aparece una sola dimensión en varias ocasiones en la misma tabla de hechos. Esto puede suceder en un número de maneras. Por ejemplo, en ciertos tipos de tablas de hechos, el tiempo pueden aparecer repetidamente. Por ejemplo, podemos construir una tabla de hechos para registrar el estado y la disposición final de un pedido de un cliente. Este tipo de tabla de hechos es llamada tabla de hechos instantánea acumulando.
- El uso de un role embebido, como la ubicación, en una variedad de dimensiones más grandes no relacionados, es uno de los pocos lugares en los que nos animan y apoyan a snowflaking. En otras palabras, nos recomendaría la creación de una unión de cada una de las tablas que se necesitan para describir la ubicación de un clon de la tabla de ubicación. Nosotros necesitamos vistas separadas para cada uso de la tabla de ubicación, con cuidado para crear nombres de las columnas distinguibles. Estos puntos de vista se utilizan después para unirse a sus respectivas dimensiones más grandes, como el número de teléfono de trabajo.
Tabla de echos Extendida:
En esta sección se describe una serie de situaciones en que un modelo común de tabla de hechos es muy eficaz o por el contrario, donde el diseñador puede elegir un diseño ineficiente.
- Datos de diferente granularidad y asignación: El modelo dimensional gana poder como los registros de hechos individuales se vuelven más y más atómica. En el nivel más bajo de transacción individual o individuo instantáneo en el tiempo, el diseño es más potente porque:
- Más de los atributos descriptivos tienen valores únicos.
- El diseño soporta con gracia sorpresas en forma de nuevos hechos, nuevas dimensiones, o nuevos atributos dentro de las dimensiones existentes. Estos nuevos elementos de datos por lo general se pueden añadir al diseño existente sin desentrañar los procedimientos administrativos existentes o consultas e informes existentes.
- Por lo general, más expresividad al nivel más bajo de granularidad, y, por tanto, más dimensiones tienen sentido en este nivel. Por ejemplo, a menudo se puede conectar una dimensión empleado a una transacción de cliente que representa el empleado, el cliente agente o el oficial de préstamo, pero esta dimensión empleado no puede tener sentido lógico en un registro resumen mensual o a través de múltiples clientes.
Cuando el diseñador se enfrenta a hechos de diferente granularidad, la primera respuesta debe ser para tratar de obligar a todos los hechos hasta el nivel más bajo. Podemos referirse ampliamente a esta procedimiento que "la asignación de" lo hechos de alto nivel para el nivel bajo. Hay muchos, muchos ejemplos de la necesidad de asignar en un almacén de datos. El ejemplo más generalizado es la necesidad de asignar los costos. Por ejemplo, en una factura de envío, puede haber un envío costaría para toda la factura que en un principio no se ha asignado a la partida individual.
- Hora del día: El seguimiento a escala fina de las transacciones individuales podrá introducir una fecha y un tiempo significativo para estampar en los datos que están disponibles para ese minuto o incluso ese segundo. En este caso, lo que hacemos es no crear una dimensión de tiempo con un registro por cada minuto o segundo en la totalidad. Por lo general, las nociones de día son muy distintas de las nociones de tiempo dentro de la día. La medida del día está virtualmente expresada como una clave sustituta a una dimensión de pleno derecho de la tabla día que contiene la información del calendario. Pero la medida de tiempo de día puede ser mejor expresado como un hecho numérico simple en lugar de como una dimensión, a menos que haya descripciones textuales de ciertos períodos dentro de días que son significativas, como la comida Hora o Graveyard Shift. La hora del día se debe expresar como un número de minutos o número de segundos desde la medianoche.
ROLAP avanzado, consultas e informes:
En esta sección se discuten una serie de técnicas avanzadas para realizar consultas e informes que se han convertido en importantes para una discusión más básica de consultas e informes en un entorno dimensional.
- Drill-Across, consultas con múltiples tecnologías: Después de haber hecho la afirmación de que al conformarse dimensión y conforme hechos, podemos atar mercados de datos dispares, tenemos que echar un vistazo a exactamente cómo se hace eso. Está claro que si damos un paso lo suficientemente atrás y consideramos mercados de datos implementados en diferentes DBMS y datos, incluso a distancia marts implementados en varios OLAP propietaria plataformas, no hay manera para poner en marcha un único de consulta basada en SQL para cualquier máquina y obtener una respuesta conformada a través de estilo drill-across.
- Para hacer drill-across a través de múltiples tecnologías de consulta, hay que poner en marcha una serie de consultas uno contra el mercado de datos y llevar a los resultados separados que establece de nuevo a una plataforma intermedia, donde atamos las respuestas mediante la realización de una especie de combinación de correspondencia en los encabezados de fila de los conjuntos de respuestas.
- Analisis de la cesta de Mercado: Análisis de la cesta del mercado consiste en darse cuenta de las combinaciones de productos que se venden juntos. Aunque muchos análisis de la cesta de mercado son, literalmente, el análisis de la tienda de comestibles cestas de mercado tienda, el concepto se puede ampliar fácilmente a otras situaciones. A diferentes pero perfectamente buen ejemplo es la compra de televisión por cable realizadas en el mes tras la compra de un paquete de visualización de deportes.
- El secreto de la realización de análisis de la cesta de mercado de manera eficiente es empezar en la parte superior de la jerarquía de mercancías y comenzar subdividirlo, con el objetivo de siempre equilibrar el número de cestas en cada grupo.
Modelado del Negocio usando Esquema Estrella - Capitulo 7 Pentaho Solutions
Introduccion:
Cuando se trabaja con los datos del almacén de datos, lo más probable es que los esquemas en estrella se utilicen para entregar los datos al usuario final. No directamente, sin embargo, por regla general, una herramienta de informes o análisis se utiliza para acceder a los datos, mientras más avanzado los usuarios pueden utilizar una herramienta de consulta directa. Sin embargo, es importante señalar que esquemas de estrella son el vehículo de elección si se trabaja con un estilo de Kimball.
Que es un modelo Estrella?
Lo primero que cabe preguntarse es: ¿Por qué estos modelos de base de datos se llaman ''estrella''? Probablemente porque el diagrama entidad-relación de este tipo de esquema se asemeja a una estrella. El centro de la estrella se compone de una tabla de hechos grandes y las puntas de la estrella son las tablas de dimensiones. La mayoría de los usuarios encuentran por primera vez una estrella esquema en un mercado de datos de ventas con los clientes, los productos, las tiendas, las promociones, y tiempo.
Tendremos una visión multidimensional de un proceso que medimos a través de unas métricas. A nivel de diseño, consiste en una tabla de hechos (lo que en los libros encontraremos como fact table) en el centro para el hecho objeto de análisis y una o varias tablas de dimensión (dimension table) por cada dimensión de análisis que participa de la descripción de ese hecho. En la tabla de hecho encontramos los atributos destinados a medir (cuantificar) el hecho: sus métricas. Mientras, en las tablas de dimensión, los atributos se destinan a elementos de nivel (que representan los distintos niveles de las jerarquías de dimensión) y a atributos de dimensión (encargados de la descripción de estos elementos de nivel). En el esquema en estrella la tabla de hechos es la única tabla del esquema que tiene múltiples joins que la conectan con otras tablas (foreign keys hacia otras tablas). El resto de tablas del esquema (tablas de dimensión) únicamente hacen join con esta tabla de hechos. Las tablas de dimensión se encuentran además totalmente denormalizadas, es decir, toda la información referente a una dimensión se almacena en la misma tabla.
Razones a favor del modelo Estrella:
Este esquema es ideal por su simplicidad y velocidad para ser usado en análisis multidimensionales (OLAP, Datamarts, EIS). Permite acceder tanto a datos agregados como de detalle.
El diseño de esquemas en estrella permite implementar la funcionalidad de una base de datos multidimensional utilizando una clásica base de datos relacional (más extendidas que las multidimensionales).
Otra razón para utilizar los esquemas en estrella es su simplicidad desde el punto de vista del usuario final. Las consultas no son complicadas, ya que las condiciones y las uniones (JOIN) necesarias sólo involucran a la tabla de hechos y a las de dimensiones, no haciendo falta que se encadenen uniones y condiciones a dos o más niveles como ocurriría en un esquema en copo de nieve. En la mayoría de los casos son preferibles los de estrellas por su simplicidad respecto a los de copo de nieve por ser más fáciles de manejar.
Finalmente, es la opción con mejor rendimiento y velocidad pues permite indexar las dimensiones de forma individualizada sin que repercuta en el rendimiento de la base de datos en su conjunto.
