[Chap 6] 도메인, 참조 무결성, 함수적 종속

6.1 도메인 제약(Domain Constraints)

- 가장 기초적인 형태의 무결성 제약 조건

- 도메인(=범위) 제약

.프로그래밍 언어: 변수마다 형(type)을 지정함으로써, 변수가 가질 수 있는 값을 제한

.보기: 정수형 변수는 실수형이나 문자열 값을 가질 수 없음.

- SQL에서 도메인 제약을 나타내는 방법은 

create table 대여(

테이프번호    char(7),

고객번호       char(7),

대여일자       date);

위의 스키마처럼 char, date와 같이 타입으로 도메인 제약함

6.2 참조 무결성(referential integrity)

- 외톨이 투플(Dangling tuples): join을 할 때, 다른 투플과 결합하지 못하는 투플을 가리킴.

.보기: select 학생.학번, 학생.이름, 수강.과목번호 from 학생, 수강 where 학생.학번=수강.학번;

이라는 SQL 명령어를 보면 학생테이블과 수강테이블을 자연조인 함.

자연조인의 결과, 학생테이블의 투플과 수강테이블의 투플 중에 자연조인 결과에 전혀 참여하지 않는 투플이 있을 수 있음.(아래의 (9902103, 김예슬)의 수강테이블 투플 하나와, (9944444, CS400)의 수강 테이블 투플) 이 투플들을 'dangling tuple' 이라고 함.

   학생    학번       이름

             ----  ------      ------   

                          9902101  홍길동

                          9902102  박두리

                          9902103  김예슬

                 수강     학번   과목번호

                -----   -------  -------

                        9902101    CS100

                        9902101    CS200

                        9902102    CS200

                        9902102    CS300

                        9944444    CS400

- dangling tuple에 대한 분석

.공통속성이 일차 키인 테이블에 있는 dangling tuple(학생표에서 PK={학번})은 있을 수 있는 경우?

있을 수 있다. 등록된 학생이지만 수강신청을 하지 않았다던가 신입생의 경우.

. 공통 속성이 외래 키인 테이블에 있는 dangling tuple(수강표에서 FK={학번})는 있을 수 있는 경우?

아주 잘못된 경우. 외래키이므로 수강 테이블에서는 dangling tuple이 나오면 안된다.

- 자료 값을 바꿀 때, 참조무결성을 유지하기 하려면?

. PK인 표에서 tuple을 ins, del, upd 할 수 있고 FK 인 표에서 tuple을 ins, del, upd 할 수 있으므로 6가지 경우를 따져야함. 

. 보기: 학생 테이블에서 지울려는 학번이 외래 키인 수강 테이블에 있을 때, 학생 테이블에서 투플을 지우기만 하면 참조 무결성 문제가 발생하므로, 지우지 않거나 수강 테이블에서 먼저 지운 뒤, 학생 테이블에서 지우도록 한다. 

6.3 함수적 종속(Functional Dependencies)

- 함수적 종속은 정규화 이론 및 설계의 바탕이 되는 중요한 개념

.관계형 데이터베이스 설계할 때는 스키마가 정규형(NF: Normal Form)을 따르도록 한다.

.많이 쓰는 정규형은 BCNF, 3NF등이 있음.

- 정규형은 함수적 종속을 써서 정의

- 함수적 종속은 어디에 쓰일까?

.함수적 종속을 써서 여러가지 정규형을 정의 함.

.정규화: 정규형을 따르지 않는 스키마는 여러개의 작은 스키마로 나누어서 각 스키마가 정규형을 따르도록 함.

- 함수적 종속은 수퍼 키(super key) 개념을 일반화 한 것.

.달리 말하면, 수퍼키는 함수적 종속의 특별한 경우.

.사실은 함수적 종속도 제약 조건의 한 종류.

- SQL이 함수적 종속 제약 조건을 바로 지원하지 않는 이유는?

.나중에 배우겠지만 BCNF 정규형을 따르는 스키마의 경우, 일차 키의 값이 같은 투플이 없으므로 굳이 함수적 종속을 따로 나타내지 않음.(학생 표에서는 학번이 같은 투플이 없음)

.그 밖에 함수적 종속을 나타낼 필요가 없는 이유는, 함수적 종속을 유지하려면 시간이 꽤 걸리니 사용자들이 무분별하게 쓸 것을 우려하여 제공하지 않는 것으로 짐작...

- 함수적 종속을 유지하는 방안

.투플 하나를 고치려고 할 때마다, 함수적 종속을 지키는지 않는지 확인해야 한다.

.함수적 종속의 왼쪽과 오른쪽에 해당하는 속성만 추출한 뒤, 

왼쪽이 같으면서 오른쪽이 다른 것이 있는지 확인해야 함.

확인 과정으로는 정렬, 임시 색인, 해쉬 등..

- 함수적 종속의 기본 개념

.수퍼키의 개념을 일반화한 것이므로, 수퍼키의 개념을 다시 먼저 살펴보면(복습),

관계형 스키마 R이 있고, 그 스키마에 따라 인스턴스 r이 있으며, 그 스키마 R의 속성 가운데 일부로 이루어진 부분집합 K가 있을 때, 인스턴스 r에 있는 모든 투플의 짝 t1과 t2에 대하여 t1과 t2가 같지 않을 때, t1.K != t2.K 를 성립하면 K는 스키마 R의 수퍼키가 된다.

.함수적 종속의 정의

a, b는 속성의 집합이라고 하자. 만일 테이블의 인스턴스 r에 있는 모든 투플의 짝 t1, t2에 대하여

t1.a = t2.a 이면, t1.b = t2.b가 성립할 때, 그 스키마에 함수적 종속 a -> b가 있다고 말한다.

.보기: 학생 = {학번, 이름}, PK = {학번} 

a. {학번} -> {이름} : CD -> {속성의 아무 부분집합} 의 경우는 다 만족한다.(CK 값이 같은 투플이 두개 있을 수 없기 때문에 당연히...)

b. {이름} -> {학번} : 이름이 같아도 학번은 다를 수 있기에 FD가 없다. (동명이인)

c. {학번} -> {학번} : FD는 있으나 뜻이 없는(trivial) FD이다.

d. {학번, 이름} -> {이름} : FD는 있으나 뜻이 없는(trivial) FD이다.

.함수적 종속과 수퍼키

수퍼키는 함수적 종속의 특별한 경우

수퍼키를 FD를 이용하여 다시 정의하면,

주어진 스키마 R이 있고, R의 속성 부분집합 K가 있을 때, K->R이 있으면 K를 수퍼키라고 한다. (즉, 수퍼키의 속성이 같은 때, 그 튜플의 모든 속성이 다 같아야 한다는 뜻.)

.FD는 어디에 쓰나?

함수적 종속을 써서 테이블에 insert/update을 실행하고자 할 때, 함수적 종속이 지켜질 때에만 해당 명령이 실행되도록 제한 할 수 있음.

FD을 써서 어떤 테이블의 인스턴스가 주어진 FD을 지키는지 안지키는지를 확인할 수 있음.

.FD는 테이블의 인스턴스만 보고는 결정할 수 없다!

FD는 설계자가 각 스키마에서 설계할 때 지켜져야 할 FD을 결정함. (인스턴스가 FD를 어기는지 아닌지는 판단할 수 있지만, 거꾸로 인스턴스를 보고 FD를 이끌어낼 수는 없다는 뜻.

.뜻이 없는 FD(trivial FD)

β ⊆ α 일때 , α --> β 를 뜻이 없는 함수적 종속이라고 함. 

보기. {학번} -> {학번}        /          {학번,이름} -> {학번}        /         {학번, 이름} -> {이름}

6.4 함수적 종속 집합의 클로져(Closure of a set of FDs)

- 함수적 종속 집합 SFD(a Set of FDs)가 주어 졌을 때,

.거기에 포함되어 있지는 않지만 유효한 다른 함수적종속을 이끌어 낼 수 있다.

.그렇게 이끌어 낸 함수적 종속은 SFD에 묵시적(implicitly)으로 포함되어 있다고 말한다.

- 함수적 종속 집합 SFD가 있을 때,

.SFD의 클로져(=closure, 울타리) SFD+는, SFD에 묵시적으로 포함되어 있는 모든 함수적 종속까지도 포함된 집합

- 함수적 종속을 이끌어내는 Armstrong 규칙 세개: A1, A2, A3

.A1: 되돌아오기 규칙(reflexivity rule)

뜻이 없는 함수적 종속 trivial FD를 이끌어 내는 규칙

.A2: 붙이기(늘리기) 규칙(augmentation rule)

속성의 집합  a,b에 대하여 a -> b가 있을 때, 왼쪽와 오른쪽에 속성의 집합 r를 모두 더한 함수적 종속 

ar ->br 도 또한 존재한다. 

.A3: 전이 규칙(transitivity rule)

함수적 종속 a -> b 와 b -> r이 있을 때, 함수적 종속 a -> r 도 있다.

- 또 다른, 함수적 종속을 이끌어내는 규칙 3가지: B4, B5, B6

.B4: 합치기 규칙(union rule)

함수적 종속 a -> b 와 a -> r가 있을 때, a -> br 의 함수적 종속이 있다.

.B5: 나누기 규칙(decomposition rule)

함수적 종속 a -> br 이 있으면, 함수적 종속 a -> b와 a -> r도 있다.

.B6: 의사전이 규칙(pseudotransivity rule)

함수적 종속 a -> b와 br -> d 가 있을 때, ar -> d도 있다.

6.5 규범적 커버(canonical cover)

- 주어진 함수적 종속 집합 SFD에서, 어떤 FD의 왼쪽 또는 오른쪽에 있는 어떤 속성을 뺐을 때, 그 클로져 SFD+가

바뀌지 않는다면 그 빠진 속성을 extraneous(관련이 없는) 속성이라고 한다.

.보기: SFD1에 {학번} -> {학번, 이름} 이라는 FD1을 가지고 있다고 가정하자. 그런데 이 FD1에B5(decompositon rule)를 적용하면 {학번} -> {학번}, {학번} -> {이름} 으로 나뉘게 된다. 여기서 FD1을 뜻이 없는 FD {학번} -> {학번}을 제외한 FD1-1를 만들고 FD1-1를 갖는 SFD2를 정의했을 때, SFD1+와 SFD2+를 계산했을 때 두 클로져는 같다. 이때 제외된 속성을 extraneous 속성이라고 함.

- 규범적 커버 SFDc는 다음을 만족한다

.SFD+ = (SFDc)+     (단, SFDc에 있는 어떤 함수적 종속에도 extraneous 속성이 없다.

.또한 a -> b와 a -> r와 같은 FD가 두개 있어서는 안되며 이 경우 a -> br 로 하나의 FD로 만들어야한다.

- SFDc는 프로그램으로 찾기가 쉽지 않고 SFDc는 유일하지 않음.(실제로 이를 찾기보다 3NF decomposition를 위해 이해가 중요)

6.6 FD를 SK의 관점에서 바라보기

- 원래 함수적 정의는 R1의 모든 투플의 짝 t1, t2에 대하여

.t1.a = t2.a 일 때, t1.b = t2.b 이면, R1 스키마에 함수적 종속 a -> b가 있다.

- 그런데 실제로 함수적 종속 FD1이 실제로 그 R1에 있는지 확인하기 위해서 다음과 같은 절차를 거칠 수 도 있음

.R1(a+b+c) 일 때, FD1: a ->b 가 존재하는지 확인하고자 함. 

R1을 R2(a, b)로 project해서, a가 SK인지 확인하고 SK 이면 FD1은 존재하는 것임.

- 하지만 앞서 언급했듯이, 주어진 인스터스가 그 FD를 어기는지 또는 어기지 않는지를 판단할 수 있지만, 주어진 인스턴스만 보고 어떤 FD가 있는지는 판정할 수 없음. 인스턴스가 없을 때에는 DB 설게자가 FD가 있는지 없는지, 있어야 할지를 결정함.