3장 스탠더드 데이터 모델의 이해를 위한 선결 요건
3.1 엔터티 통합의 이해
3.1.1 엔터티 통합의 진정한 의미
결합될 요소들이 다양하지만 동질성이 지속적으로 유지될 수 있도록 체계적이고 명확한 기준을 가지고 유기적으로 결합되어야 한다.
데이터 통합으로 인해 비록 단위 엔터티 내의 개체 수는 증가하게 되겠지만 그들은 반드시 동일한 규칙을 준수해야 하므로 업무규칙은 훨씬 단순해진다.
3.1.2 통합 엔터티의 독립성
유연성을 위한 일반화시킨 동질성에 따른 통합은 각 집합의 고유한 특성(독립성) 훼손되지 않도록 해야 한다. 공통속성은 Supertype으로 고유속성은 Subtype으로 분리하여 관리하면 된다.
3.1.3 통합 엔터티의 정의 원칙
다양한 종류의 집합을 모두 수용해야 하기 때문에 집합의 동질성을 추상적으로 표현하여 '일반화'를 시킬 수밖에 없다. 그러나 일반화는 다양한 형태의 집합을 수용하기 위한 의도일 뿐, 통합 엔터티의 정의를 모호하게 해도 된다는 것이 아니다.
명확한 집합의 유형을 최대한 많이 찾아내서, 부분집합을 많이 도출할수록 엔터터의 집합은 명확해진다.
3.2 관계 통합의 이해
3.2.1 관계 통합의 진정한 의미
- 엔터티 통합으로 발생한 관계 통합 : 엔터티 통합의 목적은 유연성 향상과 확장성 증대이다. 관계 또한 통합을 통해 유연성을 향상시켜야 엔터티 통합의 효과를 극대화 시킬 수 있다.
- 배타적 관계를 이용한 적극적 관계 통합 : 행위의 주체들은 이질성을 갖더라도 그들이 행하는 행위들은 공통적일 수 있다. 또한 동일한 의미의 행위가 분리되어 있다면 데이터 활용 시에도 여러 엔터티를 취합해야 하므로 복잡성이 증가한다.
- 엔터티가 통합되면 통합되기전 기존 엔터티의 관계역시 통합이 수반될 수 밖에 없다.
3.2.2 직렬식과 병렬식 관계의 비교
엔터티간의 다중관계는 병렬식(하나의 row에 여러 관계로 구성)관계 보다는 직렬식(하나의 row가 하나의 관계로 구성)관계로 설계하는 것이 유연성과 확장성, 성능에 유리하다.
추가적으로 자신의 고유속성과 자식 엔터티를 가질 수 있어 업무 변화에 유연하게 대응할 수 있다.
혼합식 관계는 기본적으로 모든 관계를 직렬식으로 통합하고, 업무조건이 고정되어 있거나 중요한 소수의 관계들만 병렬식으로 중복시켜 관리하는 방법이다.
3.2.3 순환구조의 관계 통합
- 1:M 순환관계 엔터티
- M:M 릴레이션 엔터티
동질성있는 파편화된 엔터티들을 위와 같은 통합 구조의 엔터티로 관리하자.
(2025.08.07)
3.3 속성 통합의 이해
3.3.1 속성 통합의 진정한 의미
3.3.2 속성 통합과 분리의 결정기준
3.3.3 속성 통합의 새로운 표현법
(2025.08.19)
3.4 통합 모델의 기본형
3.4.1 기본형의 구성
- 기본 엔터티 : 주제영역의 메인 엔터티로 가장 기본적인 개체가 들어 있는 집합, 다양한 서브타입이 다계층으로 구성
- 내부관게 엔터티 : 기본 엔터티 내의 다양한 서브타입들간의 다양한 형태의 관계를 통합한 M:M 구조의 관계 엔터티
- 프로파일 엔터티 : 기본 엔터티에 모두 담을 수 없는 댜양한 사양(상세)정보를 관리하는 자식 엔터티
- 외부관계 엔터티 : 타 주제영역과의 관계를 통한 새로운 개념의 집합을 관리하는 엔터티
- 단순 관계 : 4의 경우처럼 별도 관계 엔터티가 필요 없는 단순한 참조 관계
3.4.2 표준 모델이 높은 유연성을 가지는 이유
3.4.3 기본형의 적용 유형
상세 프로파일 정보는 관리할 속성이 전혀 달라 통합이 거의 불가능하다.
비록 상세 정보는 별도로 관리하더라도 본질적인 개체들이 기본 엔터티에 통합되어 있기 때문에 내·외부 관계들의 통합이 가능해지고 분류의 체계화를 얻을 수 있다.
일반적으로 행위의 주체나 대상, 자원은 자신의 내부정보의 관리보다 더 중요한 것이 실제 업무의 행위를 관리하는 엔터티의 역할이다.
주역을 담당하고 있기 때문에 자신이 복잡해져 있으면 모든 행위의 관리도 복잡해진다.
모든 행위의 주역이 되는 핵심 주제영역만 동일한 개념의 기본형으로 체계화 한다면 단지 내부적 구성만 다를 뿐 어떤 업종이라도 유사한 형태의 데이터 모델을 가질 수 있다.
(2025.08.28)
3.5 데이터 모델에 대한 편견과 오해의 해소
3.5.1 통합과 명확성의 상관관계
명확성은 얼마나 쉽게 자기 집합을 식별할 수 있는가를 의미한다.
통합이란 동일한 의미를 가진 개체들의 모임인데, 너무 지나친 통합은 동질성의 훼손으로 집합이 모호해 질 수 있다. 즉 명확성이 나빠진다. 그러나 각 집합을 서브타입으로 뚜렸하게 구분한다면 명확성은 훼손되지 않는다.
즉 집합의 경계선만 분명히 한다면 비록 이질적인 집합이 모여있더라도 명확성을 지킬 수 있다.
단위 집합의 명확성은 반드시 독립적으로 존재해야만 얻을 수 있는 것은 아니다. 오히로 통합된 집합에서 명확성을 이끌어 내는 것이 집합을 이해하는데 더 유리하다.
중요한 엔터티일수록 다른 많은 엔터티와 관계를 맺을수 밖에 없다. 주요 엔터티가 복잡하면 하위는 더 복잡해진다. 최선은 외형을 통합하여 단순화 시키고 내부를 철처히 체계화하여 집합을 명확히하는 것이다.
아무리 통합을 하더라도 내부적 체계화만 철저히 한다면 명확성은 결코 훼손되지 않는다. 주요 엔터티의 내부의 부분집합을 정밀하게 표현하기 위해 노력을 기울여야 한다.
3.5.2 통합과 독립성의 상관관계
엔터티 통합으로 동질성이 있는 집합이 다양한 서브타입으로 정의 되었다고 해서 각 서브타입의 독립성이 훼손되지는 않는다. 여전히 서브타입은 고유의 속성과 서브타입내의 식별자를 가질수 있고, 다른 서브타입간에도 관계를 가질 수 있다.
3.5.3 모델링은 누가해도 유사하다?
전략성이 요구되는 모델링은 매우 사고적인 영역이어서 경험이나 기능성이 유사하다고 해서 결과 까지 유사해진다는 보장이 없는 분야이다.
3.5.4 데이터 모델은 업무규칙에 종속적이다?
특정 업무를 처리하기 위한 설계를 하지말고, 전사적 차원에서 엔터티의 후보를 도출하고 집합의 명확한 정의를 통해 엔터티의 형태를 결정하는 등 데이터 본질을 규명하는 방식으로 접근해가야 한다.
즉, 데이터 모델은 업무에 무관할 수는 없지만 결코 종속적이어서는 안된다.
(2025.08.31)
3.5.5 표준은 현실세계를 모두 반영할 수는 없다?
3.5.6 업종의 특성이 표준에 미치는 영향
비즈니스 도메인별 구조적 유사성(엔터티의 개념이나 역할이 비슷하다는 의미다.)
- 통신업무, 카드업무, 게임포탈 : 가입계약에 의해 생성된 서비스 계정이 별도로 존재하는 청구 계정과 하나 이상의 연관을 맺고 있는 계정구조
- 은행업, 보험업, 증권업 : 계약(계좌)에 의해 생성되는 서비스 계정이 청구 계정의 역학을 동시에 담당하는 계정구조
- 교육서비스업, 벙원업, 인터넷 쇼핑몰 : 고객 계정이 서비스 계정과 청구 계정의 역할까지 담당하는 구조
3.5.7 물리모델 전환에 대한 편견의 해소
(2025.09.01)
4장 핵심 스탠더드 데이터 모델의 상세
4.1 전사관계자 영역의 상세
같은 행위 개체를 여러 행위 주체 엔터티에 중복되어 관리되어서는 안되고, 하나의 통합된 행위 주체 집합에서 유일하게 관리되어야 한다.
4.1.1 전사관계자 영역에 대한 개요
물리적 개체들을 먼저 정의하고, 이들로 부터 논리적 개체집단을 만들수 있다.
물리적 개체는 다른 개체의 도움없이 생성될 수 있는 독립적이고 창조적(자생적) 개체이다.
⌞ 상위의 논리적 개체 : 다수의 물리적 개체가 하나의 논리적 묶음으로 논리적 집단이 될 수 있다.
⌞ 하위의 논리적 개체 : 하나의 물리적 개체가 여러 역할을 수행하는 논리적 개체가 될 수 있다.
(2025.09.02)
4.1.2 전사관계자 영역의 서브타입
4.1.2.1 사람관계자(Person Party)의 상세
가장 분명한 물리적 개체이므로 반드시 유일하게 정의해야 하며, 행위와 무관하여야 한다. 또한 모든 행위의 주체가 되는 사람들을 통합해 관리해야 한다.
모든 행위의 주체들이 포함되어 있다는 가정이 깨지면 동일한 개체가 여러 곳에 다르게 정의되어 있던 과거의 시스템으로 되돌아가게 된다.
불분명한 개체를 담아서는 안되고, 식별가능한 최소한의 자격을 갖춘 데이터만이 관리 대상이어야 한다.
4.1.2.2 조직관계자(Organization Party)의 상세
사람관계자와 마찬가지로 분명한 물리적 개체이므로 반드시 유일하게 정의해야 하고, 행위와 무관해야 한다. 또한 모든 행위의 주체가 되는 모든 조직들을 관리해야 한다.
모든 행위의 주체들이 포함되어 있다는 가정이 깨지면 동일한 개체가 여러 곳에 다르게 정의되어 있던 과거의 시스템으로 되돌아가게 된다.
4.1.2.3 그룹관계자(Group Party)의 상세
물리적 개체인 사람관계자와 조직관계자를 필요에 따라 결합한 상위의 논리적 개체를 정의한 영역이다.
예) 상담원그룹, 직책, 세대, 창구, 권한그룹
4.1.2.4 역할관계자(Role Party)의 상세
물리적 개체를 역할에 따라 좀 더 세분화시킨 하위의 논리적 개체를 관리하는 영역이다. (=관계형 관리자(Relation Party))
전사관계자는 모든 종류의 개체등을 포함하고 있기 때문에 그들 간에는 필연적으로 다양한 관계를 가질 수밖에 없다. 또한 모든 유형의 관계를 가지기 위해서는 반드시 M:M관계로 정의 되어야 한다. (=전사관계자 관계(Party Relationship))
전사관계자 관계엔터티로 관리되는 논리적 집합은 관계임에 분명하지만 맡은 역할에 따라 책임과 의무가 따르고, 그 역할이 하는 행위의 주체가 될 수 있으므로 각각 별개의 개체로 관리되어야 한다.
이러한 역할개체는 반드시 전사관계자에 등록이 되어야하고, 그 출신이 원래 '관계'였기 때문에 명칭이 '관계형 관리자'라 한다.
업무담당자
비공유고객
(2025.09.10)
4.1.2.5 비배타적 서브타입(Inclusive Subtype)
표현에 오해의 소지가 있다 중복 서브타입을 의미하는 것이 아니다. (중복 서브타입은 같은 레벨에 대한 중복을 의미한다. 예) 종목레벨에서 야구선수 이면서 축구선수)
전사관계자 구분(Party Type) 속성은 배타적 서브타입 구분자이지만,
비배타적 서브타입(다른 레벨에 대한 중복을 의미한다. 예) 남녀구분과 기혼여부, 남자이면서 기혼)은 하나의 개체에 대한 다중 선택 분류(속성)를 표현한 것이다.
즉 하나의 개체가 여려 비배타적 서브타입 속성을 가질 수 있고, 개체들을 특정 집합별로 분류할 수 있는 방법을 제공한다.
개체가 속하는 분류 관리를 목적으로 한다면, 1정규화해서 '전사관계자 분류'엔터티를 도출하는 것이 나을 것 같다.
큰 의미는 모르겠다.
4.1.2.6 전사관계자의 업종별 사례 연구
(2025.09.12)
4.2 상품/서비스(Product or Service) 영역의 상세
4.2.1 상품/서비스 영역에 대한 새로운 이해
4.2.1.1 기존 상품/서비스 관리 방식의 문제점
코드정의형 상품관리는 새로운 상품 개체를 생성할때 상품의 개체단위를 정의하는 명확한 기준을 가지고 있지 않다.
상품을 결정하는 본질식별자(누가 + 무엇을 + 언제 + 어디서)를 정확히 정의하지 않았다면 그 개체단위가 불분명해진다.
4.2.1.2 상품/서비스 개념의 재정립
4.2.1.3 고객 맞춤형 상품/서비스의 개념
4.2.2 상품/서비스 영역의 기본형 상세
4.2.2.1 상품/서비스 영역의 기본형
4.2.2.2 상품/서비스의 관계 정의
4.2.3 상품/서비스 영역의 응용형
4.2.3.1 판매상품과 기능상품의 개념
기능상품 : 순수한 기능적 특성과 서비스를 제공하는 기본형 상품
판매상품 : 판매를 목적으로 기능상품들 혹은 다른 판매상품들을 다양한 형태로 결합해서 만든 일종의 논리적 상품
상품관계/가격정책 : 이 엔터티는 판매상품에 구성된 기능상품의 구성내역을 관리하고 있다. 판매상품의 가격은 상품관계 엔터티의 상품구성별 가격들을 근거로 책정된다.
기능상품과 판매상품이 거의 유사한 형태라면 하나의 엔터티로 통합하는 것이 유리하겠으나,
소수의 기능상품으로 다양한 형태의 판매상품을 가지고 있는 경우나 상품의 변동성이 크다면 분리하는 것이 좋다.
4.2.3.2 보험형 상품/서비스 모델
4.2.3.3 기타 업종별 상품/서비스 모델 사례
4.3 계정(Account) 영역의 상세
4.3.1 고객 계정(Customer Account) 영역의 상세
4.3.1.1 고객 계정의 개념 정립
고객계정 = 고객(전산관계자) + 계정(서비스계정)
'전사관계자' 개체가 업무적 목적을 위해서 필요한 '분신'을 만든 것이라 할 수 있다.
즉 물리적 개체를 필요에 따라 세분화된 분신으로 만든 것이 고객계정이다.
⌞하나의 물리적 고객이 여러 논리적 회원계정을 가지는 구조
이러한 개체가 특정 업무 분야가 아닌 전사적 관점에서 행위의 주체가 될 수 있다면 전사 관계자 소속이어야 하고,
특정 업무 영역을 처리하기 위해서 필요한 개체들이라면 고객 계정으로 분리되는 것이 맞다.
4.3.1.2 고객 계정의 개체단위 결정
고객 계정의 개체단위를 결정하는 요소는 업무적 판단이 개입될 수 밖에 없다.
이 판단의 주된 기준은 기존의 개체를 그대로 사용할 것인지 아니면 새로운 개체로 인정할 것인지에 대한 것이다.
일반적인 경우는 고객 계정이 있으면 하위에 서비스 계정과 청구 계정을 거느릴 수 있다. 그러나 항상 그런 것은 아니다.
단순한 구조의 계정을 가지는 업무의 경우에는 고객 계정이 서비스 계정과 때로는 청구 계정의 역할까지도 포함할 수 있다.
(2025.09.26)
4.3.2 서비스 계정(Service Account)과 청구 계정(Billing Account)
4.3.2.1 서비스 계정의 상세한 개념
실질적 주체인 전사관계자가 업무를 수행하기 위한 해당업무의 '행위의 주체'를 말한다.
계약과 같은 일종의 행위에 의해 생성되지만 수행하는 역할은 전사관계자의 특정 영역별 분신이다. 즉 본질적으로는 전사관계자에 가깝다.
은행 : 수신계좌, 여신계좌
보험회사 : 계약(보험증권), 보상
대학의 입학영역 : 수험번호, 학사관리 : 학번 단위
제조업 : 주문오더, 작업지시서
4.3.2.2 청구 계정의 상세한 개념 정립
요금의 계산이나 청구/수납/미납 행위의 주체가 되는 계정을 말한다.
서비스를 제공 받았으면 반드시 그 대가를 지불해야 하고, 그 수행 역할은 반드시 존재해야 한다. 하지만 꼭 별도의 청구 계정이 생성되어 그 역할을 해야하는 것은 아니다. 서비스 계정이 청구 계정역할을 포함하여 수행할 수도 있다.
하나의 청구 계정은 여러개의 서비스 계정의 사용료를 책임질 수 있다.
청구 계정을 만드는 것은 단지 청구서를 통합하고 미수납을 일원화하기 위한 목적이 아니다. 각종 할인나 감면 혜택, 체납에 대한 불이익까지 이 단위로 관리하겠다는 것을 의미한다.
청구 계정은 서비스 계정처럼 어떤 계약에 의해서 뚜렷한 개체단위가 생성되는 것이 아니라 서비스 계정을 논리적으로 묶어주는 형태의 논리적 집합이라는 특징이 있다.
4.3.2.3 서비스 계정과 청구 계정의 연관성
서비스 계정과 청구 계정의 관계는 Static한 구조를 가져갈것이 아니라,
분납이 발생할 수 있거나 비번한 청구 계정의 변경이 발생할 소지가 있으므로 M:M구조가 유연하겠다.
물론 하나의 청구 계정(1)이 여러 서비스 계정(M)을 가지는 구조가 단순하긴하다.
서비스 계정과 청구 계정의 관계구조 사례
- 고속도로 휴계소의 Food Court 과거의 식당별 결제 및 서비스 제공이 현재는 일원화된 결제(식권구매) 후 각 식당별 매뉴(서비스)제공으로 변경.
- 카페의 경우 키오스크를 통해서 주문(청구)를 받고, 음료(서비스)를 1:1로 제공.
- 카드사의 경우 여러 개의 카드(서비스)를 발급하고 이들을 묶어서 한번에 결제(청구)하고 있다.
4.3.2.4 ACCOUNT 모델의 표준형
카드 계약이 발생하면 발급되는 카드는 하나 이지만, 카드를 분실후 재발급을 반복한다면 실제 발급카드는 여러개가 생성 될 수 있다.
서비스 계정의 개체 간에 계층이 존재하는 형태를 '다계층 Account'라 한다.
통합청구는 청구 계정별로 작성한 청구서를 동봉하는 단위로 사용되는 개체일뿐 청구액 계산이나 수납은 청구계정 단위여야 한다.
4.3.2.5 ACCOUNT의 다계층 구조와 GROUP
전사관계자에서 기본적은 물리적 개체를 기반으로 상위 혹은 하위 논리적 개체를 정의 했듯이, 서비스 계정에서도 동일하게 기본적인 개체를 정의하고 이를 기반으로 상/하위의 논리적 개체를 정의할 수 있다.
은행의 여신업무도 여신계좌가 먼저 있어야 하고, 대출이 발생할 때마다 상환일이나 이자 등이 다르므로 당연히 별도의 개체로 관리되어야 하는 '다계층 Account'이다.
080전화번호는 여러개의 실질적 전화번호를 묶은 가상의 전화번호이다.
Account Group : 계정에 있는 개체를 다양한 목적으로 묶은 집합으로 계정 성격이면 계정영역에 포함이 되어야 하지만 그렇지 않다면 별도의 엔터티로 관리 되어야 한다.
(2025.10.02)
4.3.3 ACCOUNT 모델의 사례 연구
4.3.3.1 대학의 ACCOUNT 모델
4.3.3.2 온라인 게임 ACCOUNT 모델
4.3.3.3 이동통신 ACCOUNT 모델
4.3.3.4 은행업무 ACCOUNT 모델
4.3.3.5 보험업무 ACCOUNT 모델
(2025.10.06)