제 10 장

1. 제 10 장 차원 모델링의 원리 Data Warehousing

2. 장의 목표 • 요구사항의 규정이 데이터 설계를 결정하는 방법 • 차원 모델링과 개체-관계 모델링 비교 • STAR schema • 사실 테이블과 차원 테이블의 내부 비교 • 데이터 웨어하우스를 위한 STAR 스키마의 장점 Data Warehousing

3. 10.1 요구사항에서부터 데이터 설계까지 • 요구사항의 규정은 데이터 웨어하우스를 위한 데이터 설계에 이용된다. • 데이터 설계는 자료 구조들을 조립하는 것 • 한 그룹의 데이터 요소들은 하나의 자료 구조를 형성한다. • 논리적인 데이터 설계는 요구되어지는 다양한 데이터 요소들의 결정과 자료의 구조들을 이루는 데이터 요소들의 결합을 포함한다. • 논리적인 데이터 설계는 또한 데이터 구조들 사이의 관계의 확립도 포함한다. • 그림 10-1 Data Warehousing

4. 정보 매트릭스: 측정단위, 업무차원, 업무차원간의 계층 그림 10-1 FROM REQUIREMENTS TO DATA DESIGN Data Warehousing

5. 설계 결정 • 주제 선택 • 구체화 정도 선택 • 차원을 확인하고 일치시키기(conforming) • 사실(facts) 선택 • 데이터베이스의 존속 기간 선택 Data Warehousing

6. 차원 모델링 기초 • Dimensional modeling gets its name from the business dimensions • A logical design technique to structure the business dimensions and the metrics that are analyzed along these dimensions • The metrics or facts from the information package diagram(IPD) will form the fact table. • The data item within each column in IPD would then be the attributes for each dimension table. • What are the relationships and how should we mark the relationships in the model. Data Warehousing

7. Typical Query • How much sales proceeds did the Jeep Chrokee, Year 2000 Model with standard options, generate in January 2000 at Big Sam Auto dealership for buyers who own their homes and who took 3-year lease, financed by Daimler-Chrysler Financing? • The attributes in the dimensional tables act as constraints and filters in our queries Data Warehousing

8. Data Warehousing

9. Data Warehousing

10. How to arrange the fact and dimensional tables • Criteria for combining the tables into a dimensional model • Provide the best data access • Be query-centric • Be optimized for queries and analyses • Dimensional tables interact with the fact table • Every dimension can be interact equally with the fact table • Allow drilling down or rolling up along dimension hierarchies Data Warehousing

11. Data Warehousing

12. E-R Modeling Versus Dimensional Modeling Data Warehousing

13. E-R Modeling Versus Dimensional Modeling Data Warehousing

14. Use of CASE Tools • You can use a case tool to define the tables, the attributes, and the relationships • Assign the primary keys and indicate the foreign keys • Form the entity-relationship diagrams • Forward-engineer • Most of the existing vendors have expanded their modeling case tools to include dimensional modeling Data Warehousing

15. Forward Engineer • The forward-engineering tool builds a physical (actual) databasefrom your Visual Case project.  If some of the database objects already exist in your physical database, the engineering tool will check for difference between the physical database and your design and will automatically make only the required changes.  Unless it's necessary, the engineering tool changes the physical database without losing any data.  As part of the engineering process you will be informed as to what changes are about to be made to your physical database.  However, you are responsible for taking adequate backups of your data before you apply your design changes. Data Warehousing

16. Reverse Engineer • The reverse-engineering tool builds a Visual Case projectfrom a physical database.  The tool will easily allow you to create documentation of existing databases.  If you need to convert a legacy database, use the reverse-engineering tool: it will create the Visual Case project and convert the database to any of our supported database types.  Then you can make any required design changes and forward-engineer to your new platform. • http://www.visualcase.com/kbase/database_engineer.htm Data Warehousing

17. 10.2 STAR 스키마 • 간단한 STAR 스키마의 검토 • Figure 10-7 • The orders fact table • Four dimension tables Data Warehousing

18. SKU(Stock Keeping Unit) 최소유지상품단위 Data Warehousing

19. 간단한 질의 • A simple query  Figure 10-8 • The marketing department wants the quantity sold and order dollars for product bigpart-1, relating to customers in the state of Maine, obtained by salesperson Jane Doe, during the month of June. Data Warehousing

20. Data Warehousing

21. 마케팅 부서의 질의: 그림 10-9 • 1999연도에 북동 지역에 있는 고객들에게 제품 브랜드 big parts로 팔린 전체 양을 보여주시오. • 분석의 다음 단계로, 마케팅 부서는 지금 같은 제품 브랜드인 big parts에 대해서 북동 지역에 대하여 1999년의 분기 수준으로 드릴 다운하기를 원한다. • 다음으로, 분석은 그 브랜드에서 각각의 제품들의 수준으로 내려간다. • 마지막으로, 분석은 북동 지역에서 각각의 주에 의한 상세 수준으로 간다. Data Warehousing

22. Drill-down analysis Data Warehousing

23. 차원 테이블 내부 • Figure 10-10 • Observation Dimension table key, Table is wide, Textual attributes, Attributes not directly related, Not normalized, Drilling down, rolling up, Multiple hierarchies, Fewer number of records Data Warehousing

24. Data Warehousing

25. 사실 테이블 내부 • Figure 10-11 lists the characteristics of a fact table • Concatenated key • Data grain • Fully Additive Measures • Semiadditive Measures • Table Deep, Not Wide • Sparse Data • Degenerate Dimensions Data Warehousing

26. Data Warehousing

27. The Factless Fact Table • A fact table to track the attendance of students • In the fact table row, the attendance will be indicated with the number one • Figure 10-12 Data Warehousing

28. 해당되는 사실 테이블 행의 존재는 출석을 표시한다. Data Warehousing

29. 데이터 구체화정도Data Granularity • Granularity represents the level of detail on the fact table • 기본 수준 사실 테이블 (base level fact tables) • What are the natural lowest levels of the corresponding dimensions? • 적절한 변경 “Graceful” change • Add a new attribute of district in the sales representative dimension • Add a new dimension of promotion Data Warehousing

30. 가장 낮은 구체화 정도 • 가장 낮은 구체화정도에서 사실 테이블을 위한 저장과 유지 면에서 대가를 지불해야 한다. • 가장 낮은 구체화정도는 필수적으로 큰 수의 사실 테이블 행들을 의미한다. • 알갱이 사실 테이블(granular fact tables)은 두개의 더 많은 장점들이 있다. • 알갱이 사실 테이블들은 운용 시스템들로부터 빈번히 추출될지도 모르는 현재의 운용 데이터에 대한 자연스런 도착지로 다룬다. • 최신의 데이터 마이닝 응용들은 가장 낮은 구체화정도에서 상세함을 요구한다. Data Warehousing

31. 10.3 스타 스키마 키 • Star Schema Keys • 기본키 primary key • 대리키 surrogate key • 외래키 foreign key Data Warehousing

32. 기본키Primary Keys • 운용 시스템에서 사용하는 product code를 primary key로 사용하면, 데이터 웨어하우스에서 문제를 일으킬 수 있다 • 어떤 년도에 code를 change • 같은 product의 새 제품은 다른 primary key를 가질 수도 있다. • The Problem • The result of our decision to use the operational system key ad the key for the dimension table Data Warehousing

33. Data Warehousing

34. 대리키Surrogate Keys • Two general principles when choosing primary keys for dimension tables • Avoid built-in meanings in the primary key of the dimension tables • Do not use production system keys as primary keys for dimension tables • The answer is to use surrogate keys • Simply system-generated sequence numbers Data Warehousing

35. 외래키Foreign Keys • The primary key of each dimension table must be a foreign key in the fact table. • Reexamine the primary keys for the fact tables • A single compound key whose length is the total length of the keys of the individual dimension tables • Concatenated primary key that is the concatenation of all the primary keys of the dimension tables • A generated primary key independent of the keys of the dimension tables Data Warehousing

36. 10.4 스타 스키마의 장점 • STAR schema • Simply a relational model with a one-to-many relationship between each dimension table and the fact table • Not a normalized model • The dimension tables are purposely denormalized Data Warehousing

37. 사용자들이 이해하기 쉽다 • Users themselves will formulate queries • The STAR schema reflects exactly how the users think and need data for querying and analysis • The STAR schema defines the join paths in exactly the same way users normally visualize the relationships • STAR 스키마는 사용자들에 의해 직관적으로 이해된다. Data Warehousing

38. 항해를 최적화한다 • 데이터베이스 스키마에서, 데이터 개체들 사이의 관계들이나 연결들의 목적은 무엇인가? • 관계들은 당신이 찾고 있는 정보를 얻기 위하여 한 테이블에서 다른 테이블로 이동하는 데 사용된다. 관계들은 데이터베이스를 통하여 항해(navigation)하는 능력을 제공한다. 당신은 조인 경로들을 사용하여 테이블에서 테이블로 뛰어다닌다. • STAR 스키마의 주요한 장점은 데이터베이스를 통하여 항해를 최적화한다는 것이다. Data Warehousing

39. Optimize Navigation Data Warehousing

40. 당신은 GM 자동차들을 판매하는 자동차 판매대리점에 있는 서비스 관리자라고 가정하자. 당신은 2000년 1월에 코르벳(Corvettes) 표면에 흠이 있는 하얀 페인트칠의 높은 발생률에 주목했다.당신은 그런 결함들을 분석하고, 근원적인 원인들을 결정하고, 그 문제를 해결할 도구가 필요하다. STAR 스키마에서, 결함들의 개수는 결함 사실 테이블의 부분으로서, 중간에서 측정치들로 유지된다. 시간 차원은 모델 연도를 포함한다. 구성성분 차원은 부품 정보를 가진다; 예를 들면, 진주색의 하얀 페인트. 제품 차원은 자동차들의 제작, 모델, 정비 패키지를 포함한다. 공급자 차원은 부품들의 공급자들에 대한 데이터를 포함한다. 지금 진주색의 하얀 코르벳의 표면에 흠이 있는 페인트를 일으키게 한 공급자를 어떻게 쉽게 결정하는 지를 보자. 네 개의 차원 테이블들로부터 사실 테이블로 향하게 하는 네 개의 화살표들을 보라. 제품 차원으로부터 코르벳을, 문제 차원으로부터 흠이 있는 페인트를, 구성성분 차원으로부터 진주색의 하얀 페인트를, 그리고 시간 차원으로부터 2000년 1월을 분리해내기 위해, 당신이 사실 테이블에서 어떻게 행들을 항해하는 지를, 이 화살표들은 보여준다. 항해는 그 문제를 일으킨 공급자를 분리해내기 위하여, 사실 테이블로부터 공급자 차원으로 직접 간다. Data Warehousing

41. 질의 처리에 가장 적합하다 • The STAR schema is a query-centric structure • A simple query: 교과서 284-285 페이지 참조 • What is the total extended cost of product A sold to customers in San Francisco during January 2000? • 주요 특징: next slide • Drill down is a process of further selection of the fact table rows • Rolling up is a process of expanding the selection of the fact table rows Data Warehousing

42. 스타 스키마에서 질의 처리 • 질의에 참여하는 차원들의 개수와 관계없고 질의의 복잡도에 관계없이, 모든 질의는 먼저 질의 매개변수들에 기초한 필터들을 사용하여 차원 테이블들로부터 행들을 선택하고, 그 다음에 대응되는 사실 테이블행들을 찾아냄으로써 단순히 실행된다. • 이것은 간단하고 직접적인 조인 경로들 때문에, 그리고 STAR 스키마의 바로 그 배열 때문에 가능하다. • 차원 테이블들로부터 사실 테이블에 도달하기 위해 항해해야 할 중간의 미로는 없다. Data Warehousing

43. STARjoin and STARindex • STARjoin is a high-speed, single-pass, parallelizable, multitable join • Join more than two tables in a single operation • STARindex is a specialized index to accelerate join performance • Indexes created on one or more foreign keys of the fact table Data Warehousing

44. 요약 • 차원 모델의 구성성분은 요구사항 규정에 있는 정보 패키지로부터 유도된다. • 개체-관계 모델링 기법은 데이터 웨어하우스에 대해 적당하지 않다; 차원 모델링 기법이 적절하다. • 데이터 설계에 사용된 STAR 스키마는 사실과 차원 테이블로 이루어진 관계형 모델이다. • 사실 테이블은 업무 측정규준들이나 측정치들이다; 차원 테이블들은 업무 차원들을 포함한다. • STAR 스키마 장점들은: 사용자들이 이해하기 쉽고, 항해를 최적화하고, 질의 처리에 아주 적합하고, 그리고 특정한 성능 설계들을 가능하게 한다. Data Warehousing