RIEPILOGO: Propongo un'interfaccia visiva di Table Builder che consentirebbe la selezione del database, operazioni nel database come l'unione e il filtraggio, operazioni in memoria come "Tabella> Concatena" e "Righe> Seleziona dove..." e alcune operazioni JSL come Aggiungi Proprietà da concatenare in un flusso visivo. Credo che questo approccio fornirebbe un modo molto intuitivo per le persone con poca formazione sulla scienza dei dati per automatizzare la preparazione e la pulizia dei dati per acquisire facilmente origini dati in tempo reale in JMP per la generazione e l'analisi di informazioni dettagliate.
PARTICOLARI: Mi ritrovo a usare parecchio JMP Query Builder per creare query di dati dal nostro database Postgres interno e funziona bene come strumento di query di database di base. Detto questo, mi ritrovo ancora a tornare a Python, KNIME o SQL grezzo per affrontare flussi di lavoro più complessi, come la generazione di una tabella unendo due sottoquery, esse stesse il risultato di join e trasformazioni su tabelle di base. In definitiva, però, devo ancora eseguire una semplice query JMP per ottenere i dati in JMP dal database. Inoltre, l'attuale generatore di query è piuttosto lento e non molto intuitivo per le persone che non hanno solide basi nelle operazioni di database.
L'approccio adottato da KNIME e Alteryx qui mi sembra davvero buono: un flusso visivo che si presta a un potente modello mentale delle operazioni di database. Ogni passaggio genera una nuova tabella virtuale (in realtà un'operazione SQL astratta) che può quindi essere assemblata in query più grandi.
La configurazione dei singoli passaggi in KNIME è anche molto più veloce rispetto a Query Builder, presumo perché i passaggi del predicato rimangono in memoria e solo l'operazione modificata deve essere eseguita sulla rappresentazione in memoria del passaggio precedente. QB invece esegue molte query SQL (la disattivazione delle anteprime automatiche aiuta immensamente ma perdi la funzionalità di anteprima). Fondamentalmente ogni volta che si seleziona una colonna o si rinomina una colonna con l'anteprima automatica attiva si verifica una query del database e un'interruzione del flusso.
Penso che il miglioramento di Query Builder farebbe molto per democratizzare le operazioni sui dati e l'utilizzo del database per scienziati e ingegneri. Ecco cosa propongo:
- Separare la selezione della tabella dalle operazioni di unione e dal filtraggio/ordinamento
- Questo può sfruttare il generatore di query esistente, come se fosse stata selezionata una singola tabella. Il modo in cui JMP QB seleziona e rinomina le colonne è piuttosto buono!
- Ove possibile, utilizzare una rappresentazione in memoria di un esempio di tabella (incluse tutte le colonne e circa 100-500 righe) per le operazioni di anteprima per evitare query SQL il più spesso possibile, poiché l'IO è di gran lunga la parte più lenta della maggior parte delle operazioni.
- Includo la selezione delle colonne, la ridenominazione, il raggruppamento, le funzioni di aggregazione, ecc.
- Una possibile preoccupazione sono le tabelle assurdamente ampie (mi viene in mente la bioinformatica), quindi potrebbe essere necessario un limite di colonna anche per la modalità in memoria, ma sono abbastanza sicuro che coprirebbe la stragrande maggioranza degli usi.
- Crea una rappresentazione visiva del flusso per unire, filtrare, ordinare/ordinare per operazioni.
- Ogni operazione utilizzerà la rappresentazione in memoria per l'anteprima dell'output, se possibile.
- La rappresentazione in memoria degli esempi della tabella di origine eliminerebbe anche la necessità di interrogare i nomi delle colonne per l'operazione di unione, un passaggio incredibilmente lento in JMP.
- Idealmente, consentire alle operazioni di tabella JMP (divisione, stack, concat, forse anche aggiunta di colonne con formule, selezione di righe, nascondi ed escludi righe, ecc.) Da concatenare al flusso come passaggi visivi dopo la query dal database.
- Trovo che molti dei miei colleghi finiscano per mettere insieme vari passaggi di pulizia e preparazione dei dati come operazioni di menu di cui ho quindi bisogno per convertire in uno script post-query per loro.
- Allegare script alla tabella di dati finale potrebbe anche essere un passaggio visivo, che renderebbe un flusso conveniente avere una serie di N passaggi per N script allegati.
Almeno dal punto di vista dell'interfaccia utente, la maggior parte o tutte queste parti possono sfruttare le interfacce utente esistenti in JMP: il pannello di configurazione per un passaggio JMP Table Concatenate può letteralmente utilizzare lo stesso formato dell'opzione Tabelle>Concatena già in JMP.
Il mio stato ideale è che un collega senza una formazione significativa su SQL o database potrebbe facilmente sperimentare la selezione delle tabelle, l'unione, il filtraggio e la preparazione dei dati per ottenere un flusso di lavoro completamente automatizzato che si traduce esattamente nella tabella di cui hanno bisogno per eseguire la visualizzazione e l'analisi . Penso che l'approccio del flusso visivo sia un modo eccellente per facilitarlo! Si tratterebbe di un vero generatore di tabelle, che combina le funzionalità di query del database, operazioni nel database e operazioni su tabelle, righe, colonne e script in memoria per creare un flusso di lavoro di preparazione dei dati completamente automatico.
L'output finale sarebbe una specie di generatore di query: un file .jmpflow (o qualsiasi altra cosa) che si aprirà al flusso di Table Builder o uno script salvato che può essere eseguito da un componente aggiuntivo o dalla finestra di script.
Ho allegato un'immagine mal disegnata di quello che sto pensando. Se questo suscita l'interesse degli sviluppatori, non esitare a contattarmi tramite messaggio privato se desideri connetterti per parlarne!
NOTA: modificato per la formattazione
