gmod_bulk_load_gff3.plp - En ligne dans le cloud

PROGRAMME:

Nom

$0 - Charge en bloc les fichiers gff3 dans une base de données chado.

SYNOPSIS

% 0 $ [options]
% chat | 0 $ [options]

OPTIONS

--gfffile Le fichier contenant GFF3 (facultatif, peut lire
de stdin)
--fastafile Fichier Fasta à partir duquel charger la séquence
--organism L'organisme pour les données
(utilisez la valeur 'fromdata' pour lire à partir de l'organisme GFF=xxx)
--dbprofile Nom du profil de configuration de la base de données
--dbname Nom de la base de données
--dbuser Nom d'utilisateur de la base de données
--dbpass Mot de passe de la base de données
--dbhost Hôte de la base de données
--dbport Port de la base de données
--analysis Les données GFF proviennent d'une analyse informatique
--noload Crée des fichiers de chargement en bloc, mais ne les charge pas réellement.
--nosequence Ne charge pas la séquence même si elle est dans le fichier
--notransact Ne pas utiliser une seule transaction pour charger la base de données
--drop_indexes Supprimer les index des tables affectées avant de commencer le chargement
et recréer une fois le chargement terminé ; généralement
n'aide pas les performances.
--validate Valide les termes SOFA avant d'essayer d'insérer (peut
ralentir le démarrage du script, désactivé par défaut)
--ontology Donne des instructions pour gérer divers Ontology_terms
--skip_vacuum Ignore l'aspiration des tables après les insertions (par défaut)
--no_skip_vaccum Ne sautez pas l'aspirateur sur les tables
--inserts Affiche les instructions INSERT au lieu de COPY FROM STDIN
--noexon Ne convertit pas les fonctionnalités CDS en exons (mais crée quand même
caractéristiques polypeptidiques)
--recreate_cache Provoque la recréation du cache de nom unique
--remove_lock Supprimer le verrou pour permettre à un nouveau processus de s'exécuter
--save_tmpfiles Enregistre les fichiers temporaires utilisés pour le chargement de la base de données
--random_tmp_dir Utilise un répertoire tmp généré aléatoirement (la valeur par défaut est
pour utiliser le répertoire courant)
--no_target_syn Par défaut, le chargeur ajoute le targetId dans
la liste des synonymes de la fonctionnalité. Ce drapeau
désactiver cela.
--unique_target Faites confiance à l'unicité des identifiants cibles. Les identifiants sont cas
sensible. Par défaut, le nom unique d'une nouvelle cible
sera 'TargetId_PrimaryKey'. Avec ce drapeau,
ce sera 'TargetId'. De plus, le nom du
la cible créée sera son TargetId, au lieu du
Nom de la fonction.
--dbxref Utilisez soit la première annotation Dbxref comme
dbxref primaire (qui va dans feature.dbxref_id),
ou si un argument facultatif est fourni, le premier
dbxref qui a une partie base de données (c'est-à-dire avant le ':')
qui correspond au modèle fourni est utilisé.
--delete Au lieu d'insérer des fonctionnalités dans la base de données,
utiliser les lignes GFF pour supprimer des entités comme si
l'option CRUD=delete-all a été définie sur toutes les lignes
(voir 'Suppressions et mises à jour via GFF ci-dessous'). Les
loader demandera une confirmation avant de continuer.
--delete_i_really_mean_it
Fonctionne comme --delete sauf qu'il ne demande pas
pour confirmation.
--fp_cv Nom du vocabulaire contrôlé par la propriété de l'entité
(par défaut 'feature_property').
--noaddfpcv Par défaut, le chargeur ajoute les types d'attributs GFF comme
nouveaux termes de cv feature_property lorsqu'ils sont manquants. Ce drapeau
le désactive.
** note dgg : devrait renommer ce drapeau : --[no]autoupdate
pour les tableaux Chado cvterm, cv, db, organisme, analyse...

--manuel pages de manuel détaillées
--custom_adapter Utiliser un adaptateur de sous-classe personnalisé pour Bio::GMOD::DB::Adapter
Fournissez le chemin d'accès à l'adaptateur comme argument
--private_schema Charge les données dans un schéma non public.
--use_public_cv Lors du chargement dans un schéma non public, chargez n'importe quel cv et
données cvterm dans le schéma public
--end_sql Code SQL à exécuter une fois le chargement des données terminé
--allow_external_parent
Autoriser les balises parent à faire référence à des identifiants en dehors de l'actuel
fichier GFF

Notez que tous les arguments qui commencent par « db » ainsi que par organisme peuvent être fournis par
par défaut par Bio::GMOD::Config, qui a été installé lors de l'exécution de 'make install'. Notez également
l'option dbprofile et toutes les autres options db* s'excluent mutuellement - si vous fournissez
dbprofile, ne fournissez aucune autre option db*, car elles ne seront pas utilisées.

DESCRIPTION

Le GFF dans le fichier de données doit être la version 3 en raison de son contrôle plus strict de la spécification
et l'utilisation d'un vocabulaire contrôlé. Par conséquent, les noms des types d'entités doivent être exactement
ceux de l'annotation de caractéristiques d'ontologie de séquence (SOFA), pas les synonymes et pas le
numéros d'accession (les numéros d'accession SO peuvent être pris en charge dans les futures versions de ce
scénario).

Notez que la directive ##sequence-region n'est pas prise en charge comme moyen de déclarer un
séquence de référence pour un fichier GFF3. La directive ##sequence-region n'est pas expressive
assez pour définir quel type de chose la séquence est (c'est-à-dire, est-ce un chromosome, un contig, un
bras, etc?). Si votre fichier GFF utilise une directive ##sequence-region de cette manière, vous devez
convertissez-le en une ligne GFF3 complète. Par exemple, si vous avez cette ligne :

##séquence-région chrI 1 9999999

Ensuite, il devrait être converti en une ligne GFF3 comme ceci :

chrI. chromosome 1 9999999 . . . ID=chrI

Comment la GFF3 is stockée in Chado
Voici un résumé de la façon dont les données GFF3 sont stockées dans chado :

Colonne 1 (séquence de référence)
La séquence de référence de l'entité devient le srcfeature_id de l'entité dans le
table featureloc pour cette fonctionnalité. Cette featureloc attribuait généralement un rang de zéro
s'il existe d'autres emplacements associés à cette fonctionnalité (par exemple, pour un match
feature), les autres emplacements se verront attribuer des valeurs featureloc.rank supérieures à
zéro.

Colonne 2 (source)
La source est stockée en tant que dbxref. L'instance chado doit d'une entrée dans la table db
nommé 'GFF_source'. Le script créera ensuite une entrée dbxref pour la fonction
source et l'associer à l'entité via la table feature_dbxref.

Colonne 3 (type)
Le cvterm.cvterm_id du type SOFA est stocké dans feature.type_id.

Colonne 4 (début)
La valeur de start moins 1 est stockée dans featureloc.fmin (une est soustraite car
chado utilise des coordonnées interbases, alors que GFF utilise des coordonnées de base).

Colonne 5 (fin)
La valeur de end est stockée dans featureloc.fmax.

Colonne 6 (note)
Le score est stocké dans l'une des colonnes de score de la table analysisfeature. Les
la valeur par défaut est analysisfeature.significance. Voir la section ci-dessous sur les résultats d'analyse
pour plus d'informations.

Colonne 7 (volet)
Le brin est stocké dans featureloc.strand.

Colonne 8 (phase)
La phase est stockée dans featureloc.phase. Notez qu'il y a actuellement un problème avec
le schéma chado pour le cas d'exons uniques ayant différentes phases dans différents
transcriptions. Si vos données ont juste un tel cas, plaindre à
[email protected] pour trouver des moyens de résoudre ce problème.

Colonne 9 (groupe)
C'est ici que la magie opère.

Attribution de feature.name, feature.uniquename
Les valeurs de feature.name et feature.uniquename sont attribuées en fonction de ces
règles simples :

S'il y a une étiquette d'identification, elle est utilisée comme feature.uniquename
sinon, il reçoit un nom unique qui est égal à 'auto' concaténé
avec le feature_id.

S'il y a une balise Name, sa valeur est définie sur feature.name ;
sinon c'est nul.

Notez que ces règles sont bien plus simples que celles que Bio::DB::GFF
utilisations, et peut avoir besoin d'être réexaminé.

Attribution d'entrées feature_relationship
Toutes les entités étiquetées par le parent se voient attribuer des entrées feature_relationship de 'part_of'
à leurs caractéristiques parentales. Les balises Derived_from sont affectées 'derived_from'
des relations. Notez que les entités parents doivent apparaître dans le fichier avant tout
les fonctionnalités utilisent des balises Parent ou Derived_from faisant référence à cette fonctionnalité.

Balises d'alias
Les valeurs d'alias sont stockées dans la table des synonymes, à la fois sous synonym.name et
synonym.synonym_sgml, et sont liés à la fonctionnalité via la table feature_synonym.

Balises dbxref
Les valeurs dbxref doivent être de la forme 'db_name:accession', où db_name doit avoir un
entrée dans la table db, avec une valeur de db.name égale à 'DB:db_name' ; nombreuses
les noms de base de données ont été préinstallés avec la base de données lors de l'exécution de 'make prepdb'.
Exécutez 'SELECT name FROM db' pour savoir quelles bases de données sont déjà disponibles.
De nouvelles entrées dbxref sont créées dans la table dbxref et les dbxrefs sont liées à
fonctionnalités via la table feature_dbxref.

Balises d'espacement
Actuellement est principalement ignoré - la valeur est stockée en tant que featureprop, mais sinon
n'est pas encore utilisé.

Balises de notes
Les valeurs sont stockées en tant qu'entrées featureprop pour la fonction.

Toutes les balises personnalisées (c'est-à-dire en minuscules d'abord)
Les balises personnalisées sont prises en charge. Si la balise n'existe pas déjà dans la table cvterm,
il sera créé. La valeur sera stockée avec son cvterm associé dans le
table featureprop.

Terme_ontologie
Lorsque les balises Ontology_term sont utilisées, les éléments de Gene Ontology et Sequence
L'ontologie sera traitée automatiquement lorsque le format standard DB:accession est
utilisé (par exemple GO:0001234). Pour utiliser d'autres termes d'ontologie, vous devez spécifier que
mappage des identifiants DB dans le fichier GFF et le nom des ontologies dans
le tableau cv sous forme de paires balise=valeur séparées par des virgules. Par exemple, pour utiliser des plantes et
termes d'ontologie de cellule, vous fourniriez sur la ligne de commande :

--ontology 'PO=ontologie végétale,CL=ontologie cellulaire'

où 'plant ontology' et 'cell ontology' sont exactement les noms dans le tableau cv
tels qu'ils apparaissent.

Balises cibles
Un traitement correct des balises cibles nécessite qu'il y ait deux fonctionnalités source
déjà disponible dans la base de données, la caractéristique source « primaire » (le chromosome ou
contig) et le « sujet » de l'analyse de similarité, comme un EST, un ADNc ou
chromosome synténique. Si la fonction de sujet n'est pas présente, le chargeur
tenter de créer un objet de fonction d'espace réservé à sa place. Si vous avez un fasta
le fichier contient le sujet, vous pouvez utiliser le script perl, gmod_fasta2gff3.pl,
fourni avec cette distribution pour créer un fichier GFF3 adapté au chargement dans
chado avant de charger vos résultats d'analyse.

Fonctionnalités CDS et UTR
La façon dont les entités CDS sont représentées dans Chado est comme une intersection d'un
les exons du transcrit et la caractéristique polypeptidique du transcrit. Pour permettre une bonne
traduction des fonctionnalités CDS d'un fichier GFF3, ce chargeur convertira CDS et UTR
lignes caractéristiques des caractéristiques d'exon correspondantes (et ajoutez une featureprop notez que le
exon a été déduit d'une lignée GFF3 CDS et/ou UTR), et crée un polypeptide
caractéristique qui s'étend sur la région génomique du début de la traduction à l'arrêt.

Si votre fichier GFF3 contient à la fois des fonctionnalités exon et CDS/UTR, vous voudrez
supprimer la création des fonctionnalités d'exon et ne voudra à la place qu'un
caractéristique polypeptidique à créer. Pour ce faire, utilisez l'option --noexon. Dans ce
cas, les caractéristiques CDS et UTR seront toujours converties en caractéristiques exon comme
décrit ci-dessus.

Notez que dans le cas où votre fichier GFF contient des fonctionnalités CDS et/ou UTR qui ne
n'appartiennent pas aux gènes du « dogme central » (c'est-à-dire qui ont un gène, un transcrit et
fonctionnalités CDS/exon), rien de ce qui précède ne se produira et les fonctionnalités seront stockées
comme si.

NOTES
Chargement du fichier fasta
Lorsque --fastafile est fourni avec un argument qui est le chemin d'accès à un fichier
contenant une séquence fasta, le chargeur tentera de mettre à jour la table des fonctionnalités avec
la séquence fournie. Notez que l'ID fourni dans la ligne de description fasta doit
correspondent exactement à ce qui se trouve dans le champ nom unique de la table des caractéristiques. Soyez prudent si c'est
possible que le nom unique de la fonctionnalité ait été modifié pour garantir l'unicité lorsqu'il
a été chargé à partir du GFF d'origine. Notez également que lors du chargement d'une séquence à partir d'un fasta
fichier, le chargement de GFF à partir de l'entrée standard est désactivé. Désolé pour le dérangement.

##séquence-région
Ce script n'utilise pas de directives de région de séquence pour quoi que ce soit. S'il représente un
fonctionnalité qui doit être insérée dans la base de données, elle doit être représentée par un
ligne GFF complète. Cela inclut la séquence de référence pour les entités si elle n'est pas
déjà dans la base de données, comme un chromosome. Par exemple, ceci :

##séquence-région chr1 1 213456789

devrait changer en ceci:

chr1 Chromosome UCSC 1 213456789 . . . ID=chr1

Transactions
Cette application essaiera, par défaut, de charger toutes les données en une seule fois.
transaction. C'est plus sûr du point de vue de la base de données, car si quelque chose de mal
se produit pendant le chargement, la transaction sera annulée et la base de données sera
intact. Le problème se produit s'il y a beaucoup (disons, plus de 2 à 300,000 XNUMX) lignes
dans le fichier GFF. Lorsque c'est le cas, effectuer la charge comme une seule transcation peut
entraîner le manque de mémoire de la machine et l'arrêt des processus. Si --notranscat est
fourni sur la ligne de commande, chaque table sera chargée en tant que transaction distincte.

SQL INSERT versus COPY FROM
Ce chargeur en bloc a été conçu à l'origine pour utiliser la syntaxe PostgreSQL COPY FROM pour
chargement en masse des données. Cependant, comme mentionné dans la section « Transactions », la mémoire
des problèmes peuvent parfois interférer avec de tels chargements en masse. Dans un autre effort pour contourner
ce problème, le chargeur en bloc a été modifié pour créer éventuellement des instructions INSERT
au lieu des instructions COPY FROM. Les instructions INSERT se chargeront beaucoup plus lentement
que les instructions COPY FROM, mais comme elles se chargent et s'engagent individuellement, elles sont plus
plus de chances de réussir. Comme indication des différences de vitesse
impliqué, le chargement des annotations de levure GFF3 (environ 16K lignes), cela prend environ 5 fois
utiliser plus longtemps INSERT que COPY sur mon ordinateur portable.

Suppressions et mises à jour via GFF
Il existe un support rudimentaire pour modifier les fonctionnalités dans une base de données existante via
GFF. Actuellement, seule la suppression est prise en charge. Pour supprimer, la ligne GFF
doit avoir une balise personnalisée dans la neuvième colonne, « CRUD » (pour créer, remplacer, mettre à jour et
Supprimer) et avoir une valeur reconnue. Actuellement, les deux valeurs reconnues sont
CRUD=supprimer et CRUD=supprimer tout.

REMARQUE IMPORTANTE : L'utilisation des opérations de suppression peut potentiellement créer des
caractéristiques (par exemple, les exons dont le gène a été supprimé). Vous devez faire attention à vous assurer
cela n'arrive pas. Inclus dans cette distribution est un déclencheur PostgreSQL (écrit dans
plpgsql) qui supprimera tous les enfants orphelins de manière récursive, donc si un gène est supprimé,
tous les transcrits, exons et polypeptides qui appartiennent à ce gène seront également supprimés.
Voir le fichier modules/sequence/functions/delete-trigger.plpgsql pour plus d'informations.

delete
L'option de suppression supprimera une et une seule fonctionnalité dont le nom, tapez
et l'organisme fait correspondre ce qui est dans la ligne GFF avec ce qui est dans la base de données. Noter
que feature.uniquename ne sont pas pris en compte, ni les coordonnées présentées dans
le fichier GFF. Ceci afin que les mises à jour via GFF puissent être effectuées sur les coordonnées. Si
il y a plus d'une caractéristique pour laquelle le nom, le type et l'organisme correspondent, le
loader imprimera un message d'erreur et s'arrêtera. S'il n'y a pas de caractéristiques qui correspondent
le nom, le type et l'organisme, le chargeur imprimera un message d'avertissement et continuera.

supprimer-tout
L'option delete-all fonctionne de la même manière que l'option delete, sauf qu'elle
supprimer toutes les caractéristiques qui correspondent au nom, au type et à l'organisme dans la ligne GFF (comme
plutôt que d'autoriser la suppression d'une seule caractéristique). S'il n'y a pas de fonctionnalités
qui correspondent, le chargeur imprimera un message d'avertissement et continuera.

Le verrou de course
Le Bulk Loader n'est pas une application multi-utilisateurs. Si deux processus de chargement en bloc distincts
essayez de charger des données dans la base de données en même temps, au moins une et peut-être toutes
les charges échoueront. Pour éviter que cela ne se produise, le chargeur en vrac place un verrou dans le
base de données pour empêcher d'autres processus gmod_bulk_load_gff3.pl de s'exécuter en même temps
temps. Lorsque l'application se termine normalement, ce verrou sera supprimé, mais s'il
se bloque pour une raison quelconque, le verrou ne sera pas supprimé. Pour retirer le verrou du
ligne de commande, fournissez l'indicateur --remove_lock. Notez que si le chargeur plante
nécessitant la suppression du verrou, vous devrez peut-être également reconstruire le nom unique
cache (voir la section suivante).

Le cache de nom unique
Le chargeur utilise la base de données chado pour créer une table qui met en cache les feature_ids,
uniquesnames, type_ids et organization_ids des caractéristiques qui existent dans la base de données à
l'heure à laquelle le chargement commence et les fonctionnalités qui seront ajoutées lorsque le chargement est
Achevée. S'il est possible que de nouvelles fonctionnalités aient été ajoutées via une méthode qui est
pas ce chargeur (par exemple, Apollo édite ou charge avec XORT) ou si un précédent chargement utilisant ce
loader a été abandonné, vous devez alors fournir l'option --recreate_cache pour vous assurer
le cache est frais.

Séquence
Par défaut, s'il y a une séquence dans le fichier GFF, elle sera chargée dans les résidus
colonne de la ligne de la table des caractéristiques qui correspond à cette caractéristique. En fournissant le
--nosequence, la séquence sera ignorée. Vous voudrez peut-être le faire si vous
ont des séquences très volumineuses, qui peuvent être difficiles à charger. Dans ce contexte, « très
grand" signifie plus de 200 Mo.

Notez également que pour que les séquences se chargent correctement, le fichier GFF doit avoir le ##FASTA
directive (elle est requise pour une analyse correcte par Bio::FeatureIO) et l'ID du
caractéristique doit être exactement le même que le nom de la séquence suivant le > dans le
section fasta.

La table ORGANISME
Ce script suppose que la table des organismes contient des informations sur votre
organisme. Si vous n'êtes pas sûr que ce soit le cas, vous pouvez exécuter cette commande à partir de
la ligne de commande psql :

sélectionnez * dans l'organisme ;

Si vous ne voyez pas votre organisme dans la liste, exécutez cette commande pour l'insérer :

insérer dans l'organisme (abréviation, genre, espèce, nom_commun)
valeurs ('H.sapiens', 'Homo','sapiens','Humain');

en substituant les valeurs appropriées à votre organisme.

Commande parents/enfants
Les parents doivent se présenter avant les enfants dans le fichier GFF.

Analyse
Si vous chargez des résultats d'analyse (c'est-à-dire des résultats blat, des prédictions de gènes), vous devez
spécifiez l'indicateur -a. Si aucun argument n'est fourni avec le -a, alors le chargeur
supposer que les résultats appartiennent à un ensemble d'analyse avec un nom qui est le
concaténation de la source (colonne 2) et de la méthode (colonne 3) avec un trait de soulignement dans
entre. Sinon, l'argument fourni avec -a sera pris comme nom du
ensemble d'analyse. Dans tous les cas, l'ensemble d'analyses doit déjà figurer dans la table d'analyse.
Le moyen le plus simple de le faire est de l'insérer directement dans le shell psql :

INSERTION DANS l'analyse (nom, programme, version du programme)
VALEURS ('genscan 2005-2-28','genscan','5.4');

Il existe d'autres colonnes dans la table d'analyse qui sont facultatives ; voir le schéma
documentation et '\d analysis' dans psql pour plus d'informations.

Chado a quatre colonnes possibles pour stocker le score dans la colonne de score GFF ; s'il te plaît
utilisez celui qui est le plus approprié et identifiez-le avec l'indicateur --score_col (signification
est la valeur par défaut). Notez que le nom de la colonne peut être raccourci à une lettre. Si
vous avez plus d'un score associé à chaque caractéristique, vous pouvez mettre l'autre
scores dans la neuvième colonne en tant que paire balise=valeur, comme 'identité=99', et le volume
loader le mettra dans la table featureprop (à condition qu'il y ait un cvterm pour l'identité ;
voir la section ci-dessus concernant les balises personnalisées). Les options disponibles sont :

signification (par défaut)
identité
note aux normes
score brut

Un ajout prévu à la fonctionnalité de gestion des résultats d'analyse est de permettre
fichiers GFF "mixtes", où certaines lignes sont des résultats d'analyse et d'autres non.
De plus, on pourra fournir des listes de types (éventuellement avec des sources) et
leur entrée associée dans la table d'analyse. Le format sera probablement la valeur de la balise
paires:

--analysis match:Rice_est=riz_est_blast, \
match:Maize_cDNA=maize_cdna_blast, \
ARNm=genscan_prediction,exon=genscan_prediction

Regroupement des fonctionnalités par ID
La spécification GFF3 permet de regrouper des fonctionnalités telles que les CDS et les match_parts
ensemble en partageant le même identifiant. Ce chargeur ne prend pas en charge cette méthode de
regroupement. Au lieu de cela, la fonction parente doit être explicitement créée avant les pièces et
les parties doivent faire référence au parent avec la balise Parent.

Identifiants parent externes
La spécification GFF3 stipule que les ID ne sont valides que dans un seul fichier GFF, vous
ne peut pas avoir de balises Parent faisant référence à des ID dans un autre fichier. En précisant le
drapeau "allow_external_parent", vous pouvez assouplir cette restriction. Un mot d'avertissement
cependant : si le nom/ID unique de l'entité parente a été modifié lors du chargement (pour le rendre
unique), cette fonctionnalité ne fonctionnera pas, car elle ne pourra pas trouver l'original
fonction correctement. En fait, cela peut être pire que de ne pas travailler, cela peut attacher un enfant
fonctionnalités au mauvais parent. C'est pourquoi c'est une mauvaise idée d'utiliser cette fonctionnalité !
Veuillez utiliser avec prudence.

AUTEURS

Jour Allen[email protected]>, Scott Caïn[email protected]>

Copyright (c) 2011

Cette bibliothèque est un logiciel libre ; vous pouvez le redistribuer et/ou le modifier sous le même
termes comme Perl lui-même.

Utilisez gmod_bulk_load_gff3.plp en ligne à l'aide des services onworks.net