Fases de un proyecto de Minería de datos

Dentro de un proyecto de Data Mining podemos diferenciar las siguientes fases:

1. Identificación y definición del objetivo de negocio a resolver. Muy importante. La minería de datos no es un fin en si mismo, sin objetivos de negocio no hay proyecto.
2. Identificación de las fuentes de datos para soportar la resolución de los objetivos y análisis preliminar de la calidad de los datos. Si no tenemos unos datos con la calidad requerida y el formato necesario, nuestro proyecto será un fracaso. Creo que muchas veces se subestima este punto...
3. Preparación y acondicionamiento de los datos. Una fase crucial, que ocupa un tanto por ciento importante del tiempo del proyecto. Con preparación y acondicionamiento estamos hablando de las estructuras que alimentaran la construcción del modelo. Por ejemplo, si queremos hacer una segmentación de clientes, para ello necesito preparar los datos en formato tabla de clientes, donde cada registro es un cliente con los atributos de modelización en columnas.
4. Modelización de datos. Aplicando las técnicas de minería de datos, obtenemos el mejor modelo predictivo posible para nuestros objetivos.
5. Análisis de resultados. Una vez obtenido el modelo, se debe proceder a su validación comprobando que las conclusiones que arroja son válidas y suficientemente satisfactorias. En el caso de haber obtenido varios modelos mediante el uso de distintas técnicas, se deben comparar los modelos en busca de aquel que se ajuste mejor al problema. Si ninguno de los modelos alcanza los resultados esperados, debe alterarse alguno de los pasos anteriores para generar nuevos modelos.
   
6. Conclusiones. ¿Se han cumplido las expectativas y los objetivos?
7. Puesta en producción. No nos podemos quedar con unos simples informes de consultoría o una serie de recomendaciones. Si cogemos los modelos generados y los ponemos en producción de forma efectiva estaremos aprovechando el principal beneficio del Data Mining.
   

Técnicas de Minería de datos

• Clustering. Consiste en definir grupos lo más parecido posible y a su vez lo más distinto posible a otros grupos (o clusters). Ejemplo: clientes más rentables, clientes menos rentables.

• Segmentación. Consiste en la división de la totalidad de los datos, segun determinados criterios. Ejemplo: Dividir los clientes en función de su antiguedad.

• Clasificación. Consiste en definir una serie de clases, donde poder agrupar los diferentes clientes. Ejemplo: definida unas variables de entrada se produce una determinada salida que clasifica al cliente en un grupo o en otro. Por ejemplo, si la edad esta entre 20 y 40, esta casado y tiene cuenta de ahorro, entonces contrata hipoteca en un 78% de posibilidades.

• Predicción. Consiste en intentar conocer resultados futuros a partir de modelizar los datos actuales. Ejemplo: Creamos un modelo de variables para saber si el cliente compra o no compra. Aplicamos el modelo a un futuro cliente, y ya podemos predecir si comprará o no.

No se trata de escoger una técnica o otra... mi mucho menos. Cada cosa para lo que está concebida. La minería de datos es, prácticamente, el único proceso analítico que genera nueva información en la capa de acceso. Toda esta información debe ser reintroducida en el entorno para su posterior análisis.

Minería de datos

Muy interesante este apartado del temario... que creo dará para unos cuantos posts. De entrada me quedo con una definición:

Se denomina Minería de datos al conjunto de metodologías, técnicas de modelización matemática y mecanismos de visualización, cuyo objetivo es la extracción de tendencias, patrones y comportamientos subyacentes en grandes volúmenes de datos, y no detectables mediante técnicas de consulta convencionales, con el fin de soportar la toma de decisiones de negocio

Me quedaría con la frase de que un gran numero de analistas y responsables de DWH piensan que hacen minería de datos simplemente porque sus sistemas son muy grandes en cuanto a datos y soportan consultas muy pesadas.

Esquema en estrella

El esquema en estrella es la representación más importante del modelo dimensional. En el modelo dimensional encontramos hechos y dimensiones.
Todo objeto de análisis es un hecho. Este hecho se representa en el modelo dimensional en forma de tabla de hechos o fact table. Los hechos son analizados a su vez, a través de las dimensiones o componentes (tantas como dimensiones participen en la descripción del hecho), que se representan en el modelo dimensional a partir de las tablas de dimensiones.

Si realizamos este esquema mental (tabla de hechos en el centro y tablas de dimensiones alrededor), todo parece dibujar una forma de estrella, origen del nombre.

Los hechos tienen columnas de datos denominadas métricas y las dimensiones tienen columnas que representan los niveles de jerarquías.

Un ejemplo: Tenemos un hecho archifamoso: ventas. Y sus dimensiones: Tiempo, localización y producto. Alguna métrica de ventas seria número de unidades vendidas y valor de la venta. En cuanto a los niveles de jerarquía de las dimensiones encontraríamos día, semana y mes (para el tiempo), almacén, población, provincia (para la localización), producto, familia, departamento (para los productos). Creo que así queda más claro:

Para acabar, decir que las métricas son indicadores que nos permiten cuantificar los hechos y siempre hay que intentar buscar estas métricas que sean aditivas. Una métrica es aditiva cuando es sumarizable por todas sus dimensiones. Otro ejemplo: Una fabrica tiene 50 unidades en el almacén en Enero. En Febrero tiene 30 y en Marzo 10. Esta métrica no es sumarizable, ya que 50+30+10 no da el inventario final del trimestre. Esto suele pasar bastante con la dimensión TIEMPO.

Metadatos

Los metadatos de un DWH están formados por aquellas tablas, campos y registros que mantienen información sobre los datos del propio DWH. En las bases de datos operacionales también existen estos tipos de datos, pero están ocultos de cara al usuario, así que la gran diferencia con los DWH esta en que en estos se pueden ver y se puede interaccionar con ellos. Existen herramientas en el mercado que hacen una gestión automática de los mismos a través de los diferentes procesos ejecutas, pero también se puede realizar mantenimientos manuales.

Los metadatos como tal, contienen información como la procedencia de la información, la periodicidad de refresco, su fiabilidad, forma de cálculo, etc. y una cosa importante, si los datos cambian, los metadatos tienen que cambiar con ellos.

Además los sistemas BI almacenan en ellos información vital como las relaciones de negocio que se establecen entre atributos (jerarquías), operaciones de agrupación a realizar con los diferentes indicadores definidos, etc.

Los objetivos que deben cumplir los metadatos, según el colectivo al que va dirigido, serían:

- Soportar al usuario final, ayudándole a acceder al Data Warehouse con su propio lenguaje de negocio, indicando qué información hay y qué significado tiene. Ayudar a construir consultas, informes y análisis, mediante herramientas de navegación.

- Soportar a los responsables técnicos del Data Warehouse en aspectos de auditoria, gestión de la información histórica, administración del Data Warehouse, elaboración de programas de extracción de la información, especificación de las interfaces para la realimentación a los sistemas operacionales de los resultados obtenidos, etc..

Data Warehouse: ¿Alguien habló de redundancia de datos?

Dicen que hay un mito de que tener y mantener un DWH es mantener repositorio con datos duplicados, ya que estos se extraen de las Bases de datos operacionales.
Evidentemente el origen de estos datos es ciertamente uno que ya poseemos, pero podríamos decir que para nada encontramos una relación directa entre estos datos y los de la BD operacional. Un dato cuando pasa un DWH sufre alteraciones como:

• Normalización
• Depuración
• Creación de metadatos asociado
• Sello de tiempo
• Postproceso para integrarlo como dato agregado, resumido o calculado.

Entonces, ¿podemos hablar del mismo dato? Difícilmente vamos a entender que es el mismo.
Además en los DWH no se cargan todos los datos de la BD operacionales, solo aquellos que se consideran necesarios para el proceso de apoyo a la toma de decisiones.

Otro punto importante a tener en cuenta es, que en el espacio histórico (años), las BD operaciones y el DWH solo comparten un tiempo (meses) relativamente pequeño.
Evidentemente se puede asumir que el mantenimiento del DWH tiene un coste y que los datos ya los teníamos en las otras BD…. pero el resultado final, tanto en informes como en análisis deja libre de toda duda de que los datos del DWH no pueden entenderse como una simple réplica.

Data Warehouse en profundidad

Empieza el primer tema hablando de los Data Warehouses, los almacenes de datos.
Los sistemas tradicionales empezaron a tener problemas para satisfacer las necesidades de los usuarios y de esta problematica, surgen los Data Warehouse como sistemas de apoyo a la toma de decisiones, en que los datos de una organización se transforman en información estratégica. Ayudan a su vez a disponer de un acceso sencillo e inmediato a determinada información de negocio estructurada y de calidad.

Acceder a los datos directamente en sistemas operacionales (del dia a dia, no DWH) suponía algunos problemas:

• Conocer lenguajes como SQL
• Rendimiento
• Los datos no están preparados para las consultas necesarias.
• No suelen tener un horizonte histórico como para detectar tendencias o realizar seguimientos.

Data Warehousing versus Data Warehouse
Data Warehousing es el proceso de crear y mantener un almacén central de datos, es decir un Data Warehouse.

Características de un DWH

• Orientado a temas: en contra de la orientación a procesos de los sistemas operacionales, facilitando su acceso y entendimiento.
• Integrado: Los datos de un DWH son íntegros en unidades de medida, nombres, codificación, etc...
• Variante en el tiempo: Se guardan datos históricos (del orden de años) que facilitan la evaluación e identificación de tendencias.
• No volátil: Los valores permanecen en el DWH sin modificación.

Diferencias entre un DWH y una BD Operacional
La principal diferencia entre un Data Warehouse y una BD operacional es su objetivo, el primero esta orientado a las operaciones del día a día y el segundo al análisis y la toma de decisiones. Por tanto podemos preveer que uno recibe multitud de transacciones repetitivas y conocidas y el DWH consultas masivas, puntuales y no conocidas. También como diferencia encontramos el rendimiento, la volatilidad, los usuarios (más expertos), estructura (relacional versus multidimensional), alcance histórico, detalle de los datos y por último el volumen, mucho mayor en un DWH.

Arquitectura de un DWH
Cuando hablamos de la arquitectura, nos referimos a la manera de representar la estructura global de los datos, los procesos y las interfaces de usuario. Las bases de esta arquitectura son:

• Mezclar los datos de la BD operacional con otras fuentes de datos, incluidas las externas.
• Información fácil y transparente
• Proveer al usuario de un acceso universal a los datos (apoyado en lenguaje SQL)
• Metadatos: De donde proviene un dato, que formato tenía, significado, como se ha calculado, etc...
• Construir y mantener el directorio de datos.
• Gestión de copia y de replicación: todos los procesos necesarios para asegurar la calidad de los datos.

Estructura del DWH
¿Qué nivel de detalle tienen los datos? Normalmente difiere de los sistemas de producción por contener agregaciones y por guardar al detalle los datos de otros años.
Dentro del DWH también encontramos los famosos Metadatos, que los podríamos definir como un directorio para ayudar a ubicar los contenidos, una guía de donde provienen los datos y una descripción de los algoritmos utilizados para calcular las agregaciones pertinentes.

Data Mart
Un Data Mart cumple los mismos principios que un Data Warehouse, pero difiere principalmente en el alcance del mismo, que seria de un departamento o grupo de personas y no de toda la organización. De Data Marts podemos encontrar de dos tipos: dependientes e independientes según si los datos son extraidos del DWH o directamente de los sistemas operacionales (a la larga un desastre).

Explotar un Data Warehouse
El reto es sacar datos y convertirlo en información, que se dice pronto... y encima querer crear una ventaja empresarial. Este reto va des de la edición de informes hasta una minería de datos avanzada, con análisis multidimensional. Por tanto, un DWH es un medio, no un fin en si mismo. Ningún proyecto debería tener como finalidad construir un DWH, sino obtener información... si bien, cabe decir que el construirlo debe suponer una gran meta.
Para la explotación encontramos tres técnicas principalmente: Query and reporting, OLAP (análisis multidimensional) y Minería de datos . La primera consiste en realizar informes y generar consultas flexibles, con una interfaz gráfica, permitiendo también escribir total o parcialmente la consula en SQL (o similar). La segunda (OLAP) consiste en realizar análisis desde un conjunto de perspectivas o dimensiones. Muy adecuada para grandes volúmenes de datos.
La tercera consiste en el descubrimiento de conocimiento no accesible de manera directa... si no que se encuentra oculto, por ejemplo, buscar patrones de información en los datos.