게시판
      
상위분류 : 잡필방 중위분류 : 서류가방 하위분류 : 전산과 컴퓨터
작성자 : 문시형 작성일 : 2014-01-16 조회수 : 4,530
제 목 : [모델링 빠름 신공 10] #3 모델링 패턴 & #4 20:80
[모델링 빠름 신공 10] #3 모델링 패턴 & #4 20:80
엔코아 신승렬 이사
 
2013년 12월 2일 (월) 15:52:29

 

 


▲ 엔코아 신승렬 이사
 

[아이티데일리] 데이터 모델링 프로젝트 진행 시 가장 중요한 것 중 하나가 제한된 일정 내에 데이터 모델 설계를 완성해야 하는 ‘납기 준수’라고 생각한다.

 

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

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

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

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

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

동일한 데이터를 관리하기 데이터 모델의 최종적인 모습은 매우 다양하다.  하지만 데이터 모델에도 몇 가지 패턴이 있다. 몇 가지 패턴들을 나열해 보면

-테이블의 통합과 분리
-컬럼의 통합과 분리
-이력 관리 방법
-주소 관리 방법
-마스터 개체 집합 관리
-다양한 속성 관리 방법(메타 형태)
-게시판 형태 관리
-관계형, 매핑 형태 테이블 관리 등
- 시스템, 메뉴 관리

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

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

중대형 시스템은 보통 수백 ~ 수천 개의 테이블들이 존재한다. 수 많은 테이블들을 리버스 모델링을 통하여 분석하다 보면 어디서부터 손을 대야 할지 몰라서 갈팡질팡 할 때가 있다. 일반적인 프로젝트에서는 분석 기간을 많이 주지 않는다. 1년짜리 프로젝트라면 대개 2달 내외로 분석 기간을 할당한다(경험). 이 짧은 기간 내에 모든 테이블과 속성의 쓰임새를 분석하는 것은 사실상 불가능한 일이다. 그러면 어느 범위까지를 조사하면 분석을 완료했다고 볼 수 있을까?

개인적으로 분석 기간에는 다음이 정리되면 분석 완료라고 정리한다.

-테이블/컬럼의 사용 여부 파악
-테이블/컬럼의 한글화 여부 (엔티티명, 속성명) : 한글화 하는 것이지 표준화를 진행하는 것이 아니다.
-중요 테이블의 구성과 역할에 대한 정의
-중요 속성에 대한 정의(번호 도메인, 코드 도메인 후보가 되는 속성들)
-영역별로 ERD를 작성하면서 주요 관계를 표현

시스템마다 주요한 Key가 되는 테이블들이 존재한다. 1000개 정도 되는 테이블이 존재한다고 하면 100개 정도의 테이블을 중요 테이블로 선정하고 초반에 집중적인 분석을 해야 한다. 나머지 것들은 사용 여부, 한글화 정도만 파악되더라도 분석을 마무리 할 수 있을 것이다.

이러한 핵심 테이블들은 어떻게 찾아야 하는가?

-시스템 담당자에게 핵심 테이블을 선정해 달라고 요청한다(성의 있는 답변을 너무 기대하지는 말자).
-데이터 프로파일링을 실시한 후 데이터 건수를 보고 짐작할 수 있다.
-리버스 후 ERD를 작성하다 보면 상위 테이블들이 저절로 나타날 것이다. (PK가 인조키로만 된 시스템은 좀 난해 할 수 있다.)

 
중요한 핵심 테이블 중에서도 10개 정도의 테이블은 해당 시스템에서 매우 중요한 테이블들 일 것이다. 주로 고객, 상품, 제품, 계정, 장비, 사용자, 위치, 거래, 이벤트 마스터 테이블들일 것이다. 이들 테이블들의 속성을 가장 먼저 상세히 분석해 두도록 한다. 왜냐하면 이곳에서 사용하는 속성들이 다른 990개의 테이블에서 중복적으로 사용할 가능성이 많기 때문이다.  또한 10개 정도의 테이블이 분석되면 대상 시스템에서 다루고 있는 데이터와 비즈니스 상황을 어느 정도 빠르게 이해할 수 있다.
 
리버스를 통한 시스템 분석 시 가장 경계해야 할 것은 특정 테이블의 특정 데이터에 너무 목매지 말아야 한다. 시스템마다 독특한 형태의 테이블 구조로 설계된 것들이 있다.  이런 테이블에는 데이터도 이상하게 정의되어 있다. 상황에 따라 이런 테이블을 깊게 분석함으로써 전체 구조를 이해하는데 도움이 될 수도 있으나, 복잡한 형태의 테이블들에 너무 집착하게 되면 분석 일정을 따라 잡을 수가 없을 것이다. 얼마나 깊게 분석할 것인가를 항상 염두에 두어야 한다. 핵심 테이블 위주로 큰 틀을 파악하기 위해서는 과감하게 그 외 테이블 분석을 생략해야 할 때도 있다.

| | 목록으로