1 INTRODUCCIÓN
Este documento detalla el modelo de carga a través de Sql Server Integratin Services 2008 para dimensiones históricas.
Microsoft Integration Services es una plataforma para la creación de soluciones empresariales de transformaciones de datos e integración de datos. Integration Services sirve para resolver complejos problemas empresariales mediante la copia o descarga de archivos, el envío de mensajes de correo electrónico como respuesta a eventos, la actualización de almacenes de datos, la limpieza y minería de datos, y la administración de objetos y datos de SQL Server. Los paquetes pueden funcionar por separado o conjuntamente con otros paquetes para hacer frente a las complejas necesidades de la empresa. Integration Services puede extraer y transformar datos de muchos orígenes distintos, como archivos de datos XML, archivos planos y orígenes de datos relacionales, y, posteriormente, cargarlos en uno o varios destinos.
Integration Services contiene un variado conjunto de tareas y transformaciones integradas, herramientas para la creación de paquetes y el servicio Integration Services para ejecutar y administrar los paquetes. Las herramientas gráficas de Integration Services se pueden usar para crear soluciones sin escribir una sola línea de código. También se puede programar el amplio modelo de objetos de Integration Services para crear paquetes mediante programación y codificar tareas personalizadas y otros objetos de paquete.
2 DIMENSIONES HISTÓRICAS
Las dimensiones históricas son aquellas las cuales es requerimiento del negocio mantener la historia de la evolución del negocio el cual permite realizar el análisis de la evolución y los resultados en el momento del tiempo en el cual ocurrieron los cambios.
A través de este documento estaremos realizando un ejercicio de carga de dimensión histórica, también conocidas como Dimensiones Lentamente Cambiantes o por sus siglas en ingles SCD (Slowly Changing Dimension).
2.1 Conceptos Importantes
A continuación se indicarán algunos conceptos que son importantes entender para la realización de la carga de estas dimensiones:
• Sql Server Integration Services: es la herramienta del conjunto de soluciones de Sql Server 2008 para la generación de Business Intelligence.
• Componente Slowly Changing Dimension: es el componente que utilizaremos para realizar la carga de la dimensión lentamente cambiante. A través de un Wizard nos permitirá indicar cuál es la dimensión que utilizaremos y cuales son los campos que queremos que sean históricos.
• Business Key: es la clave del negocio que identifica un concepto, por ejemplo, un producto.
• Subrrogate Key: la clave subrrogada es un campo numérico único que se utilizará como clave del registro de la dimensión. Este tipo de claves permiten mantener la historia y la integridad referencial en el caso de que, por adecuaciones o evolución del negocio, la Business Key de un concepto cambio. También es importante para la mejor performance de las consultas dado ser un campo numérico.
• Atributo Fijo: son campos en los cuales no deben cambiar en el tiempo, por ejemplo, el lugar y fecha de nacimiento de un cliente.
• Atributos Cambiantes: son campos que pueden cambiar con el tiempo pero no es una necesidad del negocio mantener su historia.
• Atributos Historicos: son campos que pueden cambiar con el tiempo pero es una necesidad del negocio mantener su historia, por ejemplo, una sucursal de un banco puede estar bajo una subdirección pero por la propia evolución del negocio cambia a otra subdirección. En el caso de que mantengamos la historia, podremos determinar los ingresos y gastos de esa sucursal en el tiempo, cuanto fue su gasto cuando dependía de la primera subdirección y cuanto en la segunda.
• Current record: es un campo (booleano) que nos indica cual es el registro actual. En el ejemplo anterior de la sucursal, tendríamos dos registros con distintas claves subrrogadas para la misma sucursal pero uno de ellos tendría el campos Current en false y el actual en true, lo cual nos permite saber el registro que es el actual.
• Inferred Members: los miembros inferidos son un caso especial dentro de las dimensiones lentamente cambiantes el cual se utiliza un campo (booleano) que nos permite indicar si el registro está completo o no. Para el mejor entendimiento de este concepto sigamos el siguiente ejemplo:
o Tenemos una dimensión de productos y una factable asociada a esa dimensión en donde se indican las ventas de los productos. La asociación entre la dimensión y la factable se realiza a través de la clave subrrogada de la dimensión.
o La factable se carga diariamente a través de un archivo que llega al datawarehouse con las ventas del dia anterior el cual contiene la clave del negocio del producto de la venta.
o La dimensión de productos se carga mensualmente a través de un archivo que llega al datawarehouse con los productos existentes en el negocio.
o Durante el correr del mes y antes de la llegada del catálogo de productos al datawarehouse se crea un nuevo producto con una nueva clave de negocio y se generan ventas para ese producto.
o Los archivos de ventas que llegan al datawarehouse ya contienen la clave de negocio para ese producto.
o El proceso de carga diario utiliza el archivo de ventas, captura la clave de negocio para los productos y busca, en la dimensión de productos, la clave subrrogada para la clave de negocio correspondiente y con eso realiza el registro en la factable y mantiene la integridad referencial.
En este escenario, el nuevo producto no se encontrará en la dimensión de productos pues el catálogo todavía no llegó al datawarehouse. Para evitar perder el registro y mantener la realidad de las ventas para este producto, el proceso de carga lo que hace es registrar la clave de negocio que viene del archivo de ventas en la dimensión de productos generando su respectiva clave subrrogada. Además, marca el registro como inferido a través de la columna correspondiente y con eso nos permite poder registrar la venta en la factable manteniendo la integridad referencial con la misma.
Al momento de que el catálogo llegue al datawarehouse, el proceso de carga encontrará que ese producto está registrado en la dimensión de productos cómo inferido y procederá a actualizar el registro con los datos que vienen del mismo catálogo.
2.2 Proceso de Carga
El proceso de carga para las dimensiones lentamente cambiantes seguirá los siguientes pasos:
2.2.1 Extracción de los datos desde el origen
Cargaremos los datos del origen a través de un componente de Integration Services dependiendo del formato. Estos componentes se encuentran en la barra de herramientas dentro de la opción Data Flow Sources. En el ejemplo abajo el origen es un archivo en Excel. Arrastramos el componente Excel Sources dentro de la región Data Flow y indicamos la localización del archivo:
2.2.2 Inserción de los datos en el destino
La inserción de los datos en el destino se realizará a través del componente Slowly Changing Dimension:
Para eso, en el menú de herramientas, dentro de la opción Data Flow Transformations arrastramos el Slowly Changing Dimension.
Hacemos doble click dentro del componente y nos muestra la pantalla de bienvenida. Luego de eso marcamos el botón Next.
En la pantalla Select a Dimension Tables and Keys procederemos a indicar cual es la tabla de destino que queremos cargar en la opción Tableo or View. Luego de eso se mostrarán las columnas de la tabla. En este momento debemos indicar cual es la clave de negocio en la columna Key Type con la opción Business Key. Luego de realizar esto marcamos el botón Next:
En la pantalla Slowly Changing Dimension Columns indicamos el comportamiento de cada columna los cuales pueden ser: Fixed Attribute, Changing Attribute y Historical Attribute:
En la pantalla Fixed and Changing Attribute Options indicaremos el comportamiento para estas dos opciones. En el ejemplo abajo indicamos que si una columna fue indicada como Fixed (no cambio con el tiempo) el proceso de carga fallará:
En la pantalla Historical Attribute Options indicaremos cómo controlaremos la histórica de la columna, los cuales pueden ser a través de una columna booleana o a través de un rango de fechas. En este ejemplo utilizamos una columna denominada IsRowCurrent booleana y indicamos el valor cuando es actual y el valor cuando ya no lo es:
En la pantalla Inferred Dimension Members se indica si se utiliza o no el miembro inferido. En este ejemplo no usamos el miembro inferido:
Terminando tenemos la pantalla de fin y marcamos finish. Esto genera los componentes necesarios para los pasos indicados anteriormente:
De los componentes indicados anteriormente su funcionamiento se explica a continuación:
1. Recupera los datos del origen
2. Configuración del componente SCD indicando el comportamiento de los campos. Pueden haber los siguientes comportamientos:
a. Nuevo registro: en este caso el componente SCD para los datos directamente a insertarlos en el destino.
b. Registro existentes sin cambios: en el caso de que el registro ya exista en la base de datos y no se encontraron diferencias entre el actual y el nuevo el SCD no realiza ninguna acción.
c. Registro existentes con cambios: pueden haber tres comportamientos del SCD:
i. Columnas tipo Fixed: si la columna es fija el resultado dependerá de lo que se indicó en la pantalla Fixed and Changing Attribute Options. En el ejemplo indicado anteriormente, el resultado será la falla del componente.
ii. Columnas tipo Changing: el resultado será la realización de un UPDATE del registro con el nuevo valor.
iii. Columnas tipo Historical: el resultado será la realización de un UPDATE en donde la columna ISROWCURRENT se pasa a false indicando que el registro ya no es actual y la inserción de un nuevo registro generando una nueva clave subrrogada y la columna ISROWCURRENT con valor en true.
Thursday, May 6, 2010
Wednesday, May 5, 2010
Modelos OLAP
1 INTRODUCCIÓN
Los sistemas OLAP (On-Line Analytical Processing) proporcionan una alternativa a los sistemas transaccionales, ofreciendo una visión de los datos orientada hacia el análisis y una rápida y flexible navegación por estos.
2 CARACTERÍSTICAS
Las siguientes son características que la tecnología OLAP posee:
• Las bases de datos de OLAP tienen un esquema que está optimizado para que las preguntas realizadas por los usuarios sean respondidas rápidamente.
• Las preguntas que se le hacen a un OLAP, deben permitir un uso interactivo con los usuarios
• Los cubos de OLAP almacenan varios niveles de datos conformados por estructuras altamente optimizadas que responden a las expectativas de negocio de la empresa.
• Un sistema OLAP está preparado para realizar informes complejos de una manera simple.
• OLAP proporciona una vista de datos multidimensional. Los cubos proporcionan una vista de los datos multidimensional que se extiende más allá del análisis de dos dimensiones que puede proporcionar una simple planilla de cálculo utilizada como tal.
• Los usuarios pueden cambiar fácilmente las filas, las columnas, y las páginas en informes de OLAP, pudiendo leer la información de la manera que se crea más conveniente para el análisis.
3 CONCEPTOS
3.1 Data Mart
Un Data mart es una versión especial de almacén de datos (data warehouse). Son subconjuntos de datos con el propósito de ayudar a que un área específica dentro del negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden ser agrupados, explorados y propagados de múltiples formas para que diversos grupos de usuarios realicen la explotación de los mismos de la forma más conveniente según sus necesidades.
El Data mart es un sistema orientado a la consulta, en el que se producen procesos batch de carga de datos (altas) con una frecuencia baja y conocida. Es consultado mediante herramientas OLAP (On Line Analytical Processing - Procesamiento Analítico en Línea) que ofrecen una visión multidimensional de la información. Sobre estas bases de datos se pueden construir EIS (Executive Information Systems, Sistemas de Información para Directivos) y DSS (Decision Support Systems, Sistemas de Ayuda a la toma de Decisiones). Por otra parte, se conoce como Data Mining al proceso no trivial de análisis de grandes cantidades de datos con el objetivo de extraer información útil, por ejemplo para realizar clasificaciones o predicciones.
En síntesis, se puede decir que los data marts son pequeños data warehouse centrados en un tema o un área de negocio especifico dentro de una organización.
3.2 Data Warehousing
Es el conjunto de almacenes de datos particulares (Data Mart) con información de interés para la empresa en general
“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”. Bill Inmon -Using de Data Warehouse.
De la definición anterior de detalla:
Integrado Los datos almacenados en el Data Warehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas.
La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios.
Temático Sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional.
Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales.
Por ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla del Data Warehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar
Histórico El tiempo es parte implícita de la información contenida en un Data Warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente.
La información almacenada en el Data Warehouse sirve, entre otras cosas, para realizar análisis de tendencias.
El Data Warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones
No volátil El almacén de información de un Data Warehouse existe para ser leído, y no modificado.
La información es por tanto permanente, significando la actualización del Data Warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.
3.3 Análisis multidimensional
E.F. Codd, considerado como el padre de las bases de datos relacionales, ha venido insistiendo desde principio de los noventa, que disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones.
Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza.
Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio.
3.4 Dimensiones del negocio
Estas dimensiones de negocio se comprenden mejor fijando un ejemplo, para lo que vamos a mostrar, para un sistema de gestión de expedientes, las jerarquías que se podrían manejar para el número del mismo para las dimensiones: zona geográfica, tipo de expediente y tiempo de resolución
4 DATA WAREHOUSING
4.1 Procesos de un DW
A continuación se detallan los procesos que sufre la información en el flujo del Datawarehouse.
Extracción: obtención de información de las distintas fuentes tanto internas como externas.
Elaboración: filtrado, limpieza, depuración, homogeneización y agrupación de la información.
Carga: organización y actualización de los datos y los metadatos en la base de datos.
Explotación: extracción y análisis de la información en los distintos niveles de agrupación.
4.2 Sistema tradicional y Data Warehousing
Las diferencias entre el sistema tradicional transaccional y del de Data Warehousing se detallan a continuación:
Sistema Tradicional Data Warehousing
Predomina la actualización. Predomina la consulta.
La actividad más importante es de tipo operativo, día a día. La actividad más importante es el análisis y la decisión estratégica.
Predomina el proceso Puntual. Predomina el proceso masivo.
Mayor importancia a la estabilidad. Mayor importancia al dinamismo.
Datos en general desagregados. Datos en distintos niveles de detalle y agregación
Importancia del dato actual Importancia del dato histórico.
4.3 Etapas modelado de DW
Para el correcto análisis de un sistema OLAP se deben seguir algunas etapas que ayudarán a modelar correctamente el objeto de análisis de la solución. Se detallan:
Identificación de las necesidades y requerimientos.
En base a los requerimientos, definir las tablas auxiliares y los procesos de selección, transformación e importación de datos.
Reconocimiento de las fuentes de datos originales y sus estructuras.
Construir el esquema multidimensional. Debe controlarse que este esquema concuerde con los requerimientos y las tablas auxiliares, como primera forma de testeo.
Acceso al sistema desde las estaciones de trabajo de los analistas obteniendo la información identificada en la etapa de requerimientos.
4.4 Diseño y modelización
Los requerimientos de información identificados durante la anterior fase proporcionarán las bases para realizar el diseño y la modelización del Data Warehouse.
En esta fase se identificarán las fuentes de los datos (sistema operacional, fuentes externas,..) y las transformaciones necesarias para, a partir de dichas fuentes, obtener el modelo lógico de datos del Data Warehouse. Este modelo estará formado por entidades y relaciones que permitirán resolver las necesidades de negocio de la organización.
El modelo lógico se traducirá posteriormente en el modelo físico de datos que se almacenará en el Data Warehouse y que definirá la arquitectura de almacenamiento del Data Warehouse adaptándose al tipo de explotación que se realice del mismo.
La mayor parte estas definiciones de los datos del Data Warehouse estarán almacenadas en los meta datos y formarán parte de
4.5 METODOLOGIA DE LOS 9 PASOS DE KIMBALL
Ralph Kimball, es reconocido como uno de los padres del concepto de Datawarehouse, se ha dedicado desde hace más de 10 años al desarrollo de su metodología para que éste concepto sea bien aplicado en las organizaciones y se asegure la calidad en el desarrollo de estos proyectos.
Su metodología se enfoca principalmente en el diseño de la base de datos que almacenará la información para la toma de decisiones.
A continuación se detallan un proceso de 9 pasos enfocado a la generación del diseño del modelo:
Paso Detalle
SELECCIÓN DEL PROCESO Hace referencia al tema objetivo del DW.
SELECCIÓN DE LA GRANULARIDAD Implica decidir qué es lo que va a representar cada registro de la fact.
Solo después de seleccionar la granularidad de la fact podremos identificar las dimensiones.
La decisión sobre la granularidad de la fact determina granularidad de cada tabla de dimensión.
IDENTIFICACION Y CONFORMACION DE LAS DIMENSIONES Las dimensiones establecen el contexto para realizar preguntas acerca de los hechos contenidos en la fact.
SELECCIÓN DE HECHOS La granularidad de la fact determina que hechos pueden usarse en el DW.
ALMACENAMIENTO DE LOS VALORES PRECALCULADOS EN LA FACT Determinar si existe la posibilidad de utilizar valores pre calculados.
TERMINACION DE LAS TABLAS DE DIMENSION Volver a las tablas de dimensión y añadimos tantas descripciones textuales a las dimensiones como sea posible.
SELECCIÓN DE LA DURACION DE LA BASE DE DATOS La duración mide hasta que momento del pasado debe retroceder la tabla de hechos.
CONTROL DE LAS DIMENSIONES LENTAMENTE CAMBIANTES Mantenimiento de la historia de los cambios de una dimensión.
SELECCIÓN DE LAS PRIORIDADES DE CONSULTA Y DE LOS MODOS Cuestiones de diseño físico.
5 MODELADO DE DIMENSIONALIDAD
Todo modelo dimensional está compuesto de una tabla central con una clave principal compuesta, denominada Tabla de Hechos, y un conjunto de tablas más pequeñas denominadas Tablas de Dimensión.
Cada tabla de Dimensión contiene una clave principal simple (no compuesta) que se corresponde exactamente con uno de los componentes de la clave compuesta de la tabla de Hechos.
Otra característica importante de un modelo DM es que todas las claves naturales se sustituyen por claves subrogadas (SK). Esto significa que toda combinación entre la tabla de hechos y las dimensiones está basada en claves subrogadas y no naturales.
Cada clave subrogada debe tener una estructura generalizada basada en enteros simples.
5.1 ESQUEMA ESTRELLA
Una estructura lógica que tiene una tabla de hechos que contiene datos factuales en el centro, rodeada por tablas de dimensión que contienen datos de referencia (que pueden estar des normalizados)
Los Hechos más útiles de una tabla de hechos son numéricos y aditivos.
Las tablas de dimensión, por contraste, contienen generalmente información contextual descriptiva.
Los esquema estrella pueden utilizarse para acelerar la velocidad de las consultas, des normalizando la información de referencia en una única tabla de dimensión.
5.2 ESQUEMA EN COPO DE NIEVE
Una estructura variante del estrella en el que las tablas de dimensión no contienen datos des normalizados.
5.3 Tabla de Hechos
Un DW, clasifica la información en base a los aspectos que son de interés para la empresa. Estos aspectos pueden ser los sujetos de los cuales formarán las dimensiones y los hechos que formarán las Tablas de Hechos.
El modelo dimensional divide el mundo de los datos en dos grandes tipos: las medidas y las dimensiones de estas medidas.
Las medidas, siempre son numéricas, se almacenan en las tablas de hechos y las dimensiones que son textuales se almacenan en las tablas de dimensiones.
La tabla de hechos es la tabla primaria del modelo dimensional, y contiene los valores del negocio que se desea analizar.
Cada tabla de hechos contiene las claves externas (FK), que se relacionan con sus respectivas tablas de dimensiones (PK), y las columnas con los valores que serán analizados.
Ejemplos de Hechos:
• En un hospital: admisión de pacientes
• En un operador telefónico: Tráfico telefónico
Un hecho es un concepto de interés primario para el proceso de toma de decisiones, corresponde a eventos que ocurren dinámicamente en el negocio de la empresa.
5.4 Dimensiones
Diseñaremos y construiremos cada dimensión basados en los procesos de negocio definidos por el cliente.
Las dimensiones organizan los datos en función de un área de interés para los usuarios.
Cada dimensión describe un aspecto del negocio y proporciona el acceso intuitivo y simple a datos.
Una dimensión provee al usuario de un gran número de combinaciones e intersecciones para analizar datos.
Las tablas de dimensiones son las compañeras de las tablas de hechos. Cada dimensión se define por su clave primaria que sirve para mantener la integridad referencial en la tabla de hechos a la que se relaciona.
Un cubo requiere que se defina al menos una dimensión en su esquema.
5.5 Relaciones y Estructura de una dimensión
Cada nivel de una dimensión debe corresponderse con una columna en la tabla de la dimensión. Los niveles se ordenan por grado de detalle y se organizan en una estructura jerárquica. Cada nivel contiene miembros, los miembros son los valores de la columna que define el nivel.
Entre los miembros y entre los niveles de una dimensión existen relaciones, estas se pueden comprender como las relaciones que existen en un árbol genealógico donde los términos padre, hijo, hermano, primo, etc. indican una correspondencia entre elementos del árbol; y los miembros de la dimensión se comportan como familiares dentro del árbol genealógico.
5.6 Dimensiones: Padre – Hijo (Parent – Child)
Una dimensión padre-hijo es una dimensión donde el dato del Padre se relaciona con el Hijo y ambos se encuentran en la misma tabla de dimensión, es decir, la dimensión se relacionan consigo misma.
5.7 Medidas
Las medidas son los valores de datos que se analizan.
Una medida es una columna cuantitativa, numérica, en la tabla de hechos. Las medidas representan los valores que son analizados, como cantidad de pacientes admitidos o llamadas efectuadas.
Las medidas son:
o Valores que permiten analizar los hechos
o Valores numéricos porque estos valores son las bases de las cuales el usuario puede realizar cálculos.
Si la medida fuera un valor no numérico debemos codificarla a un valor numérico en el proceso de obtención de datos, y luego cuando tengamos que exponer sus valores decodificarla para mostrarla con el valor original.
Las siguientes son algunas de las características de las medidas:
o Deben ser numéricas.
o Cruzan todas las dimensiones en todos los niveles.
Las medidas pueden clasificarse en:
o Naturales - Columnas de las tablas de hechos
o Calculadas - Surgen a partir de las Naturales
Cuando definimos una medida debemos tener en cuenta cual será la forma de agregación (agrupación de la misma) al subir por la estructura dimensional.
Estas formas de agregación pueden ser:
o Suma: es la operación que suma los valores de las columnas
o Cuenta: realiza un conteo de los valores
o Mínima: devuelve un valor mínimo
o Máxima: proporciona el mayor de los valores
o Cuenta de Distintos: cuenta los valores diferentes
Las agregaciones son resúmenes de datos pre calculados que mejoran el tiempo de respuesta por el simple hecho de tener preparadas las respuestas antes de que se planteen las preguntas (agrupación de las mismas).
5.8 Tipos de Almacenamiento
5.8.1 MOLAP
En el modo de almacenamiento MOLAP (OLAP Multidimensional) una copia de los datos de origen del cubo, junto con sus agregaciones, es almacenada en una estructura multidimensional.
Debemos tener en cuenta que mientras los datos de origen cambian directamente con las operaciones, los objetos con almacenamiento MOLAP deben ser procesados para incorporar estos cambios.
El tiempo comprendido entre un procesamiento y el siguiente, crea un periodo de latencia durante el que puede que la información OLAP no coincida con los datos de origen actuales.
Como característica del almacenamiento MOLAP podemos destacar:
• Provee excelente rendimiento y compresión de datos.
• Tiene mejor tiempo de respuesta, dependiendo solo del porcentaje de las agregaciones del cubo.
• La estructura está muy optimizada para maximizar el rendimiento de las consultas.
• En general este método, es muy apropiado para cubos con uso frecuente por su rápida respuesta.
5.8.2 ROLAP
En un modelo ROLAP (OLAP Relacional) toda la información del cubo, sus datos, su agregación, sumas, etc., son almacenados en una base de datos relacional.
A diferencia del modo de almacenamiento MOLAP, ROLAP no almacena copia de la base de datos, accede a las tablas originales cuando necesita responder a las consultas, generalmente es mucho más lenta que las otras estrategias de almacenamiento (MOLAP o HOLAP).
ROLAP se utiliza para ahorrar espacio de almacenamiento cuando se trabaja con grandes conjuntos de datos que se consultan con poca frecuencia; por ejemplo, datos exclusivamente históricos.
Los usos comunes de este esquema son:
• Cuando los clientes desean ver los cambios inmediatamente.
• Cuando contamos con grandes conjuntos de datos que no son frecuentemente buscados
5.8.3 HOLAP
HOLAP (OLAP híbrido) combina atributos de MOLAP y ROLAP.
Al igual que MOLAP, HOLAP hace que las agregaciones se almacenen en una estructura multidimensional, y los datos a nivel de detalle, en una base de datos relacional como lo hace el almacenamiento ROLAP.
Para procedimientos de búsqueda que accedan datos sumarizados, HOLAP es equivalente a MOLAP. Por el contrario, si los procesos de consultas accedieran a los máximos niveles de detalle, deberían recuperar los datos de la base de datos relacional y esto no seria tan rápido comparado con una estructura MOLAP.
Los cubos almacenados como HOLAP, son más pequeños que los MOLAP y responden más rápidos que los ROLAP.
Usos comunes de HOLAP
• Cubos que requieren rápida respuesta.
• Cuando existen sumarizaciones basadas en una gran cantidad de datos de origen.
• Solución de compromiso para bajar el espacio ocupado sin perjudicar totalmente el rendimiento de las consultas.
5.9 Definición de Agregaciones
Otro factor para considerar en la implementación del modelo OLAP, además del modo de almacenamiento, es la definición del porcentaje de agregaciones.
Se denomina agregación al proceso de pre calcular el cálculo de los datos a través de los niveles, para disminuir los tiempos de respuestas en los procesos de búsquedas de información. El porcentaje de agregación da idea de la proporción o profundidad hasta la que se realizarán el pre cálculos.
Las agregaciones se almacenan en la estructura multidimensional (según el modo de almacenamiento que escogimos).
Cuando definamos agregaciones debemos tener en cuenta de especificar las restricciones de almacenamiento y de porcentaje de agregación, a fin de lograr una buena solución de compromiso entre el tiempo de respuesta a las consultas y los requisitos de almacenamiento.
Si calculáramos todas las agregaciones posibles necesitaremos gran cantidad de tiempo de procesamiento y espacio de almacenamiento. Si por el contrario, no se pre calculan agregaciones (0%), la cantidad de espacio de almacenamiento que se necesita se reduce al mínimo, pero el tiempo de respuesta aumenta.
Por lo tanto, suele existir un equilibrio entre el espacio de almacenamiento, el porcentaje de posibles agregaciones que se pre calculan y la performance requerida.
Características de las agregaciones:
• Las agregaciones permiten mejorar los tiempos de respuesta
• Requieren de almacenamiento adicional
• Si no son controladas pueden provocar una explosión en los requisitos de almacenamiento
A mayor número de agregaciones más tiempo de procesamiento y más requerimiento de espacio.
A menor número de agregaciones peor tiempo de respuesta de las consultas y menos requerimiento de espacio.
Esta definición debe considerar los siguientes factores
• Modo de almacenamiento que escogimos (MOLAP-ROLAP-HOLAP)
• Tamaño de la tabla de hechos (cantidad de registros)
• Numero de dimensiones del modelo
• Porcentaje de agregaciones
Para determinar la frecuencia con que procesaremos el cubo debemos tener en cuenta lo analizado con el cliente respecto de la granularidad de los datos para el tiempo. EL nivel de detalle (día, mes, etcétera) nos fijará la periodicidad de actualización de los datos.
A diferencia de los sistemas OLTP en los que la actualización de los datos se realiza en línea con las transacciones y la agregación de los datos se realiza en el momento en que el usuario realiza una consulta, en OLAP el procesamiento de los cubos se realiza a contra turno, en los horarios en que no se afecta la tarea de los usuarios.
5.10 Particiones
Los cubos están compuestos por particiones. Como su nombre lo sugiere, una partición es una división o fraccionamiento de la información que conforma a un cubo. Cada cubo contiene al menos una partición, pero puede estar compuesto por múltiples particiones.
Las particiones de un cubo son invisibles para el usuario, pero su uso aumenta la carga de trabajo del administrador del modelo multidimensional.
Para cada partición podemos definir la fuente de datos, el modo de almacenamiento y el porcentaje de agregación de manera independiente de las demás particiones.
Además, una partición de datos puede ser actualizada independientemente de las otras. Esta propiedad es muy importante ya que nos brinda la ventaja de mejorar los tiempos de procesamiento si dividimos correctamente las particiones y las procesamos adecuadamente.
Así, si dividimos nuestro cubo en particiones definiremos cada unos de estos parámetros de la manera mas indicada.
Partición más utilizada (Tiempo Actual):
Modo de Almacenamiento MOLAP,
% de Agregación: alto (estimado:40%)
Frecuencia de procesamiento: alta
Partición medianamente consultada (Tiempos intermedios):
Modo de Almacenamiento: HOLAP
% de Agregación: bajo (estimado:10%)
Frecuencia de procesamiento: ocasional
Partición poco accedida (Períodos viejos):
Modo de Almacenamiento ROLAP,
% de Agregación: nulo (estimado:0%)
Frecuencia de procesamiento: muy baja (normalmente sólo al crear la partición)
5.11 Transformación y agrupación de datos – ETL
Los datos que alimentan a un sistema DW provienen de diferentes fuentes, estas fuentes son los distintos sistemas operacionales que la empresa posee, generalmente ni son homogéneos entre sí ni concuerdan exactamente con lo que se necesita, por lo que será necesario realizar todas las adaptaciones pertinentes.
Los diferentes procesos que se concentran en el concepto de toma, transformación y carga de datos en un DW se denominan ETL, sus siglas en inglés significan Extract – Transform – Load.
Al reunir datos de los diferentes sistemas, se debe definir una norma única para el DW y realizar las transformaciones que sean necesarias en cada caso. Básicamente deben realizarse las siguientes tareas:
• Establecer las reglas que serán utilizadas para realizar la transformación.
• Detectar las inconsistencias que pueden originarse al tomar los datos desde distintas fuentes.
• Planificar cuidadosamente y con detalles la transformación de los datos que den como resultado final conjuntos de datos consistentes.
6 EXPRESIONES MULTIDIMENSIONALES – MDX
Las expresiones multidimensionales (MDX es el acrónimo de MultiDimensional eXpressions) es un lenguaje de consulta para bases de datos multidimensionales sobre cubos OLAP, se utiliza en Business Intelligence para generar reportes para la toma de decisiones basados en datos históricos, con la posibilidad de cambiar la estructura, o permitiendo rotar el cubo.
Una consulta MDX es muy similar a una consulta SQL, nos devuelve un conjunto de celdas, que es resultado de tomar un subconjunto de las celdas del cubo original.
Consulta MDX Básica:
Sintaxis: SELECTon columns, on rows FROM WHERE
A continuación se estarán detallando una serie de ejemplos de consultas MDX tomando distintos parámetros que serán de utilidad al momento de realizar el análisis requerido para el negócio:
Comma (,) and Colon (:)
Indica cómo se separan los elementos en una consulta.
{[Time ].[January 2005 ],[Time ].[February 2005 ],[Time ].[March 2005 ] }}
SELECT
{[Time ].[Sep,2004 ]: [Time ].[Mar,2005 ] }}on columns,
{[Product ].[Tools ]: [Product ].[Home Audio ] }}on rows
FROM [Sales ]
WHERE ([Customer ].[Lubbock,TX ],[Measures ].[Unit Sales ])
{{[Time ].[January-2001 ] :[Time ].[March-2001 ] }},{[Time ].[October-2001 ] :[Time ].[December-2001 ] }}}
{[Time ].[2001 ],{[Time ].[January-2001 ] :[Time ].[March-2001 ] }}}
.MEMBERS
Retorna todos los miembros de una jerarquía o atributo.
SELECT
{[Scenario ].Members }on columns,
{[Store ].Members }on rows
FROM Budgeting
.Children
Retorna todos los hijos de los miembros de una jerarquía o atributo.
SELECT
{[Time ].[Q3,2005 ].Children }
on columns,
{[Product ].[Tools ],[Product ].[Tools ].Children }
on rows
FROM Sales
WHERE ([Customer ].[TX ],[Measures ].[Unit Sales ])
Descendants()
Es una función que retorna los hijos de un miembro determinado.
Descendants (member [,[level ] [,flag ]] ))
SELF - miembros del nivel indicado (por defecto)
BEFORE - miembros anteriores al nivel indicado
AFTER - miembros siguientes al nivel indicado
SELF_AND_BEFORE - miembros del nivel indicado y los miembros anteriores al nivel
SELF_AND_AFTER - miembros del nivel actual mas los miemros siguientes.
SELF_BEFORE_AFTER - miembros anteriores, actual y siguientes
SELECT
{[Product ].[Tools ],[Product ].[Toys ] }}ON COLUMNS,
descendants([Time].[2005],[Time].[Month],SELF)ON ROWS
FROM Sales
WHERE [Measures ].[Dollar Sales ]
SELECT
crossjoin([Fecha].[Año].members,
CrossJoin({[Promoción].[Todos Promoción].[Bulk Mail].[Bag Stuffers]},{[Store Sales],[Store Cost]})) on 0,
descendants([Producto].[Todos Producto].[Baking Goods],[Producto].[Product Subcategory],self_before_after) on 1
FROM Sales
SELECT
crossjoin(descendants(
[Fecha].[Todos Fecha].[1997],
[Fecha].[Mes],self),
CrossJoin({[Promoción].[Todos Promoción].[Bulk Mail].[Bag Stuffers]},
{[Store Sales],[Store Cost]})) on 0,
descendants([Producto].[Todos Producto].[Baking Goods],[Producto].[Product Subcategory],self_before_after) on 1
FROM Sales
NON EMPTY
No retorna los empty
SELECT
{[Time ].[Jan,2005 ],[Time ].[Feb,2005 ] }} ON COLUMNS,
NON EMPTY{[Product ].[Toys ],[Product ].[Toys ].Children} ON ROWS
FROM Sales
WHERE ([Measures ].[Dollar Sales ],[Customer ].[TX ])
Comentarios
/* */
//
Tuplas
Combinación de miembros de una o mas dimensiones
([Customer ].[Chicago,IL ],[Time ].[Jan,2005 ])
Sets
Colección de tuplas
{([Time ].[2005 ],[Measures ].[Dollar Sales ] )),
([Time ].[Feb,2005 ],[Measures ].[Unit Sales ] ))
}
CrossJoin()
Función que permite realizar un cruce entre dos o mas colecciones de tuplas.
CrossJoin (set1 ,set2 )
SELECT
CrossJoin (
{[Time ].[Q1,2005 ],[Time ].[Q2,2005 ]},
{[Measures ].[Dollar Sales ],[Measures ].[Unit Sales ] }
)
ON COLUMNS ,
{[Product ].[Tools ],[Product ].[Toys ] }ON ROWS
FROM Sales
SELECT
crossjoin(descendants(
[Fecha].[Todos Fecha].[1997],
[Fecha].[Mes],self),
CrossJoin({[Promoción].[Todos Promoción].[Bulk Mail].[Bag Stuffers]},
{[Store Sales],[Store Cost]})) on 0,
descendants([Producto].[Todos Producto].[Baking Goods],[Producto].[Product Subcategory],self_before_after) on 1
FROM Sales
Filter()
Función que permite filtrar una tupla en base a una expression.
Filter (set ,boolean-expression )
Filter (
{[Product ].[Product Category ].Members },
[Measures ].[Dollar Sales ] >>=500
)
Filter (
{[Product ].[Product Category ].Members },
([Measures ].[Dollar Sales ] >>=1.2 *[Measures ].[Dollar Costs ])
AND [Measures ].[Dollar Sales ] >>=150
)
Filter (
CrossJoin (
[Product ].[Product Category ].Members,
[Store ].[City ].Members
),
[Measures ].[Dollar Sales ] >>=500
)
Order()
Función que ordena los miembros de una tupla en base a una expresión.
Order (set1 ,expression [,ASC DESC BASC BDESC ])
SELECT
{[Measures ].[Dollar Sales ] }on columns,
Order (
[Product ].[Product Category ].Members,
[Measures ].[Dollar Sales ],
BDESC
)
on rows
FROM [Sales ]
WHERE [Time ].[2004 ]
SELECT
CrossJoin (
{[Time ].[2004 ],[Time ].[2005 ]},
CrossJoin (
{[Customer ].[Northeast ],[Customer ].[West ] },
{([Measures ].[Dollar Sales ],[Measures ].[Unit Sales ] }
)
)on columns,
Order (
[Product ].[Product Category ].Members,
([Measures ].[Unit Sales ],[Time ].[2005 ],
[Customer ].[All Customers ]),
BDESC
)on rows
FROM [Sales ]
SELECT
CROSSJOIN({[Fecha].[Todos Fecha].[1997],[Fecha].[Todos Fecha].[1998]},
CROSSJOIN({[Producto].[Todos Producto].[Candles].[Candles],[Producto].[Todos Producto].[Candy].[Chocolate Candy]},{[Store Sales],[Store Cost]})) on 0,
ORDER(DESCENDANTS([Almacén].[Todos Almacén].[USA],[Almacén].[Store State]),([Store Sales],[Cliente].[Todos Cliente]),BDESC) on 1
FROM Sales
DIMENSION PROPERTIES
Las propiedades de miembro cubren la información básica de todos los miembros de cada tupla. Esta información básica incluye el nombre del miembro, el nivel primario, el número de secundarios, etc. Las propiedades de miembro están disponibles para todos los miembros de un determinado nivel. En términos de organización, las propiedades de miembro se tratan como datos organizados dimensionalmente, almacenados en una sola dimensión.
SELECT
{[Customer ].[Akron,OH ].Children }
DIMENSION PROPERTIES [Customer].[Zip Code],
[Customer].[Individual].[Hair Color]
on columns,
{[Product ].[Category ].Members }on rows
FROM Sales
WHERE ([Measures ].[Units Sold ],[Time ].[July 3,2005 ])
-----------------------------------------------------------------------
WITH MEMBER MemberIdentifier AS ‘member-formula ’ [,properties ...]
WITH MEMBER [Measures].[Avg Sales Price] AS ‘[Measures].[Dollar Sales] / [Measures].[Unit Sales]’
SOLVE_ORDER
Calcula el orden de ejecución de la consulta
WITH
MEMBER [Measures ].[Avg Sales Price ] AS
‘[Measures ].[Dollar Sales ] //[Measures ].[Unit Sales ]’,
SOLVE_ORDER = 0
MEMBER [Time ].[Q1 to Q2 Growth ] AS
‘[Time ].[Q2,2005 ]-[Time ].[Q1,2005 ]’,
SOLVE_ORDER = 1
SELECT
{[Measures ].[Dollar Sales ],[Measures ].[Unit Sales ],[Measures ].[Avg Sales Price ]} on columns,
{[Time ].[Q1,2005 ],[Time ].[Q2,2005 ],[Time ].[Q1 to Q2 Growth ] } on rows
FROM [Sales ]
WHERE ([Customer ].[MA ])
Avg()
Función que calcula el promedio de una tupla en relación a una expresión numérica.
Avg (set [,numeric_value_expression ])
Avg (
{[Product ].[Tools ],
[Product ].[Toys ],
[Product ].[Indoor,Outdoor Games ] }},
[Measures ].[Dollar Sales ]
)
Count(), .Count
Función que cuenta la cantidad de miembros de una tupla.
Count (set [,EXCLUDEEMPTY INCLUDEEMPTY ] ))
Count (
CrossJoin (
{[Measures ].[Unit Sales ] }},
[Product ].[Tools ].Children
)
)
DistinctCount()
Función que cuenta la cantidad de miembros distintos de una tupla.
DistinctCount (set )
DistinctCount (
[Measures ].[Dollar Sales ] **
{[Product ].[Tools ],[Product ].[Toys ],
[Product ].[Indoor,Outdoor Games ]
}
)
Sum()
Función que suma los miembros de una tupla en relación a una expresión numérica.
Sum (set [,numeric_value_expression ])
Sum (
{[Product ].[Tools ],
[Product ].[Toys ],
[Product ].[Indoor,Outdoor Games ] }},
[Measures ].[Dollar Sales ]
)
Max()
Función que retorna el valor máximo de una tupla en relación a una expresión numérica.
Max (set [,numeric_value_expression ])
Max (
{[Product ].[Tools ],
[Product ].[Toys ],
[Product ].[Indoor,Outdoor Games ] }},
[Measures ].[Dollar Sales ]
)
Median()
Devuelve el valor medio de una expresión numérica evaluada sobre un conjunto.
Median (set [,numeric_value_expression ])
Median (
[Product ].[Tools ].Children,
[Measures ].[Dollar Sales ]
)
Min()
Devuelve el valor mínimo de una expresión numérica evaluada sobre un conjunto.
Min (set [,numeric_value_expression ])
Min (
[Product ].[Tools ].Children,
[Measures ].[Dollar Sales ]
)
NonEmptyCount()
Función que retorna la cantidad no vacía de una tupla.
NonEmptyCount (set [,numeric_value_expression ])
NonEmptyCount (
[Product ].[Tools ].Children,
[Measures ].[Unit Sales ]
)
Using the .CurrentMember function
Devuelve el miembro actual de una jerarquía especificada durante la iteración.
Dimension .CurrentMember
****
Using the .Parent function
Devuelve el elemento primario de un miembro.
Member .Parent
****
[Measures ].[Unit Sales ] / ([Measures ].[Unit Sales ],[Product ].CurrentMember.Parent)
Using the Ancestor() function
Función que devuelve el antecesor de un miembro especificado en un nivel especificado oa una distancia especificada del miembro.
Ancestor (member ,level )
[Measures ].[Unit Sales ] /([Measures ].[Unit Sales ],Ancestor ([Product ].CurrentMember,[Product ].[Family ]))
.PrevMember and .NextMember
Devuelve el miembro anterior y siguiente en el nivel que contiene un miembro especificado.
WITH MEMBER [Measures ].[Unit Sales Increase ] AS
‘[Measures ].[Unit Sales ]
-([Measures ].[Unit Sales ],[Time ].CurrentMember.PrevMember)
SELECT
{[Time ].[Oct,2005 ].PrevMember [Time ].[Oct,2005 ] }}on columns,
{[Measures ].[Unit Sales ],[Measures ].[Unit Sales Increase ] }}on rows
FROM Sales
ParallelPeriod()
Devuelve un miembro de un periodo anterior en la misma posición relativa que el indicado.
WITH MEMBER [Measures ].[Unit Sales YAgo Increase ] AS
‘[Measures ].[Unit Sales ]
-([Measures ].[Unit Sales ],
ParallelPeriod ([Time].[Year], 1, [Time].CurrentMember))'
SELECT
{[Time ].[Quarter ].[Q1,2005 ],
[Time ].[Quarter ].[Q1,2005 ].Children}on columns,
{[Measures ].[Unit Sales ],[Measures ].[Unit Sales YAgo Increase ] }}on
rows
FROM Sakes
PeriodsToDate()
Devuelve un conjunto de miembros del mismo nivel que un miembro determinado, empezando por el primer miembro del mismo nivel y acabando con el miembro en cuestión, de acuerdo con la restricción del nivel especificado en la dimensión de tiempo.
WITH MEMBER [Measures ].[YTD Dollar Sales ] AS
‘Sum (
PeriodsToDate ( [Time].[Year], [Time].CurrentMember )
[Measures ].[Dollar Sales ]
)’
SELECT
{[Time ].[Quarter ].[Q3,2000 ],[Time ].[Quarter ].[Q4,2000 ],
[Time ].[Quarter ].[Q1,2001 ]
}on columns,
{[Measures ].[Expenses ],[Measures ].[YTD Expenses ] }}on rows
FROM Costing
[Time ].CurrentMember.Level.Members.Item(0)
OpeningPeriod ([Time ].[All Time ],[Time ].CurrentMember.Level)
OpeningPeriod ([Time ],[Time ].CurrentMember.Level)
LastPeriods()
Devuelve un conjunto de miembros hasta un miembro determinado, éste inclusive.
SELECT
{LastPeriods (-4 [Time ].[Mar,2005 ] ))}
on columns,
{[Product ].[Toys ],
[Product ].[Toys ].Children
}
on rows
FROM Sales
WHERE [Measures ].[Unit Sales ]
SELECT {[Measures].[Sales Amount]} ON 0,
{[Product].[Product Categories].[Category]} ON 1
FROM (SELECT -{[Product].[Product Categories].[Category].&[3]} ON 0
FROM [Adventure Works])
CREAR UN SET
CREATE SET [User Selection] AS
‘Filter (
[Product].[Category].Members,
[Measures].[Dollar Sales] > 5000
)’
WHERE ([Time].[Q1, 2005])
Los sistemas OLAP (On-Line Analytical Processing) proporcionan una alternativa a los sistemas transaccionales, ofreciendo una visión de los datos orientada hacia el análisis y una rápida y flexible navegación por estos.
2 CARACTERÍSTICAS
Las siguientes son características que la tecnología OLAP posee:
• Las bases de datos de OLAP tienen un esquema que está optimizado para que las preguntas realizadas por los usuarios sean respondidas rápidamente.
• Las preguntas que se le hacen a un OLAP, deben permitir un uso interactivo con los usuarios
• Los cubos de OLAP almacenan varios niveles de datos conformados por estructuras altamente optimizadas que responden a las expectativas de negocio de la empresa.
• Un sistema OLAP está preparado para realizar informes complejos de una manera simple.
• OLAP proporciona una vista de datos multidimensional. Los cubos proporcionan una vista de los datos multidimensional que se extiende más allá del análisis de dos dimensiones que puede proporcionar una simple planilla de cálculo utilizada como tal.
• Los usuarios pueden cambiar fácilmente las filas, las columnas, y las páginas en informes de OLAP, pudiendo leer la información de la manera que se crea más conveniente para el análisis.
3 CONCEPTOS
3.1 Data Mart
Un Data mart es una versión especial de almacén de datos (data warehouse). Son subconjuntos de datos con el propósito de ayudar a que un área específica dentro del negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden ser agrupados, explorados y propagados de múltiples formas para que diversos grupos de usuarios realicen la explotación de los mismos de la forma más conveniente según sus necesidades.
El Data mart es un sistema orientado a la consulta, en el que se producen procesos batch de carga de datos (altas) con una frecuencia baja y conocida. Es consultado mediante herramientas OLAP (On Line Analytical Processing - Procesamiento Analítico en Línea) que ofrecen una visión multidimensional de la información. Sobre estas bases de datos se pueden construir EIS (Executive Information Systems, Sistemas de Información para Directivos) y DSS (Decision Support Systems, Sistemas de Ayuda a la toma de Decisiones). Por otra parte, se conoce como Data Mining al proceso no trivial de análisis de grandes cantidades de datos con el objetivo de extraer información útil, por ejemplo para realizar clasificaciones o predicciones.
En síntesis, se puede decir que los data marts son pequeños data warehouse centrados en un tema o un área de negocio especifico dentro de una organización.
3.2 Data Warehousing
Es el conjunto de almacenes de datos particulares (Data Mart) con información de interés para la empresa en general
“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”. Bill Inmon -Using de Data Warehouse.
De la definición anterior de detalla:
Integrado Los datos almacenados en el Data Warehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas.
La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios.
Temático Sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional.
Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales.
Por ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla del Data Warehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar
Histórico El tiempo es parte implícita de la información contenida en un Data Warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente.
La información almacenada en el Data Warehouse sirve, entre otras cosas, para realizar análisis de tendencias.
El Data Warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones
No volátil El almacén de información de un Data Warehouse existe para ser leído, y no modificado.
La información es por tanto permanente, significando la actualización del Data Warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.
3.3 Análisis multidimensional
E.F. Codd, considerado como el padre de las bases de datos relacionales, ha venido insistiendo desde principio de los noventa, que disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones.
Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza.
Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio.
3.4 Dimensiones del negocio
Estas dimensiones de negocio se comprenden mejor fijando un ejemplo, para lo que vamos a mostrar, para un sistema de gestión de expedientes, las jerarquías que se podrían manejar para el número del mismo para las dimensiones: zona geográfica, tipo de expediente y tiempo de resolución
4 DATA WAREHOUSING
4.1 Procesos de un DW
A continuación se detallan los procesos que sufre la información en el flujo del Datawarehouse.
Extracción: obtención de información de las distintas fuentes tanto internas como externas.
Elaboración: filtrado, limpieza, depuración, homogeneización y agrupación de la información.
Carga: organización y actualización de los datos y los metadatos en la base de datos.
Explotación: extracción y análisis de la información en los distintos niveles de agrupación.
4.2 Sistema tradicional y Data Warehousing
Las diferencias entre el sistema tradicional transaccional y del de Data Warehousing se detallan a continuación:
Sistema Tradicional Data Warehousing
Predomina la actualización. Predomina la consulta.
La actividad más importante es de tipo operativo, día a día. La actividad más importante es el análisis y la decisión estratégica.
Predomina el proceso Puntual. Predomina el proceso masivo.
Mayor importancia a la estabilidad. Mayor importancia al dinamismo.
Datos en general desagregados. Datos en distintos niveles de detalle y agregación
Importancia del dato actual Importancia del dato histórico.
4.3 Etapas modelado de DW
Para el correcto análisis de un sistema OLAP se deben seguir algunas etapas que ayudarán a modelar correctamente el objeto de análisis de la solución. Se detallan:
Identificación de las necesidades y requerimientos.
En base a los requerimientos, definir las tablas auxiliares y los procesos de selección, transformación e importación de datos.
Reconocimiento de las fuentes de datos originales y sus estructuras.
Construir el esquema multidimensional. Debe controlarse que este esquema concuerde con los requerimientos y las tablas auxiliares, como primera forma de testeo.
Acceso al sistema desde las estaciones de trabajo de los analistas obteniendo la información identificada en la etapa de requerimientos.
4.4 Diseño y modelización
Los requerimientos de información identificados durante la anterior fase proporcionarán las bases para realizar el diseño y la modelización del Data Warehouse.
En esta fase se identificarán las fuentes de los datos (sistema operacional, fuentes externas,..) y las transformaciones necesarias para, a partir de dichas fuentes, obtener el modelo lógico de datos del Data Warehouse. Este modelo estará formado por entidades y relaciones que permitirán resolver las necesidades de negocio de la organización.
El modelo lógico se traducirá posteriormente en el modelo físico de datos que se almacenará en el Data Warehouse y que definirá la arquitectura de almacenamiento del Data Warehouse adaptándose al tipo de explotación que se realice del mismo.
La mayor parte estas definiciones de los datos del Data Warehouse estarán almacenadas en los meta datos y formarán parte de
4.5 METODOLOGIA DE LOS 9 PASOS DE KIMBALL
Ralph Kimball, es reconocido como uno de los padres del concepto de Datawarehouse, se ha dedicado desde hace más de 10 años al desarrollo de su metodología para que éste concepto sea bien aplicado en las organizaciones y se asegure la calidad en el desarrollo de estos proyectos.
Su metodología se enfoca principalmente en el diseño de la base de datos que almacenará la información para la toma de decisiones.
A continuación se detallan un proceso de 9 pasos enfocado a la generación del diseño del modelo:
Paso Detalle
SELECCIÓN DEL PROCESO Hace referencia al tema objetivo del DW.
SELECCIÓN DE LA GRANULARIDAD Implica decidir qué es lo que va a representar cada registro de la fact.
Solo después de seleccionar la granularidad de la fact podremos identificar las dimensiones.
La decisión sobre la granularidad de la fact determina granularidad de cada tabla de dimensión.
IDENTIFICACION Y CONFORMACION DE LAS DIMENSIONES Las dimensiones establecen el contexto para realizar preguntas acerca de los hechos contenidos en la fact.
SELECCIÓN DE HECHOS La granularidad de la fact determina que hechos pueden usarse en el DW.
ALMACENAMIENTO DE LOS VALORES PRECALCULADOS EN LA FACT Determinar si existe la posibilidad de utilizar valores pre calculados.
TERMINACION DE LAS TABLAS DE DIMENSION Volver a las tablas de dimensión y añadimos tantas descripciones textuales a las dimensiones como sea posible.
SELECCIÓN DE LA DURACION DE LA BASE DE DATOS La duración mide hasta que momento del pasado debe retroceder la tabla de hechos.
CONTROL DE LAS DIMENSIONES LENTAMENTE CAMBIANTES Mantenimiento de la historia de los cambios de una dimensión.
SELECCIÓN DE LAS PRIORIDADES DE CONSULTA Y DE LOS MODOS Cuestiones de diseño físico.
5 MODELADO DE DIMENSIONALIDAD
Todo modelo dimensional está compuesto de una tabla central con una clave principal compuesta, denominada Tabla de Hechos, y un conjunto de tablas más pequeñas denominadas Tablas de Dimensión.
Cada tabla de Dimensión contiene una clave principal simple (no compuesta) que se corresponde exactamente con uno de los componentes de la clave compuesta de la tabla de Hechos.
Otra característica importante de un modelo DM es que todas las claves naturales se sustituyen por claves subrogadas (SK). Esto significa que toda combinación entre la tabla de hechos y las dimensiones está basada en claves subrogadas y no naturales.
Cada clave subrogada debe tener una estructura generalizada basada en enteros simples.
5.1 ESQUEMA ESTRELLA
Una estructura lógica que tiene una tabla de hechos que contiene datos factuales en el centro, rodeada por tablas de dimensión que contienen datos de referencia (que pueden estar des normalizados)
Los Hechos más útiles de una tabla de hechos son numéricos y aditivos.
Las tablas de dimensión, por contraste, contienen generalmente información contextual descriptiva.
Los esquema estrella pueden utilizarse para acelerar la velocidad de las consultas, des normalizando la información de referencia en una única tabla de dimensión.
5.2 ESQUEMA EN COPO DE NIEVE
Una estructura variante del estrella en el que las tablas de dimensión no contienen datos des normalizados.
5.3 Tabla de Hechos
Un DW, clasifica la información en base a los aspectos que son de interés para la empresa. Estos aspectos pueden ser los sujetos de los cuales formarán las dimensiones y los hechos que formarán las Tablas de Hechos.
El modelo dimensional divide el mundo de los datos en dos grandes tipos: las medidas y las dimensiones de estas medidas.
Las medidas, siempre son numéricas, se almacenan en las tablas de hechos y las dimensiones que son textuales se almacenan en las tablas de dimensiones.
La tabla de hechos es la tabla primaria del modelo dimensional, y contiene los valores del negocio que se desea analizar.
Cada tabla de hechos contiene las claves externas (FK), que se relacionan con sus respectivas tablas de dimensiones (PK), y las columnas con los valores que serán analizados.
Ejemplos de Hechos:
• En un hospital: admisión de pacientes
• En un operador telefónico: Tráfico telefónico
Un hecho es un concepto de interés primario para el proceso de toma de decisiones, corresponde a eventos que ocurren dinámicamente en el negocio de la empresa.
5.4 Dimensiones
Diseñaremos y construiremos cada dimensión basados en los procesos de negocio definidos por el cliente.
Las dimensiones organizan los datos en función de un área de interés para los usuarios.
Cada dimensión describe un aspecto del negocio y proporciona el acceso intuitivo y simple a datos.
Una dimensión provee al usuario de un gran número de combinaciones e intersecciones para analizar datos.
Las tablas de dimensiones son las compañeras de las tablas de hechos. Cada dimensión se define por su clave primaria que sirve para mantener la integridad referencial en la tabla de hechos a la que se relaciona.
Un cubo requiere que se defina al menos una dimensión en su esquema.
5.5 Relaciones y Estructura de una dimensión
Cada nivel de una dimensión debe corresponderse con una columna en la tabla de la dimensión. Los niveles se ordenan por grado de detalle y se organizan en una estructura jerárquica. Cada nivel contiene miembros, los miembros son los valores de la columna que define el nivel.
Entre los miembros y entre los niveles de una dimensión existen relaciones, estas se pueden comprender como las relaciones que existen en un árbol genealógico donde los términos padre, hijo, hermano, primo, etc. indican una correspondencia entre elementos del árbol; y los miembros de la dimensión se comportan como familiares dentro del árbol genealógico.
5.6 Dimensiones: Padre – Hijo (Parent – Child)
Una dimensión padre-hijo es una dimensión donde el dato del Padre se relaciona con el Hijo y ambos se encuentran en la misma tabla de dimensión, es decir, la dimensión se relacionan consigo misma.
5.7 Medidas
Las medidas son los valores de datos que se analizan.
Una medida es una columna cuantitativa, numérica, en la tabla de hechos. Las medidas representan los valores que son analizados, como cantidad de pacientes admitidos o llamadas efectuadas.
Las medidas son:
o Valores que permiten analizar los hechos
o Valores numéricos porque estos valores son las bases de las cuales el usuario puede realizar cálculos.
Si la medida fuera un valor no numérico debemos codificarla a un valor numérico en el proceso de obtención de datos, y luego cuando tengamos que exponer sus valores decodificarla para mostrarla con el valor original.
Las siguientes son algunas de las características de las medidas:
o Deben ser numéricas.
o Cruzan todas las dimensiones en todos los niveles.
Las medidas pueden clasificarse en:
o Naturales - Columnas de las tablas de hechos
o Calculadas - Surgen a partir de las Naturales
Cuando definimos una medida debemos tener en cuenta cual será la forma de agregación (agrupación de la misma) al subir por la estructura dimensional.
Estas formas de agregación pueden ser:
o Suma: es la operación que suma los valores de las columnas
o Cuenta: realiza un conteo de los valores
o Mínima: devuelve un valor mínimo
o Máxima: proporciona el mayor de los valores
o Cuenta de Distintos: cuenta los valores diferentes
Las agregaciones son resúmenes de datos pre calculados que mejoran el tiempo de respuesta por el simple hecho de tener preparadas las respuestas antes de que se planteen las preguntas (agrupación de las mismas).
5.8 Tipos de Almacenamiento
5.8.1 MOLAP
En el modo de almacenamiento MOLAP (OLAP Multidimensional) una copia de los datos de origen del cubo, junto con sus agregaciones, es almacenada en una estructura multidimensional.
Debemos tener en cuenta que mientras los datos de origen cambian directamente con las operaciones, los objetos con almacenamiento MOLAP deben ser procesados para incorporar estos cambios.
El tiempo comprendido entre un procesamiento y el siguiente, crea un periodo de latencia durante el que puede que la información OLAP no coincida con los datos de origen actuales.
Como característica del almacenamiento MOLAP podemos destacar:
• Provee excelente rendimiento y compresión de datos.
• Tiene mejor tiempo de respuesta, dependiendo solo del porcentaje de las agregaciones del cubo.
• La estructura está muy optimizada para maximizar el rendimiento de las consultas.
• En general este método, es muy apropiado para cubos con uso frecuente por su rápida respuesta.
5.8.2 ROLAP
En un modelo ROLAP (OLAP Relacional) toda la información del cubo, sus datos, su agregación, sumas, etc., son almacenados en una base de datos relacional.
A diferencia del modo de almacenamiento MOLAP, ROLAP no almacena copia de la base de datos, accede a las tablas originales cuando necesita responder a las consultas, generalmente es mucho más lenta que las otras estrategias de almacenamiento (MOLAP o HOLAP).
ROLAP se utiliza para ahorrar espacio de almacenamiento cuando se trabaja con grandes conjuntos de datos que se consultan con poca frecuencia; por ejemplo, datos exclusivamente históricos.
Los usos comunes de este esquema son:
• Cuando los clientes desean ver los cambios inmediatamente.
• Cuando contamos con grandes conjuntos de datos que no son frecuentemente buscados
5.8.3 HOLAP
HOLAP (OLAP híbrido) combina atributos de MOLAP y ROLAP.
Al igual que MOLAP, HOLAP hace que las agregaciones se almacenen en una estructura multidimensional, y los datos a nivel de detalle, en una base de datos relacional como lo hace el almacenamiento ROLAP.
Para procedimientos de búsqueda que accedan datos sumarizados, HOLAP es equivalente a MOLAP. Por el contrario, si los procesos de consultas accedieran a los máximos niveles de detalle, deberían recuperar los datos de la base de datos relacional y esto no seria tan rápido comparado con una estructura MOLAP.
Los cubos almacenados como HOLAP, son más pequeños que los MOLAP y responden más rápidos que los ROLAP.
Usos comunes de HOLAP
• Cubos que requieren rápida respuesta.
• Cuando existen sumarizaciones basadas en una gran cantidad de datos de origen.
• Solución de compromiso para bajar el espacio ocupado sin perjudicar totalmente el rendimiento de las consultas.
5.9 Definición de Agregaciones
Otro factor para considerar en la implementación del modelo OLAP, además del modo de almacenamiento, es la definición del porcentaje de agregaciones.
Se denomina agregación al proceso de pre calcular el cálculo de los datos a través de los niveles, para disminuir los tiempos de respuestas en los procesos de búsquedas de información. El porcentaje de agregación da idea de la proporción o profundidad hasta la que se realizarán el pre cálculos.
Las agregaciones se almacenan en la estructura multidimensional (según el modo de almacenamiento que escogimos).
Cuando definamos agregaciones debemos tener en cuenta de especificar las restricciones de almacenamiento y de porcentaje de agregación, a fin de lograr una buena solución de compromiso entre el tiempo de respuesta a las consultas y los requisitos de almacenamiento.
Si calculáramos todas las agregaciones posibles necesitaremos gran cantidad de tiempo de procesamiento y espacio de almacenamiento. Si por el contrario, no se pre calculan agregaciones (0%), la cantidad de espacio de almacenamiento que se necesita se reduce al mínimo, pero el tiempo de respuesta aumenta.
Por lo tanto, suele existir un equilibrio entre el espacio de almacenamiento, el porcentaje de posibles agregaciones que se pre calculan y la performance requerida.
Características de las agregaciones:
• Las agregaciones permiten mejorar los tiempos de respuesta
• Requieren de almacenamiento adicional
• Si no son controladas pueden provocar una explosión en los requisitos de almacenamiento
A mayor número de agregaciones más tiempo de procesamiento y más requerimiento de espacio.
A menor número de agregaciones peor tiempo de respuesta de las consultas y menos requerimiento de espacio.
Esta definición debe considerar los siguientes factores
• Modo de almacenamiento que escogimos (MOLAP-ROLAP-HOLAP)
• Tamaño de la tabla de hechos (cantidad de registros)
• Numero de dimensiones del modelo
• Porcentaje de agregaciones
Para determinar la frecuencia con que procesaremos el cubo debemos tener en cuenta lo analizado con el cliente respecto de la granularidad de los datos para el tiempo. EL nivel de detalle (día, mes, etcétera) nos fijará la periodicidad de actualización de los datos.
A diferencia de los sistemas OLTP en los que la actualización de los datos se realiza en línea con las transacciones y la agregación de los datos se realiza en el momento en que el usuario realiza una consulta, en OLAP el procesamiento de los cubos se realiza a contra turno, en los horarios en que no se afecta la tarea de los usuarios.
5.10 Particiones
Los cubos están compuestos por particiones. Como su nombre lo sugiere, una partición es una división o fraccionamiento de la información que conforma a un cubo. Cada cubo contiene al menos una partición, pero puede estar compuesto por múltiples particiones.
Las particiones de un cubo son invisibles para el usuario, pero su uso aumenta la carga de trabajo del administrador del modelo multidimensional.
Para cada partición podemos definir la fuente de datos, el modo de almacenamiento y el porcentaje de agregación de manera independiente de las demás particiones.
Además, una partición de datos puede ser actualizada independientemente de las otras. Esta propiedad es muy importante ya que nos brinda la ventaja de mejorar los tiempos de procesamiento si dividimos correctamente las particiones y las procesamos adecuadamente.
Así, si dividimos nuestro cubo en particiones definiremos cada unos de estos parámetros de la manera mas indicada.
Partición más utilizada (Tiempo Actual):
Modo de Almacenamiento MOLAP,
% de Agregación: alto (estimado:40%)
Frecuencia de procesamiento: alta
Partición medianamente consultada (Tiempos intermedios):
Modo de Almacenamiento: HOLAP
% de Agregación: bajo (estimado:10%)
Frecuencia de procesamiento: ocasional
Partición poco accedida (Períodos viejos):
Modo de Almacenamiento ROLAP,
% de Agregación: nulo (estimado:0%)
Frecuencia de procesamiento: muy baja (normalmente sólo al crear la partición)
5.11 Transformación y agrupación de datos – ETL
Los datos que alimentan a un sistema DW provienen de diferentes fuentes, estas fuentes son los distintos sistemas operacionales que la empresa posee, generalmente ni son homogéneos entre sí ni concuerdan exactamente con lo que se necesita, por lo que será necesario realizar todas las adaptaciones pertinentes.
Los diferentes procesos que se concentran en el concepto de toma, transformación y carga de datos en un DW se denominan ETL, sus siglas en inglés significan Extract – Transform – Load.
Al reunir datos de los diferentes sistemas, se debe definir una norma única para el DW y realizar las transformaciones que sean necesarias en cada caso. Básicamente deben realizarse las siguientes tareas:
• Establecer las reglas que serán utilizadas para realizar la transformación.
• Detectar las inconsistencias que pueden originarse al tomar los datos desde distintas fuentes.
• Planificar cuidadosamente y con detalles la transformación de los datos que den como resultado final conjuntos de datos consistentes.
6 EXPRESIONES MULTIDIMENSIONALES – MDX
Las expresiones multidimensionales (MDX es el acrónimo de MultiDimensional eXpressions) es un lenguaje de consulta para bases de datos multidimensionales sobre cubos OLAP, se utiliza en Business Intelligence para generar reportes para la toma de decisiones basados en datos históricos, con la posibilidad de cambiar la estructura, o permitiendo rotar el cubo.
Una consulta MDX es muy similar a una consulta SQL, nos devuelve un conjunto de celdas, que es resultado de tomar un subconjunto de las celdas del cubo original.
Consulta MDX Básica:
Sintaxis: SELECT
A continuación se estarán detallando una serie de ejemplos de consultas MDX tomando distintos parámetros que serán de utilidad al momento de realizar el análisis requerido para el negócio:
Comma (,) and Colon (:)
Indica cómo se separan los elementos en una consulta.
{[Time ].[January 2005 ],[Time ].[February 2005 ],[Time ].[March 2005 ] }}
SELECT
{[Time ].[Sep,2004 ]: [Time ].[Mar,2005 ] }}on columns,
{[Product ].[Tools ]: [Product ].[Home Audio ] }}on rows
FROM [Sales ]
WHERE ([Customer ].[Lubbock,TX ],[Measures ].[Unit Sales ])
{{[Time ].[January-2001 ] :[Time ].[March-2001 ] }},{[Time ].[October-2001 ] :[Time ].[December-2001 ] }}}
{[Time ].[2001 ],{[Time ].[January-2001 ] :[Time ].[March-2001 ] }}}
.MEMBERS
Retorna todos los miembros de una jerarquía o atributo.
SELECT
{[Scenario ].Members }on columns,
{[Store ].Members }on rows
FROM Budgeting
.Children
Retorna todos los hijos de los miembros de una jerarquía o atributo.
SELECT
{[Time ].[Q3,2005 ].Children }
on columns,
{[Product ].[Tools ],[Product ].[Tools ].Children }
on rows
FROM Sales
WHERE ([Customer ].[TX ],[Measures ].[Unit Sales ])
Descendants()
Es una función que retorna los hijos de un miembro determinado.
Descendants (member [,[level ] [,flag ]] ))
SELF - miembros del nivel indicado (por defecto)
BEFORE - miembros anteriores al nivel indicado
AFTER - miembros siguientes al nivel indicado
SELF_AND_BEFORE - miembros del nivel indicado y los miembros anteriores al nivel
SELF_AND_AFTER - miembros del nivel actual mas los miemros siguientes.
SELF_BEFORE_AFTER - miembros anteriores, actual y siguientes
SELECT
{[Product ].[Tools ],[Product ].[Toys ] }}ON COLUMNS,
descendants([Time].[2005],[Time].[Month],SELF)ON ROWS
FROM Sales
WHERE [Measures ].[Dollar Sales ]
SELECT
crossjoin([Fecha].[Año].members,
CrossJoin({[Promoción].[Todos Promoción].[Bulk Mail].[Bag Stuffers]},{[Store Sales],[Store Cost]})) on 0,
descendants([Producto].[Todos Producto].[Baking Goods],[Producto].[Product Subcategory],self_before_after) on 1
FROM Sales
SELECT
crossjoin(descendants(
[Fecha].[Todos Fecha].[1997],
[Fecha].[Mes],self),
CrossJoin({[Promoción].[Todos Promoción].[Bulk Mail].[Bag Stuffers]},
{[Store Sales],[Store Cost]})) on 0,
descendants([Producto].[Todos Producto].[Baking Goods],[Producto].[Product Subcategory],self_before_after) on 1
FROM Sales
NON EMPTY
No retorna los empty
SELECT
{[Time ].[Jan,2005 ],[Time ].[Feb,2005 ] }} ON COLUMNS,
NON EMPTY{[Product ].[Toys ],[Product ].[Toys ].Children} ON ROWS
FROM Sales
WHERE ([Measures ].[Dollar Sales ],[Customer ].[TX ])
Comentarios
/* */
//
Tuplas
Combinación de miembros de una o mas dimensiones
([Customer ].[Chicago,IL ],[Time ].[Jan,2005 ])
Sets
Colección de tuplas
{([Time ].[2005 ],[Measures ].[Dollar Sales ] )),
([Time ].[Feb,2005 ],[Measures ].[Unit Sales ] ))
}
CrossJoin()
Función que permite realizar un cruce entre dos o mas colecciones de tuplas.
CrossJoin (set1 ,set2 )
SELECT
CrossJoin (
{[Time ].[Q1,2005 ],[Time ].[Q2,2005 ]},
{[Measures ].[Dollar Sales ],[Measures ].[Unit Sales ] }
)
ON COLUMNS ,
{[Product ].[Tools ],[Product ].[Toys ] }ON ROWS
FROM Sales
SELECT
crossjoin(descendants(
[Fecha].[Todos Fecha].[1997],
[Fecha].[Mes],self),
CrossJoin({[Promoción].[Todos Promoción].[Bulk Mail].[Bag Stuffers]},
{[Store Sales],[Store Cost]})) on 0,
descendants([Producto].[Todos Producto].[Baking Goods],[Producto].[Product Subcategory],self_before_after) on 1
FROM Sales
Filter()
Función que permite filtrar una tupla en base a una expression.
Filter (set ,boolean-expression )
Filter (
{[Product ].[Product Category ].Members },
[Measures ].[Dollar Sales ] >>=500
)
Filter (
{[Product ].[Product Category ].Members },
([Measures ].[Dollar Sales ] >>=1.2 *[Measures ].[Dollar Costs ])
AND [Measures ].[Dollar Sales ] >>=150
)
Filter (
CrossJoin (
[Product ].[Product Category ].Members,
[Store ].[City ].Members
),
[Measures ].[Dollar Sales ] >>=500
)
Order()
Función que ordena los miembros de una tupla en base a una expresión.
Order (set1 ,expression [,ASC DESC BASC BDESC ])
SELECT
{[Measures ].[Dollar Sales ] }on columns,
Order (
[Product ].[Product Category ].Members,
[Measures ].[Dollar Sales ],
BDESC
)
on rows
FROM [Sales ]
WHERE [Time ].[2004 ]
SELECT
CrossJoin (
{[Time ].[2004 ],[Time ].[2005 ]},
CrossJoin (
{[Customer ].[Northeast ],[Customer ].[West ] },
{([Measures ].[Dollar Sales ],[Measures ].[Unit Sales ] }
)
)on columns,
Order (
[Product ].[Product Category ].Members,
([Measures ].[Unit Sales ],[Time ].[2005 ],
[Customer ].[All Customers ]),
BDESC
)on rows
FROM [Sales ]
SELECT
CROSSJOIN({[Fecha].[Todos Fecha].[1997],[Fecha].[Todos Fecha].[1998]},
CROSSJOIN({[Producto].[Todos Producto].[Candles].[Candles],[Producto].[Todos Producto].[Candy].[Chocolate Candy]},{[Store Sales],[Store Cost]})) on 0,
ORDER(DESCENDANTS([Almacén].[Todos Almacén].[USA],[Almacén].[Store State]),([Store Sales],[Cliente].[Todos Cliente]),BDESC) on 1
FROM Sales
DIMENSION PROPERTIES
Las propiedades de miembro cubren la información básica de todos los miembros de cada tupla. Esta información básica incluye el nombre del miembro, el nivel primario, el número de secundarios, etc. Las propiedades de miembro están disponibles para todos los miembros de un determinado nivel. En términos de organización, las propiedades de miembro se tratan como datos organizados dimensionalmente, almacenados en una sola dimensión.
SELECT
{[Customer ].[Akron,OH ].Children }
DIMENSION PROPERTIES [Customer].[Zip Code],
[Customer].[Individual].[Hair Color]
on columns,
{[Product ].[Category ].Members }on rows
FROM Sales
WHERE ([Measures ].[Units Sold ],[Time ].[July 3,2005 ])
-----------------------------------------------------------------------
WITH MEMBER MemberIdentifier AS ‘member-formula ’ [,properties ...]
WITH MEMBER [Measures].[Avg Sales Price] AS ‘[Measures].[Dollar Sales] / [Measures].[Unit Sales]’
SOLVE_ORDER
Calcula el orden de ejecución de la consulta
WITH
MEMBER [Measures ].[Avg Sales Price ] AS
‘[Measures ].[Dollar Sales ] //[Measures ].[Unit Sales ]’,
SOLVE_ORDER = 0
MEMBER [Time ].[Q1 to Q2 Growth ] AS
‘[Time ].[Q2,2005 ]-[Time ].[Q1,2005 ]’,
SOLVE_ORDER = 1
SELECT
{[Measures ].[Dollar Sales ],[Measures ].[Unit Sales ],[Measures ].[Avg Sales Price ]} on columns,
{[Time ].[Q1,2005 ],[Time ].[Q2,2005 ],[Time ].[Q1 to Q2 Growth ] } on rows
FROM [Sales ]
WHERE ([Customer ].[MA ])
Avg()
Función que calcula el promedio de una tupla en relación a una expresión numérica.
Avg (set [,numeric_value_expression ])
Avg (
{[Product ].[Tools ],
[Product ].[Toys ],
[Product ].[Indoor,Outdoor Games ] }},
[Measures ].[Dollar Sales ]
)
Count(), .Count
Función que cuenta la cantidad de miembros de una tupla.
Count (set [,EXCLUDEEMPTY INCLUDEEMPTY ] ))
Count (
CrossJoin (
{[Measures ].[Unit Sales ] }},
[Product ].[Tools ].Children
)
)
DistinctCount()
Función que cuenta la cantidad de miembros distintos de una tupla.
DistinctCount (set )
DistinctCount (
[Measures ].[Dollar Sales ] **
{[Product ].[Tools ],[Product ].[Toys ],
[Product ].[Indoor,Outdoor Games ]
}
)
Sum()
Función que suma los miembros de una tupla en relación a una expresión numérica.
Sum (set [,numeric_value_expression ])
Sum (
{[Product ].[Tools ],
[Product ].[Toys ],
[Product ].[Indoor,Outdoor Games ] }},
[Measures ].[Dollar Sales ]
)
Max()
Función que retorna el valor máximo de una tupla en relación a una expresión numérica.
Max (set [,numeric_value_expression ])
Max (
{[Product ].[Tools ],
[Product ].[Toys ],
[Product ].[Indoor,Outdoor Games ] }},
[Measures ].[Dollar Sales ]
)
Median()
Devuelve el valor medio de una expresión numérica evaluada sobre un conjunto.
Median (set [,numeric_value_expression ])
Median (
[Product ].[Tools ].Children,
[Measures ].[Dollar Sales ]
)
Min()
Devuelve el valor mínimo de una expresión numérica evaluada sobre un conjunto.
Min (set [,numeric_value_expression ])
Min (
[Product ].[Tools ].Children,
[Measures ].[Dollar Sales ]
)
NonEmptyCount()
Función que retorna la cantidad no vacía de una tupla.
NonEmptyCount (set [,numeric_value_expression ])
NonEmptyCount (
[Product ].[Tools ].Children,
[Measures ].[Unit Sales ]
)
Using the .CurrentMember function
Devuelve el miembro actual de una jerarquía especificada durante la iteración.
Dimension .CurrentMember
****
Using the .Parent function
Devuelve el elemento primario de un miembro.
Member .Parent
****
[Measures ].[Unit Sales ] / ([Measures ].[Unit Sales ],[Product ].CurrentMember.Parent)
Using the Ancestor() function
Función que devuelve el antecesor de un miembro especificado en un nivel especificado oa una distancia especificada del miembro.
Ancestor (member ,level )
[Measures ].[Unit Sales ] /([Measures ].[Unit Sales ],Ancestor ([Product ].CurrentMember,[Product ].[Family ]))
.PrevMember and .NextMember
Devuelve el miembro anterior y siguiente en el nivel que contiene un miembro especificado.
WITH MEMBER [Measures ].[Unit Sales Increase ] AS
‘[Measures ].[Unit Sales ]
-([Measures ].[Unit Sales ],[Time ].CurrentMember.PrevMember)
SELECT
{[Time ].[Oct,2005 ].PrevMember [Time ].[Oct,2005 ] }}on columns,
{[Measures ].[Unit Sales ],[Measures ].[Unit Sales Increase ] }}on rows
FROM Sales
ParallelPeriod()
Devuelve un miembro de un periodo anterior en la misma posición relativa que el indicado.
WITH MEMBER [Measures ].[Unit Sales YAgo Increase ] AS
‘[Measures ].[Unit Sales ]
-([Measures ].[Unit Sales ],
ParallelPeriod ([Time].[Year], 1, [Time].CurrentMember))'
SELECT
{[Time ].[Quarter ].[Q1,2005 ],
[Time ].[Quarter ].[Q1,2005 ].Children}on columns,
{[Measures ].[Unit Sales ],[Measures ].[Unit Sales YAgo Increase ] }}on
rows
FROM Sakes
PeriodsToDate()
Devuelve un conjunto de miembros del mismo nivel que un miembro determinado, empezando por el primer miembro del mismo nivel y acabando con el miembro en cuestión, de acuerdo con la restricción del nivel especificado en la dimensión de tiempo.
WITH MEMBER [Measures ].[YTD Dollar Sales ] AS
‘Sum (
PeriodsToDate ( [Time].[Year], [Time].CurrentMember )
[Measures ].[Dollar Sales ]
)’
SELECT
{[Time ].[Quarter ].[Q3,2000 ],[Time ].[Quarter ].[Q4,2000 ],
[Time ].[Quarter ].[Q1,2001 ]
}on columns,
{[Measures ].[Expenses ],[Measures ].[YTD Expenses ] }}on rows
FROM Costing
[Time ].CurrentMember.Level.Members.Item(0)
OpeningPeriod ([Time ].[All Time ],[Time ].CurrentMember.Level)
OpeningPeriod ([Time ],[Time ].CurrentMember.Level)
LastPeriods()
Devuelve un conjunto de miembros hasta un miembro determinado, éste inclusive.
SELECT
{LastPeriods (-4 [Time ].[Mar,2005 ] ))}
on columns,
{[Product ].[Toys ],
[Product ].[Toys ].Children
}
on rows
FROM Sales
WHERE [Measures ].[Unit Sales ]
SELECT {[Measures].[Sales Amount]} ON 0,
{[Product].[Product Categories].[Category]} ON 1
FROM (SELECT -{[Product].[Product Categories].[Category].&[3]} ON 0
FROM [Adventure Works])
CREAR UN SET
CREATE SET [User Selection] AS
‘Filter (
[Product].[Category].Members,
[Measures].[Dollar Sales] > 5000
)’
WHERE ([Time].[Q1, 2005])
Subscribe to:
Posts (Atom)