메뉴 건너뛰기

bysql.net

09 패턴의 활용

2013.04.16 02:23

정재훈 조회 수:21357

Capter 9. 패턴의 활용


이장은 이제까지 검토해온 여러 종류, 다양한 레벨 패턴들을 실제 데이터 모델링 상황에서 

어떻게 적용할 것인가를 설명한다.

먼저 이제까지 검토해온 패턴들은 하나의 컴포넌트(객체-레고 블럭)라고 여김.

데이터 모델링 시나리오는 다음과 같이 나눈다.

- 프로토타이핑 데이터 모델링

- 어플리케이션 데이터 모델링

- 전사 데이터 모델링

- 데이터웨어하우스 데이터 모델링

- 마스터데이터 관리 데이터 모델링


1. 프로토타입 데이터 모델링


" 시나리오 "

  Sands Distribution사는 대기업으로써 두바에 있는 석유화학 산업 장비를 유통하는 회사이다.

  이 회사는 최근 몇년동안 상당히 성장하였고 세계 도처에서 이 회사의 장비에 대한 수요도 꽤 증가하였다.

  데이터가 잠재적 자산임을 인식하고 여러 국가에서 고객 데이터를 갖고 있는 작은 유통회사들을 흡수 하였다. 

  하지만 이 자산-고객 데이터들-을 어떻게 최적화 할 것인가? 어떻게 통합하고 시스템화할 것인가? 즉 통합하고

  관리하는데 일관성있는 전략을 원했다.

  그래서 CEO는 고객중심의 회사로 발전시키고자 데이터 전략을 수립하기 위해 데이터 전문가 그룹을 초빙한다.


데이터팀 접근 방법

  데이터 전문가 그룹은 이회사의 현재와 미래 발생할 요구사항에 대한 데이터 전략서를 작성하기로 함

  이들은 회사에 고객에 대한 과업범위서를 작성을 요청함.


Sands Distribution사의 고객 과업범위서. (과업범위서: 1단계)

RFP:Request For Proposal: 제안요청서

  1) 고객

    - Sands Distribution 사에게 상품을 구매하고 배송받고, 사용한다.

    - 조직 또는 개인일 수 있다.

    - 모회사 조직 (상부)이 있다. 없을 수도 있다. (개인 경우)

    - 다양한 연락처가 필요한다. 영수증, 배송지, 고객개인, 회사에 대한 연락처

    - 상태가 있다.

    - 유효: 최근 2년 동안 한 건이라도 거래가 발생한 고객

    - 더 많은 상태가 존재하지만 아직 알지 못함.

    - 다양한 형태로 분류한다.

    - 고객 규모: 대규모, 중규모, 소규모

    - 고객 산업분류: 제조

    - 고객 업종: 통신

  2) 상부 조직

    - 고객을 관리한다.

    - 조직 규모: 대규모, 중규모, 소규모

  3) 주문

    - 오직 한 고객이 주문하고

    - 오직 한 고객에게 배송되며

    - 오직 한 고객에게 사용된다.


" 데이터모델링: 프로토타입 1단계 설계 "

전략 

  - 고위 경영진과 관리자들에게 가능성(고객 중심의 회사)을 시사해줌

  - 다양한 리포트, 화면, 경영 분석 루틴에 적용 유무 확인

  - 데이터의 범위를 사전 파악

  << 즉. 초기에 과업범위를 파악하기 위한 것 >>


 [ 모델링 설계 ]

 프로토타입1 모델링.png



    - 고객 연락처

      컨택메커니즘 : 레벨 1을 적용

      첫째. 고객에게 연락하기 위한 모든 항목을 찾기를 원함.

      둘재. 다양한 연락처의 용도, 목적, 유형을 찾기를 원함.

    - 주문 고객 유형 정보

      맥락적 역할 : 레벨 2 적용



고위 경영진과 관리자와 협의 후 아래 내용 피드백받음. (과업범위서: 2단계)

  ● 고객은 유효함 또는 유효하지 않음 이외에 더 많은 상태를 갖음 

  ● 모회사의 연락처 정보가 필요. 단 개인 연락처는 필요 없음

  ● 모회사도 고객처럼 상태, 연락정보, 업종, 산업분류 정보가 필요함

  ● 모회사가 존재하면 모든 청구서는 모회사에 보낸다. 없으면 고객에게 보낸다.

  ● 배송은 모회사가 주문 결재했어도 고객에게 전달 된다.

  ● 한 고객이 다양한 유형으로 분류 될 수 있다.

    (산업분류: 제조, 유통, 서비스, 업종: S/W 개발, 판매, 통신서비스 등)


" 데이터모델링: 프로토타입 2단계 설계 "

아래 부분을 수정하기로 함

상태 패턴 : 레벨1 -> 레벨2 : 새로운 상태 추가

분류 패턴 : 레벨1 -> 레벨2 : 새로운 분류 추가

모회사에 컨택 메커니즘 레벨1 적용

“모회사가 존재하면 모든 청구서는 모회사에 보낸다. 없으면 고객에게 보낸다.”는 비즈니스룰 패턴


모델링 설계

프로토타입2 모델링.png


" 강점 "

  ● 이해하기 쉽다

  ● 사용하기 쉽다

  ● 구현하기 쉽다

  ● 좋은 시작 포인트

  ● 비즈니스 대표자들과 커뮤니케이션하는데 효과적

  ● 상위 레벨 패턴으로 변경이 간단하다.

  - 클라이언트(고위 경영진과 관리자)들는 요구사항은 구체적이지만 비전문가들로써

     어떻게 자신들의 요구사항이 어떻게 충족되는지 알고 싶어함.

  - 데이터 팀은 초기에 업무의 이해도나 조직의 구조 및 흐름에 대해 접근이 어려움.

  - 클라이언트와 커뮤니케이션 쉽게 이루어짐. (커뮤니케이션 중요성 : 고객은 무엇을 말해야 할지 모름.)

  - 요구사항 검증하고 과업범위로서 일부분을 사용

  - 내용이 구체적이기 때문에 요구사항에 대한 오해나 실수를 확인할 수 있다.

  - 이들의 용어를 이해하는 도움을 준다.

  - 짧은 기간에 작성할 수 있다


" 약점 "

  ● 정규화되지 않는 많은 속성을 갖을 수 있다.

  ● 첫 거래 일자, 최근 거래일자 등과 같은 고객 상태에 따른 다양한 자료를 갖을 수 없다.

  ● 공통 루틴으로 재 사용이 어렵다

  ● 유연성이 부족하다. 시스템을 운영하면서 향후에 발생할 수 있는 다양한 요구사항을 충족할 수 없다.



  프로토타입 모델이란 레벨1, 레벨2 패턴을 이용하여 데이터모델링 설계하는 것으로

  고객과 커뮤케이션 용도로 사용하고 시스템에 적용하기에는 부족하다.



2. 어플리케이선 데이터 모델


" 시나리오 "

  데이터 팀은 프로트타입을 고위 경영진과 협의한 후에 고객 데이터 관리(어플리케이션을 통한 관리)를 위한 완성적인   데이터모델을 요청 받았다. 그런데 고위층과 관리자들은 고객의 다양한 상태, 다양한 종류 등과 향후 발생할 다양한   형태에 대해서 구체화 할 수 없었다.


  데이터팀 접근 방법

    첫째. 데이터 범위 확인 (프로토타입 2를 기준으로)

    둘째. 어플리케이션 개발을 위해 기능에 관해 논의할 업무(현업) 전문가 (비즈니스와 IT)와 업무 협의


● 업무 협의 사항

1. 고객계층:

  - 조직 경우: 두레벨 이상의 고객 계층을 갖는다. 모회사, 자회사, 사업부, 팀 등

  - 개인 경우: 개인 정보

2. 고객상태: 동일 시점에 하나 이상의 상태 갖을 수 있음 : 유효함, 신용조회 중

3. 다양한 고객 분류가 있다.

  - 주문자, 공급자, 배송자, 파트너 등

  - 한 고객이 여러 역할: 공급와 파트너를 동시 수행

4. 다양한 주문 분류가 있다.

  - 제품 구매 주문, 생산 주문, 배송 주문 등

5. 각 고객이 동일 회사, 하위 사업부의 개별 고객들인 경우에는 휴대폰번호, 메일주소, 전자주소,

   우편번호, 집 주소를 서로 공유하여 사용

6. 각 연락처에 대한 용도와 목적을 관리

  - 목적: 청구, 용도:개인적, 판매목적으로 연락 하지 말것 등



" 모델링 설계 "


" 전 략 "

    프로토타입2 모델을 기준으로 위 요구사항을 반영할 수 있도록 설계

     레벨1, 레벨2 => 레벨2와 레벨3로 교체


" 모델링 "


어플리케이션 모델링.png




" 강점 "

● 어플리케이션의 구체적인 요구사항과 향후 발생할 업무의 변화에 유연하게 대처할 수 있음

  - 다양한 고객 유형에 적용할 수 있음

  - 여러 종류의 연락처를 다양한 형태로 관리할 수 있음

  - 고객 종류와 연락처의 목적, 용도가 미래에 다양한 형태로 요구되더라도 데이터모델에 대한 변경

    없이 어플리케이션에 적용할 수 있다

● 통합 공통 솔루션

  - 개인과 조직에 모두 적용 가능

● 일관성

  - 비즈니스 전문가가 더 유연한 버전의 모델을 요구할 때 이 모델을 기준으로 더 표준화된 구조로

    발전 시킬 수 있다.


" 약점 "

● 어떤 면에서는 유연하지 못하고 어떤 면에서는 복잡하다

  - 더 구체적인 업무가 제시될 때는 사용하지 못함

  - 업무가 단순할 경우는 복잡함 초래

● 공통적인 모델링 스타일의 결여

● 이해도 저하 초래: 비즈니스 대표자들에게는 너무 복작하다고 생각됨

● 비즈니스 룰 표현이 부족해짐

  - 구체적인 패턴은 일반화된 패턴 보다 비즈니스 룰과 설명을 데이터모델에 더 많이 표현할 수 있음.



어플리케이션 데이터모델링이란 실재 데이터를 관리하기 위한 단계의 모델링으로 구체화 단계에서 일반화 단계로 구현하는 것을 의미한다.




3. 전사 데이터 모델


“ 시나리오 ”

운영위원회는 다양한 어플리케이션이 동일한 고객 데이터 유형을 갖고 있다는 사실을 인식하고 일관성 있는 데이터 모델링 구조를 사용한다면 커뮤니케이션을 향상시킬 수 있고, 유지보수 비용을 줄일 수 있으며 프로그램 인터페이스를 단순화하고 데이터 품질을 향상시킨 수 있다고 생각하게 되었다.

그래서 데이터팀에게 전사적 차원에서 효과적이고 일관성있는 데이터 모델링을 요청하였다.

● 전사에 걸처 데이터모델을 활용하기 때문에 현재와 미래의 데이터 전체를 기술해 달라

● 전사의 다양한 활동에 한 단계 높은 출발점을 제공해주고 통합할 수 있는 일관성을 제공하며 품질보증 

   체크포인트를 제공해 달라


   “일단” 고객, 주문, 상품에 초점을 둔 전사 데이터 모델링 진행



데이터팀 접근 방법


프로토타입 단계 데이터 모델링과 어플리케이션 단계 데이터 모델링을 적절히 혼합한 데이터 모델링

즉 구체화와 일반화를 모두 적용한 데이터 모델링....



“ 모델링 설계 ”


전략

- 동일한 레벨의 패턴을 일관성 있게 적용

- 구체화 패턴과 일반화 패턴을 적절히 섞어 구현


- 다양한 패턴으로 구현하기 (레벨2로구현, 레벨3로 구현)

첫째. 고객 정보

  - 고객별 다양한 상태 적용 (패턴 레벨3)

  - 고객뿐 아니라 고객 Role에 있을 수 있는 모든 분류 유형을 관리 (Role 유형 엔티티)

  - 하나 또는 그 이상의 고객으로 세분화 (Recursive Partten)

  - 고객과 고객 간의 관계 표현 (고객관계 엔티티)

둘째. 주문

  - 다양한 형태 주문 유형을 관리 (주문 Role 정보)

  - 주문에 대한 고객의 역할 표현가능 (주문, 배송, 출하 등..)

  - 구체화 표현 (상품정보)

  - 상품의 다양한 분류 추가 (상품 분류 정보)

셋째. 연락처

  - 일관되고 다양한 형태의 연락처 관리 (컨텍메커니즘 레벨 3 적용)



모델링


전사 모델링.png



“ 강점 ”

● 고품질의 데이터모델링 방법이다

● 데이터 모델링에 대한 일관성을 제공한다.

● 해당 패턴을 사용하므로써 모델링 시간을 줄일 수 있다.


“ 단점 ”

● 다양한 대한 패턴을 적용한 모델링은 접근의 어려움이 있다. 이해하기 어렵다.

● 여러 레벨의 패턴을 적용하므로 일관성이 없을 수도 있다.



전사 데이터모델링이란 전사에 걸처 적용하기 위한 모델링 단계로서 구체화와 일반화를 적절히 적용하여 데이터 모델리을 진행하는 것이다. 즉 역할, 분류, 재귀 릴레이션쉽, 상태 등과 같은 공통적인 구조의 모델링 방법이다.





4. 데이터웨어하우스 데이터 모델


기업에서 시스템을 통해서 데이터를 관리하는 궁극적인 목적

- 현재 상황를 실시간 파악

- 문제 상황에 대한 빠른 의사 결정

I. 현재 상태를 실시간 파악한다는 것

- 기업 운영에서 발생한 여러 가지 상태-데이터-들을 즉시성(Real Time)으로 파악하는 것

- 고객, 제품, 주문에 대해서

- 어떤 상품이 누구에게, 어디에서 언제 가장 매출이 높은가? 주문량이 많은가?

- 어떤 유형의 고객이 어떤 유형의 상품을 가장 많이 주문하는가?

- 가장 큰 규모로 주문하는 지역은, 고객은, 기업은?

- 각 지역의 주문 금액 비율은?

II. 빠른 의사 결정한다는 것

- 한도 초과 고객의 주문을 접수 받을 것인가?

- 더 이상 주문, 판매가 이루어지지 않은 제품에 대한 생산을 계속할 것인가?

- 개인 주문이 더 이상 없을 경우 개인에게 제품을 판매할 것인가?

- 원가 비중이 높은 제품을 계속 생산, 판매할 것인가?

- 적정 재고 수량은 얼마큼 유지할 것인가?

- 고객 관리 인원이 적정한가?


이런 부분을 지원할 수 있는 시스템을 어떻게 구축할 것 인가?


이런 시스템을 구축할 때는 또한 아래의 요구사항이 나타난다.

- 분석 자료를 매우 빠르게 리포팅해야 하고

- 매우 다양한 리포팅 - 비교 표, 그래프 등-을 지원해야하고

- 운영자와 경영진 다양한 요구사항/ 변덕스러운 요구사항에 빠르게 대처할 수 있어야하고

- 향후에 발생할 다양한 상황에 대해 확장성과 유연성을 갖추어야함.

- 현재 상품계열, 상품유형, 상품군 분류가 향후는 가격구간 유형(고가, 중가, 저가), 상품사용분류(산업용, 가정용)

- 고객 분류가 더 다양함

- 시장분야 분류(오일, 가스, 정제, 탐사 회사 등)

- 직원수 분류(1000명 미만, 5만명 미만, 5만명 이상 등)

- 지리적 범위 리포팅

- 가장 큰 규모로 주문하는 곳

- 각 지역의 주문 금액 비율


솔루션: 데이터웨어하우스 구축하고 의사결정지원 시스템을 개발하는 것 (BI)


이 구축의 주요 소스

- 전사차원의 데이터모델링

- 전사 모델링 범위를 넘어선 현업(IT부서와 경영진)의 요구사항


이번장은 데이터웨어하우스를 모델링하는 두가지 방법에 패턴들을 어떻게 적용할 것인지 설명

   1. 관계형 모델 접근법

   2. 스타스키마 모델 접근법


1) 데이터웨하우스 데이터 모델 - 관계형 접근법


데이터팀은 의사결정 지원시스템에서 데이터 요구사항에 대한 변경이 매우 빈번히 발생함 => 매우 유연한 모델을 생성하기로 결정함. 먼저 데이터모델 소스는 전사데이터모델을 사용하기로 결정하고 어떤 패턴을 의사결정 지원 데이터모델에 어떻게 적용할 수 있을지 검토하였다. 그리고 미래의 다양한 소스 시스템을 수용할 수 있는 데이터웨어하우스가 필요하다고 생각하였다.

일관성 있는 일반화된 레벨-즉 고객분류 패턴으로 제품 및 다른 부분에도 적용-로 데이터웨어하우스 설계에 적용한다면 유연성 보장할 뿐 아니라 각각의 데이터를 관리하는 방법이 유사할 것이고 개발과 관리가 쉬울 것이라고 판단하였다.

전사데이터모델과 의사결정 요구사항을 검토한 결과 아래와 같은 데이터모델링을 하였다.


“ 데이터 모델링 ”

DW 관계형 설계.png





[ 고객 ROLE 패턴 부분 ]

- 개인이나 조직을 하나의 고객 테이블-PARTY-로 관리

  고객별 역할을 고객 ROLE 테이블 -PARTY ROLE-로 관리 

  고객별 ROLE을 카테고리를 TYPE 별로 관리

- 미래에 발생한 새로운 ROLE TYPE를 쉽게 추가할 수 있고 쉽게 관리할 수 있음.

- 내,외부 IT 전문가 이러한 패턴에 익숙해서 그들의 경험을 재사용할 수 있다고 판다.

- 고객 조직구조에 레벨2 재귀패턴을 적용했음.

- 레벨3 재귀패턴을 이용해서 어떤 고객 ROLE이 고객관계, 고객관계 유형을 통해 다른 고객 ROLE과 연관될 수 있게 하였다.


[ 고객 릴레이션쉽 패턴 부분 ]

- 고객 릴레이션쉽과 고객 릴레이션쉽 유형을 사용 고객의 모든 연관 관계를 표현한다. 고객과 고객이 일하는 기업간의, 공급자와 공급자간의, 고객의 내부조직과 파트너 조직 간의 경우처럼 관계자 사이에 존재할 수 있는 모든 릴레이션쉽을 유연하게

표현한다.

- 외부의 다른 소스에서는 다른 유형의 고객관계를 표현할 수 있다. 고객이 다른 고객의 파트너가 되고 고객이 다른 고객과 통합되고, 다른 고객을 통해 고객이 획득되고 

- 다양한 역할에 대한 계층, 집합, 개인간의 릴레이션쉽을 관리할 수도 있어야함. 

  공급자 계층의 릴레이션쉽, 판매사원과 고객간의 릴레이션쉽, 작업자와 고객간의 릴레이션쉽 등

   => 모델링하는 데 동일한 구조를 사용해야함.

[ 고객 분류 패턴 ]

- 전사데이터모델은 레벨2분류 패턴 사용 -고객규모, 사업유형, 고객유형 -

- 레벨3재귀분류패턴을 적용 : 고객역할 유형에 포함시킴

  미래에 발생할 다양한 유형을 분류 엔티티 추가 없이 반영해야 함. : 유연성 확보

  고객규모, 사업유형, 고객유형 뿐아니라 시장점유율, 직원수 뿐아니라

  고객 평가, 소수 고객의 상태 (다른 어플리케이션에서 적용)

[ 제품분류 패턴 ]

- 고객역할과 같은 레벨3재귀분류패턴을 적용함

  미래에 발생할 다양한 유형을 분류 엔티티 추가 없이 반영 함

  상품유형, 상품계열, 상품군과 같은 다양한 유형의 분류 반영

[ 고객 연락처 패턴 ]

- 요구사항

   각 주문별로 주문 청구자의 본사가 어느 나라에 있는지 알아야함

   주문 정보에 지역 정보를 포함

   주문은 오직 하나의 지역에서 주문될 수 있다. 하나의 지역은 여러 주문 지역될 수 있다.


결론적으로 데이터팀은 비즈니스의 미래요구사항을 지원하고 다양한 릴레이션쉽을 관리할 수 있는 매우 유연한 데이터모델을 생성하였다. 레벨3패턴은 구현과 관리의 어려움을 초래할 것이라고 생각했지만 모델이 매우 일관성 있기 때문에 어플리케이션을 통한 관리가 일관성을 유지할 수 있음. 루틴을 재사용할 수 있음. 고객 분류와 상품분류가 유사함 => 고객 분류 개발한 어플리케이션에 약간의 코드 수정으로 상품 분류도 적용할 수 있다. (?)



“ 장점 ”

이 패턴을 사용하는 이유

전사 범위의 다차원 모델을 개발할 충분한 지식이 없어도 유연한 모델로 데이터웨어하우스 구축할 수 있음

다양한 분석을 위한 매우 포괄적인 유형의 데이터를 관리할 수 있다.

조직 내부의 전문지식을 재 사용할 수 있다.

1. 의사결정지원 데이터를 관리하기에 매우 유연한 솔루션을 제공 (레벨3패턴)

2. 동일한 패턴이 데이터웨어하우스 전반에 걸쳐 사용되었기에 일관성있게 데이터와 프로그램을 관리

3. 이력관리가 쉽움

=> 전사 데이터 모델이 데이터웨어하우스 요구사항을 기반으로 변경될 수 있다.



“ 약점 ”

일반화 패턴을 사용하므로 데이터모델이 복잡하다. 이해가 어렵다.

구체적인 이력관리를 할 수 없다.

이러한 설계는 매우 유연한 설계를 제공하지만 데이터를 적재하고 리포팅하기 매우 어렵다.

소스 데이터를 이렇게 견고하고 유연한 데이터웨어하우스 구조로 가져온 후에 스타스키마 설계를 기반으로 한 데이터마트로 분배할 수 있다.



2) 데이터웨하우스 / 데이터 모델 - 스타스키마 접근법

시나리오 관계형 접근법과 동일함.

데이터팀은 요구사항을 충족할 수 있는 현실적이고 단순한 접근법을 원함.

또한 많은 기업의 IT 부서에서 데이터웨어하우스 개발을 위해 스타스키마 다차원 접근법을 사용하고

있음을 알고 있었다.


접근 방식은

첫 번째는 비즈니스 요구사항 분석하고

두 번째는 Fact 테이블 식별해 내고

세 번째는 Dimension의 복잡한 릴레이션쉽을 파악하는 것


어떤 데이터 요구사항이 있는가? 

    고객, 상품, 지리적 위치, 시간 (일, 월, 년, 주) 등과 같은 Dimension으로 주문수량과 주문금액을 리포팅하는 요구

필요한 Fact, Measure, Dimension은 어떤 것인가? 

    주문 정보를 기반으로 한 Fact 테이블(주문아이템에 관해 주문금액, 주문수량 존재 ) 예상함.

    Dimension : 고객, 상품, 지리적 위치, 시간 (일, 월, 년, 주)을 설정


그러기 위해서 어플리케이션 데이터모델과 전사 데이터모델을 재 검토하여 적용할 수 있는 유형의 패턴을

먼저 설계하고 이를 바탕으로 스타스키마 설계하기로 함.


아래와 같은 데이터 모델을 생성함. 

" 스타스키마 설계 전 데이터 모델링 "

DW 스타스키마 설계 1.png

위 부분을 스타스키마 접근법으로 설계한 모델은 아래와 같다.

DW 스타스키마 설계 2.png


결국 모델 9-6은 스타스키마를 생성하기 전에 데이터의 성격을 이해하기 위한 디딤돌로 볼 수 있다.

스타스키마 설계는 하나의 FACT 테이블과 다수의 DIMENSION 테이블로 구성된 별 형태 구조이다.

스타 스키마 설계는 데이터 분석과 리포팅을 비교적 단순하고 빠르게 수행하는 어플리케이션을 위한 매우 일반적이고 유용한 기술이다.


“ 장점 ”

1. 스타스키마 개발 전에 데이터모델 개발을 위한 패턴을 사용함으로써 데이터 성격을 더 잘 파악.

2. 일관성있는 방법을 활용하여 Dimension 설계 가능

3. 데이터를 더 잘 이해할 수 있다.


“ 약점 ”

1. 실제 데이터의 릴레이션쉽을 모두 표현하지 못한다.

2. 일부는 스타스키마 개발 전에 데이터모델 개발은 불필요한 부가적 단계라고 생각한다.

3. 스타스키마는 많은 이점이 있지만 약간의 단점도 있다. 일단 생성하면 수정이 어렵다. 즉 새로운 분류를

추가하거나 새로운 역할을 추가한다면 이 모델은 Dimension테이블에 새로운 속성을 추가해야하고 추출

(Extract), 변환(Transform), 적재(Load) 과정을 반드시 거처야 한다.



스타스키마 참고자료: 강연2.ppt