1.정규형의 종류
- 1정규형(First Normal Form)
- 2정규형(Second Normal Form)
- 3정규형(Third Normal Form)
- 보이스코드 정규형(Boyce-Codd Normal Form, 이하 BC정규형)
- 4정규형(Fourth Normal Form)
- 5정규형(Fifth Normal Form)
- 순서대로 진행되는 것은 아니며 일반적으로 3정규형을 만족하면 1,2정규형도 만족하게 됨
2.1정규형
1정규형의 원칙
- 모든 속성은 반드시 하나의 값을 가져야 함
- 1정규화와 관련된 속성은 다가 속성과 복합 속성
다가속성(Multivalued Attributes)
- 같은 종류의 값을 여러 개 가지는 속성을 다가 속성이라 함
- 위 그림의 모델은 하나의 속성에 여러 전화번호를 관리하고 있으므로 속성은 반드시 하나의 값을 가져야한다는 1정규형에 어긋남
- 위와 같이 다가 속성이 존재하면 새로운 릴레이션이 필요함
- 위와 같은 릴레이션을 1정규화하면 아래와 같음
- 이를 모델로 표현하면 아래의 오른쪽 모델과 같음
- 위와 같이 하나의 속성에 여러 값을 가지는 사례는 흔치 않고 보통은 아래와 같은 릴레이션으로 관리함
- 위 릴레이션은 물리적으로는 모든 속성이 하나의 값만을 가지고 있지만, 논리적으로 하나의 값을 가지고 있다고 볼 수 없음
고객이름과 주민등록번호 속성은 중복되었고, 고객ID에 종속돼서 2정규형을 만족하지 못함 - 하지만 성능을 위해 비정규화된 아래와 같은 모델을 사용할 수 있음(반복 속성이 고정적일 경우)
- 이 경우 속성에 의미를 명확히 부여해야함 전화번호1, 전화번호2, 전화번호3 과 같이 사용하는 것은 바람직하지 않음
- 위와 같은 비정규형은 null 데이터가 많이 발생할 수 있고 인덱스가 많이 필요하며 'or' 조회가 많이 발생할 수 있는 단점이 존재
복합속성(Composite Attributes)
- 하나의 속성이 여러 개의 속성으로 분리될 수 있을 때 이를 복합 속성이라 함
- 복합 속성은 속성의 관리 수준에 따라 달라질 수 있음
- 주소 속성은 시,구,동,번지 데이터를 따로 관리하게 되면 복합 속성이 됨
- 복합 속성처럼 보인다 하여 무조건 분해하면 안 됨
- 위와 같은 주소 속성의 경우 한꺼번에 입력하고 조회하는데 분해해서 입력하고 각각을 합치는 것은 비효율적
- 위의 표에서 시,구,동,번지가 각각 유의미한 속성으로 통계등에 활용된다면 분해하는 것이 좋음
반복속성
- 한 릴레이션에서 반복 형태의 속성이 있어서는 안 됨
- 다만 위와 같은 모델에서 상품이 3개 이상은 절대로 주문 불가하다면 비정규화된 모델이 유리할 수 있음
비정규형과 정규형의 특징
- 업무 요건의 변경에 매우 취약. 즉 모델의 확장성이 좋지 않음
- 인덱스 수가 증가하고 특정요건 조회 시 SQL이 복잡해짐
- 엔터티의 속성이 추가될 가능성이 없을 때 사용 가능
- 속성 레벨로 관리되는 데이터의 자식 엔터티를 가질 수 없음
- (여러 데이터가 하나의 인스턴스에 묶여 있어 개별로 관리해야할 하위 데이터가 있으면 관리 불가능)
- 업무 요건 변경이 유연. 확장성 좋음
- 인덱스 수 감소, 특정 요건 조회 시 SQL 단순해짐(복잡해질 수도 있음)
- 엔터티의 속성이 추가될 가능성이 존재할 때 사용
- 로우 레벨로 관리되는 데이터의 자식 엔터티를 가질 수 있음
인스턴스 대상으로 수행한 1정규화
|
그림4-14 |
- 고객 ID와 주문일 속성이 인스턴스 별로 중복되며 상품코드와 수량은 다가 속성의 성격을 가짐
- 그림4-14는 그림4-15와 같이 표현할 수 있고 이를 중첩 릴레이션(Nested Relation 또는 Relation-Valued Attribute)라고 함
- (하나의 인스턴스 내부에 다시 인스턴스가 존재하는 형태)
|
그림4-15 |
- 주문번호 속성은 릴레이션의 주식별자이며 상품코드 속성은 중첩 릴레이션의 주 식별자이면서 전체 릴레이션에서 부분 주 식별자(Partital Primary Identifier)가 됨
- 결국 그림4-15는 속성이 하나 이상의 값을 가지게 되어 1정규형 위반
- 그림4-14는 고객ID와 주문일자 속성이 주 식별자 중 주문번호에만 종속되므로 2정규형 위배
- 아래와 같이 정규화
- 엔터티별로 동일한 성격의 속성이 존재하는 경우
- 개인고객, 법인고객 엔터티가 따로 존재하고 양쪽에 전화번호 속성이 존재하는 경우
- 가장 이상적인 구조는 동일한 성격의 속성은 전사 모델에 한 번만 존재하는 것
3.2정규형
2정규형의 원칙
- 후보식별자 속성과 일반 속성 간의 종속성에 의해 수행
- 릴레이션의 모든 속성이 후보 식별자 전체에 종속이 되어야 2정규형
- 후보 식별자를 구성하는 속성이 두 개 이상일 때만 2정규화의 대상이 됨
- 위 그림에서 C 속성은 후보 식별자의 일부분인 B 속성에만 종속되어 부분 함수 종속이므로 B 속성을 주 식별자로 하는 릴레이션을 추가해 두 개의 릴레이션으로 분리해야함
예시2
- 상품명과 단가는 주 식별자(주문번호,상품코드)에 종속되지 않고 상품코드에만 종속되므로 2정규화 대상
- 아래와 같이 정규화
4.3정규형
3정규형의 원칙
- 이행적 종속성(Transitive Dependency)과 관련
- 일반 속성 간의 종속 관계를 분해하는 것이 3정규화
예시1
예시2
- 고객 ID는 고객명의 결정자임
- 아래 그림과 같이 정규화할 수 있음
5.보이스코드 정규형
보이스코드 정규형의 원칙
- 모든 속성의 결정자는 주 식별자여야 함(3정규형과 동일)
- 이와 함께 릴레이션에 존재하는 종속자가 후보 식별자이면 BC 정규형이 아님
예시1
- 예제1 릴레이션은 일반속성 C의 종속자 B가 주 식별자이므로 BC정규형에 어긋남
- 일반 속성 사이에는 종속 관계가 없으므로 3정규형임
- 예제2 릴레이션의 주 식별자는 A이고 B,C가 후보식별자일 때 D가 C의 결정자이므로 BC 정규형 아님
예시2
- 학생의 학점을 관리하는 릴레이션
- 학생은 여러 과목 수강 가능
- 교수는 한 과목만 강의
- 여러 교수가 동일한 과목 강의 불가
- FD1: (학생번호,과목명) -> (교수번호,학점)
- FD2: 교수번호->과목명
- FD2 종속자인 과목명 속성이 주 식별자에 포함돼 있으므로 BC정규형에 어긋남
이 경우 "2정규화는 만족하는 것인가? 교수번호는 과목명에만 종속되는 것 아닌가?" 하는 궁금증이 생겼습니다.
해서 저자분에게 여쭈어보았습니다.
A)
"2정규형 위반은 속성이 복합 PK 속성 중 한 속성에만 종속될 때 생깁니다.
BC정규화 예제는, 속성인 교수번호가 결정자니까 2정규화 위반은 아닙니다.
속성이 종속자인데, 특정 식별자에만 종속될 때 2정규형 위반입니다."
종속의 개념에 대한 약간의 오해가 있었네요.
교수번호는 결정자로써 2정규화에서는 모든 종속자가 후보키에 부분종속되지 않는지를 체크하는 것이므로
교수번호가 과목명에 종속되는 것인가는 2정규화와 무관합니다.
- 위의 모델을 BC정규형으로 만들면 아래와 같음
예시3
- 업체번호 속성이 업체명 속성을 종속하므로 오른쪽 모델과 같이 정규화해야 함
- 상품코드와 업체번호만으로도 주 식별자가 될 수 있는데 업체명까지 넣음으로써 슈퍼 식별자가됨
6.4정규형
4정규형의 원칙
- 다가 종속(MVD:Multivalued Dependency) 개념이 기반이 되는 정규형
- 다가 종속이란 한 릴레이션에 다가 속성이 두 개 이상 존재할 때 발생
- 하나의 다가 속성의 모든 값이 다른 다가 속성의 모든 값마다 중복되는 문제점이 발생할 수 있는데
- 이를 다가 종속이라 함
- 속성 A의 하나의 값이 속성 B의 여러 값을 결정하면 A->->B로 표시하며
- 'A가 B를 다가 결정(Multidetermine)한다' 또는 'B가 A에 다가종속(Multidependent)됐다' 라고 함
- 4정규형은 이런 다가 종속을 제거하는 것임
예시1
- 사원은 여러 기술을 가지고 있으며 구사할 수 있는 언어도 여러 개임
- 기술과 언어는 아무 연관이 없음
- 이렇게 되면 많은 중복 데이터가 발생함(아노말리 발생 가능)
- 중복데이터를 줄이기 위해 아래 그림과 같이 관리하게 되면
- 모델링과 영어가 연관성을 가지는 것처럼 보이게 됨
- 4정규형은 1정규형과 유사, 1정규화는 다가 속성을 엔터티로 분해하는 것이고
- 4정규화는 서로 관련이 없는 다가 속성을 개별 엔터티로 분해하는 것
- 다가 속성을 1정규형으로 만들면 다가 종속은 자연히 제거 됨
7.5정규형
5정규형의 원칙
- 조인종속(Join Dependency) 개념을 기반으로 수행
- 조인종속을 없앤 것이 5정규형
무손실조인 비부가조인
- 만약 하나의 릴레이션을 여러 개의 릴레이션으로 분해(Decomposition)한 후 공통(식별자) 속성으로 조인하여
- 데이터 손실 없이 원래의 릴레이션으로 복원할 수 있으면 이를 무손실 조인(Lossless join)이라 함
- 조인한 결과에 원래 릴레이션에 없는 데이터(가짜 튜플)가 존재하지 않으면 이를 비부가적 조인(Nonadditive join)이라 함
- 필요한 데이터가 사라지지 않는 무손실 분해가 되고 필요 없는 데이터가 생기지 않는
비부가적 분해가 된 릴레이션이 5정규형임
예시1
|
그림4-37 |
- 그림4-37은 조인 종속이 존재하는 릴레이션임
- 4정규형과 유사하지만 4정규형과 다른 점은 기술과 언어가 연관성이 있다는 점임
- 그림4-37은 그림4-38과 같이 분해될 수 있음
|
그림4-38 |
- 이렇게 세 개의 릴레이션으로 분해하고 나서 조인하면 다시 그림4-37 릴레이션으로 돌아갈 수 있으므로 분해하기 전의 릴레이션인
- 그림4-37은 조인 종속이 존재하는 릴레이션이며 5정규형을 위반한 릴레이션임
- 그림4-38의 세 개의 릴레이션 중에서 어느 두 개의 릴레이션만 조인해서는 원 데이터를 만들 수 없고 반드시 세 개의 릴레이션을
- 조인해야 원하는 요건을 얻을 수 있음
- 5정규형은 조인 종속이 존재하지 않아야 하므로 그림4-38과 같이 분해하면 더 이상 분해할 수 없는 5정규형이 됨
- 5정규형은 분할하고(Project) 합치는(Join) 개념 때문에 PJ 정규형(Project-Join Normal Form)이라고도 함
- 5정규형은 더는 분해할 수 없는 릴레이션이므로 가장 이상적인 정규형이지만 하나의 릴레이션에서 데이터를 관리해도 아노말리 현상이 발생하지 않아 조인 종속이 발생하는 상태로 릴레이션을 관리하는 것이 현실적임
- 4정규형은 5정규형과 유사하지만 속성간의 연관관계가 있을 때 5정규형이 필요
- 5정규형은 지나치게 이론적이며 DBMS에서 실제로 사용하기 적합하지 않음
정규형 요약