티스토리 뷰
데이터베이스 Key 종류 총정리, 기본키·외래키·후보키·슈퍼키 쉽게 이해하기
데이터베이스를 공부하다 보면 기본키(PK), 외래키(FK), 후보키, 슈퍼키, 대체키 같은 용어가 한 번에 쏟아집니다. 이름도 비슷하고 전부 Key라서 처음에는 “다 중요한 것 같은데 뭐가 뭔지 모르겠다”는 느낌이 들기 쉽습니다.
그런데 Key는 결국 복잡한 암기 주제가 아니라, 데이터를 구분하고 연결하기 위한 규칙이라고 보면 훨씬 쉬워집니다.
이번 글에서는 Key 종류를 쉬운 정의부터 정리하고, 각각 언제 쓰는지, 실무에서는 어떻게 적용하는지까지 흐름대로 살펴보겠습니다.
예를 들어 회원 테이블이 있다고 해보겠습니다.
users
+----+--------+-------------------+
| id | name | email |
+----+--------+-------------------+
| 1 | Kim | kim@example.com |
| 2 | Lee | lee@example.com |
| 3 | Kim | kim2@example.com |
+----+--------+-------------------+
여기서 이름만 가지고 사람을 구분하면 문제가 생깁니다. Kim이 두 명일 수 있기 때문입니다.
그래서 DB는 “이 행을 유일하게 구분할 기준”이 필요합니다. 그 기준이 바로 Key입니다.
즉,
- 어떤 데이터를 정확히 식별할 것인지
- 어떤 테이블끼리 어떻게 연결할 것인지
- 중복을 허용할 것인지 말 것인지
를 정하는 핵심 개념이 Key입니다.
보통 아래 흐름으로 이해하면 쉽습니다.
- 슈퍼키(Super Key)
- 후보키(Candidate Key)
- 기본키(Primary Key)
- 대체키(Alternate Key)
- 외래키(Foreign Key)
이제 하나씩 보겠습니다.
슈퍼키는 한 행을 유일하게 식별할 수 있는 속성 집합입니다.
예를 들어 users 테이블에서 아래는 모두 슈퍼키가 될 수 있습니다.
idemailid + nameemail + name
왜냐하면 전부 결과적으로는 한 행을 유일하게 식별할 수 있기 때문입니다.
하지만 id + name처럼 굳이 필요 이상으로 속성이 많이 들어간 키도 포함됩니다. 그래서 슈퍼키는 가장 넓은 개념이라고 보면 됩니다.
후보키는 유일성 + 최소성을 만족하는 키입니다.
즉,
- 유일하게 식별할 수 있어야 하고
- 쓸데없는 컬럼이 없어야 합니다.
예를 들어 users 테이블에서
idemail
은 각각 후보키가 될 수 있습니다.
반면 id + name은 유일하게 식별할 수는 있지만, id만으로 충분하므로 최소성이 깨집니다. 따라서 후보키는 아닙니다.
기본키는 후보키 중에서 테이블의 대표 키로 선택한 것입니다.
예를 들어 id와 email이 모두 후보키라면, 이 중 하나를 기본키로 정할 수 있습니다. 실무에서는 보통 숫자형 id 같은 컬럼을 PK로 두는 경우가 많습니다.
기본키는 보통 아래 성질을 가집니다.
- 중복 불가
- NULL 불가
- 한 테이블의 대표 식별자
CREATE TABLE users (
id BIGINT PRIMARY KEY,
email VARCHAR(255) UNIQUE,
name VARCHAR(100)
);
여기서 id는 기본키이고, email은 후보키이면서 대체키가 될 수 있습니다.
대체키는 후보키 중에서 기본키로 선택되지 않은 나머지 키입니다.
예를 들어,
id를 PK로 선택했다면email은 대체키가 됩니다.
즉, 충분히 식별 가능한 값이지만 대표키로 쓰지 않은 경우입니다.
실무에서는 이런 대체키에 UNIQUE 제약을 두는 경우가 많습니다.
외래키는 다른 테이블의 기본키를 참조하는 컬럼입니다.
예를 들어 주문 테이블이 회원 테이블과 연결된다고 해보겠습니다.
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
user_id BIGINT,
FOREIGN KEY (user_id) REFERENCES users(id)
);
여기서
users.id는 기본키orders.user_id는 외래키
입니다.
외래키를 쓰면 좋은 점은
- 잘못된 참조를 막을 수 있고
- 테이블 간 관계가 분명해지고
- 데이터 정합성을 높일 수 있다는 것입니다.
| 종류 | 의미 | 포인트 |
|---|---|---|
| 슈퍼키 | 유일하게 식별 가능한 모든 키 집합 | 불필요한 컬럼 포함 가능 |
| 후보키 | 유일성과 최소성을 만족하는 키 | PK 후보가 되는 키 |
| 기본키 | 후보키 중 대표로 선택한 키 | NULL 불가, 중복 불가 |
| 대체키 | 후보키 중 PK로 선택되지 않은 키 | 보통 UNIQUE로 관리 |
| 외래키 | 다른 테이블의 PK를 참조하는 키 | 테이블 간 관계 형성 |
기본키를 쓰는 시기
- 테이블을 만들 때 대표 식별자가 필요할 때
- 한 행을 정확히 조회/수정/삭제해야 할 때
외래키를 쓰는 시기
- 회원과 주문, 주문과 주문상세처럼 관계를 만들 때
- 참조 무결성을 유지하고 싶을 때
대체키를 쓰는 시기
- PK는 숫자 ID로 두고, 이메일/사번/학번처럼 유일해야 하는 값도 함께 보장할 때
즉,
- PK는 내부 대표 식별자
- FK는 관계 연결자
- 대체키는 비즈니스 유일값
정도로 기억하면 됩니다.
실무에서는 보통 이렇게 많이 갑니다.
1) PK는 단순하고 안정적인 값으로 둔다
보통 BIGINT AUTO_INCREMENT나 UUID 같은 값을 PK로 둡니다.
왜냐하면 이름, 이메일처럼 업무 속성은 바뀔 수 있기 때문입니다. 반면 PK는 바뀌지 않는 편이 좋습니다.
2) 이메일, 사번, 주문번호 등은 대체키/UNIQUE로 관리한다
비즈니스적으로 유일해야 하는 값은 별도로 UNIQUE 제약을 두고 관리합니다.
3) 관계는 FK로 명확하게 만든다
회원-주문, 주문-결제, 게시글-댓글처럼 관계를 FK로 연결하면 데이터 정합성이 좋아집니다.
4) FK 제약은 성능/운영 방식까지 보고 결정한다
대부분은 FK가 유리하지만, 대용량 분산 환경이나 운영 구조에 따라 애플리케이션 레벨에서 무결성을 관리하는 경우도 있습니다.
1) 기본키 = 무조건 숫자여야 한다?
아닙니다. 다만 실무에서는 관리 편의상 숫자형 PK를 많이 씁니다.
2) 이메일을 PK로 쓰면 안 된다?
가능은 하지만, 바뀔 가능성과 연결 영향까지 고려해야 합니다.
3) FK는 없어도 된다?
없어도 동작은 할 수 있지만, 정합성 보장은 약해질 수 있습니다.
4) 후보키/슈퍼키는 실무에서 쓸모 없다?
직접 용어를 자주 말하지는 않아도, PK 설계를 이해하려면 매우 중요한 개념입니다.
초보 단계에서는 우선 이렇게 기억하면 충분합니다.
DB Key는 데이터를 구분하고 연결하는 규칙이고, 실무에서는 PK로 식별하고 FK로 연결한다고 기억하면 됩니다.
'IT > SQL·DB' 카테고리의 다른 글
| 실행계획(Execution Plan) 보는 방법, 느린 쿼리 잡는 핵심 (0) | 2026.03.25 |
|---|---|
| 데이터베이스 정규화 vs 반정규화, 언제 써야 할까? (0) | 2026.03.25 |
| SQL JOIN 완벽 정리, INNER JOIN·LEFT JOIN·RIGHT JOIN 차이 한 번에 이해하기 (0) | 2026.03.24 |
| ORM이란 무엇인가? JPA 포함 개념 정리와 SQL과의 차이 (0) | 2026.03.24 |
| [MariaDB] CentOS7에 MariaDB 설치 (0) | 2022.08.04 |