slide1
Download
Skip this Video
Download Presentation
제 10 장

Loading in 2 Seconds...

play fullscreen
1 / 44

10 - PowerPoint PPT Presentation


  • 220 Views
  • Uploaded on

제 10 장. 차원 모델링의 원리. 장의 목표. 요구사항의 규정이 데이터 설계를 결정하는 방법 차원 모델링과 개체 - 관계 모델링 비교 STAR schema 사실 테이블과 차원 테이블의 내부 비교 데이터 웨어하우스를 위한 STAR 스키마의 장점. 10.1 요구사항에서부터 데이터 설계까지 . 요구사항의 규정은 데이터 웨어하우스를 위한 데이터 설계에 이용된다 . 데이터 설계는 자료 구조들을 조립하는 것 한 그룹의 데이터 요소들은 하나의 자료 구조를 형성한다 .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' 10 ' - Patman


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

제 10 장

차원 모델링의 원리

Data Warehousing

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

Data Warehousing

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

Data Warehousing

slide4

정보 매트릭스:

측정단위,

업무차원,

업무차원간의 계층

그림 10-1 FROM REQUIREMENTS TO DATA DESIGN

Data Warehousing

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

Data Warehousing

slide6
차원 모델링 기초
  • 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

typical query
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

how to arrange the fact and dimensional tables
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

use of case tools
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

forward engineer
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

reverse engineer
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

10 2 star
10.2 STAR 스키마
  • 간단한 STAR 스키마의 검토
    • Figure 10-7
    • The orders fact table
    • Four dimension tables

Data Warehousing

slide18

SKU(Stock Keeping Unit)

최소유지상품단위

Data Warehousing

slide19
간단한 질의
  • 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

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

Data Warehousing

slide22

Drill-down analysis

Data Warehousing

slide23
차원 테이블 내부
  • 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

slide25
사실 테이블 내부
  • 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

the factless fact table
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

data granularity
데이터 구체화정도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

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

Data Warehousing

slide31
10.3 스타 스키마 키
  • Star Schema Keys
    • 기본키 primary key
    • 대리키 surrogate key
    • 외래키 foreign key

Data Warehousing

primary keys
기본키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

surrogate keys
대리키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

foreign keys
외래키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

slide36
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

slide37
사용자들이 이해하기 쉽다
  • 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

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

Data Warehousing

slide39

Optimize Navigation

Data Warehousing

slide40

당신은 GM 자동차들을 판매하는 자동차 판매대리점에 있는 서비스 관리자라고 가정하자. 당신은 2000년 1월에 코르벳(Corvettes) 표면에 흠이 있는 하얀 페인트칠의 높은 발생률에 주목했다.당신은 그런 결함들을 분석하고, 근원적인 원인들을 결정하고, 그 문제를 해결할 도구가 필요하다.

STAR 스키마에서, 결함들의 개수는 결함 사실 테이블의 부분으로서, 중간에서 측정치들로 유지된다. 시간 차원은 모델 연도를 포함한다. 구성성분 차원은 부품 정보를 가진다; 예를 들면, 진주색의 하얀 페인트. 제품 차원은 자동차들의 제작, 모델, 정비 패키지를 포함한다. 공급자 차원은 부품들의 공급자들에 대한 데이터를 포함한다.

지금 진주색의 하얀 코르벳의 표면에 흠이 있는 페인트를 일으키게 한 공급자를 어떻게 쉽게 결정하는 지를 보자. 네 개의 차원 테이블들로부터 사실 테이블로 향하게 하는 네 개의 화살표들을 보라. 제품 차원으로부터 코르벳을, 문제 차원으로부터 흠이 있는 페인트를, 구성성분 차원으로부터 진주색의 하얀 페인트를, 그리고 시간 차원으로부터 2000년 1월을 분리해내기 위해, 당신이 사실 테이블에서 어떻게 행들을 항해하는 지를, 이 화살표들은 보여준다. 항해는 그 문제를 일으킨 공급자를 분리해내기 위하여, 사실 테이블로부터 공급자 차원으로 직접 간다.

Data Warehousing

slide41
질의 처리에 가장 적합하다
  • 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

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

Data Warehousing

starjoin and starindex
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

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

Data Warehousing

ad