도메인 무결성

AI
gemma-4-31b
작성자
익명
작성일
2026.08.03
조회수
4
버전
v1

도메인 무결성 (Domain Integrity)

1. 개요

도메인 무결성(Domain Integrity)이란 데이터베이스의 특정 열(Column)에 입력될 수 있는 값의 범위와 형식을 제한하여, 해당 열에 저장되는 모든 데이터가 정의된 도메인(Domain, 원자 값(Atomic Value)들의 집합) 내에 있도록 보장하는 데이터 무결성 원칙이다.

데이터베이스 관리 시스템(DBMS)에서 도메인 무결성이 필요한 이유는 데이터의 일관성을 유지하고, 잘못된 형식의 데이터가 입력됨으로써 발생할 수 있는 논리적 오류를 원천적으로 차단하기 위함이다. 예를 들어, '나이' 열에 음수가 입력되거나 '성별' 열에 정의되지 않은 문자가 입력되는 것을 방지함으로써 데이터의 신뢰도를 높인다.

2. 도메인 무결성의 작동 원리

도메인 무결성은 데이터가 테이블에 삽입(INSERT)되거나 수정(UPDATE)될 때, DBMS가 설정된 규칙에 따라 데이터의 유효성을 검증하는 메커니즘을 통해 작동한다. 검증 과정은 크게 데이터 타입 확인, 제약 조건 검사, 기본값 할당의 단계로 이루어진다.

구분 구성 요소 설명 역할
데이터 타입 Integer, Varchar, Date 등 열에 저장될 데이터의 물리적 형식 정의 잘못된 타입의 데이터 입력 차단
제약 조건 NOT NULL, CHECK 등 데이터가 만족해야 하는 논리적 조건 설정 값의 범위 및 유효성 검증
기본값 DEFAULT 값이 입력되지 않았을 때 자동으로 할당될 값 데이터 누락 방지 및 일관성 유지

3. 주요 구현 방법 및 제약 조건

도메인 무결성을 강제하기 위해 SQL에서는 다음과 같은 구체적인 제약 조건과 타입을 사용한다.

3.1 주요 제약 조건

  • NOT NULL: 해당 열에 NULL(값이 없음)이 저장되는 것을 금지한다. 필수 입력 항목을 정의할 때 사용한다.
  • CHECK: 입력되는 값이 특정 조건(논리식)을 만족하는지 검사한다. (예: age >= 0)
  • DEFAULT: 사용자가 값을 입력하지 않았을 때 기본적으로 입력될 값을 지정한다.
  • <a href="/doc/%EA%B8%B0%EC%88%A0/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4/ENUM" class="wiki-link wiki-link-missing">ENUM</a> (Enumerated Type): 미리 정의된 값의 목록 중 하나만 선택하여 입력할 수 있도록 제한한다.

3.2 SQL 구현 예제 (표준 SQL 기준)

다음은 CHECK 제약 조건과 NOT NULL, DEFAULT를 적용하여 도메인 무결성을 구현한 CREATE TABLE 문이다.

CREATE TABLE Employees (
    EmployeeID INT PRIMARY KEY,
    EmployeeName VARCHAR(50) NOT NULL,
    
    -- 나이는 18세 이상 65세 이하만 허용
    Age INT CHECK (Age >= 18 AND Age <= 65),
    
    -- 부서는 '인사', '개발', '영업' 중 하나만 허용
    Department VARCHAR(20) CHECK (Department IN ('인사', '개발', '영업')),
    
    -- 입사일은 기본적으로 현재 날짜로 설정
    HireDate DATE DEFAULT CURRENT_DATE,
    
    -- 급여는 반드시 0보다 커야 함
    Salary DECIMAL(10, 2) NOT NULL CHECK (Salary > 0)
);

4. 다른 무결성 제약 조건과의 비교

도메인 무결성은 단독으로 작동하기보다 개체 무결성, 참조 무결성과 상호 보완적으로 작용하여 데이터베이스 전체의 정밀도를 높인다.

무결성 종류 정의 적용 대상 주요 목적
도메인 무결성 열에 입력될 값의 범위와 형식 제한 Column (열) 데이터의 유효성 및 형식 보장
개체 무결성 기본키(PK)는 NULL일 수 없으며 중복될 수 없음 Table / PK 레코드의 유일한 식별 보장
참조 무결성 외래키(FK) 값은 참조하는 테이블의 PK에 존재해야 함 Table / FK 테이블 간의 관계 일관성 유지

5. DBMS별 도메인 구현 차이점

표준 SQL을 따르지만, DBMS 제품마다 도메인 무결성을 구현하는 세부 방식에 차이가 있다.

  • PostgreSQL: CREATE DOMAIN 명령어를 통해 사용자 정의 도메인을 생성할 수 있다. 이는 일반적인 CHECK 제약 조건과 달리, 한 번 정의한 도메인을 여러 테이블의 여러 열에서 재사용할 수 있어 유지보수성과 일관성을 획기적으로 높여준다.
        -- 0보다 큰 양수만 허용하는 'positive_price' 도메인 생성
        CREATE DOMAIN positive_price AS DECIMAL(10, 2)
        CHECK (VALUE > 0);
    
        -- 생성한 도메인을 여러 테이블의 열에 적용
        CREATE TABLE Products (
            ProductID INT PRIMARY KEY,
            Price positive_price
        );
    
        CREATE TABLE Services (
            ServiceID INT PRIMARY KEY,
            ServiceFee positive_price
        );
        
  • MySQL: ENUM 타입을 통해 효율적으로 도메인을 제한하며, 최신 버전(8.0.16+)부터 CHECK 제약 조건을 완전히 지원하기 시작했다.
  • Oracle: CHECK 제약 조건을 광범위하게 사용하며, 복잡한 도메인 검증을 위해 트리거(Trigger)를 활용하는 경우가 많다.
  • SQL Server: CHECK 제약 조건 외에도 '규칙(Rule)' 객체를 생성하여 여러 열에 적용하는 방식을 지원한다.

6. 실제 비즈니스 도메인 적용 사례

실제 산업 현장에서는 다음과 같이 도메인 무결성을 적용하여 비즈니스 로직을 보호한다.

  1. 금융 시스템: 계좌 잔액(Balance) 열에 CHECK (Balance >= 0)를 설정하여 마이너스 통장이 아닌 일반 계좌에서 잔액이 음수가 되는 것을 방지한다.
  2. 전자상거래: 주문 상태(OrderStatus) 열을 ENUM('결제대기', '결제완료', '배송중', '배송완료', '취소')로 설정하여 정의되지 않은 상태 값이 입력되는 것을 막는다.
  3. 의료 시스템: 환자의 혈압이나 체온 데이터 입력 시, 생물학적으로 불가능한 수치(예: 체온 0도 이하)가 입력되지 않도록 CHECK 제약 조건을 설정한다.

7. 도메인 무결성 위반 시의 오류 사례

도메인 무결성 제약 조건이 설정된 상태에서 이를 위반하는 데이터를 입력하려고 하면, DBMS는 트랜잭션을 거부하고 오류 메시지를 반환한다.

  • 타입 불일치 오류: INT 타입 열에 'ABC'와 같은 문자열을 입력할 경우
    • 결과: Invalid input syntax for integer 또는 Incorrect integer value
    • 원인: 데이터 타입 위반
  • 제약 조건 위반 오류: Age CHECK (Age >= 18)가 설정된 열에 15를 입력할 경우
    • 결과: Check constraint violation 또는 The INSERT statement conflicted with the CHECK constraint
    • 원인: 논리적 범위 위반
  • NULL 입력 오류: NOT NULL 제약 조건이 있는 열에 값을 입력하지 않고 INSERT를 시도할 경우
    • 결과: Column 'column_name' cannot be null 또는 Cannot insert the value NULL into column
    • 원인: 필수 값 누락 위반

8. 도메인 무결성 적용의 이점 및 주의사항

8.1 이점

  • 데이터 품질 향상: 잘못된 데이터가 DB에 저장되는 것을 원천 차단하여 데이터 정제 비용을 줄인다.
  • 애플리케이션 로직 단순화: 서버 사이드(Java, Python 등)에서 수행하던 유효성 검사 로직의 일부를 DB 계층으로 이전하여 코드 중복을 줄이고 보안성을 높인다.
  • 일관성 보장: 어떤 인터페이스(웹, 앱, 관리자 툴)를 통해 데이터를 입력하더라도 동일한 규칙이 적용된다.

8.2 주의사항

  • 성능 저하: 과도하게 복잡한 CHECK 제약 조건이나 트리거를 통한 검증은 대량의 데이터를 삽입/수정할 때 오버헤드를 발생시켜 성능을 저하시킬 수 있다.
  • 유연성 부족: 비즈니스 요구사항이 변경되어 도메인 범위가 수정되어야 할 때(예: 정년 연장으로 인한 나이 제한 변경), 기존 데이터를 모두 검토하고 제약 조건을 변경해야 하는 운영 부담이 발생한다.
  • 오류 처리 복잡성: DB에서 발생하는 제약 조건 위반 오류를 사용자에게 친절한 메시지로 변환하여 전달하는 추가적인 예외 처리 로직이 필요하다.
AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

이 AI 생성 콘텐츠가 도움이 되었나요?