Primary Key

기본 키의 가장 근본적인 특성은 유일성이다. 이는 하나의 테이블 내에서 기본 키의 값이 중복될 수 없음을 의미한다. 각 레코드는 기본 키를 통해 고유한 식별자를 가지며, 이는 데이터베이스가 특정 레코드를 정확히 하나만 가리킬 수 있게 한다. 예를 들어, 주민등록번호를 기본 키로 사용하는 사용자 테이블에서는 동일한 주민등록번호를 가진 두 명의 사용자가 존재할 수 없다.

이러한 유일성은 데이터의 정확성과 무결성을 보장하는 핵심 메커니즘이다. 데이터베이스 시스템은 기본 키 제약 조건을 통해 삽입 또는 갱신 작업 시 자동으로 중복 값을 검사한다. 만약 중복된 기본 키 값을 가진 새로운 레코드를 삽입하려고 시도하면 시스템은 이를 거부하고 오류를 발생시킨다. 이는 데이터 무결성을 유지하고, 후보 키 중에서 기본 키로 선택된 컬럼 집합이 가지는 필수 조건이기도 하다.

유일성은 테이블 간의 관계를 설정하는 데도 필수적이다. 외래 키는 다른 테이블의 기본 키를 참조하여 관계를 형성하는데, 참조 대상인 기본 키가 유일하지 않다면 어떤 레코드를 참조해야 할지 명확히 할 수 없다. 따라서 기본 키의 유일성은 관계형 데이터베이스의 정규화된 구조와 데이터 간의 명확한 연결을 가능하게 하는 기반이 된다.

최소성은 기본 키가 레코드를 유일하게 식별하는 데 필요한 최소한의 컬럼으로만 구성되어야 한다는 특성이다. 즉, 기본 키를 구성하는 컬럼 중 하나라도 제거하면 유일하게 식별하는 능력을 상실하게 되어야 한다. 이 특성은 기본 키를 후보 키 중에서 선택하는 중요한 기준이 된다.

예를 들어, 주민등록번호 컬럼 하나만으로도 각 개인을 유일하게 식별할 수 있다면, 이는 최소성을 만족한다. 반면, '이름'과 '생년월일' 두 컬럼을 함께 사용해야만 유일성을 보장할 수 있는 경우, 이 두 컬럼의 조합은 최소성을 가진 복합 기본 키가 된다. 만약 주민등록번호와 이름을 함께 기본 키로 지정한다면, 이름 컬럼은 식별에 불필요하므로 최소성을 위반하게 된다.

최소성은 데이터 중복을 방지하고 저장 공간을 효율적으로 사용하는 데 기여한다. 또한 불필요한 컬럼이 포함되지 않은 간결한 기본 키는 인덱스의 성능을 최적화하고, 이를 참조하는 외래 키의 관리도 용이하게 만든다. 따라서 기본 키 설계 시 유일성과 함께 최소성을 반드시 검증해야 한다.

불변성은 기본 키가 가져야 하는 중요한 특성 중 하나이다. 이는 기본 키로 지정된 값이 레코드의 생명주기 동안 변하지 않아야 한다는 원칙을 의미한다. 한 번 식별자로 할당된 기본 키 값은 해당 레코드를 대표하는 불변의 식별번호 역할을 하며, 이를 변경하는 것은 시스템적으로 복잡한 문제를 일으킬 수 있다.

기본 키 값이 변경되면, 이를 참조하고 있는 외래 키가 있는 모든 테이블에서 참조 무결성이 깨질 위험이 있다. 데이터베이스는 이를 방지하기 위해 계단식 업데이트와 같은 기능을 제공하기도 하지만, 이는 성능 저하와 예상치 못한 사이드 이펙트를 초래할 수 있다. 따라서 설계 단계에서 불변성을 염두에 두고 자연 키보다는 변경 가능성이 낮은 속성을 선택하거나, 아예 변경되지 않는 대리 키를 사용하는 것이 일반적인 관행이다.

실제 운영 환경에서는 비즈니스 요구사항 변경으로 인해 불변성을 완전히 보장하기 어려운 경우도 있다. 예를 들어, 사용자의 이메일 주소를 자연 키로 사용했다가 정책 변경으로 이메일을 수정할 수 있게 되는 경우가 그 예이다. 이런 상황을 대비하여 기본 키는 오로지 레코드 식별이라는 본연의 목적에만 충실하도록 설계하고, 사용자에게 노출되는 비즈니스 식별자는 별도의 유니크 제약 조건을 가진 컬럼으로 관리하는 것이 바람직하다.

자연 키는 테이블에 저장된 엔티티의 고유한 비즈니스 속성이나 의미 있는 데이터를 그대로 기본 키로 사용하는 방식을 말한다. 예를 들어, 주민등록번호, 이메일 주소, ISBN 번호, 계좌번호 등이 자연 키의 대표적인 예시이다. 이러한 속성들은 그 자체로 업무 규칙에 의해 고유성을 보장받으며, 외부 세계에 이미 존재하는 식별자이기 때문에 '자연스럽게' 키로 사용된다는 특징이 있다.

자연 키를 사용하는 주요 장점은 데이터 자체에 내재된 의미를 그대로 반영한다는 점이다. 키 값만 보고도 해당 레코드가 무엇을 나타내는지 직관적으로 이해할 수 있으며, 별도의 추가 컬럼 없이도 데이터 무결성을 유지할 수 있다. 또한, 대리 키와 달리 새로운 값을 생성하는 오버헤드가 없어 시스템 부하를 줄일 수 있다.

그러나 자연 키는 여러 가지 실무적 어려움을 동반한다. 가장 큰 문제는 시간이 지남에 따라 변경될 가능성이 있다는 점이다. 예를 들어, 이메일 주소는 사용자가 변경할 수 있고, 주민등록번호는 개인정보 보호 정책으로 인해 저장 자체가 제한될 수 있다. 기본 키의 불변성이 훼손되면 이를 참조하는 모든 외래 키를 함께 수정해야 하는 큰 부담이 발생한다. 또한, 길이가 길거나 복잡한 경우(예: 긴 문자열 조합) 인덱스 성능에 부정적인 영향을 미칠 수 있다.

따라서 자연 키는 변경되지 않을 것이 확실하고, 길이가 짧으며, 반드시 NOT NULL 제약을 만족하는 안정적인 속성일 때만 사용하는 것이 바람직하다. 대부분의 현대 데이터베이스 설계에서는 변경 가능성과 성능 문제를 고려하여 인위적으로 생성된 대리 키를 기본 키로 선호하는 경향이 있다.

대리 키는 테이블 내의 데이터 자체와는 무관하게, 단순히 레코드를 식별하기 위한 목적으로 데이터베이스 시스템이 인위적으로 생성하는 기본 키이다. 주로 순차적으로 증가하는 정수 값을 사용하며, 이는 데이터의 논리적 의미를 담지 않는다. 대리 키는 시스템에 의해 자동으로 생성되고 관리되기 때문에, 사용자가 직접 값을 할당하거나 변경할 필요가 없다는 특징을 가진다.

대리 키의 가장 큰 장점은 최소성과 불변성을 쉽게 보장할 수 있다는 점이다. 자연 키가 시간에 따라 변경되거나 길이가 길어질 수 있는 위험이 있는 반면, 대리 키는 보통 단일의 짧은 정수 컬럼으로 구성되며, 한 번 할당된 값은 절대 변경되지 않는다. 이는 외래 키 참조의 안정성을 크게 높여주며, 데이터베이스의 참조 무결성을 유지하는 데 유리하다.

대리 키는 특히 자연 키로 적합한 명확한 속성이 없거나, 자연 키가 너무 길거나 복잡한 경우에 널리 사용된다. 예를 들어, 회원 테이블에서 이메일 주소나 주민등록번호 대신 단순한 회원 번호를 사용하는 것이 대리 키의 전형적인 예이다. 대부분의 현대 관계형 데이터베이스 관리 시스템은 AUTO_INCREMENT(MySQL)나 SEQUENCE(Oracle, PostgreSQL)와 같은 기능을 제공하여 대리 키 생성을 자동화한다.

그러나 대리 키는 데이터 자체의 의미를 반영하지 않기 때문에, 사용자에게 직관적이지 않을 수 있으며, 특정 비즈니스 규칙을 강제하기 어려운 단점도 있다. 따라서 데이터베이스 설계 시에는 데이터의 특성과 애플리케이션의 요구사항을 고려하여 자연 키와 대리 키 중 적절한 방식을 선택해야 한다.

복합 키는 두 개 이상의 컬럼을 조합하여 하나의 기본 키를 구성하는 방식을 말한다. 단일 컬럼만으로는 레코드를 유일하게 식별할 수 없는 경우에 주로 사용된다. 예를 들어, 학생과 수강 과목의 관계를 기록하는 수강 테이블에서는 학생 ID 하나만으로는 특정 레코드를 식별할 수 없으며, 학생 ID와 과목 코드를 함께 묶어야 특정 학생의 특정 과목 수강 이력을 유일하게 가리킬 수 있다.

복합 키를 설계할 때는 유일성과 최소성이라는 기본 키의 특성을 모두 만족시켜야 한다. 즉, 키를 구성하는 컬럼들의 조합은 테이블 내 모든 레코드에 대해 중복되지 않아야 하며(유일성), 그 조합에서 어떤 컬럼이라도 제거하면 유일성을 보장할 수 없어야 한다(최소성). 복합 키는 종종 자연 키의 형태로 나타나며, 실제 업무 데이터에서 의미를 가지는 여러 속성의 조합으로 구성된다.

복합 키의 사용은 데이터 모델링에서 중요한 의미를 가진다. 이는 테이블 간의 관계를 정의하는 외래 키가 여러 컬럼으로 구성될 수 있음을 의미하며, 참조 무결성을 유지하기 위해 복잡성을 증가시킬 수 있다. 또한, 복합 키는 인덱스 구조에 영향을 미쳐, 키를 구성하는 컬럼들의 순서에 따라 쿼리 성능이 달라질 수 있다. 따라서 설계 시 조합의 순서와 빈번하게 사용되는 질의 조건을 고려해야 한다.

SQL 데이터베이스, 즉 관계형 데이터베이스에서 기본 키는 테이블을 정의하는 핵심적인 제약 조건이다. PRIMARY KEY 제약을 통해 지정된 컬럼 또는 컬럼 집합은 데이터베이스 시스템에 의해 자동으로 유일성과 NOT NULL 제약이 부여된다. 이는 테이블 내 모든 레코드가 서로 구분될 수 있도록 보장하며, 데이터 무결성의 기초를 형성한다.

대부분의 SQL 데이터베이스(MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server 등)는 기본 키를 자동으로 관리하는 인덱스를 생성하여 검색 속도를 최적화한다. 이 인덱스는 주로 B-트리 자료 구조를 사용하여 구현되며, 기본 키를 통한 조회가 매우 빠르게 수행될 수 있도록 한다. 또한, 이 인덱스는 외래 키 제약이 참조하는 대상이 되므로, 테이블 간 관계 설정의 기준점 역할을 한다.

기본 키는 CREATE TABLE 문에서 컬럼 정의 시 함께 지정하거나, 테이블 생성 후 ALTER TABLE 문으로 추가할 수 있다. 단일 컬럼으로 구성된 기본 키가 일반적이지만, 필요에 따라 여러 컬럼을 조합한 복합 키를 정의할 수도 있다. 한 테이블에는 오직 하나의 기본 키만 존재할 수 있으며, 이는 여러 후보 키 중에서 선택된 주 식별자에 해당한다.

NoSQL 데이터베이스는 관계형 모델을 따르지 않는 다양한 데이터베이스 시스템을 포괄하는 개념이다. 이들 시스템은 스키마가 유연하거나 없을 수 있으며, 데이터 모델에 따라 키-값 스토어, 문서 데이터베이스, 컬럼형 데이터베이스, 그래프 데이터베이스 등으로 분류된다. 이러한 특성상 기본 키의 개념과 구현 방식도 SQL 데이터베이스와는 차이를 보인다.

키-값 스토어에서는 저장되는 각 값을 식별하는 유일한 키가 기본 키의 역할을 한다. 이 키는 애플리케이션에서 제공하며, 시스템은 이를 통해 데이터를 빠르게 조회한다. 문서 데이터베이스에서는 각 문서를 식별하는 필드가 기본 키 역할을 한다. 예를 들어, MongoDB에서는 _id라는 필드가 각 문서의 유일한 식별자로 사용되며, 사용자가 명시하지 않으면 시스템이 자동으로 생성한다.

그래프 데이터베이스에서는 노드와 관계에 고유한 ID를 부여하여 식별하는 방식을 주로 사용한다. 컬럼형 데이터베이스에서는 행 키(Row Key)가 테이블 내 레코드를 구분하는 기준이 된다. NoSQL 환경에서는 분산 시스템에서의 데이터 일관성과 가용성을 유지하기 위해 기본 키 설계가 매우 중요하며, 파티셔닝과 샤딩 전략에 직접적인 영향을 미친다.

외래 키는 관계형 데이터베이스에서 테이블 간의 관계를 정의하고 참조 무결성을 유지하는 데 사용되는 키이다. 한 테이블의 컬럼이 다른 테이블의 기본 키를 참조할 때, 이 컬럼을 외래 키라고 부른다. 외래 키는 두 테이블 사이에 논리적인 연결을 생성하여 데이터의 일관성을 보장한다.

외래 키의 주요 역할은 참조 무결성을 강제하는 것이다. 이는 외래 키 컬럼에 입력되는 값이 반드시 참조하는 테이블의 기본 키 값으로 존재하거나 NULL 값이어야 함을 의미한다. 이를 통해 존재하지 않는 데이터를 참조하는 오류를 방지할 수 있다. 예를 들어, 주문 테이블의 고객ID 컬럼이 고객 테이블의 기본 키를 외래 키로 참조한다면, 주문을 등록할 때 반드시 실존하는 고객의 ID를 사용해야 한다.

외래 키는 데이터베이스 설계에서 테이블 간의 관계를 명확히 표현하는 수단이 된다. 일대다 관계에서 '다'쪽에 해당하는 테이블에 외래 키가 위치한다. 또한 계층적 질의나 조인 연산을 효율적으로 수행하는 기반이 되기도 한다. 대부분의 데이터베이스 관리 시스템은 외래 키 제약 조건을 설정, 수정, 삭제할 수 있는 기능을 제공한다.

외래 키 사용 시 주의할 점도 있다. 참조하는 기본 키 테이블의 레코드를 삭제하거나 키 값을 변경할 때, 이를 참조하는 외래 키 테이블의 레코드를 어떻게 처리할지에 대한 정책(예: CASCADE, SET NULL, RESTRICT)을 미리 정의해야 한다. 잘못된 정책은 데이터 손실이나 불일치를 초래할 수 있으며, 과도한 외래 키 관계는 시스템 성능에 부정적인 영향을 줄 수도 있다.

후보 키는 관계형 데이터베이스에서 테이블의 각 레코드를 유일하게 식별할 수 있는 하나 이상의 컬럼(열)의 집합이다. 후보 키는 기본 키가 될 수 있는 모든 잠재적인 키를 의미하며, 하나의 테이블에는 여러 개의 후보 키가 존재할 수 있다. 후보 키는 기본 키와 마찬가지로 유일성과 최소성이라는 두 가지 핵심 특성을 반드시 만족해야 한다. 유일성은 키 값이 중복되지 않아야 함을 의미하고, 최소성은 키를 구성하는 컬럼이 꼭 필요한 최소한의 것들로만 이루어져야 함을 뜻한다.

후보 키는 자연스러운 데이터에서 도출된 자연 키일 수도 있고, 데이터베이스 시스템이 생성한 대리 키일 수도 있다. 예를 들어, '주민등록번호'와 '이메일 주소'가 모두 중복되지 않고 NULL 값을 허용하지 않는다면, 한 명의 사용자를 식별하는 후보 키가 두 개 존재하는 것이다. 데이터베이스 설계자는 이러한 후보 키들 중에서 하나를 기본 키로 선택하여 실제로 레코드 식별과 외래 키 참조의 기준으로 사용한다.

후보 키와 슈퍼 키는 구분되는 개념이다. 슈퍼 키는 유일성만 만족하는 컬럼의 집합으로, 최소성을 만족하지 않아도 된다. 예를 들어, '주민등록번호'와 '이름'의 조합은 유일성을 가질 수 있지만, '주민등록번호' 단독으로도 유일성을 가지므로 최소성을 만족하지 않아 슈퍼 키는 될 수 있으나 후보 키는 될 수 없다. 모든 후보 키는 슈퍼 키이지만, 모든 슈퍼 키가 후보 키인 것은 아니다.

후보 키는 데이터 모델링에서 중요한 개념으로, 적절한 후보 키를 식별하는 것은 데이터 무결성을 설계하는 첫걸음이다. 설계자는 테이블의 모든 후보 키를 검토한 후, 비즈니스 요구사항, 성능, 안정성 등을 고려하여 그 중 가장 적합한 하나를 기본 키로 선정하게 된다.

인덱스는 데이터베이스에서 데이터 검색 속도를 향상시키기 위해 사용하는 자료 구조이다. 기본 키는 자동으로 인덱스가 생성되는 경우가 많지만, 인덱스는 검색 조건에 자주 사용되는 다른 컬럼에도 생성할 수 있다. 인덱스를 사용하면 테이블의 모든 데이터를 순차적으로 검색하는 대신, 책의 색인처럼 특정 값을 빠르게 찾을 수 있다.

인덱스는 B-트리나 해시 테이블과 같은 구조로 구현되며, 주로 읽기 성능을 최적화한다. 그러나 인덱스를 관리하기 위한 추가 저장 공간이 필요하고, 데이터를 삽입, 수정, 삭제할 때 인덱스도 함께 갱신해야 하므로 쓰기 성능에는 부담이 될 수 있다. 따라서 어떤 컬럼에 인덱스를 생성할지는 데이터 접근 패턴을 분석하여 신중히 결정해야 한다.

기본 키는 테이블의 레코드를 유일하게 식별하는 역할을 하지만, 인덱스는 검색 효율성을 위한 보조적인 구조이다. 기본 키는 자체가 유일성과 최소성을 만족하는 특별한 인덱스로 볼 수 있으며, 외래 키가 참조하는 대상이 된다. 반면, 인덱스는 후보 키가 아닌 일반 컬럼에도 적용될 수 있고, 유일성을 보장하지 않는 비고유 인덱스도 존재한다.

데이터베이스 성능 튜닝에서 인덱스 설계는 매우 중요한 요소이다. 적절한 인덱스는 쿼리 실행 시간을 획기적으로 줄여주지만, 너무 많은 인덱스는 오히려 시스템 전체 성능을 저하시킬 수 있다. 데이터베이스 관리 시스템은 실행 계획을 분석하여 최적의 인덱스를 사용하는 방법을 결정한다.