개인적으로는 속성 명이 길어나는 건 반대입니다.
하지만 통합 코드를 구분하는 게 의미가 있어 매뉴얼에 포함시켰습니다.
--
통합코드 엔터티에서 관리되는 코드를 사용하는 속성 명은 ‘~통합코드’로 정하며, 구분/종류/유형과 같은 구분자를 붙여서 정한다. 따라서 일반 코드 속성 명은 ‘~구분통합코드’, ‘~종류통합코드’, ‘~유형통합코드’와 같이 사용한다.
코드 속성은 비코드 속성과 성격이 다르기 때문에 속성 명을 구분해서 정하는 것이 좋다 속성 명을 구분하면 사용법이 자연스럽게 구분되기도 한다.
주 식별자 속성과 같은 비코드 속성은 하나의 인스턴스가 하나의 실체(개체)를 의미하므로 구분/유형/종류 등을 사용하는 것이 적절하지 않지만, 일반 코드는 하나의 개체를 의미하는 것이 아니라 범주를 의미하므로 구분/종류/상태/등급/방법/단위 등과 같이 구분자(Discriminator) 역할을 하는 용어와 함께 사용하는 것이 적절하다.
다만 이런 구분자의 종류가 많을 경우 분별하려는 의도가 퇴색될 수 있으며, 선택할 때 복잡할 수 있다. 또한 상태 등과 같은 구분자는 그 자체로 의미가 있기 때문에 ‘구분/종류/유형’으로 구분하는 게 간명하다.
또한 통합 관리하는 코드를 의미하도록 속성 명에 ‘~통합코드’로 사용해서 혼란이 없도록 할 수 있다.
‘~구분통합코드’는 코드 인스턴스가 향후에도 거의 늘어나지 않을 만큼 고정적인 코드를 나타낸다. 이런 코드 중에서 코드 인스턴스가 두 개뿐일 때 ‘~여부’로 사용하는 경우가 있지만, 코드로 정의해서 코드 인스턴스를 명확히 구분하는 것에 바람직하다. 그래야 대비되는 값을 알 수 있다. 예를 들어 ‘남자여부’보다는 남녀구분코드가, ‘매수여부’보다는 ‘매수매도구분코드’가 더욱 명확하다.
‘~종류통합코드’는 고정적이지 않고 지속적으로 늘어날 수 있는 코드명을 나열할 때 사용한다. 기업에서 제공하는 서비스를 코드로 설계할 때는, 사업을 하면서 계속 늘어날 수 있으므로 ‘서비스종류코드’로 정한다.
‘~유형통합코드’는 성질이나 특징이 유사한 것끼리 묶을 때 사용한다. 큰 묶음이므로 코드 인스턴스가 종류코드보다 코드 인스턴스가 많지 않고 거의 늘어나지 않는다. 개인과 법인을 나타내는 ‘고객유형코드’가 이에 해당한다.
이렇게 일반 코드의 속성 명을 구별해 사용할 때의 장점은 비코드 속성과 분명하게 구분할 수 있다는 점이다. 또한 크진 않겠지만 코드 속성 명을 정하는 시간을 줄여주며, 의사소통을 원활하게 하는 데 도움을 주고 가독성을 높여준다. 속성 명이 길어진다는 것은 단점이 될 수 있지만 구분하는 장점이 크다고 생각한다.
다른 문제는 일반 코드로 사용하다 식별자 코드가 될 때 속성 명이 바뀐다는 것이다. 예를 들어 일반 코드 속성으로 ‘국가종류통합코드’를 사용하다 식별자 코드로 사용할 때는 ‘국가번호’가 돼서 속성 명이 바뀌게 된다. 이를 방지하는 방법은 처음부터 코드 속성 설계를 제대로 하는 것이다. 즉 하나의 개별 개체를 의미하는 데이터에 대해서는 범주를 의미하는 일반 코드로 정의하지 않는 것이다.
국가는 하나의 인스턴스가 실제의 한 실체를 의미하기 때문에 애초부터 국가 엔터티로 설계해야 하는 후보다. ‘대한민국’이라는 인스턴스는 ‘아시아’와 같은 묶음을 의미하는 유형이 아니며 개별 개체다.
식별자 코드와 일반 코드에 대해서 명명 규칙을 정해 사용하는 것은 의미가 있다. 이 둘을 유사하거나 같은 것으로 생각하는 것도 명명법과 무관하지 않기 때문에 구분하는 것이 좋다.
'데이터 Story > 모델링 매뉴얼' 카테고리의 다른 글
속성의 묶음이 반복된다면 정규화가 원칙 (0) | 2017.08.06 |
---|---|
코드 유형과 코드 인스턴스를 한 개의 엔터티로 설계 (0) | 2017.05.27 |
외부에서 받은 코드 값만 관리할 때 (0) | 2017.05.13 |
외부 코드를 내부 코드에 통합하는 방법 (0) | 2017.05.09 |
내부 코드 통합 엔터티 (0) | 2017.05.07 |