[Database Modeling] 함수 종속성(Functional Dependency)

DaeHoon·2024년 2월 20일
0

Database Modeling

목록 보기
5/5
  • 데이터베이스 설계의 주요 개념 중 하나는 데이터베이스 테이블의 속성 간의 관계를 설명하는 함수 종속성이다. 함수 종속성은 데이터베이스에서 데이터 무결성을 보장하고 데이터 중복성을 줄이는 데 중요한 역할을 한다.
  • 함수 종속성데이터베이스 테이블의 속성 간의 관계를 제어하는 규칙 세트다. 한 속성의 값이 동일한 테이블에서 다른 속성의 값을 결정하는 방법을 설명한다.
    • 예를 들어, 고객 테이블에서 고객의 이메일 주소는 고유한 고객 ID에 따라 달라질 수 있다. 고객 ID가 변경되면 데이터 무결성을 유지하기 위해 이메일 주소도 변경해야 한다.

함수 종속성(Functional Dependency)

  • 함수 종속(functional dependency)은 데이터베이스의 릴레이션(relation)에서 두 개의 속성(attribute) 집합 간 제약의 일종
  • 어떤 릴레이션 R에서, X와 Y를 각각 R의 속성(attribute) 집합의 부분 집합이라고 가정하자. 속성(attribute) X의 값 각각에 대해 시간에 관계없이 항상 속성(attribute) Y의 값이 오직 하나만 연관되어 있을 때 Y는 X에 함수 종속이라 하고, X → Y로 표기한다.
  • 여기서 X는 결정자(determinant set)라 하고, Y를 종속자(dependent attribute)라고 한다.
  • 주의할 점은 X → Y 라고 해서 Y → X는 아니다. 가령 id -> name이라 해서 name -> id가 되지는 못한다. name이 동명이인인 경우도 존재하니까.

함수 종속성의 종류

1. 완전 함수 종속 (Full Functional Dependency)

X->Y가 주어지고 모든 부분 집합(proper subset) X'이 Y를 결정할 수 없으면 X->Y는 full FD라고 한다.

  • {사원번호, 부서번호} -> {직책} (가능)
  • {사원번호} -> {직책} (불가능)
  • {부서번호} -> {직책} (불가능)

즉, {사원번호, 부서번호}로만 {직책}을 결정할 수 있고, 이러한 관계를 완전 함수 종속이라고 한다.

2. 부분 함수 종속 (Partial Functional Dependency)

X->Y가 주어지고 부분 집합(proper subset) X'이 Y를 결정할 수 있으면 X->Y는 Partial FD

  • {사원번호, 부서번호} -> {사원이름, 주소, 전화번호}
  • {사원번호} -> {사원이름, 주소, 전화번호}

해당 관계는 {사원번호}로 종속자 Y인 {사원이름, 주소, 전화번호}를 결정할 수 있으므로 부분 함수 종속이다.

  • {사원번호, 부서번호} -> {부서이름}
  • {부서번호} -> {부서이름}

이 경우도 마찬가지로 {부서번호} 종속자 Y인 {부서이름}을 결정할 수 있으므로 부분 함수 종속이다.

또한 해당 종속은 제 2 정규화 대상이 된다.
[사원번호, 사원이름, 주소, 전화번호], [부서번호, 부서이름], [사원번호, 부서번호, 직책]

3. 이행 함수 종속 (Transitive Functional Dependecy)

릴레이션에서 X, Y, Z라는 3 개의 속성이 있을 때 X→Y, Y→Z 이란 종속 관계가 있을 때, X→Z가 성립되면 Transitive FD

  • {사원번호} -> {사원이름} -> {주소, 전화번호, 직책} 일 경우 {사원번호} -> {주소, 전화번호, 직책} 관계가 성립한다.

해당 종속은 제 3 정규화 대상이 된다.
[사원번호, 사원이름], [사원이름, 주소, 전화번호]

4. 결정자 함수 종속 (Boyce-codd Normalization)

제 3 정규화를 만족은 하나(Non Tivial), 함수 종속의 결정자가 후보키가 아닌 경우.

  • {Student, Course} -> {Room}
    • Student, Course로 Room이라는 값을 정할 수 있다.
  • {Room} -> {Course, Student}
  • 하지만, 일반 컬럼인 Room으로도 Course, Student를 결정할 수 있고, Room은 후보키가 아니다.
  • 릴레이션에 존재하는 종속자는 후보 키가 아니어야 한다 (즉, 일반 컬럼이 후보 키를 결정하면 안된다.)
  • 해당 테이블은 [Room, Course], [Student, Room]으로 재구성할 수 있다.

해당 종속은 제 BCNF 정규화 대상이 된다.

profile
평범한 백엔드 개발자

0개의 댓글