DB를 설계하는 방법의 기본이 되는 functional dependency(함수 종속)에 대해 알아보자
모든 내용은 영상을 참고해 정리한 내용이다!
한 테이블에 있는 두 개의 attribute(s) 집합 사이의 제약
empl_id(pk) | empl_name | birth_date | position | salary | dept_id |
---|
가 있다 하자.
집합 X: {empl_id}
집합 Y: {empl_name, birth_date, position, salary}
라고 한다면 의미적으로 X 값이 같으면 Y 값도 같다는 것을 알 수 있다.
이렇게 X값에 따라 Y값이 유일하게 결정될때
X가 Y를 함수적으로 결정한다(functionally determine)
Y가 X에 함수적으로 의존한다(functionally dependent)
라 말할 수 있고, 두 집합 사이의 이런 제약 관계를 functional dependency(FD)라고 부른다
이런 FD 관계는 테이블의 데이터를 보고 판단하면 안되고 스키마를 보고 의미적으로 파악해야 한다.
즉, 테이블에 employee 이름에 따라 생일이 모두 다르다고 FD라 판단하면 안된다. 실제 동명이인이 있을 수 있어 employee_name이 같아도 생일이 다를 수 있기 때문이다.
위의 집합 Y에 만약 dept_id
도 추가되면 X -> Y를 만족할 수 있을까?
이는 회사의 정책에 따라 다를것이다. 임직원이 하나 이상의 부서에 속할 수 있다면 FD가 될 수 없지만 하나의 부서에만 속하게 된다면 X -> Y를 만족할 것이다.
X: empl_id
Y: empl_name
일때 X -> Y는 만족한다. 하지만 Y -> X는 만족하지 않는데, 동명이인이 있는 경우 Y가 같아도 X는 달라질 수 있기 때문이다.
공집합이 Y를 결정한다. 즉, Y값은 언제나 하나의 값만을 가진다는 의미이다.
특정 attribute에 따라 Y가 바뀌는게 아닌 항상 같은 값을 가짐.
X -> Y이고, 이때 Y가 X의 부분집합이면 X -> Y를 trivial FD라고 한다.
ex. {a, b, c} -> {c}, {a, b, c} -> {a, b, c}
X -> Y이고, 이때 Y가 X의 부분집합이 아니면 X -> Y는 non-trivial FD라 한다.
ex. {a, b, c} -> {b, c, d}
{a, b, c} -> {d, e} <- 이 경우는 X와 Y에 겹치는 부분이 하나도 없음. 이럴땐 completely non-trivial FD
라고 함
X -> Y이고, X의 proper subset이 Y를 결정지을 수 있다면, X -> Y는 partial FD이다.
X의 proper subset이란? X의 부분 집합이지만 X와 동일하진 않은 집합
ex. X = {a, b} 이면 X의 proper subset은 {}, {a}, {b}가 될 수 있다.
하지만 {a, b}는 proper subset이 아니다!
partial FD의 예를 알아보자.
{empl_id, empl_name} -> {birth_date}이란 FD가 있을 때
사실 empl_id만으로 birth_date가 결정된다.
따라서 {empl_id, empl_name} -> {birth_date}는 partial FD라 할 수 있다.
X -> Y이고, X의 proper subset이 Y를 결정지을 수 없다면(즉, X 전체만이 Y를 결정지을 수 있음), X -> Y는 full FD이다.
{stu_id, class_id} -> {grade}인 FD가 있다.
하지만 {stu_id, class_id}의 proper subset인 {stu_id}, {class_id}, {}는 {grade}를 결정지을 수 없다.
따라서 {stu_id, class_id} -> {grade}는 full FD이다.