코딩공작소
함수적 종속성(FD)와 정규화 본문
정규화이론의 필요성
- 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형태로 참조한다.
- 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는 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하다고 여겨진다.
- 관계의 모든 후보키와 관련하여 부분, 전체 함수종속성, 이행 종속성 를 고려해야 한다.
- 가짜의 [본문으로]
'어플리케이션개발 > 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 |