본질식별자와 인조식별자
쉽게 말하면
식별자는 업무에 원래 있는 값으로 만들 수도 있고(주문번호와 상품번호 조합), 아무 뜻 없는 일련번호를 새로 붙일 수도 있어요. 앞의 것을 본질식별자, 뒤의 것을 인조식별자라고 해요. 일련번호는 간단하지만, 같은 내용이 두 번 들어가도 번호만 달라서 중복을 알아채기 어려워요.
시험용 정의
본질식별자는 업무에 원래 있는 속성으로 만든 식별자(주문번호+상품번호)이고, 인조식별자는 업무와 상관없이 인위적으로 만든 일련번호 같은 식별자다. 인조식별자는 단순하고 편리하지만 중복 데이터가 생길 수 있고 불필요한 인덱스가 늘어나는 단점이 있다.
비유로 이해하기
도서관 책을 (제목, 저자, 출판연도)로 구별하는 것이 본질식별자, 책마다 붙인 바코드 번호가 인조식별자다. 바코드는 편하지만, 같은 책이 실수로 두 번 등록돼도 바코드만 다르면 알아채지 못한다.
자세히
먼저 알아 둘 말
| 말 | 뜻 |
|---|---|
| 일련번호(시퀀스) | 1, 2, 3...처럼 자동으로 늘어나는 번호. Oracle은 SEQUENCE, SQL Server는 IDENTITY로 만든다 |
| 인덱스 | 책의 색인처럼 원하는 행을 빨리 찾도록 만든 별도 구조. 기본키를 만들면 자동으로 생긴다. 많을수록 입력·수정이 느려진다 |
| UNIQUE 제약 | 열(조합)의 값이 중복되지 않게 막는 제약조건 |
비교
| 구분 | 본질식별자 | 인조식별자 |
|---|---|---|
| 만드는 방법 | 업무에 원래 있는 속성으로 | 일련번호처럼 인위적으로 |
| 예 (주문상세) | (주문번호, 상품번호) | 주문상세번호 1, 2, 3... |
| 장점 | 업무 의미가 그대로 드러나고, 중복을 키가 막아 준다 | 속성 하나라 단순하고 조인·참조가 편하다 |
| 단점 | 속성이 많아지면 키가 길고 복잡해진다 | 중복 데이터 위험, 본질식별자로 찾기 위한 인덱스가 따로 필요 |
인조식별자의 단점 자세히
- 중복 데이터 발생 가능성: 인조식별자만 PK로 두면 같은 주문의 같은 상품이 두 번 들어가도 키가 달라 막지 못한다
- 불필요한 인덱스 생성: PK 인덱스(일련번호)는 실제 조회에 잘 안 쓰이고, 업무 조회는 (주문번호, 상품번호)로 하므로 그 조합에 인덱스를 또 만들어야 한다. 인덱스가 늘면 저장 공간과 입력·수정 부담이 커진다
언제 무엇을 쓸까
- 기본은 본질식별자를 쓴다
- 본질식별자 속성이 너무 많거나, 자식에게 계속 상속되어 키가 길어지거나, 마땅한 본질식별자가 없을 때 인조식별자를 고려한다
- 인조식별자를 쓰면 본질식별자 조합에 UNIQUE 제약을 걸어 중복을 막는다
시험에 이렇게 나와요
- 본질식별자 = 업무로 만들어지는 식별자, 인조식별자 = 인위적 일련번호
- 인조식별자 단점: 중복 데이터 발생 가능성, 불필요한 인덱스 생성
- 인조식별자를 쓸 때는 본질 속성 조합에 UNIQUE 제약
- 식별자 분류 중 '대체 여부'에 따른 분류
출제 범위·공식 안내 기반
확인 문제
Q1. 주문상세의 주식별자를 (주문번호, 상품번호) 대신 일련번호 하나로 바꿨다. 가장 조심해야 할 문제는?
- 조회가 불가능해진다
- 정규화가 깨진다
- 같은 주문에 같은 상품이 중복으로 들어갈 수 있다
- 외래키를 만들 수 없다
정답 보기
3번 같은 주문에 같은 상품이 중복으로 들어갈 수 있다
일련번호는 매번 새 값이 나오므로 (주문번호, 상품번호)가 같은 행도 막지 못한다. 중복 데이터를 막으려면 본질식별자 조합에 UNIQUE 제약을 따로 걸어야 한다.
Q2. 인조식별자의 단점으로 알맞은 것은?
- NULL이 들어갈 수 있다
- 키가 너무 길어진다
- 중복 데이터가 생길 수 있고 불필요한 인덱스가 늘어날 수 있다
- 외래키로 쓸 수 없다
정답 보기
3번 중복 데이터가 생길 수 있고 불필요한 인덱스가 늘어날 수 있다
본질 조합의 중복을 막지 못하고, 실제 조회용 인덱스를 따로 만들어야 한다.
Q3. 주문상세에 인조식별자를 PK로 쓸 때 중복 입력을 막는 방법은?
- (주문번호, 상품번호)에 UNIQUE 제약을 건다
- PK를 하나 더 만든다
- 인덱스를 모두 지운다
- COMMIT을 자주 한다
정답 보기
1번 (주문번호, 상품번호)에 UNIQUE 제약을 건다
본질식별자 조합에 UNIQUE 제약을 건다.
Q4. 식별자를 대체 여부로 나눈 것은?
- 주식별자 / 보조식별자
- 단일식별자 / 복합식별자
- 내부식별자 / 외부식별자
- 본질식별자 / 인조식별자
정답 보기
4번 본질식별자 / 인조식별자
업무에서 원래 쓰는지(본질), 인위적으로 대신 만든 것인지(인조).
Q5. 본질식별자의 예로 알맞은 것은?
- 시스템이 무작위로 만든 코드
- 주문 테이블에 새로 붙인 일련번호
- 업무에서 쓰는 사업자등록번호
- 시스템이 만든 순번
정답 보기
3번 업무에서 쓰는 사업자등록번호
업무에서 원래 쓰는 식별자가 본질식별자, 인위적으로 만든 번호가 인조식별자다.
Q6. 인조식별자를 기본키로 쓰면 생기기 쉬운 문제는?
- 정규화가 불가능하다
- 본질 속성이 같은 데이터가 중복 입력될 수 있다
- 외래키를 만들 수 없다
- 조회를 할 수 없다
정답 보기
2번 본질 속성이 같은 데이터가 중복 입력될 수 있다
그래서 본질 속성 조합에 UNIQUE 제약을 함께 건다.
헷갈리기 쉬운 O·X
인조식별자는 업무적으로 의미 있는 값으로 이루어진다.
정답 보기
X 인조식별자는 업무 의미가 없는 인위적 값이다.
본질식별자 속성이 너무 많아 복잡하면 인조식별자를 고려할 수 있다.
정답 보기
O 이때도 본질 조합의 UNIQUE 제약을 함께 둔다.
인조식별자를 쓰면 인덱스 수가 반드시 줄어든다.
정답 보기
X 오히려 PK 인덱스와 본질 조합 인덱스가 따로 필요해 늘어날 수 있다.