제2부 스탠더드 데이터 모델의 개요

1장 스탠더드 데이터 모델의 등장 배경

1.1 기존 데이터 모델에서 발생하는 일반적인 문제점

1.1.1 데이터 모델에 대한 기존의 인식

정보시스템 분야에 종사하는 대부분의 사람들은 프로그래머로 시작하기 때문에 머릿속에는 온통 업무처리 과정과 이를 응용 프로그램에 어떻게 구현할 것인가에 주로 관심이 쏠려있다.
그들에게 중요한건 프로세스이지 데이터가 아니다. 그래서 잘못된 데이터 구조의 문제로 인한 근본적은 문제에 관심이 없다.

1.1.2 구조적 측면에서 바라 본 문제점

전사적 차원에서의 데이터의 설계와 관리를 하지 않고 업무담당자가 자의적으로 설계와 관리를 했기 때문에 매우 복잡한 데이터 구조를 가지게 되었다.
게다가 각 모듈의 개발자가 자신만의 전용 테이블을 함부로 만들고 사용하니 전혀 불만을 느끼지 않는다.
이렇게 전사적 관점에서 미래의 업무변화에 대한 유연성과 확정성을 고려하지 못한 구조는 갈수록 시스템이 복잡해지게 하는 원인이 된다.

1.1.3 관리적 측면에서 바라 본 문제점

체계적인 문서하나 제대로 없고, 평면도 수준의 ERD로 관리되고 있으니 ERD를 볼 이유도 없고, 정밀하게 관리할 이유도 없는 것이 현실이다.
설계자에게 필요한 진정한 의미의 논리모델을 보유한 기업이 전무하다.

(2024.12.15)

 

1.2 문제해결의 대안으로서의 스탠더드 모델

1.2.1 스탠더드 모델이 가진 의미

1.2.2 스탠더드 데이터 모델의 적용 효과

 

2장 스탠더드 데이터 모델의 기본 개념

2.1 데이터 모델의 본질에 대한 개괄적 고찰

2.2 물리적 개체와 논리적 개체에 대한 이해

2.2.1 물리적 개체와 논리적 개체의 개념비교

물리적 계체 : 보이거나 만질 수 있어 존재를 구체적으로 확인할 수 있는 개체
논리적 계체 : 보거나 만질 수는 없지만 개념적으로는 분명히 존재하는 개체, 물직적 계체없이 스스로 발생할 수 없다.

2.2.2 논리적 개체의 진정한 의미와 역할

데이터 모델이란 업무상의 형상을 집합적으로 표현해 둔 것이기 때문에 논리적 개체가 나타나는 건 당연하다.
업무 프로세스는 물리적 개체로 활동하지만 데이터는 프로세스가 아니라 집합이므로 논리적 개체가 존재할 수 밖에 없다.

2.2.3 논리적 개체의 유형별 사례

(2025.01.29)

 

2.3 스탠더드 데이터 모델의 골격

2.3.1 스탠더드 데이터 모델의 개관(槪觀)

2.3.2 전사관계자(Involved Party) 영역의 개요

어떤 행위를 할 수 있는 자격이 있는 개체들로 행위와는 무관한 절대(대부분 물리적) 개체를 말한다. 따라서 업종에 영향을 받지않고 관리하는 속성이 대부분 동일하다.

2.3.3 상품/서비스(Product or Service) 영역의 개요

다양한 업종만큼 다양한 상품과 서비스가 있으므로 이를 통합하여 유연성을 확보해야 한다. 이것을 '종류의 집합'과 이들 간의 연결성을 관리하는 '관계의 집합'으로 구성된 BOM구조로 관리할 수 있다.
제조업의 부품, 일부 부품을 조립한 중간부픔이 존재하듯 서비스업에서도 단위서비스와 단위서버스를 묶은 상품(서비스)이 존재할 수 있다. 따라서 업종간의 관리방식은 차이는 없다.

2.3.4 계정(Account) 영역의 개요

수많은 서비스 행위들을 동일한 성격으로 묶을 수 있는 단위로 '서비스를 제공해야 할 대상 개체'를 말한다.
일반적으로 계약(contract)행위를 통해 이러한 개체(account, 실질적 행위주체)가 탄생된다. 이 개체는 행위의 결과라기 보다는 앞으로 발생할 행위의 직접적인 '주체 역할'을 하게 된다.
'카드발급'행위 → '카드계정'
'통장개설'행위 → '계좌계정'
'전화가입'행위 → '가입계정'

  • 고객계정 : 전사관계자가 물리적 개체를 관리한다면, 고객계정은 논리적 개체로서 회원가입을 통한 회원계정 혹은 사용자 계정 등이 있다. 하나의 물리개체가 논리적 회원으로 여러계정을 가질 수 있다.
  • 서비스계정 : 업무적 행위의 직접적인 주체, 서비스를 제공 받을 대상
  • 청구계정 : 서비스 계정을 청구 단위용으로 결합한 계정으로 금전적인 관리의 단위이므로 책임과 권리의 단위이기도 하다.

(2025.01.31)

2.3.5 서비스 약정(Service Agreement) 영역의 개요

2.3.6 가격정책(Price Policy, Price Plan) 영역의 개요

2.3.7 청구/입금(Charge & Payment) 영역의 개요

2.3.8 미납관리(Collection) 영역의 개요

청구계정하위에 미납관리를 위한 미납계정이 있어야 한다.
계정을 만드는 이유는 일련의 행위들을 의미 있는 동일한 성격으로 관리하고자 함이다. 미납이 발생한 청구단위별로 각각의 미납을 관리할 수도 있지만
한번 연체가 발생한 고객은 다음에도 연체가 발생할 가능성이 높으며, 변제를 하더라도 일부만 할 가능성이 높기때문에 청구단위별로 관리하는 것은 매우 복잡해 질 수 있다.

(2025.03.03)

2.3.9 통합 자원(Resource) 영역의 개요

2.3.10 오더관리(Order Management) 영역의 개요

오더가 계정인 이유는 이로 인해 발생하게 되는 많은 행위들이 오더를 중심으로 동일한 성격으로 관리되어야 하기 때문이다.
오더는 '처리행위를 발생시키는 주체이며 약속된 서비스를 받을 대상'이다.

  • 구매 오더 : 업무상 필요한 자재나 물품, 서비스 등을 거래처로부터 구매하고자 할 때 발생하는 오더
    ⌞ 제안요청
    ⌞ 견적
    ⌞ 선정
    ⌞ 입고
    ⌞ 검사・저장

  • 수주 오더 : 자사의 상품/서비스를 구입하는 고객의 주문에 대한 오더, 상황에 따라 제조 오더, 구매 오더, 출하 지시, 선적 오더 등의 다른 오더를 발생시키기도 한다.
    ⌞ 생산 스케줄링 및 납기확정
    ⌞ 출하
    ⌞ 배송
    ⌞ 대금결재
    ⌞ 견적서・신용장(L/C) 개설
    ⌞ 송장(Invoice)
    ⌞ 선하증권(B/L)

  • 진료 오더 : 환자가 병원에서 진료를 받을 때 발생하는 오더
    ⌞ 처방전달시스템(OCS, Order Communication System)

  • 서비스 요청(S/R, Service Request) : 주로 고객센터를 통해 발생하는 고객 불만사항의 접수나 서비스 가입, 해지, 변경에 대한 요청, 수리나 교환 등에 대한 요청을 말한다.
    ⌞ 세부적인 활동 오더(Activity Order)

  • 거래 오더 :  예적금의 입출금은 반드시 서비스 계정(계좌)가 존재해야하는 거래행위이나, 송금이나 환전은 계좌를 가지고 있지 않아도 가능한 '행위' 혹은 '오더'로 볼 수 있다.

  • 대여/대출 오더 : 제공하는 상품/서비스의 형태가 다를 뿐 개념적으로는 차이가 없다.
    ⌞ 대여 : 대여료 정산, 사용 관련 정보, 고장이나 기타 문제 발생 정보, 서비스 가능 정보 등 많은 관련 정보들을 관리해야 하므로 개념적으로 계정으로 보는 것이 타당하다.
    ⌞ 대출 : 서비스 계정인 '여신용 계좌'가 먼저 생성되어야 가능하고 해당 대출 건을 기준으로 이자율이나 상환기일 등을 관리하기 때문에 계정의 개념이 분명하다.

  • 이동(배송, Movement Order) 오더 : 공간을 차지하는 물건을 특정 목적지로 옮기는데 필요한 제반 행위를 동일한 성격으로 관리하는 단위이다. 하나의 이동 오더가 여러 대상물을 처리하거나 반대로 하나의 대상이 여러 번에 걸쳐 이동 오더를 발생 시킬 수 있다. (M:M관계)
    ⌞ 이동 수단(자원)
    ⌞ 담당자
    ⌞ 일정 계획
    ⌞ 입출고
    ⌞ 검사
    ⌞ 인벤토리

  • 출하지시(Shipping Order) : 수주 오더나 이동 오더로 인해 발생하는 오더이다. 경우에 따라서 이동 오더와 같은 개념일 수 있다. 상위 계정과 M:M 관계
    ⌞ 출고
    ⌞ 적재
    ⌞ 이송

  • 작업지시(Work Order) : 넓은 의미로 보면 이동 오더나 출하지시를 모두 포함하는 포괄적인 의미의 오더이다. 상품/서비스를 위한 자원의 설치나 철거 작업지시, 고장수리나 교환을 위한 출동 작업지시
    ⌞ 작업처리내용의 관리
    ⌞ 소요된 자재나 인건비의 정산/청구
    ⌞ 사후관리

 

이러한 형태의 오더는 단지 고객(전사관계자)이나 고객계정이 수행한 행위라는 관점이 아니라

하위의 다양한 처리행위를 발생시키고, 이를 관리하기 위한 상세한 정보(다양한 자식 엔터티가 필요)의 기준이 되는 단위. 즉 계정으로 관리 되어야 한다.

(2025.03.10)

2.3.11 인벤토리(Inventory) 영역의 개요

관리해야할 모든 상품과 자원들이 어디에 존재하고 있고, 어디로 이동했는지를 관리하는 영역이다.

개체단위가 커서 개체마다 관리하여도 비용과 식별의 문제가 발생하지 않는다면 개체별로 관리하는 것이 좋겠지만,
대부분의 업종에서는 개체별로 독립적인 관리를 하는 것이 지나친 비용이 들고, 업무 진행상 식별이 불가능한 경우가 많기 때문에 개체별 관리를 하지 않는 경우가 많다.

저장소의 이동간 수량은 비교적 일정하게 유지할 수 있으나, 개체의 단가는 평가된 시점과 방법에 따라 수시로 달라질 수 있다.

2.3.12 업무처리(Business Action) 영역의 개요

(2025.07.16)