데이터 모델링2 - 데이터 이해하기

업무를 이해한다는 것과 업무 데이터를 이해하는 것의 차이

어떤 회사의 구매 업무를 데이터 모델링한다고 가정해보자. 회사의 여러 부서에 필요한 상품,솔루션,소프트웨어 등을 구매하는 구매팀의 주요 업무 처리 절차인 메가 프로세스(mega process)는 다음과 같다.

1. 다른 팀으로부터 상품 구매를 의뢰받는다.
2. 구매팀의 상품 유형별 담당자가 상품을 판매하는 회사, 가격등에 대한 시장조사를 수행한다.
3. 후보 회사들과 협상이나 입찰을 통해 최종 구매 회사, 상품, 가격을 결정하거나,기업간 B2B 웹사이트에서 직접 주문하기도 한다.
4. 선정된 구매 건을 품의한다. 구매를 요청한 팀에도 이를 통보한다.
5. 품의 완결 후 업체와 구매 계약을 맺고 계약금을 지급한다.
6. 상품을 납품받으면 잔금을 지급하고 구매를 요청한 팀에 해당 상품을 전달한다.

일반적으로 업무를 파악하고 이해하다는 것은 앞의 메가 프로세스와 같이 단위 업무의 시작과  끝을 일의 경로나 공정을 중심으로 알아간다는 뜻이다.

 

반면 데이터 관점으로 업무를 이해한다는 것, 즉 업무 데이터를 이해한다는 것은 이와 조금 다른 얘기다.  예를 들어 상품 구매를 의뢰 받거나 구매품의 내용을 의뢰한팀에 통보하는 과정이 오프라인으로 처리될 수도 있다. 그렇다면 구매 요청과 통보는 데이터 관점에서는 구매 행위와 직접 관련이 없으므로 관심 대상에서 제외할 수 있다. 후보 회사들과의 협상이나 시장조사 과정에서 발생하는 데이터를 정보시스템 으로 관리할 필요가 없다면 이들을 관심밖으로 밀어낼 수 있다.

 

그렇다면 데이터 관점에서 무엇이 주요 관심 대상이 되어야 하는가?  누가 언제, 어떤 상품을 어느 회사로 얼마에 구매했는냐는 비지니스 행위이다. 이를 위해 같은 상품을 구매팀의 서로 다른 담당자가 여러번 구매할수 있는지, 하루에도 여러 번 구매가 가능한지, 여러 상품을 묶어서 한 번에 주문할 수 있는지, 특정 상품을 구매하기 위해서는 반드시 선주문을 하거나 함께 구매해야하는 다름 상품이 있는지 등의 업무 규칙을 명확히 해야한다. 즉 겉으로 드러나는 업무 처리 방법이나 공정과는 분리해서, 그 안에서 데이터가 어떻게 발생하고 흐르는지, 데이터 사이의 선행관계와 같은 종속성 규칙을 관찰하고 읽어내야한다. 

 

업무 데이터의 이해
업무 데이터를 이해한다는 것은 기업의 비지니스를 데이터 측면에서 처음부터 끝까지 조명해보는 것이다. 즉, 업무 프로세스나 프로세스 지원 시스템의 기능과는 완전히 분리해서 생각해야한다.

 

구매요청 - 구매행위  직접관련 여부

구매 요청과 구매 행위가 직접 관련되어 있는지 판단하는 기준은 무엇일까? 예를 들어 구매를 요청한 부서를 언제든지 확인할 수 있어야 한다는 업무 요건이 있다고 가정해 보자 그래서 해당 정보를 관리해야 한다면 직접 관련되었다고 본다.

 

그림 2-1 업무 데이터를 이해한다는 것

그림 2-1

데이터 모델링1 게시물의 자동차 동호회 예시에서 A동호회의 운영자인 K가 차를 두 대 이상 소유한 회원들을  위해 회원 정보와 소유 차량 정보를 별도의 표로 분리한 이유 생각해보자. 회원 개인 정보표가 회원 명부라는 관점보다 회원의 차량 정보를 우선시하는 것, 다시 말해 표의 한 row를 차지하는 정보의 관리 단위가 회원이 소유한 차량의 대 수가 되는 상황을 피하려고 했다. 여기서 정보의 관리 단위라는 것은 엔티티 개체와 맞닿아 있는 굉장히 중요한 개념이다.

 

---

상품 주문 데이터 이해하기

데이터 모델링을 할경우 전체 맥락을 이해하지 못 한 채 특정 부분만을 읽고 다이어그램으로 그려낸다면 오히려 그 특정 영역에대한 해석조차 잘못 되기 쉽다. 이를 명심하고 다음 구매팀 상품주문 예에서 데이터 구조가 형성되는 과정을 살펴보자

고객과 상품 사이에는 주문이라는 관계가 있다. 한 고객이 여러 상품을 주문 할 수 있고, 하나의 상품을 여러 고객이 주문할 수 있는 다대다 M:N 관계이다. 이를 관계형 데이터베이스로 구현하기 위해 M:N관계를 해소(resolve)하면 주문이라는 관계 엔티티로 만들어진다. 그리고 주문과 상품은 여전히 다대다 관계이므로, 이것 역시 풀어주면 고객, 주문, 주문상품, 상품이라는 엔티티가 도출된다.

 

그림 2-2 고객과 상품을 주문이라는 관계로 연결한 모습

그림 2-3 고객과 상품 사이의 M:N 관계를 해소한 모습

'고객이 특정 상품을 평생 단 한 번만 구매할 수 있다'하는 요건이 있다면 구매는 고객과 상품의 관계 엔티티로 볼 수 있다. 즉, 구매는 고객이라는 아빠와 상품이라는 엄마 사이에 태어난 자식인 셈이다. 하지만 실제 현실세계에서는  인터넷 쇼핑몰에서 한번 구매했던 상품을 다시 구매하지 못하는 곳은 없다. 그러니까 앞선 전제는 현실적이지 않다. 고객이  상품을 여러번 살 수 있도록 하려면 시간 이라는 개며이 하나 더 관계 되어야 한다.

 

주문을 고객과 상품의 단편적인 관계로 보면 주문이라는 데이터는 고객과 상품에 종속되므로, 주문의 키값은 <고객번호>와<상품번호>여야한다. 하지만 동일한 고객이 1시간 후에 같은 상품을 다시 주문한다면 어떻게 될까?<고객번호>와<상품번호>만 으로는 이전 주문과 구별할 수 없으니 <주문일시>와 같은 시각 정보나 <주문일련번호>와 같은 인조 식별자(Artificial Identifier)를 추가할 수 밖에 없다. 이는 주문이 고객과 상품의 관계 엔티티가 아니라 시간이 개입되어야 하는 트랜잭션임을 반증하는 것이다.

 

💡tip) 트랜잭션이란?

트랙잭션(transaction)이란 데이터베이스의 상태를 변화시키기 위해  수행하는 논리적 단위이다. 데이터베이스의 상태를 변화시킨다는 말은 SELECT,INSERT,UPDATE,DELETE등과 같은 조작어를 사용하는 행동을 의미한다. 이런 트랜잭션은 상황에 따라 여러개가 만들어 질 수 있고, 그 각각의 트랜잭션들은 상황에 따라 commit(저장)되거나 rollback(철회)될 수 있다.

1.  트랙잭션은 데이터베이스 시스템에서 병행제어 및 회복 작업 시 처리되는 작업의 놀리적 단위이다.
2. 사용자가 시스템에 대한 서비스 요구 시 시스템이 응잡하기 위한 상태 변화 과정의 작업이다.
3. 하나의 트랜잭션은 commit되거나 rollback된다.

트랜잭션 4가지 특징 원자성(atomicity), 일관성(constency), 격리성(isolation), 지속성(durability)을 따서 ACID라고 한다.

 

그림 2-4 상품은 주문 트랜잭션의 참조 정보일 뿐이다.

 

 

시각 정보를 주문의 식별자로 추가하는 순상 상품번호는 식별자로 필요 없는 속성(슈퍼식별자)가 되어버리기 때문이다. 정리 하자면 주문 A를 주문 B와 구분해주는 식별자는 고객과 시각이다. 누가와 언제라는 정보가 절대적으로 중요하며 어떤 상품인지는 주문 트랜잭션을 식별하는데 직접적인 영향이 없다. 상품은 주문이라는 트랜잭션의 참조 정보일 뿐이다.

 

주문은 상품보다는 오히려 주문 시각이라는 시간 개면이 절대적으로 개입되는  고객 행위로 보아야 한다. 이 처럼 비지니스 행위, 즉 트랜잭션에는 반드시 시간의 개념이 개입되며, 이는 행위 엔티티의 시별자에 타임스탬프와 같은 시각 속성이 존잰하는것에서 확인할 수 있다.

 

💡tip) 행위와 관계 구분
물론 행위와 관계를 구분하기 모호한 지점도 있다. 혹은 행위를 관계의 범주 중 하나로 이해할 수도 있다. 중요한 점은 행위와 관계의 구분이 대상을 이해하는데 도움이 된다는 것이다. 데이터가 만들어지는 과정에서 의미상 주어를 명확히 식별한다는 것에 가치가 있다. 더불어 행위를 정확히 알아야만 행위와 그 주변 엔티티와의 관계를 어떻게 맺을지 명확히 파악할 수 있다.

 

출처 - 프로젝트의 성패를 결정짓는 데이터 모델링 이야기 , 김상래 저