0. 데이터 무결성
- 데이터의 정확성, 일관성, 유효성, 유일성이 유지되는 것
- 데이터 자체가 얼마나 정확하고, 신뢰할 수 있으며, 규칙에 맞게 유지되고 있는지를 의미
- 정확성: 데이터가 사실을 반영하는가?
- 일관성: 데이터 내부에서 모순이 없는가?
- 유효성: 규칙/제약조건을 만족하는가?
- 유일성: 중복 없이 고유한가?
1. 데이터 무결성 구현 방법
| 기법 | 역할 |
|---|
| 1.1 제약 조건 | 데이터의 형식과 범위를 사전에 제한하여 잘못된 입력 방지 |
| 1.2 정규화 | 데이터 중복 제거, 관계 구조 최적화로 일관성과 유지보수성 향상 |
| 1.3 트랜잭션 관리 | 데이터 변경의 안전성과 일관성을 보장, 충돌 및 오류 방지 |
1.1 제약 조건 (Constraints)
무결성 제약 조건(Integrity Constraints)의 종류
1. 개체 무결성 (Entity Integrity)
제약 조건: PRIMARY KEY
- 테이블의 각 행(row)이 고유하게 식별되어야 함을 보장
PRIMARY KEY는 NULL을 허용하지 않으며, 중복도 불가능
- 예시) 고객 테이블의
customer_id는 반드시 유일하고 값이 있어야 한다.
2. 도메인 무결성 (Domain Integrity)
- 제약 조건:
CHECK, NOT NULL
- 특정 열(column)에 저장될 수 있는 값의 형식, 범위, 조건 등을 제한
데이터가 미리 정의된 규칙에 적합한 값만 입력되도록 제어
- 예시) age 컬럼은 0~120 범위만 입력 가능하게 설정하거나, gender 컬럼에 'M', 'F'만 허용하도록 설정
3. 참조 무결성 (Referential Integrity)
- 제약 조건:
FOREIGN KEY
- 다른 테이블의 기본 키를 참조할 때, 반드시 존재하는 값만 참조하도록 보장
- 외래 키(Foreign Key)는 참조 대상이 존재하지 않으면 삽입 불가
- 예시) 주문 테이블의
customer_id는 반드시 고객 테이블에 존재하는 ID여야 한다.
4. 사용자 정의 무결성 (User-Defined Integrity)
- 제약 조건: 애플리케이션 로직 또는 트리거 등 사용자 정의
- 표준 제약 조건 외에, 특정 비즈니스 규칙에 따라 무결성을 보장
- 주로
트리거나 저장 프로시저, 백엔드 로직`을 통해 구현
- 예시) 주문 수량이 재고 수량을 초과하면 안 된다.
5. NULL 무결성 (NULL Integrity)
- 제약 조건:
NOT NULL
- 특정 컬럼에 NULL 값을 허용할지 여부를 제어합니다.
- 비어 있으면 안 되는 필수 입력 값에 사용됩니다.
- 예시) 회원 가입 시 이름이나 이메일은 반드시 입력되어야 함
6. 고유 무결성 (Unique Integrity)
- 제약 조건:
UNIQUE
- 특정 컬럼이나 컬럼 조합이 중복되지 않도록 보장
- 단, UNIQUE 제약은
NULL 값은 허용
- 예시) 이메일 주소는 모든 회원이 고유하게 가져야 하지만, 입력하지 않은 경우(NULL)는 허용
데이터 무결성을 보장하기 위해 다음과 같은 여러 종류의 무결성 제약이 사용된다.
- NOT NULL: 특정 컬럼이 반드시 값을 가져야 함 (예: 이름, ID 등)
- UNIQUE: 해당 컬럼의 값이 중복되지 않도록 보장 (예: 이메일, 주민등록번호)
- PRIMARY KEY: 테이블 내에서 행을 고유하게 식별하는 열 (NOT NULL + UNIQUE)
- FOREIGN KEY: 다른 테이블의 기본 키를 참조하는 열로 참조 무결성을 보장
- CHECK: 특정 조건을 만족해야만 데이터를 저장 가능 (예: 나이는 0 이상)
무결성 종류에 따른 주요 제약 조건
| 무결성 종류 | 주요 제약 조건 | 설명 |
|---|
| 개체 무결성 | PRIMARY KEY | NULL/중복 불가, 행을 유일하게 식별 |
| 도메인 무결성 | CHECK, NOT NULL | 값의 형식, 범위, 조건을 만족해야 함 |
| 참조 무결성 | FOREIGN KEY | 다른 테이블의 존재하는 값만 참조 가능 |
| 사용자 정의 무결성 | 사용자 로직 기반 | 비즈니스 규칙에 따른 맞춤 제약 |
| NULL 무결성 | NOT NULL | 특정 컬럼에 NULL 허용 여부 지정 |
| 고유 무결성 | UNIQUE | 중복 불가, NULL은 가능 |
무결성 제약조건의 장단점
장점
1. 데이터베이스 자체가 유효성 검사를 수행한다.
- 이로 인해 개발자는 애플리케이션 코드에서 중복된 검증 로직을 줄일 수 있으며,
데이터베이스에 저장되는 모든 값이 일정한 규칙을 따르도록 강제할 수 있다.
2. 제약조건을 통해 비즈니스 규칙을 명확히 반영할 수 있다.
- 데이터 간의 논리적 오류를 줄이고, 여러 테이블 간의 관계도 안정적으로 유지할 수 있다.
단점
1. 성능 저하의 위험성
- 제약조건이 많아질수록 입력이나 수정 작업 시 내부적으로 수행되는 검증 작업이 많아져
성능 저하가 발생할 수 있다.
- 특히 대량의 데이터를 처리하거나 높은 트래픽을 감당해야 하는 시스템에서는 이러한 제약이 병목이 될 수 있다.
2. 아키텍처에 따른 제한사항 발생 가능성
- 마이크로서비스나 NoSQL 같은 분산 아키텍처에서는 외래 키 제약처럼
물리적인 테이블 간 관계를 강제하는 기능을 사용할 수 없는 경우도 많다.
- 운영 중에 제약조건을 추가하거나 제거하는 작업도 어렵고 위험할 수 있기 때문에,
설계 초기 단계에서 신중하게 결정해야 한다.
무결성 제약조건은 데이터의 정합성을 보장하는 매우 유용한 도구지만,
성능과 시스템 구조, 유연성 등을 종합적으로 고려해 상황에 맞게 적절히 사용하는 것이 중요하다.
일부 검증을 애플리케이션 레이어로 위임하는 것도 좋은 전략이 될 수 있다.
1.2 정규화 (Normalization)
데이터 중복을 제거하고 관계형 데이터 모델의 구조를 체계화함으로써 데이터의 일관성과 정확성을 높이는 과정
- 제1정규형(1NF)
컬럼은 원자값만 저장 (ex. 쉼표로 구분된 다중 값 금지)
- 제2정규형(2NF)
부분 함수 종속 제거 (복합키 일부에만 의존하는 컬럼 제거)
- 제3정규형(3NF)
이행 함수 종속 제거
(비Primary 속성이 다른 비프라이머리 속성에 의존하지 않게 함)
- BCNF (보이스-코드 정규형)
모든 함수 종속의 좌변은 슈퍼키여야 함
슈퍼키가 아닌 속성이 결정자 역할을 하는 경우 분해 필요
- 제4정규형 (4NF)
다치 종속(Multivalued Dependency) 제거
하나의 키가 둘 이상의 독립적인 속성 집합을 결정하는 경우 분해
예: 하나의 학생이 여러 과목을 듣고, 여러 동아리에 가입하는 경우
- 제5정규형 (5NF)
조인 종속(Join Dependency) 제거
테이블이 여러 개로 분해된 후, 원래 테이블로 무손실 복원이 가능해야 함
주로 다대다 관계가 복잡하게 얽혀 있을 때 발생
정규화를 통해 얻을 수 있는 이점
- 데이터 중복 제거
- 변경 이상(수정/삽입/삭제 이상 현상) 방지
- 유지보수 비용 감소
단, 과도한 정규화는 JOIN 비용 증가와 성능 저하를 유발할 수 있으므로 상황에 따라 비정규화를 선택적으로 적용해야 한다.
1.3 트랜잭션 관리 (Transaction Management)
정규화와 제약 조건은 정적인 구조 측면에서 무결성을 보장하는 반면,
트랜잭션 관리는 데이터의 변경 과정 중 발생할 수 있는 무결성 위반을 막는 동적인 보호막 역할을 한다.
예를 들어,
하나의 트랜잭션 안에서 여러 테이블을 수정하다가 중간에 오류가 발생하면,
트랜잭션이 롤백(rollback)되면서 불완전하거나 모순된 데이터 저장을 방지할 수 있다.
다시 말해, 제약 조건과 정규화는 데이터가 잘못 저장되지 않도록 미리 틀을 잡아주는 역할을 하고,
트랜잭션은 그 틀이 깨지지 않도록 실행 중에도 데이터를 안전하게 관리해주는 역할을 한다.
데이터 무결성은 트랜잭션의 다음과 같은 성질을 통해 보장된다.
| 항목 | 설명 |
|---|
| Atomicity (원자성) | 트랜잭션은 모두 수행되거나, 전혀 수행되지 않아야 함 |
| Consistency (일관성) | 트랜잭션 수행 후에도 DB 상태는 일관성 유지 |
| Isolation (격리성) | 동시에 수행되는 트랜잭션 간 간섭 방지 |
| Durability (지속성) | 트랜잭션이 완료된 후 결과는 영구 반영 |
또한, 여러 트랜잭션이 동시에 실행되는 환경에서는 동시성 문제(예: Dirty Read, Lost Update 등)를 방지하기 위한 격리 수준(Isolation Level) 설정도 매우 중요하다.
이는 다음 장에서 더 자세히 다루고자 한다.