2011年度生物データベース論　2日目木構造データ

Lecture - Biological Databases: Structured Data Processing

生物データベース論

講義：生物データベース論２日目

2011年9月14日

担当：斉藤太郎（森下研究室） [email protected]

構造を持ったデータの扱い

テーブル構造データ（有田先生）

関係代数、関数従属性（FD）、SQL

木構造データ（今回の講義の内容）

XML, JSONなどが有名

生物のゕノテーション、ゲノムデータ、プログラミング言語で使うオブジェクトなど、あらゆる種類のデータがここに含まれる

講義の内容

木構造データの例

XML, JSON, その他ゲノム情報処理で使われるデータ形式について

木構造データのデータベース作成

木構造データの索引 (interval encoding, ORDPATH)

木構造データの検索

親子、祖先子孫関係の判定

木構造データの字句解析・構文解析（JSONを例に）

木構造データのストリーム処理

木構造データの直列化（Serialization）とその復元（Deserialization）

木構造データを敢えてフラットに表現する

テーブルに分解（データモデリング）、木構造データでの関数従属性

1


XML

XML (eXtensible Markup Language)

タグ <A> … </A> を使って、テキストデータに意味を持たせる

例：

<reference>D. melanogaster</reference>

各々のタグには、さらに属性 (attribute) を複数追加できる

例：

<A id=“1”> (Aはタグ名、idはattribute)

タグを入れ子にして階層構造を表す

XMLの活用例

RSS/Atom

Webページの更新情報を配信

例えば、Nature誌の更新情報などが自動的に届く

BioDAS

ゲノム情報の取得。

配列、遺伝子情報、各種ゕノテーション等

GMail

RPC通信

リモートのサーバー上からメールのデータをブラウザに送信する

GMailのメール表示が高速なのは、あらかじめメールのデータをブラウザに読み込ませているため

XMLの中に、serialize (後で説明）されたオブジェクトデータを埋め込んで通信している

染色体名のリストをDASから、XMLで取得した例

2


XMLデータは木構造を持つ

city

name

“Jeffrey”

item

“J-001”

“New York”

“Notebook”

id

“2002/02/13”

“50

”

order

num

customer

order

date

“3

”

oid

item

“Blank Label”

“2002/02/10”

“100”

num

date

“1”

oid

status

“delivered”

<customer id=“J-001”>

<name> Jeffrey </name>

<city> New York </city>

<order oid=“3”>

<item> Notebook </item>

<date> 2002/02/11 </date>

<num> 50 </num>

</order>

<order oid=“1”>

<item> Blank Label </item>

<date> 2002/02/10 </date>

<num> 100 </num>

<status> delivered </status>

</order>

</customer>

3


ゲノム情報処理で使われる木構造データフォーマット

BED format

主に遺伝子領域の記述に使われる

ヘッダー行データの名前、説明など

データの行空白区切りで、chr, start, end, name, score, strand, thickStart, thickEnd, rgb, blockCount, blockSizes, blockStartsの情報を記述

thickStart, thickEndは、CDSの開始・終了範囲、blockCount, blockSizesなどはexonの数、大きさの記述に使われる

WIG format

棒グラフなどのデータの記述に使われる

最近では、ChIP Seqのデータになど応用される

http://genome.ucsc.edu/FAQ/FAQformat.html より抜粋

4

http://genome.ucsc.edu/FAQ/FAQformat.html


ショートリード用のデータフォーマット

FASTQ フォーマット

リード名、塩基配列、+、各塩基のQuality valueのASCII値

次世代シーケンサー Illumina Hiseq2000では、 1runで数億本ものリードが読まれる

SAMフォーマット

詳細は仕様に（5ページほどなので簡単）

http://samtools.sourceforge.net/SAM1.pdf

BAMフォーマット

SAMフゔルを圧縮したもの（5分の1程度に圧縮できる）

各リードがマッピングされた染色体上の位置を表す

ゕランメントの状態をCIGAR文字列で表現

（塩基数）（タプ）の羅列

タプの種類

M: match or mismatch

I: insertion to reference sequence

D: deletion from reference sequence

S: soft-clipped

e.g., chimeric read, adapter sequence, etc.

N: gap

P: padding

H: hard-clipped

e.g., split alignment part

@SAMPLE1.L1.5449 ATGGAGGTCATCACCTACAAGCTCGTCACACCATCCGTCGTCTCTGAACGTCTGAAGGTTCGTGCTTCATTGGCCA + IIIIIIIHIIIIIIIIIIIIIIIIIIIIIIIIIHIIIGIIEHHHFHHIIIFIHHGGHHDEIGDGGGEGEGEDDGFI @SAMPLE1.L1.5450 GTTAAAAAGCCCGTAGTTGGATCTAGGTTACGTGCCGCAGTTCGCAATTTGCGTCAACTGTGGTCGTGACTTCTAA + HHHHHGGHHHHHHHHHHHHHDHHHHHHHHHHHDHHHHHHHBGGEGFFHHHHHHGHEEFHHBHF<EECE@BECBEA@ @SAMPLE1.L1.5451 CAGAATGACTGTCGCTCACATGTGGTACGATGAAACCATCCATGAGTGTGATACCACCGAAACTCAAACCAGCCAG +

5






SAMフォーマットで表現されたショートリードゕランメントの可視化の例

UTGB (University of Tokyo Genome Browser) より http://utgenome.org/

6


木構造データをデータベースに格納する

様々なフォーマットのデータがあるが、どれも木構造として考えることができる

木構造データのデータベース化

用途によって様々なゕプローチがある

木構造専用のnative databaseを使う、あるいは自作する（今回は説明しない）

既存のnative XML databaseを利用

あまりこれといったものが見当たらないのが難点

関係データベース relational databaseに格納する

木構造をテーブル型に変換する

interval encoding

ORDPATH

木構造をオブジェクトにマッピングする

木構造データの構文解析ー＞ストリーム処理－＞オブジェクトへのマッピング

オブジェクトー＞テーブルに分解－＞RDBに保存

あるいは、オブジェクトをserialize（直列化。バナリー形式に変換）してcolumnに保存する

7


木構造の区間表現

Interval Encoding

木構造を枝を使わずに表現する手法

各ノードを(start, end)の区間で表す

区間の包含関係

Ancestor－Descendantの関係に対応

Parent-Childの対応を見るためには、階層の深さ(level)の情報も保持する

タグの種類ごとにノードを分類しておけば、特定の子孫のノードをすばやく検索できる

例

Root以下のCノードの検索

Aノードの子孫であるDノードの検索

利点

SQLで検索できる

startの値が、深さ優先順になっている

B+-treeに格納しやすい

endの値は、post orderになっている

欠点

ノードを追加していくと、区間が枯渇してしまう

8

10 1000

20 100 120 190 230 300

A

(20, 100)

Root

(10, 1000)

B

(120, 190)

A

(230, 300)

C

(30, 35)

D

(40, 50)

C

(240, 260)

level 0

level 1

level 2


更新に強い木構造のencoding

ORDPATH

更新に対応したラベルの付け方

各ノードに対し、階層上での位置がわかるラベルを付ける

ラベルの付け方

兄弟ノードに奇数を左から順に割り当てていく

子のラベルは

「親のラベル . 兄弟間でのラベル」の形式で連結する

親のラベルがprefixになる

親子関係、祖先ー子孫関係の判定がラベル同士の比較で可能

ORDPATHの連結の段数が、ノードの深さに対応

新しいノードを挿入するとき

挿入したい位置に奇数がもうないときは、間の偶数を一段はさんで、奇数を１から割り振る

ノードの深さを調べる場合、偶数の段はスキップする

ORDPATHの利点

ラベルの付け方が明確（区間表現は任意性がある）

更新が容易

ノード間の全順序が保たれる

深さ優先探索順

次に説明するprefix free encodingで、B+-treeに格納

ORDPATHの欠点

階層が深くなると、各ノードのラベルサズが大きくなりすぎる

SQLだけで階層構造の検索が記述できない場合がある

9

A

1.1

Root

1

B

1.3

A

1.5

C

1.1.1

D

1.1.3

C

1.5.1

A

1.1

Root

1

B

1.3

A

1.5

C

1.1.1 D

1.1.3

C

1.5.1

C

1.1.2.1


ORDPATHのprefix-free encoding

ORDPATH

各段のラベルを(Li, Oi) の組で表して連結

Li：次に続くbit stringの長さ

Oi: i段の番号を表すbit string (右表を使う）

例

1.1 = 01001 01001

1.3 = 01001 01011

1.1.3= 01001 01001 01011

1.9 = 01001 1000001

2.1 = 01010 01001

prefix free encoding

Liのbit stringが他のLi bit stringと衝突しない

ORDPATHのbinary stringをソートすると、木構造の深さ優先順と同じになる

10


木構造のデータをrelational databaseに格納する

木の各ノードを１レコードに対応させる

ORDPATHの代わりにstart, end, depth を

列に使ってもよい

練習問題

階層構造を使った以下の検索をSQLで記述せよ

BOOKノード以下にあるTITLEノードをすべて取得する

解答

SELECT * FROM XMLTable t1, XMLTable t2 WHERE t1.TAG = “BOOK” AND t2.tag = “TITLE” AND t1.ORDPATH is_prefix_of t2.ORDPATH t1とt2は同じテーブル（右図）を参照している

ORDPATHでのancestor-descendant/parent-childの検索は、prefixの判定機能が実装されている（あるいは追加できる）DBMSでないと実行できない

(start, end, depth, tag)のテーブルを使った場合、SQL文はどのようになるか？

11


参考：B+-treeを使って多次元データを検索する

空間充填曲線（space-filling curve）を用いるとXMLの(start, end, level, tag) など多次元の情報を１つのB+-treeで検索できるようになる

XMLの場合には、z-curveが使いやすい bit-interleave 操作で空間充填曲線上のンデックス(z-

order) が計算できる

z-orderをキーにして、B+-treeに各ノードのデータを格納

(start, end)の区間を2次元にマップすると子孫ノードは右下、祖先ノードは左上の長方形領域に包含

される

B+-treeのリーフを飛び飛びにscanして、多次元領域検索を行える

12

start

en

d

z-curve and z-order

bit interleave function

multidimensional range query


木構造データの汎用性

BED, WIG, FASTQ, SAMのデータはすべて木構造で表現できる

それなのに、なぜXML以外のフォーマットが使われるのか？

現実的な課題

処理速度

XMLより、タブ区切りデータの方が速く読み書きできる

データをコンパクトに表現できるか？

XMLは次世代シーケンサーのように大きなデータのやり取りには全く使われていない

記述、出力のしやすさ

タブ区切り形式でデータを出力するのは簡単。ただし、同時に含めるべき情報（サンプル名、更新履歴、どのような処理で生成されたデータなのか、などの重要な情報）が欠落している弊害も

構文解析のしやすさ

lexer/parserを書く必要があるか、splitするだけで使えるか

共同作業のしやすさ

様々なプログラミング言語で扱えるか？（仕様がシンプルだと、実装者が現れやすい）

XMLは複雑な仕様にも関わらず、時代の波にうまく乗れたため、各言語で構文解析器が実装されてきた（1997年以降～）

可読性

フラットなフォーマットだと、一画面に情報を詰め込みやすい

コマンドランでの扱いやすさ

この講義での目的

様々なフォーマットで記述されていても、すべて木構造データとして汎用的に扱う枠組み

13


参考：コマンドラインでのデータ処理の例

例１：SAM フォーマット中のリードの検索

SAMフォーマットではデータがタブ区切りで記述されている

マップされたリードのうち、mapping quality > 0 かつ、chr22にマップされたものを取り出す

cat sample.sam | grep –v “^@” | awk ‘$5 > 0 && $3 ~ /chr22/’

@で始まる行は、ヘッダ行なので取り除く

BAM fileの場合

catの代わりに、samtools viewコマンドを使う

例２：特定の名前のリードを、gzip圧縮されたfastqフゔルから取り出す

zcat sample.fastq.gz | grep –w –A 3 “SAMPLE1.L1.5449”

-w は単語単位でのマッチ、-A 3は、マッチした箇所の後の3行分まで表示するオプション

例３：タブ区切りデータのテーブルの第4列に含まれる値の種類を調べる

cat input.tab | awk ‘{ print $4; }’ | sort | uniq

awk（あるいはcut）で4列目のデータを取り出し、ソートして重複除去をおこなう

14


JSON

JSON (JavaScript Object Notation)

構造を持ったデータの通信フォーマットとして広く活用されている

多くのWebゕプリケーションの裏側で使われている

これも木構造

構文解析が容易。多くのプログラミング言語でparserが実装されている

JSONのフォーマット

Object

{ “key1”:value1, “key2”:value2, … }

波括弧で囲む. keyとvalueはコロンでつなぎ、key-valueの組はコンマで連結

Array

[value1, value2, … ]

鍵括弧で囲む. valueはコンマで連結

value type

string （文字列）

double quotation (“…”) で囲む

number

integer (整数), real (浮動小数点数）

boolean

true or false

null

Object, Arrayもvalueに成り得る

例：（遺伝子のエントリ）

{“id”:1, “gene name”:”gene A”, “strand”:”+”, “start”:11617, “end“:16804, “exon”:[{“start”:11617, “end”:11689}, {“start”:16472, “end“:16804}]}

15


JSONの字句解析 (lexical analysis)

JSONデータを木構造に変換するためには、まずテキストデータの構文解析を行う

例： JSONの文字列

{“id”:1, “name”:”gene A”}

字句解析 (lexical analysis) - トークン(token)に分割

文字列トークン型パターン State

{ LBrace 一文字マッチ初期状態 {か[のみを受理

“id” String ”[^”]*” (正規表現) key or end stringか}を受理

: Colon 一文字マッチ colon colonのみを受理

1 Integer value type全て value value typeなら受理

（integer/string/boolean/null/array/object）

, Comma 一文字マッチ next or end commaか}を受理

“name” String ”[^”]*” key stringのみを受理

: Colon 一文字マッチ colon

”gene A” String ”[^”]*” value

} RBrace 一文字マッチ next or end

トークン

トークン型

文字列

行番号、文字列のstart, end位置も保持しておくとデバッグに便利

16


Lexerの実装

テクニック

string中以外の空白 [ ¥t¥n¥r]+ (white space token)は読み飛ばす

正しくないデータが入力されたときのために、データをどこまで読んだか（行、列番号）を管理しておく

改行文字 ¥n (LF. Unix), ¥r¥n (CR+LF, Windows), ¥r (CR, 昔のMac) が出現したら、行番号を+1

改行文字が多様なのはタプラター時代の名残

LF: line feed （１行分紙を巻く）、CR: carriage return （行頭までヘッドを移動）

字句解析では正規表現に対応するオートマトンを作って考える

練習問題

テキストフゔルの内容を入力文字列として受け取り、３種類の改行文字の出現を認識できる決定性オートマトンを作成せよ

改行コードを認識するstateに到達したら、改行tokenを出力

括弧の入れ子やdouble quotationなどの対応関係を見る必要がある場合、オートマトンの能力(正規表現と同等)を超えるので、括弧等をスタックに積む(push)、取り出す（pop）機能を付加したオートマトン (push down automaton)を使う

スタックの状態（空の場合とそうでない場合、など）に応じて、遷移先のstateを切り替えられる

練習問題

以下のScheme文法に従った文字列を受理する決定性プッシュダウンオートマトンを作成せよ

S := expr

expr := ‘(‘ op expr expr+ ‘)’ | number

op := ‘+’ | ‘-’ | ‘*’ | ‘/’

number := [1-9][0-9]*

入力文字列の例

(+ 1 (* 2 3) (/ 10 5))

JSONの場合、Stateを管理しなくてもlexerは実装できるが、凝った文法を扱う際には必要

XMLの場合：タグの中身か、それ以外で、文字列の認識パターンが変わる

各種プログラミング言語：コメント文の内部とそれ以外。ポンタのマーク（＊）なのか、掛け算operator（＊）なのか。

17


JSONの構文解析 (syntax analysis)

例： JSONの文字列の構文解析

{“id”:1, “name”:”gene A”}

構文解析 (parsing) – トークン列をパターンルールにマッチさせる

字句解析で得られるトークン列： LBrace, String(“id”), Colon, Integer(1), String(“name”), Colon, String(“gene A”), RBrace

JSONの構文パターンルール（抜粋） Object := LBrace (KeyValue (Comma KeyValue)*)? RBrace

Array := LBracket (Value (Comma Value)*)? RBracket

KeyValue := String Colon Value

Value := String | Integer | Boolean | null | Object | Array

18


再帰下降型構文解析器 recursive descent parser

再帰下降型構文解析

実装が簡単

パターンごとに構文解析する関数を作成

parseObject, parseArray, parseKeyValue, parseValue, …

各関数で、再帰的に他のパターンの構文解析関数を呼び出す

parseObject

match(LBrace) // 次のトークンがLBraceでなければエラーを報告

loop:

parseKeyValue

if nextToken is Comma, consume(Comma), then continue loop

look aheadを使う

match(RBrace)

parseKeyValue

match(String)

match(Colon)

parseValue

構文解析では、どの関数を呼び出すか決めるために、1トークン先読み（look ahead）機能を実装する

matchではトークンを読み進めるが、look aheadでは読み進めない

19


構文木の作成

{“id”:1, “start”:11617, “end“:16804, “exon”:[{“start”:11617, “end”:11689}, {“start”:16472, “end“:16804}]}

parseObject, parseArray では、各々が担当する部分木をreturn文で返す

object

id:1 start:11617 end:16804

array

exon

object

start:11617 end:11589

object

start:16472 end:16804

20


構文解析の参考資料

Lexer/Parser生成器

Lex/Yacc

古くから使われている

Flex/Bison

Lex/YaccのC++対応版

ANTLR

多言語でlexer/parserを作れる。便利だが、大規模データ用にはやや処理が遅い

参考図書

Compilers: Principles, Techniques, and Tools

Second Edition

The Definitive ANTLR Reference

ANTLR3で記述したJSON lexer/parserの例

21


ストリーム処理

再帰下降型構文解析では難しいケース

データが巨大な場合

例：5千万エントリを含むSAMフゔル

構文パターン SAM := Header* ReadAlignment*

SAMオブジェクトの配下に、ReadAlignmentのオブジェクトが5千万個。構文木がメモリに収まりきらない

参考：次世代シーケンサー (Illumina Hiseq2000) では、１runで数億本のリードが読める

FASTQフゔルは1 run分で100GBほど。SAMフゔルは150GB程度になる


限られたバッフゔ上で、巨大な入力データを処理する

音楽、映像データなどのWeb配信などは基本的にストリームの形で処理される

例：SAMフゔルのストリーム処理

file reader -> parser -> object handler とデータが流れる

parser

SAMフゔルを一行ずつ読み込む -> Header または ReadAlignmentオブジェクトを出力（emit）

object handler

HeaderかReadAlignmentオブジェクトを受け取る関数を用意

handleHeader(…)

handleReadAlignment(…)

22


ストリーム処理の２つの形態：Push Parser

Push Parser

parserが event handlerを呼び出す（前頁の形態）

parser –(pushes events to)-> event handler

プログラム例 parser.parse() {

void handleHeader(Header h) { // parserがこの関数を呼び出す

// ヘッダの処理

}

void handleReadAlignment(ReadAlignment r) { // parserがこの関数を呼び出す

// ゕランメントのデータを処理

}

}

利点：

複数のevent handlerをパプラン化して使う場合に、CPUの無駄が少ない parser -> handler1 -> handler2 -> … 各handlerが次のhandlerにデータを渡す

push modelは並列データベースでクエリの高速処理のためによく利用される

欠点：

parserの動きを制御するのがやや難しい。parserの動きを途中で止めたり、一部のデータを読み飛ばす（フゖルタリング、エラー処理時）など。

23


ストリーム処理の２つの形態：Pull Parser

Pull Parser

データ処理側(event handler) がparser.next()を呼び出して、逐次データを取り出す

event handler <-(pulls events from)- parser

プログラム例 for(Event e; (e = parser.next()) != EOF; ) { // parserからデータを取り出す

// e を使って、何らかの処理を行う swtch(e.type) { case Header: … // ヘッダの処理 case ReadAlignment: … // ゕランメントのデータを処理

} }

利点：

Parserの動きを制御しやすい（再帰下降parserと組み合わせたり、一部のデータを読み飛ばすなど）

Pull parserがあればpush parserを実装するのは簡単

逆に、push parserをpull parserに変換するには、プログラムの並列化が必要（練習問題）

欠点

複数の処理をパプラン化する際、event handlerごとにevent bufferを作り、各々pullする必要があるので無駄が多い

参考：

GoogleのMapReduce：分散処理部分でpull model を使っている（詳しくは笠原先生の回に）

24


参考：MapReduce

output file (s)

input file

f f f

chr1 chr2

chr3

chr2 chr3 chr1

chr2 chr3

hashing records

chr1 chr2 chr3

sort and merge

Split the data file into several chunks

Map

Reduce

…

25

Proposed by Google [SOSP2004]

An open-source implementation: Apache Hadoop

Map Apply the function f to each chunk of the input

records

Function f produces (key, value) pairs

Gives program semantics for parallelization

The evaluation order of the records does not matter

Reduce Receives the sorted output from the map function.

pull model


木構造からオブジェクトへのマッピング

プログラミング言語で使うオブジェクトと木構造を対応付ける（Object-Tree Mapping)

object

id:1 start:11617 end:16804

array

exon

object

start:11617 end:11589

object

start:16472 end:16804

Gene

Exon Exon

26

class Gene { int id string name string chr int start int end List<Exon> exon }

class Exon { int start int end }


オブジェクトストリームの生成

startObject g = new Gene()

key:id, value:1 g.id = 1

key:start, value:11617 g.start = 11617

key:end, value:16804 g.end = 16804

key:exon

startArray e = new List<Exon>()

startObject e0 = new Exon()

key:start, value:11617 e0.start = 11617

key:end, value:11689 e0.end = 11689

endObject e.add(e0) // 配列にExonを追加

startObject e1 = new Exon()

key:start, value:16472 e1.start = 16427

key:end, value:16804 e1.end = 16804

endObject e.add(e1)

endArray g.exon = e

endObject emit(g) // Gene オブジェクトを出力

27

object

id:1 start:11617 end:16804

array

exon

object

start:11617 end:11589

object

start:16472 end:16804

Gene

Exon Exon




オブジェクトの直列化

生物情報学では解析の数だけオブジェクト（型定義）があるといっても過言ではない

プログラムの解析結果をいかに保存するか？

Object Serialization

オブジェクトのデータをバト列に変換する

主な用途

デゖスク・ネットワークにデータを書き出す

データベースに保存する

簡単な方法: オブジェクト -> 木構造データに変換（XML/JSON など）

オブジェクトの各パラメータごとにノードを出力

構造を持った型のパラメータは、再帰的に処理

function toJSON(Object) { output “{“ for each parameter p in Object output “(p.name):” if p is primitive type // int, string, float, etc. output “(p.value)” else if p is array type output “ [”

for each element e in p { output(“, “) if e.index == 0; toJSON(e) } output “]”

else

toJSON(p)

output “}”

}

出力例

{“id”:1, “name”:”gene A”, … , “exon”:[{“start”:…, “end”:…}, {“start”:…, “end”:…} ] }

28




スキーマを使ったオブジェクトの直列化

JSONに出力する形式

オブジェクト毎に、毎回同じパラメータ名を出力しており冗長

よりコンパクトに表現できないか？

オブジェクトの型定義からスキーマを構成

Gene (id:int, name:string, chr:string, start:int, end:int, exon:Exon*)

Exon (start:int, end:int)

パラメータ名を出力せずにデータを連結したレコードを作成

| type id | param1 | param2 | … | param k |

各パラメータは型ごとにシリゕラズ

int -> 4 bytes or 可変長整数表現（固定長レコード）

string -> 文字列の長さ、バト列（可変長レコード）

配列 -> 配列の長さ、各エントリのレコード …

参考

serializationのためのツールはいくつかある

Google Protocol Buffers, MessagePack, Boost::Serialize、Ruby on Railsなど

29




Large Dataのデータベース化

WIGデータ

(ゲノム中の座標, value) の組がゲノムワドに存在

ヒトゲノムなら30億エントリが必要

これだけのデータをさばけるRDBMSは少ない

ゲノムをビンに分割

例えば、ヒトゲノム30億塩基を10kサズのビンに分割すると、30万エントリで済む

(bin start, [bin start, bin start + 10k) の区間にあるグラフデータ) の形でエントリを保存

bin startの列に対して、B+-treeの索引を構築

グラフのデータは圧縮するとさらに効率的

gzip （圧縮率が良いが、速度がやや遅い）

snappy （圧縮率は悪いが、伸長速度が高速。データベース向き）

デゖスクI/Oのコストと、CPUを使う圧縮・伸長計算コストとのトレードオフ

現在デゖスク（HDD, SSDなど）では、圧縮するのが良い戦略

30


木構造を持ったデータをフラットに表現する

木構造データを敢えてテーブルで表現することで、SQLによる検索が行えて便利な場合がある

練習問題

上のデータを、geneとexonの２つのテーブルを用いて表現せよ

geneが複数ある場合でも、geneとexonの対応関係が正しくなるように注意

それらのテーブルを用いて、各gene中のexonの数、exonの長さの平均値を求めるSQL文を作成せよ

group by文を使うとよい。Excelのピボットテーブルも同等の機能

31

object

id:1 start:11617 end:16804

array

exon

object

start:11617 end:11589

object

start:16472 end:16804

Gene

Exon Exon


区間の交差判定

問題： n本のショートリードを重なりがないように並べよ

32


33

区間の交差判定

ゲノム情報処理で頻出する問題

重なっているショートリードを列挙する

区間が遺伝子領域と重なっているか？

単純な実装

全リードとの交差を調べる O(N)

区間を2次元にマップする

区間の始まりをｙ軸、区間の終わりをｘ軸とした2次元平面上の点に区間を対応させる

例えば、区間L2 [4, 6]と交差する区間は、左図の、[4, N] × [-∞, 6]の領域を調べれば数え上げられる

Priority Search Treeで高速に列挙できる

end

start

0

1 8 2 3 4 5 6 7

L1 L2

L4

L5

L3

1 8 2 3 4 5 6 7

1

8

2

3

4

5

6

7

(4, 6)

L1

L2

L3

L4

L5


34

Priority Search Tree

X

Y

0

Priority search tree

rootは最小のyの値を持つノード

各ノードに対応する区間を[i, j]とすると

左の子は区間 [i, floor((i+j)/2)]

右の子は区間 [floor((i+j)/2 )+1, j] に対応する。

各ノードは、それぞれの領域で最小のyの値をもつノードとなる

性質

x方向にはbinary search tree

木の高さは、log n

y方向では、親ノードのyは必ず子ノードのyより小さい (heap)

記憶容量 O(n)

構築時間 O(n log n)

[x1, x2] x [0, y] の範囲のrange query

O(log n + k) で検索できる

kは領域に含まれるノード数

[x1, x2] の区間に含まれる部分木は高々2log n個

34


まとめ

木構造データは汎用的

XML/JSON/Object その他、種々の生物情報のデータフォーマットを含む

木構造データを関係データベースに格納する手法

interval encoding / ORDPATH

木構造データの処理

構文解析


オブジェクトへのマッピング（Deserialization)

オブジェクトのSerialization

巨大データの分割

木構造データを、フラットに表現する

区間データの扱い

Priority search tree

遺伝子領域、ゲノム上のゕノテーション、リードゕランメントの交差判定


発展：木構造の組み方には任意性がある

遺伝子、ショートリードなど同じ染色体上にあるものが多い

chrの情報は上位のノードに配置する方が、小さなデータとして表現できる

しかし、オブジェクトの定義と、木構造の階層が一致しなくなる

構造の組み方が多様な場合

どのようにオブジェクトにマッピングするか？

オブジェクトに対応するノード数最小の木構造を生成するゕルゴリズム

36

object

id:1 start:11617 end:16804

object

id:1 start:11617 end:16804

object

chr:22

array

gene


2011年度 生物データベース論 2日目 木構造データ

Education

2011年度生物データベース論　2日目木構造データ