Embed Size (px)
Citation preview
Analysis Server 2008
Diseño multidimensional. Tecnología OLAP
Tutorial
Marta Zorrilla
Universidad de Cantabria
©2010
Tabla de contenidos
1. Uso de Microsoft Analysis Services __________________________________ 3
1.1. Cómo crear un cubo OLAP ____________________________________________ 5
1.2. Construir dimensiones________________________________________________ 12 1.2.1. Propiedades de las dimensiones_____________________________________________16 1.2.2. Elegir cómo ordenar los miembros de un nivel. ________________________________17
1.3. Definir medidas y miembros calculados en los cubos_______________________ 17 1.3.1. Creación de conjuntos para consultas ________________________________________23 1.3.2. Propiedades del cubo_____________________________________________________25
1. Uso de Microsoft Analysis Services
En este apartado se introduce al lector en el uso de la herramienta de Microsoft que permite hacer análisis multidimensional. Su nombre es Microsoft Analysis Services.
A continuación se realizan unas consideraciones que van a ayudar a hacer un buen uso de la herramienta.
Un cubo OLAP es una representación multidimensional de los datos detallados (filas concretas) y de los resumidos (agregados). Se utilizan para consultas analíticas complejas que buscan información en la base de datos desde puntos de vista distintos, que quedan establecidos por sus dimensiones. Cada cubo representa una entidad de negocio diferente, como ventas o recursos humanos.
Los cubos se crean a partir de un esquema de base de datos en estrella o en copo de nieve. Estos se caracterizan por tener tablas de hechos y tablas de dimensiones. Las tablas de hechos guardan los datos históricos. Estos generalmente son medidas numéricas que describen una transacción del negocio que se trate (ventas, transacciones bancarias,...). Las tablas de dimensiones se emplean para especificar el significado de los datos contenidos en la tabla de hechos.
El esquema en estrella, Figura 1, se caracteriza por tener una tabla de hechos en el centro rodeada de tablas de dimensiones que contienen la descripción de los hechos desnormalizados. El esquema en copo de nieve es una extensión del modelo en estrella en el que una o más dimensiones se definen por varias tablas.
Figura 1. Ejemplo de esquema en estrella.
Los cubos OLAP son esencialmente las funciones de agregación que se calculan de acuerdo con el esquema en estrella o copo de nieve.
Los datos y las agregaciones del cubo pueden almacenarse de diferentes modos: MOLAP, ROLAP, HOLAP.
La estructura MOLAP almacena los datos y las agregaciones en una estructura multidimensional. Permite dimensiones que contengan hasta 5 millones de miembros. Es la más eficiente en búsquedas, independiente del gestor y la que requiere mayor tiempo de procesado y de espacio en disco. Una desventaja es que hay que actualizarlo para que incorpore los datos nuevos que vayan entrando al DW.
La estructura ROLAP mantiene los datos en la tabla de hechos original y almacena las agregaciones en tablas relacionales de la misma base de
datos. Es más lenta la búsqueda pero es válida aunque el tamaño del cubo exceda los 5 Gb, donde MOLAP tiene problemas.
La estructura HOLAP mantiene los datos en la tabla de hechos original y almacena las agregaciones en una estructura multidimensional.
1.1. Cómo crear un cubo OLAP
A continuación se establecerán los pasos para crear un cubo OLAP sobre la base de datos Ventas_dwh.
Se abre la herramienta SQL Server Business Intelligence Development Studio, eligiendo como tipo de proyecto Analysis Service. Comprobad que el servicio Analysis Services está iniciado.
El primer paso es crear un Origen de datos configurándolo hacia la base de datos donde residen los esquemas en estrella. En este caso, la base de datos ventas_dwh en SQL Server2008. Indicar en carpeta de Impersonation Information qué usuario utiliza Analysis Services para conectarse a la BD relacional, poner por defecto la cuenta asociada al servicio (Figura 3).
Figura 2. Definir el origen de datos.
Figura 3. Definir el origen de datos.
A continuación se crea un Vista de los orígenes de datos que recoja el esquema de nuestra estrella. Los proyectos de proceso analítico en línea (OLAP) y minería de datos de Microsoft SQL Server se diseñan basándose en un modelo de datos lógico de tablas, vistas y consultas relacionadas de uno o varios orígenes de datos. Este modelo de datos lógico se denomina vista de origen de datos. Una vista de origen de datos es un objeto que contiene los metadatos de objetos de origen de datos seleccionados, incluidas las relaciones entre estos objetos definidos en el origen de datos subyacente o en la vista de origen de datos. Una vista de origen de datos almacena en caché los metadatos de los orígenes de datos a partir de los cuales se genera. Los metadatos almacenados en caché le permiten desarrollar un proyecto de Analysis Services sin tener una conexión activa continua con el origen de datos.
Figura 4. Definir vista del origen de datos.
Antes de proseguir crear la referencia entre supervisor y EmpleadoID.
En este momento ya se pueden definir los cubos que sean necesarios para nuestro Data Warehouse. Para ello se selecciona la opción “Nuevo cubo” – “Asistente” que arrancará el asistente de creación de cubos (ver Figura 5).
Figura 5. Invocar al asistente de generación de cubos.
El asistente presenta la pantalla de la Figura 6.
Figura 6. Pantalla inicial del asistente para generación de cubos.
Al pulsar “Siguiente>>”, presenta la pantalla de la Figura 7 donde se seleccionará la vista del origen de datos que proporcionará los datos al cubo.
Figura 7. Selección de la vista de origen de datos y tabla de hechos
A continuación, tras pulsar “Siguiente >” se presenta la pantalla de la Figura 8 donde el asistente detecta las medidas a crear.
Figura 8. Selección de medidas
A continuación muestra las dimensiones que detecta y crea además las jerarquías subyacentes en función de las relaciones que encuentra (puede que no tengan sentido para nosotros). Hay jerarquías de atributo (se crean para cada atributo de la tabla de dimensión) y jeraquías de usuario (que constan de varios niveles). A continuación se confirman o modifican las tablas de hechos y dimensiones detectadas por el asistente (Figura 9).
Figura 9. identificación de tabla de hechos y dimensiones
Por último se observa el cubo definido (Figura 10).
Figura 10. Cubo definido
Ahora vamos a revisar las medidas definidas. Se puede observar en carpeta Propiedades la operación definida sobre cada una de las medidas. Todas ellas tienen la operación SUM por defecto, a excepción del atributo Recuento Ventas Fact que es COUNT. Atención con PedidoID no tiene sentido sumarizarlo, este lo utilizaremos para medidas calculadas, así que lo eliminamos.
Una vez diseñado el cubo hay que construirlo. Para ello se elige la opción Procesar del menú Generar y se pulsa Ejecutar, sino hay ningún error se mostrará la imagen de la Figura 11.
Figura 11. Cubo construido
Ahora ya podemos utilizarlo (construir consultas) desde la carpetilla Examinador.
Figura 12. Examinando el cubo.
Se observa que las dimensiones no ofrecen atributos ni jerarquías de interés por lo que hay que editarlas y modificarlas.
1.2. Construir dimensiones
Comenzamos revisando la dimensión Producto. Para ello pulsamos doble clic sobre la dimensión en la ventana del Explorador de soluciones. Vemos que por defecto el asistente solo asigna el atributo clave. Así que incorporaremos a la dimensión los distintos atributos por los que se quiera consultar. También crearemos dos jerarquias de usuario: categoría � producto y suministrador � producto
Consideraremos mínimoStock y obsoleto como propiedades del nombre del producto pues no tiene mucho sentido como atributo de consulta, aunque en la dimensión se mantendrá (se establece en versión 2008 en la carpetilla Relaciones de atributos). La idea de las propiedades es poder mostrar esta información en vez de navegar por la jerarquía de atributos para verla.
Nota en Versión 2005: hay que establecer la Cardinalidad a 1 en la relación del atributo (un producto tiene un mínimo stock y solo una situación de obsoleto).
En versión 2008: se hace por medio del establecimiento de las relaciones de atributo (ver Figura 14). Para cada tabla incluida en una dimensión, hay una relación de atributos que relaciona el atributo clave de la tabla con otros atributos en esa tabla. Esto tiene como ventaja:
- Reducir la cantidad de memoria necesaria para procesar la dimensión. Esto acelera el procesamiento de dimensiones, particiones y consultas.
- Aumentar el rendimiento de las consultas porque el acceso al almacenamiento es más rápido y se optimizan mejor los planes de ejecución.
- Hacer que los algoritmos de diseño de agregaciones seleccionen agregados más efectivos, siempre y cuando las jerarquías definidas por el usuario se hayan establecido a lo largo de las rutas de acceso de la relación.
La principal restricción al crear una relación de atributos consiste en asegurarse de que el atributo al que la relación de atributos hace referencia no tenga más de un valor para ningún miembro en el atributo al que pertenece la relación de atributos. Por ejemplo, si se define una relación entre un atributo ProductoNombre y una CategoriaNombre, cada productoNombre sólo puede relacionarse con una única CategoriaNombre.
Figura 13. Definir dimensión.
Figura 14. Definir relaciones de atributo.
Al explorar la dimensión, podemos seleccionar cada uno de los atributos o jerarquías y visualizar las propiedades de sus miembros al pulsar el botón Propiedades (Figura 15).
Figura 15. Dimensión con sus propiedades.
La dimensión Transporte requiere únicamente añadir el atributo nombre.
En la dimensión Cliente crearemos las jerarquías que se ven en la figura 16.
Figura 16. Dimensión cliente.
En la dimensión Empleado, se observa que ha creado una jerarquía por supervisor al detectar la relación reflexiva supervisor-empleado. Se puede observar que el asistente ha identificado supervisor como uso de atributo primario (ver icono en sección de atributos). Si vemos los datos de la jerarquía, ésta solo contiene números, los que representa la clave (empleadoKey). Si queremos que en vez de mostrar la clave muestre el nombre, cambiamos la propiedad NameColumn (Figura 17). Además crearemos la jerarquía Puesto � empleado.
Figura 17. Dimensión empleado cambiada por la relación primario-clave.
Por último está la dimensión temporal. Crearemos las jerarquías especificadas en la Figura 18. Observar que aunque la jerarquía Año-trimestre-mes-dia tiene el atributo mes, se ha puesto en NameColumn el MesAño para que salga el texto y no el número, también podemos elegir el atributo MesAño. Además se ha establecido la ordenación de cada atributo por key y no por name para que la ordenación sea númerica y no alfanumérica.
Figura 18. Dimensión Tiempo.
1.2.1. Propiedades de las dimensiones
A continuación se comentarán algunas propiedades de las dimensiones que permiten personalizar el comportamiento de las mismas.
Propiedades dimensión:
AttributeAllMemberName: texto que se mostrará para el nivel superior (Todos)
Default member: El miembro predeterminado se utiliza cuando se evalúa una celda y no hay ningún otro miembro especificado para la dimensión (condición por la cuál se hace el browse de los datos). Esta es utilizada si la dimensión no está incluida en una consulta. Por defecto el Analysis Server incluye todas las dimensiones en la consulta para que luego el usuario haga los filtros.
Member keys unique: Indica si las claves de miembro son únicas a través de toda la dimensión.
Member name unique: Indica si los nombres de miembros son únicos a través de toda la dimensión. Caso de una dimensión versionada.
Storage Mode: modo de almacenamiento Molap o Rolap.
Propiedades nivel:
Member key column: Indica el nombre de la columna que contiene las claves de miembro.
Member name column: Indica el nombre de la columna que contiene el nombre de los miembros. Este valor puede ser un campo o una
concatenación de ellos ("producto"."producto_nombre" + ‘ ‘ + "producto"."producto_version")
1.2.2. Elegir cómo ordenar los miembros de un nivel.
Member key column tiene un número entero que referencia a cada miembro.
Member name column es el título de la columna que se muestra en el cubo.
Order by campo por el que se establece la ordenación.
Por defecto, las dos primeras propiedades toman el mismo valor pero al independizarlas permite establecer la ordenación, como se puede observar en la dimensión Empleado (EmpleadoKey y EmpleadoApellidosNombre).
1.3. Definir medidas y miembros calculados en los cubos
Un cubo debe contener al menos una dimensión y una medida. La medida más simple corresponde a un campo numérico de la tabla de hechos. Pero es posible también crear medidas.
Por ejemplo, vamos a crear la medida COMISION como el 15% de total de la línea y el nº de pedidos como la cuenta de distintos pedidosID. Para ello se pulsa sobre la sección de Medidas y se indica Nueva medida. Se seleciona el atributo sobre el que se construirá la medida derivada (por ejemplo PedidoID) y luego en propiedades se establecerá la función de agregación y su nombre (Ver Figura 19).
Para el caso de la comisión, no nos deja establecer la función de cálculo en la versión Standard Edition, lo que podemos resolver, creando este campo en la vista del origen de datos, a través de crear un nuevo cálculo con nombre en la tabla de hechos (Ver Figura 20) y luego agregarla al grupo de medidas del cubo.
Figura 19. Crear Medida Nº pedidos.
Figura 20. Crear medida comisión.
Por defecto, la función de agregación de cualquier medida es la suma. Si quisieramos crear un indicador (ratio) que muestre el margen neto obtenido ( = beneficio / total) para que sea correcto, se debe realizar la agregación antes de la división. Por ello es necesario crear un miembro calculado. La diferencia entre medida y miembro calculado es cuándo el cálculo se realiza.
Una medida derivada se calcula antes que las agregaciones sean creadas y los valores son almacenados en el cubo. Un miembro calculado se calculan las agregaciones y los miembros no son almacenadas en el cubo.
Como ejemplo vamos a calcular el margen neto que se ha conseguido en las ventas. Poner la propiedad Format String a Porcentaje. Y también podeis poner un código de colores para que se marque cuando está por encima o por debajo de un determinado valor.
Figura 21. Crear métrica calculada margenNeto.
También se puede calcular la aportación de cada miembro de la dimensión producto al beneficio total, para saber qué productos son los que más beneficios nos aportan (Ver Figura 22).
Figura 22. Crear métrica aportación de cada producto al beneficio.
Ahora vamos a calcular un valor promedio, por ejemplo el importe medio por pedido. Para ello hace falta usar la función count. Esta función cuenta filas y puede ser utilizada sobre cualquier campo tanto numérico como no numérico, a diferencia del SUM, MAX y MIN.
Utilizaremos la dimensión degenerada PedidoID para definir la variable NumPedidos (ya hecho previamente). Y ahora creamos el miembro calculado:
Figura 23. Crear métrica aportación.
Ahora vamos a calcular ratios, uno como la aportación de cada producto en el beneficio total y la misma aportación pero desglosado por categoría.
CREATE MEMBER CURRENTCUBE.[MEASURES].[Aportacion (Ratio) del producto
al beneficio total]
AS [Measures].[Beneficio Total Linea]/
(
// The Root function returns the (All) value for the target
dimension.
Root
( [Producto dim]
),
[Measures].[Beneficio Total Linea]
),
FORMAT_STRING = "Percent",
VISIBLE = 1 ;
CREATE MEMBER CURRENTCUBE.[MEASURES].[Aportacion (ratio) del producto
respecto a su categoría en relación al beneficio]
AS Case
When [Producto Dim].[Categ-
producto].CurrentMember.Level.Ordinal
= 0
Then 1
Else [Measures].[Beneficio Total Linea]
/
( [Producto Dim].[ Categ-producto].CurrentMember.Parent,
[Measures].[Beneficio Total Linea] )
End,
FORMAT_STRING = "Percent",
VISIBLE = 1 ;
A continuación se observa el resultado. Daos cuenta que solo tiene sentido si se tiene a la dimension producto en una de las dimensiones. Aunque se pueden añadir más para filtrar. Se observa que no tiene sentido si aparecen 100%
Figura 24. Resultado de la métrica aportación creada
También podemos crear el miembro calculado incremento de clientes. Previamente hay que crear la medida “DistintosClientes” creando una nueva medida sobre el campo clientekey de la tabla de hechos. Dado que solo puede haber una medida con operador DISTINCTCOUNT, crearemos otro cubo con las dimensiones tiempo y cliente.
CREATE MEMBER CURRENTCUBE.[MEASURES].[Crecimiento en cartera de
clientes]
AS Case
When [Tiempo Dim].[Año - Trimestre - Mes -
día].CurrentMember.Level.Ordinal = 0
Then "NA"
When IsEmpty
(
(
[[Tiempo Dim].[Año - Trimestre - Mes -
día].CurrentMember.PrevMember,
[Measures].[DistintosClientes]
)
)
Then Null
Else (
( [Tiempo Dim].[Año - Trimestre - Mes -
día].CurrentMember, [Measures].[DistintosClientes] )
-
( [Tiempo Dim].[Año - Trimestre - Mes -
día].PrevMember, [Measures].[DistintosClientes] )
)
/
( [Tiempo Dim].[Año - Trimestre - Mes - día].
PrevMember,[Measures].[DistintosClientes] )
End,
FORMAT_STRING = "Percent",
NON_EMPTY_BEHAVIOR = { [DistintosClientes] },
VISIBLE = 1 ;
Figura 25. Resultado del cubo para crecimiento de clientes
1.3.1. Creación de conjuntos para consultas
Uso de definición de conjuntos para usar en dimensiones, ejemplo de Clientes europeos
uso
Otro ejemplo, es la selección de productos no obsoletos:
1.3.2. Propiedades del cubo
Los cubos tienen una serie de propiedades que se pueden configurar para que influyan en el comportamiento de todo el cubo, y algunas propiedades que no se pueden modificar. Estas propiedades se resumen en la tabla siguiente:
Propiedad Definición
AggregationPrefix Prefijo común que se utiliza para los nombres de agregaciones
Collation Identificador de configuración regional (LCID) e indicador de comparación, separados por un carácter de subrayado, como Latin1_General_C1_AS
DefaultMeasure Expresión multidimensional (MDX) que define la medida predeterminada para el cubo
Description Descripción del cubo, que se puede mostrar en aplicaciones cliente
ErrorConfiguration
Opciones de control de errores configurables para control de claves duplicadas, claves desconocidas, límites de error, acciones al detectarse un error, archivo de registro de errores y control de claves NULL
EstimatedRows Número de filas estimadas en el cubo
ID Identificador (Id.) único del cubo
Language Identificador de idioma del cubo
Name Nombre descriptivo del cubo
ProactiveCaching Configuración de almacenamiento en caché automático para el cubo
ProcessingMode Indica si la indización y la agregación se deben producir durante o después del procesamiento; las opciones son Regular o Lazy
ProcessingPriority Determina la prioridad de procesamiento del cubo durante operaciones en segundo plano, como indización y agregaciones diferidas. El valor predeterminado es 0.
ScriptCacheProcessingMode Indica si la caché de secuencias de comandos se debe generar durante o después del procesamiento; las opciones son Regular y Lazy
ScriptErrorHandlingMode Determina el control de errores; las opciones son IgnoreNone o IgnoreAll
Source Vista de origen de datos utilizada para el cubo
StorageLocation
Ubicación de almacenamiento del sistema de archivos para el cubo. Si no se especifica ninguna ubicación, se hereda de la base de datos que contiene el objeto de cubo
StorageMode Modo de almacenamiento para el cubo; los valores son MOLAP, ROLAP y HOLAP
Visible Determina la visibilidad del cubo
