본문 바로가기
Quality control (Univ. Study)/Database Design

Relation schema design protocol and Functional Dependencies

by 생각하는 이상훈 2023. 10. 31.
728x90

Relation schema design protocol

관계형 데이터베이스 설계란 좋은 릴레이션 스키마를 생성하기 위하여 애트리뷰트들을 그룹핑하는 과정이다. 이때 좋은 릴레이션 스키마의 기준은 단순성과 무결성으로 크게 볼 수 있으나 복합적인 기준이 반영이 되어야할 것이다. 아래를 보면 같은 데이에 대해 좋은 relation schema와 나쁜 relation schema가 예시로 나와있다.

GOOD relation schema
GOOD DB based on GOOD relation schema
BAD schema

먼저 좋은 릴레이션 설계에 관한 개괄적인 지침을 논의한 후, 함수적 종속성과 정규형 개념에 관해 논의한다.

 

릴레이션 스키마를 형성하기 위해 애트리뷰트들을 집단화 하는 경우, 한 릴레이션에 속하는 애트리뷰트는 실세계에서 어떤 의미를 가져야 한다. 여러 엔티티(EMPLOYEE, DEPARTMENT, PROJECT)의 애트리뷰트들이 하나의 릴레이션에혼합되면 의미가 불명확해지므로 좋지 않다. 하나의 릴레이션은 하나의 엔티티나 관계를 나타내는 것이 바람직하다. 다른 엔티티를 참조하기 위해서는 외래키 만을 사용해야 한다.


투플단위 주의사항

하나의 릴레이션에 하나 이상 엔티티의 애트리뷰트들을 혼합하는 것은 아래와 같이 여러 가지 문제를 일으킨다. 

정보가 중복 저장되며, 저장 공간을 낭비하게 된다. 또한 갱신 이상이 발생하게 된다. 동일한 정보를 한 릴레이션에는 변경하고, 나머지 릴레이션에서는 변경하지 않은 경우 어느 것이 정확한지 알 수 없게 되어 발생하는 문제이다. 갱신 이상의 종류에 대해서 살펴보면 3가지 정도가 있다.

삽입 이상 (insertion anomalies): ex) EMP_DEPT에 객체를 삽입할 때 부서가 정해지지 않은 직원이나 직원이 없는 부서를 insert 하는데 문제가 발생한다.

삭제 이상 (deletion anomalies): ex) 부서의 마지막 직원을 삭제하면 부서 정보도 없어진다.

수정 이상 (modification anomalies): ex) 부서 정보를 변경하면 부서의 모든 직원 투플에서 동일하게 변경해야 한다.

 

아래의 예시와 함께 살펴보자.

ㅇ삭제이상(deletion anomaly)

- 200번 학생이 'C123'의 등록을 취소

⇒ 3학년이라는 정보도 함께 삭제됨

- 연쇄 삭제(triggered deletion)에 의한 정보의 손실(loss of information)

 

ㅇ삽입이상(insertion anomaly)

- 600번 학생이 2학년이라는 사실을 삽입

⇒ 어떤 과목을 등록하지 않는 한 삽입이 불가능

(∵ 과목 번호가 기본 키)

- 원하지 않는 정보의 강제 삽입

 

ㅇ갱신이상(update anomaly)

- 400번 학생의 학년을 4에서 3으로 변경

⇒ 학번이 400인 4개의 투플 모두를 갱신시켜야 함

- 중복데이타의 일부 갱신으로 정보의 모순성(inconsistency) 발생

 

위와 같은 문제들을 해결하기 위해 애트리뷰트들 간의 종속관계를 분석하여 여러개의 릴레이션으로 분해(decomposition)하여 정규화(normalization)를 진행한다.


투플의 NULL

릴레이션의 투플들이 (가급적) 널 값을 가지지 않도록 설계해야 한다. 널 값은 저장 단계에서 공간을 낭비하게 되고 논리적 차원에서는 조인 연산들을 지정하기 힘들고 애트리뷰트들의 의미를 이해하기 어렵다. 또한 COUNT나 AVG와 같은 집단 함수들이 적용되었을 때 널 값의 해석이 모호하다. 널 값은 다음과 같이 여러 가지로 해석이 가능하여 더욱 모호해진다.

1. 그 애트리뷰트가 이 투플에는 적용되지 않는다. (존재 여부를 모른다)

2. 이 투플에서 애트리뷰트의 값이 아직 알려져 있지 않다 (존재하지만 모른다).

3. 애트리뷰트 값이 알려져 있지만 DB에 기록되지는 않았다.

따라서 모든 널 값을 동일하게 표현하면 널 값이 갖는 여러 의미를 훼손하게 된다.

 

이런 문제점을 방지하기 위해서 릴레이션을 분리하여 해결한다. 아래 그림과 같이 널 값이 많이 나타나는 애트리뷰트들은 별도 릴레이션으로 분리하는 것이다.

사원들 중 10%만이 자기의 사무실을 가지고 있는 경우, 사원 레코드의 90%는 널 값으로 채워져서 문제를 방지하기 위해 분리한 모습이다.


가짜 투플 (Spurious Tuple)

관계 데이터베이스 설계를 잘못하게 되면, 조인 연산들이 틀린 결과를 생성할 수 있다. 조인 연산의 결과가 올바르기 위해서는, 릴레이션들이 “무손실 조인(lossless join)” 조건을 만족하도록 설계되어야 한다. 무손실 조인 특성상 원래의 릴레이션을 분해하여 두 릴레이션을 생성하는 경우, 분해된 두 릴레이션을 조인하면 원래의 릴레이션이 복원되어야 한다. 무손실 조인 특성이 만족되지 않으면 조인 시 원래의 릴레이션에 없던 가짜 투플이 발생한다. 분해 시 (기본키, 외래키) 조합을 이용하는 것이 바람직하고 키가 아닌 애트리뷰트를 매개로 분해하면 조인 시 가짜 투플이 발생할 수 있다.

얼핏 보기에도 잘못 만들어진 위의 릴레이션 두개를 조인하면 아래와 같이 된다.

* 는 가짜 투플을 나타냄

Ssn이 같고 다른 이름을 가진 데이터 즉 수많은 가짜 투플이 생성된 것을 볼 수 있다.


함수적 종속성(FD)

함수적 종속성(FD: functional dependency)은 좋은 릴레이션 설계의 정형적 기준으로 사용된다. FD와 키는 릴레이션의 정규형을 정의하기 위해 사용된다. FD는 데이터 애트리뷰트들의 의미와 애트리뷰트들 간의 상호 관계로부터 유도되는 제약조건 (constraints)의 일종이다.

X와 Y를 임의의 애트리뷰트 집합이라고 할 때, X의 값이 Y의 값을 유일하게(unique) 결정한다면 “X는 Y를 함수적으로 결정한다(functionally determines)”라고 한다. X → Y로 표기하고, “Y는 X에 함수적으로 종속된다” 라고 한다. X를 결정자(determinant), Y를 종속자(dependent)라고 부른다. 함수적 종속성은 모든 릴레이션 인스턴스 r(R)에 대하여 성립해야 한다. 다시 말해서 릴레이션 인스턴스 r(R)에 속하는 어떠한 임의의 두 투플에 대해서도 속성들의 집합 X에 대해 동일한 값을 가질 때마다 Y에 대해서도 동일한 값을 가진다면 X → Y라는 함수적 종속성이 성립한다. 즉, r(R)에서의 임의의 두 투플 t1과 t2에 대해 t1 [X] = t2 [X]이면, t1 [Y] = t2 [Y]이다.

 

FD 제약조건의 예제를 보면 아래와 같다.

• 주민등록번호는 사원의 이름을 결정한다. SSN → ENAME

• 프로젝트 번호는 프로젝트 이름과 위치를 결정한다. PNUMBER → {PNAME, PLOCATION}

• 사원의 주민등록번호와 프로젝트 번호는 그 사원이 일주일 동안 그 프로젝트을 위해서 일하는 시간을 결정한다. {SSN, PNUMBER} → HOURS


완전 함수 종속과 부분 함수 종속

복합 애트리뷰트 X에 대하여 X -> Y가 성립할 때 완전 함수 종속 (full functional dependency)은 X' ⊂ X 이고 X’ ⊂ Y 를 만족하는 애트리뷰트 X'이 존재하지 않는 경우를 의미하고 부분 함수 종속 (partial functional dependency)은 X' ⊂ X 이고 X' ⊂ Y 를 만족하는 애트리뷰트 X'이 존재한다는 것을 의미한다. 아래의 예시를 통해 살펴보자.

 

ex) 수강 릴레이션의 함수 종속

학번 -> 학년

{학번,과목번호} -> 성적

(학년)은 (학번)에 완전 함수 종속, 그러나 {학번,과목번호}에는 부분 함수 종속이고 (성적)은 {학번,과목번호}에 완전 함수 종속이다. 

 

ㅇ함수 종속에 대한 추론 규칙

R1: (반사, reflexive) A ⊇ B이면 A -> B이다. 또한 A -> A이다

R2: (첨가, augmentation) A -> B이면 AC -> BC이고 AC -> B이다.

R3: (이행, transitive) A -> B이고 B -> C이면 A -> C이다.

R4: (분해, decomposition) A -> BC이면 A -> B이다.

R5: (결합, union) A -> B이고 A -> C이면 A -> BC이다.


 

728x90

'Quality control (Univ. Study) > Database Design' 카테고리의 다른 글

Normalization (2)  (0) 2023.11.09
Normalization (1)  (0) 2023.11.07
Login page  (0) 2023.10.31
SQL 실습 (2)  (0) 2023.10.20
SQL 실습(1)  (1) 2023.10.20