まとめ：データベースの選択、結合やフィルタリングなどのデータベース内操作、「Table>Concatenate」や「Rows> Select Where...」などのメモリ内操作、および Add などのいくつかの JSL 操作を可能にする視覚的な Table Builder インターフェイスを提案します。ビジュアル フローでチェーンされるプロパティ。 私はこのアプローチが提供すると信じています非常に直感的な方法データ サイエンスのトレーニングをほとんど受けていない人向けで、データの準備とクリーンアップを自動化し、ライブ データ ソースを JMP に簡単に取り込んで、洞察の生成と分析を行うことができます。
詳細： JMP Query Builder を頻繁に使用して、社内の Postgres データベースからデータ クエリを作成しています。これは、基本的なデータベース クエリ ツールとしてうまく機能します。 とは言うものの、Python、KNIME、または未加工の SQL に戻って、2 つのサブクエリを結合してテーブルを生成するなどのより複雑なワークフローに対処するために、それ自体がベース テーブルでの結合と変換の結果であることに今でも気付いています。 ただし、最終的には、単純な JMP クエリを作成して、データベースから JMP のデータを取得する必要があります。 さらに、現在のクエリ ビルダはかなり遅く、データベース操作の基礎がしっかりしていない人にとっては直感的ではありません。
ここで KNIME と Alteryx が採用したアプローチは、私にとって非常に良いと感じています。つまり、データベース操作の強力なメンタル モデルに役立つ視覚的なフローです。 各ステップでは、新しい仮想テーブル (実際には抽象化された SQL 操作) が生成されます。これは、より大きなクエリにまとめることができます。
KNIME で個々のステップを構成することも、Query Builder よりもはるかに高速です。これは、述語ステップがメモリに残り、前のステップのメモリ内表現で変更された操作のみを実行する必要があるためだと思います。 代わりに、QB は多くの SQL クエリを実行します (自動プレビューをオフにすると非常に役立ちますが、プレビュー機能が失われます)。 基本的に、列を選択するか、自動プレビューをオンにして列の名前を変更するたびに、データベース クエリが実行され、フローが中断されます。
Query Builder を改善することは、データ操作とデータベースの使用を科学者やエンジニアに民主化するのに大いに役立つと思います。 ここに私が提案しているものがあります：
- 結合操作とフィルタリング/順序付けからテーブル選択を分離
- これにより、単一のテーブルが選択されたかのように、既存のクエリ ビルダーを活用できます。 列を選択して名前を変更する JMP QB の方法は非常に優れています。
- IO はほとんどの操作の中で最も遅い部分であるため、できるだけ頻繁に SQL クエリを回避するために、可能な限り、プレビュー操作にテーブル サンプル (すべての列と約 100 ～ 500 行を含む) のメモリ内表現を使用します。
- これには、列の選択、名前の変更、グループ化、集計関数などを含めます。
- 考えられる懸念は、とてつもなく広いテーブルです (バイオインフォマティクスが頭に浮かびます)。そのため、メモリ内モードにも列制限が必要になる場合がありますが、それでほとんどの用途をカバーできると確信しています。
- 操作による結合、フィルタリング、並べ替え/並べ替えの視覚的なフロー表現を構築します。
- 可能であれば、各操作は出力のプレビューにメモリ内表現を使用します。
- ソース テーブル サンプルのメモリ内表現により、結合操作のために列名をクエリする必要もなくなります。これは、JMP では驚くほど遅いステップです。
- 理想的には、JMP テーブル操作 (分割、スタック、連結、場合によっては式を含む列の追加、行の選択、行の非表示と除外など) を、データベースからのクエリ後の視覚的なステップとしてフローに連鎖できるようにします。
- 多くの同僚が、さまざまなデータのクリーンアップと準備の手順をメニュー操作としてつなぎ合わせてしまい、それを後クエリ スクリプトに変換する必要があります。
- スクリプトを最終的なデータ テーブルに添付することも、視覚的なステップになる可能性があります。これにより、添付された N 個のスクリプトに対して一連の N 個のステップを持つ便利なフローが作成されます。
少なくともUIの観点からは、これらの部分のほとんどまたはすべてがJMPの既存のUIを活用できます。JMPのTable Concatenateステップの構成パネルは、文字どおりJMPのTables>Concatenateオプションと同じフォーマットを使用できます。
私の理想的な状態は、重要な SQL またはデータベースのトレーニングを受けていない同僚が、テーブルの選択、結合、フィルタリング、およびデータの準備を簡単に試して、完全に自動化されたワークフローを完成させ、視覚化と分析を実行するために必要なテーブルを正確に作成できることです。 . ビジュアル フロー アプローチは、それを容易にする優れた方法だと思います。 これは、データベース クエリ、データベース内操作、およびメモリ内テーブル、行、列、およびスクリプト操作の機能を組み合わせて、完全に自動化されたデータ準備ワークフローを構築する真のテーブル ビルダーです。
最終的な出力は、クエリ ビルダーのようなものです。テーブル ビルダー フローに対して開く .jmpflow ファイル (または任意のもの)、またはアドインまたはスクリプト ウィンドウから実行できる保存済みスクリプトのいずれかです。
私が考えていることのひどく描かれた絵を添付しました。 これが開発者の興味をそそる場合、これについて話すために接続したい場合は、プライベート メッセージでお気軽にご連絡ください。
注：書式設定のために編集
これに +1。17 の JMP ワークフローでは、このビューも表示できると思います。
こんにちは@Ryan_Gilmore 、素晴らしいですね。この願いをもう一度開いていただけますか?
ちなみに、私もこれは依然として適切な提案だと考えています。ビジュアル フロー アプローチは、ETL プロセスを処理する柔軟な方法であり、実質的に各ステップが順番に呼び出される関数であるワークフローに置き換えられるものではありません。
@Sarah-Sylvestreこのリクエストを再開する可能性はありますか?
この願いは、視覚的にワークフローを作成することを目標としています。
@jthiによる関連する願い
JMP のさまざまなレポートとデータテーブル間の参照視覚化
既存の関係を視覚化するというアイデアに基づいて。
