길리랩blog

릴레이션 무결성 제약으로 데이터 일관성 지키기

도메인·개체·참조·키·사용자 정의 무결성 제약의 역할과 강제 방법, 위반 처리 방식을 데이터베이스 설계 관점에서 정리합니다.

2026-08-14 · 최초 발행 2025-08-10

데이터 오류를 DBMS가 막도록 설계한다

릴레이션 무결성 제약은 관계형 데이터베이스 안의 정보가 정확하고 일관된 상태를 유지하도록 만드는 규칙 집합이다. 데이터의 신뢰성을 보장하기 위한 장치이며, 설계 단계에서 정의한 뒤 구현과 운영 과정에서 적용한다. DBMS는 이 규칙을 자동으로 검사하고 강제한다.

제약은 단순히 잘못된 입력을 막는 기능에 그치지 않는다. 각 행을 식별하는 방식, 테이블 사이의 관계, 업무 규칙까지 데이터 모델에 명시해 데이터 품질 관리의 기반을 만든다.

속성값부터 테이블 관계까지 다루는 제약

도메인 무결성은 속성값이 해당 속성에 허용된 도메인 안에 있도록 제한한다. 데이터 타입, 형식, 범위, NULL 허용 여부가 여기에 포함된다. CHECK, NOT NULL, DEFAULT 제약조건으로 구현할 수 있다.

CREATE TABLE Employee (
    emp_id INT NOT NULL,
    name VARCHAR(50) NOT NULL,
    age INT CHECK (age >= 18 AND age <= 65),
    email VARCHAR(100) CHECK (email LIKE '%@%.%'),
    salary DECIMAL(10,2) DEFAULT 0.00
);

개체 무결성은 모든 테이블이 기본키를 갖도록 요구한다. 기본키는 NULL일 수 없고 테이블 안에서 유일해야 하므로, 각 개체를 고유하게 식별할 수 있다.

CREATE TABLE Department (
    dept_id INT PRIMARY KEY,
    dept_name VARCHAR(50) NOT NULL,
    location VARCHAR(100)
);

참조 무결성은 외래키로 테이블 간 관계를 유지한다. 외래키 값은 참조 대상 테이블의 기본키 또는 유일키에 존재해야 하며, NULL도 가능하다. 이 제약은 부모-자식 관계가 어긋나는 상황을 막는다.

CREATE TABLE Employee (
    emp_id INT PRIMARY KEY,
    name VARCHAR(50) NOT NULL,
    dept_id INT,
    FOREIGN KEY (dept_id) REFERENCES Department(dept_id)
    ON DELETE SET NULL
    ON UPDATE CASCADE
);

키 무결성은 테이블의 모든 행, 즉 튜플이 반드시 고유하게 식별될 수 있어야 한다는 요구다. 후보키 중 하나를 기본키로 선택하고, 유일성과 최소성을 보장한다. 중복을 허용하지 않는 값에는 UNIQUE 제약조건을 둘 수 있다.

CREATE TABLE Customer (
    customer_id INT PRIMARY KEY,
    email VARCHAR(100) UNIQUE,
    phone VARCHAR(15) UNIQUE,
    name VARCHAR(50) NOT NULL
);

사용자 정의 무결성은 일반적인 키나 값 범위만으로 표현하기 어려운 업무 규칙을 대상으로 한다. 트리거, 저장 프로시저, 애플리케이션 로직을 사용해 데이터의 의미적 일관성을 검사한다.

-- 직원의 급여가 부서 평균 급여의 2배를 초과할 수 없다는 비즈니스 규칙
CREATE TRIGGER check_salary_limit
BEFORE INSERT OR UPDATE ON Employee
FOR EACH ROW
DECLARE
    avg_salary NUMBER;
BEGIN
    SELECT AVG(salary) INTO avg_salary
    FROM Employee
    WHERE dept_id = :NEW.dept_id;

    IF :NEW.salary > avg_salary * 2 THEN
        RAISE_APPLICATION_ERROR(-20001, 'Salary cannot exceed twice the department average');
    END IF;
END;

즉시 검사와 커밋 시점 검사

무결성 제약은 SQL 문을 실행할 때마다 검사할 수도 있고, 트랜잭션을 커밋할 때 검사할 수도 있다.

⤢✕위반 발견통과위반 발견통과데이터 조작 요청즉시 제약조건 검사트랜잭션 거부트랜잭션 처리지연된 제약조건 검사트랜잭션 롤백트랜잭션 커밋

즉시 제약은 모든 SQL 문이 실행될 때마다 조건을 확인한다. 지연 제약은 트랜잭션의 커밋 시점에 제약조건을 검사한다.

스키마 선언과 절차 로직의 역할

선언적 방법은 SQL DDL로 스키마를 정의하면서 제약조건을 명시하는 방식이다. CREATE TABLE이나 ALTER TABLE 문에 제약을 포함하며, DBMS 엔진이 자동으로 검사하고 강제한다. 일반적으로 권장되는 접근이다.

ALTER TABLE Order
ADD CONSTRAINT fk_customer
FOREIGN KEY (customer_id) REFERENCES Customer(customer_id);

절차적 방법은 트리거, 저장 프로시저, 애플리케이션 코드에 검사 로직을 구현한다. 복잡한 비즈니스 규칙처럼 선언적 제약만으로 다루기 어려운 경우에 사용한다.

CREATE TRIGGER check_order_amount
BEFORE INSERT ON Order
FOR EACH ROW
BEGIN
    IF :NEW.amount <= 0 THEN
        RAISE_APPLICATION_ERROR(-20002, 'Order amount must be positive');
    END IF;
END;

참조 관계가 깨질 때 선택할 처리 방식

참조 무결성이 위반될 때 DBMS가 취할 수 있는 처리는 거부, 연쇄, 널 설정, 기본값 설정, 무시로 나뉜다.

거부는 제약을 어기는 연산을 받아들이지 않고 에러 메시지를 반환하며 트랜잭션을 롤백하는 방식이다.

연쇄는 부모 레코드에 적용된 작업을 관련 자식 레코드에도 적용한다. 예를 들어 부서를 삭제할 때 해당 부서의 직원 레코드도 삭제하도록 설정할 수 있다.

FOREIGN KEY (dept_id) REFERENCES Department(dept_id)
ON DELETE CASCADE

널 설정은 참조 대상이 삭제됐을 때 외래키 값을 NULL로 바꾼다. 부서가 삭제되면 해당 부서에 속했던 직원의 dept_id를 NULL로 변경하는 경우가 이에 해당한다.

FOREIGN KEY (dept_id) REFERENCES Department(dept_id)
ON DELETE SET NULL

기본값 설정은 외래키를 미리 정의한 기본값으로 바꾼다. 부서를 삭제하면서 직원들을 기본 부서로 이동시키는 방식으로 사용할 수 있다.

FOREIGN KEY (dept_id) REFERENCES Department(dept_id)
ON DELETE SET DEFAULT

무시는 참조 무결성 위반이 생겨도 별도 조치를 취하지 않는 방식이다. 데이터 불일치를 초래할 수 있으므로 주의가 필요하다.

은행 계좌 관계에 적용한 예

은행 계좌 관리 시스템에서는 고객, 계좌, 거래 사이의 관계에 무결성 제약을 적용할 수 있다.

⤢✕hascontainsCustomerintcustomer_idPKstringnamestringemailUKdatebirth_dateAccountintaccount_idPKintcustomer_idFKdecimalbalancedateopened_datestringstatusTransactioninttransaction_idPKintaccount_idFKdecimalamountdatetransaction_datestringtype

계좌 잔액은 항상 0 이상이어야 하므로 도메인 무결성이 필요하다. 고객, 계좌, 거래는 각각 고유 식별자를 가져야 하며, 존재하지 않는 고객의 계좌나 존재하지 않는 계좌의 거래는 허용되지 않는다. 출금 거래가 계좌 잔액을 초과할 수 없다는 조건은 사용자 정의 무결성으로 표현할 수 있다.

-- 도메인 무결성
ALTER TABLE Account ADD CONSTRAINT chk_positive_balance CHECK (balance >= 0);

-- 참조 무결성
ALTER TABLE Account ADD CONSTRAINT fk_customer
FOREIGN KEY (customer_id) REFERENCES Customer(customer_id);

-- 사용자 정의 무결성 (트리거)
CREATE TRIGGER check_withdrawal
BEFORE INSERT ON Transaction
FOR EACH ROW
DECLARE
    v_balance NUMBER;
BEGIN
    IF :NEW.type = 'WITHDRAWAL' THEN
        SELECT balance INTO v_balance FROM Account WHERE account_id = :NEW.account_id;
        IF v_balance < :NEW.amount THEN
            RAISE_APPLICATION_ERROR(-20003, 'Insufficient funds');
        END IF;
    END IF;
END;

데이터 품질과 운영 복잡성 사이의 선택

무결성 제약은 데이터의 일관성과 정확성을 유지하고, 입력 및 조작 과정의 실수를 예방한다. 업무 규칙을 데이터베이스 수준에서 강제할 수 있으며, 엔티티 간 관계를 명확히 하는 데이터 모델링에도 도움이 된다. DBMS의 자동 검증은 애플리케이션 개발에서 데이터 검증 부담을 줄인다.

반면 무결성 검사는 성능 오버헤드를 일으킬 수 있고, 제약조건이 늘어날수록 데이터베이스 관리가 복잡해진다. 특수한 상황에서는 제약이 업무 처리를 제한할 수 있으며, 분산 데이터베이스에서는 일관된 제약조건 적용이 어렵다. 업무 요구사항과 데이터 관계를 함께 검토해 필요한 제약을 선택해야 한다.

데이터베이스무결성 제약참조 무결성관계형 데이터베이스SQL