Sie sind auf Seite 1von 90

Sistemas informáticos 2010/2011

Sistema de ayuda a la
concesión de créditos
mediante la aplicación de
perfiles de morosidad

Autores: Francisco Javier Sánchez Pardo

Sara García Huete

Director: Miguel Ángel Blanco Rodríguez

1
2
Autorización

Autorizamos a la Universidad Complutense a difundir y utilizar con fines


académicos, no comerciales y mencionando expresamente a sus
autores, tanto la propia memoria, como el código, la documentación y/o
el prototipo desarrollado.

Fdo: Francisco Javier Sánchez Pardo


y Sara García Huete

3
Resumen

El objetivo del proyecto es crear un sistema de ayuda a la decisión


basado en reglas que permita a una entidad bancaria estimar la probabilidad de
que un préstamo solicitado por un cliente para comprar un bien, vaya a ser
devuelto íntegramente.

La aplicación consistirá básicamente de un sistema de gestión de


clientes y de préstamos, y de un sistema de gestión de reglas lógicas. Un
análisis (que no es parte de este proyecto) de la información de la morosidad
de los préstamos concedidos (casos) permitirá deducir reglas lógicas que
asocien una probabilidad de morosidad a un conjunto de características del
préstamo (perfiles de morosidad).

La aplicación permitirá integrar dichas reglas en la gestión de los


préstamos, y su explotación, de forma que cuando un usuario introduzca una
solicitud de préstamo de un cliente la aplicación contraste los datos del mismo
con las reglas definidas y proporcione un valor estimado de morosidad para
dicho préstamo, permitiendo tomar una decisión.

Palabras claves: Bases de datos, casos, reglas, toma de decisiones,

motor inferencia, gestión préstamos

4
Abstract

The goal of this Project is to create a case-based expert system which


allows a bank to predict the probability that a client applying for a loan will pay it
back or not.

Basically the application will consists of a database where all the clients
and logical rules will be stored. Cases will be obtained from this information.
When an application user wants to estimate the probability for granting a loan to
a client the cases will be studied in order to come to a conclusion.

The application will permit the integration of the rules in loan


management in the way that when a user inserts a client loan, the application
uses the stored rules to estimate the reliability for the loan, and return this value
to make a decision

Keywords: Database, cases, rules, decision making, inference engine,


loan management

5
6
Índice General

AUTORIZACIÓN ............................................................................................................................... 3
RESUMEN ...................................................................................................................................... 4
ABSTRACT...................................................................................................................................... 5
ÍNDICE GENERAL ............................................................................................................................. 7
INTRODUCCIÓN............................................................................................................................... 9

CAPÍTULO 1 ............................................................................................................................ 11

DESARROLLO DEL PROYECTO ................................................................................................... 11

CAPÍTULO 2 ............................................................................................................................ 12

ANÁLISIS FUNCIONAL ............................................................................................................... 12


1. Funcionamiento general del sistema ........................................................................... 12
2. principales funciones del sistema................................................................................. 13
3. Información guardada de los clientes .......................................................................... 15
4. Información de los bienes. ........................................................................................... 20
5. Información almacenada para las reglas lógicas......................................................... 23

CAPÍTULO 3 ............................................................................................................................ 25

DISEÑO DE LA BASE DE DATOS ................................................................................................. 25


1. Área de negocio. .......................................................................................................... 25
1.1. Entidades. ............................................................................................................................ 25
1.2. Esquemas Entidad-Relación. ............................................................................................... 28
1.3. Paso del esquema E/R al Modelo Relacional....................................................................... 30
2. Área de inferencia. ....................................................................................................... 32
1.1. Entidades. ............................................................................................................................ 32
1.2. Esquemas Entidad-Relación. ............................................................................................... 33
1.3. Paso del esquema E/R al Modelo Relacional....................................................................... 34
1.4. Ejemplos de inserción de reglas lógicas en la base de datos............................................... 35
1.5. Motor de inferencia ............................................................................................................ 36

CAPÍTULO 4 ............................................................................................................................ 39

DESCRIPCIÓN DE LA APLICACIÓN ............................................................................................. 39


1. ÁREA DE NEGOCIO. ...................................................................................................... 40
2. Gestión de Clientes....................................................................................................... 40
3. Gestión de Solicitudes de Préstamos. .......................................................................... 50
4. Gestión de Préstamos. ................................................................................................. 56
7
5. Historial crediticio de Clientes. ..................................................................................... 58
6. GESTIÓN DE TABLAS AUXILIARES: ................................................................................ 59
7. GESTIÓN REGLAS LÓGICAS ........................................................................................... 64
1.1. GESTIÓN DE REGLAS LÓGICAS ............................................................................................. 64
1.2. GESTIÓN DE PREMISAS........................................................................................................ 66
8. HERRAMIENTAS ........................................................................................................... 68
1.1. Configuración. ..................................................................................................................... 68
9. Ampliaciones futuras. .................................................................................................. 70
10. conclusiones............................................................................................................. 71
BIBLIOGRAFÍA ........................................................................................................................... 72
APÉNDICE A. SENTENCIAS SQL ................................................................................................. 73
APÉNDICE B. ACTAS .................................................................................................................. 81

8
Introducción

El objetivo de este proyecto es crear un sistema de ayuda a la decisión


que le permita a una entidad bancaria evaluar y valorar la posible morosidad de
los préstamos que le son solicitados (hipotecas, préstamos personales,
compras mediante tarjeta) para poder actuar en consecuencia, así como
detectar perfiles de fraude.

La aplicación consistirá básicamente de un sistema de gestión de


clientes y préstamos por un lado, y de un sistema de gestión de reglas lógicas
que permitan inferir probabilidades de morosidad de cada préstamo, por otro.

La información presente en el sistema de los préstamos concedidos por


la entidad, junto con la valoración sobre su morosidad (si ha resultado moroso
o no) constituye la información de partida: los casos. Un análisis estadístico
exhaustivo de los datos de los casos (que queda fuera del alcance de este
proyecto) permitirá deducir reglas que asocien una probabilidad de morosidad a
una combinación de condiciones sobre los valores de determinados atributos
clave dentro de la información que constituye el préstamo, es decir, identificar
una especie de patrón.

Cada una de estas reglas tendrá una serie de premisas y una


conclusión. Las premisas se definen como un conjunto de condiciones sobre
determinadas características del cliente y del bien que se va a comprar, y la
conclusión se define como la probabilidad de morosidad estimada para un
préstamo tipo en el que las características del cliente y del bien encajan en el
patrón definido por la regla.

Cuando un usuario de la aplicación introduzca los datos de una solicitud


de préstamo, el sistema, utilizando las reglas definidas intentará establecer una
concordancia con los datos del préstamo, informando al usuario de la
probabilidad de morosidad obtenida o de que no ha sido posible obtenerla.

9
La información que se almacenará sobre cada cliente será bastante
amplia, ya que a priori no se sabe cuáles pueden ser los atributos clave que
puedan tener relación con la morosidad. Entre esta información se incluyen
datos personales (edad, nivel de estudios...), datos sociales (estado civil,
número de hijos/personas a su cargo,…), datos socioeconómicos (sueldo,
puesto en la empresa,...) y datos sobre hobbies. Además también se guardarán
los datos referentes al bien para el que se desea obtener el préstamo (tipo de
bien, importe, …).

10
CAPÍTULO 1

DESARROLLO DEL PROYECTO

El proyecto se ha desarrollado siguiendo las instrucciones y


explicaciones que el director proporcionaba en las reuniones quincenales. En
cada una de estas reuniones se presentaba el trabajo realizado durante la
semana y se discutía sobre él, valorando que debía mantenerse y que debía
cambiarse. Tras la valoración del trabajo realizado, el director indicaba como
proseguir la investigación. Cada reunión quedaba registrada en un acta donde
constaba la fecha de la reunión, los asistentes, los temas tratados, los
acuerdos alcanzados y el trabajo a realizar hasta la siguiente reunión.

En la primera reunión mantenida se decidió dividir el proyecto en cuatro


fases para que su seguimiento y desarrollo fueran más sencillos. Dichas fases
han sido:

Fase 1 - Análisis funcional: en esta fase definimos los requerimientos del


proyecto y todos los elementos que intervienen en él.

Fase 2 - Diseño de la base de datos: en esta fase diseñamos la base de


datos basándonos en los elementos obtenidos en la fase anterior.

Fase 3 - Creación del aplicativo: en esta fase del proyecto desarrollamos


el código de la aplicación. La aplicación es completa en el sentido de que
incluye todas las opciones necesarias para introducir en el sistema cualquier
tipo de información utilizada, prescindiendo de utilidades accesorias.

Fase 4 - Creación de la memoria: en la última fase del proyecto se ha


redactado esta memoria.

El trabajo realizado en las diferentes fases se desarrolla en los sucesivos


puntos de la memoria.

11
CAPÍTULO 2

ANÁLISIS FUNCIONAL

Durante esta fase definimos el funcionamiento general del sistema, sus


funciones principales, la interacción con el usuario, la información guardada de
los clientes, reglas lógicas, etcétera.

1. FUNCIONAMIENTO GENERAL DEL SISTEMA

El sistema recibirá los datos de una solicitud de un préstamo de un


cliente que quiere financiar una compra. A partir de los datos del cliente, del
bien que se desea comprar y de los atributos propios de la compra el sistema
buscará una concordancia con los atributos de las reglas definidas y, en el caso
de que se encuentre una regla que se cumpla, asignará a la solicitud el valor
estimado de morosidad indicado en la regla (una probabilidad), e informará al
usuario de ese valor o de que no ha sido posible encontrar una concordancia.

Si el valor obtenido excede de un cierto umbral de morosidad


(configurable) la solicitud quedará denegada automáticamente. De forma
similar, si es inferior a otro determinado umbral (también configurable), quedará
autorizada automáticamente. Entre ambos umbrales el usuario tiene margen
para decidir la concesión o no del préstamo, requiriendo más información al
cliente o mediante el análisis de un experto externo.

Si la solicitud es autorizada el préstamo podrá concederse finalmente si


lo desea el cliente. Una vez concedido, cuando el préstamo haya finalizado
deberá ser valorado por la entidad como moroso o no moroso, pasando a
formar parte de la base de casos.

12
El sistema, por tanto, basa su funcionamiento en una serie de reglas
obtenidas previamente a partir del análisis de los datos de los préstamos
concedidos previamente. Estos datos conciernen a los clientes, a los bienes y a
la compra. Los préstamos deben ser calificados como morosos o no morosos
para pasar a formar parte de los casos.

Disponiendo de una extensa muestra de casos en la base de datos se


puede inferir mediante un motor de inferencia un conjunto de reglas que
asocien un perfil de préstamo con un perfil de morosidad (un porcentaje de
morosidad probable).

En este proyecto, como no disponemos de dicha base de casos para


poder obtener las reglas correspondientes usaremos otras introducidas
manualmente por el usuario.

Además de para obtener las reglas lógicas, para determinar los rangos
adecuados para los diferentes atributos numéricos (que se utilizarán en la
definición de las reglas) también se necesita disponer de una muestra extensa
de casos para poder agrupar los valores de la forma más significativa posible.
Como en el caso de las reglas lógicas estos intervalos los hemos hecho
manualmente siguiendo nuestro propio criterio.

Finalmente, como se ha comentado, a partir de las reglas se


establecerá una morosidad asociada al préstamo que un cliente solicita para
adquirir un determinado bien. A partir de ésta se tomará una decisión y la
entidad obrará en consecuencia.

2. PRINCIPALES FUNCIONES DEL SISTEMA.

A continuación se resumen las principales funciones que ofrece el


sistema.

13
Gestión de clientes: El sistema debe permitir el alta, la consulta, la
modificación y el borrado de los datos de clientes. También debe permitir
realizar búsquedas sobre ellos.

Consulta de datos históricos de clientes. Se guardará un histórico de


los datos sociales, económicos y de hobbies de los clientes, y se permitirá su
consulta.

Gestión de solicitudes de préstamos. Se permitirá dar de alta,


consultar, modificar, borrar y buscar solicitudes, y convertirlas en
préstamos. En el alta se permitirá importar los datos de clientes existentes.
Cuando la solicitud se genere el sistema informará de la probabilidad de
morosidad que le adjudica, pudiendo quedar autorizada o denegada
automáticamente. En la consulta también se podrá consultar información
adicional de los datos del cliente correspondientes a la fecha de la solicitud. En
la modificación se podrán cambiar todos los datos, pudiendo también importar
un nuevo cliente, y al grabar el sistema volverá a adjudicarle de nuevo la
probabilidad de morosidad, ya que puede ser que al cambiar los datos, ésta
también cambie. Mediante la modificación el usuario también podrá autorizar o
denegar la solicitud, siempre y cuando el valor de la morosidad esperada se lo
permita. Por último la solicitud puede convertirse en un préstamo (si ha sido
autorizada previamente). Una vez convertida en préstamo, su gestión se realiza
desde el apartado de préstamos.

Gestión de préstamos. Se permitirá dar de alta, consultar, modificar,


borrar y buscar préstamos según diferentes criterios. El alta no se utilizará en
la operativa normal y su finalidad es permitir introducir datos de préstamos
anteriores a la entrada en funcionamiento del programa, es decir, datos de
casos previos. En la consulta se podrá acceder a la información detallada de
los datos del cliente en la fecha de la solicitud del préstamo. En la modificación
solo se permitirá cambiar la morosidad del préstamo, calificándolo como
moroso o no moroso.

14
Consulta de historial crediticio de clientes. Esta función permitirá
buscar un cliente y consultar todos los datos de sus solicitudes de préstamo y
de todos sus préstamos concedidos.

Gestión de Entidades auxiliares. Este es un conjunto de funciones que


permitirán dar de alta, consultar, modificar y borrar en cada una de las
entidades auxiliares que se han definido en el sistema como Profesiones,
Países, etc (26 en total).

Gestión de reglas Lógicas. Se permitirá dar de alta, modificar,


consultar y borrar reglas lógicas que identifiquen un patrón de morosidad.

Configuración de la aplicación. Esta función permitirá configurar los


parámetros de funcionamiento de la aplicación, concretamente los umbrales de
morosidad para la autorización/denegación automática de solicitudes, y los
parámetros de conexión a la base de datos, permitiendo probar la conexión a
la misma.

3. INFORMACIÓN GUARDADA DE LOS CLIENTES

A continuación se establece la lista de los atributos identificados para el


cliente (atributos personales, sociales, socioeconómicos y de hobbies), junto
con sus dominios respectivos. Para los atributos numéricos se establecen
rangos de valores que serán utilizados después en la definición de las reglas
lógicas.

1) Personales
 Nombre
 Apellidos
 Fecha de nacimiento
 Sexo: H/M
 Tipo documento:
15
 NIF
 Tarjeta residencia
 Nº documento
 Nacionalidad:
 España
 Argentina
 ….
 Extranjero: Si/No
 Permiso residencia: Si/No
 Años de residencia en el país
 Nivel de estudios
 Estudios universitarios o equivalentes
 Enseñanzas profesionales superiores
 Enseñanza general secundaria, 2º ciclo.
 Enseñanza profesional de 2º grado, 2º ciclo.
 Enseñanza general secundaria, 1er ciclo.
 Estudios primarios o equivalentes
 Sin estudios

2) Sociales
 Estado civil
 Soltero/a
 Casado/a
 Separado/a
 Viudo/a
 Divorciado/a
 Nº hijos/personas a su cargo
 0
 1-3
 3-5
 >5

16
3) Hobbies
 Modalidad hobby
 Individual
o Cine
o Lectura
o Videojuegos
o ….
 Colectivo
o Danza
o Turismo
o Fútbol
o Baloncesto
o ….
 Carácter hobby
 Cultural
o Visita museos
o Conciertos musicales
 Deportivo
o Fútbol
o Baloncesto
o …

4) Socioeconómicos
 Profesión
 Informático
 Administrativo
 Comercial
 Policía
 Ama casa
 ….
 Situación laboral
 Desempleado
17
 Con contrato fijo
 Con contrato temporal
 Funcionario
 Autónomo
 Otra
 Años de antigüedad en la empresa
 0-2
 2-5
 5-10
 >10
 Actividad de la empresa CNAE1
 Agricultura, ganadería, pesca
 Industrias extractivas
 Industria manufacturera
 Suministro de energía eléctrica
 Suministro de agua
 Construcción
 Comercio al por mayor y al por menor
 Transporte y almacenamiento
 Hostelería
 Información y comunicaciones
 Actividades financieras y de seguros
 Actividades inmobiliarias
 Actividades profesionales, científicas y técnicas.
 Actividades administrativas y servicios auxiliares
 Administración pública y defensa
 Educación
 Actividades sanitarias y de servicios sociales
 Actividades artísticas y recreativas
 Otros servicios

1
CNAE: Clasificación Nacional de Actividades Económicas

18
 Actividades hogares
 Actividades organismos extraterritoriales
 Cargo en la empresa
 Presidente
 Director área
 Gerente
 …
 Nº veces que ha cambiado de trabajo
 0
 1-3
 3-5
 >5
 Sueldo bruto anual (parte fija)
 <15.000
 15.000 – 30.000
 30-000 – 50.000
 >50.000
 Sueldo bruto anual (parte variable)
 <3.000
 3.000 - 10.000
 10.000-20.00
 >20.000
 Otros ingresos anuales
 <5.000
 5.000 – 10.000
 10.000 – 30.000
 >30.000
 Importe hipoteca/alquiler mensual
 <500
 500-1.000
 >1.000
 Importe gastos mensuales
19
 <1000
 1000-2000
 2.000 – 5.000
 >5.000
 Coeficiente de caja mensual (Ingresos - gastos)
 <500
 500-1000
 1000-3000
 3000-5000
 >5000
 Vivienda en propiedad: si/no
 Valor vivienda en propiedad
 <100.000
 100.000 – 300.000
 300.000 – 500.000
 >500.000
 Otras propiedades: si/no
 Importe de otras propiedades
 <10.000
 10.000 – 50.000
 50.000-100.000
 >100.000

4. INFORMACIÓN DE LOS BIENES.

Clasificamos los bienes en distintos tipos y subtipos:

1. Inmueble
 Tipo
 Vivienda
 Local

20
 Plaza garaje
 Terreno sin edificar
 Otro
 Zona
 Lujo
 Alta
 Media
 Humilde
 Importe
 <50.000
 50.000 – 150.000
 150.000 – 400.000
 >400.000
2. Vehículo
 Tipo
 Turismo
 Motocicleta
 Furgoneta
 Camión
 Otro
 Cilindrada
 Alta
 Media
 Baja
 Importe
 <10.000
 10.000 – 30.000
 30.000 – 100.000
 >100.000
 Uso
 Personal/ocio
 Profesional
21
3. Electrodomésticos
 Tipo
 Televisión
 Ordenador personal
 Electrodoméstico cocina
 Climatización
 Otros electrónica
 Otros
 Importe
 >500
 500-2000
 2000-10.000
 >10.000

4. Ocio
 Tipo
 Viajes
 Cursos varios
 Otros
 Importe
 <1.000
 1.000 – 10.000
 10.000 – 50.000
 >50.000

5. Salud
 Tipo
 Intervenciones estética
 Intervenciones curativas
 Otros tratamientos de salud
 Importe
22
 <3.000
 3.000-10.000
 10.000-30.000
 >30.000

6. Otros
 Tipo
 Reformas hogar
 Formación profesional
 Inversiones
 Otros
 Importe
 <3.000
 3.000-20.000
 20.000-100.000
 >100.000

5. INFORMACIÓN ALMACENADA PARA LAS REGLAS


LÓGICAS

Una regla lógica es una conjunción de premisas, cada sobre su


correspondiente atributo y siempre tendrá como conclusión el valor de la
morosidad esperado para los casos en los que se cumplan todas las premisas.

Los atributos se corresponden con los atributos que se almacenan para


cada solicitud de préstamo, y en el caso de valores numéricos se harán
corresponder con el rango adecuado de la premisa en concreto.

De las reglas lógicas almacenaremos la siguiente información:

1. Premisa

23
 Tabla (nombre de la tabla a la que referencia)

 Campo (nombre del campo de la tabla referenciada)

 Tipo de Premisa (positiva – la condición debe cumplirse o


negativa – la condición no debe cumplirse).

 Máximo (en el caso de que el campo corresponda con un


rango de valores)

 Mínimo(en el caso de que el campo corresponda con un


rango de valores)

 Valor (en el caso de que el campo no sea un rango de


valores

 IdRegla (Regla a la que pertenece la premisa)

 TipoPremisa (si la premisa es positiva o negativa)

2. Reglas

 IdRegla( número de la regla)

 Valor de morosidad (valor de morosidad asociado a la regla)

 Descripción (Descripción sobre la regla)

24
CAPÍTULO 3

DISEÑO DE LA BASE DE DATOS

Una vez perfilado el funcionamiento general de la aplicación, vamos a


proceder al diseño de la base de datos en este apartado. El estudio se divide
en dos partes, por un lado el área de negocio y por otro el área de los datos
necesarios para la inferencia.

1. ÁREA DE NEGOCIO.

1.1. Entidades.

En esta parte se guarda toda la información relativa a los clientes y a los


bienes que se pretenden adquirir. Se han identificado las siguientes entidades
principales:

ClienteDatPers: esta entidad guarda los datos esenciales de un usuario.


Sus atributos son IdCliente, Nombre, Apellidos, Tipo de documento, nº de
documento, Fecha de nacimiento, Sexo, Nacionalidad, Nivel de Estudios,
Extranjero, Permiso de Residencia y Años de residencia.

ClienteDatSociales: esta entidad guarda los datos de la situación


social/familiar de un cliente. Sus atributos son: EstadoCivil, NumHijosPersonas
(nº de hijos o personas a su cargo).

ClienteDatSocioEco: esta entidad guarda los datos socioeconómicos y


laborales del cliente. Sus atributos son: CodProfesion, CodSitLaboral,
CodActividadEmp, Antigüedad, CargoEmp, CambiosTrabajo, SueldoAnuFijo,
SueldoAnuVar, OtrosIngresosAnu, ImpGastosMen, ImpHipAlqMen (importe
mensual de la hipoteca/alquiler), CoefCajaMen, ViviendaPropia, ValorVivienda,
OtrasProp, ValorOtrasProp. El atributo Coeficiente de Caja Mensual es un

25
campo calculado que se determina como ingresos – gastos (teniendo en
cuenta si son anuales o mensuales) y que da una indicación del dinero
mensual "disponible" para el cliente.

Hobbies: contiene la información acerca de los hobbies. Sus atributos


son: código, descripción, modalidad del hobby y carácter del hobby.

Bienes: contiene la información de los bienes que los clientes desean


comprar. Se trata de una "superentidad" de la que se derivan las entidades con
los diferentes tipos de bienes que hemos considerado. Sus atributos son IdBien
e importe (atributos comunes para todas).

Inmueble: sus atributos específicos son Tipo y CodZona.

Vehículo: sus atributos específicos son Tipo, CodUso y CodCilindrada.

Electrodoméstico: su atributo específico es Tipo.

Ocio: su atributo específico es Tipo.

Salud: su atributo específico es Tipo.

Otros: su atributo específico es Tipo.

Por otro lado tendremos las siguientes relaciones:

TieneS: relaciona la entidad ClienteDatPers con la entidad


ClienteDatSociales (cardinalidad 1:N). Tiene un atributo Fecha porque se
quiere guardar un histórico de los diferentes cambios que se produzcan en los
datos sociales, para poder identificar perfectamente la situación del cliente en
una fecha dada.

TieneSE: relaciona la entidad ClienteDatPers con la entidad


ClienteDatSocioEco (cardinalidad 1:N). Tiene un atributo Fecha para poder

26
guardar un histórico de las diferentes situaciones que se produzcan en los
datos sociales e identificar la situación del cliente en una fecha dada.

ClienteHobbies: relaciona la entidad ClienteDatPers con la entidad


ClienteHobbies (cardinalidad 1:N). También tiene un atributo Fecha para llevar
un histórico de los cambios que se produzcan en este aspecto.

Compra: relaciona la entidad ClienteDatPers con la entidad Bienes


(cardinalidad M:N). Un cliente puede comprar de 0 a N bienes, mientras que un
bien podría ser comprado por más de un cliente. Esta relación modeliza la
compra de un bien mediante un préstamo y guarda información que permite
modelizar el proceso de concesión del crédito. Sus atributos son: Fecha,
TipoFinan, AniosPago, ImporteMensual, TipoInterés, ProbMorosidad,
Autorizada, EstudioMorosidad, Concedido. Por su importancia explicaremos
algunos de los atributos. El atributo ProbMorosidad contiene la probabilidad
(calculada por el sistema) de que la compra actual mediante un préstamo
resulte morosa. El atributo booleano Autorizada está estrechamente
relacionado con el campo anterior y vale verdadero o falso en función de que
se autorice o no la solicitud de préstamo. El atributo booleano Concedido indica
si finalmente se firma el préstamo o no. Y el atributo EstudioMorosidad permite
catalogar el préstamo asociado a la compra como moroso o no moroso,
constituyendo un caso. Básicamente el ciclo es: estado inicial= solicitud de
préstamo (atributo concedido= false)  autorización de la solicitud (atributo
autorizada=true), (la autorización estará condicionada al valor de morosidad) 
estado final= crédito (atributo concedido = true).

Por último, también se han identificado un numeroso conjunto de


entidades auxiliares de menor importancia como EstadosCiviles, Profesiones,
etc, que están conectadas con las entidades explicadas anteriormente
mediante relaciones (1:N). Aquí solamente las comentaremos de pasada,
aunque después las detallaremos en el modelo relacional.

27
1.2. Esquemas Entidad-Relación.

A continuación se presentan los esquemas Entidad-Relación que


modelan esta parte de la base de datos.

Para mayor claridad en los esquemas E/R representaremos solamente


los atributos clave de cada entidad. Y para facilitar la visión lo hemos separado
en dos partes (parte de clientes y parte de bienes), aunque ambas partes
estarían unidas mediante la siguiente relación:

 Esquema Entidad-Relación que modela el cliente:

28
 Esquema Entidad-Relación que modela los bienes:

29
1.3. Paso del esquema E/R al Modelo Relacional.

A continuación pasamos a traducir los esquemas obtenidos en el modelo


entidad-relación al modelo relacional, para así poder realizar el diseño de las
tablas que darás lugar a la base de datos.

Por eficiencia solo crearemos una única tabla de bienes y no 1 para


cada subtipo, ya que el número de registros que vamos a insertar en las tablas
no es elevado, así que habrá que añadir en la tabla Bienes un campo Tipo para
diferenciar los tipos de bienes y un campo Subtipos para clasificar cada tipo de
bien. Además se incluirán todos los atributos de cada tipo de bien, los cuales a
veces quedarán vacíos en función del tipo de bien que vayamos a rellenar.

La lista de tablas obtenidas del área de negocio es la siguiente:

ClienteDatPers (IdCliente, Nombre, Apellidos, TipoDocumento,


NumeroDocumento, FechaNacimiento, Sexo, Nacionalidad, Extranjero,
NivelEstudios, PermisoResidencia, AniosResidencia)

ClienteDatSocioEco (IdCliente, Fecha, CodProfesion, CodSitLaboral,


CodActivEmp, Antiguedad, CargoEmp, CambiosTrabajo, SueldoAnuFijo,
SueldoAnuVar, OtrosIngresosAnu, ImpGastosMen, ImpHipAlqMen,
CoefCajaMen, ViviendaPropia, ValorVivienda, OtrasProp, ValorOtrasProp)

ClienteDatSociales (IdCliente, Fecha, EstadoCivil, NumHijosPersonas)

ClienteHobbies (IdCliente, Fecha, CodHobby)

Bienes (IdBien, Tipo, SubTipo, Importe, CodZona, CodCilindrada,


CodUso)

30
Compra (IdCliente, IdBien, FechaCompra, TipoFinan, AniosPago,
ImporteMensual, TipoInterés, ProbMorosidad, Autorizada, EstudioMorosidad,
Concedido)

ActividadesEmpresas (Código, Descripción)

CaracteresHobbies (Código, Descripción)

CargosEmpresa (Código, Descripción)

CilindradasVehículo (Código, Descripción)

EstadosAutorización (Código, Descripción)

EstadosCiviles (Código, Descripción)

EstudioMorosidad (Código, Descripción)

Hobbies (Código, Descripción, Modalidad, Caracter)

Modalidadeshobbies (Código, Descripción)

NivelesEstudios (Código, Descripción)

Países (Código, Descripción)

Profesiones (Código, Descripción)

Sexos (Código, Descripción)

SituacionesLaborales (Código, Descripción)

TiposBien (Código, Descripción)

TiposDocumento (Código, Descripción)

TiposElectrodoméstico (Código, Descripción)

TiposFinanciación (Código, Descripción)

31
TiposInmueble (Código, Descripción)

TiposInterés (Código, Descripción)

TiposOcio (Código, Descripción)

TiposOtros (Código, Descripción)

TiposSalud (Código, Descripción)

TiposVehículo (Código, Descripción)

UsosVehículo (Código, Descripción)

ZonasInmueble (Código, Descripción)

2. ÁREA DE INFERENCIA.

1.1. Entidades.

En esta parte se guarda toda la información relativa a las reglas lógicas,


la cual no permitirá más tarde decidir si se concede o no un préstamo
hipotecario. Se han identificado las siguientes entidades principales:

Premisa: la tabla premisa contiene las diferentes premisas que


conforman una regla lógica. Un premisa está compuesta por :

 IdPremisa que identifica la premisa de forma unívoca

 Tabla que especifica una tabla a la que se asocia la premisa

 Campo que especifica el campo de la tabla al que se refiere la


premisa. Campo puede ser un valor numérico, una fecha o una
32
cadena de caracteres. En el caso de ser un valor numérico se
podrá establecer un rango de valores para la premisa, de los
predefinidos anteriormente.

 TipoPremisa, que indica si la premisa es positiva o negativa.

 Un campo Valor, un valor ValorMax y un valor ValorMin. Se


rellenará el primer campo cuando no se especifique un rango de
valores, y se utilizarán los otros dos en el otro caso. La premisa
se cumplirá cuando el valor dado sea igual al valor especificado o
esté dentro del rango definido.

Reglas: tabla que contiene el valor de morosidad asociado a reglas


lógicas. Tiene dos campos:

 IdRegla, que se corresponde con el número del campo Regla de


la tabla Premisa.

 Descripción, que contiene una pequeña descripción de la regla


lógica.

 ValorMorosidad que indica el valor de morosidad asociado a la


regla. Todas las premisas que tengan el mismo número de regla
tendrán asociado este valor de morosidad. El valor de morosidad
deberá ser un valor entre 0 y 1, siendo 0 un valor de morosidad
esperado de 0% y 1 un valor de morosidad esperado de 100%.

1.2. Esquemas Entidad-Relación.

33
 Esquema Entidad-Relación que modela las reglas lógicas:

 Tabla Premisa:

 Tabla Reglas:

1.3. Paso del esquema E/R al Modelo Relacional.

De la misma manera que hemos hecho antes pasamos a traducir los


esquemas E/R de esta parte al modelo relacional y diseñar las tablas
correspondientes.

Premisas ( IdPremisa, Tabla, Campo, ValorMin, ValorMax, IdRegla,


Valor, TipoPremisa)

Reglas ( IdRegla, Descripcion, ValorMorosidad)

CamposPremisas( Tabla, Campo, Tipo, tablaAux)


34
TiposCamposPremisas( Codigo, Descripcion)

TiposPremisas( Codigo, Descripcion)

1.4. Ejemplos de inserción de reglas lógicas en la base de datos.

Regla1: Si ClienteDatPers.Nacionalidad=’00’ (España) ^ Clientedatsocioeco.


CoefCajaMen=1.000-30.000 ^ Bienes. CodUso=’01' (Profesional) ^ Bienes. Importe=10.000-
30.000 → 20% probabilidad de morosidad

Regla Premisa Tabla Campo Minimo Maximo Valor

1 1 ClienteDatPers Nacionalidad - - 00 (España)

1 2 Clientedatsocioeco CoefCajaMen 1.000 30.000

1 3 Bienes CodUso - - 01
(Profesional)

1 4 Bienes Importe 10.000 30.000

IdRegla Descripción ValorMorosidad

1 Regla compra automóvil 0,2


nacional

Regla2: Si Bienes.tipo=’1’ (Inmueble) ^ Clientedatsocioeco. CoefCajaMen=3.000-


5.000 ^ Clientedatsocioeco. CodSitLaboral=’2- ContratoFijo’ ^ Bienes.Importe= 150.000-
400.000 → 30% probabilidad de morosidad
35
Regla Premisa Tabla Campo Minimo Maximo Valor

2 5 Bienes tipo - - 1 - Inmueble

2 6 Clientedatsocioeco CoefCajaMen 3.000 5.000

2 7 Clientedatsocioeco CodSitLaboral - - 2-
ContratoFijo

2 8 Bienes Importe 150.000 400.000

IdRegla Descripción ValorMorosidad

2 Regla compra inmueble 0,3

1.5. Motor de inferencia

Para implementar el motor de inferencia se han usado las reglas lógicas


además de toda la información de los clientes y bienes que se almacena en la
base de datos.

Cada regla implementa una rama de un árbol de decisión, en el que en


cada nodo se evalúa una condición sobre un atributo (premisa). Una regla
equivale a una rama completa del árbol y un nodo a una premisa de la regla.

Las reglas deben ser disjuntas para concluir una única probabilidad. Si,
para un caso, al calcular la probabilidad, el sistema detecta que se puede
aplicar más de una regla es que hay un error en la definición, y avisará de ello
al usuario.

36
Además se ha hecho una lista de atributos discriminantes, que serán los
que se usen para crear las reglas, por lo que cuando creamos una premisa de
una regla solo se podrá crear con estos. La lista de atributos discriminantes
viene especificada en la siguiente tabla, y está almacenada en la tabla
CamposPremisas, por lo que en el caso de que la lista de atributos cambie
estos se pueden modicar.

Tabla Campo Tipo


ClienteDatPers FechaNacimiento Fecha
Sexo String
Nacionalidad String
Extranjero Boolean
NivelEstudios String
PErmisoResidencia Boolean
AniosResidencia Integer
Clientedatsociales EstadoCivil String
NumHIjosPersonas INteger
Clientedatsocioeco CodProfesion String
CodSitLaboral String
CodActivEmp String
CargoEmp String
Antigüedad Integer
CambiosTrabajo Integer
SueldoAnuFijo Integer
SueldoAnuVar Integer
OtrosIngresosAnu Integer
ImpGastosMen Integer
ImpHipAlqMen Integer
CoefCajaMen Integer
ViviendaPropia Boolean
ValorVivienda Integer
OtrasProp Boolean
ValorOtrasProp Integer
Clientehobbies CodHobby String
Compra TipoFinan String
AniosPago Integer
ImporteMensual Integer
TipoInteres String
Bienes Tipo String
SubTipo String
Importe Integer
CodZona String
CodCilindrada String
CodUso String
37
38
CAPÍTULO 4

DESCRIPCIÓN DE LA APLICACIÓN

A continuación se explica la funcionalidad de la aplicación


implementada. Ésta ha sido desarrollada en lenguaje Java usando MySQL
como gestor de la base de datos.

La ventana principal de la aplicación se presenta de la siguiente forma:

La funcionalidad la podemos dividir en cuatro partes claramente


diferenciadas:

39
1. ÁREA DE NEGOCIO.

Aquí se incluyen las funciones principales relacionadas con el negocio,


principalmente la gestión de clientes, la de solicitudes de préstamo y la de
préstamos. A continuación pasamos a comentarlas en más detalle.

2. GESTIÓN DE CLIENTES.

Se accede a través de la pestaña negocio, en la opción Gestión de


clientes. Aquí se implementan todas las funciones referentes al manejo de
clientes especificadas anteriormente de forma sencilla e intuitiva.

La ventana principal para la gestión de clientes es la siguiente:

40
Se trata de una pantalla de "conjunto" en la que se muestran todos los
clientes que hay en la base de datos, a continuación se detallan todas las
operaciones que se pueden realizar:

 Filtrar los clientes por alguno de los siguientes campos: idCliente,


Tipo/Número de documento, nombre y apellidos. Al rellenar
cualquiera de estos datos y regresar a la pantalla anterior
veremos que se ha aplicado el filtro y se restringen los clientes
que se muestran y así podremos localizar el cliente deseado.
Veremos también que el botón de "filtrar" habrá cambiado de
color para informar de que se está aplicando un filtro. Este
funcionamiento es similar en todas las pantallas de búsqueda, por
lo que no se volverá a comentar.

 Quitar filtros, con lo que se vuelven a mostrar todos los clientes de


la base de datos sin filtrar. El botón de "filtrado" volverá a su color
original.

 Consultar todos los datos de un cliente seleccionado. En esta


opción solamente está permitido consultar los datos y no
modificar ninguno de ellos. Los datos de un cliente están divididos
tal y como especificamos anteriormente en datos personales,
datos socioeconómicos, datos sociales y hobbies. Para que se

41
diferencie claramente esta división cada uno de estos tipos se
encuentran en una pestaña diferente de los datos del cliente, tal y
como se ve a continuación:

o Datos personales

o Datos Socioeconómicos

42
o Datos sociales.

o Hobbies

43
Si nos fijamos veremos que en las pestañas de datos sociales,
socieconómicos y de hobbies, aparece un botón de "histórico". Cada uno
de estos botones permite consultar todos los cambios que se han
producido en cada tipo de datos. Cada botón conduce a una pantalla de
"conjunto" que muestra todos los registros del histórico, en la que
podremos elegir uno y consultarlo más en detalle. A continuación se
muestran las pantallas de cada uno.

 Consulta del histórico de datos socioeconómicos

44
 Consulta detallada del histórico de datos socioeconómicos

 Consulta del histórico de datos sociales

45
 Consulta detallada del histórico de datos sociales

46
 Consulta del histórico de hobbies del cliente

47
 Consulta detallada del histórico de hobbies del cliente

48
 Dar de alta a un nuevo cliente en la base de datos. El aspecto de
la interfaz y las opciones son las mismas que en la consulta de
datos de un cliente, con la única diferencia de que en este caso
los formularios están completamente vacíos para ser rellenos con
los datos del nuevo cliente.

 Modificar los datos de un cliente existente en la base de datos. La


interfaz y las opciones son las mismas que en el caso de consulta
e inserción de un nuevo cliente en la base de datos, con la única
diferencia de que en este caso los formularios están rellenos con
los datos almacenados en la base de datos del cliente y éstos se
pueden actualizar con los nuevos datos. Cada vez que se
modifique un cliente se generará una nueva situación (registros
nuevos) de sus datos sociales, socioeconómicos y de hobbies,
permitiendo llevar un historial de los cambios realizados.

 Borrar todos los datos de un cliente seleccionado, con lo que se


elimina el registro del cliente seleccionado de la base de datos.
49
 "Volver", que cierra la ventana actual y regresa a la ventana
principal de la aplicación.

3. GESTIÓN DE SOLICITUDES DE PRÉSTAMOS.

La gestión de solicitudes de préstamos permite crear, modificar,


consultar, borrar o pasar a préstamo solicitudes de préstamo. Además también
se pueden poner y quitar filtros de búsqueda.

La ventana que lo gestiona es la siguiente:

Esta pantalla también es del tipo "conjunto" en la que se muestran todas


las solicitudes que hay en la base de datos. A continuación se detallan todas
las operaciones que se pueden realizar:
50
 Filtrar las solicitudes por alguno de los siguientes campos:
idCliente, Tipo/Número de documento, nombre, apellidos, fecha
desde, fecha hasta, tipo de bien, importe desde, importe hasta,
estado de la solicitud del préstamo y análisis de morosidad. El
funcionamiento es similar al comentado anteriormente así que no
se vuelve a comentar.

 Quitar filtros, con lo que se vuelven a mostrar todas las solicitudes


sin filtrar.

 Alta de solicitudes. El formulario de alta está dividido en varias


pestañas que contienen las diferentes categorías de datos.

o Pestaña "cliente" en la cual se permite incorporar todos los


datos de un cliente. Para ello se muestra un botón
"Importar cliente" que conduce a la pantalla de gestión de
51
clientes anteriormente vista. Allí podremos seleccionar e
importar los datos del cliente si éste ya existe (mediante un
nuevo botón "Importar" a tal efecto) o bien crear el cliente y
después importarlo. Al hacerlo sus datos se verán rellenos
en la pestaña de la solicitud.

o Pestaña ‘Bien’, en la cual se rellenan los datos


correspondientes al bien para el que el cliente desea
solicitar el préstamo. Dependiendo del tipo de bien se
habilitarán o no los combos de selección de Zona,
Cilindrada y Uso.

52
o La pestaña ‘Datos financiación’ tiene los datos referentes al
tipo de financiación, tipo de interés, años de pago e importe
mensual.

53
Al grabar la solicitud de préstamo el sistema, a partir de los datos de la
compra y de las reglas lógicas definidas, determinará una probabilidad de
morosidad. En función de esa probabilidad y de los rangos de morosidad
definidos en el sistema la solicitud quedará automáticamente en estado
autorizada, denegada o pendiente de evaluación. Si el sistema no fuera capaz
de obtener una probabilidad, se asignará a ésta un valor igual al umbral mínimo
para denegación automática (sin excederlo) y la solicitud quedará como
pendiente de evaluación. En cualquier caso se informará al usuario de la
probabilidad obtenida y del estado en el que queda la solicitud.

 Consulta de solicitudes. Esta opción permite la consulta de los


datos de la solicitud sin poder modificarlos. La única novedad es
que aparece un nuevo botón "Más info cliente" que permite la
consulta de todos los datos que tenía el cliente en la fecha de la
solicitud.

54
 Modificación de solicitudes. Esta opción permite modificar
cualquier dato de la solicitud, pudiendo incluso importar datos de
un cliente distinto. La autorización o denegación de la solicitud
también se realiza a través de ésta función. Cuando se graban los
nuevos datos el sistema vuelve a obtener el porcentaje de
morosidad, ya que puede haber cambiado algún dato que afecte a
su cálculo. El sistema validará también que, si hay un cambio de
estado (autorizada, denegada o pendiente de evaluación), el
nuevo estado sea compatible con el porcentaje de morosidad
obtenido.

 Concesión de préstamo (conversión de la solicitud en un


préstamo). En esta función no se permite modificar ningún dato
de la solicitud. El objetivo es cambiar el "status" de la solicitud y
convertirla en un préstamo, cambiando el valor del atributo
booleano "concedido" (falso para las solicitudes, verdadero para
los préstamos). El cambio solo es posible si la solicitud está
previamente autorizada. Una vez convertida en préstamo, no
aparecerá más como solicitud, y su gestión se hace desde el
55
apartado de préstamos. El valor de morosidad inicial que figurará
en el préstamo será "Sin valorar", para indicar que debe ser
revisado.

 Borrado de solicitudes, que permite borrarlas de la base de datos.

4. GESTIÓN DE PRÉSTAMOS.

La gestión de préstamos permite crear, modificar, consultar o borrar


préstamos. Además también se pueden poner y quitar filtros de búsqueda. Los
préstamos constituyen los "casos" de nuestro sistema.

Por su similitud con las funciones de la gestión de solicitudes solo


explicaremos las principales diferencias entre ambas. La ventana que lo
gestiona es la siguiente:

56
 Alta de préstamos. La entrada normal de información en el
sistema se realizará a través de la gestión de solicitudes, mientras
que esta opción está reservada para grabar préstamos anteriores
a la entrada en funcionamiento del sistema (casos previos). Su
funcionamiento es muy similar al alta de solicitudes.

 Consulta de préstamos. Permite consultar la información de un


préstamo de forma similar a la consulta de solicitudes.

 Modificación de préstamos. Es similar a la modificación de


solicitudes pero el único dato que se permite modificar es la
morosidad final del préstamo concedido, es decir, catalogarlo
como moroso o no moroso, y constituyendo un caso. Esta

57
valoración se hará posteriormente, cuando la duración del
préstamo haya finalizado.

 Borrado de préstamos. Permite borrar toda la información de un


préstamo.

5. HISTORIAL CREDITICIO DE CLIENTES.

Mediante esta opción podemos consultar las solicitudes de préstamos y


los préstamos que existen en el sistema para un cliente dado.

La pantalla de entrada muestra este aspecto:

Las operaciones que se pueden realizar son las siguientes:

 Consultar cliente. Permite la consulta de todos los datos del


cliente.

58
 Filtrar. Permite establecer filtros de selección de igual forma que
la pantalla de filtrado en gestión de clientes.

 Quitar Filtrado. Permite quitar los filtros establecidos.

 Préstamos. Muestra una pantalla de "conjunto" con todos los


préstamos solicitados por el cliente. Una vez en esta pantalla se
puede elegir un préstamo y ver todos sus datos con detalle.

 Solicitudes. Muestra una pantalla de "conjunto" con todas las


solicitudes realizadas por el cliente. Una vez en esta pantalla se
puede elegir una solicitud y ver todos sus datos con detalle.

6. GESTIÓN DE TABLAS AUXILIARES:

Se han utilizado tablas auxiliares para el funcionamiento del sistema,


que permiten parametrizarlo fácilmente. Cada una de estas tablas contiene
todos los posibles valores que puede tomar un determinado campo, por
ejemplo, el estado civil (soltero, casado, divorciado, etc). Esta opción permite la
gestión de las mismas de forma fácil y cómoda desde la aplicación.

El aspecto general es el siguiente:

59
Se han necesitado tablas auxiliares para la gestión de clientes, para la
gestión de bienes y para la gestión de compras.

A continuación se presentan todas las tablas auxiliares creadas:

 Personas:

o Tipos de Documento (NIF, Tarjeta de residencia)

o Sexos ( Hombre, mujer)

o Nivel de estudios (sin estudios, estudios primarios, …)

o Paises (España, Italia, Francia,..)

o Modalidades de Hobby (colectivo, individual)

o Caracteres de hobby (deportivo, cultural)

o Hobbies (natación, cine, lectura,..)

60
o Estados civiles (casado, soltero, separado, divorciado,
viudo)

o Profesiones (informático, arquitecto, …)

o Situaciones laborales (desempleado, contrato fijo,…)

o Actividades empresas (agricultura, construcción, …)

o Cargos empresa (directivo, jefe de proyecto, …)

 Bienes:

o Tipos de bienes (inmueble, vehículo, …)

o Tipos de inmuebles (vivienda, local, plaza de garaje, …)

o Zonas de inmueble (lujo, alta, media, humilde)

o Tipos de vehículo ( turismo, motocicleta, furgoneta, …)

o Cilindradas de vehículo (baja, media, alta)

o Usos de vehículo (personal/ocio, profesional)

o Tipos de electrodoméstico (televisión, ordenador personal)

o Tipos de bienes de ocio (viajes, cursos varios, otros)

o Tipos de bienes de salud (intervenciones curativas,


intervenciones estética, …)

o Tipos de otros bienes (reformas del hogar, formación


profesional, …)

 Compras:

o Tipos de financiación (tarjeta de crédito, préstamo


personal, hipoteca)
61
o Tipo de interés (interés fijo, interés variable, interés mixto)

o Tipos de morosidad (sin valorar, no moroso, moroso)

o Estados de autorización (Denegada, autorizada, pendiente


de evaluación.

 Reglas:

o Tipos de premisas (positivas, negativas)

o Tipo de campos en premisas

o Campos utilizables en premisas

Por último se muestra a modo de ejemplo la gestión de la tabla de


Actividades Empresas.

La pantalla de entrada muestra una lista con todos los registros de dicha
tabla:

62
Las funciones disponibles son:

 Alta de un nuevo registro en la tabla

 Modificación de un registro seleccionado, tiene una interfaz


similar a la anterior y modifica el valor del registro seleccionado
actualizándolo.

 Consultar un registro seleccionado, que de nuevo con una interfaz


similar a la de alta muestra los datos del registro seleccionado.
63
 Borrar, que elimina el registro seleccionado de la base de datos

 Volver, que cierra la ventana actual.

7. GESTIÓN REGLAS LÓGICAS

La gestión de reglas lógicas permite crear, modificar o borrar reglas


lógicas, que son la base para comprobar la posterior morosidad de un cliente
para un determinado bien y sus respectivas premisas.

1.1. GESTIÓN DE REGLAS LÓGICAS

La ventana que gestiona esta opción es igual que la del resto de


gestiones y en ella podemos ver todas las reglas almacenadas junto con su
descripción y valor de morosidad asociado.

A continuación se especifican las funcionalidades:

 Añadir una nueva regla lógica, que inserta una nueva regla en la
base de datos. Para añadir una regla primero se crea la regla con
su descripción y valor de morosidad asociado:

64
Posteriormente la aplicación nos avisará de que el alta de la regla
se ha producido de forma correcta, además de preguntar si
queremos dar de alta las premisas asociadas a las regla. En caso
afirmativo nos redirigirá al formulario de alta de premisas.

 Consultar una regla lógica, con lo que se muestran los datos de la


regla, además de un botón de premisas, que abre una ventana
que muestra todas las premisas asociadas a la regla lógica.

65
Este es el menú principal de premisa, en el que se muestran
todas las premisas asociadas a una regla lógica.

 Modificar una regla lógica, donde se pueden modificar tanto la


descripción como el valor de morosidad asociado a la regla.

 Borrar, que permite eliminar la regla lógica seleccionada de la


base de datos y sus premisas asociadas.

 Cerrar, que cierra la ventana actual

1.2. GESTIÓN DE PREMISAS

En la ventana principal aparecen todas las premisas dadas de alta en el


sistema:

Hay las siguientes opciones:

66
 Añadir, el formulario de alta premisas es el siguiente:

En función del tipo de Campo de la tabla se habilitará la opción de


rellenar el Valor mínimo y máximo en el caso de valores
continuos, o elegir un Valor de la lista en otro caso.

 Consultar una premisa, que permite ver todos los valores


asociados a una premisa pero sin posibilidad de modificarlos, y la
ventana es igual a la de alta

 Modificar una premisa seleccionada, que permite modificar


cualquier valor de la premisa, y la ventana también es igual a la
de alta

 Borrar una premisa seleccionada.

 Volver, que nos redirige a la ventana de la regla asociada a la


premisa.

67
8. HERRAMIENTAS

1.1. Configuración.

Mediante esta opción podremos cambiar los parámetros de


funcionamiento del sistema, como son los umbrales de morosidad y los
parámetros de conexión a la base de datos (nombre de la base de datos,
usuario, password, etc). Cada una de estas categorías de datos se muestra en
una pestaña diferente. La configuración se almacena en un fichero denominado
perfiles.properties (que forma parte de los ficheros de la aplicación), y que se
actualizará con los cambios realizados.

 Pestaña "Umbrales de morosidad"

o Umbral mínimo de denegación automática de solicitudes


de préstamo. Cuando el valor obtenido de morosidad para
una solicitud supera este umbral, la solicitud se deniega
automáticamente y no podrá autorizarse.

68
o Umbral máximo de autorización automática de solicitudes
de préstamo. Cuando el valor obtenido de morosidad para
una solicitud sea inferior a este umbral, la solicitud se
autorizará automáticamente, y no podrá denegarse.

 Pestaña "Base de datos"

En esta pantalla se pueden modificar los parámetros habituales de


conexión a la base de datos. Además se incluye un botón para probar la
conexión y confirmar que están bien establecidos.

69
9. AMPLIACIONES FUTURAS.

Como ampliación se podría tener en cuenta dentro del motor de


inferencia el historial crediticio del cliente para obtener el valor de morosidad
esperado, o para calcular el coeficiente de caja actualizado teniendo en cuenta
todos los préstamos concedidos a dicho cliente.

Si el cliente ya ha solicitado más préstamos anteriormente, con su


historial se pueden obtener nuevas premisas aplicables solo al cliente, con lo
cual el valor de morosidad calculado para el mismo sería más exacto y
personalizable.

También se podría realizar otra ampliación consistente en a partir del


historial que se va generando con el paso del tiempo, regenerar la base de
reglas lógicas en función de la evolución de los datos obtenidos, con lo cual la
base de reglas lógicas quedaría actualizada.

70
10. CONCLUSIONES.

Tras el desarrollo del proyecto hemos conseguido cumplir los siguientes


objetivos:

Investigar acerca del uso de reglas lógicas y su aplicación para inferir en


decisiones (en nuestro caso el valor de morosidad esperado para un cliente
para la concesión de un préstamo hipotecario)

Implementar una aplicación que usa la investigación realizada. Para ello


se ha implementado la aplicación anteriormente explicada que permite realizar
todos los objetivos que se pretendían.

Tanto para la investigación como para la implementación de la aplicación


se han usado los conocimientos adquiridos a lo largo de toda la formación
académica.

71
BIBLIOGRAFÍA

 "La Biblia de Java 2 v5.0", Herbert Schildt, Anaya Multimedia

 Tutorial "Creating a GUI With JFC/Swing",


"http://download.oracle.com/javase/tutorial/uiswing/index.html"

72
APÉNDICE A. SENTENCIAS SQL

A continuación se relacionan las sentencias de creación de todas las


tablas necesarias con sus respectivas restricciones:

CREATE TABLE `actividadesempresas` (


`Codigo` varchar(4) NOT NULL,
`Descripcion` varchar(100) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `bienes` (


`IdBien` int(10) unsigned NOT NULL AUTO_INCREMENT,
`Tipo` varchar(1) NOT NULL,
`SubTipo` varchar(1) NOT NULL,
`Importe` int(10) unsigned NOT NULL,
`CodZona` varchar(1) NOT NULL,
`CodCilindrada` varchar(1) NOT NULL,
`CodUso` varchar(1) NOT NULL,
PRIMARY KEY (`IdBien`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=latin1;

CREATE TABLE `campospremisas` (


`Tabla` varchar(45) NOT NULL,
`Campo` varchar(35) NOT NULL,
`Tipo` varchar(45) NOT NULL,
`TablaAux` varchar(45) NOT NULL,
PRIMARY KEY (`Tabla`,`Campo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `caractereshobbies` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `cargosempresa` (


73
`Codigo` varchar(2) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `cilindradasvehiculo` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `clientedatpers` (


`IdCliente` int(10) unsigned NOT NULL AUTO_INCREMENT,
`Nombre` varchar(20) NOT NULL,
`Apellidos` varchar(30) NOT NULL,
`FechaNacimiento` date NOT NULL,
`Sexo` char(1) NOT NULL,
`Nacionalidad` varchar(2) NOT NULL,
`Extranjero` tinyint(1) NOT NULL,
`NivelEstudios` varchar(1) NOT NULL,
`PermisoResidencia` tinyint(1) NOT NULL,
`TipoDocumento` varchar(1) NOT NULL,
`AniosResidencia` int(10) unsigned NOT NULL,
`NumDocumento` varchar(20) NOT NULL,
PRIMARY KEY (`IdCliente`)
) ENGINE=InnoDB AUTO_INCREMENT=30 DEFAULT CHARSET=latin1;

CREATE TABLE `clientedatsociales` (


`IdCliente` int(10) unsigned NOT NULL AUTO_INCREMENT,
`Fecha` date NOT NULL,
`EstadoCivil` varchar(1) NOT NULL,
`NumHijosPersonas` int(10) unsigned NOT NULL,
PRIMARY KEY (`IdCliente`,`Fecha`)
) ENGINE=InnoDB AUTO_INCREMENT=30 DEFAULT CHARSET=latin1;

CREATE TABLE `clientedatsocioeco` (


`IdCliente` int(10) unsigned NOT NULL AUTO_INCREMENT,
`Fecha` date NOT NULL,

74
`CodProfesion` varchar(2) NOT NULL,
`CodSitLaboral` varchar(2) NOT NULL,
`CodActivEmp` varchar(2) NOT NULL,
`Antiguedad` int(10) unsigned NOT NULL,
`CambiosTrabajo` int(10) unsigned NOT NULL,
`SueldoAnuFijo` int(10) unsigned NOT NULL,
`SueldoAnuVar` int(10) unsigned NOT NULL,
`OtrosIngresosAnu` int(10) unsigned NOT NULL,
`ImpGastosMen` int(10) unsigned NOT NULL,
`ImpHipAlqMen` int(10) unsigned NOT NULL,
`CoefCajaMen` int(11) NOT NULL,
`ViviendaPropia` tinyint(1) NOT NULL,
`ValorVivienda` int(10) unsigned NOT NULL,
`OtrasProp` tinyint(1) NOT NULL,
`ValorOtrasProp` int(10) unsigned NOT NULL,
`CargoEmp` varchar(2) NOT NULL,
PRIMARY KEY (`IdCliente`,`Fecha`)
) ENGINE=InnoDB AUTO_INCREMENT=30 DEFAULT CHARSET=latin1;

CREATE TABLE `clientehobbies` (


`IdCliente` int(10) unsigned NOT NULL AUTO_INCREMENT,
`Fecha` date NOT NULL,
`CodHobby` varchar(2) NOT NULL,
PRIMARY KEY (`IdCliente`,`Fecha`,`CodHobby`)
) ENGINE=InnoDB AUTO_INCREMENT=30 DEFAULT CHARSET=latin1;

CREATE TABLE `compra` (


`IdCliente` int(10) unsigned NOT NULL,
`IdBien` int(10) unsigned NOT NULL,
`FechaCompra` date NOT NULL,
`TipoFinan` varchar(1) NOT NULL,
`AniosPago` int(10) unsigned NOT NULL,
`ImporteMensual` int(10) unsigned NOT NULL,
`TipoInteres` varchar(1) NOT NULL,
`ProbMorosidad` float NOT NULL,
`Autorizada` varchar(1) NOT NULL,
`EstudioMorosidad` varchar(1) NOT NULL,
`Concedido` tinyint(1) NOT NULL,

75
PRIMARY KEY (`IdCliente`,`IdBien`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `estadosautorizacion` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `estadosciviles` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `estudiomorosidad` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `hobbies` (


`Codigo` varchar(2) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
`Modalidad` varchar(1) NOT NULL,
`Caracter` varchar(1) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `modalidadeshobbies` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `nivelesestudios` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,

76
PRIMARY KEY (`Codigo`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `paises` (


`Codigo` varchar(2) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `premisas` (


`IdPremisa` int(10) unsigned NOT NULL AUTO_INCREMENT,
`Tabla` varchar(45) NOT NULL,
`Campo` varchar(45) NOT NULL,
`ValorMin` varchar(45) NOT NULL,
`ValorMax` varchar(45) NOT NULL,
`IdRegla` int(10) unsigned NOT NULL,
`Valor` varchar(45) NOT NULL,
`TipoPremisa` varchar(1) NOT NULL,
PRIMARY KEY (`IdPremisa`)
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1;

CREATE TABLE `profesiones` (


`Codigo` varchar(2) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE `reglas` (
`IdRegla` int(10) unsigned NOT NULL AUTO_INCREMENT,
`Descripcion` varchar(45) NOT NULL,
`ValorMorosidad` float NOT NULL,
PRIMARY KEY (`IdRegla`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=latin1;

CREATE TABLE `sexos` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

77
CREATE TABLE `situacioneslaborales` (
`Codigo` int(10) unsigned NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposbien` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposcampospremisas` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposdocumento` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposelectrodomestico` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposfinanciacion` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposinmueble` (

78
`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposinteres` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposocio` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposotros` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tipospremisas` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tipossalud` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `tiposvehiculo` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,

79
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `usosvehiculo` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `zonasinmueble` (


`Codigo` varchar(1) NOT NULL,
`Descripcion` varchar(45) NOT NULL,
PRIMARY KEY (`Codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

80
APÉNDICE B. ACTAS

Fecha: 5 de octubre de 2010

Asistentes: Miguel Ángel Blanco Rodríguez, Sara García Huete y


Francisco Javier Sánchez Pardo

El proyecto consiste en la creación de una aplicación que permita


determinar el riesgo de morosidad de una compra realizada con tarjeta de
crédito por una persona. Para ello se considerarán un conjunto de
características personales (edad, sexo, etc.), sociales (hobbies, etc.) y
económicas (sueldo, empleo, etc.) del comprador y otro conjunto de
características del bien comprado (tipo del bien, importe, número de pagos,
etc.)

A lo largo del proyecto se realizarán reuniones semanales o quincenales


con el profesor para abordar el desarrollo del proyecto. De éstas se realizarán
actas, que pasarán a formar parte de la documentación del proyecto
posteriormente.

Se acuerda que el proyecto se va a estructurar de la siguiente manera:

 1er trimestre: toma de requisitos.


 2do trimestre: creación de tablas y desarrollo de la aplicación
 3er trimestre: realización de la documentación.

Para realizar el proyecto se puede utilizar cualquier base de datos


libremente, aunque Miguel Ángel sugiere MySQL u Oracle Database Personal
Edition.

81
Fecha: 19 de octubre de 2010

Asistentes: Miguel Ángel Blanco Rodríguez, Sara García Huete y


Francisco Javier Sánchez Pardo

Se establece que hay que categorizar el perfil del comprador definiendo


una serie de características propias. También habrá que categorizar el bien
destino de la compra mediante atributos propios. El perfil del comprador
permite establecer las premisas y las categorías del bien de consumo permiten
especificar las conclusiones (p. ej: un comprador soltero, mayor de 40 años,
directivo, etc., tiene una probabilidad baja de morosidad al comprar una moto
de gran cilindrada). Esta categorización, tanto del comprador como del bien, se
realizará jerárquicamente en forma de árbol. Los atributos que sean numéricos
(p. ej. la edad) se estructurarán en rangos de valores conformando intervalos.

Como punto de partida se discuten un conjunto de atributos que


permitan categorizar al comprador y al bien destino de la compra.

Atributos del bien destino de la compra:

 Qué se compra: electrodomésticos, ocio/viajes, coches, motos,


etc
 Importe
 Duración de los pagos

Atributos del comprador (personales, sociales y socioeconómicos):

 Edad
 Casado: si/no
 Nº hijos
 Inmigrante: si/no
 Hobbys

82
 Profesión: liberal, funcionario, empresario, etc.
 Cargo en la empresa
 Sueldo
 Años de antigüedad en la empresa
 Nº veces que se cambiado de trabajo
 Activos o bienes

Se acuerda para la siguiente reunión desarrollar más en detalle los


atributos del bien para discutir sobre ellos.

83
Fecha: 2 de noviembre de 2010

Asistentes: Miguel Ángel Blanco Rodríguez, Sara García Huete y


Francisco Javier Sánchez Pardo.

Se profundiza en los atributos tanto de los bienes a comprar como del


comprador, acordando que el nivel de profundidad de las clasificaciones no
será mayor de 4.

Se aclara que las hipotecas por la compra de un inmueble sí van a


formar parte de los bienes a comprar, y que la salida o respuesta de nuestro
sistema será la probabilidad asociada a un bien para un determinado cliente, y
que esta probabilidad cambiará para el mismo cliente dependiendo del bien a
comprar.

Para la siguiente reunión se refinarán las clasificaciones tanto del cliente


como del bien a comprar, además de comenzar con un esquema
Entidad/Relación inicial.

84
Fecha: 23 de noviembre de 2010

Asistentes: Miguel Ángel Blanco Rodríguez, Sara García Huete y


Francisco Javier Sánchez Pardo.

Se finaliza la clasificación de los atributos de los bienes y del comprador


quedando como figura en la clasificación anterior, añadiéndole los rangos
correspondientes a cada atributo.

Asimismo se crea una primera versión del esquema entidad/relación que


modela a los bienes y a los clientes.

Además se establece que para crear los rangos de los valores continuos
finalmente no se usará ninguna herramienta específica, ya que su aprendizaje
es muy laborioso y sobrepasa el ámbito del proyecto.

Para la siguiente reunión se refinará el esquema entidad-relación,


además de comenzar a crear una base de reglas lógicas a modo de ejemplo.

85
Fecha: 30 noviembre 2010

Asistentes: Miguel Ángel Blanco Rodríguez, Sara García Huete y


Francisco Javier Sánchez Pardo.

Se concretan las siguientes características:

 en una regla aparecerán máximo cuatro atributos

 Las reglas son excluyentes entre sí.

 Tendremos máximo seis reglas lógicas

Además se establece que con una muestra de 2000 casos se podría


inferir sobre cualquier caso haciendo uso de un paquete estadístico adecuado,
pero para nuestro proyecto en concreto se usará una probabilidad aproximada
ya que no tenemos acceso a ninguna base de datos para obtener la muestra
necesaria.

Se usarán así mismo algunas reglas subsumidas (reglas contenidas en


otras reglas)

86
Fecha: 8 febrero 2011

Asistentes: Miguel Ángel Blanco Rodríguez, Sara García Huete y


Francisco Javier Sánchez Pardo.

Se explica cómo pasar del modelo Entidad/Relación al modelo


relacional, junto con como ponderar las probabilidades que hay dentro de un
rango determinado para que la probabilidad no quede escalonada.

Fecha: 15 febrero 2011

Asistentes: Miguel Ángel Blanco Rodríguez, Sara García Huete y


Francisco Javier Sánchez Pardo.

Se realiza un ejemplo de regla lógica:

Si tipoBien=’automovil’ ^ edad= 35-45 ^coeficiente_caja=500-600


^uso=’profesional’ ^importe=18.000-20.000 → 70% probabilidad de morosidad

Se establece que los rangos de valores usados en las reglas lógicas


tienen que corresponder a un rango de las premisas.

Consensuamos que los valores continuos tienen que ir ponderados, por


lo que tendremos que hacer un ajuste ponderado en la premisa.

Se establece un valor mínimo pero no máximo en las reglas.

En cuanto a la implementación, se usarán bases de datos de


explotación, además de formularios de entrada de información (con los datos
iniciales necesarios para alimentar la base de datos y las reglas lógicas) que se
obtendrán a partir de un cuestionario que realizaremos cuando se desea pedir

87
un préstamo y los formularios de salida con la probabilidad de morosidad
además de otros posibles datos de interés.

Fecha: 14 julio 2011

Asistentes: Miguel Ángel Blanco Rodríguez y Sara García Huete.

Se acuerda usar dos bases de datos diferentes:

 Base de datos para clientes, en la que estarán todos los datos referentes
a los clientes que han solicitado o desean solicitar un préstamo
hipotecario.

 Base de datos con las reglas, en las que estarán todas las reglas junto
con sus premisas correspondientes premisas y los atributos asociados a
ellas.

Un ejemplo de entrada para la base de datos de las reglas lógicas es la


siguiente:

Regla Premisa Atributo

Regla1 TipoBien Automóvil

Regla1 Edad 35-40

Conclusion1 Valor morosidad 0,70

Además se acuerda el uso de alguna terminología como:

88
 Diagnóstico: probabilidad

 No discrimina: no infiere en la regla lógica

89
Fecha: 9 agosto 2011

Asistentes: Miguel Ángel Blanco Rodríguez, Sara García Huete y


Francisco Javier Sánchez Pardo.

Se presentan los ejemplos a usar de reglas lógicas descritos


anteriormente.

Se establece que en la respuesta del sistema para una probabilidad de


morosidad del [0.0 – 0.4] sí se concederá el préstamo hipotecario, con una
probabilidad de [0.6 - 1] no se concederá y para la probabilidad comprendida
en el intervalo [0.4 – 0.6] el caso pasará a análisis.

Se sugieren varias líneas de investigación en el campo de data mining


(BMPD, SPSS, análisis discriminante, knowledge seeker, …) como posibles
complementos a la investigación actual.

90

Das könnte Ihnen auch gefallen