코드 속성의 명명법
식별자코드와 일반코드는 성격이 다르기 때문에 속성의 이름을 구분해서 정하는 것이 좋다.
식별자코드는 부서번호, 사원번호등과 같이 '~번호'로 사용된다. 이런 식별자코드는 단지 인스턴스를 식별하는 역활을 하면 그만이기 때문에 인조식별자인 '~번호'로 사용하는 것이 바람직하다. 조인 목적으로 사용하며, 자체의미는 없다.
주식별자 값이 문자와 숫자가 혼합돼 있고, 체계가 있어 이미 범용적으로 코드값으로 인식해서 사용하고 있는 식별자는 부서코드 지점코드 등으로 사용할수 있다. 대신 식별자코드의 속성명에는 일반코드에서 설명할 구분자(구분, 유형종류)를 사용하지 않는다.
일반코드는 범주를 의미하므로 구분자역활하는 용어와 함께사용(구분, 유형, 종류)
식별자코드 인스턴스 하나의 개체를 의미하므로 구분자와 함께사용되지 않음
구분코드 : 코드명이 더이상 늘어나지 않고 고정적일때 사용 ex) 남녀구분코드
종류코드 : 고정적이지 않고 지속적으로 늘어날 수 있을 때 사용 ex) 서비스종류코드
유형코드 : 성질이나 특징이 유사한 것끼리 묶을때 사용 ex)지불수다유형코드
식별자코드와 일반코드명을 구별해 사용할 때의 장점
-식별자 코드에 '~코드'를 사용하지 않는 것 자체가 식별자 코드와 일반코드를 분명하게 구분할 수 있게 해준다.
-일반코드를 특정구분자로 구분하는 것 역시 속성명을 정하는 시간을 줄여주고, 가독성을 높여준다
문제가 있다면 일반코드로 사용하다가 식별자 코드가 될때 속성명이 바뀐다는 것
일반코드속성으로 국가종류코드를 사용하다가 식별자코드로 사용할때 국가번호가 돼서 속성명이 바뀌게 된다
이를 방지하는 방법은 처음부터 코드속성 설계를 제대로 하는 것이다. 하나의 개별개체를 의마하는 것에 대해서 범주를 의미하는 일반코드로 정의하지 않는 것이다.
코드인스턴스 설계원칙
코드값은 코드명에 대해서 사전에 정한 기호일 뿐이다. 중요한건 코드명이며 코드값은 사용편의를 위해 만든 물리적인 값이다. 실제의미가 있는 코드명과 이를 기호화 한 코드값을 합친것을 코드 인스턴스라고 한다.
코드인스턴스를 설계하는 기준은 엔터티를 설계하는 기준과 동일하다. 엔터티나 코드는 집합이라는 개념을 기반으로 설계하기 때문이다.
-성격이 동일해야 한다.
인스턴스를 구성하는 코드명의 성격이 동일해야 한다. 이질적인 것을 하나의 코드 집합으로 정의하면 안된다.
S={동물,식물, 양의 정수, 음의 정수} -> 아무리 일반화를 시켜도 성격이 유사하다고 보기 힘들다.
이런현상은 두개의 코드를 관리하기 싫어서? 코드를 통합하는 과정에서도 생길수 있다. 이건 통합이 아니다. 다른성격의 코드명을 하나의 코드집합으로 정의하면 안된다.
-상호 배타적이어야 한다.
코드집합은 상호배타적이어야 하고, 교집합이 존재하면 안된다. 코드명 사이에 포함관계가 존재하기 때문에 잘 못 설계한 코드다.
-전체가 합집합이어야 한다.
코드집합의 원소 전체를 합하면 코드속성정의가 되어야 한다. 코드명이 하나라도 빠지면 안된다. 전체코드명대상으로 정의해야하며 코드집합에 대한 올바른 설계가 이뤄진다.
S={양의 정수, 음의 정수} (X) / S={양의 정수, 음의 정수,0}(O)
-상세화 수준이 유사해야 한다
코드집합에 속한 원소는 상세화 수준, 분류수준이 동일해야 한다. 상세화수준이 다르면 잘못된 설계다.
코드명을 제대로 구성해야 코드를 제대로 설계하는 것이다. 잘못된 원소가 포함돼 있다면 집합이 아니며, 집합이 아니라면 잘못된 설계다. 성격이 유사하고 , 상호배타적이 되도록 코드명을 설계해야 한다.
코드사용하는 용도
코드는 업무나 프로그램에서 사용하려고 만든다. 해당 인스턴스를 구분해서 사용하려고 코드로 관리한다.
-집계용도
어떤구분으로 집계하려면 인스턴스를 코드명으로 구분해놔야 한다. 코드인스턴스는 집계기준이된다.
계좌유형코드 속성의 코드 인스턴스는 종합 신탁 등이 있다. 계좌유형코드 속성에 구분해 놓아야 집계할때 사용할 수 있다.
-조회용도 : 특정대상만을 뽑기위해서 사용
-분기용도 : 코드프로그램에서 다른로직을 적용해야 한다거나 화면에서 달리보여줘야 할때
-서브타입 구분용도 : 슈퍼타입의 특정 인스턴스가 어떤 서브타입과 연관되는지 알기위해 코드로 구분
코드 엔터티와 참조 무결성 관계
코드엔터티와 일반엔터티 사이에 관계선을 표현하는 것이 원칙이지만 엔터티 관리하는 방법에 따라 조금씩 달라진다.
코드엔터티를 관리하는 방법
1) 개별코드엔터티에서 관리하면서 직접관계존재
개인과 법인을 나타내는 고객유형코드를 개별코드엔터티에서 관리하는 방법
과거에는 이방법을 사용했지만, 메타시스템에서 코드를 통합관리하는 것이 효율적이므로 거의 사용하지 않는다.
-고객유형 엔터티에 명 이외에 관리할 속성이 있거나, 인스턴스가 상당히 많다면 개별관리
-코드 이외에 다른속성이 필요하다면 당연히 개별엔터티에서 관리할 수 밖에 없다
-코드 인스턴스는 메모리에 올려서 사용하기 떄문에 데이터양이 많다면 코드 엔터티에서 제외하는 것이 좋다.
고객유형 엔터티와 이를 참조한 고객 엔터티간에는 관계선을 표현해야 한다.
2)통합 코드 엔터티에서 관리하면서 직접 관계 존재
코드엔터티는 모든 유형의 코드를 통합하여 관리한다. 주식별자는 유형을 의미하는 코드유형번호 속성과 유형별 코드를 의미하는 코드속성으로 구성된다. 따라서 이코드엔터티를 참조할려면 관계속성(고객유형코드유형번호,고객유형코드) 두가 필요하다. 코드유형은 여러개일 수도 있으므로 관계속성뿐만 아니라 관계명에도 해당코드유형을 나타내야 한다.
이방법은 관계속성이두개라서 관계선을 표현하면 모델이 복잡해 질수 있다. 고객엔터티와 같은 핵심엔터티는 코드속성이 열개 이상일수 있어서 관계선 표현조자 어려울 수 있다.
이모델의 경우 일부 예외적으로 관계선 표현을 생략할 수 있다. 가독성이 문제가 될정도로 복잡한 엔터티가 아니면 관계선은 필요하다.
3)통합코드엔터티에서 관리하면서 간접관계존재
고객엔터티의 고객유형코드속성에 사용되는 코드 인스턴스는 이미 코드통합관리시스템에 존재한다는 것을 아는 상태
논리적으로만 관계가 존재
4)통합코드엔터티에서 관리하면서 직접관계존재
코드엔터티의 주식별자를 단순화한 모델이다. 이모델은 두엔터티사이에 참조무결성 관계가 존재하기 때문에 관계선 표현해야 한다. 관계선을 제약으로 관리해서 데이터품질을 높이기위해 코드엔터티의 주식별자를 단순화한것이기 때문에 관계선을 표현해야 한다. 관계선이 의미하는 코드가 무엇인지는 관계명에 표현해야 한다.
단순히 복잡한 것은 문제가 아니라 혼란을 일으키고 관리측면에서 문제를 발생할 수 있다.
코드엔터티와 코드를 참조하는 일반엔터티 사이에는 관계선을 표현해야 한다.
통합코드엔터티와 개별코드엔터티
코드를 통합관리해야하는 이유와 통합코드엔터티에서 관리할 수 없는 상황
-개별엔터티 사용 시
한종류의 코드인스턴스는 몇개 안되므로 한블록에 저정하면 많은공간이 사용하지 못하고 낭비됨 -> 몇개의 인스턴스가 한블록을 차지한다는 것은 데이터를 조회할때 많은 블록이 사용된다는 것을 의미하므로 비효율적 (단지 저장공간을 많이 사용하는 것이 문제가 아니라 조회성능에도 영향을 끼친다)
디스크 I/O가 빈번히 발생, 메모리 적중률 낮아질수 있음
모델의 가독성 떨어뜨린다. 엔터티 모델이 복잡해질 수 있다.
-통합코드엔터티 사용 시
모든코드인스턴스를 하나의 엔터티에서 관리하면 한 블록에 많은 종류의 코드 데이터를 저장. 저장한 블록이 메모리에 상주하면 디스크I/O없이 메모리I/O가 발생 해 성능에 효율적임. 메모리에 존재하는 블록이 다시 사용될 가능성이 커짐. 메모리 적중률이 높아져 성능이 좋아짐
예외상황으로 개별코드엔터티로 관리해야하는 경우
-코드값, 코드명 이외에도 관리할 속성이 있을때
-코드관리에 부가적인 기능이 추가될 때
-부분집합 개념을 관리, 코드간의 관계를 관리한다든지 하는 부가기능이 존재할 때도
-코드인스턴스가 상당히 많을 떄도 별도로 관리
-성능 차원에서 집중조회로 인한 경합을 줄여야 할때, 코드종류에 따라 집중적으로 조회될 수 있을때 성능저하될수 있다.
-코드인스턴스를 외부에서 받을때, 오너십 또한 내부에 있지 않아 받아서 그대로 사용할때
-코드값이 자주 바뀌는 경우도 별도 엔터티로 구성(이력데이터를 고려해야하기 때문에)
일반적인 코드 모델
코드엔터티는 데이터성격을 파악해 엔터티를 도출하기보다는 관리하기 쉬운방법, 애플리케이션에서 사용하기 편리한 방법으로 엔터티를 설계해야 한다.
코드엔터티 관리하는 기본적인 요건
코드모델은 코드를 제대로 관리할 수 있으면서 사용하기 편하도록 설계하는 것이 중요하다.
첫번째 . 코드유형 엔터티에는 코드로 관리할 종류를 관리한다. 코드유형별 코드의 인스턴스는 코드엔터티에서 관리한다.
매수와 매도를 조회해서 보여줄떄는 코드엔터티에 코드유형번호(001) 값를 사전에 알고 있어야 한다. 코드유형번호를 002값으로 잘못 사용될 경우 매도매수의미를 사원 대리로 보일 수 있다.
두번째 코드유형 엔터티의 주식별자인 코드유형코드 속성값에 코드속성의 물리명을 사용하는 것이다. 주식별자에 무의미한 번호를 사용하는 첫번째 모델과 달리 유의미한 물리명을 사용하는 것이 다르다. 일반적으로 주식별자값에 의미를 부여하는 것은 그 의미가 속성에 종속 될 수 있기 때문에 바람직 하지 않지만, 코드모델은 애플리케이션에서 사용하기 편하도록 의미를 부여하는 것이 좋은 방법이다. 조회쿼리는 조건에 코드유형코드가 'BS_CD'라는 것을 알고 있어야 사용가능하다. 실제로는 컬럼명을 사용하므로 ' WHERE A.BS_CD = B.CODE'와 같기 때문에 네번째 줄의 상수인 ' BS_CD'를 쉽게 알수있으므로 애플리케이션에서 사용하기 편하다.
코드속성명을 영문명이 아닌 한글명으로 사용하는 것도 유용한 방법이다. 한글로 사용하는 것이 거부감이 있지만, 의미도 명확하고 사용하기 편리한 방법이다.(?) 매도매수구분코드 속성명은(한글명)은 변하지 않는 값이다. 만약 이값이 바뀐다면 코드자체가 바뀌는 것으로 인식해야 한다. 반면에 컬럼명(영문명)은 변경될 가능성이 존재한다. 속성명은 그대로이지만 영문약어의 변경등으로 컬럼명은 변경될 수 있어 속성명을 코드속성값으로 사용하는 것이 더욱 견고하며 논리적이다.
세번째. 코드엔터티는 하나의 엔터티에서 코드유형과 코드값을 통합관리한다. 릴리이션에서 코드유형번호 속성 값이 null인 인스턴스는 코드유형을 의미한다. 코드속성값의 앞 세자리의 값과 코드유형번호 속성값이 같으면 해당 코드유형에 속한 코드의 인스턴스를 의미한다. 코드유형에 대한 코드속성 값은 세자리의 값을 사용하며 앞의 세자리가 같은면 같은 유형을 의미하기 때문에 코드 속성값으로도 코드 인스턴스를 알 수 있다. 코드 속성 값의 앞의 세자리가 코드유형번호 속성값과 일치하도록 관리해야 한다. 이는 중복데이터지만 코드데이터는 애플리케이션에서 사용하기 편리하도록 관리한는게 우선이다.
이방법의 단점은 데이터에 의미를 부여할때 엔터터의 성격이 분명하지 않아 잘못사용될 수 있다.많은 엔터티에 사용되는 코드속성에 5bytes의 값이 저장된다는 점도 저장공간 차원에서 단점이 있지만, 사용하기 편하다는 최대의 장점이 있다.
' WHERE A.매수매도구분코드= B.코드' 이는 속성값에 코드유형까지 포함된 코드를 저장했기 때문에 코드엔터티와 조인을 통해 바로 코드명을 알수 있다. 이쿼리는 워낙많이 사용되므로 쿼리가 단순해진다는 점은 커다란 장점이 될수 있다.
쿼리에 상수를 쓰지않아 실수를 방지할수도 있는 장점도 있다.
위 모델과 같이 코드를 기준데이터로 통합 관리하는 엔터티와 코드를 사용한 엔터티간의 관계선을 표현하는 것도 수월하다는 장점이 있다. 참조무결성 제약을 생성할 수 있으므로, 데이터 무결성을 높일 수 있다는 것을 의미한다. 코드데이터는 중요하므로 데이터의 품질에 특별히 신경써야 한다.
네번째. 재귀관계로 설계된 코드 모델은 데이터를 구조적으로 관리한다는 점에서 는 바람직하지만, 결과적으로는 세번째모델과 같은 효과가 있으면서 공간을 조금 더 사용한다. 재귀관계로 관리하므로 무결성은 좋아지지만 세번째모델보다는 유연성이 떨어진다.
'관계형데이터모데링노트 요약' 카테고리의 다른 글
| 속성명 (0) | 2023.12.02 |
|---|---|
| 코드속성 2 (0) | 2023.11.29 |
| 식별자 종류 Part 2 (2) | 2023.11.19 |
| 식별자 종류 Part 1. (0) | 2023.11.18 |
| 업무식별자와 인조식별자의 혼합 (1) | 2023.11.14 |