[Database] 키의 개념과 구분(슈퍼키, 후보키, 기본키, 대체키, 외래키)

안녕하세요.

 

오늘은 관계형 데이터베이스의 키의 개념과 구분에 대해서 알아보려고 합니다. 

 

관계형 데이터베이스의 키의 개념을 알기 위해서는 

 

유일성과 최소성의 개념에 대해 알아야 합니다. 

 

 

- 유일성

관계형 데이터베이스에서 유일성이란 테이블의 행을 고유하게 식별할 수 있는 속성 또는 속성의 집합을 말합니다. 

 

 

위와 같은 테이블에서 행 하나를 유일하게 구별할 수 있는 필드값을 찾아봅시다. 

 

학번으로 유일하게 구별 할 수 있으며 생년월일도 가능하며 이름도 가능합니다. 

 

성별은 중복이 있어서 불가능하죠. 

 

그런데 여기서 (이름, 성별)을 묶어서 생각하면 유일하게 구별할 수 있습니다. 

 

마찬가지로 (학번, 생년월일) , (생년월일, 이름), (생년월일, 이름, 성별), (학번, 생년월일, 이름) 등등.....

 

필드값을 조합해서 유일성을 찾을수 도 있습니다. 

 

- 최소성

관계형 데이터베이스에서 최소성이란 키를 구성하는 속성 하나를 제거하면 유일하게 식별할 수 없도록 반드시 필요한 

 

최소의 구성으로 이루어져야 한다는 것입니다. 

 

위에서 예시를 든 테이블로 설명을 하겠습니다.  

 

이전에 유일성을 만족하는 필드값들이 (학번), (생년월일), (이름, 성별), (학번, 생년월일), (생년월일, 이름) 등등

 

여러 필드 조합이 나왓습니다. 

 

여기서 (학번, 생년월일) 필드값을 보면 둘 중 하나의 필드가 없어도 유일성을 만족할 수 있습니다. 

 

학번만으로도 가능하며, 생년월일만으로도 테이블의 행을 유일하게 구분할 수 있습니다. 

 

이러한 경우 (학번, 생년월일)은 최소성을 만족하지 못하고 학번과 생년월일 각각이 최소성을 만족하는 필드입니다.

 

 

 

- 슈퍼키

슈퍼키란 유일성을 만족하는 키값입니다. 

 

이전에 설명했던 테이블에서  학번, 생년월일, 이름, (학번, 생년월일) , (생년월일, 이름), (생년월일, 이름, 성별),

 

(학번, 생년월일, 이름) 등등..... 모든 조합이 슈퍼키가 될 수 있습니다. 

 

 

 

- 후보키

후보키란 유일성과 최소성을 만족하는 키값입니다. 

 

위의 예시에서 후보키는 학번, 생년월일, 이름이 후보키가 될 수 있습니다. 

 

 

- 기본키

흔히 말하는 pk이며 설계자에 의해 선택된 후보키 중 테이블의 식별자로 가장 적합한 키값 입니다.

 

이론적으로 후보키의 개념과 크게 차이가 나지 않지만 기본키는 실무에서 사용되는 의의가 크며

 

pk의 설정에 따라 테이블 접근과 성능에 큰 영향을 끼칠 수 있습니다.

 

 

- 대체키

대체키는 후보키들 중 기본키로 선택되지 못한 키값들을 대체키라고 합니다.

 

 

 

슈퍼키, 후보키, 기본키, 대체키의 관계는 아래와 같습니다.

 

 

 

 

- 외래키

관계형 데이터베이스에서 한 테이블의 필드가 다른 테이블의 행을 식별할 수 있는 키를 외래키라고 합니다. 

 

간단히 설명하면, 두 테이블을 연결하고 참조하는 테이블을 자식 테이블, 참조되는 테이블을 부모테이블이라고 합니다.

 

참조하는 테이블인 자식테이블에서 외래키를 설정하며 외래키는 부모테이블의 기본키로 설정해야합니다.

 

외래키를 설정하는 예시를 이론적인 내용보다는 실무적인 특성을 통해 살펴보겠습니다. 

 

수학문제에 적용될 단원정보와 유형정보를 구성하는 테이블이 아래와 같이 있다고 하겠습니다.

 

 

 

문제 유형 정보는 고유하지만 단원정보는 중복이 굉장히 많이 있음을 알 수 있습니다. 

 

간단한 예시를 들었지만, 실제로 하나의 대단원 안에 중단원도 여러개이며, 그 중단원 안에 소단원도 여러개

 

문제 유형도 여러개이기 때문에 테이블의 중복값은 훨씬 심해질 것입니다. 

 

초등수학부터 고등수학까지 단원정보와 유형정보가 모두 저장된다면 더욱더 심해지겠죠.

 

또한, 프로그래밍 환경에서 사용자들이 단원정보를 통해 유형정보를 검색하는 경우를 위해

 

개발자가 검색 기능을 개발할때 쿼리의 where 조건에는 (대단원, 중단원, 소단원) 모두 들어가야하며

 

모든 필드값이 한글로 저장되어 있어 검색성능도 굉장히 좋지 못할 것입니다. 

 

마찬가지로 단원정보만 모두 불러들이고 싶은 경우 단원정보가 중복이 심하여 중복체크를 해야하는

 

불필요한 스캔 과정을 거쳐야합니다.

 

위의 테이블은 테이블 자체로도 중복이 많아 디스크낭비가 심하며

 

프로그래밍 환경에서 접근하기에도 성능이 좋지 못한 테이블입니다.

 

 

위의 테이블의 설계적 결함과 성능적 결함 해결을 목적으로 아래와 같이 분리해보겠습니다.

 

 

 

위와 같이 단원정보 테이블과 유형정보 테이블로 분리했으며

 

단원정보 테이블에 단원고유번호라는 정수형 필드값을 추가했으며

 

유형정보 테이블에도 유형번호라는 정수형 필드값을 추가했습니다. 

 

이때 단원정보 테이블의 단원고유번호는 pk이며 유형정보 테이블은 이 단원 고유번호 필드를 외래키로 설정하여

 

문제유형에 대한 단원 정보를 참조 할 수 있습니다.

 

단원고유번호나 유형번호와 같은 정수형 필드값을 통해 쿼리의 성능도 향상시킬 수 있으며

 

테이블의 중복값도 줄일 수 있습니다.

(제가 든 예시로는 데이터가 오히려 많아진것처럼 보이지만 실제 데이터가 많다면 중복도가 줄어듦을 확인할 수 있습니다.)

외래키는 개념으로 이해하기 보다는 실제 사용 사례를 보며 이해하고

 

외래키를 사용하는것이 효율적인지 비효율적인 판단하여 설계하는 것이 좋을 것입니다.

 

 

이렇게 해서 슈퍼키, 후보키, 기본키, 대체키, 외래키에 대해서 알아보았습니다.

 

프로그래밍은 죽어도 살릴 수 있지만, DB는 한번 죽으면 살릴 수 없다는 말이 있더군요.

 

한번 설계한 테이블은 왠만하면 수정이 잘 일어나지않고 데이터가 쌓일수록 수정하기에는 더욱 까다로워집니다. 

 

DB의 테이블은 데이터가 쌓일 수록 성능이 나빠지는데 잘못 설계한 테이블이라면 더욱더 나빠지는 속도가 빠를 것이고

 

이는 아무리 실력있는 개발자가 프로그래밍을 짜도 설계가 잘못된 테이블의 접근 성능은 살릴 수 없다는걸 의미하겠죠.

 

DB에 대해서는 기본적인 개념조차 가볍게 여겨왔는데

 

DB에 대해 깊게 알아봐야할 필요가 있을 것 같습니다.