4. 관계 데이터 모델 , 관계 데이터 베이스 제약 조건

이 글은 Database Management System 3ed / R. Ramakrisnan and J. Gehrke 책을 읽고 직접 정리한 글입니다. 

 

목차

1-1. 관계 모덜의 뜻 정리
1-2. relation의 예시
1-3. 예시를 통한 domain, attribute, tuple, relation 용어 정의
1-4. relation의 특성
1-5. tuple 내에서 값들과 NULL 값

 

2-1. 관계 모델 제약 조건

2-2. 도메인 제약조건

2-3. 키 제약 조건과 널에 대한 제약 조건

2-4. 관계 데이터베이스 스키마

2-5. 엔티티 무결성 제약조건

2-6. 참조 무결성 제약조건

 

3-1. 렐레이션의 3가지 갱신 연산(삭제, 삽입, 수정)

1-1. 관계 모델의 뜻 정리

관계 모델이란 DB의 개념적 설계 단계에서 사용되는 설계 기법중 하나이다. 

관계 모델이란 데이터베이스를 relation들의 모임으로 표현한다. 

relation은 값들의 table로 Record file과 유사한 모습을 가진다. 

table의 각 행은 관련 데이터 값들의 모임을 나타낸다. (아직 정리하진 않았지만 이를 tuple 이라 한다.)

열은 실세계의 엔티티 또는 관계에 대한 사실들을 표현한다.  (열을 attribute라고 한다. )

그리고 위와 같은 행열 가진 table을 하나의 relation이라고 한다. 이러한 relation들이 모여서 관계 모델이 구성된다.  

 

우선 아래 relation의 예시를 먼저 보고 예시를 확인해가며 4가지 용어에 대해 정리해보자. 

 

1-2. relation의 예시

STUDENT

Name	Address	Age	Phone
Kim	Busan	19	111-222
Lee	Seoul	21	123-456

                                                           STUDENT relation의 attribute와 tuple들 

 

 

1-3. 예시를 통한 domain, attribute, tuple, relation 용어 정리

1) relation , attribute , relation schema 정의

STUDENT는 relation 이름을 나타내며 R이라는 기호로 표기한다. 

attribute는 table의 1행에 열들인 Name, Address, Age, Phone을 말한다. 

그리고 R(A1, A2, A3...An)으로 표기하는 relation 이름과 attribute로 표한하는 방식을 릴레이션 스키마라고한다. 릴레이션 스키마는 릴레이션을 표현하기 위해 사용되며, 이때 n은 릴레이션 스키마의 차수라고한다.

(attribute의 개수이다.)

 

2) tuple 정의

예제에서 한 열을 하나의 tuple이라고 한다. 각각의 tuple들을 원소로 하는 집합을 r 또는 r(R)이라고 하며, 

r = r(R) = {t1, t2, t3,...tn} 표기에서 r 또는 r(R)은 n-tuple (n은 차수)들의 집합을 의미한다. 

n-tuple은 n-tuple t1, n-tuple t2, ..n-tuple tn 과 같이 되는데 

n-tuple t 라는 것을 정리해보면 n개 (n개의 attribute)의 값의 순서 리스트를 의미하는데, 표기법으로 

t = <V1, V2, ...Vn> 으로 표기한다. (t는 t1~tn들 중 하나)

각각의 Vi는 dom(Ai)의 원소이거나 NULL 값이 된다. 이것에 대해서는 domain에서 자세히 정리한다.

 

3)  예제를 적용한 정리

위 내용을 예시를 적용해 정리해보자. 위 예제는 관계 모델을 나타내는 수 많은 relation들 중 하나의 relation을 나타낸 것으로 relation name은 STUDENT이다. 

attribute의 집합을 나타내면 {Name, Address, Age, Phoen}이 된다. 

relation schema 는 STUDENT(Name, Address, Age, Phone)으로 표현한다. 

tuple을 써보면 아래와 같다. 

4-tuple t1 = <Kim, Busan, 19, 111-222>

4-tuple t2 = <Lee Seoul, 21, 123-456>

로 표현 가능하다.

r = r(STUDEN) 는 4-tuple = {4-tuple t1, t-tuple t2} 이라는 집합으로 (쉽게 말하면 table의 열들의 집합이다.) 아래와 같이 표기한다. 

r = r(STUDENT) = {4-tuple t1, t-tuple t2} 

 

4) domain

도메인 D는 형식 관계 모델에서 원자 값들의 집합이다. 원자값은 더 이상 나누어질 수 없는 값을 의미한다. 

도메인을 명시하는 일반적인 방법은 그 도메인에 속하는 값들의 데이터 타입을 명시하는 것이다. 

또한 도메인의 값들을 해석하기 위해서는 "도메인을 위한 이름" 을 명시하는 것이 좋다. 

아래는 "도메인을 위한 이름"의 예이다. 

• Names. 개인의 이름을 표현하며 문자열의 집합이다. 
• Ages. 10~80세 사이의 나이값들을 의미하며 정수 값이다. 
• Phone_numbers. 휴대폰 번호로 xxx-xxx와 같은 형식(format)을 가진다.  

위에서 도메인의 논리적 정의를 정리하였다. 

도메인은 "이름", "데이터 타입, "포맷"을 가질 수 있다. 예를 들어 Phone_numbers라는 도메인은 데이터 타입으로 정수이고 포맷으로 xxx-xxx의 형태를 가진다. 

STUDENT relation의 attribute에 대한 도메인을 아래와 같이 "도메인을 위한 이름"으로 나타낼 수 있다. 

• dom(Name) = Names.
• dom(Age) = Employee_ages.
• dom(Phone) = Phone_numbers.

 

domain을 쉽게 정리하면, relation table의 각 tuple에서 attribute에 대응 하는 값들을 의미하는데.  위 예제에서 

4-tuple t1의 Name 에 대한 값으로 "Kim"이다.  이 값이 도메인이다.

Name.라는 dom(Name)은 이름이라는 문자열의 집합으로 Kim이 될수도 Lee가 될수도 있듯 다양한 이름이 있을 수 있다. 이것을 표현으로 Name.라고"도메인을 위한 이름"으로 표현하는 것 이다. 

 

 

1-4. relation의 특성

1) relation에서 tuple들의 순서에 대한 이야기

relation은 tuple의 집합으로 정의된다. 수학적으로 집합에는 순서가 없다. 

따라서 relation의 tuple역시 순서는 무시된다. (순서가 없다.) 하지만 파일에서는 레코드들이 디스크 또는 메모리에 물리적으로 저장되기때문에 메모리 주소라는 저장 순서가 존재한다. 이 저장 순서를 표현하기 위해 relation table로 표시할때 특정 순서로 행동을 표시하는 것이다. !!

 

2) tuple내에서 값(domain)의 순서와 relation의 또 다른 정의

n-tuple은 n개의 값의 순서 리스트이다. 따라서 한 tuple내에서 값들의 순서가 중요하다. 이는 relation schema를 정의할때 attribute의 순서가 중요함을 의미한다. 

하지만 더 추상적인 관점에서는 각 attribute와 값(domain)들이 서로 대응되기만 한다면 attribute들의 순서와 attribute의 값(domain)들의 순서는 중요한 것이 아니다. 

 

relation의 또 다른 정의에서는 tuple 내에서의 값들의 순서가 무의미하다는 것이다. 

tuple은 (<attribute>, <domain 값>) 쌍들의 집합으로도 생각할 수 있다.  각 쌍은 attribute 중 하나인 Ai에서 dom(Ai) 내의 어떤 값 Vi로 사상을 나타낸다. 이 정의에서는 각 attribute의 이름이 값과 함께 표시되므로 attribute의 순서가 중요하지 않다. !! 

• t1 = <(Name, Kim), (Address, Busan), (Age, 19), (Phone, 111-222)> 
• t1 = <(Address, Busan),  (Age, 19), (Phone, 111-222), (Name, Kim)>

따라서 위 표현은 동일한 표현이 된다. 

 

 

1-5. tuple내에서 값들과 NULL 값

tuple 내의 각 값들은 원자값이다. 즉 기본적인 관계 모델 구조 내에서는 값이 더 이상 나누어질 수 없다. 

따라서 복합 애트리뷰트(composite attribute)와 다치 애트리뷰트(multivalued attribute)는 허용하지 않는다.

이 모델은 "평면 관계 모델"이라고도 부르며 다치 애트리뷰트는 별도의 relation으로 표현해야하며, 복합 애트리뷰트는 기본 relation 모델7의 단순 애트리뷰트들로만 표현해야한다. 

 

tuple내에 NULL 값을 사용하는 경우는 다음과 같다.

• 값을 알 수 없는 경우
• 가능하지 않은 값을 가지고 있는 경우
• 이 tuple에는 이 attribute를 적용할 수 없는 경우(정의되지 않은 값인 경우
• 일부 시스템에서는 각 유형의 NULL 값에 대해 서로 다른 코드 값을 사용며 관계 모델 연산에서 이런 NULL 값들을 구별하는것은 매우 어려운 일이며 앞으로 더 공부를 해나가야할것 같다...

 

마무리...

relation schema는 선언 또는 일종의 주장이다. STDENT relation schema는 일반적으로 사람 엔티티가 

Name, Address, Age, Phone 속성을 가진다고 주장한다. 

그리고 각 tuple은 이 주장에 대한 사실 또는 인스턴스로 해석이 된다. 

예를 들어 이름이 Kim이고 Address가 Busan이고 Age는 19 Phone은 111-222라는 사람이 존재한다는 사실을 주장하게 되는 것이다. 

 

어떤 relation은 엔티티에 대한 사실을 표현하는 반면에 어떤 relation은 엔티티 간의 관게에 관한 사실을 표현한다. 

관계 모델은 엔티티와 엔티티 간의 관계에 관한 사실을 똑같이 relation으로 표현한다. 

따라서 이 둘을 구별하기 위해선 어떤 relation 타입을 표현하는지 추측해야 하기 때문에 때론 이것은 이해도를 떨어트릴 수 있다. 

 

---

2-1. 관계 모델의 제약 조건들 정리 

1절에서 단일 릴레이션 특징에 대해 정리하였다. 관계 데이터베이스는 더욱 많은 릴레이션이 있고 투플들은 다양한 방법으로 연관되어 있다. 

 

전체 데이터베이스 상태란 특정한 시점에서의 묻는 릴레이션들의 상태를 의미한다. 일반적으로 데이터베이스 상태에서는 실제 값에 대한 많은 제약 조건들이 있다. 이러한 제약 조건들은 DB가 표현하는 작은 세계의 규칙들로부터 유도된다. 일반적으로 데이터베이스에서의 제약 조건은 크게 3가지 주제가 있는데, 

1. 관계 데이터 모델 자체에서 존재하는 제약 조건이다. 이는
   본질적  모델 기반 제약 조건 또는 함축적 제약 조건이라고도 부른다.
   ex) 각각의 릴레이션에서 중복되는 tuple은 존재할 수 없다.
2. 관계 데이터 모델의 스키마에서 직접 표현 가능한 제약 조건으로 주로 DDL(data definition language)로 명시한다. 스키마 기반 제약 조건 또는 명시적 제약 조건이라고 부른다. 
3. 데이터 모델의 스키마에서 직접 표현이 불가능한 제약 조건으로 응용 프로그램에 의해 표현되고 시행된다. 
   이를 응용 기반 제약 조건 또는 의미적 제약 조건이나 비즈니스 규칙이라 부른다. 

3번의 경우 너무 추상적이고 일반적고, 애트리뷰트의 상태 및 의미와도 밀접한 관련이 있어서 데이터 모델 내에서 제약 조건을 표현하고 지키도록 하는 것이 어려워 보통 데이터베이스를 업데이트하는 응용 프로그램에서 이것을 체크한다. 일부 응용 프로그램에서는 이런 제약 조건을 SQL의 질의(assertion)으로 명시될 수 있다고 한다. 

 

지금 이 글에서는 2번째인 DDL을 통해 릴레이션 모델의 스키마에 표현되는 제약조건에 대해 정리할 것이다. 

DDL 은 도메인 제약 조건, 키 제약 조건, 널에 대한 제약 조건, 엔티티 제약 조건, 참조 무결성 제약 조건을 포함한다. 이제 이들에 대해 하나하나 정리해보자.

 

 

2-2. 도메인 제약 조건

각각의 tuple내에서 각각의 애트리뷰트 A의 값이 반드시 A의 도메인 dom(A)에 속하는 원자값이어야 한다는 것이다. 도메인과 관련된 전형적인 데이터 타입들에는 정수와 실수와 같은 표준 숫자형, 논리형, 문자, 고정 길이 문자열, 가변 길이 문자열, 날짜, 시간 등 데이터 타입이 있다. 

 

2-3. 키 제약 조건과 널에 대한 제약 조건

Name	Address	Age	Phone
Kim	Busan	19	111-222
Lee	Seoul	21	123-456
Park	Busan	19	111-222

<슈퍼키의 개념>

위 예제 표를 보면서 설명을 진행한다. 

릴레이션 스키마 R의 릴레이션 상태 r={t1, t2,...tn}에 대해 임의의 두 투플에 대해 서로 다른 값들을 갖는 애트리뷰트들의 부분집합이 존재한다. 그리고 그러한 부분 집합을 SK라고 표기해보자. 

이것에 대한 보충 설명으로 SK라는 것은 애트리뷰들의 부분집합인데 {Name, Age} 또는 {Address, Name, Age}... 이 모든 부분 집합들 중에서 서로 다른 "값"을 가지는 애트리뷰트들의 부분집합이 존재한다는 의미이다. 예를 들어 t1와 t2에서 애트리뷰트들의 부분 집합중 하나인 {Age}  집합은 t1과 t2에 대해 서로 다른 값이 되므로 SK라고 할 수 있다. 또한 {Name, Age}도 마찬가지임. 

 

이러한 SK를 슈퍼키(superkey)라고 부른다. 슈퍼키는 임의의 두 투플을 구분해주는 유일성 제약 조건을 만족 시킨다. 하지만 슈퍼키는 중복되는 애트리뷰트들을 가질 수 있다. 이것에 대한 보충 설명으로 만약

t2와 t3를 보면 Name만 다르다. SK={Name}은 슈퍼키가 될 수 있다.
SK={Name, Address}와 그리고 SK={Name, Address, Age}그리고 SK={Name, Address, Age, Phone} 역시 모두 슈퍼키가 된다. 왜? Name이 서로 다르기 때문에 위와 같은 모든 SK는 t1과 t3를 구별해주기 때문이다. 따라서 위에서 나열한 SK들은 슈퍼키가 된다. 하지만 위에서 나열한 슈퍼키 내에서 Address, Age, Phone은 같은 속성과 같은 값을 가진다. 따라서 이들을 보고 "슈퍼키는 중복되는 애트리뷰트들을 가질 수 있다"라고 표현한 것이다. 

우리는 이러한 중복성까지 없앤 슈퍼키를 생각해볼것이고 이것이 필요하다. 이것을 Key라고 한다. 

 

<key의 개념>

Key는 최소의 슈퍼키이다. 즉 슈퍼키 안에서 중복되는 애트리뷰트(+값)이 없도록 하는 슈퍼키를 의미한다. 

t1과 t3에서 그럼 Key는? {Name} 이 슈퍼키 하나이다.

t1과 t2에서 key는? 모든 슈퍼키의 부분 집합이 key가된다. (왜냐? t1과 t2는 모든 애트리뷰트들의 값이 다르기때문)

 

<후보키의 개념>

릴레이션 스키마는 하나 이상의 Key를 가질 수 있다. 즉 임이의 두 투플을 구별해주는 애트리뷰트가 여러개 일 수 있다는 것이다. 

이러한 후보키들 중 하나 또는 적은 수의 애트리뷰트를 가진 기본키를 선택한다. 즉 후보키들 중 하나를 선택하여 그것을 기본키(primary key)로 지정한다는 것이다. 

릴레이션은 이런 기본키를 구성하는 애트리뷰트들에는 밑줄을 긋는다. (그래서 Name에 밑줄을 그음)

기본키가 지정되면 다른 후보키들은 밑줄을 안그어도 된게 된다. 

 

<널 값의 허용 여부>

애트리뷰트에 대한 또 다른 제약 조건으로 널 값의 허용 여부이다. 예를 들어 모든 STUDENT 투플이 Name 애트리뷰트에 대해 널이 아닌 유효한 값을 가진다면 STUDNET의 Name은 NOT NULL로 제한된다. 

 

2-4. 관계 데이터베이스 스키마

지금까지 정리한 정의와 제약 조건들은 한 릴레이션과 그 릴레이션의 애트리뷰트에 적용된다. 

지금부터는 관계 데이터베이스와 관계 데이터베이스 스키마를 정의할 것이다. 

관계 데이터베이스 스키마(relatinal database schema)는 S로 표기하며
S는 릴레이션 스키마들의 집합 + 무결성 제약 조건(integrity constraint) 집합 IC 이다. 

 

S의 관계 데이터베이스 상태를 DB라고 한다. DB는 릴레이션 상태들의 집합이다. 즉 각각의 릴레이션은 자신의 릴레이션 상태 r = R(r) = {t1, t2, t3...}을 가지는데 이러한 {r1, r2, r3..} 집합을 S의 상태 DB라고 한다. 

여기서 ri는 Ri의 상태이고, ri 릴레이션은 IC에서 명시된 무결정 제약 조건들을 만족한다. 

정리하면 아래 한줄로 표현됨

S의 상태=DB={r1, t2, ...}

 

 

그림1)에서 데이터 베이스는 각각의 릴레이션들의 모임으로 나타낸 것이다.  

관계 데이터베이스 스키마 S는 COMPANY = {EMPLOYEE, DEPARTMENT, DEPT_LOCATIONS, WORKS_ON, DEPENDENT} 라고 나타낼 수 있다. 

관계 데이터베이스라고 하면 묵시적으로 스키마와 현재 상태를 모두 포함하도록 한다. 

무결성 제약 조건을 준수하지 않는 데이터 베이스 상태를 유효하지 않은 상태(invalid state)라고 한다. 

무결성 제약 조건을 모두 준수한 데이터 베이스 상태를 유효한 상태(valid state)라고 한다. 

 

서로 다른 릴레이션들에서 동일한 실세계 개념을 나타내는 애드리뷰트들이 같은 이름을 가질수도 있고 다른 이름을 가질 수도 있다. 반대로 서로 다른 릴레이션에서 사로 다른 개념을 나타내는 애트리뷰트들이 같은 이름을 가질 수 있다. 이것의 예로

DEPARTMENT 릴레이션과 DEPT_LOCATIONS 릴레이션의 Dnumber 애트리뷰트는 동일한 실세계의 개념으로써 부서에 부여된 번호를 나타낸다. 이 똑같은 개념을 EMPLOYEE 릴레이션에서는 Enumber로 나타내며, PROJECT 릴레이션에서는 Pnumber으로 나타낸다. 

 

관계 모델 초기에는 같은 실세계 개념을 나타내는 애트리뷰드들은 모든 릴레이션에서 동일한 이름을 갖는다는 가정이 있었다. 하지만 현제는 EMPLOYEE 릴레이션의 Ssn과 Super_Ssn 처럼 동일한 (Social Security Number)라는 개념을 다른 이름의 애트리뷰트로 나타낸다.

 

2-4 절 마무리..

관계 DBMS는 관계 데이터베이스 스키마를 정의 하기 위해 데이터 정의어(DDL)를 가져야한다. 현재 이런 목적으로 대부분 SQL을 사용한다. 

무결성 제약 조건은 데이터베이스 스키마에 명시하며 그 스키마의 모든 데이터베이스 상태가 이를 만족해야한다. 2.2절~2.3절까지 무결정 제약조건에 대해 알아보았다. 무결성 제약 조건에 추가적으로 

엔티티 무결성 제약조건, 참조 무결성 제약조건 두 가지가 더 있다. 이것에 대해 간단히 정리했다.

 

 

2-5. 엔티티 무결정 제약 조건

어떠한 기본키의 값도 Null 값이 될 수 없다는 것이다. Key는 릴레이션의 각 tuple을 구별해줘야하기 떄문이다.

 

2-6. 참조 무결성 제약 조건과 foreign key

1) 참조 무결성 제약 조건 

두 릴레이션 사이에 명시되는 제약조건인데, 두 릴레이션의 일관성을 유지하는데 사용된다. 

P라는 릴레이션에 있는 A라는 tuple이 Q라는 릴레이션의 B라는 tuple을 참조하기 위해서는 Q릴레이션에는 B는 반드시 B가 있어야한다는 제약조건이다. 

예를 들어 그림1)에서 EMPLOYE의 Dno 어트리뷰트는 부서 번호를 값으로 가진다. DEPARTMENT에서 Dnumber는 부서 번호를 나타내는데, EMPLOYE의 Dno 값은 반드시 DEPARTMENT의 Dnumber 값들 중 한아여야한다. 

 

2) foreign key (외래키)

우선 외래키는 참조 무결성 제약조건을 더욱 엄격히 정의하기 위해 필요한 개념이다.

외래키는 두 릴레이션 스키마 R1, R2가 있을 때 R1의 일부 어트리뷰트 집합 K가 아래의 2가지 규칙을 따른다면 K는 릴레이션 R2를 참조하는 R1의 foreign key라고 한다. 

• K라는 애트리뷰트 집합은 R2의 기본키(이를 M이라고하면)들과 동일한 도메인을 가진다. 
• R1릴레이션의 현제 어떤 상태에 대해 t1이라는 한 투플에서 K의 값은 현제 상태 R2에서 어떤 투플 t2의 M 값과 일치하거나 NULL 값을 가진다.

위 내용을 쉽게 정리해보면, EMPLOYEE 릴레이션의 부서 번호를 나타내는 Dno 라는 어트리뷰트가 있고 이 값들은 1~10 사이의 범위의 값이라고 하자. 

DEPARTMENT 릴레이션의 Dnumber라는 기본키인 애트리뷰트가 있는데 이 값 역시 1~10 사이 범위이다. 

즉 EMPLOYEE의 Dno는 DEPARTMENT의 기본키인 Dnumber의 도메인들 중 하나이거나 NULL(직원이 부서가 없는 경우) 값을 가져야한다. 

위 조건을 만족시키는 EMPLOYEE의 Dno 어트리뷰트는 EMPLOYEE의 foreign key(외래키)가 된며, EMPLOYEE 릴레이션은DEPARTMENT 릴레이션을 참조한다 라고 말한다. 

 

이러한 릴레이션의 외래키는 그림1)에서와 같이 그 외래키가 참조하는 곳으로 화살표로 나타낼 수 있다. 

그렇다면 반드시 화살표를 받는 쪽은 기본키가 되야할 것이다.

---

3-1. 릴레이션의 3가지 갱신 연산

1) 추출과 갱신

관계 모델의 연산은 크게 추출과 갱신 2가지로 나누어진다. 그 중 갱신 연산에는 삽입, 삭제, 수정 이라는 3가지 작업이 있다.

이런 갱신 연산의 사용에 있어 관계 DB의 스키마에 정의된 무결성 제약 조건을 위배하지 않아야한다.

하지만 3가지 연산과정 중 이것의 위배 현상, 예를 들어 a) 키 제약 조건, b) 엔티티 무결성 제약 조건, c) 참조 무결성 제약 조건 등을 위배 것에 대해 어떻게 대처하는지에 대해 아래 3가지 연산을 정리하면서 함께 정리해보았다. 

 

2) 삽입 연산

삽입 연산이란 릴레이션에 새로운 투플을 삽입하는 것이다. 

삽입 연산은 새로운 투플에 대한 애트리뷰트 값들을 명시한다. 삽입 연산시 위에서 설명한 무결성 제약 조건을 위배할 수 있다. 아래 두 가지 상황은 무결설 제약 조건이 위배되는 경우이다.

• 예를 들어 삽입 연산으로 주어진 애트리뷰트의 값이 도메인 집합의 값이 아니라면 이는 도메인 제약 조건을 위배하게 된다. 
• 새로운 투플이 기존의 투플과 중복된다면 key 제약조건을 위배하게 된다. 

위 상황처럼 삽입 연산시 하나라도 제약 조건을 위반한다면 그 삽입은 reject된다. 

 

3) 삭제 연산

삭제 연산이란 릴레이션의 투플을 삭제하는 것을 의미한다. 삭제 연산시 제약 조건을 위배하는 경우로는

삭제 하려는 투플의 key 값이 다른 릴레이션의 투플의 어트리뷰트에 의해 "참조" 즉 외래키가 참조하고 있는 경우에 삭제를한다면 삭제 연산이 reject 된다. 

이러한 경우 3가지 옵션으로 reject를 대처할 수 있다. 

 

옵션1) 

삭제를 거부하는 restrict 옵션이다. 

 

옵션2) 

예를 들어 DEPARTMENT의 Dnumber 중 111이라는 번호를 제거하는 연산을 한다고 생각해보자. 이때 EMPLOYEE의 Esn(외래키) 는 Dnumber를 참조하기 때문에 삭제 연산이 거부되지면 옵션2인 cascade 옵션을 사용하면 연쇄 삭제로 아래와 같이 삭제가 가능하다. 

DEPARTMENT의 Dnumber 중 111 삭제 -> EMPLOYEE의 Esn중 111을 가진 EMPLOYEE relation의 tuple 삭제 수행 

 

옵션3) 

set null 또는 set default라고 부르는 세 번째 옵션은 옵션2에서 예로 들었던 상황에서 연쇄 삭제가 아닌 

EMPLOYEE의 Esn중 111을 가진 값을 변화시키는 것이다. 

이 값을 null로 바꾸거나 유효한 다른 디폴트 투플을 참조하게 하는 것이다.

이때 만약 Esn의 값이 EMPLOYEE의 기본키라면 null로 바꿀 수 없다는 엔티티 무결성 제약조건이 있으므로 이 경우는 null로 바꿀 순 없다.

 

이러한 3가지 옵션들을 조합하여 적용해 삭제 연산시 일어나는 reject를 대처할 수 있다.

 

4) 갱신 연산

갱신 연산은 릴레이션의 투플내의 일부 어트리뷰트 값들을 변경하는 것이다. 

변경하려는 값의 어트리뷰트가 기본키 또는 외래키가 아니라면 변경하는데 있어 변경 값의 데이터 타입과 도메인에 속하는 값이기만 하면 문제가 발생하지 않지만 문제가 발생되는 경우에서는 삭제 연산에서 설명한 대처 방법을 적용하면 된다. 

 

추가로 트랜잭션이란 읽기, 삽입, 삭제, 갱신과 같은 연산들을 수행해주는 프로그램이다.