DW

• DataWareHouse(DW)

-데이터 웨어하우스는 기업 내/외부에 산재 된 대량의 자료를 시간적 관점을 초월하는 하나의 통합체로 구성하고, 

  이의 다각적 분석, 새로운 업무지식의 창출 및 의사결정 지원을 위한 활용환경으로 구성하는 것

-운영계의 Data는 업무 Process가 끝나고, 필요한 Data를 정리하여 DW에 적재

-운영계 Data는 실 업무(거래)에 필요한 Data이므로 빠른 속도가 중요

-정보계의 Data는 분류기준(기간, 거래처)에 따라 정리된 통합 Data로 관계 파악이 중요

-OLAP : Data Mart 

-OLTP : 운영계 Process

• DW Modeling

DW에서 가장 중요한 Point 4가지

1. Star Schema 
2. Snow Flake Schema
3. Summary
4. 사용자의 요구사항과 현업의 Process를 잘 이해하고 만든 DW 구조

-Demension >> 카테고리 / 관리항목 

ex) 날짜, 거래처, 품목

-Fact >> 실제 Data  

ex) 날짜, 거래처, 품목 / 별 실제 수치 

• Star Schema

Demension - 월 ID / 영업소 ID

Fact - 월 Desc...등 / 영업소 Desc...등

• Snow Flake Schema

-Star Schema를 더욱 정규화한 형태

-Table의 컬럼이 많은 경우 정규화가 효율적일 수 있으나,

 많은 Join이 요구되므로 성능 저하가 우려된다

• 집계 테이블(Summary)

-빠른 Select를 위해서 자주 조회하는 자료 모음을 Table의 형태로 만들어 두는 것

(대용량의 Data를 처리하는 OLAP에서 성능의 차이는 핵심적이다 - 10분 → 4초)

-경로 설계가 매우 중요

-집계 테이블은 기본적으로 중복을 발생하기 때문에 무분별하게 만들면 용량이 과도하게 늘어나고, 업데이트에 문제 발생

-최대한의 쿼리를 지원하는 유연한 집계테이블을 구축

-데이터가 밀집되어 있는 집계 테이블을 구축

-빈번한 쿼리를 지원하는 집계 테이블을 구축

-HW 성능이 발달할 수록 집계 테이블의 필요성은 감소(상이한 설계간의 속도 차이 감소)

• 집계 테이블(Summary)의 핵심은 고객의 요구사항과 업무 Process를 정확하게 파악하여, 성능을 최적화하는 것!

-실제 활용되는 Data인지를 파악해야 함

 ex) 모든 영업사원이 영업실적을 내지는 않는다.(사원/대리급이 영업 실무자)

        이런 상황에서 영업실적 / 총 영업사원 수 = 1인당 평균 영업실적 Data는 의미가 없음

 ex) 정유사 상품 출하는 일별이 아니라, 월별로 발생함 

       이런 상황에서는 Dimension을 일이 아니라 월로 설정해야 1/365이 아니라 1/12로 검색할 수 있음

-Summary를 이론적으로만 하면 실제 업무와 괴리가 생길 수 있음

※ 적어도 검색횟수를 1/20으로는 줄게해야 실무에서 Summary를 활용

-Data가 자주 변경되는 경우 

>> 현업에 요구사항을 문의하여 정확한 방향을 설정

>> 보통은 다되게 해달라고 요구 > 실제 보고서/정산을 기준으로 근거 제시

※Fact No Data

-건수가 누락된 경우, 운영계에서 Data를 가져와서 가공한 후 추가

ex)신규 가입자수, 탈퇴자 수 >> 실 Data에는 Colume으로 존재하지 않는 Data이므로 가공, 생성 

• OLAP 설계/구축(피벗 테이블과 유사)

-Physical Name(DNAME) -> Logic Name(부서명)으로 변경해서, 사용자에게 제공

-OLAP 개발자는 SQL을 이해해야, Summary Table을 덜 만들고 유연성이 생김

 >> 불필요한 Table을 줄여야 > 용량 절감/ Application 개발축소 / 유지보수 시간단축 / 효율성 재고

-Compact하게!

>> 가능하면 Summary Table을 만들지 않고, View로 처리

※ETL TOOL : 인포메티카 / DataStage / BTL

※OLAP : Cognus(현재 하향세) / 태블로