릴레이션 직교성

직교성은 여러 개의 릴레이션 사이의 중복에 관한 개념이다. 즉 DB 전체에서 중복을 제거하는 작업이다. 각 릴레이션에서 중복을 제거해도 DB 전체를 볼 때 중복이 남아 있다면 결국 불일치의 원인이 된다. 

직교란 두 개 이상의 릴레이션이 같은 값을 갖지 않는 상태이다. 

 

1. 같은 값을 가진 릴레이션

레플리카 

완전히 같은 구조와 같은 데이터를 가진 릴레이션이 여러 개 있는 경우. 즉 DB를 복제하여 사용하는 경우 

 

같은 형태의 릴레이션 

예를 들어보면 특정 데이터를 2000년~ 2020년의 데이터를 1년마다 다른 릴레이션에 저장하는 경우, 제목이 완전히 같은 릴레이션은 분명 의미도 같은 것이라고 생각하기 때문에 같은 값을 가질 수 있다. 이때 같은 값을 가지고 있다면 중복되므로 모순이 발생한다. 

 

제목 일부만 같은 릴레이션 

말 그래도 완전히 같지는 않지만 일부가 공통일 때, 중복이라고 봐야하는가를 생각해봐야한다. 이렇게 릴레이션에 명백하지 않은 함수 종속성이나 암시적이지 않은 결합 종속성이 존재하면 릴레이션을 직접 비교하는 것만으로는 직교하고 있는지 아닌지 알 수 없다. 그래서 6NF가 필요하다. 

 모든 릴레이션을 6NF가 될 때까지 무손실 분해하고 튜플을 비교해 중복이 없는 것을 확인하면 직교성을 보장할 수 있다. 

직접 JOIN해보면서 중복이 있는지 확인해보자 

 

이름	학년	클럽
KWW	1	검도

이름	학과	학년
KWW	SW	1

이 경우 {이름, 학년}이 겹친다. 이럴 때 나눠줘야한다. 

이름	학년
KWW	1

이름	학과
KWW	SW

이름	클럽
KWW	검도

 

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

정규화

직교성을 확인하려면 6NF까지 정규화를 하면 된다. 실무에서 실제 DB 설계 시에는 5NF까지 정규화 하면 충분하다. 그러나 6NF를 활용하려면 5NF까지 정규화 하는 것이 중요하다. 

정규화를 제대로 해두면 단지 릴레이션 그 자체를 다루기 쉬울 뿐만 아니라 직교성을 확인할 때도 도움이 된다.

 

속성(칼럼)의 이름 통일하기

같은 의미의 속성인데 이름이 다르다면 같은지 알 수 없으니 꼭 통일해 놓자. 반대로 의미가 다른대 같은 이름을 사용할 때도 문제가 된다. 

속성을 어떻게 명명해야 좋을지는 사실 꽤 깊은 주제다. 자세하게는 아니지만 간단히 2개를 소개하면

1. 명명규칙 통일하기  : 한국어, 알파벳, 로마자, 영어 무엇을 사용할지 일괄적으로 정하기 
2. 주어를 포함하기 : 압도적으로 많은 사용하는 것 id 그러나 이것은 좋은 것은 아님. 어떤 id를 나타내는지 알 수 없다. 구체적인 의미를 포함한 이름으로 사용하자. Blog_id, Blog_honer, Blog_pw 등등

응용 프로그램의 정합성 

직교하지 않은 릴레이션은 대부분 응용프로그램의 설계상 문제가 발생. 다른 두 가지의 기능에 같은 의미의 데이터가 필요할 때는 공통의 구성 요소를 설계하는 대신에 각 독립된 DB에 테이터를 등록하면 직교하지 않는 DB가 완성됨.
(Ex. mysql, firebase)

 

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

각각의 A, B가 나타내는 조건의 의미가 완전히 독립적이라면 특별히 설계상의 문제는 없다. 완전히 독립적인 두 테이블이 나타내는 조건에 맞을 때 사용하고 싶을 때도 있을 것이기 때문이다. 즉 릴레이셩은 집합이므로 교집합과 합집합으로 연산하고 싶을 때가 있을 것이다. 이와 같은 연산 자체는 중복된 데이터가 서로의 릴레이션에 포함돼 있어도 문제가 되지 않는다. 

 

3. 중복을 해결해 얻는 이점 

1. 변칙을 막을 수 있다. 
2. 필요한 데이터가 어디 있는지 명확해진다.
3. 쿼리의 작성이 선언적이 된다. -> Why 형식으로 작업이 되므로 생산성이 크게 증가 
4. 불필요한 무손실 분해는 필요없다. -> 서브쿼리가 만들어지면서 복잡해지고 효율적이지 못함 
5. 복잡한 제약은 필요없다. 
   1. 정규화와 직교화가 완료되지 않은 경우 갱신하더라도 변칙이 생기지 않게 하려면 제약을 걸어야 한다. 그런데 이러한 제약은 단순하게 작성할 수 없다. 
6. 응용프로그램의 코드에 낭비가 없어진다. : DB 설계쌍의 문제를 응용프로그램이 가져갈 때의 비용은 상상 이상이다.
7. 성능이 향상된다. : 메모리 뿐만 아니라 데이터 조작에 대한 낭비가 없어진다. 

 

요약 .

DB의 중복을 해결하지 않고 RDB를 사용하는 것은 그 본래의 성능을 포기하는 것, 즉 도구의 사용 방법을 잘못 알고 있어서 마치 테니스 라켓으로 탁구를 하는 것과 동일하게 비효율적이다. 쿼리의 효율이라는 관점에서도, 프로그래밍의 효율이라는 관점에서도 중복을 해결하지 않는 것은 현명한 선택이라고 할 수 없다.