DATOR


업무 규칙의 표현 업무규칙


업무 규칙을 데이터 모델에 표현해야 한다는 점은 많이 공유되고 있지만, 막상 업무 규칙을 표현해 보라고 하면 제대로 표현하는 사람은 그리 많지 않은 것이 현실이다. 또, 업무 규칙을 어느 정도까지 데이터 모델에 나타내야 하는지에 대해서 결정하기도 쉽지 않다. 사원엔터티에 대해 다음과 같은 업무 규칙을 생각해 보자.

 

1. 사원엔터티의 식별자는 사원번호이다.

2. 사원엔터티의 사원명과 주민등록번호 속성은 NOT NULL이다.

3. 사원엔터티에는 내부사원과 협력사사원이 포함된다.

4. 부서코드 속성에  내부사원인 경우는 소속부서코드를 협력사사원인 경우는 소속협력사코드를 저장한다.  이 때, 협력사사원인 경우는 협력사코드가 NULL이 가능하나 내부사원인 경우 부서코드는 NOT NULL이어야 한다.

5. 사원이 퇴직하더라도 사원엔터티에서 삭제하지 않는다.

6. 퇴직한 사원이 재입사하면 사원번호를 새로 부여하여 새로운 인스턴스를 생성한다.

7. 내부직원만 호봉 속성을 관리한다.

8. 내부사원만 가족정보를 별도의 엔터티로 관리한다.

9. 사원엔터티의  가족수 속성은 해당 사원의 가족엔터티의 인스턴스 건수와 동일하다.

 

모델링 툴마다 업무 규칙을 표현하는 방법이 조금씩 다르겠지만 엔코아의 DataWare DA를 사용하면 다음과 같이 표현할 수 있다.

 

    업무규칙표현erd4.JPG

 

 모델링을 조금이라도 해 본 사람이라면 1,2번은 쉽게 표현할 수 있을 것이다.  그러나 3,7,8번은 서브타입의 개념을 이해해야만 표현이 가능하므로 서브타입의 이해가 선행되어야 한다.

 한편, 4번은 복잡한 표현도 가능한 DataWare DA의 특징이라고 할만한 것이다. 자세히 살펴보면 두 개의 속성에 부서코드[내부사원], 협력사코드[협력사사원]와 같이 대괄호가 표현되고 있는데, 이것은 아래쪽에 있는 협력사사원과 내부사원 서브타입을 가리키는 것으로 사원엔터티의 부서코드 속성은 내부사원인 경우 부서코드를 협력사사원인 경우 협력사코드를 배타적으로 가져오록 표시한 것이다. 자세한 설명은 'Tool의 감상' 카테고리에서 설명하도록 하겠다.

 9번은 가족수 속성 뒤쪽에 '(d)'라는 추출속성표시를 통해 나타낼 수 있다. 이 때 어떤 엔터티에서 어떻게 가족수 값을 가져오느냐에 대한 규칙은 가족수 속성의 정의를 클릭하면 알 수 있으며, 모델의 기호만으로는 이 속성이 추출속성인지만 나타내고 있다.

 

위에 제시된 업무 규칙 중

5. 사원이 퇴직하더라도 사원엔터티에서 삭제하지 않는다.

6. 퇴직한 사원이 재입사하면 사원번호를 새로 부여하여 새로운 인스턴스를 생성한다.

의 두 업무 규칙은 사실 데이터 모델의 기호만으로는 나타내기가 거의 불가능하다. 따라서 엔터티의 설명에 글로써 입력해야 하는데, 단, 6번의 경우 다음과 같이 식별자를 본질식별자와 실질식별자를 구분하여 정의함으로써 표현이 가능하다.

 

본질식별자-실질식별자.JPG

 

위 그림과 같이 주민등록번호와 입사일자를 본질식별자로 정의함으로써 한 명의 사원에 대해 입사일자에 따라 2개 이상의 인스턴스를 생성한다는 의미를 나타내며, 사원번호 속성만이 실질식별자로 지정되어 있음과 같이 해석하면, 주민등록번호가 같더라도 입사일자가 다르면 별도의 사원번호를 생성한다는 업무 규칙을 유추해 낼 수 있다. 사실 이것은 글로 써놓은 것보다 더 명확하게 업무 규칙을 표현하고 있는 것이다.

 

지금까지 간단하게 몇 개의 업무 규칙을 데이터 모델에 표현하는 방법에 대해서 설명하였다. 그러나 실제 업무 규칙은 훨씬 더 복잡한 경우가 많기 때문에 좀 더 생각해 보아야 한다. 다음과 같은 업무 규칙을 생각해 보자.

 

1. 연봉이 4000만원 이하이 이면서 나이가 40세 이상인 사원에게는 체력단련비가 별도로 지급된다.

2. 사우회에 가입한 직원에 한해서 급여의 1%를 상조회비로 급여에서 공제한다.

3. 결혼한 사원만 육아휴직을 신청할 수 있다.

 

위와 같이 매우 상세한 수준의 업무 규칙까지 데이터 모델에 기호로 표현하려면 너무 많은 서브타입을 생성해야 하므로 거의 표현이 불가능하다. 따라서 어느 정도까지의 업무 규칙을 기호로 표현하고, 어느 정도를 글로써 표현할지, 나아가 데이터 모델에는 표현하지 않고 프로그램명세서에만 표현할지를 결정해야 한다. 

 우선 데이터 모델에 표현할 것인지 아니면 프로그램명세에만 표현할 것인지는 프로젝트의 방법론, DA와 AA의 역할분담 등 다양한 현실적인 인자에 영향을 받게 된다. 물론 데이터에 대한 업무 규칙은 모두 데이터 모델에 표현하여 추후 유지보수 단계에서까지 활용하고 업무 규칙의 변경 사항을 계속해서 반영하도록 하는 것이 이상적인 방법이겠지만 현실적인 측면에서 실현하기 어려운 일이므로 적절한 선에서의 타협이 필요한 부분이라 하겠다.

 또, 데이터 모델에 기호로 표현할지 글로써 표현할지는 모델링 툴에 따라 모델러의 선택이 필요한 부분이다. 모델러가 중요하다고 생각하는 업무 규칙은 아무래도 데이터 모델에 기호로 표현하는 것이 좋겠지만 모델링 툴에 따라 표현이 불가능하거나 데이터 모델이 너무 복잡해지는 경우도 발생할 수 있으므로 모델러가 고민해서 결정해야 할 부분이다.

 

TAG

Leave Comments