개요

엔터티에서 단 하나의 인스턴스를 구별하기 위한 논리적 이름, 그것이 바로 식별자(Identifier)이다.
속성에서 말한 기본키가 식별자라고 할 수 있다.
그래서 속성에 대해서 성립하는 개념이라 보면 될 것이다.

식별자는 모델링을 할 때 나오는 논리적인 개념이다.
그러나 나는 이것이 실질적으로 테이블을 만들 때 사용되는 키와 비슷한 개념으로 보고 한꺼번에 설명하고자 한다.
엄밀하게 보면 다른 개념이 맞다.
키는 테이블에 대한 제약조건으로 거는 것이기 때문이다.

특징

다음의 특징을 가진다.
기본키의 특징이라고 봐도 될 듯.

• 유일성
• 최소성
• 불변성
• 존재성
  • null이 없다.

주민번호 없는 한국 국민이 없다고 가정한다면, 주민번호가 바로 식별자가 될 것이다.

분류

식별자는 여러 방식으로 분류할 수 있다.

• 대표성 여부
  • 주식별자
    • 엔터티 내에서 각 행을 구분짓는 구분자.
    • 다른 엔터티와 참조관계 가질 때 연결하는 식별자
    • 학생 엔터티의 학생 id
  • 보조 식별자
    • 이것도 각 행을 구분지을 수도 있다.
    • 그러나 대표성이 없어서 연결할 때 사용할 순 없다.
    • 학생 엔터티의 이메일 번호
    • 근데 지피티 옹님 왈 가능하다고 한다..
• 스스로 생성 여부
  • 내부 식별자
    • 엔터티 내부에서 만들어지는 식별자
  • 외부 식별자
    • 다른 엔터티와 관계를 통해 만들어지는 식별자
    • 주문 엔터티의 고객 번호
• 속성의 수
  • 단일 식별자
  • 복합 식별자
• 대체 여부
  • 본질 식별자
    • 비즈니스에 의해 만들어지는 식별자
  • 인조 식별자
    • 본질 식별자가 복잡해서 인위적으로 만드는 식별자
    • 주문 엔터티의 주문 번호
      • 원래는 보통 고객 번호+ 주문 순번인데 이러면 힘드니까 아예 따로 만든다.

용도

위에서 말했듯이 식별자는 엔터티에서 원하는 인스턴스를 꺼내기 위해 사용된다.
그래서 복합 식별자일 때는 대체로 그것을 따로 합쳐서 단일 식별자를 새로 만든다.
그리고 여러 개의 식별자가 있을 때는 대표성을 띄는 것을 확실하게 하나를 정한다.

식별 관계

분류에서 봤듯이 외부 식별자라는 게 있다.
이것은 엔터티 간 관계에서 자식 쪽에 생성되는 속성이다.
위에서 본 외래키가 바로 이것이다.

이때 이 외래키가 기본키가 되는 경우가 있다고 말했는데, 이것을 식별 관계라고 부른다.
반대로 그냥 일반 속성으로만 사용한다면 비식별 관계이다.

왜 이걸 굳이 따로 구분해서 개념 짓는가?
식별자는 null일 수 없다고 했기 때문에, 외부 식별자를 주식별자로 쓴다면 반드시 부모 엔터티가 앞서 존재해야만 한다.
부모에 대한 정보가 기본키인 자식 엔터티는 부모 엔터티가 선행해야만 있을 수 있다.

한편 부모 없는 자식(!) 엔터티로 만들 수도 있다.
필수로 두지는 않을 수도 있다.
이런 경우는 보통 자식이 받은 속성이 필수가 아니라서 이렇게 설정되거나, 부모의 식별자를 써도 되지만 자식이 따로 주식별자를 두는 게 유리하다고 판단될 때 이렇게 한다.

식별자 관계로 표현할 수 있다고 해서 그렇게 하는 게 항상 좋은 것은 절대 아니다.
강제성을 넣기에 안정적이라고도 할 수 있기는 하다.
그러나 다음의 두 경우를 생각해보자.

• 인터넷 고객, 전화 고객, 방문 고객 테이블을 따로 두고 있다.
  • 이때 접수 관련 엔터티를 설정한다면, 각 엔터티에 대해 만드는 것보다는 통합해서 엔터티를 만드는 게 관리가 수월할 것이다.
  • 그렇다면 접수 엔터티는 방문 고객의 주민번호, 인터넷 고객의 이메일주소 등을 외래키로 가지되, null일 때도 있게 가져야 한다.
• 고객, 주문, 주문상세, 주문상세변경내역 엔터티가 각각 따로 있다.
  • 이것들은 순차적으로 식별 관계로 나타낼 수 있다.
  • 그런데 이렇게 되면 주문상세변경내역에서는 식별자를 4개나 써야 한다;
  • SQL문을 작성할 때 이것은 복잡성과 오류 가능성을 유발한다.

그래서 다음의 과정을 거쳐서 비식별 관계를 도입하면 좋다.

• 관계를 분석한다.
• 약한 관계라면, 비식별로 만든다.
• 자식 엔터티에 독립적인 주식별자가 있어야 편하다면, 비식별로 만든다.
• 나중에 SQL 복잡성이 증가할 것 같다면, 비식별로 만든다.

키

이건 나중에 따로 정리하도록 하겠다.

키 칼럼

기본키

테이블은 기본키를 가진다.
근데 이게 복합키로 된 경우도 존재한다.
복합키는 컬럼을 많이 읽어야 하기 때문에, 테이블 풀 스캔이 발생하게 한다면 성능에 영향이 간다.

가령 a,b,c가 합쳐져 기본키인데, 조회를 할 때 a,b만 쓴다고 쳐보자.
이러면 조회 시 테이블 풀 스캔이 발생한다.
이렇다보니, 후보키중에서 어떤 놈을 기본키로 할 지는 트랜잭션 조회 패턴을 보고 결정해야 한다.
가능한 한 기본키는 where절에서 =연산에 들어오도록 만들어줘야 한다.
그리고 기본키는 순서가 있는데, 이 순서에 맞춰 where 절을 작성해야 또 좋다!
심지어 between으로 쓰이는 놈보다 =로 쓰이는 놈을 쓰는 게 중요하댄다!
그래야 인덱스 스캔이 일어난다.
이건 쿼리 성능 개선 부분에서 자세히 다룬다.

외래키

논리적으로 외래키 제약이 보인다고 해서 반드시 물리 모델링 시 넣지는 않는다.
해당 제약 조건을 생성 안하는 경우도 있고, 생성해도 관련 인덱스를 안 넣는 경우도 있다.
그래도 대체로는 외래키가 있을 땐 그것으로 인덱스를 만드는 게 성능 상 유리하다.
조인할 때 테이블 풀스캔을 때려버리는 경우가 생기기 때문이다.

참고