第10章: データベース技術

この章を読む理由

解析結果を再利用可能な資産に変えるには、 ファイルを置くだけでなく、スキーマ、索引、追跡可能性、権限制御を設計する必要があります。 第10章は、第4章と第7章で得た成果物を 「チームで使えるデータ基盤」へ変換するための章です。

本章で使う共通題材

• 題材A: SARS-CoV-2 公開データ
  • SRR11140744 / MN908947.3
  • 変異結果や時系列監視データをどう保存するかを考えます。
• 題材B: TCGA-LUAD 研究用ミニケース
  • TCGA-LUAD
  • 発現行列・変異情報・臨床メタデータを統合する研究用データマートの最小例として扱います。

学習目標

• 生物学データの保存戦略を、リレーショナル / NoSQL / データウェアハウスの観点で比較できる
• genomic_variants や sample_metadata のような最小スキーマを設計し、索引とクエリ計測の考え方を説明できる
• データ由来、更新履歴、権限制御を含む追跡可能性の設計を整理できる

10.0 DB/API由来データを保存対象にする前提

10.0.1 DB/APIを保存対象にする前の確認事項

第10章では、データベースを「高速に検索する仕組み」だけでなく、外部DB・APIから取得したデータを再利用可能な資産に変えるための設計対象として扱います。NCBI Datasets CLI / API、Entrez / E-utilities、Ensembl REST、UniProt REST、GA4GH標準などの使い分けは 付録I-2 で、API rate limit、retry、cache、provenance / 来歴の実装前チェックは 付録I-5 で扱います。

この章のスキーマ例では、解析結果そのものだけでなく、analysis_run、source_dataset、reference_version、api_request_log のようなメタデータを別テーブルまたは別コレクションとして設計します。これにより、同じ variant / 変異や発現値を後から読み直すときに、「どのDB releaseを、どの経路で、どの条件で取得した値か」を説明できます。

10.1 保存先の選択（DB / Parquet / object storage / データウェアハウス）

最初に決めるのは製品名ではなく、保存対象の粒度、更新頻度、同時利用者、再解析時に説明したい provenance / 来歴です。小規模な検証では単一ファイルのDBや列指向ファイルで十分な場合があります。一方、複数人が更新する共有基盤では、トランザクション、権限、バックアップ、監査ログを備えたRDBを優先します。

実務では、次の順で候補を絞ります。

1. snapshot固定か継続更新か: 研究・教育用の再現性を優先するなら、DB release、取得日、checksumを固定したsnapshotを作ります。継続更新する場合は、差分件数、更新理由、ロールバック手順を analysis_run に残します。
2. 行指向か列指向か: サンプル単位の検索や更新が中心ならRDB、列を絞った集計や発現行列の横断分析が中心ならParquetのような列指向保存を検討します。
3. 同時更新と権限が必要か: 1人の検証ではSQLiteやDuckDBで始め、複数人が更新する段階でPostgreSQLなどの共有RDBへ移します。
4. provenanceをどこに置くか: 生データ、整形済みテーブル、API request log、checksum確認表を分け、source_dataset と reference_version から追跡できるようにします。

分散DBや専用データウェアハウスは、大規模データを扱うための選択肢です。ただし、最初から大規模基盤を前提にすると、schema version、取得元、checksum、権限境界のような基本設計が曖昧になることがあります。まず小さな題材で、保存先ごとの成果物と運用責任を説明できる状態にしてから拡張します。

10.1.1 インデックス最適化とクエリ計測（PostgreSQL）

RDBの索引設計では、variant / 変異テーブル単体の検索速度だけでなく、検索結果から取得元データセットと解析実行へ戻れるかも計測対象にします。source_dataset と analysis_run へのJOINを典型クエリに含めておくと、性能改善とprovenance / 来歴の説明責任を同時に確認できます。

以下は PostgreSQL での索引設計とクエリ計測の観点を示す SQL 断片です。genomic_variants / source_dataset / analysis_run のテーブル定義、制約、サンプルデータ、権限設定を省略しているため、そのままでは実行できません。 🧪 概念例（実行不可: テーブル定義・サンプルデータを省略した PostgreSQL の SQL 断片）

-- 代表的な索引の作成（位置・染色体・サンプルID）
CREATE INDEX IF NOT EXISTS idx_variants_chr_pos
  ON genomic_variants (chromosome, position);
CREATE INDEX IF NOT EXISTS idx_variants_sample
  ON genomic_variants (sample_id);

-- provenance / 来歴をたどる外部キー列も、典型クエリに合わせて索引化
CREATE INDEX IF NOT EXISTS idx_variants_source_chr_pos
  ON genomic_variants (source_dataset_id, chromosome, position);
CREATE INDEX IF NOT EXISTS idx_variants_analysis_run
  ON genomic_variants (analysis_run_id);
CREATE INDEX IF NOT EXISTS idx_source_dataset_release
  ON source_dataset (source_dataset_id, db_release);

-- 範囲検索と取得元・解析実行の確認を同じクエリで計測
-- source_dataset_id は、表示名ではなく snapshot 単位で固定したIDを想定
EXPLAIN (ANALYZE, BUFFERS)
SELECT v.variant_id, v.chromosome, v.position, v.sample_id,
       s.dataset_name, s.db_release, a.pipeline_version
  FROM genomic_variants AS v
  JOIN source_dataset AS s ON v.source_dataset_id = s.source_dataset_id
  JOIN analysis_run AS a ON v.analysis_run_id = a.analysis_run_id
 WHERE v.source_dataset_id = 'tcga_luad_snapshot'
   AND v.chromosome = '1'
   AND v.position BETWEEN 1000000 AND 2000000
   AND s.db_release = 'fixed_db_release';

-- 欠損の多い列には部分索引も検討
CREATE INDEX IF NOT EXISTS idx_variants_quality_notnull
  ON genomic_variants (quality) WHERE quality IS NOT NULL;

ヒント:

• パーティションプルーニングを活かすため、パーティションキー（例: 染色体）を絞り込む述語を必ず含める。
• EXPLAIN (ANALYZE, BUFFERS) の結果を比較し、テーブルスキャン→インデックススキャンへの切替を確認。
• source_dataset や analysis_run とのJOINを典型クエリに含め、検索結果から取得元DB、DB release、pipeline version に戻れることを確認。
• dataset_name のような表示名だけで絞らず、snapshot単位で固定した source_dataset_id とDB releaseを条件に含める。
• 統計更新（ANALYZE）とワークメモリ・並列設定でプランの改善余地を検討。
• 索引変更の理由、対象snapshot、計測日時、主要クエリ、実行計画の要約を analysis_run または運用ログに紐づけて残す。

10.2 NoSQLデータベースを使う条件

NoSQL は、RDB を置き換える万能な保存先ではありません。使う前に、データ構造が頻繁に変わるのか、関係をたどる検索が中心なのか、時系列の追記が中心なのかを切り分けます。sample_metadata や analysis_run のように整合性と外部キーが重要なデータはRDBを基本にし、NoSQLは構造やアクセスパターンがRDBだけでは扱いにくい部分へ限定して使います。

NoSQL を採用する場合でも、解析の起点になる source_dataset、reference_version、analysis_run はRDBやmanifestで追跡できるようにします。たとえば、注釈JSONをドキュメントDBに置く場合でも、どの accession.version とDB releaseから作った文書かをRDB側に残し、再生成できる経路を確保します。

採用を避ける目安も明確にします。表形式で扱える小規模データを「将来大きくなるかもしれない」という理由だけでNoSQL化すると、JOIN、制約、監査、バックアップの設計が複雑になります。まずRDBまたはParquetで表現し、検索パターンが明確になってから必要な部分だけNoSQLへ分離します。

10.3 データウェアハウスと研究用データマート

データウェアハウスは、外部DB/APIから取得した原本を置く場所ではなく、解析・集計・共有のために整形した派生データを置く場所として設計します。第10章では、大規模な商用DWH製品名よりも、raw snapshot、staging、curated data mart、aggregate の層を分け、それぞれに provenance / 来歴を残すことを重視します。

ETL / ELT は、単なる「抽出・変換・格納」ではなく、どの段階でデータを信頼できる形へ昇格させるかを決める作業です。たとえば TCGA-LUAD の研究用ミニケースでは、発現行列、変異情報、臨床メタデータを1つの巨大テーブルにまとめるのではなく、サンプルID、測定種別、由来DB、利用条件を分けて持つ data mart を作ります。

DWH や data mart を設計するときは、次の境界を明記します。

1. 原本と派生物の境界: raw snapshot と curated table を分け、派生物だけを見ても元データの accession.version、DB release、checksum に戻れるようにします。
2. 分析用と監査用の境界: 解析者向けの集計テーブルとは別に、analysis_run、source_dataset、reference_version、api_request_log を監査用に残します。
3. 更新と再計算の境界: full refresh と incremental update のどちらで更新するかを決め、差分件数、失敗時のロールバック手順、再計算の起点を記録します。
4. 利用条件の境界: 公開DB/API由来のデータでも、利用条件、再配布可否、商用利用可否が異なる場合があるため、data mart の列やmanifestに用途区分を残します。

この設計により、DWH は「すべてを入れる場所」ではなく、研究・教育用途の再解析と説明責任を支える読み取り最適化層になります。臨床判断や個人情報を扱う場合の追加要件は、第11章と第12章で扱います。

まとめ

• DB 章の要点は、性能だけでなく「どの成果物を、どの粒度で、誰が再利用するか」を先に決めることです。
• SRR11140744 の変異結果や TCGA-LUAD の研究データを例に、 スキーマ、索引、保存先、由来情報に加えて、accession.version、DB release、genome build、checksum、取得日時を一緒に設計すると後続章で再利用しやすくなります。
• RDB、Parquet、object storage、NoSQL、DWH は物理的な保存先や実行基盤として整理し、raw snapshot、staging、curated data mart、aggregate / reporting は論理層として分けて設計します。
• DB/API 由来データを保存する場合は、source_dataset、reference_version、analysis_run、api_request_log を成果物に含めると、後から「どの取得元を、どの条件で、どの処理に使ったか」を説明できます。
• 第11章では、この基盤設計を前提に、個人情報・同意・監査ログの扱いへ進みます。

Source notes / 次の一歩

• 付録F: 第10章の次の一歩
• 付録I: データベース利用の実践ガイド
• 付録J: 実在アクセッション一覧
• 付録K: 用語集

次章への橋渡し

データを保存できるだけでは、医療・研究現場では使えません。 次章では、同じデータ基盤を前提に、匿名化、権限管理、監査ログ、 フェデレーテッド学習といったプライバシー保護の観点を重ねます。

最小入出力（期待成果物/期待ログ）

• 入力: 対象データのスキーマ（例: 変異・注釈・サンプル）、サンプルデータ（小規模で可）、accession.version 付きID、DB/API取得元、reference_version（genome build 例: GRCh38 などを含む）、DB release または snapshot ID
• 出力（期待成果物）: 保存先・実行基盤選択メモ（RDB / Parquet / object storage / NoSQL / DWH）、インデックス/パーティショニング方針、主要クエリの設計メモ、raw snapshot / staging / curated data mart / aggregate の層定義、source_dataset、reference_version、analysis_run、api_request_log の項目定義、checksum / row count 確認表
• 期待ログ（例）: クエリ性能の計測結果（例: EXPLAIN ANALYZE、実行時間）、取得URL / API endpoint、query、HTTP status、retry / cache の記録、層ごとの row count、checksum / row count の検証結果、更新時の差分件数とロールバック手順が残る

演習

1. genomic_variants、sample_metadata、source_dataset、analysis_run の 4 テーブルを持つ最小スキーマを設計し、主キー・外部キー・索引方針と保存先（RDB / Parquet / object storage）を示せ。
2. SRR11140744 または TCGA-LUAD を題材に、raw snapshot、staging、curated data mart、aggregate / reporting の 4 層を定義し、各層の row count、checksum、manifest 項目を示せ。
3. 外部DB/APIから取得した注釈を保存する想定で、RDB、ドキュメントDB、Key-value / cache のどれを使うかを判断し、api_request_log に残す endpoint、query、取得日時、HTTP status、retry回数、cache有無、checksum を定義せよ。
4. 研究用途と将来の臨床連携検討を分けるために、権限、監査ログ、データ保持期間、専門家レビューの要否をどう切り分けるか整理せよ。

具体課題例

• 変異結果を RDB へ格納する案、注釈 JSON をドキュメント DB へ格納する案、集計済み Parquet を DuckDB で読む案を比較する。
• データ更新時に必要なメタデータ（accession.version、DB release、genome build、checksum、参照配列 ID、ツール版、実行日、責任者、ロールバック手順）を列として設計する。
• NCBI Datasets / Entrez、UniProt REST、Ensembl REST などから注釈を取得する場合に、取得経路、利用条件、API version、rate limit、retry / cache 方針を列挙する。
• TCGA-LUAD の研究用データマートを例に、sample、variant、expression、annotation の表を分け、source_dataset との対応を示す。
• 第12章で臨床ゲノム情報の責任境界を検討する前提として、どの列を匿名化 / 仮名化対象にするかメモを作る。