이번 포스팅에서는 전 시간에 진행했던 Logical Database Design이 잘 구조화되었는지에 대해 알아본다.
목차는 다음과 같다.
목차
1. Well Structured Relation
2. Functional Dependency
3. Normalization
1. Well Structured Relation
Relation이란? 명명된 2차원의 데이터 표를 의미한다.
다음과 같은 Relation에서 직원번호가 100번인 데이터 2개의 행에 대해 업데이트를 한다고 했을 때 만약, 연봉이 첫번째만 업데이트가 되고 아래행은 업데이트가 안됐다고 가정해보자. 이러면 어떻게 될까?
Modification Anomaly, 수정 이상 징후가 발생한다.
Anomaly란 데이터베이스를 업데이트 할 때 발생할 수 있는 오류 또는 불일치를 의미한다.
만약 위의 테이블에서 어떤 직원도 수강하지 않는 Course를 넣으려고 한다면?
Insertion Anomaly가 발생한다.
만약 직원번호 140번인 직원의 데이터를 지운다면 과목의 정보까지 없어지게 된다.
Deletion Anomaly가 발생한다.
-> 두 가지 이상의 테마를 한 테이블에 저장했기 때문에 발생한다.
따라서, 테이블을 잘 만들어야 한다.
Well Structured Relation이란, 데이터 중복이 최소, 사용자가 삽입, 삭제, 수정을 할 때 어떠한 Anomaly도 야기되지 않는 것을 의미한다.
Logical Database Design의 목표는 잘 구조화된 테이블을 설계하는 것이다.
이를 알기 위해서 체크를 해야하고 그렇지 않을 경우 바꿀 수 있어야 한다.
Anomaly를 피하는 목표는 다음과 같다.
Modification Anomaly -> 행의 데이터 변경으로 인해 다른 행이 강제로 변경되는 되는 경우
Insertion Anomaly -> 새 행을 추가하면 사용자가 중복 데이터를 만들 수 있는 경우
Deletion Anomaly -> 행을 삭제하면 향후 다른 행에 데이터가 손실될 수 있는 경우
두 개 이상의 Entity Type이 하나의 Relation으로 처리되선 안된다는 이야기 이다.
따라서, Normalization을 진행해야 한다.
Normalization을 이해하기 위해 Funtional Dependency에 대해서 알아본다.
2. Functional Dependency
X -> Y란, X의 값에 따라서 Y의 값이 결정이 될 때 사용한다. 이때 X는 Determinant(결정자)라고 부른다.
예를 들어 알아보자.
Emp_ID -> Name?
Emp_ID -> Course_Title?
Emp_ID, Course_Title -> Salary?
Emp_ID, Course_Title -> Salary, Name, Date_Completed? 에 대해서 알아보자,
Emp_ID를 알면 Name을 알 수 있는지? 에 대한 것들이다.
이를 이해하기 위해선, Full Functional Dependency, Partial Functional Dependency개념에 대해서 알아야 한다.
Full Functional Dependency란 X->Y에서 X 중에 어느 하나라도 없었을 때 X->Y가 성립을 하지 않는다면 그것을 Full Functional Dependency라고 부른다.
Emp_ID, Course_Title -> Date_Completed? 에서 두 개 중에 하나 없으면 성립하지 않으므로 이는 Full Functional Dependency이다.
Emp_ID, Course_Title -> Salary? 에서 Course_Title이 없어도 Salary를 알 수 있으므로 Partial Functional Dependency이다.
3. Normalization
Normalization이란 더 작고 잘 구성된 테이블을 만들기 위해 Anomaly를 가지고 있는 잘못 구조화된 테이블을 쪼개는 과정이다.
- 그룹화할 속성을 결정하는 공식 프로세스이다.
- 정규화는 논리적 데이터베이스 설계를 검증하거나 개선하기 위한 도구로 사용될 수 있다. 즉, 특정 제약조건을 충족하고, 원치 않는 데이터 복제를 방지하는 것이다.
- Normalization은 Anomaly가 있는 관계를 더 작고 더 잘 구성된 관계로 분해하는 과정이다.
- 정규화는 단계별로 구성된다.
Normal Form : 특정 규칙의 적용으로 야기되는 테이블의 상태를 의미한다.
정규화 과정 동안 관계의 상태는 다음과 같을 수 있다.
1NF(First Normal Form), 2NF(Second Nomal Form), 3NF(Third Normal Form)이다.
이 모든 정규 형태는 테이블 속성들 사이의 Functional Dependency에 의존한다.
주로, Third Normal Form이면 잘 만들어진 것이라고 이야기 한다.
First Normal Form : 테이블의 모든 속성 값은 Atomic해야 한다. (Not Multivalued, Not Composite)
-> Relatinal Model의 속성이 성립하는 Relation은 모두 First Normal Form이다.
예를 들어 위의 첫번째 그림은 하나의 속성에 두개의 값이 들어가 있으므로 Multi-valued이고, First Normal Form이 아니다. 반면 위의 두번째 그림은 하나의 속성에 하나의 속성만 들어가 있으므로 First Normal Form이다.
Second Normal Form : 무조건 1NF이면서, 모든 Primary key가 아닌 Attribute가 Primary key에 Fully Functionally dependent여야 한다.
즉, 2NF는 Partial Functional Dependencies를 금지한다.
예시를 통해 알아본다.
위의 테이블은 2NF인가?
아니다, Partial Functional Dependencies를 갖기 때문이다. Primary key가 Emp_ID, Course_Title인데, Course_Title을 몰라도 Name, Dept_Name, Salary를 알 수 있고, Emp_ID를 몰라도 Date_Completed를 알 수 있기 때문이다.
이럴경우 첫번째로, Primary key를 가지고 새로운 테이블을 만든다. 두번째로, 완전히 종속된, Primary key가 아닌 모든 속성들을 새로운 테이블로 이동한다.
다음과 같다.
Employee2 ( Emp_ID, Course_Title, Name, Dept_Name, Salary, Date_Completed)
->
Employee1 ( Emp_ID, Name, Dept_Name, Salary)
즉, Partial Functionally Dependency의 원인이 되는걸 떼어낸다.
Third Normal Form: 무조건 2NF이여야 하고, non primary key중에 transitively하게 dependent한 Attribute가 있으면 안된다.
Transitive Functional Dependency: 만약 A->B, B-> C, A 일때 C는 전이되는식으로 A에게 의존한다.
CourseOffering(CourseNo, Room, Capacity)에서
만약 CourseNo -> Room
Room -> Capacity
CourseNo -> Capacity
라면 C는 전이되는식으로 A에게 의존한다.
따라서, 이를 해결하기 위해 새로운 테이블을 만들어서 해결한다.
CourseOffering(CourseNo, Room, Capacity)
CourseRoom(Room, Capacity)과 같이 결국, 2개의 테이블로 해결한다.
이번 포스팅에는 잘 구조화된 테이블인지 검증하는 과정들에 대해서 배웠다.
데이터베이스를 이용한 프로젝트들에 대해서 잘 구조화되었는지?에 대해서 다시한번 돌이켜 볼 수 있는 생각을 하게 됐다.
중요한 데이터베이스 개념들을 밑바탕 삼아 JPA든 MyBatis든 이용해야겠다!
다음 포스팅에는 Physical Database Design과 Performance에 대해서 알아본다.
'Dev > Database' 카테고리의 다른 글
| [Database] 6-1. Relational Algebra (0) | 2022.02.26 |
|---|---|
| [Database] 5. Physical Database Design (0) | 2022.02.25 |
| [Database] 4-1. Logical Database Design (0) | 2022.01.26 |
| [Database] 3. The Enhanced E-R Model (0) | 2022.01.25 |
| [Database] 2. Modeling Data in the Organization (0) | 2022.01.24 |
