데이터웨어하우스 데이터 모델링 (Data Warehouse Data Modeling)

1. 데이터웨어하우스데이터 모델링(Data Warehouse Data Modeling)

2. 목 차(1) • 제 1 장 데이터웨어하우스 데이터모델링 개요 • DW 데이터의 특성 • DW 모델링 개요 • 제 2 장 데이터 정의 • 원 데이터와 목적 데이터 • 갭(Gap) 분석 및 해결 • 데이터 변형

3. 목 차(2) • 제 3 장 데이터웨어하우징 모델링 • Dimensional Business Model • Star Model • Star Model의 구축 • Fact Table • Fact Table 의 속성 • Dimension Tables • Snowflake Model • Multiple Fact Tables • Multi Star Schema • 외부참조 테이블 (Outboard Table) • DW내에서의 시간의 활용

4. 목 차(3) • 제 4 장 고급 데이터웨어하우스 모델링 • Dimension 속성의 변경 • History의 관리 • One Dimension Compare To Several Dimensions • 계층구조 데이터의 모델링 • 차원내의 복수 계층 • 제 5 장 데이터의 집합화 • 요약 Table과 집합화 • 집합화 (Aggregation) • Snowflake model과 요약 fact table • 하나의 대규모 단일 fact table • DW내에서 요약 Table의 관리 • 요약 Table 사용시의 주의할 사항 • Granularity

5. 제1장 데이터웨어하우스 데이터모델링 개요 • DW 데이터의 특성 • DW는 데이터의 통합체 • DW 데이터는 주제중심 • DW 데이터는 … • DW 모델링 개요 • 정보요구를 모델로 • DW 모델 • 주제영역 논리적 데이터모델링

6. DW는 데이터의 통합체(Consolidation) Internal Data Operational Data Store Data Warehouse External Data Manual Data Data Marts

7. DW 데이터는 주제중심(Subject Oriented) 적용업무에 의해서가 아닌 업무적 주제에 의한 분류 및 저장 여신 수신 고객실적 정보 공통 외환 수출입 데이터웨어하우스의 업무적 주제에 의한 분류 적용업무에 의한 분류

8. DW 데이터는 ... • 데이터통합 • 데이터통합 • 데이터의 일관성 (Data Consistency) • 데이터의 중복 (Data Redundancy) • Time Variant • Key Time Element • 비휘발성

9. 정보요구를 모델로 • 정보요구 수집 • JAD (Joint Application Development) • Interviews • Current Reports • IT Report Backlog • 대상업무와 관련된 업계의 출판물 • 경영진, 관리자와의 Meetings • 업무 프로세스가 아닌 데이터를 보는 관점(View)에 주력

10. DW 모델 Operational Data Store Subject Area Logical Data Model Star Schema Physical Data Model Snowflake Schema Physical Data Model

11. 주제영역 논리적 데이터모델링 • Subject Area 정의 • 엔티티(Entity) 정의 • 속성(Attribute) 정의 • 관계(Relationship) 정의 • 업무규칙(Business Rule) 검증 • Critical Business Measure 정의 • 추출데이터 추가 • 시간요소 추가

12. 제2장 데이터 정의 • 원 데이터와 목적 데이터 • 갭(Gap) 분석 및 해결 • 데이터 변형

13. 원 데이터와 목적 데이터 • 원 데이터 (Source Data) • 다른 database, file, segment들에 있는 data나 외부에서 제공되는 data • 운영 시스템에서 추출된다 • 목적 데이터 (Target Data) • Data Warehouse database의 data가 되는 data • 원 시스템(Source System) 분석 • ER-Diagram • Database Catalogs • Metadata • 역공학(Reverse Engineering) 을 활용하라 • 80:20 Rule을 염두에 두라

14. 갭(Gap) 분석 및 해결 • 갭(Gap) 분석 • Data content • Data format • Data relationship • Granularity • 갭(Gap) 의 해결 • Ignore • Adjust • Compromise • Postpone

15. 제품 번호 데이터 변형 • 원시 시스템에서 추출된 데이터는 DW로 구성되기 전에 통합되고 변형된다. = 17A554322 17 A 5543 22 지역 Code 영업구역 제품 Code 제품 Size Code Key들로 구축된 항목

16. 제3장 데이터웨어하우징 모델링 • Dimensional Business Model • Star Model • Star Model의 구축 • Fact Table • Fact Table 의 속성 • Dimension Tables • Snowflake Model • Multiple Fact Tables • Multi Star Schema • 외부참조 테이블 (Outboard Table) • DW내에서의 시간의 활용

17. Dimensional Business Model Product Geography Facts Sales Inventory Costs Dist. Time Channel Dimension High level Dimensional Business Model

18. Star Model • 분석 처리를 지원 • Fact table • Dimension table • 장점 • 간단한 모델 • 사용자 중심 • 테이블 조인을 감소하여 성능 향상 • 단점 • 융통성이 적다 • 중복된 데이터를 갖는다 • 다수의 요약 테이블을 필요로 한다 • Fact 테이블간의 조인이 어렵다

19. Star Model의 구축 • 주제 영역 • 사실 (Facts) • 세분화 (Granularity) • 차원 (Dimensions) • 차원의 속성들 (Dimensional attributes) • 속성의 특징 • 정적인가 • 동적인가

20. Fact Table • Major table이라고도 한다. • Business에 관한 수량적이거나 사실적인 data를 갖는다. • 숫자로 나타내는 측정치가 정보로 질의된다. • 많은 수의 column들과 수백만의 행을 갖는다. Product Time Key Product Key Customer Key Channel Key Sales Facts (Units, Price) Customer Channel Time

21. Fact Table Attributes • Fact는 업무의 양적 특성을 보이는 속성이다 • Fact table의 속성들은 외부 dimension key들이나 판매나 단위와 같은 수치적 특성들을 구분한다 • Fact Data • Additive • Non-additive • Semi-additive Sales Fact Time_Key Product_Key Store_Key Promotion_Key Quantity_sold* Revenue* Cost* Customer_count Store Time Additive Semi-Additive Product Promotion

22. Dimension Table • Minor table이라고도 한다. • Business의 차원을 반영하는 서술적인 data를 갖는다. • Fact table내의 각각의 row에 대하여 서술적인 정보를 갖는다 • 일반적으로 fact table에 비하여 그 양이 적다 • 시간 차원 테이블을 갖는다 • Large Dimension Tables • 모든 dimension table이 항상 작은 것은 아니다 • 고객에 관한 정보를 갖는 dimension table이라면 매우 커질 수 있다 • 이러한 복잡한 분석을 지원하기 위하여 보다 정교한 인덱스와 조인 기술을 필요로 한다

23. Snowflake Model • Star model의 변형 • fact table 구조는 그대로 유지하면서 모든 차원 정보를 3차 정규형으로 저장 • 잇점 • 보다 적은 저장 공간을 필요로 한다 • 대부분의 많은 개발툴이 지원한다 • 데이터 중복을 최소로 한다 • 단점 • 보다 복잡해지므로 사용자의 이해도를 좀 더 필요로 한다 Time Period Category Products Sales (units, price) Time Customer Channel Segment

24. Product_ID Market_ID Period_ID Prod_Desc Brand Size Market_Desc District Region Period_Desc Quarter Year Market_ID Market_ID Units Dollars Discount% Units Dollars Discount% Period_ID Period_ID Product_ID Product_ID Multiple Fact Table (1) • Snowstorm model이나 Snowflake model이라고도 한다 • Fact table들이 dimension table을 통하여 연결된다 • 서로 다른 시간 Dimension을 적용할 수 있다

25. Product_ID Market_ID Period_ID Prod_Desc Brand Size Market_Desc District Region Period_Desc Quarter Year Market_ID Units Dollars Discount% Group_ID Group_Desc Period_ID Product_ID Product_ID Group_ID Multiple Fact Table (2) • DW Model의 모든 table들이 fact나 dimension으로 나뉘어지는 것은 아니다 • business의 임의의 차원간의 다-대-다 관계를 해소하기 위하여 추가된다 • Factless fact table • Associative Dimension

26. Store_ID SKU_ID Store_Name Region Manager Class_ID Dept_ID Item Dept_ID Class_ID Class_Desc Dept_Desc Store_ID SKU_ID Units Price Amount Date 2개의 2차 dimension table을 갖는 Multi star schema Receipt_Nbr Receipt_Line_Item Multi Star Schema • foreign key의 연결만으로 fact table의 각 행을 유일하게 구분할 수 없을 경우에 유도된다

27. Product_ID Market_ID Period_ID Prod_Desc Brand Size Market_Desc District_ID Region_ID Period_Desc Quarter Year Market_ID Units Dollars Discount% District_ID Region_ID District_Desc Region_Desc Period_ID Product_ID 외부참조 테이블 (Outboard Table) • 임의의 Dimension table은 다른 Dimension table에 의하여 참조될 수 있다 • 참조되는 dimension table을 outboard, outrigger 혹은 2차 dimension table이라고도 한다

28. DW내에서의 시간의 활용 • DW에 있어 시간의 표현은 필수요소 • DW내에서 시간의 단위에 대한 다양한 정의를 만족하는 시간의 계층을 정의해야 한다 • 시간은 어디에 저장되어야 하는가? • 일반적으로 DW내에서의 시간 dimension table은 시간적인 요소로 fact table에 저장된다 • Multiple Time Hierachies • Calendar 접근 • 시간에 대한 측정치는 간단하게 시작될 수 있으나 곧 매우 복잡한 개념으로 발전하게 된다

29. 제4장 고급 데이터웨어하우스 모델링 • Dimension 속성의 변경 • History의 관리 • One Dimension Compare To Several Dimensions • 계층구조 데이터의 모델링 • 차원내의 복수 계층

30. Dimension 속성의 변경 • DW는 history를 저장한다 • 사용자의 요구사항이 저장되어져야 할것을 결정 • 변화는 추적가능해야 한다 • 사용할 수 있는 몇가지 방법들 • history를 전부 다시쓴다 • record를 추가함으로 history의 유지 • history table을 이용한 history 유지 • 부분적 history의 유지보수 Married Single Separated Divorced

31. History의 관리 • History 다시 쓰기 • 구현이 쉽다 • 이전의 history를 잃는다 • Record를 추가함으로 history의 유지 • 차원이 증가하여 history 보존 • 시간적 제약은 필요하지 않다 • 일반화할 수 있는 Key를 필요로 한다 • History table을 이용한 history 유지 • History table이 추가되어 Dimension이 확장된다 • History table내에서의 key를 무엇으로 할것인가 • 부분적 history의 유지보수 • Data의 불안정에 대비하여야 한다 Single Married Separated Divorced

32. One Dimension Compare To Several Dimensions • 단일 차원 • 보다 적은 조합에 의한 보다 작은 Fact table을 만든다 • dimension data의 분석과 유지를 어렵게 한다 • 복수 차원 • 다수의 조합에 의하여 fact table의 크기를 증가 시킨다 • 분석의 융통성을 증대 • data 정의의 변화에 있어 보다 쉬운 방법을 제공 • 전반적인 유지보수를 쉽게 한다

33. 계층구조 데이터의 모델링 • 계층 구조 데이터는 다음과 같이 표현된다 • 단일 계층 (차원; dimension) • 복수 계층 (dimensions) • 계층적 data는 dimension table에 저장된다 • Dimension은 하나 이상의 계층을 가질 수 있다 • 여러 개의 모델이 사용 가능하다 • Flat • Recursive • Combined • 3NF

34. Sales District Sales Region Sales Zone 모든 고객 Country State 고객 차원내의 복수 계층 • 테이블 항목의 사용 • 항목 계층의 생성 • Drilling down • 좀 더 자세히 • Rolling Up • 요약하여 Dimension table내의 복수 계층

35. 제5장 데이터의 집합화와 요약 • 요약 Table과 집합화 • 집합화 (Aggregation) • Snowflake model과 요약 fact table • 하나의 대규모 단일 fact table • DW내에서 요약 Table의 관리 • 요약 Table 사용시의 주의할 사항 • Granularity

36. 요약 Table과 집합화(Aggregation) • 요약된 데이터란? • 미리 정의된 fact data를 누적 • 직접적이고 쉽게 접근할 수 있도록 data를 집합화 • 왜 요약된 데이터를 갖는가? • 질의 응답시간을 개선하기 위하여 • 자원의 활용도를 최적화 하기 위하여 • 분석 처리를 강화하기 위하여 • 집합화된 data(Aggregated data) • DW내의 SUM, MAX, MIN, COUNT등으로 미리 계산되고 요약된 data • 일반적으로 요약된 fact table에 저장

37. Region 집합화 (Aggregation) Geography Market Store Item Class Dept Product Geography와 product dimension에 대한 미리 저장된 집합화 Table

38. Date Key Region ID Product Key Total Units TotalSales Date Key Store Key State ID Product Key Product Key Total Units Total Units TotalSales TotalSales Snowflake model과 요약 fact tables • Snowflake 구성 • Dimension table을 공유 가능하게 한다 • 보다 진보된 의사결정 tool들의 사용을 쉽게한다 • 유연성 • 정규화를 요구한다 • 성능이 저하될 수 있다 • 대규모 dimension Region ID ... Region Summary Table Total by region, by product, by day Denormalized Store Dimension Table State ID ... State Summary Table Total by state, by product, by day Store Key ... Basic Fact Table

39. 하나의 대규모 단일 fact table • 세부 fact data와 요약된 data를 같은 table에 • 집합화 정보가 fact table에 포함되어 있다 • 차원에서 level을 관리하기 위하여 일반화된 key가 필요하다 • 요약된 정보를 얻기위한 질의 절차가 간단하다 • 종종 OLAP을 위하여 사용된다 • 유지보수, 운영관리가 어렵다 Row Headers Summary Rowns Basic Grain Rowns Fact Table

40. DW내에서 요약 Table의 관리 Yearly summary data Quarterly summary data Monthly summary data Last 12 months Daily detail 1994/1995 1994 1997 1998

41. 요약 Table 사용시의 주의할 사항 • 생성시의 제한 사항 • 모든 가능한 사항에 대한 고려는 엄청난 양의 자원을 필요로 한다 • 사용시의 주의할 사항 • 요구사항을 명확히 구분한다 • 향상될 수 있는 성능을 측정해 낸다 • 요약 table의 가치를 결정하여 더하거나 삭제한다 • 지속적인 재반영(refresh)은 시간의 소모가 클 수 있다 • 원활한 운영에 부적합한 Tool을 사용하지는 않는가 • 제한된 확장성

42. Granularity • Grin • DW내의 세밀화의 수준 • Granularity의 수준은 database의 크기와 database가 지원할 수 있는 분석의 형태에 직접 영향을 준다 • Low level of granularity • high level of detail • 한달 동안 고객이 사용한 각각의 통화에 대한 세부 정보 • High level of granularity • low level of detail • 한달에 임의의 고객이 통화한 횟수