DISEÑO DE UNA GUÍA GENERAL PARA CONSTRUIR UNA BODEGA DE DATOS DEL

ÁREA DE VENTAS DE UNA EMPRESA.

DANIEL ERNESTO ROLDAN PINZON

066061104

UNIVERSIDAD LIBRE
FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
BOGOTA D.C.
2015
DISEÑO DE UNA GUÍA GENERAL PARA CONSTRUIR UNA BODEGA DE DATOS DEL
ÁREA DE VENTAS DE UNA EMPRESA.

DANIEL ERNESTO ROLDAN PINZON

066061104

Monografía del diplomado de Oracle para obtener el título de Ingeniero de Sistemas

Director
Néstor Espitia

UNIVERSIDAD LIBRE
FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
BOGOTA D.C.
2015
 CONTENIDO
1. GENERALIDADES .................................................................................................................. 4
1.1. FORMULACION DEL PROBLEMA .............................................................................. 4
1.2. JUSTIFICACION .............................................................................................................. 4
1.3. OBJETIVOS ...................................................................................................................... 4
1.3.1. Objetivos específicos ................................................................................................ 5
1.4. INTRODUCCION .............................................................................................................. 4
2. MARCO TEORICO .................................................................................................................. 6
2.1. ¿QUE ES UNA BODEGA DE DATOS? ....................................................................... 6
2.2. MODELADO DIMENSIONAL ........................................................................................ 7
2.3. MODELO MULTIDIMENSIONAL .................................................................................. 8
2.4. OLTP (On-Line Transactional Processing) .............................................................. 8
2.5. OLAP .................................................................................................................................. 8
2.6. CUBOS MULTIDIMENSIONALES ................................................................................ 9
3. METODOLOGIA........................................................................ ¡Error! Marcador no definido.
4. DESARROLLO GUIA ............................................................................................................ 11
HERRAMIENTAS DE HARDWARE ....................................................................................... 11
HERRAMIENTAS DE SOFTWARE ........................................................................................ 11
4.1. PLANIFICACIÓN DEL PROYECTO ........................................................................... 12
4.2. DEFINICIÓN DE REQUERIMIENTOS DEL NEGOCIO ........................................... 13
4.3. MODELADO DIMENSIONAL ...................................................................................... 14
4.4. DISEÑO FÍSICO ............................................................................................................. 15
4.5. DISEÑO E IMPLEMENTACIÓN DEL SUBSISTEMA DE EXTRACCIÓN,
TRANSFORMACIÓN Y CARGA (ETL) .................................................................................. 17
4.6. IMPLEMENTACIÓN ...................................................................................................... 22
4.7. MANTENIMIENTO Y CRECIMIENTO DE LA BODEGA DE DATOS ................... 23
4.8. DISEÑO DE LA ARQUITECTURA TÉCNICA........................................................... 23
5. CONCLUSIONES................................................................................................................... 25
 1. GENERALIDADES

1.1. INTRODUCCION

Como parte del proceso de crecimiento de una empresa con infraestructura

informática y manejando un gran volumen de datos, las empresas encuentran la
necesidad de consolidar sus datos y encuentran el desafío de construir su propia
bodega de datos, consolidar los datos desde diferentes fuentes en un solo repositorio.
Las bodegas de datos como fuente de los cubos multidimensionales que son usados
para obtener la información necesaria que puede ser consultada y analizada para la
toma de decisiones del negocio.
La implementación de una bodega de datos puede llegar a ser compleja para las
empresas con escasa experiencia en manejo de datos, es decir sus bases de datos
están dispersas y solo son consultadas para realizar tareas básicas como inventarios.
Ese es el porqué de esta guía para ayudar a aquellas empresas que van a iniciar o
desean implementar una bodega de datos y necesitan saber qué pasos seguir con los
menos errores y problemas posibles además de poder implementar la bodega de
datos de manera satisfactoria.

1.2. FORMULACION DEL PROBLEMA

¿Cómo ayudar de forma clara a desarrollar una bodega de datos para el área de
ventas de una empresa en general?

1.3. JUSTIFICACION

La importancia de contar con una guía general de implementación de una bodega de

datos, radica en los tiempos de implementación del modelo y en los estándares de
documentación que se generan como proceso para la construcción de los cubos
multidimensionales que aporten valor agregado a la empresa.

1.4. OBJETIVOS

Diseñar una guía general para la implementación de un Bodega de datos para el área
de ventas de una empresa.

4
1.4.1. Objetivos específicos

 Llevar a cabo el levantamiento y análisis de las diferentes fuentes de datos

de un área de ventas.
 Integrar los componentes elementales involucrados en la solución.
 Identificar las herramientas para generar los cubos multidimensionales.

5
 2. MARCO TEORICO

2.1. ¿QUE ES UNA BODEGA DE DATOS?

Una bodega de datos es una herramienta empresarial utilizada como una solución
informática que consolida los datos de diferentes fuentes de una entidad, institución o
negocio ya sean de bases de datos, archivos planos o de otros sistemas del negocio,
extrayéndolos, transformarlos en el caso de ser necesario y almacenarlos en un solo
repositorio. El objetivo de la bodega de datos es soportar la toma de decisiones en un
negocio y centralizar los datos, interpretarlos y darle un valor agregado para beneficio
del negocio, ofreciendo un fácil acceso y visualización para su análisis por parte de los
usuarios. La bodega de datos es un almacén de los datos que han sido extraídos y
transformados, y están separados físicamente del origen donde provienen los datos.
Una bodega de datos es una copia de los datos de las bases de operaciones del
negocio que está estructurado específicamente para la consulta y el análisis.
Las bodegas de datos pueden estar integrados por Datamarts, que es son
subconjuntos de datos específicos de una dependencia del negocio. Los Datamarts
deben ser consistentes en la representación de los datos para asegurar robustez.
Figura 1. Arquitectura de una bodega de datos

Archivos
planos
Cubos

Base de Data
TRANSFORMACION

Mart
Datos 1
EXTRACCION

CONSULTA

BODEGA DE Reporte
DATOS Data s
Base de Mart

Datos 2
Soluciones
Data
WEB
Mart
Otra
fuente

La arquitectura de la bodega de datos se basa en aplicar un proceso de extracción,

transformación y carga más conocido como proceso ETL (Extract, Tranform and
Load), por medio de este proceso se cargan los datos en una bodega de datos por
medio de las siguientes operaciones:

 Extracción: Obtener los datos necesarios que están almacenados desde

diferentes fuentes externas a la bodega de datos.

6
  Transformación: Cualquier tarea realizada para limpiar o transformar los
datos para que se puedan cargar en la bodega. Los datos al ser extraídos
desde diferentes fuentes, pueden tener diferentes formatos y ser poco
integrales.
 Carga: Es el almacenamiento de los datos en la bodega de datos.

Las bodegas de datos pueden ser consultadas por medias herramientas de consulta y
análisis como los cubos multidimensionales, reportes, soluciones web.
Las bodegas de datos deben cumplir con estas características:

 Utiliza solo los datos necesarios: no se extraen de las fuentes los datos que
no se puedan analizar o sean requeridos.
 Integrado: Los datos deben ser consistentes, en formato, atributos. En el
caso de que los datos no sean consistentes, se deben transformar los
datos para cumplir esta característica.
 Historia: la información en la bodega debe incluir datos históricos para
poderse usar en la identificación y análisis de tendencias.
 Los datos no se eliminan o modifican, solo se deben hacer dos
operaciones únicas en la bodega: la carga de los datos y su consulta.

2.2. MODELADO DIMENSIONAL

El modelado dimensional es un diseño lógico que presenta la información de una
manera estándar, sencilla y sobre todo intuitiva para los usuarios del negocio. El
modelo dimensional está conformado por una tabla de hechos (Fact) y tablas de
dimensión.
En esta guía se va a usar el modelo de estrella tiene una tabla de hechos con varias
llaves foráneas que se relacionan con cada una de las llaves primarias de las tablas
de dimensión.
Figura 2. Modelado Estrella

CLIENTE PRODUCTO

IdCliente VENTAS
IdProducto
Nombre
VentIdCliente Nombre
Telefono
VentIdProduct Descripcion
Direccion o

Cantidad
Tabla de dimensión Tabla de dimensión
Tabla de hechos

7
 La tabla de dimensión contiene atributos que determinan los parámetros de lo que
dependen las medidas en la tabla de hechos.
La tabla de hechos contiene las medidas de negocio mediante la intersección de
dimensiones, por lo general son numéricas y son usadas para el análisis. Un ejemplo
de medida es la cantidad de productos vendidos a un cliente1.
2.3. MODELO MULTIDIMENSIONAL

Este modelo está diseñado para permitir el almacenamiento y la recuperación eficiente

de grandes volúmenes de datos relacionados, vistos y analizados desde diferentes
perspectivas (dimensiones). Ofrece una mejor comprensión de los datos y proporciona
un mejor rendimiento para consultas complejas de análisis. Es una matriz de n-
dimensiones. En el modelo se representa el hecho que es objeto de análisis y las
dimensiones que caracterizan la actividad y la información relevante sobre el hecho se
representa por un conjunto de medidas. Las bodegas de datos se basan en un modelo
multidimensional.

2.4. OLTP (On-Line Transactional Processing)

Son bases de datos orientadas al procesamiento de transacciones. Una transacción

genera un proceso atómico y que puede involucrar operaciones de inserción,
modificación y borrado de datos. El proceso transaccional es típico de las bases de
datos operacionales. El acceso a los datos está optimizado para tareas frecuentes de
lectura y escritura por ejemplo, la enorme cantidad de transacciones que tienen que
soportar las bases de datos de bancos o hipermercados diariamente. Los datos se
estructuran según el nivel aplicación como programa de gestión a medida, ERP o
CRM implantado, sistema de información departamental. Los formatos de los datos no
son necesariamente uniformes en los diferentes departamentos es común la falta de
compatibilidad y la existencia de islas de datos. El historial de datos suele limitarse a
los datos actuales o recientes2.

2.5. OLAP

Son bases de datos orientadas al procesamiento analítico. Este análisis implica

generalmente la lectura de grandes cantidades de datos para llegar a extraer algún
tipo de información útil: tendencias de ventas, patrones de comportamiento de los
consumidores, elaboración de informes complejos… etc. Este sistema es típico de los
datamarts.

1
WREMBEL. Robert. CONCILIA, Christian, Data Ware- house and OLAP Concepts,
Architectures and Solutions. 2007
2
Bases de datos OLTP y OLAP http://www.sinnexus.com/business_intelligence/olap_vs_oltp.aspx

8
 El acceso a los datos suele ser de sólo lectura. La acción más común es la consulta.
Los datos se estructuran según las áreas de negocio, y los formatos de los datos
están integrados de manera uniforme en toda la organización.
El historial de datos es a largo plazo, normalmente de dos a cinco años.
Se suelen alimentar de información procedente de los sistemas operacionales
existentes, mediante un proceso de extracción, transformación y carga (ETL)3.

2.6. CUBOS MULTIDIMENSIONALES

Los cubos OLAP es un modelo multidimensional de datos, que simplifica y facilita a los
usuarios realizar consultas complejas, arreglar datos en un reporte, cambiar la vista de
datos de datos resumidos a datos detallados.

Los Cubos OLAP son vectores o pequeños almacenes de datos en los cuales se
dispone la información y permite un análisis rápido de los datos y convertirla en
información valiosa para la toma de decisiones.

Imagen 1. Cubo Multidimensional

3
Bases de datos OLTP y OLAP http://www.sinnexus.com/business_intelligence/olap_vs_oltp.aspx

9
 3. MARCO CONCEPTUAL

La Metodología que se va a utilizar para esta guía es la metodología Kimball, esta es

una metodología empleada para la construcción de bodegas de datos. La metodología
se basa en lo que Kimball denomina Ciclo de Vida Dimensional del Negocio. Este ciclo
de vida del proyecto de DWH, está basado en cuatro principios básicos:

 Centrarse en el negocio.
 Construir una infraestructura de información adecuada.
 Realizar entregas en incrementos significativos.
 Ofrecer la solución completa proporcionando los elementos necesarios
para entregar valor a los usuarios del negocio.

Imagen 2. Ciclo de vida Metodología de Kimball4

4
Kimball Lifecycle methodology diagram. Kimball Group

10
 4. DESARROLLO DEL PROYECTO

Antes de iniciar la guía, se debe tener en cuenta que la guía es general y en algunas
empresas presentar requerimientos, procesos o acciones que se deben tener en
cuenta y adicionar.
Para la construcción de una bodega de datos debemos cumplir unos requisitos
respecto a las herramientas de software y hardware que usaremos para el desarrollo
de la guía:
HERRAMIENTAS DE HARDWARE
La herramienta de hardware que se requiere es un servidor para el almacenamiento y
manejo de la base de datos corporativa; se recomienda que este servidor sea
altamente escalable, puede que algunas veces el proyecto de construcción de la
bodega presente algún redimensionamiento a medida que se avanza en la
implementación. La capacidad inicial de almacenamiento estará determinada por los
requerimientos de información histórica presentados por la empresa y por la
perspectiva de crecimiento que se tenga.

HERRAMIENTAS DE SOFTWARE
Las herramientas de software que necesitamos para la construcción de la bodega de
datos se clasifican en cuatro categorías básicas:
Herramientas de Almacenamiento: corresponde a las herramientas en la cual se
irán a almacenar los datos. Existen muchas opciones dependiendo del volumen de los
datos, presupuesto y capacidad del sistema. Cada uno de los sistemas de
administración de bases de datos, como Oracle, DB2, Informix, TeraData, Sybase,
Microsoft.
Herramientas de Extracción y Colección: Ayudan a realizar el proceso de
extracción, transformación y carga de los datos de los sistemas transaccionales de la
empresa a la bodega de datos. Algunas de estas herramientas son:

 Informatica - Power Center

 SAP – Business Objects Data Integrator
 IBM - Cognos Data Manager
 Microsoft - SQL Server Integration Services
 Oracle - Data Integrator
 SAS - Data Integration Studio

La mayoría de esas herramientas son utilizadas por el personal interno de la

compañía dado el gran conocimiento que tienen de los sistemas transaccionales.

Herramientas para Elaboración de Reportes: Son las herramientas que construyen

la interface vista por el usuario final. Al usuario se le debe proveer un mecanismo para
que vea los datos a un alto nivel y que obtenga con ellos la solución a preguntas
específicas del negocio. Existen muchas herramientas orientadas a reportes como:

11
Cognos Powerplay, Business Objects, SAS Enterprice, etc. En esta guía no vamos a
profundizar en estas herramientas.
Herramientas para Construcción de cubos Multidimensionales: Son las
herramientas donde se establecen las dimensiones y medidas que van a ser usadas
en el cubo y se genera el cubo para la consulta. Algunas de las herramientas
orientadas a la construcción de cubos multidimensionales son: Cognos Powerplay
Transformer, Microsoft Analysis Service, Orale Analytic Workspace Manager 11g.
Para tener en cuenta: Independiente del software que se va a utilizar para desarrollar
la bodega de datos y del enfoque de esta guía, se deben tener en cuenta que es
necesario crear 3 ambientes; desarrollo, prueba y producción. Se debe estipular un
manual de cómo se van a pasar los futuros desarrollos a el ambiente de producción,
responsables de los ambientes, los formatos para especificar los objetos desarrollados
y pasos a seguir en el paso a producción. Es recomendable ser estrictos con estos
ambientes y su uso correcto, para así mantener el ambiente de producción (cara a los
usuarios finales) limpio y solo con los desarrollos ya aprobados y funcionando de
manera correcta.

4.1. PLANIFICACIÓN DEL PROYECTO

Siguiendo con la guía y aplicando la metodología de Kimball iniciamos con
Planificación del Proyecto donde determinamos la construcción de la bodega de datos
del área de ventas. Se deben determinar unas acciones para la planificación del
proyecto:

 El alcance, en nuestro caso nuestro alcance es el área de ventas de una

empresa, la construcción de la bodega de datos y el diseño de los cubos
multidimensionales.
 Identificar las tareas que se van a desarrollar en la construcción de la
bodega de datos. Las tareas que identificamos en la guía son:
- Especificar de manera clara y precisa de las funciones que se esperan
obtener de la bodega de datos.
- Definir el modelo lógico de datos para la bodega de datos.
- Definir los procedimientos de conexión con las fuentes de datos y a la
bodega de datos.
- Determinar el formato de los datos que se almacenaran en la bodega
de datos.
- Definir los modelos físicos obtenidos de los modelos lógicos.
- Generar los diseños para programas y procesos que se requieran para
el área de ventas a nivel de datos como de aplicación.
- Diseño de la bodega de datos.
- Construir los programas que realicen el proceso de ETL para alimentar
la bodega.
- Montaje de la bodega de datos, instalación, puesta en marcha y
utilización de la bodega de datos.
- Definir las herramientas de acceso del usuario final.

12
 - Diseñar los cubos multidimensionales.
- Generar los cubos multidimensionales.
 Programar las tareas para limitar el tiempo de la implementación y poder
hacer un seguimiento del estado de la construcción de la bodega.
 Planificar los tiempos de los recursos que se usaran para desarrollar las
tareas que se identificaron, crear un cronograma con los tiempos para
hacer seguimiento de la construcción de la bodega y ayudando a tener un
estado de la construcción para identificar si se están cumpliendo con los
tiempos establecidos. Se deben evitar tiempos muertos de los recursos, en
el caso de ser necesario cuando ya se inició la construcción de la bodega y
se presenta un inconveniente, se debe identificar tareas adicionales que
puedan impactar en el desarrollo, adicionarlo al cronograma con su
respectivo tiempo.
 Asignar la carga de trabajo a los recursos apoyándose en los tiempos
identificados en el punto anterior.
 Elaboración de un documento final que representa un plan del proyecto,
donde se incluyen los puntos anteriores, este documento debe ser muy
específico para que el equipo que va a construir la bodega de datos tenga
el mismo enfoque, conocimiento de las tareas, tiempos para cada tarea y
se eviten malinterpretaciones que se pueda ver reflejado en una mala
implementación y/o tareas que tomen más tiempo de lo planeado.

Se debe definir cómo se va a realizar la administración con las siguientes actividades:

• Monitoreo del estado de las tareas y su desarrollo dentro de los tiempos
establecidos.
• Rastreo e identificación de problemas.
• Definir un canal de comunicación entre la empresa y las áreas de TI ayudando a
una fácil comunicación y apoyo cooperativo.

4.2. DEFINICIÓN DE REQUERIMIENTOS DEL NEGOCIO

Continuando con la guía vamos a definir unos requerimientos generales para un área
de ventas de una empresa5:
 La bodega de datos permitirá la integración de distintas fuentes de datos.
 Definir el área de ventas en procesos que sean medibles.
 Tener una sola versión de la información.
 Proveer la información del área de ventas de la empresa en una sola
bodega de datos.
 La bodega debe usar nombres estandarizados para que la posterior
generación de reportes sea de manera intuitiva.

5
Business Intelligence Business Requirements and the BI Portfolio - Steve Williams
http://www.b-eye-network.com/view/index.php?cid=6887

13
  Permitir la consulta de la información por medio de cubos
multidimensionales para el uso de los usuarios finales.
 Identificar la información necesaria para el área de ventas.

Algunas empresas pueden necesitar más requerimientos, si es así, se deben

identificar todos los informes posibles del área de ventas; rastrear los documentos de
estrategia interna; realizar entrevistas a los encargados del área (ejecutivos,
directivos, técnicos) y se deben conocer los términos y la terminología del negocio
para identificar los requerimientos específicos de la empresa.

4.3. MODELADO DIMENSIONAL

Nuestro proceso del negocio es el área de ventas y este procesos es el que vamos a
modelar. Vamos a usar el siguiente modelado:

Figura 3. Modelo Multidimensional Ventas

Se recuerda que se debe verificar que el modelo es a un área de ventas en general,

puede que se necesite adicionar algunas dimensiones dependiendo de cómo se
encuentre definido en la empresa.

Puede que sea necesario crear dimensiones que guarden la historia por ejemplo como
el cambio de dirección o de cargo en la DIMENSION_EMPLEADO o la
DIMENSION_CLIENTE, estas dimensiones que es necesario que guarden historia son
llamadas dimensiones de tipo 2. Las dimensiones que no es requerido que guarden
historia son llamadas dimensiones de tipo 1. Las dimensiones de tipo 2 necesitan un

14
campo adicional en la tabla para poder identificar cual es el registro actual en caso de
llevar una historia.

Importante: cuando se carguen las dimensiones en la bodega de producción, estas no

deben ser truncadas o borradas, se recomienda actualizar los campos diferentes a la
llave subrogada de la dimensión o hacer inserción de nuevos registros en la
dimensión. En caso de truncar o borrar alguna dimensión y de que ya se tenga
cargada alguna tabla de hechos, se debe hacer una carga inicial (truncar y volver a
poblar la tabla) de la dimensión y la(s) tabla(s) de hechos, esto porque las llaves de la
tabla de hechos asociadas a las dimensiones pueden ser incorrectos.

4.4. DISEÑO FÍSICO

En base a nuestro modelo multidimensional vamos a generar un modelo físico, con los
nombres de las tablas, campos y tipo de dato:

Figura 4. Modelo Físico Ventas

Como en el punto anterior, si fue necesario adicionar más dimensiones, se deben

adicionar al modelo físico (tablas, campos y tipo de dato).

Se debe contar con un servidor con mínimo estas características de hardware:

Requerimientos Requerimientos Requerimientos

mínimos para mínimos para recomendados para
desarrollo y producción producción

15
 pruebas*
Arquitectura** 32bits 64bits 64bits
Procesador 2 núcleos, con 4 núcleos, con 4 núcleos, con
velocidad de 2,0 GHz velocidad de 2,5 GHz velocidad de 2,5 GHz
mínimo mínimo (con Socket libre para
un segundo
procesador
Memoria 8BG 16GB 32GB
Espacio en disco*** 2GB para instalación 2GB para instalación 2GB para instalación
5GB para 5GB para 5GB para
configuraciones y configuraciones y configuraciones y
logs logs logs

*Los requerimientos para desarrollo y pruebas pueden ser distintos a los de

producción si las herramientas de software que se van a usar lo permiten, el servidor
enfocaría los recursos solo en los nuevos desarrollos mientras pasan al ambiente de
producción.

**La arquitectura para desarrollo y pruebas pueden ser distintos a los de producción si
las herramientas de software que se van a usar lo permiten, en el caso de ser
requerido, el servidor de pruebas debe tener la misma arquitectura que el servidor de
producción para poder evaluar de manera precisa el rendimiento de los desarrollos
que se van a pasar a producción.

***El espacio de disco puede variar dependiendo de las herramientas que van a
utilizar tanto como para almacenamiento de datos, como para la construcción de la
bodega de datos.

Se debe tener en cuenta que el servidor se pueda conectar a las distintas fuentes de
datos que van a alimentar la bodega de datos.

El sistema operativo debe ser compatible con la herramienta de almacenamiento y las

herramientas de construcción de la bodega de datos.

Para la instalación del software que se va a usar para desarrollar la bodega de datos
se debe tener la documentación para evitar errores y tiempos adicionales en el
desarrollo.

Se debe tener en cuenta los factores de uso de la bodega de datos a corto y largo
plazo para identificar cuando es necesario una configuración más grande y más
compleja de la bodega.

El equipo que va a desarrollar la bodega de datos debe tener acceso a las distintas
fuentes de datos y tener instalado el software que se va a utilizar para el procesos de
ETL. Aunque este fuera de esta guía, el equipo que va a hacer reporting (BI) debe
contar con el software correspondiente para realizar reportes y los accesos a la
bodega de datos cuando ya esté desarrollada.

16
Se recomienda que las tablas de hechos en la base de datos deben estar
particionadas por mes, esto con el fin de optimizar las consultas que se le realicen a
las tablas, que al paso del tiempo van adquiriendo volumen.

¿Cuáles son los factores de uso que llevarán a una configuración más grande y más
compleja?

4.5. DISEÑO E IMPLEMENTACIÓN DEL SUBSISTEMA DE EXTRACCIÓN,

TRANSFORMACIÓN Y CARGA (ETL)

Antes de iniciar, se debe tener en cuenta que desarrollo de la bodega de datos se

debe realizar en el ambiente de desarrollo, como es el inicio de una bodega de datos
puede que se tengan que realizar ajustes o adiciones, la idea es cuando se tenga la
bodega de datos lista y funcionando, poder realizar un paso al ambiente de producción
con la primera versión aprobada de la bodega de datos.

En esta parte de la guía vamos a enfocarnos en el subsistema de Extracción,

Transformación y Carga (ETL) que es la base sobre la cual se alimenta la bodega de
datos. Vamos a diseñar un ETL básico teniendo en cuenta que tendremos distintas
fuentes de datos, con distintos tipo de datos:

Figura 5. Diseño ETL Ventas

Archivos planos xls

Clientes
EXTRACCION TRANSFORMACION CARGA
Productos

Base de datos Conexión

nativa
Recursos Humanos ASCII/OLEDB - Limpieza de
Oracle datos Entrega de
- Estandarizar datos a las
Empleados. Conexión Staging datos respectivas BODEGA DE
nativa SQL Area - Crear datos tablas en la DATOS
Base de datos calculados bodega de
datos
Área Ventas
Oracle Conexión
nativa SQL
Recibos
Sucursales
Clientes
Productos

17
 Dependiendo de la herramienta ETL que se vaya a utilizar se debe crear las
conexiones a las distintas fuentes de los datos, como en nuestro caso a los archivos
planos, a la base de datos de recursos humanos con la información de los empleados
y a la base datos del área de ventas. Se debe tener en cuenta que los orígenes de
datos no pueden ser los mismos que los que necesite su empresa y se debería ajustar
a sus necesidad.

Los campos que se van a extraer de cada fuente son:

Archivos planos Cliente Archivos planos Productos Tabla Empleados Tabla Sucursal
Id Cliente Id Producto Id Empleado Nombre Sucursal
Nombres Cliente Nombre Producto Nombres Empleado País Sucursal
Apellidos Cliente Descripción Producto Apellidos Empleado Región Sucursal
Departamento
Sexo Cliente Marca Producto Sexo Empleado Sucursal
Dirección Cliente Dirección Empleado Ciudad Sucursal
Ciudad Cliente Ciudad Empleado Dirección Sucursal
Teléfono Cliente Teléfono Empleado
Correo Empleado
Cargo
Sucursal

Tabla Recibos Tabla Clientes Tabla Productos

Fecha Id Cliente Id Producto
Id Recibo Nombres Cliente Nombre Producto
Id Vendedor Apellidos Cliente Descripción Producto
Id Cliente Sexo Cliente Id Marca
Descripción Recibo Dirección Cliente Nombre Marca Producto
Id Producto Vendido Ciudad Cliente
Cantidad productos Teléfono Cliente
Valor Profesión Cliente
Correo Cliente

En las tablas DIM_CIUDAD, DIM_SEXO y DIM_PROFESION queda a libre elección

de como poblar los campos faltantes como Id y descripción.

En la herramienta de ETL se deben crear las fuentes de datos (DataSources) para

extraer los datos que se identificaron en el modelo físico. Los campos SK son la llave

18
de cada dimensión, se debe calcular de manera incremental, esta llave es
independiente del Id o llave que se usa en el modelo relacional.

Este es el diccionario de datos de las tablas que tenemos para la bodega que vamos a
desarrollar:

DIM_TIEMPO
Campo Tipo Dato Tamaño Descripción
Sk_Fecha INTEGER 8 Llave subrogada de la dimensión de tiempo
Anio INTEGER 4 Numero del año
Semestre INTEGER 1 Numero del semestre del año
Mes INTEGER 2 Numero del mes del año
Mombre_mes VARCHAR 10 Nombre del mes del año
Dia INTEGER 2 Numero del dia del mes
Nombre_dia VARCHAR 10 Nombre del dia del mes

DIM_CLIENTE
Campo Tipo Dato Tamaño Descripción
Sk_Cliente INTEGER 8 Llave subrogada de la dimensión cliente
Sk_Profesion INTEGER 10 Llave subrogada de la dimensión profesión
Sk_Sexo INTEGER 2 Llave subrogada de la dimensión sexo
Sk_Ciudad INTEGER 4 Llave subrogada de la dimensión ciudad
Id_Cliente INTEGER 15 Numero de identificación de cliente
Nombres VARCHAR 50 Nombres de cliente
Apellidos VARCHAR 50 Apellidos de cliente
Direccion VARCHAR 100 Dirección de residencia de cliente
Telefono INTEGER 20 Teléfono de cliente
Correo_e VARCHAR 50 Correo electrónico de cliente

DIM_PROFESION
Campo Tipo Dato Tamaño Descripción
Sk_Profesion INTEGER 8 Llave subrogada de la dimensión profesión
Id_Profesion INTEGER 8 Código de profesión
Nombre_profesion VARCHAR 50 Nombre de la profesión

DIM_SEXO
Campo Tipo Dato Tamaño Descripción
Sk_Sexo INTEGER 8 Llave subrogada de la dimensión de tiempo
Id_Sexo INTEGER 2 Código de sexo
Descripcion VARCHAR 20 Descripción de genero

19
 HECHOS_VENTAS
Tipo
Campo Dato Tamaño Descripción
Sk_Fecha INTEGER 8 Llave subrogada de la dimensión de tiempo
Sk_Sucursal INTEGER 8 Llave subrogada de la dimensión sucursal
Sk_Empleado INTEGER 8 Llave subrogada de la dimensión empleado
Sk_Producto INTEGER 8 Llave subrogada de la dimensión producto
Sk_Cliente INTEGER 8 Llave subrogada de la dimensión cliente
Sk_Recibo INTEGER 8 Llave subrogada de la dimensión recibo
Cantidad_vendida INTEGER 8 Numero de productos vendidos
Monto_venta FLOAT Valor total de los productos vendidos

DIM_SUCURSAL
Campo Tipo Dato Tamaño Descripción
Sk_Sucursal INTEGER 8 Llave subrogada de la dimensión de tiempo
Sk_Ciudad INTEGER 8 Llave subrogada de la dimensión ciudad
Nombre_sucursal VARCHAR 50 Nombre de la sucursal
Direccion VARCHAR 50 Dirección de la sucursal

DIM_CIUDAD
Campo Tipo Dato Tamaño Descripción
Sk_Ciudad INTEGER 8 Llave subrogada de la dimensión ciudad
Id_Ciudad INTEGER 4 Código de ciudad
Nombre_Ciudad VARCHAR 50 Nombre de la ciudad
Id_Departamento INTEGER 4 Código del departamento donde se ubica la ciudad
Nombre_Departamento VARCHAR 50 Nombre del departamento donde se ubica la ciudad
Id_Region INTEGER 4 Código de la región donde se ubica la ciudad
Nombre_Region VARCHAR 50 Nombre de la región donde se ubica la ciudad
Id_Pais INTEGER 4 Código del país donde se ubica la ciudad
Nombre_Pais VARCHAR 50 Nombre del país donde se ubica la ciudad

DIM_RECIBO
Campo Tipo Dato Tamaño Descripción
Sk_Recibo INTEGER 8 Llave subrogada de la dimensión de recibo
Id_Recibo INTEGER 6 Código de recibo
Descripcion VARCHAR 50 Descripción de recibo

DIM_PRODUCTO
Campo Tipo Dato Tamaño Descripción
Sk_Producto INTEGER 8 Llave subrogada de la dimensión de tiempo
Id_Producto INTEGER 6 Código del producto
Nombre VARCHAR 50 Nombre del producto

20
 Descripcion VARCHAR 50 Descripción del producto
Id_Marca INTEGER 6 Código de marca del producto
Nombre_Marca VARCHAR 50 Nombre de marca del producto

DIM_EMPLEADO
Campo Tipo Dato Tamaño Descripción
Sk_Empleado INTEGER 8 Llave subrogada de la dimensión de empleado
Sk_Cargo INTEGER 8 Llave subrogada de la dimensión de cargo
Sk_Sexo INTEGER 8 Llave subrogada de la dimensión de sexo
Sk_Ciudad INTEGER 8 Llave subrogada de la dimensión de ciudad
Id_Empleado INTEGER 8 Numero de identificación de empleado
Nombres VARCHAR 50 Nombres de empleado
Apellidos VARCHAR 50 Apellidos de empleado
Direccion VARCHAR 50 Dirección de residencia de empleado
Telefono INTEGER 20 Teléfono de empleado
Correo_e VARCHAR 50 Correo electrónico de empleado

DIM_CARGO
Campo Tipo Dato Tamaño Descripción
Sk_Cargo INTEGER 8 Llave subrogada de la dimensión de tiempo
Id_Cargo INTEGER 6 Código del cargo
Nombre_Cargo VARCHAR 50 Nombre del cargo

Se deben limpiar los datos eliminando caracteres especiales, datos nulos,

convirtiendo los datos de ser necesario y que los datos cumplan con tipo de dato
especificado en el modelo físico. De esta forma aseguramos la calidad de los datos
cuando provienen de distintas fuentes y se almacenan en un solo repositorio.

La tabla de tiempo se puede crear por medio de la herramienta de ETL que se utilice
fijando una fecha inicial y especificando que detalle de la fecha se requiere para poblar
otros campos de la tabla.

Durante el desarrollo de la bodega de datos es muy seguro requerir de una Staging

Area, esta es un área intermedia de almacenamiento de datos utilizada para el
procesamiento de los mismos durante procesos de ETL. En el caso de que una
extracción requiera más de una iteraciones y/o crear campos calculados a partir de
campos de diferentes fuentes.

Finalmente se cargan los datos en la bodega de datos en las tablas especificadas en

el modelo físico. Ya se puede contar los datos almacenados en un solo repositorio, de
calidad y consistentes.

21
 4.6. IMPLEMENTACIÓN
En esta parte se debe ver la convergencia entre la tecnología, los datos y las
aplicaciones de usuarios finales que serán accesibles desde el escritorio del usuario
del negocio. En esta guía nos enfocamos en los cubos multidimensionales que va a
ser nuestra aplicación de usuario final, se debe tener en cuenta que no se debe dejar
de lado el desarrollo de aplicaciones como reportes o dashboards.

Se debe tener una herramienta que cree los Metadatos de la bodega de datos. Los
metadatos son la capa que traduce la estructura física de los datos (con sus tablas,
campos y relaciones) en la terminología de negocio, que resulta familiar y conocida
por los usuarios de negocio6.

Contando que ya se cuentan con los metadatos ya podemos iniciar con la generación
de nuestros cubos multidimensionales. Debemos seleccionar el origen de datos que
son nuestras tablas de la bodega de datos. Los cubos que se van a generar son:

1- Un cubo que permita ver el valor de la venta por clientes, producto y sucursal por
mes.
Nuestra tabla de grupo de medidas es la tabla de hechos; FACT_VENTAS.
Nuestras medidas serán; Monto_venta.
Nuestras dimensiones son las tablas: DIM_CLIENTE, DIM_PRODUCTO,
DIM_SUCURSAL, DIM_CIUDAD, DIM_TIEMPO (con el campo mes), DIM_SEXO.

2- Un cubo que permita ver la cantidad de productos que se venden por sucursal por
mes.
Nuestra tabla de grupo de medidas es la tabla de hechos; FACT_VENTAS.
Nuestras medidas serán; Cantidad_vendida.
Nuestras dimensiones son las tablas: DIM_PRODUCTO, DIM_SUCURSAL,
DIM_CIUDAD, DIM_TIEMPO (con el campo mes).
3- Un cubo que permita ver el monto de ventas por sucursal y empleado, numero de
productos vendidos por empleado por mes.
Nuestra tabla de grupo de medidas es la tabla de hechos; FACT_VENTAS.
Nuestras medidas serán; Cantidad_vendida, Monto_venta.
Nuestras dimensiones son las tablas: DIM_PRODUCTO, DIM_CLIENTE,
DIM_EMPLEADO, DIM_CARGO, DIM_SUCURSAL, DIM_CIUDAD, DIM_TIEMPO
(con el campo mes).

4- Un cubo que permita ver la cantidad de productos que se venden por género y
profesión por mes.
Nuestra tabla de grupo de medidas es la tabla de hechos; FACT_VENTAS.
Nuestras medidas serán; Cantidad_vendida.

6
http://www.businessintelligence.info/productos/capa-semantica-business-intelligence.html

22
 Nuestras dimensiones son las tablas: DIM_PRODUCTO, DIM_CLIENTE,
DIM_SEXO, DIM_PROFESION, DIM_TIEMPO (con el campo mes).

Estos 4 cubos están diseñados para responder algunas de las preguntas que se
pueden crear a partir de la bodega de datos que tenemos diseñada. No se debe
olvidad que los cubos pueden variar dependiendo del negocio. Como se ha venido
recomendando, en el caso de que la bodega de datos se haya modificado, se debe
tener en cuenta que los cubos también deben ser modificados o ajustados.

Se deben capacitar a los usuarios finales sobre la visualización de estos cubos y su

correcto uso. Recordamos que la comunicación es esencial para enfocar la bodega de
datos y los reportes de usuario final, utilizar las estrategias de retroalimentación es
una buena práctica.

4.7. MANTENIMIENTO Y CRECIMIENTO DE LA BODEGA DE DATOS

Para administrar el entorno de la bodega de datos existente es importante enfocarse

en los usuarios de negocio que son el motivo de su existencia, además de gestionar
adecuadamente las operaciones de la bodega, medir y proyectar su éxito. Como ya se
mencionó antes la comunicación constante con los usuarios establece un flujo de
retroalimentación. Esto sería llamado el Mantenimiento.

Se deben sentar las bases para el crecimiento y evolución de la bodega de datos, este
aspecto es clave en donde se debe manejar de forma iterativa utilizando el ciclo de
vida expuesto en la imagen 2, donde se establecen oportunidades de crecimiento,
nuevos requerimientos, cambios a la estructura de los datos, cambios de orígenes de
datos.

4.8. DISEÑO DE LA ARQUITECTURA TÉCNICA

Esta es el área que cubre los procesos y herramientas utilizan en los datos. En el área
técnica se divide en dos conjuntos con distintos requerimientos, propios servicios y
componentes para el almacenamiento de datos. Estos son:

- Back Room: Es la parte responsable de la adquisición y preparación de

los datos. Aquí se incluye los procesos ETL desarrollados. Para crear la
arquitectura del Back Room es decisivo comprender la naturaleza de
las fuentes de datos y qué formas van a tomar estos datos.

23
 - Front Room: Es la parte responsable de la adquisición de los datos y
entrega a los usuarios, donde se tienen todos los reportes y cubos
desarrollados desde la bodega de datos.

Se debe tener en cuenta la seguridad que deben cumplir estas arquitecturas. En el

Back Room la seguridad no es estricta como en el Front Room, esto se debe a que el
Back Room se enfoca en el desarrollo de aplicaciones y obtención de datos, y es
suficiente utilizar las reglas de seguridad estándares. El Front Room requiere
seguridad para determinar quién puede acceder a la administración del servidor de la
bodega de datos. Kimball plantea debe tener almenos un administrador en el equipo
del área, esto con el fin de evitar que cuando se presente una situación en la maquina
donde se tiene la bodega de datos, se pueda acceder y de ser requerido, reiniciarla.
Otro planteamiento es que no todos los miembros del equipo puedan tener acceso a
todo, el servidor de la bodega de datos debe estar estrictamente controlado. Frente a
la seguridad de los usuarios, es recomendable otorgarle acceso a cada usuario solo a
las aplicaciones que este requiera o use constantemente.

Siguiendo por el camino inferior del diagrama, se encuentran los puntos que se
asocian al área de aplicaciones de Inteligencia de Negocios, encontramos tareas
donde se diseña y desarrolla aplicaciones para usuarios finales. Como ya se había
explicado al inicio del desarrollo de la guía, no vamos a enfocarnos en esta parte del
ciclo de vida.

Las aplicaciones de inteligencia de negocios se ofrecen a una comunidad de usuarios

una forma estructurada y fácil de acceder a la bodega de datos. Se muestran
informes, aplicaciones de análisis que proporcionan información útil a los usuarios.
Estos van desde informes simples de formato fijo hasta aplicaciones sofisticadas
analíticas que aplican complejos algoritmos y modelos de minería de datos, ayudando
a identificar oportunidades o preguntas generadas en los datos. Algunas de estas
aplicaciones son:

 Análisis de la eficacia de la promociones

 Análisis de rutas de acceso en un sitio Web
 Análisis de afinidad de programas
 Planificación del espacio en espacios comerciales
 Detección de fraudes
 Administración y manejo de categorías de productos

24
 5. CONCLUSIONES

En adición a tener la experiencia laboral en el área donde se desenvuelve esta guía

ha sido un desafío crear el documento pensando cómo alguien que no tiene mucho
conocimiento de cómo desarrollar una bodega de datos y que necesita para hacerlo,
la investigación sobre metodologías que se adapten mejor a los futuros redactores de
la guía y los diseños generales sobre el área de ventas que puedan tener las
empresas, la investigación gerencial de cómo planear y organizar el equipo que va a
realizar la implementación, me ayudo a ver desde un punto de vista distinto al de
desarrollador, lo que abarca la construcción de una bodega de datos.
La investigación y experiencia personal que se aplicó para el desarrollo de esta guía
está enfocada en mostrar los posibles inconvenientes, mejores prácticas y escenarios
que he identificado para que la implementación sea lo más satisfactorio posible para
así disfrutar de los beneficios que la bodega de datos ofrece.
El aprendizaje transferido en esta guía es un gran apoyo que va a servir a cualquier
empresa que quiera iniciar un desarrollo de una bodega de datos para su área de
ventas, ahorrando tiempos y esfuerzo por parte de los futuros desarrolladores.

25