데이터베이스에서 PK, FK, 슈퍼키를 제대로 이해하면 단순히 “테이블을 연결하는 방법”을 아는 수준을 넘어, 데이터 무결성 integrity, 중복 제거, 관계형 설계의 논리를 함께 볼 수 있습니다. 특히 relational database 환경에서는 한 테이블 안의 행을 어떻게 식별하고, 다른 테이블과 어떤 관계를 맺는지가 시스템 전체 품질을 좌우합니다.
실무에서는 테이블이 많아질수록 “이 컬럼이 정말 PK인가”, “어떤 컬럼이 FK인지”, “중복 가능성이 있는지”, “복합키인지 단일키인지”를 빠르게 파악할 수 있어야 합니다. 이런 기준이 흔들리면 조인 오류, 중복 데이터, 삭제 불가 문제, 리포트 집계 왜곡이 발생하기 쉽습니다.
슈퍼키와 후보키의 의미
슈퍼키(super key)는 한 행을 유일하게 식별할 수 있는 속성의 집합입니다. 유일성은 만족하지만, 최소성까지 보장하지는 않기 때문에 불필요한 컬럼이 포함될 수 있습니다. 예를 들어 학생 테이블에서 student_id만으로도 식별이 가능하다면, student_id + name도 슈퍼키가 될 수 있지만 더 넓은 의미의 키일 뿐입니다.
후보키(candidate key)는 슈퍼키 중에서 최소성을 만족하는 키입니다. 즉, 특정 행을 식별하는 데 꼭 필요한 속성만 남긴 형태입니다. 실제 설계에서는 후보키가 여러 개 있을 수 있고, 그중 하나를 골라 PK(primary key)로 지정합니다.
정리하면 슈퍼키는 “유일하게 구분 가능하면 됨”, 후보키는 “유일하면서 더 줄일 수 없음”입니다. 이 차이를 이해하면 설계 문서나 ERD를 볼 때 어떤 키가 본질적인 식별자인지 더 명확하게 보입니다.
PK와 FK의 역할
PK(primary key)는 후보키 중 선택된 키로, 테이블의 각 행을 고유하게 식별합니다. SQL Server 기준으로 PK는 유일성과 비어 있지 않음 null 불가 조건을 가지며, 데이터베이스 엔진은 PK에 대해 자동으로 unique index를 만들기도 합니다. 즉 PK는 논리적 식별자이면서 물리적 조회 성능과도 연결됩니다.
FK(foreign key)는 다른 테이블의 PK 또는 unique key를 참조하는 키입니다. FK는 테이블 간 관계를 표현하고, 참조 무결성 referential integrity를 유지합니다. 자식 테이블에 존재하는 FK 값은 부모 테이블에 실제로 존재해야 하며, 이 규칙이 깨지면 관계가 끊어진 데이터가 생깁니다.
예를 들어 Orders.CustomerID가 Customers.CustomerID를 참조한다면, 주문은 반드시 존재하는 고객에 속해야 합니다. 이 구조가 바로 1대다 관계의 전형적인 예이며, FK가 없으면 주문 데이터가 고아 레코드처럼 떠돌 수 있습니다.
PK, FK, 슈퍼키 차이
아래처럼 비교하면 개념이 더 선명해집니다.
| 구분 | 의미 | 유일성 | 최소성 | null 허용 | 다른 테이블 참조 |
| 슈퍼키 | 행을 유일하게 식별 가능한 속성 집합 | O | X | 상황에 따라 다름 | X |
| 후보키 | 최소한의 슈퍼키 | O | O | 일반적으로 X | X |
| PK | 후보키 중 선택된 식별자 | O | O | X | X |
| FK | 다른 테이블의 키를 참조하는 속성 | 상황에 따라 다름 | 해당 없음 | DBMS 규칙에 따름 | O |
이 표에서 가장 중요한 점은 PK와 FK는 “같은 종류의 키”가 아니라는 것입니다. PK는 테이블 내부의 대표 식별자이고, FK는 테이블 간 연결선입니다. 슈퍼키는 그보다 더 넓은 이론적 개념이고, 후보키는 PK의 재료가 됩니다.
실무에서 찾는 방법
PK를 찾는 가장 빠른 방법은 테이블 정의를 확인하는 것입니다. SQL Server에서는 sys.key_constraints, sys.indexes, INFORMATION_SCHEMA.TABLE_CONSTRAINTS 같은 시스템 뷰를 통해 PK 정보를 볼 수 있습니다. 많은 DBMS에서 PK는 자동으로 인덱스와 연결되므로, 인덱스 목록을 보면 후보를 쉽게 찾을 수 있습니다.
FK를 찾을 때는 sys.foreign_keys, sys.foreign_key_columns를 확인하면 됩니다. 부모 테이블, 자식 테이블, delete rule, update rule까지 함께 볼 수 있어 관계 분석에 유용합니다. 또한 FK가 걸린 컬럼은 조인 빈도가 높고, 참조 데이터 품질 점검 대상이 되기 때문에 운영 점검에서도 중요합니다.
슈퍼키를 직접 시스템 뷰에서 “정답처럼” 찾는 것은 어렵습니다. 슈퍼키는 이론적 개념이라서 DBMS가 별도로 저장하지 않으며, 실제로는 unique 제약조건, PK, 복합 unique index 등을 보고 “유일성을 만족하는 후보 집합”을 추론해야 합니다. 즉 슈퍼키는 데이터 모델을 읽고 설계 의도를 파악하는 과정에서 찾는 개념에 가깝습니다.
찾는 실전 절차
- 테이블의 제약조건을 확인합니다. PK, unique constraint, FK를 먼저 봐야 전체 구조가 보입니다.
- 각 컬럼의 null 허용 여부와 중복 여부를 점검합니다. PK 후보는 null이 있으면 안 되고, 중복도 있으면 안 됩니다.
- 복합키 여부를 확인합니다. 단일 컬럼이 아니라 여러 컬럼의 조합이 유일한지 봐야 합니다.
- FK가 참조하는 부모 테이블의 키를 확인합니다. 참조 대상이 PK인지 unique key인지에 따라 설계 의미가 달라집니다.
- 실제 데이터 분포를 확인합니다. 이론상 후보키 같아 보여도, 운영 데이터에서 예외값이 있으면 식별자로 쓰기 어렵습니다.
이 과정을 거치면 단순히 “키를 찾는다”가 아니라 “왜 이 키가 선택되었는지”까지 이해할 수 있습니다. 특히 데이터 마트나 분석계 설계에서는 source system의 키 체계를 그대로 믿지 말고, 실제 데이터 품질과 함께 판단해야 합니다.
잘못 설계될 때 생기는 문제
PK가 부적절하면 한 행을 정확히 식별하지 못해 중복 저장이나 업데이트 오류가 생깁니다. FK가 잘못 잡히면 삭제 시 연쇄 영향이 예상과 다르게 발생하고, orphan row가 쌓이거나 반대로 정상 삭제가 막힐 수 있습니다.
또한 FK 컬럼에 인덱스가 없으면 조인이나 참조 무결성 검사 비용이 커질 수 있습니다. 일부 DBMS 문서는 FK 컬럼 인덱스를 권장하거나 사실상 필요 조건처럼 설명하기도 하며, 대용량 환경에서는 성능 차이가 분명하게 나타납니다.
실무에서 자주 보이는 실수는 “업무적으로 유일해 보이는 값”을 곧바로 PK로 잡는 것입니다. 예를 들어 이메일, 전화번호, 거래번호는 비즈니스 규칙이 바뀌거나 중복 정책이 바뀔 수 있어 장기적으로는 surrogate key가 더 안전한 경우가 많습니다.
데이터베이스의 PK, FK, 슈퍼키는 단순한 시험 개념이 아니라, 데이터를 믿을 수 있게 만드는 설계의 뼈대입니다. 슈퍼키에서 후보키를 거쳐 PK를 고르고, FK로 관계를 연결하는 흐름을 이해하면 SQL 쿼리 작성뿐 아니라 데이터 모델 검토와 품질 점검까지 훨씬 수월해집니다.
놓치면 아쉬운 추천 글, 함께 읽어보세요!
- 추천 글을 불러오는 중입니다...
