データセット

MIDAS のプロジェクトは、CSV ファイルから読み込んだデータと、そこから SQL やデータ変換で生成した派生データで構成されます。このページでは、データセットの種類と、それぞれの動作について説明します。

データセットの種類

Primary Dataset

CSV や TSV ファイルを読み込むと、Primary Dataset が作成されます。読み込んだデータがそのまま格納され、セルの直接編集や行の除外ができます。

Project Overview には元ファイルの名前、読み込み日時、ファイルサイズがメタデータとして表示されます。

Derived Dataset

SQL Query Editor タブ、Crosstab、Reshape、Dummy Coding などの変換操作や、Filtered Data の Save as Dataset で生成されるデータセットです。生成元の操作と、依存する親データセット(あれば)が記録されます。

Derived Dataset のデータは直接編集できません。データを変更するには、変換操作を修正するか、親データセットを更新します。

Ephemeral Dataset は、プロジェクトに永続化されない一時的なデータセットです。Primary Dataset と Derived Dataset がプロジェクトに保存されるのに対し、Ephemeral Dataset はタブを開いている間だけ存在し、タブを閉じると破棄されます。Filtered Data タブのフィルタ結果などがこれにあたります。

タブを開いたままプロジェクトを保存すると、タブを復元するためにそのデータもプロジェクトファイルに含まれます。どのタブからも参照されていない Ephemeral Dataset は保存時に含まれません。フィルタ結果を恒久的に残すには、Filtered Data の Save as Dataset や Data Table の Save Filtered Data で Derived Dataset として保存します。

データ型の自動推論

CSV ファイルを読み込むと、各列のデータ型が自動的に判定されます。MIDAS が対応しているデータ型(boolean, int64, float64, date, datetime, string, enum)についてはデータの準備と読み込みを参照してください。

判定には優先順位があり、boolean、数値(int64/float64)、日付(date/datetime)の順にチェックされます。どれにも該当しない場合は string になります。enum 型は自動推論されず、string 型または int64 型から手動で変換して作成します。

空欄や欠損値は null として扱われ、型の判定には影響しません。

Derived Dataset のスキーマ継承

SQL Query Editor などで Derived Dataset を作成すると、結果の列は親データセットのメタデータを引き継ぎます。具体的には、測定尺度(名義・順序・間隔・比率)、データ型、enum 名が引き継がれます。

引き継ぎのルールは次のとおりです。

  • 結果の列名と同じ名前の列が親データセットにあれば、その設定を引き継ぐ
  • 測定尺度・データ型・enum 名は独立して継承される。親が複数ある場合(JOIN など)、同名の列が複数の親にあれば FROM 句で先に指定したデータセットが優先され、ある属性を先の親で取得できなければ後続の親から補完される
  • 該当する親の列がない場合は、クエリ結果から自動判定される

たとえば、親データセットで郵便番号の列を間隔尺度から名義尺度に変更していた場合、SQL で SELECT zip_code FROM ... とすると、名義尺度の設定がそのまま引き継がれます。

ただし、CAST(category AS INTEGER) のように結果の型が変わる変換では、親の測定尺度は引き継がれず、結果の型から自動判定されます。自動判定の結果が意図と異なる場合は手動で修正してください。

enum 名を引き継いだ列でも、結果のデータに enum 定義にない値が含まれる場合は、その列は string 型になり enum 名は外れます。たとえば COALESCE や CASE で定義外の文字列を補った列がこれにあたります。

カスケード削除

データセットを削除すると、そのデータセットに依存するリソースが連鎖的に削除されます。

削除されるもの

  • そのデータセットを親に持つ Derived Dataset(推移的に、孫・ひ孫も含む)
  • そのデータセットで適合した Model

削除されないもの

  • Report(ただし、削除されたデータセットを参照しているレポート要素はレポートから自動的に除去されます)

たとえば、Primary Dataset「A」から Derived Dataset「B」を作成し、「B」から Derived Dataset「C」と Model「M」を作成している場合、「A」を削除すると「B」「C」「M」もすべて削除されます。

削除前に影響範囲を確認するには、Project Lineage タブで依存関係を確認してください。

モデルの削除

モデルを削除する場合も同様にカスケード削除が働きます。

削除されるもの

  • そのモデルが生成した Derived Dataset(診断データセットや係数テーブルなど)
  • それらのデータセットに依存する Derived Dataset と Model(推移的に)

削除されないもの

  • モデルの適合元データセット
  • Report(ただし、削除されたモデルやその関連データセットを参照しているレポート要素はレポートから自動的に除去されます)

たとえば、Dataset「A」に適合した Model「M」が係数データセット「M-coef」を生成し、「M-coef」から Derived Dataset「D」を作成している場合、「M」を削除すると「M-coef」と「D」も削除されますが、「A」は残ります。

遅延評価とキャッシュ

Derived Dataset は、必要になるまでデータを計算しません。たとえば、プロジェクトファイルを開いた直後は、Derived Dataset のデータはまだ計算されていない状態です。Data Table タブ、Graph Builder、分析タブ、Statistics、Report、CSV のエクスポートでそのデータセットを参照したタイミングで初めて計算が実行され、結果がメモリにキャッシュされます。計算の間、Graph Builder と Report は "Evaluating derived dataset..." と表示し、計算に失敗したときはその理由を同じ場所に表示します。

親データセットが更新されると(再読み込み、型変更、セル編集など)、下流にある Derived Dataset のキャッシュはすべて破棄されます。次にデータが必要になったとき、自動的に再計算されます。

依存する Model も自動的に再推定されます。再推定が完了するまで、そのモデルの推定結果は表示されません。再推定が失敗したときは、画面右下に通知が表示されます。通知の Open Model ボタンからそのモデルを開いて、失敗の理由を確認できます。

分析タブでまだモデルとして保存していないフィット結果も、フィットに使ったデータセットの更新で無効になります。保存済み Model と違って自動では再推定されないため、GLM・GLMM・Linear Regression の各タブは結果を画面から外し、再実行を促すメッセージを表示します。

計算結果のプロジェクトファイルへの保存

Save data with project を有効にした Derived Dataset は、計算結果をプロジェクトファイル(MDS)に保存します。この設定は既定では無効です。無効のとき、MDS には操作の定義だけが入り、MIDAS はプロジェクトを開いたあとデータが必要になった時点で操作を再実行します。

有効にすると、MDS のファイルサイズは大きくなりますが、プロジェクトを開いた直後から再計算を待たずにデータを使えます1。計算に時間のかかる SQL クエリや大きなデータの変換を含むデータセットほど、この差は大きくなります。設定は Project Overview の Datasets セクションと、Data Table タブのメニューで切り替えます。Agent API からも切り替えられます。

この設定が決めるのは保存するかどうかだけで、データを再計算する条件は変わりません。有効にした Derived Dataset でも、親データセットが更新されると、MIDAS はメモリ上の計算結果を破棄し、遅延評価とキャッシュで説明したとおり次に必要になったときに再計算します。MDS ファイルの中身が変わるのは、次にプロジェクトを保存したときです。

有効にしたデータセットの行データは MDS ファイルに入ります。ファイルを第三者に共有するときは、そのデータの内容に注意してください。

データセットのリネームと SQL の自動更新

Project Overview でデータセットの名前を変更すると、そのデータセットを参照している SQL クエリが自動的に更新されます。

たとえば、データセット「sales_2024」を「sales」にリネームすると、Derived Dataset の SQL 内の FROM "sales_2024" が FROM "sales" に書き換わります。更新は SQL の構文解析に基づいて行われるため、文字列リテラルやコメント内の同名テキストは影響を受けません。

自動更新の対象は、FROM "sales_2024" のようにダブルクォートで囲んだテーブル名参照です。FROM sales_2024 のように引用符なしで記述した参照は更新されないため、リネーム後に SQL を手動で修正してください。

リネーム後、影響を受けた Derived Dataset のキャッシュは破棄され、次回アクセス時に再計算されます。

自動更新の対象は保存済みの SQL であり、編集中の SQL Query Editor タブに表示されているクエリは書き換わりません。編集タブを開いたままリネームしたときの扱いは SQL Query Editor タブ を参照してください。

See also

脚注

  1. MDS に入るのは、保存した時点で計算済みのデータだけです。親データセットの更新で計算結果を破棄したあと、再計算する前にプロジェクトを保存すると、そのデータセットのデータは MDS に入らず、開いたあと必要になった時点で再計算します。 ↩