주 키

주 키는 데이터베이스에서 테이블의 각 레코드를 고유하게 식별하는 데 사용되는 하나 이상의 열의 집합이다. 이는 관계형 데이터베이스 설계의 핵심 개념으로, 기본 키와 동일한 의미를 지닌다. '주 키'라는 용어는 '기본 키'를 의미하는 영어 'Primary Key'의 직역에 가깝다.

주 키는 후보 키 중에서 데이터베이스 설계자가 테이블의 주요 식별자로 선택한 하나의 키를 의미한다. 하나의 테이블에는 여러 개의 후보 키가 존재할 수 있지만, 주 키는 그 중 오직 하나만 지정된다. 이 선택된 주 키는 개체 무결성을 보장하는 근간이 된다.

주 키로 지정된 열 또는 열의 조합은 유일성과 최소성을 반드시 만족해야 한다. 즉, 테이블 내 모든 레코드의 주 키 값은 서로 달라야 하며(유일성), 주 키를 구성하는 열들은 꼭 필요한 최소한의 열만으로 구성되어야 한다(최소성). 이러한 특성은 데이터의 정확한 식별과 효율적인 관계 설정을 가능하게 한다.

후보 키는 데이터베이스의 테이블에서 주 키가 될 수 있는 모든 키를 의미한다. 즉, 테이블 내 각 레코드를 유일하게 식별할 수 있는 하나 이상의 속성 또는 속성들의 집합이다. 후보 키는 주 키의 후보 자격을 가지므로, 주 키를 선정하기 전에 먼저 모든 후보 키를 식별하는 과정이 필요하다.

후보 키는 주 키가 되기 위해 반드시 두 가지 핵심 조건을 만족해야 한다. 첫 번째는 유일성으로, 키의 값이 테이블 내 모든 레코드에 대해 중복되지 않고 고유해야 한다. 두 번째는 최소성으로, 레코드를 식별하는 데 꼭 필요한 속성만으로 구성되어야 한다. 불필요한 속성이 포함된 키는 후보 키가 될 수 없다.

하나의 테이블에는 여러 개의 후보 키가 존재할 수 있다. 이 중 데이터베이스 설계자가 하나를 선택하여 공식적인 주 키로 지정하며, 선택받지 못한 나머지 후보 키는 대체 키라고 부른다. 후보 키의 개념은 관계형 데이터베이스의 정규화 과정과 데이터 무결성을 유지하는 데 중요한 기초가 된다.

주 키의 유일성은 데이터베이스 내에서 각 레코드를 고유하게 식별할 수 있는 근본적인 속성이다. 이는 주 키로 지정된 열 또는 열들의 조합(복합 키) 값이 테이블에 존재하는 모든 행에서 중복되지 않고 반드시 하나만 존재해야 함을 의미한다. 이 유일성 덕분에 데이터베이스 시스템은 특정 레코드를 정확히 찾아내고, 데이터 무결성을 유지하며, 다른 테이블과의 관계를 설정하는 외래 키가 참조할 수 있는 안정적인 기준점을 확보한다.

유일성은 주 키가 후보 키의 자격 요건 중 하나이기도 하다. 여러 후보 키 중 하나를 주 키로 선택하면, 나머지 후보 키들은 대체 키가 되어 유일성은 유지하지만 주 키로서의 역할은 수행하지 않게 된다. 유일성을 보장하기 위해 데이터베이스 관리 시스템(RDBMS)은 주 키 제약 조건을 생성할 때 자동으로 해당 열에 대해 유일 인덱스를 생성하는 것이 일반적이다.

이 속성은 데이터베이스 설계에서 매우 중요하며, 주 키 값의 중복은 시스템에 의해 철저히 차단된다. 예를 들어, 주민등록번호나 사원번호와 같이 본질적으로 고유한 값을 가지는 자연 키를 사용하거나, 데이터베이스가 자동으로 생성하는 순차적인 대리 키(예: Auto Increment)를 활용하여 유일성을 실현한다. 유일성이 훼손되면 데이터의 정확한 조회, 수정, 삭제가 불가능해지고 참조 무결성이 깨질 수 있으므로, 이는 절대적인 요구사항으로 간주된다.

주 키는 후보 키의 조건 중 하나인 최소성을 만족해야 한다. 최소성은 주 키를 구성하는 속성 집합이 해당 레코드를 유일하게 식별하는 데 꼭 필요한 최소한의 속성들로만 구성되어야 함을 의미한다. 즉, 주 키를 이루는 속성 중 어느 하나라도 제거하면 유일하게 식별하는 능력이 손상되는 경우, 그 속성 집합은 최소성을 가진다고 본다. 이는 데이터의 중복을 최소화하고 데이터베이스의 효율성을 높이는 데 기여하는 중요한 원칙이다.

예를 들어, 학생 테이블에서 학번과 주민등록번호가 각각 유일성을 가진다고 가정하자. 이때 두 속성을 모두 포함한 {학번, 주민등록번호} 조합은 확실히 유일성을 가지지만, 학번 하나만으로도 각 학생을 구분할 수 있으므로 이 조합은 최소성을 만족하지 않는다. 따라서 주 키로 적합하지 않다. 반면, 학번 단독은 유일성과 최소성을 모두 만족하므로 주 키가 될 수 있다.

최소성은 주 키 설계 시 자연 키와 대리 키의 선택에도 영향을 미친다. 자연 키는 비즈니스 의미를 가진 속성(예: 주민등록번호, 이메일)을 사용하는데, 이 속성 자체가 이미 최소 단위이므로 최소성을 자연스럽게 만족한다. 반면, 복합 키를 구성할 때는 각 구성 속성이 정말로 필요한지 신중히 검토해야 한다. 불필요한 속성이 포함되면 저장 공간 낭비와 인덱스 성능 저하를 초래할 수 있다.

이러한 최소성 원칙은 데이터베이스 정규화 과정과도 깊이 연관되어 있다. 정규화의 목표 중 하나가 불필요한 데이터 중복을 제거하는 것이므로, 주 키의 최소성은 효율적인 관계형 데이터베이스 설계의 기본 토대가 된다고 할 수 있다.

주 키의 불변성은 한번 지정된 주 키 값이 해당 레코드의 수명 동안 변경되지 않아야 한다는 속성을 의미한다. 이는 데이터베이스 설계의 핵심 원칙 중 하나로, 데이터 무결성을 유지하는 데 중요한 역할을 한다.

주 키 값이 변경되면, 이를 참조하고 있는 외래 키를 가진 다른 테이블의 레코드들이 참조 무결성을 잃게 되어 데이터 간의 연결이 끊어질 수 있다. 이는 시스템에 심각한 오류를 초래할 수 있으며, 데이터의 정합성을 해치는 주요 원인이 된다. 따라서 불변성은 데이터베이스 내 관계의 안정성과 신뢰성을 보장하기 위한 필수 조건이다.

실제 데이터베이스 관리 시스템에서는 주 키 필드의 값을 변경하려는 시도를 제한하거나, 관련된 모든 외래 키를 함께 업데이트하는 계단식 업데이트와 같은 복잡한 작업을 필요로 한다. 이러한 이유로 주 키는 가능한 한 변경될 여지가 없는 값을 선택하는 것이 바람직하다. 예를 들어, 주민등록번호나 시스템이 부여한 고유한 대리 키가 자연 키보다 불변성을 유지하기에 더 적합한 경우가 많다.

결론적으로, 주 키의 불변성은 데이터베이스의 구조적 안정성을 지탱하는 기반이 되며, 이 원칙을 준수함으로써 데이터의 정확한 관계와 일관된 상태를 장기적으로 유지할 수 있다.

주 키를 설계할 때는 자연 키와 대리 키 중 하나를 선택하는 것이 핵심적인 고려 사항이다. 자연 키는 데이터베이스에 저장되는 엔티티 자체가 가지고 있는 의미 있는 속성(예: 주민등록번호, 이메일 주소, ISBN)을 키로 사용하는 방식이다. 반면, 대리 키는 데이터의 의미와 무관하게 시스템이 생성한 인위적인 식별자(예: 순차적으로 증가하는 숫자, UUID)를 키로 사용한다.

자연 키의 주요 장점은 비즈니스 의미를 내포하고 있어 직관적이라는 점이다. 또한, 별도의 키 생성을 위한 추가 작업이 필요 없어 초기 설계가 간단할 수 있다. 그러나 자연 키는 사용 중인 속성 값이 변경될 수 있어 불변성 원칙을 위반할 위험이 크다. 예를 들어, 이메일 주소나 전화번호는 사용자가 변경할 수 있으므로 이를 주 키로 사용하면 관련된 모든 외래 키 참조를 수정해야 하는 복잡한 문제가 발생한다.

대리 키는 비즈니스 로직과 완전히 분리되어 있어 값의 변경 가능성이 없으므로 불변성을 보장한다. 이는 데이터 무결성을 유지하는 데 매우 유리하다. 또한, 일반적으로 단순한 정수형 데이터를 사용하므로 인덱스 성능이 우수하고, 저장 공간을 절약할 수 있다. 단점은 키 자체가 아무런 의미를 가지지 않아, 쿼리 결과를 직접 해석하기 어렵고, 의미 있는 속성에 대한 중복 제약 조건을 별도로 설정해야 할 수 있다는 점이다.

현대의 데이터베이스 관리 시스템 설계에서는 변경 가능성과 성능을 고려하여 대리 키의 사용이 일반적인 추세이다. 특히 마이그레이션이나 시스템 통합이 빈번한 환경에서는 대리 키가 더욱 안정적인 선택이 될 수 있다. 그러나 특정 도메인에서 절대적으로 불변하면서 유일한 자연 키가 존재한다면, 이를 활용하는 것도 하나의 합리적인 선택이 된다.

단일 키는 하나의 속성만으로 구성된 주 키이다. 반면 복합 키는 두 개 이상의 속성이 조합되어 구성된다. 단일 키는 구조가 단순하고 이해하기 쉬우며, 인덱스 관리와 쿼리 성능 측면에서 일반적으로 유리하다. 많은 시스템에서 대리 키로 사용되는 자동 증가 숫자나 UUID는 대표적인 단일 키의 예이다.

복합 키는 여러 속성의 조합이 하나의 레코드를 유일하게 식별해야 할 필요가 있을 때 사용된다. 예를 들어, 특정 강의의 수강 신청 내역을 저장하는 테이블에서 '학생 번호' 단독으로는 중복이 발생할 수 있지만, '학생 번호'와 '강의 코드'를 함께 사용하면 특정 학생의 특정 강의 신청 기록을 고유하게 식별할 수 있다. 이처럼 비즈니스 로직상 자연스럽게 식별자가 되는 경우에 적용된다.

복합 키를 설계할 때는 최소성 원칙을 준수해야 한다. 즉, 주 키를 구성하는 속성 집합에서 불필요한 속성을 제거하여 가능한 한 적은 수의 속성으로 구성해야 한다. 또한 복합 키의 속성 순서는 인덱스의 효율성에 영향을 미칠 수 있으므로, 쿼리 패턴을 고려하여 자주 사용되고 선택도가 높은 속성을 앞에 배치하는 것이 일반적이다.

복합 키의 사용은 외래 키 참조를 복잡하게 만들 수 있다는 단점이 있다. 다른 테이블에서 이 복합 키를 참조하는 외래 키 역시 동일한 수와 순서의 속성을 모두 가져야 하기 때문이다. 이로 인해 데이터베이스 스키마의 복잡도가 증가하고, 조인 연산이 다소 번거로워질 수 있다. 따라서 신중한 판단이 필요하다.

SQL에서 주 키는 PRIMARY KEY 제약 조건을 사용하여 정의한다. 이 제약 조건은 테이블을 생성할 때 CREATE TABLE 문 내에서 지정하거나, 기존 테이블에 ALTER TABLE 문을 사용하여 추가할 수 있다. PRIMARY KEY를 설정하면 해당 열 또는 열들의 조합은 자동으로 NOT NULL 및 UNIQUE 제약 조건을 가지게 되며, 데이터베이스는 이를 효율적으로 검색하기 위해 자동으로 인덱스를 생성하는 경우가 일반적이다.

주 키를 정의하는 기본 문법은 두 가지 방식이 있다. 첫 번째는 열 수준에서 단일 열을 주 키로 지정하는 방식이다. 이는 CREATE TABLE 문에서 해당 열의 데이터 타입 뒤에 PRIMARY KEY 키워드를 직접 명시하는 방법이다. 두 번째는 테이블 수준에서 하나 이상의 열을 묶어 복합 키로 지정하는 방식이다. 이는 CREATE TABLE 문의 마지막에 PRIMARY KEY (열1, 열2, ...)와 같은 형식으로 작성하며, 두 개 이상의 열 이름을 괄호 안에 나열한다.

대부분의 관계형 데이터베이스 관리 시스템에서는 주 키의 값을 자동으로 증가시키는 자동 증가 기능을 제공한다. MySQL의 AUTO_INCREMENT, PostgreSQL의 SERIAL 또는 GENERATED ALWAYS AS IDENTITY, SQL Server의 IDENTITY 속성이 이에 해당한다. 이는 대리 키를 구현할 때 흔히 사용되는 방법이다. 한편, ALTER TABLE 문을 사용하면 기존 테이블에 주 키를 추가하거나, 이미 존재하는 주 키 제약 조건의 이름을 변경하거나 삭제할 수도 있다.

주 키 제약 조건의 무결성은 데이터베이스 시스템에 의해 엄격하게 관리된다. 시스템은 삽입 또는 갱신 연산 시 주 키의 유일성과 최소성을 검사하여 중복된 값이나 NULL 값이 들어오는 것을 방지한다. 이로 인해 주 키는 레코드를 고유하게 식별하고, 다른 테이블의 외래 키가 참조하는 안정적인 기준점 역할을 수행할 수 있게 된다.

주 키는 데이터베이스의 성능 최적화를 위해 테이블에 생성되는 인덱스와 밀접한 관계를 가진다. 대부분의 관계형 데이터베이스 관리 시스템(RDBMS)에서는 주 키를 정의하면 자동으로 해당 열(또는 열들의 조합)을 기준으로 한 클러스터형 인덱스 또는 비클러스터형 인덱스가 생성된다. 이 인덱스는 주 키 값을 이용한 레코드 검색, 정렬, 그리고 외래 키에 의한 조인 연산의 속도를 획기적으로 향상시키는 핵심 메커니즘으로 작동한다.

주 키와 인덱스의 관계는 데이터베이스의 물리적 저장 구조와 직접적으로 연결된다. 예를 들어, 마이에스큐엘(MySQL)의 인노디비(InnoDB) 스토리지 엔진에서는 주 키가 클러스터형 인덱스로 사용되어, 테이블의 데이터 행 자체가 주 키 값 순서로 물리적으로 정렬되어 저장된다. 이는 주 키를 통한 범위 검색이 매우 빠르게 이루어질 수 있도록 한다. 반면, 엠에스에스큐엘(Microsoft SQL Server)에서는 기본적으로 주 키에 클러스터형 인덱스가 생성되지만, 사용자가 비클러스터형 인덱스로 지정하는 옵션도 제공한다.

주 키 인덱스의 설계는 전체 시스템 성능에 지대한 영향을 미친다. 비효율적인 주 키(예: 길이가 길거나 자주 변경되는 값을 사용)는 인덱스의 크기를 불필요하게 증가시키고, 인덱스 재구성 작업을 빈번하게 유발하여 성능 저하를 일으킬 수 있다. 또한, 복합 주 키로 인덱스가 생성될 경우, 인덱스의 선행 열만을 사용한 검색은 효율적이지만, 후행 열만을 조건으로 하는 검색에는 인덱스가 제대로 활용되지 않을 수 있다. 따라서 주 키 선택은 단순히 레코드를 식별하는 수단을 넘어, 데이터 접근 경로를 정의하는 데이터베이스 성능 설계의 핵심 요소로 고려되어야 한다.

주 키의 가장 기본적이고 핵심적인 용도는 데이터베이스 내의 각 레코드를 고유하게 식별하는 것이다. 테이블에 저장된 모든 행은 서로 구분 가능해야 하며, 주 키는 이 구분을 보장하는 식별자 역할을 한다. 이를 통해 시스템은 특정 레코드를 정확하게 찾아내고, 조작하며, 다른 레코드와 혼동하지 않을 수 있다.

레코드 식별 기능은 데이터 무결성을 유지하는 데 필수적이다. 주 키의 유일성 제약 덕분에 동일한 값을 가진 레코드가 중복으로 삽입되는 것을 방지할 수 있다. 또한 관계형 데이터베이스에서 다른 테이블의 외래 키가 이 주 키 값을 참조함으로써 테이블 간의 논리적 연결, 즉 관계를 설정하는 기반이 된다. 예를 들어, '회원' 테이블의 주 키인 회원번호는 '주문' 테이블에서 어떤 회원이 주문을 했는지를 나타내는 외래 키로 사용될 수 있다.

이러한 식별자로서의 역할은 데이터 조회(SELECT), 수정(UPDATE), 삭제(DELETE) 작업의 정확성과 효율성을 높인다. 데이터베이스 시스템은 주 키를 기반으로 인덱스를 자동 생성하는 경우가 많아, 주 키 값을 이용한 검색 속도가 매우 빠르다. 결과적으로 주 키는 단순히 레코드를 구분하는 것을 넘어, 전체 데이터베이스 구조의 정합성과 성능을 좌우하는 핵심 설계 요소이다.

• Oracle - 기본 키 및 외래 키

• MySQL - 외래 키 제약 조건

• Microsoft SQL Server - 외래 키 관계 만들기

• PostgreSQL - 외래 키

• SQLite - 외래 키 지원

• IBM Db2 - 참조 무결성 제약 조건

• w3schools - SQL FOREIGN KEY

• SQL Tutorial - SQL FOREIGN KEY Constraint

• GeeksforGeeks - SQL | Foreign Key

• TechOnTheNet - SQL: Foreign Keys

외래 키는 관계형 데이터베이스에서 테이블 간의 관계를 정의하고 참조 무결성을 유지하기 위해 사용되는 제약 조건이다. 한 테이블의 열 또는 열의 집합이 다른 테이블의 주 키를 참조할 때, 이 참조하는 열을 외래 키라고 한다. 외래 키는 두 테이블 사이에 논리적 연결을 생성하며, 이를 통해 부모 테이블과 자식 테이블 간의 일대다 관계를 구현한다.

외래 키의 핵심 기능은 참조 무결성을 보장하는 것이다. 이는 자식 테이블에 존재하는 모든 외래 키 값이 반드시 부모 테이블의 주 키 값으로 존재해야 함을 의미한다. 예를 들어, 주문 테이블에 고객ID라는 외래 키가 있다면, 이 값은 반드시 고객 테이블에 존재하는 유효한 주 키 값이어야 한다. 데이터베이스 관리 시스템은 이 제약을 통해 부모 테이블에 없는 값을 자식 테이블에 입력하거나, 부모 테이블의 레코드를 참조하는 자식 레코드가 존재할 때 부모 레코드를 삭제하는 것을 방지할 수 있다.

외래 키는 SQL 문법에서 FOREIGN KEY 제약 조건으로 정의된다. 이를 설정하면 데이터베이스는 자동으로 참조 무결성을 검사하며, 사용자는 CASCADE, SET NULL, RESTRICT와 같은 참조 동작을 정의하여 부모 테이블의 데이터 변경이 자식 테이블에 어떻게 영향을 미칠지 제어할 수 있다. 이는 복잡한 비즈니스 규칙을 데이터베이스 수준에서 안전하게 관리하는 데 필수적이다.

외래 키는 데이터 모델링에서 엔터티 관계도를 물리적 데이터베이스 구조로 변환하는 핵심 요소이다. 이를 통해 분리된 데이터 간의 일관성을 유지하고, 효율적인 조인 연산을 가능하게 하여 데이터 중복을 최소화한다. 따라서 외래 키는 단순한 기술적 제약을 넘어 관계형 데이터베이스의 관계형 특성을 실현하는 근간이 된다.

슈퍼 키는 데이터베이스에서 테이블 내 튜플을 고유하게 식별할 수 있는 하나 이상의 속성의 집합을 말한다. 주 키는 슈퍼 키의 특별한 형태로, 슈퍼 키 중에서 최소성을 만족하는 것을 의미한다. 즉, 모든 주 키는 슈퍼 키이지만, 모든 슈퍼 키가 주 키는 아니다.

슈퍼 키는 유일성만을 만족하면 되기 때문에, 튜플을 식별하는 데 필요하지 않은 추가 속성을 포함할 수 있다. 예를 들어, 학생 테이블에서 '학번' 속성만으로도 각 학생을 고유하게 구분할 수 있으므로 이는 슈퍼 키이자 주 키 후보가 된다. 반면, '학번'과 '이름'의 조합도 중복되지 않는 고유한 식별자가 될 수 있으므로 슈퍼 키가 되지만, '이름' 속성은 식별에 필수적이지 않으므로 최소성을 만족하지 않아 주 키가 될 수 없다.

이러한 개념은 관계형 데이터베이스의 정규화 과정과 무결성 제약 조건을 이해하는 데 중요한 기초가 된다. 슈퍼 키의 집합에서 최소성을 가진 것들을 후보 키로 선정하고, 그중 하나를 최종적으로 주 키로 선택하는 것이 일반적인 데이터베이스 설계 절차이다.

대체 키는 관계형 데이터베이스에서 후보 키 중 하나를 기본 키로 선택한 후, 남은 후보 키들을 지칭하는 용어이다. 즉, 기본 키가 될 수 있는 모든 유일하고 최소한의 속성 집합인 후보 키들 중에서 실제로 기본 키로 지정되지 않은 키들을 의미한다. 하나의 테이블에는 반드시 하나의 기본 키가 존재하지만, 대체 키는 없을 수도 있고 여러 개 존재할 수도 있다.

대체 키는 기본 키와 마찬가지로 유일성과 최소성을 만족해야 한다. 이는 테이블 내 모든 레코드를 고유하게 식별할 수 있는 능력을 보유하고 있음을 의미한다. 따라서 대체 키는 기본 키의 역할을 대체할 수 있는 잠재력을 가진 키로, 기본 키에 문제가 발생하거나 데이터베이스 설계가 변경될 경우 그 자리를 대신할 수 있는 후보이다. 예를 들어, 회원 테이블에서 주민등록번호가 기본 키로 사용된다면, 이메일 주소나 회원 번호와 같은 다른 고유 식별자는 대체 키가 될 수 있다.

데이터베이스 관리 시스템에서는 대체 키에 대해 명시적으로 ALTERNATE KEY라는 제약 조건을 정의하는 경우는 드물다. 대신, 유일 제약 조건을 설정하여 대체 키의 역할을 구현한다. 이는 해당 속성 또는 속성 집합의 값이 테이블 내에서 중복되지 않도록 보장함으로써, 대체 키가 가지는 유일성 조건을 강제하는 효과를 낸다. 따라서 대체 키는 개념적으로 중요한 데이터 무결성 도구이며, 응용 프로그램 로직에서 기본 키 외의 대체 수단으로 레코드를 조회하거나 검증하는 데 활용될 수 있다.