Inteligencia de negocios

PRESENTACION

Una buena toma de decisiones debe estar soportada en un análisis exhaustivo de la

realidad. La importancia de tener diversas perspectivas del negocio es imprescindible.

El presente manual, desarrolla la manera de implementar una solución analítica basada en un

proceso de data warehousing. Las herramientas empleadas permiten que el usuario (quien
toma las decisiones), tenga diversas formas de ver su realidad y lo más importante es que le
permite a él mismo crear sus propias perspectivas de su realidad. Para esto se desarrolla un
ejemplo completo de implementación de una solución OLAP, desde la definición de los
indicadores (signos vitales de una organización), pasando por el modelamiento analítico, la
implementación de estructuras conocidas por cubos (vista analítica personalizada al usuario)
hasta la explotación de datos en herramientas Office y su publicación en Internet.

OBJETIVOS ESPECÍFICOS

 Diseñar e implementar el Data Warehouse.

 Desarrollar el proceso de ETL del Data warehouse.

 Mostrar, manipular y reconocer la importancia de una solución OLAP

 Ejecutar los comandos SQL relacionados con la sumarización de registros

 Aplicar el proceso de instalación del servidor OLAP

1. BUSINESS INTELLIGENCE
Una de las operaciones fundamentales, en el proceso administrativo, es la toma de
decisiones, la cual determinará el éxito o fracaso de una empresa.

“El 75% de los gerentes toman sus decisiones con información incompleta y
fuera de fecha.” Fuente: CFO Magazine 1999

La tecnología no puede estar ajena a esta necesidad. Es por ello que empresas
como Microsoft, Oracle, IBM e Informix han desarrollado productos Business
Intelligence.

“Business Intelligence” describe la habilidad de la empresa para accesar y

explorar la información (a menudo contenida en un data warehouse) y analizarla
para desarrollar un entendimiento profundo que nos permitirá tomar mejores
decisiones. Gartner Group

Recuerde que no solo es el intercambio de productos entre empresas (B2B),

entre empresa y consumidor (B2C), entre consumidor y empresa (C2B) o entre
consumidores (C2C), sino el agregar VALOR a dichos intercambios.

1.1 Sistemas transaccionales

Los sistemas transaccionales se basan en transacciones, es decir, tienen un proceso

de inicio y fin claramente definidos y no pueden ser interrumpidos en el proceso
general. Como ejemplo, tenemos los sistemas tradicionales de facturación, ventas,
matrícula, notas, caja, etc.

Estos sistemas están orientados a las funciones que cumple el usuario del
sistema, es decir, existen operaciones sobre registros (ingreso, modificación,
eliminación) que se realizan diariamente y los reportes están orientados al detalle
de las operaciones efectuadas.

Este tipo de sistemas usa la tecnología OLTP (On line Transactional Processing)
1.2 Sistemas analíticos

Los sistemas analíticos están basados en la información del sistema transaccional,

es decir, no existe ingreso de datos por parte del usuario y los reportes están
orientados a la sumarización de la información.

El objetivo principal de un sistema analítico es brindar información base para la toma

de decisiones. Este tipo de sistemas usa la tecnología OLAP (On line Analytical
Processing)

1.3 Nuevos conceptos: data warehouse - datamart

Los componentes de los sistemas Business Intelligence proporcionan, primero, la

tecnología OLAP, que nos brinda técnicas y pautas en cuanto a modelamiento y
manejo de data; y, segundo, las herramientas BI, que son herramientas gráficas
que permiten el análisis en línea. Como resultado de su interrelación, se crearon dos
nuevos tipos de bases de datos: data warehouse y datamart.

“El Data Warehouse (DWH) es una colección de datos integrada en una

Base de Datos, orientada según un tema, diseñadas para soportar un
Sistema de Soporte a las Decisiones (DSS), donde cada unidad de dato es
relevante en algún momento del tiempo.” Bill Inmon

“Un data warehouse es un conjunto de datos integrados orientados a una

materia, que varía en el tiempo y que no son transitorios, los cuales soportan el
proceso de toma de decisiones de una administración.” Harjinder S. Gil

Un datamart es un subconjunto de un data warehouse, orientado

específicamente a un área de la empresa.
1.4 Proceso data warehouse

El proceso de desarrollo data warehouse, en forma general, es el siguiente:

Proceso ETL de un Data Warehouse

La migración de los datos desde las fuentes operacionales al DW requiere la necesidad de

procesos para extraer, transformar y cargar los datos, actividad que se conoce como ETL.

Extraer

La primera tarea del proceso ETL consiste en extraer los datos almacenados en los
distintos sistemas de origen. En un número elevado de casos, en los proyectos de
almacenamiento de datos se fusionan datos que provienen de distintos sistemas de
origen. Cada sistema puede usar una organización distinta de los datos, o formatos
diferentes. Dichas fuentes pueden ser bases de datos, ficheros planos, etc., sea cual sea
su estructura. La tarea de extracción convierte todos estos datos a un formato preparado
para comenzar con el proceso de transformación.

El requerimiento imprescindible a la hora de realizar la tarea de extracción es que la

misma cause un impacto mínimo en los sistemas de origen. Si la cantidad de datos a
extraer es muy elevada, el sistema se puede ralentizar, o incluso colapsarse, por lo que
las grandes operaciones de extracción se suelen realizar en momentos donde el impacto
sobre el sistema sea el mínimo posible.
Transformar

En la tarea de transformación se aplican una seria de funciones sobre los datos extraídos
al objeto de convertirlos en datos preparados para su carga. Algunas fuentes de datos tan
solo requerirán mínimas transformaciones, mientras que otras necesitaran de un gran
número de ellas.

Entre las operaciones de transformación podemos encontrar las siguientes: Traducción y

codificación de códigos. Obtención de valores calculados. Generación de nuevos campos.
División de la información. Unión de datos de múltiples fuentes.

Cargar

Es la tarea mediante la cual los datos ya transformados en la fase anterior son cargados
en el sistema de destino. Durante esta fase se interactúa directamente con las bases de
datos de destino, por lo que se aplicaran todas las restricciones y disparadores que se
hayan definido en la misma, contribuyendo este hecho a que se garantice la calidad de los
datos durante el proceso integro.
2. RECURSOS A UTILIZAR

2.1 Herramientas para la inteligencia de negocios (Business Intelligence)

Existen diferentes herramientas para Inteligencia de negocios, Business Intelligence o

simplemente BI. Entre ellas tenemos: Business Objects, Oracle Discoverer, MicroStrategy,
Cognos, Hyperium Analyzer y Microsoft Analysis Services.

Para el presente manual, usaremos el Analysis Services de Microsoft SQL Server 2012 como
Servidor de Análisis y SQL Server Business Intelligence Development Studio como
herramienta de desarrollo. El usuario final podrá explotar y visualizar la información a través
de herramientas como Microsoft Excel y/o páginas Web utilizando el OWC (Office Web
Components).

Las herramientas Microsoft que permiten manejar el proceso data warehousing son las
siguientes:

 SQL Server 2012 .- Manejador de bases de datos relacionales

 SQL Server Integration Services (SSIS).- Transforma y carga datos entre diferentes
fuentes de datos
 SQL Server Analysis Services (SSAS).- Manejador de bases de datos
multidimensionales.
 SQL Server Reporting Services (SSRS).- Servidor de reportes
 SQL Server Business Intelligence Development Studio.- Herramienta que permite el
desarrollo de proyectos de Inteligencia de negocios.
2.2 Bases de datos

Para el desarrollo del proyecto, partiremos de la base de datos transaccional

AdventureWorks2012 Dicha base de datos contiene los datos de ventas para una compañía
que vende artículos deportivos.

El modelo de datos es el siguiente:

Product (Production) SalesOrderDetail (Sales) SalesOrderHeader (Sales) SalesTerritory (Sales)
ProductID SalesOrderID SalesOrderID TerritoryID
Name SalesOrderDetailID RevisionNumber Name
ProductNumber CarrierTrackingNumber OrderDate CountryRegionCode
MakeFlag OrderQty DueDate [Group]
FinishedGoodsFlag ProductID ShipDate SalesYTD
Color SpecialOfferID Status SalesLastYear
SafetyStockLevel UnitPrice OnlineOrderFlag CostYTD
ReorderPoint UnitPriceDiscount SalesOrderNumber CostLastYear
StandardCost LineTotal PurchaseOrderNumber rowguid
ListPrice rowguid AccountNumber ModifiedDate
Size ModifiedDate CustomerID Person (Person)
BusinessEntityID
SizeUnitMeasureCode SalesPersonID
PersonType
WeightUnitMeasureCode TerritoryID
ProductModel (Production)
NameStyle
Weight ProductModelID BillToAddressID
Customer (Sales) Title
DaysToManufacture Name ShipToAddressID
CustomerID
FirstName
ProductLine CatalogDescription ShipMethodID
PersonID
MiddleName
Class Instructions CreditCardID
StoreID
LastName
Style rowguid CreditCardApprovalCode
TerritoryID
Suffix
ProductSubcategoryID ModifiedDate CurrencyRateID
AccountNumber
EmailPromotion
ProductModelID SubTotal
rowguid
AdditionalContactInfo
SellStartDate TaxAmt
ModifiedDate
ProductCategory (Production) Demographics
SellEndDate Freight
ProductCategoryID
rowguid
DiscontinuedDate TotalDue
Name
ModifiedDate
rowguid Comment
rowguid SalesPerson (Sales)
ModifiedDate rowguid BusinessEntityID
ModifiedDate
ModifiedDate TerritoryID

SalesQuota
ProductSubcategory (Production) Bonus
ProductSubcategoryID
CommissionPct
ProductCategoryID
SalesYTD
Name
SalesLastYear
rowguid
rowguid
ModifiedDate
ModifiedDate

Tabla Descripción
La tabla registra la información de los productos que son solicitados en las
Production.producto
órdenes
La tabla registra la información relacionada con las categorías que agrupan
Production.Category
varios productos.
La tabla registra la información relacionada con las Subcategorías que
Production.SubCategory
agrupan varios productos.
La tabla registra la información relacionada con las Modelos de los
Production.Model
productos.
La tabla registra los movimientos de cada orden generada, en la cual se
Sales.SalesOrderHeader consigna el cliente solicitante, el empleado que la atiende, la fecha, entre
otros campos.
La tabla registra el detalle de cada línea de producto de cada orden
Sales.SalesOrderDetail generada, es decir, el producto, la orden, la cantidad solicitada, el precio
unitario y el descuento.
La tabla registra la información relacionada con los vendedores de la
Sales.Customer
compañia
La tabla registra la información relacionada con la cartera de clientes con la
Sales.SalesPerson
que trabaja la compañia
Esta tabla contiene la información general de las personas que interactúan
Person.Person
con la empresa (Clientes, Vendedores, etc)
Sales.SalesTerritory Esta tabla muestra la ubicación de los territorios donde vende la empresa
3. CREACIÓN DE LA BASE DE DATOS

3.1. INDICADORES DE ANÁLISIS

De acuerdo con lo expuesto anteriormente, referente a las tablas de la base de datos y al giro
del negocio de dicha empresa, es posible plantar algunos requerimientos de análisis.

La facilidad que brindan las soluciones OLAP queda de manifiesto en poder definir aquello
que se desea analizar de manera sencilla y flexible.

Debe formularse de manera precisa aquello que se desea analizar. Lo importante

de los indicadores, es que muestran información relevante para poder tomar
decisiones en base a esta información.

La toma de decisiones puede conllevar a la promoción de un nuevo producto, la

liquidación de contrato con un cliente, ser más agresivo en las campañas publicitarias,
fusión entre empresas o hasta el cierre del negocio.

Vamos a listar algunos criterios de análisis básicos sobre la base de datos

o Análisis comparativos de monto facturado entre categorías por periodos de tiempo

o Análisis geográfico por territorios de clientes que solicitan ordenes por
periodos de tiempo
o Análisis de productos con problemas de aceptación por rangos de tiempo
o Comparativos entre meses relacionados a monto de facturación
o Encontrar los periodos de tiempo con menos ingresos (facturación) para la
empresa con respecto a las órdenes

3.2. MODELO DIMENSIONAL

El modelo dimensional contiene la representación de las tablas que conforman la

solución OLAP. Dicho modelo tiene una estructura muy diferente al modelo E-R
conocido.

En el modelo dimensional, se deben contemplar dos tipos de estructuras:

1. Tabla de hechos (fact table).

2. Tabla dedimensión

3.2.1 Tabla de hechos (fact table)

Esta tabla contiene la representación de un hecho en el sistema. El hecho se origina

al momento de registrarse las transacciones en el sistema OLTP y debe ser identificado
por el analista con la finalidad de representarlo en el modelo dimensional.
 La tabla de hechos debe contener la información de las medidas que se pretende analizar,
las cuales serán campos con tipos de datos numéricos, como monto facturado, cantidad
de items, gastos, notas.

Por ejemplo:

Un hecho es el registro de asistencia de cada trabajador de manera diaria al llegar a

su centro de labores, con lo cual podemos analizar las tardanzas mensuales, anuales,
entre otros.

La tabla de hechos deberá contener:

o Medidas
o Información relacionada al hecho (Surrogate Key)

3.2.2 Tabla d e dimensión

Esta tabla contiene la información relacionada con el hecho, el cual es descrito en la tabla
de hechos.

Las tablas d e dimensión también representan las distintas opciones que el usuario tiene
para poder analizar su información, por ejemplo, las ventas se pueden analizar por
clientes, por productos, por empleados, etc. Aquí, clientes, productos y empleados son,
potencialmente, tablas dimensión.

También, es importante estructurar las tablas dimensión con campos que puedan ser
potencialmente agrupables.

Por ejemplo:
 Productos, analizar las órdenes desde el punto de vista de los productos
 Clientes, analizar las órdenes desde el punto de vista de los clientes
3.3. GRANULARIDAD DE DATOS DEL MODELO DIMENSIONAL

Esto significa que debemos definir el nivel de detalle de nuestro Data warehouse.
En nuestro caso, el objetivo es analizar los volúmenes de ventas por cada producto
de una orden.

3.4. ESTRUCTURA DEL MODELO DIMENSIONAL

DIM_producto DIM_categoria
SKproductoID SKcategoriaID
productoID categoriaID
nombre nombre
color

FACT_Ventas
DIM_modelo
SKVenta DIM_subcategoria
SKmodeloID ordenID SKsubcategoriaID

modeloID detalleid subcategoriaID

nombre cantidad nombre

costounitario
preciounitario
total
DIM_fecha
SKfecha SKfecha
DIM_territorio
SKproductoid fecha
SKterritorioID
SKcategoriaID año
territorioID
SKsubcategoriaID mes
nombre
SKmodeloID mesD
codigoPais
SKclienteID dia
Grupo
SKvendedorID semana
SKterritorioID cuatrimestre

DIM_vendedor DIM_cliente
SKvendedorID SKclienteID
vendedorID clienteID
nombre nombre

El modelo dimensional mostrado responde a las preguntas planteadas en la

sección de los indicadores. El modelo dimensional consta de las siguientes tablas.

Ejemplo:
 “Comparativos entre meses relacionados a monto de facturación”

o Cada registro en la tabla fact_ventas contiene el monto

facturado por un producto determinado en una orden. Con
este, podemos obtener la facturación total de manera
mensual, con lo cual es factible realizar la comparación.

Del modelo dimensional (MD) se puede concluir:

o El M.D, está en esquema estrella, pues las tablas dimensión se conectan con
la tabla de hechos directamente.
o Las estructuras de las tablas del M.D. presentan diferencias con las del
modelo E-R.
3.5. BASE DE DATOS DE TRABAJO O INTERMEDIA (VentasStage)

Las organizaciones de hoy en día cuentan con innumerables dispositivos de

almacenamiento donde a los largo de los años han ido guardando sus datos:
archivos de texto, hojas de cálculo, archivos dbf, diversas bases de datos (Informix,
Oracle, SQL, etc), etc.

La elaboración de un modelo dimensional debe entonces, considerar toda estos

orígenes de información para poder responder a preguntas de análisis que
pudiera requerirse sobre estos datos.

Es por ello que, antes de trasladar la información de nuestros orígenes de datos a

nuestro modelo dimensional, es necesario que estos sean integrados, limpiados y
transformados, de tal manera que aseguren la calidad de los datos que se están
almacenando en el modelo dimensional creado.

Para ello, es necesario contar con un modelo intermedio en el cual se pueda

realizar esta tarea de limpieza y transformación. Esta área es conocida como
Stage Area o Área de trabajo.

La siguiente gráfica muestra la arquitectura que se debe construir para el desarrollo

del ejemplo.

Anteriormente, hemos descrito la base de datos AdventureWorks, así como la base de

datos VentasDWH. Para poblar el modelo dimensional es necesario que los datos
hayan sido preparados y depurados. Dicha labor se realiza en el Stage Area
(VentasStage)
ESTRUCTURA DEL MODELO VentasStage (Base de datos intermedia)

STG_subcategoria STG_categoria STG_cliente

subcategoriaID categoriaID clienteID
nombre nombre nombre
categoriaID SKcategoriaID SKclienteID
SKsubcategoriaID

STG_producto STG_DetalleOrden STG_Orden

productoID OrdenID ordenID
fechas
nombre OrdenDetalleID fecha
fecha
NoProducto productoid clienteID
año
color cantidad vendedorID
mes
costo preciounitario territorioID
mesD
precio total subtotal
dia
subcategoriaID SKVenta impuesto
semana
modeloID SKproductoid total
cuatrimestre
SKproductoID SKclienteID
SKfecha
SKcategoriaID SKvendedorID
SKsubcategoriaID SKterritorioID
SKmodeloID

STG_territorio
territorioID
STG_vendedor
nombre
STG_modelo vendedorID
modeloID codigoPais
nombre
nombre Grupo
SKvendedorID
SKmodeloID SKterritorioID

Note que el modelo anterior es u n d ise ñ o in te r m e d io e n tr e la s b a s e s d e

d a to s tr a n sa ccio n a l e s y e l m o d e lo dimensional. La base de datos de área
de trabajo (Stage área), es empleada para realizar todas las tareas de limpieza y
transformación de los datos.
4. CREACIÓN DE UN PROYECTO DE ETL UTILIZANDO SQL
SERVER INTEGRATION SERVICES
En un proceso data warehouse, el sistema transaccional debe alimentar al sistema
analítico. Sin embargo, es muy probable que el sistema transaccional se encuentre
en fuentes de datos muy diversas (archivos.DBF, base de datos Oracle o Sybase,
archivos.XLS, archivos.TXT, etc.), pero la data en el servidor de análisis debe
ser uniforme. Para ello, utilizamos SQL Server Integration Services, que es la
herramienta de ETL proporcionada por Microsoft y que viene incluida en SQL Server
2008. SSIS nos permite lo siguiente:

 Generar, dentro de un Proyecto, uno o más paquetes de ETL que nos permita
trasladar los datos de diferentes orígenes a un destino.

 Permitirá administrar mejor los procesos de ETL que puedan desarrollarse para
poblar el data warehouse,

 Extraer la información de diferentes fuentes de datos a través de diferentes

conectores (proveedores .Net y proveedores OLE DB nativos),

 Transformar datos mediante tareas de transformación, búsqueda, integración,

combinación, etc.;

 Controlar la secuencia que los datos deben seguir mediante el control de eventos
de éxito y fallo;

 Cargar la información a diferentes fuentes de datos.

4.1. ELEMENTOS DE SSIS

SSIS está constituido por varios elementos que permiten construir paquetes de ETL
complejos. Sus componentes son:

A. Data Sources.- Identifica las conexiones hacia los diversos orígenes de datos.

B. Data Source View.- Definen vistas parciales o totales de los objetos de un Data
Source.

C. Tasks.- Asociada a una unidad de transformación, procesamiento de datos o

transferencia de registros de un origen a un destino.
 D. Control Flow.- Define la secuencia lógica de transferencia de información. Por
ejemplo, a través de los flujos de control se permiten controlar la secuencia
de transformación, limpieza, búsqueda, etc. del dato.

E. Container.- Permite agrupar diferentes tareas de transformación para facilitar

el entendimiento o la secuencia de las tareasl.

F. Package.- Todas las tareas contenidas dentro de un paquete de SSIS

4.2. CREACIÒN DE PAQUETES DTS

La creación de un paquete de SQL Server Integration Services se realiza utilizando

el entorno de desarrollo “SQL Server Business Intelligence Development Studio”.
Ahí se crearán los paquetes que nos permitirá extraer la información de la base de
datos AdventureWorks a la base de datos VentasStage, hacer el proceso de
transformación necesario y de ésta cargar la base de datos VentasDWH.

Es necesario que definamos y aclaremos algunos puntos antes de iniciar nuestra

labor:

 Definición del problema a solucionar

o ¿Es un problema de migración de datos?.
o ¿Estoy en un proceso de Data Warehousing?.
o ¿Mi proceso se deberá ejecutar periódicamente o por única vez?.
o ¿Será un proceso de ejecución manual, automática o a demanda?.

 Definición de las fuentes de datos que intervendrían en dicha solución

o ¿El ETL involucra un solo servidor o más de uno?.
o ¿El ETL involucra solo servidores SQL SERVER?.
o Si existiera la necesidad de involucrar a otras fuentes de datos,
¿en qué plataformas están (Oracle, Ms.Excel, Correo, MySql, archivos
planos, etc.)?.
o Para el paso anterior, ¿tenemos los Drivers apropiados para
podernos conectar a las fuente de datos en cuestión?.

 Definir si la fuente de datos contiene datos que son factibles transformarlos

para poder obtener datos de calidad.

 Definir específicamente dónde están los datos dentro de la fuente de datos

para preparar las sentencias de acceso a datos.
4.2.1. Ingreso al entorno del SSIS (SQL Server Integration Services).

Para comenzar nuestro trabajo en la creación de paquetes ETL, debemos

ingresar SQL Server Data Tools y crear un nuevo proyecto de SQL Server
Integration Services.

Aparecerá el entorno de desarrollo de Microsoft Visual Studio. Para generar un

nuevo proyecto de SSIS elegimos la opción Archivo / Nuevo / Proyecto.
Aparecerá la pantalla de proyectos en el cual seleccionamos Proyecto de
Integration Services y le asignamos como nombre “ExtraerVentas.”
 A continuación, se muestra el entorno de desarrollo de los paquetes de ETL.

4.2.2. Implementación de l o s paquetes SSIS

El ejemplo que se está desarrollando requiere la implementación de tres

paquetes. El primero llevará la data de la base de datos AdventureWorks a
VentasStage (EXTRACCION), el segundo adecuará la data para su carga al Data
warehouse (TRANSFORMACION) y el tercero vaciará la data de VentasStage a
VentasDWH (CARGA).
A. Construir paquete ExtraerVentas

Nota: Si el cuadro de herramientas no aparece, entonces ir al Menu Ver / Cuadro de

Herramientas.

A continuación procederemos a construir el primer paquete de ETL que va a

trasladar la información de la base de datos AdventureWorks a la base de datos
VentasStage (ExtraerVentas).

Las actividades desarrolladas en el ETL son:

o Eliminar los registros de las tablas de Stage.

o Inicializar los campos identity de las tablas de l a b a s e d e
datos intermedia (VentasStage).
o Implementar los Flujos de Datos.
Generar Conexiones

Esta tarea consiste en pasar la información de las tablas de la base de datos de

AdventureWorks a las tablas de la base de datos de trabajo VentasStage, por lo que
se deberá generar una conexión al origen de datos AdventureWorks
(específicamente a la vista DW_AdventureWorks previamente definida, así como
también se debe tener conexión con la base de datos VentasStage.

 Para Generar la conexión a VentasStage, en el área de administradores de

conexión dar (1) clic derecho y ( 2 ) s e l e c c i o n a r NuevaConexión OLE DB

 En la siguiente ventana:

 Dar nueva
 Ponemos los valores de proveedor, nombre del servidor, conexión, base de datos
en el Administrador de conexiones, presionamos el botón de probar conexión y
finalmente aceptar.

 Seleccionar la conexión y darle aceptar.

 Generamos la conexión a AdventureWorks, repitiendo los pasos anteriores, de tal
forma que queden las dos conexiones:
Actividad eliminar registros

 Del Cuadro de Herramientas de Elementos de flujo de control seleccionamos la

tarea “Tarea Ejecutar SQL” y la arrastramos al Diseñador.

 Clic derecho sobre la tarea, Editar.

 Modificamos las siguientes propiedades

Propiedad Valor
Name Limpiar Tablas
Description Limpia Tablas de VentasStage
ConnectionType OLEArea
DB
Connection Localhost.VentasStage
SQL Statement Delete from STG_Cliente…

 Para escribir la consulta de SQL presionar

 Se abrirá una ventana donde se debe introducir este código:

 Para terminar, presionar aceptar.

 Para probar la tarea tenemos que ejecutarla: Para esto seguimos los siguientes
pasos, seleccionamos la tarea / Clic Derecho / Ejecutar tarea

o La tarea comienza su ejecución. Durante este proceso la tarea cambia

de color.

Amarillo.- Tarea se está ejecutando.

Rojo.- Tarea terminó con error.
Verde.- Tarea terminó correctamente.

 Al finalizar la tarea paramos la ejecución (Menú Depurar /

Detener Depuración)
Actividad I n i c i a l i z a r S e r i a l e s

 Del Cuadro de Herramientas de Elementos de flujo de control seleccionamos la

tarea “Tarea Ejecutar SQL” y la arrastramos al Diseñador (1) y le cambiamos el
nombre a “Inicializa seriales”.

 Se debe definir el orden de ejecución de las tareas, creando una conexión entre
estas, para lo que se debe dar clic sobre la tarea previa (Limpiar Tablas) y arrastrar
la punta de la flecha a la siguiente tarea a ejecutar (2).
 Dar clic derecho sobre la tarea, Editar.
 Modificamos las siguientes propiedades

Propiedad Valor
Name Limpiar Tablas
Description Limpia Tablas de VentasStage
ConnectionType OLEArea
DB
Connection Localhost.VentasStage
SQL Statement DBCC CHECKIDENT…
 Para inicializar los seriales presionar el botón (…) al final de la línea
SQLStatement y se abrirá una ventana donde se debe introducir este código:

 Darle Aceptar
Actividad Carga Categoria

Esta tarea consiste en pasar la información de las categorías de los productos de la

base de datos de AdventureWorks a la base de datos de trabajo VentasStage.

 Del cuadro de herramientas seleccionamos de Elementos de flujo la tarea

“Tarea Flujo de datos” y la arrastramos a Diseñador.

 Cambiar el nombre a “cCategoria” e Indicar el orden de ejecución de las tareas.

 Clic derecho sobre la tarea y seleccionamos la opción Editar.

 Automáticamente la pantalla del Diseñador cambia a la pestaña Flujo de datos y
el Cuadro de herramientas cambia de tareas disponibles como sigue:

La pantalla de Flujo de datos nos permitirá realizar la tarea de ETL. Para ello
necesitaremos conectarnos a un origen de datos, diseñar las tareas de
transformación para, finalmente, trasladarla hacia el destino final.
SSIS dentro del flujo de datos nos permite conectarnos a los siguientes
orígenes:

Nos permite trasladar la información a los siguientes destinos.

Y nos permite realizar las siguientes transformaciones.

Para desarrollar nuestra Tarea de flujo de datos seguiremos los siguientes pasos:

1.- Crear un origen de datos

 De orígenes de flujo de datos arrastramos “Origen de OLE DB” al diseñador.

 Cambiamos el nombre de la tarea a Lee Categoría.

 Damos doble clic sobre la tarea Lee Categoría o Clic derecho/editar y aparece la
pantalla con las propiedades de la tarea seleccionada con las siguientes
opciones:

 Administrador de Conexión OLE DB.- Define el origen del cual se leerá los
datos.
 Modo de Acceso a Datos.- Define la forma en cómo se leerán los datos. Esta
puede ser:
o Tabla o vista
o Variable de Nombre de tabla o Nombre de vista
o Comando SQL
o Comando SQL con variable.

 Nombre de la tabla o vista – indica la tabla de la que se van a leer los datos (como
se seleccionó como origen de datos una vista de la base de datos que contiene
alguna tablas, la lista muestra solamente la tablas contenidos en la vista):
Para el ejemplo, debemos considerar los siguientes valores:

Propiedad Valor
Administrador de Conexión OLE DB DW_AdventureWorks
Modo de Acceso a Datos Tabla o Vista
Nombre de la tabla o vista [Production].[ProductCategory]

 Seleccionamos las columnas que utilizaremos en el proceso de carga (en este

caso solo ProductCategoryID y Name).

 damos Clic en Aceptar.

2.- Transformación del flujo de datos.

Debido a que para la información de las categorías de productos solo es necesario

pasarla de la tabla de Production.ProductCategory de AdventureWorks a
STG_Category de VentasStage como se muestra en el diagrama no es necesario un
proceso de transformación.
3.- crear un destino de datos.

 De Destinos de flujo de datos arrastramos “Destino de OLE DB” al diseñador.

 Cambiamos el nombre de la tarea a escribe Categoría.
 Definimos la secuencia que debe llevar el flujo de datos, se debe dar clic izquierdo
sobre lee Categoría, y aparecen 2 flechas la verde indica el flujo cuando la lectura
es correcta, la roja cuando hay algún error.

Se debe seleccionar la flecha verde y conectar con escribe categoría.

 Se le da Clic derecho Editar o doble clic sobre la tarea escribe Categoría y

aparece el Editor de destino OLE DB con las siguientes opciones:
 Administrador de conexión OLE DB.- Define el destino en el cual se grabaran los
datos
 Modo de acceso a datos.- Define la forma en cómo se grabaran los datos. Esta
puede ser:
 Tabla o vista.
 Carga rápida de Tabla o vista.
 Variable de nombre de tabla o Nombre de vista.
 Carga rápida de variable de nombre de tabla o Nombre de vista
 Comando SQL.
• Nombre de la tabla o vista sobre la que se insertaran los datos

Para el ejemplo, debemos considerar los siguientes valores:

Propiedad Valor
Administrador de conexión OLE DB Localhost.VentasStage
Modo de acceso a datos Tabla o Vista
Nombre de la tabla o vista [dbo].[STG_Categoria]

 En la opción de Asignaciones (1), relacionamos las columnas del origen (o de las

transformaciones) con las columnas del destino.

 Para hacer la asignación se pueden arrastrar las columnas de entrada a las

columnas de salida y dar Clic en Aceptar.

Para probar el paquete, ubíquese en Flujo de control, seleccione la tarea Cargar

STG_Categoria y ejecútelo, al finalizar la tarea, pare la ejecución (Menú
Depurar / Detener Depuración), grabe el proyecto (Menú Archivo / Guardar Todo).
Para la información de Subcategorías, Modelos, y Productos el proceso es el mismo
que el de categorías, donde solo es necesario seguir los diagramas de mapeo de la
información como sigue, otra situación que hay que cuidar también que el orden de
llenado de las tablas considere la 2da regla de integridad (los valores de las llaves
foráneas):

Actividad Carga SubCategoria

Actividad Cargar STG_Modelo

Actividad Cargar STG_Producto

El diagrama de Flujo de control al llegar a este punto será el siguiente:

Las tareas de carga Categoría, y Carga Modelos se realizan simultáneamente,

sin embargo para cargar productos es necesario que previamente se carguen
categorías, subcategorías y modelos, como se muestra en el diagrama de flujo de
control.

Actividad Cargar STG_Territorio

Para la tabla STG_Territorios los datos nombre y grupo se definieron de tipo

nvarchar(20), mientras que name y group de la tabla original SalesTerritory son
nvarchar(50), por lo que va a ser necesario una transformación para evitar errores.
Para desarrollar nuestra Tarea de flujo de datos seguiremos los siguientes pasos:

 Del cuadro de herramientas seleccionamos de Elementos de flujo la tarea

“Tarea Flujo de datos” y la arrastramos a Diseñador.

 Le cambiamos el nombre a CTerritorio, y se coloca después de la tarea limpiar

tablas, ya que se puede ejecutar simultáneamente con las anteriormente definidas
sin problema y pasamos a definir su flujo de datos.

1.- Crear el origen de datos

 De orígenes de flujo de datos arrastramos “Origen de OLE DB” al diseñador.

 Cambiamos el nombre de la tarea a Lee Territorio.

 Damos doble clic sobre la tarea Lee Territorio o Clic derecho/editar y establecemos
los siguientes valores:

Propiedad Valor
Administrador de Conexión OLE DB DW_AdventureWorks
Modo de Acceso a Datos Tabla o Vista
Nombre de la tabla o vista [Sales].[SalesTerritory]
  Seleccionamos las columnas que utilizaremos en el proceso de carga

 damos Clic en Aceptar.

2.- Transformación del flujo de datos.

Como se comentó anteriormente, se debe hacer un proceso de transformación de datos ya

que para la tabla STG_Territorios los datos nombre y grupo se definieron de tipo
nvarchar(20), mientras que name y group de la tabla original SalesTerritory son
nvarchar(50).

Para esto se utiliza una tarea SSIS. Del Cuadro de herramientas, en

Transformación de flujo de datos, seleccionamos la tarea Columna Derivada y lo
asociamos con la tarea Lee Territorio. Debe mostrarse de la siguiente manera.
La tarea de Columna Derivada nos permitirá crear nuevos campos a partir de los
campos ya existentes. Para ello, nos facilitará un conjunto de funciones de
cadena, matemáticas, de fecha, nulos, conversión de tipo, etc.

En el ejemplo, vamos a crear las columnas nombre20 y grupo20 a partir de

las columnas Name y group.

 Si le damos Clic derecho Editar o doble clic sobre la tarea Columna

Derivada, nos aparecerá la siguiente pantalla:

Las propiedades a incluir son:

 Nombre de la columna.- Indicamos el nombre de la columna que

necesitamos crear.
 Columna derivada.- Indicamos si la columna derivada será una nueva columna o
reemplazará a una columna ya existente.
 Expresión.- Indicamos el ¿Cómo se va a crear la nueva columna derivada?.
 Tipo de datos.- Indicamos el nuevo tipo de dato que se le asignará a la columna.
 Longitud.- Si el campo es carácter, se debe especificar el tamaño que tendrá en
nuevo campo.
 Precisión / Escala.- Si el campo es numérico, se debe especificar el número de
enteros y decimales que soportará.

Para el ejemplo, utilizaremos los siguientes valores:

Propiedad Valor
Nombre de columna Nombre20
Columna derivada <agregar como columna nueva>
Expresión SUBSTRING(Name,1,20)
Tipo de datos Cadena Unicode[DT_WSTR]
Longitud 20
3.- crear un destino de datos.

 De Destinos de flujo de datos arrastramos “Destino de OLE DB” al diseñador.

 Cambiamos el nombre de la tarea a escribe Territorio.
 Definimos la secuencia que debe llevar el flujo de datos, se debe colocar esta tarea
después de la tarea Columna Derivada.

 Se le da Clic derecho Editar o doble clic sobre la tarea y se le configura con

las siguientes opciones:

Propiedad Valor
Administrador de conexión OLE DB Localhost.VentasStage
Modo de acceso a datos Tabla o Vista
Nombre de la tabla o vista [dbo].[STG_Territorio]

 En la opción de Asignaciones, relacionamos las columnas del origen o las

derivadas con las columnas del destino.

 y dar Clic en Aceptar.

Actividad Cargar Clientes

Para la tabla STG_Clientes, los datos provienen de las tablas Sales.Customer y

Person.person lo que hace necesario hacer una reunión con estas tablas (la cual se
realizará con una operación de SQL), además la columna nombre se forma con la
concatenación de las columnas FirstName, MiddleName y LastName. Lo que hace
necesario una transformación de datos (también se puede hacer con una operación de
SQL, pero esto lo dejaremos para el siguiente ejemplo (carga Vendedores)).
Para desarrollar nuestra Tarea de flujo de datos seguiremos los siguientes pasos:

 Del cuadro de herramientas seleccionamos de Elementos de flujo la tarea

“Tarea Flujo de datos” y la arrastramos a Diseñador.

 Le cambiamos el nombre a C Clientes, y se coloca después de la tarea limpiar

tablas, ya que se puede ejecutar simultáneamente con las anteriormente
definidas sin problema y pasamos a definir su flujo de datos.
1.- Crear un origen de datos

 De orígenes de flujo de datos arrastramos “Origen de OLE DB” al diseñador.

 Cambiar el nombre de la tarea a Lee Cliente.

 Dar doble clic sobre la tarea Lee Cliente o Clic derecho/editar y Configurar las
siguientes propiedades:

Propiedad Valor
Administrador de conexión DW_AdventureWorks
Modo de acceso a datos Comando SQL
Texto de comando SQL select customerid,firstname,middlename,
lastname
from sales.customer c inner join person.person p
on c.personid = p.businessentityid
  Aparecen solo las columnas que se incluyeron en la operación de SQL.

 damos Clic en Aceptar.

2.- Transformación del flujo de datos.

Note que en la tabla Person de la base de datos AdventureWorks, el nombre

del Cliente aparece separado en las columnas LastName, MidlleName y
FistName, pero en la tabla STG_Cliente se necesita almacenar e n una columna
con el nombre completo.
Se utiliza una tarea SSIS. Del Cuadro de herramientas, en Transformación de
flujo de datos, seleccionamos la tarea Columna Derivada y lo asociamos con la
tarea Lee Cliente y le cambamos el nombre a Integra Fullname. Debe mostrarse de
la siguiente manera:
En el ejemplo, vamos a crear la columna FullName a partir de las columnas
FirstName, MiddleName y LastName, también debemos considerar que existen
registros de personal que tienen valor nulo en la columna MiddleName, si se
concatenan las 3 columnas el resultado sería nulo para estos casos por lo que
usaremos una condición.

 Editar la tarea de Columna Derivada y utilizar los siguientes valores:

Propiedad Valor
Nombre de columna FullName
Columna derivada <agregar como columna nueva>
Expresión ISNULL(middlename) ? SUBSTRING(TRIM(lastname) +
" " + TRIM(firstname),1,50) :
SUBSTRING(TRIM(lastname) + " " +
Tipo de datos TRIM(middlename)
Cadena + " " + TRIM(firstname),1,50)
Unicode[DT_WSTR]
Longitud 50
3.- crear un destino de datos.

 De Destinos de flujo de datos arrastramos “Destino de OLE DB” al diseñador.

 Cambiamos el nombre de la tarea a escribe Cliente.
 Definimos la secuencia que debe llevar el flujo de datos, se debe colocar esta tarea
después de la tarea Columna Derivada.

 Se le da Clic derecho Editar o doble clic sobre la tarea y se le configura con

las siguientes opciones:

Propiedad Valor
Administrador de conexión OLE DB Localhost.VentasStage
Modo de acceso a datos Tabla o Vista
Nombre de la tabla o vista [dbo].[STG_Cliente]

 En la opción de Asignaciones, relacionamos las columnas del origen y la

derivada (FullName) con las columnas del destino.

 y dar Clic en Aceptar.

Actividad Cargar Vendedores

Para cargar la tabla STG_Vendedor, los datos provienen de la tabla Person.person

tomando únicamente las personas que tienen su BusinessEntityID igual al valor de la
columna SalesPersonID de la tabla SalesOrderHeader, lo que hace necesario realizar
una operación de SQL, por otra parte la columna nombre se forma con la concatenación
de las columnas FirstName, MiddleName y LastName. Lo que hace necesario una
transformación de datos como en el ejemplo anterior o definir una columna (FullName) en
la operación de SQL antes mencionada (lo que se va a hacer en este ejemplo).

Para desarrollar nuestra Tarea de flujo de datos seguiremos los siguientes pasos:

 Del cuadro de herramientas seleccionamos de Elementos de flujo la tarea

“Tarea Flujo de datos” y la arrastramos a Diseñador.

 Le cambiamos el nombre a CVendedores, y se coloca después de la tarea Inicia

Seriales, ya que se puede ejecutar simultáneamente con las anteriormente
definidas sin problema y pasamos a definir su flujo de datos.
1.- Crear un origen de datos

 De orígenes de flujo de datos arrastramos “Origen de OLE DB” al diseñador.

 Cambiar el nombre de la tarea a Lee Vendedor.

 Dar doble clic sobre la tarea o Clic derecho/editar y Configurar las siguientes
propiedades, con el case se resuelve el problema de que el middlename sea nulo:

Propiedad Valor
Administrador de DW_AdventureWorks
conexión
Modo de acceso a datos Comando SQL
Texto de comando SQL select businessentityid,
substring(firstname+' ' +
case
when middlename is null then '' else middlename
end
+ ' '+lastname,1,50) as Fullname
from person.person
where businessentityid in (select salespersonid
from sales.salesorderheader)
  Aparecen solo las columnas que se incluyeron en la operación de SQL incluyendo la
columna FullName.

 damos Clic en Aceptar.

2.- Transformación del flujo de datos.

Ya que la columna FullName ya se definió en la operación de SQL del origen de
datos no es necesario hacer una operación de Transformación, ya que se puede
pasar directamente al destino de datos, esto también se puede hacer en el ejemplo
anterior (carga Clientes).

3.- crear un destino de datos.

 De Destinos de flujo de datos arrastramos “Destino de OLE DB” al diseñador.

 Cambiamos el nombre de la tarea a escribe Vendedor.
 Definimos la secuencia que debe llevar el flujo de datos, se debe colocar esta tarea
después de la tarea Lee Vendedor.
 Se le da Clic derecho Editar o doble clic sobre la tarea y se le configura con
las siguientes opciones:

Propiedad Valor
Administrador de conexión OLE DB Localhost.VentasStage
Modo de acceso a datos Tabla o Vista
Nombre de la tabla o vista [dbo].[STG_Vendedor]

 En la opción de Asignaciones, relacionamos las columnas BusinessEntityID y

FullName que se definieron en la operación de SQL con las columnas del destino.

 y dar Clic en Aceptar.

Otra forma de cargar la tabla STG_Vendedor, es crear una vista y cargar los datos
directamente de ésta como sigue:

Utilizando SQL Server Management Studio crear la vista vendedores en la base de datos
VentasStage.

use ventasStage;

create view vendedores (vendedorID,nombre)

as select businessentityid,
substring(firstname+' '+ISNULL(p.MiddleName,'')+' '+lastname,1,50)
from AdventureWorks2012.person.person as p
where businessentityid in (select salespersonid
from AdventureWorks2012.sales.salesorderheader);

 Creamos la “Tarea Flujo de datos” y le cambiamos el nombre a cVendedores.

1.- Crear un origen de datos

 De orígenes de flujo de datos arrastramos “Origen de OLE DB” al diseñador.

 Cambiar el nombre de la tarea a Lee Vendedor.

 Dar doble clic sobre la tarea o Clic derecho/editar y Configurar las siguientes
propiedades.

Propiedad Valor
Administrador de conexión ventasStage
Modo de acceso a datos Tabla o vista
Nombre de la tabla o vista vendedores
  Aparecen solo las columnas que se incluyeron en la vista.

 damos Clic en Aceptar.

2.- Transformación del flujo de datos.

Ya que la columna nombre ya se definió en la vista vendedores no es necesario
hacer una operación de Transformación, ya que se puede pasar directamente al
destino de datos, esto también se puede hacer en el ejemplo anterior (carga
Clientes).
3.- crear un destino de datos.

 De Destinos de flujo de datos arrastramos “Destino de OLE DB” al diseñador.

 Cambiamos el nombre de la tarea a escribe Vendedor.
 Definimos la secuencia que debe llevar el flujo de datos, se debe colocar esta tarea
después de la tarea Lee Vendedor.

 Se le da Clic derecho Editar o doble clic sobre la tarea y se le configura con

las siguientes opciones:

Propiedad Valor
Administrador de conexión OLE DB Localhost.VentasStage
Modo de acceso a datos Tabla o Vista
Nombre de la tabla o vista [dbo].[STG_Vendedor]

 En la opción de Asignaciones, relacionamos las columnas vendedorId y nombre con

las columnas del destino.

 y dar Clic en Aceptar.

Actividad Carga Fechas

Para realizar este proceso debemos crear una Tarea de flujo de datos como sigue:

 Del cuadro de herramientas seleccionamos de Elementos de flujo la tarea

“Tarea Flujo de datos” y la arrastramos a Diseñador.

 Le cambiamos el nombre a CFechas, y se coloca después de la tarea Inicia

Seriales, ya que se puede ejecutar simultáneamente con las anteriormente
definidas sin problema y pasamos a definir su flujo de datos.

1.- Crear un origen de datos

 De orígenes de flujo de datos arrastramos “Origen de OLE DB” al diseñador.



 Cambiar el nombre de la tarea a Lee Fechas.

 Dar doble clic sobre la tarea o Clic derecho/editar
En este punto podemos seleccionar dos opciones de origen de datos, A.-(Tabla o
vista) o B.-(Comando SQL).

Para la opción A debemos crear con el SQL Server Managment Studio una vista que
llamaremos Vfechas en la Base de datos VentasStage con la siguiente definicion:

use ventasStage

create view Vfechas

as select distinct OrderDate fecha,
YEAR(OrderDate) año,
MONTH(OrderDate) mes,datename(mm,OrderDate) mesD,
DAY(OrderDate) dia,
datename(wk,OrderDate) semana,
datename(qq,OrderDate) cuatrimestre
from AdventureWorks2012.Sales.SalesOrderHeader;

Y en el editor de Origen de datos indicamos la base de datos (VentasStage), el modo

de acceso a datos la opción de Tabla o vista y en el nombre seleccionamos la vista
VFechas, como sigue:
Para la opción B, en el editor de Origen de datos indicamos la base de datos
(AdventureWorks), el modo de acceso a datos la opción de Comando SQL y en el
Texto de comando SQL la siguiente proposición select:

select distinct OrderDate fecha,

YEAR(OrderDate) año,
MONTH(OrderDate) mes,datename(mm,OrderDate) mesD,
DAY(OrderDate) dia,
datename(wk,OrderDate) semana,
datename(qq,OrderDate) cuatrimestre
from AdventureWorks2012.Sales.SalesOrderHeader;

Y quedaría como sigue:

 damos Clic en Aceptar.

2.- Transformación del flujo de datos (para los dos casos).

La columna Mesd del origen de datos tiene una longitud mayor que la columna
Mesd de la tabla de destino, por lo que se deberá recortar a una longitud de 10
utilizando una transformación de columna derivada como sigue, esto también se
puede corregir en la vista y/o comando de SQL:

3.- crear un destino de datos (para los dos casos).

 Crear el destino de datos, cambiarle el nombre a escribe fechas y modificar las

propiedades como sigue:

Propiedad Valor
Administrador de conexión OLE DB Localhost.VentasStage
Modo de acceso a datos Tabla o Vista
Nombre de la tabla o vista [dbo].[STG_Fechas]

 En la opción de Asignaciones, relacionamos las columnas correspondientes.

Para la información de Órdenes y Detalle de orden el proceso es el mismo que el de
categorías, donde solo es necesario seguir los diagramas de mapeo de la información
como sigue, otra situación que hay que cuidar también que el orden de llenado de las
tablas considere la 2da regla de integridad (los valores de las llaves foráneas):

Actividad Carga Orden

Actividad Carga DetalleOrden

El diagrama de Flujo de control al llegar a este punto será el siguiente:

Paquete extraerVentas
B. Construir paquete TransformarVentas
Una vez Cargada la información de la base de datos, se procederá a hacer algunas tareas
para acondicionar los datos para el Data Warehouse, por ejemplo eliminar valores nulos que
se cargaron en algunas tablas.

Para comenzar nuestro trabajo en la creación del paquete ETL transformaVentas,

debemos ingresar SQL Server Data Tools y crear un nuevo proyecto de SQL
Server Integration Services.

Aparecerá el entorno de desarrollo de Microsoft Visual Studio. Para generar un nuevo

proyecto de SSIS elegimos la opción Archivo / Nuevo / Proyecto. Aparecerá la pantalla
de proyectos en el cual seleccionamos Proyecto de Integration Services y le asignamos
como nombre “transformarVentas.”
Generar Conexiones

Esta tarea consiste en transformar (adecuar) la información de las tablas de la base

de datos intermedia (ventasStage) antes del proceso de carga al data Warehouse,
por lo que se deberá generar únicamente una conexión al origen de datos para esta
base de datos.

 Para Generar la conexión a VentasStage, en el área de administradores de

conexión dar (1) clic derecho y ( 2 ) s e l e c c i o n a r NuevaConexión OLE DB

Seleccionar la conexión ventasStage y darle aceptar

Analisis de tablas (ventasStage)

Productos (STG_Producto)

Como se puede observar, en la tabla de productos, aparecen algunas tuplas con valores nulos
en las columnas de color, subcategoría y modelo.

La tarea a realizar consistirá en cambiar el valor nulo de color por ‘Sin color’, subcategoriaID a
0 y modeloID también a 0, sin embargo como subcategoriaID se relaciona con la tabla
STG_Subcategoria y modeloID con STG_modelo, insertaremos previamente las siguientes
tuplas:

Tablas Tupla
STG_Categoria 0,’Sin categoria’
STG_Subcategoria 0,’Sin Subcategoria’,0
STG_Modelo 0,’Sin modelo’

Tareas insertar categoría, subCategoria y modelo.

 De elementos de flujo de control arrastramos “Tarea ejecutar SQL” al diseñador y le

cambiamos el nombre a preparaCategoria.
Y la editamos para indicar la conexión (a ventasStage) y la instrucción de SQL a ejecutar

Repetir los pasos para subCategoria y modelo con las siguientes operaciones de
inserción:

Tabla Operacion
subcategoria insert into STG_Subcategoria
values(0,'Sin Subcategoria',0);
modelo insert into STG_modelo
values(0,'Sin modelo');

Quedando como sigue:

Tarea preparaProducto

Arrastramos la tarea Ejecutar SQL, le cambiamos el nombre a preparaProducto y la

ligamos con preparaSubCategoria y preparaModelo.

Y le cambiamos las siguientes propiedades:

Propiedad Valor
Name preparaProducto
Description Elimina valores nulos de producto
ConnectionType OLE DB
Connection VentasStage
SQL Statement update STG_Producto
set color = 'Sin Color'
where color is null;

update STG_Producto
set subcategoriaID = 0
where subcategoriaID is null;

update STG_Producto
set modeloID = 0
where modeloID is null;

Ya se pueden cambiar los valores nulos por ceros en categorías, subcategorías y

modelos sin violar la segunda regla de integridad.
Crear una tarea para incluir las ventas por Internet

La compañía maneja ventas por internet y el sitio de comercio electrónico para identificarlas
deja la columna VendedorID de la tabla de órdenes con un valor nulo, como se puede
observar.

Ordenes (STG_Ordenes)

La tarea a realizar consistirá en cambiar el valor nulo por un 0 (cero) e insertar en la tabla de
vendedores este valor con el nombre de ‘ventas por internet’ para complementar la
información.

 De elementos de flujo de control arrastramos “Tarea ejecutar SQL” al diseñador.

 Cambiar el nombre de la tarea a incluye ventas por internet.

 Dar doble clic sobre la tarea o Clic derecho/editar y Configurar las siguientes
propiedades:

Propiedad Valor
Name incluye ventas por internet
Description incluye ventas por internet
ConnectionType OLE DB
Connection Localhost.VentasStage
SQL Statement insert into STG_vendedor
values(0,'Ventas por internet');

update STG_Orden
set vendedorID = 0

where vendedorID is null;

Resolver las referencias (llaves foráneas) utilizando las llaves seriales
definidas

Ya que las referencias (llaves foráneas) que se utilizaran para el Data Warehouse serán las
llaves seriales definidas en la base de datos intermedia (VentasStage), el siguiente paso,
antes de la carga del DWH será el resolver esas referencias, por ejemplo: en la tabla
STG_producto a la columna SKProductoID se le dieron automáticamente los valores al
momento de insertar las tuplas en la tabla, sin embargo falta asignarle valor a los columnas
SKCategoriaID, SKSubCategoriaID y SKModeloID, se acuerdo con los valores que se
asignaron al momento de cargar las tablas respectivas.

Para la base de datos VentasStage, será necesario actualizar los seriales (subrogados) de las
tablas:
Tabla STG_Producto:
SKCategoriaID
SKSubCategoriaID
SKModelo

Tabla STG_DetalleOrden:
SKProductoID
Tabla STG_Orden:
SKClienteID
SKVendedorID
SKTerritorioID

Por lo que es más conveniente crear un procedimiento almacenado en la base de datos

ventasStage, al cual le llamaremos seriales y actualizara estas tablas.

Créate procedure seriales

As
Begin

update stg_producto
set SKsubcategoriaID = (select SKsubcategoriaID
from STG_subcategoria
where stg_producto.subcategoriaID =STG_subcategoria.subcategoriaID),
SKcategoriaID = (select SKcategoriaID
from STG_categoria
where categoriaID in (select categoriaID
from STG_subcategoria
where stg_producto.subcategoriaID =
STG_subcategoria.subcategoriaID))
where SKsubcategoriaID is null

update stg_producto
set SKmodeloID = (select SKmodeloID
from STG_modelo
where stg_producto.modeloID = STG_modelo.modeloID)
where SKmodeloID is null

update STG_Orden
set SKclienteID = (select SKclienteID
from STG_cliente
where stg_orden.clienteID = STG_cliente.clienteID)
where SKclienteID is null;

update STG_Orden
set SKvendedorID = (select SKvendedorID
from STG_vendedor
where stg_orden.vendedorID = STG_vendedor.vendedorID)
where SKvendedorID is null;
update STG_Orden
set SKterritorioID = (select SKterritorioID
from STG_territorio
where stg_orden.territorioID = STG_territorio.territorioID)
where SKterritorioID is null;

update STG_DetalleOrden
set SKproductoid = (select SKproductoid
from STG_producto
where stg_DetalleOrden.productoid = STG_producto.productoid)
where SKproductoid is null;
end;

 Para crear la tarea, de los elementos de flujo de control arrastramos “Tarea ejecutar
SQL” al diseñador y le cambiamos el nombre a prepara seriales

 Dar doble clic sobre la tarea o Clic derecho/editar y Configurar las siguientes
propiedades, de tal forma que se ejecute el procedimiento almacenado (seriales):

Propiedad Valor
Name Prepara seriales
Description Prepara seriales
ConnectionType OLE DB
Connection VentasStage
SQL statement Exec seriales
Paquete transformarVentas
5. CREACIÓN DEL PROYECTO (CargarVentas) PARA CARGAR
EL DATA WAREHOUSE (VENTASDWH) CON LAS
INFORMACIÓN DE LA BASE DE DATOS DE TRABAJO
(VENTASSTAGE).

ESTRUCTURA DEL MODELO VENTASSTAGE (B.D. de TRABAJO)

STG_subcategoria STG_categoria STG_cliente

subcategoriaID categoriaID clienteID
nombre nombre nombre
categoriaID SKcategoriaID SKclienteID
SKsubcategoriaID

STG_producto STG_DetalleOrden STG_Orden

productoID OrdenID ordenID
fechas
nombre OrdenDetalleID fecha
fecha
NoProducto productoid clienteID
año
color cantidad vendedorID
mes
costo preciounitario territorioID
mesD
precio total subtotal
dia
subcategoriaID SKVenta impuesto
semana
modeloID SKproductoid total
cuatrimestre
SKproductoID SKclienteID
SKfecha
SKcategoriaID SKvendedorID
SKsubcategoriaID SKterritorioID
SKmodeloID

STG_territorio
territorioID
STG_vendedor
nombre
STG_modelo vendedorID
modeloID codigoPais
nombre
nombre Grupo
SKvendedorID
SKmodeloID SKterritorioID
 ESTRUCTURA DEL MODELO VENTASDWH (MULTIDIMENSIONAL)

DIM_producto DIM_categoria
SKproductoID SKcategoriaID
productoID categoriaID
nombre nombre
color

FACT_Ventas
DIM_modelo
SKVenta DIM_subcategoria
SKmodeloID ordenID SKsubcategoriaID

modeloID detalleid subcategoriaID

nombre cantidad nombre

costounitario
preciounitario
total
DIM_fecha
SKfecha SKfecha
DIM_territorio
SKproductoid fecha
SKterritorioID
SKcategoriaID año
territorioID
SKsubcategoriaID mes
nombre
SKmodeloID mesD
codigoPais
SKclienteID dia
Grupo
SKvendedorID semana
SKterritorioID cuatrimestre

DIM_vendedor DIM_cliente
SKvendedorID SKclienteID
vendedorID clienteID
nombre nombre

CREAR LA VISTA VENTAS (opcional)

La tabla de Hechos (Fact_Ventas) contiene información de 3 tablas de la base de datos

intermedia (STG_ORDEN, STG_DETALLEORDEN Y STG_PRODUCTO), por lo que para
facilitar la carga de esta tabla es conveniente crear una vista que reúna esta información, a
esta vista le llamaremos ventas.

STG_producto STG_Orden
productoID ordenID
STG_DetalleOrden fecha
nombre
OrdenID
NoProducto clienteID
OrdenDetalleID
color vendedorID
productoid
costo territorioID
cantidad subtotal
precio
preciounitario impuesto
subcategoriaID
total total
modeloID
SKVenta SKclienteID
SKproductoID
SKproductoid SKvendedorID
SKcategoriaID
SKsubcategoriaID SKterritorioID

SKmodeloID SKfecha
Cree la vista ventas con la siguiente definición:

use VentasStage;

create view ventas(SKVenta,ordenID,detalleid,cantidad,costounitario,preciounitario,

total,SKfecha,SKproductoid,SKcategoriaID,SKsubcategoriaID,
SKmodeloID,SKclienteID,SKvendedorID,SKterritorioID)
as
select do.SKVenta,do.ordenID,do.OrdenDetalleID,do.cantidad,p.costo,do.preciounitario,
do.total,o.SKfecha,do.SKproductoid,p.SKcategoriaID,p.SKsubcategoriaID,
p.SKmodeloID,o.SKclienteID,o.SKvendedorID,o.SKterritorioID
from STG_Orden o inner join STG_DetalleOrden do on o.ordenID = do.OrdenID
inner join STG_producto p on p.productoID = do.productoid

La cual nos producirá la siguiente información, note que es la misma estructura que la tabla
FACT_Ventas):

Para esto ingrese a Microsoft SQL Server Managment Studio y cree la vista como sigue:
CREACIÓN DEL PROYECTO (cargarVentas)

Ingresar a SQL Server Business Intelligence Development Studio y crear un

nuevo proyecto de SQL Server Integration Services y nombrarlo CargarVentas.

A. Definir Origen de datos

Lo primero que tenemos que hacer es conectarnos a la base de datos VentasStage

que es la fuente de la cual vamos a extraer los datos. Para ello debemos generar
una conexión hacia ese origen. C o n los siguientes pasos:

 En el área de administradores de conexión dar clic derecho y s e l e c c i o n a r

NuevaConexión OLE DB
  Seleccionar la conexión ventasStage y darle aceptar

B. Definir Destino de datos

Generamos la conexión a VentasDWH (destino de los datos), con los siguientes pasos:

 En el área de administradores de conexión dar clic derecho y s e l e c c i o n a r

NuevaConexión OLE DB
 Seleccionar nueva.

 Indicar el proveedor, nombre del servidor, autentificación de Windows, la base de

datos (ventasDWH) y darle probar conexión y finalmente Aceptar.
  Seleccionar la conexión ventasDWH y darle Aceptar.

 Deben aparecer ambas conexiones.

Diseño del Paquete SSIS

Para cargar en el Data Warehouse (VentasDWH) la información de la base de datos de

trabajo (VentasStage), solo se deben definir tareas de flujo de datos con origen en
ventasStage y destino en VentasDWH, solo hay que cuidar que el orden de llenado de
las tablas considere la 2da regla de integridad.

Crear todas las actividades de flujo de datos, para la carga de todas las tablas de dimensión.
Actividad Cargar Hechos Ventas

Se crea una tarea de Flujo de datos y le cambiamos el nombre por Carga Hechos Ventas,
de damos doble clic para entrar al editor y arrastramos un Origen de datos de Ole DB, al
que le ponemos lee Ventas.

 Dar doble clic sobre la tarea o Clic derecho/editar

Si se creó la vista Ventas como se indica al inicio de esta sección, simplemente en el

editor de Origen de datos indicamos la base de datos (VentasStage), el modo de
acceso a datos la opción de Tabla o vista y en el nombre seleccionamos la vista
Ventas, como sigue:

 Presionar aceptar
En caso de que no se quiera usar la vista, en el editor de Origen de datos indicamos
la base de datos (VentasStage), el modo de acceso a datos la opción de Comando
SQL y en el Texto de comando SQL la siguiente proposición select:

select do.SKVenta,do.ordenID,do.OrdenDetalleID,do.cantidad,p.costo,do.preciounitario,
do.total,o.SKfecha,do.SKproductoid,p.SKcategoriaID,p.SKsubcategoriaID,
p.SKmodeloID,o.SKclienteID,o.SKvendedorID,o.SKterritorioID
from STG_Orden o inner join STG_DetalleOrden do on o.ordenID = do.OrdenID
inner join STG_producto p on p.productoID = do.productoid

Y quedaría como sigue:

 damos Clic en Aceptar.

 Y creamos el destino de datos correspondiente

 Indicamos la tabla Fact_ventas de la base de datos ventasDWH.

 Verificamos la asignación de los atributos.

 Presionamos el botón aceptar.

 El paquete queda como sigue:

Paquete CargarVentas