① 사용자유형코드 : 사용자 엔터티는 3개의 서브타입으로 구성되어 있다. 크게 직원과 고객, 직원은 다시 정직원과 계약직으로 구성된다.
이화식씨는 엔터티를 키(key), 메인(main), 행위(action) 3가지로 분류하고
김기창씨는 실체, 행위, 가공, 기준 4가지로 분류하는데, 뭐 어떤식으로 분류하든 결국 분류기준은 관리하고자하는 데이터 집합의 성격이다.
보통 현장에서 기간계 시스템(Legacy System)에 I/F 받아오는 마스터라불리우는 데이터가 '키' 혹은 '실체', '기준'엔터티들이다.

혹시 왜 엔터티들을 굳이 분류하느냐라고 생각할 수 있는데... 데이터 성격이 다르다는 것은 관리하는 방식이 달라야하기 때문이기도 하고 또 서로 다른 성격의 데이터 집합를 하나의 엔터티로 잘못 도출하는 경우를 방지하기 위함이다. 이런 분류개념이 없이 설계를 해놓으면 개발자는 프로젝트가 끝날때까지 이 잘못된 table를 조작할때마다 매우 불편함을 느끼면서 설계자의 요구를 힘들어 하고 설계자는 왜 불편해 하는지 이해못한다. 그리고 결국 설계자도, 개발자도 이 불편함의 원인이 무엇인지 프로젝트가 끝나도 모른다. 그리고 다음 프로젝트에서도 반복한다. 이런식의 설계가 제품화된 솔류션에 녹아 있다면 더 문제다. 그리고 진짜 문제는 이런 설계의 기초가 안된 사람들이 누군가의 사수가 되어 가르치고 있다는 것이다. 모를 수는 있지만, 잘못알고 있는것을 재생산하는 우를 스스로 범하고 있는것은 아닌지 되새겨 봐야 한다. 이것이 DA를 공부해야하는 이유 중 하나다.

그리고 무엇인가 불편한데 그 불편함의 시작이 무엇인지 고민되지도 않고 고민하지도 않는다면 설계자로서 자질은 없다고 본다. 물론 본인도 여기에 자유롭지는 못하다. 

아무튼 이런 '실체'엔터티들을 설계할때, 이 집합의 성격을 분석하다보면 부분집합들이 도출되기도 하고 애초에 서로 다르다 생각했던 엔터티들이 그 실체가 규명되고 통합이 되면서 부분집합이 생기게 되는데, 이런 부분집합을 구분하는 속성을 'Subtype 구분자'라 한다.  이런 'Subtype 구분자'는 절대 Null 허용이 될 수 없다. 즉 이도저도 아닌 집합은 있을 수 없다. 만약 기존 Subtype어디에도 속하지 않는 집합이 있다면 실체를 규명하여 새로운 Subtype으로 도출해야 한다. 이런식으로 데이터의 실체를 하나씩 밝혀나가다보면 현업 본인들도 모르고 있던 Business Rule을 알게되거나, 업무상의 규칙성을 찾아내기도 한다. 사실 해보면 잼있다.
예) 제품유형코드, 결제유형코드, 장르코드, 차종코드

② 논리모델의 업무규칙 : 사용자와 주문과의 관계가 표현되어 있는데, '사용자중 고객만이 주문할 수 있다'로 표현되어 있다. 이 규칙이 맞는냐 틀리느냐는 고객의 needs에 따라 달라질 수 있다. 사실 직원들이 주문을 못하게 할 이유는 없어 보인다. 고객과 프로세스의 정의가 필요해보인다.
그런데 여기서 중요한 것은 이 논리모델이 물리모델로 전환되면서 각 서브타입이 개별 Table로 분리되지 않고, 하나의 Table로 가져가기로 결정했다면 사용자와 주문과의 관계는 '모든 사용자가 주문을 할 수 있다'라고 밖에 표현되지 않는다. 즉 논리모델에서 표현된 특정 서브타입과의 관계가 물리모델로 전환되면서 그 업무규칙이 희석되어 버린다는 것이다. 이것이 논리모델이 존재해야하는 이유이다. 물론 모델툴에서 제공하는 각종 메모기능으로 업무규칙을 설명할 수 있으나, 공식 표기법 만큼 명확한건 없다.

현장에서 논리모델과 물리모델을 바라보는 관점은 안타깝다. 단순히 속성명(물리Table의 한글로된 컬럼 코멘트)로 보느냐 컬럼명(물리Table의 영문으로된 컬럼명)으로 보느냐의 차이일 뿐이다. 대부분의 ERD가 이런식의 차이만 있을 뿐 논리모델이 비즈니스룰의 본질을 담고 있어야 한다는 개념이 없다. 이런 잘못된 형태의 ERD만 보다보니 논리모델의 필요성이나 가치가 어디에 있는지 연차가 있는 설계자나 개발자들도 모르는 경우가 대부분이고, 막 업계로 진입한 초심자들은 더 말할 것도 없다.
다시한번더 강조하면 논리모델은 훼손되지 않은 비즈니스룰을 입체적으로 표현하고 있지만 물리모델로 전환시 모델이 float하게 표현되기 때문에 비즈니스룰이 희석될 수 밖에 없다. 그래서 정밀한 논리모델이 필요한 것이다.

위의 셈플모델을 말그대로 단순한 구조여서 경험이 많은 설계자는 논리모델을 생략하고 곧 바로 물리모델을 설계하고 비즈니스룰은 따로 문서화해서 전달할 수도 있겠으나 복잡한 비즈니스룰은 그런식으로 전달한다는 것은 어림도 없다. 그리고 그 무엇보다 데이터 구조로 표현한 것보다 명확한 커뮤니케이션 매개물은 없다.
우리가 어떻게 데이터의 연관관계를 관리할 것인지 목표를 알게 되면 나머지 로직은 지엽적인 부분이 된다. 가고자 하는 목적으로 이해하지 않고 그 지엽적인 부분으로 목적을 이해 시키는 것은 방법도 거꾸로 일뿐만아니라 설명하는데도 에너지를 너무 많이 소비하게 된다. 그렇게 할 이유가 없다.