Key?
- super key : DB table의 각 튜플(tuple)을 유니크하게 식별(uniquely identify)할 수 있는 attribute(s)를 의미
- key (or candidate key) : super key인데, 이 key에서 attribute를 하나라도 제거하면 더 이상 튜플을 유니크하게 식별할 수 없는 super key
Functional dependency?
DB 테이블의 attributes로 이루어진 집합 X와 집합 Y 사이에 'tuple들의 X값이 같다면 Y값도 같다'는 의존 관계가 존재할 때
X와 Y 사이의 이런 관계를 functional dependency(FD)라고 부르며,
'X는 Y를 함수적으로 결정한다(functionally determine)' 혹은
'X는 Y를 유니크하게 결정한다(uniquely determine)'고 말한다
기호로는 X → Y 라고 표현할 수 있다
Key와 FD의 차이
key는 '튜플'을 유니크하게 식별하는 것이고
functional dependency(FD)는 'attribute(s) 값'을 유니크하게 결정하는 것이다
둘 다 '유니크하게'라는 단어가 들어가서 헷갈릴 수 있는데
FD는 그 이름에서 이미 '함수'적이라는 의미가 있기 때문에 함수의 특징을 잘 생각해보면 이해하기 쉽다
수학에서 함수(function)는 인풋(input)이 같으면 아웃풋(output)이 항상 동일한데
그런 관계가 attributes로 이루어진 두 집합 사이에 존재할 때 이걸 FD라고 하는 것이다
반면 key는 말 그대로 테이블의 튜플을 유니크하게 식별하는 attribute(s)다
그렇기 때문에 key와 key 외의 나머지 attribute(s)들과의 관계는 아래와 같은 FD 관계가 성립한다
key attribute(s) → 나머지 attribute(s)
하지만 그 역은 성립하지 않는데
X, Y 두 attribute(s) 집합이 X → Y의 관계에 있다고 해서 X가 key인 것은 아니다
사실 X와 key는 아무런 관계가 없다
예를 통해 확인
마지막으로 축구 선수 정보를 저장하는 Soccer_Player 테이블을 예로 살펴보자
아래는 Soccer_Player 테이블 스키마(schema)이다
team_id | back_number | team_name | player_name |
여기서 key는 {team_id, back_number}다
팀 ID만으로는 축구 선수를 유니크하게 식별할 수 없고
등번호(back_number)만으로는 축구 선수를 유니크하게 식별할 수 없지만
각 팀에서 등번호는 유니크하게 선수들에게 부여되기 때문에
{team_id, back_number}를 함께 사용하면 축구 선수를 유니크하게 식별할 수 있다
그러면 이 key를 통해 아래와 같은 FD도 존재한다고 말할 수 있다
{team_id, back_number} → {team_name, player_name}
즉, 동일한 팀 ID와 등번호는 항상 동일한 팀 이름과 선수 이름을 가지게 된다
그리고 여기에는 또 다른 FD가 있는데,
{team_id} → {team_name}
이런 FD가 존재한다
즉, 동일한 팀 ID는 항상 동일한 팀 이름을 가지게 된다
팀 ID는 동일한데 여러 팀 이름들을 가질 수는 없다
그리고 {team_id}가 key는 아닌 것처럼
FD 관계에 있다고 해서 화살표 왼쪽에 있는 left-hand side가 key인 것은 아니다
key일지 아닐지는 전혀 별개의 문제다
쉬운코드는 본질에 충실합니다
👉 funcitonal depedency 영상 보러 가자