[데베시] 12강

relation schema 디자인 가이드라인 & functional dependency(함수적 종속)

- goodness of DB shema?

 

Informal Design Guidelines for Relation Schemas

- good table schemas를 정의하는 과정 : 몇개의 table로 구성? 각 테이블은 어떤 속성을 가질것인가?

- 직관적 판단 근거 : (1) attributes의 의미 (2) tuple의 중복 정보 (3) tuple 내의 NULL 수 (4) 가짜 튜플 수

- 정형화된 판단 근거 : Normalization(정규화)

 

Semantics of Attributes in Relations

하나의 relation에 속한 attribute들은 모두 현실 세계에서 상호 연관된 의미가 있어야 한다. (ex. STUDENT(name, age, gender, address) )

-> Guideline 1 : 각 튜플은 하나의 entity instance나 relationship instance에 해당해야 한다. (서로 다른 엔티티 타입의 속성을 하나로 묶거나 관계 타입을 하나의 릴레이션에 묶지 말 것)

Guideline 1을 어긴 예시

 

Redundant Information

- Minimizing storage space : 중복된 값이 저장

되면 공간 효율이 나쁨 -> 테이블 스키마 디자인의 목적 : 중복 정보 제거

1:N의 관계 : Dnumber, Dname, Dmgr_ssn 이 여러번 중복된다.

M:N 관계 : 두 종류의 중복 칼럼이 나온다.

Update Anomalies(이상)

- tuple을 Update할 때 기대하지 않은 동작을 하지 않아야 함. (Insertion, Deletion, Modification)

- Insertion Anomalies(삽입 이상) : 삽입하고 싶은 tuple을 삽입할 수 없는 현상 ex) EMP_DEPT는 사람이 없는 빈 DEPARTMENT는 생성 불가능.  

- Deletion Anomalies(삭제 이상) : 삭제하고 싶은 tuple을 삭제할 수 없는 현상 or 삭제할 때 원하는 정보 이외의 정보까지 함께 삭제되는 현상 ex) EMP_DEPT에서는 특정 부서의 마지막 남은 직원을 삭제하면 직원 정보 뿐 아니라 부서 정보까지 함께 삭제됨

- Modification Anomalies(갱신 이상) : 하나의 튜플을 갱신한 결과 다른 튜플과의 정보가 차이가 발생하는 현상 or 하나의 튜플만 갱신해서는 원하는 갱신이 이루어지지 않는 현상 ex) EMP_DEPT에서 부서의 매니저를 변경하려면 해당 부서의 모든 튜플을 갱신해야만 한다.

-> 모두 독립적인 table로 만들면 해결 

-> Guideline 2 : update anomaly가 없도록 설계해야 함 -> Anomaly가 존재한다면 어떤 종류인지 어떻게 해결할 수 있는지를 확실히 해야 함.

 

NULL Values in Tuples

- NULL : Unknown Value / Unavailable or Not Applicable Attribute

- NULL value의 문제 : 저장공간 낭비, 애매모호한 의미, Aggregate function 사용의 어려움

- NULL이 생기는 걸 피할 수 없다면? : 최소한 대부분이 NULL이 되지는 않도록 설계, 너무 NULL이 많을 것 같다 싶으면 아예 새로운 relation을 만들기 ex) 전체 직원 중 단 10%만 개별 사무실을 갖는다고 할 때 EMPLOYEE relation의 attribute로 넣으면 90%는 NULL이 들어가게 됨 -> EMP_OFFICES(Essn, Office_number)라는 새로운 relation을 만들어 개별 사무실이 있는 직원의 정보만 따로 넣어주기. -> null value 줄일 수 있음.

 

Spurious Tuples(가짜 튜플)

- NATURAL JOIN의 결과로 생성된 tuple이 invalid information일 때 이를 Spurious Tuples이라고 함. 설계가 잘못되어서 생기는 문제. ex)

잘못 설계된 예

JOIN의 결과 점이 찍힌 tuple들은 현실과 다른 정보를 나타내고 있다.

-> Guideline 4 : relation을 join할 때 Foreign key나 Primary key가 아닌 attribute로 조인이 되지 않도록 해야 한다.

 

 

Functional Dependencies(함수적 종속) *****중요*****

- 개념 : relational schema의 분석에 대한 공식적인 도구, normal form인지 아닌지를 판정할 때 key와 함께 사용

- 형식 : X -> Y (X,Y는 R의 attribute의 subset) - Y가 X에 함수적으로 종속된다. or X가 Y에 의해 함수적으로 결정된다.

- 의미 : 특정 relation의 두 튜플 t1과 t2에 대해 t1[X] = t2[X]라면 t1[Y] = t2[Y]인 경우 X -> Y

  -> 해석 : 하나의 튜플이 X에 대해 같은 값을 가진다면 Y에 대해서도 같은 값을 가진다. or X attribute set의 값이 Y attribute set의 값을 유일하게 결정한다.

- 예시 : Department(학과) -> School(단과대) / City(시) -> Province(도)

- 특징 :

   (1) X가 R의 후보키라면 R의 임의의 모든 attribute subset Y에 대해서도 X -> Y가 성립 : X가 key니까 unique하므로

   (2) R에서 X -> Y일 때 반드시 Y -> X인 것은 아니다. (교환법칙 성립 x)

- FD는 table schema R의 특성(property)이다. : 하나의 특정한 table instance r에 대해서만 성립하는 것이 아님 -> r(R)인 모든 instance에 대해서 유지되는 제약조건이다. -> r로부터 추론되는 개념이 아니라 R을 설계할 때 이미 정해지고 이후로 r이 추가될 때 지켜져야 하는 요소. (이전에 key constraint와 비슷)

예시

 

Inference Rules for FDs

- F : table schema R에 정의된 functional dependencies의 집합

- F+ : F의 closure. F로부터 추론될 수 있는 모든 dependencies의 집합. (당연히 F도 포함됨)

ex) F = {Ssn -> {Ename, Bdate, Address, Dnumber}, Dnumber ->{Dname, Dmgr_ssn} } 일 때 다음과 같은 FD들이 추론 가능함 : (1) Ssn -> {Dname, Dmgr_ssn} (2) Ssn -> Ssn (trivial) (3) Dnumber -> Dname

- Armstrong's inference rule(추론 규칙)

   - (1) IR1 (reflexive rule) : if X ⊇ Y, then X -> Y : Y가 X의 subset라면 Y는 X에 함수적 종속 ex) 

   - (2) IR2 (augmentation rule) : {X->Y} |= XZ->YZ : Y가 X에 함수적 종속이라면 Y에 Z attribute set이 추가된 YZ는 X에 Z가 추가된 XZ에 함수적 종속 ex)

   - (3) IR3 (transitive rule) : {X->Y, Y->Z} |= X->Z

 -> Armstrong's IR1~3은 Sound하고 Complete함 : Sound (이 rule대로만 찾으면 틀린 rule이 만들어지지 않음) Complete(이 룰을 적용하면 모든 FD를 찾을 수 있음)

   - (4) IR4 (decomposition rule) : {X->YZ} |= X->Y, X->Z : Y와 Z를 합한 subset이 Z에 함수적 종속이라면 Y랑 Z 모두 X에 함수적 종속

   - (5) IR5 (union rule) : {X->Y, X->Z} |= X->YZ : Y랑 Z 모두 X에 함수적 종속이라면 Y와 Z를 합한 subset이 Z에 함수적 종속

   - (6) IR6 (psuedo-transitive rule) : {X->Y, WW->Z} |= WX->Z : IR2와 IR3을 합친 rule

 -> IR4~6은 IR1~3으로부터 증명 가능

 

Systematic Way to Determine Additional FDs

X : F에 속하는 FD 중에서 좌측변에 속하는 attribute의 집합

X+ : closure of X under F. X에 의해서 함수적으로 결정되는 attributes의 집합. X 각각에 대해 결정됨. 

X+를 구하는 알고리즘

실제 예시