04. 속성 이야기 (3)

코드 속성의 명명법

식별자 코드와 일반 코드는 성격이 다르기 때문에 속성의 이름을 구분해서 정하는 것이 좋다.

• 식별자 코드는 부서번호/사원번호/상품번호/화면번호 등과 같이 '~번호'로 사용한다.
• 일반 코드는 '~구분코드', '~유형코드', '~종류코드'와 같이 구분/유형/종류 등을 붙여 사용한다.
  • 구분코드: 코드 명이 더 이상 늘어나지 않고 고정적일 때 사용 (ex. 남녀구분코드)
  • 종류코드: 고정적이지 않고 지속적으로 늘어날 수 있을 때 사용 (ex. 서비스종류코드, 지불수단종류코드)
  • 유형코드: 성질이나 특징이 유사한 것끼리 묶을 때 사용 (ex. 지불수단유형코드, 거래유형코드)

 

코드 인스턴스 설계 원칙

코드 인스턴스(코드값/코드명)가 되기 위해서는 몇 가지 조건을 만족해야 한다.(넓게 보면 엔터티가 되기 위한 조건과 동일)

1. 성격이 동일해야 한다.
   • 이질적인 것을 하나의 코드 집합으로 정의하면 안 된다.
2. 상호 배타적이어야 한다.
   • 코드 집합 간에는 교집합이 존재하면 안 된다.
3. 전체가 합집합이어야 한다.
   • 코드 집합의 원소(코드명) 전체를 합하면 코드 속성 정의가 돼야 한다.
4. 상세화 수준이 유사해야 한다.
   
   • 코드 집합에 속한 원소는 상세화 수준, 즉 분류 수준이 같아야 한다.

 

코드를 사용하는 용도

1. 집계 용도
   
   • 어떤 구분으로 집계하려면 인스턴스를 코드 ㅁ여으로 구분해 놓아야 한다. 즉 코드 인스턴스는 집계의 기준이 된다.
2. 조회 용도
   • 코드는 특정한 대상만을 뽑아 조회하기 위한 용도로 많이 사용된다.
3. 분기 용도
   • 다른 로직을 적용해야 한다거나, 화면에서 달리 보여줘야 하는 요건이 있을 때 코드로 구분하여 관리한다.
4. 서브타입 구분 용도
   • 슈퍼타입의 특정 인스턴스가 어떤 서브타입과 연관되는지를 알기 위해 코드로 구분해야 한다.

 

통합 코드 엔터티와 개별 코드 엔터티

1. 통합 코드 엔터티의 장점
   • 저장 공간 절약: 코드 인스턴스가 적어 블록 낭비를 줄일 수 있음.
   • 조회 성능 향상: 디스크 I/O 감소, 메모리 적중률 상승으로 빠른 조회 가능.
   • 모델 단순화: 코드별로 엔터티가 늘어나는 것을 방지, 모델 가독성 및 관리 용이.
2. 개별 엔터티 관리가 필요한 예외 상황
   • 코드에 부가 속성이나 **추가 기능(부분집합 관리, 관계 관리 등)**이 필요한 경우.
   • 코드 인스턴스가 매우 많아 메모리 적중률과 관리 효율성을 해칠 경우.
   • 특정 코드가 집중 조회되어 통합 엔터티의 성능을 저하시킬 가능성이 있는 경우.
   • 외부 시스템에서 제공받는 코드로 내부 관리가 복잡하거나 오너십이 없는 경우.
   • 코드 값 변경이 잦고 이력 관리가 필요한 경우.
3. 권장 원칙
   • 위 예외 상황이 아닌 경우, 모든 코드를 하나의 통합 엔터티에서 관리하는 것이 바람직하다.
   • 불필요하게 코드별 개별 엔터티를 만들면 공간 낭비, 성능 저하, 모델 복잡성을 유발한다.

 

일반적인 코드 모델

코드 엔터티는 일반적인 엔터티와 성격이 다르다. 데이터의 성격을 파악해 엔터티를 도출하기보다는 관리하기 쉬운 방법, 애플리케이션에서 사용하기 편리한 방법으로 엔터티를 설계해야 한다. 따라서 모델 구조뿐만 아니라 데이터를 어떻게 생성할 것인지도 중요하다.

 

1. 첫 번째 모델

 

• 가장 일반적으로 사용하는 코드 모델
• 코드 유형 엔터티에는 코드로 관리할 종류를 관리하고, 코드유형별 코드의 인스턴스는 코드 엔터티에서 관리한다.

2. 두 번째 모델

• 코드유형 엔터티의 주 식별자인 코드유형코드 속성 값에 코드 속성의 물리명을 사용한다. (주 식별자에 유의미한 물리 명을 사용)
• 일반적으로 주 식별자 값에 의미를 부여하는 것은 좋지 않지만, 코드 모델은 애플리케이션에서 사용하기 편하도록 의미를 부여하는 것이 좋은 방법이다.

3. 세 번째 모델

• 하나의 에넡티에서 코드 유형과 코드 값을 통합 관리하는 모델
• 이는 중복 데이터를 허용하지만, 코드 데이터는 애플리케이션에서 사용하기 편리하도록 관리하는 게 의미가 있다.
• 이 방법은 임의로 데이터에 의미를 부여함에 따라 엔터티의 성격이 분명하지 않아 잘못 사용될 수 있다는 단점이 있다.
• 많은 엔터티에 상용되는 코드 속성에 5 bytes의 값이 저장된다는 점은 저장 공간 차원에서도 단점이다.
• 하지만 사용하기 편하다는 최대의 장점이 있다.

4. 네 번째 모델

• 세 번째 모델과 유사하나 다른 점은 재귀 관계를 사용해 데이터를 관리한다는 점이다.
• 재귀 관계를 관리해야 하므로 무결성이 좋아지짖만, 구조적으로 세번째 모델보다 덜 유연하다.

 

전체 코드의 부분집합을 관리하는 모델

코드 값과 코드 명을 관리하는 기본적인 코드 모델에, 다양한 부가 기능이 첨가된 코드 모델이 최근에 간혹 사용된다. 그중에 대표적인 기능이 부분집합 코드를 관리하는 모델이다. 부분집합 코드를 서브 코드라고도 한다.

 

 

부분집합으로서 관리가 필요한 코드유형이 생기면 새로운 코드유형으로 등록하고, 코드 값 전체 집합을 가리키는 상위코드유형번호를 지정한다. 그리고 코드 엔터티에는 해당 코드유형에 존재하는 코드 값을 등록한다.

하지만 코드 데이터를 위와 같이 부분집합 코드로 사용하는 것은 몇 가지 문제가 있다.

• 관리 문제: 시스템 구현의 어려움과 사용의 모호함 탓에 관리가 제대로 되지 않을 수 있다.
• 오너십 문제: 전체 집합 코드에 대한 오너십이 이쓴ㄴ지, 전체 집합 코드는 단순히 모집합의 역할만 하는지에 따라 관리하는 방법이 달라진다.

 

코드 값 간 관계를 관리하는 코드 모델

코드를 전체 집합과 부분집합으로 나눠 관리하는 방법과 유사한 기능이 코드 값(코드 ㅇ니스턴스) 간에 존재하는 계층 체계를 관리하는 기능이다.

 

계층 체계

1. 상위 계층의 코드만을 관리하는 것 (재귀 관계)
2. 상/하위 계층 코드를 관리하는 것 (BOM 관계)

 

출력 순서를 관리하는 코드 모델

코드 인스턴스에 대한 출력 순서를 관리하는 요건이 간혹 있따. 과거에는 코드 값을 정할 때 임의적인 규칙을 부여했다. 예를 들어 중간에 새로운 코드가 들어갈 것을 대비해 '10', '20', '30' 등으로 사용하고, 코드가 추가될 때는 유사한 코드 명에 따라 '21'과 같이 코드값을 사용했다.

하지만 최근에는 순차적인 번호(문자)를 주로 사용한다. 코드 값의 자릿수는 코드유형별로 코드 개수가 100개를 넘지 않는다는 가정하에 2자리로 정하고, 데이터 타입은 varchar로 정해 '01'부터 차례로 사용한다. 이렇게 사용할 때의 문제는 새로운 코드가 중간에 위치할 수 없다는 것이다. 코드 값대로 출력하지 않고 순서를 정해 출력해야 한다면 출력순서 속성을 별도로 관리해야 한다.

 

코드 모델의 이력 관리

코드 갑스이 이력 관리가 필요한 기본적인 이유는 감시 목적이다. 필요할 때 누가 어떤 코드값을 언제 어떻게 바꾸었는지를 알기 위해서이다. 조인을 통해 직접 사용하기보다는 참조할 필요가 있을 때 과거 정보를 조회하기 위해서 사용한다. 보통 코드 값에 대한 등록이나 변경에 대해서는 엄격한 승인 프로세스가 존재하기 때문에 이려 데이터는 관리해야 한다.

 

 

속성 명은 어떻게 정하는가?

• 속성 명을 명확하게 표현하려면 구체적으로 표현해야 한다. (ex. 전화번호 → 자택전화번호/휴대전화번호 → 고객자택전화번호/고객휴대전화번호)
• 구체적으로 명명해야 하지만 속성 명이 지나치게 길면 좋지 안핟.
• 간혹 무조건 짧은 속성 명을 선호하는 경향이 있는데, 의미가 충분히 전달이 안 되면서 짧기만한 속성 명은 혼란을 초래할 수 있으므로 바람직하지 않다.
• 반면에 영문 명은 가능한 짧은 것이 좋기 때문에 단어에 대응하는 영문 단축 명은 짧게 정하는 것이 좋다.
• 속성 명을 정할 때 지나치게 일반적인 용어는 사용하지 말아야 한다. (ex. 일자 → 삭제일자)

 

속성 설명

• 속성 설명은 단순, 명료하게 기술해야 한다.
• 만약 중복 속성이라면 원본 속성이 무엇인지를 기술해야 한다.
• 코드 속성일 때는 코드 인스턴스를 기술하는 것이 좋다.
• 엔터티 설명은 문법적으로 완전한 문장이 좋지만, 속성 설명은 명사형으로 끝나는 간략한 형식이 명료하다.

 

속성 표준화

표준화란 일정한 기준에 따라 통일하는 과정을 의미한다. 속성 표준화 역시 속성의 쓰임새를 통일시키는 것이 핵심이다. 즉 같은 의미의 속성에 대해서는 속성 명을 동일하게 사용하는 것이다. 같은 의미를 다르게 쓰거나 다른 의미를 같게 쓰지 않도록 하는 과정이 표준화다.

 

표준화를 하는 이유

• 데이터의 품질을 높일 수 있다.
• 관련자의 커뮤니케이션을 돕는다.
• 속성 표준화를 하지 않으면 일관된 모델을 구축할 수 없다.

 

표준화 하는 법

1. 단어
   • 속성 표준화의 출발은 단어를 정의하는 것이다.
   • 속성에서 사용된 모든 단어의 정의와 영문 약어를 정한다.
2. 영문 약어
   • 영문 약어는 컬럼 명에 사용된다.
   • 영문 약어를 정할 때 주의할 점은 길게 정하지 않는 것이다. 
   • 복합 단어의 발생을 원천적으로 막을 수는 없지만, 최소화하는 것이 바람직하다.
   • 속성을 구성하는 단어가 많을 때는 5개가 넘어가므로 단어의 영문 약어는 2~3개의 알파벳으로 정하는 것이 복합어를 최소화하는 방법이다.
3. 이음동의어
   • 이음동의어/동음이의어 사용을 허용하지 않는 것을 권장한다.
4. 동음이의어
5. 도메인

 

속성 명을 표준화하려면 아래와 같은 상세한 지침이 있어야 한다.

• 특정한 날짜를 의미할 때는 '일자'를 사용한다. (ex. 입금일자)
• '시분초'까지 의미할 때는 '일시'를 사용한다. (ex. 방문일시)
• 년/월/일 중 일부만을 의미할 때는 '년', '년월', '월', '월일', '일 등으로 사용한다. (ex. 회계년, 기준년월, 적용월, 이체일)
• 가격/좌수/단가/잔액 등의 관행적으로 사용하는 단어를 제외하고 금전을 의미할 때는 '금액'을 사용한다. (ex. 계약금액)
• 비율을 의미할 때는 '율'을 사용한다. (ex. 이율)

 

도메인

도메인은 속성에 허용된 유효한 값(원자 값)의 집합을 의미한다.) 속성이 가질 수 있는 값의 집합이 도메인이다.

 

데이터 모델링에서 사용하는 도메인의 두 가지 정의

1. 데이터 타입과 길이를 의미하는 것 (물리적 개념)
2. 속성의 대표 속성을 의미하는 것 (논리적 개념)

 

물리 도메인

물리 도메인을 구성하는 주요 요소는 데이터 타입과 길이다. 좀 더 확장하면 허용 값의 범위와 기본 값, 값의 포맷 등을 포함한다.

 

'일자'라는 도메인이 포함하는 요소

• 도메인 이름: 일자
• 도메인의 데이터 타입: date
• 도메인의 데이터 포맷: yyyy-mm-dd
• 허용 범위: 1900년 1월 1일부터 9999년 12월 31일까지의 날짜
• 기본 값: 9999년 12월 31일

 

논리 도메인

논리 도메인은 간단하게 대표 속성을 의미한다. 

ex. 'CRM고객명'이라는 속성을 등록할 때, '고객명'이라는 속성을 지정하는 것

• 의미가 포함되기 때문에 데이터 성격이 고정적인 속성에만 논리 도메인을 적용하는 것이 바람직하다.
  • 주 식별자
  • 식별자 번호
  • 코드 속성
  • 표준 데이터 성격의 기준 데이터
  • 외부 시스템에서 받은 번호나 코드

 

데이터 타입 선정 원칙과 절차

 

 

널에 대한 서설

널은 속성의 값을 알 수 없을 때 사용하는 데이터 값이다. 데이터가 입려된느 시점을 기준으로, 값을 알 수 없을 때 널을 사용한다. 널을 허용한 속성은 선택 속성이다.

 

• 속성을 정밀하게 모델링하기 위해서는 '모르는 것'과 '해당 사항이 없는 것'을 구분할 필요가 없다. 그래서 '해당 사항이 없는 것'으로 널을 저장하는 속성은 해당 엔터티에서 분리하는 것이 바람직하다.
• 속성이 코드 값을 사용할 때는 적용할 수 없는 값과 알 수 없는 널 값을 구분해 코드 값 의미를 더욱 명확하게 설계하는 것이 바람직하다. 즉 '적용할 수 없음'이나 '해당 없음'을 의미하는 코드 값을 추가해서 사용해야 한다.
• 널이 존재하는 속성이 많을 때는 원천 엔터티에서 분리해서 별도의 엔터티에서 관리하는 것도 고려해야 한다. 특히 '해당없음'에 해당하는 속성은 분리하는 것이 좋다.

 

널과 DBMS와 인덱스

속성의 널은 값을 모를 때와 값이 없을 때로 세밀하게 설계할 필요가 있다. 하지만 DBMS에서는 가능하면 널 값을 사용하지 않는 것이 좋다. 널 값도 하나의 고유한 값이어서 쿼리에서 뜻하지 않게 사용될 수 있다. 특히 연산할 때는 주의해야 한다.

• 대부분의 그룹 함수(SUM/AVG/COUNT/MAX/MIN 등)는 널 값을 연산 대상으로 고려하지 않는다.
• 널 값은 보통 인덱스에 포함되지 않는다. 널 값을 허용한 속성을 조회할 때는 이 점을 주의해야 한다.
  • 널 값에 대한 조회가 많고 널 값이 저장된 인스턴스가 적다면, 해당 속성에 대해서는 인덱스 스캔을 하도록 유도해야 한다.
  • 반면에 널 값이 저장된 인스턴스가 많다면, 테이블 풀 스캔을 유도하기 위해 실제 널 값을 사용하는 것이 유리하다.
• 널 값이 허용된 속성을 조회하는 쿼리에서 NVL 구문을 사용하면 인덱스를 사용할 수 없게 된다. 
• 널은 참조 무결성 제약을 사용할 때도 주의해야 한다. 참조 무결성 제약을 사용한 관계 속성이 업무적으로 널이 가능하면 널을 허용해야 한다.
• 외래 식별자 속성에 널 값이 존재할 때는 아웃터 조인을 항상 염두해 두어야 한다.
• 널 값은 기존 데이터를 마이그레이션할 때도 고려돼야 한다. 예를 들어 ASIS 속성에는 널 값이 허용됐는데 TOBE 속성에는 NOT NULL과 DEFAULT를 사용한다면, 마이그레이션할 때 기본값으로 업데이트 해야 한다.

 

널 특징과 사용법

 

 

속성 검증

속성을 검증하는 방법

1. 속성 존재 여부 검증
   • 모델에 표현되지 않은 속성이 있는지? / 모델에 표현된 불필요한 속성이 있는지?
   • ASIS 속성과 TOBE 속성을 비교하는 방법
     • 화면에는 있는데 속성이 없는 경우
     • 속성만 존재하고 화면에는 없는 경우
     • 속성에도 없고 화면에도 없는 경우
2. 식별자 검증
   • 주 식별자가 엔터티의 인스턴스를 유일하게 식별하는지를 검토한다.
   • 주 식별자에 논리적인 널 값(기본 값)을 사용하는 것은 바람직하지 않다.
   • 주 식별자 속성 값에 체계가 존재하는지 검토한다.
   • 하위(자식) 엔터티가 많은 주요 엔터티의 주 식별자가 단순하지 않다면 인조 식별자의 채택을 검토해야 한다. 반대로 하위 엔터티가 거의 없는 엔터티인데 인조 식별자를 채택했는지도 검토한다.
   • 단지 인스턴스의 유일성을 보장할 목적으로 '~순번'과 같은 부분 인조 식별자가 사용된 엔터티는 다시 검토해야ㅕ 한다.
   • 슈퍼 식별자를 사용하지 않는 것도 주요 원칙이다.
   • 복합 주 식별자를 사용한 엔터티는 주 식별자의 순서가 데이터를 추출하는 데 있어 효율적으로 구성됐는지를 검토한다.
   • 명이나 내용, 숫자, 금액 등이 도메인인 속성이 주 식별자에 포함됐는지를 검토한다. (주 식별자에 적절치 않은 속성)
   • 주 식별자가 동일한 엔터티가 존재하지 않는지를 검토해야 한다.
3. 일반 속성 검증
   • 속성이 단어의 조합으로 구성됐는지를 검토한다.
   • 메타 시스템에서는 도메인을 관리하는데, 속성 명이 도메인으로 끝나도록 원칙을 정했을 때 속성명이 도메인과 일치해서는 안 된다.
   • 논리 도메인이 사용돼야 할 속성에 물리 도메인이 사용되지 않았는지를 검토한다.
4. 모델 구조 검증
   • 속성 명 끝에 숫자가 포함된 속성의 사용은 지양해야 한다.(ex. 전화번호2, 전화번호3)
   • 반복되는 속성이 있는지 검토하여 정규화를 한다.
   • 중복 속성은 최대한 사용을 배제해야 한다.
   • 코드 속성일 경우 코드 인스턴스(코드값/코드명)가 존재해야 한다.
   • 코드 속성은 그 자체가 도메인(논리 도메인)으로 사용되기 때문에, 수식어가 제대로 사용됐는지를 검토해야 한다.
   • 서브타입 모델일 경우에는 슈퍼타입과 서브타입의 속성이 제 위치에 존재하는지를 검토한다.
   • 만약 주 식별자에 변경일자나 종료일자 속성이 포함돼 있다면 해당 엔터티가 이력 엔터티인지를 검토해야 한다.