1. 주 식별자의 속성이 변경되지 않도록 한다

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

2. 주 식별자의 속성값이 바뀌지 않도록 한다

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

4. 추출 속성이 주 식별자에 포함되지 않도록 한다

• 추출 속성이 무엇?
• 추출 속성은 데이터 정합성을 맞추기 어렵다

7. 최소한의 속성 조합으로 구성되도록 선정한다

• 엔티티 자체의 가독성을 높일 수 있다
• 자식 엔티티에서 식별자를 상속받을 때 속성 갯수가 과도하게 늘어나는 것을 방지한다
• 자식 엔티티와의 관계선을 단순화 시킬 수 있다
• 주 식별자의 인덱스 사이즈를 작게 유지하여 조회 성능을 높일 수 있다

• 조합 속성 주 식별자에 의해 엔티티의 정체성이 불분명 할 경우
  
  

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

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

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

8. 슈퍼 식별자가 되지 않도록 한다

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

9. 업무적 활용도가 높은 속성으로 선정한다

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

10. 인조 식별자를 사용할 시 의미를 부여하거나 속성에 종속적이 되지 않도록 한다

• 인조 식별자 생성 권고사항
• 인조 식별자는 의미 없는 코드로 사용
• 업무적인 의미가 존재하는 데이터는 별도의 속성으로 관리
• 이는 속성 값이 변경될 경우 주 식별자 값도 변경되는 것을 방지한다
  • 주 식별자인 "계좌번호" 가 (개설일+지점코드) 조합일 경우
  • 지점이 통 폐합 시 계좌번호도 변경되어야 한다

• 인조 식별자 생성 권고사항을 따를 때 장점
• 특정 속성값만 조회 요건이 있을 때 데이터 중복 저장이 생기는 것을 방지한다
  • 주 식별자인 "계좌번호" 가 (개설일+지점코드) 일 경우
  • 개설 일 별 조회 요건이 있을 때 별도의 개설일자 속성을 중복해서 만들어야 한다

• 인조 식별자 생성 권고사항에 대한 예외 상황
• 데이터 통합 모델의 경우
• 여러 종류 상품을 하나의 엔티티로 사용할 때 복합 주 식별자인 (상품번호+상품종류코드)가 식별자가 됨
• (상품번호+상품코드) 를 신규상품번호 속성으로 단독 주 식별자로 사용하는게 좋다
• 이 때 New상품번호는 "속성 의미 부여" 보다 "중복 제거" 의 목적이 크며
• 상품코드는 별도의 의미를 가진 속성으로 관리되어야 한다

11. 최소한의 길이가 되도록 한다

• 길이가 짧으면 데이터/인덱스 저장공간이 적어지고
• 인덱스 블록 갯수가 적어져 조회 성능이 향상될 수 있으며
• 인덱스의 깊이(Depth) 가 늘어나는 것을 발지할 수 있다

• 자릿수는 업무적인 내용을 고려하여 지나치게 크게 잡지 않는다
• Varchar 타입보다는 NUMBER 타입이 저장공간이 절약되므로 공간활용/성능 면에서 효율적이다

12. 속성에 논리적으로 널이 없도록 선정한다

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

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

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

13. 가능한 고정길이 자릿수를 원칙으로 한다

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

14. 업무/인조 식별자를 혼합하여 사용하지 않는다

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

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

15. 주 식별자 속성은 전사에서 단 한번만 사용하는것을 권장한다

• 엔티티의 성격을 파악하기 쉽다
• 엔티티 간 관계 표현 시 명확 해 진다
• 주 식별자가 일자+순번같이 구분이 힘든 엔티티가 많은 모델이라면
  • 차라리 엔티티의 고유한 인조 식별자 생성 권장

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

16. 암호화가 필요한 속성은 사용하지 않는다

• 성능 상 비 효율적이다

주 식별자 선정 원칙 요약

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

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

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

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