정규화
동기
데이터는 원래 종속적임.
근데 테이플 하나에 다 표현하면 속성 간 종속으로 이상이 발생함
이상(Anomaly)
삽입 이상 - 내가 모르는 속성이 많아서 원치않는 null 등으로 채움
삭제 이상 - 학생튜플을 지웠는데 학과 속성도 없어짐
갱신 이상 - 중복이 너무 많아서 일관성유지 못함
그래서 정보 무손실 + 테이블 분리 + 데이터 중복 감소 하기로 함
1NF - 원자값 정돈
속성이 여러개의 값이 아닌 원자값(Atomic Value) 를 가짐
2NF - 기본키 정돈
(ID, 이름)(기본키) 로 회원번호가 결정되는데 ID 만으로도 결정된다?
기본키가 복합일 때 다른 속성이 기본키의 일부에 대해 종속적임 안댐
그럴거면 따로 빼지. 위는 부분함수적 종속이라 부름.
그래서 기본키에 대해 다른 모든 각각의 속성이 완전함수적 종속만 댐
3NF - 필드 정돈
ID(기본키) 로 우편번호가 결정되고 우편번호로 주소가 결정이 된다?
기본키로 A->B , B->C => A->C 인 이행적 종속 금지
기본키에 대해 (Transitive Dependency) 금지
정보의 무손실 표현(종속성 유지)가 되는 마지노선
BCNF(Boyce-Codd NF)
필드에 몬스터가 레벨별로 1마리씩 들어감
(필드, 레벨)(기본키)로 몬스터ID가 결정되는데 이 ID 가 레벨을 결정?
레벨 대신 ID 넣고 레벨 빼는게 나음.
그래서 결정자는 무조건 후보키어야만 함
(후보키는 1:1 대응이라 어쩔 수 없음)
4NF - 결합도
서로 독립적인 속성이 기본키 하나에 묶여있는 경우
MVD(Multi Valued Dependency, 다차종속)
A->>B, B가 A에 대해 종속적이고 A는 B와 독립인 다른 속성과도 관계
다차종속 A->>B 가 성립시 R 의 모든 속성이 A에 대해 종속관계여야 함.
뭔말이면 A가 서로 독립적인 속성 B, C 중 B 를 결정짓는다고 하자.
그럼 A->B 에 대해서 C 의 도메인 갯수만큼 데카르트 곱이 필요할 거임.
왜냐하면 C 는 B와 독립적이니까.
이러면 중복된 값이 많고 동시에 A->C 가 성립하지 않음.
그래서 테이블 하나 빼서 A->C 인거 만듬.
5NF - 결합도
4NF 결과값을 join 하면 원래값이 안나옴.
그래서 서로 독립적인 B ,C 그것만 테이블로 따로 빼서 원래값이 되도록함.
Join Dependency(조인 종속)
select 로 구성한 부분집합으로 join 할 때 자신이 되면 성립
모두 따로 만들면 조인 종속은 후보키에서만 성립하게 됨
반정규화
처리속도나 보안 등을 위해 의도적으로 정규화 안함
테이블 통합
Join 등 두 테이블이 자주 함께 사용되는 경우
1:1, 1:N, 슈퍼타입/서브타입 통합이 있어 레코드 증가 가능성 큼
슈퍼타입/서브타입 통합
슈퍼타입 기준 테이블 변환
조인 안해도 되고 뷰로 조회 삭제 가능
서브타입 구분 필요
서브타입 기준 테이블 변환
서브타입 구분 안해도 됨.
여러 테이블 통합된 뷰는 수정 불가능
개별타입 기준 테이블 변환
슈퍼타입 - 서브타입 은 1:1 관계임. 1:M 아님
용량이 덜 먹음
조인이 항상 발생해서 느림.
테이블 분할
수평분할 - 레코드별 빈도차이 큰 경우
수직분할
갱신 위주
레코드 잠금으로 다른 속성에 대한 검색도 안댐
자주 갱신되는 속성만 뺌
조회 위주 - ㅈㄱㄴ
크기가 큰 속성 - ㅈㄱㄴ
보안 위주 - 특정 속성에만 보안 적용하고 싶을 때
기본키의 유일성 관리가 어려워짐
중복 테이블 추가
집계 테이블 추가(트리거로 동기화), 진행 테이블 추가(이전 속성 값) 등
중복 속성 추가
데이터를 조회하는 경로 - 조인 을 단축
기본키가 여러개로 구성되어 더러울 경우
SQL Group Function(Sum, Avg 등) 으로도 해결될 수도 있으니 유의