RÉSUMÉ: Je propose une interface visuelle Table Builder qui permettrait la sélection de base de données, des opérations dans la base de données telles que la jointure et le filtrage, des opérations en mémoire comme "Table> Concatenate" et "Rows> Select Where...", et certaines opérations JSL comme Add Propriété à enchaîner dans un flux visuel. Je crois que cette approche fournirait une manière très intuitive pour les personnes ayant peu de formation en science des données pour automatiser la préparation et le nettoyage des données afin de capturer facilement des sources de données en direct dans JMP pour la génération et l'analyse d'informations.
DÉTAILS: J'utilise beaucoup JMP Query Builder pour créer des requêtes de données à partir de notre base de données Postgres interne, et cela fonctionne bien comme outil de requête de base de données de base. Cela dit, je me retrouve toujours à revenir à Python, KNIME ou SQL brut pour traiter des workflows plus complexes, comme générer une table en joignant deux sous-requêtes, elles-mêmes le résultat de jointures et de transformations sur des tables de base. En fin de compte, je dois encore faire une simple requête JMP pour obtenir les données dans JMP à partir de la base de données. De plus, le générateur de requêtes actuel est plutôt lent et peu intuitif pour les personnes qui n'ont pas de bases solides dans les opérations de base de données.
L'approche adoptée par KNIME et Alteryx ici me fait vraiment du bien : un flux visuel qui se prête à un puissant modèle mental d'opérations de base de données. Chaque étape génère une nouvelle table virtuelle (en réalité une opération SQL abstraite) qui peut ensuite être reconstituée en requêtes plus importantes.
La configuration d'étapes individuelles dans KNIME est également beaucoup plus rapide que dans Query Builder, je suppose, car les étapes de prédicat restent en mémoire et seule l'opération modifiée doit s'exécuter sur la représentation en mémoire de l'étape précédente. QB exécute à la place de nombreuses requêtes SQL (la désactivation des aperçus automatiques aide énormément, mais vous perdez la fonctionnalité d'aperçu). Fondamentalement, chaque fois que vous sélectionnez une colonne ou renommez une colonne avec l'aperçu automatique activé, il y a une requête de base de données et une interruption du flux.
Je pense que l'amélioration de Query Builder contribuerait grandement à démocratiser les opérations de données et l'utilisation de la base de données pour les scientifiques et les ingénieurs. Voici ce que je propose :
- Séparez la sélection de table des opérations de jointure et du filtrage/classement
- Cela peut tirer parti du générateur de requêtes existant, comme si une seule table était sélectionnée. La méthode JMP QB pour sélectionner et renommer les colonnes est plutôt bonne !
- Dans la mesure du possible, utilisez une représentation en mémoire d'un échantillon de table (y compris toutes les colonnes et environ 100 à 500 lignes) pour les opérations d'aperçu afin d'éviter les requêtes SQL aussi souvent que possible, car les E/S sont de loin la partie la plus lente de la plupart des opérations.
- J'inclus la sélection de colonnes, le changement de nom, le regroupement par, les fonctions d'agrégation, etc.
- Une préoccupation possible concerne les tables absurdement larges (la bioinformatique me vient à l'esprit), il peut donc être nécessaire d'avoir une limite de colonne également pour le mode en mémoire, mais je suis assez confiant que cela couvrirait la grande majorité des utilisations.
- Créez une représentation visuelle du flux pour joindre, filtrer, trier/ordonner par opérations.
- Chaque opération utiliserait la représentation en mémoire pour prévisualiser la sortie si possible.
- La représentation en mémoire des exemples de table source supprimerait également la nécessité d'interroger les noms de colonne pour l'opération de jointure, une étape extrêmement lente dans JMP.
- Idéalement, autorisez les opérations de table JMP (fractionner, empiler, concat, peut-être même l'ajout de colonnes avec des formules, la sélection de lignes, le masquage et l'exclusion de lignes, etc.) à enchaîner au flux en tant qu'étapes visuelles après la requête de la base de données.
- Je trouve que beaucoup de mes collègues finissent par enchaîner diverses étapes de nettoyage et de préparation des données en tant qu'opérations de menu que j'ai ensuite besoin d'aider à convertir en un script post-requête pour eux.
- Attacher des scripts à la table de données finale pourrait également être une étape visuelle, ce qui constituerait un flux pratique d'avoir une série d'étapes N pour N scripts attachés.
Du moins du point de vue de l'interface utilisateur, la plupart ou la totalité de ces éléments peuvent tirer parti des interfaces utilisateur existantes dans JMP : le panneau de configuration d'une étape de concaténation de table JMP peut littéralement utiliser le même format que l'option Tables>Concaténer dans JMP.
Mon état idéal est qu'un collègue sans formation significative en SQL ou en base de données puisse facilement expérimenter la sélection de tables, la jointure, le filtrage et la préparation des données pour se retrouver avec un flux de travail entièrement automatisé qui aboutit exactement à la table dont il a besoin pour faire sa visualisation et son analyse. . Je pense que l'approche du flux visuel est un excellent moyen de faciliter cela ! Il s'agirait d'un véritable générateur de tables, combinant les fonctionnalités d'interrogation de base de données, d'opérations en base de données et d'opérations en mémoire sur les tables, les lignes, les colonnes et les scripts pour créer un flux de travail de préparation des données entièrement automatique.
La sortie finale serait un peu comme un générateur de requêtes : soit un fichier .jmpflow (ou autre) qui s'ouvrira sur le flux du Générateur de tables, soit un script enregistré pouvant être exécuté à partir d'un complément ou de la fenêtre de script.
J'ai joint une image mal dessinée de ce que je pense. Si cela suscite l'intérêt des développeurs, n'hésitez pas à me contacter par message privé si vous souhaitez vous connecter pour en parler !
REMARQUE : modifié pour la mise en forme
+1 pour cela. Je pense qu'avec JMP Workflows 17, nous pouvons également avoir cette vue.
salut @Ryan_Gilmore , ça a l'air génial - pourriez-vous s'il vous plaît rouvrir ce souhait ?
C'est toujours important, rouvrons ceci s'il vous plaît.
Pour mémoire, je pense également que cette suggestion est toujours pertinente. Une approche de flux visuel est une manière flexible de gérer les processus ETL et n'est pas remplacée par les workflows, qui sont, en pratique, chaque étape sous forme de fonction appelée dans l'ordre.
@Sarah-Sylvestre, une chance de rouvrir cette demande ?
ce souhait a pour but de CRÉER un flux de travail visuellement.
souhait associé par @jthi
Visualisation de référence entre différents rapports et tables de données dans JMP
avec l'idée de visualiser une relation existante.
