DATOR


모델링 빠름신공 #3 모델링패턴 #4 20:80 데이터모델


제한된 기간내에 데이터 모델링을 마무리 하기 위한 "빠름신공"은 납기준수품질의 두마리 토끼를 모두 잡을 수 있는 실전 방법들에 대한 경험을 정리해 보는 시간을 갖는데 의미가 있다.  프로젝트 일정에 쫒겨서 데이터 모델 설계를 대충 대충하여 주어진 일량을 땜방 하자는 의도가 아님을 밝혀 둔다. 

이번에는 다양한 모델링에 대한 패턴을 학습해두는 방법과 매우 많은 테이블을 분석하고 설계할 때 무엇에 집중해야 하는지에 대한 기법을 살펴 보기로 한다.


#3 모델링패턴

소프트웨어 용어 중에서 "디자인패턴" 이라는 것이 있다. 디자인 패턴은, 프로그램 개발에서 자주 나타나는 과제를 해결하기 위한 방법 중 하나로, 과거의 소프트웨어 개발 과정에서 발견된 설계의 노하우를 축적하여 이름을 붙여, 이후에 재이용하기 좋은 형태로 특정의 규약을 묶어서 정리한 것이다. 알고리즘 같이 프로그램 코드로 바로 변환될 수 있는 형태는 아니지만, 특정한 상황에서 구조적인 문제를 해결하는 방식을 설명해 준다.(위키백과에서 인용)

오래전 JAVA 프로그램을 공부할 때 'Design Patterns"라는 책을 본 적이 있다.  데이터 모델의 세계에서도 이와 유사한 패턴들이 존재하는데 많은 경험과 다양한 분야를 접해본 모델러들은 무의식적으로 이러한 패턴에 의지하여 그림 그리듯 쓱쓱 ERD를 설계 하게 된다.

 

1) Copy and Paste
컴퓨터를 사용하면서 가장 많이 사용하는 기능이 Ctrl + C, Ctrl + V를 이용한 복사, 붙여넣기인 것 같다. 프로그램을 작성하거나 SQL을 작성할 때 기존에 작성된 것들을 그대로 재 사용하는 방법이다. 엔티티나 속성을 설계 할때도 다른 시스템에 적용된 유사한 것 들을 모방하여 빠르게 작성하곤 한다. 어느 정도 모델링의 내공이 쌓이게 되면 전체적인 구조를 설계시 타 모델을 참조하지 않고서 처음부터 그리는 것이 더 빠를 수도 있다.  동일한 여러 속성들을 배치하거나 나열할때는 속성의 복사기능을 사용하면 표준화 측면에서 볼때 일관성 있는 모델을 작성할 수 있을 것이다.

 

2) 다양한 모델을 정리하고 기억해 둔다.
동일한 데이터를 관리하기 데이터 모델의 최종적인 모습은 매우 다양하다.  하지만 데이터 모델에도 몇가지 패턴이 있다. 몇가지 패턴들을 나열해 보면
- 테이블의 통합과 분리
- 컬럼의 통합과 분리
- 이력관리 방법
- 주소관리 방법
- 마스터 개체 집합 관리
- 다양한 속성 관리방법 (메타형태)
- 게시판 형태관리
- 관계형, 매핑형태 테이블 관리 등

- 시스템, 메뉴 관리
데이터 모델링때마다 발견되는 다양한 패턴들을 정리 및 이해하려고 노력한다. (정리한다는 것이 참 힘든 일인것 같다)

 

3) 여러가지 대안을 만들어 보는 습관
중요하거나 이슈가 있는 범위의 테이블을 설계할 때 1안, 2안, 3안을 만들어 두는 습관을 들인다. 이렇게 할까? 저렇게 할까? 매번 프로젝트때마다 고민하게 되는데 여러가지 대안 중에서 최선의 것을 선택하도록 한다.  모델러의 생각과 현업/개발자의 생각이 일치하는 것이 아니기 때문에 여러 대안 중에서 하나를 선택하는 과정은 매우 중요한 순간이 된다.  이렇게 선택된 모델은 향후 프로젝트를 진행하면서 이슈사항이 나오더라도 슬기롭게 피해갈 수 있는 상황을 만들어 주곤 한다.


#4 20:80  중요한 것에 몰두한다.


중대형 시스템은 보통 수백 ~ 수천개의 테이블들이 존재한다. 수 많은 테이블들을 리버스 모델링을 통하여 분석하다 보면 어디서 부터 손을 대야 할지 몰라서 갈팡질팡 할 때가 있다. 일반적인 프로젝트에서는 분석 기간을 많이 주지 않는다.  1년짜리 프로젝트라면 대개 2달 내외로 분석기간을 할당한다(경험). 이 짧은 기간내에 모든 테이블과 속성의 쓰임새를 분석하는 것은 사실상 불가능 한 일이다. 그러면 어느 범위까지를 조사하면 분석을 완료 했다고 볼 수 있을까?
개인적으로 분석기간에는 다음이 정리되면 분석완료라고 정리한다.
- 테이블/컬럼의 사용여부 파악
- 테이블/컬럼의 한글화 여부 (엔티티명, 속성명) : 한글화 하는 것이지 표준화를 진행하는 것이 아니다.
- 중요 테이블의 구성과 역할에 대한 정의
- 중요 속성에 대한 정의 (번호도메인, 코드도메인 후보가 되는 속성들)
- 영역별로 ERD를 작성하면서 주요 관계를 표현

 

1) 핵심 테이블에 초기 시간과 정열 투입
시스템마다 주요한 Key가 되는 테이블들이 존재한다. 1000개 정도 되는 테이블이 존재한다고 하면 100개 정도의 테이블을 중요테이블로 선정하고 초반에 집중적인 분석을 해야 한다. 나머지 것들은 사용여부, 한글화 정도만 파악되더라고 분석을 마무리 할 수 있을 것이다.
이러한 핵심 테이블들은 어떻게 찾아야 하는가?
- 시스템 담당자에게 핵심 테이블을 선정해 달라고 요청한다.(성의있는 답변을 너무 기대하지는 말자.)
- 데이터 프로파일링을 실시한 후 데이터 건수를 보고 짐작할 수 있다.
- 리버스 후 ERD를 작성하다 보면 상위 테이블들이 저절로 나타 날 것이다. (PK가 인조키로만 된 시스템은 좀 난해 할 수 있다.)
 
2) 10개의 테이블을 잡아라
중요한 핵심 테이블 중에서도 10개 정도의 테이블은 해당 시스템에서 매우 중요한 테이블들 일 것이다. 주로 고객, 상품, 제품, 계정, 장비, 사용자, 위치, 거래, 이벤트 마스터 테이블들일 것이다. 이들 테이블들의 속성을 가장 먼저 상세히 분석해 두도록 한다. 왜냐하면 이곳에서 사용하는 속성들이 다른 990개의 테이블에서 중복적으로 사용할 가능성이 많기 때문이다.  또한 10개 정도의 테이블이 분석되면 대상 시스템에서 다루고 있는 데이터와 비즈니스 상황을 어느정도 빠르게 이해 할 수 있다.
 
3) 큰틀을 파악하기
리버스를 통한 시스템 분석시 가장 경계해야 할 것은 특정 테이블의 특정 데이터에 너무 목매지 말아야 한다. 시스템 마다 독특한 형태의 테이블 구조로 설계된 것들이 있다.  이런 테이블에는 데이터도 요상하게 정의되어 있다.  상황에 따라 이런 테이블을 깊게 분석함으로써 전체 구조를 이해하는데 도움이 될 수도 있으나, 복잡한 형태의 테이블들에 너무 집착하게 되면 분석 일정을 따라 잡을 수가 없을 것이다. 얼마나 깊게 분석할 것인가를 항상 염두에 두어야 한다.  핵심 테이블 위주로 큰 틀을 파악하기 위해서는 과감하게 그 외 테이블 분석을 생략해야 할 때도 있다.


 

* 따뜻한 데이터 세상 만들기 - FROM 핫신 *
Tag :

Leave Comments