by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

주 식별자 선정 원칙




주 식별자 선정 원칙



1. 주 식별자의 속성이 변경되지 않도록 한다
  • 속성이 바뀌면 외래 식별자의 속성도 따라서 바뀌어야 하므로 영향이 크다
  • 속성이 바뀌는 원인?
     엔티티 잘못 분석
     엔티티 정의가 명확하지 않음
     - 엔티티를 임의대로 사용할 수 있어 식별자 변경 가능성 있음
     업무 분석 부정확
     - 특정 업무에서는 문제 없는데 다른 업무에서는 인스턴스 식별이 불가능 해 질 경우
     - 예외적 업무에 대한 고려 부족
     업무 규칙 변경
     프로젝트 중 요구사항 변경
     - 모델러의 감으로 미루어보아 변경 가능성이 있다면 인조식별자 사용하여 주 식별자 변경을 최소화
     이력 등의 시간개념이 반영되지 않아서
     - 12장(이력관리) 에서 다룸

2. 주 식별자의 속성값이 바뀌지 않도록 한다
  • 속성값이 바뀌면 외래 식별자 모든 값도 따라서 바뀌어야 하므로 영향이 크다
  • 값이 바뀔 수 있는 주민번호, 휴대전화번호 등등은 사용 지양해야 한다
  • 이력 관리에서는 관리 방법에 따라 주 식별자 값이 바뀔수도 있다
     - 선분이력 모델에서 종료 일자를 날짜 Max(9999-12-31) 등으로 관리 할 경우
  • 자식 엔티티가 없을때도 주 식별자 값 변경이 문제 되지 않을 수도 있다

3. 일반 속성에 종속되지 않도록 한다



4. 추출 속성이 주 식별자에 포함되지 않도록 한다
  • 추출 속성이 무엇?
  • 추출 속성은 데이터 정합성을 맞추기 어렵다

5. 선정 시 텍스트 형 데이터는 사용하지 않는다



6. 데이터 변경이 가능한 속성(수량, 금액 등)은 사용하지 않는다



7. 최소한의 속성 조합으로 구성되도록 선정한다
  • 엔티티 자체의 가독성을 높일 수 있다
  • 자식 엔티티에서 식별자를 상속받을 때 속성 갯수가 과도하게 늘어나는 것을 방지한다
  • 자식 엔티티와의 관계선을 단순화 시킬 수 있다
  • 주 식별자의 인덱스 사이즈를 작게 유지하여 조회 성능을 높일 수 있다
  • 조합 속성 주 식별자에 의해 엔티티의 정체성이 불분명 할 경우


 - 아래처럼 엔티티 정체성을 잘 드러내는 인조 식별자로 대체 가능하다



 - 단순한 단독 식별자 일 경우 베타 관계를 표현하기도 쉽다



 - 어떤점에서 쉽다는건지는 잘 모르겠다

  • 피치 못하게 복합 식별자를 써야 하는 경우도 있다
     - 교차 엔티티는 양쪽 엔티티의 주 식별자를 상속받아서 복합 주 식별자로 사용해야 한다
     - 일반적인 종속 엔티티는 부모 엔티티의 주 식별자가 포함 된 복합 식별자가 사용된다
     --> 이럴 경우 성능을 고려 해 속성의 순서를 정해야 한다

8. 슈퍼 식별자가 되지 않도록 한다
  • 슈퍼 식별자를 만드는 이유는 인덱스와 주 식별자의 개념이 부족하기 때문이다
  • 인덱스와 주 식별자는 동일한 개념이 아니다

9. 업무적 활용도가 높은 속성으로 선정한다
  • 가급적 업무 식별자를 그대로 사용한다
     - 업무 식별자는 업무적으로 자주 사용될 가능성이 많으며
     - 조회 조건으로 자주 사용될 가능성이 많다
  • 인조 식별자를 사용하면 필요한 데이터를 한번 더 찾아야 되므로 사용 효율성이 떨어진다고 하는데 무슨 뜻인지 잘 모르겠다
  • 업무 식별자 중 업무 대표성이 큰 식별자를 주 식별자로 한다

10. 인조 식별자를 사용할 시 의미를 부여하거나 속성에 종속적이 되지 않도록 한다
  • 인조 식별자 생성 권고사항
     - 인조 식별자는 의미 없는 코드로 사용
     - 업무적인 의미가 존재하는 데이터는 별도의 속성으로 관리
     - 이는 속성 값이 변경될 경우 주 식별자 값도 변경되는 것을 방지한다
      주 식별자인 "계좌번호" 가 [개설일+지점코드] 조합일 경우
      --> 지점이 통 폐합 시 계좌번호도 변경되어야 한다
  • 인조 식별자 생성 권고사항을 따를 때 장점
     - 특정 속성값만 조회 요건이 있을 때 데이터 중복 저장이 생기는 것을 방지한다
      주 식별자인 "계좌번호" 가 [개설일+지점코드] 일 경우
      --> 개설 일 별 조회 요건이 있을 때 별도의 개설일자 속성을 중복해서 만들어야 한다
  • 인조 식별자 생성 권고사항에 대한 예외 상황
     - 데이터 통합 모델의 경우
     여러 종류 상품을 하나의 엔티티로 사용할 때 복합 주 식별자인 [상품번호+상품종류코드]가 식별자가 됨
      [상품번호+상품코드] 를 신규상품번호 속성으로 단독 주 식별자로 사용하는게 좋다
      이 때 New상품번호는 "속성 의미 부여" 보다 "중복 제거" 의 목적이 크며
      상품코드는 별도의 의미를 가진 속성으로 관리되어야 한다

11. 최소한의 길이가 되도록 한다
  • 길이가 짧으면
     데이터/인덱스 저장공간이 적어지고
     인덱스 블록 갯수가 적어져 조회 성능이 향상될 수 있으며
     인덱스의 깊이(Depth) 가 늘어나는 것을 발지할 수 있다
  • 자릿수는 업무적인 내용을 고려하여 지나치게 크게 잡지 않는다
  • Varchar 타입보다는 NUMBER 타입이 저장공간이 절약되므로 공간활용/성능 면에서 효율적이다

12. 속성에 논리적으로 널이 없도록 선정한다
  • 알수 없는 값(Null)으로 인스턴스를 식별하지는 못한다
  • 테이터 통합 등으로 부득이하게 널 값이 있을 수도 있을 경우 속성 기본값을 지정하여 대체한다

아래 고객/계좌 속성 변경 이력에 계좌순번은 널이 들어갈 수 있으며 이 때 임의의 기본값으로 대체 가능하다


  • 기본 값을 사용할 때에는
     - 데이터가 일관적으로 생성되도록 해야한다(중간에 값이 바뀌면 안됨)
     - 업무에서 사용되지 않는 값을 정해 업무 값과 혼돈되지 않아야 한다

13. 가능한 고정길이 자릿수를 원칙으로 한다
  • 업무적으로 자릿수 길이를 통일해야 한다
     - CHAR 타입을 사용하라는 말이 아니다(CHAR 는 별 이득이 없다)
    -베타 속성 통합 모델 등에서 예외가 생길 수 있다



14. 업무/인조 식별자를 혼합하여 사용하지 않는다
  • 혼합 할 경우 가독성이 떨어지며 인스턴스 발생 기준을 알 수 없다
  • 보통 "~순번" 을 많이 사용하는데 유일성을 보장하기 위해 순번을 사용하는것은 권장하지 않는다
     교차 엔티티에서 위와 같은 상황이 많이 발생 하는데
     --> 업무적 관련성을 고려하여 다양한 전략을 취한다

 상세 예시는 책 참조(237p ~ 241p)

  • 교차 엔티티에서 취할 수 있는 주 식별자 방법은 아래 예시들이 있다



15. 주 식별자 속성은 전사에서 단 한번만 사용하는것을 권장한다
  • 엔티티의 성격을 파악하기 쉽다
  • 엔티티 간 관계 표현 시 명확 해 진다
  • 주 식별자가 [일자+순번]같이 구분이 힘든 엔티티가 많은 모델이라면
     --> 차라리 엔티티의 고유한 인조 식별자 생성 권장

서브타입 속성을 1:1 수직 분할 한 엔티티에서는 동일 주 식별자를 사용해야 할 수 밖에 없다
실무적으로는 따르기 거의 불가능하지만 원칙을 세우는 것 만 해도 좋다

16. 암호화가 필요한 속성은 사용하지 않는다
  • 성능 상 비 효율적이다

주 식별자 선정 원칙 요약

후보 식별자 중 주 식별자를 선정하는 기준

  • 시간이 지나도 값이 바뀌지 않는 후보 식별자
  • 널 값이 존재하지 않는후보 식별자
  • 길이가 짧고체계가 없는 간결한후보 식별자
  • 여러 속성으로 구성된 후보 식별자보다는 딘일 속성의 후보 식별자
  • 업무를 대표하는(업무 식별자 역할을 하는) 후보 식별자
  • 암호화되지 않는 후보 식별자

인조 식별자를 채택할 수 있는 상황

  • 업무 식별자가 여러 개의 속성으로 구성 될 때
  • 업무 식별자가 변경될(업무가 변경될)가능성이 있을 때
  • 업무 식별자의 값이 변경될 가능성이 있을 때
  • 업무 식별자의 값에 널(Null)이 포함될 수 있을 때
  • 업무 식별지에 체계(의미)가 존재할 때
  • 업무 식별자의 길이를 줄일 때
  • 시스템 내부에서만 사용되는 인조 식별자를 도입할 때
  • 업무 식별자의 값에 보안을 적용해야 할 때


문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.