dbparser: de bancos de dados complexos de medicamentos para fluxos de trabalho R reproduzíveis

Grandes bancos de dados farmacológicos são valiosos porque preservam relações complexas entre medicamentos, alvos, vias, produtos, efeitos adversos e interações. Eles são difíceis de analisar exatamente pelo mesmo motivo. O DrugBank chega como XML profundamente aninhado; onSides como arquivos CSV relacionais; TWOSIDES como dados de interação compactados. dbparser converte essas diferentes fontes em objetos R consistentes e fluxos de trabalho de integração rastreáveis.

01O problema é estrutural, não cosmético

Um banco de dados farmacológico não é uma planilha com muitas colunas. Os registros de medicamentos se conectam a alvos, enzimas, transportadores, vias, produtos, referências e identificadores externos. Um analisador que apenas nivela o arquivo pode facilitar o carregamento do resultado e, ao mesmo tempo, destruir silenciosamente as relações que dão significado aos dados.

As fontes também discordam sobre formatos e identificadores. O DrugBank usa uma grande hierarquia XML. O OnSides distribui tabelas CSV relacionadas derivadas de rótulos de medicamentos. TWOSIDES usa uma representação plana comprimida de eventos adversos associados a pares de medicamentos. Os scripts ad-hoc podem unir uma análise, mas geralmente ocultam suposições sobre uniões, versões e valores ausentes.

02Um objeto comum sem apagar a fonte

dbparser apresenta o dvobject—um objeto drugverse implementado como uma lista R com padrões de acesso consistentes. Ele retém tabelas organizadas para análise, metadados sobre o processo de lançamento e análise do banco de dados e mapeamentos que descrevem como as tabelas se relacionam entre si.

Para uma única liberação do DrugBank, o objeto pode expor informações sobre medicamentos, sais, produtos, referências e as estruturas conectadas transportador-enzima-alvo-transportador. Quando as fontes são mescladas, o mesmo objeto ganha componentes de banco de dados aninhados e tabelas integradas, em vez de se tornar uma coleção não documentada de uniões.

03Do analisador ao mecanismo de integração

O pacote atual usa o DrugBank como núcleo mecanístico. OnSIDES contribui com eventos adversos extraídos dos rótulos de medicamentos da FDA, enquanto TWOSIDES contribui com eventos adversos associados a combinações de medicamentos. A arquitetura hub-and-spoke reduz o número de mapeamentos de identificadores que precisam ser mantidos e torna explícito o caminho de integração.

Esse design é uma desvantagem: fluxos de trabalho de vários bancos de dados dependem dos identificadores e mapeamentos do DrugBank. Mas é uma compensação visível e testável, em vez de uma suposição implícita escondida em um caderno único.

04A engenharia de software em torno do analisador

Um pacote de pesquisa útil precisa de mais do que funções de análise operacionais. Precisa de uma interface pública estável, testes, documentação, metadados, exemplos, versões identificadas e um processo de revisão das alterações. O dbparser é distribuído pelo CRAN, documentado pela rOpenSci, publicado sob licença MIT e mantido em um repositório público.

O pacote passou pela revisão por pares da rOpenSci, e seu artigo de software foi publicado no Journal of Open Source Software em fevereiro de 2026. Esse registro é importante porque torna verificáveis as alegações de qualidade: os usuários podem consultar o repositório, a discussão da revisão, a versão arquivada, a documentação e o rastreador de problemas.

05Um fluxo de trabalho compacto e reproduzível

O código abaixo mostra a ideia arquitetônica sem escondê-la por trás de uma interface gráfica. Cada fonte é analisada de forma independente. Os objetos resultantes são então mesclados por meio de operações explícitas e encadeáveis. O código permanece deliberadamente inalterado na documentação do pacote.

library(dbparser)
library(dplyr)

drugbank_db <- parseDrugBank("data/drugbank.xml")
onsides_db  <- parseOnSIDES("data/onsides/")
twosides_db <- parseTWOSIDES("data/TWOSIDES.csv.gz")

final_db <- drugbank_db %>%
  merge_drugbank_onsides(onsides_db) %>%
  merge_drugbank_twosides(twosides_db)

head(final_db$integrated_data$drug_drug_interactions)

06Do projeto estudantil à infraestrutura de pesquisa

O CRAN grava o primeiro lançamento do dbparser em dezembro de 2018. O arquivo público então mostra uma sequência de versões mantidas em vez de um upload único. Na versão 2.2.1, publicada em janeiro de 2026, o pacote foi além da análise exclusiva do DrugBank para oferecer suporte a fluxos de trabalho integrados de farmacovigilância em três fontes.

A documentação do projeto identifica o uso em mais de dez publicações revisadas por pares, abrangendo reaproveitamento de medicamentos, biomarcadores, modelagem de caminhos e análise de ensaios clínicos. A história mais forte, portanto, não é que um aluno tenha escrito um analisador. É que o trabalho sobreviveu ao contato com outros pesquisadores, à alteração dos bancos de dados de origem, à revisão de pacotes e à manutenção de longo prazo.

07O ex-aluno por trás do projeto de código aberto

Mohammed Ali é ex-aluno de DSTI, autor e mantenedor do dbparser. Ali Ezzat é coautor do pacote e do artigo do JOSS. Seu registro público permite que os leitores inspecionem o software em vários níveis: a versão estável do CRAN, o manual de referência completo, a documentação do OpenSCI, o repositório de origem, a discussão da revisão do software e a publicação arquivada do JOSS.

Essa abertura faz parte do resultado da engenharia. Uma ferramenta de pesquisa reproduzível deve permitir rastrear não apenas a saída de uma análise, mas também a versão do software, a liberação dos dados de origem e as decisões que transformaram uma na outra.

Software, documentação e publicação

Fonte e nota editorial: Artigo desenvolvido a partir do registro do projeto estudantil anterior na DSTI, de um manuscrito fornecido e das fontes atuais do CRAN, da rOpenSci, do repositório e do JOSS. Os nomes técnicos, as funções do pacote, o código e os títulos das publicações foram preservados com exatidão.