A Global Alliance for Genomics and Health tem trabalhado na questão da representação de dados de sequenciamento e metadados para armazenamento e compartilhamento por algum tempo, embora com resultados mistos. Eles oferecem um modelo e uma API para armazenar dados NGS em seu repositório GitHub, mas pode ser um pouco trabalhoso obter uma visualização de alto nível. Não tenho certeza se alguma representação melhor disso existe em outro lugar.

Posso dizer por experiência pessoal (tendo construído mais de uma dúzia de bancos de dados genômicos), não existe um modelo de dados ideal e práticas recomendadas de armazenamento. Os dados genômicos vêm em muitas formas e tamanhos, e suas necessidades variam de acordo com todas as outras organizações, então o que funciona para um grupo de bioinformática não necessariamente funcionará para você. A melhor coisa a fazer é projetar e implementar um modelo que cobrirá todos os tipos de dados em seu fluxo de trabalho e análises downstream que você pode fazer com os dados e metadados.

Concordo que não existe um modelo de dados ideal que seja estável por muito tempo em um campo de rápida evolução como a informática do genoma. Talvez uma abordagem de banco de dados sem esquema (NoSQL ou algum outro sistema baseado em documento, como MongoDB) funcione melhor? Isso dá a você flexibilidade máxima para anexar qualquer informação relevante às entradas do banco de dados que você está adicionando agora, sem a necessidade de reconstruir o banco de dados posteriormente, se desejar anexar mais / informações diferentes às entradas subsequentes do banco de dados.

Para metadados , eu usaria um esquema SQL parecido com o seguinte:

  CREATE TABLE Projeto (ac TEXT, - projeto / acesso de estudo PRIMARY KEY ( ac)); CREATE TABLE Sample (- amostra biológica / biópsia ac TEXT, PRIMARY KEY (ac)); CREATE TABLE AnalysisSample (prj_ac TEXT, - projeto acccession (Project.ac) símbolo TEXT, - um nome curto exclusivo em o projeto sample_ac TEXT, - amostra de acesso (Sample.ac) PRIMARY KEY (prj_ac, símbolo)); CREATE TABLE Collection (- um arquivo BAM ac TEXT, - coleção / alinhamento de arquivo de acesso prj_ac TEXT, - project access ( Project.ac) PRIMARY KEY (ac)); CRIAR TABELA ReadGroup (cl_ac TEXT, - acesso de coleção (Collection.ac) rg_id TEXT, - @ RG-ID sample_sym TEXT, - @ RG-SM; correspondente AnalysisSample.symbol PRIMARY KEY (cl_ac, rg_id)); CREATE TABLE VariantSet (- um arquivo VCF ac TEXT, - VCF file access prj_ac TEXT, - project access (Project.ac) PRIMARY KEY (ac)); CRIAR TABELA Va riantSample (vs_ac TEXT, - acesso ao arquivo VCF (VariantSet.ac) sample_sym TEXT, - símbolo de amostra no arquivo VCF; correspondência AnalysisSample.symbol PRIMARY KEY (vs_ac, sample_sym));  

No esquema, você tem Projeto e tabelas biológicas Amostra , que são independentes umas das outras no alto nível. Um AnalysisSample descreve uma amostra usada em BAM ou VCF e conecta Projeto e Amostra biológica. É importante ressaltar que cada AnalysisSample possui um símbolo exclusivo em um projeto (consulte o índice primário). Este é o símbolo em uma linha de grupo de leitura BAM ou em uma linha de amostra VCF. Uma Collection é, na verdade, um arquivo BAM / CRAM. Em teoria, um arquivo BAM pode conter mais de uma amostra (embora rara na prática), que é endereçada por uma tabela ReadGroup separada. Finalmente, um VariantSet é um arquivo VCF. VariantSample informa quais amostras estão incluídas em cada arquivo VCF.

Este é o esqueleto de um esquema completo. Você pode adicionar campos extras às tabelas apropriadas (por exemplo, caminho do arquivo e hg19 / hg38 / etc para Collection , ler comprimento para ReadGroup e ID de família para Sample ). Você também precisa de índices para junção de tabelas eficiente e talvez mais tabelas para estruturas complexas (por exemplo, pedigree).

Para os projetos dos quais participei, esse esquema deve funcionar na maioria das vezes. É inspirado no esquema JSON do GA4GH, mas minha versão é em SQL, é mais simples e também tem uma estrutura um pouco diferente que acho melhor.