Global Alliance for Genomics and Health on työskennellyt sekvensointidatan ja metatietojen esittämisen varastoimiseksi ja jakamiseksi jo pitkään, vaikka tulokset ovatkin ristiriitaisia. He tarjoavat mallin ja API: n NGS-tietojen tallentamiseen GitHub-arkistoon, mutta korkean tason näkymän saaminen voi olla hieman tuskaa. En ole varma, onko tätä parempi esitys muualla.

Voin sanoa henkilökohtaisen kokemukseni perusteella (koska olen rakentanut yli tusinan genomitietokantoja), ihanteellista tietomallia ja tallennuksen parhaita käytäntöjä ei ole. Genomidataa on useita muotoja ja kokoja, ja tarpeesi vaihtelevat kaikista muista organisaatioista, joten se, mikä toimii yhdelle bioinformatiikkaryhmälle, ei välttämättä toimi sinulle. Parasta on suunnitella ja toteuttaa malli, joka kattaa kaikki työnkulun tietotyypit ja jatkoanalyysit, joita saatat tehdä tiedoilla ja metatiedoilla.

Olen samaa mieltä siitä, että ei ole olemassa ihanteellista tietomallia, joka pysyisi vakaana pitkään nopeasti muuttuvalla alalla, kuten genomi-informatiikassa. Ehkä skeematon (NoSQL tai jokin muu asiakirjapohjainen järjestelmä, kuten MongoDB) tietokantamenetelmä toimisi paremmin? Tämä antaa sinulle äärimmäisen joustavuuden liittää kaikki tiedot, jotka ovat merkityksellisiä tietokantamerkintöihin, jotka lisäät nyt tietokantaan, ilman tietokannan uudelleenrakentamista myöhemmin, jos haluat liittää lisää / erilaisia ​​tietoja seuraaviin tietokantamerkintöihin.

metatiedoissa käytän SQL-mallia, joka on jotain seuraavaa:

  CREATE TABLE Project (ac TEXT, - project / Study liittyminen ENSIMMÄINEN AVAIN ( CREATE TABLE Sample (- biologinen näyte / biopsia ac TEXT, ENSIMMÄINEN AVAIN (ac)); CREATE TABLE AnalysisSample (prj_ac TEXT, - projektin liittymismerkki (Project.ac) symboli TEXT, - lyhyt nimi, joka on ainutlaatuinen projektin näyte_ac TEKSTI, - näytteen liittyminen (näyte.ac) ENSIMMÄINEN AVAIN (prj_ac, symboli)); LUO TAULUKON kokoelma (- BAM-tiedosto ac TEXT, - kokoelma- / kohdennustiedoston liittyminen prj_ac TEXT, - projektin liittyminen ( Project.ac) ENSIMMÄINEN AVAIN (ac)); Luo taulukko ReadGroup (cl_ac TEXT, - kokoelman liittyminen (Collection.ac) rg_id TEXT, - @ RG-ID sample_sym TEXT, - @ RG-SM; vastaava AnalysisSample.symboli ENSIMMÄINEN AVAIN (cl_ac, rg_id)); LUO TAULUKKO VariantSet (- VCF-tiedosto ac TEXT, - VCF-tiedosto liittyminen prj_ac TEXT, - projektin liittyminen (Project.ac) ENSIMMÄINEN AVAIN (ac)); LUO TAULUKKO Va riantSample (vs_ac TEXT, - VCF-tiedoston liittyminen (VariantSet.ac) sample_sym TEXT, - näytesymboli VCF-tiedostossa; vastaavat AnalysisSample.symbol ENSIMMÄINEN AVAIN (vs_ac, sample_sym));  

Kaavalla on Project ja biologiset Sample -taulukot, jotka ovat toisistaan ​​riippumattomia korkealla tasolla. AnalysisSample kuvaa BAM: ssä tai VCF: ssä käytettävän näytteen ja yhdistää Project ja biologisen Sample . Tärkeää on, että jokaisella AnalysisSample : lla on projektissa ainutlaatuinen symboli (katso ensisijainen hakemisto). Tämä on symboli BAM-lukuryhmärivillä tai VCF-näyteviivalla. Collection on itse asiassa BAM / CRAM-tiedosto. Teoriassa BAM-tiedosto voi sisältää useamman kuin yhden näytteen (tosin käytännössä harvinainen), johon osoitetaan erillinen ReadGroup -taulukko. Lopuksi VariantSet on VCF-tiedosto. VariantSample kertoo, mitkä näytteet sisältyvät jokaiseen VCF-tiedostoon.

Tämä on koko skeeman luuranko. Voit lisätä ylimääräisiä kenttiä sopiviin taulukoihin (esim. Tiedostopolku ja hg19 / hg38 / etc kohtaan Collection , lukupituus ReadGroup -kohtaan ja perhetunnus kohtaan Sample ). Tarvitset myös indeksejä taulukkojen tehokkaaseen liittämiseen ja ehkä enemmän taulukoita monimutkaisiin rakenteisiin (esim. Sukutaulu).

Tämän mallin pitäisi toimia suurimman osan ajasta projekteissa, joihin olen osallistunut. Se on saanut inspiraation GA4GH: n JSON-mallista, mutta versioni on SQL-muodossa, yksinkertaisempi ja siinä on myös hieman erilainen rakenne, joka on mielestäni parempi.