개발/sqld

[SQL/1과목] 식별자(Identifiers)

2ivii 2025. 7. 31. 23:42

저번 포스팅에서, 식별자란 것이 언급되었다. 이번 포스팅에선 식별자에 대해 알아볼 예정이다. 
이때 참고할 점! 내가 블로그 포스팅을 위해 많은 티스토리 자료들을 살펴보았는데, 대다수의 포스팅이 식별자의 정의 및 특징 이라곤 되어있지만 주식별자의 정의와 특징을 설명하고있는 것을 발견하였다. 그래서 이유 또한 찾아보니, 대부분 데이터 모델링 실무에서 식별자 = 주식별자로 쓰는 경우가 많아서, 일반적인 설명이 주식별자 중심으로 되어 있는 것이었다!!

 

SQLD 시험에서는 “식별자의 특징”을 물으면 주식별자의 특징과 거의 동일한 내용이 정답이라고 하니 참고해도 좋을거같다 !


 

식별자와 주식별자란?

 

엔티티 내 각 인스턴스를 유일하게 구분하기 위해 선택한 속성 또는 속성들의 집합이다. 
또한 주식별자란 하나의 엔티티에 구성되어 있는 여러 개의 속성 중에서 엔티티를 대표할 수 있는 속성을 의미하며 하나의 엔티티는 반드시 하나의 유일한 주식별자가 존재해야 한다. 이때 중요한 것은 유일하다인데, 주식별자는 여러개의 컬럼이 하나의 주식별자(복합식별자)가 될 수 있다.

 

식별자의 특징

 

주식별자의 특징은 다음과 같다.

  • 유일성 : 주식별자에 의해 엔터티 내에 모든 인스턴스들을 유일하게 구분한다.
  • 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
  • 불변성 : 주식별자가 한번 특정 엔터티에 지정되는 그 식별자의 값은 변하지 않아야 한다.
  • 존재성 : 주식별자가 지정되면 반드시 데이터 값이 존재해야한다. NULL 허용이 되지 않는다.
식별자의 분류

 

식별자는 다음과 같은 분류로 나눌 수 있다.

 

1. 대표성 여부

  • 주식별자 : 엔터티 내에서 각 인스턴스(아커런스)를 구분할 수 있는 구분자이며, 타 엔터티와 참조 관계를 연결할 수 있는 식별자이다. 기본키(PK)라고도 불린다!
  • 보조식별자 : 엔터티 내에서 각 인스턴스(어커런스)를 구분할 수 있는 구분자이나 대표성을 가지지 못해 참조 관계 연결을 못한다. 주식별자 아니면 다 보조식별자이다. 후보키라고도 불린다. 

2. 스스로 생성여부

  • 내부식별자 : 엔터니 내부에서 스스로 만들어지는 식별자이다.
  • 외부식별자 : 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자이다. 외래키(FK)라고도 불린다.

3. 속성의 수

  • 단일식별자 : 하나의 속성으로 구성된 식별자이다.
  • 복합식별자 : 둘 이상의 속성으로 구성된 식별자이다. 복합식별자는, 주식별자에만 쓰이는 개념이다.

4. 대체 여부

  • 본질식별자 : 업무에 의해 만들어지는 식별자이다. 
  • 인조식별자 : 업무적으로 만들어지지는 않지만 원조식별자(본질식별자)가 복잡한 구성을 가지고 있기 때문에 인위적으로 만들어진 식별자이다. 데이터베이스에서 자동으로 생성되는 일련번호(ID), UUID 등이 이에 해당한다. 

이제, 식별자 비식별자에 대해 알아보겠다! 식별자, 비식별자는 처음 내가 ERD를 만들 때 너무 헷갈렸던 개념이라 이렇게 구분까지했다.

 

식별자와 비식별자

 

1. 식별자

  • 실선표시
  • 강한 연결관계
  • 부모의 주식별자가 자식의 주식별자가 되는 경우

2. 비식별자

  • 점선표시
  • 약한 연결관계
  • 부모의 주식별자가 자식의 일반속성이 되는 경우
사용 예시

 

첫 sqld 포스팅에 가져온 나의 전 프로젝트 erd이다. (잘은 못만들었을 듯..)

여기서, 핑크색이 비식별자관계이고, 하늘색이 식별관계이다. 

users(부모엔터티)와 setting(자식엔터티)이 식별 관계이다. 이때, 설정이란것이 사람이 있어야 그 사람의 설정값이 생기기때문에 user이 삭제되면, setting도 존재할 수 없다. 

즉, 자식의 존재가 부모의 존재에 의존하므로 식별관계이다. 그렇기에 보면, user의 주식별자인 id가 setting의 주식별자로 되어있다. 

 

다른 비식별 관계에대해 보겠다. 

users와 todo_lists에 대해선, todolist id를 따로 생성해서 관리하고있다. user_id는 단순 FK일 뿐이다. 이렇게 된다면 todo_list는 user이 없어도 논리적으로 존재할 수 있다!

 

종합적으로 봤을 때 비식별관계는 부모의 PK를 FK로만 참조하므로 구조 변화에 더 유연성있고 복잡도도 감소할 것이다. 또한 부모의 PK를 자식의 PK를 사용하는 것보다 독립성을 유지하는 것이 관리에도 용이하다.
즉 기본적으로 비식별관계를 우선 사용하고나서!! 자식이 부모 없이는 절대 존재할 수 없고, 비즈니스 규칙상 완전히 종속적일 때만 식별관계 채택을 하는 것이 좋다!!



추가적으로, 부모의 PK를 자식의 PK로 받아오는 식별관계이기에, 의문점이 든 것은 그럼 식별관계는 1대1만 가능한가??? 인데 그건 아니다!! 복합키를 사용한다면 1:N의 식별 관계도 가능하다!