CAPITULO I

DATAWAREHOUSE
DEFINICIONES PRELIMINARES

Para aquellos que desarrollan y mantienen los sistemas de datos haciéndolos disponibles para
los directivos de las empresas, el término Datawarehouse o también conocido como Almacén
de Datos, ofrece la solución como ubicación central para que todos puedan acceder a la
información con los reportes necesarios, dando respuesta a necesidades de diferentes tipos de
usuarios.
El DW organiza y orienta los datos desde la perspectiva del usuario final, mientras que los
sistemas operacionales organizan sus datos desde la perspectiva de la aplicación, para lograr
eficiencia en el acceso a datos.

1.1 DATAWAREHOUSE

• Es un modelo de base de datos, perfectamente estructurado y depurado, para apoyo al

análisis y la toma de decisiones.
• Separado del entorno operacional y creado a partir del mismo y de datos
complementarios.
• Dedicado, en cualquier momento, para análisis e interrogación desde los usuarios en el
área de negocios.
• Integrado como base de un modelo de negocio o área del mismo.
• Enriquecido por periodos de tiempo determinados en cuyo momento representa una
visión puntual y completa del mismo.
• Orientado a un área o problema específico.
• No volátil, en la medida que no puede modificarse de forma unitaria en un elemento
concreto.
• Accesible para usuarios con poca experiencia y poco conocimiento de sistemas
informáticos.

1
 Fig. 1.1: “Modelo de DW”

1.2 OBJETIVOS

• Comprender las necesidades de los usuarios por áreas dentro del negocio.
• Determinar qué decisiones se pueden tomar con la ayuda del DW
• Seleccionar un subconjunto del sistema de fuentes de datos que sea el más efectivo y
procesable para presentar el DW.
• Asegurar que los datos sean precisos, correctos y confiables y que mantengan la
consistencia.
• Monitorear continuamente la precisión y exactitud de los datos y el contenido de los
reportes generados.
• Publicar los datos.

1.3 CARACTERISTICAS DE UN DW

Un DW debe tener cuatro características que son primarias.

• Es orientado a sujetos:

Un primer aspecto de un DW es que esta orientado a los mayores sujetos de la empresa.

El mundo operacional esta diseñado alrededor de aplicaciones y funciones, como por
ejemplo pagos, ventas, entregas de mercadería, para una institución comercial, tiene en
cuenta los procesos de negocio de la empresa que se deseen Priorizar.

2
• Los datos son integrados: Fig. 1.2: “DW orientada a sujetos”

El aspecto más importante del ambiente de un DW es que sus datos están integrados.
Cuando los datos son movidos del ambiente operacional, son integrados antes de entrar
en el DW. Por ejemplo, un diseñador puede representar el sexo como "M" y "F", otro
puede representarlo como "0" y "1", o "x" e "y", y otro usar las palabras completas
"masculino" y "femenino". No importa la fuente de la cual el sexo llegue al DW, debe
ser guardado en forma consistente; los datos deben ser integrados.

Fig. 1.3: “DW Integrado”

• Es variante en el tiempo

Los datos en el DW son precisos para un cierto momento, no necesariamente ahora; por
eso se dice son variantes en el tiempo. El Data DW contiene datos de un largo horizonte
de tiempo. Las aplicaciones operacionales, sin embargo, contienen datos de intervalos
de tiempo pequeños, por cuestiones de performance (tamaño chico de las tablas). Toda
estructura clave en un DW contiene implícita o explícitamente un elemento del tiempo.

3
 Esto no necesariamente pasa en el ambiente operacional. Los datos de un DW, una vez
almacenados, no pueden ser modificados (no se permiten updates). En el ambiente
operacional, los datos, precisos al momento de acceso, pueden ser actualizados, según
sea necesario.

• Es simple de manejar

Updates, inserts y deletes son efectuados regularmente, en una base de record-por-

record, a los datos operacionales. La manipulación de datos en un DW, es mucho más
sencilla. Solo ocurren dos operaciones, la carga inicial, y el acceso a los datos. Hay
consecuencias muy importantes de esta diferencia de procesos con un sistema
operacional: A nivel de diseño, en un DW, no hay que controlar anomalías producidas
por los updates, ya que no hay updates. Se pueden tomar libertades de diseño físico
como optimizar el acceso a los datos, y denormalización física. Otra consecuencia es la
simplicidad de la tecnología del DW, en lo que respecta a backups, recuperación, locks,
integridad, etc.

• No volátil

La información es útil solo cuando es estable, se usa principalmente para operaciones

de recuperación de información y no para actualizaciones. Los datos operacionales
cambian sobre una base momento a momento. La perspectiva más grande, esencial para
el análisis y la toma de decisiones, requiere una base de datos estable.

Fig. 1.4: “DW No Volátil”

1.4 JUSTIFICACION PARA LA CONSTRUCCION DE UN DW

4
 Generalmente, los sistemas transaccionales u OLTP usan estructuras normalizadas, en las
cuales se optimizan las inserciones y actualizaciones de artículos e incluso algunas
selecciones, pero es menos probable que el sistema se organice de forma tal que produzca
reportes eficientes para datos resumidos con cierta jerarquía. Y es aquí donde debería usarse
el DW, que usa los datos relevantes de fuentes existentes y los combinan en una estructura
que ha sido optimizada para las selecciones.
Esta es la razón por la cual se construye un DW para solucionar la problemática de tener un
sistema fuente transaccional corriendo sobre un servidor. Esta información se necesita que
esté consultable para los clientes de la empresa de forma remota y sin embargo, por
problemas de seguridad no puede estar directamente disponible desde el mismo sistema
fuente. El DW ha sido la solución propuesta para que la información sea utilizada por una
aplicación cliente de acceso remoto. De esta forma se aprovecha la forma en que se
organizan los datos en el almacén en el modelo dimensional y se brinda a la Gerencia un
grupo de informaciones organizadas en cubos multidimensionales que les permite
profundizar en el análisis de la información y ver su variación en el tiempo.
Los DW están en la categoría de los sistemas para el soporte de decisiones (DSS) que
tienen como objetivos medir y controlar el desarrollo de las variables importantes del
negocio, buscando identificar, proyectar y predecir tendencias a partir de los datos
acumulados.
Los datos que se manejan en el DW son informacionales, esto significa que son datos
resumidos y periódicos a diferencia de los datos operacionales.

1.5 DATAMART:

• Es un pequeño almacén de datos, diseñado para una unidad de negocio.

• Se centra en un tema concreto. Muchos almacenes de datos comienzan siendo Data
Mart (para minimizar riesgos) y se va ampliando su ámbito.
• Un Data Mart está enfocado a una sola área o grupo de usuarios, mientras que un DW
contiene información de diferentes sujetos y áreas de la corporación.
• Una organización puede tener un sólo DW, pero varios Data Marts.

• Los Data Marts no contienen información almacenada como datos operacionales, pero
si la tienen los DWs.
• Como los Data Marts contienen menos información, son más fáciles de entender y
navegar, que los DWs corporativos. Un DW puede contener tanta información, que es
difícil de manejar por los usuarios.

5
• Las soluciones de Data Marts, requieren una arquitectura de 3 capas: Los DWs son la
primera capa (opcional), los Data Marts son la segunda capa, y las estaciones de trabajo
de usuarios son la tercera.

El reciente crecimiento de los Data Marts, ha generado también, muchos problemas a los
usuarios, para acceder a la información de la organización.

• Se pierde performance a medida que aumenta el tamaño de los Data Marts. Los usuarios
esperan mejor respuesta de los Data Marts, que de los DWs.
• Los usuarios requieren acceso a datos de muchos Data Marts. Los datos pueden ser
replicados entre los Data Marts, pero se requieren mejores soluciones.
• Las compañías no pueden administrar fácilmente muchos Data Marts. Mientras sólo se
tiene un DW, se pueden tener muchísimos Data Marts.
• Las organizaciones tienen dificultades para construir los Data Marts. Aunque es
aceptable que la construcción de un DW lleve varios años, los Data Marts requieren un
ciclo de desarrollo muy corto, para una inversión moderada.

1.5.1 TIPOS DE DATAMART

1.5.1.1 DATAMART DEPENDIENTES

En esta arquitectura los datos son cargados desde los sistemas de producción
hacia el data DW empresarial y entonces subdivididos en Data Marts. Se llaman
Data Marts dependientes porque utilizan los datos y metadatos del DW en lugar
de obtenerlos de los sistemas de producción.
Esta solución resuelve los problemas de performance, estrategia, finanzas e
incluso algunos de los problemas políticos. Aunque tiene esos puntos a favor,
sigue teniéndose que construir el DW global antes que los Data Marts sean
implementados.

1.5.1.1.1 VENTAJAS

• Se asegura la coherencia y consistencia de la información

registrada así como la inexistencia de redundancias indeseadas
• Permite un desarrollo en etapas, una vez haber realizado el diseño
global del DW o Modelo Empresarial, abordando la construcción
de los Data Marts secuencialmente.

6
 • La gestión de los Data Marts es más cómoda ya que las reglas que
rigen la extracción, carga y transformación de los datos son
comunes.

1.5.1.1.2 INCONVENIENTES

• Diseño más complejo debido al enfoque global inicial que se

aplica.
• Puede ser difícil resolver los problemas de prioridades que surjan
entre las diferentes unidades de negocio involucradas.

Fig. 1.6: “Data Mart Dependiente”

Fig. 5: “Data Mart Dependiente”

7
1.5.1.2 DATAMART INDEPENDIENTES

Esta óptica es considerada por muchos como una alternativa del DW central.
Con ella es posible comenzar con un sistema pequeño, invirtiendo menos
dinero y obteniendo resultados limitados entre tres a seis meses. Los que
proponen esta arquitectura, argumentan que luego de comenzar con un Data
Mart pequeño, otros data marts pueden proliferar en otras líneas de negocio o
departamentos que tengan necesidades y que satisfaciendo las distintas
necesidades divisionales, una organización puede construir su camino para el
DW completo, de una manera bottom up. En este caso de Data Marts
múltiples también se tienen procesos de carga múltiples donde los datos son
extraídos desde sistemas de producción quizás en forma redundante.

1.5.1.2.1 VENTAJAS

• Rapidez del retorno de la inversión realizada.

• Desarrollo más rápido debido a que se afronta un conjunto de
datos de menor entidad y complejidad
• Rapidez de acceso a la información soportada. Ventaja que
adquiere importancia a partir de volúmenes de datos notables

1.5.1.2.2 INCONVENIENTES
• Redundancias indeseadas de datos. Cada Data Mart ha de ser
totalmente independiente por lo que habrá tablas y/o datos que
deberán estar repetidos, lo que conlleva un incremento de espacio
ocupado y graves problemas de coherencia.
• Lo anteriormente expuesto provoca la existencia de procesos de
extracción, manipulación y carga redundantes con el incremento
de recursos y complejidad que conlleva.
• Imposibilidad de asegurar la consistencia de los datos
almacenados.
• Dificultad para la realización de consultas que relacionen datos
situados en diferentes Data Marts. Depende de las herramientas
de Reporte/Análisis de Información utilizadas ya que algunas

8
 permiten la realización de informes multiconsulta accediendo a
diferentes bases de datos relacionadas entre sí.

Fig. 1.7: “Data Mart Independiente”

1.6 TERMINOLOGIA DW

• DIMENSIONES
Entidades que deseo monitorear
Clasificación por jerarquía
Ejemplo: Cliente, Producto, Región, Tiempo

• ATRIBUTO
Característica de la dimensión
Ejemplo: Sexo, Estado

• VARIABLE O MEDIDA
Valor que permite controlar el negocio
Ejemplo: Ventas, Costos, Unidades

• FACT TABLE
Registro de las transacciones

9
 CAPITULO II
DATAWAREHOUSING
ALMACENES DE DATOS

Generalmente, la información que se quiere investigar sobre un cierto dominio de la

organización se encuentra en bases de datos y otras fuentes muy diversas, tanto internas como
externas. Muchas de estas fuentes son las que se utilizan para el trabajo diario (bases de datos

10
operacionales). Sobre estas mismas bases de datos de trabajo ya se puede extraer conocimiento
(visión tradicional). El Datawarehousing nos permite obtener estos datos e integrarlos en un
repositorio organizacional para luego acceder a ellos y hacer real la Gestión del Conocimiento.
Para conseguirlo será necesaria la aplicación de una Metodología, y la implantación de una
Arquitectura Tecnológica de la Gestión del Conocimiento.

2.1 DATAWAREHOUSING

Datawarehousing es el proceso de integrar datos corporativos de la empresa en un solo

repositorio. El DW resultante puede entonces soportar una variedad de funciones de análisis
de decisiones así como también funciones estratégicas operacionales. Estos datos a menudo
se originan de una variedad de fuentes (los tipos diferentes de bases de datos), formatos, y
tipos y son generalmente consolidados, transformados, y cargados en uno o más instancias
de un sistema de gestión de base de datos para facilitar un rango generoso de aplicaciones
analíticas. El almacén de datos puede constar de una sola base de datos de la empresa, de la
cual los usuarios y los administradores se conectan directamente, o puede incorporar varios
sistemas más pequeños, llamados Data Marts, cada uno de los cuales almacena un área
específica dentro del almacén global.

2.2 CUBO

Es un modelo multidimensional soporta el manejo de una basta cantidad de datos

empresariales y temporales.
En una base de datos multidimensional la información se representa como una matriz
multidimensional, en los ejes de esta matriz se encuentran los criterios de análisis, en los
cruces están los valores a analizar. Como ejemplo de Cubo encontramos el que nos muestra
la figura 2.1, la cual contiene tres dimensiones: producto, ciudad y año; donde cada
dimensión tiene tres diferentes niveles o hechos, para finalmente encontrar la medida al
intersectar los valores.

Lima
Arequipa
1999199 Huancayo
8
200
Producto1

Producto2

Producto
3

Ventas 11
 Fig. 2.1: “Modelo de Cubo de 3” Dimensiones”

2.2.1 CONFORMACION

Los Cubos o Hipercubos están formados por:

• Dimensiones

Las dimensiones son un concepto esencial de bases de datos multidimensionales.

Las dimensiones representan los criterios de análisis de los datos, macro-objetos del
problema y variables independientes. Si una dimensión tiene más de un nivel
entonces los miembros de la dimensión pueden ser organizados en una o más
jerarquías, como lo muestra la figura Nº 8.

Fig. 2.2: “Dimensión con Niveles”

• Medida

Las medidas son un dato numérico que representa una actividad específica de un
negocio, mientras que una dimensión representa una perspectiva de los datos. Cada
dimensión está descrita por un conjunto de atributos (datos agregados). A su vez se
pueden intersectar estas dimensiones para obtener un valor, llamado medida.

Una medida contiene una propiedad numérica y una fórmula. Existen tres clases de
medidas:

o Medidas aditivas: Pueden ser combinadas a lo largo de cualquier dimensión.

12
 o Medidas semi-aditivas: No pueden ser combinadas a lo largo de una o más
dimensiones.
o Medidas no aditivas: No pueden ser combinadas a lo largo de ninguna
dimensión.

2.3 TIPOS DE TABLAS

2.3.1 TABLA DE HECHOS (FACT TABLE)

La tabla de hechos contiene los valores de las medidas de negocios, por ejemplo:
ventas promedio en dólares, número de unidades vendidas, etc.
Es la tabla central en un esquema dimensional. Es en ella donde se almacenan las
mediciones numéricas del negocio. Estas medidas se hacen sobre el grano, o unidad
básica de la tabla.
El grano o la granularidad de la tabla queda determinada por el nivel de detalle que
se almacenará en la tabla. Por ejemplo, para el caso de producto, mercado y tiempo,
el grano puede ser la cantidad de madera vendida ‘mensualmente’. El grano revierte
las unidades atómicas en el esquema dimensional.
La clave de la tabla fact recibe el nombre de clave compuesta o concatenada debido
a que se forma de la composición (o concatenación) de las llaves primarias de las
tablas dimensionales a las que está unida.
Así entonces, se distinguen dos tipos de columnas en una tabla fact: columnas fact y
columnas key.
• Donde la columna fact es la que almacena alguna medida de negocio
• Una columna key forma parte de la clave compuesta de la tabla.

2.3.2 TABLAS LOCK-UP O DIMENSIONALES

Estas tablas son las que se conectan a la tabla fact, son las que alimentan a la tabla fact.
Una tabla lock_up almacena un conjunto de valores que están relacionados a una
dimensión particular. Tablas lock_up no contienen hechos, en su lugar los valores en las
tablas lock_up son los elementos que determinan la estructura de las dimensiones. Así
entonces, en ellas existe el detalle de los valores de la dimensión respectiva.
Una tabla lock_up está compuesta de una primary key que identifica unívocamente una
fila en la tabla junto con un conjunto de atributos, y dependiendo del diseño del modelo

13
 multidimensional puede existir una foreign key que determina su relación con otra tabla
lock_up.
Para decidir si un campo de datos es un atributo o un hecho se analiza la variación de la
medida a través del tiempo. Si varía continuamente implicaría tomarlo como un hecho,
caso contrario será un atributo.
Los atributos dimensionales son un rol determinante en un DW. Ellos son la fuente de
todas las necesidades que debieran cubrirse. Esto significa que la base de datos será tan
buena como lo sean los atributos dimensionales, mientras más descriptivos, manejables
y de buena calidad, mejor será el DW.

2.3.3 TABLA DIMENSIÓN TIEMPO

Virtualmente se garantiza que cada DW tendrá una tabla dimensional de

tiempo, debido a la perspectiva de almacenamiento histórica de la
información. Usualmente es la primera dimensión en definirse, con el
objeto de establecer un orden, ya que la inserción de datos en la base de
datos multidimensional se hace por intervalos de tiempo, lo cual asegura
un orden implícito.

2.4 MODELAMIENTO DE DW

La técnica usada dependerá de la complejidad de los datos y las necesidades del usuario.
Existen dos tipos básicos de modelamiento y son:

o Modelo Estrella
o Modelo Copo de Nieve
2.4.1 MODELO ESTRELLA (STAR SCHEMA)

El modelo multidimensional también se conoce con el nombre de esquema estrella,

pues su estructura base es similar: una tabla central y un conjunto de tablas que la
atienden radialmente. El centro de la estrella consiste de una o más tablas fact, y las
puntas de la estrella son las tablas lock_up.

2.4.1.1 Pasos para el diseño de un Star Schema

Identificar los procesos del negocio para analizar (como ventas)

Identificar las medidas o hechos (ventas en dólares)

14
 Identificar dimensiones para hechos (dim_product, dim_ubicación,
dim_tiempo)
Lista de columnas que describen cada dimensión (nombre de región, nombre
de marca, nombre de región)
Determinar el nivel mas bajo de resumen en la tabla de hechos (venta en
dólares)

Fig. 2.11: “Modelo Estrella”

2.4.2 MODELO COPO DE NIEVE (SNOWFLAKE SCHEMA)

La diferencia del esquema snowflake comparado con el esquema estrella, está en la

estructura de las tablas lock_up: las tablas lock_up en el esquema snowflake están
normalizadas. Cada tabla lock_up contiene sólo el nivel que es clave primaria en la
tabla y la foreign key de su parentesco del nivel más cercano del diagrama.
Variante del esquema de estrella que presenta las tablas de dimensión estructuradas a
más de un nivel. (Tablas normalizadas)

15
Fig. 2.12: “Modelo Copo de Nieve”

16
 CAPITULO III
INTELIGENCIA DE DATOS EN
LA EMPRESA DEXUR E.I.R.Ltda

3.1. PROBLEMA DE INVESTIGACIÓN

3.1..1 PLANTEAMIENTO DEL PROBLEMA.

Una empresa multinacional fundada en octubre de 1999 con sede en Brasil y

representación en Chile, Colombia y Venezuela, se dedica a la venta de productos
de automoción, albañilería y limpieza.
La empresa ha recogido las ventas realizadas por toda la fuerza comercial durante
estos años en una única base de datos, de la que se describe el submodelo de la
base de datos que registra las transacciones de ventas
La toma de decisiones se basa en reportes unidimensionales que provienen de los
sistemas operacionales tales como de Ventas, Contabilidad y otros.
DEXUR, posee solo un sistema operacional, este que reflejan la evolución de la
empresa a lo largo del tiempo, claro que también maneja una información en forma
“Artesanal” en papeles e inventarios documentados, facturas, boletas, etc., sus
éxitos y fracasos están en esa montaña de información sobre la cual está
estructurada la empresa, lamentablemente toda esa información no ha sido
estructurada ni procesada en un Sistema de Información dedicado exclusivamente
al Management Comercial y Marketing

3.1.2 FORMULACION DEL PROBLEMA

3.1.2.1 PROBLEMA GENERAL

¿Cómo transformar toda esa información de una manera rápida, para el

mejoramiento de las tomas de decisiones a la empresa aprovechando toda
esta información contenida en el sistema operacional de modo que ayuden

17
 a encontrar las claves para que los ejecutivos definan las estrategias en el
Área comercial posicionando a DEXUR en el liderazgo como empresa
distribuidora al por mayor y menor de productos en el centro de el Perú?

3.1.2.2PROBLEMAS ESPECIFICOS.

¿Cómo se debe de analizar correctamente la información de Ventas,

Marketing y Logística de manera eficiente y veloz para la mejor toma de
decisiones en la gestión comercial?
¿Cómo establecer una relación personalizada con los clientes identificando sus
consumos, necesidades y preferencias?
¿Cómo establecer una relación personalizada con los proveedores que muchas
veces por confiar en ellos podemos perder clientes?
¿Cómo posicionar más y mejores cosas al mercado de Huancayo?

3.1.3 OBJETIVOS

3.1.3.1 OBJETIVO GENERAL

• Desarrollar un Sistema de Gestión de la Información dedicado al

Manejo de Información Gerencial y Comercial de DEXUR, para ayuda
a la toma de decisiones en esta empresa aplicando Datawarehousing y
Business Intelligence (Datamining) para la estructuración de la
información y la obtención del conocimiento relativos a mercados,
clientes, proveedores y productos con los que la empresa podrá generar
utilidades y añadir valor agregado a sus actividades.

3.1.3.2 OBJETIVOS ESPECIFICOS

• Aplicar el Modelamiento multidimensional para la estructuración de la

información comercial y posteriormente hacer un análisis OLAP y
aplicar modelos de Datamining.
• Aplicar software adecuado para la empresa que haciendo el análisis
coste/beneficio sea muy productivo para esta.

18
 3.1.4 JUSTIFICACION

La información de una empresa es importante y decisiva, siempre en cuando

esta llegue de manera inmediata para la toma de decisiones correcta, los
sistemas de información poco a poco han integrado a toda la empresa, pero
muchas veces la tecnología aún no tenía las características para poder
satisfacer esa necesidad en cuanto a velocidad, capacidad, precio y facilidad.
Actualmente hay nuevos paradigmas de gestión y los gerentes de hoy
reconocen estar en el negocio de la información.

3.2 DISEÑO Y CONSTRUCCION DEL DATAWAREHOUSE

3.2.1 BASE DE DATOS ORIGINAL EN ACCESS

Analizamos la base de datos original que se encuentra en Access.

Fig. 3.1: “Base de Datos en Access”

19
 3.2.3 PAQUETE DE TRANSFORMACIÓN DE DATOS DE LA BASE DE
DATOS EN ACCESS HACIA EL DATAWAREHOUSE EN SQL

Migramos o exportamos las tablas que se va ha utilizar en el DW, previamente

analizados en la base de datos original.

Fig. 3.2: “DTS de Access a SQL”

3.3. DATA WAREHOUSE EN SQL

Diseñamos nuestro DW en SQL Server e implementamos nuestra tabla Tiempo_Dim y

Comercial_Fact (Tabla de hechos)

20
 Fig. 3.2: “DW DEXUR”

3.3.1 DESCRIPCION DE LAS TABLAS DEL ESQUEMA

• ORIGEN_VENTA:

ORI_ID: identificador del origen de la venta

ORI_NOMBRE : nombre del origen de la venta

Valores:
ORI_ID ORI_NOMBRE
1 Venta Cruzada
2 Venta Directa
3 Tele-Venta

• MONEDAS:

MON_ID: identificador de la moneda

MON_NOMBRE: nombre de la moneda
MON_CAMBIO: cambio de la moneda respecto al dólar

21
 Valores:
MON_ID MON_NOMBRE MON_CAMBIO
1 Reales 1,92
2 Peso Chileno 792
3 Peso Colombiano 2510
4 Bolivar 850

• PAISES:

PAIS_ID: identificador del país

MON_ID : identificador de la moneda del país
PAIS_NOMBRE : nombre del país

Valores:
PAIS_ID MON_ID PAIS_NOMBRE
1 3 Colombia
2 2 Chile
3 1 Brasil
4 4 Venezuela

• TIPOS_CLIENTES:

TIP_ID: Identificador del tipo de cliente

TIP_NOMBRE: Nombre del tipo de cliente

Valores:
TIP_ID TIP_NOMBRE
1 Tarjeta ORO
2 Tarjeta PLATA
3 Tarjeta BRONCE

• CLIENTES:

CLI_ID: identificador del cliente

TIP_ID: identificador del tipo de cliente

22
 CLI_BAJA: indica si el cliente ha sido baja
CLI_NOMBRE: Nombre del cliente
CLI_CIF: Identificador Fiscal del cliente
CLI_TELEFONO: Teléfono del cliente

Ejemplos:
1 3 0 cliente 1 1599.38 555-00-1
2 2 0 cliente 2 1600.38 555-00-2

• PRODUCTOS:

PRO_ID: identificador del producto

PRO_NOMBRE: nombre del producto
PRO_CODIGO: código del producto. Las dos primeras letras
indican el tipo de producto (Alimentación, Limpieza o Automoción).

Valores:
PRO_ID PRO_NOMBRE PRO_CODIGO
1 Ladrillo 12x5 AL01
2 Teja interior AL02
3 Cera cubre arañazos LI01
4 Neumático 175R AU01
5 Liquido anticongelante LI02
6 Neumático 195R AU02
7 Ladrillo 10x10 AL05
8 Teja exterior AL03
9 Ladrillo 7x7 AL04
10 Neumático 165R AU03

• ESTADOS_CONTRATOS:

EST_ID : identificador del estado del contrato

EST_NOMBRE: nombre del estado del contrato

23
 Valores:
EST_ID EST_NOMBRE
1 Edición
2 Revisión
3 Servicio
4 Cerrado
5 Anulado
6 Sustituido por nueva versión
7 Borrado

• CONTRATOS:

CON_ID: identificador del contrato

CON_VERSION: versión del contrato
PAIS_ID: país que ha realizado la venta
CLI_ID: identificador del cliente al que se le ha hecho la venta
EST_ID: estado del contrato
ORI_ID: id del origen por el que se ha realizado la venta
MON_ID: moneda del contrato
CON_IMPORTE: importe TOTAL del contrato
CON_F_INI: fecha de inicio del contrato
CON_F_FIN: fecha de caducidad de la oferta del contrato
CON_NOMBRE: nombre del contrato
CON_FIRMA_FECHA: fecha de firma del contrato

• PARTES_CONTRATOS:

CON_ID: identificador del contrato

CON_VERSION: identificador de la versión de contrato
PART_CON_ID: identificador de la parte del contrato
PRO_ID: producto asociado a la parte del contrato
PART_CON_F_INICIO: fecha de inicio de entrega del producto
PART_CON_F_FIN : fecha máxima de entrega del producto
PART_CON_CANTIDAD: número de productos de la parte del contrato
PART_CON_IMPORTE: importe de la parte del contrato
PART_CON_COSTE: coste interno de la empresa asociado a la parte del
contrato.

24
 PART_CON_CAMBIO_MONEDA: cambio a dólares de la moneda del
Contrato. Este valor se registra en el momento de añadir una nueva parte
del contrato al mismo.

3.2 MODELAMIENTO DEL DATAWAREHOUSE

Para dar solución al problema anteriormente planteado, se ha implementado un Sistema

de Toma de Decisiones para la alta Dirección con las siguientes Métricas:

- Importe de la venta
- Coste de la venta
- Unidades vendidas
- Número de ventas a fecha
- Ganancia Bruta = (Importe de la venta – Coste de la venta)
- Ventas Medias a Fecha = (Importe Venta / Número Ventas a Fecha)
- Coste Medio por Unidad = (Importe Venta / Unidades vendidas)
- Porcentaje de la venta según parámetros frente al resto de parámetros
- Crecimiento comparativo respecto al periodo paralelo anterior
- Crecimiento comparativo respecto al periodo inmediatamente anterior
- Importe de ventas acumulado dentro del mismo año
- Importe medio de las ventas realizadas en los últimos tres periodos

3.4.1 DIMENSIONES DEL DATA MART

Para crear el Data Mart Ventas para la empresa DEXUR E.I.R.Ltda, necesitamos
hacer el modelamiento de la Fact Table (Tabla de Hechos). La clave de la Fact
Table_Ventas recibe el nombre de clave compuesta o concatenada debido a que se
forma de la composición (o concatenación) de las llaves primarias de las tablas
dimensionales Paises, Productos, Origen_Venta, Clientes, Tiempo a las que está
unida.

25
 Origen_venta

Tiempo_dim Paises_dim

Bloques_Ventas_Fact

Productos_dim
Clientes_dim

Fig. 3.3: “Data Mart DEXUR”

3.4.1.1 Descripción de las Dimensiones

Para tener un mejor entendimiento de las dimensiones que emplea la tabla

Ventas_Fact, se describen a continuación.

- Tiempo_dim
- Origen_Venta_dim
- Pais_dim
- Clientes_dim
- Productos_dim

Nombre de la Dimensión Descripción de la Dimensión

Tiempo_dim Contiene todos los atributos asociados con la fecha
considerada como venta
Origen_venta_dim Indica el origen de la venta (Televenta, Venta directa o
Venta Cruzada entre países)
Pais_dim Contiene todos los atributos asociados al país de la venta
Clientes_dim Contiene los atributos asociados al cliente al que se ha
realizado la venta. Los clientes están categorizados según
tengan Tarjeta ORO, PLATA o BRONCE.
Productos_dim Contiene información del producto asociado a la venta.
Están categorizados según se trate de productos de
Albañilería, Automoción o Limpieza.

Tabla 3.1 “Descripción de las dimensiones usadas por Ventas_Fact

DEXUR”

26
 3.4.1.2 Detalle de las Dimensiones

A continuación se van a explicar como se particionaron las dimensiones

usadas para la construcción de la Data Marts

a. Dimensión Tiempo

La dimensión tiempo se ha particionado de la siguiente manera:

Año

Quarto

Mes

Semana

Día

Fecha último día Semana

Nombre Mes

Nombre Día Fecha Venta

Fecha último día Mes

Fig. 3.4: “Particionamiento de la Dimensión Tiempo”

Descripción Atributos Dimensión Tiempo

La dimensión tiempo tiene los atributos descritos a continuación:

Nombre Atributo Descripción Atributo Ejemplo

Fecha Venta Es la menor entre las fechas de firma 04/11/2001
del contrato y la fecha del comienzo
del mismo
Num dia mes Número del día dentro del mes 4
Num dia año Número del día dentro del año 308
Num semana Número de semana dentro del año 44
Num mes Número del mes 11
Num quarto Número del quarto (trimestre) 4
Num año Número del año 2001
Nombre día Nombre del día domingo
Nombre mes Nombre del mes noviembre
Fecha último día Fecha último día de la semana 04/11/2001
semana

27
 Nombre Atributo Descripción Atributo Ejemplo
Fecha último día mes Fecha último día del mes 30/11/2001
Tabla 3.2: “Atributos de la Dimensión Tiempo”

b. Dimensión Origen de la Venta

La dimensión tiempo emplea a: Origen

Descripción Atributos Dimensión País

Esta dimensión tiene los siguientes atributos:

Nombre Atributo Descripción Atributo Ejemplo

Nombre Origen Indica el origen de la venta Televenta
(Televenta, Venta directa o Venta
Cruzada entre países)

Tabla 3.3: “Atributos de la Dimensión Origen_Venta”

c . Dimensión País

País
Emplea a la tabla país

Descripción Atributos Dimensión País

La dimensión país tiene el siguiente atributo:

Nombre Atributo Descripción Atributo Ejemplo

Nombre País Es el país donde se ha realizado la Brasil
venta
Tabla 3.4: “Atributos de la Dimensión País”

d. Dimensión Cliente

La dimensión cliente emplea a la tabla cliente con la jerarquía de categoría cliente

28
 Cliente

Categoría Cliente

Descripción Atributos Dimensión Cliente

Para la dimensión cliente se consideran los siguientes atributos:

Nombre Atributo Descripción Atributo Ejemplo

Cliente Nombre del cliente Cliente 12
Categoría Cliente Indica si se trata de un Anunciante, de un Tarjeta ORO
cliente con tarjeta de ORO, PLATA o
BRONCE.
Tabla 3.5: “Atributos de la Dimensión Cliente”

e. Dimensión Producto

La dimensión producto usa la tabal producto con la jerarquía tipo de producto.

Producto

Tipo Producto

Descripción Atributos Dimensión Producto

La dimensión producto tiene os atributos producto y tipo de producto detallados a

continuación:

29
 Nombre Atributo Descripción
Tabla 3.6: “Atributos de Atributo
la Dimensión Producto” Ejemplo
Producto Nombre del producto Cera cubre arañazos
Tipo Producto Categoría del producto Automoción

3.4.1.3 Detalle de la Tabla de Hechos

a. Ventas Facts

Descripción Ventas Fact

La tabla de hechos llamado para nuestro caso Ventas_Fact, tiene los

hechos ventas en dólares, coste dólares, unidades, número de ventas a
fecha que se especifican mejor en la siguiente tabla.

Regla de
Nombre del Hecho Descripción del Hecho Agregación
Venta Dólares Representa el importe de la Venta, Sum
previa transformación de la moneda
local a la moneda de consolidación
(dólares).
Coste Dólares Representa el importe del Coste Sum
generado internamente en la compañía,
previa transformación de la moneda
local a la moneda de consolidación
(dólares).
Unidades Número total de productos vendidos. Sum
Número de Ventas a Fecha Indica el número de ventas que han Count
ocurrido en un momento dado

Tabla
b. Miembros 3.7: “Hechos de la tabla Ventas_Fact”
Calculados

Para la construcción de la tabla de hechos Ventas_Fact, se consideran los

siguientes miembros calculados

Regla de
Nombre del Medidas Descripción de las Medidas Agregación
Ganancia Bruta Ganancia que representa la Venta Venta - Coste

30
 Regla de
Nombre del Medidas Descripción de las Medidas Agregación
Ventas Medias a Fecha Representa el número de ventas medias Venta / Num
realizadas hasta la fecha Ventas
Coste Medio por Indica el coste medio de las unidades Venta / Unidades
Unidad para una venta
Tabla 3.8: “Medidas de la tabla Ventas_Fact”

3.5 ELABORACION DE LA TABLA DE HECHOS

Después de haber realizado la construcción del data mart de la empresa DEXUR

E.I.R.Ltda,, tenemos la siguiente tabla de hechos

3.5. 1 Tabla Bloques Ventas_Fact

Recordemos que la tabla Fact tiene como clave primaria, las claves de las tablas
dimensionales y los hechos a evaluar en la empresa

Fig. 3.5: “Tabla de Hechos Ventas_Fact”

En este diseño se puede observar que han sido necesarias las siguientes transformaciones
de los datos de la base de datos operacional:

1. Creación de una nueva tabla tipo_producto_dim en el diseño multidimensional, que

31
 categoriza a éstos según sean de Automoción, Limpieza o Albañilería.

Pues se pretende clasificar las ventas según su procedencia y es necesario crear una
dimensión.

2. Creación de una nueva columna en la tabla productos_dim, que permite categorizar a

los mismos y hace referencia a la tabla anterior.

3. La granularidad elegida en el modelo es Partes_Contratos. Ha sido necesaria una

desnormalización debido a que la relación entre Contratos-Pais, Contratos-Moneda y
Contratos-Clientes, se ha convertido en el modelo multidimensional en relaciones
entre Partes_Contratos-Pais, Partes_Contratos -Moneda y Partes_Contratos –
Clientes.

Se repiten estos valores a nivel de Partes_Contratos (aunque se trata de los mismo

dentro de un mismo contrato).

4. Debido que aveces se fía, la fecha de la venta es la menor entre las fechas de firma
del contrato (con_firma_fecha) y la fecha de inicio del mismo (con_f_ini).

Ha sido necesario calcular apartir de estas fechas guardadas en el operacional la

fecha de venta, y almacenar en la tabla de hechos el id de la fecha correspondiente a
la fecha de venta obtenida.

5. Únicamente se han considerado como partes_contratos buenos, es decir

partes_contratos que deben considerarse como venta, aquellos que provengan de
contratos que se encuentren en estado o bien Cerrado o bien en Servicio.
El importe de los bloques ha sido necesario convertirlos en dólares, en función del
valor de cambio a dólares considerado para cada país, ya que es necesario conocer el
importe total de las ventas en todos los países y la suma de estos.
En la tabla Monedas se almacena el tipo de cambio actual, en la tabla
partes_contratos se almacena el tipo de cambio en el momento de la venta.

32
3.5.2 Tablas de Dimensión

A continuación se describen los nombres de las columnas de todas las tablas de

dimensiones que participan en la Fact Table.

a. Tabla Dimensión Origen de la Venta

ORI_ID: id del origen de la venta en el operacional

ORI_NOMBRE: nombre del origen de la venta
ori_dm_id: id del origen de la venta en el Datamart. Clave de la tabla

b. Tabla Dimensión Tiempo

c. Tabla Dimensión Países

PAIS_ID: id del país en el operacional

MON_ID: id de la moneda del datamart
PAIS_NOMBRE: nombre del país
pais_dm_id: id del país en el datamart. Clave de la Tabla.

33
d. Tabla Dimensión Clientes

CLI_ID: id del cliente en el operacional

TIP_ID: id que referencia al tipo de cliente, id del operacional
CLI_BAJA: indica si el cliente ha sido baja
CLI_NOMBRE: nombre del cliente
CLI_CIF: Identificador Fiscal del Cliente
CLI_TELEFONO: Número de teléfono del Cliente
cli_dm_id: id del cliente en el Datamart
tip_dm_id: id que referencia al tipo de cliente, id del datamart
TIP_NOMBRE: nombre del tipo de cliente

e. Tabla Dimensión Productos

PRO_ID: id del producto en el operacional

PRO_NOMBRE: nombre del producto

PRO_CODIGO: código del producto

pro_dm_id: código del producto en el datamart. Clave de la tabla.

La tabla tipo_producto_dim no está presente en el operacional, se ha creado en el

datamart con la finalidad de poder categorizar los productos según los primeros
dos caracteres del PRO_CODIGO: AL (alimentación), AU (automoción) y LI
(limpieza)

34
3.6 CONSTRUCCIÓN DE LOS CUBOS OLAP

Construcción del cubo (cubos) de datos para dar respuesta a las consultas siguiente así como
respuesta a las siguientes preguntas:
o Tipología de producto más vendido en enero de 2000 y número de unidades
vendidas
o Producto más rentable en Colombia en el 2000
o Evolución de las ventas realizadas con el paso del tiempo en cada país
o Importe total de las ventas de todos los países consolidadas bajo una única moneda
(dólar americano)
o Ingresos por tipos de clientes y por años
o Ingresos según el origen de la venta
o Comparativas de ventas para los mismos periodos en distintos años.

3.6.1 PROCESO DE CONSTRUCCION DE UN CUBO OLAP

Para construir Cubos OLAP se carga el Analysis Services de SQL Server y se ejecuta
el Analysis Manager del Analysis Services

Fig. 3.6: “Pantalla del Análisis Manager”

1. Creamos el origen de datos y configuramos aquí el proveedor y la conexión a usar en

nuestro caso es el Microsoft OLE DB provider for SQL Server. El servidor Local y la
base de datos EXPO_DW.

35
 Fig. 3.7: “Seleccionando Proveedor y Conexión”

2. Construimos el cubo

- Crearemos el cubo cubo_ventas, para ello debemos seguir el siguiente

proceso:

a. Seleccionamos la Tabla de Hechos

Fig. 3.7: “Seleccionando la Fact Table”

b. Seleccionamos las medidas

Recordemos que las medidas son los valores en los que se desea hacer la
consulta

36
 Fig. 3.8: “Seleccionando la medidas a usar”

c. Creamos las dimensiones

Las dimensiones son los hechos que deseo analizar. Por ejemplo: ventas al año,
venta en dólares, etc.

Fig. 3.9: “Asistente para Crear las Dimensiones”

d. Definimos el modelamiento a usar

En el caso de ventas, se escoge un modelamiento en estrella. Pero si analizamos

producto por tipo debemos escoger el modelamiento copo de nieve por las
jerarquías que tiene la tabla producto

37
 Fig. 3.10: “Seleccionando el Modelamiento”

d. Y generamos el cubo y analizamos los datos previamente

Fig. 3.11: “Nombrando al Cubo Generado”

Fig. 3.12: “Analizando el Cubo”

38
e. Generamos el cubo y seleccionamos el tipo de Almacenamiento a Usar

Aquí se define el modo de almacenamiento que deseamos usar, podría ser

ROLAP, MOLAP o HOLAP. El tipo seleccionado depende de los procesos de la
empresa, recordemos que rolap crea los cubos en la base de datos mientras que
molap los almacena en cubos.

Fig. 3.13: “Asistente de Almacenamiento”

Fig. 3.13: Asistente Para Almacenamiento a Usar”

En DEXUR E.I.R.Ltda se ha escogido el modelamiento MOLAP por las ventajas

que nos brinda.

Fig. 3.14: “Escogiendo el Modo de Almacenamiento a Usar”

Luego, para poder tener data en el cubo, primero debemos procesar el cubo

39
 Fig. 3.15: “Procesamiento exitoso”

3.7 QUERY & REPORTING

Aquí detallamos como se realizan las consultas y los reportes respectivos dentro de un
cubo en SQL Server, Una vez procesado el cubo podemos visualizar nuestros reportes.

3.7.1 DEFINICION DE REPORTES

Podremos analizar los reportes que nos da el SQL desde Microsoft Excel y poder
ayudar a la toma de decisiones llegando a un análisis gráfico como podemos ver en
el siguiente diagrama:

a. Obteniendo data de la base de datos EXPO_DW

Fig. 3.16: “Generando la conexión al SQL”

b. Generamos el origen de datos

Es importante determinar el correcto origen de la data que se desea examinar,

en este caso Servicios OLAP de Microsoft SQL Server

40
 Fig.
Luego, tenemos que 3.17: “Eligiendo
seleccionar la baseeldeorigen
datosde la la
con conexión”
que se desea trabajar, para la
aplicación, debemos conectarnos a la base de datos EXPO_DW

Fig. 3.18: “Seleccionando la Base de Datos EXPO_DW”

Luego de escoger la base de datos, se necesita conectar al cubo que se desea

analizar, en nuestro caso Cubo_Ventas. Aparece una ventana emergente en la que
aparecen los campos que se escogieron para hacer el análisis. Para rellenar la tabla
dinámica, solo necesitas drag y drop los campos.

Fig. 3.19: “Reporte Generado en Access”

41
 Para generar un reporte gráfico, lo único que se tiene que hacer es buscar la
herramienta Insertar Gráfico. Aquí se le puede dar formato de presentación y escoger
el tipo de gráfico sea barras, radial, etc.
A continuación, se presenta un reporte gráfico sobre el cubo_ventas de DEXUR
E.I.R.Ltda.

Fig. 3.20: “Gráfico Generado en Access”

Hasta aquí se realizo todos los pasos de Modelamiento de un Datawarehouse haciendo uso de la
herramienta OLAP.
De los cubos generados, se hará un análisis de Minería de Datos, si la empresa así lo establece,
pero ese es otro tema de investigación que no se desarrollará en el presente informe.

42
 CONCLUSIONES

1. Las bases de datos operacionales por sus características propias y su rigidez en el diseño
y funcionalidad no permiten realizar con facilidad el análisis de los datos que esta
alberga.

2. El Datawarehouse usa un esquema mucho mas flexible, bajo esta concepción es posible
crear una arquitectura que se adecue a los requerimientos de información del individuo
que será usuario de este sistema, variando así su estructura de un usuario a otro,
corroborando que un sistema de estas características esta orientado al sujeto.

3. Para realizar análisis de tendencias, comparaciones, etc., es necesario contar con datos
que no estén siendo modificados constantemente pero si que sean incrementados, esta
es una peculiaridad del Datawarehouse, por ello es la herramienta precisa para realizar
este tipo de actividades.

4. El desarrollo de un sistema de DW es diferente al desarrollo de un sistema operacional.

A grandes rasgos, uno apoya al negocio transaccional y el otro al decisional.

5. La implementación de un DW corporativo ayudara a DEXUR a tomar decisiones

empresariales a partir de su data almacenada en un DW y procesada con herramientas
OLAP

6. El proceso de ETL y DTS de la base de datos de la empresa se realizo usando

tecnología SQL Server 2000

43
 RECOMENDACIONES

1. A los encargados del área de Tecnologías de la Información, formular proyectos de

desarrollo de herramientas de análisis de información como parte de los objetivos
estratégicos del Plan de Sistemas institucional.

2. A los ejecutivos de la institución, tomar sus decisiones con la ayuda de herramientas

que le permitan analizar el comportamiento y las tendencias de las variables que
determinan las reglas del negocio y manejan el aspecto operativo transaccional del
mismo.

3. A los encargados del desarrollo de sistemas, realizar la toma de los requerimientos de

información a los usuarios que serán beneficiarios del sistema de ayuda a la toma de
decisiones de modo que el diseño del modelo OLAP sea coherente y este alineado con
los objetivos estratégicos de la Institución.

44
 REFERENCIAS

a. BIBLIOGRAFICAS

• Campos Rimarachin, Heli. Manual de Elaboración de un DataWarehouse. En:

Taller Datawarehouse de Principio a Fin. Perú: MUG Huancayo; 2004
• Microsoft Corporation. “SQL Server Developer’s Guide to OLAP with Analysis
Services”. Sybex. USA; 2001.
• Heredia Mayer, Juan Carlos. Monografía : Datawarehouse. Perú ;2004
• Mallqui Shicshe, Maria. Informe: Inteligencia de Datos en Distribuidora Aranda
SA. Perú; 2004
• Uceda Pérez, Luis. En: V Curso de Actualización Ingeniería de Computación y
Sistemas. Informe: Prototipo de DW SEDAM - Huancayo; 2005
• Morales Zapata, Carlos. Data Modeling for DW. Perú, 2005

b. ELECTRONICAS

• Denominación Vancouver. USA; 2002 [fecha de acceso 22 de Agosto de 2007]

URL disponible en http://www.fisterra.com/recursos_web/mbe/vancouver.asp
• Campos Rimarachin, Heli. Desarrollando un Datawarehouse [Diapositiva]. Perú.
2004. 35 Diapositivas.
• Fredatawarehouse.com. USA; 2005 [fecha de acceso 21 de Agosto de 2007] URL
disponible en
http://freedatawarehouse.com/tutorials/dmtutorial/Step%20By%20Step%20Design.aspx
• Tutorialhotline. USA; 2005 [fecha de acceso 21 Octubrede 2007] URL disponible en
http://www.tutorialshotline.com/rolap.html
• Campos Rimarachin, Heli. Datawarehousing y OLAP [Diapositiva]. Perú. 2004. 64
Diapositivas.
• Microsoft Technet. Datawarehouse with SQL 2000. [fecha de acceso 21 d
Setiembre de 2007]. URL disponible en
http://www.microsoft.com/technet/prodtechnol/sql/2000/reskit/parts/#top

45
 • Carvajal, Jhon. ODBC (Open Database Connectivity) y su utilización en Excel.
2005[ fecha de acceso 21 de Agosto de 2005] URL disponible en
http://www.monografias.com
Guevara M, Flores C. AllFusion Edwin Data Modeler. 2002 [fecha de acceso 13 de Agosto de
2005] URL disponible en http://www.librosdigitales.com

46