KOMAS

[데이터베이스] SQL 순서 (문법과 실행 순서)

SQL 문법 순서

• SELECT
• FROM
• JOIN
• WHERE
• GROUP BY
• HAVING
• ORDER BY

SQL 실행 순서

• FROM
• JOIN
• WHERE
• GROUP BY
• HAVING
• SELECT
• ORDER BY

DISTINCT, ORDER BY, LIMIT 등 을 제외하면 SELECT의 실행은 최종적으로 이루어진다.

JOIN으로 테이블을 결합하고, WHERE 조건을 적용, 그룹화를 진행한다.

그후 형성된 테이블을 SELECT 한다.

[데이터베이스] 보이스 코드 정규형 BCNF

데이터베이스의 정규화를 공부 중 보이스 코드 정규형의 이해가 쉽지 않았어서 정리하고자 글을 작성합니다.

우선 보이스 코드 정규형의 정의는 이렇습니다.

모든 결정자가 후보키(유일, 최소)여야 한다.

일단 결정자라 함은 릴레이션 내에서 다른 속성을 결정할 수 있는 것입니다.

예를 들면 (이름, 주민등록번호)로 구성된 릴레이션이 있다고 했을 때, 이름 속성은 동명이인이 있을 수 있으므로 주민등록번호 속성을 결정하지 못합니다.

하지만 주민등록번호 속성은 릴레이션에서 유일하기 때문에 이름 속성을 결정할 수 있습니다.

이렇게 한 속성이 다른 속성을 유일하게 결정할 수 있을 때 결정자라 합니다.

자연스럽게 이름은 주민등록번호의 종속자가 됩니다.

* 주민등록번호(결정자) -> 이름(종속자)

이러한 결정자의 역할을 주로 하는 것은 보통 기본키라고 할 수 있습니다.

하지만 보이스 코드 정규형에서 문제가 되는 부분은 이러한 결정자의 역할을 할 수 있는 속성이 후보키가 아니란 말입니다.

후보키라는 것은 유일성과 최소성을 갖습니다. 유일성은 릴레이션 내에서 유일하다는 것이고, 최소성은 최소 집합 관계로 키를 구성하는 것을 말합니다.

다시 보이스 코드 정규형 정의로 돌아가서 보면, 결정자인데 후보키(유일성, 최소성)를 만족하지 못하고 있는 것입니다.

이 말은 릴레이션에서 결정자 속성이 다른 속성을 결정할 수 있음에도 튜플로 여러 번 등장한다는 말입니다.

그리고 이러한 결정자가 결정하는 속성인 종속자가 기본키의 부분 집합인 경우 이를 제거해야 합니다.

학번과 과목이 기본키로 설정돼있고 한명의 교수는 한개의 과목을 가르친다고 가정했을 시 교수 속성은 결정자입니다.

결정자 -> 종속자

브라운 -> 데이터 베이스

블랙 -> 데이터 베이스

레드 -> 정보 보안

현재 교수만 알면 과목을 알 수 있습니다. 교수 속성은 결정자입니다.

하지만 결정자인데도 불구하고 교수 속성은 현재 후보키가 아닙니다. (유일성을 만족하지 않는다.)

한 릴레이션 내에서 튜플로 2번 등장했기 때문입니다. (브라운)

후보키의 조건인 유일성을 만족시키지 않습니다. 

교수 결정자 속성의 종속자는 과목 속성입니다.

현재 종속자인 과목은 기본키의 부분집합이므로 이 부분을 제거해주어야 합니다.

결국 이러한 릴레이션은 보이스 코드 정규형을 적용시켜야 하는 조건을 만족합니다. 

무손실 분해

한 릴레이션을 분리했을 때 R1, R2 두가지 릴레이션이 나오게 됩니다.

이때 R1, R2 를 교집합 했을 때 나오는 값은 R1의 키 이거나, R2의 키여야 합니다.

(학번,과목), (교수, 과목) 은 교집합의 결과가 과목이고, 과목은 한쪽의 키가 아니기 때문에 무손실 분해가 아닙니다.

보이스 코드 정규화를 적용하여 무손실 분해 결과로 분리된 테이블은

(학번,교수) , (교수, 과목)가 됩니다.

(학번,교수), (교수, 과목) 은 교집합의 결과가 교수이고, 교수는 한쪽 테이블의 기본키이기 때문의 무손실 분해입니다.

REF. 키의 종류

슈퍼키 : 유일하게 식별, 단위는 최소가 아니어도 된다.

후보키 : 유일하게 식별, 최소 단위여야 한다.

기본키 : 후보키 중 선정된 키

대체키 : 기본키로 선정되지 않은 후보키

대리키 : 가상의 키

외래키 : 다른 릴레이션의 기본키를 참조