Capítulo 9 - Medidas

1. Cubos

Un cubo contiene un subconjunto de la información de un Data Mart o Data Warehouse. Su información se almacena en una estructura multidimensional definida por dimensiones y medidas.

Todo cubo se construye a partir de un esquema de datos que consiste en tablas de hechos y tablas de dimensión. Una mejora importante de SSAS 2012 sobre la versión 2000 es que cada cubo puede contener múltiples sola tablas de hechos.

Cada dimensión puede contener varias jerarquías. Cada jerarquía contiene varios niveles. Los niveles permiten efectuar complejas operaciones de drill down (aumentar el nivel de detalle de las consultas) y drill up (disminuir el nivel  de detalle de las consultas).

Por ejemplo, una operación de drill down puede consistir en observar la información de ventas de manzanas en todo el Perú, y luego aumentar el nivel de detalle para consultar las ventas de Cuzco y Lima. Una operación de drill up típica consistiría en observar las ventas de Lima, y disminuir posteriormente el nivel de detalle para observar las ventas en todo el Perú.

La información se sumariza en un cubo de acuerdo a la estructura de niveles y jerarquías definida en cada dimensión. Por ejemplo, en la tabla de hechos de un cubo pueden almacenarse las ventas para cada distrito. Durante el procesamiento del cubo, se calculan y almacenan las sumas parciales de las ventas en cada provincia y departamento. Estas sumas parciales reciben el nombre de agregaciones. De esta manera, se pueden efectuar consultas rápidas sobre vastos conjuntos de datos.

1.1 Propiedades de los cubos

Los cubos tienen una serie de propiedades, configurables desde el diseñador de cubos de SQL Server Data Tools. A continuación se explican algunas de estas propiedades:

• AggregationPrefix: Especifica el prefijo normal que se utiliza para nombres de agregación
• Collation: Especifica el identificador de configuración regional (LCID) y la marca de comparación, separados por un carácter de subrayado. por ejemplo, Latin1_General_C1_AS.
• DefaultMeasure: Contiene una expresión MDX (Expresiones multidimensionales) que define la medida predeterminada para el cubo. 
• Descripción: Proporciona una descripción del cubo, que se puede mostrar en aplicaciones cliente.
• ErrorConfiguration: Contiene valores de control de errores configurables para controlar claves duplicadas, claves desconocidas, límites de error, acciones al detectar errores, archivos de registro de errores y control de claves nulas.
• EstimatedRows: Especifica el número de filas estimadas del cubo. 
• ID: Contiene el identificador único (Id.) del cubo.
• Language: Especifica el identificador de idioma predeterminado del cubo.
• Name: Especifica el nombre descriptivo del cubo.
• ProactiveCaching: Define la 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 script 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: Muestra la vista del origen de datos utilizada para el cubo.
• StorageLocation: Especifica la 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: Especifica el modo de almacenamiento del cubo. Los valores son MOLAP, ROLAP o HOLAP.
• Visible: Determina la visibilidad del cubo

2. Medidas y grupos de medidas

Una medida (measure) representa un valor obtenido a partir de una columna numérica de la tabla de hechos. La definición de las medidas constituye el paso central en el análisis de soluciones de inteligencia de negocios, pues constituyen la información que los usuarios finales desean visualizar.

Las medidas se agrupan en grupos de medidas (measure groups). Cada measure group corresponde con una tabla de hechos. Un cubo de SSAS 2012 puede contener varios measure groups.

2.1 Propiedades de los measure groups

Las propiedades de los grupos de medida determinan el comportamiento de todo el grupo de medida y establecen los comportamientos predeterminados de ciertas propiedades de medidas dentro de un grupo de medida.

A continuación, se explican las propiedades principales de los measure groups:

• AggregationPrefix: Se aplica al almacenamiento ROLAP. Asigna un prefijo común a las vistas indizadas en SQL Server, que se usa para almacenar agregaciones para las particiones asociadas con este grupo de medida.
• DataAggregation: Esta propiedad se reserva para uso futuro y actualmente no tiene ningún efecto. Por lo tanto, se recomienda que no modifique esta configuración.
• Descripción: Puede usar esta propiedad para documentar el grupo de medida.
• ErrorConfiguration: Valores de control de errores configurables para controlar las claves duplicadas, las claves desconocidas, las claves NULL, los límites de error, las acciones tras la detección de errores y el archivo de registro de errores.
• EstimatedRows: Especifica el número estimado de filas de la tabla de hechos.
• EstimatedSize: Especifica el tamaño estimado (en bytes) del grupo de medida.
• ID: Especifica el identificador del objeto.
• IgnoreUnrelatedDimensions: Determina si las dimensiones no relacionadas están forzadas a su nivel superior cuando los miembros de las dimensiones que no están relacionadas con el grupo de medida se incluyen en una consulta. El valor predeterminado es True.
• Name: Nombre de la medida. Esta propiedad es de solo lectura. Por defecto, el nombre del measure group se forma a partir de la tabla de hechos correspondiente.
• ProactiveCaching: Valores de control de errores configurables para controlar las claves duplicadas, las claves desconocidas, las claves NULL, los límites de error, las acciones tras la detección de errores y el archivo de registro de errores.
• ProcessingMode: Indica si la indización y la agregación se deben producir durante o después del procesamiento. Las opciones son Regular y LazyAggregations. LazyAggregations puede usarse para ejecutar la agregación como una tarea en segundo plano.
• ProcessingPriority: Determina la prioridad de procesamiento del cubo durante las operaciones de fondo, como indizaciones y agregaciones diferidas. El valor predeterminado es 0.
• Storage location: La ubicación del almacenamiento del sistema de archivos para el grupo de medida. Si no se especifica ningún valor, la ubicación se heredará del cubo que contiene el grupo de medida.
• StorageMode: El modo de almacenamiento del grupo de medida. Los valores disponibles son MOLAP, ROLAP u HOLAP.
• Type: Especifica el tipo del grupo de medida.

2.2 Propiedades de las medidas

Las medidas heredan determinadas propiedades del grupo de medida del que son miembro, aunque estas propiedades se reemplazan en el nivel de medida. Las propiedades de medidas determinan cómo se agrega una medida, su tipo de datos, el nombre que se muestra al usuario, la carpeta para mostrar en la que aparecerá la medida, su cadena de formato, cualquier expresión de medida, la columna de origen subyacente y la visibilidad para los usuarios.

Las medidas poseen una serie de propiedades. A continuación, se explican algunas de ellas:

• Name: Nombre de la medida 
• Description: Ofrece una descripción de la medida, que se puede mostrar en aplicaciones cliente.
• DisplayFolder: Especifica la carpeta en la que se mostrará la medida a los usuarios cuando se conecten al cubo. Cuando un cubo tiene muchas medidas, se pueden utilizar carpetas para mostrar para categorizar las medidas y mejorar la exploración para el usuario.
• Source: Especifica la columna de la vista del origen de datos a la que se enlaza la medida.
• Format String: Determina el formato de visualización de la medida. Analysis Services provee una serie de formatos (por ejemplo, porcentaje y moneda), y también permite ingresar una cadena de formato personalizada.
• Id: Muestra el identificador único (Id.) de la medida. Esta propiedad es de solo lectura.
• MeasureExpression: Especifica una expresión MDX restringida que define el valor de la medida. La expresión se evalúa en el nivel de hoja antes de agregarse, y permite la ponderación de un valor. Por ejemplo, en la conversión de moneda en que la tasa de cambio pondera un importe de ventas. 
• Visible: Determina si la medida es visible o no. Esta propiedad es útil cuando se definen medidas intermedias, a partir de las cuales se calcularán otras medidas a través de MDX.
• Data Type: Especifica el tipo de datos de la columna de la tabla de hechos subyacente a la que se enlaza la medida. Este valor se hereda de la columna de origen de forma predeterminada.
• Aggregate Function: Función que se utilizará para sumarizar la medida. Analyisis Services provee las siguientes funciones de agregación:
• SUM: Es la función de agregación por defecto. Significa que el valor de la medida para un miembro de una dimensión es igual a la suma de los valores para todos sus miembros hijos. Ejemplo: la venta del Perú es la suma de las ventas de todos sus departamentos.
• COUNT: Recupera la cuenta de registros en la tabla de hechos. Esta función puede responder a preguntas del tipo: “¿cuántas ventas se han producido en Enero del 2005?”
• MIN: Significa que el valor de la medida para un miembro es igual al valor mínimo encontrado entre sus miembros hijos. A través de esta función se puede saber, por ejemplo, cuál ha sido la venta más pequeña entre los distritos de Lima.
• MAX: Significa que el valor de la medida para un miembro es igual al valor máximo encontrado entre sus miembros hijos. A través de esta función se puede saber, por ejemplo, cuál ha sido la venta más grande entre los distritos de Lima.
• DISTINCT COUNT: Recupera la cuenta de registros en la tabla de hechos, eliminando las ocurrencias repetidas. Esta función puede responder a preguntas del tipo: “entre mis 150 clientes, ¿cuántos han efectuado compras en Enero del 2005?
• NONE: No se efectúa ningún tipo de agregación; es decir, la medida o es aditiva. Esta función de agregación debe usarse cuando los valores de la medida no deben ser acumulados; por ejemplo, si la medida representa un promedio o el resultado de un cociente.
• BY ACCOUNT: Agrega la medida de acuerdo con la función de agregación asignada a las dimensiones de tipo “Account”. Si el cubo no tiene dimensiones de tipo “Account”, este valor es ignorado y se trata como una función NONE.
• AVERAGE OF CHILDREN: Significa que el valor de la medida para un miembro de una dimensión es igual al promedio de los valores para todos sus miembros hijos no vacíos.
• FIRST CHILD: Significa que el valor de la medida para un miembro es igual al valor de la medida para su primer miembro hijo. 
• LAST CHILD: Significa que el valor de la medida para un miembro es igual al valor de la medida para su último miembro hijo.
• FIRST NON EMPTY: Significa que el valor de la medida para un miembro es igual al valor de la medida para su primer miembro hijo no vacío.
• LAST NON EMPTY: Significa que el valor de la medida para un miembro es igual al valor de la medida para su último miembro hijo no vacío.

3. Relación entre las dimensiones y los grupos de medidas

El uso de la dimensión define las relaciones entre una dimensión de cubo y los grupos de medida de un cubo. Una dimensión de cubo es una instancia de una dimensión de base de datos que se utiliza en un cubo específico.

Un cubo puede y suele tener dimensiones de cubo que no están directamente relacionadas con un grupo de medida, pero que podrían estar indirectamente relacionadas con el grupo de medida a través de otra dimensión o grupo de medida.

Cuando se agrega una dimensión de base de datos o un grupo de medidas a un cubo, Microsoft SQL Server Analysis Services intenta determinar el uso de la dimensión mediante el examen de las relaciones entre las tablas de dimensiones y las tablas de hechos de la vista del origen de datos del cubo y mediante el examen de las relaciones entre los atributos de las dimensiones. Analysis Services establece automáticamente la configuración del uso de la dimensión para las relaciones que puede detectar.

Una relación entre una dimensión y un grupo de medida consta de las tablas de dimensiones y hechos que participan en la relación y un atributo de granularidad que especifica la granularidad de la dimensión del grupo de medida concreto. Comúnmente, estas relaciones se efectúan a través de columnas comunes en las tablas de dimensión y las tablas de hechos.

SSAS 2014 soporta los siguientes tipos de relaciones entre las dimensiones y los measure groups:

• Relación regular.
• Relación referenciada.
• Relación “fact”.
• Relación many – to – many.

El tipo de relación entre las dimensiones y los measure groups se determina a través del tab Dimension Usage en el diseñador de cubos.

3.1 Relación regular

Las relaciones regulares constituyen el tipo más frecuente de relación. SSAS 2014 provee soporte natural a este tipo de relaciones regulares. 

El uso de la dimensión regular define las relaciones entre una dimensión de cubo y los grupos de medida de un cubo. Hay una relación de dimensión normal entre una dimensión de cubo y un grupo de medida cuando la columna de clave (PK) de la dimensión se combina directamente con la tabla de hechos (FK).

Esta relación directa se basa en una relación de clave principal a clave externa de la base de datos relacional subyacente, pero también podría basarse en una relación lógica definida en la vista del origen de datos. Una relación de dimensión normal representa la relación entre tablas de dimensiones y una tabla de hechos en un diseño de esquema en estrella tradicional.

La siguiente figura muestra una relación de este tipo entre “DimPromotion” y “FactInternetSales”: Se muestran las características de la relación entre la dimensión “Promotion” y el measure group “Internet Sales”: 

Un caso especial lo constituye la situación denominada “Role Playing”. En ocasiones, una dimensión participa múltiples veces en el mismo cubo, desempeñando distintos roles. Esto se presenta, por ejemplo, en las siguientes ocasiones:

• Una tabla de hechos puede contener tres columnas que lo enlacen con la dimensión de tiempo: una columna para almacenar la fecha de facturación, otra para almacenar la fecha de remisión, y otra paraalmacenar la fecha de entrega.
• Una tabla de hechos puede contener dos columnas enlazadas con la dimensión de empleados: una columna para representar al empleado que efectuó la venta, y otra para representar al empleado que efectuó el despacho.

En versiones anteriores a SQL Server 2012, este tipo de requerimiento solo podía satisfacerse duplicando las tablas de dimensión, o creando vistas a partir de la tabla de dimensión (en los ejemplos anteriores, la solución hubiera consistido en crear tres tablas de dimensión para el tiempo y dos tablas de dimensión para los empleados; o en crear tres vistas a partir de la tabla de dimensión de tiempo y dos vistas a partir de la tabla de empleados).

En cambio, SSAS 2014 provee soporte natural a las situaciones de “Role Playing”. En SSAS 2014, la misma dimensión puede participar múltiples veces en el mismo cubo.

3.2 Relación Referenciada (referenced relationship)

Una relación de dimensión de referencia representa la relación entre tablas de dimensiones y una tabla de hechos en un diseño de esquema de copo de nieve.

Cuando las tablas de dimensiones se conectan en un esquema de copo de nieve, es posible definir una única dimensión mediante columnas de varias tablas, o bien, definir dimensiones independientes basadas en las tablas de dimensiones independientes y, a continuación, definir un vínculo entre ellas mediante la configuración de la relación de dimensión de referencia.

Este tipo de situaciones corresponde con lo que típicamente se llama “Dimensión Snowflake”.

Una relación referenciada se produce cuando la tabla de dimensión no está directamente relacionada con la tabla de hechos. En esta situación, la relación se produce a través de una tabla de dimensión intermedia, como se muestra en la figura siguiente.

3.3 Relación “Fact”

Frecuentemente, las tablas de hechos contienen, además de columnas de medidas y foreign keys, columnas adicionales que almacenan información relevante para el negocio. Por ejemplo, una tabla de hechos con información de ventas puede contener columnas que almacenen el número de factura y la dirección de envío del despacho.

Las dimensiones de hechos, más conocidas como dimensiones degeneradas, son dimensiones estándar que se crean a partir de columnas de atributos de tablas de hechos en lugar de columnas de atributos de tablas de dimensiones. Los datos útiles de dimensiones algunas veces se almacenan en una tabla de hechos para reducir la duplicación.

Por ejemplo, en el siguiente diagrama se muestra la tabla de hechos FactResellerSales de la base de datos de ejemplo Adventure Works DW Multidimensional 2014, que contienen columnas que almacenan el número de la orden de venta.

La tabla contiene información sobre atributos no solo para cada línea de un pedido emitido por un distribuidor, sino sobre el propio pedido. Esta Información es relevante para el negocio; razón por la cual es considerado en la tabla de hechos para ser relacionado con las medidas.

En este esquema la relación de cada línea de pedido con la FactResellerSales se efectuará mediante la relación con la propia tabla de hechos FactResellerSales.

3.4 Relación muchos a muchos (many - to - Many relationship) En la mayoría de dimensiones, cada hecho se combina con un solo miembro de la dimensión y un único miembro de la dimensión puede asociarse a varios hechos. En terminología de bases de datos relacionales, esto se conoce como relación de uno a varios. No obstante, suele resultar útil combinar un único hecho con varios miembros de dimensión, esto se reconoce como relación de muchos a muchos.

Por ejemplo, un cliente de un banco podría tener varias cuentas (cuenta corriente, libreta de ahorro, tarjetas de crédito y cuentas de inversión) y una cuenta también puede tener varios propietarios. La dimensión de cliente creada a partir de estas relaciones tendrá varios miembros relacionados con una única transacción de cuenta. 

SSAS 2014 provee un tipo especial de relación que permite implementar relaciones de muchos a muchos entre las tablas de hechos y las tablas de dimensión. Véase la siguiente figura:

En general, la implementación de una relación muchos – muchos requiere de los siguientes componentes representados en la figura anterior:

• Fact Table: La tabla de hechos principal
• Many to many dimension: La tabla de dimensión con la cual se desea relacionar la tabla de hechos principal
• Regular Dimension: Una dimensión relacionada con la tabla de hechos principal a través de una relación regular
• Intermediate Fact Table: Una tabla de hechos relacionada con las dos dimensiones mencionadas más arriba

Las tablas Fact Table, Regular Dimension e Intermediate Fact Table deben estar relacionadas en el data source view. De lo contrario, no se podrá definir la relación muchos – muchos.

Este tipo de situaciones en las cuales las dimensiones tienen relaciones de tipo muchos – muchos con las tablas de dimensión. Por ejemplo, véase la siguiente imagen:

La tabla “DimSalesReason” almacena motivos de venta. Como puede deducirse de la figura, la relación entre “DimSalesReason” y “FactInternetSales” es de tipo muchos – muchos: cada venta (un registro en “FactInternetSales”) puede tener múltiples motivos de venta (registros en “DimSalesReason”). Y, análogamente, cada motivo de venta puede estar relacionado con múltiples ventas.

En este diseño, la relación muchos – muchos se implementa a través de la tabla “FactInternetSalesReason”, que relaciona los registros de “FactInternetSales” con los registros de “DimSalesReason”.

Anuncio sobre la estructura de la página

Buenas tardes, se les hace conocimiento que hasta el momento se cuenta con siete (07) capítulos  del curso de "Business Intelligence", donde nosotros estamos brindando toda la información de manera gratuita y ha sido creado especialmente para todos los interesados en la materia.

Esta web actualmente se manejará de la siguiente manera:

• En la página de "Inicio" se mostrará en detalle de tipo blog todos los capítulos en los que está subdividido este Curso.
• Cada uno de los capítulos posee lecturas adicionales y videos relacionados, pero para los que deseen ver directamente las lecturas o los videos, se ha separado en 2 menús completos.
• Asimismo, se estará creando una página adicional referente a los ejercicios que se hacen durante cada uno de los capítulos o cada dos (02) capítulos. Esta página se llamará Ejercicios.
• Se ha creado la sección de Nosotros, donde se explica de forma mas concreta a lo que apuntará esta página.
• También se ha creado la sección de Politicas de privacidad, donde se explica a detalle qué hay en la página y que seguridades le hemos colocado. Se informa que esta página es 100% segura y pueden navegar en ella todo lo que deseen.
• Finalmente, tenemos la página de contacto, donde se les informa que pueden enviar un correo a extracheaphosting@gmail.com, que es un correo administrativo que nos envía al instante el mensaje que desean hacernos.

Mas adelante la página tendrá mas información, conforme a eso se detalle lo siguiente:

• La página contará con catorce (14) capítulos.
• En la parte derecha se colocará en resumen todos capítulos con hipervínculos, para que se puedan dirigir a todas las secciones de forma mas rápida.
• Se mejorarán todas las secciones conforme se avancen.
• También en la parte derecha se colocará las páginas amigas o páginas relacionada, donde se mostrarán las demás páginas que se han desarrollado.

Capítulo 7 - Modelos Multidimensionales

1. El almacenamiento multidimensional y estructura interna

1.1 Modelo multidimensional

Una vez que la información ha sido consolidada y transferida al Data Mart (donde reside el esquema STAR o SNOWFLAKE), puede ser enviada a repositorios multidimensionales. SQL Server 2014 implementa el almacenamiento multidimensional a través de los Servicios de Análisis (SQL Server Analysis Services, o SSAS).

Los repositorios multidimensionales se denominan cubos. Estos permiten efectuar consultas muy complejas sobre grandes conjuntos de datos, con alto rendimiento y velocidad. Los datos se encuentran totalizados y precalculados, lo cual permite obtener un tiempo de respuesta reducido para consultas que implican cálculos sobre grandes volúmenes de información.

Desde SQL Server 2005 Analysis Services la única herramienta para modelos de datos BI es UDM (Unified Dimensional Model). Actualmente, esta herramienta ha sido modificada desde la versión SQL Server 2012. Con Business Inteligence Semantic Model (BISM).

El modelo semántico de Analysis services como único modelo utilizado para reportes, datos analíticos, “scorecards”, “dashboards”, experiencias de usuario (personal, equipo y organizacional).

La arquitectura BISM presenta un modelo para herramientas de cliente, con dos maneras de construirlo: Tabular y Multidimensional

Modelos de almacenamiento

• OLAP Multidimensional (MOLAP)
• Los datos se encuentran almacenados en una estructura multidimensional.
• Para optimizar los tiempos de respuesta, el resumen de la información es usualmente calculado por adelantado. Estos valores precalculados o agregaciones son la base de las ganancias de desempeño de este sistema.
• Está compuesta por un motor OLAP en un servidor dedicado.
• Permitir mejoras enormes en la performance con respecto a los tiempos de consulta logrando un análisis más fácil y rápido
• Está diseñada para almacenar poco volumen de datos lo cual generará una limitación respecto al tamaño de BD. Los usuarios que requieren de datos agregados y sumarizados necesitarán de una arquitectura MOLAP
• OLAP Relacional (ROLAP)
• Es un sistema en el cual los datos se encuentran almacenados en una base de datos relacional. Típicamente, los datos son detallados, evitando las agregaciones y las tablas se encuentran normalizadas.
• Está compuesta por un servidor de base de datos Relacional y un motor OLAP en un servidor dedicado.
• Está diseñada para almacenar gran volumen de datos, debido a que su almacenamiento es relacional. Los usuarios que requieren de un alto nivel de detalle necesitarán de una arquitectura ROLAP.
• OLAP Híbrido (HOLAP)
• Mantiene los registros detallados en la BD relacional, mientras que los datos resumidos o agregados se almacenan en una base de datos multidimensional separada.
• Este método de almacenamiento es una combinación de los dos anteriores e intenta rescatar lo mejor de cada uno.
• Está compuesta por un servidor de base de datos Relacional y un motor OLAP en un servidor dedicado.
• Permite que el espacio físico, la performance de las consultas y el procesamiento sea menor que MOLAP y mayor que ROLAP. Los analistas que requieran ambos tipos de análisis necesitarán una arquitectura HOLAP.

1.2 Estructura interna

Un cubo se define a partir de una tabla de hechos y una o varias tablas de dimensión. Las medidas (measures) de la tabla de hechos se convertirán en las medidas del cubo. Las dimensiones del cubo se definen a partir de las tablas de dimensión.

Por ejemplo, un cubo de ventas puede tener las medidas Precio_Producto y Costo_Producto, provenientes de la tabla de hechos Sales_Fact. Estas medidas se cruzan con las dimensiones Almacén, Línea_de_Producto y Año_Fiscal. Las consultas efectuadas sobre este cubo permitirían obtener la evolución del precio de un producto a lo largo del tiempo, por almacén y línea de producto.

Cada dimensión en un cubo tiene uno o varios niveles (levels). Los niveles representan agrupaciones jerárquicas al interior de una dimensión.

Por ejemplo, la dimensión Ubicación_Geográfica puede tener los niveles Continente, Región, País y Ciudad. Los continentes contienen regiones, las regiones contienen países, y los países ciudades. La existencia de niveles permite obtener rápidamente resultados totalizados de información; de esta manera, los cuatro niveles mencionados en el ejemplo anterior permiten obtener las ventas totalizadas por Continente, Región, País y Ciudad.

2. Estructura y Componentes Básicos de un Cubo

La figura superior muestra una representación de la estructura de un cubo.

Los componentes básicos de un cubo son las dimensiones (dimensions), los miembros (members), (estos dos componentes provienen de las tablas dimensionales) y las celdas (cells) (que provienen de la tabla de hechos).

2.1 Dimensiones (dimensions)

Cada dimensión en un cubo representa una perspectiva desde la cual los usuarios consultan y analizan los datos. Desde un punto de vista gráfico, se puede afirmar que las dimensiones corresponden con los ejes del cubo. Por ejemplo, se desea un reporte que nos muestre las ventas por Producto, Tiempo y Ubicación, ellas representan las dimensiones de un cubo. En la figura superior, podemos ver la representación gráfica de las dimensiones Productos (en el eje vertical), Tiempo (en el eje horizontal) y Ubicación (en el eje que atraviesa perpendicularmente esta página).

2.2 Niveles (levels)

Los niveles representan los grados de sumarización de una dimensión. Por ejemplo, la dimensión Tiempo puede contener los niveles Año, Mes y Día.

2.3 Miembros (members)

Cada ocurrencia particular en una dimensión está representada por un miembro. Por ejemplo, en la figura los miembros de la dimensión Productos son Uvas, Fresas, Melones, Manzanas y Peras. Los miembros de la dimensión Ubicación son Loreto, Lima y Cuzco.

2.4 Celdas (cells)

Una celda está definida por una intersección de las dimensiones del cubo. En la figura, la celda de color blanco representa la intersección de los miembros T4 (Tiempo), Fresas (Productos) y Cuzco (Ubicación).

3. Creación de Cubos a través del SQL Server Data Tools

En el capítulo anterior, se utilizó el SQL Server Data Tools para crear proyectos de Integration Services. Con el mismo entorno de desarrollo, se pueden crear proyectos de Analisys Services, a través de los cuales se define la estructura de los cubos en una solución de Business Intelligence.

En versiones anteriores a SQL Server 2012; la creación de bases de datos de análisis requiere una conexión permanente hacia el origen de datos donde residen los esquemas de datos (STAR o SNOWFLAKE). En SQL Server 2012 en adelante, los Data Sources Views (vistas de origen de datos) almacenan localmente información sobre la estructura de las tablas del data mart. De esta manera, el desarrollador puede continuar trabajando sobre el cubo sin necesidad de una conexión con el origen de datos.

El desarrollo de una solución de Business Intelligence a través del entorno de desarrollo de Microsoft Visual Studio .Net permite un desarrollo más rápido y una mejor definición de los componentes del cubo.

Para definir cubos en el SQL Server Data Tools, se debe crear un proyecto de tipo Analysis Services Project.

A continuación se describen algunos de los componentes del entorno de diseño:

1. Panel de diseño: Muestra gráficamente los componentes que constituyen el cubo y las dimensiones.
2. Solution Explorer Window (explorador de soluciones): Muestra, en una vista de árbol, a los elementos que componen el proyecto: orígenes de datos (Data Sources), vistas de origen de datos (Data Source Views), cubos, dimensiones, modelos de minería de datos, etc.
3. Properties Window (ventana de propiedades): Muestra las propiedades configurables del cubo, las dimensiones y sus componentes.

3.1 Data Sources

Un origen de datos de Microsoft SQL Server Analysis Services representa una conexión a un origen de datos y contiene la cadena de conexión que define el modo en que Analysis Services se conecta a un almacén de datos físico mediante un proveedor Microsoft .NET Framework administrado o un proveedor OLE DB nativo.

La cadena de conexión contiene información sobre el nombre del servidor, la base de datos, la seguridad, el tiempo de espera y otra relacionada con la conexión.

Analysis Services admite directamente muchos orígenes de datos. Entre los orígenes de datos admitidos se incluyen las bases de datos de Microsoft SQL Server y las creadas mediante otros productos, como Oracle, DB2 y Teradata.

3.2 Data Sources View

Una vista de origen de datos contiene el modelo lógico del esquema (STAR o SNOWFLAKE) que utilizan los objetos de las bases de datos de Analysis Services: cubos, dimensiones y estructuras de minería de datos. Una vista de origen de datos es la definición de metadatos, almacenada en formato XML.

Una vista de origen de datos:

• Se genera a partir de los orígenes de datos ya definidos en la base de datos conformados por el modelo Start o Snowflake.
• Contiene los metadatos que representan objetos seleccionados a partir de uno o más orígenes de datos.
• Se puede generar con uno o más orígenes de datos, lo que permite definir objetos OLAP y de minería de datos que integren datos de varios orígenes.
• Puede contener relaciones, claves principales, nombres de objeto, columnas calculadas y consultas que no están presentes en un origen de datos y que son independientes de los orígenes de datos físicos.
• Obtiene las relaciones de las tablas automáticamente a partir de las claves foráneas existentes en el origen de datos. Sin embargo el desarrollador puede definir nuevas relaciones directamente en el data source view.
• Dispone de la facilidad de colocar nombres amigables para las tablas y sus columnas.
• Puede incluir nuevas definiciones de columnas, escritas por el desarrollador a partir de expresiones de cálculo.
• Se almacenan de forma permanente en el proyecto de análisis; por tanto, permiten trabajar sin necesidad de una conexión en línea con las bases de datos de origen.

3.3 El Cube Wizard

El entorno de desarrollo de proyectos de análisis incluye un asistente para la definición de cubos.

Dicho asistente incluye dos opciones para la generación de cubos:

Build the cube using a data source:

Esta opción obtiene las definiciones del cubo a partir de la estructura existente en una base de datos, donde reside un esquema STAR o SNOWFLAKE. Si se selecciona la opción Auto build, el asistente analizará la estructura de las tablas, y detectará automáticamente las tablas de hechos y tablas de dimensión. Además, el asistente podrá determinar cuáles serán los niveles que se agregarán a las dimensiones. Si la opción Auto build no se selecciona, el desarrollador definirá manualmente la estructura del cubo.

Build the cube without using a data source:

Esta opción permite que el desarrollador defina la estructura del cubo sin necesidad de elegir un data source view. Posteriormente, a partir de la estructura propuesta por el desarrollador, SSAS generará las definiciones del STAR o SNOWFLAKE. SSAS provee dos plantillas de diseño: una de ellas es compatible con las características de la versión Enterprise Edition, y la otra con las opciones disponibles en la versión Standard Edition.

Cualquiera de las características y definiciones establecidas por el asistente pueden ser modificadas por el desarrollador en un momento posterior.

3.4 El Diseñador de Cubos

El diseñador de cubos permite establecer las propiedades del cubo y sus dimensiones. Provee una interfaz gráfica de fácil utilización, a través de la cual se puede personalizar el diseño de cada cubo en la solución de análisis. Este diseñador posee las siguientes pestañas, visibles en la parte superior de:

• Cube Structure: Permite efectuar cambios en la estructura del cubo: medidas, dimensiones, propiedades de agregación, etc.
• Dimension Usage: Permite definir las relaciones existentes entre el cubo y sus dimensiones.
• Calculations: Permite definir cálculos personalizados en el cubo a través de sentencias MDX (Multidimensional Expressions).
• KPIs: Permite definir Key Performance Indicators (KPIs) para establecer valores comparativos contra los cuales deben evaluarse las medidas.
• Actions: Permite definir las acciones que los usuarios pueden efectuar al navegar a través de la información del cubo.
• Partitions: Permite definir las particiones en que se almacena el cubo y los modos de almacenamiento de cada una de ellas.
• Perspectives: Permite definir perspectivas. Cada perspectiva constituye una vista parcial de la información, disponible para un grupo de usuarios.
• Translations: Permite traducir los nombres de los objetos en el cubo a múltiples idiomas.
• Browser: Permite observar la información almacenada en el cubo.

3.5 Deployment

Para ver los datos de las métricas y las dimensiones, debe implementar el proyecto en una instancia determinada de Analysis Services y luego procesar el cubo y sus dimensiones.

Al implementar un proyecto de Analysis Services se crean y definen objetos en una instancia de Analysis Services. Cuando se procesan los objetos en una instancia de Analysis Services (servidor de análisis), se copian los datos de los orígenes de datos en los objetos del cubo.

Durante la fase de procesamiento, el servidor de análisis se conecta con el data source origen donde residen las tablas de hechos y las tablas de dimensión, y extrae su información para poblar el cubo para luego almacenarlo en una base de datos de análisis.

VIDEOS COMPLEMENTARIOS

SQL 2014 Cubos OLAP
https://www.youtube.com/watch?v=ddOaljj66C8

LECTURAS COMPLEMENTARIOS

Modelado multidimensional (SSAS)
https://msdn.microsoft.com/es-es/library/hh230904(v=sql.120).aspx

Capítulo 6 - Poblando un Data Mart

1. Etapas de un proceso ETL

Una vez definida la base de datos STAR o SNOWFLAKE para el Data Mart, se debe efectuar la población con la información de los sistemas transaccionales. Este proceso puede alcanzar niveles de complejidad muy altos.

Los procesos que pueblan el Data Mart se denominan procesos ETL (Extraction, Transformation and Loading). Estos procesos extraen la data de los sistemas transaccionales, la transforman para asegurar la uniformidad y consistencia de los datos, y cargan dicha información en el Data Mart.

Con frecuencia, los procesos ETL deben modificar el formato y la presentación de los datos leídos desde los sistemas transaccionales. La siguiente figura muestra las operaciones de transformación que pueden realizarse:

2. Opciones para implementar proceso ETL

2.1. Transact - SQL

SELECT DISTINCT Date = (S.ShipDate),
DayOfWeek = DateName("dw", S.ShipDate),
Month = DatePart("mm",S.ShipDate),
Year = DatePArt("yy", S.ShipDate),
Quarter = DatePArt("qq",S.ShipDate),
DayOfYear=DatePart("dy", S.ShipDate),
Holiday = 'N',
Weekend = Case DatePart("dw", ShipDate)
When (1) then 'Y' When (7) then 'Y'
Else 'N'
End,
YearMonth = DateName("month",S.ShipDate) + '-' +
DateName("year", S.ShipDate),
WeekOfYear = DatePart("wk",S.ShipDate)
FROM Sales.SalesOrderHeader S WHERE S.ShipDate IS NOT NULL

2.2. Consultas Distribuidas

Las consultas distribuidas permiten consolidar la información a partir de múltiples servidores de datos. A través de SQL Server 2012, se pueden crear linked servers (servidores enlazados) sobre los cuales se pueden efectuar consultas Transact – SQL. La comunicación con los servidores enlazados se establece mediante proveedores OLEDB; por tanto, cualquier origen de datos accesible por OLEDB puede ser configurado como un servidor enlazado.

El siguiente ejemplo muestra una consulta distribuida Transact – SQL sobre un origen de datos Access (obsérvese la utilización de la función OPENROWSET):

Use Demo 
Insert Into HistoricoPedidos 
Select a.* From OPENROWSET(‘Microsoft.Jet.OLEDB.4.0’, 
‘C:\MSOffice\Access\Samples\Northwind.mdb’; ‘nuevocliente’;’password’, Pedidos)

La siguiente consulta muestra cómo utilizar la sentencia SELECT para acceder un servidor enlazado llamado ContaServer y extraer información de la tabla Proveedores, ubicada en la base de datos Ventas:

Use Demo 
Select NomCliente, Telefono 
INTO ListaFono FROM ContaServer.Ventas.dbo.Proveedores

2.3. El utilitario BCP y la sentencia Bulk Insert

El utilitario Bulk Copy Program (BCP) y la sentencia BULK INSERT permiten cargar datos provenientes de un archivo de texto hacia una base de datos SQL Server 2014.
También puede efectuarse el camino inverso; es decir, leer información de una tabla SQL Server y volcarla en un archivo de texto.

El utilitario BCP debe ejecutarse desde la línea de comandos del sistema operativo. La sentencia BULK INSERT se invoca desde una sesión de SQL Server 2014, que puede ser iniciada desde el SSMS.

2.4. SQL Server Integration Services (SSIS)

Esta herramienta permite crear “paquetes” de transformación de datos. Cada paquete consta de uno o más pasos, que extraen la data del origen, la transforman y la mueven hacia su destino.

Los servicios de transformación se conectan con las fuentes de datos a través de diversos conectores (proveedores .Net, proveedores .Net para OLE DB, y proveedores OLE DB nativos). Esta característica convierte a los paquetes SSIS en una herramienta muy útil para implementar procesos ETL que trabajan con información procedente de diversos orígenes.

3. Introducción a SQL Server Integration Services

SQL Server Integration Services (SSIS) no constituye la evolución de los Data Transformation Services (DTS) de SQL Server 2000. Es una plataforma completamente nueva para implementar procesos ETL de alcance empresarial.

Elementos de SSIS
SSIS está constituido por varios elementos que permiten construir aplicaciones de carga y transformación de datos altamente complejos y flexibles. A continuación, se presentan los elementos básicos de SSIS:

3.1. Connection Managers

Definen conexiones hacia los orígenes de datos. SSIS es capaz de conectarse con cualquier origen de datos accesible a través de proveedores .Net y OLE DB.

3.2. Tasks: Una tarea (task)

Define una unidad de transformación o procesamiento de datos. Las tareas pueden ejecutar diversas acciones: ejecutar sentencias SQL, ejecutar scripts .Net, enviar correos, etc. Un tipo especial de tarea es el Data Flow Task (tarea de flujo de datos) que efectúa transferencias de registros entre varios tipos de orígenes de datos.

3.3. Control flow

Permite definir secuencias lógicas de transferencia de información. Por ejemplo, a través de los flujos de control, se pueden definir bucles que repitan varias veces una transferencia de datos.

3.4. Containers

Las tareas de transformación se pueden agrupar en contenedores (containers). El uso de contenedores hace más sencillo definir la secuencia lógica de ejecución de las tareas.

3.5. Package

Todas las tareas y contenedores se hallan dentro de un package (paquete) de SSIS. Un proyecto SSIS puede contener varios paquetes.

4. Implementación de ETL a través de SQL Server Integration Services

4.1. El asistente de importación y exportación

SQL Server posee un asistente que nos permite importar y exportar datos de manera sencilla y rápida. Este asistente soporta la mayoría de conectores a diversas fuentes y bases de datos.

4.2. SQL Server Data Tools (SSDT) y el diseñador de paquetes

SQL Server Data Tools se considera como la siguiente evolución de Visual Studio basada en herramientas de base de datos que proporciona a los desarrolladores una herramienta única para apoyar las necesidades del desarrollo de bases de datos.

La herramienta para el desarrollo de proyectos de Business Intelligence en Visual Studio 2013 y versiones anteriores la conocíamos como Business Intelligence Development Studio (BIDS), ahora para Visual Studio 2010, 2012 y 2013 estará bajo el nombre de SQL Server Data Tools, sumándose a este nuevo conjunto de herramientas para el desarrollo de base de datos.

4.3. Paquetes: Conexiones y Transformación

MicrosoftSQL Server Integration Services (SSIS) es una plataforma que permite generar soluciones de integración de datos de alto rendimiento, entre las que se incluyen paquetes de extracción, transformación y carga de datos (ETL) para el almacenamiento de datos. SSIS incluye herramientas gráficas y asistentes para generar y depurar paquetes; tareas para realizar funciones de flujo de datos tales como operaciones de FTP; ejecución de instrucciones SQL y envío de mensajes de correo electrónico; orígenes y destinos de datos para extraer y cargar datos; transformaciones para limpiar, agregar, combinar y copiar datos; un servicio de administración, el servicio Integration Services para administrar la ejecución y almacenamiento de paquetes; e interfaces de programación de aplicaciones (API) para programar el modelo de objetos de Integration Services.

4.4. Precedencias

En el ejercicio anterior, se creó una tarea de flujo de datos para transferir datos hacia la tabla ResumenProductos. Es posible que, antes de efectuar la transferencia de los registros, se desee limpiar esta tabla a través de una sentencia DELETE o TRUNCATE. Para ello, SSIS tiene una tarea llamada Execute SQL Task, a través de la cual se puede ejecutar un batch SQL. Bastará con agregar esta tarea al paquete, y escribir en ella la sentencia SQL que elimine la información de la tabla ResumenProductos.

Sin embargo, al ejecutar el paquete, es posible que la tarea de eliminación de los registros se efectúe después de la transferencia de registros. Como resultado, al finalizar el paquete, la tabla ResumenProductos estará vacía. Por tanto, es necesario implementar algún mecanismo de precedencia que garantice que la tarea SQL se efectuará antes de la transferencia de datos.

SSIS permite conectar dos tareas a través de una precedencia. De esta forma, se garantiza que la segunda tarea se efectuará después de la primera. A través de las precedencias, se puede determinar el orden en que se efectuarán las transformaciones y tareas. Los principales tipos de precedencia son los siguientes:

• On Success: La tarea o transformación destino se efectúa sólo si la transformación origen termina exitosamente.
• On Failure: La tarea o transformación destino se efectúa sólo si la transformación origen falla.
• On Completion: La tarea o transformación destino se efectúa al terminar la transformación origen, sin importar si acabó exitosamente o si produjo un error.

Es posible, también, configurar una precedencia para evaluar una expresión, a través de la cual se verifique el valor de una variable. De esta manera, si la expresión devuelve True, la tarea destino se efectuará.

4.5. Script Component (Componente Script)

SSIS incluye un tipo de transformación que permite al desarrollador implementar componentes avanzados, escritos a través de .Net: el Script Component. El código de un Script Component puede aprovechar toda la funcionalidad disponible en el .Net Framework, lo cual permite crear paquetes muy complejos y personalizados. Los lenguajes soportados son Visual Basic .Net y C#.

Se puede usar el componente de script en paquetes para los siguientes fines:

•  Aplicar varias transformaciones a los datos en lugar de usar varias transformaciones en el flujo de datos. Por ejemplo, un script puede sumar los valores de dos columnas y luego calcular el promedio de la suma.
• Tener acceso a las reglas de negocios en un ensamblado .NET existente. Por ejemplo, un script puede aplicar una norma empresarial que especifica el intervalo de valores que son válidos en la columna Income.
• Usar fórmulas personalizadas y funciones, además de las funciones y operadores que proporciona la gramática de la expresión Integration Services. Por ejemplo, validar números de tarjeta de crédito mediante la fórmula.
• Validar datos de columna y omitir registros que contienen datos no válidos. Por ejemplo, un script puede evaluar si un valor de franqueo es razonable y omitir registros con valores extremadamente altos o bajos.

Existen tres tipos de componentes de script:

• Source Components: No poseen columnas de input. A través de estos componentes, se pueden escribir orígenes personalizados de datos. De esta manera, es posible desarrollar orígenes sobre formatos de datos no soportados de forma nativa por SSIS.

https://msdn.microsoft.com/en-us/library/ms136060(v=sql.110).aspx

• Destination Components: No poseen columnas de output. A través de estos componentes, se pueden escribir destinos personalizados de datos para escribir la información hacia formatos no soportados de forma nativa por SSIS.

https://msdn.microsoft.com/en-us/library/ms135939(v=sql.110).aspx

• Transformation Components: Poseen columnas de input y columnas de output. A través de estos componentes, se puede escribir lógica compleja para efectuar transformaciones personalizadas de datos.

https://msdn.microsoft.com/en-us/library/ms136114(v=sql.110).aspx?cs-save-lang=1&cs-lang=vb#code-snippet-6

Según la forma en que se usa el componente, admite una entrada o salidas, o ambas cosas. El script es invocado por cada fila en la entrada o la salida.

4.6. Containers (Contenedores)

Los contenedores permiten agrupar tareas relacionadas. El uso de contenedores hace más sencillo definir el flujo de las tareas al interior de un paquete. La siguiente figura muestra un ejemplo de la definición de tareas agrupadas en contenedores:
Como puede observarse en la figura, resulta más sencillo representar el flujo de ejecución de las tareas utilizando contenedores. Existen tres tipos de contenedores y son los siguientes:

Sequence Container:
Agrupa tareas relacionadas entre sí. Las tareas en el interior de este tipo de contenedor se ejecutarán en paralelo, a menos que se hayan definido precedencias entre ellas.
Se ejecutan las tareas en paralelo cuando no se contempla precedencia entre ellas.
No es más que un contenedor de otros componentes. Sirve para:

• Paralelizar procesos (que varias cajitas se ejecuten a la vez)
• Que un conjunto de procesos solo se ejecuten si se ha producido un evento anterior o bajo determinadas circunstancias.
• Permitir administrar propiedades en varias tareas de una ubicación estableciendo propiedades en un contenedor de secuencias en lugar de hacerlo en las tareas individuales.
• Proporciona un ámbito para variables usadas por un grupo de tareas y contenedores relacionados.

For Each Loop:
Este contenedor efectúa una iteración a través de los elementos de una colección. Esta colección puede provenir de diversas fuentes: la lista de archivos dentro de una carpeta del sistema operativo, una colección de ADO .Net, etc. Las tareas dentro del contenedor For Each Loop repetirán su ejecución, por cada elemento encontrado en la colección.

Ejecuta un flujo de control repetidamente mediante un enumerador. Este bucle recorre elementos de una colección, la colección pueden ser desde ficheros en un directorio hasta registros en un dataset.

Ejemplo: Si la carpeta especificada por el enumerador contiene cuatro archivos, el bucle se repetirá cuatro veces y copiará cuatro archivos.

For Loop:
Evalúa una expresión, y repite la ejecución de las tareas hasta que dicha expresión sea verdadera.
Ejecuta un flujo de control repetidamente probando una condición.
Es un bucle al estilo de la programación normal en el que se especifica:

• Cláusula de inicialización
• Cláusula de evaluación (detiene el bucle cuando devuelve False, es por tanto una expresión booleana)
• Cláusula de asignación (sirve para cambiar los valores y que la expresión booleana que se evalúa pueda ir cambiando).

4.7. Variables

A menudo, es necesario que los paquetes SSIS utilicen valores que deben calcularse en tiempo de ejecución. Por ejemplo, una variable en un paquete SSIS puede ser utilizada para almacenar el nombre de un servidor de base de datos. De esta manera, si una base de datos cambia de servidor, no sería necesario actualizar los connection managers o data sources en el proyecto SSIS.

Las propiedades de los objetos de SSIS (data sources, connection managers, tasks, containers, etc.) Pueden ser obtenidas desde variables. El uso de variables resulta particularmente útil cuando se utilizan Script Components o Script Tasks.

Una variable en SSIS tiene siempre el ámbito o alcance del container donde fue declarada. Por ejemplo, si se declara una variable en el paquete SSIS, dicha variable será visible desde cualquier lugar del paquete. Si la variable es declarada en un contenedor For Each Loop, será visible solo en las tareas que se encuentren en dicho contenedor.

4.8. Lookup (Busqueda)

Los Lookups implementan un mecanismo útil para efectuar transformaciones utilizando tablas de equivalencia. La transformación Búsqueda realiza búsquedas mediante la combinación de datos de columnas de entrada con columnas de un conjunto de datos de referencia. La búsqueda se utiliza para tener acceso a información adicional en una tabla relacionada que está basada en valores de columnas comunes.

Ejemplo: La figura superior muestra la utilización de una tabla de búsqueda para convertir los códigos de distritos de Lima en sus respectivos nombres. La transformación Búsqueda intenta realizar una combinación de igualdad entre valores de la entrada de la transformación y valores del conjunto de datos de referencia. Una combinación de igualdad quiere decir que cada fila de la entrada de transformación debe coincidir con, al menos, una fila del conjunto de datos de referencia. Si una combinación de no es posible, la transformación Búsqueda realiza una de las siguientes acciones:

• Si no hay ninguna entrada correspondiente en el conjunto de datos de referencia, no se produce ninguna combinación. De forma predeterminada, la transformación Búsqueda trata como errores las filas sin entradas coincidentes. Sin embargo, la transformación Búsqueda se puede configurar para redirigir dichas filas a un resultado no coincidente.
• Si hay varias coincidencias en la tabla de referencia, la transformación Búsqueda devuelve solo la primera coincidencia devuelta por la consulta de búsqueda. Si se encuentran varias coincidencias, la transformación Búsqueda genera un error o advertencia solo cuando la transformación se ha configurado para cargar todo el conjunto de datos de referencia en la memoria caché. En este caso, la transformación Búsqueda genera una advertencia cuando detecta varias coincidencias mientras la transformación llena la memoria caché.

4.9. Data Conversions (Conversión de datos)

Los procesos ETL deben leer información de múltiples tipos de fuentes, y transferirla a diversos destinos. Es muy posible, por tanto, que sea necesario efectuar conversiones de datos.

La transformación Conversión de datos convierte los datos de una columna de entrada a otro tipo de datos diferente y después los copia a una nueva columna de salida. Por ejemplo, un paquete puede extraer los datos de diferentes orígenes y después usar esta transformación para convertir las columnas al tipo de datos necesario para el almacén de datos de destino. Puede aplicar múltiples conversiones a una sola columna de entrada.

Un paquete puede utilizar esta transformación para realizar las siguientes conversiones de tipos de datos:

• Cambiar el tipo de datos.
• Establecer la longitud de la columna de los datos de cadena así como la precisión y la escala de los datos numéricos.
• Especificar una página de códigos.

4.10. Package Configurations

A menudo, para aumentar la flexibilidad de un paquete SSIS, es necesario pasarle ciertos valores de entrada. Por ejemplo, si una base de datos se mueve hacia otro servidor, es deseable que el nombre del servidor pueda ser establecido en tiempo de ejecución sin necesidad de modificar el paquete SSIS.

Los Package Configurations implementan mecanismos para pasarle valores de entrada a un paquete SSIS. Los package configurations permiten definir información de entrada a través de:

• Un archivo XML: Los valores quedan almacenados en un archivo XML. El paquete SSIS cargará estos valores al iniciarse su ejecución.
• Variables de entorno: Los valores de entrada del paquete se obtienen de las variables de entorno de Windows.
• Entrada de registro: Los valores de entrada del paquete se obtienen desde el registro de Windows.
• Parent package variable: Los valores de entrada del paquete se encuentran definidos como variables en un paquete de nivel superior que contiene al paquete actual.
• SQL Server: Los valores de entrada del paquete se encuentran almacenados en una tabla de SQL Server.

4.11. Derived Column (Columna derivada)

La transformación Derived Column se utiliza para generar nuevas columnas, con base en las columnas de input ya existentes. Esto se hace a través de expresiones, es decir, fórmulas que se aplican a las columnas de input para generar un nuevo valor de output. El lenguaje de expresiones de SSIS posee un vasto conjunto de funciones y operadores que permiten efectuar transformaciones avanzadas en la información de una fila.

Puede utilizar esta transformación para realizar las siguientes tareas:

• Concatenar datos de distintas columnas en una columna derivada. Por ejemplo, puede combinar valores de las columnas FirstName y LastName en una sola columna derivada, denominada FullName, mediante la expresión FirstName + " " + LastName.
• Extraer caracteres de datos de cadena mediante funciones como SUBSTRING y después almacenar el resultado en una columna derivada. Por ejemplo, puede extraer de la columna FirstName la inicial del nombre de una persona mediante la expresión SUBSTRING(FirstName,1,1).
• Aplicar funciones matemáticas a datos numéricos y almacenar el resultado en una columna derivada. Por ejemplo, puede cambiar la longitud y la precisión de una columna numérica, SalesTax, a un número con dos cifras decimales mediante la expresión ROUND(SalesTax, 2).
• Crear expresiones que comparen columnas de entrada y variables. Por ejemplo, puede comparar la variable Versión con los datos de la columna ProductVersion y, en función del resultado de la comparación, usar el valor de Version o ProductVersion mediante la expresión ProductVersion == @Version? ProductVersion : @Version.
• Extraer partes de un valor datetime. Por ejemplo, puede utilizar las funciones GETDATE y DATEPART para extraer el año actual mediante la expresión DATEPART("year",GETDATE()).
• Convierta las cadenas de fecha a un formato específico mediante una expresión.

4.12. Fuzzy Lookup (Búsqueda aproximada)

Al igual que el Lookup, la transformación Fuzzy Lookup compara los datos de entrada con una tabla de equivalencias. Sin embargo, en Fuzzy Lookup no es necesario que las equivalencias sean exactas; basta con que exista cierta similitud para que Integration Services decida que existe una correspondencia.

La transformación Fuzzy Lookup crea columnas adicionales que almacenan indicadores numéricos de semejanza. Esta característica permite que el desarrollador del paquete establezca políticas de tipo “si la semejanza es mayor que 90%, la decisión tomada por Integration Services es correcta. Para las filas restantes, el administrador tomará la decisión final”

Las columnas de salida de transformación incluyen las columnas de entrada marcadas como columnas de paso, las columnas seleccionadas en la tabla de búsqueda y las siguientes columnas adicionales:

• _Similarity, una columna que describe la similitud entre los valores de las columnas de entrada y de referencia.
• La puntuación 0.0 significa que no se encontraron coincidencias
• Mientras que 1.0 significa que se encontró una coincidencia exacta.
• Una puntuación entre 0.0 y 1.0 indica un grado de similitud, en el que un valor cercano a 1.0 indica mayor similitud.
• _Confidence, una columna que describe la calidad de la coincidencia. La transformación utiliza la conexión a la base de datos de SQL Server para crear las tablas temporales que utiliza el algoritmo de coincidencia aproximada.

4.13. Agregate y SORT (Agregado y Ordenar)

La transformación Agregado aplica funciones de agregado, como Average, a los valores de columnas y copia los resultados en la salida de transformación. Además de las funciones de agregado, la transformación proporciona la cláusula GROUP BY, que se puede usar para especificar los grupos en los que se debe realizar el agregado.

La transformación Agregado controla los valores NULL de la misma forma que el motor de base de datos relacional de SQL Server.Este comportamiento se define en el estándar SQL-92.Se aplican las reglas siguientes:

• En una cláusula GROUP BY, los NULLS se tratan como cualquier otro valor de columna.Si la columna de agrupamiento contiene varios valores NULL, éstos se colocan en un grupo individual.
• En las funciones COUNT (nombre de columna) y COUNT (nombre de columna DISTINCT), los NULLS se omiten y el resultado excluye las filas que contienen valores NULL en la columna con nombre.
• En la función COUNT (*), se cuentan todas las filas, incluso las filas con valores NULL.

La transformación Ordenar ordena los datos de entrada en sentido ascendente o descendente, y copia los datos ordenados a la salida detransformación. Puede aplicar varias ordenaciones a una entrada; cada ordenación se identifica mediante un numeral que determina el criterio de ordenación.

La columna con el número más bajo se ordenará primero, la columna con el segundo número más bajo se ordena a continuación, etc.

Existe circunstancia en las cuales se debe efectuar el ordenamiento durante el proceso de transferencia de datos y no en la consulta origen: Y son las siguientes:

• Cuando el origen de datos no soporta operaciones de agregación y ordenamiento. Por ejemplo: archivos de texto, Excel.
• Si se requiere agregar y ordenar datos que provienen de operaciones previas sobre múltiples orígenes de datos.
• El uso de operadores ORDER BY, GROUP BY, etc., hacen que la consulta sobre el origen de datos sea muy lenta.

4.14. Merge Join (Combinación de Mezcla)

La transformación Merge Join permite combinar dos filas provenientes de orígenes de datos distintos en una sola fila con base en una o más columnas que tengan valores comunes.

También proporciona una salida que se genera combinando dos conjuntos de datos ordenados mediante una combinación FULL, LEFT o INNER.

La implementación de una transformación Merge Join tiene las siguientes condiciones:

• Las columnas que cumplen el papel de Join Keys deben tener el mismo tipo de datos.
• Las filas que ingresan a la transformación Merge Join deben estar ordenadas con base en los valores de las columnas que cumplen el papel de Join Keys.

Por ejemplo: Pueden tenerse las siguientes filas en un archivo de texto (contiene ID Cliente y las ventas) y una tabla de BD que contiene el ID Cliente y el nombre del cliente. Se requiere unir la información en una sola tabla.

4.15. Conditional Split (División Condicional)

La transformación Conditional Split permite bifurcar un flujo de datos con base en condiciones lógicas. Por ejemplo, es posible que se requiera escribir las filas provenientes de un único flujo de datos en dos o más destinos distintos dependiendo de los valores de ciertas columnas en cada fila.

En una transformación Conditional Split, el desarrollador puede definir varios outputs cada uno de los cuales tiene asignada una cierta condición lógica. Por ejemplo, al leer un archivo de ventas por país, se puede hacer que las filas cuyo ID de país sea “Perú” se escriban en una tabla de SQL Server, y las filas correspondientes con otros países se escriban en una hoja de Excel.

La implementación de la transformación División condicional es similar a una estructura de decisión CASE de un lenguaje de programación. Evalúa expresiones y, en función de los resultados, dirige la fila de datos a la salida especificada. Esta transformación también proporciona una salida predeterminada, de modo que si una fila no coincide con ninguna expresión, se dirige a la salida predeterminada.

4.16. Distribución (deployment) del proyecto SSIS

Una vez finalizado el desarrollo de los paquetes SSIS, estos deben ser llevados a un servidor que esté corriendo los servicios de SQL Server Integration Services. A este proceso se le denomina distribución (deployment).

Durante el deployment, la definición del paquete SSIS se almacena en el servidor en alguna de las siguientes ubicaciones:

• File system: El paquete se graba en un archivo ubicado en una carpeta del sistema de archivos del servidor.
• SQL Server: La definición del paquete se almacena en la base de datos msdb que es una base de datos de sistema de SQL Server 2014.

Una vez que los paquetes han sido distribuidos, pueden ser ejecutados por el administrador en cualquier momento, desde la consola del SQL Server Management Studio. El administrador puede también programar la ejecución automática de los paquetes, a través de la creación de jobs (trabajos) en el agente de SQL Server 2014.

La distribución de los paquetes SSIS puede efectuarse en una de las siguientes formas:

• Distribución manual: Consiste en copiar en el servidor el archivo del paquete (extensión dtsx) y cualquier otro archivo relacionado, y cargarlo manualmente en los servicios de SQL Server Integration Services. A través de este mecanismo, solo puede distribuirse un paquete a la vez.
• Deployment utility: SSIS provee una herramienta para facilitar la distribución de los paquetes que se encuentran un proyecto SSIS. El deployment utility es un asistente que produce un archivo que puede ejecutarse en el servidor para efectuar la distribución con solo un clic.

4.17. Automatización de la ejecución de los paquetes

Una vez desplegados, los paquetes SSIS pueden ser ejecutados bajo demanda. Sin embargo, en la mayoría de los casos, los paquetes deben ejecutarse de acuerdo con una programación periódica sin intervención de ningún usuario.
La automatización de la ejecución de paquetes se efectúa a través del servicio SQL Server Agent. Este servicio es responsable por todas las tareas automatizadas que deben correr en el servidor de datos. Para programar la ejecución periódica de un paquete de Integration Services, se deben realizar los siguientes pasos:

• Crear un trabajo (job) en el Agente de SQL Server 2008.
• Agregar al trabajo un paso (step) de tipo Integration Services Package.
• Seleccionar el paquete que se desea ejecutar y los parámetros de ejecución del paquete (orígenes de datos, archivos de configuración, etc.).
• Agregar al trabajo una nueva programación (schedule). Debe tenerse en cuenta que, para que los trabajos se ejecuten periódicamente, es necesario que el servicio SQL Server Agent esté iniciado.

4.18. Data Profiling Task (Tarea de Perfiles de datos)

Los problemas de calidad de datos cuestan a las empresas estadounidenses más de $ 600 mil millones por año. ¿Por qué un costo tan elevado? Si los datos no tienen calidad, sus KPIs y predicciones de minería de datos serán incorrectas y podría llevar malas decisiones de negocios.

Por tanto, la tarea de generación de perfiles de datos calcula diversosbperfiles que le ayudan a familiarizarse con un origen de datos y a identificarben los datos problemas que deban corregirse.

Puede utilizar la tarea de generación de perfiles de datos dentro de un paquete de Integration Services para generar perfiles de datos que estánvalmacenados en SQL Server e identificar posibles problemas de calidad de los datos.

La tarea de generación de perfiles de datos puede calcular ocho perfiles de datos diferentes. Cinco de estos perfiles analizan columnas individuales y los otros tres analizan varias columnas o relaciones entre las columnas y las tablas.

Los cinco perfiles siguientes analizan columnas individuales:

Los tres perfiles siguientes analizan varias columnas o relaciones entre columnas y tablas:

Después de utilizar la tarea para calcular los perfiles de datos y guardarlos en un archivo, puede utilizar el Visor de perfil de datos independiente para revisar el perfil generado. El Visor de perfil de datos también admite la obtención de detalles para ayudarle a entender los problemas de calidad de los datos que se identifican en el perfil generado.

Videos Complementarios

Carga Datos nuevos ETL

http://www.guillesql.es/Articulos/SQLServerIntegrationServices_SSIS_FAQ.aspx

Getting Started
https://www.youtube.com/watch?v=3cPq9FXk-RA - SQL Server Integration Services (SSIS) Part 1 - Getting Started

Performing Basic Tasks
https://www.youtube.com/watch?v=tHbjhSEiyOs - SQL Server Integration Services (SSIS) Part 2 - Performing Basic Tasks

Basic Transformations
https://www.youtube.com/watch?v=VZrlXwM0_Pg - SQL Server Integration Services (SSIS) Part 3 - Basic Transformations

Variables
https://www.youtube.com/watch?v=S9c8kB7j7ao - SQL Server Integration Services (SSIS) Part 4 - Variables

Data Types and Data Conversion
https://www.youtube.com/watch?v=8I9IfZUK2dk - SQL Server Integration Services (SSIS) Part 5 - Data Types and Data Conversion

Expressions
https://www.youtube.com/watch?v=a0fCg7jvESM - SQL Server Integration Services (SSIS) Part 6 - Expressions

Conditional split and derived column transforms
https://www.youtube.com/watch?v=QSuI-qV7yWY - SQL Server Integration Services (SSIS) Part 7 - Conditional split and derived column transforms

Debugging
https://www.youtube.com/watch?v=OsqQT6eHs00 - SQL Server Integration Services (SSIS) Part 8 - Debugging

Lookup Transforms
https://www.youtube.com/watch?v=GazT32eqdsk - SQL Server Integration Services (SSIS) Part 9 - Lookup Transforms

Sequence Containers and FOR Loops
https://www.youtube.com/watch?v=lL63ZSRp_Ck - SQL Server Integration Services (SSIS) Part 10 - Sequence Containers and FOR Loops

Looping Over Files
https://www.youtube.com/watch?v=h6x0oI9gSh8 - SQL Server Integration Services (SSIS) Part 11 - Looping Over Files

Other Foreach Loops
https://www.youtube.com/watch?v=HIp06xn8puw - SQL Server Integration Services (SSIS) Part 12 - Other Foreach Loops

Script Tasks using C#
https://www.youtube.com/watch?v=iPmXgiUHUPQ - SQL Server Integration Services (SSIS) Part 13 - Script Tasks using C#

Script Tasks using Visual Basic
https://www.youtube.com/watch?v=VWLlIXjUtgY - SQL Server Integration Services (SSIS) Part 14 - Script Tasks using Visual Basic

Script Components
https://www.youtube.com/watch?v=nIPZvzivo_M - SQL Server Integration Services (SSIS) Part 15 - Script Components

Expression and Other Constraints
https://www.youtube.com/watch?v=oqiG4oNyvHk - SQL Server Integration Services (SSIS) Part 16 - Expression and Other Constraints

Event-handling and logging
https://www.youtube.com/watch?v=xFx4adO92gg - SQL Server Integration Services (SSIS) Part 17 - Event-handling and logging

Error handling
https://www.youtube.com/watch?v=LzFxNFPrPyQ - SQL Server Integration Services (SSIS) Part 18 - Error handling

Parameters and deployment
https://www.youtube.com/watch?v=idFCAFAgOO0 - SQL Server Integration Services (SSIS) Part 19 - Parameters and deployment

Lecturas Complementarias

1. SQL Server Integration Services
https://msdn.microsoft.com/en-us/library/ms141026(v=sql.120)

2. What's New (Integration Services)
https://technet.microsoft.com/en-us/library/bb522534(v=sql.120).aspx

3. Developer's Guide (Integration Services)

https://technet.microsoft.com/en-us/library/ms136025(v=sql.120).aspx

Capítulo 5 - Datawarehousing y Datawarehouse

1. Datawarehousing

Entre estos procesos generales podemos encontrar los siguientes:

• Fuentes de Datos

Son los orígenes de datos que pueden ser internos o externos, pueden ser de diferentes naturalezas: archivos, bases de datos, web, video, sonido, etc.

• ETL

Son los procesos de Extracción, Transformación y Carga de Datos, apoyados en herramientas ETL como Integration Services.

• Modelamiento

Es la fase en que se traduce en un modelo dimensional los requerimientos del negocio.

• Datamarts / Datawarehouse

Son los repositorios de datos que almacenan el modelo de datos orientados al negocio.

• Reportes Empresariales

Son herramientas que permiten mostrar datos de negocio a través de reportes estándares pero con distintas capacidades como reportes históricos, en caché, etc.

• OLAP y Datamining

Es la construcción de estructuras multidimensionales y predictivas para el negocio.

• Entrega de la Información

Es la manera de dar al usuario final los reportes de inteligencia de negocios a través de agentes automatizados y formatos y medios requeridos por el usuario de negocio.

2. Datawarehouse

Un Data Warehouse (DWH) es un repositorio central que contiene la información más valiosa de la empresa. Los datos que aquí se almacenan han pasado por un proceso de calidad que asegura su consistencia. Además, el repositorio está construido de tal manera que el acceso sea lo más rápido posible.

La construcción del DataWarehouse se va realizando por etapas que normalmente corresponden a las principales áreas operativas de la empresa. Por ejemplo: Área de Ventas, Área Financiero Contable, Área de Recursos Humanos, etc. Estas áreas reciben el nombre de DataMarts.

Los Data Warehouses (Base de Datos OLAP, On-Line Analytical Processing) son diseñados para cumplir con un conjunto de metas, las cuales son muy diferentes de los objetivos de un sistema transaccional (OLTP, On-Line Transaction Processing). Por ejemplo, una meta de los OLTP es maximizar la concurrencia mediante el uso de locks, dicho objetivo no es pertinente en el diseño de DW donde las operaciones son solo de consulta, es decir del tipo SELECT.

Además de las técnicas de diseño, un desarrollador de Data Warehousing debe focalizarse en entregar un análisis multidimensional y capacidades de reportes ad-hoc (generación de reportes por parte del usuario experto basados en el conocimiento del negocio). Para realizar esto, el diseñador necesita conocer los requerimientos del negocio tan bien como las técnicas de diseño multidimensional.

3. Diseño e implementación de Datawarehouse

"Un Data Warehouse no se puede comprar, se tiene que construir". La construcción, implantación y diseño de un Data Warehouse es un proceso evolutivo.

Este proceso se tiene que apoyar en una metodología específica para este tipo de procesos, si bien es más importante que la elección de la mejor de las metodologías, el realizar un control para asegurar el seguimiento de la misma. En las fases que se establezcan en el alcance del proyecto es fundamental el

incluir una fase de formación en la herramienta utilizada para un máximo aprovechamiento de la aplicación. El seguir los pasos de la metodología y el comenzar el Data Warehouse por un área específica de la empresa, nos permitirá obtener resultados tangibles en un corto espacio de tiempo.

Planteamos aquí la metodología propuesta por SAS Institute: la "Rapid Warehousing Methodology". Dicha metodología es iterativa, y está basada en el desarrollo incremental del proyecto de Data Warehouse dividido en cinco fases. 

• Definición de los objetivos 
• Definición de los requerimientos de información
• Diseño y modelización
• Implementación
• Revisión

3.1 Clasificación de las Medidas

• Naturales: Son aquellas que se obtienen por agregación de los datos originales.
• Suma : Suma los valores de las columnas
• Cuenta : Conteo de los valores
• Mínima : Valor mínimo
• Máxima : Valor máximo
• Cuenta de Distintos : Valores Diferentes
• Calculadas: Si se derivan de una medida natural
• Cálculos matemáticos
• Expresiones condicionales
• Alertas

3.2 Definición de los objetivos

• Establece claramente la finalidad hacia la cual deben dirigirse los recursos y esfuerzos para dar cumplimiento a los propósitos del proyecto.
• Es preciso “vender la idea” a los usuarios finales (todos los niveles: a la Dirección, Gerencia e incluso al área de Desarrollo) de un Data Warehouse.
• Se definirá el equipo de proyecto
• Se definirá el alcance
• Se definirán cuáles son las funciones que el Data Warehouse realizará como suministrador de información de negocio estratégica para la empresa.

3.3 Definición de los requerimientos de información

• Tal como sucede en todo tipo de proyectos, sobre todo si involucran técnicas novedosas como son las relativas al Data Warehouse, es analizar las necesidades y hacer comprender las ventajas que este sistema puede reportar. 
• Será en este punto, en donde detallaremos los pasos a seguir en un proyecto de este tipo en donde el usuario va a jugar un papel tan destacado.
• Analizar las necesidades y hacer comprender las ventajas que este sistema puede reportar.
• Se mantendrán sucesivas entrevistas con los usuarios finales y TI para definir las necesidades de información requerida.
• Se realizará el estudio de los sistemas de información existentes.
• Se definirá la estrategia y arquitectura de implantación del Data Warehouse.

3.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, etc.) 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 de estas definiciones de los datos del Data Warehouse estarán almacenadas en los metadatos y formarán parte del mismo. 

3.5 Implementación

La implantación de un Data Warehouse lleva implícitos los siguientes pasos:

• Extracción de los datos del sistema operacional y transformación de los mismos.
• Carga de los datos validados en el Data Warehouse. Esta carga deberá ser planificada con una periodicidad que se adaptará a las necesidades de refresco detectadas durante las fases de diseño del nuevo sistema. 
• Explotación del Data Warehouse mediante diversas técnicas dependiendo del tipo de aplicación que se dé a los datos.
• Query & Reporting
• On-line analytical processing (OLAP)
• Executive Information System (EIS) ó Información de gestión
• Decision Support Systems (DSS)
• Visualización de la información
• Data Mining o Minería de Datos, etc.
• La información necesaria para mantener el control sobre los datos se almacena en los metadatos técnicos (cuando describen las características físicas de los datos), metadatos operativos (programación de cargas, etc.) y de negocio (cuando describen cómo se usan esos datos). Dichos metadatos deberán ser accesibles por los usuarios finales que permitirán en todo momento tanto al usuario, como al administrador que deberá además tener la facultad de modificarlos según varíen las necesidades de información.
• Con la finalización de esta fase se obtendrá un Data Warehouse disponible para su uso por parte de los usuarios finales y el departamento de informática.

3.6 Revisión

• La construcción del Data Warehouse no finaliza con la implantación del mismo, sino que es una tarea iterativa en la que se trata de incrementarsu alcance aprendiendo de las experiencias anteriores.
• Después de implantarse, debería realizarse una revisión del Data Warehouse planteando preguntas que permitan, después de los seis o nueve meses posteriores a su puesta en marcha, definir cuáles serían los aspectos a mejorar o potenciar en función de la utilización que se haga del nuevo sistema.

3.7 Diseño de la estructura de cursos de formación

• Con la información obtenida de reuniones con los distintos usuarios se diseñarán una serie de cursos a medida, que tendrán como objetivo el proporcionar la formación estadística necesaria para el mejor aprovechamiento de la funcionalidad incluida en la aplicación. 
• Se realizarán prácticas sobre el desarrollo realizado, las cuales permitirán fijar los conceptos adquiridos y servirán como formación a los usuarios.

4. SQL Parallel Datawarehouse

SQL Server 2014 posee las siguientes ediciones:

• Enterprise (64 bits y 32 bits)
• Business Intelligence (64 bits y 32 bits)
• Standard (64 bits y 32 bits)
• Web (64 bits y 32 bits)
• Developer (64 bits y 32 bits)
• Ediciones Express (64 bits y 32 bits)
• Parallel Datawarehouse

Las Ediciones que manejan de mejor manera las soluciones de Business Intelligence son Business Intelligence, Enterprise y Parallel Datawarehouse teniendo como mejor uso las que vienen en arquitectura de 64 bits.

La edición Business Intelligence es más para ambientes departamentales, mientras la versión Enterprise es para ambientes empresariales. Sin embargo, la formance presenta es la versión Parallel Datawarehouse.

SQL Server Parallel Datawarehouse (PDW): Es una solución Appliance del tipo MPP, tecnología que permite el uso de más de 32 microprocesadores.

Entre sus características encontramos las siguientes:

• Viene en dos versiones de hardware bajo plataforma HP y Dell.
• El software viene pre-instalado y afinado para soluciones Business Intelligence.
• Polybase, nuevo motor de procesamiento que permite integrar la data tradicional del Data Warehouse y el “Big Data”. Usa el lenguaje estándar TSQL (en vez de MapReduce) para acceder y unir data Hadoop con data relacional.
• Entre otras características es el bajo precio de almacenamiento frente a otros proveedores de soluciones Business Intelligence.

VIDEOS COMPLEMENTARIOS

Data Warehousing - An Overview

https://www.youtube.com/watch?v=zTs5zjSXnvs

Introduction to Microsoft Parallel Data Warehouse (PDW)

https://www.youtube.com/watch?v=ER3U_XjMRzE

Building BI Solutions with Microsoft SQL Server Parallel Data Warehouse (PDW)

https://www.youtube.com/watch?v=0AEVFO2mwk0

Polybase in the Modern Data Warehouse

https://www.youtube.com/watch?v=X-zP0zSjJOk

LECTURAS COMPLEMENTARIOS

1. Implementación de un modelo básico para el uso de la información Georeferencial en aplicación de BI; caso de estudio: Empresa de Retail
http://www.google.com.pe/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj446ubnZjKAhWIDJAKHfP-CxIQFggaMAA&url=http%3A%2F%2Frepositorio.puce.edu.ec%2Fbitstream%2Fhandle%2F22000%2F8084%2FDisertacion_de%2520Grado_Hypatia_Merino.pdf%3Fsequence%3D1%26isAllowed%3Dy&usg=AFQjCNHtuhoZwbTEH6i7qaimkd-qg-Hmkw

2. Parallel Data Warehouse (PWD)
http://www.jamesserra.com/archive/2014/03/parallel-data-warehouse-pdw-benefits-made-simple/