데이터 통합

데이터 통합은 여러 출처의 데이터를 결합, 공유 또는 동기화하여 사용자에게 통합된 시각을 제공하는 과정이다.^[1] 데이터 통합은 상업적(예: 기업이 여러 데이터베이스를 병합하는 경우)에서 과학적(서로 다른 생물정보학 저장소의 연구 데이터를 결합하는 경우)까지 매우 다양한 응용 분야가 있다.

데이터를 통합해야 할 필요성은 데이터의 양과 복잡성(빅 데이터)이 증가하고, 기존 데이터를 공유해야 할 필요성이 폭발적으로 커질 때 주로 발생한다.^[2] 데이터 통합은 광범위한 이론적 연구의 대상이 되었으며, 여전히 해결되지 않은 많은 문제가 남아 있다.

데이터 통합은 내부 사용자뿐만 아니라 외부 사용자 간의 협업을 촉진한다. 통합되는 데이터는 이기종 데이터베이스 시스템(영어판)에서 받아들여져, 클라이언트를 위한 파일 네트워크 전반에 걸쳐 동기화된 데이터를 제공하는 단일 일관성 데이터 저장소로 변환되어야 한다.^[3] 데이터 통합의 대표적 활용 예는 데이터 마이닝에서 기존 데이터베이스를 분석하고 정보를 추출하여 비즈니스 인텔리전스에 활용하는 경우이다.^[4]

이기종(영어판) 데이터 소스를 단일 쿼리 인터페이스 아래에서 결합하는 문제, 흔히 정보 사일로라 불리는 문제는 오랜 기간 존재해 왔다. 1980년대 초, 컴퓨터 과학자들은 이기종 데이터베이스의 상호 운용성을 위한 시스템 설계를 시작했다.^[5]

구조화된 메타데이터에 의해 구동되는 최초의 데이터 통합 시스템은 1991년 미네소타 대학교에서 통합 공공 마이크로데이터 시리즈(영어판)(IPUMS)를 위해 설계되었다. IPUMS는 데이터 웨어하우징 접근법을 사용하여, 이기종 소스에서 데이터를 추출·변환·적재한 뒤 단일 논리 스키마(영어판)로 통합해 서로 다른 소스의 데이터가 호환되도록 하였다.^[6] 수천 개의 인구 데이터베이스를 상호 운용 가능하게 함으로써, IPUMS는 대규모 데이터 통합의 실현 가능성을 입증했다. 데이터 웨어하우스 접근법은 강결합 아키텍처를 제공하는데, 데이터가 이미 단일 쿼리 저장소에 물리적으로 통합되어 있으므로 쿼리 해결에 일반적으로 시간이 거의 걸리지 않는다.^[7]

데이터 웨어하우스 접근법은 데이터셋이 자주 갱신되는 경우에는 적합하지 않다. 동기화를 위해 [추출, 변환, 적재] 과정을 지속적으로 반복 실행해야 하기 때문이다. 또한, 요약 데이터 소스에 대한 쿼리 인터페이스만 있고 전체 데이터에 접근할 수 없는 경우, 데이터 웨어하우스 구축에 어려움이 발생한다. 이러한 문제는 여행, 중고 광고 등 여러 상업적 쿼리 서비스 통합 시 자주 나타난다.

2009년 이후에는 데이터를 약결합(영어판) 방식으로 처리하고,^[8] 중재 스키마를 통한 실시간 데이터 접근을 위한 통합 쿼리 인터페이스를 제공하는 경향이 두드러졌다(그림 2 참조). 이 방식은 정보가 원본 데이터베이스에서 직접 검색되도록 한다. 이는 그 당시 유행하던 SOA 접근법과 일치한다. 이 방식은 중재 스키마와 원본 스키마 간의 매핑에 의존하며, 쿼리를 원본 데이터베이스의 스키마에 맞는 하위 쿼리로 변환한다. 이러한 매핑은 두 가지 방식으로 지정할 수 있다: 중재 스키마의 엔티티에서 원본 소스의 엔티티로 매핑하는 "Global-as-View"^[9](GAV) 접근법, 또는 원본 소스의 엔티티에서 중재 스키마로 매핑하는 "Local-as-View"^[10](LAV) 접근법이다. 후자의 경우, 쿼리 처리를 위해 더 복잡한 추론이 필요하지만, (안정적인) 중재 스키마에 새로운 데이터 소스를 쉽게 추가할 수 있다. 2010년 기준^[update], 데이터 통합 연구의 일부는 시맨틱 통합(영어판) 문제에 집중하고 있다. 이 문제는 통합 아키텍처 구조화가 아니라, 이기종 데이터 소스 간 시맨틱 충돌을 어떻게 해결할 것인지에 관한 것이다. 예를 들어, 두 회사가 데이터베이스를 병합할 때, 각각의 스키마에서 "수익"과 같은 개념과 정의가 다를 수 있다. 한 데이터베이스에서는 달러(실수형)로, 다른 곳에서는 판매 건수(정수형)로 정의될 수 있다. 이러한 문제 해결을 위해 온톨로지를 활용하여 스키마 용어를 명시적으로 정의하고 시맨틱 충돌을 해결하는 전략이 흔히 사용된다. 이는 온톨로지 기반 데이터 통합(영어판)에 해당한다. 한편, 서로 다른 생물정보학 저장소의 연구 결과를 결합하는 문제는, 여러 데이터 소스에서 계산된 유사도를 단일 기준(예: 양성 예측값)으로 벤치마킹하여 직접 비교 가능하게 하고, 실험의 성격이 달라도 통합할 수 있도록 한다.^[11]

2011년 기준^[update], 기존 데이터 모델링 방식이 모든 데이터 아키텍처(영어판)에 데이터 고립을 야기하여, 서로 다른 데이터 모델의 섬과 정보 사일로가 형성된다는 것이 밝혀졌다. 이 데이터 고립은 데이터 모델링 방법론의 의도치 않은 산물로, 서로 다른 데이터 모델이 개발되는 결과를 낳는다. 이러한 데이터 모델이 데이터베이스로 구현되면, 이질적인 데이터베이스가 된다. 데이터 고립 현상을 제거하고 통합 데이터 모델 개발을 촉진하기 위한 향상된 데이터 모델 방법론이 개발되었다.^[12] 한 향상된 데이터 모델링 방법은 표준화된 데이터 엔터티 형태의 구조적 메타데이터를 데이터 모델에 추가하여 데이터 모델을 재구성한다. 여러 데이터 모델을 재구성하면, 이 데이터 모델들이 공통으로 가지는 구조적 메타데이터를 기반으로 하나 이상의 공통성 관계를 공유하게 된다. 공통성 관계는 여러 데이터 모델의 표준화된 데이터 엔터티를 연결하는 동등 관계이다. 동일한 표준 데이터 엔터티를 포함하는 여러 데이터 모델이 동일한 공통성 관계에 참여할 수 있다. 통합 데이터 모델이 데이터베이스로 구현되고, 공통 마스터 데이터 집합으로 적절히 채워지면 이 데이터베이스들은 통합된다.

2011년 이후로는 데이터 허브 접근법이 완전히 구조화된(일반적으로 관계형) 엔터프라이즈 데이터 웨어하우스보다 더 큰 관심을 받게 되었다. 2013년 이후로는 데이터 레이크 접근법이 데이터 허브 수준으로 부상하였다. (세 용어의 구글 트렌드 비교^[13]) 이러한 방식은 비정형 또는 다양한 데이터를 한 곳에 모으지만, 허브 내의 모든 데이터를 구조화하고 정의하는 (복잡한) 마스터 관계형 스키마가 반드시 필요한 것은 아니다.

최근에는 활용되는 애플리케이션의 수가 크게 증가하고, 애플리케이션 간 통합이 중요해지면서 [통합 API]가 등장하였다. 이는 개발자가 자신의 앱을 다른 앱과 통합할 수 있도록 돕고, 최근에는 [MCP - 모델 컨텍스트 프로토콜]이 AI 에이전트 통합까지 한 단계 더 발전시켰다.... 데이터 통합은 시장 조사를 위한 데이터 수집 등 비즈니스에서 매우 중요한 역할을 한다. 소비자로부터 수집한 원시 데이터를 일관성 있는 데이터로 변환하는 것은 기업이 다음 전략을 결정할 때 시도하는 일이다.^[14] 조직들은 데이터 마이닝을 활용하여 데이터베이스에서 정보와 패턴을 수집하는 일이 점점 많아지고 있으며, 이는 새로운 비즈니스 전략을 개발하고 비즈니스 성과를 높이며 경제 분석을 더 효율적으로 수행하는 데 도움이 된다. 수집한 방대한 데이터를 시스템에 저장하는 것도 비즈니스 인텔리전스를 위한 데이터 통합의 한 형태로, 성공 가능성을 높이는 데 기여한다.^[15]

사용자가 도시별 각종 정보(범죄 통계, 날씨, 호텔, 인구통계 등)를 조회할 수 있는 웹 애플리케이션을 생각해보자. 전통적으로 이러한 정보는 단일 데이터베이스와 단일 스키마에 저장되어야 한다. 그러나 한 기업이 이처럼 방대한 정보를 수집하는 것은 어렵고 비용이 많이 든다. 설령 데이터를 모두 수집한다 해도, 기존 범죄 데이터베이스, 날씨 웹사이트, 인구조사 데이터 등과 중복될 가능성이 높다.

데이터 통합 솔루션은 이러한 외부 자원을 가상 중재 스키마(영어판) 위의 구현 뷰로 간주하여 "가상 데이터 통합"을 실현할 수 있다. 즉, 애플리케이션 개발자는 사용자가 원하는 답변 유형에 가장 적합한 가상 스키마(중재 스키마)를 설계한다. 다음으로, 범죄 데이터베이스나 날씨 웹사이트 등 각 데이터 소스에 대한 "래퍼" 또는 어댑터를 설계한다. 이 어댑터는 각 사이트나 데이터베이스가 반환하는 쿼리 결과를 데이터 통합 솔루션이 처리하기 쉬운 형태로 변환한다(그림 2 참조). 사용자가 중재 스키마에 쿼리를 실행하면, 데이터 통합 솔루션이 이를 각 데이터 소스에 맞는 쿼리로 변환한다. 마지막으로, 가상 데이터베이스가 이 쿼리 결과를 결합하여 사용자의 질문에 대한 답변을 제공한다.

이 솔루션의 장점은 새로운 소스를 추가할 때 해당 소스에 대한 어댑터나 소프트웨어 블레이드만 만들면 된다는 점이다. ETL 시스템이나 단일 데이터베이스 솔루션과는 달리, 전체 데이터셋을 시스템에 수동으로 통합할 필요가 없다. 가상 ETL 솔루션은 가상 중재 스키마(영어판)를 활용하여 데이터 조화를 구현하며, 지정된 "마스터" 소스에서 정의된 타깃으로 필드별로 데이터를 복사한다. 고급 데이터 가상화(영어판)는 객체 지향 모델링 개념을 기반으로 허브 앤 스포크 아키텍처를 사용해 가상 중재 스키마나 가상 메타데이터 저장소를 구축한다.

각 데이터 소스는 서로 다르며, 데이터 소스 간 신뢰할 수 있는 조인을 지원하도록 설계되지 않았다. 따라서 데이터 가상화 및 데이터 페더레이션은 이질적 데이터셋 간의 우연한 데이터 공통성에 의존해 데이터를 결합한다. 데이터 값의 공통성이 부족하기 때문에 반환 결과는 부정확하거나 불완전하며, 검증이 불가능할 수 있다.... 한 가지 해결책은 이질적 데이터베이스를 재구성하여 ETL 없이 통합하는 것이다. 재구성된 데이터베이스는 데이터베이스 간 참조 무결성을 보장하는 공통성 제약을 지원한다. 이렇게 하면 데이터 값의 공통성이 데이터베이스 간에 보장되는 설계된 데이터 접근 경로를 제공할 수 있다.

데이터 통합의 이론^[1]은 데이터베이스 이론의 하위 분야로, 문제의 근본 개념을 1차 논리로 형식화한다. 이 이론을 적용하면 데이터 통합의 실현 가능성과 난이도를 평가할 수 있다. 정의는 추상적으로 보일 수 있지만, 중첩 관계형/XML 데이터베이스를 포함한 모든 통합 시스템^[16]과 데이터베이스를 프로그램으로 취급하는 시스템^[17][18]까지 포괄할 만큼 충분히 일반적이다. 오라클이나 DB2와 같은 특정 데이터베이스 시스템과의 연결은 JDBC 같은 구현 기술로 제공되며, 이론적 수준에서는 다루지 않는다.

데이터 통합 시스템은 일반적으로 튜플 ${\displaystyle \left\langle G,S,M\right\rangle }$로 정의된다. 여기서 ${\displaystyle G}$는 글로벌(또는 중재) 스키마, ${\displaystyle S}$는 이기종 소스 스키마 집합, ${\displaystyle M}$은 소스와 글로벌 스키마 간 쿼리 매핑이다. ${\displaystyle G}$와 ${\displaystyle S}$ 모두 각각의 관계에 대한 기호로 구성된 형식 언어로 표현된다. 매핑 ${\displaystyle M}$은 ${\displaystyle G}$와 ${\displaystyle S}$에 대한 쿼리 간의 단언으로 이루어진다. 사용자는 데이터 통합 시스템에 쿼리를 제시할 때 ${\displaystyle G}$에 대해 쿼리를 제출하고, 매핑은 글로벌 스키마와 소스 스키마의 요소 간 연결을 단언한다.

스키마 위의 데이터베이스는 각 관계에 대해 하나씩, 여러 집합의 집합으로 정의된다(관계형 데이터베이스의 경우). 소스 스키마 ${\displaystyle S}$에 해당하는 데이터베이스는 각 이기종 데이터 소스에 대한 튜플 집합의 집합으로 구성되며, 이를 소스 데이터베이스라 한다. 이 소스 데이터베이스는 실제로는 여러 개의 분리된 데이터베이스 집합일 수 있다. 가상 중재 스키마 ${\displaystyle G}$에 해당하는 데이터베이스는 글로벌 데이터베이스라 한다. 글로벌 데이터베이스는 소스 데이터베이스에 대해 매핑 ${\displaystyle M}$을 만족해야 한다. 이 매핑의 합법성은 ${\displaystyle G}$와 ${\displaystyle S}$ 간의 대응 방식에 따라 달라진다. 대표적 모델링 방식으로 Global as View(GAV)와 Local as View(LAV)가 있다.

GAV 시스템은 글로벌 데이터베이스를 ${\displaystyle S}$에 대한 뷰 집합으로 모델링한다. 이 경우 ${\displaystyle M}$은 ${\displaystyle G}$의 각 요소에 대해 ${\displaystyle S}$에 대한 쿼리를 연결한다. 쿼리 처리는 ${\displaystyle G}$와 ${\displaystyle S}$ 간의 명확한 연결 덕분에 비교적 단순하다. 복잡성의 부담은 데이터 통합 시스템이 소스 데이터베이스에서 요소를 어떻게 가져올지 명확히 지시하는 중재자 코드 구현에 있다. 새로운 소스가 시스템에 추가될 경우, 중재자를 업데이트하는 데 상당한 노력이 필요할 수 있어, GAV는 소스가 변경될 가능성이 적을 때 선호된다.

위 예시의 데이터 통합 시스템에서 GAV 접근을 적용하면, 시스템 설계자는 먼저 각 도시 정보 소스에 대한 중재자를 개발한 뒤, 이 중재자를 중심으로 글로벌 스키마를 설계한다. 예를 들어, 한 소스가 날씨 웹사이트라면, 설계자는 글로벌 스키마에 날씨 항목을 추가할 것이다. 이후에는 날씨에 대한 술어를 날씨 웹사이트 쿼리로 변환하는 중재자 코드를 작성하는 데 주력한다. 만약 다른 소스도 날씨와 관련될 경우, 두 소스의 결과를 올바르게 결합하는 코드를 작성해야 하므로 복잡해질 수 있다.

반면 LAV에서는 소스 데이터베이스를 ${\displaystyle G}$에 대한 뷰 집합으로 모델링한다. 이 경우 ${\displaystyle M}$은 ${\displaystyle S}$의 각 요소에 대해 ${\displaystyle G}$에 대한 쿼리를 연결한다. 여기서는 ${\displaystyle G}$와 ${\displaystyle S}$ 간의 정확한 연결이 더 이상 명확하지 않다. 다음 절에서 설명하듯, 소스에서 요소를 어떻게 가져올지는 쿼리 프로세서에 맡겨진다. LAV 모델링의 장점은 새로운 소스를 추가할 때 GAV보다 훨씬 적은 작업만 필요하므로, 중재 스키마가 불안정하거나 변경 가능성이 높을 때 적합하다.^[1]

위 예시 시스템에서 LAV 접근을 적용하면, 시스템 설계자는 먼저 글로벌 스키마를 설계한 뒤, 각 도시 정보 소스의 스키마를 입력한다. 예를 들어, 한 소스가 날씨 웹사이트라면, 이미 없다면 글로벌 스키마에 날씨 항목을 추가한다. 그 다음 프로그래머가 웹사이트용 어댑터 또는 래퍼를 작성하고, 웹사이트 결과의 스키마 설명을 소스 스키마에 추가한다. 새로운 소스 추가의 복잡성은 설계자에서 쿼리 프로세서로 이동한다.

데이터 통합 시스템의 쿼리 처리 이론은 일반적으로 결합 쿼리와 Datalog(영어판)(순수 선언적 논리 프로그래밍 언어)를 사용해 표현된다.^[20] 결합 쿼리는 데이터베이스의 관계에 적용되는 논리 함수(예: "${\displaystyle f(A,B)}$ where ${\displaystyle A<B}$")로 생각할 수 있다. 튜플을 대입하여 규칙을 만족시키면(참이면), 해당 튜플은 쿼리의 답변 집합에 포함된다. Datalog 같은 형식 언어는 이러한 쿼리를 간결하고 명확하게 표현하지만, 일반 SQL 쿼리도 결합 쿼리에 해당한다. 데이터 통합에서 "쿼리 포함성"은 결합 쿼리의 중요한 속성이다. 쿼리 ${\displaystyle A}$가 쿼리 ${\displaystyle B}$를 포함한다(${\displaystyle A\supset B}$)는 것은, 어떤 데이터베이스에 대해서도 ${\displaystyle B}$의 결과가 ${\displaystyle A}$의 결과의 부분집합임을 의미한다. 두 쿼리는 어떤 데이터베이스에 대해서도 결과 집합이 같으면 동등하다. 이는 GAV와 LAV 시스템 모두에서, 사용자가 가상 스키마(뷰 집합 또는 "구현된" 결합 쿼리) 위에 결합 쿼리를 제시하는 상황에 중요하다. 통합의 목적은 뷰로 표현된 쿼리를 사용자의 쿼리와 동등하거나 최대한 포함되도록 재작성하는 것이다. 이는 뷰를 사용한 쿼리 응답 문제에 해당한다.^[21]

GAV 시스템에서는 시스템 설계자가 쿼리 재작성용 중재자 코드를 작성한다. 사용자의 쿼리 각 요소는 대입 규칙에 대응하며, 글로벌 스키마의 각 요소는 소스에 대한 쿼리에 대응한다. 쿼리 처리는 중재자에 지정된 규칙에 따라 사용자의 쿼리 하위 목표를 확장하므로, 결과 쿼리는 동등할 가능성이 높다. 설계자가 사전 작업을 대부분 수행하지만, Tsimmis와 같은 일부 GAV 시스템은 중재자 설명 과정을 단순화한다.

LAV 시스템에서는 중재자가 없어 사용자의 쿼리를 간단히 확장할 수 없으므로, 쿼리가 더 급진적으로 재작성된다. 통합 시스템은 가능한 쿼리 공간을 탐색하여 최적의 재작성을 찾아야 한다. 결과 쿼리는 동등하지 않고 최대 포함일 수 있으며, 결과 튜플이 불완전할 수 있다. 2011년 기준^[update] GQR 알고리즘^[22]이 LAV 데이터 통합 시스템의 대표적 쿼리 재작성 알고리즘이다.

일반적으로 쿼리 재작성의 복잡도는 NP-완전이다.^[21] 재작성 공간이 상대적으로 작다면, 수백 개의 소스를 가진 통합 시스템에서도 문제가 되지 않는다.

실세계 근거(영어판), 지구 온난화, 침입종 확산, 자원 고갈 등 과학의 대규모 문제들은 메타분석을 위해 이질적 데이터셋의 수집을 점점 더 요구하고 있다. 생태학 및 환경 데이터는 메타데이터 표준(영어판)이 통일되어 있지 않고 데이터 유형이 다양해, 이런 유형의 데이터 통합은 특히 어렵다. 미국 국립과학재단의 Datanet(영어판) 등은 과학자들이 사이버인프라(영어판)와 표준을 제공받아 데이터 통합을 쉽게 할 수 있도록 지원한다. 다섯 개의 Datanet(영어판) 프로젝트는 DataONE(영어판),^[23] Data Conservancy,^[24] SEAD: Sustainable Environment through Actionable Data,^[25] DataNet Federation Consortium,^[26] 그리고 Terra Populus^[27]이다. Research Data Alliance(영어판),^[28]는 최근 글로벌 데이터 통합 프레임워크 구축을 탐색하고 있다. OpenPHACTS(영어판) 프로젝트는 유럽연합 혁신 의약품 이니셔티브(영어판)의 지원을 받아 유럽 생물정보학 연구소, 왕립화학회, UniProt, WikiPathways(영어판), DrugBank 등 여러 데이터셋을 연결한 신약 개발 플랫폼을 구축했다.

• 비즈니스 시맨틱 관리(영어판)

• 변경 데이터 캡처

• 코어 데이터 통합(영어판)

• 사이버인프라(영어판)

• 데이터 블렌딩(영어판)

• 데이터 큐레이션(영어판)

• 데이터 퓨전(영어판)

• 데이터 매핑

• 데이터 랭글링

• 데이터베이스 모델

• 데이터스페이스(영어판)

• 엣지 데이터 통합(영어판)

• 엔터프라이즈 애플리케이션 통합

• 엔터프라이즈 아키텍처 프레임워크(영어판)

• 엔터프라이즈 정보 통합(영어판) (EII)

• 엔터프라이즈 통합(영어판)

• Geodi: 지구과학 데이터 통합

• 정보 통합(영어판)

• 정보 사일로

• 통합 역량 센터(영어판)

• 통합 컨소시엄(영어판)

• ISO 15926: 석유 및 가스 생산 시설을 포함한 프로세스 플랜트의 수명 주기 데이터 통합

• JXTA(영어판)

• 마스터 데이터 관리(영어판)

• 객체-관계 매핑

• Open Text(영어판)

• 시맨틱 통합(영어판)

• 스키마 매칭(영어판)

• 3계층 접근법(영어판)

• UDEF(영어판)

• 웹 데이터 통합(영어판)

• 웹 서비스