데이터 모델링20 - Account, 개체 그룹핑 모델링 이해

Account라는 마스터 데이터, 업무 행위의 논리적 주체

그림 9-6 서비스 제공을 위한 개념 모델

[그림 9-6]에서 <청구계정> 엔티티가 없었 다면 어떤 문제가 발생했을까? Account(계정)의 개념을 조금이라도 알고 있는 사람이라면 이미 눈치 챘겠지만, <청구계정>이 없다면 청구 업무가 고객이 계약한 서비스 단위로밖에 이루어질 수 없다.

 

 

그림 10-1 3인가족의 이동통신 서비스 사용 상황

[그림 10-1]과 같이 엄마,아빠, 아들로 구성된 가족은 모두 같은 이동통신사의 서비스를 이용한다고 해보자. 미성년자인 딸은 아빠 명의로 가입되어 있으며 그 요금은 엄마가 낸다.  그리고 엄마는 매월 청구서에 본인이 사용한 서비스와 딸의 서비스 비용을 하나의 청구 단위로 지불할 것을 요청받는다. 즉, 개별 계약 단위가 아닌 계약의 묶음 형태로 청구가 이루어지고 있다. 

 

그런데 만약 <청구계정> 엔티티가 없었다면 이러한 형태의 요금 청구는 불가능 했을 것이다. 서비스별 비용을 묶어서 청구하려면 그것을 묶는 매개체 혹은 단위가 필요한다. 이러한 단위로서 청구 집합이 바로 <청구계정>이다. 따라서 이 엔티티가 누락되었다는 것은 그 단위(매개체) 개체가 존재하지 않는다는 뜻이다. (물론 존재하지 않는 집합을 애플리케이션으로 가공해서 처리할 수는 있지만. 그만큼 애플리케이션이 복잡해진다.)

 

여기까지 이해되었다면 데이터의 발생 단위와 이를 묶는 상위 단위에 대한 감을 얻었으리라 기대한다. 그럼 본격적으로 Account에 대해 알아보자. 우리말로는 흔히 계정이라고 번역되는 Account를 사람들은 어떻게 이해하고 있을까?

 

IT 종사자 4명에게 물어본 Account의 의미

A : 계정? UNIX 서버 계정을 말하는 건가요?

B : 음... 뭐랄까. 산에서 칡을 캘 때 들어 올리면 칡넝쿨이 쭉 올라오잖아요. 그럴 때 여러 뿌리를 달고 있는 제일 위쪽의 줄기 같은 거죠. 뿌리를 데이터라고 생각하면 트랜잭션 데이터를 주렁주렁 매달고 있는 상위 개체 엔티티 같은 거라고 생각합니다.

C : 업무 처리 데이터들을 동일한 범주로 관리할 수 있는 단위라고 생각합니다. 어떤 면에서 Account는 계약(contract)의 이음동의어가 아닌가 싶습니다.

D : Account가 뭔가요? 전 그런거 모르고도 그동안 모델링 잘했습니다.

D의 경우를 보면 아마도 둘 중 하나일 것이다. Account의 개념을 몰라서 골격이 잘못된 데이터 모델을 많이 그려왔거나, Account라는 말은 몰랐지만 이미 그 개념을 가지고 Account에 해당하는 개체 집합을 엔티티로 표현해서 트랜잭션을 정확한 단위로 관리한 경우일 것이다.

 

앞으로 설명하게될 Account는 B와 C의 답변을 조합한 형태에 가깝다. 즉, Account는 '업무 행위의 최상위 주체로, 관련 업무 처리들을 동일한 성격으로 관리하는 단위'다. Account는 또한 '수 많은 행위 데이터를 동일한 성격으로 묶을 수 있는 다위 개체' 일반적으로 계약 행위를 통해 탄생하지만, 관련된 다른 하위 행위의 직접적인 주체 역할을 담당한다.

 

X는 L전자로부터 동일한 노트북 2대를 구입해서 집과 사무실에서 사용하고 있다. 그러던 중 집에 사용하던  노트북에 이상이 생겨 A/S를 받게 되었다. 이때 얼핏 L전자는 X라는 한 사람에게 서비스하는 것 같지만 사실 각 상룸을 구입한 개별 고객에게 서비스하는 것이다. 즉, L전자 입장에서는 '상품을 구매한 고객' 단위로 서비스 대상을 인식한다. L전자는 A/S를 요청하는 사람의 연락처나 주민등록번호보다는 고장난 노트북의 모델명과 일련번호가 일차적 관심대상이다. A/S의 단위가 사람이 아닌 상품이기 때문이다. X역시 A/S 권리는 상품별로 요구하는 것이 맞다. 이것이 Account의 개념이다.

 

일반적으로 [그림 9-6]의 <서비스계약>과 같은 엔티티는 Account를 의미한다. X가 구입한 노트북 상품에 해당하는 계약은 각각 별개의 인스턴스로 <서비스계약>엔티티에 존재해야한다. 그리고 상품별 보증 서비스와 서비스 처리 결과와 같은 기타 트랜잭션 데이터는 해당 <서비스계약> 엔티티의 하위에서 <서비스계약번호> 속성을 식별자로 상속받아 관리해야 한다. 다시 말해 데이터적으로 사람이 아니라 계약단위로 서비스 활동이 이루어짐을 이해해야 한다. 결국 구체적인 업무 행위의 주체는 의인화된 Account인 것이다.

 

행위의 주체라는 것은 행위가 해당 주체에 완전 종속되었음을 의미한다. 그래서 Account를  1)어떤 업무 처리 데이터들을 동일한 범주로 관리할 수 있는 단위며 2)통상적으로 계약에 의해 발생한다'고 정의 할수 있다.

 

 Y가 특정 웹사이트에 111번 회원으로 가입했다가 탈퇴한지 일주일 만에 222번 회원으로 다시 가입했다. 그런데 웹사이트의 현 구조상 111번일 때의 회원 정보를 상속받지 못한다고 한다. 이것이 의미하는 바는 이 시스템에서 사람이라는 물리적 개체의 본질적인 정보(고객)와 xxx번 회원으로서의 역할 정보 (회원)를 분리해서 관리하지 않고 '회원 = 고객'으로 인식해서 구현했다는 것이다. 기존 고객 정보를 상속받고자 한다면 물리 개체로서의 사람과 논리개체로서의 회원을 분리할 필요가 있다. 앞서 Account는 계약이라고 했는데 지금의 경우도 마찬가지다. 웹사이트 가입이라는 일종의 계약을 한 셈이기 때문이다. 

 

다음은 어느 포탈 회원 가입이야기다.  이 포탈에서 개인당 ID를 3개까지만 만들 수 있다. 일종의 제약임 셈이다.ㅏ 그래서 Z는 AAA라는 ID와 BBB라는 ID 2개를 만들었다고 한다. 메일,블로그,카페 활동 등 여기저기서 발생하는 비지니스 데이터는  Z라는 개체가 아닌 Z가 만든 계정에 지배받는다. 즉, 특정 카페에서 Z가 작성한글은 Z라는 사람 개체가 아닌 AAA 혹은 BBB라는 논리적인 계정을 최상위로 해서 발생하는 것이다.

 

논리적으로 분명히 존재하는 최상위 주체인 Account를 발견하지 못해 엔터티로 도출하지 못할 경우 관계선은 이상하게 연결되기 시작하며, 데이터 모델은 스파게티처럼 꼬이게 된다. 업무 데이터를 담으려면 반드시 업무의 주체인 Account가 존재해야 하므로 어쩌면 모델링에서 가장 중요한 골격에 해당한다고 할 수 있다. 시스템에서 Account의 정의가 올바르지 못하면 이후의 업무 데이터는 제 위치를 찾지 못하고 골결은 뒤틀린다.

 

전달하고 싶은 핵심 메시지는 데이터의 올바른 부모찾기다. 업무 행위의 주체를 정확하게 식별하고, 특히 업무 서비스의 최상위에 해당하는 Account를 명확하게 정의하기 위해서는 지금까지 배운 논리를 구체화하고 다양한 실전 경험을 통해 자신만의 안목과 기준을 구축해가는 시간이 필요하다.

 

눈에 잘 보이지 않지만, 개념적으로 분명히 존재하는 집합이자 행위희 주체인 Account라는 마스터 데이터를 발견할 수 있는 시각이 필요하다.

 

💡 tip) 그룹핑하는 상위의 단위 개체 

데이터 개체가 상위 단위에 지배를 받는 경우, 혹은 하위 데이터들을 묶는 개념, 그리고 데이터들을 동일한 성격으로 그룹핑하는 논리적인 개체에 주목해야 한다. 통상 업무 행위의 최상위 주체를 Account라고 하지만, 과의적으로 이러한 상위 단위의 개체들을 모두 Account라고 이해해도 무리는 없다.

 

Account와 같은 상위 개체 집합이 누락될 경우

그림  10-2 <고객>과 <주문내역>

[그림 10-2]는 보통 이숙한 상품 주문을 조금 다르게 표현한 다이어그램이다. <주문내역> 엔티티의 주 식별자를 유심히 관찰해보자. 주 식별자에 <주문번호>뿐 아니라 <주문상품번호>까지 포함되어 있다. 이를 통해 <주문내역>에 포함되는 개체 발생과 관리 단위(정보 단위)는 주문한 상품임을 알 수 있다. 즉, 고객이 3개의 상품을 한번에 주문했더라도 개체 3개가 만들어지는 구조다(표 10-1)

 

표 10-1 한 번에 여러 상품을 주문했을 때의 <주문내역>엔티티의 모습

주문번호	주문상품번호	주문일시	주문배송지주소	고객번호
1000	10	2015.10.10	서울시 영등포구	CS5001
1000	14			CS5001
1000	20			CS5001
1001	14	2015.10.11	강원도 강릉시	CS6000
1001	15			CS6000

더불어 개별 주문 상품을 묶는 단위로서의 주문 개체는 어디에 있는 걸까?(주문이라는 엔티티가 없다) ERD 상으로 주문 개체는 존재하지 않는다. 그런데 <주문내역>의 속성 중 <주문일시>와 <주문배송지주소>는 분명 주문 수준의 정보다. 이들은 더 상위 수준(주문 수준)의 정보인 까닭에 [표 10-1]에서처럼 <주문번호>가 동일한 상품 중 대표 개체 하나에만 이들 정보를 기록해도 정상적인 주문 처리가 가능하다(물론 애플리케이션이 이런 상황을 인지하고 대응해야한다.)

 

주문도 일종의 계약이므로 Account로 인식할 수 있다. 지금의 모델은 주문이라는 Account 없이 주무의 상세 내역만을 관리하는 구조다. 그리고 같은 주문의 첫 상품에만 주문 수준의 속성을 기록함으로써 주문 엔티티 부재에 대응하고 있기는 하나, 어색해 보인다. 마땅히 존재해야 하는 주문이라는 개체 집합이 누락되어 무리가 따르게 된 것이다. 주문의 첫 상품이 주문을 대표하는 개체이기 때문에 주문 취소나 환불등의 프로세스에서 발생하는 다양한 데이터가 첫 상품 데이터와 관계되어야 한다. 현행 모델은 주문 상품이 변경되면 구조적으로 견디기 힘들것이다. 비즈니스를 담기에는 유연성이 부족하다는 의미이다.

 

💡 tip) 계정 성격의 개체 정의
결국 데이터 개체는 올바른 단위에서 정의되고 관리되어야 한다. 그래야 다른 개체 집합과의 관계 역시 올바르게 맺어질 수 있다.

 

이상의 사례는 모델도 간단하고 주문이라는 익숙한 업무를 다루어 금세 문제점을 발견할 수 있었지만, 복잡한 실무에서는 업무 데이터의 발생과 관계파악이 쉽지 않아 논리적인 상위 개체를 적절한 수준에서 정의하지 못하는 경우가 왕왕 발견된다.  그래서 [표 10-1]과 같이 상위에서 관리해야 할 개체가 정의되지 않아 하위 집합에서 상위 집합에서 관리해야하는 데이터를 관리하는 모습을 자주 발견할 수 있다.(이런 상황을 통상적으로 '하위 집합이 상위 집합을 삼켰다'라고 한다.)

 

심지어 업무 담당조차 이런 구조적인 문제점을 인지하지 못하는 경우도 많다. 모델의 골격이 잘못 되면 데이터가 잘못쌓이고, 애플리케이션에 무리가 가며, 향후 비지니스가 변경될 때 유연하게 대응하기 어렵다. 반드시 적당한 수준의 상위 집합을 정의하고 엔티티로 관리하는 것이 바람직하다. [표 10-1]처럼 데이터가 부분적으로 중복되어 쌓이거나, 대표 개체에만 값이 존재하고 다른 개체의 속성에는 NULL이 많다면 구조에 문제가 없는지 의심해봐야 한다. 

 

 

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