Listado de las actas de las reuniones

Apéndice B
Listado de las actas de las reuniones

Durante el desarrollo del proyecto tal como se explico en el apartado de metodología de desarrollo hicimos reuniones periódicas. El seguimiento de dichas reuniones se encuentra en este listado de actas.
El proyecto trata de documentar diseñar e implementar un Sistema de Atención al Cliente o CRM que tiene como objetivo guardar y gestionar toda la información posible acerca de los productos, los clientes, ventas, etc así como las relaciones que puedan existir entre ellos. Existen elementos fundamentales tales como:
  • Productos
  • Clientes
  • …
Nuestro sistema tendrá información acerca de los productos concretos tal como: nombre, garantía, modelo, además será necesario identificar cada producto de forma unívoca a través del S/N (Serial Number).

Como es natural, pueden existir varios modelos para un mismo producto. Por ello será necesario poder recabar información de cada modelo, como puede ser la versión o el año de creación.

Para los clientes el sistema ha de manejar sus datos personales: nombre, apellidos, fecha de nacimiento,… así como atributo adicional para identificarlo y distinguirlo del resto de clientes.
El sistema recogerá información acerca de las acciones de los clientes.

En la operación compra se relaciona un producto con el cliente que lo adquirió. Almacenando algún dato identificativo del cliente así como un identificador para compra, siendo así posible recuperar posteriormente esta información para cualquier otro fin. Además cada compra tendrá el importe y la fecha en la que fue hecha.

El aprendizaje del sistema es importante para determinar de qué forma suele actuar cada cliente. Esto nos permite averiguar cuáles son sus preferencias y en general patrones de comportamiento. Los datos se extraerán bien de la forma de actuar de cada cliente o mediante cuestionarios. A partir de estos datos podemos crear perfiles de clientes que actúen de la misma forma.

El sistema registrará cada incidencia que el cliente plantee. Cada incidencia recogerá datos como modelo afectado, cliente, así como alguna información extra relacionada con la forma de proceder o solventar. Además se extraerán datos relevantes relacionados con el funcionamiento de cada producto y sobre el uso que cada usuario hace. Dependiendo del tipo de incidencia puede llevarse a cabo distintas alternativas para la solución de la misma como por ejemplo sustituir el producto por otro de características similares. Incluso dependiendo del tipo de cliente (por ejemplo un VIP) que tiene la incidencia se puede actuar de distinta forma como por ejemplo ofrecer un modelo superior a un VIP.

Otro aspecto importante a destacar es el funcionamiento de cada modelo. Muchas veces los clientes no entienden el funcionamiento de un producto y existen dudas bastantes comunes. Por ello se crean manuales de usuario que ayuden a comprender su funcionamiento y contienen una lista de preguntas más frecuentes (FAQ). Además si de manera usual una duda sobre el uso del producto lleva a otra duda el sistema indicará la respuesta a la 2ª duda relacionada con la 1ª.

El proyecto trata de documentar diseñar e implementar un Sistema de Atención al Cliente o CRM que tiene como objetivo guardar y gestionar toda la información posible acerca de productos, clientes, ventas, incidencias, quejas, soluciones, así como las relaciones que puedan existir entre ellos, y dar respuestas a las consultas de los clientes. Además, una funcionalidad muy importante que debería implementar el sistema que se está especificando es el aprendizaje, basado en casos, por lo cual podremos obtener soluciones satisfactorias.
El sistema registrará cada consulta que el cliente plantee. El aprendizaje del sistema es muy importante para determinar de qué forma suele actuar cada cliente. Esto nos permite averiguar cuáles son sus preferencias y en general patrones de comportamiento. Los datos se extraerán bien de la forma de actuar de cada cliente o mediante cuestionarios. A partir de estos datos podemos crear perfiles de clientes que actúen de la misma forma. Pasando a la descripción técnica de nuestro sistema, existen elementos fundamentales tales como:
  • Productos o Equipos
  • Clientes
  • Consultas
  • Incidencias o Averías
  • Quejas o reclamaciones
  • Recomendaciones
  • Soluciones
Los productos son aquellos elementos de consumo, que han sido vendidos o están en stock o incluso puede que aun estén en desarrollo experimental (prototipos). Los productos se pueden identificar unívocamente por su Serial Number (S/N), además de disponer una serie de atributos, que aun no interesa detallar. Como es natural, pueden existir varios modelos para un mismo producto.

Los clientes son todos aquellos usuarios, pasados, presentes y futuros, de los que tengamos constancia y datos en nuestro sistema, que podrán ser utilizados para la generación de estadísticas, y, por consiguiente, para el aprendizaje. Se les podrá clasificar según perfiles, para darle un servicio de asistencia diferente dependiendo del perfil (económico, social, etc). Por ejemplo: Pepito. Varón. 45 años. Dos hijos. Médico = Torpe. Explicarle las cosas de manera sencilla. Juan. Varón. 30 años. Sin hijos. Ingeniero de Telecomunicaciones = Listo. Hablarle con términos técnicos. El sistema recogerá información acerca de las acciones de los clientes. Las compras, las reclamaciones, las consultas, los gustos, los problemas que tienen con los productos, debido a su uso, a su manejo o a la facilidad que tienen de entenderlos.

Las consultas son las llamadas que hacen los clientes al servicio técnico. Pueden ser por varias causas: averías, reparaciones, quejas, recomendaciones o información adicional.

Las Incidencias o Averías ocurren cuando un producto deja de funcionar correctamente. Entonces, el cliente usará el servicio de soporte técnico para intentar solucionarlo. Puede haber muchas clases de averías, desde, por ejemplo, rotura por caída, o que se moje un producto, hasta que el cliente haya desconfigurado el producto y no sepa como restaurar el estado original. Evidentemente habrá más consultas por averías mientras el producto esté en garantía, ya que a partir de esa fecha, es muy probable que compense vender un producto nuevo que arreglar el viejo, pero puede que no. Cada incidencia recogerá datos como modelo afectado y tipo de cliente, y a partir de ella se generará información extra relacionada con la forma de proceder o solventar. Además se extraerán datos relevantes relacionados con el funcionamiento de cada producto y sobre el uso que cada usuario hace.

Las Reparaciones se refieren al arreglo de un producto. Como consultas, las reparaciones pueden proporcionar al cliente información sobre fechas, plazos y costes de la reparación antes de que se produzca. Todos estos datos pueden surgir a partir de la experiencia con otros productos similares o en ocasiones distintas. También se podría proporcionar información, una vez que el producto se ha mandado a reparar, del tiempo que quedará (por ejemplo, se detecta que es un fallo de un componente y que va a tardar un tiempo en llegar uno nuevo). Una idea extra sería hacer un sistema de alarmas, que cuando se modificara un dato de reparaciones se avise al cliente.

Las quejas son las reclamaciones de los clientes, que no quedan satisfechos con el producto o con el servicio, por ejemplo con un retraso en una entrega de un equipo en reparación o venta.

Las consultas de Información se refieren a las características que tiene un producto, funcionalidad (con vistas a adquirirlo o no), propuestas de equipos, dependiendo del perfil socio-económico del cliente, o sobre su manejo. Muchas veces los clientes no entienden el funcionamiento de un producto y existen dudas bastantes comunes. Cada modelo de producto debería disponer de un manual y de una lista de preguntas más frecuentes (FAQ) que pueden ser diferentes dependiendo del perfil. Además si de manera usual una duda sobre el uso del producto lleva a otra duda el sistema indicará la respuesta a la segunda duda relacionada con la primera.

Las recomendaciones son las propuestas que se le da a un cliente que pide un producto con unas características determinadas. Se le intentaría proponer algo que contentara lo máximo posible al cliente, dependiendo de su perfil socio-económico y de lo que requería.

Las soluciones son aquellas medidas que el equipo del Servicio Técnico toma para cada situación, dependen del tipo de cliente, del caso o problema que se presenta, y del grado de satisfacción conseguido en ocasiones anteriores. Según el tipo de cliente (por ejemplo un VIP) que tiene la incidencia se puede actuar de distinta forma como por ejemplo ofrecerle un modelo superior. Por ejemplo, si a un representante de una empresa se le ha dado un terminal telefónico cutre y ha quedado decepcionado porque la imagen que han tenido los clientes de su compañía ha sido mala, el sistema aprende y la próxima vez no toma esa decisión. Dependiendo de la consulta puede llevarse a cabo distintas alternativas para la solución de la misma como por ejemplo sustituir el producto por otro de características similares.

Se le presenta el documento de presentación del proyecto con las modificaciones de la versión anterior, completo y adecuado a las expectativas salvo un par de matices.

Presentación del proyecto modificada

El proyecto trata de documentar diseñar e implementar un Sistema de Atención al Cliente o CRM que tiene como objetivo guardar y gestionar toda la información posible acerca de productos, clientes, ventas, incidencias, quejas, soluciones, así como las relaciones que puedan existir entre ellos, y dar respuestas a las consultas de los clientes. Además, una funcionalidad muy importante que debería implementar el sistema que se está especificando es el aprendizaje, basado en casos, por lo cual podremos obtener soluciones satisfactorias.

El sistema registrará cada consulta que el cliente plantee. El aprendizaje del sistema es muy importante para determinar de qué forma suele actuar cada cliente. Esto nos permite averiguar cuáles son sus preferencias y en general patrones de comportamiento. Los datos se extraerán bien de la forma de actuar de cada cliente o mediante cuestionarios. A partir de estos datos podemos crear perfiles de clientes que actúen de la misma forma.

Pasando a la descripción técnica de nuestro sistema, existen elementos fundamentales tales como:
  • Productos o Equipos
  • Usuarios
  • Clientes
  • Contactos
  • Consultas
    • Incidencias o Averías
    • Quejas o reclamaciones
    • Consultas de Información
  • Soluciones
Los productos son aquellos elementos de consumo, que han sido vendidos o están en stock o incluso puede que aún estén en desarrollo experimental (prototipos). Los productos se pueden identificar unívocamente por su Serial Number (S/N), además de disponer una serie de atributos, que aún no interesa detallar. Como es natural, pueden existir varios modelos para un mismo producto.

Los usuarios son las personas que usen el sistema que estamos desarrollando.

Los contactos son aquellas personas de las que tengamos constancia y datos en nuestro sistema, que podrán ser utilizados para la generación de estadísticas, y, por consiguiente, para el aprendizaje. Se les podrá clasificar según perfiles, para darle un servicio de asistencia diferente dependiendo del perfil (económico, social, etc). Por ejemplo:
  • Juan. Varón. 45 años. Dos hijos. Médico => Sin conocimientos técnicos. Explicarle las cosas de manera sencilla.
  • María. Mujer. 30 años. Sin hijos. Ingeniera de Telecomunicaciones => Con conocimientos técnicos. Hablarle usando términos técnicos.
El sistema recogerá información acerca de las acciones de los clientes. Las compras, las reclamaciones, las consultas, los gustos, los problemas que tienen con los productos, debido a su uso, a su manejo o a la facilidad que tienen de entenderlos.

Los clientes son todos aquellos personas que han comprado. Tendrán las mismas características que cualquier contacto, pero además, se les podrá consultar desde el sistema, los productos que han adquirido.

Las consultas son las llamadas que hacen los clientes al servicio técnico. Pueden ser por varias causas: Incidencias, Reclamaciones o información adicional.

Las Incidencias o Averías ocurren cuando un producto deja de funcionar correctamente. Entonces, el cliente usará el servicio de soporte técnico para intentar solucionarlo. Puede haber muchas clases de averías, desde, por ejemplo, rotura por caída, o que se moje un producto, hasta que el cliente haya desconfigurado el producto y no sepa como restaurar el estado original. Cada incidencia recogerá datos como modelo afectado y tipo de cliente, y a partir de ella se generará información extra relacionada con la forma de proceder o solventar. Además se extraerán datos relevantes relacionados con el funcionamiento de cada producto y sobre el uso que cada usuario hace.

Las quejas son las reclamaciones de los clientes, que no quedan satisfechos con el producto o con el servicio, por ejemplo con un retraso en una entrega de un equipo en reparación o venta, o incluso con el servicio de atencion que se le ha prestado.

Las consultas de Información se refieren a las características que tiene un producto, funcionalidad (con vistas a adquirirlo o no), propuestas de equipos, dependiendo del perfil socio-económico del cliente, o sobre su manejo. Muchas veces los clientes no entienden el funcionamiento de un producto y existen dudas bastantes comunes. Cada modelo de producto debería disponer de un manual y de una lista de preguntas más frecuentes (FAQ) que pueden ser diferentes dependiendo del perfil. Además si de manera usual una duda sobre el uso del producto lleva a otra duda el sistema indicará la respuesta a la segunda duda relacionada con la primera.
Las Reparaciones se refieren al arreglo de un producto. Como consultas, las reparaciones pueden proporcionar al cliente información sobre fechas, plazos y costes de la reparación antes de que se produzca. Todos estos datos pueden surgir a partir de la experiencia con otros productos similares o en ocasiones distintas. También se podría proporcionar información, una vez que el producto se ha mandado a reparar, del tiempo que quedará (por ejemplo, se detecta que es un fallo de un componente y que va a tardar un tiempo en llegar uno nuevo). Una idea extra sería hacer un sistema de alarmas, que cuando se modificara un dato de reparaciones se avise al cliente.

Las soluciones son aquellas medidas que el equipo del Servicio Técnico toma para cada situación, dependen del tipo de cliente, del caso o problema que se presenta, y del grado de satisfacción conseguido en ocasiones anteriores. Según el tipo de cliente (por ejemplo un VIP) que tiene la incidencia se puede actuar de distinta forma como por ejemplo ofrecerle un modelo superior. Por ejemplo, si a un representante de una empresa se le ha dado un terminal telefónico cutre y ha quedado decepcionado porque la imagen que han tenido los clientes de su compañía ha sido mala, el sistema aprende y la próxima vez no toma esa decisión. Dependiendo de la consulta puede llevarse a cabo distintas alternativas para la solución de la misma como por ejemplo sustituir el producto por otro de características similares.

Las recomendaciones son las soluciones propuestas que se le da a un cliente que pide un producto con unas características determinadas. Se le intentaría proponer algo que contentara lo máximo posible al cliente, dependiendo de su perfil socioeconómico y de lo que requería.

Las modificaciones aportadas al documento se basan en los siguientes puntos:
  • Los CLIENTES que todavía no han comprado, no son CLIENTES sino CONTACTOS
  • Los USUARIOS son los que van a usar la utilidad que estamos desarrollando.
  • Las CONSULTAS van a ser todas las llamadas que realizan los CLIENTES y los CONTACTOS, y pueden ser de varios tipos dependiendo del motivo:
    • Averías o INCIDENCIAS
    • Quejas o RECLAMACIONES
    • CONSULTAS DE INFORMACIÓN, que a su vez, puede ser por conocer la funcionalidad de un determinado producto, alguna duda de su uso, o también para pedir recomendación para adquirir uno nuevo, con unas características determinadas y en base a su perfil socioeconómico.
    • Las SOLUCIONES comprenderán, para cada consulta, el desenlace de la misma, así como el grado de satisfacción de cada cliente. Por tanto, podría ser, o bien la reparación de una avería, la tramitación de una queja, o la recomendación de producto que se le ha dado a un cliente.
Además, no interesa que un producto vaya a tener más reparaciones mientras esté en garantía, ya que eso, como mucho, sería un dato estadístico más.

Una vez que ya tenemos una idea de lo que trata el producto, se nos pide definirlo mediante diagramas de secuencia:

1.1. Iniciar Sesión Basic

Diagrama de secuencia - Iniciar Sesión Basic
Diagrama de secuencia - Iniciar Sesión Basic

1.2. Iniciar sesión Detallado

Iniciar sesión Detallado - Diagrama de secuencia
Iniciar sesión Detallado - Diagrama de secuencia

2. Cerrar Sesión

Cerrar Sesión - Diagrama de secuencia
Cerrar Sesión - Diagrama de secuencia

3. Verificar Cliente

Verificar Cliente - Diagrama de secuencia
Verificar Cliente - Diagrama de secuencia

4.1. Crear Incidencia VIP - Necesario Taller

Crear Incidencia VIP - Necesario Taller - Diagrama de secuencia
Crear Incidencia VIP - Necesario Taller - Diagrama de secuencia

4.2. Crear Incidencia VIP - Desconfiguración

Crear Incidencia VIP - Desconfiguración - Diagrama de secuencia
Crear Incidencia VIP - Desconfiguración - Diagrama de secuencia

5. Consultar Información

Consultar Información - Diagrama de secuencia
Consultar Información - Diagrama de secuencia

Un diagrama de secuencia, (formalmente diagrama de traza de eventos) muestra las interacciones entre objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por el escenario.

Por ejemplo, qué sucede exactamente cuando un cliente llama por una avería, si se le toman los datos, si se consulta en la Base de Datos de qué tipo de avería se puede tratar, o si se trata únicamente de una desconfiguración del producto, ayudando al cliente a configurarlo correctamente.

Otro ejemplo sería el de un cliente que pide información porque se quiera comprar un nuevo modelo de un producto que ya tiene. Haría falta, por ejemplo, consultar qué producto está usando y cual es la nueva versión, y se le enumerarían las características del nuevo producto, por ejemplo.
Revisión de los diagramas de secuencia, resultando demasiado triviales en algunas partes como demasiado orientados al código en otras. Es por eso que nos dividimos el trabajo para hacer cada uno de nosotros un tipo de consulta. De manera individual realizaremos un trabajo de abstracción e imaginación de la lógica de negocio. Generaremos un diagrama en el que quede reflejado cuáles son las características o atributos o propiedades o circunstancias del cliente y su consulta, por lo que se ha de priorizar para que el sistema proporcione alternativas. Como aún estamos en una fase preliminar, los tipos de respuesta serán de carácter general, (p.e. acción dura, acción media, acción blanda, etc)

Diagrama de flujo de las incidencias

Diagrama de flujo de las incidencias
Diagrama de flujo de las incidencias

B.5. Acta 5 (21/11/2007)

Exponemos los diagramas generados, en los que se representa el árbol de decisiones que el sistema tendría que tomar para ofrecer una respuesta adecuada dependiendo de las condiciones del cliente. Estas condiciones serían por las que el sistema tendría que priorizar. Entre las condiciones del cliente propuestas tenemos:
  • Tipo de cliente
  • Número de vez que llama
  • Otras relacionadas con la naturaleza del caso en cuestión ( reclamaciones, incidencias, soluciones)
Tras revisar los diagramas encontramos algunos fallos:
  • Necesidad de aumentar el número de condiciones.
  • Necesidad de aprendizaje para que el sistema sea capaz de seguir las políticas de la empresa.
Diagrama de flujo de incidencias modificado:
Diagrama de flujo de las incidencias - Versión 2
Diagrama de flujo de las incidencias - Versión 2

Revisamos los diagramas de manera conjunta con el profesor. En la revisión descubrimos algunos cambios y mejoras:
  • Debemos prescindir por el momento de la lógica de negocio interna, de las acciones que se llevarán a cabo así como de la manera que las propiedades del cliente interactúan entre sí. Todos estos factores será impuestos por la empresa que use la aplicación para sus intereses comerciales.
  • El sistema será capaz de proponer un conjunto de acciones que dependerán de manera dinámica del histórico del cliente así como de otros valores sociales.
  • Revisando el histórico del cliente se podrán extraer información acerca de las acciones realizadas sobre el cliente. Esto es, se podrán sacar datos estadísticos que permitan cambiar las acciones disponibles.
  • Las acciones que serán propuestas al cliente serán determinadas por un sistema inteligente que tendrá en cuenta los puntos anteriores
Por ellos generamos el diagrama correspondiente atendiendo a estos cambios:
Diagrama de flujo de las incidencias - Versión 2
Diagrama de flujo de las incidencias - Versión 3


Realizamos una revisión de los diagramas con las modificaciones de la reunión anterior. Limitándonos a mostrar la estructura que tendría el sistema así como los “atributos” requeridos para que la inteligencia proponga una o varias respuestas. Lo que llamaremos acciones.
Empezamos una nueva fase: el diseño de la base de datos. Primeramente capturamos los atributos que hacen falta para modelar el comportamiento deseado. En esta primera fase nos centraremos en poner el nombre de la tabla junto con los campos que contendría, sin centrarnos en el tipo de datos de los campos, ni en los datos que contendría cada tabla, ni optimizaciones sobre la BBDD.

El sistema debe tener un comportamiento de acción - reacción. Por ellos es importante almacenar las acciones que hemos hecho sobre cada cliente, así como las reacciones que los clientes tienen al realizar dicha acción. De todos estos datos se podrán extraer comportamientos estadísticos con los que se sustituirán las acciones según los intereses de la empresa que use CRMI (por ejemplo: aquellas acciones que provoquen bajas de los clientes deberán ser sustituidas por otras si así lo aconsejan).

Como primera aproximación generamos una vista preliminar de las tablas y los campos que contendrían para gestionar las incidencias.
Diseño preliminar BBDD
Diseño preliminar BBDD


En la reunión revisamos el esquema de tablas y atributos generados. Sin encontrar mayor problema, generaremos un ejemplo a modo ilustrativo para hacer más palpable que las tablas propuestas y sus atributos cumplen las especificaciones del proyecto. Aun no estamos en condiciones de asegurar de que esas serán todas las tablas de nuestra BBDD en nuestro sistema (seguramente harán falta más) es por ello por lo que es necesario ver la completidud del sistema con el soporte de las tablas actual. Al hacer la revisión de las tablas nos dimos cuenta de que hacía falta unificar los nombres así como la disposición de las mismas.
El documento generado para la orden del día es un ejemplo que muestra para un caso genérico incidencias, aunque se han usado algunos datos concretos para aportar mas claridad al ejemplo, de cuales serían los atributos que se han de recuperar de la bases de datos así como la relación de algunas atributos con algunas tuplas en otras tablas.
Ilustración de funcionamiento
Ilustración de funcionamiento


Para ir entrando en materia se propone una implementación de la base de datos para ellos se genera el diagrama Entidad - Relación (diagrama E/R) relativo a las incidencias:
Diagrama Entidad - Relación
Diagrama Entidad - Relación

No hubo reunión. Debido a la cercanía del comienzo de las vacaciones de navidad, el profesor no tuvo clase la hora anterior a la reunión, por lo tanto se suspendió la reunión posponiéndola para el siguiente miércoles de enero.

En la primera parte el profesor revisa los documentos generados en la Reunión 8 y muestra su conformidad con lo que se propone en ellos. Desde hace algunas reuniones, nuestro sistema tiene un modulo que se incorpora como una caja negra. Se trata del módulo de la inteligencia. Como es natural ese módulo dispondrá de una serie de reglas, las cuales serán actualizadas y coherentes con el conocimiento estadístico extraído de la propia interacción de los clientes con el sistema. Además puede estar asentado sobre un conocimiento mas general, pero siempre estará adaptado a las reacciones que tienen los clientes. Existen diversas maneras de implementar el módulo de inteligencia:
  • Usando un sistema basado en reglas, haciendo uso de la ingeniería del conocimiento, así como el uso de las herramientas que proporciona esta metodología.
  • Usando algún componente que almacene las reglas y sea mantenido de forma manual, como puede ser una base de datos que contenga las condiciones para que una determinada acción se pueda realizar.
Por el momento el profesor sugiere que usemos el 2º modo de implementación (usando una BBDD)
En ambos sistemas las reglas deben tener la siguiente forma:

Condición 1 Condición 1 … Condición i … Condición N Acción
Valor a Valor b … Valor c … Valor d Acción A
Valor b Valor f … NULL … Valor g Acción B
De tal forma que si se cumplen todas las condiciones de una fila se activara la acción correspondiente a dichos valores.

Como condiciones aparecerán todas las condiciones usadas por alguna de las reglas almacenadas en el sistema. De esta forma será frecuente la aparición de valores NULL para alguna de las condiciones de una regla. Esto será así siempre y cuando ese valor no sea relevante para aplicar dicha acción.

Para esta reunión se trata de esbozar el diseño del módulo de inteligencia. Centrándonos en el diseño de la tabla que almacene las reglas.

Se muestra un ejemplo de lo que contendría la tabla de reglas.
id idAccion edad_Min edad_Max profesión tipoCliente estUltLlamada
1 1 0 17 NULL Normal NULL
2 2 18 26 Ingeniería Normal conforme
3 1 18 26 NULL moroso disconforme
4 1 35 45 Funcionario NULL conforme

La tabla reglas se añade al diseño de la BBDD:
Diseño Entidad - Relación - Versión 2
Diseño Entidad - Relación - Versión 2


Revisamos los diagramas propuestos por el profesor. Dado el visto bueno, nos pide que implementemos la base de datos. Para ello usaremos el diseño generado con el programa fabFORCE generando así las correspondientes instrucciones SQL de creación de tablas.

El código SQL para la generación de la base de datos se muestra a continuación: Notar que el código que se genera crea las tablas necesarias y algunas filas para su uso con las reclamaciones. La incorporación de la parte de soluciones y reclamaciones solo conllevaría algunas modificaciones en el actual diseño. Siendo necesario la inclusión de alguna nueva tabla así como la posible inclusión de atributos adicionales en las ya existentes.
Ver contenido del archivo version1.sql

CREATE TABLE Acciones (
  idAccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idTipoAccion INTEGER UNSIGNED NOT NULL,
  descripcion TEXT NULL,
  PRIMARY KEY(idAccion),
  INDEX Acciones_TipoAccion(idTipoAccion)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE Clientes (
  idCliente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idTipoCliente INTEGER UNSIGNED NOT NULL,
  nivelDeComprensión TINYINT UNSIGNED NULL,
  nombre VARCHAR(45) NULL,
  apellidos VARCHAR(45) NULL,
  fechaDeNacimiento DATE NULL,
  profesión VARCHAR(45) NULL,
  PRIMARY KEY(idCliente),
  INDEX Clientes_FK_TipoCliente(idTipoCliente)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE HistoricoAcciones (
  idHistoricoAccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idAccion INTEGER UNSIGNED NOT NULL,
  idProducto INTEGER UNSIGNED NOT NULL,
  idIncidencia INTEGER UNSIGNED NOT NULL,
  detalles TEXT NULL,
  numLlamada INTEGER UNSIGNED NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idHistoricoAccion),
  INDEX HistoricoAcciones_FK_Incidencias(idIncidencia),
  INDEX HistoricoAcciones_FK_Productos(idProducto),
  INDEX HistoricoAcciones_FKAcciones(idAccion)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE HistoricoDeudas (
  idHistoricoDeuda INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idCliente INTEGER UNSIGNED NOT NULL,
  deuda FLOAT NULL,
  fecha DATE NULL,
  PRIMARY KEY(idHistoricoDeuda),
  INDEX HistoricoDeudas_FK_Clientes(idCliente)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE HistoricoReacciones (
  idHistoricoReaccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idProducto INTEGER UNSIGNED NOT NULL,
  idIncidencia INTEGER UNSIGNED NOT NULL,
  idReaccion INTEGER UNSIGNED NOT NULL,
  detalles TEXT NULL,
  numLlamada INTEGER UNSIGNED NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idHistoricoReaccion),
  INDEX HistoricoReacciones_FK_Reacciones(idReaccion),
  INDEX HistoricoReacciones_FK_Incidencias(idIncidencia),
  INDEX HistoricoReacciones_FK_Productos(idProducto)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE Incidencias (
  idIncidencia INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idCliente INTEGER UNSIGNED NOT NULL,
  tipo VARCHAR(45) NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idIncidencia),
  INDEX Incidencias_FK_Clientes(idCliente)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE Productos (
  idProducto INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  problemasProducto BOOL NULL,
  mesesDeGarantia INTEGER UNSIGNED NULL,
  Caracteristicas TEXT NULL,
  TipoProducto TEXT NULL,
  PRIMARY KEY(idProducto)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE Reacciones (
  idReaccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idTipoReaccion INTEGER UNSIGNED NOT NULL,
  descripcion TEXT NULL,
  PRIMARY KEY(idReaccion),
  INDEX Reacciones_FK_TipoReaccion(idTipoReaccion)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE Reglas (
  idReglas INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idAccion INTEGER UNSIGNED NOT NULL,
  edad_Min TINYINT UNSIGNED NULL,
  edad_Max TINYINT UNSIGNED NULL,
  profesión VARCHAR(45) NULL,
  claseSocial VARCHAR(45) NULL,
  tipoCliente VARCHAR(45) NULL,
  estadoUltimaLlamada VARCHAR(45) NULL,
  PRIMARY KEY(idReglas),
  INDEX Reglas_FK_Acciones(idAccion)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE TipoAcciones (
  idTipoAccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombreTipo VARCHAR(45) NULL,
  descripción TEXT NULL,
  clasificación SET("Blanda", "Dura") NULL,
  PRIMARY KEY(idTipoAccion)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE TipoClientes (
  idTipoCliente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombreTipo VARCHAR(45) NULL,
  descripción TEXT NULL,
  PRIMARY KEY(idTipoCliente)
);
--------------------------------------
--------------------------------------
 
 
CREATE TABLE TipoReacciones (
  idTipoReaccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombreTipo VARCHAR(45) NULL,
  descripción TEXT NULL,
  clasificación SET("Blanda", "Dura") NULL,
  PRIMARY KEY(idTipoReaccion)
);
--------------------------------------
--------------------------------------
 
 
INSERT INTO `acciones` (`idAccion`, `idTipoAccion`, `descripcion`) VALUES
(1, 1, 'Se proveerá al cliente del servicio de la forma más rápida posible.
    Aumentando la prioridad de sus incidencias, o incluso saltándose la cola de casos pendientes.'),
(2, 1, 'Debido al perfil de cliente se tardará más de lo normal en proveer el servicio.
     Pudiéndose retrasar hasta el doble de lo establecido en el código de buenas prácticas
     o hasta que el cliente cumpla un determinado criterio, normalmente económico.'),
(3, 2, 'Se le proporcionará una reparación rápida y sin coste para el cliente.'),
(4, 2, 'Se le reparará el dispositivo asumiendo el cliente el 100% del coste de la reparación.');
--------------------------------------
--------------------------------------
 
 
INSERT INTO Clientes (idCliente, nivelDeComprensión, nombre, apellidos, fechaDeNacimiento) VALUES
    (NULL, 1, 'Juan', 'Pérez' , '1945-10-12');
INSERT INTO Clientes (idCliente, nivelDeComprensión, nombre, apellidos, fechaDeNacimiento) VALUES
    (NULL, 2, 'María', 'González' , '1977-05-02');
INSERT INTO Clientes (idCliente, nivelDeComprensión, nombre, apellidos, fechaDeNacimiento) VALUES
    (NULL, 3, 'Francisco', 'Sánchez' , '1985-04-15');
INSERT INTO Clientes (idCliente, nivelDeComprensión, nombre, apellidos, fechaDeNacimiento) VALUES
    (NULL, 1, 'Mercedes', 'Cruz' , '1962-04-20');
INSERT INTO Clientes (idCliente, nivelDeComprensión, nombre, apellidos, fechaDeNacimiento) VALUES
    (NULL, 1, 'Roberto', 'Pla' , '1955-12-25');
--------------------------------------
--------------------------------------
 
 
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
    (NULL, 1,  100 ,     '2007-1-15');
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
    (NULL, 2,  10000 , '2007-2-5');
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
    (NULL, 1,  500 ,     '2007-4-14');
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
    (NULL, 2,  20000 , '2007-5-30');
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
    (NULL, 2,  1000 ,   '2007-6-8');
--------------------------------------
--------------------------------------
 
 
INSERT INTO Incidencias (idIncidencia, idCliente, tipo,  fecha) VALUES
    (NULL, 1,  'tipo1' , '2007-10-25');
--------------------------------------
--------------------------------------
 
 
INSERT INTO Productos (idProducto, problemasProducto, mesesDeGarantía,
            Caracteristicas,  TipoProducto) VALUES
     (NULL, 1,  12 , 'Con camara de fotos', 'Tipo1');
--------------------------------------
--------------------------------------
 
 
INSERT INTO `reglas` (`idReglas`, `idAccion`, `edad_Min`, `edad_Max`, `profesión`,
              `claseSocial`, `tipoCliente`, `estadoUltimaLlamada`) VALUES
(NULL, 1, 0, 17, NULL, NULL, 'Normal', NULL),
(NULL, 2, 18, 26, 'Ingeniería', NULL, 'Normal', 'conforme'),
(NULL, 1, 18, 26, '', NULL, 'moroso', 'disconforme'),
(NULL, 1, 35, 45, 'Funcionario', NULL, NULL, 'conforme');
--------------------------------------
--------------------------------------
 
 
INSERT INTO `tipoacciones` (`idTipoAccion`, `nombreTipo`, `descripción`, `clasificación`) VALUES
(1, 'Provisión Servicio', NULL, 'Blanda'),
(2, 'Reparación dispositivo', NULL, 'Blanda');

Presentamos los diseños preliminares de la base de datos al profesor. Sin entrar en los detalles propios del diseño, para las siguientes reuniones empezaremos a implementar la BBDD. Como comentamos en reuniones pasadas, utilizaremos MySQL para gestionar la base de datos del proyecto. Para poder realizar pruebas en los laboratorios se solicitó acceso a MySQL.

Comprobado que se carga la base de datos en los laboratorios. Se ha modificado el archivo generado para la pasada reunión que se adjunta a continuación.
Ver contenido del archivo version2.sql
CREATE TABLE Acciones (
  idAccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idTipoAccion INTEGER UNSIGNED NOT NULL,
  descripcion TEXT NULL,
  PRIMARY KEY(idAccion),
  INDEX Acciones_TipoAccion(idTipoAccion)
);
 
/****************************************************/
 
CREATE TABLE Clientes (
  idCliente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idTipoCliente INTEGER UNSIGNED NOT NULL,
  nivelDeComprensin TINYINT UNSIGNED NULL,
  nombre VARCHAR(45) NULL,
  apellidos VARCHAR(45) NULL,
  fechaDeNacimiento DATE NULL,
  profesin VARCHAR(45) NULL,
  PRIMARY KEY(idCliente),
  INDEX Clientes_FK_TipoCliente(idTipoCliente)
);
/****************************************************/
 
 
CREATE TABLE HistoricoAcciones (
  idHistoricoAccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idAccion INTEGER UNSIGNED NOT NULL,
  idProducto INTEGER UNSIGNED NOT NULL,
  idIncidencia INTEGER UNSIGNED NOT NULL,
  detalles TEXT NULL,
  numLlamada INTEGER UNSIGNED NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idHistoricoAccion),
  INDEX HistoricoAcciones_FK_Incidencias(idIncidencia),
  INDEX HistoricoAcciones_FK_Productos(idProducto),
  INDEX HistoricoAcciones_FKAcciones(idAccion)
);
/****************************************************/
 
 
CREATE TABLE HistoricoDeudas (
  idHistoricoDeuda INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idCliente INTEGER UNSIGNED NOT NULL,
  deuda FLOAT NULL,
  fecha DATE NULL,
  PRIMARY KEY(idHistoricoDeuda),
  INDEX HistoricoDeudas_FK_Clientes(idCliente)
);
/****************************************************/
 
 
CREATE TABLE HistoricoReacciones (
  idHistoricoReaccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idProducto INTEGER UNSIGNED NOT NULL,
  idIncidencia INTEGER UNSIGNED NOT NULL,
  idReaccion INTEGER UNSIGNED NOT NULL,
  detalles TEXT NULL,
  numLlamada INTEGER UNSIGNED NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idHistoricoReaccion),
  INDEX HistoricoReacciones_FK_Reacciones(idReaccion),
  INDEX HistoricoReacciones_FK_Incidencias(idIncidencia),
  INDEX HistoricoReacciones_FK_Productos(idProducto)
);
/****************************************************/
 
 
CREATE TABLE Incidencias (
  idIncidencia INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idCliente INTEGER UNSIGNED NOT NULL,
  tipo VARCHAR(45) NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idIncidencia),
  INDEX Incidencias_FK_Clientes(idCliente)
);
/****************************************************/
 
 
CREATE TABLE Productos (
  idProducto INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  problemasProducto BOOL NULL,
  mesesDeGarantia INTEGER UNSIGNED NULL,
  Caracteristicas TEXT NULL,
  TipoProducto TEXT NULL,
  PRIMARY KEY(idProducto)
);
/****************************************************/
 
 
CREATE TABLE Reacciones (
  idReaccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idTipoReaccion INTEGER UNSIGNED NOT NULL,
  descripcion TEXT NULL,
  PRIMARY KEY(idReaccion),
  INDEX Reacciones_FK_TipoReaccion(idTipoReaccion)
);
/****************************************************/
 
 
CREATE TABLE Reglas (
  idReglas INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idAccion INTEGER UNSIGNED NOT NULL,
  edad_Min TINYINT UNSIGNED NULL,
  edad_Max TINYINT UNSIGNED NULL,
  profesin VARCHAR(45) NULL,
  claseSocial VARCHAR(45) NULL,
  tipoCliente VARCHAR(45) NULL,
  estadoUltimaLlamada VARCHAR(45) NULL,
  PRIMARY KEY(idReglas),
  INDEX Reglas_FK_Acciones(idAccion)
);
/****************************************************/
 
 
CREATE TABLE TipoAcciones (
  idTipoAccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombreTipo VARCHAR(45) NULL,
  descripcin TEXT NULL,
  clasificacin SET("Blanda", "Dura") NULL,
  PRIMARY KEY(idTipoAccion)
);
/****************************************************/
 
 
CREATE TABLE TipoClientes (
  idTipoCliente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombreTipo VARCHAR(45) NULL,
  descripcin TEXT NULL,
  PRIMARY KEY(idTipoCliente)
);
/****************************************************/
 
 
CREATE TABLE TipoReacciones (
  idTipoReaccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombreTipo VARCHAR(45) NULL,
  descripcin TEXT NULL,
  clasificacin SET("Blanda", "Dura") NULL,
  PRIMARY KEY(idTipoReaccion)
);
/****************************************************/
 
 
INSERT INTO `acciones` (`idAccion`, `idTipoAccion`, `descripcion`) VALUES
(1, 1, 'Se proveer al cliente del servicio de la forma ms rápida posible.
Aumentando la prioridad de sus incidencias, o incluso saltándose la cola de casos pendientes.'),
(2, 1, 'Debido al perfil de cliente se tardar ms de lo normal en proveer el servicio.
Pudiéndose retrasar hasta el doble de lo establecido en el cdigo de buenas prácticas
o hasta que el cliente cumpla un determinado criterio, normalmente económico.'),
(3, 2, 'Se le proporcionar una reparación rápida y sin coste para el cliente.'),
(4, 2, 'Se le reparar el dispositivo asumiendo el cliente el 100% del coste de la reparación.');
/****************************************************/
 
 
INSERT INTO Clientes (idCliente, nivelDeComprensin, nombre, apellidos, fechaDeNacimiento) VALUES
        (NULL, 1, 'Juan', 'Prez' , '1945-10-12');
INSERT INTO Clientes (idCliente, nivelDeComprensin, nombre, apellidos, fechaDeNacimiento) VALUES
        (NULL, 2, 'Mara', 'Gonzlez' , '1977-05-02');
INSERT INTO Clientes (idCliente, nivelDeComprensin, nombre, apellidos, fechaDeNacimiento) VALUES
        (NULL, 3, 'Francisco', 'Snchez' , '1985-04-15');
INSERT INTO Clientes (idCliente, nivelDeComprensin, nombre, apellidos, fechaDeNacimiento) VALUES
        (NULL, 1, 'Mercedes', 'Cruz' , '1962-04-20');
INSERT INTO Clientes (idCliente, nivelDeComprensin, nombre, apellidos, fechaDeNacimiento) VALUES
        (NULL, 1, 'Roberto', 'Pla' , '1955-12-25');
/****************************************************/
 
 
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
        (NULL, 1,  100 ,     '2007-1-15');
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
        (NULL, 2,  10000 , '2007-2-5');
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
        (NULL, 1,  500 ,     '2007-4-14');
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
        (NULL, 2,  20000 , '2007-5-30');
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
        (NULL, 2,  1000 ,   '2007-6-8');
/****************************************************/
 
 
INSERT INTO Incidencias (idIncidencia, idCliente, tipo,  fecha) VALUES
        (NULL, 1,  'tipo1' , '2007-10-25');
/****************************************************/
 
INSERT INTO Productos (idProducto, problemasProducto, mesesDeGarantia, Caracteristicas,  TipoProducto)
        VALUES (NULL, 1,  12 , 'Con camara de fotos', 'Tipo1');
/****************************************************/
 
 
INSERT INTO `reglas` (`idReglas`, `idAccion`, `edad_Min`, `edad_Max`, `profesin`,
 `claseSocial`, `tipoCliente`, `estadoUltimaLlamada`) VALUES
        (NULL, 1, 0, 17, NULL, NULL, 'Normal', NULL),
        (NULL, 2, 18, 26, 'Ingeniera', NULL, 'Normal', 'conforme'),
        (NULL, 1, 18, 26, '', NULL, 'moroso', 'disconforme'),
        (NULL, 1, 35, 45, 'Funcionario', NULL, NULL, 'conforme');
/****************************************************/
 
 
INSERT INTO `tipoacciones` (`idTipoAccion`, `nombreTipo`, `descripcin`, `clasificacin`) VALUES
(1, 'Provisin Servicio', NULL, 'Blanda'),
(2, 'Reparacin dispositivo', NULL, 'Blanda');

Realizamos una integración de las 3 partes constituyentes el CRMI, a saber: Reclamaciones, Incidencias y Consultas de Información

El diseño de la BBDD realizado es el siguiente:
Diseño completo BBDD
Diseño completo BBDD


El script SQL de creación de las tablas es el siguiente:
Ver contenido del archivo version3.sql
CREATE TABLE Acciones (
  idAccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idTipoAccion INTEGER UNSIGNED NOT NULL,
  descripcion TEXT NULL,
  PRIMARY KEY(idAccion),
  INDEX Acciones_FK_TipoAcciones(idTipoAccion)
);
 
INSERT INTO `acciones` (`idAccion`, `idTipoAccion`, `descripcion`) VALUES
(1, 1, 'reponer servicio/equipo'),
(2, 1, 'promocionar cuotas del servicio'),
(3, 2, 'suspender el servicio'),
(4, 2, 'embargar bienes'),
(5, 1, 'proporcionar ayuda de forma presencial con el cliente'),
(6, 1, 'reparar dispositivo'),
(7, 1, 'configurar dispositivo por telefono con la intervención del cliente'),
(8, 1, 'efectuar comprobaciones de funcionamiento'),
(9, 1, 'sustituir dispositivo por uno equivalente'),
(10, 1, 'sustituir dispositivo por uno mejor'),
(11, 1, 'sustituir dispositivo por uno peor'),
(12, 1, 'sustituir dispositivo por uno mas sencillo'),
(13, 1, 'sustituir dispositivo por uno mas complicado');
 
 
CREATE TABLE Clientes (
  idCliente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idProfesion INTEGER UNSIGNED NOT NULL,
  idTipoCliente INTEGER UNSIGNED NOT NULL,
  nivelDeComprensión TINYINT UNSIGNED NULL,
  nombre VARCHAR(45) NULL,
  apellidos VARCHAR(45) NULL,
  fechaDeNacimiento DATE NULL,
  PRIMARY KEY(idCliente),
  INDEX Clientes_FK_TipoCliente(idTipoCliente),
  INDEX Clientes_FK_Profesiones(idProfesion)
);
 
INSERT INTO `clientes` (`idCliente`, `idProfesion`, `idTipoCliente`, `nivelDeComprensión`,
            `nombre`, `apellidos`, `fechaDeNacimiento`) VALUES
(1, 5, 3, 1, 'Juan', 'Pérez', '1945-10-12'),
(2, 4, 1, 2, 'María', 'González', '1977-05-02'),
(3, 3, 3, 3, 'Francisco', 'Sánchez', '1985-04-15'),
(4, 2, 2, 1, 'Mercedes', 'Cruz', '1962-04-20'),
(5, 1, 1, 1, 'Roberto', 'Pla', '1955-12-25');
 
 
CREATE TABLE Consultas (
  idConsulta INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idCliente INTEGER UNSIGNED NOT NULL,
  tipo VARCHAR(45) NOT NULL,
  fecha DATETIME NOT NULL,
  PRIMARY KEY(idConsulta),
  INDEX Consultas_FK_Clientes(idCliente)
);
 
CREATE TABLE HistoricoAcciones (
  idHistoricoAccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idConsulta INTEGER UNSIGNED NOT NULL,
  idReclamacion INTEGER UNSIGNED NOT NULL,
  idAccion INTEGER UNSIGNED NOT NULL,
  idProducto INTEGER UNSIGNED NOT NULL,
  idIncidencia INTEGER UNSIGNED NOT NULL,
  detalles TEXT NULL,
  numLlamada INTEGER UNSIGNED NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idHistoricoAccion),
  INDEX HistoricoAcciones_FK_Productos(idProducto),
  INDEX HistoricoAcciones_FK_Acciones(idAccion),
  INDEX HistoricoAcciones_FK_Reclamaciones(idReclamacion),
  INDEX HistoricoAcciones_FK_Incidencias(idIncidencia),
  INDEX HistoricoAcciones_FK_Consultas(idConsulta)
);
 
CREATE TABLE HistoricoDeudas (
  idHistoricoDeuda INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idCliente INTEGER UNSIGNED NOT NULL,
  deuda FLOAT NULL,
  fecha DATE NULL,
  PRIMARY KEY(idHistoricoDeuda),
  INDEX HistoricoDeudas_FK_Clientes(idCliente)
);
 
INSERT INTO HistoricoDeudas (idHistoricoDeuda, idCliente, deuda,  fecha) VALUES
(NULL, 1,  100 , '2007-1-15'),
(NULL, 2,  10000 , '2007-2-5'),
(NULL, 1,  500 , '2007-4-14'),
(NULL, 2,  20000 , '2007-5-30'),
(NULL, 2,  1000 , '2007-6-8');
 
 
CREATE TABLE HistoricoReacciones (
  idHistoricoReaccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idConsulta INTEGER UNSIGNED NOT NULL,
  idReclamacion INTEGER UNSIGNED NOT NULL,
  idProducto INTEGER UNSIGNED NOT NULL,
  idIncidencia INTEGER UNSIGNED NOT NULL,
  idReaccion INTEGER UNSIGNED NOT NULL,
  detalles TEXT NULL,
  numLlamada INTEGER UNSIGNED NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idHistoricoReaccion),
  INDEX HistoricoReacciones_FK_Reacciones(idReaccion),
  INDEX HistoricoReacciones_FK_Incidencias(idIncidencia),
  INDEX HistoricoReacciones_FK_Productos(idProducto),
  INDEX HistoricoReacciones_FK_Reclamaciones(idReclamacion),
  INDEX HistoricoReacciones_FK_Consultas(idConsulta)
);
 
CREATE TABLE Incidencias (
  idIncidencia INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idCliente INTEGER UNSIGNED NOT NULL,
  tipo VARCHAR(45) NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idIncidencia),
  INDEX Incidencias_FK_Clientes(idCliente)
);
 
INSERT INTO Incidencias (idIncidencia, idCliente, tipo,  fecha) VALUES
(NULL, 1,  'tipo1' , '2007-10-25');
 
 
CREATE TABLE Productos (
  idProducto INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  Nombre VARCHAR(45) NULL,
  Modelo VARCHAR(45) NULL,
  problemasProducto BOOL NULL,
  mesesDeGarantia INTEGER UNSIGNED NULL,
  Caracteristicas TEXT NULL,
  TipoProducto TEXT NULL,
  PRIMARY KEY(idProducto)
);
 
 
INSERT INTO Productos
 (idProducto, problemasProducto, mesesDeGarantia, Caracteristicas,  TipoProducto)
 VALUES (NULL, 1,  12 , 'Con camara de fotos', 'Tipo1');
 
 
CREATE TABLE Profesiones (
  idProfesion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombre VARCHAR(60) NULL,
  comentarios TEXT NULL,
  PRIMARY KEY(idProfesion)
);
 
INSERT INTO `profesiones` (`idProfesion`, `nombre`, `comentarios`) VALUES
(1, 'Fuerzas Armadas', 'Fuerzas Armadas'),
(2, 'Dirección de las Empresas y de las Administraciones Públicas',
    'Dirección de las Empresas y de las Administraciones Públicas'),
(3, 'Técnicos y Profesionales científicos',
    'Técnicos y Profesionales científicos e intelectuales'),
(4, 'Técnicos y Profesionales de Apoyo', 'Técnicos y Profesionales de Apoyo'),
(5, 'Empleados de tipo administrativo', 'Empleados de tipo administrativo'),
(6, 'Trabajadores de los Servicios Sociales',
    'Trabajadores de los Servicios de restauración, personales, protección y vendedores de los comercios'),
(7, 'Trabajadores cualificados en agricultura y pesca',
    'Trabajadores cualificados en la agricultura y en la pesca'),
(8, 'Trabajadores cualificados de las industrias primarias',
    'Artesanos y Trabajadores cualificados de las industrias manofactureras,
     la construcción y la minería, excepto los operadores de instalaciones y maquinaría'),
(9, 'Operadores de instalaciones y maquinaria',
    'Operadores de instalaciones y maquinaria y montadores'),
(10, 'Trabajadores no cualificados', 'Trabajadores no cualificados'),
(11, 'Inactivo o desocupado', 'Inactivo o desocupado');
 
 
CREATE TABLE Reacciones (
  idReaccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idTipoReaccion INTEGER UNSIGNED NOT NULL,
  descripcion TEXT NULL,
  PRIMARY KEY(idReaccion),
  INDEX Reacciones_FK_TipoReacciones(idTipoReaccion)
);
 
CREATE TABLE Reclamaciones (
  idReclamacion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idCliente INTEGER UNSIGNED NOT NULL,
  tipo VARCHAR(45) NULL,
  fecha DATETIME NULL,
  PRIMARY KEY(idReclamacion),
  INDEX Reclamaciones_FKIndex1(idCliente)
);
 
INSERT INTO Incidencias
(idIncidencia, idCliente, tipo,  fecha)
VALUES (NULL, 1,  'tipo1' , '2007-10-25');
 
 
CREATE TABLE Reglas (
  idReglas INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  idAccion INTEGER UNSIGNED NOT NULL,
  edad_Min TINYINT UNSIGNED NULL,
  edad_Max TINYINT UNSIGNED NULL,
  profesión VARCHAR(45) NULL,
  claseSocial VARCHAR(45) NULL,
  tipoCliente VARCHAR(45) NULL,
  estadoUltimaLlamada VARCHAR(45) NULL,
  PRIMARY KEY(idReglas),
  INDEX Reglas_FK_Acciones(idAccion)
);
 
 
INSERT INTO `reglas`
(`idReglas`, `idAccion`, `edad_Min`, `edad_Max`, `profesión`, `claseSocial`,
            `tipoCliente`, `estadoUltimaLlamada`) VALUES
(NULL, 1, 0, 17, NULL, NULL, 'Normal', NULL),
(NULL, 2, 18, 26, 'Ingeniería', NULL, 'Normal', 'conforme'),
(NULL, 1, 18, 26, '', NULL, 'moroso', 'disconforme'),
(NULL, 1, 35, 45, 'Funcionario', NULL, NULL, 'conforme');
 
 
CREATE TABLE TipoAcciones (
  idTipoAccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombreTipo VARCHAR(45) NULL,
  descripción TEXT NULL,
  clasificación SET('Blanda', 'Dura') NULL,
  PRIMARY KEY(idTipoAccion)
);
 
CREATE TABLE TipoClientes (
  idTipoCliente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombreTipo VARCHAR(45) NULL,
  descripción TEXT NULL,
  PRIMARY KEY(idTipoCliente)
);
 
INSERT INTO `tipoclientes` (`idTipoCliente`, `nombreTipo`, `descripción`) VALUES
(1, 'exigencia baja', 'baja necesidad de tecnologías avanzadas'),
(2, 'exigencia media', 'necesidades tecnológicas medias'),
(3, 'exigencia alta', 'Alta necesidad de usar las ultimas tecnologías.');
 
 
CREATE TABLE TipoReacciones (
  idTipoReaccion INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nombreTipo VARCHAR(45) NULL,
  descripción TEXT NULL,
  clasificación SET('Blanda', 'Dura') NULL,
  PRIMARY KEY(idTipoReaccion)
);

Como se pedía para esta reunión se genera un pequeño ejemplo de los pasos que se llevarían a cabo vistos desde el punto de vista de la BBDD. El ejemplo trata de manera esquemática el proceso desde que un nuevo cliente llega al sistema, crea una nueva incidencia, pasado un tiempo consulta el estado de la misma. Además de quedar registrado en el según el modelo acción - reacción.

Al final se muestra un pequeño ejemplo de una selección para obtener las acciones que se le aplicarían al cliente. Tener en cuenta que el ejemplo es una simplificación. Para la obtención de las acciones sería necesario restringir mas por mayor numero de campos. Además la información de las reglas es meramente ilustrativa no contiene significado adecuado en el dominio.
Ver contenido del archivo inserciones.sql
-- Inserción de un cliente existente  => error
-- INSERT INTO clientes VALUES(1, 3, 1, 1, 'Juan', 'Pérez', '1945-10-12');
 
-- Inserción de un nuevo cliente
INSERT INTO clientes VALUES(99, 2, 1, 1, 'Juan', 'Pérez', '1945-10-12');
 
 
-- El cliente abre una incidencia
INSERT INTO incidencias VALUES(10, 3, 99, 'iniciada','2008-03-11');
 
-- MIRAR EN REGLAS para propononer una acción   <-----------
 
INSERT INTO historicoAcciones VALUES(NULL, NULL, 10, NULL, 1, 1,
 'el cliente no tiene línea', 1, '2008-03-11 20:40');
 
INSERT INTO historicoReacciones VALUES(NULL, NULL, 10, NULL, 1, 1, 'detalles', 1, '2008-03-11 20:40');
 
 
-- comienza la resolución de la incidencia
UPDATE incidencias SET estado = 'en proceso' WHERE idIncidencia = 10;
 
-- El cliente quiere consultar el estado de la incidencia
SELECT estado FROM incidencias WHERE
    idIncidencia = (SELECT idIncidencia FROM incidencias WHERE DNI_Cliente = 99);
 
-- MIRAR EN REGLAS para proponer una acción   <-----------
 
INSERT INTO historicoAcciones VALUES(NULL, NULL, 10, NULL, 1, 1,
    'el cliente no tiene línea', 2, '2008-03-13 12:23');
 
INSERT INTO historicoReacciones VALUES(NULL, NULL, 10, NULL, 1, 1, 'detalles', 2, '2008-03-13 12:23');
 
-- Ejemplo de reglas
SELECT descripcion FROM acciones WHERE idAccion IN (
    SELECT idAccion FROM reglas WHERE idProfesion = (
        SELECT idProfesion FROM clientes WHERE DNI = 99
        ));

Esta reunión (Reunión 15) estaba prevista para el día 25/03/2008, por motivos de incompatibilidad de horarios se ha pospuesto a una reunión posterior. Corresponde al Acta 16.

Se han realizado algunos cambios en la BBDD. De esta forma se clarifica la estructura de la BBDD con el fin de facilitar su genericidad y desarrollo.
  • Cambio de nomenclatura, para que el siguiente punto tenga sentido semántico. Ahora las Incidencias pasan a llamarse Averías. Y del mismo modo el conjunto de Averías, Reclamaciones y Consultas pasan a llamarse Incidencias.
  • Ahora sólo hay una tabla en la que se almacena la información referente a Averías, Reclamaciones y Consultas. Por ello se combinan las 3 tablas anteriores para crear una nueva que se llame Incidencias. Además como es natural es necesario añadir un campo extra para poder diferenciar el tipo de incidencia. Del mismo modo las tablas de acciones y reacciones se simplifican reduciendo el número de campos sin uso.
  • Para poder elegir de manera correcta la acción es necesario identificar las acciones con el tipo de Incidencia, en sentido global, ya que en cualquier caso, la acción no sólo depende del cliente, sino que depende en mas medida de la incidencia asociada.
Diagrama de flujo
El diagrama de flujo muestra el comportamiento del CRMI para el caso de un cliente existente o no quiera interaccionar con el sistema. El diagrama se centra sobre todo en las reglas y la selección de las acciones que se realizaran al cliente.
Diagrama de flujo
Figura B.1: Diagrama de flujo

Nueva versión del documento disponible en el Acta 16.

En esta reunión se enseña al profesor los casos de uso, la documentación referente a la memoria y el diagrama de flujo generado en el acta 15. Respecto al dicho diagrama se sugiere la modificación y explicación de las variables que intervienen en el módulo buscar reglas correspondientes a la etapa de inteligencia. Por ellos se genera un diagrama modificado según lo propuesto.

En una segunda parte de la reunión se concretan las partes que debe contener la memoria.
La memoria se compondrá de las siguientes partes enumeradas por el profesor.
La explicación del contenido puede variar ya que no ha sido detallada por parte del profesor.

  1. Objetivo del proyecto (4)

    • Explicar que pretende conseguir el proyecto. Finalidad. En definitiva, objetivos del proyecto.

  2. Metodología de desarrollo (4)

    • Explicar cómo nos hemos organizado para la elaboración del proyecto.
      • Reuniones semanales
      • Documentación y coordinación en la wiki
      • Revisiones de los documentos con el profesor

  3. Análisis (10)

    • Comentar qué técnicas son necesarias para llevar a cabo el proyecto
      • Datos estadísticos
      • Inferencias
      • Datos de casos reales
      • Data mining

  4. Diseño (10)

    • Explicar los aspectos del diseño relacionados con el proyecto. En principio se centrarían en la base de datos aunque también se podrán explicar las decisiones de la lógica del sistema, interfaces. etc.

  5. Implementación (10)

    • Tocando los mismos temas que el apartado de implementación pero esta vez desde el punto de vista de la implementación. Considerar aspectos globales. Explicar la arquitectura del sistema.

  6. Resultados (5)

    • Resultados obtenidos del "sistema en funcionamiento". Se piden incorporar varios casos con datos reales que ilustren las características y objetivos del proyecto. Serán casos "en funcionamiento"

  7. Conclusiones (3)

    • Conclusiones finales.

  8. Futuras extensiones (2)

    • Mejoras que se pueden añadir al sistema para mejorar o añadir funcionalidad.

  1. Bibliografía (1)

Aunque el sistema no se llegará a implementar, eso al menos son las previsiones, en lo referente a implementación y cuestiones de funcionamiento, no ha de tomarse en sentido estricto, si no en sentido amplio, de tal manera que se pueda decir establecer un criterio de implementación, arquitectura interna. etc.

Se incluye una nueva versión del diagrama de flujo generado en el acta 15 incorporando el árbol discriminatorio, en lugar de un filtro como aparecía en la versión anterior. Las diferencias entre filtro y árbol discriminatorio son:
  • Forma de realizar las preguntas
    • En el filtro se pregunta por todas las variables al la vez.
    • En el árbol se pregunta cada vez por una variable distinta. De tal forma que se pregunte primera por las variables mas discriminatorias. Además no siempre preguntará por todas las variables en todos los casos.
  • Resultados obtenidos
    • En el filtro los resultados obtenidos son siempre iguales sin importar el orden relativo de las variables.
    • En el árbol discriminatorio los resultados podrían ser distintos dependiendo del orden de las variables.
Diagrama de flujo - Versión 2
Figura B.2: Diagrama de flujo - Versión 2

En esta reunión hemos estado hablando de como debe estar estructurada la memoria final del proyecto. Los distintos apartados que la componen son los siguientes:
  1. Antecedentes:
    Aquí definimos que es un CRM-I mediante una definición completa.
  2. Objetivos del proyecto:
    Dejaremos claro que es lo que queremos mostrar con el proyecto.
  3. Metodología de desarrollo:
    Explicaremos cómo nos hemos organizado en el proyecto y cómo se han llevado a cabo las reuniones.
  4. Análisis:
    Se describen las distintas técnicas estudiadas para llevar a cabo nuestro objetivo.
  5. Diseño:
    En este apartado mostraremos los diagramas y la estructura final de la base de datos. Se incluyen los casos de usos ya implementados.
  6. Implementación:
    Describimos las tecnologías de desarrollo utilizadas y mencionamos parte del interfaz con algún pantallazo incluido.
  7. Resultados:Se mencionan los casos más significativos.
  8. Conclusiones:
  9. Futuras extensiones:
  10. Bibliografía:

En cuanto a las extensiones de cada apartado no está muy claro.

Reunión de control para revisar la memoria. El objetivo de esta reunión es presentar al profesor la memoria para que nos de su opinión y corrija posibles fallos, tanto como cambios de contenidos, punto de vista, temas que se debieran tratar, etc. A fecha de la reunión la memoria se encuentra en pleno desarrollo, aún no esta terminada, pero si bastante avanzada, por eso requerimos el punto de vista del profesor para que establezca nuevos objetivos de la memoria. Por falta de tiempo del profesor, en la reunión solo pudimos darle la memoria en formato editable.

En la reunión se revisa la memoria y se establecen nuevos objetivos. El contenido de la memoria es adecuado, pero quedan limar detalles relacionados con al expresión y el estilo. Aunque el contenido es correcto quedan temas pendientes de desarrollar. Es una reunión bastante breve aunque nos sirve de punto de partida para seguir ampliando la memoria.

Tras la revisión de la memoria del acta anterior (Acta 19) y habiendo ampliado la memoria en los puntos comentados, se procede a una revisión mas exhaustiva con el profesor revisando más en detalle los contenidos de la memoria. Se establecen nuevos objetivos para la memoria: añadir un apartado de ejemplos de funcionamiento que refleje el funcionamiento del sistema. Además comentamos cuestiones relacionadas con la exposición del proyecto:
  • Transparencia con la metodología desarrollada
  • Transparencia con la estructura del sistema (arquitectura componente... en alto nivel)
    • Diagrama de bloques (BBDD mecanismos inferencia, paquete estadístico)
  • Transparencia con los resultados (ejemplos de funcionamiento)
  • Transparencia con el diseño de la BBDD (reducido, no mostrar atributos ni relaciones como por ejemplo es un o es de tipo. quitar la tabla tipo que relaciona reglas con incidencias)

No hay comentarios:

Publicar un comentario

Suscribirse a: Entradas (Atom)