Embed Size (px)
Citation preview
UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIÓN DE INGENIERÍA DE COMPUTACIÓN
DISEÑO Y DESARROLLO DE SISTEMA DE INTELIGENCIA DE NEGOCIOS EN EL
SECTOR FINANCIERO
Por:
Daniel Alejandro Ciuffi Álvarez
INFORME DE PASANTÍA
Presentado ante la Ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de
Ingeniero de Computación
Sartenejas, octubre de 2012
UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIÓN DE INGENIERÍA DE COMPUTACIÓN
DISEÑO Y DESARROLLO DE SISTEMA DE INTELIGENCIA DE NEGOCIOS EN EL
SECTOR FINANCIERO
Por:
Daniel Alejandro Ciuffi Álvarez
Realizado con la asesoría de:
Tutor Académico: Marlene Goncalves
Tutor Industrial: Eduardo Sojo
INFORME DE PASANTÍA
Presentado ante la Ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de
Ingeniero de Computación
Sartenejas, octubre de 2012
iv
Resumen
En el presente proyecto se desarrolló un sistema de extracción, procesamiento y
carga de datos financieros desde unas bases de datos de origen hacia una base de
datos histórica. Como resultados de la pasantía, se obtuvieron tres productos: un
paquete que ejecuta el proceso de extracción, procesamiento y carga de datos, un
esquema para la visualización de los datos y un conjunto de reportes
correspondientes a distintas vistas de los datos, destinado a los usuarios finales de
la aplicación. El desarrollo del proyecto está enmarcado en la fase de desarrollo de la
metodología de entrega de servicios de Microsoft, utilizada para proyectos de
consultoría, y las herramientas utilizadas fueron el manejador de bases de datos
SQL Server 2008 de Microsoft y tres de sus complementos para desarrollo de
soluciones empresariales: SQL Analysis Services, SQL Integration Services y SQL
Reporting Services.
v
Índice general
Resumen ………………………………………………………………………………………. iv
Índice general …………………………………………………………………………………. v
Índice de tablas ……………………………………………………………………………... viii
Índice de figuras ……………………………………………………………………………… ix
Lista de abreviaturas ………………………………………………………………………… x
Introducción …………………………………………………………………………………… 1
1. DESCRIPCIÓN DE LA EMPRESA …………………………………………………….. 2
2. DESCRIPCIÓN DEL PROBLEMA ……………………………………………………... 5
3. MARCO TEÓRICO ………………………………………………………………………… 7
3.1. Inteligencia de Negocios ………………………………………………………………... 7
3.2. Almacén de Datos ……………………………………………………………………….. 8
3.3. SQL ………………………………………………………………………………………. 14
4. MARCO TECNOLÓGICO ………………………………………………………………. 17
4.1. SQL Server ……………………………………………………………………………… 17
4.1.1. Servicios adicionales de SQL Server …………………………………………….... 17
4.1.1.1. Servicios de Análisis ………………………………………………………………. 17
4.1.1.2. Servicios de Generación de Reportes …………………………………………… 19
4.1.1.3. Servicios de Integración ………………………………………………………….. 19
4.1.1.4. Estudio de Administración de SQL Server ……………………………………. 21
4.1.1.5. Business Intelligence Development Studio ……………………………………. 22
vi
4.1.2. Programación ………………………………………………………………………… 22
5. DESCRIPCIÓN DE LA SOLUCIÓN ………………………………………………….. 24
5.1. Bases de datos ………………………………………………………………………….. 26
5.2. Generador de datos aleatorios en tablas de origen ……………………………….. 27
5.2.1. Procedimiento del aplicativo “Efectos” …………………………………………… 28
5.2.2. Procedimiento del aplicativo “Factoring” ………………………………………… 28
5.2.3. Procedimiento del aplicativo “Prestamos” ……………………………………….. 29
5.2.4. Procedimiento del aplicativo “Leasing” …………………………………………... 29
5.2.5. Procedimiento del aplicativo “Sobregiros” ……………………………………….. 29
5.2.6. Procedimiento del aplicativo “Medios de pago” …………………………………. 29
5.3. Scripts de carga y transformación de datos ………………………………………... 30
5.3.1. Primer script, ’00.Universo.sql’ ……………………………………………………. 30
5.3.2. Segundo script, ’02.Factoring.sql’ …………………………………………………. 31
5.3.3. Procedimiento para inserción directa sobre la tabla AT04 de SIF …………… 32
5.3.4. Scripts adicionales …………………………………………………………………… 32
5.4. Extracción y carga ……………………………………………………………………... 32
5.4.1. Inserción de registros en las tablas de dimensión de la base de datos
Prototipo …………………………………………………………………………………… 32
5.4.2. Flujo de datos desde la tabla AT04 de la base de datos SIF hasta la tabla AT04
de la base de datos Prototipo …………………………………………………………… 34
5.5. Elaboración del cubo OLAP con Analysis Services mediante la herramienta
Business Intelligence Development Studio ……………………………………………... 35
vii
5.6. Elaboración del paquete de flujo de datos con Integration Services mediante la
herramienta Business Intelligence Development Studio ……………………………... 38
5.7. Consulta …………………………………………………………………………………. 39
6. PRUEBAS Y RESULTADOS …………………………………………………………… 42
Conclusiones y recomendaciones …………………………………………………………. 44
Referencias …………………………………………………………………………………… 46
A. INFORMACIÓN SOBRE LAS TABLAS DE LAS BASES DE DATOS …………. 49
B. REGISTROS DE EJEMPLO SUMINISTRADOS POR EL BANCO …………….. 53
C. PROCEDIMIENTOS PARA LA INSERCIÓN DE DATOS EN LAS TABLAS DE
ORIGEN ………………………………………………………………………………………. 62
D. POSIBLES VALORES PARA LOS DATOS ALEATORIOS INSERTADOS EN
LAS TABLAS DE ORIGEN ……………………………………………………………….. 79
E. DESCRIPCIÓN DE SCRIPTS DE CARGA Y TRANSFORMACIÓN DE DATOS
………………………………………………………………………………………………….. 87
F. SCRIPTS PARA CREACIÓN Y ELIMINACIÓN DE RESTRICCIONES DE
CLAVE E ÍNDICES EN LAS TABLAS DE LA BASE DE DATOS PROTOTIPO .. 101
G. VENTAJAS Y DESVENTAJAS DE UN DW ………………………………………. 109
viii
Índice de tablas
Tabla 5.1: Cálculos con nombre …………………………………………………………… 37
ix
Índice de figuras
Figura 1.1: Organigrama de Consultoría en Microsoft Venezuela ……………………. 4
Figura 3.1: Ejemplo de cubo ……………………………………………………………….. 10
Figura 3.2: Cubo después de pivotaje ……………………………………………………. 10
Figura 3.3: Cubo después de roll-up ……………………………………………………… 11
Figura 3.4: Cubo después de drill-down …………………………………………………. 12
Figura 3.5: Esquema en Estrella …………………………………………………………. 13
Figura 5.1: Arquitectura de la Solución …………………………………………………. 25
Figura 5.2: Modelo de datos del átomo 4 ………………………………………………… 36
Figura 5.3: Montos Vencidos Totales para créditos discriminados por aplicativo
(filas) y estado de crédito (columnas), cuya situación de crédito es ‘Litigio’ (filtro)
………………………………………………………………………………………………….. 38
Figura 5.4: Montos Vencidos Totales para créditos discriminados por fecha de
liquidación (filas) y naturaleza del cliente (columnas) ………………………………… 39
Figura 5.5: Cuotas Vencidas discriminadas para créditos por aplicativo (filas) y
situación de crédito (columnas), cuya fecha de cierre está en el año 2012 (filtro) … 39
Figura 5.6: Ejemplo del servidor de reportes …………………………………………… 40
Figura 5.7: Ejemplo de visualización del cubo en Excel ………………………………. 41
Figura 6.1: Tiempos de ejecución para el paquete de flujo …………………………… 42
x
Lista de abreviaturas
EM Engagement Manager, Gerente de Compromisos
SUDEBAN Superintendencia de Bancos
BI Business Intelligence, Inteligencia de Negocios
DW Data Warehouse, Almacén de Datos
OLAP Online Analytical Processing, Procesamiento Analítico en Línea
SQL Structured Query Language, Lenguaje Estructurado de Consultas
ANSI American National Standards Institute, Instituto de Estándares Nacionales
de Norteamérica
ISO International Organization for Standards, Organización Internacional para
Estándares
MOLAP Multidimensional OLAP, OLAP Multidimensional
ROLAP Relational OLAP, OLAP Relacional
MDX MultiDimensional eXpressions, Expresiones Multidimensionales
1
Introducción
El presente proyecto de pasantía forma parte de un proyecto de consultoría de
Microsoft Venezuela para el BBVA Banco Provincial, dentro de cuyos objetivos se
encuentra que el banco pueda contar con históricos de su información financiera y
contable. Con el apoyo de este trabajo de pasantía, el banco dispondrá de una
herramienta para evaluar su desempeño a lo largo del tiempo y, por lo tanto, para
tomar decisiones de negocio futuras.
Para ese fin, se ha propuesto la implementación de una solución que permita la
extracción de la información financiera y contable desde los sistemas de bases de
datos fuentes del banco, el procesamiento de dicha información para ajustarla a un
formato que facilite su consulta y su almacenamiento en una base de datos histórica.
En el presente proyecto de pasantía, se plantea como objetivo principal el
desarrollo de un prototipo que permita la extracción, procesamiento y
almacenamiento, tomando como referencia un subconjunto de las bases de datos del
banco, relacionado específicamente con la asignación de créditos por parte del banco,
y permita la exploración de los datos históricos obtenidos como consecuencia del
proceso.
El presente informe consta de cinco capítulos. En el primer capítulo, se hace una
pequeña descripción de la empresa y se muestra un organigrama del segmento de la
empresa en el cual se desarrolló el presente proyecto de pasantía. En el segundo
capítulo, se hace una descripción del problema al cual se pretendió dar solución con
lo desarrollado en el presente proyecto de pasantía. En el tercer capítulo, se hace
una descripción del marco tecnológico, es decir, de las herramientas utilizadas para
el desarrollo de la solución. En el cuarto capítulo, se hace una descripción de la
solución desarrollada. En el quinto capítulo, se muestran resultados de la ejecución
del proceso de extracción, procesamiento y carga para ciertos datos de prueba.
CAPÍTULO 1
DESCRIPCIÓN DE LA EMPRESA
Microsoft Corporation, establecida en 1975, es una corporación multinacional con
sede en Redmond, Washington, E.E.U.U., que desarrolla, fabrica, licencia y apoya
un amplio espectro de productos y servicios predominantemente relacionados con
computación. [1]
Microsoft de Venezuela, filial de Microsoft Corporation, establecida en el año 1991,
ha posicionado, desde sus inicios, sus productos y servicios a una gran cantidad de
Clientes Corporativos y de Pequeñas y Medianas Empresas, de manera directa o a
través de sus socios de negocios. [2]
Microsoft de Venezuela está dividida en varios segmentos, con un diverso espectro
de campos de acción, relacionados siempre con la tecnología Microsoft y la manera
en que esta contribuye a mejorar la eficiencia de los clientes de la compañía, tanto
internos como externos.
Dado que el proyecto de pasantía presentado en este informe se desarrolla en el
segmento de Servicios, y más específicamente en el área de Consultoría
perteneciente al mismo, se presenta a continuación una descripción general del
segmento y del área de Consultoría.
La misión del segmento de Servicios es la de “ayudar a los clientes y socios de
negocio a realizar su máximo potencial a través de la adopción y el uso productivo de
las tecnologías de Microsoft.” [3] En otras palabras, el segmento de Servicios de
Microsoft de Venezuela es el encargado del despliegue de la tecnología Microsoft en
las compañías venezolanas que requieran la implementación, automatización y/o
optimización de procesos susceptibles de ello en el seno de sus centros de operación a
través de herramientas informáticas.
3
Los servicios del área de Consultoría, a su vez, están diseñados para apoyar a los
clientes con la optimización y la implantación de las tecnologías Microsoft. [4]
Para la materialización de los servicios de Consultoría, existen tres figuras
principales en la subsidiaria. Dichas figuras son los EM (Engagement Manager,
Gerente de Compromisos), los gerentes de proyecto y los consultores. [3]
Los EM son los encargados de definir, el alcance de los proyectos, los planes de
ejecución de los mismos y los presupuestos. Para esto, piden los recursos humanos
que consideren necesarios, definen los tipos de los contratos, establecen las órdenes
de trabajo, hacen previsiones de ingresos, entre otros. [4]
Los gerentes de proyecto, por su parte, son los encargados de la planificación y la
organización de los proyectos. Ellos hacen un seguimiento del trabajo de los
consultores para asegurar que este se ajuste a los planes trazados previamente, se
encargan de las relaciones con los clientes y velan por la satisfacción de los mismos.
Además, realizan varias tareas administrativas y llevan un control de la ejecución
de los proyectos, haciendo los ajustes que consideren necesarios según lo que dicten
las circunstancias. [3]
Los consultores son los encargados de la ejecución de las tareas estipuladas para el
proyecto. Los mismos deben ejecutar las actividades tal y como fueron planeadas,
producir la documentación adecuada, asegurarse constantemente de la calidad del
trabajo realizado, colaborar y trabajar de manera armoniosa con el equipo de
trabajo, contribuir a la satisfacción del cliente y realizar las tareas administrativas
que les sean asignadas, tales como elaboración de reportes de avance, entre otros. [3]
El proyecto desarrollado en esta pasantía fue desarrollado bajo la tutoría
industrial de un consultor de Microsoft Venezuela. En la Figura 1.1, se muestra un
organigrama del área de Consultoría ubicada en el contexto del segmento de
Servicios de Microsoft Venezuela.
4
Figura 1.1: Organigrama de Consultoría en Microsoft Venezuela
CAPÍTULO 2
DESCRIPCIÓN DEL PROBLEMA
Para dar cumplimiento a una resolución de la Superintendencia de Bancos,
SUDEBAN, el BBVA Banco Provincial necesita generar información financiera y
contable bajo un formato y reglas suministradas por dicho ente regulador. La
aplicación de dichos formato y reglas debe estar reflejada, finalmente, en un
conjunto de archivos de transmisión, llamados Átomos. Los Átomos son archivos de
texto plano que se generarán mensualmente y que contendrán distintas
visualizaciones de los datos suministrados previamente por el banco.
Adicionalmente, el BBVA Banco Provincial necesita poder contar con históricos de
su información financiera y contable, con base en los Átomos generados mes a mes, y
generar consultas dinámicas y reportes sobre los mismos.
En función de la necesidad de BBVA, se ha definido un proyecto entre cuyas áreas
de trabajo se encuentra la generación de una arquitectura o plataforma de bases de
datos Átomos. La presente pasantía está enmarcada en la labor de la generación de
dicha arquitectura para uno de los Átomos, específicamente para el Átomo 4. Dicho
Átomo contiene información relacionada con la asignación de créditos por parte del
banco.
En primer lugar, la solución desarrollada en esta pasantía debe contemplar un
repositorio en el cual se almacenen datos originados por el banco, siempre
relacionados con los datos históricos que se quieran visualizar en el Átomo 4, es
decir, aquellos relacionados con la asignación de créditos. A esto se le ha llamado
bases de datos origen.
En la solución, debe existir también un conjunto de procesos que se encarguen de
extraer los datos de las bases de datos de origen, los transformen a fin de que
encajen con el formato definido para el Átomo 4 y los carguen en otra base de datos
6
intermedia. En dicha base de datos intermedia se cargarán los datos del mes más
reciente.
Debe haber, por último, un proceso que, una vez que el mes más reciente haya
terminado y los datos del mismo hayan sido transmitidos a SUDEBAN, lleve estos
datos a una base de datos histórica, a partir de la cual se generarán consultas
dinámicas y reportes de los históricos de la información financiera y contable.
CAPÍTULO 3
MARCO TEÓRICO
En el presente capítulo se presentan conceptos y nociones relacionados con los
elementos manejados durante el desarrollo del proyecto de pasantía y que se
consideran indispensables para la comprensión de lo explicado en los siguientes
capítulos. En primer lugar, se hace una pequeña introducción a lo que significa la
inteligencia de negocios. Posteriormente, se explican ciertas nociones relacionadas
con un almacén de datos. Por último, se hace una pequeña referencia al lenguaje
SQL, lenguaje por excelencia para la interacción con bases de datos relacionales.
3.1. Inteligencia de Negocios
BI (Business Intelligence, Inteligencia de Negocios) es un término empleado para
referirse a un conjunto de tecnologías de soporte a decisiones que permiten a
ejecutivos, gerentes y analistas tomar decisiones mejores y más rápidas. [5]
Las tecnologías BI proveen vistas históricas, actuales y predictivas de operaciones
de negocio. Entre las funciones comunes de las tecnologías de inteligencia de negocio
se pueden incluir elaboración de reportes, procesamiento analítico en línea, minería
de datos, procesamiento de eventos complejos, gerencia de desempeño de negocio,
análisis predictivo, entre otros. [5]
El objetivo de la inteligencia de negocios es dar apoyo a, y en consecuencia
mejorar, la toma de decisiones concernientes a un negocio. Por lo tanto, un sistema
BI puede ser llamado un sistema de soporte a decisiones. La inteligencia de negocios
usa tecnologías, procesos y aplicaciones para analizar datos estructurados y, en su
mayoría, internos de una compañía y procesos de negocio. [5]
8
La inteligencia de negocios puede ser utilizada para varios propósitos en un
negocio. En el caso específico del proyecto desarrollado para esta pasantía, se
pueden destacar:
a. Realización de mediciones relacionadas con cantidades de créditos entregadas
por el banco a clientes según el tipo de cliente, el tipo de crédito, la fecha de
liquidación del crédito, entre otros.
b. Facilidad en el análisis de dichas mediciones.
c. Elaboración de una infraestructura de generación de reportes.
d. Colaboración entre distintas áreas del banco, consolidando datos provenientes
de diversas fuentes para objetivos comunes.
3.2. Almacén de Datos
Un DW (Data Warehouse, Almacén de Datos) es un sistema de base de datos y,
como tal, posee una colección de información y un software de gestión. Sin embargo,
a diferencia de un sistema de base de datos relacional, está concebido para las
aplicaciones de toma de decisiones y es utilizado principalmente para la generación
de reportes y análisis. Los datos almacenados en el DW son obtenidos de sistemas de
bases de datos tradicionales. Dichos datos pueden pasar por bases de datos
intermedias para realizárseles operaciones adicionales necesarias para que puedan
ser usados en el DW para hacer reportes. [6]
Los datos sobre los cuales las tareas de inteligencia de negocios trabajan se
encuentran típicamente en los DW. Sin embargo, esto no es necesariamente así. Una
definición amplia de BI incluiría elementos como integración de integración de
datos, calidad de datos, almacenamiento de datos, gerencia de datos, análisis de
contenidos y otros. Sin embargo, es importante ver a la preparación de los datos y al
uso de los datos como dos segmentos distintos, si bien relacionados íntimamente, de
la inteligencia de negocios. [5]
9
Típicamente, un DW utiliza capas de preparación, integración y acceso para
albergar sus funciones claves. La capa de preparación almacena los datos en bruto
extraídos de cada sistema fuente de datos. La capa de integración realiza la limpieza
y la homogeneización de los datos provenientes de las diversas fuentes. Los datos
integrados y limpiados son movidos a otra base de datos, en la cual los datos son
agrupados y ordenados en grupos jerárquicos. Por ejemplo, si los datos estuviesen
relacionados por regiones, estas podrían organizarse según el país al cual
pertenecen, y estos a su vez según el continente en el que se ubican. La capa de
acceso está pensada para ayudar a los usuarios a recuperar datos. [6]
“OLAP (Online Analytical Processing, Procesamiento Analítico en Línea) es un
término utilizado para describir el análisis de datos complejos desde el almacén de
datos.” [6] El modelo multidimensional es un modelo ampliamente utilizado para
OLAP. En los modelos multidimensionales, se rellenan matrices multidimensionales
llamadas cubos de datos, o hipercubos si las mismas tuviesen más de tres
dimensiones. [6] Los datos deben estar organizados en el cubo de manera tal que se
facilite la ejecución de consultas no predeterminadas de información agregada.
En la Figura 3.1, se muestra un ejemplo de un cubo con datos para créditos por
trimestre de liquidación del crédito, estado del crédito y naturaleza del cliente. En
cada celda del mismo se tienen los datos de un trimestre, estado de crédito y
naturaleza de cliente específicos.
“El cambio desde una orientación dimensional a otra en un cubo se logra
fácilmente mediante una técnica llamada pivotaje (o rotación).” Por ejemplo, como se
muestra en la Figura 3.2, se puede pivotear el cubo para mostrar los datos de
créditos por naturaleza del cliente como filas, los datos de créditos por trimestre
como columnas y los datos de créditos por estado de crédito en la tercera dimensión.
10
Figura 3.1: Ejemplo de cubo
Figura 3.2: Cubo después de pivotaje
11
Cada elemento de una dimensión podría ser resumido utilizando una jerarquía, si
sus características lo permiten. Por ello, es posible la creación de vistas jerárquicas
en los modelos multidimensionales. En primer lugar, la visualización roll-up, de
compactación, “mueve hacia arriba la jerarquía, agrupando en unidades más
grandes a lo largo de una dimensión.” [6] En la Figura 3.3, se muestra una
visualización roll-up que se desplaza desde trimestres hacia semestres. Por otra
parte, la visualización drill-down, de descomposición, “ofrece la operación contraria,
proporcionando una vista más fina.” [6] En la Figura 3.4, se muestra una
visualización drill-down que se desplaza desde trimestres hacia meses.
Figura 3.3: Cubo después de roll-up
Para el almacenamiento multidimensional, se necesitan dos tipos de tablas; de
dimensión y de hechos. Las de dimensión constan de “tuplas de atributos de la
dimensión” [6], mientras que las de hechos son “una agrupación de tuplas, una por
12
cada hecho registrado.” [6] Cada hecho contiene variables medidas y son asociadas
mediante punteros con las tablas de dimensión, que le dan un contexto.
El esquema en estrella es el esquema multidimensional más simple. El esquema
en estrella “consiste en una tabla de hechos con una única tabla por cada
dimensión.” [6] Un ejemplo del mismo es mostrado en la Figura 3.5.
Figura 3.4: Cubo después de drill-down
La tabla de hechos contiene los valores medibles documentados para un evento en
específico. Debido a la necesidad recurrente de guardar datos al nivel más atómico
posible, generalmente se tiene una cantidad enorme de registros en esta tabla. Por
lo tanto, es muy importante pensar bien en el número y el tamaño de los atributos
para restringir el tamaño de las tablas y mantener un buen desempeño.
13
Las tablas de dimensión, usualmente, tienen pocos registros en comparación con
las tablas de hechos. Sin embargo, pueden tener un gran número de atributos para
describir los datos de los hechos.
Figura 3.5: Esquema en Estrella
Los esquemas en estrella están diseñados para optimizar la facilidad de uso por
parte de los usuarios y el desempeño de la obtención de datos, minimizando el
número de tablas a combinar para llevar a cabo las operaciones.
El principal beneficio que ofrece un esquema en estrella es su simplicidad para los
usuarios y su facilidad para ser procesado por un sistema de bases de datos, ya que
las consultas son escritas con combinaciones sencillas entre las tablas de hechos y
un pequeño número de dimensiones.
Debido a su enorme volumen, la información contenida en un almacén de datos
cambia con menos frecuencia que la contenida en una base de datos transaccional.
14
En el proyecto de pasantía, se ha supuesto que la información en el almacén de
datos solamente aumenta, por lo que la eliminación o reemplazo de datos en el
mismo no está contemplado en el alcance del proyecto.
3.3 SQL
SQL (Structured Query Language, Lenguaje Estructurado de Consultas) es un
lenguaje de programación diseñado para el manejo de datos en sistemas de
administración de datos relacionales. [6] Para poder realizar la consulta, inserción,
eliminación y actualización de datos en varias bases de datos contempladas en la
solución desarrollada en este proyecto, es necesaria la correcta utilización de SQL,
ya que dichos datos van a estar almacenados en un sistema de administración de
datos relacional, más específicamente SQL Server 2008.
SQL fue uno de los primeros lenguajes comerciales que reflejaron el modelo
relacional de Edgar F. Codd. [6] A pesar de no apegarse al modelo relacional descrito
por Codd, pasó a ser el lenguaje de bases de datos más utilizado. Si bien SQL es
descrito como, y es en gran medida, un lenguaje declarativo, es decir, que indica lo
que se va a realizar, pero no como lo va a hacer, también incluye elementos
procedurales.
Después de convertirse en un estándar de la ANSI (American National Standards
Institute, Instituto de Estándares Nacionales de Norteamérica) en 1986 y de la ISO
(International Organization for Standards, Organización Internacional para
Estándares), varias funcionalidades han sido incorporadas a SQL.
La operación más común en SQL es la consulta, la cual es llevada a cabo con la
declaración SELECT. SELECT recupera filas de la base de datos y permite la selección
de una o más filas o columnas de una o más tablas.
Un elemento que adquiere especial relevancia para los procesos de extracción,
transformación y carga de datos en el presente proyecto es la combinación de tablas,
15
especificada a través del operador JOIN. Este operador define la manera en que dos
tablas están relacionadas especificando las columnas de cada tabla a ser usadas
para la combinación y los operadores lógicos a ser usados para la comparación entre
los valores de dichas columnas. Por ejemplo, si en una tabla se tienen las claves de
todos los créditos asignados y sus estados y en otra las claves de todos los créditos
asignados y sus fechas de vencimiento, se puede realizar una consulta que muestre,
para cada crédito, su estado y su fecha de vencimiento, utilizando como atributo de
combinación la clave del crédito.
Además de las consultas, SQL provee otros elementos para la manipulación de
datos y esquemas contenidos en un manejador. Entre los más relevantes para el
presente proyecto, se encuentran:
a. Los comandos INSERT, UPDATE y DELETE, que agregan, modifican y eliminan,
respectivamente, filas a una tabla existente. Mediante estos comandos, en
combinación con la declaración SELECT, se han realizado los procesos de
extracción, transformación y carga de datos desde las bases de datos origen
hasta las bases de datos intermedia e histórica.
b. El comando CREATE, el cual crea un objeto, como una tabla, un índice, etc., en
la base de datos. Utilizando este comando, se han creado los esquemas, las
tablas y los índices en las bases de datos utilizadas en el proyecto.
c. El comando ALTER, que modifica la estructura de un objeto existente. Este
comando ha sido utilizado para agregar y eliminar restricciones de clave
primaria en varias tablas a lo largo del proceso contemplado en la solución.
a. El comando TRUNCATE borra todos los datos que se encuentran en una tabla
sin borrar la tabla como tal. Utilizándolo, se han borrado los datos de las
tablas pertenecientes a las bases de datos origen e intermedia una vez que los
mismos hubiesen pasado a la base de datos histórica.
b. El comando DROP borra un objeto que tenga nombre de la base de datos. Con
este comando se han eliminado índices creados sobre atributos en las tablas
16
de la base de datos histórica a fin de agilizar el proceso de carga de los datos
en ellas.
CAPÍTULO 4
MARCO TECNOLÓGICO
En el presente capítulo se realiza una descripción de las herramientas utilizadas
para el desarrollo de la solución. Se describe SQL Server, un sistema de
administración de bases de datos, junto con varios servicios adicionales del mismo,
relacionados con inteligencia de negocios. Adicionalmente, se hace mención de la
manera de programar en SQL Server, el lenguaje de programación T-SQL
4.1. SQL Server
SQL Server de Microsoft es un sistema de administración de bases de datos
relacionales desarrollado por Microsoft. Su función principal es la de almacenar y
recuperar datos como sea requerido por otras aplicaciones de software, ya estén
estas contenidas en la misma computadora o en otras que se encuentren en la
misma red, incluyendo el Internet. El lenguaje con el cual se ejecuta SQL Server de
Microsoft es T-SQL, el cual agrega varias funcionalidades al SQL estándar, como
control de transacciones, manejo de excepciones, procesamiento de filas, declaración
de variables, entre otras. [6]
SQL Server está disponible, en varias ediciones, con diferentes conjuntos de
funcionalidades y con diferentes tipos de usuario objetivo. La edición con la que se
trabajó en el actual proyecto de pasantía es la edición Standard (Estándar).
4.1.1. Servicios adicionales de SQL Server
SQL Server incluye una colección de servicios agregados. A continuación se
presentan los utilizados para la realización del presente proyecto de pasantía.
4.1.1.1. Servicios de Análisis
18
Analysis Services (Servicios de Análisis) es un servicio de SQL Server, el cual
incluye un conjunto de capacidades OLAP y de minería de datos. En este proyecto de
pasantía, se ha utilizado para la generación del cubo de datos, especificando los
hechos, las dimensiones, las tablas de las que se extraerían los datos
correspondientes, entre otras cosas. [8]
Los datos en el almacén de datos pueden ser almacenados de dos maneras
principalmente: [9]
a. MOLAP (Multidimensional OLAP, OLAP Multidimensional): Al ser procesado
el cubo, los datos fuente son tomados de las bases de datos relacionales,
procesados y agregados convenientemente y guardados en el almacén. En el
caso de Analysis Services, los datos son guardados en el servidor en un
formato multidimensional comprimido y optimizado. Después del
procesamiento, los datos en el cubo dejan de estar conectados con las fuentes
relacionales. Por lo tanto, cualquier cambio subsiguiente en los datos
relacionales no serán reflejados hasta que el cubo sea reprocesado. La ventaja
principal de este modo de almacenamiento es que, como los datos están
guardados localmente en el servidor y los cálculos son generados previamente,
las consultas se ejecutan rápidamente.
b. ROLAP (Relational OLAP, OLAP Relacional): Tanto los datos como las
agregaciones permanecen en la fuente de datos relacional. La ventaja
principal de este modo de procesamiento es que los datos se pueden ver
prácticamente en tiempo real.
En el presente proyecto, se ha decidido utilizar la opción de almacenamiento por
defecto de Analysis Services, MOLAP, ya que se supone que el banco está dispuesto
a realizar la inversión en almacenamiento para el servidor OLAP y que la
generación de informes se realizará frecuentemente, para lo cual es necesario que
las consultas sobre la base de datos histórica sean procesadas rápidamente. De todas
formas, en caso de que más adelante se decida utilizar el modo de almacenamiento
19
ROLAP, esto no representaría ningún problema, pues la herramienta lo hace
bastante transparente.
Entre otras cosas, Analysis Services soporta un lenguaje de manipulación de
datos, llamado MDX (MultiDimensional eXpressions, Expresiones
Multidimensionales), el cual es un lenguaje de consultas para bases de datos OLAP,
de la misma manera en que SQL es un lenguaje de consultas para bases de datos
relacionales. [10] Las consultas y las visualizaciones en el presente proyecto de
pasantía se han hecho de manera visual, generándose automáticamente los scripts
en dicho lenguaje.
4.1.1.2. Servicios de Generación de Reportes
Reporting Services (Servicios de Generación de Reportes) es un sistema de
generación de reportes y puede ser usado para preparar y entregar una variedad de
reportes impresos e interactivos. Reporting Services posee una interfaz de servicios
web para soportar el desarrollo de aplicaciones personalizadas de generación de
reportes. [11]
En el presente proyecto, se han generado ciertos reportes basados en datos
contenidos en el cubo utilizando Reporting Services.
4.1.1.3. Servicios de Integración
Integration Services (Servicios de Integración) es un componente de SQL Server
que puede ser utilizado para llevar a cabo un amplio rango de tareas de migración,
integración y transformación de datos. Integration Services ofrece herramientas
rápidas y flexibles para realizar dichas tareas. Dichas herramientas pueden ser
usadas, además, para automatizar el mantenimiento de bases de datos SQL Server
y la actualización de datos multidimensionales de cubos. [12]
20
Para la creación o el mantenimiento de paquetes de Integration Services, se usa
una herramienta visual de desarrollo basada en Visual Studio llamada Business
Intelligence Development Studio (Estudio de Desarrollo de Inteligencia de Negocios).
Dicha herramienta visual ha sido utilizada igualmente para el uso de Analysis
Services y Reporting Services. Mediante esta herramienta se pueden crear y editar
paquetes de Integration Services utilizando una interfaz de usuario drag-and-drop
(arrastrar y soltar). Además, un ambiente de programación está disponible, en el
caso de que sea necesario escribir código.
Elementos de distinta índole definen un paquete de Integration Services. El
principal elemento a mencionar son las tareas, las cuales son unidades de trabajo
atómicas que llevan a cabo alguna acción. Existe una gran variedad de tareas
posibles, como aquellas relacionadas con el sistema de archivos, transformaciones de
datos, ejecución de scripts SQL, procesamiento de cubos, etc. En el caso del proyecto
de pasantía, la ejecución de los distintos scripts de carga y transformación de datos y
de eliminación de registros, la ejecución de procedimientos almacenados y el
procesamiento del cubo se han definido como tareas dentro del paquete. [12]
Otro elemento de un flujo de trabajo son las conexiones. Una conexión incluye la
información necesaria para la conexión a alguna fuente de datos particular, la cual
puede ser una base de datos, un archivo de texto plano, entre otros. Las tareas
pueden referirse a la conexión a través de su nombre, dejando la posibilidad de que
los detalles de conexión sean cambiados o configurados a tiempo de ejecución. En el
proyecto de pasantía se han creado conexiones a las distintas bases de datos y a
scripts contenidos en archivos de texto. [12]
Las restricciones de precedencia son un elemento que permite conectar a las
tareas. La restricción de precedencia de alguna tarea en particular debe ser
cumplida antes de que la tarea sea ejecutada. Las tareas pueden ser ejecutadas en
paralelo si las restricciones de precedencia no lo impiden. Existen en particular tres
restricciones de precedencia: compleción, éxito o falla. Es decir, si dos tareas están
21
conectadas mediante una restricción de precedencia de compleción, la segunda tarea
se ejecutará si y solo si la primera termina y si dos tareas están conectadas
mediante una restricción de precedencia de éxito o falla, la segunda tarea se
ejecutará si y solo si la primera termina exitosamente o con errores,
respectivamente. Las restricciones de precedencia constituyen el flujo de trabajo del
paquete, del mismo modo que las tareas. En el proyecto de pasantía realizado se han
colocado las restricciones de precedencia consideradas adecuadas para conectar las
tareas. [12]
Por último, las variables son elementos referenciados por las tareas que pueden
ser utilizados para guardar resultados, tomar decisiones, etc. En el proyecto, se han
controlado, mediante las variables, el número de tuplas insertadas en las tablas al
momento de ejecución del paquete. [12]
Cuando un paquete es guardado, su contenido persiste en formato XML.
La herramienta permite al usuario ejecutar el paquete en cualquier momento de
su proceso de creación. Durante la ejecución, el paquete puede ser depurado o
monitorizado.
4.1.1.4. Estudio de Administración de SQL Server
SQL Server Management Studio (Estudio de Administración de SQL Server) es
una herramienta de interfaz gráfica incluida con SQL Server usada para configurar,
manejar y administrar todos los componentes de SQL Server. La herramienta
incluye editores de piezas de código y herramientas gráficas que trabajan con objetos
y funcionalidades del servidor. [13]
Una de las funcionalidades centrales de SQL Server Management Studio es el
Explorador de Objetos, el cual permite a los usuarios navegar, seleccionar y realizar
acciones sobre cualquier objeto en el servidor. El Explorador de Objetos puede ser
usado para observar y analizar planes de consulta y optimizar el desempeño de la
22
base de datos, entre otros. Además, el mismo puede ser usado para crear nuevas
bases de datos, alterar cualquier base de datos existente agregando o modificando
tablas e índices, o realizar análisis de desempeño. El Explorador de Objetos incluye
ventanas de consulta, las cuales proveen una interfaz gráfica para escribir y ejecutar
consultas.
SQL Server Management Studio fue de gran utilidad para la realización del
proyecto, ya que permite la edición y creación de scripts de SQL y la ejecución de
consultas sobre las distintas tablas de manera muy sencilla.
4.1.1.5. Business Intelligence Development Studio
Business Intelligence Development Studio es el IDE de Microsoft utilizado para
desarrollar soluciones de análisis de datos y de inteligencia de negocios usando,
como ya se mencionó, Analysis Services, Reporting Services e Integration Services.
Está basado en el ambiente de desarrollo de Visual Studio, pero está adaptado con
las extensiones y tipos de proyectos específicos de SQL Server, incluyendo
herramientas adicionales. [14]
En el proyecto se utilizó Business Intelligence Development Studio para
desarrollar prácticamente todo lo relacionado con el cubo de la base de datos.
4.1.2. Programación
T-SQL es la manera principal de programar y manejar SQL Server. Este lenguaje,
que constituye la extensión de Microsoft a SQL, expande dicho estándar incluyendo
programación procedimental, variables locales, funciones de procesamiento de
cadenas de caracteres, de procesamiento de fechas, matemáticas, etc., y cambia las
declaraciones DELETE y UPDATE. Todas las aplicaciones que se comunican con una
instancia de SQL Server lo hacen enviando declaraciones T-SQL al servidor,
independientemente de la interfaz gráfica de la aplicación. [15]
23
En T-SQL, las declaraciones DELETE y UPDATE permiten agregarles una cláusula
FROM, lo cual permite incluir combinaciones de tablas, es decir JOINs.
CAPÍTULO 5
DESCRIPCIÓN DE LA SOLUCIÓN
La solución desarrollada en el presente período de pasantía es un prototipo de un
sistema de Inteligencia de Negocios y Almacén de Datos que constituye una parte
de un proyecto a realizar por Microsoft para BBVA Banco Provincial.
Entre otras cosas, el BBVA Banco Provincial necesita poder disponer de datos
históricos relacionados con la información financiera y contable generada
mensualmente y generar informes que faciliten el archivamiento y la comprensión
de dichos datos. Para dicho fin, la parte del proyecto a desarrollar relacionada con
Inteligencia de Negocios debe recoger, compaginar y analizar datos transaccionales,
definir hechos y dimensiones y generar informes que hagan uso de dichos datos
agregados.
La solución de Inteligencia de Negocios de esta pasantía comprende la extracción,
transformación y carga desde fuentes heterogéneas de datos hacia un área de
preparación. Desde esa área, los datos son movidos hacia un almacén central de
datos históricos, a partir de los cuales un cubo OLAP es construido. Dichos datos
agregados contenidos en el cubo son, en fin, hechos disponibles a los usuarios finales
a través de reportes, por medio de un servidor de reportes y por medio de Excel.
En el esquema presentado en la Figura 5.1, se muestra la arquitectura de la
solución desarrollada. A partir de la base de datos origen, en la cual se ha realizado
la inserción de registros aleatorios, se ejecutan diversos procesos de carga,
extracción y procesamiento de datos. Esto deriva finalmente en la construcción de
una base de datos OLAP a partir de la cual se pueden realizar consultas a fin de
cubrir parte de los requerimientos de información planteados por el BBVA Banco
Provincial.
25
Figura 5.1: Arquitectura de la Solución
26
El proyecto de pasantía está enmarcado en la fase de desarrollo de la metodología
de entrega de servicios de Microsoft, la cual es una guía de calidad para los servicios
de consultoría de la compañía. Debido a que el servicio de consultoría para BBVA
Banco Provincial ya estaba puesto en marcha algunos meses atrás, los pasos previos,
como la conformación de los equipos, la delimitación de los objetivos, la planificación
de las tareas, entre otros, ya estaban realizados. En la fase de desarrollo, se
pretende pasar a la construcción de una solución que incluya todos los aspectos de
las necesidades del proyecto, como el código, los manuales de despliegue, etc.
Antes de proseguir, es importante mencionar que la totalidad de la solución
desarrollada en este proyecto de pasantía fue realizada de manera local en un
computador con sistema operativo Windows 7 de 64 bits con las siguientes
características:
a. Procesador Intel Core2 Duo, 2.20GHz
b. 4 GB de memoria
c. 93 GB de disco duro
A continuación, se hace una descripción de las bases de datos involucradas en la
solución, desde las bases de datos origen hasta la base de datos histórica obtenida al
final. Después, se describe el generador de datos aleatorios. Dado que no se contaba
con datos reales, se procedió a generar datos aleatorios para probar las
herramientas. Se presentan los procesos de extracción, transformación y carga de
datos. Luego, se presenta una descripción del proceso llevado a cabo para la
configuración del cubo OLAP y para la creación del paquete de flujo que se encarga
de coordinar los procesos que componen la solución. Por último, se hace una pequeña
descripción de las maneras en que se han visualizado los datos históricos, una vez
procesados.
5.1. Bases de datos.
27
En primer lugar, es importante mencionar que las bases de datos origen utilizadas
constituyen un subconjunto de la totalidad de las bases de datos reales. Esto es
debido a que las bases de datos reales poseen una cantidad enorme de tablas y hacer
una solución contemplando todas ellas se saldría ampliamente del alcance posible en
el tiempo de duración de la pasantía. A continuación se presenta una pequeña
descripción de las bases de datos utilizadas. Para información sobre las tablas que
conforman las bases de datos, los atributos de las tablas y los tipos de datos de los
atributos, ir al apéndice A.
La base de datos DBALEJANDRIA_STAGINGAREA es la base de datos origen, sobre
cuyas tablas se realizan los procesos de extracción y carga.
La base de datos SIF contiene los datos procesados desde la base de datos origen,
es decir, DBALEJANDRIA_STAGINGAREA. Está formada únicamente por una tabla
llamada AT04. En esta tabla se guardan los datos correspondientes a los créditos,
como fecha de cierre, número de crédito, estado de crédito, situación del crédito,
cuotas vencidas, etc.
La base de datos Prototipo es una base de datos histórica de créditos en la cual
son cargados los datos provenientes directamente de la base de datos SIF.
5.2. Generador de datos aleatorios en tablas de origen.
Para la elección de los posibles valores de los atributos en la base de datos
DBALEJANDRIA_STAGINGAREA, se ha utilizado como referencia en algunos casos un
conjunto de registros de ejemplo suministrados por el banco, mostrados en el
apéndice B. Por otra parte, también fueron utilizados como referencia valores
encontrados en los scripts de carga y transformación, suministrados por los
consultores de Microsoft.
Los créditos, cuyos datos son descritos en el Átomo 4, como se dijo en el capítulo 2,
están divididos en subconjuntos según el tipo de operación financiera que
28
involucran, determinada por el banco. A cada uno de estos subconjuntos se le llama
“aplicativo”. En el presente proyecto de pasantía, se contemplaron seis aplicativos:
“Efectos”, “Factoring”, “Prestamos”, “Leasing”, “Sobregiros” y “Medios de pago”. Por
ejemplo, el aplicativo “Prestamos” está relacionado con la cartera comercial de
préstamos del banco, el aplicativo “Leasing” está relacionado con los créditos de
arrendamiento, el aplicativo “Sobregiro” está relacionado con los contratos en
condiciones de sobregiro, “Medios de pago” está relacionado con las tarjetas de
crédito, etc.
En esta pasantía, se implementó un procedimiento específico para la inserción de
datos para cada aplicativo, debido a que los datos correspondientes a cada aplicativo
están contenidos en tablas determinadas. A continuación se realiza una breve
descripción de los procedimientos implementados y utilizados. Los scripts de los
mismos se encuentran en el apéndice C.
Las tablas para las cuales se hace la inserción, los campos involucrados y sus
posibles valores se encuentran detallados en el apéndice D.
5.2.1. Procedimiento del aplicativo “Efectos”
Mediante la ejecución de este procedimiento, se insertan en las tablas de origen los
datos de los créditos pertenecientes al aplicativo “Efectos”.
El procedimiento se llama prc_RandomInsertEfectos, se ha almacenado
tentativamente en la base de datos SIF y recibe como parámetro un valor entero,
llamado @Filas, el cual tiene como valor por defecto 100 e indica el número de
registros a ser insertados. El procedimiento consta de un ciclo con número de
iteraciones igual a @Filas.
5.2.2. Procedimiento del aplicativo “Factoring”
29
Mediante la ejecución de este procedimiento, se insertan en las tablas de origen los
datos de los créditos pertenecientes al aplicativo “Factoring”. El procedimiento se
llama prc_RandomInsertFactoring y funciona de manera similar al del
aplicativo “Efectos”.
5.2.3. Procedimiento del aplicativo “Prestamos”
Mediante la ejecución de este procedimiento, se insertan en las tablas de origen los
datos de los créditos pertenecientes al aplicativo “Prestamos”. El procedimiento se
llama prc_RandomInsertPrestamos y funciona de manera similar al del
aplicativo “Efectos”.
5.2.4. Procedimiento del aplicativo “Leasing”
Mediante la ejecución de este procedimiento, se insertan en las tablas de origen los
datos de los créditos pertenecientes al aplicativo “Leasing”. El procedimiento se
llama prc_RandomInsertLeasing y funciona de manera similar al del aplicativo
“Efectos”.
5.2.5. Procedimiento del aplicativo “Sobregiros”
Mediante la ejecución de este procedimiento, se insertan en las tablas de origen los
datos de los créditos pertenecientes al aplicativo “Sobregiros”. El procedimiento se
llama prc_RandomInsertSobregiros y funciona de manera similar al del
aplicativo “Efectos”.
5.2.6. Procedimiento del aplicativo “Medios de pago”
Mediante la ejecución de este procedimiento, se insertan en las tablas de origen los
datos de los créditos pertenecientes al aplicativo “Medios de pago”. El procedimiento
se llama prc_RandomInsertMediosPago y funciona de manera similar al del
aplicativo “Efectos”.
30
5.3. Scripts de carga y transformación de datos
En esta pasantía, se utilizó una serie de scripts para la carga y transformación de
datos desde la base de datos de origen, DBALEJANDRIA_STAGINGAREA, hacia la base
de datos SIF. Dichos scripts fueron suministrados por los consultores de Microsoft
Venezuela y fueron utilizados, además, como ya se mencionó anteriormente, como
referencia para la generación de datos aleatorios para las tablas de origen, de
manera que los mismos arrojaran resultados que efectivamente mostraran su
funcionamiento. Por otra parte, se creó también un procedimiento para crear
registros directamente sobre la tabla AT04 de SIF.
A continuación se realiza una breve descripción de los scripts de carga y
transformación de datos y del procedimiento mencionados, en el mismo orden en el
que han de ser ejecutados. Una descripción más detallada de los scripts y
procedimientos se encuentra en el apéndice E.
5.3.1. Primer script, ’00.Universo.sql’
En este script se hace la inserción de registros con información de créditos en la
tabla AT04 de SIF, específicamente para los campos Fecha_Cierre,
IDAplicativo, Credito, Credito_18, Estado_credito y Tipo_cartera, a
partir de las tablas de la base de datos origen DBALEJANDRIA_STAGINGAREA. Por
último, se realiza una actualización y una eliminación de registros sobre la tabla
AT04.
El campo Fecha_Cierre contiene la fecha de cierre del crédito; el campo
IDAplicativo contiene el número que identifica al aplicativo al que pertenece el
crédito; los campos Credito y Credito_18 contienen el identificador del crédito, en
versiones de 20 y 18 caracteres, respectivamente; el campo Estado_credito
contiene un valor entero que indica el estado del crédito y el campo Tipo_cartera
contiene un valor entero que indica el tipo de cartera asociado al crédito.
31
La inserción de los registros en la tabla AT04 se realiza secuencialmente y por
grupos. Cada grupo corresponde a un aplicativo y se selecciona mediante una
declaración SELECT. Los grupos son unidos mediante la operación de grupos UNION.
Hacia el final del script, como ya se mencionó, se realizan una actualización y una
eliminación de registros en la tabla AT04. Las tablas involucradas fueron creadas,
pero solo a fin de que el script se ejecutase correctamente; no se hicieron realmente
tales actualización y eliminación de registros en la tabla.
5.3.2. Segundo script, ’02.Factoring.sql’
En este script se realiza la actualización de la información de créditos contenida en
la tabla AT04 desde la combinación de sí misma con varias tablas de acuerdo a
varias reglas de combinación. Si bien todas las tablas fueron creadas para que el
script se ejecutase correctamente, solamente se realizó efectivamente la
actualización de datos, en primer lugar, desde las tablas en las que datos aleatorios
fueron agregados y, en segundo lugar, con valores constantes colocados en el script.
Las tablas desde las cuales se realizó actualización fueron las correspondientes al
aplicativo “Factoring”. En este script se actualizan valores para los siguientes
campos de la tabla AT04:
a. Fecha_liquidacion, fecha de liquidación del crédito.
b. CUOTAS, número de cuotas del crédito.
c. CUOTAS_VENCIDAS, número de cuotas vencidas del crédito.
d. Monto_V30d, montos con hasta 30 días de vencidos.
e. Monto_V60d, montos con hasta 60 días de vencidos.
f. Monto_V90d, montos con hasta 90 días de vencidos.
g. Monto_V120d, montos con hasta 120 días de vencidos.
h. Monto_V180d, montos con hasta 180 días de vencidos.
i. Monto_V1a, montos con hasta un año de vencidos.
j. Monto_Vm1a, montos con más de un año de vencidos.
32
5.3.3. Procedimiento para inserción directa sobre la tabla AT04 de SIF
Con este procedimiento se realiza inserción aleatoria de registros en la tabla AT04
de la base de datos SIF, de manera directa, es decir, sin extraer datos de las tablas
origen. Para mantener la consistencia, se ha asociado a los registros insertados de
esta manera un aplicativo llamado “(Insercion Aleatoria)”. Este procedimiento se ha
implementado a fin de tener una manera rápida de insertar registros en la tabla
AT04 de SIF, ya que la ejecución del script ’02.Factoring.sql’ es lenta.
El procedimiento se llama prc_RandomInsert, se ha almacenado
tentativamente en la base de datos SIF y recibe como parámetro un valor entero,
llamado @Filas, el cual tiene como valor por defecto 10000 e indica el número de
filas a ser insertadas. El procedimiento consta de un ciclo con número de iteraciones
igual a @Filas.
5.3.4. Scripts adicionales
En esta pasantía, se ejecutaron cuatro scripts más, a saber: ‘14.Post-
ComunesCorasu.sql’, ‘15.Post-ComunesDefaults.sql’, ‘16.SP01.sql’ y
‘17.ActualizacionSudeban.sql’. Sin embargo, los mismos no realizaron realmente
ninguna función dentro del marco del presente proyecto. Solamente fueron
ejecutados por ser considerados parte del proceso de extracción, transformación y
carga.
5.4. Extracción y carga
En esta sección se explica la inserción de registros en las tablas de dimensión de la
base de datos histórica Prototipo y el flujo de datos desde la tabla AT04 de SIF
hasta la tabla AT04 de Prototipo.
5.4.1. Inserción de registros en las tablas de dimensión de la base de datos
Prototipo
33
La inserción de registros en la tabla DimTiempo, tabla de dimensión que guarda
las fechas de los créditos, debe obligatoriamente ser realizada antes de la generación
aleatoria de datos en las tablas de origen, pues algunos procedimientos que la llevan
a cabo toman valores de la misma. Para dicha inserción de registros en la tabla, se
ha ejecutado un procedimiento suministrado por los consultores de Microsoft,
llamado LoadDimFecha, que se ha almacenado en la base de datos Prototipo.
El resto de las tablas de dimensión pueden ser llenadas en cualquier momento
antes del flujo de datos entre las bases de datos SIF y Prototipo.
Las tablas que posee la base de datos Prototipo son:
a. DimTiempo: tabla de dimensión que guarda las fechas de los créditos.
b. APLICATIVO: tabla de dimensión que guarda los diferentes aplicativos a los
que pertenecen los créditos.
c. SB34_ESTADO_CREDITO: tabla de dimensión que guarda los posibles estados
en los que puede estar un crédito, como activo, cancelado, etc.
d. SB35_SITUACION_CREDITO: tabla de dimensión que guarda las posibles
situaciones en las que se puede encontrar un crédito, como vigente, vencido,
en litigio, etc.
e. SB76_NATURALEZA_CLIENTE: tabla de dimensión que guarda las posibles
naturalezas que puede poseer un cliente, como persona natural o jurídica.
f. TIPO_CARTERA: tabla de dimensión que guarda los distintos tipos de cartera
a los que puede estar asociado un crédito. Las carteras están asociadas a
relaciones crediticias entre un banco y un cliente, determinadas por el
comportamiento de los clientes con respecto a las moras en el pago de créditos.
g. AT04: tabla de hechos que guarda diferentes valores asociados a los créditos,
como cuotas, cuotas vencidas, montos vencidos a 30, 60, 90 días, entre otros.
Los datos que se encuentran en esta tabla son cargados directamente desde la
tabla homónima de la base de datos SIF.
34
La tabla APLICATIVO contiene los códigos de los aplicativos y sus nombres. Los
aplicativos son “Sobregiros”, “Efectos”, “Factoring”, “Leasing”, “(Inserción
Aleatoria)”, “Medios de Pago” y “Prestamos”.
La tabla SB34_ESTADO_CREDITO contiene los códigos de los estados de crédito y
sus nombres. Los estados que puede tener un crédito son “Activo”, “Cancelado” y
“Castigado”.
La tabla SB35_SITUACION_CREDITO contiene los códigos de las situaciones de
crédito y sus nombres. Las situaciones que puede tener un crédito son “No Aplica”,
“Vigente”, “Reestructurado”, “Vencido” y “Litigio”.
La tabla SB76_NATURALEZA_CLIENTE contiene los códigos de las naturalezas de
los clientes y sus nombres. Las naturalezas de un cliente pueden ser “No Aplica”,
“Persona Natural”, “Persona Jurídica” y “Organismo Oficial”.
Para completar la tabla TIPO_CARTERA, se ha ejecutado un procedimiento llamado
prc_InsertCartera, que se ha almacenado en la base de datos Prototipo y que
no recibe parámetros de entrada. En el mismo se borran todos los registros de la
tabla y después se insertan registros cuyos valores para el único atributo que
poseen, Cod, van desde 0 hasta 99.
5.4.2. Flujo de datos desde la tabla AT04 de la base de datos SIF hasta la tabla
AT04 de la base de datos Prototipo
Para la tabla AT04 de la base de datos Prototipo, además de las restricciones de
clave primaria y de clave foránea hacia las tablas de dimensión, se definieron, en el
script de creación de la base de datos, índices sobre varios conjuntos de atributos.
Por cuestiones de eficiencia, antes del flujo de datos entre las tablas AT04, se
eliminaron las restricciones de clave primaria y foránea y los índices, para después
restablecerlos y hacer el chequeo de los mismos después de que los datos fuesen
35
copiados. Estas dos tareas se realizaron mediante dos scripts, llamados “Creacion
Indices y Fks en At04.sql” y “Eliminacion Indices y Fks en At04.sql”,
respectivamente. Los mismos se encuentran en el apéndice F.
Además, también antes del flujo de datos entre las tablas AT04 y mediante un
procedimiento llamado prc_ArreglarCierreLiquidacion, el cual se almacenó en
la base de datos SIF y que no recibe parámetros de entrada, se actualizaron los
valores de los atributos Fecha_cierre_date y Fecha_liquidacion_date de la
tabla AT04 de la misma base de datos de acuerdo a los valores de los atributos
Fecha_Cierre y Fecha_liquidacion, respectivamente. Por ejemplo, si para un
registro el valor de Fecha_liquidacion es ‘19000101’, entonces en
Fecha_liquidacion_date se coloca ‘1900-01-01 00:00:00.000’. Es decir,
hace que los valores de las fechas de cierre y liquidación como tipo de dato fecha se
correspondan con sus valores como tipo de dato entero.
El flujo de datos entre las tablas AT04 consiste simplemente en copiar los datos de
la tabla AT04 de SIF a la tabla AT04 de Prototipo. Los atributos son exactamente
los mismos en ambas tablas.
Después del flujo de datos entre las tablas AT04, se ha de proceder a eliminar
todos los registros tanto de las tablas de las bases de datos
DBALEJANDRIA_STAGINGAREA y SIF, permaneciendo dichos datos únicamente en la
tabla AT04 de Prototipo, la cual viene a ser la base de datos histórica y sobre la
cual se elaborará el cubo OLAP.
5.5. Elaboración del cubo OLAP con Analysis Services mediante la herramienta
Business Intelligence Development Studio
En esta sección se explica brevemente el procedimiento realizado para la
configuración y elaboración del cubo OLAP a partir de las tablas descritas en las
secciones anteriores. En la Figura 5.2 se muestra el modelo de datos para el cubo del
36
Átomo 4. En el mismo se observa la tabla de hechos AT04 rodeada por las tablas de
dimensión DimTiempo, SB34_ESTADO_CREDITO, APLICATIVO,
SB35_SITUACION_CREDITO, TIPO_CARTERA y
SB76_NATURALEZA_CLIENTE, cada una con un conjunto de atributos y, en el
caso de DimTiempo, con una organización jerárquica de sus componentes.
Figura 5.2: Modelo de datos del átomo 4
En primer lugar, se configuraron las conexiones a las fuentes de datos. En este caso, la
fuente de datos es la base de datos Prototipo. En segundo lugar, se seleccionaron las
tablas de dimensión y la tabla de hechos de la Figura 5.2. En tercer lugar, se agregaron a la
tabla de dimensión dos atributos derivados. El cálculo de los mismos se presenta en la Tabla
37
5.1. Esto se hizo para que los meses, los trimestres y los semestres de cada año pudieran ser
identificados unívocamente, ya que la herramienta lo requiere para elaborar las jerarquías
de la dimensión.
En cuarto lugar, se configuraron las dimensiones del cubo, las cuales están
basadas en las tablas de dimensión. Para el caso de la dimensión de tiempo, basada
en la tabla DimTiempo, se configuraron las dos jerarquías mostradas en la Figura
5.2, una mensual y la otra semanal.
Tabla 5.1: Cálculos con nombre
Nombre Cálculo
MesClave Anho*100 + Mes
TrimestreClave Anho*100 + NumeroTri
SemestreClave Anho * 10 + Semestre
Finalmente, se configuró el cubo con la tabla de hechos y las dimensiones
configuradas previamente. Para la tabla de hechos, se seleccionaron las medidas
para los cuales efectivamente se insertaron valores en el proceso de carga de datos,
mencionadas en la sección 5.3. Además, se agregó un miembro calculado para la
tabla de hechos, llamado Montos Vencidos Totales, el cual es la suma de todos los
montos vencidos (a 30, 60, 90, 120, 180 días, a un año y a más de un año).
Después de configurar el cubo, hay que desplegarlo. Una vez hecho esto, se
pueden obtener distintas visualizaciones del mismo, como se muestra en las Figuras
5.3, 5.4 y 5.5, a través del explorador del cubo ofrecido por la herramienta.
38
Por ejemplo, en la Figura 5.4, se puede saber los montos vencidos totales para
personas jurídicas cuya fecha de vencimiento se encuentra en el mes de enero de
2010, etc.
5.6. Elaboración del paquete de flujo de datos con Integration Services mediante la
herramienta Business Intelligence Development Studio
Posteriormente a la configuración del cubo, se pasó a la configuración y
elaboración del paquete de flujo que ejecute lo mostrado en la Figura 5.1 desde la
generación de datos aleatorios en las tablas de origen hasta el procesamiento y
almacenamiento de datos históricos en el cubo. Esto se hizo utilizando Integration
Services.
Figura 5.3: Montos Vencidos Totales para créditos discriminados por aplicativo (filas)
y estado de crédito (columnas), cuya situación de crédito es ‘Litigio’ (filtro)
Se crearon las conexiones a las bases de datos, variables, tareas y demás
elementos explicados en la sección 4.1.1.3, necesarios para que el flujo de datos se
ejecutara.
Después de crear el paquete, el funcionamiento del mismo se verificó al ejecutarlo.
39
Figura 5.4: Montos Vencidos Totales para créditos discriminados por fecha de
liquidación (filas) y naturaleza del cliente (columnas)
Figura 5.5: Cuotas Vencidas discriminadas para créditos por aplicativo (filas) y
situación de crédito (columnas), cuya fecha de cierre está en el año 2012 (filtro)
5.7. Consulta
De lo realizado en la sección 5.5 se obtuvo un cubo OLAP con el cual se pueden
realizar distintas operaciones a fin de observar sus datos. De hecho, en las Figuras
5.3, 5.4 y 5.5, se dieron ejemplos de posibles visualizaciones, resultantes de la
combinación de hechos y dimensiones, las cuales a su vez están jerarquizadas y
pueden establecerse con diferentes granularidades, dependiendo del caso. Por
40
ejemplo, para la dimensión relativa al tiempo, se pueden ver los montos vencidos por
día, mes, trimestre, semana, etc.
Dichas visualizaciones de datos pueden colocarse en un servidor de informes,
utilizando Reporting Services, a fin de que personas que no estén familiarizadas con
el Business Intelligence Development Studio y que vayan a necesitar acceso a los
datos puedan hacerlo sin muchos inconvenientes. Esto se ha hecho utilizando la
misma herramienta Business Intelligence Development Studio. Después de creados,
los informes pueden ser visualizados en un navegador de Internet. La Figura 5.6
muestra un reporte de los montos vencidos totales discriminados por naturaleza del
cliente y por fecha de cierre del crédito.
Desde Excel 2010 también es posible acceder a los datos de un cubo creado en
Analysis Services. En la Figura 5.7 se muestra un reporte de los montos vencidos de
120 y 180 días y un año discriminados por naturaleza del cliente y estado del
crédito.
Figura 5.6: Ejemplo del servidor de reportes
41
Figura 5.7: Ejemplo de visualización del cubo en Excel
CAPÍTULO 6
PRUEBAS Y RESULTADOS
En este capítulo, se presentan tiempos de ejecución del paquete de Integration
Services mencionado en la sección 5.6. Los mismos son presentados en la Figura 6.1.
Figura 6.1: Tiempos de ejecución para el paquete de flujo
Las filas insertadas en las tablas de origen se indican en el eje x y los tiempos de
ejecución del paquete, en segundos, en el eje y. “Tiempo total” muestra el tiempo de
ejecución del paquete completo. “00Universo” muestra el tiempo de ejecución del
script “00.Universo.sql”, presentado en la sección 5.3.1. “02Factoring” muestra el
tiempo de ejecución del script “02.Factoring.sql”, presentado en la sección 5.3.2.
“Rep. del cubo” muestra el tiempo de reprocesamiento del cubo con los nuevos
valores insertados.
0
500
1000
1500
2000
2500
3000
3500
4000
0 5000 10000 15000 20000 25000
Tiem
po
de
ejec
uci
ón
(s)
FilasOrigen
Tiempos de ejecución para paquete de flujo
Tiempo total
00Universo
02Factoring
Rep. del cubo
43
Cabe acotar que parte del tiempo de ejecución del paquete corresponde a la
ejecución del procedimiento para crear registros directamente sobre la tabla AT04 de
SIF, presentado en la sección 5.3.3, con valor 50000 para el parámetro @Filas. Al
insertarse siempre el mismo número de registros, el tiempo de ejecución de este
procedimiento es constante para todas las corridas realizadas, con un valor
alrededor de los 30 segundos.
Debido a la gran cantidad de combinación de tablas que se incluyen dentro del
script “02Factoring”, el tiempo de ejecución del mismo crece de manera polinomial
con un exponente elevado con respecto al número de registros en las tablas
involucradas en dichas combinaciones, lo cual hace, como se observa en la Figura
6.1, que la ejecución del mismo consuma la mayor parte del tiempo de ejecución del
paquete de datos entero.
Si bien la ejecución del script “00Universo” también posee combinaciones de tablas
y también consume un tiempo que crece de manera polinomial con respecto al
número de registros en las tablas, dicho crecimiento polinomial es mucho más lento
que el del script “02Factoring”.
44
Conclusiones y recomendaciones
En el presente proyecto se ha desarrollado un prototipo de solución que lleva a
cabo, de manera secuencial, la extracción de datos desde unas bases de datos de
origen, el procesamiento de dichos datos y su carga en una base de datos histórica.
La extracción de datos consistió en tomar los datos desde las bases de datos de
origen, siempre con conocimiento previo del significado que los mismos tendrían una
vez colocados en la base de datos histórica. Los datos utilizados para simular este
proceso de extracción son aleatorios y fueron generados a partir de unos pocos
registros de prueba suministrados por el banco.
En el procesamiento de los datos, los datos extraídos desde las bases de datos
origen, en bruto, son ordenados, agrupados y, finalmente, convertidos en
información útil para la base de datos histórica. Con base en las pruebas realizadas,
se observó que el procesamiento de los datos puede consumir mucho tiempo si el
número de registros a procesar es grande. Por lo tanto, se recomienda para el futuro
la optimización del acceso a los datos mediante la construcción de índices y la
realización de pruebas en ambientes con características más cercanas a aquellas en
las que la solución va a ser implantada, en este caso los servidores del banco.
La carga de datos consistió en colocar los datos ya procesados desde las bases de
datos fuente en las bases de datos históricas. Debido a la suposición de que las bases
de datos históricas son permanentes, es decir, que los datos contenidos en ellas no se
pueden ni modificar ni eliminar una vez son ingresados, no se implementaron
procesos de mantenimiento de datos en estas bases de datos históricas, sino
solamente de carga.
Por otra parte, los datos contenidos en el cubo OLAP configurado están basados en
la información contenida en la base de datos histórica. Es precisamente sobre el cubo
OLAP que los usuarios finales van a realizar las visualizaciones de los datos
históricos y la generación de reportes. Dichas visualizaciones y reportes se pueden
45
realizar, o bien en el marco de la herramienta utilizada para la configuración del
cubo, o bien en otros entornos como un servidor de reportes o el mismo Microsoft
Excel.
Como en toda aplicación a ser utilizada por usuarios no necesariamente
poseedores de conocimientos técnicos en el área de la informática, la interacción de
los usuarios con la misma debe ser sencilla y de fácil aprendizaje. Es por eso que la
visualización de los datos históricos a través del servidor de reportes y de Microsoft
Excel, si bien puede no constituir un elemento importante técnicamente hablando,
toma especial relevancia en este proyecto.
46
Referencias
1. Encyclopædia Britannica Inc. 2012. Microsoft Corporation. Disponible en Internet:
http://www.britannica.com/EBchecked/topic/380624/Microsoft-Corporation, consultado
el 23 de abril de 2012.
2. Eduardo Valero. 2011. Comunicado oficial de Microsoft Venezuela. Disponible
en Internet: http://www.noticias24.com/tecnologia/noticia/8035/microsoft-
desmiente-retiro-de-venezuela-y-reafirma-su-compromiso-con-el-pais/,
consultado el 23 de abril de 2012.
3. Margarita Alberti, Luisa Gómez. 2012. Services Venezuela FY12 Career
Development Month (Mes de Desarrollo de Carreras del Año Fiscal 2012 de
Servicios de Venezuela). Presentación en Power Point.
4. Microsoft Corporation. 2012. Microsoft Services. Disponible en Internet:
http://www.microsoft.com/africa/enterprise/services.aspx, consultado el 25 de
abril de 2012.
5. Surajit Chaudhuri, Umeshwar Dayal, Vivek Narasayya. 2011. An Overview of
Business Intelligence Technology. Disponible en Internet:
http://cacm.acm.org/magazines/2011/8/114953-an-overview-of-business-
intelligence-technology/fulltext, consultado el 27 de abril de 2012.
6. Elmasri, R. y Navathe, S. 2007. Fundamentos de Sistemas de Bases de Datos.
5ª edición. Pearson Educación, Madrid.
7. Margaret Rouse. 2006. SQL Server. Disponible en Internet:
http://searchsqlserver.techtarget.com/definition/SQL-Server, consultado el 27
de abril de 2012.
47
8. Microsoft. 2012. SQL Server Analysis Services. Disponible en Internet:
http://msdn.microsoft.com/en-us/library/ms175609%28v=sql.90%29.aspx,
consultado el 28 de abril de 2012.
9. Arshad Ali. 2012. Storage Modes in SQL Server Analysis Services. Disponible
en Internet: http://www.sql-server-performance.com/2009/ssas-storage-
modes/, consultado el 28 de abril de 2012.
10. Microsoft. 2012. Multidimensional Expressions (MDX) Reference. Disponible
en Internet: http://msdn.microsoft.com/en-us/library/ms145506.aspx,
consultado el 28 de abril de 2012.
11. Microsoft. 2012. Reporting Services (SSRS). Disponible en Internet:
http://msdn.microsoft.com/en-us/library/ms159106.aspx, consultado el 28 de
abril de 2012.
12. Microsoft. 2012. SQL Server Integration Services. Disponible en Internet:
http://msdn.microsoft.com/en-us/library/ms141026.aspx, consultado el 28 de
abril de 2012.
13. Microsoft. 2012. Microsoft SQL Server 2008 Management Studio. Disponible
en Internet: http://www.microsoft.com/en-us/download/details.aspx?id=7593,
consultado el 29 de abril de 2012.
14. Microsoft. 2012. Introducing Business Intelligence Development Studio.
Disponible en Internet: http://msdn.microsoft.com/en-
us/library/ms173767%28v=sql.105%29.aspx, consultado el 29 de abril de 2012.
15. Microsoft. 2012. Transact-SQL Reference (Transact-SQL). Disponible en
Internet: http://msdn.microsoft.com/en-
us/library/ms189826%28v=sql.90%29.aspx, consultado el 29 de abril de 2012.
48
16. Exforsys Inc. 2007. Advantages and Disadvantages to Using a Data
Warehouse. Disponible en Internet: http://www.exforsys.com/tutorials/data-
warehousing/advantages-and-disadvantages-to-using-a-data-warehouse.html,
consultado el 26 de abril de 2012.
17. Exforsys Inc. 2007. The Benefits of Data Warehouses. Disponible en Internet:
http://www.exforsys.com/tutorials/data-warehousing/data-warehouses-
benefits.html, consultado el 26 de abril de 2012.
49
APÉNDICE A
INFORMACIÓN SOBRE TABLAS DE LAS BASES DE DATOS
A continuación se presentan las tablas utilizadas junto con los atributos que
fueron utilizados efectivamente de las mismas y sus tipos de datos SQL
correspondientes. Todos los valores pueden ser null a menos que sean parte de la
clave primaria o se indique lo contrario.
A.1. Base de datos DBALEJANDRIA_STAGINGAREA:
a. TXT_LRDTS02 (COD_BCO_CONTR (CHAR(4)), COD_AGEN_CONTR
(CHAR(4)), CH_DIG1_CONTR (CHAR(6)), CH_DIG2_CONTR (CHAR(6)),
SEQ_CTA_CONTR (CHAR(10)), STATUS_GIRO (CHAR(1)), DT_STATUS
(CHAR(10))).
b. TXT_LRDTS21 (BCO_CONTR (CHAR(4)), AGEN_CONTR (CHAR(4)),
DIG1_CONTR (CHAR(6)), DIG2_CONTR (CHAR(6)), SEQ_CTA_CONTR
(CHAR(10)), COD_SUB_PROD (CHAR(4))).
c. TXT_FADTFAC (FAC_NCONTRAT_ENT (CHAR(4)), FAC_NCONTRAT_CENT
(CHAR(4)), FAC_NCONTRAT_DC (CHAR(2)), FAC_NCONTRAT_CP
(CHAR(2)), FAC_NCONTRAT_CTA (CHAR(8)), FAC_IESTFCT
(CHAR(2)), FAC_DULTCOB (CHAR(10)), FAC_NFACTURA (CHAR(15)),
FAC_MANTICIP (CHAR(20)), FAC_DVENCIM (CHAR(10))).
d. TXT_FADTCTR (CTR_NCONTRAT_ENT (CHAR(4)), CTR_NCONTRAT_CENT
(CHAR(4)), CTR_NCONTRAT_CP (CHAR(2)), CTR_NCONTRAT_CTA
(CHAR(8)), CTR_CTIPFAC (CHAR(1)), CTR_DACTIVA (CHAR(10))).
e. TXT_FADTPRC (PRC_CODCAR (CHAR(2)), PRC_TIPFACT (CHAR(1))).
f. TXT_UGDTMAE (ENTIOFI (CHAR(8)), DIGICCC1 (CHAR(1)), DIGICCC2
(CHAR(1)), CUENTA (CHAR(10)), SITPRES (CHAR(1)), FECSIT
(CHAR(30)), LIBRE_CAR5 (CHAR(10)), SALREAL (CHAR(20)),
SALTEOR (CHAR(20))).
50
g. TXT_LEDTCON (COD_EMPRESA (CHAR(4)), CENTRO_APORTAN
(CHAR(4)), DIGITOS_CTRL (CHAR(2)), COD_SERVICIO (CHAR(2)),
NUM_CONTRATO (CHAR(8)), TIPO_ULT_MODIF (CHAR(3)),
EST_CONTRATO (CHAR(2)), FEC_VAL_RESID (CHAR(30)),
EST_CARTERA (CHAR(2)), FEC_CAMBIO_CAR (CHAR(30))).
h. TXT_BTMAX0 (ENTIDAD (CHAR(4)), CENTRO_ALTA (CHAR(4)),
DIGICCC1 (CHAR(1)), DIGICCC2 (CHAR(1)), CUENTA (CHAR(10)),
SUBPRODU (CHAR(4)), SALDO_DISPUE (CHAR(20)), PRODUCTO
(CHAR(2))).
i. TXT_PEDT008 (CLAVCTA (CHAR(18)), CLASTIT (CHAR(3))).
j. TXT_MCDTCON (MCNENTCO (CHAR(4)), MCNOFICO (CHAR(4)),
MCTCONTR (CHAR(2)), MCNCONTR (CHAR(8)), MCLMOTBJ (CHAR(2)),
MCTTARJE (CHAR(2)), MCFBAJCO (CHAR(30))).
k. TXT_MCDTRGO (MCNENTCO (CHAR(4)), MCNOFICO (CHAR(4)),
MCTCONTR (CHAR(2)), MCNCONTR (CHAR(8)), MCTOTDEU
(CHAR(18))).
A.2. Base de datos SIF:
a. AT04 (Fecha_Cierre (PARTE DE LA CLAVE PRIMARIA, INT),
IDAplicativo (TINYINT), Credito (PARTE DE LA CLAVE PRIMARIA,
VARCHAR(30)), Credito_18 (CHAR(18)), Estado_Credito
(TINYINT), Situacion_credito (TINYINT), Naturaleza_cliente
(TINYINT), Tipo_Cartera (VARCHAR(4)), Fecha_liquidacion
(INT), Oficina (VARCHAR(5)), Cuotas (SMALLINT),
Cuotas_Vencidas (SMALLINT), Monto_V30d (DECIMAL(13,2)),
Monto_V60d (DECIMAL(13,2)), Monto_V90d (DECIMAL(13,2)),
Monto_V120d (DECIMAL(13,2)), Monto_V180d (DECIMAL(13,2)),
Monto_V1a (DECIMAL(13,2)), Monto_Vm1a (DECIMAL(13,2)),
Fecha_cierre_date (DATETIME), Fecha_liquidacion_date
(DATETIME), Carga_Manual (BIT)).
51
A.3. Base de datos Prototipo:
h. DimTiempo (ConsecutivoFecha (CLAVE PRIMARIA, INT), Fecha
(DATETIME, NOT NULL), Anho (INT), Mes (INT),
MesNombre(VARCHAR(20)), Semana (INT), SemanaNombre
(VARCHAR(15)), DiaAnho (INT), Dia (INT), DiaNombre
(VARCHAR(15)), DiaShort (VARCHAR(3)), Semestre (INT),
SemestreNombre (VARCHAR(15)), NumeroTri (INT), NombreTri
(VARCHAR(15)), MesF (INT), DiaF (INT), EsFeriado (BIT),
Feriado (VARCHAR(35)), EsFinSemana (BIT), SemanaF (INT),
SemanaNombreF (VARCHAR(15)).
i. APLICATIVO (Cod (CLAVE PRIMARIA, TINYINT), Nombre
(VARCHAR(30)).
j. SB34_ESTADO_CREDITO (Cod (CLAVE PRIMARIA, TINYINT), Nombre
(VARCHAR(30)).
k. SB35_SITUACION_CREDITO (Cod (CLAVE PRIMARIA, TINYINT),
Nombre (VARCHAR(20)).
l. SB76_NATURALEZA_CLIENTE (Cod (CLAVE PRIMARIA, TINYINT),
Descripcion (VARCHAR(20)).
m. TIPO_CARTERA (Cod (CLAVE PRIMARIA, VARCHAR(4))).
n. AT04 (Fecha_Cierre (PARTE DE LA CLAVE PRIMARIA, INT),
IDAplicativo (CLAVE FORÁNEA HACIA APLICATIVO(Cod), TINYINT),
Credito (PARTE DE LA CLAVE PRIMARIA, VARCHAR(30)),
Credito_18 (CHAR(18)), Estado_Credito (CLAVE FORÁNEA HACIA
SB34_ESTADO_CREDITO(Cod), TINYINT), Situacion_credito (CLAVE
FORÁNEA HACIA SB35_SITUACION_CREDITO(Cod), TINYINT),
Naturaleza_cliente (CLAVE FORÁNEA HACIA
SB76_NATURALEZA_CLIENTE(Cod), TINYINT), Tipo_Cartera (CLAVE
FORÁNEA HACIA TIPO_CARTERA(Cod), VARCHAR(4)),
Fecha_liquidacion (INT), Oficina (VARCHAR(5)), Cuotas
(SMALLINT), Cuotas_Vencidas (SMALLINT), Monto_V30d
(DECIMAL(13,2)), Monto_V60d (DECIMAL(13,2)), Monto_V90d
52
(DECIMAL(13,2)), Monto_V120d (DECIMAL(13,2)), Monto_V180d
(DECIMAL(13,2)), Monto_V1a (DECIMAL(13,2)), Monto_Vm1a
(DECIMAL(13,2)), Fecha_cierre_date (CLAVE FORÁNEA HACIA
DimTiempo(Fecha), DATETIME), Fecha_liquidacion_date (CLAVE
FORÁNEA HACIA DimTiempo(Fecha), DATETIME), Carga_Manual
(BIT)).
53
APÉNDICE B
REGISTROS DE EJEMPLO SUMINISTRADOS POR EL BANCO
A continuación se muestran los registros de ejemplo suministrados por el banco
para ciertas tablas de la base de datos DBALEJANDRIA_STAGINGAREA.
B.1. Tabla TXT_LEDTCON:
('0108','00023589','30','28','00079772',' ','CA02','AN','0029','0580','3870','C',' ',
' ','N','N','L','N','VEB','000100000 ','000013300000000 ',' ',' ',
'000000000000000 ','001 ','000000000000000 ','000000000000000 ','024 ','01 ','01 ','1',
' ','26 ','0108','0001',' ','0100020969','M','NEG','02100000 ','00000000 ',
'00000 ','001 ','M','20060326','001 ',' ','N','00 ','000 ',' ',' ','000000000000000 ',
' ','I','VA','0000000 ','000000000000000 ','0015000 ','000000000000000 ','0000000 ',
'000000000000000 ','0000000 ','000000000000000 ','0000000 ','000000000000000 ',
'0000000 ','000000000000000 ',' ','0000000 ','000000000000000 ',' ',
'0000000 ','000000000000000 ','F','N',' ','N','N','S','S','000000000000000 ','N',
'000000000000000 ','000000000000000 ','00300000 ','S','000013300000000 ',
'000002939115277 ','000000000000000 ','000002273476119 ','000000000000000 ',
' ','000000000000000 ',' ','000000000000000 ','000000000000000 ',
54
'000000000000000 ','000000000000000 ',' ','000000000001400 ',
'000000000000000 ','000000000000000 ',' ',' ','VI',' ',' ','N ',
'000001862000000 ','000001862000000 ','000000000000000 ','000002939115277 ',
'02100000 ','02100000 ','000013300000000 ','000000000000000 ','000000000000000 ',
'000002273476119 ','000000000000000 ','000000786916667 ','20060226','20060326',
'S','20080226','F','000000010000000 ','I','I','000000000000000 ','000000199500000 ',
'000000000000000 ','000000000000000 ','000000000000000 ','000000000000000 ',
'000000000000000 ','000000000000000 ','000000000000000 ','000000000000000 ',
'000000000000000 ','000000000000000 ','000000000000000 ','BMLZ',
'2006-01-26-17.01.38.222234','VP37656 ','2006-01-26-17.12.15.442556',
'VP37656 ','LE2CM110')
B.2. Tabla TXT_LRDTS02:
('0108','0061','7 ','1 ','2300004925','0000000001 ','0020200001 ','0000000111 ',
'05263180','23','2301',' ',' ','3','2002-04-19','00','2002-01-02','0108','0061','0108','0061',
'0108','0061','7','9','0100101923','VEB','2002-01-02','2002-04-19','2002-04-19','S',
'0445000 ','005 ','000001100000000000 ','00104241','0108','0087','1','1','0100004512',
'025 ','LR4C0036','BATCH ',' ',' ','000001100000000000 ','000000145490277000 ',
55
'000000000000000000 ','000000000000000000 ','000000000000000000 ','G','G',
' ','G','C',' ','2002-01-02','0001-01-01','30061 ',' ',
'000000000000000000 ','000000000000000000 ','2002-04-19-20.45.11.121017')
B.3. Tabla TXT_LRDTS21:
('0108','0001','3','7','2300006572','00172866','23','2301','07','00000000 ',
'000000000000000000 ','00000000 ','000000000000000000 ','00000000 ',
'000000000000000000 ','00000000 ','000000000000000000 ','2003-03-27','2003-07-25',
'0108','0001','0108','0001','2003-03-27','212 ','7512671 ','212 ','0000000000',' ',
' ','VEF','0108','0001','3','2','0100035451','000000001886600000 ',
'000000001886600000 ','000000000000000000 ','000000001886600000 ','LR4C0071',
'BATCH ','99900000 ','2003-03-271120 ','0001-01-01',
'0001-01-01','000000001886600000 ','000000000000000000 ',
'2012-04-30-21.32.58.050000')
B.4. Tabla TXT_FADTFAC:
('0108','0001','31','26','00055680','0-0378856 ','2008','00087858','02349543','N','N',
'2008-05-07','000000000000000 ','039 ','000000000002123 ','028000000 ',
'000000000000000 ','2008-05-06','000000000100000 ','000000010000000 ',
56
'2008-05-06','VEF','S',' ','0001-01-01','2008-06-15','2008-06-15',
'CT','2008-06-27','000000000070000 ','000000007000000 ','VEF','000000000070000 ',
'000000007000000 ','000000000000000 ','000000000000000 ','000000000000000 ',
'000000000000000 ','000000000000000 ','000000000000100-','000000000000000 ',
'000000000000000 ','000000000000000 ','2008-06-27',' ','000000000000000 ',
'0001-01-01','00 ','000000000100000 ','000000000000000 ','000000000000000 ',
'000000000000000 ','000000000000000 ',' ','0001-01-01','N','N','N','PI','0108',
'0001','37','01','00025006','N',' ','BOUY','2008-05-06-18.21.49.762794','A4C0300',
'2008-06-27-18.20.29.247599','A4C0650')
B.5. Tabla TXT_FADTCTR:
('0108','0001','31','26','00055680','F','D','VEF','00087858','0950','E','2007-09-24',
'2008-09-30','2008-09-30','A','0001-01-01','000 ',' ','000000000000000 ','BOUZ',
'2007-09-24-10.44.25.499396','VP34703','2008-09-30-18.21.24.871954','A4C6100')
B.6. Tabla TXT_FADTPRC:
('C','26','FA01','FACTORING CON RECURSO ','CC',
'CARTERA COMERCIAL ','0601 ','0604 ','M','0001-01-01','0000000000000.00',
' ','BZ7E','2006-04-05-11.27.38.763906','VH41101',
57
'2006-04-05-11.27.38.763906','VH41101')
B.7. Tabla TXT_FADTCBA:
('0108','0001','31','26','00055680','00081989','V','2007-09-24','9999-12-31',
'000000000000000 ','00000 ','000 ','000000000000000 ','00000 ','000 ',' ','N','N','N',
'000000010000000 ','000000000000000 ','000 ',' ','000000000000000 ','000 ','000 ',
' ','00000 ',' ','000000000000000 ',' ','ZOV0','2007-09-24-10.58.57.674692','VP34703',
'2007-09-24-10.58.57.674692','VP34703')
B.8. Tabla TXT_FADTTIN:
('0108','0001','31','26','00055680','00081989','V','2007-09-24','9999-12-31','P01','D10',
'P01','DP5','ZOV1','2007-09-24-11.13.43.125625','VP34703',
'2009-01-14-15.42.14.318140','VP41211')
B.9. Tabla TXT_FADTT07:
('DP1','VEF','2002-08-09','2004-12-07','001000000 ','000000000000000 ','000000000 ',
'000000000000000 ','000000000 ','000000000000000 ','000000000 ',
'000000000000000 ','000000000 ','000000000000000 ','000000000 ',
'000000000000000 ','000000000 ','000000000000000 ','000000000 ',
'000000000000000 ','000000000 ','000000000000000 ','000000000 ','000 ','000000000 ',
58
'000 ','000000000 ','000 ','000000000 ','000 ','000000000 ','000 ','000000000 ','000 ',
'000000000 ','000 ','000000000 ','000 ','000000000 ','000 ','000000000 ','BII2',
'2002-08-08-17.43.13.930614','VP27165','2004-12-07-17.32.45.873701','VP27165')
B.10. Tabla TXT_HAQLT190:
('02-05-2012','617800101171 ','1021','VEF','010844149100115205',' 15','950')
B.11. Tabla TXT_MCDTRGO:
('0108','0001','50','00252910','00000000000 ','00000000000 ','00000000000 ',
'00000000000 ','00000000003-','UV','A ','00 ','2012-04-30','MP4C6060',
'2012-05-01-01.22.24.469376','0000000 ','T1')
B.12. Tabla TXT_MCDTCON:
('0108','0001','50','00252910',' ',' ',' ',' ','N','VEF','1988-09-15','M',
'00000014000 ','00000000000 ','0000000 ',' ',' ',' ','00000000000 ','00000000000 ',
'0000000 ',' ','1900-01-01',' ','1900-01-01','1900-01-01','1900-01-01','1900-01-01',
'1900-01-01','00000000000 ','00000000003-','1900-01-01','00000000000 ',
'00000000003-','000000000 ','0141 ','000000 ','00000000000 ','1900-01-01',
'1900-01-01',' ','00000000000 ','0000000 ','1900-01-01','1900-01-01',' ','00000000000 ',
'0000000 ','1900-01-01','1900-01-01','2012-04-15-02.07.59.591116','0001','M',' ',
59
'1900-01-01','00000000000 ',' ',' ','1','00 ','1900-01-01','0140 ','000000 ','2012-04-14',
'1900-01-01','N64','1900-01-01',
'CONVERSION2000-08-21 999 ',' ',' ',
'1900-01-01','S','000000 ','0000 ',' ','0000000000000 ','0000000000000 ',' ',' ',
'00000000000 ','00000000000 ','00000000000 ','00000000000 ','00000000000 ',
'00000000000 ','00000000000 ','00000000000 ','2012-05-10',' ','1900-01-01','00000 ',
'MP4C1220',' ','000014000 ','1900-01-01','AUTO3005','0000000 ','540009','T1',
'1992-02-28',' ','0108','N',' ',' ',' ',' ','C','VEF')
B.13. Tabla TXT_PEDT001:
('00000208','X','0000000217','5','00','0000000217','0100','C','1900-01-01 ','0001-01-01 ',
'N','0001-01-01 ','0001-01-01 ','J','65',' ','S ',' ',
'EDIFICIOS COMERCIALE',' ',' ','-','Z',' ','VEN ','0001-01-01 ',
'SIN DIRECCION ','FICHERO CENTRAL ',' ',
' ','CARACAS ',' ','01','01010','VEN ',' ','000','0000000',' ',
'000','0000000',' ','000','0000000','0001-01-01 ','0108','0021','CONV ',' ','0001-01-01 ',
'CONV','PE4C8530','CONV','2006-02-26-01.18.29.990435','OTR','OTR',' P ',' ',' ',' ',
' ','000000000000','0000','00',123)
60
B.14. Tabla TXT_PEDT008:
('00000005','010800120100070117','T02','1998-07-13 ','1998-07-08 ','2003-08-26 ',
'C','0',' ','2003-08-26-01.36.39.833455',' ')
B.15. Tabla TXT_UGDTMAE:
('01080571','9600148012','6','8','01080571',' ','01080571','01080571','96','BE01',
'999','0604 ','3004','VEF ','0103030','000000000554900','000000000554900',
'000000000554900','2012-01-12','2012-01-12','2012-01-12','2012-01-31','2012-01-31',
'2016-01-31','0','2012-03-31','000000000524679','000000000524679','2012-03-23',
'2012-03-31','2012-04-30','2012-04-30','2012-01-12','0001-01-01','0001-01-01',
'2012-03-31','2012-04-30','00','00','2012-03-23','2012-01-12','000000000000000',
'0001-01-01','000000000000000','0','N','S','0','0','S','S','N','N','N','S','0','S','0',' ','0','0',' ',' ',
' ','N',' ',' ',' ','N','00','0001-01-01','0108','0571','0100007016','6','2','00915197','000','S',
'000000000000000','000000000000000','0000000','00003','N64',' ','00000001070',
'30571 ','000000000000000','000000000000000','000','0',' ','0','N','T','01','000',' ',
'000000000000000','000000000000000','000000000000000','000000000000000',
'000000000000000','000000000000000','000000000000000',' ',' 0571 ',' ','000',
' ','2012-01-31','CBE NP ','R','E','N','N','0103030','9999-12-31','9999-12-31',
61
'0001-01-01','0001-01-01','0001-01-01','P','L','N','N','N','001','031','000000000000000',
'000000000000000','S','N','F','2012-03-31','0108','3220','UB4CDI20','UB4CDI20',
'2012-04-30-23.56.18.482580','0000','000000','VEN','N','01080571',
'0000000000000000','0000000000000000',' ',' ','V','000000000000000',
'000000000000000','000000000000000','0001-01-01','0001-01-01','0001-01-01',
'000000000000000','000000000000000',' ','000000000000000','0001-01-01',
'0001-01-01','0001-01-01',' ','000000000000000','0001-01-01','0001-01-01',
'0001-01-01','0001-01-01','0001-01-01','000000000000000','000000000000000',
'000000000000000','NN ',' ',' ','000000000000000',
'000000000000000','0001-01-01','000000000000000',' ','0001-01-01','0001-01-01',
'0001-01-01','000000000000000')
62
APÉNDICE C
PROCEDIMIENTOS PARA LA INSERCIÓN DE DATOS EN LAS TABLAS DE
ORIGEN
C.1. Procedimiento prc_RandomInsertEfectos:
USE [SIF]
GO
DROP PROCEDURE [dbo].[prc_RandomInsertEfectos]
GO
CREATE PROCEDURE [dbo].[prc_RandomInsertEfectos]
@Filas int = 100
AS
BEGIN
declare @Bcn char(4) = '0100'
declare @Acn char(4) = ISNULL(RIGHT('000' +
convert(varchar,(SELECT MAX(SUBSTRING([CREDITO],5,4)) FROM
Prototipo.dbo.AT04 WHERE [IDAplicativo] = 23) + 1),4),'0000')
declare @Di1 char(1) = '7'
declare @Di2 char(1) = '1'
declare @Seqcn char(10)
63
declare @Stgir char(1)
declare @Dtst char(10) = '2012-01-31'
declare @Csp char(4)
declare @Ap int = 23
declare @Seq1 int = 0
declare @Seq2 int = 0
declare @Cont int = 0
WHILE @Cont < @Filas AND @Seq1 < 10000
BEGIN
WHILE @Cont < @Filas AND @Seq2 < 10000
BEGIN
SELECT @Seqcn = CONVERT(varchar,@Ap) + RIGHT('000' +
convert(varchar,@Seq1),4) + RIGHT('000' +
convert(varchar,@Seq2),4)
SELECT @Stgir = CONVERT(varchar, CAST(RAND() * 4 AS INT) + 1)
SELECT @Csp = CONVERT(varchar, CAST(RAND() * 100 AS INT))
INSERT INTO DBALEJANDRIA_STAGINGAREA.dbo.TXT_LRDTS02
([COD_BCO_CONTR], [COD_AGEN_CONTR], [CH_DIG1_CONTR],
[CH_DIG2_CONTR], [SEQ_CTA_CONTR], [STATUS_GIRO], [DT_STATUS])
SELECT @Bcn, @Acn, @Di1, @Di2, @Seqcn, @Stgir, @Dtst
64
INSERT INTO DBALEJANDRIA_STAGINGAREA.dbo.TXT_LRDTS21
([BCO_CONTR], [AGEN_CONTR], [DIG1_CONTR], [DIG2_CONTR],
[SEQ_CTA_CONTR], [COD_SUB_PROD])
SELECT @Bcn, @Acn, @Di1, @Di2, @Seqcn, @Csp
SELECT @Cont = @Cont + 1
SELECT @Seq2 = @Seq2 + 1
END
SELECT @Seq2 = 0
SELECT @Seq1 = @Seq1 + 1
END
END
GO
C.2. Procedimiento prc_RandomInsertFactoring:
USE [SIF]
GO
DROP PROCEDURE [dbo].[prc_RandomInsertFactoring]
GO
CREATE PROCEDURE [dbo].[prc_RandomInsertFactoring]
@Filas int = 100
65
AS
BEGIN
declare @Ent char(4) = '0108'
declare @Cent char(4) = ISNULL(RIGHT('000' +
convert(varchar,(SELECT MAX(SUBSTRING([CREDITO],5,4)) FROM
Prototipo.dbo.AT04 WHERE [IDAplicativo] = 26) + 1),4),'0000')
declare @Dc char(2) = '31'
declare @Cp char(2) = '26'
declare @Cta char(8)
declare @Iest char(2)
declare @Dult char(10) = '2012-01-31'
declare @Nfac char(15)
declare @Mant char(20)
declare @Dven char(10)
declare @Ctip char(1)
declare @Dact char(10)
declare @Seq1 int = 0
declare @Seq2 int = 0
declare @Cont int = 0
66
IF (SELECT COUNT(*) FROM
DBALEJANDRIA_STAGINGAREA.dbo.TXT_FADTPRC) < 10
BEGIN
DELETE FROM DBALEJANDRIA_STAGINGAREA.dbo.TXT_FADTPRC
WHILE @Cont < 10
BEGIN
INSERT INTO DBALEJANDRIA_STAGINGAREA.dbo.TXT_FADTPRC
([PRC_TIPFACT], [PRC_CODCAR])
SELECT @Cont, convert(varchar,CAST(RAND() * 100 AS INT))
SELECT @Cont = @Cont + 1
END
END
SELECT @Cont = 0
WHILE @Cont < @Filas AND @Seq1 < 10000
BEGIN
WHILE @Cont < @Filas AND @Seq2 < 10000
BEGIN
SELECT @Cta = RIGHT('000' + convert(varchar,@Seq1),4) +
RIGHT('000' + convert(varchar,@Seq2),4)
67
SELECT @Iest = CASE WHEN CAST(RAND() * 2 AS INT) = 0 THEN
'VE' ELSE 'CT' END
SELECT @Nfac = '0-' + CONVERT(varchar, CAST(RAND() * 1000000
AS INT))
SELECT @Mant = RIGHT('0000000000000000000' +
convert(varchar,CAST(RAND() * 1000000000 AS INT)),20)
SELECT @Dven = (SELECT TOP(1) CONVERT(char(10), Fecha, 20)
FROM Prototipo.dbo.DimTiempo ORDER BY NEWID())
SELECT @Ctip = CONVERT(varchar, CAST(RAND() * 10 AS INT))
SELECT @Dact = (SELECT TOP(1) CONVERT(char(10), Fecha, 20)
FROM Prototipo.dbo.DimTiempo ORDER BY NEWID())
INSERT INTO DBALEJANDRIA_STAGINGAREA.dbo.TXT_FADTFAC
([FAC_NCONTRAT_ENT], [FAC_NCONTRAT_CENT], [FAC_NCONTRAT_DC],
[FAC_NCONTRAT_CP], [FAC_NCONTRAT_CTA], [FAC_IESTFCT],
[FAC_DULTCOB], [FAC_NFACTURA], [FAC_MANTICIP], [FAC_DVENCIM])
SELECT @Ent, @Cent, @Dc, @Cp, @Cta, @Iest, @Dult, @Nfac,
@Mant, @Dven
INSERT INTO DBALEJANDRIA_STAGINGAREA.dbo.TXT_FADTCTR
([CTR_NCONTRAT_ENT], [CTR_NCONTRAT_CENT], [CTR_NCONTRAT_CP],
[CTR_NCONTRAT_CTA], [CTR_CTIPFAC], [CTR_DACTIVA])
SELECT @Ent, @Cent, @Cp, @Cta, @Ctip, @Dact
SELECT @Cont = @Cont + 1
SELECT @Seq2 = @Seq2 + 1
68
END
SELECT @Seq2 = 0
SELECT @Seq1 = @Seq1 + 1
END
END
GO
C.3. Procedimiento prc_RandomInsertPrestamos:
USE [SIF]
GO
DROP PROCEDURE [dbo].[prc_RandomInsertPrestamos]
GO
CREATE PROCEDURE [dbo].[prc_RandomInsertPrestamos]
@Filas int = 100
AS
BEGIN
declare @Ofi char(4) = ISNULL(RIGHT('000' +
convert(varchar,(SELECT MAX(SUBSTRING([CREDITO],5,4)) FROM
Prototipo.dbo.AT04 WHERE [IDAplicativo] = 96) + 1),4),'0000')
declare @Entiofi char(8) = '0116' + @Ofi
69
declare @Di1 char(1) = '6'
declare @Di2 char(1) = '8'
declare @Cuenta char(10)
declare @Sitpres char(1)
declare @Fecs char(10) = '2012-01-31'
declare @LibC5 char(10)
declare @Ap int = 96
declare @Salr int
declare @Salt int
declare @Seq1 int = 0
declare @Seq2 int = 0
declare @Cont int = 0
WHILE @Cont < @Filas AND @Seq1 < 10000
BEGIN
WHILE @Cont < @Filas AND @Seq2 < 10000
BEGIN
SELECT @Cuenta = CONVERT(varchar,@Ap) + RIGHT('000' +
convert(varchar,@Seq1),4) + RIGHT('000' +
convert(varchar,@Seq2),4)
70
SELECT @Sitpres = CONVERT(varchar, CAST(RAND() * 4 AS INT))
SELECT @LibC5 = ' ' + CONVERT(varchar, CAST(RAND() * 100 AS
INT))
SELECT @Salr = CAST(RAND() * 10000000 AS INT)
SELECT @Salt = CAST(RAND() * 10000000 AS INT)
INSERT INTO
DBALEJANDRIA_STAGINGAREA.dbo.TXT_UGDTMAE([ENTIOFI], [DIGICCC1],
[DIGICCC2], [CUENTA], [SITPRES], [FECSIT], [LIBRE_CAR5],
[SALREAL], [SALTEOR])
SELECT @Entiofi, @Di1, @Di2, @Cuenta, @Sitpres, @Fecs,
@LibC5, @Salr, @Salt
SELECT @Cont = @Cont + 1
SELECT @Seq2 = @Seq2 + 1
END
SELECT @Seq2 = 0
SELECT @Seq1 = @Seq1 + 1
END
END
GO
C.4. Procedimiento prc_RandomInsertLeasing:
71
USE [SIF]
GO
DROP PROCEDURE [dbo].[prc_RandomInsertLeasing]
GO
CREATE PROCEDURE [dbo].[prc_RandomInsertLeasing]
@Filas int = 100
AS
BEGIN
declare @Codem char(4) = '0124'
declare @Cenap char(4) = ISNULL(RIGHT('000' +
convert(varchar,(SELECT MAX(SUBSTRING([CREDITO],5,4)) FROM
Prototipo.dbo.AT04 WHERE [IDAplicativo] = 28) + 1),4),'0000')
declare @Dig char(2) = '30'
declare @Codser char(2) = '28'
declare @Numcon char(8)
declare @Tum char(3)
declare @Estcon char(2)
declare @Fvalres char(10) = '2012-01-31'
declare @Estcar char(2) = 'VE'
72
declare @Feccamcar char(10) = '2012-01-31'
declare @Seq1 int = 0
declare @Seq2 int = 0
declare @Cont int = 0
WHILE @Cont < @Filas AND @Seq1 < 10000
BEGIN
WHILE @Cont < @Filas AND @Seq2 < 10000
BEGIN
SELECT @Numcon = RIGHT('000' + convert(varchar,@Seq1),4) +
RIGHT('000' + convert(varchar,@Seq2),4)
SELECT @Tum = ' ' + CONVERT(varchar, CAST(RAND() * 100 AS
INT))
SELECT @Estcon = CASE CAST(RAND() * 4 AS INT) WHEN 0 THEN
'AC' WHEN 1 THEN 'NO' WHEN 2 THEN 'FI' ELSE 'RL' END
INSERT INTO DBALEJANDRIA_STAGINGAREA.dbo.TXT_LEDTCON
([COD_EMPRESA], [CENTRO_APORTAN], [DIGITOS_CTRL], [COD_SERVICIO],
[NUM_CONTRATO], [TIPO_ULT_MODIF], [EST_CONTRATO],
[FEC_VAL_RESID], [EST_CARTERA], [FEC_CAMBIO_CAR])
SELECT @Codem, @Cenap, @Dig, @Codser, @Numcon, @Tum,
@Estcon, @Fvalres, @Estcar, @Feccamcar
SELECT @Cont = @Cont + 1
73
SELECT @Seq2 = @Seq2 + 1
END
SELECT @Seq2 = 0
SELECT @Seq1 = @Seq1 + 1
END
END
GO
C.5. Procedimiento prc_RandomInsertSobregiros:
USE [SIF]
GO
DROP PROCEDURE [dbo].[prc_RandomInsertSobregiros]
GO
CREATE PROCEDURE [dbo].[prc_RandomInsertSobregiros]
@Filas int = 100
AS
BEGIN
declare @Ent char(4) = '0132'
74
declare @Cenalt char(4) = ISNULL(RIGHT('000' +
convert(varchar,(SELECT MAX(SUBSTRING([CREDITO],5,4)) FROM
Prototipo.dbo.AT04 WHERE [IDAplicativo] = 1) + 1),4),'0000')
declare @Di1 char(1) = '0'
declare @Di2 char(1) = '4'
declare @Cuenta char(10)
declare @Subpr char(4)
declare @Saldis char(20)
declare @Prod char(2) = '01'
declare @Clastit char(3) = 'T01'
declare @Seq1 int = 0
declare @Seq2 int = 0
declare @Cont int = 0
WHILE @Cont < @Filas AND @Seq1 < 10000
BEGIN
WHILE @Cont < @Filas AND @Seq2 < 10000
BEGIN
SELECT @Cuenta = '01' + RIGHT('000' +
convert(varchar,@Seq1),4) + RIGHT('000' +
convert(varchar,@Seq2),4)
75
SELECT @Subpr = CONVERT(varchar, CAST(RAND() * 100 AS INT))
SELECT @Saldis = CONVERT(varchar, -1 * CAST(RAND() *
1000000000 AS INT))
INSERT INTO DBALEJANDRIA_STAGINGAREA.dbo.TXT_BTMAX0
([ENTIDAD], [CENTRO_ALTA], [DIGICCC1], [DIGICCC2], [CUENTA],
[SUBPRODU], [SALDO_DISPUE], [PRODUCTO])
SELECT @Ent, @Cenalt, @Di1, @Di2, @Cuenta, @Subpr, @Saldis,
@Prod
INSERT INTO
DBALEJANDRIA_STAGINGAREA.dbo.TXT_PEDT008([CLAVCTA], [CLASTIT])
SELECT (@Ent+@Cenalt+@Cuenta), @Clastit
SELECT @Cont = @Cont + 1
SELECT @Seq2 = @Seq2 + 1
END
SELECT @Seq2 = 0
SELECT @Seq1 = @Seq1 + 1
END
END
GO
C.6. Procedimiento prc_RandomInsertMediosPago:
76
USE [SIF]
GO
DROP PROCEDURE [dbo].[prc_RandomInsertMediosPago]
GO
CREATE PROCEDURE [dbo].[prc_RandomInsertMediosPago]
@Filas int = 100
AS
BEGIN
declare @Ment char(4) = '0140'
declare @Mofi char(4) = ISNULL(RIGHT('000' +
convert(varchar,(SELECT MAX(SUBSTRING([CREDITO],5,4)) FROM
Prototipo.dbo.AT04 WHERE [IDAplicativo] = 50) + 1),4),'0000')
declare @Tcon char(2) = '50'
declare @Ncon char(8)
declare @Mot char(2)
declare @Tarj char(2)
declare @Baj char(10) = '2012-01-31'
declare @Totdeu int
declare @Seq1 int = 0
77
declare @Seq2 int = 0
declare @Cont int = 0
WHILE @Cont < @Filas AND @Seq1 < 10000
BEGIN
WHILE @Cont < @Filas AND @Seq2 < 10000
BEGIN
SELECT @Ncon = RIGHT('000' + convert(varchar,@Seq1),4) +
RIGHT('000' + convert(varchar,@Seq2),4)
SELECT @Mot = CASE CAST(RAND() * 2 AS INT) WHEN 0 THEN 'CS'
ELSE 'CL' END
SELECT @Tarj = CONVERT(varchar, CAST(RAND() * 100 AS INT))
SELECT @Totdeu = CAST(RAND() * 1000000 AS INT)
INSERT INTO DBALEJANDRIA_STAGINGAREA.dbo.TXT_MCDTCON
([MCNENTCO], [MCNOFICO], [MCTCONTR], [MCNCONTR], [MCLMOTBJ],
[MCTTARJE], [MCFBAJCO])
SELECT @Ment, @Mofi, @Tcon, @Ncon, @Mot, @Tarj, @Baj
INSERT INTO DBALEJANDRIA_STAGINGAREA.dbo.TXT_MCDTRGO
([MCNENTCO], [MCNOFICO], [MCTCONTR], [MCNCONTR], [MCTOTDEU])
SELECT @Ment, @Mofi, @Tcon, @Ncon, @Totdeu
SELECT @Cont = @Cont + 1
78
SELECT @Seq2 = @Seq2 + 1
END
SELECT @Seq2 = 0
SELECT @Seq1 = @Seq1 + 1
END
END
GO
79
APÉNDICE D
POSIBLES VALORES PARA LOS DATOS ALEATORIOS INSERTADOS EN LAS
TABLAS DE ORIGEN
D.1. Tabla TXT_LRDTS02:
a. COD_BCO_CONTR: ‘0100’, escogido arbitrariamente.
b. COD_AGEN_CONTR: el valor depende de los valores que ya existan para
registros del mismo aplicativo en la base de datos histórica, que comienza en
‘0000’ y que aumenta de manera secuencial cada vez que se ejecuta el
proceso completo de manera sucesiva mientras no sea borrada la base de
datos histórica. Por ejemplo, la primera vez que se ejecuta el proceso de la
solución, toma el valor ‘0000’, el cual llega a la base de datos histórica. Si se
ejecuta de nuevo, verifica la base de datos histórica y toma el valor siguiente,
que es ‘0001’. Sin embargo, si se borra la base de datos histórica, al ejecutar
de nuevo el proceso de la solución, este campo toma de nuevo el valor ‘0000’.
c. CH_DIG1_CONTR: ‘7 ’, escogido arbitrariamente.
d. CH_DIG2_CONTR: ‘1 ’, escogido arbitrariamente.
e. SEQ_CTA_CONTR: los primeros dos caracteres son ‘23’, número que identifica
al aplicativo. Después, los siguientes ocho caracteres corresponden a una
secuencia numérica que comienza en ‘00000000’ y aumenta de uno en uno a
medida que se van generando los registros aleatorios dentro del
procedimiento.
f. STATUS_GIRO: toma de manera aleatoria cualquier valor comprendido entre
‘1’ y ‘4’, incluidos estos, si se interpretan como enteros, con probabilidad
uniformemente distribuida.
g. DT_STATUS: toma el valor ‘2012-01-31’, el cual posteriormente se
interpreta como una fecha, específicamente el 31 de enero de 2012. En este
80
informe de pasantía, las fechas serán mostradas con el formato AAAA-MM-DD,
donde AAAA es el año, MM es el mes y DD es el día.
D.2. Tabla TXT_LRDTS21:
a. BCO_CONTR: se inserta el mismo valor que para el atributo COD_BCO_CONTR
de la tabla TXT_LRDTS02.
b. AGEN_CONTR: se inserta el mismo valor que para el atributo
COD_AGEN_CONTR de la tabla TXT_LRDTS02.
c. DIG1_CONTR: se inserta el mismo valor que para el atributo CH_DIG1_CONTR
de la tabla TXT_LRDTS02.
d. DIG2_CONTR: se inserta el mismo valor que para el atributo CH_DIG2_CONTR
de la tabla TXT_LRDTS02.
e. SEQ_CTA_CONTR: se inserta el mismo valor que para el atributo
SEQ_CTA_CONTR de la tabla TXT_LRDTS02.
h. COD_SUB_PROD: toma de manera aleatoria cualquier valor comprendido entre
‘0 ’ y ’99 ’, incluidos estos, si se interpretan como enteros, con
probabilidad uniformemente distribuida.
D.3. Tabla TXT_FADTPRC:
a. PRC_TIPFACT: los valores comprendidos entre ‘0’ y ‘9’, incluidos estos, si
se interpretan como enteros.
b. PRC_CODCAR: toma de manera aleatoria cualquier valor comprendido entre ‘0
’ y ‘99’, incluidos estos, si se interpretan como enteros, con probabilidad
uniformemente distribuida.
D.4. Tabla TXT_FADTFAC:
a. FAC_NCONTRAT_ENT: ‘0100’, escogido arbitrariamente.
81
b. FAC_NCONTRAT_CENT: el valor depende de los valores que ya existan para
registros del mismo aplicativo en la base de datos histórica, que comienza en
‘0000’ y que aumenta de manera secuencial cada vez que se ejecuta el
proceso completo de manera sucesiva mientras no sea borrada la base de
datos histórica. Por ejemplo, la primera vez que se ejecuta el proceso de la
solución, toma el valor ‘0000’, el cual llega a la base de datos histórica. Si se
ejecuta de nuevo, verifica la base de datos histórica y toma el valor siguiente,
que es ‘0001’. Sin embargo, si se borra la base de datos histórica, al ejecutar
de nuevo el proceso de la solución, este campo toma de nuevo el valor ‘0000’.
c. FAC_NCONTRAT_DC: ‘31’, escogido arbitrariamente.
d. FAC_NCONTRAT_CP: ‘26’, corresponde al número del aplicativo.
e. FAC_NCONTRAT_CTA: corresponde a una secuencia numérica que comienza en
‘00000000’ y aumenta de uno en uno a medida que se van generando los
registros aleatorios dentro del ciclo.
f. FAC_IESTFCT: toma de manera aleatoria o el valor ‘VE’ o el valor ‘CT’, con
la misma probabilidad para ambos.
g. FAC_DULTCOB: toma el valor ‘2012-01-31’, el cual posteriormente se
interpreta como una fecha, específicamente el 31 de enero de 2012.
h. FAC_NFACTURA: los primeros dos caracteres son ‘0-’. Después, los siguientes
seis caracteres corresponden a un número seleccionado de manera aleatoria
con probabilidad uniforme que puede ir desde ‘0 ’ hasta ‘999999’.
i. FAC_MANTICIP: toma de manera aleatoria cualquier valor comprendido entre
‘00000000000000000000’ y ‘00000000000999999999’, incluidos estos, si
se interpretan como enteros, con probabilidad uniformemente distribuida.
j. FAC_DVENCIM: toma una fecha de manera aleatoria con probabilidad
uniforme de la tabla de dimensión DimTiempo de la base de datos
Prototipo, interpretada como una cadena de diez caracteres, como por
ejemplo ‘2011-11-25’, la cual correspondería al 25 de noviembre de 2011.
D.5. Tabla TXT_FADTCTR:
82
a. CTR_NCONTRAT_ENT: se inserta el mismo valor que para el atributo
FAC_NCONTRAT_ENT de la tabla TXT_FADTFAC.
b. CTR_NCONTRAT_CENT: se inserta el mismo valor que para el atributo
FAC_NCONTRAT_CENT de la tabla TXT_FADTFAC.
c. CTR_NCONTRAT_CP: se inserta el mismo valor que para el atributo
FAC_NCONTRAT_CP de la tabla TXT_FADTFAC.
d. CTR_NCONTRAT_CTA: se inserta el mismo valor que para el atributo
FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC.
e. CTR_CTIPFAC: toma de manera aleatoria cualquier valor comprendido entre
‘0 ’ y ‘9’, incluidos estos, si se interpretan como enteros, con probabilidad
uniformemente distribuida.
f. CTR_DACTIVA: toma una fecha de manera aleatoria con probabilidad
uniforme de la tabla de dimensión DimTiempo de la base de datos
Prototipo, de manera similar a como lo hace el atributo FAC_DVENCIM de la
tabla TXT_FADTFAC.
D.6. Tabla TXT_UGDTMAE:
a. ENTIOFI: los primeros cuatro caracteres son ‘0116’, escogidos
arbitrariamente. Después, los siguientes cuatro caracteres dependen de los
valores que ya existan para registros del mismo aplicativo en la base de datos
histórica, que comienza en ‘0000’ y que aumenta de manera secuencial cada
vez que se ejecuta el proceso completo de manera sucesiva mientras no sea
borrada la base de datos histórica. Por ejemplo, la primera vez que se ejecuta
el proceso de la solución, toman el valor ‘0000’, el cual llega a la base de
datos histórica. Si se ejecuta de nuevo, verifica la base de datos histórica y
toman el valor siguiente, que es ‘0001’. Sin embargo, si se borra la base de
datos histórica, al ejecutar de nuevo el proceso de la solución, estos cuatro
caracteres toman de nuevo el valor ‘0000’.
b. DIGICCC1: ‘6’, escogido arbitrariamente.
83
c. DIGICCC2: ‘8’, escogido arbitrariamente.
d. CUENTA: los primeros dos caracteres son ‘96’, número que identifica al
aplicativo. Después, los siguientes ocho caracteres corresponden a una
secuencia numérica que comienza en ‘00000000’ y aumenta de uno en uno a
medida que se van generando los registros aleatorios dentro del
procedimiento.
e. SITPRES: toma de manera aleatoria cualquier valor comprendido entre ‘0’ y
‘3’, incluidos estos, si se interpretan como enteros, con probabilidad
uniformemente distribuida.
f. FECSIT: toma el valor ‘2012-01-31’, el cual posteriormente se interpreta
como una fecha, específicamente el 31 de enero de 2012.
g. LIBRE_CAR5: toma de manera aleatoria cualquier valor entre
‘ 1 ’ y ‘ 99 ’, incluidos estos, si se interpretan como
enteros, con probabilidad uniformemente distribuida.
h. SALREAL: toma de manera aleatoria cualquier valor comprendido entre
‘0 ’ y ‘9999999 ’, incluidos estos, si
se interpretan como enteros, con probabilidad uniformemente distribuida.
i. SALTEOR: toma de manera aleatoria cualquier valor comprendido entre
‘0 ’ y ‘9999999 ’, incluidos estos, si
se interpretan como enteros, con probabilidad uniformemente distribuida.
D.7. Tabla TXT_LEDTCON:
a. COD_EMPRESA: ‘0124’, escogido arbitrariamente.
b. CENTRO_APORTAN: el valor depende de los valores que ya existan para
registros del mismo aplicativo en la base de datos histórica, que comienza en
‘0000’ y que aumenta de manera secuencial cada vez que se ejecuta el
proceso completo de manera sucesiva mientras no sea borrada la base de
datos histórica. Por ejemplo, la primera vez que se ejecuta el proceso de la
solución, toma el valor ‘0000’, el cual llega a la base de datos histórica. Si se
84
ejecuta de nuevo, verifica la base de datos histórica y toma el valor siguiente,
que es ‘0001’. Sin embargo, si se borra la base de datos histórica, al ejecutar
de nuevo el proceso de la solución, este campo toma de nuevo el valor ‘0000’.
c. DIGITOS_CTRL: ‘30’, escogido arbitrariamente.
d. COD_SERVICIO: ‘28’, corresponde al número del aplicativo.
e. NUM_CONTRATO: corresponde a una secuencia numérica que comienza en
‘00000000’ y aumenta de uno en uno a medida que se van generando los
registros aleatorios dentro del procedimiento.
f. TIPO_ULT_MODIF: toma de manera aleatoria cualquier valor comprendido
entre ‘ 0 ’ y ‘ 99’, incluidos estos, si se interpretan como enteros, con
probabilidad uniformemente distribuida.
g. EST_CONTRATO: toma de manera aleatoria cualquiera de los siguientes
valores: ‘AC’, ‘NO’, ‘FI’ y ‘RL’, con probabilidad uniformemente
distribuida.
h. FEC_VAL_RESID: toma el valor ‘2012-01-31’, el cual posteriormente se
interpreta como una fecha, específicamente el 31 de enero de 2012.
i. EST_CARTERA: toma el valor ‘VE’.
j. FEC_CAMBIO_CAR: toma el valor ‘2012-01-31’, el cual posteriormente se
interpreta como una fecha, específicamente el 31 de enero de 2012.
D.8. Tabla TXT_BTMAX0:
a. ENTIDAD: ‘0132’, escogido arbitrariamente.
b. CENTRO_ALTA: el valor depende de los valores que ya existan para registros
del mismo aplicativo en la base de datos histórica, que comienza en ‘0000’ y
que aumenta de manera secuencial cada vez que se ejecuta el proceso
completo de manera sucesiva mientras no sea borrada la base de datos
histórica. Por ejemplo, la primera vez que se ejecuta el proceso de la solución,
toma el valor ‘0000’, el cual llega a la base de datos histórica. Si se ejecuta
de nuevo, verifica la base de datos histórica y toma el valor siguiente, que es
85
‘0001’. Sin embargo, si se borra la base de datos histórica, al ejecutar de
nuevo el proceso de la solución, este campo toma de nuevo el valor ‘0000’.
c. DIGICCC1: ‘0’, escogido arbitrariamente.
d. DIGICCC2: ‘4’, escogido arbitrariamente.
e. CUENTA: los primeros dos caracteres son ‘01’, número que identifica al
aplicativo. Después, los siguientes ocho caracteres corresponden a una
secuencia numérica que comienza en ‘00000000’ y aumenta de uno en uno a
medida que se van generando los registros aleatorios dentro del
procedimiento.
f. SUBPRODU: toma de manera aleatoria cualquier valor entre ‘0 ’ y ’99 ’,
incluidos estos, si se interpretan como enteros, con probabilidad
uniformemente distribuida.
j. SALDO_DISPUE: toma de manera aleatoria cualquier valor comprendido entre
‘-999999999 ’ y ‘0 ’, incluidos estos, si
se interpretan como enteros, con probabilidad uniformemente distribuida.
k. PRODUCTO: toma el valor ‘01’.
D.9. Tabla TXT_PEDT008:
a. CLAVCTA: se inserta el valor correspondiente a la concatenación de los
atributos ENTIDAD, CENTRO_ALTA y CUENTA, en ese mismo orden, del registro
insertado en la tabla TXT_BTMAX0 en el mismo ciclo.
b. CLASTIT: toma el valor ‘T01’.
D.10. Tabla TXT_MCDTCON:
a. MCNENTCO: ‘0140’, escogido arbitrariamente.
b. MCNOFICO: el valor depende de los valores que ya existan para registros del
mismo aplicativo en la base de datos histórica, que comienza en ‘0000’ y que
aumenta de manera secuencial cada vez que se ejecuta el proceso completo de
manera sucesiva mientras no sea borrada la base de datos histórica. Por
86
ejemplo, la primera vez que se ejecuta el proceso de la solución, toma el valor
‘0000’, el cual llega a la base de datos histórica. Si se ejecuta de nuevo,
verifica la base de datos histórica y toma el valor siguiente, que es ‘0001’.
Sin embargo, si se borra la base de datos histórica, al ejecutar de nuevo el
proceso de la solución, este campo toma de nuevo el valor ‘0000’.
c. MCTCONTR: ‘50’, corresponde al número del aplicativo.
d. MCNCONTR: corresponde a una secuencia numérica que comienza en
‘00000000’ y aumenta de uno en uno a medida que se van generando los
registros aleatorios dentro del procedimiento.
e. MCLMOTBJ: toma de manera aleatoria o el valor ‘CS’ o el valor ‘CL’, con la
misma probabilidad para ambos.
f. MCTTARJE: toma de manera aleatoria cualquier valor entre ‘0 ’ y ’99’,
incluidos estos, si se interpretan como enteros, con probabilidad
uniformemente distribuida.
l. MCFBAJCO: toma el valor ‘2012-01-31’, el cual posteriormente se interpreta
como una fecha, específicamente el 31 de enero de 2012.
D.11. Tabla TXT_MCDTRGO:
a. MCNENTCO: se inserta el mismo valor que para el atributo MCNENTCO de la
tabla TXT_MCDTCON.
b. MCNOFICO: se inserta el mismo valor que para el atributo MCNOFICO de la
tabla TXT_MCDTCON.
c. MCTCONTR: se inserta el mismo valor que para el atributo MCTCONTR de la
tabla TXT_MCDTCON.
d. MCNCONTR: se inserta el mismo valor que para el atributo MCNCONTR de la
tabla TXT_MCDTCON.
e. MCTODDEU: toma de manera aleatoria cualquier valor comprendido entre
‘0 ’ y ‘999999 ’, incluidos estos, si se
interpretan como enteros, con probabilidad uniformemente distribuida.
87
APÉNDICE E
DESCRIPCIÓN DE SCRIPTS DE CARGA Y TRANSFORMACIÓN DE DATOS
E.1 Script ’00.Universo.sql’
En este script, se hace en primer lugar la declaración de una variable de tipo INT
llamada @FechaCierre, a la cual se le asigna el valor retornado por la función
fx_FechaCierre, almacenada en la base de datos SIF y que actualmente retorna
el valor 20120131, el cual se interpreta como la fecha 31 de enero de 2012. Después
se pasa a la inserción de registros en la tabla AT04 de SIF, específicamente para los
campos Fecha_Cierre, IDAplicativo, Credito, Credito_18, Estado_credito
y Tipo_cartera, a partir de las tablas de la base de datos origen
DBALEJANDRIA_STAGINGAREA. Por último, se realiza una actualización y una
eliminación de registros sobre la tabla AT04.
La inserción de los registros en la tabla AT04 se realiza secuencialmente y por
grupos. Cada grupo corresponde a un aplicativo y se selecciona mediante una
declaración SELECT. Los grupos son unidos mediante la operación de grupos UNION.
E.1.1. Grupo correspondiente al aplicativo “Efectos”
Para este aplicativo, la tabla AT04 toma valores de la combinación de las tablas
TXT_LRDTS02 y TXT_LRDTS21. La regla de combinación es que los valores del
atributo CONTRATO sea igual en ambas tablas. CONTRATO es un atributo calculado
para ambas tablas y corresponde, para TXT_LRDTS02, a la concatenación de los
atributos COD_BCO_CONTR, COD_AGEN_CONTR, CH_DIG1_CONTR, CH_DIG2_CONTR y
SEQ_CTA_CONTR, y para TXT_LRDTS21, a la concatenación de los atributos
BCO_CONTR, AGEN_CONTR, DIG1_CONTR, DIG2_CONTR y SEQ_CTA_CONTR.
88
Este grupo se divide, a su vez, en dos subgrupos, el primero correspondiente al de
los créditos activos y castigados y el segundo al de los créditos castigados. La
condición para que sea un crédito pertenezca al primer subgrupo es que el atributo
STATUS_GRUPO de la tabla TXT_LRDTS02 sea ‘1’ o ‘2’. Las condiciones para que
un crédito pertenezca al segundo subgrupo son que el atributo STATUS_GRUPO de la
tabla TXT_LRDTS02 sea ‘3’ o ‘4’, que el mismo número de contrato no aparezca en
el subgrupo anterior y que el atributo DT_STATUS de TXT_LRDTS02, interpretado
como fecha sea igual a la variable @FechaCierre, interpretada como fecha (en este
caso, DT_STATUS tendría que tener el valor ‘2012-01-31’). En ambos casos, los
caracteres once y doce de CONTRATO deben ser ‘2’ y ‘3’, respectivamente.
Los valores insertados para los registros de la tabla AT04 son:
a. Fecha_Cierre toma el valor de la variable @FechaCierre.
b. IDAplicativo toma siempre el valor 23, correspondiente al presente
aplicativo.
c. Credito toma el valor del atributo calculado CONTRATO de la tabla
TXT_LRDTS02.
d. Credito_18 toma el valor correspondiente a la concatenación de los primeros
ocho caracteres y los últimos diez caracteres del atributo calculado CONTRATO
de la tabla TXT_LRDTS02.
e. Estado_credito toma el valor 1 si se trata de un crédito activo o castigado y
2 si se trata de un crédito cancelado.
f. Tipo_cartera toma el valor del atributo COD_SUB_PROD de la tabla
TXT_LRDTS21.
E.1.2. Grupo correspondiente al aplicativo “Factoring”
Para este aplicativo, la tabla AT04 toma valores de la combinación de las tablas
TXT_FADTFAC, TXT_FADTCTR y TXT_FADTPRC. Las regla de combinación son que la
concatenación de los atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT,
89
FAC_NCONTRAT_CP y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC sea igual a la
concatenación de los atributos CTR_NCONTRAT_ENT, CTR_NCONTRAT_CENT,
CTR_NCONTRAT_CP y CTR_NCONTRAT_CTA de la tabla TXT_FADTCTR y que el valor
del atributo CTR_CTIPFAC de la tabla TXT_FADTCTR sea igual al valor del atributo
PRC_TIPFACT de la tabla TXT_FADTPRC.
Este grupo se divide, a su vez, en dos subgrupos, el primero correspondiente al de
los créditos activos y castigados y el segundo al de los créditos castigados. La
condición para que sea un crédito pertenezca al primer subgrupo es que el atributo
FAC_IESTFCT de la tabla TXT_FADTFAC no sea ni ‘CT’, ni ‘AN’, ni ‘PM’. Las
condiciones para que un crédito pertenezca al segundo subgrupo son que el atributo
FAC_IESTFCT de la tabla TXT_FADTFAC sea ‘CT’ y que la concatenación de los
atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT, FAC_NCONTRAT_CP y
FAC_NCONTRAT_CTA no sea la misma en ningún registro del subgrupo anterior. En
ambos casos, el atributo FAC_CONTRAT_CP de la tabla TXT_FADTFAC debe ser igual
a 26.
Los valores insertados para los registros de la tabla AT04 son:
a. Fecha_Cierre toma el valor de la variable @FechaCierre.
b. IDAplicativo toma siempre el valor 26, correspondiente al presente
aplicativo.
c. Credito toma el valor correspondiente a la concatenación de los atributos
FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT, FAC_NCONTRAT_DC,
FAC_NCONTRAT_CP y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC.
d. Credito_18 toma el valor correspondiente a la concatenación de los atributos
FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT, FAC_NCONTRAT_CP y
FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC.
e. Estado_credito toma el valor 1 si se trata de un crédito activo o castigado y
2 si se trata de un crédito cancelado.
90
f. Tipo_cartera toma el valor del atributo PRC_CODCAR de la tabla
TXT_FADTPRC.
E.1.3. Grupo correspondiente al aplicativo “Préstamos”
Para este aplicativo, la tabla AT04 toma valores de la tabla TXT_UGDTMAE.
Las condiciones para que un registro de la tabla TXT_UGDTMAE sea seleccionado
son:
a. Que el atributo SITPRES sea ‘0’, ‘2’ o ‘3’, o que el atributo sea ‘1’ y que
el atributo FECSIT, interpretado como fecha, sea igual a la variable
@FechaCierre, interpretada como fecha (en este caso, FECSIT tendría que
tener el valor ‘2012-01-31’).
b. Que los primeros dos caracteres de CUENTA sean ‘9’ y ‘6’, respectivamente.
Los valores insertados para los registros de la tabla AT04 son:
a. Fecha_Cierre toma el valor de la variable @FechaCierre.
b. IDAplicativo toma siempre el valor 96, correspondiente al presente
aplicativo.
c. Credito toma el valor correspondiente a la concatenación de los atributos
ENTIOFI, DIGICCC1, DIGICCC2 y CUENTA.
d. Credito_18 toma el valor correspondiente a la concatenación de los atributos
ENTIOFI y CUENTA.
e. Estado_credito toma el valor 1 si el atributo SITPRES es ‘0’, ‘2’ o ‘3’ y
el valor 2 si el atributo es ‘1’ y el atributo FECSIT, interpretado como fecha,
es igual a la variable @FechaCierre.
f. Tipo_cartera toma el valor de la sub-cadena de caracteres del atributo
LIBRE_CAR5 que va desde el segundo carácter hasta el tercero, incluidos
ambos.
91
E.1.4. Grupo correspondiente al aplicativo “Leasing”
Para este aplicativo, la tabla AT04 toma valores de la tabla TXT_LEDTCON.
Este grupo se divide, a su vez, en tres subgrupos, el primero correspondiente al de
los créditos activos, el segundo al de los créditos cancelados y el tercero al de los
créditos castigados. La condición para que sea un crédito pertenezca al primer
subgrupo es que el atributo EST_CONTRATO sea ni ‘AC’ o ‘NO’. Las condiciones
para que un crédito pertenezca al segundo subgrupo son que el atributo
EST_CONTRATO sea ‘FI’ y que el atributo FEC_VAL_RESID, interpretado como
fecha, sea igual a la variable @FechaCierre, interpretada como fecha. Las
condiciones para que un crédito pertenezca al tercer subgrupo son que el atributo
EST_CONTRATO sea ‘RL’, que el atributo EST_CARTERA sea ‘VE’ y que el atributo
FEC_CAMBIO_CAR, interpretado como fecha, sea igual a la variable @FechaCierre,
interpretada como fecha. En los tres casos, el atributo COD_SERVICIO de la tabla
TXT_FADTFAC debe ser igual a 28.
Los valores insertados para los registros de la tabla AT04 son:
a. Fecha_Cierre toma el valor de la variable @FechaCierre.
b. IDAplicativo toma siempre el valor 28, correspondiente al presente
aplicativo.
c. Credito toma el valor correspondiente a la concatenación de los atributos
COD_EMPRESA, CENTRO_APORTAN, DIGITOS_CTRL, COD_SERVICIO y
NUM_CONTRATO.
d. Credito_18 toma el valor correspondiente a la concatenación de los atributos
COD_EMPRESA, CENTRO_APORTAN, COD_SERVICIO y NUM_CONTRATO.
e. Estado_credito toma el valor 1 si se trata de un crédito activo, 2 si se trata
de un crédito cancelado y 3 si se trata de un crédito castigado.
92
f. Tipo_cartera toma el valor de la sub-cadena de caracteres del atributo
TIPO_ULT_MODIF que va desde el segundo carácter hasta el tercero, incluidos
ambos.
E.1.5. Grupo correspondiente al aplicativo “Sobregiros”
Para este aplicativo, la tabla AT04 toma valores de la combinación de las tablas
TXT_BTMAX0 y TXT_PEDT008. Las reglas de combinación son que la concatenación
de los atributos ENTIDAD, CENTRO_ALTA y CUENTA de la tabla TXT_BTMAX0 sea
igual al atributo CLAVCTA de la tabla TXT_PEDT008 y que el atributo CLASTIT de la
tabla TXT_PEDT008 sea igual a ‘T01’.
Las condiciones para que un registro de la combinación de tablas recién
mencionada sea seleccionado son que el atributo SALDO_DISPUE de la tabla
TXT_BTMAX0 , interpretado como un entero, sea menor que 0, que el atributo
PRODUCTO de la tabla TXT_BTMAX0 sea ‘01’ y que los primeros dos caracteres del
atributo CUENTA de la tabla TXT_BTMAX0 sean ‘0’ y ‘1’, respectivamente.
Los valores insertados para los registros de la tabla AT04 son:
a. Fecha_Cierre toma el valor de la variable @FechaCierre.
b. IDAplicativo toma siempre el valor 1, correspondiente al presente
aplicativo.
c. Credito toma el valor correspondiente a la concatenación de los atributos
ENTIOFI, CENTRO_ALTA, DIGICCC1, DIGICCC2 y CUENTA de la tabla
TXT_BTMAX0.
d. Credito_18 toma el valor correspondiente a la concatenación de los atributos
ENTIOFI, CENTRO_ALTA y CUENTA de la tabla TXT_BTMAX0.
e. Estado_credito toma el valor 1.
f. Tipo_cartera toma el valor del atributo SUBPRODU de la tabla TXT_BTMAX0.
93
E.1.6. Grupo correspondiente al aplicativo “Medios de pago”
Este grupo se divide en dos subgrupos, el primero correspondiente al de los
créditos activos y castigados y el segundo al de los créditos cancelados.
Para el primer subgrupo, la tabla AT04 toma valores de la combinación de las
tablas TXT_MCDTCON y TXT_MCDTRGO. Las regla de combinación son que los
atributos MCNENTCO, MCNOFICO, MCTCONTR y MCNCONTR sean iguales en ambas
tablas y que el atributo MCTOTDEU de la tabla TXT_MCDTRGO, interpretado como un
entero, sea mayor a 0. Además, para que un registro sea seleccionado para este
grupo, el atributo MCLMOTBJ de la tabla TXT_MCDTCON debe ser ‘’ o ‘CS’.
Para el segundo subgrupo, la tabla AT04 toma valores de la tabla TXT_MCDTCON.
Para que un registro sea seleccionado para este grupo, el atributo MCLMOTBJ de la
tabla no debe ser ‘’ ni ‘CS’ y el atributo MCFBAJCO, interpretado como fecha, debe
igual a la variable @FechaCierre, interpretada como fecha.
Para ambos subgrupos, el atributo MCTCONTR de la tabla TXT_MCDTCON,
interpretado como un entero, debe ser igual a 50.
Los valores insertados para los registros de la tabla AT04 son:
a. Fecha_Cierre toma el valor de la variable @FechaCierre.
b. IDAplicativo toma siempre el valor 50, correspondiente al presente
aplicativo.
c. Credito toma el valor correspondiente a la concatenación de los atributos
MCNENTCO, MCNOFICO, MCTCONTR y MCNCONTR de la tabla TXT_MCDTCON.
d. Credito_18 toma el valor correspondiente a la concatenación de los atributos
MCNENTCO, MCNOFICO, MCTCONTR y MCNCONTR de la tabla TXT_MCDTCON.
e. Estado_credito toma el valor 1 si se trata de un crédito activo o castigado y
2 si se trata de un crédito cancelado.
94
f. Tipo_cartera toma el valor del atributo MCTTARJE de la tabla
TXT_MCDTCON.
E.1.7. Resto del script
Hacia el final del script, como ya se mencionó, se realizan una actualización y una
eliminación de registros en la tabla AT04.
La actualización se realiza desde una tabla llamada
CONTROL_SB09_TIPO_CREDITO, que se encuentra en una base de datos llamada
STAGING. Esta tabla y esta base de datos fueron creadas, pero solo a fin de que el
script corriera correctamente; no se hizo inserción de registros en la tabla.
La eliminación de registros se hizo mediante la creación de una tabla temporal. El
criterio de eliminación consta de una conjunción de condiciones, entre las cuales se
encuentra que Credito_18 de la tabla sea igual que CONTRATO de la tabla
TXT_UGDTMAE y que SALREAL, interpretado como un entero, de esta última tabla sea
mayor a 0. Por lo tanto, y por las características de los datos aleatorios insertados en
dicha tabla, no se realiza la eliminación de ningún registro de la tabla.
E.2. ’02.Factoring.sql’
En primer lugar, en este script se realiza la declaración de dos variables llamadas
@FECHAC, de tipo INT, y @FECHA, de tipo DATE. A la primera se le asigna el valor
retornado por la función fx_FechaCierre, almacenada en la base de datos SIF y
que actualmente retorna el valor 20120131, el cual se interpreta como la fecha 31
de enero de 2012. A la segunda se le asigna una fecha un mes anterior a la
representada por la variable @FECHAC (en este caso 2011-12-31).
En este script se realiza la actualización de la tabla AT04 desde la combinación de
sí misma con varias tablas de acuerdo a varias reglas de combinación. Si bien todas
95
las tablas fueron creadas para que el script corriese correctamente, solamente se
realizó efectivamente la actualización de datos, en primer lugar, desde las tablas en
las que datos aleatorios fueron agregados y, en segundo lugar, con valores
constantes colocados en el script. Las tablas desde las cuales se realizó actualización
fueron dos de aquellas en las que se insertaron registros en el procedimiento de
inserción aleatoria para el aplicativo Factoring, explicado en la sección 5.2.2., a
saber: TXT_FADTCTR y TXT_FADTFAC. Además, solamente se aceptan para la
inserción registros combinados para los cuales el valor de IDAplicativo sea igual a
26, número que representa al aplicativo Factoring. A continuación se presentan las
reglas de combinación para dichas tablas y AT04:
a. El atributo CREDITO_18 de la tabla AT04 debe ser igual a la concatenación de
los atributos CTR_NCONTRAT_ENT, CTR_NCONTRAT_CENT, CTR_NCONTRAT_CP
y CTR_NCONTRAT_CTA de la tabla TXT_FADTCTR.
b. El atributo CREDITO_18 de la tabla AT04 debe ser igual a la concatenación de
los atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT, FAC_NCONTRAT_CP
y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC.
Los atributos de la tabla AT04 que se actualizan desde las tablas TXT_FADTCTR y
TXT_FADTFAC son los siguientes:
k. Fecha_liquidacion toma el valor del atributo CTR_DACTIVA de la tabla
TXT_FADTCTR, convertido en entero.
l. CUOTAS toma un valor igual al número de filas para las cuales el atributo
CREDITO_18 de la tabla AT04 es igual a la concatenación de los atributos
FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT, FAC_NCONTRAT_CP y
FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC.
m. CUOTAS_VENCIDAS toma un valor igual al número de filas para las cuales el
atributo CREDITO_18 de la tabla AT04 es igual a la concatenación de los
atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT, FAC_NCONTRAT_CP y
96
FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC y el atributo FAC_IESTFCT de
la tabla TXT_FADTFAC es igual a ‘VE’.
n. Monto_V30d toma el valor correspondiente a la sumatoria de los valores del
atributo FAC_MANTICIP de la tabla TXT_FADTFAC para los registros en los
cuales el atributo CREDITO_18 de la tabla AT04 sea igual a la concatenación
de los atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT,
FAC_NCONTRAT_CP y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC y la
fecha representada por el atributo FAC_VENCIM de la tabla TXT_FADTFAC sea
de uno a treinta días menor a la fecha contenida en la variable @FECHA.
o. Monto_V60d toma el valor correspondiente a la sumatoria de los valores del
atributo FAC_MANTICIP de la tabla TXT_FADTFAC para los registros en los
cuales el atributo CREDITO_18 de la tabla AT04 sea igual a la concatenación
de los atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT,
FAC_NCONTRAT_CP y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC y la
fecha representada por el atributo FAC_VENCIM de la tabla TXT_FADTFAC sea
de treinta y un a sesenta días menor a la fecha contenida en la variable
@FECHA.
p. Monto_V90d toma el valor correspondiente a la sumatoria de los valores del
atributo FAC_MANTICIP de la tabla TXT_FADTFAC para los registros en los
cuales el atributo CREDITO_18 de la tabla AT04 sea igual a la concatenación
de los atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT,
FAC_NCONTRAT_CP y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC y la
fecha representada por el atributo FAC_VENCIM de la tabla TXT_FADTFAC sea
de sesenta y un a noventa días menor a la fecha contenida en la variable
@FECHA.
q. Monto_V120d toma el valor correspondiente a la sumatoria de los valores del
atributo FAC_MANTICIP de la tabla TXT_FADTFAC para los registros en los
cuales el atributo CREDITO_18 de la tabla AT04 sea igual a la concatenación
de los atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT,
FAC_NCONTRAT_CP y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC y la
97
fecha representada por el atributo FAC_VENCIM de la tabla TXT_FADTFAC sea
de noventa y un a ciento veinte días menor a la fecha contenida en la variable
@FECHA.
r. Monto_V180d toma el valor correspondiente a la sumatoria de los valores del
atributo FAC_MANTICIP de la tabla TXT_FADTFAC para los registros en los
cuales el atributo CREDITO_18 de la tabla AT04 sea igual a la concatenación
de los atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT,
FAC_NCONTRAT_CP y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC y la
fecha representada por el atributo FAC_VENCIM de la tabla TXT_FADTFAC sea
de ciento veintiún a ciento ochenta días menor a la fecha contenida en la
variable @FECHA.
s. Monto_V1a toma el valor correspondiente a la sumatoria de los valores del
atributo FAC_MANTICIP de la tabla TXT_FADTFAC para los registros en los
cuales el atributo CREDITO_18 de la tabla AT04 sea igual a la concatenación
de los atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT,
FAC_NCONTRAT_CP y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC y la
fecha representada por el atributo FAC_VENCIM de la tabla TXT_FADTFAC sea
de ciento ochenta y un a trescientos sesenta y cinco días menor a la fecha
contenida en la variable @FECHA.
t. Monto_Vm1a toma el valor correspondiente a la sumatoria de los valores del
atributo FAC_MANTICIP de la tabla TXT_FADTFAC para los registros en los
cuales el atributo CREDITO_18 de la tabla AT04 sea igual a la concatenación
de los atributos FAC_NCONTRAT_ENT, FAC_NCONTRAT_CENT,
FAC_NCONTRAT_CP y FAC_NCONTRAT_CTA de la tabla TXT_FADTFAC y la
fecha representada por el atributo FAC_VENCIM de la tabla TXT_FADTFAC sea
más de trescientos sesenta y cinco días menor a la fecha contenida en la
variable @FECHA.
E.3. Procedimiento para crear registros directamente sobre la tabla AT04 de SIF
98
El procedimiento se llama prc_RandomInsert, se ha almacenado
tentativamente en la base de datos SIF y recibe como parámetro un valor entero,
llamado @Filas, el cual tiene como valor por defecto 10000 e indica el número de
filas a ser insertadas. El procedimiento consta de un ciclo con número de iteraciones
igual a @Filas.
En este procedimiento se insertan registros en la tabla AT04 de la base de datos
SIF. A continuación se presentan los campos para los cuales se hace la inserción en
dichas tablas y sus posibles valores:
a. Fecha_Cierre toma el valor 20120131.
b. IDAplicativo toma siempre el valor 44, el cual fue elegido arbitrariamente.
c. Credito toma, para los primeros cuatro caracteres, ‘0148’, escogido
arbitrariamente. Después, los siguientes cuatro caracteres dependen de los
valores que ya existan para registros del mismo aplicativo en la base de datos
histórica, que comienza en ‘0000’ y que aumenta de manera secuencial cada
vez que se ejecuta el proceso completo de manera sucesiva mientras no sea
borrada la base de datos histórica. Por ejemplo, la primera vez que se ejecuta
el proceso de la solución, toman el valor ‘0000’, el cual llega a la base de
datos histórica. Si se ejecuta de nuevo, verifica la base de datos histórica y
toman el valor siguiente, que es ‘0001’. Sin embargo, si se borra la base de
datos histórica, al ejecutar de nuevo el proceso de la solución, estos cuatro
caracteres toman de nuevo el valor ‘0000’. Los siguientes cuatro caracteres
toman ‘4444’, escogido arbitrariamente. Por último, los siguientes ocho
caracteres corresponden a una secuencia numérica que comienza en
‘00000000’ y aumenta de uno en uno a medida que se van generando los
registros aleatorios dentro del procedimiento.
d. Credito_18 toma el mismo valor que Credito, con la diferencia que la
secuencia ‘4444’, escogida arbitrariamente, cambia por la secuencia ‘44’,
también escogida arbitrariamente.
99
e. Naturaleza_cliente toma de manera aleatoria cualquier valor entre 0 y 3,
incluidos estos, con probabilidad uniformemente distribuida.
f. Estado_credito toma de manera aleatoria cualquier valor entre 1 y 3,
incluidos estos, con probabilidad uniformemente distribuida.
g. Situacion_credito toma de manera aleatoria cualquier valor entre 0 y 4,
incluidos estos, con probabilidad uniformemente distribuida.
h. Saldo toma de manera aleatoria cualquier valor entre 0 y 999999, incluidos
estos, con probabilidad uniformemente distribuida.
i. Monto_V30d toma de manera aleatoria cualquier valor entre 0 y 999999,
incluidos estos, con probabilidad uniformemente distribuida.
j. Monto_V60d toma de manera aleatoria cualquier valor entre 0 y 999999,
incluidos estos, con probabilidad uniformemente distribuida.
k. Monto_V90d toma de manera aleatoria cualquier valor entre 0 y 999999,
incluidos estos, con probabilidad uniformemente distribuida.
l. Monto_V120d toma de manera aleatoria cualquier valor entre 0 y 999999,
incluidos estos, con probabilidad uniformemente distribuida.
m. Monto_V180d toma de manera aleatoria cualquier valor entre 0 y 999999,
incluidos estos, con probabilidad uniformemente distribuida.
n. Monto_V1a toma de manera aleatoria cualquier valor entre 0 y 999999,
incluidos estos, con probabilidad uniformemente distribuida.
o. Monto_Vm1a toma de manera aleatoria cualquier valor entre 0 y 999999,
incluidos estos, con probabilidad uniformemente distribuida.
p. Tipo_Cartera toma de manera aleatoria cualquier valor entre ‘0’ y ‘99’,
incluidos estos, si se interpretan como enteros, con probabilidad
uniformemente distribuida.
E.4. ’15.Post-ComunesDefaults.sql’
En este script se realiza la actualización de la tabla AT04 de la base de datos SIF,
colocando valores por defecto para una gran cantidad de campos en los que se tiene
el valor null. Para este caso, hay ciertos valores por defecto que interesan, pues no
100
fueron considerados en todos los scripts de inserción aleatoria y forman parte del
cubo OLAP a construir:
a. Saldo tiene 0 como valor por defecto.
b. Cuotas tiene 0 como valor por defecto.
c. Cuotas_Vencidas tiene 0 como valor por defecto.
d. Monto_V30d tiene 0 como valor por defecto.
e. Monto_V60d tiene 0 como valor por defecto.
f. Monto_V90d tiene 0 como valor por defecto.
g. Monto_V120d tiene 0 como valor por defecto.
h. Monto_V180d tiene 0 como valor por defecto.
i. Monto_V1a tiene 0 como valor por defecto.
j. Monto_Vm1a tiene 0 como valor por defecto.
k. Situacion_credito tiene 0 como valor por defecto.
l. Naturaleza_cliente tiene 0 como valor por defecto.
m. Estado_credito tiene 0 como valor por defecto.
n. Fecha_liquidacion tiene 19000101 como valor por defecto, la cual puede
interpretarse como el 1 de enero de 1900.
101
APÉNDICE F
SCRIPTS PARA CREACIÓN Y ELIMINACIÓN DE RESTRICCIONES DE CLAVE
E ÍNDICES EN TABLAS DE LA BASE DE DATOS PROTOTIPO
F.1. “Creacion Indices y Fks en At04.sql”
USE [Prototipo]
GO
ALTER TABLE [dbo].[AT04] WITH CHECK ADD CONSTRAINT
[FK_AT04_DimTiempo] FOREIGN KEY([Fecha_cierre_date])
REFERENCES [dbo].[DimTiempo] ([Fecha])
GO
ALTER TABLE [dbo].[AT04] CHECK CONSTRAINT [FK_AT04_DimTiempo]
GO
ALTER TABLE [dbo].[AT04] WITH CHECK ADD CONSTRAINT
[FK_AT04_DimTiempo1] FOREIGN KEY([Fecha_liquidacion_date])
REFERENCES [dbo].[DimTiempo] ([Fecha])
GO
ALTER TABLE [dbo].[AT04] CHECK CONSTRAINT [FK_AT04_DimTiempo1]
GO
ALTER TABLE [dbo].[AT04] WITH CHECK ADD CONSTRAINT
[FK_AT04_DimTiempo2] FOREIGN KEY([Fecha_liquidacion_date])
REFERENCES [dbo].[DimTiempo] ([Fecha])
102
GO
ALTER TABLE [dbo].[AT04] CHECK CONSTRAINT [FK_AT04_DimTiempo2]
GO
ALTER TABLE [dbo].[AT04] WITH CHECK ADD CONSTRAINT
[FK_AT04_SB34_ESTADO_CREDITO] FOREIGN KEY([Estado_credito])
REFERENCES [dbo].[SB34_ESTADO_CREDITO] ([Cod])
GO
ALTER TABLE [dbo].[AT04] CHECK CONSTRAINT
[FK_AT04_SB34_ESTADO_CREDITO]
GO
ALTER TABLE [dbo].[AT04] WITH CHECK ADD CONSTRAINT
[FK_AT04_SB35_SITUACION_CREDITO] FOREIGN KEY([Situacion_credito])
REFERENCES [dbo].[SB35_SITUACION_CREDITO] ([Cod])
GO
ALTER TABLE [dbo].[AT04] CHECK CONSTRAINT
[FK_AT04_SB35_SITUACION_CREDITO]
GO
ALTER TABLE [dbo].[AT04] WITH CHECK ADD CONSTRAINT
[FK_AT04_SB76_NATURALEZA_CLIENTE] FOREIGN
KEY([Naturaleza_cliente])
REFERENCES [dbo].[SB76_NATURALEZA_CLIENTE] ([Cod])
GO
103
ALTER TABLE [dbo].[AT04] CHECK CONSTRAINT
[FK_AT04_SB76_NATURALEZA_CLIENTE]
GO
ALTER TABLE [dbo].[AT04] WITH CHECK ADD CONSTRAINT
[FK_AT04_APLICATIVO] FOREIGN KEY([IDAplicativo])
REFERENCES [dbo].[APLICATIVO] ([Cod])
GO
ALTER TABLE [dbo].[AT04] CHECK CONSTRAINT [FK_AT04_APLICATIVO]
GO
ALTER TABLE [dbo].[AT04] WITH CHECK ADD CONSTRAINT
[FK_AT04_TIPO_CARTERA] FOREIGN KEY([Tipo_Cartera])
REFERENCES [dbo].[TIPO_CARTERA] ([Cod])
GO
ALTER TABLE [dbo].[AT04] CHECK CONSTRAINT [FK_AT04_TIPO_CARTERA]
GO
CREATE NONCLUSTERED INDEX [IX_AT04_EDI_1] ON [dbo].[AT04]
(
[IDAplicativo] ASC
)
GO
104
CREATE NONCLUSTERED INDEX [IX_AT04_EDI_2] ON [dbo].[AT04]
(
[Credito_18] ASC
)
GO
CREATE NONCLUSTERED INDEX [IX_AT04_EDI_3] ON [dbo].[AT04]
(
[Estado_credito] ASC
)
GO
CREATE NONCLUSTERED INDEX [IX_AT04_EDI_4] ON [dbo].[AT04]
(
[Tipo_Cartera] ASC
)
GO
CREATE NONCLUSTERED INDEX [IX_AT04_EDI_5] ON [dbo].[AT04]
(
[Tipo_credito] ASC
)
GO
105
CREATE NONCLUSTERED INDEX [IX_AT04_EDI_6] ON [dbo].[AT04]
(
[Credito] ASC
)
GO
F.2. “Eliminacion Indices y Fks en At04.sql”
USE [Prototipo]
GO
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =
OBJECT_ID(N'[dbo].[FK_AT04_DimTiempo]') AND parent_object_id =
OBJECT_ID(N'[dbo].[AT04]'))
ALTER TABLE [dbo].[AT04] DROP CONSTRAINT [FK_AT04_DimTiempo]
GO
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =
OBJECT_ID(N'[dbo].[FK_AT04_DimTiempo1]') AND parent_object_id =
OBJECT_ID(N'[dbo].[AT04]'))
ALTER TABLE [dbo].[AT04] DROP CONSTRAINT [FK_AT04_DimTiempo1]
GO
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =
OBJECT_ID(N'[dbo].[FK_AT04_DimTiempo2]') AND parent_object_id =
OBJECT_ID(N'[dbo].[AT04]'))
ALTER TABLE [dbo].[AT04] DROP CONSTRAINT [FK_AT04_DimTiempo2]
106
GO
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =
OBJECT_ID(N'[dbo].[FK_AT04_SB34_ESTADO_CREDITO]') AND
parent_object_id = OBJECT_ID(N'[dbo].[AT04]'))
ALTER TABLE [dbo].[AT04] DROP CONSTRAINT
[FK_AT04_SB34_ESTADO_CREDITO]
GO
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =
OBJECT_ID(N'[dbo].[FK_AT04_SB35_SITUACION_CREDITO]') AND
parent_object_id = OBJECT_ID(N'[dbo].[AT04]'))
ALTER TABLE [dbo].[AT04] DROP CONSTRAINT
[FK_AT04_SB35_SITUACION_CREDITO]
GO
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =
OBJECT_ID(N'[dbo].[FK_AT04_SB76_NATURALEZA_CLIENTE]') AND
parent_object_id = OBJECT_ID(N'[dbo].[AT04]'))
ALTER TABLE [dbo].[AT04] DROP CONSTRAINT
[FK_AT04_SB76_NATURALEZA_CLIENTE]
GO
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =
OBJECT_ID(N'[dbo].[FK_AT04_APLICATIVO]') AND parent_object_id =
OBJECT_ID(N'[dbo].[AT04]'))
ALTER TABLE [dbo].[AT04] DROP CONSTRAINT [FK_AT04_APLICATIVO]
GO
107
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id =
OBJECT_ID(N'[dbo].[FK_AT04_TIPO_CARTERA]') AND parent_object_id =
OBJECT_ID(N'[dbo].[AT04]'))
ALTER TABLE [dbo].[AT04] DROP CONSTRAINT [FK_AT04_TIPO_CARTERA]
GO
IF EXISTS (SELECT * FROM sys.indexes WHERE object_id =
OBJECT_ID(N'[dbo].[AT04]') AND name = N'IX_AT04_EDI_1')
DROP INDEX [IX_AT04_EDI_1] ON [dbo].[AT04]
GO
IF EXISTS (SELECT * FROM sys.indexes WHERE object_id =
OBJECT_ID(N'[dbo].[AT04]') AND name = N'IX_AT04_EDI_2')
DROP INDEX [IX_AT04_EDI_2] ON [dbo].[AT04]
GO
IF EXISTS (SELECT * FROM sys.indexes WHERE object_id =
OBJECT_ID(N'[dbo].[AT04]') AND name = N'IX_AT04_EDI_3')
DROP INDEX [IX_AT04_EDI_3] ON [dbo].[AT04]
GO
IF EXISTS (SELECT * FROM sys.indexes WHERE object_id =
OBJECT_ID(N'[dbo].[AT04]') AND name = N'IX_AT04_EDI_4')
DROP INDEX [IX_AT04_EDI_4] ON [dbo].[AT04]
GO
108
IF EXISTS (SELECT * FROM sys.indexes WHERE object_id =
OBJECT_ID(N'[dbo].[AT04]') AND name = N'IX_AT04_EDI_5')
DROP INDEX [IX_AT04_EDI_5] ON [dbo].[AT04]
GO
IF EXISTS (SELECT * FROM sys.indexes WHERE object_id =
OBJECT_ID(N'[dbo].[AT04]') AND name = N'IX_AT04_EDI_6')
DROP INDEX [IX_AT04_EDI_6] ON [dbo].[AT04]
GO
109
APÉNDICE G
VENTAJAS Y DESVENTAJAS DE UN DW
Entre las ventajas de un DW, se pueden encontrar: [6] [7]
a. La historia de los datos es mantenida, incluso si los sistemas fuente no lo
hacen.
b. Los datos de varios sistemas fuente son integrados, posibilitando una visión
central a lo largo de la empresa.
c. Los datos son reestructurados para obtener un desempeño excelente de las
consultas, incluso para consultas analíticas complejas, sin causar impacto
sobre los sistemas operacionales.
d. Los usuarios pueden acceder a una gran cantidad de información de manera
rápida.
e. Un modelo de datos único es presentado para todos los datos de interés,
independientemente de su fuente.
f. La información contenida es consistente.
g. La información contenida puede ser utilizada para encontrar patrones
históricos o conexiones que permitan tomar decisiones de negocio.
h. El costo de cómputo es reducido y datos provenientes de varias fuentes
pueden ser combinados en un solo sitio.
i. Puede crear una estructura que permite que los cambios en los datos que
contiene sean transferidos de regreso a los sistemas operacionales.
j. Puede crear un ambiente en el cual sean necesarios pocos conocimientos
técnicos sobre bases de datos para hacer consultas sobre los datos contenidos
en el mismo.
k. Reestructurar los datos para obtener un desempeño excelente de las
consultas, incluso para consultas analíticas complejas, sin causar impacto
sobre los sistemas operacionales.
110
Sin embargo, entre las desventajas de un DW se pueden mencionar: [5] [6]
a. La construcción de un DW es una tarea que puede llevar años de
conceptualización e implementación.
b. Los procedimientos de limpieza, extracción y carga de los datos desde los
sistemas fuente pueden tardar mucho tiempo. Además, la mezcla de datos
provenientes de distintas fuentes puede llegar a ser un gran problema dadas
las diferencias en nombres, definiciones de dominios para los datos, etc. Cada
vez que una base de datos se modifica, el administrador debe tomar en cuenta
las interacciones con las demás.
c. En el caso de que haya problemas de compatibilidad entre los diferentes
sistemas transaccionales, las personas que trabajan con el DW deben estar
muy bien entrenados.
d. Si el DW es accedido desde el internet, muchas precauciones de seguridad
deben ser tomadas.
e. Los costos de mantenimiento y de administración de un DW pueden ser altos,
tanto por la mano de obra como por el hardware. La compañía que lo utilice
debe estar segura de que los beneficios son mayores que los costos.
