1 관계 카테고리

2 개체에 대한 개념의 범위를 한정(역할과 책임)짓는 관계

3 개체의 상호작용에 의한 관계

4 부모-자식 관계

5 형이상학 실재적론의 고찰

6 참고

관계는 다음의 3가지 중 하나다.

• 개체에 대한 개념의 범위를 한정(역할과 책임, 코드, 단방향 참조)
  
• 개체간의 상호작용 결과(양방향 참조)
  
• 부모-자식 관계(개체의 탄생의 순서, 존재종속관계, 순서쌍)
  
  

이 관계는 개체에 대한 개념의 범위를 한정(역할과 책임) 관계다. 관계가 있냐 없냐를 따졌을 때, 관계가 있다면 그 관계가 강한지 약한지를 나타낸다. 강/약은 Mandatory 또는 Optional이라고만 표현하는데, 위의 예제처럼 꼭 Mandatory라고 하여 반드시 부서가 먼저 존재해야만 사원이 존재할 수 있다는 의미가 아니다. 예를 들어, 사원 "이재학"의 소속부서가 "BI팀"이라 가정해보자. "이재학"이 사원 테이블에 입력되러면 반드시 "BI팀"이 부서 테이블에 먼저 입력되어야 한다. 이 관계는 DBMS의 외래키 제약조건이지 탄생의 순서에 의한 것이 아니다. 부서와 사원 관계가 Mandatory라면 이는 관계가 강한 것이고, Optinal이라면 관계가 약한 것이다. "이재학"이 "BI"팀이라는 것은 "이재학"이 존재하는 이유에 대해 설명해 준다. 즉, "이재학"이라는 사원이 할 수 있는 일은 "BI팀"에서 담당하는 업무의 범위에 한정된다. 즉, "BI팀"의 카테고리에 속하게 된다. "oo코드"라는 코드성 테이블들도 범위를 한정한다.

"주문"은 "고객"과 "상품"과의 상호작용에 의해 생겨난 개체집합이다. 표현하기에 따라 "고객"과 "상품"의 다:다 관계다. 여기에서의 Mandatory는 탄생의 순서와도 관련이 있다. "고객"과 "상품" 중 1개라도 없다면 상호작용은 있을 수 없다. "고객"과 "상품"의 상호작용에 의해 기존에 없던 "주문"이 생겼다. 이것은 무엇을 의미하는가? 바로 시너지(synergy) 즉, 시스템 에너지(system energy)다. 시너지는 1+1 = 2 가 아닌 2 이상을 의미한다. 이게 개체집합과 개체집합의 관계에 의해 만들어진 정보 창출 능력이다.

말 그대로 부모/자식의 관계다. "서브타입(부분집합)"이나 "약 개체집합"이 이에 속한다. 개체에 대한 이력관리 테이블들이 부모/자식의 관계다. 위의 부분집합은 물리적으로 구현하면 다음과 같은 모양이 될 것이다. (대략 이런 모델이다. 상황에 따라서 모양은 달라질 수 있다.)

식별자 관계 or 비식별자 관계 불리는 논리 모델의 명칭으로 부모-자식 관계를 나누는 것이 아닌 실제 세계에서 부모-자식의 관계여야만 부모-자식 관계다. 대부분은 식별자 관계를 부모-자식 관계라고 봐도 되지만, 부모-자식 관계가 아님에도 불구하고 식별자 관계로 논리 모델을 표현해 놓을 수도 있으니 AS-IS 시스템에서 관계를 파악할 때에 주의해야 한다.

실재론에서는 플라톤이건 아리스토텔레스건 보편자(universal)의 속성(properties), 관계(relations), 종(kinds)찾는 것을 기본으로 한다. 특히나 보편자에 대해서는 '속성일치'를 찾는다. 요즘에는 '부서번호'와 같은 외부키를 '관계속성'이라고 많이 부른다. 이는 잘못된 것이라 생각된다. 사원은 소속된 부서가 없이도 존재할 수 있다. 물론 부서도 그 자체로 존재가능하다. 이 글을 보는 사람이 사원이라면 주위의 다른 부서나 팀 사람들을 보라. 부서딱지를 떼어내도 그들은 사원이다.

* 시간에 대한 형이상학적 고찰을 하지 않은 상태에서 쓴 글이므로 참고만 하세요. 좀 더 생각해봐야 합니다. --2011-04-18

오동규씨의 관계선을 함부로 긋는 이유(http://scidb.tistory.com/149)를 보면 위 그림의 사원의 '부서번호(FK)'가 '발령이력'이 원천임을 말하고 있지만, 난 견해가 다르다. 시간이 실재한다는 가정하에서 '이력'은 '관계'와 '시간'의 또 다른 '관계'다. 시간이 없다면 발령이력도 없다. 왜냐하면 본질적인 식별자에 시간의 개념이 포함되어야 하기 때문이다.

오동규씨는 너무 지나치게 파고 들어간게 아닌가 싶다. 천 년, 만 년이 지나도 1:다 관계를 유지하리라는 보장은 없다. 그러므로 이 글의 논리로는 1:다의 관계는 모두 다:다의 관계가 되어야 한다. 또한 이 논리라면 모든 속성도 단일값이 아닌 다중값이 되어야 한다. 결국은 요구사항의 범위에 대한 차이다. 모델러가 이력관리를 할지 말지를 결정하는 것이 아니다. 어떤 논리를 들이대도 애매한 것은 마찬가지이므로 이 의사결정이 쉽게 하자 말자를 결정될 수 없다.

사원과 부서사이의 관계를 현재만 관리할 것인가 과거도 관리할 것인가에 대한 요구사항범위의 차이일 뿐이지 '발령이력'이 맞다 또는 '현소속부서로서'가 맞다 틀리다를 따지는 것은 무의미하다고 본다. 중요한 것은 사원과 부서의 존재이유다. 또한 관계의 이력을 관리하면 요구사항의 범위가 늘어난다. 돈이 많이 들어간다는 것이다. 필요없는 군더더기는 복잡성을 유발한다. 이것은 곧 비용이다. 즉, 자원 투하의 의지에 따라서 모델은 변한다.

안녕하세요. 오동규 입니다. 제 글에 대한 오해가 있네요.
제가 블로그에서 말씀드린 것은 '모든것을 관계의 이력으로 관리해야한다' 가 아닙니다.
제가 블로그에서 말씀드린 것은 '역정규화는 논리모델링에서 하지말고 물리모델링 단계에서 해라' 입니다.
심지어 개념모델단계에서 부터 마지막값을 역정규화하여 속성으로 관리하더군요. -- 오동규 2014-03-07 13:41:43

그렇군요. 제가 봉황의 뜻을 헤아리지 못했네요. 지금보니 제가 쓴 글도 생각하다 말았네요. -- 이재학 2014-03-07 20:53:01