シングルセル解析用のデータベース作成 ~テーブル定義編~

データサイエンティストに求められるスキルとして、データベースを活用したデータハンドリング技術が挙げられます。これはビッグデータ解析を行う上ではExcelでは行数不足が起こり得るということもありますし、何より全てのデータがメモリに収まりきらないことがあるので、データベースサーバーからデータを逐次取得する技術が必要だからだと考えられます。

これまでの老化解析で使ってきたシングルセルデータも、数が増えてくればH5ADファイル単位でのデータ管理では回らなくなってしまいます。これをデータベース化することができれば、データ自体はストレージに格納しつつ、クエリを入力することで必要なデータを検索してメモリに送り込むことができます。


本記事では、シングルセル解析のデータを格納するためのデータベース設計を行います。データベースシステムは色々存在しますが、今回は一番有名なリレーショナルデータベース(RDB)方式で設計を行いました。この記事のようにテーブル定義すれば、おそらく様々なシングルセルデータを格納できるのではないかと思います。


第一正規形テーブルの作成


まずはデータベースに格納するためのデータを第一正規形テーブルとして用意します。


遺伝子発現データをRDB用に整形する

シングルセルデータは、基本的に遺伝子ID(行)と細胞ID(列)の二次元行列であり、それぞれの遺伝子発現量(カウント)が格納されています。しかし、RDBは二次元行列のようなデータ構造とはなっていないので、RDBで読み込めるようにデータを整形します。

下画像の左テーブルが整形前、右テーブルが整形後です。


f:id:emoriiin979:20210205102534p:plain


RDBではカラム(列)ごとにデータを持つため、このように整形します。


その他の必要なデータを追加する

次に、ここで作成したテーブルをベースとして、細胞タイプなどの他に必要なデータを追加します。最終的に、下画像のような第一正規形テーブルが完成します。


f:id:emoriiin979:20210205102905p:plain


テーブルを第三正規化する


これで必要なデータが全て集まりましたが、このデータを一つのテーブルに格納すると後のデータ管理が非常に面倒になります。例えば、動物種の「マウス」という名前を「Mus Musculus」に変更したいときは、テーブルに存在する全20データの動物種を変更しなければならなくなります。そうすると、変更が面倒なだけでなく、変更し忘れなどのトラブルも起こりえます。

そうならないように、第一正規形テーブルはそのまま使わずに、いくつかのテーブルに分割します。これを第三正規化と呼んでいます。


それでは、以下よりどんどんテーブルを分割していきます。


研究

まず、「研究タイトル」が同じものが重複しており、こちらは後に変更される可能性が高いので、別のテーブルとして管理します。


f:id:emoriiin979:20210205103706p:plain


このように、研究IDを設けて別テーブルを作成すれば、以後は研究テーブルの「研究タイトル」を一つ変更するだけでよくなります。


遺伝子

次に、遺伝子テーブルを作成します。遺伝子IDと紐づくのは遺伝子名と遺伝子IDを提供しているブラウザ(Ensemblなど)です。これらを遺伝子IDから参照できるようにすれば、カウントデータと紐づけるのは遺伝子IDだけでよくなります。


f:id:emoriiin979:20210205104154p:plain


なお、遺伝子IDについては研究IDのように1からの通し番号ではなく、遺伝子ブラウザから提供されているものが一意で分かりやすいので、そのまま使っています。


遺伝子ブラウザ

遺伝子ブラウザ名も今後変わらないとも限らないので、テーブルを分割して管理できるようにします。


f:id:emoriiin979:20210205104619p:plain


細胞

ここからは細胞IDに紐づくデータを管理するテーブルを作成していきます。まずは、細胞データをカウントテーブルから完全に隔離させます。


f:id:emoriiin979:20210205104926p:plain


これで、カウントデータと紐づく遺伝子データと細胞データは全てIDに置き換わりました。あとは細胞テーブルの分割を進めて完了です。


組織

まずは細胞がどこから採取されたのかを示す組織データを隔離します。組織名が変わることはまず無いと思いますが、組織テーブルがあった方が必要な組織が網羅されているか見やすいかなと思ったので用意しました。


f:id:emoriiin979:20210205105431p:plain


組織の親要素として「動物種」があります。こうすると動物種が増えるごとに組織を増やさなければならないので面倒になるのですが、これが無いと例えばショウジョウバエの組織を追加したときにごちゃごちゃになりそうな気がしたので、ひとまずはこのような設計になっています。


動物種

続いて、動物種のテーブルも作成します。前述の通り、動物種名は変更されることがあり得るからです。


f:id:emoriiin979:20210205105913p:plain


細胞タイプ

最後に、細胞タイプと細胞サブタイプです。当然ながら両者は親子関係となっており、加えて細胞ごとに細胞タイプと細胞サブタイプが両方とも定義されているので、少し面倒な設計ですが、基本は組織と動物種での設計と同じです。

まずは細胞サブタイプのテーブルを作成します。


f:id:emoriiin979:20210205110404p:plain


組織テーブルの時と同じように、親要素として細胞タイプIDを付与しています。

続いて、細胞タイプのテーブルを作成します。


f:id:emoriiin979:20210205110620p:plain


こうすることで、名称の冗長性が完全になくなり、何か名称を変更したくなったら各テーブルにアクセスすればよくなりました。


ER図を作成する


これで必要なテーブルの設計が完了しました。ただし、上記のテーブル情報だけではテーブル間の関係性が分かりづらいので、それらをER図に図示しました。


f:id:emoriiin979:20210205110849p:plain


最終的に、このようなデータベース設計となりました。後はRDBを動かすためのシステム(MySQLなど)を選定して実際にデータを流し込めば、シングルセル解析用のデータベースが完成します。


まとめ


本記事では、これまでの解析で用いてきたシングルセル解析データをリレーショナルデータベース(RDB)に格納するために、データベースのテーブル設計を行いました。

感想としては、研究テーブルの位置関係が本当にここで良かったのかが未だに怪しいということと、やはり細胞タイプ・サブタイプのテーブル関係がややこしくなってしまったので、いずれはもっと管理しやすい設計手法を身に付けたいという所感です。


調べてみたところ、遺伝子発現データをRDBで管理するといったことがあまり行われていないように見えたので、もしかすると本記事は割と貴重な資料となり得るかもしれません。もちろん、本記事のテーブル設計手法が正しいとも限らないですし、データによっては新たに追加すべき項目も存在するかもしれないので、そこは臨機応変に修正してみることをお勧めします。


以上です。