과거부터 신약 개발은 비용과 시간이 많이 드는 매우 영역으로 평균 10 ~ 15년의 기간과 한화 약 1조, 1만 분의 1이라는 극악의 확률로 유명합니다. 기본적인 신약 개발 과정은 [그림 1]로 목표 질병에 대한 후보 물질 약 10,000개에서 시작 시 최종적으로 1개의 약물이 신약이 되는 것으로 보고 있습니다. 하지만 이마저도 많은 경우 실패로 돌아가며 많은 제약 회사들에게 고위험산업으로 인식되어 시도조차 되지 않는 현실입니다.
신약 개발에 있어 다양한 문제가 존재하지만 특히 맨 앞 부분인 후보 약물 탐색 (Drug Discovery)의 경우 매우 다량의 표준화되지 못한 실험 데이터들로 효율적인 약물 탐색이 어려운 문제가 있었습니다.
각각의 실험 마다 Relational Database (RDB) - Table 형식의 데이터로 정리되지만 후보 약물을 찾는데 중요한 단서인 데이터들 사이의 관계에 대해 단적으로 “어떤 단백질은 어떤 형태와 물성의 약물이 효과적인가?”에 대한 효율적인 답변을 제시하지 못했던 것입니다.
분명 서로 간에 관련이 있는 실험 혹은 데이터임에도 불구하고 어떤 방식으로 연관을 지을지, 어떤 형태/형식으로 묶어야 하는지 등 Table 형태의 데이터로는 한계점이 명확했다고 할 수 있습니다.
하지만 현재는 이러한 관계를 맺기에 매우 용이하고 형식에 있어 RDB보다 훨씬 자유로운 Graph Database (GDB)를 활용하면 앞서 겪었던 문제를 어느 정도 해소할 수 있습니다.
본 아티클에선 실제로 진행하는 후보 약물 탐색의 한 방법을 다양한 오픈 소스의 Table 데이터로 시작하여 Graph/Network로 만들고 제안해보는 내용을 소개하고자 합니다.
목표는 다양한 실험 데이터를 Disease - Protein - Drug 이라는 3가지 형식의 관계 데이터로 모델링하는 것으로 후보 약물 탐색을 위한 Backbone을 만드는 것입니다.
완성된 모습은 [그림 2]와 같은 형태로 다층 구조의 Graph 모델이 될 것입니다.
가장 먼저 구심점이 될 Protein - Protein Interaction Network를 만들기 위해 단백질 상호작용 정보 혹은 실험 정보를 제공하는 여러 오픈 데이터베이스의 정보를 수집합니다.
널리 알려진 데이터베이스로는 BioGrid, HuRI, MINT, IntAct, HINT, Reactome 등이 있습니다.
앞에서 설명한 바와 같이 데이터베이스 마다 제공 형식이 다르기 때문에 Table 형태로는 하나의 정보로 합치는 것이 어려우며 필요한 데이터만을 따와 형식에 구애받지 않는 Graph 형태로 가공해야 합니다.
실제 데이터를 예로 살펴보면 [그림 3]과 같은 형식의 Table 데이터를 얻을 수 있으며, 해당 데이터를 Python의 NetworkX 혹은 R의 igraph 라이브러리를 사용하여 [그림 4]와 같은 Graph 형태의 데이터로 변환할 수 있습니다.
[그림 3]의 데이터는 총 11개의 컬럼으로 이루어져 있으며, 사용할 열 정보는 OFFICAL_SYMBOL_A, OFFICAL_SYMBOL_B, ORGANISM_A_ID, ORGANISM_B_ID입니다. 앞의 SYMBOL_A/B는 임의의 단백질 A와 B가 서로 물리적으로 붙어서 발견된다는 실험 정보를 의미하고 뒤의 ORGANISM_A/B의 경우 단백질 A와 B가 발견된 종 (ex. 인간, 쥐 etc.) 정보를 의미합니다. 이제 해당 정보만을 추출하여 단백질 A와 B를 노드로 만들고 해당 정보들이 같은 행에 존재하면 에지로 연결하여 Graph로 만들어 줍니다.
[그림 4]는 모든 단백질 정보를 연결 후 알츠하이머와 연관되어 있는 단백질 APP를 기준으로 같이 발견된 단백질을 뽑은 결과물 입니다.
이와 동일한 방식으로 약물과 약물 질병과 질병을 묶을 수 있으며 약물의 경우 ChEMBL, DrugBank, DrugCentral 등의 데이터베이스가, 질병의 경우 DisGeNET, Disnor 등의 데이터베이스가 활용됩니다. 또한 각 영역 (Protein, Drug, Disease)을 [그림 2]의 점선으로 표시된 에지와 같이 서로 간에 연결시켜주기 위해 CTD, TCRD, ChEMBL, DrugBank, DisGeNET 등의 데이터베이스를 활용할 수 있습니다.
(ChEMBL, DrugBank, DisGeNET 등의 데이터베이스는 약물-약물, 질병-질병 외의 약물-단백질, 질병-단백질 등의 정보도 포함하고 있습니다.)
언급한 데이터베이스들의 실험 정보 형태는 다양하지만 결국 Graph 모델링을 할 때의 중요한 정보는 관계 정보로 ‘A라는 약물이 B라는 단백질을 억제한다’ 혹은 ‘C라는 질병을 가진 사람은 D라는 단백질이 정상적으로 발현되지 않는다’ 등 우리는 해당 정보들만 추출하여 서로 노드/에지의 표현 양식으로 연결만 해주면 되는 것입니다.
이후 완성된 Graph에 목표 질병을 시작으로 관련 단백질과 연관된 단백질, 더 나아가 단백질에 유효한 관계 (활성/억제)를 가진 약물과 화합물을 손쉽게 찾을 수 있습니다.
기존 Table 데이터로는 질병에서 연관 약물을 찾기까지 각 데이터를 비교해 가며 찾아가야 하지만 Graph 데이터는 한두 번의 질의만으로 연관 약물을 뽑아낼 수 있습니다.
무엇보다 Table 형태로는 연결을 상상하고 insight를 얻기 어렵지만, Graph 형태로 바꾼 이후에는 ‘관계’를 중심으로 다양한 insight을 얻기 용이하기에 데이터를 효율적으로 활용할 수 있으며 실제로 생물/화학정보학 분야에서는 이러한 형태로 데이터를 정의하고 표현하는 것을 Ontology라 부르며 사용하고 있습니다.
지금까지 신약 개발 과정의 맨 앞부분인 후보 물질 발굴에 사용될 수 있는 Graph 모델링 방법에 대해 소개드렸습니다. 기존 서로 다른 데이터들의 어려운 정규화 문제를 해당 방식을 활용하면 쉽고 효율적인 방식으로 다루고 유의미한 정보에 빠르게 접근할 수 있습니다.
비트나인의 Graph-Database인 AgensGraph는 우리가 지금까지 진행하여 얻은 Graph 데이터를 어떠한 추가 가공 없이 바로 밀어 넣고 활용할 수 있으며, RDB인 AgensSQL과 GDB 모델링을 GUI로 할 수 있도록 개발된 Graphizer를 사용하면 위 모든 과정을 진행하기 위해 Python/R 등의 코딩 프로그램 없이 노코드로 모델링을 진행할 수 있습니다.
글 : 최재한 선임 ( 비트나인 Product 기획팀 )
'DBMS > 활용 사례' 카테고리의 다른 글
| 가장 인기 있는 5가지 그래프 DB 쿼리 언어 (0) | 2023.09.03 |
|---|---|
| 그래프 기반 고객 행동 데이터 모델링 및 분석 방법론 (0) | 2023.09.03 |
| Data Lineage 활용 사례 (0) | 2023.09.03 |
| Graph Database와 OGM (0) | 2023.09.02 |
| PL/SQL과 PL/pgSQL의 비교 (0) | 2023.09.02 |