1 1:1 관계

2 다:다 관계

3 병렬관계

4 식별자/비식별자 관계

5 순환관계

6 M:M 관계의 해결과 의미

1:1 관계는 1:다의 관계보다 더 통합에 힘을 써야 한다. 1:1 관계는 대부분 같은 개체집합의 다른 표현이 많이 있다. 또는 성능상의 이유(?)라는 명분으로 하나의 개체집합을 수직으로 분할한 경우이다.

통합의 대상은 포함관계(E1 ) E2)인지 파악한 후에 결정한다. 만약 포함관계라면 무조건 통합한다. 포함이라고 한다면 부분집합이지 서로 다른 개체가 아닌 것이다. 주의해야 할 것은 1:1 포함관계라도 1:다 관계가 될 수 있는지 파악하여야 한다는 것이다.

다:다 관계는 논리적으로 표현가능하나 물리적으로는 구현이 불가능하다. 다:다 관계는 비확정적이기 때문에 카테시안 곱이 된다. 그러므로 확정적으로 바꾸기 위해 2개의 1:다 관계를 가지는 집합으로 확장하여 다:다 관계를 해소해야 한다.
그렇다면 언제 다:다 관계를 해소해야 할까? 무조건 다:다 관계를 해소하여 2개의 1:다 관계를 만들면 모델이 복잡해 질 수 있다. 다:다 관계를 무조건 해소하면 하나의 개체집합이 만들어지는데 이는 관계개체집합이라고 한다. 다:다 관계의 해소는 관계개체집합이 자식 개체집합을 가져야 하는 작업을 진행할 경우에 해소한다. 즉, 필요한 경우에만 다:다 관계를 해소시키라는 것이다. 나머지는 나중에 모델이 거의 완성되어 갈 즈음에 해소 늦지 않다. 다음의 예를 보고 이해를 돕도록 하자.

“고객”과 “상품” 사이에 관계가 존재한다. “주문”은 중심개체집합으로 “고객”과 “상품”의 관계개체집합이다. “주문”은 “주문내역” 이라는 자식 개체집합을 가져야 한다. 그러므로 다:다 관계를 해소하였다.

“주문내역”의 경우 다른 개체집합과 관계를 가져야 하므로 생겨난 것이다.

병렬 관계란 두 개체집합 사이에 두 개 이상의 관계를 가지는 것을 의미한다. 아래의 그림과 같이 두 개의 관계를 가진 것을 병렬 관계라고 한다. 아래의 ERD는 절대 잘못된 것은 아니며, 물리적으로 어떻게 표현되어야 합당한지는 모델러가 판단해야 할 중요한 문제이다.

위의 ERD는 아래의 그림처럼 물리적으로 표현될 것이다. 실제로 아래의 우측 테이블의 “정비책임자”, “조작책임자”의 경우는 “사원번호”와 이음동의어이다.

그러나 이와 같은 모델은 현실을 잘 반영하고는 있지만 많은 경우에 불리하다. 일단 테이블로 변환되면 컬럼의 수가 증가하게 된다. 이는 인덱스의 수가 증가하게 될 가능성도 내포하고 있다. 또한 SQL문이 복잡해지고, 새로운 관계의 추가 및 변경에 약하다. 또한 자식 개체집합을 가질 수 없는 단점도 있다. 이러한 단점을 극복하기 위해서 다음과 같이 관계를 통합하게 되면 거의 대부분의 문제는 해결된다. 성능과 유연성에서 항상 유심히 판단해야 하는 것은 모델러의 숙명이다.

역시 강조하는 것은 유연성과 쉬운 SQL문이 나온다는 것이다. 관계가 값으로 표현되어 있어, 새로운 관계의 추가나 변경에 매우 쉽다. 또한 인덱스 수가 감소하여 관리해야 할 개체수가 줄어든다. 또한 자식개체집합을 가질 수 있어 모델이 더욱 확장될 수 있다. 하지만 무리하게 통합하여 자칫하면 의미가 희석될 수 있으니 주의하여야 한다.
또한 위 2가지 방법을 섞는 방법도 있다. 아래의 그림을 보자.

“계약자”의 경우는 직렬관계로 가져가고, “피보험자”, “납입자”의 경우는 “보험관계자”로 관계를 통합한 예제이다. 주의할 점은 모델이 복잡해 질 수 있으니 주의해야 하는 것이다.

식별자 관계는 부모-자식 관계를 가지는 관계를 의미한다. 여기서 부모-자식 관계는 개체가 탄생할 때 직접적인 영향을 끼쳤는가에 대한 기준으로 판단한다. 물리적으로 표현되었을 때 부모개체집합의 식별자가 자식개체집합의 식별자에 참여하는 관계를 의미한다. 아래의 그림을 보면 첫 번째 그림은 모두 비식별자 관계를 맺은 것이고, 두 번째 그림의 경우는 모두 식별자 관계를 가진 것이다.

고려해야 할 점은 다음과 같다.

• 어느 레벨에서 식별자 관계를 멈출 것인가?
  
• 물리적인 고려(Create Index)에 대한 고려도 해야 한다.
  
• 업무적인 이유와 엔터티 집합의 개념에 따라 판단
  
  

만약 첫 번째 그림에서 G개체집합이 A개체집합에 접근을 매우 빈번하게 한다면 A와 G는 관계를 가질 수도 있다. 이는 관계의 비정규화로 관계가 중복된 것을 의미한다.

순환관계는 다음과 같이 표현된다. 첫 번째와 같은 경우는 계층형 구조이지만 중복된 것이 없다. 하지만 두 번째 그림의 경우는 여러 개의 부품이 모여 하나의 또 다른 부품이 되는 BOM구조이다. 그러므로 모델링을 하게 되면 오른쪽과 같은 그림이 된다. 두 번째 그림의 경우는 다:다 관계이므로 적절한 시기에 이를 해소해야 한다.

다:다 관계는 해소해야 하는 이유는 뭘까? 대부분의 서적에서는 '다:다 관계를 해소해야 한다' 또는 '물리적으로 구현 불가하다'라고만 나오고 그 이유를 설명하지 않고 있다. 이제부터 다:다 관계를 해소해야 하는 이유를 설명하고, 그 의미를 살펴보도록 하자. 다음과 같이 고객과 상품은 다:다의 관계를 가지고 있다.

• 각각의 고객은 한 개 이상의 상품을 주문할 수 있다.
  
• 각각의 상품은 한명 이상의 고객으로부터 주문받을 수 있다.
  
  

실제로 다:다의 관계는 다음과 같이 표현될 수 있다. 물론 해당 조직에 따라서 카디널리티는 달라질 수 있다.

즉, 위와 같은 의미는 한 명의 고객이 여러 개의 상품을 주문할 수 있다는 것이다. 그것은 고객번호 하나가 상품번호를 모두 주문할 수 있고, 하나의 상품은 모든 고객이 주문할 수 있다는 것이 된다. 이 관계에서 어떤 고객이 어떤 상품을 주문했는지 모두 보여달라는 요청을 했다면 실제 구현되는 DBMS는 Cross Join (카테시안곱, 데카르트곱)이 된다. 그러므로 실제 필요없는 데이터까지도 비교를 하여 판단해야 한다. 대부분 이러한 개체집합은 많은 트랜잭션이 집중된다. 만약 이런 식으로 계속 트랜잭션이 집중이 된다면 시스템은 카테시안곱에 나가 떨어질 것이다. 그러므로 어떤 서적에서는 DBMS가 지원을 하지 못해서라는 이유를 들고 끝나버리고 말았다. 실제로 다:다 관계를 해결하기 위해서는 관계개체집합을 만들어야 한다. 다음은 다:다 관계를 해소한 것이다.

그러면 모델링시에는 언제 다:다 관계를 해소할 것인가? 그 시기가 문제가 된다. 만약 다:다 관계를 초기해 해소하게 되면, 데이터 모델이 복잡해진다. 데이터 모델은 의사소통의 도구 역할을 해야하므로 처음부터 복잡해서는 안 된다. 그러므로 복잡성에 빠지지 않기 위해서는 다:다 관계의 해소를 위한 기준이 필요하다. 물론 다:다 관계를 언젠가는 해소시켜야 한다. 그래서 다:다 관계의 해소 시키는 다음과 같이 권장된다.

다:다 관계의 해소는 정규화 이후에 하되, 만약 키개체집합과 중심개체집합을 도출하는 과정에서 다:다 관계를 해소해야 나타나는 관계개체집합의 하위 집합이 나올 경우이다.