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

8.3 주 식별자 선정 원칙




8.3 주 식별자 선정 원칙

주 식별자 속성이 변경되지 않도록 선정

  • 엔터티의 주 식별자(주 키)가 개발 도중이나 운영 도중에 바뀌지 않도록 처음부티 제대로 정하는 것은 가장 중요한 원칙
  • 주 식별자는 생각보다 지주 변경되는데 가장 큰 원인은 엔터티를 잘못분석하거나 명확하지 않고 애매하기 때문
  • 미래의 일을 완전하게 예측할 수는 없으므로 업무가 변경될 가능성이 조금이라도 있다변 인조 식별자를 채택히는 것도 방법 중 하나
    (주 식별지는 바뀌지 않아 영향을 최소회할 수 있다. 하지만 인조식별자 사용은 완벽하지 않다.)


주 식별자 속성의 값이 변경되지 않도록 선정

  • 주 식별자가 다른 엔터티(지식 엔터티 또는 하위 엔터티)의 외래 식별자(FK)가 돼 값이 사용된다면 주 식별자의 속성 값이 비뀌띤 그 값을 시용한 다른 엔터티의 외래 식별자 속성 값도 바
    뀌어야 한다
  • 주 식별자의 값이 바뀌는 것은 주 식별자로 선정된 속성 이 바뀌는 것보다 더욱 심각하므로 값이 바뀌지 않도록 주 식별자를 선정
  • (그림 8.9) 와 같은 모델에서 '홍길동' 고객의 주민등록번호가 바뀌면 사용한 모든 엔터티의 속성 값은 수정해야한다.

  • 그러므로 이메일 주소나휴대전화번호를 고객 엔티티의 주식별지로시용할때도 있는데 위와같은 이유에서 바람직하지 않다.
  • 바뀔수 있는 속성은 일반속성으로 관리한다.
  • 실무에서 주 식별자 값이 변경되는 것은 일반적이지 않다 변경된다면 업무적으로 요구사항이 정확하게 반영되있는지 검토할 필요가 있다.


최소한의 속성으로 구성되도록 선정

  • 주 식별자를 구성하는 속성의 수는 가능한 한 적을수록 좋다
  • 업무 식별지를 주 식별자로 채택하는 것이 바람직하지만 업무 식별자를 구성히는 속성 개수가 많고 해당 앤터티기 비교적 상위(부모) 엔터티리면 하위(지식) 엔터티를 고려해 자신의 주 식별지를 간락하게 만들어야 한다.

|
|

  • 주 식별자에 속한 속성이 많아서 가독성이 떨어진다. 다른엔티티와 관계를 표현하면 가독성이 더욱떨어진다.
  • 다른 엔터티와 관계를 표현힐 때 관계선이 복잡해져 기독성이 떨어지며 관계 자체도 관리하기 어려워진다.
  • 거래내역 엔터티에 일부 관계 속성이 존재하지 않으므로 관계선을 표현할 수 없게 되기도 한다.
  • 관계 속성을 상속할 때 일부 속성은 식별 관계로 상속하고 일부 속성은 비식별 관계로 상속하기도 한다.
  • 속성 순서를 비꿔서 싱속하는 등 관계선을 정확히 표현하지 않이 관계 속성을 제대로 관리히지 않게 된다.
  • 조인(join) 구문이 복집해져 SQL이 길어진다 ( 오류가능성이 높아진다)
  • 그림(8.10)이 그림(8.12) 보다 좋은 점은 주 식별자값을 보고 계좌에 지정된상품이나 지점의 계좌개설 일련번호갯수를 알수있다는것이다. 의미가 없다.
  • 그림(8.13) 관계선이 명확해져서 관계 속성이 단순해진다.
  • 하위 엔터티에 발생하는 베타관계를 관리하기도 쉽다.
  • 상위엔터티가 단독 주식별자면 베타관계를 구현하고 관리하기 쉽다.
  • 안좋은예

  • 너무 복잡하다. 단순할수록 좋은 모델이다.


슈퍼 식별자가 되지 않도록 선정

  • 주 식별자를 구성하는 속성의 수는 적을수록 좋으므로 슈퍼 식별자(Super Identifier)가사용되면 안 되는 것은 자명하다
  • 슈퍼 식별지를 사용하는 이유는 인덱스 와 주식별자에 대한 인식이 부족
  • 인덱스와 주 식별지는 동일한 개념이 아니다.
  • 인텍스를 설계하는 것은 단순하지 않고 최적회되지 않은 인텍스는 복잡한 성능 문제를 유벌한다
  • 데이터의 유일성을 보장하는 않는 속성은 주 식별자에서 제외해야 한다. 이러한 식별자 포함되지 않도록 한다.


업무적으로 활용도가 높은 속성으로 선정

  • 후보 식별자 가운데 주 식별지를 원칙 중의 하나는 업무 식별자를 가능한 그대로 시용히는 것이다
  • 업무 식별지는 업무적으로 지주 시용될 가능성이 크다.(그 속성으로 조회가 지주 된다는 의미다)
  • 많은 화면에서 자주 조회되면 주 식별자로 조회되는 것이 효율적이다.
  • 인조 식별지를 사용해 조회하면 필요한 데이터를 찾아가는 한 번의 과정을 더 거치므로 효율성에서는 떨어진다.
  • 업무 식별자를 도출할 때는 업무를 대표할 수 있는 속성으로 채택(예를 들어 계좌번호는 계좌 업무를 대표할 수 있는 활용도가 높은 식별자)
  • 고객 업무에서는 고객번호, 상품 업무에서는 상품변호 등이 업무를 대표할 수 있는 식별자이다.
  • 업무적으로 활용도가 높은속성을 업무 식별자로 도출하면 주식별지를 선정히는데 어려움이 없게된다(적다)


인조 식별자에는 의미를 부여하지 않으며 속성에 종속적이지 않도록 선정

  • 인조 식별자 값에 의미를 부여하지 않아야 한다는 것은 위에서 설명한 주 식별자 값이 변경되지 않아야 한다는 것과 일맥상통
  • 의미를 부여하면 모델링을 수행할 때 항상 이슈가 발생
    예) 계좌번호(10) = 개설지점(3) + 개설상품(3) + 개설순번(4) -> 조회시 값을 분리하여 조회해야함 ( 번호로 일반인이 구별하는 점도 안좋은듯-보안성)


최소한의 길이가 되도록 주 식별자 선정

  • 주식별자 길이는 짧아야 효율적
  • 주 식별자의 길이가 길면 많은 블록을 사용
  • 인덱스의 깊이(Deprh)를 깊게 민들어 가능한 한 짧은 길이 사용
  • Varchar2 타입보다는 Number 타입이 저장 공긴이 절약
  • 가독성의 문제로 3자리면 '100' 부터 시작을 권장


주 식별자 속성에 논리적으로 널 (Null) 값이 존재하지 않도록 선정

  • 주 식별자 속성 값에는 논리적인 널 (Null) 데이터를 사용불가
  • default값 사용


주 식별자 속성 값은 가능한 고정 길이가 되도록 선정

  • char 타입은 어떤 상황에서도 이득이 없으므로 사용하지 말자


업무 식별자와 인조 식별자가 혼합되지 않도록 선정

  • 인조식별자 사용시 유일성을 가지므로 혼합해서 쓰지말자


교차 엔터티


주 식별자 속성은 전사에서 한 번만 사용되도록 선정

  • 주 식별자가 동일한 엔터티가 존재하면 안 된다.
  • 암호화해하는 속성들은 주식별자로 사용하지 않는다.


후보 식별자 중에 주 식별지를 선정히는 기준

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


인조 식별자를 채택할 수 있는 기준은 디음과 같다.

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

문서정보

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