1 장의 목표

2 데이터 설계

3 구조의 계획

3.1 구성요소들의 합성

3.2 특별한 고려사항

3.3 도구와 제품

4 데이터 저장장치 명세

4.1 DBMS 선정

4.2 저장장치의 크기산정

5 정보 전달 전략

• 왜 업무 요구사항(Business Requirements)이 추진력인지를 이해한다.
  
• 어떻게 요구사항이 모든 개발 단계를 추진하는지 논의한다.
  
• 특히 어떻게 요구사항이 데이터 설계에 영향을 주는지를 배운다.
  
• 구조에서 요구사항의 영향력을 검토한다.
  
• ETL과 메타데이터에 대한 특별한 고려사항들을 주의한다.
  
• 어떻게 요구사항이 정보 전달을 실행하는지를 조사한다.
  
  

DW 시스템은 사용자들의 BP(Business Processes)들을 수행하기 위해 필요한 것을 정확하게 반영해야 한다. 사용자들에게 적절한 GUI를 제공해야 한다. 요구사항 정의는 시스템 설계와 개발의 전체 과정을 안내한다. DW를 위한 요구사항 정의는 다른 시스템보다 매우 정밀한 요구사항 정의가 필요하다. 왜냐하면 사용자들이 DW 저장소에 접근할 것이고, 그들 자신의 정형화되지 않은 출력을 직접 생성해 낼 것이 때문이다. 그러므로 DW가 분석을 위한 최적의 포맷으로 적절한 정보의 질을 위한 요소들을 포함하고 있어야 한다. 사용자들이 원하는 방법으로 그들이 필요로 하는 모든 전략 정보를 찾을 수 있어야 한다. 그들은 쉽게 데이터 웨어하우스에 접근할 수 있어야 하고, 그들의 질의를 수행하고, 힘 들이지 않고 결과를 얻고, 문제없이 다양한 유형들의 데이터 분석을 수행할 수 있어야 한다.

DW의 추진력은 오직 사용자들의 업무 요구사항뿐이다. 생명주기동안 모든 작업은 요구사항에 의해 결정된다. 그러므로 요구사항 정의가 개발의 각각의 단계를 지원하기 위해 충분한 상세사항을 포함해야 한다는 것을 특별히 보장할 필요가 있다. 요구사항 정의는 DW 개발 단계에서 가장 중요한 단계임을 명심해야 한다.

데이터 설계 단계에서 다음의 두 영역에 대한 데이터 모델이 필요하다.

• 스테이징 영역(ETL 영역)
  
• 데이터 웨어하우스 저장소
  
  

Enterprise Data Model은 소스 시스템들의 전사적인 관점에서의 데이터 모델이다. 소스 시스템의 전사적 관점이므로 요구사항 정의 문서가 소스 시스템 데이터의 구성요소들과의 관계들에 관현 충분한 정보를 포함하는 것을 보장해야 한다.

데이터 설계는 차원, 측정치, 상세수준을 결정하는 작업이다. 정보패키지의 각각의 컬럼이 업무 차원이 딘다. 주요 측정치의 사용처는 다음과 같다.

• 성과목표
  
• 사업분석
  
• 감시
  
  

예를 들어, 자동차 매출에 대해서 실제 판매가격, 옵션, 등이 측정치가 된다. 상세수준은 얼마나 집계된 상태인가를 나타낸다. 결국은 요구사항에 따라서 데이터의 상세수준(Granurality)를 결정되지만, 미래를 생각하여 가장 낮은 상세수준을 유지하는 것이 좋다.

기본적으로 모든 데이터 웨어하우스는 거의 같은 구성요소들로 이루어진다. 다음은 이미 언급된 중요한 구조의 구성요소이며, 설계 전에 조사해야 할 항목이다.

• 소스 데이터
  
  • 생산 데이터
    
  • 내부 데이터
    
  • 아카이브 데이터
    
  • 외부 데이터
    
• 데이터 스테이징
  
  • 데이터 추출
    
  • 데이터 변환
    
  • 데이터 적재
    
• 데이터 저장장치
  
• 정보 전달
  
• 메타데이터
  
• 관리와 제어
  
  

데이터 웨어하우스 아키텍처를 결정할 때의 모든 기준은 업무 요구사항이다. 구조를 계획하는데 필요로 하는 모든 정보는 요구사항으로부터 나와야 한다. 적합한 요구사항은 데이터 웨어하우스의 크기와 내용을 움직이게 할 것이다.

구조를 계획하는 것은 각 구성요소의 크기와 내용을 결정하는 것과 관련된다는 것을 기억해야 한다. 다음은 구조의 계획을 추진하기 위하여 요구사항 정의에 포함되어야 하는 정보의 형태다.

• 소스 데이터
  
  • 운영계의 소스 시스템
    
  • 컴퓨팅 플랫폼, 운영체제, 데이터베이스, 파일
    
  • 파일, 서류, 스프레드시트와 같은 부서별 데이터
    
  • 외부 데이터 소스
    
• 데이터 스테이징
  
  • 데이터 소스와 스테이징 영역의 자료 구조 사이의 데이터 매핑
    
  • 데이터 변환
    
  • 데이터 정제
    
  • 데이터 통합
    
• 데이터 저장장치
  
  • 추출 및 통합된 데이터의 크기
    
  • DBMS 특징들
    
  • 성장 잠재력
    
  • 중앙 집중 또는 분산
    
• 정보 전달
  
  • 사용자들의 유형과 수
    
  • 질의와 보고서 유형
    
  • 분석의 등급
    
  • 전사-부분 DSS 어플리케이션
    
• 메타데이터
  
  • 운영 메타데이터
    
  • ETL 메타데이터
    
  • 최종 사용자 메타데이터
    
  • 메타데이터 저장장치
    
• 관리와 제어
  
  • 데이터 적재
    
  • 외부 소스들
    
  • 경보 시스템들
    
  • 최종 사용자 정보전달
    

다음의 사항들은 반드시 요구사항 정의에 포함되어야 한다. 이 사항들이 빠진다면 심각한 결과를 초래할 것이다.

• 데이터 추출/변환/적재
  
• 데이터 품질
  
• 메타데이터
  
  

데이터 추출/변환/적재
시간소비적, 사람집중인 활동이다. 데이터 추출 작업에서는

• 모든 내부 데이터의 명확한 확인 필요
  
• 소스의 컴퓨팅 플랫폼, 소스 파일에 대한 자세한 조사 필요
  
• 외부데이터의 경우 호환성 결정
  
• 데이터 추출 방법에 대한 표기
  
  

데이터 변환 작업에서는

• 매핑 규칙을 확인한다.
  
• 변환규칙에 대한 확인을 한다.
  
  

데이터 적재 작업에서는
데이터 품질
나쁜 데이터는 나쁜 결정들로 이끈다. 데이터 품질이 불량하다고 의심된다면 신뢰는 무너지고 사용자로부터 외면을 받는다. 작은 데이터의 품질문제도 전략적 의사결정에 심각한 영향으로 귀착될 수 있다. 요구사항 정의의 초기 단계에서 바로잡고, 소스 시스템들에서 데이터 오염의 잠재적인 원인들을 확인해야 한다.

• 데이터 오염의 원인
  
  • 시스템 전환과 이전
    
  • 이종 시스템의 통합
    
  • 소스 시스템들의 부적당한 데이터베이스 설계
    
  • 데이터 노화
    
  • 고객들로부터 불완전한 정보
    
  • 입력 실수
    
  • 시스템들의 국제화/지역화
    
  • 데이터 관리 정책/절차들의 부족
    
• 데이터 품질 문제들의 유형
  
  • 소스 시스템 필드들의 더미(Dummy)값들
    
  • 소스 시스템 필드들의 데이터 부재
    
  • 다목적용 필드들
    
  • 숨겨진(Cryptic) 데이터
    
  • 모순되는 데이터
    
  • 이름과 주소 줄의 부적절한 사용
    
  • 업무 규칙들의 위반
    
  • 재사용된 기본키들
    
  • 유일하지 않은 식별자들
    
    

메타데이터
메타데이터는 단지 데이터 사전이 아니다. 메타데이터는 데이터 사전이나 데이터 카탈로그보다 훨씬 많은 데이터를 가지고 있다. 메타데이터는 모든 구성요소들을 함께 묶는 아교와 같은 역할을 한다. 데이터가 다른 구성요소로 이동할 경우에도 메타데이터에 의해 관리된다. 메타데이터는 다음과 같이 3가지로 분류된다. 요구사항은 운영에서부터 최종사용자의 영역까지 방대한 영향력을 가진다.

• 운영 메타데이터
  
• ETL 메타데이터
  
• 최종사용자 메타데이터
  

요구사항은 직접 도구들의 선택에 영향을 미치지 않는다. 데이터 웨어하우스 구조를 설계하고 그런 다음 그 구조를 지원하는 적합한 도구를 찾아야 한다. 때로는 요구사항이 구축 가능할까 의심되기도 한다. 하지만 구축을 위한 도구들은 충분히 있다. 구조 설계가 완성되면 써드파티 업체의 도구들과 제품들을 얻을 수 있다.

• ETL도구
  
  • 미들웨어
    
  • ETL
    
  • 데이터 품질
    
• 웨어하우스 저장장치
  
  • 데이터 마트
    
  • 메타데이터
    
• 정보 접급/전달
  
  • 보고서 작성기
    
  • 질의 처리기
    
  • OLAP
    
  • 경보시스템
    
  • DSS응용
    
  • 데이터 마이닝
    

Top-Down 방식

• Data Staging Area
  
• Enterprise Data Warehouse
  
• Data Mart
  
• OLAP를 위한 Multi-Dimensional Database
  
  

Bottom-Up 방식

• Data Staging Area
  
• Data Mart
  
• OLAP를 위한 Multi-Dimensional Database
  
  

DBMS를 기준으로 후방에는 ETL관련 툴들 배치될 것이고, 전방에는 사용자들의 정보전달과 관련된 툴들이 배치될 것이다. 이 모든 구조가 같은 회사의 제품이라면 개방성은 문제가 없다. 하지만 요구사항에 맞추다보면 전방과 후방과 DBMS의 제품이 모두 다를 수 있다. 그러므로 DBMS의 선택을 위한 중요한 기준은 개방성과 호환성이다.

요구사항 정의단계에서 선정될 DBMS의 유형을 논의하지 않았다. 하지만 사용자의 요구사항의 상당부분이 적합한 DBMS의 선정에 영향을 미친다. DBMS제품의 선정은 DBMS제품에 포함된 여러가지 도구들(Toolkit)에 의해 제약된다. 다음의 업무 요구사항들은 DBMS 선택에 영향을 미친다.

• 사용자의 경험수준: Casual User?, Power User?, SQL가능?
  
• 질의유형: 복잡하고 큰 결과집합을 만들어 내려면 옵티마이저가 필요하다.
  
• 개방성: 전방/후방의 구조와의 통합
  
• 데이터 적재
  
• 메타데이터 관리
  
• 데이터 저장소 위치(중앙집중? 분산?)
  
• 데이터 웨어하우스 성장
  
  

저장장치의 크기 산정의 근거는 업무 요구사항에서 답을 찾아야 한다. 요구사항 정의서에는 저장장치 크기를 산정하는데 충분한 정보를 가져야 한다. 요구사항 정의 단계에서 다음에 대한 저장장치 크기들을 예상할 필요가 있다.

• 데이터 스테이징 영역
  
  • 변환과 맵핑에 사용되는 저장장치 크기
    
  • 초기에 첫 번째 데이터 마트에 대한 업무 차원들과 측정값들에 근허아여 크기 산정
    
• 전사 데이터 웨어하우스
  
• 데이터 마트
  
• 다차원 데이터베이스
  
  

정보 전달 메카니즘은 업무 요구사항에 직접적으로 영향을 받는다. 그들이 원하는 정보는 DW로부터 검색하기를 원하는 어떤 정보를 말한다. 요구사항 정의 문서에는 이러한 정보가 기록되어야 한다. 정보 전달 구성요소는 사용자들의 비중에 따라서 강화되어야 한다. 만약 파워 유저의 경우 분석을 위한 소프트웨어(예: OLAP 도구들)로 강화되어야 하며, 정형 보고서나 사전에 구성된 질의들을 수행하기를 원한다면 질의와 보고서 구성요소가 강화되어야 한다. 직접적으로 영향받는 정보 전달 구성요소는 다음과 같다.

• 질의와 보고서
  
  • 정형 질의/보고서
    
  • 비정형 질의/보고서
    
• 분석의 유형
  
  • 드릴다운/롤업, 슬라이싱/다이싱 등의 방법
    
  • 분석의 재사용과 분석유형의 복잡도에 대한 정보를 사용자로부터 얻는다
    
• 정보 분배
  
  • LAN환경? WAN환경?
    
• 의사결정 지원 응용
  
• 성장과 확장