코딩공작소

함수적 종속성(FD)와 정규화 본문

어플리케이션개발/DB

함수적 종속성(FD)와 정규화

안잡아모찌 2018. 11. 28. 16:01

정규화이론의 필요성


 - DB 디자인 결과의 평가

 - relation schemas의 좋음을 토론할 수 있는 레벨 : Logical or conceptual level, Implementation or physical level



Relation schemas를 위한 정보 디자인 가이드라인

  • Imparting clear semantics to attribute
  • Redundant information and anomalies
  • NULL values
  • Generation of spurious tuples



1.Imparting clear semanics to attribute


 - 관계의 의미들 : 하나의 튜플에 있는 속성값의 해석으로부터의 의미있는 결과들

 - 관계의 의미들을 더 설명하기 쉽다 : 더 나은 스키마 디자인을 가리킨다 ( fact들을 조합해서 현실세계를 표현,이용,활용한다 )



<나쁜 예>


다수의 앤티티 타입과 관계타입들을 하나의 단일 관계로 속성들을 결합하지 않아야 한다.

해결방안은 view를 만들어서 사용하는 것이다.



update후에 중복 값이 서로 다른 값을 갖을 수 있다.



<좋은 예>


의미를 더 쉽게 설명하기 위한 디자인 관계 스키마




2.Redundant information and anomalies


 - 속성들을 관계 스키마로 그룹핑한다. : 저장 공간에 의미있는 영향을 미친다.

 - update anomalies에 따라서 기본 관계의 자연 조인을 저장한다.

 - update anomalies의 타입 : 삽입, 삭제, 수정 ( 공간낭비 + 이상현상 발생 )


 - 관계에서 업데이트 이상현상이 없도록 하기 위한 base relation schemas를 디자인 해라.

 - 어쩔 수 없이 생긴다면 명확하게 note해야 한다. (de-normalization 할 때)



3.NULL values


 - 저장공간을 낭비한다.

 - 의미를 이해하는 것에 문제가 생긴다


 - 빈번하게 NULL값이 생기는 values는 기본 관계에서 피하는것이 좋다.

 - 만약 NULL을 피할 수 없다면 대다수의 튜플에서가 아닌 예외적인 경우에만 적용되야 한다.



4.Generation of spurious[각주:1] tuples


 - 테이블들을 너무 막 쪼개다보면 join할 때 없던 정보가 만들어질 수 있다.

 - 원래 있던 튜플의 집합들보다 더 많은 튜플을 만드는 결과를 생산할 수 있다.

 - 이를 spurious tuples 이라 한다.

 - 이 가짜 튜플들은 유효하지 않다.


 - 적질히 연관되어 있는 속성들을 equi conditions으로 조인 할수 있는 relation schemas를 디자인해라. (가짜 튜플이 안생기게)

 - FK,PK의 관계를 기준을 쪼개야 한다. key를 이용해서 쪼갤 수 있어야 한다.




<요약과 디자인 가이드라인>

  • 이상현상은 이미 실행된 중복을 초래할 수 있다.
  • NULLs에 의해서 저장 공간의 낭비가 생길 수 있다.
  • NULL값 때문에 조인과 성능에 어려움을 겪을 수 있다.
  • 타당하지 않고 가짜 데이터가 조인을 할때 생길 수 있다.



Functional dependency


 - 정의 : 어떤 다른 두개의 튜플 t1, t2와 관계 r이 있을때, t1[X]=t2[X]을 만족하게 되면 반드시 t1[Y]=t2[Y]을 만족해야 하는 제약조건이다.

       X,Y는 서로 다른 속성들의 집합이다.   

 - 관계스키마들을 분석하기 위한 형식적인 도구

 - 관계 스키마가 얼마나 잘 되어있는지를 판단할 수 있는 도구

 - DB로부터 속성들의 두 집합사이의 제약조건

 - relation이 주어지게 되면 어떤 FD인지 찾을 수는 없지만 위반여부를 확인 할 수는 있다.



Normalization


 - 일련의 테스트 시리즈를 통해 관계 스키마를 선택한다.

 : 확실한 normal form을 만족하는지 아닌지를 검증한다. Top-down방식(쪼개기)으로 실행한다.

 - Normal Form tests(NF)

 : 관계의 정규화는 만족하는 가장 높은 정규조건과 어느정도 정규화가 되었는 지를 가리킨다.


 - 관계 스키마가 가져야하는 특성들

 : (필수) ★Non-additive(lossless) join property : 무손실 분해 , 정확성을 유지

 : (권장) Dependency preservation property : 테이블을 조인할 때, 실행시간이 늘어난다.

 



NF의 실질적인 사용


 - 결과 디자인은 고품질이고 앞서 언급된 바람직한 특성들을 만족시킨다.

 - 3NF, BCNF, 최대 4NF까지의 정규화에 주의 해야한다.

 - 반드시 가장 높은 정규화까지 만족시킬 필요는 없다.( 타당한 이유가 있다면 )

 - Denormalization은 낮은 정규화의 기본 관계로서의 NF 관계의 조인을 저장하는 과정이다.




키의 정의


 - Super key and key

 - Candidate Key

 : 관계 스키마에서 하나 이상의 키가 있다면 One is primary key(PK), others are alternate key

 - Prime vs nonprime attribute

 : 만약 속성이 관계 R의 후보키들 중 하나의 멤버라면, 그 속성은 R의 prime attribute이다.

 : 또한 속성이 prime attribute가 아니라면, 즉 어떤 후보키의 멤버가 아니라면, 그 속성은 non_prime이다.




<1NF>

  • flat relational model에서의 관계의 형식적인 정의의 부분
  • 모든 속성값들은 atomic values여야 한다.
  • composite attribute, multi attribute를 처리해야 한다.
  • nested relations을 허용하지 않는다.
  • nested relation 속성을 없애고 새로운 관계를 만든 후, PK를 그것에 넣어준다.


원래는 별도의 테이블을 만들어 주어야한다

(c)는 1NF는 만족하는 형태.




<2NF>


  • full FD에 의존한다. <--> partial dependency
  • 정의 : 모든 nonprime attribute가 PK에 의해 full FD로 의존적이면 2NF이다.
  • PK가 non prime 속성들을 결정하는 것에 전부 관여해야 한다.
  • 최소 2개 이상의 속성으로 키가 이루어져 있어야 한다.
  • 진부분, 가부분 집합으로 구별가능 해야하고 진부분 집합이 결정자 역할을 할 수 있다면 partial dependency이다.
  • FD : AB -> D 이고 FD' : B -> C 를 만족하게 된다면 2NF가 아니다.
  • 해결방안 : 쪼개준다. R1(B,C) , R2(A,B) , 문제가 된 속성들로 스키마를 만들고 나머지로 또 다른 스키마를 만든다.



PK는 2NF를 만족한다.

FD2는 FULL FUNCTIONAL DEPENDENCY를 만족한다.

FD3는 PARTIAL이기 때문에 2NF를 만족하지 않는다.

FD4는 3NF를 만족하지 않는다.



**쪼갤 때 결정자는 남기고 종속자만 뺀다.

--> JOIN할때 이용하기 위해 FK형태로 참조한다.




<3NF>

  • transitive dependency에 의존한다.
  • 정의 : nonprime attribute가 이행 함수적 종속성을 갖지 않는 다면 3NF이다.
  • FD1 : A->B , A-> C . FD2 : B->C 이면 FD2때문에 3NF를 만족하지 않는다.( 우회하는 길(transitively dependency)이 존재하면 안된다. )
  • 결정자가 PK의 일부분이면 안되고, non-key attribute여야 한다.
  • 2개 이상의 nonprime attribute가 있고, 하나의 NP가 다른 NP로 종속될 수 있으면 3NF가 아니다.
  • 해결방안 : 쪼개준다. (FK,PK의 관계로 쪼개야 한다.) 문제가 되는 속성들로 하나의 스키마, 나머지들로 하나의 스키마를 만들어준다.


**대안 정의 : BCNF때문에 약간 변경.
 : 관계 R에 있는 모든 nonprime 속성이 아래의 두조건을 만족해야한다.
 - R의 모든 키는 fully FD를 만족해야한다.
 - R의 모든 키는 non-transitively dependent여야 한다.



<Boyce-Codd(BF) Normal Form definition>

  • 모든 BCNF는 3NF를 만족한다.
    : 하지만 3NF중에서는 BCNF를 만족하지 않는 것들도 있다.
  • 정의 : nontrivial functional dependency X-->A가 R안에 있고 X가 R의 후보키들중 하나이면 BCNF를 만족한다.
  • 다른점 : prime인 A가 BCNF로부터 부재한다.
  • BCNF는 정확성이 좋다
  • 3NF는 효율성이 좋다
  • denormalization을 할 때는 타당한 이유가 있어야 한다.


(b)는 3NF는 만족하지만 BCNF는 만족하지 않는다.

후보키가 아닌 C가 FD : C -> B를 만족하기 때문.







Prime attribute


 - 어떤 후보 키의 부분들은 prime하다고 여겨진다.

 - 관계의 모든 후보키와 관련하여 부분, 전체 함수종속성, 이행 종속성 를 고려해야 한다.














  1. 가짜의 [본문으로]

'어플리케이션개발 > DB' 카테고리의 다른 글

DB application programming  (0) 2018.11.21
형식 DB언어  (0) 2018.11.21
SQL DML  (0) 2018.11.15
기본 SQL  (0) 2018.11.09
데이터베이스물리설계  (0) 2018.11.07