RESUMEN: Propongo una interfaz visual de Table Builder que permitiría la selección de bases de datos, operaciones en la base de datos como unir y filtrar, operaciones en memoria como "Tabla>Concatenar" y "Filas> Seleccionar dónde...", y algunas operaciones JSL como Agregar Propiedad de ser encadenado en un flujo visual. Creo que este enfoque proporcionaría una manera muy intuitiva para personas con poca capacitación en ciencia de datos para automatizar la preparación y limpieza de datos para capturar fácilmente fuentes de datos en vivo en JMP para generar y analizar información.
DETALLES: Me encuentro usando JMP Query Builder bastante para crear consultas de datos desde nuestra base de datos interna de Postgres, y funciona bien como una herramienta básica de consulta de bases de datos. Dicho esto, sigo volviendo a Python, KNIME o SQL sin procesar para abordar flujos de trabajo más complejos, como generar una tabla uniendo dos subconsultas, que son el resultado de uniones y transformaciones en tablas base. Sin embargo, en última instancia, todavía tengo que hacer una consulta JMP simple para obtener los datos en JMP de la base de datos. Además, el generador de consultas actual es bastante lento y no muy intuitivo para las personas que no tienen una base sólida en las operaciones de la base de datos.
El enfoque adoptado por KNIME y Alteryx aquí me parece realmente bueno: un flujo visual que se presta a un poderoso modelo mental de las operaciones de la base de datos. Cada paso genera una nueva tabla virtual (realmente una operación de SQL abstracta) que luego se puede unir en consultas más grandes.
Configurar pasos individuales en KNIME también es mucho más rápido que en Query Builder, supongo porque los pasos predicados permanecen en la memoria y solo la operación modificada debe ejecutarse en la representación en memoria del paso anterior. En cambio, QB ejecuta muchas consultas SQL (desactivar las vistas previas automáticas ayuda enormemente, pero pierde la funcionalidad de vista previa). Básicamente, cada vez que selecciona una columna o cambia el nombre de una columna con la vista previa automática activada, se trata de una consulta a la base de datos y una interrupción en el flujo.
Creo que mejorar Query Builder contribuiría en gran medida a democratizar las operaciones de datos y el uso de bases de datos para científicos e ingenieros. Esto es lo que estoy proponiendo:
- Separe la selección de tablas de las operaciones de combinación y filtrado/ordenación
- Esto puede aprovechar el generador de consultas existente, como si se seleccionara una sola tabla. ¡La forma JMP QB de seleccionar y cambiar el nombre de las columnas es bastante buena!
- Siempre que sea posible, use una representación en memoria de una muestra de tabla (incluidas todas las columnas y ~100-500 filas) para las operaciones de vista previa para evitar las consultas SQL con la mayor frecuencia posible, ya que IO es, con mucho, la parte más lenta de la mayoría de las operaciones.
- Incluyo selección de columnas, cambio de nombre, agrupar por, funciones de agregación, etc. en esto.
- Una posible preocupación son las tablas absurdamente anchas (me viene a la mente la bioinformática), por lo que es posible que también deba haber un límite de columna para el modo en memoria, pero estoy bastante seguro de que cubriría la gran mayoría de los usos.
- Cree una representación de flujo visual para unir, filtrar, clasificar/ordenar por operaciones.
- Cada operación usaría la representación en memoria para obtener una vista previa de la salida, si es posible.
- La representación en memoria de las muestras de la tabla de origen también eliminaría la necesidad de consultar los nombres de las columnas para la operación de combinación, un paso que es sorprendentemente lento en JMP.
- Idealmente, permita que las operaciones de la tabla JMP (dividir, apilar, concatenar, tal vez incluso la adición de columnas con fórmulas, selección de filas, ocultar y excluir filas, etc.) se encadenen al flujo como pasos visuales después de la consulta desde la base de datos.
- Encuentro que muchos de mis colegas terminan encadenando varios pasos de limpieza y preparación de datos como operaciones de menú que luego necesito ayudar a convertir en un script posterior a la consulta para ellos.
- Adjuntar secuencias de comandos a la tabla de datos final también podría ser un paso visual, lo que facilitaría el flujo de tener una serie de N pasos para N secuencias de comandos adjuntas.
Al menos desde el punto de vista de la interfaz de usuario, la mayoría o todas estas piezas pueden aprovechar las interfaces de usuario existentes en JMP: el panel de configuración para un paso de concatenación de tablas de JMP puede usar literalmente el mismo formato que la opción Tables>Concatenate en JMP.
Mi estado ideal es que un colega sin una formación significativa en bases de datos o SQL pueda experimentar fácilmente con la selección de tablas, la combinación, el filtrado y la preparación de datos para terminar con un flujo de trabajo completamente automatizado que dé como resultado exactamente la tabla que necesita para realizar su visualización y análisis. . ¡Creo que el enfoque de flujo visual es una excelente manera de facilitar eso! Este sería un verdadero generador de tablas, que combinaría las funciones de consulta de base de datos, operaciones en la base de datos y operaciones de script, fila, columna y tabla en memoria para crear un flujo de trabajo de preparación de datos completamente automático.
El resultado final sería una especie de generador de consultas: un archivo .jmpflow (o lo que sea) que se abrirá en el flujo de Table Builder o una secuencia de comandos guardada que se puede ejecutar desde un complemento o la ventana de la secuencia de comandos.
Adjunto una imagen mal dibujada de lo que estoy pensando. Si esto despierta el interés de los desarrolladores, no dude en comunicarse conmigo a través de un mensaje privado si desea conectarse para hablar sobre esto.
NOTA: Editado para formatear
