전체코드의 부분집합을 관리하는 모델(코드 부분집합 개념을 반영한 모델)
코드유형에 속한 전체코드값 집합중에서 필요한 코드 값만 부분집합으로서 별도 관리 할 수 있는 모델이다. 부분집합으로서 관리가 필요한 코드유형이 생기면 새로운 코드유형으로 등록하고, 코드 값 전체집합을 가리키는 상위코드 유형번호를 지정한다. 그리고 코드 엔터티에는 해당코드유형에 존재하는 코드값을 등록한다.
고객구분코드는 다섯개 값이 존재 (100 -> 01,02,03,04,99) 고객구분코드 개인과 법인만 필요하다고 한다면, 코드유형 릴레이션에 '101' 코드유형을 등록하고 상위코드유형에 '100'으로 등록하고, '101'코드유형에는 '01','03' 코드 인스턴스를 등록한다. 코드유형 릴레이션에서 상위코드유형번호 속성이 null인 것이 전체집합 코드를 의미한다. null이 아니면 부분집합코드이며, 그값은 전체집합코드(상위유형코드)를 나타낸다.
항상 전체집합이 기준이 돼 부분집합을 정의하야 한다. 사용중에 부분지합이 필요하면 그 부분집합에 속할 코드값이 전체집합에 존재하는지를 찾고, 없을때는 전체집합에 먼저 코드 인스턴스를 등록하고 나서 부분집합으로 선택해서 사용해야한다.
부분집합 코드로 사용시 단점
-관리문제
무엇보다 관리가 쉽지 않고, 메타시스템에 이기능을 완전하게 구현하기도 어렵다. 코드는 데이터를 구분하거나 집계하려는 의도에서 사용하기 때문에 사용주체마다 다를 수 있다. 이를 코드명을 기준으로 통합 후 다시 부분으로 사용하려고 하는것은 무의미한 과정일수 있기 때문이다.
-오너십문제
전체집합코드등에 대한 오너십이 있는지 전체집합은 단순히 모집합의 역활만 하는지에 따라 관리하는 방법이 달라진다.
어떤 애플리케이션은 추가될 코드 인스턴스로 인해 그 애플리케이션에 영향을 받으면 안되기 때문에 전체집합코드는 단지 모집합으로 정의하여 사용하고 전체집합코드와 동일하게 정의한 코드유형이 별도로 존재하야 한다.
-코드관리는 파장효과가 매우 크기 때문에 무리하면서까지 통합코드를 구축할 필요가 있는지 통합하면 실익이 있는지를 따져야 한다.
코드값 간 관계를 관리하는 코드모델(코드값 간에 존재하는 계층체계를 관리하는 기능)
-계층체계는 상위계층의 코드만 관리하는 것(재귀관계)과 상하위계층 코드를 관리하는 것(BOM)으로 나눌수 있다.
모델은 각 코드값에 대한 상위코드가 무엇인지를 관리한다. 일대다(1:M) 재귀관계다.재귀관계가 다대다(M:M)관계라면 모델로는 관리할수 없으며 아래와 같이 관리해줘야 한다.
코드관계 릴레이션에서는 코드 값 간의 관계를 관리한다. 주문채녈구문코드(103)는 온라인과 오프라인이며, 온라인에는 온라인채널종류코드 유형에서 속하는 HTS,ARS,MTS가 있으며, 오프라인에는 오프라인 채널종류코드 유형에 속한 창구,지점단말이 있다. 같은 유형에 속한 코드값 사이의 관계를 관리할 수 있다.
코드간의 관계를 관리하기는 쉽지 안다. 복잡한 코드를 관리할 만큼요건이 중요해야 하며, 코드관리는 메타시스템에서 완전하게 지원돼야 한다.실익이 크지 않아 실무에서는 권장하지 않는다.
출력순서를 관리하는 코드 모델
코드인스턴스에 대한 출력순서를 관리하는 요건이 있다. 코드값의 자릿수는 코드유형별로 코드개수가 100개를 넘지 않는다는 가정하에 2자리로 정하고, 데이터타입은 varchar로 정해 '01'부터 차례로 사용한다. 이렇게 사용할때 문제는 새로운코드가 중간에 위치할 수 없다는 것이다. 코드값대로 출력되지 않고, 순서를 정해 출력해야 한다면 출력순서 속성을 별도로 관리해야 한다.
출력종류코드 속성은 'A'화면 'B'화면등을 의미하며,A화면에서는 개인, 개인사업자 법인 법인사업자 순으로출력하며,
B화면에서는 개인 법인 개인사업자 법인사업자 순으로 출력할 수 있다. 출력순서 모델도 관리가 쉽지 않다.
단순한 모델이 좋은 모델이다. 더욱이 코드모델은 기능이 단순할수록 강력하게 사용되는 모델이다.
코드모델 이력관리
코드값의 이력관리가 필요한 이유는 감시가 목적이다.필요할때 누가 어떤코드값을 언제 어떻게 변경했는지 알기위해서다.
조인을 통해 직접사용하기 보다는 참조할 필요가 있을때 과거 정보를 조회하기 위해서 사용한다.
보통 코드값에 대한 등록이나 변경에 대해서는 엄격한 승인 프로세스가 존재하기 때문에 이력데이터는 관리해야 한다.
코드유형 엔터티에서 이력관리할 대상은 코드유형명 밖에 없다. 코드유형번호는 시스템에서 사용하는 단순일련번호이므로 값으로서는 의미가 없어 이력관리할 대상이 아니다. 코드유형명은 코드 인스턴스의 변화에 의해서 변경될 수 있다.
엔터티에서 사용되는 코드속성명과 논리적으로 연결되므로 코드속성명이 바뀌면 코드유형명이 바뀌게 된다. 코드유형명이 변경되면 이전 코드유형명을 코드유형이력 엔터티에서 관리한다.
코드엔터티의 이력관리는 코드유형엔터티보다 복잡한다. 코드엔터티는 코드값과 코으명이변경될 수 있다.
코드는 개별코드 인스턴스를 대상으로 이력관리하는것이 아니라 전체 코드 인스턴스를 대상으로 이력관리해야 한다.
즉 코드값과 코드명 어느하나라도 값이 변경되면 해당시점의 전체코드 인스턴스를 스냅샷방식으로 이력관리한다. 따라서 코드이력엔터티는 코드유형 엔터티와 관계가 존재한다. 코드엔터티와 관계가 존재할 것 같지만, 코드엔터티와는 참조무결성관계가 존재할 수 없다.
2035년 6월 10일 코드값 02--->03으로 변경한다면 하루 전 시점의 코드 인스턴스 전체를 코드이력엔터티에서 관리한다.코드 이력데이터를 보면 코드값'02'가 코드엔터티에는 존재하지 않기 때문에 코드엔터티와는 참조무결성 관계가 성립하지 않는다.
코드인스턴스 전체에 대한 스냅샷이기 때문에 의미상으로 코드유형 엔터티와 관계가 존재한다. 코드값은 주식별자와 같은 성격이기 때문에 코드값이 바뀌면 엔터티에서 사용된 모든 코드값을 수정해야 하기 때문에 코드값이 변경되는 경우는 거의 없다.
코드인스턴스는 중요하기 때문에 이력데이터를 관리하는 것이 바람직한다. 다만 코드와 관련된 이력데이터는 조인해서 사용하지 않으며, 추적용도로만 참조해서 사용하는 것이 간결하다.
'관계형데이터모데링노트 요약' 카테고리의 다른 글
| 도메인 (1) | 2023.12.03 |
|---|---|
| 속성명 (0) | 2023.12.02 |
| 코드 속성 1 (1) | 2023.11.27 |
| 식별자 종류 Part 2 (2) | 2023.11.19 |
| 식별자 종류 Part 1. (0) | 2023.11.18 |