5. 릴레이션의 직교성

직교성이란?
직교화전략

 

이전까지는 하나의 릴레이션 안에서 발생할 수 있는 중복에 대해 설명하였다. 이번장에서는 여러 개의 릴레이션간에 발생할 수 있는 중복의 경우와 그 해결방법에 대해 알아보자.

1. 직교성이란?

직교란, 두 개 이상의 릴레이션이 같은 값을 갖지 않는 상태를 말한다. 그렇다면 같은 값을 가진 릴레이션의 경우들과 그 해결방법에 대해 알아보자.

 

CASE 1.

두 릴레이션이 모두 동일한 속성을 가지고 있더라도 그 안에 들어가는 튜플의 값이 모두 다르면 해당 릴레이션들은 직교한다.

이때 속성들 간에 같은 값을 가지고 있는지 여부는 JOIN을 이용하면 쉽게 파악이 가능하다. 같은 값이 없다면 공집합이 출력되기 때문이다.

 

CASE 2.

두 릴레이션의 일부 속성이 일치하고 해당 속성의 튜플 값들이 일치할때 직교성 여부를 판단하기 어려울 수 있다. 그런 경우엔 앞에서 설명한 정규화 6NF를 이용한다. 6NF 단계는 더 이상 무손실 분해가 불가하므로 튜플값들의 부분에 대해 염두할 필요가 없다. 따라서 모든 릴레이션을 6NF까지 무손실 분해한 후 튜플을 비교해 중복의 여부를 판단한다. 아래 예시를 보자

• 위 두 릴레이션은 중복된 속성과 중복된 튜플값으로 직교하지 않는다.
• 두 릴레이션을 각각 6NF까지 분해한 후 중복하는 릴레이션을 통합한다.

직교화 전략

1. 정규화

• 위의 예제에서 사용한 6NF까지 정규화하여 중복을 확인한다.

2. 속성 이름 통일하기

속성명을 통일화하는 것은 직교화 전략의 주요한 포인트이다.

같은 의미의 속성인데도 릴레이션마다 이름이 다르면 속성의 일치 여부를 확인하기 어렵다. 또는 다른 의미의 속성을 동일한 이름으로 하는 경우도 릴레이션의 직교화에 혼선을 줄 수 있다. 속성 이름을 통일하기 위한 전략은 다음과 같다.

• 명명규칙을 만든다 : 한국어, 알파벳, 캐멀 케이스, 스네이크 케이스 등  명명규칙을 정하고 DB설계를 할 때 동일하게 적용한다.
• 주어를 만든다 : id, name, email, qty 등 범용적으로 사용되는 명칭에 주어를 포함하여 구분한다. (user_id, order_qty)
• DB와 애플리케이션의 상호보완성 : 직교하지 않는 DB는 어플리케이션을 잘못 설계하면 발생할 수 있다. 어플리케이션 안에서 다른 기능을 수행할 때 같은 데이터가 필요한 경우, 릴레이션을 각각 만드는 게 아니라 통합해서 설계해야 한다.

---

지금까지 정규화와 직교성을 통해서 DB의 중복을 해결하는 방법을 살펴보았다. 중복을 배제했을 때 얻는 이점을 다시 한번 정리해보자.

1. 변칙을 막을 수 있다.

데이터의 모순으로 문제가 발생했을 때의 현상을 변칙이라고 한다고 했다. 모순이 있는 경우 DB가 질의를 받았을 때 올바른 결과를 반환할 수 없다. 중복을 없애면 이러한 문제를 해결 가능하다.

2. 쿼리 작성이 간결해진다.

중복이 해결되면 특정값은 특정 튜플에만 속하게 된다. 필요한 데이터가 어디에 있는지 명확하게 안다면 헤매지 않고 쿼리를 작성할 수 있게 된다. 따라서 "어떻게 데이터를 찾을까?" 하는 고민 없이 "어떤 데이터가 필요한가?"를 기반으로 쿼리를 작성할 수 있고 프로그래밍의 생산성을 높일 수 있다. 아래 예시를 보자.

• 위와 같이 정규화가 되지 않은 테이블이 있다. 여기서 <Ruby on Rails의 수업을 수강하고 있는 학생이 재학 중인 학과의 대표번호 목록>을 구하는 쿼리를 작성해보았다.

SELECT department, number FROM
(SELECT DISTINCT department FROM sys.student_school_class WHERE class = 'Ruby on Rails') t1
INNER JOIN
(SELECT distinct department, number FROM sys.student_school) t2
USING(department)

• 첫 번째 서브 쿼리에서 Ruby on Rails 수업을 수강하는 학생의 학과를 찾고 해당 테이블을 t1이라 명명한다.
• 두 번째 서브 쿼리에서 각 학과별 번호를 찾고 해당 테이블을 t2라 명명한다.
• 두 테이블의 department 속성값이 일치한 튜플끼리 조합하여 반환한다.

---

위 테이블을 {학과, 번호}, {학과, 수업} 테이블로 무손실 분해 후 같은 결과를 도출하기 위한 쿼리를 작성해 보았다.

SELECT department, number FROM sys.depart_num
INNER JOIN sys.depart_class USING (department)
WHERE class = 'Ruby on Rails'

 

같은 결과를 도출하는 쿼리문이 훨씬 간결해진 것을 확인할 수 있다. 쿼리가 간결해지면 데이터 조작에 대한 낭비가 줄어들고 결과적으로 애플리케이션의 성능이 향상된다.

---

지금까지 DB 설계시에 중복을 피하기 위한 정규화와 직교화 방법에 대해 알아보았다. DB의 중복을 해결하지 않고는 올바른 RDB를 사용한다고 할 수 없다. 데이터의 중복을 없애는 것은 DB 설계의 기본이다!