SQLiteファイルとしてデータセットを受け取ったとします——Kaggleからのダウンロード、スクレイピングしたデータセット、同僚のエクスポート、あるいは自分自身のETLの出力かもしれません。それを処理するPythonコードを書く前に、中身を理解する必要があります。テーブル名、列の型、行数、データの分布、そして潜在的な品質の問題です。Jupyter Notebookでもクエリを実行できますが、接続を設定し、探索的なSQLを書き、Notebookのセルに結果を描画するのは、単にデータをざっと見たいだけのときにはオーバーヘッドです。
データサイエンスのワークフローにおける探索のギャップ
データサイエンティストは通常、次の3つのいずれかの方法でSQLiteファイルを探索します。sqlite3のCLI（速いがビジュアルな出力はない）、pandas.read_sql()を使ったJupyter Notebook（柔軟だがセッションごとに設定が必要）、あるいはDBeaverのような重量級のデータベースIDE（強力だがローカルファイルには過剰）です。どれも「ファイルを開いてすぐにデータを閲覧する」という理想には届きません。
CLIはデータ探索には特に不向きです。幅の広いテーブルのビジュアルな書式もなく、スクロール可能な出力もなく、データの分布をさっと確認する方法もありません。Notebookは分析には価値をもたらしますが、「このデータはどんな見た目なのか？」という最初の段階では遅く感じられます。1行を見るまでに、決まりきった接続コードを書く羽目になります。
Tomeでデータセットをビジュアルに探索
Tomeを使えば、SQLiteのデータセットを開いて、その構造を即座に理解できます。すべてのテーブルが行数とともにサイドバーに表示されます。テーブルをクリックすれば、ネイティブなグリッドでデータをスクロールできます。設定も、接続文字列も、決まりきったコードも不要です——ファイルを開いて見るだけです。
コードを書く前にスキーマを理解する
テーブルを閲覧して、列名、型、サンプル値を確認しましょう。どの列にnullが含まれているか、どのテーブルが外部キーを通じて関連しているか、データセットがどのように構造化されているかを、Pythonのコードを1行も書く前に把握できます。この文脈があれば、分析コードを最初から的確なものにできます。
対話的にクエリをテストする
オートコンプリート付きのTomeのSQLエディタを使って、クエリを試作しましょう。WHERE句、JOIN条件、集計をまずTomeでテストし、動作確認の取れたSQLをPythonのパイプラインにコピーします。ビジュアルなエディタでクエリのエラーに気づく方が、Notebookのセルでデバッグするよりも速いです。
ETLの出力を確認する
パイプラインが結果をSQLiteデータベースに書き込んだ後、Tomeでそれを開いて出力を検証しましょう。行数を確認し、null値に気づき、変換が期待通りの結果を生み出しているかを確かめられます——追加の検証コードを書く必要は一切ありません。