릴레이션의 직교성

정규화가 릴레이션 내부의 중복을 없애는 작업이라면, 직교성은 여러 개 릴레이션 사이의 중복에 관한 개념이다.

릴레이션의 직교성과 중복

릴레이션의 직교성이란 같은 값을 갖지 않는 것이다. 같은 값들을 가진 릴레이션이란 어떤 것인가?

레플리카

완전히 같은 구조와 같은 데이터를 가진 릴레이션이 여러 개 있는 경우다. 실제로는 이러한 릴레이션을 접할 일은 별로 없겠지만 이러한 구조는 매우 모순적이고 낭비이므로 여러개가 있다면 어느 하나만 사용하는 것이 좋을 것이다.

같은 형태의 릴레이션

직교란 두 개 이상의 릴레이션이 같은 값을 갖지 않는 상태를 말한다. 이 릴레이션은 서로 같은 제목을 갖는다. 그러나 튜플 값은 서로 다른 것을 가지는 의미를 가지지만, 릴레이션의 의미도 같은 것이라고 생각하기 때문에 같은 값을 가질 수 있다. 완전히 다른 데이터만 가진다라는 보장이 없다면 이러한 구조는 좋지 않다. 해결책으로 트리거 사용이 있다.

제목 일부만 같은 릴레이션

제목이 완전히 같은 경우와 다르게 일부만 같은 경우의 직교성을 갖지 않는 경우이다. 이 경우 직교성을 찾는 방법은 6NF가 될 때까지 무손실 분해 후 튜플을 비교해 중복이 없는 것을 확인하면 직교성을 보장할 수 있다. 6NF까지 분해 후 릴레이션에 중복이 없으면 통합할 필요가 없다.

릴레이션 직교화를 위한 전략

정규화

DB설계시에는 릴레이션을 5NF까지 정규화하면 충분하다. 그러면 이후에 직교성을 확인할 때 6NF로 무손실 분해가 가능하므로 직교성 확인이 수월해진다.

속성의 이름 통일하기

같은 의미의 속성인데 이름이 다르다면 같은 의미인지 확실하게 알기 어려워진다. 또한 다른 의미인데 같은 이름을 사용해도 문제가 된다.

명명규칙 통일하기

한국어로 할지, 영어로 할지, CAMEL CASE를 할지, SNAKE CASE를 할지 일괄적으로 정해야한다.

주어를 포함한다

id는 흔히 사용하는 칼럼명이지만 좋은 이름은 아니다. name, email 등도 좋은 이름은아니며 정확하게 student_name, employee_email 등 주어를 명확히 하는것이 좋다.

응용프로그램의 정합성

직교하지 않은 릴레이션은 응용프로그램 설계상 문제가 발생한다. 다른 두 가지의 기능에 같은 의미의 데이터가 필요할 때는 공통의 구성 요소를 설계하는 대신에 각 독립된 DB에 데이터를 등록하면 직교하지 않는 DB가 완성된다. 이 경우는 응용프로그램의 규모가 점점 커질수록 발생한다.

공통의 데이터가 필요한 경우 응용 프로그램 쪽의 코드도 공유할 수 있게 리팩토링을 수행해야 한다. 이렇게 하면 DB뿐만 아니라 응용프로그램쪽의 유지보수도 편해진다.

전체를 직교화할 필요는 없다

직교화는 db설계에 중요한 개념이지만 모든 릴레이션을 직교화할 필요는 없다. 예를 들어 조건에 따라서 A또는 B테이블에 데이터를 등록하는 경우 A, B가 각기 나타내는 조건의 의미가 다르면 설계상 문제는 없다.

중복을 해결해 얻는 이점

변칙을 막을 수 있다

가장 큰 이점이다. 변칙이란 DB에 포함된 모순, 상반된 사실을 나타내는 명제가 포함된 것을 의마한다.

전제에 모순이 포함돼 있으면 연산으로 도출되는 새로운 사실의 정확성을 보증할 수 없다. 나는 DB에서 학생에 대한 정보를 원하는데 아직 진학하지 않은 미취학 아동의 정보가 나오는 것과 같은 문제가 발생하지 않는다는 것이다.

필요한 데이터가 어디에 있는지 명확해진다

중복이 해결되면 한 개의 튜플이 나타내는 사실은 다른 어떤 튜플에도 존재하지 않는다. 따라서 어떤 사실에 관해 안다면 질의해야 할 대상이 명확해진다.

필요한 데이터가 어디에 있는지 명확하다면 데이터를 갱신할 때도 어느 튜플을 갱신하면 좋은지 명확하다는 장점이 있다. 중복이 없다면 참조, 갱신 어떤 경우도 헤매지 않고 쿼리를 작성할 수 있다.

쿼리의 작성이 선언적이 된다

모든 테이블이 1NF가 되어 있다면 관계형 모델을 기반으로 쿼리를 작성할 수 있다. 술어논리적으로 어떤 데이터가 필요한지 정의할 수 있다는 의미이다.

불필요한 무손실 분해는 필요없다

정규화 되어있지 않는 테이블은 원하는 데이터를 얻기위해 복잡한 쿼리를 거친다. 정규화를 한다면 특정 데이터를 뽑아내기 위한 서브쿼리를 사용할 일이 적어져 쿼리를 단순화 할 수 있다.

복잡한 제약은 필요없다

정규화와 직교화가 완료되지 않은 경우에 갱신하더라도 변칙이 생기지않게 하려면 제약을 걸어야 한다. 이러한 제약은 단순하게 작성할 수 없다.

응용프로그램의 코드에 낭비가 없어진다

중복을 해결하지 않은 DB를 사용할 경우, 문제가 발생하는 부분은 응용 프로그램에서 처리하도록 할 수 있다. 하지만 매번 응용프로그램에서 처리하게 된다면 코드 역시 중복되는 작업이 많을 것이고, 생각보다 더 어려운 작업이다.

성능이 향상된다

결합에 대한 비용은 늘어날지는 모르겠지만 불필요한 무손실 분해에 대한 비용은 줄어들게 된다. 전체적으로 보면 중복을 제거하는 편이 낭비를 최소화 한다.