Guía para la minería de datos económica

A diferencia de la programación de aplicaciones tradicional, donde las funciones de la API cambian todos los días, la programación de bases de datos básicamente sigue siendo la misma. La primera versión de Microsoft Visual Studio .NET se lanzó en febrero de 2002, con una nueva versión aproximadamente cada dos años, sin incluir las versiones de Service Pack. Este rápido ritmo de cambio obliga al personal de TI a evaluar las aplicaciones de su corporación cada dos años, dejando intacta la funcionalidad de su aplicación pero con un código fuente completamente diferente para mantenerse al día con las últimas técnicas y tecnología.

No se puede decir lo mismo sobre el código fuente de su base de datos. Una consulta estándar de SELECT / FROM / WHERE / GROUP BY , escrita en los primeros días de SQL, todavía funciona hoy. Por supuesto, esto no significa que no haya habido avances en la programación de bases de datos relacionales; las hubo, y han sido más lógicas que técnicas .

Desde los días en que Bill Inmon y Ralph Kimball publicaron sus teorías sobre el diseño de almacenes de datos, los avances en la programación de bases de datos se han centrado en evitar la pérdida de información valiosa y extraer toda la información valiosa de los datos. Una vez que Inmon y Kimball introdujeron el mundo de las bases de datos en el almacenamiento de datos, se realizaron cambios importantes en las herramientas ETL (Extraer/Transformar/Cargar) que brindaron a los desarrolladores de bases de datos un fácil acceso a metadatos y datos de fuentes de bases de datos no relacionales, con las que era difícil trabajar. en el pasado. Esto aumentó la cantidad de datos disponibles de los cuales extraer información valiosa, y este aumento en los datos disponibles condujo a avances en el procesamiento de datos a través de cubos OLAP y algoritmos de minería de datos.

Agregar un almacén de datos, cubos OLAP y algoritmos de minería de datos a la arquitectura de su base de datos puede agilizar drásticamente los procesos comerciales e iluminar patrones en sus datos que, de otro modo, nunca hubiera sabido que existían. La automatización también puede tener un profundo impacto en las capacidades de inteligencia empresarial.

Sin embargo, antes de comenzar a agregar nuevas herramientas y tecnologías, debe asegurarse de que la base de datos de transacciones esté construida correctamente.

Base de datos de transacciones

La base de datos de transacciones es la base, y si su base de datos de transacciones no es confiable y precisa, agregar algo encima es una receta para el desastre.

Un punto importante a tener en cuenta al agregar capas adicionales a su base de datos es que todos los proyectos deben mostrar un retorno de la inversión , por lo que es mejor aprovechar al máximo su arquitectura actual antes de agregar más capas. Todas estas capas utilizan datos que se originan en una base de datos de transacciones. En muchas situaciones, puede obtener el mismo resultado simplemente consultando su base de datos de transacciones. Por supuesto, hacer que todos sus informes se lean desde un almacén de datos o un cubo OLAP es el método ideal, pero cuando una organización no está preparada para ese nivel de complejidad, es más importante que primero se satisfagan sus necesidades de generación de informes. Una vez que se satisfacen las necesidades básicas de generación de informes, es mucho más fácil comenzar una discusión sobre cómo un almacén de datos adecuado y, posiblemente, un cubo OLAP, pueden beneficiar a su negocio.

Casi todos los programadores conocen las tres reglas de la normalización de bases de datos. Los procedimientos almacenados que se leen de la base de datos de transacciones son el camino hacia la optimización. Los problemas a buscar son la legibilidad, múltiples llamadas a la misma tabla de base de datos y el uso innecesario de variables.

Todos los programadores de bases de datos de élite son exigentes con la legibilidad de sus procedimientos almacenados. Hay algunos puntos en común en la forma en que los profesionales de bases de datos dan formato a sus consultas, que es diferente de un desarrollador de aplicaciones. Por lo general, las palabras clave y las funciones agregadas están en mayúsculas, mientras que los nombres de tablas y campos usan mayúsculas y minúsculas o guiones bajos. Los alias de tabla tienen cierta correlación con el nombre real de la tabla. La alineación de las secciones del procedimiento almacenado tiene algún tipo de patrón de bloque.

A continuación se muestra un ejemplo de una consulta que utiliza un formato legible.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

Lo siguiente que debe buscar es si una consulta llega a una tabla más de una vez. En la mayoría de las consultas, solo se necesita acceder a una tabla una vez, excepto en las raras ocasiones en que necesita agregar otra función agregada. Este es otro error que cometen algunos programadores de aplicaciones, quizás porque un programador de aplicaciones piensa en términos de diseño orientado a objetos.

El diseño orientado a objetos crea objetos separados para cada elemento de datos único, pero un programador de bases de datos necesita pensar en términos de lógica establecida. El hecho de que una consulta acceda a una tabla más veces de las necesarias no significa que la consulta esté produciendo datos inexactos, sin embargo, el rendimiento de la consulta se ve afectado.

Otra preocupación son los registros descartados o duplicados cada vez que se une, lo que compromete la precisión de su consulta. El uso innecesario de variables es otra señal de que un desarrollador de aplicaciones desarrolló una consulta. Los desarrolladores de aplicaciones usan variables en todo su código, mientras que una consulta rara vez necesita usar variables, excepto cuando se declara como un parámetro para el procedimiento almacenado. Una vez más, es una señal de que el desarrollador no estaba pensando en los términos de la lógica establecida.

ETL (carga de transformación de extracción) e informes

Una vez que la base de datos de transacciones de un cliente tiene consultas que funcionan correctamente, el siguiente paso es optimizar los procesos comerciales.

La forma más fácil de identificar la necesidad de una empresa de procesos ETL o informes automatizados es averiguar quién está leyendo datos de una base de datos de transacciones y luego manipulando los datos mediante una hoja de cálculo. Una hoja de cálculo tiene la misma estructura que una tabla de base de datos. Ambos contienen filas y columnas. Si tiene usuarios finales que manipulan datos por su cuenta, debe preguntarse: "¿Por qué no se puede automatizar ese proceso?"

La automatización de los procesos comerciales proporciona un retorno inmediato de la inversión y siempre debe tenerse en cuenta antes de pasar a proyectos más costosos, como el almacenamiento de datos. Identificar a los usuarios finales que manipulan datos a través de una hoja de cálculo puede parecer simple, pero hay una advertencia en este proceso.

A los desarrolladores les gusta automatizar procesos; es lo que hacen. A los usuarios finales no necesariamente les gustan los procesos automatizados, especialmente si amenazan su trabajo. Por lo tanto, no sea ingenuo y piense que los usuarios finales se acercarán a usted e identificarán las tareas diarias que se pueden automatizar. Realmente necesita tomar la iniciativa en la identificación de oportunidades de optimización.

Un sistema ETL bien construido también debe proporcionar la capacidad de rastrear todos los datos cargados en una base de datos de transacciones hasta el archivo de origen original. Esta es una pieza crítica de la arquitectura de la base de datos. Si no sabe la fecha/hora exacta de cuando se agregó cada registro, junto con el nombre de la fuente (nombre de usuario o nombre de archivo) que agregó los registros, entonces no está preparado para manejar datos incorrectos cargados en su base de datos de transacciones. Debería preguntarse: "¿Qué pasa si alguien nos envía un archivo incorrecto?" ¿Cuánto tiempo le llevaría identificar los registros que provinieron de él?

Almacén de datos

Hay dos teorías para el diseño del almacén de datos. La diferencia entre las teorías de Inmon y Kimball se puede resumir de la siguiente manera:

La teoría de Inmon es desarrollar primero un almacén de datos y luego construir mercados de datos dimensionales para generar informes desde el almacén de datos. La teoría de Kimball es desarrollar primero mercados de datos dimensionales para informes y luego fusionarlos para crear el almacén de datos.

Siempre desea proporcionar a los clientes el retorno de la inversión más rápido. Construir data marts es un proceso simple. Comienza tomando las consultas detrás de sus informes y cámbielas de devolver conjuntos de resultados a almacenar los conjuntos de resultados en tablas permanentes. Simplemente agrega TRUNCATE TABLE tablename ; INSERT INTO tablename antes de la palabra clave SELECT original. Una vez que tenga algunas tablas funcionales de data marts, la identificación de oportunidades para fusionar los data marts debería estar en su lugar; busque consultas de informes que usen la misma lista de tablas y luego combine la lista de campos. Esto requiere una consulta más complicada, especialmente cuando aumenta la lista de tablas. Sin embargo, siempre que pruebe la consulta a fondo, cada cambio incremental se puede realizar sin interrumpir los procesos comerciales normales.

Cada vez que realiza una mejora en el diseño de un almacén de datos de Kimball, tiene la oportunidad de mostrar un ROI al cliente. Esto se debe a que el almacén de datos se crea primero y los data marts de informes se crean a partir de un almacén de datos estáticos. Por lo tanto, usted incurre en la mayoría de sus costos al principio del proyecto de almacenamiento de datos.

Cubo OLAP

Un cubo OLAP puede beneficiar a una organización al proporcionar datos agregados con un tiempo de respuesta rápido, capacidades de profundización ad-hoc para usuarios finales y extracción de datos. Cuando tiene un cubo OLAP adecuado, puede extraer todo el valor de sus datos. Un cubo OLAP se crea sobre un almacén de datos, pero utiliza un lenguaje diferente, MDX, que una base de datos SQL estándar. También requiere un esfuerzo de configuración más complicado que un servidor de base de datos. Esa complejidad hace que un proyecto OLAP sea costoso, además de que es difícil encontrar desarrolladores MDX experimentados.

Los arquitectos de datos a veces ven cubos OLAP existentes con nada más que un tablero simple que utiliza el cubo, sin un solo proceso que no pueda ser reemplazado por una consulta SQL, un almacén de datos o un informe enlatado. Un cubo OLAP puede proporcionar un tiempo de respuesta más rápido que un informe enlatado, pero en la mayoría de las situaciones la diferencia es insignificante. También puede beneficiarse de las capacidades de desglose; sin embargo, antes de proporcionar capacidades de desglose a los usuarios finales, es una buena idea utilizar informes enlatados que proporcionen una interfaz ad hoc similar.

Esto le permite registrar las consultas ad hoc que ejecutan los usuarios finales, luego puede identificar nuevos informes enlatados que los usuarios finales no sabían que se podían crear. Dado que tanto el tiempo de respuesta como las mejoras en profundidad suelen ser mínimos cuando se desarrolla un cubo OLAP, no es necesario sugerírselo a un cliente hasta que necesite una arquitectura de base de datos que pueda manejar la minería de datos involucrada. Aquí es cuando realmente puede impresionar a los clientes y mostrarles algo sobre su negocio que quizás nunca hubieran conocido sin una arquitectura de base de datos sólida.

Como se mencionó anteriormente, construir un cubo OLAP puede ser un desafío. Es una buena política considerar un cubo OLAP híbrido. PowerPivot de Microsoft Excel proporciona herramientas de minería de datos fáciles de usar sin la complejidad de un cubo OLAP completo. La principal desventaja de un híbrido es que no tiene el mismo tiempo de respuesta. Sin embargo, una gran ventaja es que es más fácil crear informes de minería de datos con Excel que con MDX. Cuando se realiza minería de datos, hay tres informes que son útiles. Podemos ver algunos ejemplos del mundo real y cómo interpretarlos.

Todos estos informes provienen de una aplicación de transacciones diarias automatizada construida por el autor.

Informes visuales

Informe de gráfico de dispersión

Un informe de diagrama de dispersión es un informe de nivel de detalle que compara dos variables. Agregar color y tamaño a los puntos reales ayuda a visualizar los resultados reales en relación con esas variables.

Informe Caja y Bigotes

Este informe resume los valores x e y del informe de diagrama de dispersión. Los valores del eje x se discretizan en un conjunto de cubos.

Los extremos de cada bigote (línea) representan los valores atípicos. Las barras amarillas y azul claro representan los rangos de desviación estándar superior e inferior.

Modelo de regresión lineal

Este informe muestra la correlación entre los valores de los ejes x e y, junto con un suavizado de la línea, que se puede representar mediante una fórmula matemática. El valor R cuadrado se incluye para mostrar qué tan confiable es la correlación.

Conclusión

A medida que crece su empresa, normalmente su base de datos también crecerá.

La mayoría de las organizaciones no necesitan inicialmente un profesional de bases de datos o una empresa dedicada a la ciencia de datos que maneje sus necesidades. En cambio, hacen que su personal de TI maneje múltiples responsabilidades o, como dice el refrán, "usar muchos sombreros". Esto funciona hasta cierto punto, pero eventualmente, necesita traer especialistas.

Los elementos enumerados en este documento son una manera rápida y fácil de identificar problemas de la base de datos de los que quizás no haya tenido conocimiento. Con suerte, también cubrió cómo puede crear herramientas de minería de datos de primer nivel sin gastar mucho en costosas licencias de software. De esta forma, obtendrá una mejor idea de cuánto podría beneficiarse su organización al agregar un profesional de bases de datos a su personal de TI.