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

この章を読む理由

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

本章で使う共通題材

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

学習目標

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

10.1 並列データベース（HiRDB）

分散アーキテクチャ: 🧪 概念例（擬似コード）

フロントエンドサーバ: クエリ解析・最適化
├── ディクショナリサーバ: メタデータ管理
├── バックエンドサーバ1: データパーティション1
├── バックエンドサーバ2: データパーティション2
└── バックエンドサーバN: データパーティションN

パーティショニング戦略:

• 水平分割: 配列長による分割
• 垂直分割: 属性による分割
• 機能分割: アプリケーション用途による分割

オープンソース代替実装（PostgreSQLベース）: 🧪 概念例（擬似コード）

import psycopg2
from psycopg2.extras import RealDictCursor
import concurrent.futures
from typing import List, Dict, Any

class ParallelGenomicDatabase:
    """並列ゲノムデータベースの実装"""
    
    def __init__(self, connection_params: Dict[str, Any], n_partitions: int = 4):
        """
        Args:
            connection_params: PostgreSQL接続パラメータ
            n_partitions: パーティション数
        """
        self.connection_params = connection_params
        self.n_partitions = n_partitions
        
    def setup_partitioned_table(self):
        """パーティションテーブルの作成"""
        with psycopg2.connect(**self.connection_params) as conn:
            with conn.cursor() as cur:
                # 親テーブルの作成
                cur.execute("""
                    CREATE TABLE IF NOT EXISTS genomic_variants (
                        variant_id BIGSERIAL,
                        chromosome VARCHAR(2),
                        position INTEGER,
                        reference VARCHAR(1000),
                        alternate VARCHAR(1000),
                        quality FLOAT,
                        sample_id INTEGER,
                        genotype INTEGER,
                        PRIMARY KEY (variant_id, chromosome)
                    ) PARTITION BY LIST (chromosome);
                """)
                
                # 染色体ごとのパーティション作成
                for i in range(1, 23):
                    cur.execute(f"""
                        CREATE TABLE IF NOT EXISTS genomic_variants_chr{i}
                        PARTITION OF genomic_variants
                        FOR VALUES IN ('{i}');
                    """)
                
                conn.commit()

大規模データ処理の実現: 生物学データベースは大規模化し、単一サーバでは処理が困難な場合がある。並列データベースにより、クエリ処理を複数ノードで分散実行し、応答時間を短縮できる場合がある。適切なパーティショニングにより、関連データを同一ノードに配置し、ネットワーク通信を最小化する。結果として、研究者は大規模データに対してインタラクティブな解析が可能となり、研究効率が向上する。

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

🧪 概念例（擬似コード）

-- 代表的な索引の作成（位置・染色体・サンプル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);

-- 範囲クエリの例（chr1 1Mb〜2Mb）
EXPLAIN ANALYZE
SELECT * FROM genomic_variants 
 WHERE chromosome='1' AND position BETWEEN 1000000 AND 2000000;

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

ヒント:

• パーティションプルーニングを活かすため、パーティションキー（例: 染色体）を絞り込む述語を必ず含める。
• EXPLAIN (ANALYZE, BUFFERS) の結果を比較し、テーブルスキャン→インデックススキャンへの切替を確認。
• 統計更新（ANALYZE）とワークメモリ・並列設定でプランの改善余地を検討。

10.2 NoSQLデータベース

ドキュメントDB（MongoDB）:

• JSON形式でのゲノム注釈情報格納
• 柔軟なスキーマ設計
• 分散インデックス

グラフDB（Neo4j）:

• 遺伝子ネットワークの格納
• Cypher言語による経路検索
• リアルタイムグラフ解析

カラムナDB（Cassandra）:

• 時系列遺伝子発現データの高速集計
• 高い書き込み性能
• 線形スケーラビリティ

多様性への対応価値: 生物学データは構造が多様であり、従来のリレーショナルデータベースでは効率的な処理が困難である。NoSQLにより、データの本来構造に適したストレージを選択可能となり、性能と開発効率を向上できる。グラフ構造のネットワークデータ、半構造化された注釈情報、大量の時系列データなど、各用途に最適化されたアーキテクチャを適用することで、総合的なシステム性能を最大化する。

10.3 データウェアハウス

ETLプロセス:

1. Extract: 各種データソースからの抽出
2. Transform: データクリーニング・標準化
3. Load: 統合データベースへの格納

OLAP（Online Analytical Processing）:

• 多次元データキューブ
• ドリルダウン・ロールアップ操作
• リアルタイム集計分析

統合的知識創出の基盤: 生物医学研究では、多種多様なデータソース（ゲノム、臨床、文献、実験データ）の統合解析が重要である。データウェアハウスにより、異なる形式・品質のデータを統一的に管理し、横断的な解析を可能とする。ETLプロセスによる品質保証により、解析結果の信頼性を確保する。OLAP機能により、研究者は多角的な視点からデータを探索し、新たな知見を発見できる。

まとめ

• DB 章の要点は、性能だけでなく「どの成果物を、どの粒度で、誰が再利用するか」を先に決めることです。
• SRR11140744 の変異結果や TCGA-LUAD の研究データを例に、 スキーマ、索引、由来情報を一緒に設計すると後続章で再利用しやすくなります。
• 第11章では、この基盤設計を前提に、個人情報・同意・監査ログの扱いへ進みます。

Source notes / 次の一歩

• 付録F: 第10章の次の一歩
• 付録J: 実在アクセッション一覧
• 付録K: 用語集

次章への橋渡し

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

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

• 入力: 対象データのスキーマ（例: 変異・注釈・サンプル）とサンプルデータ（小規模で可）
• 出力（期待成果物）: インデックス/パーティショニング方針、主要クエリの設計メモ、ETL/集計の設計（最小限）
• 期待ログ（例）: クエリ性能の計測結果（例: EXPLAIN ANALYZE、実行時間）と比較結果が残る

演習

1. genomic_variants、sample_metadata、analysis_run の 3 テーブルを持つ最小スキーマを設計し、主キー・外部キー・索引方針を示せ。
2. SRR11140744 または TCGA-LUAD を題材に、典型クエリを 2 つ定義し、EXPLAIN ANALYZE で計測した結果を比較せよ。
3. 研究用途と将来の臨床用途を分けるために、権限、監査ログ、データ保持期間をどう切り分けるか整理せよ。

具体課題例

• 変異結果を RDB へ格納する案と、注釈 JSON をドキュメント DB へ格納する案を比較する。
• データ更新時に必要なメタデータ（参照配列 ID、ツール版、実行日、責任者）を列として設計する。
• 第12章で臨床レポートへ渡すことを想定し、どの列を匿名化 / 仮名化対象にするかメモを作る。