#title 데이터 웨어하우스 구성블록 [[TableOfContents]] ==== 장의 목표 ==== * 데이터 웨어하우스의 공식적인 정의를 재검토한다. * 특징들을 정의하는 것을 논의한다. * 데이터 웨어하우스와 데이터 마트를 분별한다. * 데이터 웨어하우스를 만드는 각 구성요소(component) 또는 구성블록(building block)을 연구한다. * 메타데이터를 소개하고 그 중요성을 강조한다. 데이터 웨어하우스는 정보 전달 시스템이다. 이 시스템에서는 기업의 데이터를 전략적인 의사결정에 적합한 정보로 통합하고 변환한다. 데이터 웨어하우스는 운영 시스템들로부터 이력 데이터를 수집하고, 외부 데이터와 결합합니다. 서로 다른 시스템에서의 데이터 불일치도 해결하고, 통합된 데이터 내용을 다양한 계층들의 사용자들에게 정보를 제공하는데 적합한 형태로 변환한다. 이러한 정보 전달 시스템을 만들기 위해서는 서로 다른 구성요소들이나 구성블록들을 필요로하게 된다. 이 구성블록들은 데이터 웨어하우스에 맞게 의도되어져 최적의 방법으로 합쳐지고 적합한 구조로 배치된다. 구성블록들의 적합한 형태로 통합하고 배치하려면 데이터 웨어하우스의 특징을 알아야 하는데, 선구자들은 다음과 같이 설명한다. 경영진의 의사결정을 지원하는데 있어서 데이터 웨어하우스는 * 주제중심의, * 통합된, * 비휘발성의, * 시간변이적인 데이터 집합이다. -Bill Inmon Sean Kelly는 다음과 같이 정의한다. * 분리되고(separate) * 이용가능하고(available) * 통합되고(integraed) * 시간을 새겨넣은(timestamped) * 주제중심의(subject oriented) * 비휘발성의(nonvolatile) * 접근가능한(accessible) ==== 특징을 정의하기 ==== ===== 주제중심[* 일반 운영업무를 위한 구조가 아님] ===== 운영계의 데이터는 각각의 응용 프로그램들에 의해 저장된다. 예를들어 주문처리 업무는 주문접수, 재고검사, 고객신용조회 등의 비즈니스 활동을 위해 필요한 데이터를 제공한다. 즉, 주문처리 중심으로 데이터가 구조화 된다.[* 이 부분은 논란의 여지가 있지만, 어쨌든 운영시스템의 데이터가 분석에 적합한 구조는 아니라는 것이 확실한다] 하지만 DW는 주제들에 의해서 데이터의 구조가 결정된다. 사업주제는 기업마다 다르다. 사업주제는 반드시 그 기업에서 필요한 영역이다. 예를 들어 제조회사의 경우 매출, 선정, 재고는 없어서는 안될 중요한 사업주제다. 소매점의 경우는 계산대에서의 매출이 결정적인 주제다. Opertaional Application은 주문처리, 대출, 클래임처리등이 해당되고, Data Warehouse Subject는 매출, 고객, 클래임, 제품등이 해당된다. ===== 통합 데이터 ===== 적절한 의사결정을 위해서는 다양한 소스들로부터 온 데이터를 같이 사용할 필요가 있다. 이는 서로다른 파일, 데이터베이스일 것이며, 운영체제나 문자코드, 네이밍룰, 코드등이 서로 다르게 표현되었을 수 있다. 데이터 웨어하우스에서 유용하게 쓰이기 위해서는 이러한 불일치를 제거하여야 한다. 여러가지 데이터를 표준화해야 되고 각 소스 응용 프로그램에서 데이터 이름들의 의미를 확인해야 한다. 표준화가 필요한 항목은 다음과 같다. * 네이밍룰 * 코드 * 데이터 속성 * 측정치 ===== 시간변이적인 데이터 ===== 운영 시스템에서는 현재 값을 유지하는 것이 중요하다. 물론 필요에서 의해서 이력 데이터를 저장하는 경우도 있다. 하지만 DW에 속한 데이터는 분서과 의사결정을 위한 것이다. 만약 한 고객의 구매 패턴을 조사한다면 현재뿐만이 아니라 과저의 데이터도 필요하게 된다. DW의 시간변이적인 성질은 과거의 분석을 허용하고, 정보를 현재까지 관련시켜서 설명하고, 미래에 대한 예측을 가능하게 한다. ===== 비휘발성 데이터 ===== 운영 시스템들로부터 온 데이터에서 부터 외부에서 얻어진 데이터는 변환되고, 통합되고, 저장된다. 운영 시스템의 데이터는 자주 갱신된다. 왜냐하면 현재 상태를 계속 유지해야 하기 때문이다. 하지만 DW는 과거의 상태를 알고자 하는 분석업무가 많기 때문에 데이터가 갱신되지 않는다.[* 논란이 있는 글이다. DW도 갱신된다. SCD(Slowly Changing Dimension)은 뭐란 말인가? Fact를 이야기 하는 것이라면 맞는 이야기다] ===== 데이터 구체화정도 ===== 운영 시스템의 데이터는 가장 상세 수준으로 유지된다. 하지만 DW는 주제에 맞게 적절한 구체화 정도를 유지해야 한다. 즉, 어느 정도의 요약된 데이터를 가장 상세한 수준으로 유지할 것인지 결정하는 것이 매우 중요하다. 예를 들어, 년 단위 주문건수와 년월 단위의 주문건수는 상세수준이 다른 것을 알 수 있다. ==== 데이터 웨어하우스와 데이터 마트 ==== 데이터 웨어하우스를 먼저 구축할 것인지 데이터 마트를 먼저 구축할 것인지에 관한 논란은 여전하다. 데이터 웨어하우스를 구축하기 전에 관련된 문제점을 질문하고 이야기 할 필요가 있다. * 하향식 또는 상향식 접근방법인가? * 전사적 또는 부서별인가? * 어느 것이 먼저인가? DW? DM? * 파일럿을 구축할 것인가? 또한 완전한 시스템을 구축하는가? * 종속적 또는 독립적인 데이터 마트인가? '''DW -> DM''' * 조직을 큰 그림으로 바라본다. * 하향식 접근 방법 * 매머드 데이터 웨어하우스 구축 '''DM -> DW''' * 상향식 접근 방법 * 개개의 지역적인 부서별 요구사항을 조사 * 조그만 크기의 부서별 데이터 마트들을 구축 ||'''Data Warehouse'''||'''Data Mart'''|| ||Corporate/Enterprise Wide||Deparatmental|| ||Union of all data marts||A single business process|| ||Data received from stagine area||Star-join(fact & dimensions)|| ||Queris on presentation resource||Technolgy optimal ofr data access and analysis|| ||Structure for corporate view of data||Structure to suit the departmental view of data|| ||Organized on E-R model|| || ===== 하향식 vs 상향식 ===== 하향식의 장단점은 다음과 같다. * 장점 * 진정한 기업의 노력, 데이터의 전사적 관점 * 본래 구조적이다 - 서로 다른 데이터 마트들의 조합이 아니다 * 내용에 관한 데이터의 단일 중앙 저장장치 * 중앙 집중화한 규칙들과 제어 * 반복적으로 구축되었다면 빠른 결과를 볼 수 있을 것이다. * 단점 * 반복적인 방법을 사용하더라도 구축하는데 더 오래 걸린다 * 실패에 대하여 높은 노출/위험 * 높은 수준의 교체-기능적인 기술들이 필요 * 개념에 대한 증명 없이 높은 비용이 든다 하향식의 경우 이상적이다. 하지만 높은 실패위험을 가지고 있다. 팀에 전문가가 없다면 이 접근방법은 위험해 질 수 있다. 또한 이 접근방법은 고위 경영진과 스폰서들에게 설득력이 없을 수 있다. 빠른 결과를 볼 수 없기 때문에 그들을 이해시키는 것이 매우 중요하다. 상향식의 장단점은 다음과 같다. * 장점 * 관리할 수 있는 일부들의 더 빠르고 더 쉬운 구현 * 유리한 투자수익과 개념에 대한 증명 * 더 작은 실패 위험 * 근본적으로 점진적. 중요한 데이터 마트를 첫 번째로 예정할 수 있다 * 프로젝트 팀을 배우게하고 성장하게 한다 * 단점 * 각 데이터 마트는 자체의 좁은 관점의 데이터를 가진다 * 모든 데이터 마트에 중복되는 데이터를 퍼지게 한다 * 모순되고 대립된 데이터를 계속 사용하게 한다 * 관리할 수 없는 인터페이스를 증식하게 한다 상향식의 가장 심각한 문제는 데이터의 조각화이다. 전체 관점이 아니기 때문에 전체 요구사항들에 대해서는 보는 눈이 없을 것이다. ===== 실용적인 접근방법 ===== 상향식과 하향식 접근방법의 장단점이 존재하므로 중용이 필요하다. 실용적인 접근방법의 주요 제안자는 Ralph Kimball 형님인데, 이 형님은 다음과 같이 이야기 한다. 1. 전체 기업 수준에서 요구사항들을 기획하고 정의하라 1. 완전한 데이터 웨어하우스를 위한 주변 구조를 만들어라 1. 데이터 내용을 일치시키고 표준화하라 1. 한번에 하나씩 Super Mart를 구현하여, 일련의 슈퍼마트들로 데이터 웨어하우스를 구현하라 이 방법의 핵심은 먼저 전사적 수준에서 기획한다는 것이다. ==== 구성요소들의 개관 ==== attachment:데이터웨어하우스구성블록/dw01.JPG * Source * Data Staging 추출, 변환, 적재를 위한 작업대로 클린징 작업도 이루어진다 * Data Storage - 빠른 접근이 아닌 분석을 위한 구로조 데이터가 보관되는 장소, 사용자의 관점에서는 읽기-전용이어야 함 * Information Delivery * Metadata * Management And Control ==== 데이터 웨어하우스에서의 메타데이터 ==== 메타데이터[* 이 책에서는 Meta Data에 대한 중요성을 특히 강조한다. 원래 중요하기도 하지만..]는 다음의 유형을 가진다. * Operational Metadata * Extraction And Transformation Metadata * End-User Metadata 메타데이터는 특별히 중요한 이유는 다음과 같다. * DW의 모든 부분을 연결하는 아교로 동작 * 개발자에게 내용과 구조들에 관한 정보를 제공 * 최종사용자에게 문을 열어주고 내용들을 그들 자신의 용어들로 인식하게 해줌(Road Map)