gmod_bulk_load_gff3.plp - クラウドでオンライン

プログラム：

NAME

$0 - gff3 ファイルを Chado データベースに一括ロードします。

SYNOPSIS

% $0 [オプション]
％ 猫| $0 [オプション]

OPTIONS

--gfffile GFF3 を含むファイル (オプション、読み取り可能)
標準入力から)
--fastafile シーケンスをロードする Fasta ファイル
--organism データの生物
(GFF のorganism=xxxから読み取るには、値「fromdata」を使用します)
--dbprofile データベース構成プロファイル名
--dbname データベース名
--dbuser データベースのユーザー名
--dbpass データベースのパスワード
--dbhost データベースホスト
--dbport データベース ポート
--analysis GFF データは計算解析によるものです
--noload 一括ロード ファイルを作成しますが、実際にはロードしません。
--nosequence シーケンスがファイル内にある場合でもロードしません。
--notransact データベースのロードに単一トランザクションを使用しません。
--drop_indexes ロードを開始する前に、影響を受けるテーブルのインデックスを削除します。
ロードが完了したら再作成します。 一般的に
パフォーマンスには役立ちません。
--validate 挿入を試みる前に SOFA 条項を検証します (
スクリプトの起動が遅くなります。デフォルトではオフになっています)
--ontology その他の Ontology_terms を処理するための指示を与える
--skip_vacuum 挿入後のテーブルのバキューム処理をスキップします (デフォルト)
--no_skip_vaccum テーブルのバキューム処理をスキップしません
--inserts COPY FROM STDIN の代わりに INSERT ステートメントを出力します。
--noexon CDS 特徴をエクソンに変換しません (それでも作成されます)
ポリペプチドの特徴）
--recreate_cache uniquename キャッシュが再作成されます。
--remove_lock ロックを削除して、新しいプロセスの実行を許可します。
--save_tmpfiles データベースのロードに使用される一時ファイルを保存します。
--random_tmp_dir ランダムに生成された tmp ディレクトリを使用します (デフォルトは
現在のディレクトリを使用します)
--no_target_syn デフォルトでは、ローダーは targetId を
機能の同義語リスト。 この旗は
これを無効にします。
--unique_target ターゲット ID の一意性を信頼します。 ID は大文字と小文字が区別されます
センシティブ。 デフォルトでは、新しいターゲットの一意の名前
は「TargetId_PrimaryKey」になります。 この旗をもって、
それは「TargetId」になります。 さらに、その名前は、
作成されたターゲットは、
機能の名前。
--dbxref 最初の Dbxref 注釈のいずれかを使用します。
プライマリ dbxref (feature.dbxref_id に入る)、
または、オプションの引数が指定された場合は、最初の
データベース部分 (つまり、「:」の前) を持つ dbxref
指定されたパターンと一致するものが使用されます。
--delete データベースにフィーチャを挿入する代わりに、
次のように GFF 行を使用してフィーチャを削除します
CRUD=delete-all オプションがすべての行に設定されました
(以下の「GFF を介した削除と更新」を参照してください)。 の
ローダーは続行する前に確認を求めます。
--delete_i_really_mean_it
要求しない点を除けば、--delete と同様に機能します。
確認のため。
--fp_cv 機能プロパティで制御される語彙の名前
(デフォルトは「feature_property」です)。
--noaddfpcv デフォルトでは、ローダーは GFF 属性タイプを次のように追加します。
新しい feature_property CV 用語が欠落している場合。 この旗は
それを無効にします。
** dgg 注: このフラグの名前を変更する必要があります: --[no]autoupdate
Chado テーブルの場合 cvterm、cv、db、organism、analytics ...

--manual 詳細なマニュアルページ
--custom_adapter Bio::GMOD::DB::Adapter のカスタム サブクラス アダプターを使用します。
アダプタへのパスを引数として指定します
--private_schema データを非公開スキーマにロードします。
--use_public_cv 非パブリック スキーマにロードする場合、任意の cv をロードし、
cvterm データをパブリック スキーマに追加する
--end_sql データのロード完了後に実行する SQL コード
--allow_external_parent
親タグが現在の ID 以外の ID を参照できるようにする
GFFファイル

「db」で始まるすべての引数とorganismは次のように指定できることに注意してください。
デフォルトは Bio::GMOD::Config で、「make install」の実行時にインストールされます。 こちらも注意
オプション dbprofile と他のすべての db* オプションは相互に排他的です (指定した場合)。
dbprofile では、他の db* オプションは使用されないため、指定しないでください。

DESCRIPTION

仕様をより厳密に制御するため、データファイル内の GFF はバージョン 3 である必要があります。
管理された語彙の使用。 したがって、フィーチャ タイプの名前は正確に一致する必要があります。
Sequence Ontology Feature Annotation (SOFA) にあるものであり、同義語や
アクセッション番号 (SO アクセッション番号は、このバージョンの将来のバージョンでサポートされる可能性があります)
脚本）。

##sequence-region ディレクティブは、
GFF3 ファイルの参照シーケンス。 ##sequence-region ディレクティブは表現的ではありません
シーケンスがどのような種類のものであるかを定義するには十分です (つまり、それは染色体なのか、コンティグなのか、それとも
腕など？） GFF ファイルがこの方法で ##sequence-region ディレクティブを使用する場合は、次のことを行う必要があります。
それを完全な GFF3 行に変換します。 たとえば、次の行があるとします。

##シーケンス領域 chrI 1 9999999

次に、次のように GFF3 行に変換する必要があります。

chrI 。 染色体 1 9999999 。 。 。 ID=chrI

認定条件 GFF3 is 保存され in チャド
GFF3 データがどのように chado に保存されるかをまとめたものは次のとおりです。

カラム 1 (参照配列)
フィーチャーの参照シーケンスは、フィーチャーの srcfeature_id になります。
その機能の featureloc テーブル。 その featureloc には通常、ランク XNUMX が割り当てられます
この機能に関連付けられた他の場所がある場合 (たとえば、一致の場合)
feature)、他の場所には、次の値よりも大きい featureloc.rank 値が割り当てられます。
ゼロ。

列 2 (ソース)
ソースは dbxref として保存されます。 db テーブル内のエントリの Chado インスタンスは必須です
「GFF_source」という名前。 次に、スクリプトは機能の dbxref エントリを作成します。
ソースを取得し、feature_dbxref テーブルを介して機能に関連付けます。

列 3 (タイプ)
SOFA タイプの cvterm.cvterm_id は、feature.type_id に格納されます。

列 4 (開始)
start から 1 を引いた値が featureloc.fmin に格納されます (XNUMX が減算されるのは、
chado はベース間座標を使用しますが、GFF はベース座標を使用します)。

列 5 (終了)
end の値は featureloc.fmax に格納されます。

列 6 (スコア)
スコアは、analyzefeature テーブルのスコア列の XNUMX つに保存されます。 の
デフォルトは、analyzefeature.significance です。 分析結果については以下のセクションを参照してください
をご覧ください。

列 7 (ストランド)
ストランドは featureloc.struct に保存されます。

列 8 (フェーズ)
フェーズは featureloc.phase に保存されます。 現在問題が発生していることに注意してください
異なるフェーズを持つ単一エクソンの場合の Chado スキーマ
転写物。 あなたのデータにまさにそのようなケースがある場合は、以下に苦情を申し立ててください。
gmod-schema@lists.sourceforge.net この問題に対処する方法を見つけるために。

列 9 (グループ)
ここで魔法が起こります。

feature.name、feature.uniquename の割り当て
feature.name と feature.uniquename の値は、これらに従って割り当てられます。
簡単なルール:

ID タグがある場合は、それが feature.uniquename として使用されます
それ以外の場合は、'auto' 連結に等しい一意の名前が割り当てられます。
feature_id を使用します。

Name タグがある場合、その値は feature.name に設定されます。
それ以外の場合は null です。

これらのルールは、Bio::DB::GFF のルールよりもはるかに単純であることに注意してください。
を使用するため、再検討する必要があるかもしれません。

feature_relationship エントリの割り当て
すべての親タグ付きフィーチャには、「part_of」の feature_relationship エントリが割り当てられます。
親フィーチャに。 Derived_from タグには「derived_from」が割り当てられます
関係。 親フィーチャは、ファイルに含める前に存在する必要があることに注意してください。
機能は、その機能を参照する Parent タグまたは Derived_from タグを使用します。

エイリアスタグ
エイリアスの値は、シノニム テーブルの Synonym.name と の両方に保存されます。
Synonym.synonym_sgml であり、feature_synonym テーブルを介して機能にリンクされます。

DBxrefのタグ
DBxref 値は「db_name:accession」の形式である必要があります。db_name には
db.name の値が「DB:db_name」に等しい、db テーブル内のエントリ。 いくつかの
データベース名は、「make prepdb」の実行時にデータベースとともにプリインストールされました。
「SELECT name FROM db」を実行して、どのデータベースがすでに使用可能であるかを調べます。
新しい dbxref エントリが dbxref テーブルに作成され、dbxref がリンクされます。
feature_dbxref テーブル経由の機能。

ギャップタグ
現在はほとんど無視されます。値は featureprop として保存されますが、それ以外の場合は
まだ使用されていません。

注記タグ
値は、機能の featureprop エントリとして保存されます。

任意のカスタム (つまり、小文字が最初) タグ
カスタムタグがサポートされています。 タグが cvterm テーブルにまだ存在しない場合は、
それは作成されます。 値は、関連付けられた cvterm とともに
フィーチャープロップテーブル。

オントロジー用語
Ontology_term タグが使用される場合、Gene Ontology および Sequence の項目
標準の DB:accession 形式が次の場合、オントロジーは自動的に処理されます。
使用されます (例: GO:0001234)。 他のオントロジー用語を使用するには、次のように指定する必要があります。
GFF ファイル内の DB 識別子とそのオントロジーの名前のマッピング
カンマ区切りのタグ=値のペアとしての cv テーブル。 たとえば、plant と
セル オントロジーの用語をコマンド ラインで指定します。

--ontology 'PO=植物オントロジー、CL=細胞オントロジー'

ここで、「プラント オントロジー」と「セル オントロジー」は、CV テーブル内の名前です。
それらが表示されるように。

ターゲットタグ
ターゲット タグを適切に処理するには、XNUMX つのソース フィーチャが必要です
データベース内ですでに利用可能な「一次」ソース特徴 (染色体または
contig) と、EST、cDNA、または類似性分析からの「対象」
シンテニック染色体。 対象の機能が存在しない場合、ローダーは
その場所にプレースホルダー フィーチャ オブジェクトを作成してみます。 ファスタをお持ちの場合
ファイルに件名が含まれている場合は、Perl スクリプト gmod_fasta2gff3.pl を使用できます。
これは、このディストリビューションに付属しており、GFF3 ファイルをロードに適したものにします。
分析結果をロードする前にチャドしてください。

CDS および UTR 機能
Chado で CDS 機能が表現される方法は、
転写物のエキソンと転写物のポリペプチドの特徴。 適切に許可するには
GFF3 ファイルの CDS 機能の変換。このローダーは CDS と UTR を変換します。
特徴線を対応するエクソン特徴に追加します (そして、featureprop ノートを追加します)。
エクソンは GFF3 CDS および/または UTR ラインから推測され、ポリペプチドを作成します
翻訳の開始から終了までのゲノム領域にわたる特徴。

GFF3 ファイルにエクソンと CDS/UTR の両方の機能が含まれている場合は、
エクソン特徴の生成を抑制し、代わりに必要なのは
作成されるポリペプチドフィーチャー。 これを行うには、--noexon オプションを使用します。 この中で
この場合、CDS および UTR の特徴は引き続きエクソンの特徴に変換されます。
上述した。

GFF ファイルに、次のような CDS 機能や UTR 機能が含まれている場合には注意してください。
「セントラルドグマ」遺伝子に属さない（つまり、遺伝子、転写物、および
CDS/エクソンの特徴)、上記のいずれも起こらず、特徴は保存されます。
そのまま。

注意事項
fasta ファイルをロードしています
--fastafile にファイルへのパスを引数として指定した場合
fasta シーケンスが含まれている場合、ローダーは次の機能テーブルを更新しようとします。
提供されたシーケンス。 fasta の説明行に指定される ID は、
フィーチャ テーブルの uniquename フィールドの内容と完全に一致します。 もしそうなら注意してください
機能の一意の名前が、一意性を確保するために変更された可能性があります。
オリジナルの GFF からロードされました。 fasta からシーケンスをロードする場合にも注意してください。
ファイルでは、標準入力からの GFF のロードは無効になっています。 ご不便をかけて申し訳ありません。

##シーケンス領域
このスクリプトはシーケンス領域ディレクティブを一切使用しません。 それが表す場合
データベースに挿入する必要があるフィーチャは、
フルGFFライン。 これには、フィーチャーの参照配列が含まれていない場合、その配列も含まれます。
染色体と同様に、すでにデータベースに存在します。 たとえば、これは次のとおりです。

##シーケンス領域 chr1 1 213456789

これに変更する必要があります:

chr1 UCSC 染色体 1 213456789 。 。 。 ID=chr1

取引
このアプリケーションはデフォルトで、すべてのデータを XNUMX つのデータとして一度にロードしようとします。
取引。 データベースの観点からすると、これはより安全です。
ロード中に発生すると、トランザクションはロールバックされ、データベースは
手付かずの。 この問題は、行数が多い (たとえば 2 ～ 300,000 行を超える) 場合に発生します。
GFF ファイル内。 その場合、ロードを単一のトランザクションとして実行すると、
その結果、マシンのメモリが不足し、プロセスが強制終了されます。 --notranscat の場合
コマンドラインで指定すると、各テーブルは別個のトランザクションとしてロードされます。

SQL INSERT と COPY FROM
このバルクローダーは元々、PostgreSQL の COPY FROM 構文を使用するように設計されていました。
データの一括ロード。 ただし、「トランザクション」セクションで述べたように、メモリ
問題により、このような一括読み込みが妨げられる場合があります。 回避する別の試みとして
この問題では、オプションで INSERT ステートメントを作成するようにバルク ローダーが変更されました。
COPY FROM ステートメントの代わりに。 INSERT ステートメントの読み込みが大幅に遅くなります
COPY FROM ステートメントよりも優れていますが、個別にロードしてコミットするため、
正常に完了する可能性が高くなります。 速度差の目安として
酵母 GFF3 アノテーション (約 16 行) の読み込みが含まれるため、約 5 回かかります
私のラップトップでは COPY ではなく INSERT を使用する時間が長くなりました。

GFF 経由での削除と更新
既存のデータベースの機能を変更するための基本的なサポートがあります。
ＧＦＦ。 現在のところ、削除のみがサポートされています。 削除するにはGFF行
XNUMX 列目にカスタム タグ「CRUD」(作成、置換、更新、および
削除）し、認識された値を持ちます。 現在認識されている値は次の XNUMX つです。
CRUD=削除およびCRUD=すべて削除。

重要な注意: 削除操作を使用すると、孤立したものが作成される可能性があります。
特徴（例えば、遺伝子が削除されたエクソン）。 注意して確認する必要があります
そんなことは起こらない。 このディストリビューションには、PostgreSQL トリガー (次のように記述されています) が含まれています。
plpgsql) はすべての孤立した子を再帰的に削除するため、遺伝子が削除された場合、
その遺伝子に属するすべての転写物、エクソン、ポリペプチドも削除されます。
詳細については、ファイル modules/sequence/functions/delete-trigger.plpgsql を参照してください。

削除
削除オプションは、名前、タイプが一致するフィーチャーを XNUMX つだけ削除します。
そして生物は、GFF 行にあるものとデータベースにあるものを一致させます。 注記
その feature.uniquename は考慮されず、で示される座標も考慮されません。
GFF ファイル。 これは、GFF 経由でコーディナント上で更新を実行できるようにするためです。 もし
名前、種類、生物が一致する特徴が複数あります。
ローダーはエラー メッセージを出力して停止します。 一致する特徴がない場合
名前、タイプ、生物を入力すると、ローダーは警告メッセージを出力して続行します。

すべて削除
すべて削除オプションは、削除オプションと同様に機能しますが、次の点が異なります。
GFF 行の名前、タイプ、生物に一致するすべての特徴を削除します (
XNUMX つの機能のみの削除を許可することに反対します)。 特徴が無い場合
一致する場合、ローダーは警告メッセージを出力して続行します。

ランロック
バルクローダーはマルチユーザー アプリケーションではありません。 XNUMX つの個別の一括ロード プロセスの場合
少なくとも XNUMX つ、場合によってはすべてを同時にデータベースにデータをロードしようとします。
ロードは失敗します。 これが起こらないようにするために、バルクローダーは、
他の gmod_bulk_load_gff3.pl プロセスが同時に実行されるのを防ぐためのデータベース
時間。 アプリケーションが正常に終了すると、このロックは解除されますが、
何らかの理由でクラッシュすると、ロックは解除されません。 ロックを解除するには
コマンドラインで、フラグ --remove_lock を指定します。 ローダーがクラッシュした場合に注意してください
ロックの削除が必要な場合は、uniquename の再構築も必要になる場合があります。
キャッシュ (次のセクションを参照)。

一意の名前のキャッシュ
ローダーは、chado データベースを使用して、feature_id をキャッシュするテーブルを作成します。
データベースに存在する地物の一意の名前、type_id、およびorganism_id
ロードの開始時刻とロード時に追加される機能
完了。 新しい機能が何らかの方法で追加された可能性がある場合、
このローダーではない (たとえば、Apollo が XORT を使用して編集またはロードする)、または以前にこれを使用してロードした場合
ローダーが中止された場合は、 --recreate_cache オプションを指定して確認する必要があります。
キャッシュは新しいです。

シーケンス
デフォルトでは、GFF ファイルにシーケンスがある場合、それは残基にロードされます。
そのフィーチャに対応するフィーチャ テーブルの行の列。 を供給することで、
--nosequence オプションを使用すると、シーケンスはスキップされます。 次の場合はこれを実行するとよいでしょう
シーケンスが非常に大きいため、ロードするのが難しい場合があります。 この文脈では、「非常に
「大」とは 200MB を超えることを意味します。

また、シーケンスを適切にロードするには、GFF ファイルに ##FASTA が必要であることにも注意してください。
ディレクティブ (Bio::FeatureIO による適切な解析に必要です)、およびディレクティブの ID
特徴は、> に続くシーケンスの名前とまったく同じである必要があります。
ファスタセクション。

オーガニズムテーブル
このスクリプトは、生物テーブルにあなたの生物に関する情報が入力されていることを前提としています。
生命体。 そうであるかどうかわからない場合は、次の場所からこのコマンドを実行できます。
psql コマンドライン:

生物から * を選択します。

目的の生物がリストに表示されない場合は、次のコマンドを実行して挿入します。

生物に挿入する (略語、属、種、一般名)
値 ('H.sapiens', 'Homo','sapiens','Human');

あなたの生物に適切な値を代入してください。

保護者・お子様のご注文
GFF ファイルでは、親が子の前に来る必要があります。

分析
分析結果 (つまり、blat 結果、遺伝子予測) をロードしている場合は、次のようにする必要があります。
-a フラグを指定します。 -a で引数が指定されていない場合、ローダーは
結果が次の名前の分析セットに属していると仮定します。
ソース (列 2) とメソッド (列 3) をアンダースコアで連結します。
間。 それ以外の場合、-a で指定された引数は、
分析セット。 いずれの場合も、分析セットはすでに分析テーブルに存在している必要があります。
これを行う最も簡単な方法は、psql シェルに直接挿入することです。

INSERT INTO 分析 (名前、プログラム、プログラムバージョン)
VALUES ('genscan 2005-2-28','genscan','5.4');

分析テーブルにはオプションの他の列もあります。 スキーマを参照
詳細については、ドキュメントと psql の「\d 分析」を参照してください。

Chado には、GFF スコア列にスコアを保存するための XNUMX つの列があります。 お願いします
最も適切なものを使用し、 --score_col フラグで識別します (重要性
がデフォルトです）。 列の名前は XNUMX 文字に短縮できることに注意してください。 もし
各機能に複数のスコアが関連付けられている場合は、他のスコアを追加できます。
99 列目のスコアは、「identity=XNUMX」などのタグ=値のペアとして、およびバルク
ローダーはそれを featureprop テーブルに入れます (ID 用の cvterm がある場合)。
カスタム タグに関する上記のセクションを参照してください)。 利用可能なオプションは次のとおりです。

重要度 (デフォルト)
アイデンティティ
ノームスコア
生スコア

分析結果を処理する機能への追加が予定されているのは、
「混合」GFF ファイル。一部の行は分析結果であり、一部の行は分析結果ではありません。
さらに、タイプのリスト (オプションでソース付き) を提供することもできます。
分析テーブル内のそれらに関連するエントリ。 形式はおそらくタグ値になります
ペア：

--分析一致:Rice_est=rice_est_blast、
一致:Maize_cDNA=maize_cdna_blast、
mRNA=genscan_prediction、エクソン=genscan_prediction

ID による機能のグループ化
GFF3 仕様では、CDS や match_parts などの機能をグループ化できます。
同じIDを共有することで一緒に。 このローダーはこの方法をサポートしていません
グループ化。 代わりに、親フィーチャーはパーツおよび
パーツは Parent タグを使用して親を参照する必要があります。

外部の親 ID
GFF3 仕様では、ID は単一の GFF ファイル内でのみ有効であると規定されているため、
別のファイルの ID を参照する親タグを持つことはできません。 を指定することで、
「allow_external_parent」フラグを使用すると、この制限を緩和できます。 警告の言葉
ただし、親フィーチャーの一意の名前/ID が読み込み中に変更された場合 (
unique)、オリジナルを見つけることができないため、この機能は動作しません。
正しく機能します。 実際、それは働かないより悪いかもしれません、それは子供を傷つける可能性があります
機能を間違った親に送信します。 このため、この機能を使用することはお勧めできません。
注意して使用してください。

作者

アレン・デイallenday@ucla.edu>、スコット・ケインscain@cpan.org>

著作権（c）2011

このライブラリはフリー ソフトウェアです。 同じ方法で再配布したり変更したりできます。
Perl自体としての用語。

onworks.net サービスを使用してオンラインで gmod_bulk_load_gff3.plp を使用する