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

この章を読む理由

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

本章で使う共通題材

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

学習目標

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

なぜ IT 技術者に必要か

バイオインフォマティクスのデータベース設計では、通常の業務DBよりも「どのデータを、いつ、どの版で、どの条件で取得したか」が結果の解釈に直結します。accession や gene symbol だけを保存すると、DB release、annotation version、reference genome、API endpoint、利用条件が変わったときに、同じクエリから同じ結果を再現できないことがあります。

IT 技術者は、外部DB/APIの変動を前提に、snapshot、checksum、row count、schema version、retry / cache、rate limit、terms of use、監査ログを設計へ組み込む役割を担います。この章では、検索速度だけでなく、後から説明できるデータ基盤を作る観点を重視します。

前提知識

• SQL の主キー、外部キー、索引、正規化、トランザクション、権限、バックアップの基本。
• HTTP / REST API、JSON、pagination、timeout、retry、backoff、cache、HTTP status の基本。
• FASTA / FASTQ / BAM / CRAM / VCF / GTF / GFF / BED / Parquet など、保存対象になりやすいファイル形式の役割。
• accession、accession.version、stable ID、gene symbol、genome build、annotation release、checksum の違い。
• 第4章の variant / 参照配列、第5章の count matrix / annotation、第11章の権限管理、第13章の provenance / 再現性の考え方。

基本概念

入力データと出力データ

標準的なワークフロー

1. 目的と責任境界を決める: 研究・教育用の再解析、社内共有、将来の臨床連携検討など、利用目的と専門家レビューの要否を明記する。
2. 取得元を固定する: NCBI Datasets CLI / API、Entrez / E-utilities、Ensembl REST、UniProt REST、GENCODE / RefSeq bulk download、GA4GH実装など、取得経路と endpoint を記録する。
3. raw snapshot を保存する: 取得ファイル、HTTP response metadata、query、取得日時、DB release、checksum、row count、terms of use を manifest に残す。
4. staging で検証する: 型変換、ID mapping、重複除去、欠損確認、reference genome / annotation release の整合を確認し、変換スクリプトと schema version を残す。
5. curated data mart を作る: 解析者が使う sample、variant、expression、annotation などを分け、主キー・外部キー・索引を設計する。
6. 運用ログを残す: API失敗、retry、cache hit率、差分件数、ロールバック手順、クエリ計測結果、権限変更を analysis_run や api_request_log に紐づける。
7. 結果をレビューする: 件数、欠損、checksum、典型クエリ、DB release差分、利用条件、研究・臨床境界をレビューし、必要なら取得元へ戻れるようにする。

実務上の落とし穴

• current のAPI結果だけを保存し、DB release、取得日時、query、checksum、terms of use を残さない。
• gene symbol や variant ID を安定IDとして扱い、annotation release や ID mapping 条件を記録しない。
• schema、index、cache、retry の設定を性能だけで決め、provenance / 来歴や監査ログと切り離す。
• 研究・教育用途の snapshot と、継続更新する共有DBを同じ責任境界で扱う。

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.0.2 DB/API 変更は再現性リスク

同じ accession / query でも、DB release、annotation version、reference genome、response schema、endpoint が変わると、返るレコード、列名、欠損、臨床的意義や構造予測の解釈が変わります。REST API では field name、rate limit、認証方式、endpoint、bulk download の配置も変わり得るため、サンプルコードには取得日と schema 前提を残します。教育用コードでは、外部 API が一時停止してもビルドや演習が壊れないように、small fixture と cache を用意し、実データ取得と fixture 検証を分けます。

🔁 疑似コード（実行不可: DB/API release tracking manifest の記入例）

database: AlphaFold DB
release: "例: v6 / UniProt 2025_03 など"
endpoint: "https://..."
query: "accession=P38398 or API request path"
retrieved_at: "2026-06-05"
response_schema: "field names / API doc version / response headers"
reference_genome: "GRCh38 / T2T-CHM13 / not_applicable"
license_or_terms: "利用条件・再配布条件・commercial restriction"
checksum: "raw response または download file checksum"
cache_policy: "raw response / processed table / frozen fixture"
known_breaking_changes: "field rename, endpoint migration, authentication, rate limit"

具体例として、AlphaFold DB prediction API では entryId から modelEntityId、uniprotStart / uniprotEnd から sequenceStart / sequenceEnd、uniprotSequence から sequence への field rename と、paeImageUrl の削除（sunset後はAPIから提供・参照不可）を breaking change として扱います。Ensembl では、public MySQL の MySQL 5.6 から MySQL 8 への移行に伴い、古い client / connector、authentication plugin、reserved words、LOAD DATA LOCAL INFILE、文字コード・照合順序の差分を schema 互換性リスクとして記録します。

🔁 疑似コード（実行不可: 外部 API への過剰依存を避ける取得・保存手順）

1. manifest に database / release / endpoint / query / retrieved_at / response_schema を書く。
2. 教育用 smoke test では frozen fixture を読み、外部 API へは接続しない。
3. 実取得ジョブだけが endpoint へアクセスし、raw JSON と HTTP metadata を保存する。
4. raw JSON の sha256、processed TSV の sha256、row count、schema hash を記録する。
5. response_schema または known_breaking_changes が変わったら、processed TSV を再生成して差分をレビューする。

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、権限境界のような基本設計が曖昧になることがあります。まず小さな題材で、保存先ごとの成果物と運用責任を説明できる状態にしてから拡張します。

小さな実例

小さな例では、NCBI / Ensembl / UniProt などから取得した数件のレコードを raw snapshot、staging table、curated table に分け、source_dataset、reference_version、analysis_run を通じて再取得条件と変換条件を説明できるようにする。結果の正しさだけでなく、取得元、取得日、DB release、row count、checksum、利用条件、query plan を成果物として残す。

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 または運用ログに紐づけて残す。

結果の読み方

DB/API由来データの結果は、検索結果の件数や実行時間だけでは評価しません。まず、source_dataset_id、DB release、genome build、annotation release、取得日時、checksum、row count が期待どおりに残っているかを確認します。次に、代表クエリの EXPLAIN、API request log、cache hit率、retry回数、429/503 の発生状況を確認し、性能問題と取得元側の制約を分けて読みます。

生物学的な注釈結果を読むときは、ID mapping の一対多、一対ゼロ、obsolete ID、gene symbol の別名、annotation release 差分を必ず分けます。取得に成功したことは、注釈が最新であること、研究結論が妥当であること、臨床判断に使えることを意味しません。結果表には、値そのものに加えて、取得元、版、変換条件、利用条件、レビュー状態を残します。

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 / 次の一歩

この節は参考資料として、DB/API、保存設計、provenance、利用条件、API制限を確認するための導線である。

• 付録F: 第10章の次の一歩
• 付録I: データベース利用の実践ガイド
• 付録J: 実在アクセッション一覧
• 付録K: 用語集
• NCBI Datasets CLI reference / API keys / file validation（2026-05-19確認）
• NCBI E-Utilities introduction / usage guidelines and API key / NCBI Policies and Disclaimers（2026-05-19確認）
• AlphaFold DB release notes / AFDB prediction API breaking changes / AlphaFold DB API schema reference（2026-07-15確認）
• Ensembl: programmatic access and transition to the new Ensembl Platform / Ensembl release 116 announcement / Ensembl MySQL 8 upgrade notice（2026-07-15確認）
• UniProt SPARQL endpoint / UniProt ID Mapping service / UniProt REST API paper（2026-05-19確認）
• ClinVar classification documentation / DDBJ Center services / NBDC Human Data Sharing Guidelines / jMorp User Guide（2026-07-15確認）
• GENCODE Human release history / GENCODE FAQ（2026-05-19確認）
• NCBI RefSeq（2026-05-19確認）
• GA4GH refget specifications / GA4GH htsget / Beacon protocol documentation / GA4GH Service Info（2026-05-19確認）

2026年時点の更新メモ

• NCBI Datasets CLI / API は、genome、gene、virus などのデータ取得経路として扱い、取得コマンド、対象 accession、取得日、zip / JSON / FASTA / GFF などの出力形式を manifest に残す。Entrez / E-utilities は横断検索や既存ワークフローとの接続に有用だが、NCBI の利用ガイドラインに沿って、tool名、email、API key の有無（値は保存しない）、rate limit、retry を明示する。
• AlphaFold DB v6 のように、上流 UniProt release との同期、entry URL、API schema、旧 field の sunset が同時に変わるDBでは、構造ファイルのURLだけでなく、release、API doc、field list、raw response checksum を manifest に残す。
• Ensembl は現行 platform から新 Ensembl platform への移行が案内されているため、現行 site、archive、beta / new platform などの接続先、Ensembl release、species、assembly、REST / FTP / BioMart / GraphQL / RefGet のどれを使ったかを保存する。public MySQL を使う場合は、MySQL 8 への移行、mirror終了、client / connector version も確認し、current だけを記録しない。
• UniProt は REST API、SPARQL、ID Mapping を使い分けられる。UniProtKB accession、entry version、reviewed / unreviewed、ID mapping job、fields、query、取得時の release を保存し、RefSeq、Ensembl、GENCODE との対応は一対一と仮定しない。
• GENCODE、RefSeq、Ensembl はいずれも gene / transcript / protein annotation を扱うが、目的、ID体系、更新単位、curation方針が異なる。解析結果には、どの annotation release と genome build を使ったかを明記する。
• GA4GH refget / htsget / Beacon は、参照配列の識別、部分的な reads / variants 取得、分散データ発見の標準として扱う。ただし、実際に使える endpoint、認証・認可、データ利用条件、実装versionは提供機関ごとに異なるため、標準名だけでなく endpoint と service-info 相当の情報を保存する。

次章への橋渡し

データを保存できるだけでは、医療・研究現場では使えません。 次章では、同じデータ基盤を前提に、権限管理、監査ログ、 準同型暗号、秘密分散、差分プライバシー、匿名化 / 仮名化といったプライバシー保護の観点を重ねます。

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

• 入力: 対象データのスキーマ（例: 変異・注釈・サンプル）、サンプルデータ（小規模で可）、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章で臨床ゲノム情報の責任境界を検討する前提として、どの列を匿名化 / 仮名化対象にするかメモを作る。