데이터 웨어하우스를 위한 데이터베이스 설계: 기본요건

Presentation on theme: "데이터 웨어하우스를 위한 데이터베이스 설계: 기본요건"— Presentation transcript:

1 데이터 웨어하우스를 위한 데이터베이스 설계: 기본요건
Jong Soo Park 2018년 9월 18일 Data Warehouse

2 Chapter 9 : 데이터베이스 설계: 기본요건
세가지 규칙 간단하게 하라, 간단하게 하라, 그리고 간단하게 하라 스키마(Schema)로 시각화 속도 문제 사용자 조회 시간 관리자 데이터 적재 DW : 데이터가 변경되지 않고 무결성이 엄격히 유지 2018년 9월 18일 Data Warehouse

3 데이터 웨어하우스 데이터베이스의 4가지 기본적인 요건
스키마는 간단해야 한다. 데이터는 깨끗하고 일관성이 있으며 정확해야 한다. 조회처리는 신속해야 한다. 데이터를 데이터베이스에 상당히 빠르게 적재할 수 있어야 한다. 2018년 9월 18일 Data Warehouse

4 순환적 결합 경로를 가진 OLTP 스키마 2018년 9월 18일 Data Warehouse

5 단순성 (Schema의) 설계 기준: 최종 사용자들이 편리하도록 설계 OLTP Schema 데이터베이스 설계자
DBA나 MIS 요원들에게 이익이 되도록 설계 OLTP Schema 두 개의 표를 결합하는 지정된 경로 (Join Operations) 데이터베이스 설계자 분석가의 업무 요건들을 평가 – “차원”을 파악 현재 사용되고 있는 보고서들을 분석 – 사용자 집단이 사용하는 “표”를 분석 실제 차원과 업무 자체의 조건에 바탕을 둔 직관적인 데이터 모델 2018년 9월 18일 Data Warehouse

6 성형 스키마의 구성요소 단순하고 직관적이다. 하나의 별(Star) 별의 뾰족점들 그림 9-2: 사실 표 1개, 차원 표 3개
업무에 관한 모든 수집된 사실과 숫자들 별의 뾰족점들 업무 차원들을 설명하는 일군의 표들 그림 9-2: 사실 표 1개, 차원 표 3개 2018년 9월 18일 Data Warehouse

7 간단한 성형 스키마 2018년 9월 18일 Data Warehouse

8 사실 Fact table 웨어하우스에 저장된 사실들은 분석가가 추적할 필요가 있는 실제 값 예
가장 규모가 큰 – 수백만 개 또는 수억 개의 행이 포함된 – 중앙에 있는 표 측정된 업무 값들 디스크 공간의 95% 차지 “뼈만 추린” 대부분 숫자로 된 행 웨어하우스에 저장된 사실들은 분석가가 추적할 필요가 있는 실제 값 예 판매, 주문, 예산, 선적, 회계, 예약, 구매, 수입, 보험료, 클레임 2018년 9월 18일 Data Warehouse

9 차원 내용 숫자 데이터보다는 문자를 사용하는 경향 웨어하우스가 필요로 하는 디스크 공간은 비교적 적게 차지 예
업무의 “기정 사실”일 가능성이 많다. 사용자 보고서의 행 제목 숫자 데이터보다는 문자를 사용하는 경향 웨어하우스가 필요로 하는 디스크 공간은 비교적 적게 차지 예 시간(또는 기간), 시장, 제품(또는 품목), 고객, 상점, 판매업체, 인구통계학, 홍보활동 2018년 9월 18일 Data Warehouse

10 신뢰할 수 있는 데이터 일관성 있는 해답 데이터는 일괄 형식(batch format)으로 적재 무결성 (참조 무결성)
두번째 중요한 요건(첫번째 : 단순성) 데이터는 일괄 형식(batch format)으로 적재 클린징 또는 변환 과정이 필요 무결성 (참조 무결성) 성형 스키마에 함축된 1차 키 외부 키 참조(primary key foreign key references) 다음 slide 결합 경로의 명확성(내부에서 Join Operations) 2018년 9월 18일 Data Warehouse

11 2018년 9월 18일 Data Warehouse

12 조회 처리 속도 세 번째 중요한 요건 업무 분석가들의 조회를 신속히 처리하고 그들의 사고 흐름을 따라잡을 수 있는 안정된 고성능 서버를 필요 데이터베이스 설계 시에 고려해야 한다. 조회 처리 속도 각기 다른 표 열 위에 구축된 색인의 유형과 색인 수의 함수 각 차원 표의 모든 열마다 색인을 붙이는 것이 훌륭한 전략 각기 다른 차원에 대해 각기 다른 유형의 색인 2018년 9월 18일 Data Warehouse

13 적재 처리와 성능 네 번째 중요한 요건 웨어하우스 설계에서 더 결정적인 측정 기준
소스에서 웨어하우스로 데이터를 적재하는 시간 몇 시간 대 며칠의 문제 적재 속도는 웨어하우스 설계의 다른 기본 원칙을 고수하면 얻을 수 있다 데이터 모델링시 성형 스키마 스타일 단순성의 원칙 표 구조의 단순성, 소스 데이터의 깨끗함, 참조 무결성 등 2018년 9월 18일 Data Warehouse

14 성형의 갖가지 형태 웨어하우스 스키마의 점증하는 복잡성 Outboard tables, Multi-fact stars,
Fact table families 2018년 9월 18일 Data Warehouse

15 Outboard Tables Dimension Table에 외부 키 참조를 통해 Outboard table을 작성
또는 Outrigger table이라 함. 내부 차원에 너무 많은 부담을 주게 될 데이터를 격리 -> 설계 단순화 그림 9-4 : 다음 slide 2018년 9월 18일 Data Warehouse

16 2018년 9월 18일 Data Warehouse

17 사실 표 군 가치 체인 일련의 공유 차원들을 갖춘 사실 “군(family)”
대기업 전반에 걸쳐 종종 가치 체인의 부분들을 형성 한 조직체를 통틀어 제품 또는 서비스의 흐름을 반영하는 일련의 연결된 업무 작업 일련의 공유 차원들을 갖춘 사실 “군(family)” 다음 slide 2018년 9월 18일 Data Warehouse

18 2018년 9월 18일 Data Warehouse

19 다성형 사실 표 차원 표 1차 키의 어떤 조합이 사실 표에서 둘 이상의 행을 가리킬 경우 -> multi-star schema 그림 9-6 : 다음 slide 2018년 9월 18일 Data Warehouse

20 2018년 9월 18일 Data Warehouse

21 Conceptual Modeling of Data Warehouses
Modeling data warehouses: dimensions & measures Star schema: A fact table in the middle connected to a set of dimension tables Snowflake schema: A refinement of star schema where some dimensional hierarchy is normalized into a set of smaller dimension tables, forming a shape similar to snowflake Fact constellations: Multiple fact tables share dimension tables, viewed as a collection of stars, therefore called galaxy schema or fact constellation 2018년 9월 18일 Data Warehouse

22 Example of Star Schema item branch time Sales Fact Table time_key
day day_of_the_week month quarter year time item_key item_name brand type supplier_type item Sales Fact Table time_key item_key branch_key branch_key branch_name branch_type branch location_key street city province_or_street country location location_key units_sold dollars_sold avg_sales Measures 2018년 9월 18일 Data Warehouse

23 Example of Snowflake Schema
time_key day day_of_the_week month quarter year time item_key item_name brand type supplier_key item supplier_key supplier_type supplier Sales Fact Table time_key item_key branch_key location_key street city_key location branch_key branch_name branch_type branch location_key units_sold city_key city province_or_street country dollars_sold avg_sales Measures 2018년 9월 18일 Data Warehouse

24 Example of Fact Constellation
time_key day day_of_the_week month quarter year time item_key item_name brand type supplier_type item Shipping Fact Table Sales Fact Table time_key item_key time_key shipper_key item_key from_location branch_key branch_key branch_name branch_type branch location_key to_location location_key street city province_or_street country location dollars_cost units_sold units_shipped dollars_sold avg_sales shipper_key shipper_name location_key shipper_type shipper Measures 2018년 9월 18일 Data Warehouse

25 요약 기본적인 설계 요건 성공적인 설계 단순성 데이터의 일관성과 정확성 조회 처리 속도 적재 속도 서비스를 제공
첫번째 설계는 매우 기본적이 되게 한다. 사용자들의 의견을 들은 뒤 반영 일관성 있고 가치 있는 정보 제공 2018년 9월 18일 Data Warehouse