Universidad Nacional de Ingeniera

Facultad de Ingeniera Industrial y de Sistemas

Escuela Profesional de Ingeniera de Sistemas
Tesis presentada para obtener el grado de
Ingeniero de Sistemas
Dise no y Construcci on de un Data Mart de Informaci on
Externa de Mercado para una Entidad nanciera en el Per u
por
Quispe Loayza Gabriel 20010034J
Lima - UNI
Junio de 2009
Dise no y Construcci on de un Data Mart de Informaci on
Externa de Mercado para una Entidad nanciera en el
Per u
Quispe Loayza Gabriel
23 de julio de 2009
De Gabriel Quispe Loayza:
Quiero dedicar esta tesis, que representa el ultimo esfuerzo de mi carrera de ingeniero de sistemas,
a la persona m as importante en mi vida, mi madre; Candy Loayza Palomino, cuyo esfuerzo ha he-
cho posible este logro, el cual no es mo, sino suyo. Tambi en a mi padre; Marcelo Quispe Palomino
y a mis hermanos; Mary, edna,Sonia y Nora, por el apoyo que me brindaron durante tantos a nos
de estudio, por su cari no, su comprensi on, pero sobre todo por haberme ayudado a formar lo poco
que he aprendido.
Dise no y Construcci on de un Data Mart de
Informaci on Externa de Mercado para una
Entidad nanciera en el Per u
Quispe Loayza Gabriel 20010034J
Facultad de Ingeniera Industrial y de Sistemas, 2009
Asesor de Tesis: Mag. Oporto Diaz Samuel
Involucrado totalmente en temas nancieros y con buena experiencia en procesos nancieros y
bancarios nos permitieron proponer esta tesis. Donde viendo las necesidades del sistema nanciero,
se propone construir una herramienta capaz de ayudar a los analistas de marketing, de una entidad
nanciera, tomar desiciones de m as calidad, cuando se se trata de tener una herramienta OLAP
que integre bases de datos internas y externas a la entidad Fiananciera.
Design and Construction of Data Mart of
External Information of Market for a
Financial institution in the Peru
Quispe Loayza Gabriel 20010034J
Faculty of Industrial Engineering and Systems, 2009
Major Professor: Mag. Oporto Diaz Samuel
Involved totally in nancial topics and with good experience in nancial processes and bank
employee they allowed to propose this thesis us. Where seeing the needs of the nancial system,
he proposes to construct a tool capable of helping the analysts of marketing, of a nancial insti-
tution, helping desiciones with more quality, when it is a question of having a tool OLAP that
integrates(repays) internal external bases of and information to the Financier entity.

Indice general
1. Introducci on y Planteamiento del Problema 10
1.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2. Descripci on de la situaci on problem atica . . . . . . . . . . . . . . . . . . . . . . . 12
1.3. Descripci on del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4. Objetivo de la Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.1. Objetivo superior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.2. Objetivo principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.3. Objetivos especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5. Justicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.1. Limitaciones de la Investigaci on . . . . . . . . . . . . . . . . . . . . . . . 15
2. Revisi on de la bibliografa 16
2.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1. Fundamentos B asicos del procesamiento analtico en lnea (On-Line Ana-
lytical Processing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2. Data Mart como sistema inform atico con alta disponibilidad y conabilidad 17
2.1.3. Denici on de Datawarehouse de Bill Inmon . . . . . . . . . . . . . . . . . 17
2.1.4. Denici on de Datawarehouse de Ralph Kimball . . . . . . . . . . . . . . . 18
2.1.5. Cubos de informaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2. El negocio bancario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3. Metologa de R. Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1. Lneas de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3. Descripci on de Datos 24
3.1. descripcion de los datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1. La fuente de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2. Estadstica descriptiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.3. Casos de analisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4. Metologa de soluci on 29
4.1. Modelo de soluci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4
5. Paso 1 de 5: Requerimientos de Negocio 32
5.1. Preparaci on de Entrevistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2. Resumen de Entrevistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3. Bus Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6. Paso 2 de 5: Lnea tecnol ogica 36
6.1. Arquitectura Tecnol ogica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Selecci on e Instalaci on de productos. . . . . . . . . . . . . . . . . . . . . . . . . . 37
7. Paso 3 de 5: Linea de datos 38
7.1. Modelo Dimensional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2. Modelo Fisico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.3. ETL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Paso 4 de 5: Lnea de Aplicaci on 41
8.1. Dise no del BI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.2. Desarrollo del BI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Despliegue 42
9.1. Dise no del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.2. Demostraci on 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.2.1. Desarrollo del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.2.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.3. Demostraci on 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.3.1. Desarrollo del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.3.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.4. Demostraci on 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.4.1. Desarrollo del experimento . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.4.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10. Conclusiones 43
10.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.2. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.3. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A. Classical and Romantic: How Two Styles Express Passion 45
A.1. Mendelssohn vs. Tchaikovsky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.1.1. Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.1.2. Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.2. Summation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5
B. Classical and Romantic: How Two Styles Express Passion 47
B.1. Mendelssohn vs. Tchaikovsky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.1.1. Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.1.2. Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.2. Summation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6

Indice de cuadros
1.1. Perdidas por producto nanciero . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7

Indice de guras
1.1. Modelo de negocio; EF:Entidad Financiera, SBS: Superintendencia de Banca y
Seguros, DWH: Base de Datos OLAP,RCD: Reporte Crediticio Deudor, RCC:
Reporte Crediticio Consolidado . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2. Duraci on promedio de la obtenci on de bases potenciales para campa nas y cantidad
de bases para campa nas al mes y la cantidad de personas requeridas en promedio,
en una entidad nanciera mediana del per u . . . . . . . . . . . . . . . . . . . . . . 14
1.3. Cantidad de recursos usados para la obtenci on de informaci on . . . . . . . . . . . 15
2.1. Ciclo de Vida de R. Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2. Proceso de Denici on de requerimientos de Kimball . . . . . . . . . . . . . . . . 22
3.1. Fuentes de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2. Periodo mes o mes del reporte SBS . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Cuenta contable de la SBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Longitud del campo de documento de Identidad de ls SBS . . . . . . . . . . . . . 26
3.5. Clasicaci on del documento de Identidad rcc . . . . . . . . . . . . . . . . . . . . 26
3.6. Clasicaci on del documento de Identidad de BD Interna . . . . . . . . . . . . . . 27
3.7. Clasicaci on del documento de Identidad de BD Externa . . . . . . . . . . . . . . 27
3.8. Longitud del campo de documento de Identidad de BD Externa . . . . . . . . . . . 27
3.9. Estadisticas de Fuentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Motodologa de Soluci on de R. Kimball . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Proceso de Denici on de requerimientos de Kimball . . . . . . . . . . . . . . . . 30
5.1. Matriz de Negocio de Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1. Arquitectura Tecnol ogica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Modelo Dimensional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2. MODELO FISICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.3. Esquema ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.1. dddd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8
Dise no y Construcci on de un Data Mart de
Informaci on Externa de Mercado para una
Entidad nanciera en el Per u
Como t ecnica se usar a el modelamiento dimensional OLAP, el modelo de datos resultante se
alimentar a de una fuente datos de una Entidad Financiera, la SBS y Bases de clientes externas
(ESSALUD, SUNAT).

Esta t ecnica es parte importante en la construcci on de una herramienta que
incremente el grado de integraci on de bases de datos externas con bases de datos internas de una
Entidad nanciera en el sistema nanciero peruano (ver cuadro ??).
9
Captulo 1
Introducci on y Planteamiento del Problema
1.1. Introducci on
El sistema nanciero peruano contiene aproximadamente cinco millones de personas que repor-
tan deuda en alguna entidad nanciera. Doscientas entidades nancieras entre bancos, mutuales,
nancieras, cajas rurales, etc. La SBS (SUPERINTENDENCIA DE BANCA Y SEGUROS) como
ente regulador a creado un sistema de informaci on, donde uno de sus principales objetivos es in-
tegrar y compartir informaci on de persona deudoras de todo el Per u asign andoles; varios atributos
que sirven como base para los an alisis de riesgo de cr edito, an alisis comercial para obtener nuevos
nichos de mercado, etc.
El gr aco resume la interacci on entre entidades nancieras (EF) y la SBS, en el sistema -
nanciero peruano (SFP). Para una entidad nanciera (EF) se resalntan los principales macro proce-
sos, los cuales requieren informaci on del sistema nanciero peruano (SFP) o mercado nanciero
nacional (Per u). El area de Riesgos de y el area de Tecnologas de Informaci on o TI son procesos
de apoyo pero sus necesidades son muy importantes para el negocio nanciero (TI y Riesgos se
Figura 1.1: Modelo de negocio; EF:Entidad Financiera, SBS: Superintendencia de Banca y Se-
guros, DWH: Base de Datos OLAP,RCD: Reporte Crediticio Deudor, RCC: Reporte Crediticio
Consolidado
10
consideraran como usuarios intermedios). Si consideramos los objetivos comerciales de la Enti-
dad nanciera; el area Comercial y Marketing son usuarios nales en la ya mencionada Entidad
nanciera.
Una Entidad nanciera o EF, como miembro del sistema nanciero peruano, necesita informaci on
que la SBS distribuye, con el n de que las entidades puedan gestionar mejor sus recursos; in-
formaci on, dinero, tiempo, etc. La informaci on que brinda la SBS es abundante (4 archivos) con
alrededor de 10 G de datos por cada periodo mensual, esta informaci on por s sola no es util para
los expertos de negocio. Estos datos necesitan ser procesados, trasformados y validados contra las
bases de datos propias del banco, como por ejemplo; sus maestros de clientes, bases potenciales de
clientes, Bases de datos de campa nas, bases negativas, etc. Las t ecnicas de Datawarehousing ayu-
dan al procesamiento de estos datos transaformandola en informaci on, arrojando como producto
nal una herramienta para uso de los espertos de negocio mas conocida como Data Mart.
En el captulo 2 Informaci on externa de mercado dene a todas las variables e indicadores
que est an presentes en el mercado nanciero peruano respecto al negocio bancario. La SBS como
ente regulador facilita esta informaci on a cada banco del Per u en formatos llamados RCC (Re-
porte Crediticio Deudor) y RCCD (Reporte Crediticio Deudor Detalle). Estas dos fuentes de
informaci on sumados a otras fuentes de datos externas como por ejemplo; Bases de SUNAT, RE-
NIEC, ESALUD, etc confoman la informaci on externa de mercado. Esta informaci on de personas
y deudas es analizada para encontrar nuevos nichos de mercado, identicar clientes potenciales y
evitar otorgar cr edito a personas consideradas con alto grado de riesgo, etc.
El RCC contiene informaci on referente a personas que tienen alguna forma de cr edito en el
mercado nanciero peruano; se identica a la persona por un n umero de documento, la calicaci on
asignada por la SBS, se puede diferenciar si la persona es jurdica o natural, se tiene tambi en el
nombre y apellido.
El documento RCCD informa sobre el banco o entidad nanciera que facilita el cr edito a la
persona y el monto en soles asociado a la deuda o cr edito. En el captulo 3 de este documento se
presenta la fuente de datos y se describe los datos usados en esta investigaci on de manera detallada.
En el captulo 4 se presenta el modelo de soluci on usando tecnicas de modelamiento Dimen-
sional OLAP, se detalla la estrategia para la construcci on de la herramienta OLAP y como podr a ser
usada por los expertos de negocio.
En el captulo 5 La limpieza de datos, implica el procesamiento de datos, esto es, preparar a
la data para que el modelo de pronostico se ejecute de la manera m as optima posible, limpiar y
transformar la data para que el modelo de predicci on aprenda de manera correcta y optima. La
estrategia de limpieza de datos es la de quitar los nulos, eliminar extremos y reemplazar los carac-
teres por n umeros.
11
1.2. Descripci on de la situaci on problem atica
Una entidad nanciera peruana en el sistema nanciero peruano requiere una sistema de in-
formaci on para an alisis de informaci on con el n de que sus expertos de negocio tengan una her-
ramienta que les ayude a realizar y completar an alisis seg un las necesidades del negocio.
Se ha demostrado que el crecimiento de las empresas es directamente proporcional a la ve-
locidad con que estas enfrentan a sus competidores, esto signica tener informaci on consolidada y
lista para ser usada con un alto grado de disponibilidad (100 porciento). Los expertos de negocio
opinan que tener una herramienta como un DATA MART da grandes posibilidades de encontrar
nuevos nichos de mercado y/o reaccionar r apidamente frente a las estrategias del oponente en este
caso los otros bancos.
Una alternativa viable es que el especialista de negocio (para este caso; especialistas comer-
ciales) cuenten con una herramienta f acil de usar y que este disponible en todo momento y que
muestre por supuesto informaci on validada y muy conable. Esta alternativa se la llama DATA
MART.
Los elementos que se tomaran en cuenta son:
1. Validaci on de la informaci on Cada entidad nanciera ha identicado y puesto en operaci on
procesos de validaci on y vericaci on de datos de cliente y no clientes minimizando el riesgo
de error, lo que signica que cada entidad nanciera requiere proceso de validaci on y control
de calidad de datos que aseguren la calidad de informaci on.
2. Informaci on pre-procesada Las necesidades del mercado obligan a los expertos de negocio
necesitan indicadores y variable cuyos c alculos requieren varios pasos y una buena capaci-
dad de computadoras, estos indicadores deben estar listos y ya est an pre-calculados y listos
para el uso de los usuarios.
3. Deudor del sistema nanciero peruano El deudor de una entidad nanciera viene a ser
la persona natural o jurdica que solicita el cr edito nanciero o pr estamo y su solicitud es
aprobada y validad seg un los procedimientos de validaci on y vericaci on de la entidad -
nanciera. Los procedimientos de validaci on de informaci on impactan de manera directa en el
riesgo de cr edito sin embargo este factor no ser a considerado para nes de no desnaturalizar
12
el objetivo de esta investigaci on.
4. Informaci on externa de mercado dene a todas las variables e indicadores que est an pre-
sentes en el mercado nanciero peruano respecto al negocio bancario. La SBS como ente reg-
ulador facilita esta informaci on a cada banco del Per u en formatos llamados RCC (Reporte
Crediticio Deudor) y RCCD (Reporte Crediticio Deudor Detalle). Estas dos fuentes de
informaci on sumados a otras fuentes de datos externas como por ejemplo; Bases de SUNAT,
RENIEC, ESALUD, etc confoman la informaci on externa de mercado. Esta informaci on de
personas y deudas es analizada para encontrar nuevos nichos de mercado, identicar clientes
potenciales y evitar dar cr edito a personas consideradas con alto grado de riesgo, etc.
5. Habito de pago Se dene como el comportamiento del cliente nanciero respecto al cumplim-
iento de sus obligaciones con la entidad nanciera, es decir para el C odigo de h abito igual a
cero implica que el cliente es nuevo en sistema nanciero.
Para el H abito de pago igual a uno indica la calicaci on del cliente en el periodo MES in-
mediatamente anterior, respecto al mes en que fue generada la informaci on. An alogamente
para el H abito de pago igual a dos indica la calicaci on del cliente dos meses atr as respecto a
mes en que fue generada la informaci on. tomar el tema, usted puede plantear nuevas t ecnicas
de abordar el problema o comparar t ecnicas.
1.3. Descripci on del problema
Actualmente la Entidad Financiera no cuenta con una herrmamienta OLAP que contenga infor-
maci on transformada, pre-procesada y validada proveniente de bases de datos; internas, externas
de personas y Deudas del mercado nanciero peruano, dentro del ambito de la informaci on externa
de mercado.
1.4. Objetivo de la Investigacion
1.4.1. Objetivo superior
Construir una herrmamienta OLAP que disminuya en cincuenta por ciento el tiempo de ob-
tenci on bases para campa nas a paritr de bases de datos internas cruzadas con bases de datos las
externas, dentro del ambito de la informaci on externa de mercado de una entidad nanciera.
13
Figura 1.2: Duraci on promedio de la obtenci on de bases potenciales para campa nas y cantidad de
bases para campa nas al mes y la cantidad de personas requeridas en promedio, en una entidad
nanciera mediana del per u
1.4.2. Objetivo principal
Consolidar en un solo modelo de datos todos los datos de personas, clientes y no clientes.
Usando como fuente de datos; bases de datos internas, bases de datos externas y informaci on de la
SBS todo esto dentro del ambito de la informaci on externa de mercado de una entidad nanciera
en el Per u.
1.4.3. Objetivos especcos
Tener todos los atributos de la persona cliente y no cliente en un solo repositorio con indi-
cadores de mercado nanciero, segmentaciones y calicaciones pre-procesadas.
1.5. Justicaci on
Los diferentes problemas que circundan al obtener informaci on consolidada e integrada del
banco y la SBS. Justican que hay raz on suciente para construir una herramienta que sea capaz
de ayudar a un especialista de negocio a tomar decisiones, estos problemas pueden ser por ejemplo:
Excesivo uso de recursos; tiempo y personas, para obtener informaci on consolidada e in-
tegrada del banco y la SBS .
La no disponibilidad de datos cuando m as se necesitan, por ejemplo en campa nas comer-
ciales por temas coyunturales; reacci on ante campa nas de la competencia.
Grandes tiempos utilizados en manipulaci on de datos, lo que signica que; obtener informa-
ci on integrada sea imposible tenerla en un plazo muy corto (un da).
Necesidad de los expertos de negocio en contar con una herramienta con datos preprocesa-
dos, que se use para an alisis de informaci on del mercado nanciero peruano
Se muestra un cuadro donde se observan las perdidas asociadas a cada producto nanciero en
un Banco, solo hasta noviembre el 2008, los montos son en billones de soles; los especialistas y
expertos de negocio tienen que ejecutar mucho trabajo para identicar las principales razones de
estas perdidas, por no contar con unba herramienta OLAP que les sirve de soporte a los an alisis.
14
Figura 1.3: Cantidad de recursos usados para la obtenci on de informaci on
Pr estamos Monto P erdida signica
efectivo 12 3.6 0.30
Tarjeta 3 7 0.10
Hipotecas 2 9 0.13
Cuadro 1.1: Perdidas por producto nanciero
1.5.1. Limitaciones de la Investigaci on
En el presente documento se detallar an; como se usan la t ecnicas de modelamiento de datos
Dimencional u OLAP y la metodologia de Ralp Kimball para construir una herramienta para ben-
ecio de una entidad nanciera en el Per u, en cuanto a la informaci on contenida en las bases de
datos referida a esta herramienta, es importante rescatar que; debe estar necesariamente dentro del
ambito de la informaci on externa de mercado ya denida en este documento.
15
Captulo 2
Revisi on de la bibliografa
2.1. Antecedentes
2.1.1. Fundamentos B asicos del procesamiento analtico en lnea (On-Line
Analytical Processing)
OLAP es el acr onimo en ingl es de procesamiento analtico en lnea (On-Line Analytical
Processing). Es una t ecnica utilizada cuando se quiere agilizar la consulta de grandes cantidades
de datos. Para ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datos
resumidos de grandes Bases de datos o Sistemas Transaccionales (OLTP). Se usa en informes de
negocios como; comparativos de ventas en el tiempo, gesti on de campa nas de marketing, informes
de direcci on, minera de datos y tableros de control.
La raz on de usar OLAP para las consultas es la velocidad de respuesta. Una base de datos rela-
cional almacena entidades en tablas discretas si han sido normalizadas. Esta estructura es buena en
un sistema OLTP pero para las complejas consultas multitabla es relativamente lenta. Un modelo
mejor para b usquedas (aunque peor desde el punto de vista operativo) es una base de datos multi-
dimensional.
OLAP es el acr onimo en ingl es de procesamiento analtico en lnea (On-Line Analytical
Processing). Es una t ecnica utilizada cuando se quiere agilizar la consulta de grandes cantidades
de datos. Para ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datos
resumidos de grandes Bases de datos o Sistemas Transaccionales (OLTP). Se usa en informes de
negocios como; comparativos de ventas en el tiempo, gesti on de campa nas de marketing, informes
de direcci on, minera de datos y tableros de control.
La raz on de usar OLAP para las consultas es la velocidad de respuesta. Una base de datos
relacional almacena entidades en tablas discretas si han sido normalizadas. Esta estructura es bue-
na en un sistema OLTP pero para las complejas consultas multitabla es relativamente lenta. Un
16
modelo mejor para b usquedas (aunque peor desde el punto de vista operativo) es una base de datos
multidimensional.
La principal caracterstica que potencia a OLAP, es que es lo m as r apido a la hora de ejecutar
sentencias SQL de tipo SELECT, en contraposici on con OLTP que es la mejor opci on para opera-
ciones de tipo INSERT, UPDATE Y DELETE.
2.1.2. Data Mart como sistema inform atico con alta disponibilidad y con-
abilidad
Un Data Mart es un sistema inform atico con alta disponibilidad y conabilidad que ha sido
modelado y preparado para el an alisis exhausto de datos respecto a un proceso especico y para
este se aplicar a dentro del negocio bancario.
Un Data Mart es resultado de tener informaci on consolidada ODS (Operational data Store
o repositorio de datos a nivel de detalle) a todo el proceso de integraci on se le suele conocer
como Datawarehousing. Es importante resaltar que en la pr actica el uso de un ODS es muy raro
pues su construcci on equivale a un modelo de datos corporativo que se alimenta de muchos sis-
temas OLTP en los cuales existe informaci on no integrada cada uno con est andares diferentes y en
plataformas diversas. El objetivo primordial de un ODS es que la construcci on de los Data Marts
sea transparente y que todos usen como fuente de datos al ODS.
Las empresas necesitan ser competitivas, conocer a sus clientes, conocer en que grupo de
clientes concentrarse, etc. Se ha demostrado que el crecimiento de las empresas es directamente
proporcional a la velocidad con que estas enfrentan a sus competidos, esto signica que tener
informaci on consolidada y casi lista para ser usada con un alto grado de disponibilidad es primor-
dial. Los expertos de negocio opinan que tener una herramienta como un DATA MART da
grandes posibilidades de encontrar nuevos nichos de mercado y/o reaccionar r apidamente
frente a las estrategias del oponente en este caso los otros bancos del sistema nanciero peruano.
Una alternativa viable es que el especialista de negocio (para este caso; especialistas comerciales)
cuenten con una herramienta f acil de usar y que est e disponible en todo momento y que muestre
por supuesto informaci on validada y muy conable. Esta alternativa se la llama DATA MART
basada en un ODS.
2.1.3. Denici on de Datawarehouse de Bill Inmon
Bill Inmon fue uno de los primeros autores en escribir sobre el tema de los almacenes de datos,
dene un data warehouse (almac en de datos) en t erminos de las caractersticas del repositorio de
datos:
17
Orientado a temas.- Los datos en la base de datos est an organizados de manera que todos los
elementos de datos relativos al mismo evento u objeto del mundo real queden unidos entre
s.
Variante en el tiempo.- Los cambios producidos en los datos a lo largo del tiempo quedan
registrados para que los informes que se puedan generar reejen esas variaciones.
No vol atil.- La informaci on no se modica ni se elimina, una vez almacenado un dato, este
se convierte en informaci on de s olo lectura, y se mantiene para futuras consultas.
Integrado.- La base de datos contiene los datos de todos los sistemas operacionales de la
organizaci on, y dichos datos deben ser consistentes.
Inmon deende una metodologa descendente (top-down) a la hora de dise nar un almac en de
datos, ya que de esta forma se considerar an mejor todos los datos corporativos. En esta metodologa
los Data marts se crear an despu es de haber terminado el data warehouse completo de la organi-
zaci on.
2.1.4. Denici on de Datawarehouse de Ralph Kimball
Este es otro conocido autor en el tema de los data warehouse, dene un almac en de datos co-
mo: una copia de las transacciones de datos especcamente estructurada para la consulta
y el an alisis. Tambi en fue Kimball quien determin o que un data warehouse no era m as que: la
uni on de todos los Data marts de una entidad. Deende por tanto una metodologa ascendente
(bottom-up) a la hora de dise nar un almac en de datos.
Top-down y Bottom-up son estrategias de procesamiento de informaci on caractersticas de
las ciencias de la informaci on, especialmente en lo relativo al software. Por extensi on se aplican
tambi en a otras ciencias humanas y cientcas.
En el modelo Top-down se formula un resumen del sistema, sin especicar detalles. Cada parte
del sistema se rena dise nando con mayor detalle. Cada parte nueva es entonces redenida, cada
vez con mayor detalle, hasta que la especicaci on completa es lo sucientemente detallada para
validar el modelo. El modelo Top-down se dise na con frecuencia con la ayuda de cajas negras
que hacen m as f acil cumplir requerimientos aunque estas cajas negras no expliquen en detalle los
componentes individuales.
En contraste, en el dise no Bottom-up las partes individuales se dise nan con detalle y luego
se enlazan para formar componentes m as grandes, que a su vez se enlazan hasta que se forma
el sistema completo. Las estrategias basadas en el ujo de informaci on bottom-up se antojan
potencialmente necesarias y sucientes porque se basan en el conocimiento de todas las variables
que pueden afectar los elementos del sistema.
18
2.1.5. Cubos de informaci on
Los cubos de informaci on o cubos OLAP funcionan como los cubos de rompecabezas en los
juegos, en el juego se trata de armar los colores y en el data warehouse se trata de organizar los
datos por tablas o relaciones; los primeros (el juego) tienen 3 dimensiones, los cubos OLAP tienen
un n umero indenido de dimensiones, raz on por la cual tambi en reciben el nombre de hipercubos.
Un cubo OLAP contendr a datos de una determinada variable que se desea analizar, proporcionando
una vista l ogica de los datos provistos por el sistema de informaci on hacia el data warehouse, esta
vista estar a dispuesta seg un unas dimensiones y podr a contener informaci on calculada. El an alisis
de los datos est a basado en las dimensiones del hipercubo, por lo tanto, se trata de un an alisis
multidimensional.
Ala informaci on de un cubo puede acceder el ejecutivo mediante tablas din amicas en una hoja
de c alculo o a trav es de programas personalizados. Las tablas din amicas le permiten manipular las
vistas (cruces, ltrados, organizaci on, totales) de la informaci on con mucha facilidad. Las difer-
entes operaciones que se pueden realizar con cubos de informaci on se producen con mucha rapidez.
Llevando estos conceptos a un data warehouse, este es una colecci on de datos que est a formada
por dimensiones y variables, entendiendo como dimensiones a aquellos elementos que participan
en el an alisis y variables a los valores que se desean analizar.
Dimensiones
Las dimensiones de un cubo son atributos relativos a las variables, son las perspectivas de
an alisis de las variables (forman parte de la tabla de dimensiones). Son cat alogos de infor-
maci on complementaria necesaria para la presentaci on de los datos a los usuarios, como
por ejemplo: descripciones, nombres, zonas, rangos de tiempo, etc. Es decir, la informaci on
general complementaria a cada uno de los registros de la tabla de hechos.
Variables
Tambi en llamadas indicadores de gesti on, son los datos que est an siendo analizados. For-
man parte de la tabla de hechos. M as formalmente, las variables representan alg un aspecto
cuanticable o medible de los objetos o eventos a analizar. Normalmente, las variables son
representadas por valores detallados y num ericos para cada instancia del objeto o evento
medido. En forma contraria, las dimensiones son atributos relativos a la variables, y son uti-
lizadas para indexar, ordenar, agrupar o abreviar los valores de las mismas. Las dimensiones
poseen una granularidad menor, tomando como valores un conjunto de elementos menor que
el de las variables; ejemplos de dimensiones podran ser: productos, localidades (o zonas),
el tiempo (medido en das, horas, semanas, etc.).
2.2. El negocio bancario
El nanciamiento de una empresa est a representado por los recursos utilizados para adquirir
los activos necesarios para desarrollar negocios. Una de estas fuentes es proporcionada por las
19
entidades del sistema nanciero, a las cuales pertenecen los bancos. Una entidad bancaria tiene
su propia matriz insumo - producto, capta recursos va dep ositos, los que conjuntamente con su
capital propio, son colocados en negocios viables mediante cr editos bajo diversas modalidades.
Usualmente una empresa realiza ambas operaciones con los bancos, sus excedentes de caja los
deposita buscando el mejor rendimiento y al menor riesgo posible, y sus necesidades de caja los
nancia con cr editos bancarios en complemento del capital aportado por sus accionistas o socios.
Toda empresa requiere de recursos nancieros para desarrollar sus actividades comerciales, sea
para adquirir activos jos o para disponer de capital de trabajo que permita maniobrar los activos
con la nalidad de manufacturar bienes o prestar servicios a sus clientes. Los recursos nancieros
constituyen el capital de la empresa, el cual puede ser de propiedad de los accionistas o de terceros.
El capital de los accionistas constituye el capital propio de la empresa, el cual est a formado por el
aporte inicial y las utilidades que reporta el negocio. El capital de terceros son las deudas aportadas
por los acreedores, los cuales b asicamente son proveedores de la empresa o entidades nancieras
que otorgan cr editos.
En negocios peque nos es usual que el nanciamiento de las actividades proviene del aporte
propio de los accionistas o socios de la empresa. Conforme el negocio crece, es deseable y posible
obtener nanciamiento de terceros. En negocios medianos y grandes, el nanciamiento de terceros,
principalmente de las entidades nancieras, es usual.
En esta oportunidad nos dedicaremos al nanciamiento que otorgan las entidades del sistema
nanciero, en particular los bancos; tambi en haremos referencia a la captaci on de dep ositos, es
decir el proceso de intermediaci on nanciera.
El enfoque que presentamos es desde el punto de vista de una empresa interesada en obten-
er cr editos bancarios en las mejores condiciones, as como, de ser el caso, obtener rendimientos
atractivos para sus excedentes de liquidez.
2.3. Metologa de R. Kimball
Ilustra el ujo general de implementaci on de un DWH. Esta metodologa ayuda a identicar las
secuencias de tareas ordenadas y las actividades principales que debe suceder concurrentemente.
Las necesidades deben ser acomodadas para lograr una unica necesidad de la organizaci on. Ralf
Kimball en su libro del ciclo de vida de un DWH menciona que no todos los detalles de las tar-
eas del ciclo de vida deben ser ejecutados en todos los proyectos de construcci on de un DWH
(Datawarehouse).
En la gura 4.1
2.3.1. Lneas de Desarrollo
Luego de denir los requerimientos del negocio, enfocar el proyecto a tres lneas (tracks) con-
currentes:
De Tecnologa
De Datos
20
Figura 2.1: Ciclo de Vida de R. Kimball
De Aplicaciones de BI
El ujo de actividad de las lneas, se indican por las echas La dependencia entre tareas se indican
por el alineamiento vertical de la gura de la metodologa de R. Kimball.
1. Planicaci on del programa/proyecto Visi on de programas y proyectos de Kimball. Proyec-
to, se reere a una iteraci on simple del KLC Desde el lanzamiento hasta el despliegue.
Programa, se reere a la amplia coordinaci on progresiva de recursos, infraestructura, tiempos
y comunicaci on a trav es de m ultiples proyectos Un programa contiene proyectos m ultiples
En la realidad los programas no necesariamente inician antes del proyecto, aunque debera
ser as.
Planicar un proyecto:
Denir el alcance
Identicar tareas
Programaci on de tareas.
Planicar el uso de los recursos.
Asignar la carga de trabajo a los recursos.
El documento nal representa un plan del proyecto.
2. Requerimientos del negocio El exito de un proyecto de datawarehouse de la compresi on de
las necesidades del negocio.
Es importante los requerimientos de uso de informaci on, se tiene que conocer los tipos
de informaci on que los expertos de negocio requieren o necesitan. tambi en se necesita
comprender y conocer los tipos de an alisis que se elaboran en la organizaci on.
Los requemientos de datos, deben incluir:
Fuente de datos
21
Procesis de Calidad de datos y Limpieza de datos
Almacenamiento de datos.
Procesos de carga de datos.
Proceso de denici on de requerimiento.
Figura 2.2: Proceso de Denici on de requerimientos de Kimball
Dise no de la Matriz de negocio, Relaciona los procesos organizacionales a las entidades
u objetos que participan en el proceso. Cada la es un proceso y cada columna una
dimensi on.
Existe un etapa de recolecci on de requerimientos.
El an alisis de los resultados experimentales, se dene quien hara esta recolecci on,
se clasica a los usuarios en; Ejecutivos Senior, Administradores de Departamentos
Clave, Analistas de Negocio, DBA de sistemas transaccionales y personal de TI.
Los Ejecutivos Senior le dar an un sentido de direcci on y alcance para el almac en de
datos.
3. Linea Tecnologica Marco arquitectural completo de la soluci on. Basado en la arquitectura
t ecnica dise nada, Evaluaci on y selecci on de:
22
Plataforma de hardware
DBMS (base de datos)
Herramienta ETL
Herramientas de consultas (query tools)
Herramienta de reportes
4. Linea de datos
Modelo Dimensional, Contiene los mismos datos y relaciones que un modelo normal-
izado en la 3FN, pero estructurado de manera diferente. Se ejecutan an alisis de los
datos de un proceso de negocio para:
identicar la granularidad de las tablas de hechos
dimensiones y atributos asociados
hechos num ericos
Modelo Fsico, se modela el modelo que se replejar a en la base de datos. Tambien se
prepara la seguridad apropiada. Existe una estrategia preliminar de anamiento (tuning)
de indexaci on y agregaci on
ETL Es la fase m as importante. Corresponde al 70 por ciento del riesgo y esfuerzo de
un proyecto de DWH. Capacidades de sistema ETL:
Extracci on
Limpieza y conformidad
Entrega y administraci on
Los datos en bruto son extrados de los sistemas operacionales y transformados en
informaci on signicativa para el negocio. Los procesos ETL deben dise nados mucho
antes que cualquier datos sea extrada de la fuente, se verica la calidad de los datos de
entrada y las condiciones de calidad de datos se controlan continuamente.
5. Linea de Aplicaci on del BI Aplicaciones que consultan, analizan y presentan informaci on
desde el modelo dimensional, las aplicaciones BI entregan valor al negocio desde la solu-
ci on DWH y la meta es entregar capacidades al negocio para soportar y mejorar la toma de
decisiones.
Dise no de Aplicaciones BI, Se identica las aplicaciones de BI candidatas y interfaces
de navegaci on apropiadas, tambi en se orienta las necesidades de los usuarios y se pro-
duce la especicaci on de las aplicaciones BI.
Desarrollo de aplicaciones BI, Se hace la conguraci on de la metadata del negocio y
de la infraestructura de herramientas luego de si es necesario se ejecuta la construcci on
y validaci on de aplicaciones BI analticas y operacionales y un portal de navegaci on.
6. Despliegue
23
Captulo 3
Descripci on de Datos
Para la construcci on de la herramienta OLAP, se usar an fuentes internas y fuentes externas. Las
fuentes internas esta compuesto por las bases de datos interna (PIF Plataforma Integral de persona)
y la fuentes de datos expernas con la informaci on proveniente de la SBS, SUNAT y RENIEC.
Figura 3.1: Fuentes de datos
3.1. descripcion de los datos
3.1.1. La fuente de datos
1. Fuentes Internas
PIF o Plataforma integral de Personas, es el sistema del banco en donde se resgistran
las solicitudes de las personas. Las personas solicitan nuevos creditos, ampliaciones de
24
Figura 3.2: Periodo mes o mes del reporte SBS
credito, etc.
2. Fuentes externas
Archivos de la SBS, son exactamente 4 archivos; RCC, RCCD, Entidades nancieras,
Catalogo de cuentas Contables.
RCC es el reporte crediticio Consolidado que contiene el detalle de las personas
que son clientes de alguna entidad nanciera en el Per u.
RCCD es el reporte que contiene el detalle de deudas de la personas en el sistema
nanciero peruano.
Entidades Financieras es el archivo donde se detallan todas las entidades nancieras
que act uan en el sistema nanciero Peruano.
Cat alogo de cuentas Contables es el reporte donde se detalla las descripciones de
las cuentas contables. Las cuentas contables son cuentas similares a las cuentas
usadas en contabilidad y que sirven para agrupar a las deudas de las personas.
3.1.2. Estadstica descriptiva
1. Tabla Fuente 1 de la fuente SBS: RCCD
Campo 1 del RCCD: PERIODOMES
En el graco 3.5 mostramos los valores de este concepto en la fuente SBS. Algunos
valores ejemplo son 200905 para mayo del 2009.
Campo 2 del RCCD: CUENTACONTABLE
En el graco 3.5 mostramos los valores de este concepto en la fuente SBS. Algunos
valores ejemplo son 200905 para mayo del 2009.
Campo 3 del RCCD: Numero de documento El tipo de documento de identidad indica
si el documento de la persona es un DNI, Carnet de extranjeria, Carnet de policia, etc.
Es notable que el DNI identica a la mayoria de las personas del todas las fuentes.
En el graco ?? mostramos los valores de este concepto en la fuente SBS.
2. Tabla Fuente 2 de la fuente SBS: RCC
25
Figura 3.3: Cuenta contable de la SBS
Figura 3.4: Longitud del campo de documento de Identidad de ls SBS
Campo 1 del RCC: TIPODOCUMENTO El tipo de documento de identidad indica si
el documento de la persona es un DNI, Carnet de extranjeria, Carnet de policia, etc. Es
notable que el DNI identica a la mayoria de las personas del todas las fuentes.
En el graco 3.5 mostramos los valores de este concepto en la fuente SBS.
3. Tabla Fuente 3 de la fuente BD Interna: CLIENTE
Campo 1 de CLIENTE: TIPODOCUMENTO
En el graco 3.6 mostramos los valores de este concepto en la fuente SBS.
4. Tabla Fuente 5 de la fuente EXT: BASEEXT
Campo 1 de BASEEXT: TIPODOCUMENTO El tipo de documento de identidad in-
dica si el documento de la persona es un DNI, Carnet de extranjeria, Carnet de policia,
etc. Es notable que el DNI identica a la mayoria de las personas del todas las fuentes.
En el graco ?? mostramos los valores de este concepto en la fuente SBS.
Campo 2 de BASEEXT: NUMERODOCUMENTO
En el graco 3.8 mostramos los valores de este concepto en la fuente SBS.
Figura 3.5: Clasicaci on del documento de Identidad rcc
26
Figura 3.6: Clasicaci on del documento de Identidad de BD Interna
Figura 3.7: Clasicaci on del documento de Identidad de BD Externa
Figura 3.8: Longitud del campo de documento de Identidad de BD Externa
27
Figura 3.9: Estadisticas de Fuentes
En el graco mostramos, la cantidad de registros CR, cantidad de columnas RC y la cantidad
de datos por cada fuente principal. La cantidad de datos se calcula apartir de la multiplicaci on de
CRxRC este dato se muestra en millones.
28
Captulo 4
Metologa de soluci on
4.1. Modelo de soluci on
Figura 4.1: Motodologa de Soluci on de R. Kimball
En la gura 4.1
1. Requerimientos del negocio El exito de un proyecto de datawarehouse de la compresi on de
las necesidades del negocio.
Es importante los requerimientos de uso de informaci on, se tiene que conocer los tipos
de informaci on que los expertos de negocio requieren o necesitan. tambi en se necesita
comprender y conocer los tipos de an alisis que se elaboran en la organizaci on.
Los requemientos de datos, deben incluir:
Fuente de datos
Procesis de Calidad de datos y Limpieza de datos
Almacenamiento de datos.
Procesos de carga de datos.
Proceso de denici on de requerimiento.
29
Figura 4.2: Proceso de Denici on de requerimientos de Kimball
Dise no de la Matriz de negocio, Relaciona los procesos organizacionales a las entidades
u objetos que participan en el proceso. Cada la es un proceso y cada columna una
dimensi on.
Existe un etapa de recolecci on de requerimientos.
El an alisis de los resultados experimentales, se dene quien hara esta recolecci on,
se clasica a los usuarios en; Ejecutivos Senior, Administradores de Departamentos
Clave, Analistas de Negocio, DBA de sistemas transaccionales y personal de TI.
Los Ejecutivos Senior le dar an un sentido de direcci on y alcance para el almac en de
datos.
2. Linea Tecnologica Marco arquitectural completo de la soluci on. Basado en la arquitectura
t ecnica dise nada, Evaluaci on y selecci on de:
Plataforma de hardware
DBMS (base de datos)
Herramienta ETL
Herramientas de consultas (query tools)
Herramienta de reportes
3. Linea de datos
Modelo Dimensional, Contiene los mismos datos y relaciones que un modelo normal-
izado en la 3FN, pero estructurado de manera diferente. Se ejecutan an alisis de los
datos de un proceso de negocio para:
30
identicar la granularidad de las tablas de hechos
dimensiones y atributos asociados
hechos num ericos
Modelo Fsico, se modela el modelo que se replejar a en la base de datos. Tambien se
prepara la seguridad apropiada. Existe una estrategia preliminar de anamiento (tuning)
de indexaci on y agregaci on
ETL Es la fase m as importante. Corresponde al 70 por ciento del riesgo y esfuerzo de
un proyecto de DWH. Capacidades de sistema ETL:
Extracci on
Limpieza y conformidad
Entrega y administraci on
Los datos en bruto son extrados de los sistemas operacionales y transformados en
informaci on signicativa para el negocio. Los procesos ETL deben dise nados mucho
antes que cualquier datos sea extrada de la fuente, se verica la calidad de los datos de
entrada y las condiciones de calidad de datos se controlan continuamente.
4. Linea de Aplicaci on del BI Aplicaciones que consultan, analizan y presentan informaci on
desde el modelo dimensional, las aplicaciones BI entregan valor al negocio desde la solu-
ci on DWH y la meta es entregar capacidades al negocio para soportar y mejorar la toma de
decisiones.
Dise no de Aplicaciones BI, Se identica las aplicaciones de BI candidatas y interfaces
de navegaci on apropiadas, tambi en se orienta las necesidades de los usuarios y se pro-
duce la especicaci on de las aplicaciones BI.
Desarrollo de aplicaciones BI, Se hace la conguraci on de la metadata del negocio y
de la infraestructura de herramientas luego de si es necesario se ejecuta la construcci on
y validaci on de aplicaciones BI analticas y operacionales y un portal de navegaci on.
5. Despliegue
31
Captulo 5
Paso 1 de 5: Requerimientos de Negocio
El Objetivo de este capitulo es comprender las necesidades del negocio bancario, dentro del
ambito de necesidades de informaci on externa de mercado, tomando como ejemplo un caso partic-
ular; una Banco del Per u. Se siguen los pasos seg un el capitulo n umero cuatro o metodologa de la
soluci on, seguiremos la secuencia descrita en el proceso de denici on de requerimientos descritos
en dicho capitulo:
5.1. Preparaci on de Entrevistas.
EL objetivo de la preparaci on de las entrevistas es tener listo una lista de preguntas que se har an
a los expertos de negocio.
Cu ales son los elementos que se toman en cuenta cuando se hacen an alisis del mercado
externo?
C omo una persona obtiene una tarjeta de cr edito de este banco?
Describa el an alisis de consumos de tarjetas de Cr edito que usted maneja
Describa la actividad de una persona consumidora de tarjetas de cr edito en el mercado -
nanciero peruano.
Qu e m etricas utiliza para evaluar los consumos de tarjetas de Cr editos?
C omo se calculan estas m etricas?
Es importante el tiempo o temporalidad en tus an alisis?
C omo se determinan las tendencias?
Pero y cu al o cu ales son los usos m as importantes de los an alisis que usted lidera?
32
5.2. Resumen de Entrevistas.
Entrevista al jefe de producto de tarjetas de cr editos del banco
Nombre: Jorge Malca Rodriguez
Cargo: Jefe de Producto
Preparaci on: Ingeniero Industrial
Cu ales son los elementos que se toman en cuenta cuando se hacen an alisis del mercado
externo?
Los elementos m as importantes que se necesitan son; variables a nivel de Persona, es decir, por
ejemplo edad, sexo, ocupaci on, documento de indenticaci on que sea unico. Por otro lado nos
intersa hacer conocer indicadores a nivel de:
entidades nancieras (bancos, nancieras, cajas rurales, etc.) tambi en es muy importante
conocer los atributos de la entidad nanciera, su agrupaci on (Grupos empresariales, etc.).
Agrupaci on de cuentas contables las cuales identican al producto nanciero seg un la SBS.
estas agrupaciones son; (grupo de productos), el producto y el sub producto.
A no, semestres, trimestre, mes. No es necesario conocer a nivel de da, tengo entendido que
no hay informaci on externa a nivel de da.
C omo una persona obtiene una tarjeta de cr edito de este banco?
Una persona natural o jurdica es evaluada en funci on a par ametros como ingreso menual, edad,
profesi on u ocupaci on, deudas en otros bancos, etc. Luego como resultado de esta evaluaci on el
banco decide si la persona est a calicada para obtener un cr edito mediante una tarjeta de cr edito.
Para nuestro banco el vender una tarjeta cr edito se llama colocar una tarjeta de cr edito. Luego el
objetivo del banco es que esta persona use la tarjeta de cr edito.
Describa el an alisis de consumos de tarjetas de Cr edito que usted maneja
Luego de revisar un n umero de reportes (alrededor de 4 o 5), identico las tendencias y cambios
signicativos en el comportamiento del consumidor de tarjetas de cr editos del mercado nanciero
sin perder de vista estas mismas variaciones pero de los clientes de nuestro banco.
Describa la actividad de una persona consumidora de tarjetas de cr edito en el mercado -
nanciero peruano
Primero la persona necesita tener una tarjeta de cr edito vigente emitida por alguna entidad -
nanciera en el mundo, para el Per u son v alidas las tarjetas con membresa; VISA, MASTERCARD,
American Express, Diners, etc. Cuando una persona ya tiene una tarjeta de cr edito tiene en general
dos opciones usarla o no usarla. Si la persona llega a usar la tarjeta, puede ser para alguno de los
siguientes objetivos:
33
1. Para consumo, es decir para comprar cualquier bien, en una entidad que acepte la tarjeta de
cr edito.
2. Para adquirir dinero en efectivo o tambi en llamada Cr edito efectivo.
Bueno luego de usar su tarjeta de cr edito, la persona se convierte en deudora de un cr edito en
el sistema nanciero peruano, la SBS le denomina DEUDOR. El nanciamiento de estas deudas
es de un mes a m as. Luego de que la persona ha utilizado la tarjeta de cr edito, la persona est a obli-
gada a pagar una cuota mensual al banco hasta que pague el total de su deuda y sus intereses
correspondientes. Una vez que la persona a cumplido con pagar la deuda entonces tiene la potestad
de informar al banco que ya no desea tener la tarjeta de cr edito y la entidad nanciera, como por
ejemplo un banco, anula la tarjeta de cr edito. Tambi en tiene la potestad de decidir y seguir con la
tarjeta de cr edito para un uso potencial futuro.
Que m etricas utiliza para evaluar los consumos de tarjetas de Cr editos?
Cantidad de consumos, Monto de los consumos, cantidad tarjetas no usadas, cantidad tarjetas no
usadas de otros bancos, tambi en nos interesa conocer para cada persona cual es la tarjeta que mas
usa, en que banco tiene mayor deuda una persona, cual es la deuda total de la persona en tarjetas
de cr edito, etc.
Como se calculan estas m etricas
Cabe resaltar primero que para obtener esta informaci on requerimos de la ayuda de nuestros anal-
istas de bases de datos que realizan todos los c alculos.
1. Cantidad de consumos, Monto de los consumos, cantidad tarjetas; de los reportes que nos
enva la SBS (archivos RCC y RCCD) diferenciamos primero los clientes del nuestro ban-
co con los clientes de otros bancos. Tambi en obtenemos los atributos principales de estos
clientes y no clientes (datos como edad, nombres, DNI, profesi on, sexo, demografa, etc.).
Inmediatamente despu es de tener esta base de clientes y no clientes ya podemos contar la
cantidad de consumos hechos por nuestros clientes y tambi en por los clientes de otros ban-
cos. An alogamente al proceso anterior se puede encontrar el monto de los consumos, la
cantidad de tarjetas usadas diferenciadas por clientes y no clientes.
2. Para saber cual es la tarjeta que mas usa una persona se encuentran todas las tarjetas que
tiene una persona, se identica el monto de la lnea disponible de la tarjeta de cr edito y su
saldo de deuda si la tuviera. Luego se compara tarjeta con tarjeta y se dene la tarjeta con
mayor deuda en el mercado nanciero.
3. Para la deuda total de la tarjeta de cr edito se suman todas las deudas de cada tarjeta de cr edito
y se obtiene un total que representa la deuda total por uso de tarjetas de cr edito.
Es importante el tiempo o temporalidad en tus an alisis?
Por supuesto todos nuestros indicadores son evaluados seg un el a no, mes, trimestre y/o semestre
que corresponde. Hacemos reportes comparativos donde se muestran las tendencias de consumos
34
de tarjetas de cr edito.
Como se determinan las tendencias?
Reviso las actividades mes a mes y se compara un mes de un a no contra el mismo mes de los a nos
anteriores o el a no anterior solamente. Para el tema de las tendencias se usan varios a nos por lo
general 3 a 4 a nos.
Pero y cual o cuales son los usos mas importantes de los an alisis que usted realiza?
Son varios, por ejemplo tenemos a la obtenci on de bases de clientes para nuestras campa nas de
tarjetas de cr edito. Tenemos tambi en que elaborar los reportes que nos pide el area de riesgos.
Conozco tambi en que el equipo de riesgos usa esta informaci on para hacer sus an alisis de riesgo
que tambi en entrega a la SBS y eso est a normado bajo pena multa si no se cumplen los tiem-
pos. Nosotros como area de marketing usamos esta informaci on para conocer el perl de nuestros
clientes y por supuesto ejecutar estrategias de CRM o delizaci on del cliente.
Y el area de marketing en general, tambi en usa las mismas m etricas?
Es correcto.
5.3. Bus Matrix
El resultado de las entrevistas y el data prole nos ayudan a identicar los procesos de negocio
que son importantes y las dimensiones que participan en el proceso. Es importante resaltar que no
se destacan los procesos de toda la organizaci on, si no los procesos que se encuentran dentro del
ambito de informaci on externa de mercado del banco.
Figura 5.1: Matriz de Negocio de Kimball
35
Captulo 6
Paso 2 de 5: Lnea tecnol ogica
6.1. Arquitectura Tecnol ogica.
Figura 6.1: Arquitectura Tecnol ogica
6.2. Selecci on e Instalaci on de productos.
Plataforma de hardware Para prop osito del prototipo se requiere Computador pentium IV
o superior de 2.5 Ghz con una RAM de 2 GB.
36
Base de datos Se requiere base de datos SQL Server 2000 o superior.
Herramienta ETL SQL Analizer y DTS 2000.
Herramienta de consulta SQL Analyzer.
Herramienta de Reportes Analices Services 2000.
37
Captulo 7
Paso 3 de 5: Linea de datos
7.1. Modelo Dimensional.
El modelo dimensional est a conformado por una tabla FACT o de hechos y cinco tablas .
1. PERSONA Identica a la persona deudora del Sistema Financiero nacional, es la persona
que la SBS reporta en el archivo RCC.
2. ENTIDAD O ENTIDAD FINANCIERA Identica a la Entidad Financiera presente en
el sistema nanciero Peruano, estas pueden ser Bancos, Financieras, Cajas Rurales, Cajas
Municipales y cualquier otra entidad nanciera que este presente en el sistema nanciero
peruano y que la SBS lo reporte en el RCC.
3. PRODUCTOIdentica al Producto que se origina de la agrupaci on de las cuentas reportadas
en la SBS, estos productos ser an organizados en una jerarqua (Jerarqua de productos).
El nivel de granularidad de esta dimensi on se dene seg un el data prole:
a) Grano no El tipo de producto.
b) Grano grueso Agrupaci on de Producto.
4. TIEMPO Momento en el tiempo en el cual se envi o el reporte RCC, esta fecha hace refer-
encia al mes en una a no dado. El nivel de granularidad de esta dimension es el MES.
Figura 7.1: Modelo Dimensional
38
Figura 7.2: MODELO FISICO
Tabla de hechos La tabla de hecho o Fact Table es la tabla donde se guardar a a los hechos, para
este caso el HECHO es la deuda de un cliente en el sistema nanciero peruano, que es reportada
mensualmente. El mnimo nivel de granularidad del hecho esta denido por una PERSONA, TIPO
PRODUCTO, TIEMPO y ENTIDAD.
7.2. Modelo Fisico.
A continuaci on se muestra el dise no sico, que se optiene a partir del modelo de datos.
7.3. ETL.
El proceso ETL o de extracci on, transformaci on y carga de datos se esquematiza de la siguiente
manera. Donde I (I1, I1, I1 hasta In) denen a las Interfaces de 1 hasta n y cada Interfase hace
referencia a un archivo de entrada ya sea Excel, archivo plano y/o tabla que proviene de cualquier
plataforma de BD.
39
Figura 7.3: Esquema ETL
40
Captulo 8
Paso 4 de 5: Lnea de Aplicaci on
8.1. Dise no del BI.
8.2. Desarrollo del BI.
41
Captulo 9
Despliegue
9.1. Dise no del experimento
9.2. Demostraci on 1
9.2.1. Desarrollo del experimento
9.2.2. Conclusiones
9.3. Demostraci on 2
9.3.1. Desarrollo del experimento
9.3.2. Conclusiones
9.4. Demostraci on 3
9.4.1. Desarrollo del experimento
9.4.2. Conclusiones
42
Captulo 10
Conclusiones
10.1. Conclusiones
Esta es la secci on el tesista presenta los resultados obtenidos luego del avance logrado en su
investigaci on, debe de indicar en qu e medida ha logrado resolver el problema planteado, es muy
importante que el tesista justique cada una de sus conclusiones, no debe de indicar creencias ni
armaciones ambiguas.
Las siguientes armaciones no son conclusiones v alidas:
1. El trabajo es interesante.
2. El trabajo ha sido novedoso.
3. Nos ha costado bastante tiempo y esfuerzo para desarrollar este trabajo.
4. Tuvimos muchas reuniones para el desarrollo de este trabajo.
5. Creemos que hemos logrado resolver el problema planteado.
6. No hemos logrado terminar el estudio por que no hemos tenido tiempo.
Las conclusiones de su trabajo deben de indicar:
1. Conclusiones respecto al tama no de la poblaci on y de la muestra que nalmente usaron.
2. Resultados del proceso de experimentaci on, por ejemplo resultados esperado que no se
dieron.
3. Resultados obtenidos en cada actividad (objetivos especcos) necesaria para lograr el obje-
tivo.
4. En qu e medida los instrumentos de la investigaci on apoyaron en medir las variables del
dise no de la investigaci on.
43
5. En qu e medida el modelo de soluci on planteado al inicio fue modicado a medida que la
investigaci on avanzaba.
6. An alisis de los algoritmos usados.
7. Los resultados obtenidos luego de probar cada una las hip otesis.
8. Las conclusiones obtenidas nalmente luego de analizar los resultados de todas las hip otesis.
Las siguientes conclusiones son v alidas, en todos los caso se debe de indicar referencias a
secciones o partes de su documento.
1. El total del software estudiado es de 168,595 instalaciones, 97,968 con licencia y 70,627 sin
licencia (ver cuadro 10).
2. El nivel de licenciamiento en las instituciones estudiadas es del 58 % y el porcentaje de
instalaciones sin licencia es del 42 % (ver cuadro 77).
3. El sector que tiene el mayor porcentaje de instalaciones en relaci on a los otros sectores
(10.55 %) seguido por el sector salud (9.38 %) y por el sector Transportes (9.17 %). Por otro
lado el sector con la menor cantidad total de instalaciones es Comercio Exterior (1.02 %),
seguido por Trabajo y Promoci on Social (1.60 %) y Producci on (2.015 %) (ver cuadro 88).
4. En relaci on a la hip otesis se puede armar que pron osticar el demanda considerando uno o
m as grupos proporciona mejores resultados que considerando solo un grupo.
5. El rendimiento de proceso de clasicaci on medido con el indicar MAPE es del 97 %.
10.2. Contribuciones
Las contribuciones corresponde a conclusiones signicativas que ha logrado en el transcurso
de su investigaci on, por ejemplo.
1. Tama no de la muestra que es recomendable usar en investigaciones semejantes.
2. Valores de par ametros en el dominio de la investigaci on.
3. Opciones probadas donde no se obtuvieron resultados satisfactorios.
10.3. Trabajos Futuros
Se indica posibles ampliaciones o mejoras de su trabajo que puede ser desarrollado por otro
investigador en el futuro.
En que se puede ampliar la investigaci on?
44
Ap endice A
Classical and Romantic: How Two Styles
Express Passion
There are many misconceptions about the differences between the classical and romantic
styles. The rst of these is the term romantic. Romantic music is not romantic is the sense of
romance or love. In this case, it refers to a story[1]. Other differences between these two styles
include a difference in melody. The classical style has melodies in 4m + 4m phrases, that will
usually climb to some type of goal. The romantic style has lyrical melodies that are asymmetrical
and arranged in almost endless phrases.
Both classical and romantic pieces can be lled with passion. Just as different vehicles will
transport people, different styles of music will evoke passion in the minds of the listeners.
A.1. Mendelssohn vs. Tchaikovsky
The Mendelssohn Violin Concerto in e minor is considered an example of a classical piece.
Even though the Concerto is a very passionate piece and not at all like the music of Mozart or
Haydn, Mendelssohn has used much of the traditional classical form. Tchaikovskys Romeo and
Juliet, on the other hand, is considered and example of a romantic piece. There is no longer a
true melody: only the addition of instrumental colors to the texture of the piece[4].
A.1.1. Differences
These chords highlight another difference in the two style of composition: harmony. Mendelssohn
uses chords to support the melody. The orchestra is frequently supporting the soloist, or playing
chords in the same rhythm for a tutti section. Mendelssohn also stays away from the remote keys.
Tchaikovsky, in the romantic style, uses chords more for color, rather than for supporting the
melody. Romeo and Juliet also modulates to very remote keys, quite a contrast from the style of
Mendelssohn.
45
A.1.2. Structures
Even the basic structure of these two pieces is different. Mendelssohn has structured his piece
much like a classical piece[2]. Tchaikovsky begins to develop the piece from the beginning. All the
winds are playing, and the strings are whispering to themselves. This is how Tchaikovsky develops
his themes[3]. He develops constantly, not all at once as the classical composers did.
A.2. Summation
Technically, the classicists and the romanticists are properly named. The music termed
romantic is conned to music with a program, and a certain style. D. Grout in A History of Western
Music calls the Violin Concerto in e minor a work as romantic as the Italian Symphony or the
Hebrides Overture, but on to which not the slightest suggestion of program has ever been attached.
Both the classical and romantic styles can express passion, they differ only in form.
46
Ap endice B
Classical and Romantic: How Two Styles
Express Passion
There are many misconceptions about the differences between the classical and romantic
styles. The rst of these is the term romantic. Romantic music is not romantic is the sense of
romance or love. In this case, it refers to a story[1]. Other differences between these two styles
include a difference in melody. The classical style has melodies in 4m + 4m phrases, that will
usually climb to some type of goal. The romantic style has lyrical melodies that are asymmetrical
and arranged in almost endless phrases.
Both classical and romantic pieces can be lled with passion. Just as different vehicles will
transport people, different styles of music will evoke passion in the minds of the listeners.
B.1. Mendelssohn vs. Tchaikovsky
The Mendelssohn Violin Concerto in e minor is considered an example of a classical piece.
Even though the Concerto is a very passionate piece and not at all like the music of Mozart or
Haydn, Mendelssohn has used much of the traditional classical form. Tchaikovskys Romeo and
Juliet, on the other hand, is considered and example of a romantic piece. There is no longer a
true melody: only the addition of instrumental colors to the texture of the piece[4].
B.1.1. Differences
These chords highlight another difference in the two style of composition: harmony. Mendelssohn
uses chords to support the melody. The orchestra is frequently supporting the soloist, or playing
chords in the same rhythm for a tutti section. Mendelssohn also stays away from the remote keys.
Tchaikovsky, in the romantic style, uses chords more for color, rather than for supporting the
melody. Romeo and Juliet also modulates to very remote keys, quite a contrast from the style of
Mendelssohn.
47
B.1.2. Structures
Even the basic structure of these two pieces is different. Mendelssohn has structured his piece
much like a classical piece[2]. Tchaikovsky begins to develop the piece from the beginning. All the
winds are playing, and the strings are whispering to themselves. This is how Tchaikovsky develops
his themes[3]. He develops constantly, not all at once as the classical composers did.
B.2. Summation
Technically, the classicists and the romanticists are properly named. The music termed
romantic is conned to music with a program, and a certain style. D. Grout in A History of Western
Music calls the Violin Concerto in e minor a work as romantic as the Italian Symphony or the
Hebrides Overture, but on to which not the slightest suggestion of program has ever been attached.
Both the classical and romantic styles can express passion, they differ only in form.
48
Bibliografa
[1] Stan Augarten. Bit by Bit, An Illustrated History of Computers. Tricknor and Fields, 1984.
[2] L. Peter Deutsch and Edward A. Taft. Requirements for an experimental programming envi-
ronment. Technical Report CSL-80-10, Xerox Palo Alto Research Center, June 1980.
[3] Daniel H. H. Ingalls. Design principles behind smalltalk. Byte, August 1981.
[4] Larry Tesler. The smalltalk environment. In Byte, August 1981.
49
Vita
Zufrecio Alegre Lectorio Dulce naci o en Per u, Departamento de Lima, el 29 de febrero de
1984. Ingres o a la Universidad Nacional de Ingeniera en Agosto del 2001. Actualmente se de-
sempe na como practicante en la empresa ARENA SAC y como docente en la academia SIEM-
PREUNI.
Palermo Ston, Pedro Adelante naci o en Per u, Departamento de Lima, el 29 de febrero de
1986. Ingres o a la Universidad Nacional de Ingeniera en Agosto del 2001. Actualmente se de-
sempe na como practicante en la empresa GOLITO SAC y como docente en la academia INGRE-
SAMOSSIEMPRE.
LA PRESENTE PRE-TESIS FUE TIPOGRAFIADA CON L
A
T
E
X POR QUISPE LOAYZA GABRIEL Y
.
c
Quispe Loayza Gabriel
2009
Figura B.1: dddd
51