Metodología CRISP-DM Parte 3 - Final

Realizado por la SmartB María Victoria Díaz

Hola,  a continuación te traemos la parte número 3 y final de la metodología CRISP-DM, en caso de que quieras validar las secciones anteriores puedes verificar nuestro Blog.

5. Fase de evaluación

En esta fase se evalúa el modelo, teniendo en cuenta el cumplimiento de los criterios de éxito del problema. Debe considerarse además, que la fiabilidad calculada para el modelo se aplica solamente para los datos sobre los que se realizó el análisis. Es preciso revisar el proceso, teniendo en cuenta los resultados obtenidos, para poder repetir algún paso anterior, en el que se haya posiblemente cometido algún error. Considerar que se pueden emplear múltiples herramientas para la interpretación de los resultados. Las matrices de confusión Edelstein, 1999 son muy empleadas en problemas de clasificación y consisten en una tabla que indica cuantas clasificaciones se han hecho para cada tipo, la diagonal de la tabla representa las clasificaciones correctas. Si el modelo generado es válido en función de los criterios de éxito establecidos en la fase anterior, se procede a la explotación del modelo. La figura 6 Detalla las tareas que componen esta fase y los resultados que se deben obtener.

Figura No. 6 Fase de evaluación ([CRISP-DM, 2000]).

Las tareas involucradas en esta fase del proceso son las siguientes:

Evaluación de los resultados. En los pasos de evaluación anteriores, se trataron factores tales como la exactitud y generalidad del modelo generado. Esta tarea involucra la evaluación del modelo en relación a los objetivos del negocio y busca determinar si hay alguna razón de negocio para la cual, el modelo sea deficiente, o si es aconsejable probar el modelo, en un problema real si el tiempo y restricciones lo permiten. Además de los resultados directamente relacionados con el objetivo del proyecto, ¿es aconsejable evaluar el modelo en relación a otros objetivos distintos a los originales?, esto podría revelar información adicional.

Revisión del proceso. El proceso de revisión, se refiere a calificar al proceso entero de DM, a objeto de identificar elementos que pudieran ser mejorados.

Determinación de futuras fases. Si se ha determinado que las fases hasta este momento han generado resultados satisfactorios, podría pasarse a la fase siguiente, en caso contrario podría decidirse por otra iteración desde la fase de preparación de datos o de modelación con otros parámetros. Podría ser incluso que en esta fase se decida partir desde cero con un nuevo proyecto de DM 6.

6. Fase de implementación

En esta fase (figura 7), y una vez que el modelo ha sido construido y validado, se transforma el conocimiento obtenido en acciones dentro del proceso de negocio, ya sea que el analista recomiende acciones basadas en la observación del modelo y sus resultados, ya sea aplicando el modelo a diferentes conjuntos de datos o como parte del proceso, como por ejemplo, en análisis de riesgo crediticio, detección de fraudes, etc. Generalmente un proyecto de Data Mining no concluye en la implantación del modelo, pues se deben documentar y presentar los resultados de manera comprensible para el usuario, con el objetivo de lograr un incremento del conocimiento. Por otra parte, en la fase de explotación se debe asegurar el mantenimiento de la aplicación y la posible difusión de los resultados.  Las tareas que se ejecutan en esta fase son las siguientes:

 Figura No. 7. Fase de implementación ([CRISP-DM, 2000])

Plan de implementación. Para implementar el resultado de DM en la organización, esta tarea toma los resultados de la evaluación y concluye una estrategia para su implementación. Si un procedimiento general se ha identificado para crear el modelo, este procedimiento debe ser documentado para su posterior implementación. 

Monitorización y Mantenimiento. Si los modelos resultantes del proceso de Data Mining son implementados en el dominio del problema como parte de la rutina diaria, es aconsejable preparar estrategias de monitorización y mantenimiento para ser aplicadas sobre los modelos. La retroalimentación generada por la monitorización y mantenimiento pueden indicar si el modelo está siendo utilizado apropiadamente

Informe Final. Es la conclusión del proyecto de DM realizado. Dependiendo del plan de implementación, este informe puede ser sólo un resumen de los puntos importantes del proyecto y la experiencia lograda o puede ser una presentación final que incluya y explique los resultados logrados con el proyecto. 

Revisión del proyecto: En este punto se evalúa qué fue lo correcto y qué lo incorrecto, qué es lo que se hizo bien y qué es lo que se requiere mejorar

Tips de Diseño de DWH- La Granularidad – Parte 1

Por nuestra Blogger SmartB: Rut Almoguera

Querido lector que te inicias en el diseño de DWHs, si crees que la granularidad es un término elegante para referirse a la cantidad de granos de arena que hay en una hermosa playa del Caribe… Entonces este post es para ti.

Cuando escuchamos la palabra granularidad normalmente lo asociamos a granos de arena, sin embargo en el caso del diseño de un DWH, este concepto se refiere a dos cosas.  Una es al nivel de detalle de la data que guardamos en una tabla de una dimensión, y otra al nivel de detalle que con el que registramos los hechos en una tabla Fact.

En este post hablaremos de la granularidad en las dimensiones.

La granularidad como instintivamente pensamos está asociada al grano, pero al grano de las dimensiones de un DWH. El grano de las dimensiones es el nivel de detalle a la que llegamos en la data que guardamos en la dimensión. Para entender mejor este concepto, usemos de ejemplo la dimensión Región.

Imaginemos por un momento que tenemos un DWH en donde registramos las ventas de unos almacenes que tienen presencia a nivel mundial.  En este DWH se requiere que se registren las regiones en donde se realizaron las ventas para poder analizar cómo fueron las ventas en cada una de ellas y tal vez analizar donde aplicar campañas estratégicas con ofertas por Región.

Supongamos que nuestra región de venta se registra en el transaccional a nivel de Municipio, es decir cada tienda que realiza una venta deja registrado en el sistema el Municipio de la misma.  En este caso en el sistema transaccional conocemos el detalle de las ventas con el Continente, el País, el Estado, la Ciudad y el Municipio, con lo cual tendríamos una jerarquía que llega hasta el detalle del Municipio:

Con esta jerarquía en la dimensión Región, tendríamos que la granularidad de dicha dimensión es hasta el nivel de Municipio.

Con gran frecuencia la granularidad de las dimensiones en el DWH es la que encontramos en el sistema transaccional, pero a veces ese nivel de detalle es excesivo para el DWH, y entonces debemos decidir cambiarlo por algo más resumido, para que sea útil para los análisis que se desean realizar.  Imaginemos por ejemplo que el detalle que deseamos conocer en el DWH es solo hasta el nivel de la Región.  En este caso la jerarquía que estaríamos usando dentro de nuestro DWH para la dimensión Región sería diferente al nivel de detalle que tenemos en el transaccional.  En este caso la jerarquía para dicha dimensión sería la siguiente:

Con esto la dimensión Región llegaría solo hasta la granularidad de Región y no del Municipio.

Mientras más detalle tiene una dimensión en el DWH más fino es el grano y diríamos que tiene una granularidad más fina, y mientras menos detalle, el grano es más grueso, y por lo tanto la granularidad es más gruesa.

Con frecuencia se recomienda que el grano de las dimensiones en el DWH sea el mismo que tenemos en el transaccional, pero sucede que en ocasiones demasiado detalle implica tablas Facts más grandes, y con eso puede causar que se degrade el tiempo de respuesta del DWH.  Además de esto, los DWHs guardan data histórica de varios años, lo que puede causar que el nivel de detalle se convierta en un problema para el mantenimiento de los mismos, pues tendríamos que decidir entre tener más detalle del transaccional en cada hecho guardado en la tabla Fact vs tener menos años de historia en el DWH.

Por esto al momento de diseñar las dimensiones y decidir el grano de las mismas debemos sopesar que es más importante para nuestro análisis: si el hecho de tener mayor detalle por hecho en la Fact y que se degrade el performance de respuesta del DWH con un nivel de detalle que a lo mejor no es requerido en los análisis de la empresa y que puede estar afectando el tamaño de la BD del DWH, o tener menor detalle que causaría que tuviésemos menos historia dentro del DWH.  Por esto es necesario que antes de diseñar estudiemos detenidamente los requerimientos de los usuarios, y veamos los Reportes y Dashboards que se desean que el DWH ayude a realizar, pues el DWH no está hecho para sustituir los reportes ya existentes en el sistema transaccional sino para complementarlo y responder a las preguntas de alto nivel que se hacen los directivos de la empresa con respecto al desempeño de la misma.

Así que querido lector, la próxima vez que estés diseñando un DWH es importante no solo decidir las dimensiones que participaran del mismo, sino también hay que prestar atención a la granularidad de las mismas, pues esto contribuirá con el éxito de nuestro diseño, adaptándose mejor a los análisis que se harán de los datos y también al mantenimiento de la BD que lo contiene.

En un próximo post hablaremos sobre la granularidad de las tablas Fact.