7. Relational Database Design (2)

Functional Dependency Theory

Functional-Dependency Theory Roadmap

• 주어진 함수 종속성(Functional dependency) 집합에 의해 논리적으로 함축되는 함수 종속성을 알려주는 형식 이론(formal theory)을 고려
• BCNF와 3NF로의 무손실 분해(lossless decomposition)를 생성하는 알고리즘 개발
• 분해가 종속성 보존(dependency-preserving)인지 테스트하는 알고리즘 개발

Closure of a Set of Functional Dependencies

• Armstrong's Axioms(암스트롱 공리)를 반복적으로 적용하여 F+(폐포) 계산 가능:
  • Reflexivity rule(반사 규칙): $\beta \subseteq \alpha$이면 $\alpha \rightarrow \beta$
  • Augmentation rule(증가 규칙): $\alpha \rightarrow \beta$이면 $\gamma\alpha \rightarrow \gamma\beta$
  • Transitivity rule(이행 규칙): $\alpha \rightarrow \beta$이고 $\beta \rightarrow \gamma$이면 $\alpha \rightarrow \gamma$
• 이러한 규칙들은
  • Sound(건전함): 실제로 성립하는 함수 종속성만 생성
  • Complete(완전함): 성립하는 모든 함수 종속성을 생성
• 추가 규칙:
  • Union rule(합집합 규칙): $\alpha \rightarrow \beta$이고 $\alpha \rightarrow \gamma$이면 $\alpha \rightarrow \beta\gamma$
  • Decomposition rule(분해 규칙): $\alpha \rightarrow \beta\gamma$이면 $\alpha \rightarrow \beta$이고 $\alpha \rightarrow \gamma$
  • Pseudotransitivity rule(의사 이행 규칙): $\alpha \rightarrow \beta$이고 $\gamma\beta \rightarrow \delta$이면 $\alpha\gamma \rightarrow \delta$
• 위의 규칙들은 암스트롱 공리로부터 유추 가능

Example of F+

• $R = (A, B, C, G, H, I)$, $F = \{ A \rightarrow B, A \rightarrow C, CG \rightarrow H, CG \rightarrow I, B \rightarrow H \}$
• $F^+$의 일부 멤버
  • $A \rightarrow H$
    • $A \rightarrow B$와 $B \rightarrow H$로부터 이행 규칙에 의해
  • $AG \rightarrow I$
    • $A \rightarrow C$를 $G$로 증가시켜 $AG \rightarrow CG$를 얻음
    • 그리고 $CG \rightarrow I$와의 이행 규칙에 의해 $AG \rightarrow I$를 얻음
  • $CG \rightarrow HI$
    • $CG \rightarrow I$를 $CG$로 증가시켜 $CG \rightarrow CGI$를 얻음
    • $CG \rightarrow H$를 $I$로 증가시켜 $CGI \rightarrow HI$를 얻음
    • 그리고 이행 규칙에 의해 $CG \rightarrow HI$를 얻음

(Optional) Procedure for Computing F+

• 함수 종속성 집합 F의 폐포를 계산하는 절차:

  F+ = F
  repeat
      for each functional dependency f in F+
          apply reflexivity and augmentation rules on f
          add the resulting functional dependencies to F+
      for each pair of functional dependencies f1 and f2 in F+
          if f1 and f2 can be combined using transitivity
          then add the resulting functional dependency to F+
  until F+ does not change any further
  
• 참고: 이 작업을 위한 대안적 절차는 나중에 살펴볼 것임

Closure of Attribute Sets

• 속성 B는 $\alpha \rightarrow B$일 때 $\alpha$에 의해 함수적으로 결정된다고 함
• 속성 집합 $\alpha$가 주어졌을 때, $F$ 하에서 $\alpha$의 Closure(폐포)($\alpha^+$로 표기)는 $F$ 하에서 $\alpha$에 의해 함수적으로 결정되는 속성들의 집합으로 정의됨
  • $\alpha \rightarrow \beta$가 $F^+$에 있음 $\iff \beta \subseteq \alpha^+$
• $F$ 하에서 $\alpha$의 폐포 $\alpha^+$를 계산하는 알고리즘

  result := α;
  while(changes to result) do
      for each β→γ in F do
          begin
              if β ⊆ result then result := result ∪ γ
          end
  

Example of Attribute Set Closure

• $R = (A, B, C, G, H, I)$
• $F = \{A \rightarrow B, A \rightarrow C, CG \rightarrow H, CG \rightarrow I, B \rightarrow H\}$
• $(AG)^+$
  1. result = AG
  2. result = ABCG ($A \rightarrow B$ 와 $A \rightarrow C$)
  3. result = ABCGH ($CG \rightarrow H$)
  4. result = ABCGHI ($CG \rightarrow I$)
• AG는 후보 키(candidate key)인가?
  1. AG는 슈퍼키(superkey)인가?
     • $AG \rightarrow R$인가? $\iff R = (AG)^+$인가?
  2. AG의 임의의 부분집합이 슈퍼키인가?
     • $A \rightarrow R$인가? $\iff R = (A)^+$인가?
     • $G \rightarrow R$인가? $\iff R = (G)^+$인가?
  • 일반적으로: 크기 n-1의 각 부분집합에 대해 확인

Uses of Attribute Closure

• 속성 폐포 알고리즘의 여러 용도:
  • 슈퍼키 테스트:
    • $\alpha$가 슈퍼키인지 테스트하기 위해, $\alpha^+$를 계산하고 $\alpha^+$가 $R$의 모든 속성을 포함하는지 확인
  • 함수 종속성 테스트:
    • 함수 종속성 $\alpha \rightarrow \beta$가 성립하는지(즉, $F^+$에 있는지) 확인하려면, $\beta \subseteq \alpha^+$인지 확인하면 됨
    • 간단하고 저렴한 테스트이며 매우 유용함
  • F의 폐포 계산:
    • 각 $\gamma \subseteq R$에 대해, 폐포 $\gamma^+$를 찾고, 각 $S \subseteq \gamma^+$에 대해 함수 종속성 $\gamma \rightarrow S$를 출력

Canonical Cover

• 함수 종속성 집합 F를 갖는 관계 스키마 가정
• 사용자가 관계에 대한 업데이트를 수행할 때마다,
  • 데이터베이스 시스템은 업데이트가 어떤 FD도 위반하지 않음을 보장해야 함
  • 즉, 새로운 데이터베이스 상태에서 F에 있는 모든 FD가 만족되어야 함
• 업데이트가 집합 F의 어떤 FD를 위반하면, 시스템은 업데이트를 롤백(roll back)해야 함
• 위반 여부를 확인하는 데 드는 노력을 줄일 수 있음
  • 주어진 집합과 동일한 폐포를 갖는 단순화된 FD 집합을 테스트함으로써
  • 이 단순화된 집합을 Canonical cover(정규 커버)라고 함
• 정규 커버를 정의하기 위해 먼저 Extraneous attribute(불필요한 속성)를 정의해야 함

Extraneous Attributes

• FD의 왼쪽에서 속성을 제거하면 제약조건이 더 강해짐
  • $AB \rightarrow C$가 있고 $B$를 제거하면, 잠재적으로 더 강한 결과인 $A \rightarrow C$를 얻음
  • $A \rightarrow C$는 $AB \rightarrow C$를 논리적으로 함축하지만, $AB \rightarrow C$ 자체만으로는 $A \rightarrow C$를 논리적으로 함축하지 않기 때문에 더 강할 수 있음
  • 집합 F에 따라, $AB \rightarrow C$에서 $B$를 안전하게 제거할 수 있음
  • 예: $F = \{AB \rightarrow C, A \rightarrow D, D \rightarrow C\}$
  • 그러면 F는 논리적으로 $A \rightarrow C$를 함축하므로(이행성), $AB \rightarrow C$에서 B는 불필요함
• FD의 오른쪽에서 속성을 제거하면 제약조건이 더 약해질 수 있음
  • $AB \rightarrow CD$가 있고 $C$를 제거하면, 잠재적으로 더 약한 결과인 $AB \rightarrow D$를 얻음
  • $AB \rightarrow D$만으로는 $AB \rightarrow C$를 추론할 수 없으므로 더 약할 수 있음
  • 집합 F에 따라, $AB \rightarrow CD$에서 $C$를 안전하게 제거할 수 있음
  • 예: $F = \{AB \rightarrow CD, A \rightarrow C\}$
  • $AB \rightarrow CD$를 $AB \rightarrow D$로 대체한 후에도, 여전히 $AB \rightarrow C$를 추론할 수 있으며($A \rightarrow C$로부터), 따라서 $AB \rightarrow CD$를 추론할 수 있음을 보일 수 있음

Extraneous Attributes

• F에 있는 FD의 속성은 F+를 변경하지 않고 제거할 수 있을 때 불필요함
• 함수 종속성 집합 F와 F에 있는 FD $\alpha \rightarrow \beta$를 고려
  • 왼쪽에서 제거: 속성 $A$는 $\alpha$에서 불필요함 if
    • $A \in \alpha$ 이고
    • F는 $(F - \{\alpha \rightarrow \beta\}) \cup \{(\alpha - A) \rightarrow \beta\}$를 논리적으로 함축
  • 오른쪽에서 제거: 속성 $A$는 $\beta$에서 불필요함 if
    • $A \in \beta$ 이고
    • 함수 종속성 집합 $(F - \{\alpha \rightarrow \beta\}) \cup \{\alpha \rightarrow (\beta - A)\}$가 F를 논리적으로 함축
• 즉, 약한 F로부터 더 강한 F를 논리적으로 함축할 수 있을 때 속성은 불필요함
• 참고: "더 강한" 함수 종속성은 항상 "더 약한" 것을 함축하므로, 위의 각 경우에서 반대 방향의 함축은 자명함

Testing if an Attribute is Extraneous

• 관계 스키마 $R$과 $R$에서 성립하는 함수 종속성 집합 $F$를 가정하고, 함수 종속성 $\alpha \rightarrow \beta$의 속성을 고려
• 속성 $A \in \beta$가 $\beta$에서 불필요한지 테스트
  • 더 약한 집합 고려: $F' = (F - \{\alpha \rightarrow \beta\}) \cup \{\alpha \rightarrow (\beta - A)\}$
  • $F'$ 하에서 $\alpha^+$가 $A$를 포함하는지 확인; 포함하면, $A$는 $\beta$에서 불필요함
• 속성 $A \in \alpha$가 $\alpha$에서 불필요한지 테스트
  • $\gamma = \alpha - \{A\}$라 하자. 더 강한 FD $\gamma \rightarrow \beta$가 F로부터 추론될 수 있는지 확인
  • F의 종속성을 사용하여 $\gamma^+$를 계산
  • $\gamma^+$가 $\beta$의 모든 속성을 포함하면, $A$는 $\alpha$에서 불필요함
• 불필요한 속성의 예
  • $F = \{AB \rightarrow CD, A \rightarrow E, E \rightarrow C\}$
  • $AB \rightarrow CD$에서 $C$가 불필요한지 확인하기 위해,
  • $F' = \{AB \rightarrow D, A \rightarrow E, E \rightarrow C\}$ 하에서 $AB$의 속성 폐포 계산
  • 폐포는 $ABCDE$이며, $C$를 포함함
  • 이는 $C$가 불필요함을 의미

Canonical Cover

• F에 대한 정규 커버 $F_C$는 다음과 같은 종속성 집합임
  • F는 $F_C$의 모든 종속성을 논리적으로 함축
  • $F_C$는 F의 모든 종속성을 논리적으로 함축
  • $F_C$의 어떤 함수 종속성도 불필요한 속성을 포함하지 않음
  • $F_C$의 각 함수 종속성의 왼쪽은 고유함. 즉, $\alpha_1 = \alpha_2$인 두 종속성 $\alpha_1 \rightarrow \beta_1$과 $\alpha_2 \rightarrow \beta_2$가 $F_C$에 존재하지 않음
• 이는 $F_C^+ = F^+$를 의미
• 직관적으로, F의 정규 커버는 중복 종속성이나 종속성의 중복 부분이 없는, F와 동등한 "최소" FD 집합임.

Canonical Cover

• F에 대한 정규 커버를 계산하는 방법:

  FC = F
  repeat
      Use the union rule to replace any dependencies in FC
          of the form α1→β1 and α1→β2 with α1→β1β2
      Find a functional dependency α→β in FC with an extraneous
          attribute either in α or in β
          /- Note: test for extraneous attributes done using FC, not F -/
      If an extraneous attribute is found, delete it from α→β in FC
  until (FC does not change)
  
• 참고: 일부 불필요한 속성이 삭제된 후 합집합 규칙이 적용 가능해질 수 있으므로, 다시 적용해야 함.

Example: Computing a Canonical Cover

• $R = (A, B, C)$, $F = \{ A \rightarrow BC, B \rightarrow C, A \rightarrow B, AB \rightarrow C \}$
• $A \rightarrow BC$와 $A \rightarrow B$를 $A \rightarrow BC$로 결합
• $F_C$는 이제 $\{ A \rightarrow BC, B \rightarrow C, AB \rightarrow C \}$
• $AB \rightarrow C$에서 $A$가 불필요함
  • $AB \rightarrow C$에서 $A$를 삭제한 결과(즉, $B \rightarrow C$)가 다른 종속성들에 의해 함축되는지 확인
  • 예: 사실 $B \rightarrow C$는 이미 존재함
• $F_C$는 이제 $\{ A \rightarrow BC, B \rightarrow C \}$
• $A \rightarrow BC$에서 $C$가 불필요함
  • $A \rightarrow C$가 $A \rightarrow B$와 다른 종속성들에 의해 논리적으로 함축되는지 확인
  • 예: $A \rightarrow B$와 $B \rightarrow C$에 대한 이행성을 사용하여
  • 더 복잡한 경우에는 A의 속성 폐포를 사용할 수 있음
• 정규 커버는: $F_C = \{ A \rightarrow B, B \rightarrow C \}$

Dependency Preservation

• $R$에 대한 함수 종속성 집합 $F$와 $R$의 분해 $\{R_1, \dots, R_n\}$을 가정
• $F_i$를 $R_i$의 속성만을 포함하는 $F^+$의 모든 FD 집합(즉, F의 $R_i$에 대한 제한)이라 하고, $F' = F_1 \cup F_2 \cup \dots \cup F_n$이라 하자
• 분해가 종속성을 보존한다면,

  $$F'^+ = (F_1 \cup F_2 \cup \dots \cup F_n)^+ = F^+$$

• 즉, 각 $R_i$의 FD를 사용하여 원래 FD를 구성할 수 있음
• 분해가 종속성을 보존하지 않으면 함수 종속성 위반에 대한 업데이트 확인 시 비용이 많이 드는 조인(join)을 계산해야 할 수 있음
• 그러나 분해가 종속성을 보존하면, 이러한 확인이 용이해짐
  • 각 $R_i$에서 $F_i$만 확인하면 충분함
  • 그리고 $F_i$의 모든 FD는 $R_i$의 속성만을 포함하므로, 조인을 하지 않고 하나의 관계만 확인하여 해당 종속성의 만족 여부를 테스트할 수 있음

(Optional) Testing for Dependency Preservation

• $R$을 $R_1, R_2, \dots, R_n$으로 분해할 때 종속성 $\alpha \rightarrow \beta$가 보존되는지 확인하기 위해 다음 테스트를 적용 (속성 폐포는 F로 계산)

  result = α // result는 α에 종속되는 속성들의 집합, 초기에는 α 자신
  repeat
      for each Ri in the decomposition // Fi 하에서 (result)+를 찾음
          t = (result ∩ Ri)+ ∩ Ri
          result = result ∪ t
  until (result does not change) // F' 하에서 (result)+를 찾음
  
• result가 $\beta$의 모든 속성을 포함하면, 함수 종속성 $\alpha \rightarrow \beta$는 보존됨
• 분해가 종속성을 보존하는지 확인하기 위해 F의 모든 종속성에 대해 테스트를 적용
• 이 절차는 $F^+$와 $(F_1 \cup F_2 \cup \dots \cup F_n)^+$를 계산하는 데 필요한 지수 시간이 아닌 다항 시간이 소요됨

Algorithms for Decomposition Using Functional Dependencies

Testing for BCNF

• 자명하지 않은(non-trivial) 종속성 $\alpha \rightarrow \beta$가 BCNF 위반을 일으키는지 확인하기 위해
  1. $\alpha^+$($\alpha$의 속성 폐포)를 계산하고,
  2. 그것이 $R$의 모든 속성을 포함하는지, 즉 $R$의 슈퍼키인지 확인
• 관계 스키마 $R$이 BCNF에 있는지 확인하기 위해
  • 단순화된 테스트: $F^+$가 아닌 $F$의 FD에 대해서만 BCNF 위반 여부 확인
  • $F$의 종속성 중 어느 것도 BCNF 위반을 일으키지 않으면, $F^+$의 종속성 중 어느 것도 BCNF 위반을 일으키지 않음
  • 그러나, $R$의 분해에서 관계를 테스트할 때 $F$만 사용하는 단순화된 테스트는 부정확함
  • $R = (A, B, C, D, E)$, $F = \{A \rightarrow B, BC \rightarrow D\}$를 고려
  • $R$을 $R_1 = (A, B)$와 $R_2 = (A, C, D, E)$로 분해
  • $F$의 종속성 중 어느 것도 $(A, C, D, E)$의 속성만을 포함하지 않으므로, $R_2$가 BCNF를 만족한다고 오해할 수 있음
  • 사실, $F^+$의 종속성 $AC \rightarrow D$는 $R_2$가 BCNF에 있지 않음을 보여줌

(Optional) Testing Decomposition for BCNF

• $R$의 분해에 있는 관계 $R_i$가 BCNF에 있는지 확인하기 위해
  • $F_i$(즉, $R_i$의 속성만을 포함하는 $F^+$의 모든 FD)에 대해 $R_i$를 BCNF 테스트
  • 또는 $R$에서 성립하는 원래의 종속성 집합 F를 사용하되, 다음 테스트를 사용:
    • 모든 속성 집합 $\alpha \subseteq R_i$에 대해, $\alpha^+$가 $R_i - \alpha$의 속성을 포함하지 않거나, $R_i$의 모든 속성을 포함하는지 확인
  • 만약 $F^+$의 어떤 $\alpha \rightarrow \beta$에 의해 조건이 위반되면, 종속성 $\alpha \rightarrow (\alpha^+ - \alpha) \cap R_i$가 $R_i$에서 성립함을 보일 수 있고, $R_i$는 BCNF를 위반함
  • $R_i$를 분해하기 위해 위의 종속성을 사용
  • 후자의 테스트는 F의 모든 $\alpha \rightarrow \beta$에서 $\alpha^+$를 확인하는 대신, $R_i$의 '모든 속성 부분집합'의 속성 폐포를 확인

BCNF Decomposition Algorithm

result := {R};
done := false;
compute F+;
while (not done) do
    if (there is a schema Ri in result that is not in BCNF) then
        begin
            let α→β be a nontrivial functional dependency that holds on Ri
                such that α→Ri is not in F+ , and α∩β = ∅;
            // 이는 α가 Ri의 슈퍼키가 아님을 의미
            result := (result – Ri) ∪ (Ri – β) ∪ (α, β);
        end
    else
        done := true;

• 참고: 각 $R_i$는 BCNF에 있으며, 분해는 무손실-조인(lossless-join)임.

Example of BCNF Decomposition

• class(course_id, title, dept_name, credits, sec_id, semester, year, building, room_number, capacity, time_slot_id)
• 함수 종속성:
  • course_id → title, dept_name, credits
  • building, room_number → capacity
  • course_id, sec_id, semester, year → building, room_number, time_slot_id
• 후보 키: {course_id, sec_id, semester, year}
• BCNF 분해:
  • course_id → title, dept_name, credits가 성립
  • 그러나 course_id는 슈퍼키가 아님
  • class를 다음으로 대체:
    • course(course_id, title, dept_name, credits)
    • class-1(course_id, sec_id, semester, year, building, room_number, capacity, time_slot_id)

Example of BCNF Decomposition

• course는 BCNF에 있음
• building, room_number → capacity가 class-1에서 성립
• 그러나 {building, room_number}는 class-1의 슈퍼키가 아님
• class-1을 다음으로 대체:
  • classroom(building, room_number, capacity)
  • section(course_id, sec_id, semester, year, building, room_number, time_slot_id)
• classroom과 section은 BCNF에 있음

Testing for 3NF

• BCNF 테스트에서처럼, $F$의 FD만 확인하면 됨 ($F^+$의 모든 FD를 확인할 필요 없음)
• 각 종속성 $\alpha \rightarrow \beta$에 대해, $\alpha$가 슈퍼키인지 아닌지 확인하기 위해 속성 폐포 사용
• $\alpha$가 슈퍼키가 아니면, $\beta$의 각 속성이 $R$의 후보 키에 포함되어 있는지 확인해야 함
• 이 테스트는 후보 키를 찾는 것을 포함하므로 상당히 더 비용이 많이 듦
• 3NF 테스트는 NP-hard(NP-난해)인 것으로 나타남
• 흥미롭게도, 3NF로의 분해는 다항 시간에 수행될 수 있음

3NF Decomposition Algorithm

Let FC be a canonical cover for F;
i := 0;
for each FD α→β in FC
    i := i + 1;
    Ri := αβ;

if none of Rj(1 ≤ j ≤ i) contains a candidate key for R
    then
        i := i + 1;
        Ri := any candidate key for R;

/- Optionally, remove redundant relations -/
repeat
    if any schema Rj is contained in another schema Rk
    then
        /- delete Rj -/
        Rj := Ri;
        i := i - 1;
until no more Rjs can be deleted

return (R1, R2, ..., Ri)

• 위 알고리즘은 다음을 보장
  • 각 관계 스키마 $R_i$는 3NF에 있음
  • 분해는 종속성 보존 및 무손실-조인임
• 정확성 증명은 교재(섹션 7.5.3) 참조

3NF Decomposition: An Example

• 관계 스키마: cust_banker_branch = (customer_id, employee_id, branch_name, type)
• 이 관계 스키마의 함수 종속성:
  • customer_id, employee_id → branch_name, type
  • employee_id → branch_name
  • customer_id, branch_name → employee_id
• 먼저 정규 커버를 계산
  • 첫 번째 종속성의 오른쪽에서 branch_name이 불필요함
  • 다른 불필요한 속성은 없으므로, $F_C$를 얻음
    • customer_id, employee_id → type
    • employee_id → branch_name
    • customer_id, branch_name → employee_id

3NF Decomposition: An Example

• for 루프는 다음의 3NF 스키마를 생성:
  • (customer_id, employee_id, type)
  • (employee_id, branch_name)
  • (customer_id, branch_name, employee_id)
• (customer_id, employee_id, type)이 원래 스키마의 후보 키를 포함하므로, 더 이상의 관계 스키마를 추가할 필요가 없음
• for 루프의 끝에서, (customer_id, branch_name, employee_id) 스키마의 부분집합인 (employee_id, branch_name) 스키마를 감지하고 삭제
• 결과적인 단순화된 3NF 스키마는 다음과 같음:
  • (customer_id, employee_id, type)
  • (customer_id, branch_name, employee_id)

Design Goals

• 관계형 데이터베이스 설계의 목표: 스키마를 다음과 같이 분해
  • BCNF
  • Lossless(무손실)
  • Dependency preservation(종속성 보존)
• 이를 달성할 수 없다면, 다음 중 하나를 수용
  • 종속성 보존의 부재
  • 3NF 사용으로 인한 중복성
• 흥미롭게도, SQL은 슈퍼키 이외의 함수 종속성을 지정하는 직접적인 방법을 제공하지 않음
  • Assertion(단언)을 사용하여 FD를 지정할 수 있지만, 테스트 비용이 비쌈 (그리고 현재 널리 사용되는 데이터베이스에서 지원되지 않음)
  • 종속성 보존 분해가 있더라도, SQL을 사용하면 왼쪽이 키가 아닌 함수 종속성을 효율적으로 테스트할 수 없음

and Others

Initial Relation Schemas

• 초기 관계 스키마 R이 주어졌을 때:
  • R은 E-R 다이어그램을 테이블 집합으로 변환할 때 생성되었을 수 있음
  • R은 관심 있는 모든 속성을 포함하는 단일 관계(Universal relation, 전체 관계)였을 수 있음
  • 정규화는 R을 더 작은 관계로 분해
  • R은 임시로 설계된 관계의 결과일 수 있으며, 이를 테스트/정규형으로 변환

(Optional) E-R Model and Normalization

• E-R 다이어그램을 신중하게 설계하고 모든 엔티티를 올바르게 식별하면, E-R 다이어그램에서 생성된 테이블은 추가적인 정규화가 필요하지 않아야 함
• 그러나 실제 (불완전한) 설계에서는 엔티티의 키가 아닌 속성에서 엔티티의 다른 속성으로의 FD가 있을 수 있음 (따라서 BCNF가 아님)
  • 예: employee 엔티티 (ID, name, dept_name, building, salary)
  • 함수 종속성 dept_name → building
  • 좋은 설계는 department를 엔티티로 만들었을 것임
• 관계 집합의 키가 아닌 속성에서 비롯된 함수 종속성은 가능하지만, 대부분의 관계가 이항(binary) 관계이므로 드묾

Denormalization for Performance

• 성능을 위해 비정규화된 스키마를 사용하고 싶을 수 있음
• 예: 과정 정보에 접근할 때마다 모든 선수과목이 과정 정보와 함께 표시되어야 한다고 가정
  • 정규화된 스키마에서는 course와 prereq의 조인이 필요
• 대안 1: course와 prereq의 모든 속성을 포함하는 비정규화된 관계 사용
  • 더 빠른 조회
  • 중복성으로 인한 추가 공간 및 업데이트에 대한 추가 실행 시간
  • 응용 프로그래머의 추가 코딩 작업 및 추가 코드의 오류 가능성
• 대안 2: course ⋈ prereq로 정의된 Materialized view(구체화된 뷰) 사용
  • 프로그래머의 추가 코딩 작업이 없고 가능한 오류를 피한다는 점을 제외하면, 장단점은 위와 동일

Limitation of the Normalization

• 정규화로 포착되지 않는 데이터베이스 설계의 일부 측면
• 피해야 할 나쁜 데이터베이스 설계의 예:
  • earnings(company_id, year, amount) 대신 다음 사용
    • earnings_2004, earnings_2005, earnings_2006 등, 모두 (company_id, earnings) 스키마 사용.
    • 위는 BCNF에 있지만 매년 새로운 테이블이 필요하고, 각 새로운 관계를 고려하기 위해 매년 새로운 쿼리를 작성해야 함
    • 여러 해에 걸친 쿼리도 많은 관계를 참조해야 하므로 더 복잡해짐
  • company_year(company_id, earnings_2004, earnings_2005, earnings_2006)
    • BCNF에 있지만, 위와 동일한 문제가 있음
  • 한 속성의 값이 열 이름이 되는 Crosstab(교차 분석표)의 예로, 스프레드시트와 데이터 분석 도구에서 사용됨