Relation Model Constraints (관계형 모델 제약조건)

관계형 모델 제약조건

 

관계형 모델 제약조건에는 크게 3가지가 있다.

 

1. Inherent model-based constraints 

- Implicit(내재적, 묵시적) 제약조건이라고도 하며 Relation 모델이기 때문에 지켜져야 하는 제약 조건들같이 암묵적으로 모델 자체에서 내포하고 있는 제약조건이다.

ex) Tuple들은 순서가 없고 중복이 되면 안 됨 (Relational은 tuple들의 집합이기 때문에)

 

2. Schema-based constraints

- Explicit(명시적) 제약조건이라고도 하며 스키마에서 직접적으로 표현되는 제약조건들이다.

ex) Key constraints(키 제약조건), Referential Integrity constraints(참조 무결성 제약조건) 등

 

3. Application-based constraints

- 응용프로그램에 따라 달라지는 제약조건이다.

ex) business rules(업무상 따라야 할 규칙) 등

 

이 중 우리가 중요하게 살펴볼 제약조건은 2번 Schema-based constrains이다.

실제로 DB를 다룰 때 가장 자주 마주치며 내 머리를 잡아 뜯게 만든 제약조건이다. (뇌피셜)

 

 

 

Scehma based Constraints

 

크게 4가지의 세부 제약조건들이 있다.

 

- Key constraints (키 제약조건)

- Constraints on NULLs

- Entity Integrity Constraints (개체 무결성 제약조건)

- Referential Integrity constraints (참조 무결성 제약조건)

 

이 외에도 추가적으로 

- Domain constraints

- Data dependencies가 있다.

 

내가 주요하게 다룰 부분은 key constraints와 Referential Integrity constraints이고 나머지는 간단하게 의미만 살펴보고 넘어가자.

 

 

Key Constraints

 

Key 제약조건에 대해 알아보기 전 Key가 필요한 이유에 대해서 살펴보자.

Relation은 tuple들의 집합으로 이루어져 있고, Relation에 포함된 모든 튜플들은 반드시 고유해야 한다.

(distinct 해야 한다고 하는데 번역해보면 구별돼야 한다, 뚜렷해야 등등 이지만 난 고유해야 한다고 표현하였다.)

 

그렇다면 고유하다는 것을 어떠한 방식으로 알 수 있을까?

바로 Key를 통해서 알아낼 수 있다.

 

---

Superkey

 

- Set of attributes of R : Relation R의 attribute의 집합

- R에 속해있는 서로 다른 튜플 t1, t2에 대하여 t1 [sk]!= t2 [sk]   (이때의 SK = superkey)

 

 t1 [sk]!= t2 [sk] 

 

위의 조건을 풀어 설명해보면 테이블에 존재하는 튜플의 슈퍼 키는 다른 어떠한 튜플의 슈퍼키와도 달라야 한다는 것이다.

 

슈퍼키가 모두 다르다면, 어떠한 튜플이 다른 튜플과 다르고 고유하다는 것을 증명할 수 있는 것이다.

 

슈퍼키의 개념이 헷갈릴 수 있는데 확실히 잡아놓고 가야 다음의 key들을 이해할 수 있다.

 

---

Key

- Minimal 한 Superkey

 

슈퍼키 중 minimal 한 성질을 가지고 있는 것을 Key라고 한다.

 

minimal 하다는 것은 어떠한 것도 뺄 수 없는 최선의 상태라는 것이다.

즉 Superkey에서 어떠한 attribute를 뺄 수 없는 상태를 말한다.

 

예를 들어보자.

학생 테이블이 존재하고 (학번, 이름, 성적) 이렇게 3가지 attribute가 존재한다고 가정해보자.

그럼 set of (학번, 이름)은 슈퍼키라고 할 수 있을까?

 

당연히 있다. 벌써 까먹은 건 아니지요?

학번과 이름이 같은 두 명의 학생이 존재할 수 없기 때문이다. (자아분열..?)

 

그럼 해당 Superkey가 minimal한가? 

 

그렇지 않다.

만약 Superkey인 (학번, 이름)에서 이름을 뺀다고 해도 (학번) 하나만으로도 충분히 각 튜플들이 고유함을 증명할 수 있다.

(학번은 모든 학생이 다르니까. 만약 같은 학교가 있다면.. 아쉬운 거고)

 

이 개념이 많이 헷갈릴 수 있다. 나도 처음엔 그랬다.

이후에 나오는 개념인 PK와 똑같은 거 아닌가? (해당 부분은 마지막에 다이어그램으로 표현해볼 예정이다)

 

---

Candidate Key (후보키)

- Key가 여러 개가 존재할 때 이 각각의 키를 후보키라고 한다.

---

Primary Key (기본키)

- 후보키 중 선택된 키로 각 튜플이 고유함을 증명하는 key이다.

- 절대 null값이 올 수 없다. (이는 아래의 Entity Integrity와 연관 있음)

- 후보키중 최대한 single attr인걸 골라야 하며 없다면 attr 수가 적은 것을 고른다.

 

---

Entity Integrity Constraints

개체 무결성 제약조건 : 각 Tuple의 기본키(Primary key)는 NULL 값을 절대 가질 수 없다는 것이다.

 

만약 PK 값이 NULL이 된다면 해당 Tuple은 정의가 불가능하다.

 

 

---

Referential Integrity Constraints

참조 무결성 제약조건 : 두 개의 Relation 사이에 참조하고 있는 값들이 있다면 참조되는 값이 바뀌면 참조하고 있는 값 역시 같이 바뀌어야 한다. (반대도 마찬가지)

 

Foreign Key (외래키)

 

어떠한 테이블에서 X란 Key가 다른 테이블의 PK를 참조하고 있다면 X를 외래키라고 한다.

난 DB를 완전히 처음 배울 때 이 개념이 가장 헷갈렸었다.

 

근데 교수님께서 "출장나와있는 키"라고 이해하면 편해요~

라는 한마디에 깔끔하게 해결되었다.

 

요즘도 FK 나오면 바로 출장나와있는 키를 떠올린다..

 

어쨌든 PK와 FK는 한 몸이다.

 

해당 제약조건을 쉽게 이야기하면 PK가 바뀌면 FK도 같이 바뀌어야 된다는 것이다.

만약 PK가 바뀌었는데 FK가 바뀌지 않았다면 정보를 제대로 찾아낼 수 없다.

출장 나가 있는 사람이 있는데 내가 그 사람의 이름을 바꿔버리면.. 출장나가있는 사람이 울겠죠?

 

 

---

Domain Constraints

Domain에 속해있는 모든 attribute는 반드시 atomic value로 이루어져야 한다.

여기서 atomic value란 더 이상 나눌 수 없는 값을 의미한다.

 

이것도 많이 헷갈렸는데 진짜 쉽게 말하면 집합이 아닌 값을 말한다.

ex) (학번, 이름) -> non atomic

     (학번)        -> atomic

 

 

 

여러 제약조건들이 있기 때문에 헷갈릴 수 있다.

과제로도 해당 제약조건들을 찾는 게 나왔었는데 상당히 애먹었다.

 

지금 와서 드는 생각이지만

가장 중요한 것은 먼저 PK와 FK를 확실하게 정의하고 그 관계를 이해하는 게 중요하다.