INTRODUCCION A SSAS

Analysis Services es un motor de datos analíticos en línea que se usa en soluciones de ayuda a la toma de
decisiones y Business Intelligence (BI), y proporciona los datos analíticos para informes empresariales y
aplicaciones cliente como Excel, informes de Reporting Services y otras herramientas de BI de terceros. Un flujo
de trabajo típico para Analysis Services incluye la creación de un modelo de datos OLAP o tabular, la
implementación del modelo como base de datos en una instancia de Analysis Services, el procesamiento de la
base de datos para cargarla con datos y, a continuación, la asignación de permisos para permitir el acceso a
datos. Cuando esté listo, se puede obtener acceso a este modelo de datos con varios fines desde cualquier
aplicación cliente que admita Analysis Services como origen de datos.
Puede utilizar asistentes para crear todos los elementos básicos, como orígenes de datos, vistas de origen de
datos, dimensiones, cubos y roles.
Los modelos se rellenan con datos procedentes de sistemas de datos externos, normalmente almacenamientos
de datos hospedados en un motor de base de datos relacional de SQL Server o de Oracle (los modelos
tabulares admiten tipos de orígenes de datos adicionales). Los modelos especifican objetos de consulta, como
los cubos, pero también especifican las dimensiones que se pueden usar en varios cubos, cálculos y KPI que
encapsulan la lógica del negocio, así como interacciones, como los comportamientos en navegación y
obtención de detalles.
Para usar un modelo, se implementa en una instancia de Analysis Services que ejecuta bases de datos en un
modo de servidor determinado, haciendo que los datos estén disponibles para los usuarios autorizados que
se conectan a través de Excel u otras aplicaciones.
Puede instalar una instancia de Analysis Services en uno de estos tres modos de servidor:
 Como instancia tabular, ejecutando modelos tabulares.
 Como una instancia multidimensional y de minería de datos, ejecutando cubos OLAP y modelos de
minería de datos (es el valor predeterminado).
 Como PowerPivot para SharePoint, ejecutando modelos de datos PowerPivot y de Excel en SharePoint
(PowerPivot para SharePoint es un motor de datos de nivel intermedio que carga, consulta y actualiza
modelos de datos hospedados en SharePoint).
El mismo motor de datos; tres formas de usarlo. Tenga en cuenta que los modos de servidor se establecen
durante la instalación y no se pueden cambiar posteriormente. Debe instalar una nueva instancia si necesita
otro modo diferente.

Extraído de:
https://msdn.microsoft.com/es-es/library/bb522607(v=sql.120).aspx

Cubo OLAP
Un cubo OLAP, OnLine Analytical Processing o procesamiento Analítico en Línea, término acuñado por Edgar
Frank Codd de EF Codd & Associates, encargado por Arbor Software (en la actualidad Hyperion Solutions), es
una base de datos multidimensional, en la cual el almacenamiento físico de los datos se realiza en un vector
multidimensional. Los cubos OLAP se pueden considerar como una ampliación de las dos dimensiones de una
hoja de cálculo.

A menudo se pensaba que todo lo que los usuarios pueden querer de un sistema de información se podría
hacer de una base de datos relacional. No obstante Codd fue uno de los precursores de las bases de datos
relacionales, por lo que sus opiniones fueron y son respetadas.

La propuesta de Codd consistía en realizar una disposición de los datos en vectores para permitir un análisis
rápido. Estos vectores son llamados cubos. Disponer los datos en cubos evita una limitación de las bases de
datos relacionales, que no son muy adecuadas para el análisis instantáneo de grandes cantidades de datos.
Las bases de datos relacionales son más adecuadas para registrar datos provenientes de transacciones
(conocido como
OLTP o procesamiento de transacciones en línea). Aunque existen muchas herramientas de generación
de informes para bases de datos relacionales, éstas son lentas cuando debe explorarse toda la base de
datos.

Por ejemplo, una empresa podría analizar algunos datos financieros por producto, por período, por
ciudad, por tipo de ingresos y de gastos, y mediante la comparación de los datos reales con un
presupuesto. Estos parámetros en función de los cuales se analizan los datos se conocen
como dimensiones. Para acceder a los datos sólo es necesario indexarlos a partir de los valores de las
dimensiones o ejes.

El almacenar físicamente los datos de esta forma tiene sus pros y sus contras. Por ejemplo, en estas
bases de datos las consultas de selección son muy rápidas (de hecho, casi instantáneas). Pero uno de
los problemas más grandes de esta forma de almacenamiento es que una vez poblada la base de
datos ésta no puede recibir cambios en su estructura. Para ello sería necesario rediseñar el cubo.
En un sistema OLAP puede haber más de tres dimensiones, por lo que a los cubos OLAP también
reciben el nombre de hipercubos. Las herramientas comerciales OLAP tienen diferentes métodos de
creación y vinculación de estos cubos o hipercubos.

Un ejemplo
Un analista financiero podría querer ver los datos de diversas formas, por ejemplo, visualizándolos en
función de todas las ciudades (que podrían figurar en el eje de abscisas) y todos los productos (en el eje
de ordenadas), y esto podría ser para un período determinado, para la versión y el tipo de gastos.
Después de haber visto los datos de esta forma particular el analista podría entonces querer ver los
datos de otra manera y poder hacerlo de forma inmediata. El cubo podría adoptar una nueva orientación
para que los datos aparezcan ahora en función de los períodos y el tipo de coste. Debido a que esta
reorientación implica resumir una cantidad muy grande de datos, esta nueva vista de los datos se debe
generar de manera eficiente para no malgastar el tiempo del analista, es decir, en cuestión de segundos,
en lugar de las horas que serían necesarias en una base de datos relacional convencional.

Dimensiones y jerarquías
Cada una de las dimensiones de un cubo OLAP puede resumirse mediante una jerarquía. Por ejemplo
si se considera una escala (o dimensión) temporal "Mayo de 2005" se puede incluir en "Segundo
Trimestre de 2005", que a su vez se incluye en "Año 2005". De igual manera, otra dimensión de un
cubo que refleje una situación geográfica, las ciudades se pueden incluir en regiones, países o regiones
mundiales; los productos podrían clasificarse por categorías, y las partidas de gastos podrían agruparse
en tipos de gastos. En cambio, el analista podría comenzar en un nivel muy resumido, como por ejemplo
el total de la diferencia entre los resultados reales y lo presupuestado, para posteriormente descender
en el cubo (en sus jerarquías) para poder observar con un mayor nivel de detalle que le permita descubrir
en el cubo los lugares en los que se ha producido esta diferencia, según los productos y períodos.

Dispersión en cubos OLAP

Vincular o enlazar cubos es un mecanismo para superar la dispersión. Ésta se produce cuando no todas
las celdas del cubo se rellenan con datos (escasez de datos o valores nulos). El tiempo de procesamiento
es tan valioso que se debe adoptar la manera más efectiva de sumar ceros (los valores nulos o no
existentes). Por ejemplo los ingresos pueden estar disponibles para cada cliente y producto, pero los
datos de los costos pueden no estar disponibles con esta cantidad de análisis. En lugar de crear un cubo
disperso, a veces es mejor crear otro cubo distinto, pero vinculado, en el que un subconjunto de los
datos se pueden analizar con gran detalle. La vinculación asegura que los datos de los dos cubos
mantengan una coherencia.

Definición técnica
En teoría de bases de datos, un cubo OLAP es una representación abstracta de la proyección de una
relación de un sistema de gestión de bases de datos relacionales (RDBMS). Dada una relación de
orden N, se considera la posibilidad de una proyección que dispone de los campos X, Y, Z como clave
de la relación y de W como atributo residual. Categorizando esto como una función se tiene que:
W : (X,Y,Z) → W
Los atributos X, Y, Z se corresponden con los ejes del cubo, mientras que el valor de W devuelto
por cada tripleta (X, Y, Z) se corresponde con el dato o elemento que se rellena en cada celda del
cubo.
Debido a que los dispositivos de salida (monitores, impresoras, ...) sólo cuentan con dos
dimensiones, no pueden caracterizar fácilmente cuatro dimensiones, es más práctico proyectar
"rebanadas" o secciones de los datos del cubo (se dice proyectar en el sentido clásico vector-
analítico de reducción dimensional, no en el sentido de SQL, aunque los dos conceptos son
claramente análogos), tales como la expresión:
W : (X,Y) → W
Aunque no se conserve la clave del cubo (al faltar el parámetro Z), puede tener algún significado
semántico, sin embargo, también puede que una sección de la representación funcional con tres
parámetros para un determinado valor de Z también resulte de interés.
La motivación que hay tras OLAP vuelve a mostrar de nuevo el paradigma de los informes de
tablas cruzadas de los sistema de gestión de base de datos de los 80. Se puede desear una
visualización al estilo de una hoja de cálculo, donde los valores de X se encuentran en la fila $1,
los valores de Y aparecen en la columna $A, y los valores de W: (X,Y) → W se encuentran en
las celdas individuales a partir de la celda $B2 y desde ahí, hacia abajo y hacia la derecha. Si
bien se puede utilizar el Lenguaje de Manipulación de Datos(o DML) de SQL para mostrar las
tuplas (X,Y,W), este formato de salida no es tan deseable como la alternativa de tablas
cruzadas. El primer método requiere que se realice una búsqueda lineal para cada
par (X,Y) dado, para determinar el correspondiente valor de W, mientras que el segundo permite
realizar una búsqueda más convenientemente permitiendo localizar el valor W en la intersección
de la columna X apropiada con la fila Y correspondiente.
Se ha desarrollado el lenguaje MDX (MultiDimensional eXpressions o expresiones
multidimensionales) para poder expresar problemas OLAP de forma fácil. Aunque es posible
traducir algunas de sus sentencias a SQL tradicional, con frecuencia se requieren expresiones
SQL poco claras incluso para las sentencias más simples del MDX. Este lenguaje ha sido
acogido por la gran mayoría de los proveedores de OLAP y se ha convertido en norma de hecho
para estos sistemas.
Extraido de:
https://es.wikipedia.org/wiki/Cubo_OLAP
 Práctica SSAS
1. Cuestiones previas

Para trabajar con SSAS, partimos desde la base de datos RETAIL; esta base de datos es transaccional (Registra
la información, registra las transacciones) a partir del cual extraeremos las dimensiones y las tablas de
hechos, resultado de ello obtenemos la base de datos orientada al análisis de datos, conformado por los
esquemas en estrella de acuerdo a diversas temáticas de análisis.

Esta base de datos será facilitada por el docente para su respectivo procesamiento ETL. Luego de realizar
todo el proceso de carga y transformación obtendremos nuestra base de datos dimensional de acuerdo a
los requerimientos del negocio.
 Aquí tenemos las dos versiones RETAIL Y RETAIL-DWH.

En la imagen podemos observar la base de datos transaccional (RETAIL)

y la base de datos dimensional (RETAIL-DWH).

Para obtener la base de datos dimensional se ha utilizado las

herramientas de SSIS vistos en las sesiones anteriores.

En este diagrama podemos observar uno de los esquemas en estrella,

cuya tabla de hecho es ventas(fact). Las métricas que utiliza este
esquema son: totalDolares, totalSoles, montoIgvDolares,
subTotalDolares, etc.
Luego en mismo diagrama podemos observar el otro esquema en estrella contabilidad(fact)
Aquí podemos observar otro esquema almacenTransaccion(fact), donde podemos observar algunas de las
métricas, por ejemplo: costosDolares, costosSoles, etc.

Podemos seguir analizando los demás diagramas.

Lo que nos queda ahora es convertir todos estos esquemas en estrella en una base de datos dimensional
con la ayuda de SSAS.

2. Iniciando SSAS
a) Nos conectamos al Analysis Service.
 b) Nos conectamos, y como podemos observar aún no tenemos ninguna base de datos en este
servidor.

Las características más importantes aquí serán las dimensiones y los cubos. Más adelante veremos
los resultados.

3. Creando un nuevo proyecto SSAS

Ahora vamos crear nuestro proyecto para crear la base de datos dimensional, en ellas las dimensiones
y los cubos.

a) Creamos un nuevo proyecto, seleccionamos Analysis Services Multidimensional and Data Mining.
Asignamos un nombre al proyecto y la carpeta donde se guardará.
 Este es el entorno de SSAS

4. Creando un origen de datos

a) Creamos el origen de datos. Este origen de datos se va a conectar directamente con la base de
datos REATIL-DWH, que es una base de datos que contiene información de la organización en el
modelo estrella, esto nos va a ayudar a analizar la información rápidamente.
 Click derecho en orígenes de datos / nuevo origen de datos.
 Clic en siguiente.

En el lado izquierdo tenemos los orígenes de datos con lo que ya se ha trabajado con los
procesos ETL. Creamos un nuevo origen de datos basado en una existente o nueva
conexión.
 Clic en nuevo.
Realizamos la configuración
para conectarnos a la base de
datos RETAIL-DWH. Para
proyectos SSAS es
recomendable utilizar
autenticación SQL Server.

 Clic en OK.

 En la ventana anterior le damos

a siguiente.

 Aparece la siguiente ventana

inferior.

 Aquí, es muy importante esta información. Vamos a seleccionar la opción heredar para que
herede los permisos del SQL Server y del usuario sa. Esto nos evitará tener inconvenientes al
momento de procesar. Clic en siguiente
 Asignamos un nombre al origen de datos y aceptamos. Luego clic en finalizar
 Podemos verificar que los parámetros de implementación se encuentren correctamente
establecidos, Si se presentara inconvenientes para procesar la data, hacemos clic derecho
sobre nuestro proyecto/propiedades/implementación y verificamos los parámetros, a
localhost, lo podríamos cambiar por el nombre del servidor.

 Ahora, nuevamente sobre proyecto hacemos clic derecho y seleccionamos procesar o clic en
el botón iniciar

 Ahora pasamos a nuestro servidor SSAS, comprobamos que está la base de datos con el
origen de datos configurado.
5. Crear vistas de orígenes de datos.
a) Como siguiente paso vamos a crear las vistas de orígenes de datos. Estas vistas nos van a ayudar a
acotar nuestra base de datos, entonces debemos segmentarlo ya que tiene distintos esquemas en
estrella y poder trabajar ordenadamente.
 Hacemos clic derecho sobre vistas de origen de datos.

 Clic en siguiente.

Nos aparece los orígenes de datos, que se hayan creado.

 Clic en siguiente.

En la siguiente ventana aparece las tablas y vistas que tiene nuestra base de datos.
 Para este caso, vamos a trabajar con la tabla ventas. Para poder seleccionar las tablas
relacionadas con las ventas, seleccionamos la tabla de hechos ventas, donde se encuentran
las métricas y los id para las relaciones con las dimensiones.

Para poder saber cuáles son las tablas relacionadas, podríamos ir a la base de datos RETAIL-
DWH y ver el esquema correspondiente. Pero ese trabajo no va a ser necesario ahora.
 Hacemos clic en el botón agregar tablas relacionadas. Clic en siguiente.

 En esta ventana siguiente podríamos cambiarle por un nombre más pertinente.

 Clic en finalizar.

Ya tenemos los resultados, podemos observar nuestro esquema estrella.

 Aquí también podríamos crear nuevas columnas.

6. Creando la dimensión Vendedores.

Una vez que tengamos el origen de datos y el esquema de datos (vista), podemos iniciar a crear las
dimensiones. Vamos a crear dimensiones sencillas sin jerarquías, posteriormente iremos
implementando estas dimensiones con jerarquías.
Podríamos crear directamente los cubos y a partir de ahí, las dimensiones; pero estas dimensiones no
serían personalizadas, que es lo que necesitamos hacer. Entonces se recomienda crear las dimensiones
para luego agregarlas a los cubos.

a) Ahora iniciamos creando una dimensión. Cerramos la ventana del esquema creado anteriormente.
 Hacemos clic derecho sobre la carpeta dimensiones / Nueva dimensión.

 Clic en siguiente.

 En esta ventana nos muestra diversas opciones, incluso para generar tablas no relacionada en
la base de datos referenciada por el origen de datos. Seleccionamos Usar una tabla existente.
Clic en siguiente
 En esta ventana aparece los esquemas con los que estamos trabajando, aquí solo tenemos el
esquema ESQUEMA-VENTAS-RETAIL-DWH. En la opción tablas, nos muestra las tablas del
esquema; como estamos creando dimensiones solo debemos seleccionar aquellas tablas
dimensionales. La tabla que aparece por defecto es la tabla de hechos, para nuestro caso,
vamos a iniciar con la tabla vendedores. En el cuadro columna de clave aparece las claves que
tiene esta tabla. Aquí solo tenemos una sola clave.
 Aquí vamos a personalizar el campo vendedoresid, ya que, en vez de mostrar el código del
vendedor(vendedoresid) se muestre por ejemplo su nombre(nombreVendedor),
internamente sigue trabajando con el vendedoresid, el nombre es solo para la vista del
usuario. Clic en siguiente.

 A continuación, aparecen las demás columnas que pertenecen a esta tabla. Como podemos
apreciar, esta seleccionado la columna vendedores id, pero vamos a personalizarla, ya que
esta columna está asociada con la columna nombreVendedor. Vamos a cambiar la
descripción de esta columna, ahora se llamará NombreVendedor, el campo vendedor lo
dejamos vacío ya que no es importante para esta dimensión. Clic en siguiente.
 NOTA:
Los campos de la tabla vendedores de la base de datos RETAIL-DWH, originalmente tiene los
siguientes campos:

 En esta ventana aparece nuestra dimensión vendedores con un solo atributo que es
NombreVendedor; pero que sabemos internamente sigue trabajando con la columna
vendedoresid. Podemos modificar el nombre de la dimensión, sin embargo, para este caso lo
dejamos, así como está. Clic en finalizar.

Y hemos terminado de crear parte nuestra primera dimensión sencilla.

 Explicamos el entorno de trabajo de esta dimensión.

Tablas que dan

origen a esta
dimensión
Campos de Jerarquias
la
dimension

 Ahora describimos las relaciones de atributo.

Aquí se implementan las

relaciones de columnas de las
diferentes jerarquías (aquí solo
tenemos 1)

 Luego tenemos traducciones.

 Aquí podemos cambiar las
características

 Finalmente, el explorador para saber qué datos tiene la dimensión.

Aquí podemos explorar los

datos de la dimensión

 Para comprobar que nuestro proyecto se está construyendo correctamente, lo procesamos.

Entonces, se recomienda que a medida que vayamos avanzando con nuestro proyecto,
también vayamos procesando lo avanzado, ya que, si se procesa al final, se corre el riesgo de
que aparezca errores difíciles de hacer seguimiento.
 Hacemos clic en el botón procesar proyecto.
 A la pregunta: ¿Desea generar el proyecto?, hacemos clic en sí.
 Se genera el proyecto completo. Hacemos clic en Ejecutar
 Aquí ya tenemos el resultado del proceso. Clic en Cerrar. Clic en Cerrar

 Ahora podemos ir al explorador para ver los resultados (datos de la dimensión). Si no aparece
nada, hacemos clic en el botón reconectar.
 Apreciamos los resultados. Observar que solo tenemos una sola jerarquía.

 Finalmente comprobamos que esta dimensión se encuentre registrada en nuestra base de

datos. Vamos a Analysis Service.

 Hacemos clic en nuestra dimensión y seleccionamos examinar.

Podemos observar los datos de la dimensión al igual que en Data Tools.
Finish.