데이터 무결성을 지키는 식별자와 키 설계

행을 구분하는 기준이 데이터 설계를 좌우한다

식별자는 데이터베이스에서 엔터티를 지칭하고 구분하는 속성 또는 속성 그룹이다. 같은 엔터티 안의 각 인스턴스를 유일하게 가려내는 기준점이므로, 데이터 무결성을 유지하는 데 직접 관여한다.

식별자로 쓰려면 다음 성질을 갖춰야 한다.

• 유일성(Uniqueness): 테이블 안에서 중복되지 않는 값을 가져야 한다. 학생 테이블의 학번이 이에 해당한다.
• 최소성(Minimality): 필요한 최소 속성만 포함해야 한다. 주민등록번호만으로 구분할 수 있는데 주민등록번호와 이름을 함께 식별자로 쓰면 관리 복잡성이 커지고 성능에도 영향을 준다.
• 불변성(Immutability): 식별자로 정한 값은 바뀌지 않아야 한다. 휴대폰 번호처럼 변경될 수 있는 속성은 주 식별자로 적합하지 않다.
• 존재성(Existence): 모든 인스턴스는 식별자를 가져야 하며 NULL일 수 없다. 주문 테이블의 주문번호가 없는 주문은 엔터티로서 식별할 수 없다.

키는 식별자 역할에 따라 구분된다

기본키는 테이블의 각 행을 유일하게 식별하는 컬럼 또는 컬럼 조합이다. NULL을 허용하지 않고 중복값도 허용하지 않는다. 사원 테이블의 사원번호가 대표적인 예다.

후보키는 기본키가 될 수 있는 자격을 가진 컬럼 또는 컬럼 조합으로, 유일성과 최소성을 만족한다. 학생 테이블에서 학번과 주민등록번호는 모두 후보키가 될 수 있다. 이 가운데 기본키로 선택되지 않은 후보키는 대체키가 된다. 사원번호를 기본키로 쓸 때 주민등록번호는 대체키가 될 수 있다.

슈퍼키는 유일성은 만족하지만 최소성을 충족하지 못하는 키다. (학번, 이름)이나 (주민등록번호, 주소)처럼 하나 이상의 컬럼을 묶어 행을 구분할 수 있지만, 불필요한 속성이 포함될 수 있다.

외래키는 다른 테이블의 기본키를 참조하는 컬럼이다. 테이블 간 관계를 설정하고 참조 무결성을 보장한다. 주문 테이블의 고객ID가 고객 테이블의 고객ID를 참조하는 경우가 여기에 해당한다.

⤢✕

업무 의미와 생성 주체로 식별자를 나눈다

식별자는 대표성, 생성 주체, 속성 수, 대체 여부에 따라 다른 관점으로 분류할 수 있다.

주 식별자는 업무에서 가장 중요한 대표 식별자다. 고객 테이블의 고객번호처럼 엔터티를 대표한다. 보조 식별자는 주 식별자 외에 보조적으로 쓰이며, 고객 테이블에서 유일성이 보장된 이메일 주소가 예가 될 수 있다.

내부 식별자는 시스템이 직접 생성한다. 자동 증가 sequence 번호와 UUID가 이에 속한다. 반대로 주민등록번호나 사업자등록번호처럼 외부에서 만들어져 시스템으로 들어오는 값은 외부 식별자다.

사원번호나 상품코드처럼 하나의 속성으로 이루어진 것은 단일 식별자다. (학과코드, 학번), (주문번호, 상품코드)처럼 둘 이상의 속성으로 만든 것은 복합 식별자다.

업무에서 본래 사용되는 주민등록번호나 계좌번호는 원조 식별자다. 원조 식별자가 복잡하거나 관리가 어려울 때 이를 대신하기 위해 쓰는 값은 대리 식별자다. 대리 식별자는 주로 시스템이 자동 생성한 일련번호이며, 여러 복합키를 단일 시퀀스 번호로 대신할 수 있다.

⤢✕

기본키는 사용성과 안정성을 함께 본다

기본키를 정할 때는 조인이나 검색에 자주 쓰이는 속성을 우선 검토한다. 사번이나 주민번호처럼 사용 빈도가 높은 속성이 후보가 될 수 있다.

고객명, 상품명처럼 명칭을 나타내는 속성은 변경될 수 있고 중복도 가능하므로 기본키에 적합하지 않다. 복합키 역시 속성이 지나치게 많아지면 관리가 복잡해진다. 3개 이상의 컬럼이 복합키를 이룬다면 대리키를 고려할 수 있다. 예를 들어 주문상세에서 (주문번호, 상품코드, 옵션코드, 색상코드) 대신 주문상세ID 하나를 대리키로 둘 수 있다.

운영 기간 동안 변경 가능성이 낮고 업무적으로 안정적인 값을 선택하는 것도 기본키 설계의 조건이다.

무결성 제약은 키와 데이터 값을 함께 통제한다

본질적 제약은 데이터 모델의 구조적 특성에서 비롯된다. PK는 유일한 식별자라는 제약을 가지며, Unique Key는 중복을 막는다. 이 제약은 데이터베이스 스키마를 정의할 때 명시적으로 선언된다.

내재적 제약은 데이터 의미를 정확히 표현하고 오류를 막기 위한 제약이다. FK는 참조 무결성을, Check는 값의 범위나 조건을, Default는 기본값을, Not Null은 NULL 값 방지를 담당한다. 이런 제약은 데이터 모델링 단계에서 설계된다.

명시적 제약은 프로그램에 선언하거나 사용자가 수작업으로 만드는 제약이다. 비즈니스 로직 구현을 위한 프로그래밍 방식의 제약이며, 트리거나 저장 프로시저 등을 통해 구현한다.

⤢✕

참조 관계와 값의 범위를 제약으로 관리한다

참조 무결성 제약은 Foreign Key를 통해 두 관계의 튜플 간 일관성을 유지한다. 참조 무결성이 위반될 수 있는 상황에서는 다음 처리를 적용할 수 있다.

• Restrict: 참조 중인 데이터의 변경 또는 삭제를 금지한다.
• Cascade: 참조 데이터가 변경 또는 삭제되면 연관 데이터도 함께 변경 또는 삭제한다.
• Nullify: 참조 데이터를 삭제할 때 참조하던 FK를 NULL로 설정한다.
• Default: 참조 데이터를 삭제할 때 FK를 기본값으로 설정한다.

외래키나 트리거로 이를 구현할 수 있다.

도메인 제약은 컬럼 값이 허용된 범위와 조건 안에 있는지 다룬다. Check는 CHECK (급여 >= 최저임금)처럼 조건을 검증하며, Default는 DEFAULT '일반회원'처럼 값이 입력되지 않았을 때 기본값을 지정한다. Not Null은 필수 입력 항목의 NULL 입력을 막는다. Rule은 데이터베이스 시스템에 따른 사용자 정의 규칙으로, MS SQL Server의 Rule 객체가 예다.

관계 모델에 키를 적용하는 방식

온라인 쇼핑몰에서는 고객 테이블에 고객ID(PK, 내부식별자), 이메일주소(대체키), 주민등록번호(외부식별자)를 둘 수 있다. 주문 테이블은 주문번호(PK), 고객ID(FK), 주문일시로 구성한다. 주문상세 테이블은 주문번호(FK), 상품코드(FK), 수량, 가격을 두고 (주문번호, 상품코드)를 복합키로 사용하거나 주문상세ID를 대리키로 도입해 단일 PK로 설계할 수 있다.

학사관리 시스템에서는 학과 테이블의 학과코드를 PK로 둔다. 학생 테이블은 학번(PK), 학과코드(FK), 주민등록번호(대체키)를 사용한다. 수강 테이블은 학번(FK), 과목코드(FK), 학기코드(FK), 성적으로 구성하며 (학번, 과목코드, 학기코드)를 복합 PK로 쓸 수 있다.

병원 관리 시스템에서는 환자 테이블에 환자번호(PK, 대리식별자)와 주민등록번호(원조식별자)를 둔다. 의사 테이블은 의사번호(PK)와 면허번호(대체키)를 사용한다. 진료 테이블은 진료번호(PK), 환자번호(FK), 의사번호(FK), 진료일시로 구성하며, 진료번호는 내부식별자로 시스템에서 자동 생성한다.

성능·확장성·보안까지 고려한다

키 컬럼은 인덱스로 자동 생성되므로 데이터 타입과 길이가 성능에 영향을 준다. 정수형처럼 작은 데이터 타입을 선호하고, 문자형은 가능한 짧게 설계한다. 복합키는 인덱스 크기를 키워 성능 저하 가능성이 있다. 복합키에서는 카디널리티가 높은 속성을 앞에 배치하고, 값이 고르게 분포하는 속성을 선택하는 편이 좋다. 자주 조인되는 테이블의 외래키에도 인덱스를 생성해 조인 성능을 고려한다.

비즈니스 요구사항 변화에 대응할 수 있는 유연한 키 설계도 필요하다. 대리키를 쓰는 경우 외부 시스템과의 통합을 고려하고, 번호 체계가 바뀔 가능성까지 감안해 여유 있는 자릿수를 설계한다.

문서형 데이터베이스(MongoDB)는 _id 필드로 문서를 식별하고, 키-값 저장소(Redis)는 키 자체가 데이터 접근의 기본 메커니즘이 된다. 칼럼형 데이터베이스(Cassandra)는 파티션 키와 클러스터링 키를 활용한다. 분산 환경에서는 샤딩(Sharding)에 적합한 키를 선택해야 하며, UUID는 중앙 집중식 시퀀스 없이 고유 식별자를 생성하는 데 활용할 수 있다. 비즈니스 로직과 기술적 요구사항을 함께 만족해야 한다면 복합 식별자도 선택지가 된다.

주민등록번호처럼 개인정보를 키로 쓸 때는 암호화 등 보안 대책이 필요하다. 외부에 노출될 수 있는 키 역시 보안 위험을 함께 검토해야 한다.