데이터베이스 : 관계 모델과 제약 조건

관계 데이터 모델(Relational Data Model)은 데이터를 다음과 같이 나타낸 것입니다.

엔티티 타입이나 관계 타입을 릴레이션(Relation)으로 만들 수 있고, 이 릴레이션은 테이블이라고도 부릅니다.

릴레이션의 열을 애트리뷰트(Attributes), 행을 튜플(Tuples)로 부르며,

열의 개수(number of attributes)를 degree, 행의 개수(number of tuples)를 cardinality로 부릅니다.

일반적으로 ER 모델링 이후에 관계 모델로 변환합니다.

 

- 행(rows) → 튜플 → 엔티티 혹은 관계에 해당하는 인스턴스

- 열(columns) → 애트리뷰트

- 테이블 → 릴레이션 → 엔티티 타입, 관계 타입, 다치 애트리뷰트

다음과 같이 용어를 정리할 수 있습니다.

 

관계 모델에서 애트리뷰트가 가질 수 있는 값의 집합을 도메인(domain) 이라고 합니다.

또한 도메인은 실제 데이터 타입(CHAR, VARCHAR, INT, TIME, ...) 으로 명시합니다.

예를 들어 위의 STUDENT 릴레이션에서 Name의 도메인은 Name CHAR(10) 이라고 할 수 있겠네요.

 

다음으로 릴레이션의 특성에 대해 간단히 보고 넘어가겠습니다.

투플의 무순서성 : 튜플의 순서가 달라도 동일한 릴레이션

애트리뷰트의 무순서성 : 애트리뷰트의 순서가 달라도 동일한 릴레이션

애트리뷰트의 원자성 : 튜플 내의 값은 더 이상 나눌 수 없는 원자값

→ 관계 모델에서 다치 애트리뷰트나 복합 애트리뷰트는 허용되지 않아 별도의 릴레이션으로 표현합니다.

→ 값을 알 수 없거나 해당하는 값이 없는 경우 NULL이라는 값을 사용하며, NULL도 원자값으로 취급합니다.

---

관계 모델 제약조건(constratint)은 모든 릴레이션의 인스턴스들이 만족해야 하는 조건으로,

다음의 다섯 가지 스키마 기반 제약조건으로 정의 가능합니다.

1. 도메인 제약조건
2. 키 제약조건
3. 널(NULL)에 대한 제약조건
4. 엔티티 무결성 제약조건
5. 참조 무결성 제약조건

우선 도메인 제약조건은 어찌 보면 당연한 얘기입니다.

앞서 말한 Name이라는 변수는 CHAR형 이므로, 정수형 Integer 값이 들어갈 수 없겠죠?

도메인 제약조건은 이처럼 각 원자값이 반드시 도메인의 형식에 속해야 한다는 것입니다.

 

키 제약조건은 모든 원소는 중복되어서는 안된다는 조건입니다.

어떠한 두 튜플도 릴레이션의 모든 애트리뷰트에 대해 같은 값의 조합을 가질 수 없다는 것이죠.

따라서 튜플을 식별할 수 있는 애트리뷰트인 키가 여기서 중요하게 여겨집니다.

 

이러한 키의 종류는 다음과 같습니다.

우선 슈퍼 키(super key)란 제일 큰 범위의 키를 말하는 것으로, 튜플을 식별할 수 있는 키의 모든 집합입니다.

위의 관계 모델에서 키는 학번과 주민번호라고 볼 수 있는데,

이름, 나이만으로는 같은 이름과 나이가 있을 수 있기에 튜플 식별이 불가능하지만,

주민번호+이름, 학번+주소 로는 충분히 어떤 튜플인지 식별이 가능합니다.

따라서 슈퍼키는 키를 포함하는 모든 속성의 집합이라고 볼 수도 있죠.

이처럼 유일성(uniqueness)은 만족하지만 최소성(minimality)이 만족되는 않는 애트리뷰트의 집합을 슈퍼키라 합니다.

 

후보 키(candidate key)가 바로 우리가 알고 있는 키입니다.

위의 관계 모델에서 학번과 주민번호가 후보 키임을 알 수 있겠네요.

후보 키는 유일성과 최소성을 모두 만족합니다.

 

기본 키(PK, primary key)는 후보 키 중에서 설계자가 지정한 하나의 키 입니다.

지난 글에서 얘기했듯 PK로 선택될 조건으로는 NOT NULL과 Unique가 있습니다.

PK로 선택되지 않은 후보 키는 대체 키(alternate key)가 됩니다.

 

우리가 SQL의 스크립트로, 혹은 EERD를 그려 데이터베이스를 만들 때 해당 애트리뷰트에 제약조건을 걸게 됩니다.

이 때, 학번, 주민번호, 이름과 같이 필수적으로 기입되어야 하는 요소에 NOT NULL 조건을 붙입니다.

NOT NULL 제한을 걸면 우리가 INSERT로 인스턴스를 삽입할 때 학번, 주민번호, 이름은 무조건 작성해야 합니다.

이렇게 NOT NULL 제한을 거는 것을 널 제약조건이라고 합니다.

CREATE TABLE DEPARTMENT
( DNAME VARCHAR(15) NOT NULL,
DNUMBER INT NOT NULL,
MGRSSN CHAR(9) NOT NULL,
MGRSTARTDATE DATE,
PRIMARY KEY (DNUMBER),
UNIQUE (DNAME),
FOREIGN KEY (MGRSSN) REFERENCE EMPLOYEE (SSN)) ;

 

엔티티 무결성(integrity) 제약조건이란 삽입, 수정 시 따라오는 제약조건으로, 위의 키 제약조건과도 연결됩니다.

값을 삽입할 때 기본 키 값이 기존에 있는 것과 같거나 NULL이면 삽입이 금지되어 에러가 발생하고,

값을 수정할 때에도 기본 키 값을 기존에 있는 것과 중복되도록 혹은 NULL로 변경하면 에러가 발생합니다.

다만 삭제는 엔티티 무결성 제약조건에 영향을 받지 않습니다.

 

마지막으로 참조 무결성 제약조건입니다.

부모 릴레이션 S의 기본 키(PK)를 참조하여 외래 키(FK, foreign key)로 설정한 자식 릴레이션 R이 있습니다.

이 때 릴레이션 R과 S는 참조 무결성 제약조건을 가지게 됩니다.

참조 무결성 제약조건은 릴레이션의 삽입, 삭제에 다음과 같은 영향을 끼칩니다.

 

부모 릴레이션에는 자유롭게 값을 삽입할 수 있지만,

자식 릴레이션에 값을 삽입할 때 참조받는 테이블에 해당 값이 없다면 삽입이 불가능합니다.

 

자식 릴레이션 혹은 릴레이션 내의 값의 삭제는 바로 가능하지만,

부모 릴레이션의 삭제는 딸려있는 자식이 있기에 해당 참조를 제거해야 삭제가 가능합니다.

위의 터미널을 보면 PROJECT의 튜플 하나를 지우려 했지만,

PROJECT를 부모로 가지며 Pnumber를 FK로 참조하는 WORKS_ON 릴레이션이 존재하기에 삭제 시 오류가 납니다.

WORKS_ON에서 Pnumber를 참조한 FK인 Pno를 제거하여 참조를 없앤 뒤에는 PROJECT에서 삭제가 가능해집니다.

 

<틀린 점이 있다면 지적 부탁드립니다. 감사합니다.>