메뉴 건너뛰기

bysql.net

06 상태: 데이터의 상태

2013.04.16 02:22

운영자 조회 수:6348

상태:데이터의 상태

기업의 IT 시스템이 확장되면서, 상태(status)를 표현하고 관리하는 구조의 필요성이 증가하고 있다.  비즈니스 프로세스에 의해 데이터가 처리되는 과정에서 상당수의 상태가 다양한 방법으로 생성되고, 수정되고, 삭제된다.

 

상태 : 사물, 현상이 놓여있는 모양이나 형편(일이 되어가는 경로 또는 결과)

                                      DImgQfZ5DyDGk0pAg6mWDndyBO24nnJ0rkUBsDVU


업무 영역별 전문가와 인터뷰할 때 데이터 전문가가 겪는 매우 공통적인 문제는 다양한 트랜잭션이나 이벤트 발생 시의 다양한 상태들을 파악하고 이해하기 어렵다는 것이다.

  • 운영 담당자 = '주문 접수', ' 주문 완료'

  • 재무부서 = '지불', '미지불'

이들은 전체 라이프사이클 중 단지 작은 부분만을 본다. 그래서 데이터 전문가에게 주문의 상태는 지금까지 언급한 상태 모두 이지만 주문처리의 전체 라이프사이클로 보면 일부분 이다.


데이터 모델링을 하면서 기존의 데이터베이스 설계를 검토하다 보면 많은 컬럼들이 일자와 일시 이고 그 중의 대다수가 상태를 표현하고 있음을 발견하게 된다.  매우 공통적이고 중요한 데이터를 일관성 있게 관리하는 것이 큰 이점이 있다는 것을 고려하지 않고, 기업 내에서 이런 데이터들을 일관성 없게 모델링하고 있다는 사실이다. 6장에서는 일관성 있는 방식으로 상태 데이터를 모델링하는 방법을 다룰 것이다.


1. 이 패턴이 왜 중요한가?

  • 엔티티가 수용할 수 있는 상태에는 어떤것이 있는가?

  • 특정 엔티티의 과거는 어떤 상태였고, 현재는 어떤 상태인가?

  • 상태를 표현하는 데 필요한 구체적인 시간 데이터에는 어떤 것이 있는가?


2. 이 장의 내용

 

  • 이 장에서는 먼저 상태가 어떤 것인지 정의하고, 기업이 일관된 방법으로 상태를 모델링하기 위한 데이터 모델링 패턴의 다양한 레벨을 설명하는데 각각의 패턴은 상태의 세가지 기본 관점을 제공 한다.

       *특정 엔티티의 발생 가능한 상태 목록

       *그 엔티티의 현재 상태는 어떤 것인가?

        (동시에 여러 상태들이 있다면 그 엔티티의 현재 상태는 어떤것인가?)

       *언제 그 상태가 유효하고, 변경되고, 중지되는가?


가장 구체적인 방법(레벨 1 상태 패턴) 에서 시작하여 매우 일반화된 패턴(레벨 4 상태 패턴)으로 진행된다.

'상태 카테고리 패턴', '다중 롤업 및 룰을 갖는 상태 유형 패턴'의 두 패턴은 레벨 2, 레벨 3, 레벨 4 패턴을 향상 시키기 위해 5장(분류)과 4장(재귀) 패턴을 가져와 활용하였다.

 

  • 상태 카테고리 패턴은 다양한 집합으로 상태를 분류 엔티티가 여러 개의 상태 집합을 갖도록 지원한다.

  • 다중 롤업 및 룰을 갖는 상태 유형 패턴은 상태들의 어떻게 서로 관련될 수 있는지에 대한 규칙을 관리하고자 하는 요구사항을 지원한다.

  • 상태는 데이터가 준수해야 하는 몇 가지 법적 조건을 나타낼 수 있다. (ex. 금융계좌의 '지급중지' 같은 부분)

  • 상태 유형은 다양한 분류로 그룹핑될 수 있다.  (ex. 계좌 = '요청', '등록', '개설' 과 같은 '계좌 개설'의 유형)

  • 엔티티의 인스턴스는 하나의 분류에서 하나 이상의 상태 유형을 가질 수 있다. (ex. 계좌의 개설에서 계좌등록관리자에게는 계좌 개설은 '등록'이 되고 , 계좌관리자에게는 '개설' 상태가 된다.)

  • 하나의 상태 분류에서 다양한 상태 유형들은 그 상태들 간의 동작을 통제하는 규칙을 가질 수 있다.

  • 어떤 상태들은 아무 데서나 직접적으로 모델링되어서는 안되고 반드시 파생되어야만 한다.

 

3. 상태란 무엇인가?


 상태 패턴은 아래 내용을 관리한다.
  • 데이터가 가질 수 있는 허용 가능한 상태 들.

  • 엔티티에 적용되는 상태

  • 상태의 시간관점

  • 상태 유형의 분류

  • 다양한 상태 유형 간에 존재하는 규칙  

 

4. 레벨 1 상태 패턴

레벨 1 상태 패턴을 사용하여 매우 구체적인 방식으로 모델링될 수 있다.

  • 엔티티의 '이벤트' 속성을 사용하여 각각의 상태를 관리한다.

  • 기본적인 상태 패턴은 데이터가 전체 라이프사이클에 걸쳐 가질 수 있는 모든 상태의 목록을 지원해야 한다.

             Jr_PiZYGeDE7tI5ADACkGXFkXrghx-P_9TDnz9Jm

레벨 1 상태 패턴의 3가지의 중요 특성

 

  • 첫째, 허용 가능한 상태들은 잠재적인 속성으로 기록된다.

  • 둘째, 엔티티는 속성 값을 갱신하는 것으로 상태를 기록한다.

  • 셋째, 상태는 관련된 시간이나 기간을 가질 수 있다.


4-1. 이 패턴이 필요한 이유는?


레벨 1 상태 패턴의 목적은 매우 단순하고, 명확하고, 이해하기 쉬운 모델을 만들기 위한 엔티티의 모든 상태들을 '이벤트' 속성으로 명확하게 관리하는 것이다. 또한 이 패턴은 상태가 활성화되면 일자를 표현한다.


4-2. 이 패턴은 어떻게 작동하는가?


8FaXzXZPILc0HLgoO5LSKQiqVtlM-8315bme8Swm

ENTITY의 기본 상태를 관리하기 위해 속성들이 어떻게 사용되는지 보여준다.


codnip7O0DYUhtXpAHEGgP99lKOJH00dqpBVdTUM
레벨 1 상태 패턴 활용 사례

 

RcTjXZ_r8BJ4B17DEz7dRDL-rGxIZUIVhbpRnO-Q

레벨 1 상태 패턴 활용 사례


4-3. 이패턴은 언제 사용하는가?

 

  • 잘 정의된 고정적이며 구체적인 상태 집합이 있을 때, 그리고 새로운 상태들이 추가가 예상되지 않을때

  • 상태의 개수가 매우 적을 때

  • 어떤 상태가 특정 엔티티에만 구체적으로 관련되어 있다면, 엔티티의 속성으로 표현할 수 있다.

  • 데이터 전문가가 비전문가나 관리자를 위해 기본 업무 기술서의 일부분으로 비즈니스 데이터 요구사항을 나타내는 간단한 방법을 원할때

  • 다양한 관점을 보여주고 표현하는 것이 중요할 때


4-4. 이 패턴의 약점은?

 

  • 이 패턴은 시간이 경과함에 따라 새로운 상태 유형이 발생하는, 변화가 많은 환경에는 적절하지 않다.

  • 엔티티에 많은 개수의 상태가 있을 때 이 패턴을 사용하면 상태를 일관성 있게 관리하는 것을 어렵게 만들 수 있다.

  • 이 패턴은 상태의 분류를 제공하지 않는다.

  • 이 패턴은 상태에 관한 규칙을 관리하지 않는다.

 

4-5. 이 패턴의 요약

레벨 1 상태 패턴은 언제 상태가 발생했고 언제 발생 예정인지를 관리하는 것뿐만 아니라. 특정한 엔티티가 가질수 있는 상태들을 '이벤트' 속성으로 관리하는, 매우 구체적인 방법이라 할수 있다. 이 패턴에서는 각각의 속성 값은 다양한 시점에 설정될 수 있다. 또한 상태를 일자 이벤트 속성으로 표현하며 별도의 상태 속성을 중복하여 표현하지 않는다는 것에 주목해야 한다. 이벤트가 발생하는 것을 표현하는 지시자를 두고 그 후에 이벤트가 발생한 시점을 기록하기 위한 일자시간 속성을 두는 것 대신에, 이벤트가 발생한 것과 발생한 시간을 한 개의 속성으로 표현하여 관리한다.

 

5. 레벨 2 상태 패턴, 현재 상태

기업이 엔티티의 현재 상태에만 관심을 갖는 경우와 엔티티가 단지 하나의 상태만을 갖는 경우가 있다. 단지 현재 상태만을 표현할 필요가 있다면 레벨 2 상태 패턴, 현재 상태를 사용한다. 이 패턴은 데이터 전문가가 구체적인 현재 상태 패턴 솔루션을 만들고자 하는 경우에, 유연한 전략을 제공한다.

5-1. 이 패턴이 필요한 이유는?

이 패턴은 시간이 경과함에 따라 추가적으로 유효한 상태가 발생할 수도 있는 기업에게 필요한 패턴이다.


 

5-2. 이패턴은 어떻게 작동하는가?


Z8-QQ6jtenorXVIpShnA6cb_3arRUzru7xUPjGro

  • 첫 번째, 기업의 다양한 상태유형을 단일 엔티티인 상태 타입으로 통합할수 있다. 이것은 하나의 엔티티에서 모든 상태유형 데이터를 관리함으로써 모델을 단순화 하는데 효과가 있다.

  • 두 번째, 엔티티 상태 타입이 상태 타입 엔티티의 서브입으로 생성되어있다. 서브 타입을 사용하는 것은 특정한 엔티티에만 사용 가능한 상태들을 그룹핑하기 위해서이다.


Lgd4sdBKhtwcOoVt1WeSV2ADWBrR4xhiIAWKCqLF

레벨 2 상태 패턴, 현재 상태 활용 사례


5kmQY__0W33Bjx9lALK31tYOArJyrI2SrbDh7q5p

5-3. 이패턴은 언제 사용하는가?

 

  • 엔티티에 오직 하나의 상태 만을 표현할 필요가 있을 때

  • 엔티티의 상태 이력을 표현 하는 것에 초점을 두지 않을 때

  • 향후 발생할 수 있는 새로운 상태 유형을 제공할 필요가 있을 때

 

5-4. 이 패턴의 약점은?

 

  • 이 패턴은 엔티티가 오직 하나의 현재 상태를 가질 수 있고 이전 상태들은 현재 상태로 덮어쓰인다는 규칙이 적용된다.

  • 주문 오픈과 같이 오직 하나의 현재 상태를 가질 때, 이것은 기업 전반에 걸쳐 서로 다른 해석을 초래할 수 있다. 그리고 기업의 다양한 부서에서 다양한 상태를 기록할 수 없다.

  • 이 패턴은 엔티티가 가지고 있는 다양한 상태를 시각적으로 나타내는 데 레벨 1만큼 효과적이지는 않다.

 

5-5. 이 패턴의 요약

이 패턴은 모든 상태 유형을 STATUS TYPE으로 일반화 함으로써 엔티티의 모든 상태를 표현한다. 상태 유형이 특정 속성으로서가 아닌 STATUS TYPE 엔티티의 인스턴스로 표현되기 떄문에 변경을 쉽게 수용할 수 있다.  

 

6. 레벨 3 상태 패턴

6-1. 이 패턴이 필요한 이유는?

유연성은 모델링의 중요한 고려 사항이다. 기업이 특정 비즈니스 영역과 관련된 모든 상태를 표현할 필요가 있으나 현재 표혀ㅑㄴ하고 있는 상태가 무엇인지 확신할 수 없다고 가정할 때 이 패턴은 다양한 상태의 이력을 표현하고 엔티티가 하나 이상의 상태를 동시에 갖는 것을 허용한다.

 

6-2. 이 패턴은 어떻게 작동하는가?


ESOdFyuAobJsxMtV0-gvC664rueJ0JPj2-VQDeyd

이 패턴은 ENTITY 가 하나 이상의 상태를 갖는 것을 가정한다.


 

  • ENTITY가 모든 상태를 표현할 수 있어야 한다.

  • ENTITY와 STATUS TYPE 간의 다대다 릴레이션쉽은 ENTITY STATUS 엔티티를 추가 함으로써 해소된다.

  • ENTITY는 하나 또는 그 이상의 ENTITY STATUS 에 있을 수 있다.

  • ENTITY STATUS 는 오직 하나의 STATUS TYPE 으로 분류될 수 있다.

  • status datetime 특정 시점에 발생하는 상태를 입력한다.

  • status from date와 status thru date 일자 범위를 요구하는 상태를 입력한다.


6QSgFOSTDqaIqnfrUefMHqw1GJT4gfv6GcZDQC7T

레벨 3 상태 패턴 활용 사례


dClynatyHGrccRvGXLAvVc4Hnc0QybaslesSBtZu

6-3. 이 패턴은 언제 사용하는가?

  • 유연한 솔루션이 필요할 때

  • 분석 대상 주제 영역의 상태들이 잘 정의되지 않았거나 알려지지 않았을 때

  • 기업이 상태 유형을 더 쉽게 관리하기 위해 모든 상태의 통합을 원할 때

6-4. 이 패턴의 약점은?

  • 이 패턴은 특정한 비즈니스 룰을 표현하지 못한다.

  • 이 패턴은 특정한 상태 유형이 특정 속성이나 릴레이션쉽을 갖는 경우를 수용하지 않는다.

  • 이 패턴은 더 추상적이고 이해하기 어렵다

6-5. 이 패턴의 요약

이 패턴은 엔티티가 동시에 혹은 시간이 경과함에 따라 많은 상태들을 가질 수 있다는 점에서 의미가 있다. 레벨 3 상태 패턴은 ENTITY와 STATUS TYPE 으로 표현되는 다양한 상태들간의 릴레이션쉽을 관리함으로써 이 이슈를 해결한다 이 다대다 릴레이션쉽은 ENTITY의 현재 상태들과 이력 상태들을 관리하는 연관 엔티티 ENTITY STATUS를 통해서 해소된다. 이 패턴은 상태를 관리하기 위해 일관성 있고 유연한 모델을 원하는 대부분의 기업에 사용할 수 있다. 새로운 상태 유형이 발견되면 데이터 모델의 변경 없이 STATUS TYPE에 추가할 수 있다. 그리고 각 ENTITY는 얼마든지 많은 상태를 가질 수 있을 뿐만 아니라 여러 시점에 걸쳐 여러번 기록된 동일한 상태들도 가질 수 있다.



7. 레벨 4 상태 패턴
 
 레벨 4 상태 패턴은 이장의 이전 패턴들보다 훨씬 더 유연하다. 우리는 이것을 '플러그 앤드 플레이' 유형 패턴이라고 부른다. 이것은 이 패턴을 사용하면 상태를 관리할 필요가 있는  ENTITY는 새로운 엔티티 혹은 속성을 별도로 추가하지 않고도, 이 구조 안으로 ENTITY 자신을 연결하면 된다는 것이다. 

7-1. 이 패턴이 필요한 이유는?
 
 매우 변화가 많은 데이터 환경을 가진 기업과 상태 데이터를 관리하는 데 모듈형 접근과 같은 표준을 갖고자 하는 기업에게 매우 유용하다. 

7-2. 이 패턴은 어떻게 작동하는가?

j761lKOXu8tTzJCRsERgC7Pr_43pXLi_VpzHIWdO
레벨 4 상태 패턴

_ZSz7qQH9zEi1jHCPldsLpAaBy2uKGttNfMpUjRD
레벨 4 상태 패턴 활용 사례

pOBXtO0T4zMUFILXC_mT-Rv3_Ci1vimrUrkNi9Fp
레벨 4 상태 패턴 활용 사례, ORDER

7w1G3BPz_ffbPhkHILmfEjW0e3IDJnkt1PfIo_JR
배송 이행 상태 다이어그램

O1UYe15Zwza3sBy3tgIQHxK4VJkQg42b7SdcsApw
레벨 4 상태 패턴 활용 사례, SHIPMENT

62SR6fwJkuoVbVws7I86wEcgRUm3X6SQf5Ph2s5A
작업활동 go/no go 상태 다이어 그램

kNrAgO5iHcaEam80SKEzrkiZGIX5z0GIksh3j6gj
레벨 4 상태 패턴 활용 사례, WORK EFFORT

7-3. 이 패턴은 언제 사용하는가?
  • 기업이 데이터모델 변경을 훨씬 쉽게 수용하는 매우 유연한 데이터모델을 만들고자 할때
  • 기업이 객체 관리를 더 쉽게 하기 위해 공통적인 엔티티, 속성, 릴레이션쉽을 전략적으로 통합하고자 할 때.
  • 기업이 데이터 관리를 위해 일관성 있는 접근법을 만들고자 할때, 특히 데이터 중심의 데이터 관리 전략에 집중하기로 한 기업이 상태 정보를 생성하고자 할 때
7-4. 이 패턴의 약점은?
  • 유연성이 많기 때문에 '다양한 기능성'을 수용할 수 있지만 비즈니스 룰을 시행하기는 어렵다.
  • 다양한 유형의 상태들은 실제로 다양한 정보 요건을 가질 수 있다.
  • 매우 일반화된 방법으로 모델링하는 것은 유연하지만 명확성이 떨어지는 것을 감수해야 한다.
  • 두 엔티티에 모든 상태 정보를 통합하는 것은 물리적으로 적절하게 구현되지 않는 경우에는 성능 이슈를 야기할 수 있다.
7-5. 이 패턴의 요약
 
 매우 포괄적인 상태 데이터모델 구조이므로 상태 관리가 필요한 새로운 엔티티를 자동적으로 연결하여 사용할 수 있다. 이 패턴은 새로운 또는 기존의 엔티티를 붙여서 활용할 수 있는 '인터페이스' 엔티티를 사용한다.  상태 타입은 엔티티가 필요로 하는 다양한 상태 유형을 지원한다. 따라서 인터페이스 엔티티에 연결함으로써 어떤 엔티티라도 초기의 요건과 미래의 요건을 처리할 수 있는 포괄적인 데이터구조뿐만 아니라 모든 상태 집합에 접근할 수 있다. 


8. 상태 카테고리 패턴
 
 각 상태는 하나 또는 그이상의 다른 상태와 직접 연결되어 있다. 그리고 모든 상태들은 상태의 그룹에 포함된다. 주문 접수, 주문 등록, 주문 확인, 주문 취소, 주문 완료는 주문 이행 프로세스의 맴버들이다. 그러나 주문이행 프로세스 이외에도 다른 프로세스를 갖는 것이 가능하다. 그래서 상태 카테고리 패턴은 다양한 유형의 상태 카테고리를 표현한다. 

8-1. 이 패턴이 필요한 이유는?
 
 상태 유형이 하나 또는 그 이상의 상태 분류 집합을 갖는 요구사항을 지원한다.

8-2. 이 패턴은 어떻게 작동하는가?


QI28YN9x8vWrK_TNklP7jtNmWh2bxyJH-cEcd9ym



PkCxtVNdOsW_jr2lWOw9gSt7VAQ33H1ZA7xl9xLv7CzfWcfZ8CjOkIQIQ9vJHqgH2dNnTkzTokOI4Ygt


8-3. 이 패턴은 언제 사용하는가?
  • 기업이 레벨 2, 레벨 3, 레벨 4 상태 패턴을 향상 시키고자 할 때, 기업의 다양한 상태 유형과 상태 유형 카테고리를 분류할 필요가 있을 때
  • 엔티티, 프로세스, 워크플로우에 존재하거나 사용되고 있는 다양한 상태 분류들을 리포팅하기 위한 편리한 방법이 필요할 때
  • 기업이 매우 포괄적인 방법으로 상태 데이터를 관리하고자 할 때

8-4. 이 패턴의 약점은?
  • 어떤 유형의 상태 분류가 필요한 지에 관한 구체적인 데이터 요구사항을 효과적으로 표현하지 못한다.
  • 이 패턴은 특정한 STATUS TYPE CATEGORY에 관한 속성 또는 릴레이션쉽을 구체적으로 명시하지 않는다.
8-5. 이 패턴의 요약
 
 이 패턴은 STATUS TYPE이 하나 또는 그 이상의 카테고리 맴버가 될 수 있는 방법을 보여주기 때문에 중요하다. 그리고 상태를 분류하는데 매우 유용하다.
 

833zOjk7Y7dzSXGBdz9NKFOWT9K81xNIX9FnV8TvFXxgob1JIm54arCQIpEZDlIQgHs182ERvLS5a0cElTEQKoANCXp1-ywP6r0X7Fpew4laogZsjYrADTFT

 

  • 데이터 모델 리소스 북 Vol.3  (bysql.net 2013년 1차 스터디)
  • 작성자: 김승회
  • 발표일: 2013년 5월 20일
  • 본문서는 bysql.net 스터디 결과입니다 .본 문서를 인용하실때는 출처를 밝혀주세요. http://www.bysql.net
  • 문서의 잘못된 점이나 질문사항은 본문서에 댓글로 남겨주세요. ^^