ZUSAMMENFASSUNG: Ich schlage eine visuelle Table Builder-Schnittstelle vor, die Datenbankauswahl, datenbankinterne Operationen wie Verknüpfen und Filtern, speicherinterne Operationen wie „Tabelle> Verketten“ und „Zeilen> Auswählen, wo ...“ und einige JSL-Operationen wie „Hinzufügen“ ermöglichen würde Eigenschaft, die in einem visuellen Fluss verkettet werden soll. Ich glaube, dieser Ansatz würde bieten ein sehr intuitiver Weg für Personen mit geringer datenwissenschaftlicher Ausbildung zur Automatisierung der Datenvorbereitung und -bereinigung zur einfachen Erfassung von Live-Datenquellen in JMP zur Generierung und Analyse von Erkenntnissen.
EINZELHEITEN: Ich verwende den JMP Query Builder ziemlich häufig, um Datenabfragen aus unserer internen Postgres-Datenbank zu erstellen, und er funktioniert gut als grundlegendes Tool für Datenbankabfragen. Trotzdem kehre ich immer noch zu Python, KNIME oder Raw SQL zurück, um komplexere Arbeitsabläufe zu bewältigen, wie z. B. das Generieren einer Tabelle durch Verbinden zweier Unterabfragen, die selbst das Ergebnis von Verknüpfungen und Transformationen von Basistabellen sind. Letztendlich muss ich aber immer noch eine einfache JMP-Abfrage machen, um die Daten in JMP aus der Datenbank zu bekommen. Darüber hinaus ist der aktuelle Abfragegenerator ziemlich langsam und für Personen, die keine solide Grundlage für Datenbankoperationen haben, nicht sehr intuitiv.
Der Ansatz, den KNIME und Alteryx hier verfolgen, fühlt sich für mich wirklich gut an: ein visueller Fluss, der sich für ein leistungsfähiges mentales Modell von Datenbankoperationen eignet. Jeder Schritt generiert eine neue virtuelle Tabelle (eigentlich eine abstrahierte SQL-Operation), die dann zu größeren Abfragen zusammengesetzt werden kann.
Das Konfigurieren einzelner Schritte in KNIME ist auch viel schneller als im Query Builder, da ich davon ausgehe, dass Prädikatschritte im Speicher bleiben und nur die geänderte Operation auf der In-Memory-Darstellung des vorherigen Schritts ausgeführt werden muss. QB führt stattdessen viele SQL-Abfragen aus (das Deaktivieren der automatischen Vorschau hilft immens, aber Sie verlieren die Vorschaufunktion). Grundsätzlich ist jedes Mal, wenn Sie eine Spalte auswählen oder eine Spalte mit automatischer Vorschau umbenennen, eine Datenbankabfrage und eine Unterbrechung des Flusses.
Ich denke, die Verbesserung des Abfragegenerators würde einen großen Beitrag zur Demokratisierung von Datenoperationen und Datenbanknutzung für Wissenschaftler und Ingenieure leisten. Hier ist, was ich vorschlage:
- Trennen Sie die Tabellenauswahl von Join-Operationen und Filtern/Ordnen
- Dadurch kann der vorhandene Abfragegenerator genutzt werden, als ob eine einzelne Tabelle ausgewählt wurde. Die JMP QB-Methode zum Auswählen und Umbenennen von Spalten ist ziemlich gut!
- Verwenden Sie nach Möglichkeit eine In-Memory-Darstellung eines Tabellenbeispiels (einschließlich aller Spalten und ca. 100-500 Zeilen) für Vorschauvorgänge, um SQL-Abfragen so oft wie möglich zu vermeiden, da IO bei weitem der langsamste Teil der meisten Vorgänge ist.
- Ich schließe Spaltenauswahl, Umbenennung, Gruppieren nach, Aggregationsfunktionen usw. ein.
- Ein mögliches Problem sind absurd breite Tabellen (Bioinformatik kommt mir in den Sinn), daher muss möglicherweise auch eine Spaltenbegrenzung für den In-Memory-Modus vorhanden sein, aber ich bin ziemlich zuversichtlich, dass dies die überwiegende Mehrheit der Anwendungen abdecken würde.
- Erstellen Sie eine visuelle Flussdarstellung zum Zusammenführen, Filtern, Sortieren/Ordnen nach Vorgängen.
- Jede Operation würde, wenn möglich, die In-Memory-Darstellung für eine Vorschau der Ausgabe verwenden.
- Die In-Memory-Darstellung der Quelltabellenbeispiele würde auch die Notwendigkeit beseitigen, Spaltennamen für die Join-Operation abzufragen, ein Schritt, der in JMP erschreckend langsam ist.
- Lassen Sie im Idealfall zu, dass JMP-Tabellenoperationen (Teilen, Stapeln, Verknüpfen, vielleicht sogar Hinzufügen von Spalten mit Formeln, Zeilenauswahl, Zeilen ausblenden und ausschließen usw.) als visuelle Schritte nach der Abfrage aus der Datenbank mit dem Fluss verkettet werden.
- Ich finde, dass viele meiner Kollegen am Ende verschiedene Datenbereinigungs- und Vorbereitungsschritte als Menüoperationen aneinanderreihen, die ich dann brauche, um ihnen bei der Konvertierung in ein Post-Query-Skript zu helfen.
- Das Anhängen von Skripten an die endgültige Datentabelle könnte auch ein visueller Schritt sein, was zu einem bequemen Ablauf einer Reihe von N Schritten für N angehängte Skripte führen würde.
Zumindest aus Sicht der Benutzeroberfläche können die meisten oder alle dieser Elemente vorhandene Benutzeroberflächen in JMP nutzen: Das Konfigurationsfenster für einen JMP-Tabellenverknüpfungsschritt kann buchstäblich dasselbe Format wie die Option „Tabellen > Verketten“ bereits in JMP verwenden.
Mein Idealzustand ist, dass ein Kollege ohne nennenswerte SQL- oder Datenbankschulung leicht mit Tabellenauswahl, Verknüpfung, Filterung und Datenvorbereitung experimentieren könnte, um am Ende einen vollständig automatisierten Workflow zu erhalten, der genau die Tabelle ergibt, die er für seine Visualisierung und Analyse benötigt . Ich denke, der visuelle Flussansatz ist eine hervorragende Möglichkeit, dies zu erleichtern! Dies wäre ein echter Tabellenersteller, der die Funktionen von Datenbankabfragen, datenbankinternen Operationen und speicherinternen Tabellen-, Zeilen-, Spalten- und Skriptoperationen kombiniert, um einen vollautomatischen Datenvorbereitungsworkflow aufzubauen.
Die endgültige Ausgabe wäre eine Art Abfrage-Generator: entweder eine .jmpflow-Datei (oder was auch immer), die für den Table Builder-Flow geöffnet wird, oder ein gespeichertes Skript, das von einem Add-In oder dem Skriptfenster ausgeführt werden kann.
Ich habe ein schlecht gezeichnetes Bild von dem angehängt, was ich denke. Wenn dies das Interesse der Entwickler weckt, können Sie sich gerne per privater Nachricht an mich wenden, wenn Sie sich verbinden möchten, um darüber zu sprechen!
HINWEIS: Zur Formatierung bearbeitet
+1 dafür. Ich glaube, dass wir mit JMP Workflows in 17 auch diese Ansicht haben können.
Hallo @Ryan_Gilmore , klingt super – könntest du diesen Wunsch bitte wieder öffnen?
Immer noch wichtig, lasst uns das bitte noch einmal öffnen.
Der Vollständigkeit halber sei erwähnt, dass ich diesen Vorschlag auch weiterhin für relevant halte. Ein visueller Ablaufansatz ist eine flexible Möglichkeit, ETL-Prozesse zu handhaben und wird nicht durch Workflows ersetzt, bei denen es sich praktisch um jeden Schritt als Funktion handelt, die der Reihe nach aufgerufen wird.
