Normalization
(빅데이터 등장 이후 잘 안쓰긴 합니다. 그래도 RDB에서는 중요해요)
- 좋은 relational design 생성
- instructor와 department를 in_dept으로 결합한다고 가정, 이는 instructor와 department 간의 natural join을 나타냄
- 정보의 반복이 있음
- Null 값을 사용해야 함 (새로운 부서를 추가하는 경우, instructor가 없는 경우)
Decomposition
- in_dep schema에서 정보 반복 문제를 피하는 유일한 방법은 이를 두 개의 schema - instructor와 department schema -로 분해하는 것임
- 모든 Decomposition가 좋은 것은 아님. 예를 들어, employee(ID, name, street, city, salary)를 employee1 (ID, name)과 employee2 (name, street, city, salary)로 분해한다고 가정
- 두 명의 동일한 이름을 가진 직원이 있을 때 문제가 발생함
- 다음 슬라이드는 정보를 잃는 방식을 보여줌 - 원래의 employee relation을 재구성할 수 없음 - 따라서 이것은 lossy decomposition
A Lossy Decomposition
Levels of Normalization
- 데이터베이스의 중복 양에 따라 normalization 수준이 결정됨
- 다양한 normalization 수준:
- First Normal Form (1NF)
- Second Normal Form (2NF)
- Third Normal Form (3NF)
- Boyce-Codd Normal Form (BCNF) : most poppular
- Fourth Normal Form (4NF)
- Fifth Normal Form (5NF)
- Domain Key Normal Form (DKNF)
First Normal Form (1NF) (제 1 정규형)
- 테이블의 모든 필드가 스칼라 값을 포함하는 경우 1NF에 속함 (값 목록이 아닌 경우)
1NF - Decomposition
- 반복 그룹에 나타나는 모든 항목을 새 테이블에 배치
- 생성된 각 새 테이블에 PK 지정
- 새로운 테이블에 기존 테이블의 primary key를 Duplicate 하거나, 그 반대로 한다
Functional Dependencies
테이블의 어떤 attribute 집합이 다른 집합의 attribute를 결정하는 경우, 두 번째 attribute 집합는 첫 번째 attribute 집합에 기능적으로 종속되어 있다고 한다
Second Normal Form (2NF) (제 2 정규형)
- 테이블이 2NF에 속하려면 두 가지 요구사항이 있어야 함
- 데이터베이스는 제 1 정규형에 있어야 함
- 테이블의 모든 nonkey 속성은 전체 PK에 기능적으로 종속되어야 함 (단일 키에 부분적으로 종속되지 않음)
- Single key로 nonkey를 찾는 경우
- AuId 만으로도 AuAddress를 찾을 수 있고, 따라서 AuAddress를 결정하는데 Title과 PubId를 알 필요가 없다
2NF - Decomposition
1. 어떤 data item이 primary key의 일부에만 완전히 종속된 경우, 해당 data item과 그 primary key의 일부를 new table로이동 (부분 종속성 식별)
2. 같은 primary key 일부에 종속된 data item이 있다면, 이들도 new table에 포함시킨다. (관련 데이터 포함)
3. original table에서 복사한 부분 Primary key를 new table의 primary key로 정의한다. 또한, repeating group에 속하는모든 items을 new table로 옮긴다(새로운 primary key 정의)
Third Normal Form (3NF) (제 3 정규형)
- 이 형태는 non-key attribute 간의 상호 의존성이 없어야 함을 규정함
- 테이블이 3NF에 속하려면 두 가지 요구사항이 있어야 함
- 테이블이 2NF에 속해야 함
- 어떤 attribute도 transitively(이행적으로) 종속되면 안된다
Example (Not in 3NF)
- Scheme: {Studio, StudioCity, CityTemp}
- Primary Key: {Studio}
- {Studio} → {StudioCity}
- {StudioCity} → {CityTemp}
- {Studio} → {CityTemp}
- StudioCity와 CityTemp는 전체 키에 의존함, 따라서 2NF
- CityTemp는 Studio에 이행적으로 의존함, 따라서 3NF 위반
3NF - Decomposition
- 이행적 종속에 관련된 모든 항목을 새 엔터티로 이동
- 새 엔터티에 대한 PK를 식별
- 새 엔터티에 대한 PK를 원래 엔터티의 Foreign Key로 배치
Example (Convert to 3NF)
- Old Scheme: {Studio, StudioCity, CityTemp}
- New Scheme: {Studio, StudioCity}
- New Scheme: {StudioCity, CityTemp}
Example (Convert to 3NF)
- Old Scheme: {BuildingID, Contractor, Fee}
- New Scheme: {BuildingID, Contractor}
- New Scheme: {Contractor, Fee}
Boyce-Codd Normal Form (BCNF)
- BCNF는 candidate key에 속한 attribute 간의 종속을 허용하지 않음
- BCNF는 3NF를 더 발전시킨 것으로, 3NF에서 non-key attribute의 제한을 제거함
- 다음 조건이 참일 경우 3NF와 BCNF는 동일하지 않음
- 테이블에 두 개 이상의 candidate key가 있음
- 두 개 이상의 candidate key가 여러 attribute으로 구성됨
- candidate keys 들이 일부 attributes를 share하고 있는 경우
BCNF - Decomposition
- 두 candidate primary key를 별도의 엔터티에 배치
- 나머지 데이터 항목을 primary key에 대한 종속성에 따라 생성된 엔터티에 배치
Example 1 (Convert to BCNF)
- Old Scheme: {City, Street, ZipCode}
- New Scheme1: {ZipCode, Street}
- New Scheme2: {City, Street}
Example 2 (Convert to BCNF)
- Old Scheme: {MovieTitle, MovieID, PersonName, Role, Payment}
- New Scheme: {MovieID, PersonName, Role, Payment}
- New Scheme: {MovieTitle, PersonName}
Example 3 (Convert to BCNF)
- Old Scheme: {Client, Problem, Consultant}
- New Scheme: {Client, Consultant}
- New Scheme: {Client, Problem}
Other Normal Form
4NF - Decomposition(실제 실무에서 잘 사용하지 않음)
- 두 개의 multi-valued relation를 별도의 테이블로 이동
- 각 새 엔터티에 대해 PK를 식별
Example 1 (Convert to 3NF)
- Old Scheme: {MovieName, ScreeningCity, Genre}
- New Scheme: {MovieName, ScreeningCity}
- New Scheme: {MovieName, Genre}
Fifth Normal Form (5NF)
- 모든 테이블이 중복을 피하기 위해 가능한 한 많은 테이블로 분해된 경우 5NF를 만족함. 5NF에 도달하면 사실이나 의미를 변경하지 않고 작은 relation로 분해할 수 없음
'DataBase' 카테고리의 다른 글
| [DataBase] 09. BigData and Distributed DataBase (0) | 2024.06.26 |
|---|---|
| [DataBase] 08. Transaction Recovery (0) | 2024.06.26 |
| [DataBase] 07. Data Storage Structure (0) | 2024.06.25 |
| [DataBase] 06. Physical Storage System (0) | 2024.06.25 |
| [DataBase] 05. E-R Model (0) | 2024.06.25 |
