[DB] 03. 키(Key)와 테이블 간 관계 (PK / FK)

[DB] 03. 키(Key)와 테이블 간 관계 (PK / FK)

1. 키(Key)가 필요한 이유

테이블에 행이 쌓이면 “각 행을 구분할 기준”이 필요하다. 이 기준이 없으면 특정 데이터를 정확히 찾거나 수정하기가 어려워진다.

이름(name)처럼 사람 눈에는 구분되는 값도, 데이터가 쌓이면 중복될 수 있다. 그래서 보통 의미 없는 숫자 ID를 기준으로 삼는다.

2. 기본 키(Primary Key, PK)

기본 키는 테이블의 각 행을 유일하게 식별하는 컬럼(또는 컬럼 조합)이다.

• 중복될 수 없다
• NULL이 될 수 없다

users 예시

컬럼명	역할
id	PK(회원 식별자)
email	UNIQUE로 중복 방지 가능

PK를 의미 없는 값으로 두는 이유는 단순하다. 값 자체가 의미를 가지면 바뀔 가능성이 커지고, 그 순간부터 데이터 변경 비용이 커지기 때문이다.

3. 후보키(Candidate Key)와 대체키(Alternate Key)

후보키는 PK가 될 수 있는 후보들이다(유일성 + 최소성 만족). 그중 하나를 PK로 선택하고, 나머지는 대체키라고 부른다.

실제로는 PK는 id로 두고, email에는 UNIQUE 제약을 걸어 “중복 불가”만 보장하는 경우가 많다.

4. 외래 키(Foreign Key, FK)

외래 키는 다른 테이블의 PK를 참조하는 컬럼이다.

orders 예시

컬럼명	역할
id	PK(주문 식별자)
user_id	FK(users.id 참조)

FK를 설정한다는 건, orders.user_id에 들어가는 값이 users.id에 실제로 존재해야 한다는 규칙을 DB에 걸어두는 것이다. 이 규칙이 있어야 “관계”가 데이터베이스 차원에서 보장된다.

5. 키가 없으면 생기는 문제

• 데이터를 정확히 찾기 어렵다
• 수정/삭제 기준이 모호해진다
• 관계(연결)가 끊어진 데이터가 생기기 쉽다

키는 조회를 편하게 하는 도구이기도 하지만, 그보다 “데이터가 무너지지 않게 잡아주는 기준점”이라는 성격이 더 크다.

6. 정리

• PK는 행을 유일하게 식별한다(중복/NULL 불가)
• FK는 다른 테이블의 PK를 참조해 관계를 만든다
• 관계는 의미가 아니라 “규칙(참조 제약)”으로 보장된다