티스토리 뷰

반응형

제1 정규화
   ⊙ 반복된 속성이나 그룹 속성은 삭제하고, 새로운 실체를 추가한 뒤 기존의 실체와  1 : N의 관계를 형성한다

제2정규화
   ⊙ 복합키로 구성된 경우 모든 칼럼들은 복합키 전체에 의존적이어야 한다. 
   ⊙ 복합키 일부에 의존적인 칼럼은 제거해야 한다
   ⊙ 복합키가 아닌 경우는 제2정규화의 대상이 아니다

제3정규화
   ⊙ 테이블의 칼럼들은 기본키에 의존적이어야 한다.
   ⊙ 기본키 외의 칼럼에 종속적인 칼럼은 제거해야 한다.

대부분 1~3정규화만 잘 지켜도 물리 DB를 구축시 크게 문제될 경우가 없다고 해도
과언이 아니다라고 합니다.  보이스코드, 4차 5차 정규화까지 갈 경우가 그리 많지
않다는 얘기구요. 꼭 필요할 경우 1~3차에 반정규화 정도가 적당하지 싶습니다.
정말 중요한 1~3차 정규화를 예를 들어 설명하자면 먼저
1정규화는 고객정보를 저장하는 테이블이 있다고 가정할 때 고객명, 납부자명, 배우자명
등 고객과 관련된 사람들의 이름이나 주민등록번호가 새로운 업무가 생길때 마다 컬럼으로 추가되는 현상이 있을 경우 1정규형을 위반했다고 합니다.
보통 컬럼에 1,2,3 식으로 숫자가 붙는 경우가 이런 경우겠죠.
모델링이나 sql를 떠나서라도 관리측면에서 매우 어렵습니다.
2정규형은 uid 즉 pk가 복합키로 구성되었을 경우 모든 컬럼들은 복합키 전체에
의존적이어야 합니다. 학생과 강좌라는 엔터티 사이에 수강이라는 교차 엔터티가
있을 경우 수강의 키는 학번 + 과목코드가 될텐데요, 수강이라는 컬럼에 학생명이 들어
간다고 예를 들면 학생명은 학번에는 속하지만 과목 즉 강좌에는 속하지 않습니다.
이것을 제 2정규형을 위반했다고 합니다. 그럼 수강에는 어떤 컬럼이 있을까죠?
학점 정도가 있겠죠. 학생에도 속하고 강좌에도 솏하는 .. .
3정규형도 예를 들면 쉬운데요. 수강이라는 엔터티에 학점코드, 학점설명 이렇게
2개의 컬럼이 있다면 둘다 2정규형은 위반하지 않았습니다. 하지만 학점설명은 uid 즉
학번 + 과목코드에만 종속적인 것이 아니라 학점코드에도 종속적이기 때문에 이런 경우를 3정규형을 위반했다라고 합니다. 학점설명은 학점이라는 엔터티에 들어가야 겠죠.



반응형