꼽행착오

데이터베이스 키의 개념과 종류

데이터베이스에서 키 (Key) 는 조건에 만족하는 튜플을 찾거나, 순서대로 정렬할 때 다른 튜플들과 구별할 수 있는 기준이 되는 속성이다.

하나의 릴레이션에는 수많은 튜플들이 존재한다. 고객 정보를 저장한 릴레이션에는 많은 고객들에 대한 튜플들이 존재하며, 각 튜플들 간에는 중복되는 속성값이 발생할 수 있다. 

예를 들어 이름, 나이, 사는 곳 등의 정보가 중복될 수 있는데, 이 때 각각의 고객(튜플)을 구분하기 위한 기준이 되는 속성이 필요하다. 이것을 우리는 "키" 라고 부르며, 하나의 속성 또는 여러 속성들의 집합으로 표현할 수 있다.

키의 종류로는 슈퍼키, 후보키, 기본키, 대체키, 외래키 가 있다.

최소성, 유일성

각각의 키에 대해 공부하기 전에, 최소성과 유일성이라는 개념에 대해 정리하고 넘어가려 한다.

유일성

유일성이란, 하나의 키값으로 튜플을 유일하게 식별할 수 있는 성질을 말한다. 위에서 언급했듯 여러 개의 튜플이 존재할 때 각각의 튜플을 서로 구분할 수 있는 속성이 존재해야 한다. 한 마디로 말하자면, 각각의 튜플은 유일해야 한다는 뜻이다. 예를 들어 어떤 릴레이션에 (주민번호, 나이, 사는 곳, 혈액형) 이라는 속성이 존재한다고 하자. 이 때 나이, 사는 곳, 혈액형 은 모두 충분히 중복될 수 있는 속성들이다. 하지만 주민번호는 모두 다르기 때문에 주민번호 속성에서 중복은 절대 발생할 수 없다. 이 릴레이션에서 키는 주민번호로 지정될 것이며, 이렇게 각각의 튜플을 구분할 수 있는 성질을 유일성이라고 표현한다.

최소성

최소성이란, 키를 구성하는 속성들 중 가장 최소로 필요한 속성들로만 키를 구성하는 성질을 말한다. 쉽게 말해, 키를 구성하고 있는 속성들이 진짜 각 튜플을 구분하는 데 꼭 필요한 속성들로만 구성되어 있는지를 의미한다. 예를 들어 위와 같이 (주민번호, 나이, 사는 곳, 혈액형) 릴레이션에서 (주민번호, 나이) 가 키로 지정이 되어 있다면, 당연히 이 키는 각 튜플을 구분할 수 있다. 주민번호와 나이가 모두 같은 사람은 세상에 존재하지 않기 때문에 그렇게 말할 수 있지만, 더 간단하게 주민번호가 중복되는 사람은 세상에 존재하지 않는다. 그렇기 때문에 (주민번호, 나이) 로 지정된 키는 최소성을 만족하지 않고 키에서 나이를 뺀 주민번호 만 키로 지정이 될 경우, 이 키는 최소성을 만족한다고 할 수 있다.

1. 슈퍼키 (Super Key) ; 유일성 O, 최소성 X

슈퍼키는 유일성의 특성을 만족하는 속성 또는 속성들의 집합을 의미한다.

키 값이 같은 튜플은 존재할 수 없다. 예를 들어 (고객 아이디) 의 경우 아이디가 같은 고객은 없기 때문에 슈퍼키가 될 수 있다. 하지만 (직업, 나이, 등급) 의 경우 나이, 직업, 등급이 같은 고객은 충분히 있을 수 있기 때문에 슈퍼키로 사용할 수 없다. 하지만 (고객 아이디, 직업, 나이, 등급) 의 경우는 고객 아이디가 각 튜플을 구분할 수 있는 속성이기 때문에 슈퍼키가 될 수 있다. 이처럼 슈퍼키는 유일성은 만족하지만 최소성은 만족하지 않는 키를 의미한다.

2. 후보키 (Candidate Key) ; 유일성 O, 최소성 O

후보키는 슈퍼키 중 최소성을 만족하는, 즉 유일성과 최소성을 모두 만족하는 속성 또는 속성들의 집합이다. 위의 슈퍼키에서 들었던 예시에서 (고객 아이디, 직업, 나이, 등급) 은 각 튜플을 유일하게 식별할 수 있으므로 유일성은 만족한다. 하지만 여기서 직업, 나이, 등급 정보가 굳이 필요할까? 이 속성들은 튜플 간에 중복되는 속성값을 가지고 있고, 이 속성들이 포함되어 있지 않은 (고객 아이디) 만으로도 튜플의 식별에는 전혀 문제가 되지 않는다. 그러므로 위의 키에서 직업, 나이, 등급을 제외한 (고객 아이디) 는 최소성을 만족하며 후보키가 될 수 있다.

3. 기본키 (Primary Key) ; 후보키 중 선택받은 키

이렇게 각 튜플을 구별할 수 있으며 유일성과 최소성을 모두 만족하는 후보키가 구해졌다. 후보키는 한 테이블 내에서 여러 개 존재할 수 있는데, 여기서 우리는 여러 후보키 중 하나를 택해 사용해야 하며 여기서 선택된 키가 기본키가 된다. 하지만 모든 후보키가 기본키가 되는 것은 아니고 기본키를 선택함에 있어서 다음의 기준을 통과해야 한다.

1. NULL 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적절하다.
2. 값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적절하다.
3. 단순한 후보키를 기본키로 선택한다.

속성

• NULL 값을 가질 수 없다. (개체 무결성의 첫번째 조건)
• 기본키로 정의된 속성에는 동일한 값이 중복되어 저장될 수 없다. (개체 무결성의 두번째 조건)

4. 대체키 (Alternate Key) ; 후보키 중 선택받지 못한 키

대체키는 기본키로 선택받지 못한 후보키들이다. 이름에서 알 수 있듯 대체키는 기본키를 대신할 수 있는 자격은 있지만, 3-1 ~ 3-3 의 조건에 부합하지 않아 기본키로 선택받지 못한 키들을 의미한다. 대체키는 '보조키' 라는 이름으로도 불린다.

5. 외래키 (Foreign Key) ; 다른 릴레이션의 기본키를 참조

외래키는 관계를 맺고 있는 릴레이션 R1, R2 에서 릴레이션 R1 이 참조하고 있는 릴레이션 R2 의 기본키와 같은 R1 릴레이션의 속성이다. 다시 말해 다른 릴레이션의 기본키를 그대로 참조하는 속성 또는 속성들의 집합이 외래키이다. 외래키는 릴레이션 간의 관계를 올바르게 표현하기 위해 필요하다.

속성

• 외래키로 지정되면 참조 테이블의 기본키에 없는 값은 입력이 불가하다. (참조 무결성 조건)

예를 들어, 다음과 같은 고객, 주문 릴레이션이 각각 있다고 하자.

• 고객 (고객 아이디, 고객 이름, 나이, 등급, 직업, 적립금)
• 주문 (주문번호, 주문 고객, 제품, 수량, 단가, 주문 일자)

위의 릴레이션에서 고객 릴레이션은 사이트에 가입한 고객에 대한 데이터를 가지고, 주문 릴레이션은 어떤 제품을 어떤 고객이 주문했는지에 대한 데이터를 다룬다. 주문 릴레이션에는 어떤 고객이 어떤 제품을 '언제, 얼마나, 얼마에' 에 대한 정보가 있을 것이다. 그리고 각 튜플을 구분할 수 있는 기본키(주문번호)가 있을 것이다.

여기서 주문 릴레이션은 고객의 정보를 모두 저장할 필요가 없다. 단지 고객 릴레이션에서 튜플을 구분할 수 있는 기본키가 되는 속성만을 가지고 있으면 된다. 이렇게 고객 릴레이션의 기본키(고객 아이디)를 참조하는 주문 릴레이션의 속성을 외래키(주문 고객)라 한다. 외래키는 관계를 맺은 릴레이션의 기본키를 참조하고 있으며, 이 때 중요한 점은 기본키와 기본키를 참조하는 외래키의 도메인 또한 반드시 같아야 한다는 것이다.

#Reference.

정규화 (Normalization)

1. 정규화란?

정규화의 기본적인 목표는 테이블 간에 중복되는 데이터가 발생하지 않도록 하는 것이다. 중복된 데이터를 허용하지 않음으로써 데이터의 무결성을 유지할 수 있고, 이로 인해 데이터베이스 관리에 필요한 저장 공간을 축소시키는 효과가 있다.

데이터의 중복을 피하기 위해 데이터를 구조화하고, 그 과정에서 테이블을 더 작은 테이블로 분해하는데 이를 구조화하는 정규화 단계가 정의되어 있다.

제 1 정규화

제 1 정규화란, 테이블의 컬럼이 원자값 (Atomic Value) 를 갖도록 테이블을 분해하는 것이다. 예를 들어, 아래와 같이 고객의 취미를 저장한 테이블이 존재한다고 하자.

위 테이블에서 '추신수' 와 '박세리' 는 여러 개의 취미를 가지고 있어 제 1 정규형을 만족하지 못하고 있다. 이를 제 1 정규화를 통해 분해할 수 있는데, 제 1 정규화가 적용된 테이블은 다음과 같다.

제 2 정규화

제 2 정규화란, 제 1 정규화가 진행된 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다. 여기서 완전 함수 종속이란 것은 기본키의 부분집합이 결정자가 되어선 안된다는 것을 말한다.

말이 조금 어려운데, 간단하게 얘기해서 어떤 테이블의 기본키가 두 개 이상의 컬럼으로 구성된 복합키일 때 기본키를 분해한 부분집합으로 인해 다른 컬럼의 값이 결정되어서는 안된다는 것이다. 예를 들어 다음의 테이블을 보면 조금 더 이해가 빠를 수 있다.

위 테이블에서 기본키는 {학생번호, 강좌이름} 의 복합키로 지정되어 있다. 그리고 {학생번호, 강좌이름} 의 기본키는 성적을 결정하고 있다. 그런데 여기서 강의실이라는 컬럼은 기본키의 부분집합인 {강좌이름} 에 의해 결정될 수 있다. 그렇기 때문에 위 테이블은 다음과 같이 기존의 테이블에서 강의실을 분해해 별도의 테이블을 관리해 제 2 정규형을 만족시킬 수 있다.

제 3 정규화

제 3 정규화란, 제 2 정규화를 진행한 테이블에 대해 이행적 종속이 없도록 테이블을 분해하는 것이다. 여기서 이행적 종속이란, A → B, B → C 가 성립할 때 A → C 가 성립하는 것을 의미한다.

예를 들어, 다음의 테이블을 살펴보자.

위 테이블에서 학생 번호는 강좌 이름을 결정하고 있고, 강좌 이름은 수강료를 결정한다. 결국, 학생 번호에 따라 수강료가 결정되므로 제 3 정규형을 만족하지 않는 테이블이다. 이를 제 3 정규형을 만족하도록 하기 위해서는, (학생 번호, 강좌 이름) 테이블과 (강좌이름, 수강료) 테이블로 분해할 필요가 있다.

이행적 종속을 제거하는 이유는 간단하다. 위의 테이블대로라면 학생번호가 501인 학생은 데이터베이스 강좌를 수강할 것이고 그 수강료로 20000 원을 지불하기로 되어 있다. 이 때, 이행적 종속이 테이블에 존재한다면 501 학생이 수강할 강좌를 스포츠경영학으로 변경할 경우, 스포츠경영학 강좌를 20000 원에 수강하게 된다. 물론 강좌가 변경됨에 따라 수강료 컬럼도 변경할 수 있지만, 한 컬럼의 데이터를 수정함으로 인해 다른 컬럼까지 같이 수정을 하게 되는 번거로움을 해결하기 위해 제 3 정규화를 진행하는 것이다.

즉, 학생 번호를 통해 강좌 이름을 참조하고, 강좌 이름으로 수강료를 참조하도록 테이블을 분해해야 하며 그 결과로 분해한 테이블은 다음과 같다.

BCNF 정규화

BCNF 정규화란, 제 3 정규화를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록 테이블을 분해하는 것이다. 여기서 결정자란, A → B 를 만족하는 A 를 의미한다. 예를 들어, 다음과 같이 특강 수강 정보에 대한 테이블이 있다고 하자.

위의 테이블에서 기본키는 {학생번호, 특강이름} 이다. 그리고 기본키 {학생번호, 특강이름} 은 교수를 결정하고 있다. 또한 여기서 교수는 특강 이름을 결정한다.

여기서 문제는, 교수가 특강이름을 결정하는 결정자이지만 후보키는 아니라는 점이다. 그렇기 때문에 BCNF 정규형을 만족시키기 위해서는 위의 테이블을 분해해야 하고 다음과 같이 특강 신청 테이블과 특강 교수 테이블로 분해하면 BCNF 정규형을 만족시킬 수 있다.

#Reference.