Properties of Table
우리가 관계형 DB를 설계할 때,
관계의 집합입니다.관계는 UML 다이어그램에서 파생될 수 있습니다.
그러나 모든 관계가 올바른 것은 아닙니다.
테이블의 속성을 주의 깊게 관찰해야 합니다.
기능적 종속성, 열쇠, 테이블의 분해
Definition of Functional Dependency
Functional dependency
- 어떤 relation R의 속성 A,B가 있을 때 A값이 같으면 B의 값도 같은 경우 A에서 B로의 functional dependency가 있다고 하고 A->B로 나타낸다.
관계 R에 대한 FD(기능 종속성)
iff A1 A2 A3 … An -> B
여기서 A1 , A2 , A3 , … , An , B는 R의 속성입니다.
일련의 속성 A1 A2 A3 … A는 기능적으로 B를 결정합니다.
하나 이상의 B
A1 A2 A3 … An -> B1
A1 A2 A3 … An -> B2 …
A1 A2 A3 … An -> Bk
A1 A2 A3 … An -> B1 B2 … Bk
Functional Dependency: Example
Relation
영화(title, year, length, filmType, studioName, starName)
(title year) - > length
(title year) - > filmType
(title year) - > studioName
(title year) - > length filmType studioName
? (title year) - > starName : 영화에 한 명 이상의 스타
관계에서 FD를 발견하는 것이 중요합니다.
관계 디자인의 정확성을 결정하는 데 도움이 됩니다.
Key
주어진 관계 R
하나 이상의 속성 집합 {A1, A2, A3, …, An}은 KEY iff입니다.
-세트는 기능적으로 다른 모든 속성을 결정하고
-{A1, A2, A3, …, An}의 적절한 하위 집합이 기능적으로 다른 속성을 결정하지 않음(최소)
기본 키:
-관계에 둘 이상의 키가 있는 경우 키는 기본 키로 정의됩니다.
슈퍼 키
-키를 포함하는 속성 집합
-최소 조건 없음
예시
-영화(제목, 연도, 길이, filmType, studioName, actorName)
-키란 무엇입니까?
How to discover keys
E-R 다이어그램에서: 밑줄 친 속성
- 실제 세계에 대한 이해를 바탕으로 키가 정의된다는 의미입니다.
- 예: 영화(title, year, length, filmType, studioName, actorName)
(year, starName)은 스타가 1년에 두 개 이상의 영화를 만들 수 있는 경우 키가 아닙니다.
(year, starName)은 스타가 1년에 한 편의 영화만 만들도록 허용된 경우 키입니다.
R1과 R2 사이의 관계에 대한 관계(A1, A2, B) 여기서 A1과 A2는 각 관계 R1과 R2의 키입니다.
one-one
one-Many
Many-One
Many-Many
Rules about Functional Dependencies
Armstrong's Axioms
공리(公理, 영어: axiom)는 논리학이나 수학 등의 이론체계에서 가장 기초적인 근거가 되는 명제
Closure of Attributes
- F.D.는 유도될 수도 있다. 만약 A->B, B->C라면 A->C를 유도할 수 있다.
- F가 functional dependency set일 때, F에 의해 imply될 수 있는 모든 F.D.의 set을 F의 closure라고 한다.
Algorithm to Find Closure
Closure and Key
Closing Set of Functional Dependencies
Bad Design: Anomalies(비정상적인)
Decomposing Relations: Example
Decomposition
- relation에서 특정 속성의 값이 반복적으로 나타나는 경우(data redundancy) 해당 relation을 더 작은 schema로 쪼개는 것
Lossy decomposition
- 나뉘어진 2개의 relation을 하나로 합칠 때 원래의 테이블에서 데이터 손실이 발생하는 것
- 주로, 나뉘어진 relation에서 functional dependency가 없기 때문에 발생
Losseless-Join Decomposition
아래의 예시에서는 B라는 functional dependency가 있어서 가능하다.
아래의 또 다른 예시이다.
Normal Form: Conditions for Good Relation
•1st Normal Form (1NF)
먼저 1st Normal Form(1NF)에 대해서 살펴보겠다.
테이블에 존재하는 필드가 모두 scalar value만을 가지며, 필드의 값이 모두 atomic 할 때, 1NF라고 한다. 여기에서 atomic 하다는 것은 테이블에 중복되는 항목이 존재하지 않아야 한다는 것과 같다. 1NF에서 "중복되는 항목이 없다"에 대한 정의는 명확한 것이 아니기 때문에 1NF에 대한 정의 또한 여러 개가 존재할 수 있다.
- 구성요소에 테이블이 없어야 한다.
- 집합이 없어야 한다.
- 리스트가 업어야 한다. etc....
Non-atomic value는 왜 안 좋은가?
- atomic하지 않기 때문에 data redundancy를 만들어낸다.
- 어찌보면 atomic하지 않다는 것은 최소 단위가 아니기에 storage를 복잡하게 만든다.
- atomicity는 다른 측면에선 해당 element가 어떻게 이용되는지를 나타내는데 만약 학생을 나타내는 ID가 CS0012, EE1127과 같이 된다면 DB가 아닌 Application program에서 encoding을 하게 만든다.(바꿔 말하면, 단순히 DB 접근만을 통해서 완벽하게 데이터의 정보를 알 수 없다)
Relation R이 not "good" form일 때 decompose해 "good" form으로 만들려면 다음 조건을 만족해야 한다.
- 분해한 각 relation이 "good" form이어야 한다.
- 분해가 lossless-join decomposition이어야 한다.
2nd Normal Form (2NF)
2NF는 릴레이션의 비주요 attribute는 후보 키에 기능적으로 종속되지 않습니다.
주요 속성: 키에 속하는 속성
중요하지 않은 속성에 대한 부분 종속성
2NF는 1NF의 속성을 만족하면서, 테이블에 존재하는 모든 함수 종속 관계가 완전 함수 종속이어야 한다. 2NF를 정의할 때 이용되는 완전 함수 종속의 정의는 다음과 같다.
예를 들어, [그림 1]의 테이블에서 primary key는 {S#, P#}이지만, CITY라는 필드는 {S#, P#}이 아니라 S#에 대해 함수 종속적이다. 따라서, [그림 1]의 테이블에는 완전 함수 종속이 아닌 함수 종속 관계가 존재하므로 2NF가 아니다. 위의 [그림 1]의 테이블을 2NF의 정의를 만족하도록 변형하면, 아래의 [그림 3]과 같이 SSC와 SPQ로 표현되는 두 개의 테이블로 분해할 수 있다.
그러나 2NF의 정의를 만족하는 SSC와 SPQ 테이블에서도 다음과 같은 이상 현상이 발생한다.
1) INSERT anomaly
SSC 테이블에는 "Paris라는 CITY의 STATUS는 40이다"라는 정보를 저장할 수 없다. SSC 테이블의 primary key는 S#이기 때문에 어떠한 도시의 상태에 대한 정보를 SSC 테이블에 저장할 수 없다. 또는, 해당 정보를 저장하기 위해서 S#에 dirty data를 추가해야 한다.
2) DELETE anomaly
만약, SSC 테이블에서 두 공급자 S2와 S3가 제거되면, "Busan이라는 CITY의 STATUS는 20이다"라는 정보도 같이 손실된다.
3) UPDATE anomaly
만약, Seoul이라는 CITY의 STATUS가 10에서 30으로 변경되면, SSC 테이블에서는 Seoul의 STATUS를 30으로 변경하는 작업을 1번이 아니라, 총 2번 수행해야 한다.
또 다른 예시
- Player (Team, Number, TeamAddress, Name, Position)
- 1NF but not 2NF
3rd Normal Form (3NF)
2NF의 정의를 만족하면서, 어떠한 테이블에 존재하는 key가 아닌 필드들이 서로 독립적일 때 3NF라고 한다. 예를 들어, [그림 3]의 SSC 테이블에서 STATUS 필드는 테이블의 key가 아닌 CITY 필드에 함수 종속적이기 때문에 SSC 테이블은 3NF의 정의를 만족하지 못한다. 3NF의 정의를 만족하도록 [그림 3]의 SSC 테이블을 분해하면, 아래의 [그림 4]와 같다.
위의 [그림 3]의 SSC 테이블에서는 key가 아닌 CITY에 STATUS가 종속적이었지만, [그림 4]의 SC와 CS 테이블에서는 key가 아닌 필드 사이에 어떠한 종속 관계도 존재하지 않는 것을 볼 수 있다.
Boyce-Codd Normal Form (BCNF)
어떠한 테이블에 대해 테이블에 존재하는 모든 함수 종속 관계의 determinant가 candidate key이면, BCNF라고 한다.
위의 [그림 5]는 BCNF의 정의를 만족하지 않는 테이블을 보여준다. [그림 5]의 테이블에서 candidate key는 {STD#, COURSE}이다. 따라서, {STD#, COURSE}를 통해 하나의 레코드를 유일하게 구별할 수 있다.
그러나 테이블 SCT에는 TEACHER에 의해 COURSE가 결정되는 함수 종속 관계가 존재한다. 즉, determinant가 candidate key에 해당하지 않는 함수 종속 관계가 존재하기 때문에 테이블 SCT는 BCNF의 정의를 만족하지 않는다. 이러한 테이블 SCT를 BCNF의 정의를 만족하도록 변경하면, 테이블 SCT는 아래의 [그림 6]과 같은 두 개의 테이블로 변환된다.
[그림 6] BCNF의 정의를 만족하도록 변경된 테이블 ST와 TC
위의 [그림 6]에서 함수 종속 관계는 테이블 TC에서만 존재하며, determinant에 해당하는 것은 TEACHER로써, 테이블 TC의 candidate key에 해당한다. 따라서, [그림 6]의 두 테이블은 BCNF의 정의를 만족한다.
BCNF Decomposition
- 스키마 R의 non-trivial FD a->b가 BCNF violation을 일으킨다고 하자
- 그럼 다음과 같이 R을 분해하면 된다.
- a U b
- R-(b-a)=R-b+a
BCNF 분해의 예 1
BCNF 분해의 예 2
'Computer Science > 데이터베이스' 카테고리의 다른 글
| MySQL 자료형 (0) | 2023.01.24 |
|---|---|
| 트랜잭션 (0) | 2022.12.15 |
| 관계데이터모델4 - More Relation Operation (0) | 2022.12.15 |
| 관계 데이터 모델3- UML to Relational Model (0) | 2022.10.13 |
| 관계 데이터 모델1- 관계 모델의 기본 (0) | 2022.10.13 |
