[DB] 관계형 모델과 무결성 제약조건

 

 

관계형 모델 (Relational Model)의 탄생과 기본 개념

관계형 모델은 E. Codd가 1970년에 발표한 논문 ["A Relational Model for Large Shared Data Banks"] 에 기반하고 있다. 이 모델이 큰 반향을 일으킨 이유는, 단순함(simplicity)과 수학적 기반(mathematical foundation) 덕분이다. 데이터를 마치 테이블 (Table) 처럼 단순하게 표현하고, 그 기반에는 집합 이론 (set theory)과 1차 술어 논리(first-order predicate logic)라는 이론이 깔려 있다.

 

 

 

 

비공식 용어 vs. 공식 용어

우리가 보통 쓰는 말이랑 데이터베이스에서 쓰는 공식 용어가 조금 달라서 헷갈릴 때가 많다. 간단하게 정리해 봤다. 이걸 알면 문서나 책 볼 때 훨씬 수월할 것이다.

 

비공식 용어 (Informal Terms)	공식 용어 (Formal Terms)	설명
테이블 (Table)	릴레이션 (Relation)	수학적 '집합' 개념에 기반한 데이터의 기본 단위이다.
컬럼 헤더 (Column Header)	애트리뷰트 (Attribute)	각 컬럼의 의미를 나타내는 이름이다.
컬럼의 가능한 모든 값	도메인 (Domain)	애트리뷰트가 가질 수 있는 원자적인 (atomic) 값들의 집합이다. 데이터 타입이나 포맷이 정의돼 있다. (예: 날짜 yyyy-mm-dd)
행 (Row)	튜플 (Tuple)	릴레이션의 하나의 '레코드'를 의미하며, 특정 개체나 관계의 사실을 나타낸다.
테이블 정의	스키마 (Schema, Intension)	릴레이션의 이름 R과 애트리뷰트 목록 (A1, A2,..., An)으로 정의된다. 이것을 R(A1, A2,..., An)으로 표기한다. 여기서 R은 릴레이션 이름이고, A는 Attribute 리스트이다.
데이터가 채워진 테이블	상태 (State, Extension)	특정 시점에 릴레이션에 실제로 들어있는 튜플들의 집합 r(R)이다.

 

 

 

 

핵심 특징:

• 튜플은 순서가 중요하지 않다: 튜플은 순서가 없다. 릴레이션은 집합(set)으로 정의되므로, 튜플 간 순서는 고려되지 않는다. 반면 애트리뷰트(Attribute)는 순서가 정의된다
• 애트리뷰트 값은 원자적(Atomic)이다: 튜플 내의 모든 값은 원자적(atomic, indivisible) 인 것으로 간주된다. 복합 애트리뷰트 (Composite Attributes)나 다중값 애트리뷰트 (Multi-valued Attributes)는 허용되지 않는다. 이것은 First Normal Form(1차 정규형) 가정을 기반으로 한다.
• NULL 값: 알 수 없거나(unknown), 사용 가능하지 않거나(not available), 해당 튜플에 적용할 수 없는(inapplicable) 값을 나타내기 위해 사용된다.
• 한 릴레이션 내의 모든 애트리뷰트 이름은 서로 달라야 한다.

 

 

---

 

 

릴레이션의 무결성을 지키는 제약조건 (Integrity Constraints)

앞에서 관계형 모델의 기본 뼈대를 봤다면, 이제 그 뼈대를 튼튼하게 지탱하는 규칙들, 즉 제약조건 (Constraints)에 대해 자세히 알아볼 차례다. 제약조건은 데이터베이스에서 어떤 값이 허용되고 (어떤 값은 허용되고), 어떤 값이 허용되지 않는지 (어떤 값은 허용되지 않는지)를 결정한다.

 

이 제약조건들은 크게 세 가지 카테고리로 나뉜다. 

 

 

제약조건의 세 가지 카테고리

카테고리	이름	설명	예시
Category 1	내재적/암시적 제약조건 (Inherent or Implicit Constraints)	데이터 모델 자체에 기반한 제약이다.	관계형 모델은 애트리뷰트 값으로 리스트(list)를 허용하지 않는 것.
Category 2	스키마 기반/명시적 제약조건 (Schema-based or Explicit Constraints)	데이터 모델 스키마에 직접 표현되는 제약이다. 우리가 주로 다루는 키(Key)나 도메인 제약이 여기에 속한다.	특정 컬럼의 값이 유일(unique)해야 한다는 제약.
Category 3	애플리케이션 기반/시맨틱 제약조건 (Application-based or Semantic Constraints)	비즈니스 규칙 (business rules)을 반영하며, 데이터 모델만으로는 완전히 설명할 수 없어 애플리케이션 프로그램에서 강제해야 하는 제약이다.	"만약 age>65이고 hours>40이면, 총 임금(total wages)은 두 배가 되어야 한다"는 규칙.

 

 

카테고리 2: 관계형 무결성 제약조건 (Relational Integrity Constraints)

개발자로서 가장 밀접하게 다루게 될 제약조건들은 바로 Category 2에 속하는 관계형 무결성 제약조건(Relational Integrity Constraints)이다. 이 조건들은 모든 유효한 릴레이션 상태에서 예외 없이 반드시 지켜져야 하는 조건들이다.

 

 

 

주요 유형은 다음과 같다:

 

1. 키 제약조건(Key constraints): 유일성(Uniqueness)을 보장하는 제약이다.
2. 엔티티 무결성 제약조건 (Entity integrity constraints): 튜플의 정체성(Identity)을 보장하는 제약이다.
3. 참조 무결성 제약조건 (Referential integrity constraints): 관계(Relationship)의 일관성을 보장하는 제약이다.

여기에 추가로, 도메인 제약조건 (Domain constraint) (도메인 제약조건)도 있다:

• 튜플의 모든 값은 해당 애트리뷰트의 도메인에서 온 값이어야 한다.
• 만약 해당 애트리뷰트가 허용한다면, 값은 NULL일 수도 있다.

 

 

 

---

 

 

C2-1) 키 제약조건 (Key Constraints)

키 제약조건은 릴레이션 내 튜플의 유일함을 보장하는 근본적인 규칙이다.

슈퍼키 (Superkey)

• 릴레이션 스키마 R의 애트리뷰트 부분집합 SK이다.
• 어떤 유효한 릴레이션 상태 r(R)에서도 두 튜플 t1과 t2가 SK에 대해 동일한 값을 가지지 않아야 한다. 이것이 유일성 속성 (uniqueness property)이라고 불리는 것이다.
  • 즉, t1​[SK] != t2​[SK] (t1과 t2가 다를 경우).
  • 예: {Student ID, Student Name}은 슈퍼키일 수 있다.

키 (Key)

• 최소 슈퍼키 (minimal superkey) 이다.
• 키 K에서 어떤 애트리뷰트를 제거하면 더 이상 슈퍼키가 되지 않는, 가장 작은 애트리뷰트 집합이다.
  • 키는 슈퍼키이지만, 그 역은 성립하지 않는다.

이 정의에 따라, 릴레이션은 튜플의 집합 (set of tuples) 이기 때문에, 모든 튜플은 반드시 서로 구별되어야 한다.

 

 

키의 특징과 종류

• 일반적인 규칙: 어떤 키를 포함하는 모든 애트리뷰트 집합은 슈퍼키이다.
• Candidate Key: 릴레이션 스키마는 여러 개의 키를 가질 수 있으며, 각각을 후보 키라고 부른다.
• Primary Key, PK: 후보 키들 중에서 임의로 (arbitrarily) 선택되어 릴레이션 스키마에서 밑줄로 표시된다.
  • PK의 역할: (1) 튜플을 고유하게 식별하고, (2) 다른 릴레이션에서 참조될 때 기준이 된다.
    
  • 선택 기준: 일반적으로 애트리뷰트의 수가 가장 작은 키를 선택하지만, 설계자의 판단에 따라 달라질 수 있다
• Unique Key: PK로 선택되지 않은 나머지 후보 키들은 unique keys로 지정될 수 있다 (SQL에서는 unique (State, RegNo)처럼).

 

예시: CAR 릴레이션

• CAR (State, Reg#, VIN​, Make, Model, Year)
• 두 개의 키: {State,Reg#} (자동차 등록 번호)와 {VIN} (Vehicle Identification Number- PK)
• 질문: {VIN}, {Make}는 키인가, 슈퍼키인가, 아니면 둘 다인가?
  
  • 답: VIN이 키이므로, VIN을 포함하는 {VIN, Make}는 슈퍼키이다. 하지만 Make를 제거해도 여전히 {VIN}이 키이므로, {VIN, Make}는 최소 슈퍼키(키)는 아니다. (최소성 위반)

 

---

 

 

C2-2) 엔티티 무결성 제약조건 (Entity Integrity Constraint)

이름 그대로 개체(Entity)의 정체성을 보장하는 규칙이다 (개체 무결성 제약조건).

• 핵심: 릴레이션 스키마 R의 Primary key attributes(PK)는 어떤 튜플에서도 NULL 값을 가질 수 없다.
• 이유: 주 키는 개별 튜플을 식별하는 데 사용되는데, 만약 NULL이면 튜플의 신원을 알 수 없게 되기 때문이다.
• 주의: FK가 NULL일 수 있는 경우, 해당 FK는 R1의 PK에 포함될 수 없다.
• 비 PK Attributes: PK가 아닌 일반 애트리뷰트의 경우, NULL 값 허용 여부는 따로 설정할 수 있다.

 

 

---

 

 

C2-3) 참조 무결성 제약조건 (Referential Integrity Constraint)

두 릴레이션 간의 연결(relationship)을 관리하여 데이터의 일관성(consistency)을 유지하는 데 사용된다 (참조 무결성 제약조건).

• 이 제약은 두 개 이상의 릴레이션에 걸쳐 적용된다.
• 예시: EMPLOYEE 튜플의 Dno(부서 번호) 값은 반드시 DEPARTMENT 릴레이션의 Dnumber 값 중 하나와 일치해야 한다.

 

 

외래 키 (Foreign Key, FK): 참조하는 릴레이션 R1의 애트리뷰트 집합 FK가 참조되는 릴레이션 R2의 주 키 PK를 참조하는 것이다.

• 참조하는 릴레이션 (Referencing Relation, R1​): Foreign Key 애트리뷰트를 가지고 있으며, 다른 릴레이션을 가리키는 릴레이션이다.
• 참조되는 릴레이션 (Referenced Relation, R2​): Primary Key 애트리뷰트를 가지고 있으며, R1이 가리키는 릴레이션이다.

 

규칙: 참조하는 릴레이션 R1의 튜플 t1에서 외래 키 값 t1[FK]는 다음 중 하나여야 한다:

1. 참조되는 릴레이션 R2의 기존 PK값 t2[PK]와 같거나,
2. NULL 값이어야 한다.

• 주의: 만약 FK가 NULL 값인 경우, 그 FK는 R1의 PK의 일부가 아니어야 한다. (그렇지 않으면 엔티티 무결성 제약조건을 위반한다).

 

 

---

 

 

 

데이터 조작과 무결성: INSERT, DELETE, UPDATE 시 주의할 점

데이터베이스를 운영하는 것은 단순히 데이터를 쌓아두는 것이 아니라, 그 데이터를 끊임없이 수정(Modification) 하는 과정이다. INSERT, DELETE, UPDATE 작업 시 무결성 제약조건(Integrity Constraints)이 깨지지 않도록 관리하는 것이 핵심이다.

 

데이터 수정 작업은 종종 다음의 특징을 가진다:

• 그룹화(Grouping): 여러 개의 수정 작업을 하나의 논리적인 단위로 묶어서 처리해야 할 수 있다.
• 전파(Propagation): 하나의 수정 작업이 다른 튜플의 데이터를 자동으로 수정하도록 전파(propagate)될 수 있다. 이는 무결성 제약조건을 유지하기 위해 필수적이다.

 

 

제약조건 위반 시 대응책 (Dealing with Constraint Violations)

데이터 수정 작업을 시도했는데, 만약 우리가 설정한 중요한 제약조건(키, 엔티티, 참조 무결성 등)을 위반한다면 어떻게 해야 할까? DBMS는 일반적으로 네 가지 액션 중 하나를 취하며, 이 옵션들을 잘 이해하고 설계에 반영해야 한다.

 

대응책	SQL 옵션 예시	설명
1. 작업 취소 (Cancel)	RESTRICT (no action) / REJECT	위반을 일으키는 작업을 허용하지 않고 즉시 취소한다. 많은 DBMS에서 기본적으로 사용하는 가장 안전한 방식이다.
2. 사용자에게 통보 (Inform User)	(사용하지 않음)	작업을 수행하되 사용자에게 위반 사실만 알린다. 바람직하지 않으며 대부분의 DBMS는 이 방식을 사용하지 않는다.
3. 추가 업데이트 유발 (Trigger Additional Updates)	CASCADE (갱신이 전파됨), SET NULL, SET DEFAULT	위반을 해결하기 위해 관련된 튜플들을 자동으로 추가 수정한다. 이는 보통 참조되는 릴레이션에서 참조하는 릴레이션으로 전파된다. (예: 부모 키가 삭제되면 자식 레코드를 함께 삭제하거나 NULL로 설정).
4. 오류 수정 루틴 실행 (Execute Error Routine)	(사용자 정의 프로그램)	사용자가 미리 정의한 오류 수정 프로그램(루틴)을 실행하여 복잡한 로직으로 위반을 해결한다.

 

 

 

유형별 위반 사례 분석: 데이터 조작 시 위험 요소

데이터베이스에서 INSERT, DELETE, UPDATE 작업을 수행할 때, 가장 흔하게 위반되는 세 가지 주요 관계형 무결성 제약조건을 중심으로 어떤 상황에서 문제가 발생하는지 정리한다.

 

1. INSERT (삽입) 작업 시 위반 가능성

새로운 튜플(행)을 릴레이션에 추가할 때 문제가 발생한다.

• 도메인 제약조건 위반:
  • 삽입 값이 애트리뷰트의 정의된 도메인 범위를 벗어날 때 (예: 문자열이 아닌 숫자만 허용되는 컬럼에 문자를 입력).
• 키 제약조건 위반:
  • 삽입하려는 튜플의 PK나 Candidate Key 값이 릴레이션 내 기존 튜플의 값과 중복될 때.
• 엔티티 무결성 제약조건 위반:
  • 삽입하려는 튜플의 PK 애트리뷰트에 NULL 값을 지정할 때.
• 참조 무결성 제약조건 위반:
  
  • 삽입하려는 튜플의 외래 키(FK) 값이 참조되는 릴레이션의 주 키 값 중 어디에도 존재하지 않을 때.

 

 

2. DELETE (삭제) 작업 시 위반 가능성

기존 튜플을 릴레이션에서 제거할 때 주로 참조 무결성 문제가 발생하며, 이로 인해 연쇄적인 작업이 필요할 수 있다.

 

• 참조 무결성 제약조건 위반:
  • 삭제하려는 튜플의 주 키(PK) 값을 다른 릴레이션의 튜플이 외래 키(FK)로 참조하고 있을 때.
  • 대응책: DBMS는 RESTRICT(삭제 거부), CASCADE(연쇄 삭제), SET NULL(참조 해제) 등의 옵션으로 무결성을 유지한다.

 

3. UPDATE (수정) 작업 시 위반 가능성

기존 튜플의 값을 변경할 때 발생하며, 수정되는 애트리뷰트의 역할에 따라 문제가 복합적으로 나타난다.

 

• 도메인 제약조건 위반:
  • 수정하려는 값이 해당 애트리뷰트의 도메인에 속하지 않을 때 (예: 유효하지 않은 포맷이나 범위의 값을 입력).
• 키 제약조건 위반
  
  • 주 키(PK)나 후보 키 애트리뷰트의 값을 릴레이션 내 다른 튜플의 키 값과 동일하게 수정하려 할 때.
• 엔티티 무결성 제약조건 위반:
  • 주 키(PK) 애트리뷰트의 값을 NULL로 수정하려 할 때.
• 참조 무결성 제약조건 위반:
  
  • 외래 키(FK) 값 수정 시: FK 값을 참조되는 릴레이션의 PK 값 중 어디에도 존재하지 않는 값으로 수정할 때.
  • 주 키(PK) 값 수정 시: PK 애트리뷰트의 값을 수정할 때, 다른 릴레이션이 해당 PK 값을 참조하고 있을 경우 참조 무결성 위반이 발생한다.
    • 대응책: 이 경우에도 참조되는 모든 튜플의 FK 값을 연쇄적으로 수정(CASCADE)하거나, 수정을 거부(RESTRICT)해야 한다.

 

 

 

 

 

 

출처: 경북대학교 이천희 교수님, “데이터베이스” 강의 자료