The Data Warehouse Toolkit, 3rd Edition CH.10 Financial Services

Presentation on theme: "The Data Warehouse Toolkit, 3rd Edition CH.10 Financial Services"— Presentation transcript:

1 The Data Warehouse Toolkit, 3rd Edition CH.10 Financial Services
UOS.DML. Kim Jeong Rae

2 Introduction The financial services industry A full-service bank
/17 Introduction The financial services industry A wide variety of businesses, including credit card companies, brokerage firms, and mortgage providers. A full-service bank checking accounts, savings accounts, mortgage loans, personal loans, credit cards, and safe deposit boxes. In this chapter Area Focusing on the retail bank This chapter begins with a very simplistic schema. We then explore several schema extensions, including the handling of the bank’s broad portfolio of heterogeneous products that vary significantly by line of business.

3 Banking Case Study and Bus Matrix
/17 Banking Case Study and Bus Matrix Banking Case Study The bank’s initial goal is to better analyze the bank’s accounts. Business users want the ability to slice and dice individual accounts, as well as the residential household groupings to which they belong. One of the bank’s major objectives To market more effectively by offering additional products to households that already have one or more accounts with the bank.

4 Banking Case Study and Bus Matrix
/17 Banking Case Study and Bus Matrix Banking Bus Matrix Dimensions Business Processes

5 Dimension Triage to Avoid Too Few Dimensions
/17 Dimension Triage to Avoid Too Few Dimensions Balance Snapshot Dimensions : Date(Month), Account Process : Account Monthly Snapshot Problem 각 계좌는 한 개의 Household(세대)와 Branch(지점), Product(상품)과 관련하여 구축되었음 거대한 Account Dimension에서 Product(상품)과 Branch(지점)같은 추가적인 분석Dimension을 반영 요구

6 Dimension Triage to Avoid Too Few Dimensions
/17 Dimension Triage to Avoid Too Few Dimensions 다차원 모델의 Dimension 수 : 대부분 5 ~ 20 개 Dimensions 로 구성 Kinds of dimensions Causal dimensions : 계약, 거래, 매장 상태, 날씨 등 어떤 사건의 원인에 대한 통찰 제공 프로모션 (In Chapter 3) Multiple date dimensions : 특히 Fact Table이 점진적 스냅샷인 경우 (In Chapter 4) Degenerate dimensions : 주문, 송장, 선하증권, 티켓과 같은 운영 트랜잭션 통제 번호 (In Chapter 3) Role-playing dimensions : 하나의 트랜잭션에 해당 Dimension과 연관된 여러 Business entities를 갖는 경우, 각각은 서로 분리된 Dimension으로 표현 (In Chapter 6) Status dimensions : 계정 상태와 같이 약간 큰 데이터 내에서 트랜잭션이나 월별 스냅샷의 현재 상태를 식별 하게 함. An audit dimension : 데이터 연결 추적성과 품질을 추적 (In Chapter 6) Junk dimensions : 상관도 높은 분류 값과 플래그들의 Dimension (In Chapter 6)

7 Dimension Triage to Avoid Too Few Dimensions
/17 Dimension Triage to Avoid Too Few Dimensions Solution : Supertype Snapshot F.T. 상품명 상품유형, 분류 정보 등 경제단위와의 관계 세대 수입 집 소유 은퇴여부 자녀 등 활성, 휴면상태, 신규계좌 개설, 해지 등

8 Multivalued Dimensions and Weighting Factors
/17 Multivalued Dimensions and Weighting Factors Multivalued(다중값) Dimensions 계좌는 계좌와 연관된 하나, 둘 그 이상의 소유주 또는 고객을 가질 수 있음. Problem 고객은 계좌 속성(attribute)으로 추가될 수 없다. 한 계좌에 한 명 이상의 개인이 연관되는 것 : Dimension table의 그래뉼래러티 위반 Fact Table에 별도의 Dimension으로 고객을 추가 할 수 없다. 한 계좌에 한 명 이상의 개인이 연관되는 것 : Fact table의 그래뉼래러티 위반 Solution 개별 Customer Dimension과 Account Dimension을 grain인 Fact Table에 연결하기위해 Account와 Customer Dimension 간에 Bridge Table이 요구됨

9 Multivalued Dimensions and Weighting Factors
/17 Multivalued Dimensions and Weighting Factors Solution : Account–to–Customer Bridge table 한 계좌가 두 계좌 소유주를 갖는다면, 브리지 테이블은 두 개의 rows를 갖음 Account Key와 Customer Key를 갖고 Bridge table을 활용하여 해결

10 Multivalued Dimensions and Weighting Factors
/17 Multivalued Dimensions and Weighting Factors Weighting Factor 계좌 소유주에 대해 합산가능 Fact를 배부하는 간단한 방법임 각 계좌 소유주에게 가중치 수치를 배정하여 가중치의 합이 정확히 1.00이 되게 할 수 있음 가중치는 계좌 소유주에 대해 합산가능 Fact를 배부하는데 쓰임 소유주별로 모든 수치 Fact를 합산 할 수 있고, 총합은 정확한 총 금액

11 Mini-Dimensions Revisited
/17 Mini-Dimensions Revisited Problem 은행 계좌, 고객, 세대를 설명하는 속성(attribute)들은 매우 많음 매월 신용평가등급, 외부 인구통계학 데이터, 고객행동, 유지, 수익성, 체납특성을 식별하기 위한 계산된 점수 등 시간이 지남에 따라 변화하는 속성(attribute)들에 대응 요구됨 Solution 자주 조회되고 잘 변하는 속성들은 여러 Mini Dimension들로 분리 신용평가, 인구통계학 속성들은 매달 갱신 Mini Dimension으로 Fact Table에 FK를 추가 Mini Dimension

12 Mini-Dimensions Revisited
/17 Mini-Dimensions Revisited Problem 너무 많은 Mini- Dimension을 포함해서는 안되며, 적절한 Mini Dimension의 row 수를 요구 Solution 속성(attribute)의 구간 값을 활용하여 Mini Dimension의 row 수를 적절히 유지 구간 값 설정 세분화 된 수익금 31,257,98달러 → 30,000달러 < 수익금액 <= 34,999달러 수익성 점수가 1 ~ 1200 범위 → 고정된 범위로 표현 : 100이하, 101~150, 151~200 유의사항 데이터 마이닝 분석에는 개별값이 더 효율적 구간 값이 적절한 결정여부 분석이 요구됨

13 Adding a Mini-Dimension to a Bridge Table
/17 Adding a Mini-Dimension to a Bridge Table Problem RCD(Rapidly Changing Dimension)빨리 변하는 괴물 디멘션 : Customer Dimension Account-to-Customer Bridge table이 매우 커질 수 있음 Solution 빨리 변하는 인구통계학 속성과 상태속성들을 Mini Dimension으로 분리 : Demographics Dimension Mini Dimension

14 Dynamic Value Banding of Facts
/17 Dynamic Value Banding of Facts Problem(상황 : 비즈니스 사용자 요구사항) 계좌 잔액과 같은 기본 숫자 Fact를 대상으로 구간 값 리포팅을 요구 Dimension table에 정의된 구간 값만으로 만족하지 않음 Solution 구간 정의 Table : Band Definition Table

15 Subtype Schemas for Heterogeneous Products
/17 Subtype Schemas for Heterogeneous Products Problem 기업이 제공하는 상품과 서비스의 이질적인 특성들로 인해 딜레마 발생 동일 고객에게 예금계좌에서 신용카드까지 많은 상품을 제공 Solution SubType 특별한 팩트 : 예금계좌 Fact Table SuperType과 SubType의 Dimension에서 상품 대체 key(키)는 동일 하여야 함.

16 Hot Swappable Dimension
/17 Hot Swappable Dimension Problem(상황 : 주식시장 다양한 고객의 요청 대응 위한 F.T.) 증권사는 고가-저가-종가의 일 단위 주가를 저장하는 동일 Fact Table에 접근한다. 그러나 각 고객은 각 주식의 설명 속성들을 개인별로 설정 Solution 다양한 고객의 요청에 대응하기 위해, 쿼리 시 하나의 Fact Table과 조인하는 별도의 복제한 주식 Dimension들을 보유할 수 있음.(Hot Swappable Dimension) Fact Table과 다양한 Dimension table간의 참조 무결성 제약은 해제

17 /17 감사합니다.