manual - Universidad de Cantabria

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 primarioclave.
Por último está la dimensión temporal. Crearemos las jerarquías
especificadas en la Figura 18. Observar que aunque la jerarquía Añotrimestre-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].[Categproducto].CurrentMember.Level.Ordinal
= 0
Then 1
End,
Else [Measures].[Beneficio Total Linea]
/
( [Producto Dim].[ Categ-producto].CurrentMember.Parent,
[Measures].[Beneficio Total Linea] )

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
DefaultMeasure
Description
ErrorConfiguration
Identificador de configuración regional (LCID) e
indicador de comparación, separados por un carácter de
subrayado, como Latin1_General_C1_AS
Expresión multidimensional (MDX) que define la medida
predeterminada para el cubo
Descripción del cubo, que se puede mostrar en
aplicaciones cliente
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
ProcessingMode
ProcessingPriority
Configuración de almacenamiento en caché automático
para el cubo
Indica si la indización y la agregación se deben producir
durante o después del procesamiento; las opciones son
Regular o Lazy
Determina la prioridad de procesamiento del cubo
durante operaciones en segundo plano, como indización
y agregaciones diferidas. El valor predeterminado es 0.
Indica si la caché de secuencias de comandos se debe
ScriptCacheProcessingMode 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
StorageMode
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
Modo de almacenamiento para el cubo; los valores son
MOLAP, ROLAP y HOLAP
Visible Determina la visibilidad del cubo