Relational Database Design

Features of Good Relational Design

• 좋은 E-R database schema를 설계해야 좋은 relation schema가 탄생
• Bad relation schema는 Anomalies(이상현상)을 초래

Anomalies : Redundancy

• Normalization(정규화)을 하지 않으면 Attribute의 중복된 값이 많아져 Anomalies들을 초래한다.

Anomalies : Update

• 위의 예를 보면 dept_name = Comp.Sci, building = Talyor의 budget은 10000인데, 50000으로 업데이트를 하면 데이터에 모순이 생긴다.

Anomalies : Delection

• 하나만 있는 튜플를 삭제할 경우, 그에 대한 정보가 다 사라진다.

위와 같은 문제점들을 Decomposition을 이용해 해결한다.

Fucntional Dependency (함수 종속)

• 어떤 Relation R에서, A와 B를 각각 R의 Attribute 집합의 부분 집합이라 하자. Attribute A의 값 각각에 대해 시간에 관계없이 항상 Attribute B의 값이 오직 하나만 연관되어 있을 때 B는 A에 함수 종속이라 하고, A → B라고 표기한다. [1]

  최대 한 개의 B 값에 연관되어 있을 때**, 애트리뷰트의 집합 A를 함수 결정(to functionally determine)하다고 한다.

• A1,A2...,An -> B 이렇게 표현 가능

• A1,A2...는 결정자(Determinant), B는 Dependent Attribute (종속 속성)이라 한다.

Fucntional Dependency : Example

• Fucntional Dependency를 판단할 때는 현재 값만 보고 판단하는 것이 아니라, Attribute가 갖는 의미를 보고 판단해야 한다.
• ex) ID, name값으로 오직 하나의 salary를 판단할 수는 있지만, ID만 보고 모든 salary가 독립적인 값을 가진다고 볼 수는 없다.

Fucntional Dependency (Cont.)

• B가 A에 대해 functional dependency (A -> B) 일 때, 튜플 t1, t2의 A값이 같으면 b도 같다.
• t1[A] = t2[A] -> t1[B] = t2[B]

Fucntional Dependency (Cont.) : Example

• length는 title, year에 대해 functional dependency
• title과 year의 값이 star wars, 1977인 tuple의 length는 124로 같다.

Fucntional Dependency (Cont.) : Trivial

• A -> B 일 때, B는 A의 부분집합이면 Trivial이다.

Fucntional Dependency (Cont.) : Transitive Rule

• A -> B and B -> C이면 A -> C

Normalization (정규화)

• 관계형 데이터베이스의 설계에서 중복을 최소화하게 데이터를 구조화하는 프로세스
• Anomalies 현상들을 없애준다!

Normalization : 1NF

• Domain 값이 Atomic 해야한다.

Exmaple

• 2번째 tuple에서 Telephone Number의 값은 Atomic하지 않다.

• 이렇게 쪼개면 1NF를 만족하는 Table이 된다.
• 참고로 위의 테이블은 2NF와 3NF도 만족함.

Normalization : 2NF

• 1NF를 만족하고, Candidate Key K와 K에 속하지 않는 속성 A가 있을 때, A를 결정하기 위해 K의 일부가 아닌 K 전체를 참조해야만 하는 경우
• 즉 후보 키 (또는 기본 키)에 속하지 않는 모든 속성들이 완전 함수 종속이여야 한다.

Example

• 위와 같은 table에서 candidate key(Primary key도 가능)는 {종업원, 기술}이다.
• 하지만 {근무지}라는 Attribute는 오직 {종업원}이라는 candidate key의 일부인 Attribute에만 영향을 받는다.
• 위의 Table은 Jones가 3번의 중복, Ellis가 2번의 중복이 존재한다. 이 중복은 Update Anomaliy의 원인이 된다.

• 2NF로 만들려면, 위와 같이 {종업원}을 Candidate key로 두고 나머지 Attribute가 key의 일부가 아닌 전체를 참조하게 한다.

Normalization : 3NF

• 2NF를 만족하고, transitive functional dependency (이행적 종속)이 없어야 한다.

Example

• 이 테이블은 2NF 테이블이다. 우승자와 우승자 생년월일이 {대회, 연도}라는 candidate key에 의해 결정되지만, 우승자와 우승 생년월일은 레코드에 중복이 되어 나타난다. 즉, Update Anomaly 현상을 불러온다.
• {대회, 연도} -> {우승자}, {우승자} -> {우승자 생년월일}. 이 테이블은 transitive Functional Dependency(이행적 종속)을 만족한다.

• 위와 같이 테이블을 A->B, B->C로 쪼갠다.

Normalization : BCNF

• 조건 : 3NF를 만족하고, nontrivial dependency A -> B일 때, A는 superkey여야 한다. (모든 결정자는 superkey여야 한다와 같다.)

Example

• dept_name가 super key가 아니지만 A -> B를 만족한다. 이는 BCNF가 아니다

• ID는 superkey이고 A->B를 만족한다. 이는 BCNF가 맞다.

Decomposing a Schema into BCNF

• R을 (A U B)와 (R - (B-A))의 테이블로 쪼갤 수 있다.

Decomposing a Schema into BCNF : Example

A : dept_name, B : budget, building이라 하면 아래와 같이 relation을 쪼갤 수 있다.

• 이 식을 통해 아래와 같은 Table로 쪼갤 수 있다.

• 이를 Anomaly 현상이 안 생길 때까지 반복해서 쪼갠다.