Soru:
Bir laboratuvar NGS dosya veritabanı şeması tasarlama
Gus
2017-05-22 21:32:41 UTC
view on stackexchange narkive permalink

NGS'nin yanı sıra CyTOF ve diğer büyük hacimli veri üretim teknolojilerini rutin olarak kullanan bir hastane akademik laboratuvarında Bioinfo Geek'in yerleşikiyim. Meta veri toplama ve nihai ürünlerle (miriad excel sayfaları ve birkaç kötü tasarlanmış RedCap DB) ilişkilendirmeye yönelik mevcut "protokolümüzden" bıktım.

Bunu yapacak merkezi, yapılandırılmış, kontrollü bir veri deposu uygulamak istiyorum buna dikkat et. Verilerin nasıl girileceğinin teknisyenlere arayüzünün benimsenmesi için çok önemli olduğunu biliyorum, ancak BU özel sorunun odağı bu değil: Bu tür bir veritabanı için bir şema veya şema yönergesi var mı?

Bunu nasıl yapacağını iyi bilen insanlar tarafından geliştirilmiş bir modeli kullanmayı tercih ederim. BioSQL'i biliyorum ama daha çok uniprot veya genbank'ta bulunanlar gibi tam protein / nükleotid kayıtlarına yönelik görünüyor. Burada sahip olduğumuz bu değil. İstediğim, bu ön baskıda değinilen sisteme benzer bir şey: http://biorxiv.org/content/early/2017/05/10/136358

Alternatif olarak, ilgili yönergeleri bulabileceğim veya kişisel tavsiyelerde bulunabileceğim yerlere bağlantı veren var mı?

İşlenmiş veya işlenmemiş verileri depolamak mı istiyorsunuz? Yakalamaya çalışacağınız örnek dosya formatı ne olurdu?
Bu çoğunlukla birincil veri organizasyonu içindir: 800 BAM WES alıyoruz ve PROJECT, READ_LENGTH, SAMPLE_NAME, FAMILY_ID, DATA_TYPE, DIAGNOSIS, vb. Gibi meta verilerle ilişkili her BAM'ın dosya konumunu istiyorum.
Hey Gus, biz de aynı araştırmayı yapıyoruz ve bu soruyu Biostars'ta oluşturduk, bir şey bulursan bize haber ver! https://www.biostars.org/p/350514/
üç yanıtlar:
#1
+9
woemler
2017-05-22 22:01:01 UTC
view on stackexchange narkive permalink

Global Alliance for Genomics and Health, karışık sonuçlara rağmen, oldukça uzun bir süredir depolama ve paylaşım için sıralama verilerini ve meta verileri temsil etme sorunu üzerinde çalışıyor. NGS verilerini GitHub havuzlarında depolamak için bir model ve API sunarlar, ancak üst düzey bir görünüm elde etmek biraz zahmetli olabilir. Bunun başka bir yerde daha iyi bir temsilinin olup olmadığından emin değilim.

Kişisel deneyimlerime dayanarak söyleyebilirim (bir düzineden fazla genomik veritabanı oluşturmuş olmak), ideal bir veri modeli ve en iyi depolama uygulamaları yoktur. Genomik veriler birçok şekil ve boyutta gelir ve ihtiyaçlarınız diğer tüm organizasyonlardan farklı olacaktır, bu nedenle bir biyoinformatik grubu için işe yarayan şey sizin için mutlaka çalışmayacaktır. Yapılacak en iyi şey, iş akışınızdaki tüm veri türlerini ve veriler ve meta verilerle yapabileceğiniz aşağı akış analizlerini kapsayacak bir model tasarlamak ve uygulamaktır.

#2
+5
Daniel Standage
2017-05-22 23:04:32 UTC
view on stackexchange narkive permalink

Genom bilişimi gibi hızlı hareket eden bir alanda çok uzun süre stabil kalacak ideal bir veri modeli olmadığına katılıyorum. Şemasız (NoSQL veya MongoDB gibi başka bir belge tabanlı sistem) veritabanı yaklaşımı daha iyi çalışabilir mi? Bu, sonraki veritabanı girişlerine daha fazla / farklı bilgi eklemek istiyorsanız, veritabanını daha sonra yeniden oluşturmanıza gerek kalmadan, şu anda veritabanınıza eklediğiniz veritabanı girişleriyle ilgili bilgileri eklemeniz için mükemmel bir esneklik sağlar.

#3
+5
user172818
2017-05-23 00:31:41 UTC
view on stackexchange narkive permalink

Meta veriler için, aşağıdaki gibi bir SQL şeması kullanırdım:

  CREATE TABLE Project (ac TEXT, - project / Study accession PRIMARY KEY ( ac)); CREATE TABLE Sample (- biyolojik örnek / biyopsi ac TEXT, PRIMARY KEY (ac)); CREATE TABLE Analysis Sample (prj_ac TEXT, - project acccession (Project.ac) symbol TEXT, - a unique short name in proje sample_ac TEXT, - örnek erişim (Sample.ac) PRIMARY KEY (prj_ac, symbol)); CREATE TABLE Collection (- bir BAM dosyası ac TEXT, - koleksiyon / hizalama dosyası erişimi prj_ac TEXT, - proje erişimi ( Project.ac) PRIMARY KEY (ac)); CREATE TABLE ReadGroup (cl_ac TEXT, - collection accession (Collection.ac) rg_id TEXT, - @ RG-ID sample_sym TEXT, - @ RG-SM; matching AnalysisSample.symbol PRIMARY KEY (cl_ac, rg_id)); CREATE TABLE VariantSet (- bir VCF dosyası ac TEXT, - VCF dosya erişimi prj_ac TEXT, - proje erişimi (Project.ac) PRIMARY KEY (ac)); CREATE TABLE Va riantSample (vs_ac TEXT, - VCF dosya erişimi (VariantSet.ac) sample_sym TEXT, - VCF dosyasındaki örnek sembol; eşleştirme AnalysisSample.symbol PRIMARY KEY (vs_ac, sample_sym));  

Şemada Project ve biyolojik Sample tablolarınız var, yüksek düzeyde birbirinden bağımsızdır. Bir AnalysisSample , BAM veya VCF'de kullanılan bir örneği açıklar ve Project ile biyolojik Sample 'ı birbirine bağlar. Önemlisi, her AnalysisSample bir projede benzersiz bir sembole sahiptir (birincil dizine bakın). Bu, bir BAM okuma grubu satırındaki veya bir VCF örnek satırındaki semboldür. Bir Koleksiyon aslında bir BAM / CRAM dosyasıdır. Teorik olarak, bir BAM dosyası, ayrı bir ReadGroup tablosu tarafından ele alınan birden fazla örnek içerebilir (pratikte nadir olsa da). Son olarak, VariantSet bir VCF dosyasıdır. VariantSample , her VCF dosyasına hangi örneklerin dahil edildiğini söyler.

Bu, tam bir şemanın iskeletidir. Uygun tablolara fazladan alanlar ekleyebilirsiniz (ör. Koleksiyon 'a dosya yolu ve hg19 / hg38 / etc, uzunluğu ReadGroup ' a ve aile kimliğini Sample code'a okuyabilirsiniz. >). Ayrıca verimli tablo birleştirme için endekslere ve belki karmaşık yapılar için daha fazla tabloya (örneğin, soy ağacı) ihtiyacınız var.

Katıldığım projeler için bu şema çoğu zaman işe yaramalı. GA4GH'nin JSON şemasından esinlenildi, ancak benim sürümüm SQL, daha basit ve biraz farklı bir yapıya sahip ve bence daha iyi.



Bu Soru-Cevap, otomatik olarak İngilizce dilinden çevrilmiştir.Orijinal içerik, dağıtıldığı cc by-sa 3.0 lisansı için teşekkür ettiğimiz stackexchange'ta mevcuttur.
Loading...