티스토리 뷰
SNLRWH
RW SNLRH
SNLRWH의 속성을 갖는 테이블을 아래 처럼 2개의 테이블로 분리 시킨경우 문제점
Joe라는 사람의 월급을 주고 싶을때 시급(H)과 일한시간(W)를 곱해서 계산해야 하는데, W와 H가 서로 다른 테이블에 있기 때문에
테이블 조인을 해서 계산해야 함.
1. 정규화를 할수록 테이블을 잘게 쪼개는데, 그럴수록 퍼포먼스가 떨어진다는 단점이 존재한다.
2.무손실 조인
쪼갠 두 테이블을 자연조인할 경우 원래의 테이블이 나와야 한다.(새로운 레코드가 추가되면 안됨)
무손실 조인을 지키기 위한 테이블 분해
R
UV R-V
이런식으로 테이블을 분해 해야한다. 왜 U는 R에서 빼지 않는가?
두 테이블을 다시 조인 하기 위해서 U는 오른쪽 테이블에서 빼지 않아야 한다.
SNLRWH
RW SNLRH
에서 R->W함수 종속성을 지키기 위해서 위와 같이 테이블을 분해 했을때 이 테이블들은 무손실 조인이 가능한가?
RW와 원래 관계인 SNLRWH에서 W가 빠진 SNLRH가 오른쪽 테이블로 분해 됬으므로 무손실 조인이 가능하다.
3.Dependancy Preserving (의존성 보존)
테이블을 쪼갰을때 원래 테이블에 있던 함수 종속성들이 그대로 하위 테이블에서 유지 되어야 한다.
데이터의 무결성을 보존하기 위해서 함수 종속성 무결성 제약조건을 지켜서 정규화를 더 깊이 할것인가
아니면 퍼포먼스를 위해 역 정규화를 할것인가를 상황에 맞게 잘 정하는 능력이 디비 관리자가 에게 필요한 능력이다.
F={C->CSJDPQV,JP->C,SD->P}
CSJDPQV
SDP CSJDQV
테이블 2개로 무손실 분해 하였다.
무손실 분해는 잘 되었지만, 의존성 보존이 되고 있지 않다 (JP-> C 때문에)
만약에 의존성 보존을 위해서 JPC라는 테이블을 추가로 생성하는 것은 안좋은 설계이다.
테이블을 분해할때(정규화 할때) 무손실 분해와 의존성 보존은 반드시 지켜야 하는 것들이다.
무손실 분해는 항상 가능하다. 하지만 의존성 보존은 항상 지켜지지는 않는다.
제3정규형은 무손실분해와 의존성 보존을 항상 보장할수 있지만
보이스/코드 정규형은 보장이 안된다.
그래서 데이터 베이스 설계할때 무조건 최대한 제3정규형까지는 정규화를 해주어야 한다.
그래야 데이터 중복성을 해결해서 데이터 무결성을 지켜줄수 있다.
가능하면 보이스/코드 정규형까지 해주면 좋겠지만 위의 예처럼 불가능한 경우에는 그냥 제3정규형까지만 정규화 하면 될것이다.
Minimal Cover
F={A->B,ABCD->E,EF->GH,EFACDF->EG}라는 함수 종속성이 존재하는 테이블이 있다고 할때,
Minimal Cover 를 구해서 그것을 이용해서 테이블을 분해할 경우 의존성 보존과 무손실 분해를 동시에 만족시킬수 있다.
Minimal Cover란 결정자에의해 결정된 Y값이 1개의 속성으로 이루어져있으며 최소한의 집합이다.
암스트롱 액시엄을 적용시키기 전인, F+가 아닌 F에서 뽑아내야 한다.
위의 함수 종속성 집합인 F에서 미니멀 커버를 추출해보자.
G={A->B,ACD->E,EF->G,EF->H}로 뽑아낼수 있을것이다. 이 미니멀 커버에 암스트롱 액시엄을 적용시키게 되면 원래의 함수 종속성인
F가 나오게 된다.
한마디로 G나 F나 같은 함수 종속성을 나타낸다.
애초에 ER다이어그램을 설계할때 후에 나타날 데이터 중복성을 미리 없애 주는 것을 해보자.
각 부서별로 할당된 parking lot이 존재한다고 해보자.
Employees 와 works_in을 합쳐서 workers라는 테이블을 만들건데,
workers={S,N,L,D,S}로 구성될것이고
Departments={D,M,B}로 구성될 것이다.
여기서 workers테이블을 보면 부서가 파킹랏을 결정하게 되는데, workers테이블의 키는 S이다. 따라서 키가 아닌 D라는 속성이
또다른 키가 아닌 L을 테이블 내에서 결정하게 되므로 제3정규형 테이블 이상으로 만들어 주기 위해서는 후보키만이 결정자가 되게끔
테이블을 분해해 주어야 한다.
따라서 SNLDS를 SNDS와 DL로 나누어야 한다. 그래서 After그림에서 Employees 엔티티에 ssn과 name since 외래키 did까지해서 4개의
속성을 가지게 되는것이고 lot은 departments 엔티티에 포함되게끔 해주었다.
원래는 테이블을 3개 만들어 줘야 하지만, 위와 같은 경우에는 D->L을 유지시키기 위해서 굳이 테이블을 따로 만들어줄필요 없이 L속성을 오른쪽 엔티티에 포함시키면 될것이다.
그렇게 되면 이행적 함수 종속성이 Departments테이블에 존재하지 않아서 제3정규형인 테이블이며,
모든 함수 종속성의 결정자가 키이므로 보이스/코드 정규형이다.
정규화를 알고 나니까 ER다이어그램 설계 과정에서도 어느정도 정규화를 해줄수 있는 것이다.
제대로 하려면 나중에 테이블을 만들고 나서도, 함수 종속성을 파악해서 한번더 정확하게 정규화 해줄 필요가 있다.
키가 아닌것이 키가 아닌 것을 결정하면 데이터 중복성이 다수 발생할 가능성이 있다는것을 아는게 제일 중요하다.
보이스 코드 정규형은 데이터 중복성이 없는 정규형이다.( 모든 결정자가 후보키 이므로) -> 강력한 제약 조건
미니멀 커버로 테이블을 분해하지 않았을때 무손실 분해는 되었지만 함수 의존성 보존이 안될수도 있다.
이런경우엔 역 정규화를 통해서 제3 정규형 까지로만 만드는 방법이 있을수 있다.
역 정규화를 하게 되면 조인을 덜 하게 되므로 퍼포먼스가 좋아진다.
정규화를 하면 할 수록 데이터 중복성이 사라진다. 효율적인 데이터베이스 설계가 된다.
'컴퓨터 공학과 졸업 > 데이터베이스' 카테고리의 다른 글
데이터베이스 튜닝 (0) | 2017.12.07 |
---|---|
데이터베이스 정규화 4 - 예시 (0) | 2017.12.07 |
데이터베이스 정규화 - 2 (암스트롱의 원리) (0) | 2017.11.30 |
데이터베이스 정규화 - 1 (0) | 2017.11.30 |
중간정리 (0) | 2017.10.21 |
- Total
- Today
- Yesterday
- Babel
- promise
- Action
- Polyfill
- es6
- Next.js
- reactdom
- react
- hydrate
- storybook
- react hooks
- type alias
- webpack
- await
- computed
- state
- props
- useRef
- javascript
- typescript
- async
- useEffect
- return type
- server side rendering
- rendering scope
- reflow
- mobx
- reducer
- design system
- atomic design
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |