데이터 무결성 설계

핵심 요약

무결성은 데이터가 업무 규칙에 맞게 정확하고 일관된 상태를 유지하는 성질이다. PK는 행의 유일·필수 식별, UK는 대체키 유일성, FK는 부모-자식 참조, NOT NULL·CHECK·데이터 타입은 도메인 범위를 통제한다. 여러 행의 합계·기간 중복·상태 전이처럼 선언적 제약만으로 표현하기 어려운 규칙은 트리거·서비스·배치 검증을 사용할 수 있지만, 동시 트랜잭션과 모든 입력 경로에서 같은 규칙이 적용되는지 확인해야 한다.

학습 목표

• 개체·키·참조·도메인·업무 무결성을 구분한다.
• PK·UK·FK·NOT NULL·CHECK의 역할과 한계를 설명한다.
• FK의 선택성·삭제 동작·복합키를 업무 생명주기에 맞게 설계한다.
• DB 제약과 애플리케이션 통제의 장단점 및 동시성 위험을 평가한다.

1. 무결성 유형

1.1 개체 무결성

각 테이블 행을 유일하게 식별하고 식별값이 NULL이 되지 않도록 한다. 일반적으로 PK가 구현 수단이다.

• 테이블당 주 PK는 하나지만 여러 컬럼으로 구성할 수 있다.
• PK는 UNIQUE와 NOT NULL의 의미를 함께 가진다.
• 대리키 PK를 사용해도 업무상 유일한 자연키가 사라지는 것은 아니다. 자연키는 UK나 업무 제약으로 보존한다.

1.2 키 무결성

후보키·대체식별자의 유일성을 보장한다.

회원 PK: 회원ID
대체키: 이메일주소, 외부회원번호

이메일을 대체키로 인정했다면 PK 외에 유일성 통제가 필요하다. NULL을 허용하는 UK의 중복 처리, 대소문자·공백·정규화는 DBMS와 도메인 규칙에 따라 달라지므로 실제 표현식을 검토한다.

1.3 참조 무결성

자식 FK의 비NULL 값이 부모의 PK 또는 유일키에 존재하도록 한다.

주문.고객ID → 고객.고객ID

FK 컬럼이 NULL 허용이면 “부모 없음”이 가능할 수 있다. 논리 관계가 필수라면 NOT NULL도 필요하다. 복합 FK는 컬럼 수·순서·타입을 부모 키와 맞춰야 한다.

1.4 도메인 무결성

속성 값이 정의된 타입·길이·범위·단위·허용값을 따르도록 한다.

• 데이터 타입·길이·정밀도
• NOT NULL
• CHECK 범위와 값 조합
• 코드 테이블 FK
• 명시적 기본값

기본값은 유효한 값 생성에 도움을 주지만 그 자체가 범위·참조 무결성을 보장하지 않는다.

1.5 업무·의미 무결성

단일 컬럼 제약보다 복잡한 규칙이다.

• 주문총액 = 주문라인 합계
• 같은 계약의 유효기간은 중복 금지
• 고객별 기본배송지는 정확히 한 건
• 주문상태는 허용된 순서로만 전이
• 출고수량은 주문수량을 초과할 수 없음

이 규칙은 설계 시 명시하고 DB 선언 제약, 유일 인덱스, 트리거, 서비스 트랜잭션, 직렬화·잠금, 주기 검증 중 적합한 조합으로 구현한다.

2. 제약조건의 역할

3. 참조 동작 설계

부모 삭제·키 변경 시 자식을 어떻게 할지 업무 생명주기로 결정한다.

주문·결제처럼 법적 보존이 필요한 데이터에는 고객 삭제를 CASCADE로 전파하는 것이 부적절할 수 있다. 삭제 대신 비활성화·익명화·접근 제한을 검토한다.

4. DB 통제와 애플리케이션 통제

4.1 DB 제약을 우선 검토하는 이유

• 여러 애플리케이션·배치·관리자 도구에 동일 규칙 적용
• 동시 트랜잭션에서 중앙 일관성 확보
• 데이터 사전과 DDL에 규칙이 가시적
• 위반 데이터가 저장되기 전에 차단

4.2 애플리케이션 통제가 필요한 경우

• 외부 서비스 결과와 함께 판단하는 규칙
• 복잡한 상태 전이와 사용자 권한·승인 흐름
• 여러 시스템을 아우르는 분산 트랜잭션
• 상세한 오류 메시지와 보상 작업

그러나 “먼저 SELECT로 중복 확인 후 INSERT”만 수행하면 두 세션이 동시에 통과할 수 있다. 최종 유일성은 UK 같은 DB 제약이나 적절한 동시성 제어로 보장해야 한다.

4.3 대량 적재와 제약 비활성화

성능을 이유로 제약을 비활성화하거나 지연 검증할 때는 다음을 정의한다.

1. 적재 전 원천 검증
2. 적재 후 전체 제약 검증
3. 오류행 격리·재처리
4. 제약 재활성화 실패 시 롤백
5. 비활성화 시간 동안의 동시 DML 차단

제약을 껐다는 사실이 데이터 품질 책임을 없애지 않는다.

5. DDL 사례

요구:

• 주문은 반드시 존재하는 고객에 속한다.
• 주문번호 외에 채널별 외부주문번호가 유일하다.
• 주문금액은 0 이상이다.
• 주문상태는 정해진 코드만 허용한다.

아래 SQL은 무결성 매핑을 보여 주는 예시이며 데이터 타입·제약 문법은 DBMS별로 조정한다.

CREATE TABLE ORDERS (
  ORDER_ID BIGINT PRIMARY KEY,
  CUSTOMER_ID BIGINT NOT NULL,
  CHANNEL_CODE VARCHAR(10) NOT NULL,
  EXTERNAL_ORDER_NO VARCHAR(50) NOT NULL,
  ORDER_AMOUNT DECIMAL(15,2) NOT NULL,
  ORDER_STATUS_CODE VARCHAR(20) NOT NULL,

  CONSTRAINT UK_ORDERS_EXTERNAL
    UNIQUE (CHANNEL_CODE, EXTERNAL_ORDER_NO),
  CONSTRAINT FK_ORDERS_CUSTOMER
    FOREIGN KEY (CUSTOMER_ID) REFERENCES CUSTOMER(CUSTOMER_ID),
  CONSTRAINT FK_ORDERS_STATUS
    FOREIGN KEY (ORDER_STATUS_CODE)
    REFERENCES ORDER_STATUS_CODE(ORDER_STATUS_CODE),
  CONSTRAINT CK_ORDERS_AMOUNT
    CHECK (ORDER_AMOUNT >= 0)
);

주문라인 합계=주문금액은 여러 행을 참조하므로 위 DDL만으로 자동 보장되지 않는다. 주문 확정 트랜잭션, 저장 파생값 통제, 주기 대조를 추가 설계한다.

6. 무결성 설계 절차

업무 규칙 목록화
  ↓
개체·키·참조·도메인·업무 무결성으로 분류
  ↓
PK·UK·FK·NOT NULL·CHECK로 선언 가능한 규칙 우선 매핑
  ↓
교차 행·상태·기간 규칙의 트랜잭션·동시성 통제 설계
  ↓
온라인·배치·인터페이스·관리자 우회 경로 검증
  ↓
정상·경계·동시·대량 적재·복구 시나리오 시험

7. 비교와 구분

시험 판단 포인트

• 대리키 PK를 채택해도 업무 대체키의 유일성 규칙은 UK 등으로 보존한다.
• 필수 참조 관계는 FK 존재뿐 아니라 FK 컬럼의 NOT NULL 여부를 확인한다.
• CHECK는 일반적으로 한 행의 값 범위·조합에 적합하고 교차 행 규칙은 추가 통제가 필요하다.
• CASCADE가 편리하다는 이유만으로 보존 데이터에 적용하지 않는다.
• 애플리케이션 사전 조회만으로 동시 중복을 완전히 방지할 수 없다.

자주 틀리는 부분

• PK가 있으면 모든 업무 중복이 막힌다고 본다.
• FK 컬럼이 NULL이면 참조 검사에서 제외될 수 있다는 점을 놓친다.
• 화면 입력 검증을 모든 데이터 경로의 무결성으로 간주한다.
• 기본값을 CHECK나 코드 FK의 대체물로 사용한다.
• 제약 비활성화 후 검증·오류 격리 없이 운영 데이터를 공개한다.