데이터 웨어하우스를 위한 데이터베이스 설계 : 기본요건

많은 데이터베이스 설계자들은 데이터 웨어하우스 설계에는 오직 세가지 규칙만이 있다고 말한다. 그것은 '간단하게 하라. 간단하게 하라. 그리고 간단하게 하라'는 규칙이다. 데이터 웨어하우스가 급속히 성장하는 경향이 있고 사용자 수가 극적으로 상승하고 있기는 하지만, 도매업 판매에서 부터 통신, 의료에 이르기까지 어느 산업에서든 모든 데이터 웨어하우스 응용 프로그램의 모범이 될 만한 한가지 훌륭한 설계는 언제나 매우 간단한 설계이다. 단순성의 원리는 데이터 베이스가 실제 사용자들 즉, 업무 분석가들이 이해할 수 있는 스키마(schema)로 시각화 되어야 한다는 개념에 바탕을 두고 있다. 이 원칙은 깨끗하고 일관성 있는 데이터를 사용하고 속도를 위해 설계한다는 보완적 요건과 마찬가지로 데이터 웨어하우스를 위한 효과적 데이터베이스 설계에 관한 이 논의의 중심을 이룬다. 속도문제는 두가지 측면의 문제이다. 즉, 설계자들은 사용자들이 조회에 대한 신속한 반응을 얻을 수 있도록, 그리고 관리자들이 소스에서 웨어하우스로 데이터를 신속히 적재할 수 있도록 보장해야 한다. 이러한 요건들을 자세히 검토하기 전에, 먼저 데이터 웨어하우스 설계의 전반적인 목표, 다시말해 의사 결정 지원을 위해 최적화된 데이터베이스 스키마를 창출해야 한다는 목표를 분명히 할 필요가 있다. 운영 또는 온라인 트랜잭션 처리 (on-line transaction processing:OLTP)시스템을 위해 설계된 데이터 베이스와 의사결정 지원 시스템 (decision-support system:DSS)을 위해 설계된 데이터베이스 사이에는 근본적인 차이가 있다. OLTP시스템들은 종종 데이터 웨어하우스를 채우는 소스 데이터를 제공하는 반면, 효율적이고 정확한 분석을 수행하기 위해 그리고 업무 분석가들이 정기적으로 필요로 하는 신뢰성 있는 보고서를 작성하기 위해 필요한 구조와 능력은 결여하고 있다. 랠프 킴벌의  표현처럼 "데이터 웨어하우스 구조"로서 데이터 웨어하우스는 조용하지만 OLTP시스템은 "반짝거린다". 다른 말로 표현하자면 데이터베이스의 내용들은 각각의 새로운 트렌잭션이 들어올때마다 바뀐다. 정확한 해답은 데이터가 변경되지 않고 보호되며 무결성이 엄격히 유지되는 웨어하우스 데이터베이스에서만 나온다. 완료 데이터를 얻기 위해 설계된 데이터베이스와 유용한 정보를 끌어내기 위해 설계된 데이터베이스간의 이러한 본질적인 차이를 감안하여 이 글에서는 다음과 같은 웨어하우스 데이터베이스 설계의 네가지 기본적인 요건을 비교적 자세히 다룬다. 스키마는 간단해야한다. 데이터는 깨끗하고 일관성이 있으며 정확해야 한다. 조회처리는 신속해야한다. 데이터를 데이터베이스에 상당히 빠르게 적재할수 있어야 한다. 데이터 웨어하우스는 최종 사용자들에게 보탬이 되도록 설계되어야 하며, 설계자 자신들이나 웨어하우스 환경을 유지하는 데이터베이스 관리자들 (Data administrator :DBA)과 경영 정보 시스템(Management Information System :MIS) 요원들에게 이익이 되도록 설계되어서는 안된다. 전통적으로, 데이터베이스 스키마는 모델내의 두개의 점 사이에 여러개의 순환적 결합 경롤를 가진 표들의 복잡한 상관성들로 구성된다. 결과적으로, 두개 의 표를 결합하는 조회는 지정된 경로에 따라 다른 방식으로 처리 될 수 있다. 이러한 종류의 스키마들은 최종 사용자가 업무 모델로서 인식하기에 어려울 뿐만 아니라, 작성자들이 시각화하기에도 어렵다. 갱신될 수 있는 각 논리적 항목은 트랜잭션이 이루어질때마다 나머지 데이터베이스에 거의 또는 전혀 파장 효과를 주지 않도록 자체표를 가진다. 그 결과, 전체로 본 스키마는 수십개의 표들로 구성되며, 이 표들은 모두 다수-대-일(many-to-one) 관계의 미로로 연결되어 있다. 트랜잭션 처리를 위해서는 효율적이지만, 이러한 관계는 직관적이지 않은 경향이 있으며 조회 작성시 혼란을 초래할 수 있다. 예를 들어, 어떤 제품들이 어느 해당 고객에게 선적되었는지를 추적하기 위해 이 스키마를 어떻게 사용할지 고려해 보라. 고객 표는 선적 표와 주문표를 가진 일-대-다수(one-to-many) 관계를 가지며, 따라서 얼핏 보면, 이것은 동일한 조회를 작성하기 위해 두개의 다른 결합 경로, 즉 고객 대 선적 대 주문항목 또는 고객 대 주문 대 주문항목 대 선적이라는 결합 경로를 사용할 수 있을 것 처럼 보인다. 두번째 경로를 취하는 사용자들은 조회가 무엇이 선적되었는지 보다는 오히려 무엇이 주문되었는지를 알려줄 것임을 깨닫지 못할 수도 있다. 이러한 종류의 모호성은 데이터 웨어하우징 스키마에는 적합하지 않다. 즉, 업무 분석가가 데이터베이스를 이해하고 창의적인 질문을 묻고 올바른 대답을 얻어야 한다면, 좀더 단순한 것이 필요하다. 업무 분석가는 업무를 안팎으로 잘 알고 있고, 의사 결정에 영향을 줄 수 있는 추세와 비정상성을 찾기 위해 그러한 지식을 사용하여 웨어 하우스에 저장된 사실과 수치를 탐구하고자 하는 사람이다. 예를 들어, 어떤 제품들이 언제 어디에서 성공을 거두는지를 근거로 기업체가 어떤 방향으로 나아가야 할 지에 관한 결정을 내리거나, 몇몇 판매 전략들이 어느 시장에서는 효과를 발휘하고 어느 시장에서는 그렇지 않은가를 발견하는 등이 그러한 의사 결정에 속한다. 분석가들은 데이터베이스에 관한 그들의 지식 때문에 고용되는 것이 아니라, 사업에 관한 지식과 회사의 판매, 마케팅, 유통, 제조전략에 부가가치를 더하기 위해 그것을 어떻게 분석 할 것인지에 관한 지식 때문에 고용된다. 이러한 분석가들이 숙련된 기술이나 지식을 갖추지 않을 가능성이 가장 많은 부분은 체계쩍 조회 언어(Strucutured Query Language :SQL) 의 향상된 사용, 데이터 베이스가 어떻게 결합되고 유지되는가, 그리고 웨어하우스를 처음부터 작동시키려면 무엇이 필요한가에 관한 사항이다. 대부분의 분석가들은 그들의 조회를 구성하기 위해 원료 상태의 SQL보다는 일종의 전위 조회 도구를 사용하며, 이상적으로는 이 도구가 그들이 충분히 데이터베이스에 접근하고 그것을 사용할 수 있게 허용해야 한다. 분석가들은 특수 조회 작성을 지원받기 위해 또는 보고서 요청을 위해 MIS 부서에 의존해서는 안된다. SQL엔진은 데이터 베이스 소프트웨어에 상주해야지 MIS 관리자의 머리속에 들어있어서는 안된다. 이것은 조회 도구의 바탕이 되는 스키마가 직접적인 데이터베이스 접근을 용이하게 할 만큼 단순해야 한다는 것을 의미한다. 그러한 스키마를 완성하기 위해, 데이터 베이스 설계자는 분석가의 업무 요건들을 평가함으로 시작한다. 데이터 베이스 설계보다 선행되어야 하는 사용자와의 오랜 면담 과정이 진행되는 동안, 설계자는 사용자의 어휘속에서 모든 필수적인 업무특성들 , 또는 "차원"을 파악하여야 한다. 설계자는 현재 사용되고 있는 보고서들을 살펴보고, 보고서의 제목과 내용을 연구해야 하며, 웨어 하우스 설계에서 무엇이 보존될 필요가 있는지 판단해야 한다. 전형적인 보고서 제목으로는 무엇이 있는가? 부득이 포함시킬 사항은 무엇인가? 분류기준은 무엇인가? 이것들은 일련의 정확한 차원들을 상세히 계획하기 전에 제기해야 할 필요가 있는 일반적인 질문들이다. 예를 들어, 판매와 마케팅 환경에서는 고객이 누구이고 제품이 무엇인지, 또는 의료 응용 프로그램의 경우에는 의료 제공자가 누구이고 환자가 누구인지가 설계에 반영되어야 한다. 면담이 점차 진행됨에 따라, 설계자는 사용자 집단이 수많은 그룹 또는 부서로 구성되어 있다는 것을 알게 된다.