부서-사원 모델에 대한 단상

조회관계란 무엇인가
전달관계와 조회관계의 차이점


거의 모든 프로젝트 현장에서 위와 같은 잘못된 모델이 등장한다. 위의 부서-사원 모델에서 틀린 곳을 발견할 수 있는가? 잘못된 점을 발견하지 못했다면, 여러분도 잘못된 모델링을 하고 있을 가능성이 높다. 이 글은 부서와 사원 사이에 존재하는 관계선이 잘못되었다는 것을 이야기 하고자 한다.

 

어느 설계자가 논리모델링을 하고 있었다. 그가 작업중인 위의 모델을 보는 순간 기대를 했지만 역시나 실망했다. 왜냐하면 부서엔티티에서 사원엔티티로 관계선을 긋는 것을 보았기 때문이다. 부서와 사원은 가장 기본적인 엔티티 아닌가? 핵심엔티티임에도 불구하고 관계선을 마음 내키는 대로 긋고 있는 것이다. 그래서 내가 그 설계자에게 다음과 같이 질문을 하였다.

 

필자: 사원엔티티와 부서엔티티의 관계는 사원이 현재 소속된 부서를 의미합니까?

설계자: 네 당연히 사원의 현 소속부서를 의미합니다.

필자: 그렇다면 부서와 사원 사이에 관계선을 긋지 마시고, 그냥 부서코드속성을 추가하세요.

설계자: 왜요? 부서와 사원은 1:N 관계이므로, 당연히 그어야 되는 것 아닌가요?

 

설계자의 잘못이 아니다

그렇다. 당연히 그렇게 생각할 것이다. 모델링공부를 많이 한 사람일수록 반사적으로 부서와 사원 사이에 관계선을 그어 버린다. 잘못된 관행이 온 세상을 덮고 있다. 왜냐하면, 영문원서를 포함하여 거의 모든 국내의 모델링 책에 부서-사원관계를 그어버리는 잘못을 범했기 때문이다. 교과서가 잘못되어 있는데 학생이 제대로 된 사고를 할 수 있을까? 부서와 사원간에는 이런 식으로 관계를 맺으면 안 된다.

 

위의 모델이 잘못되었다는 것을 증명하려면 모델링에 대한 약간의 배경지식이 필요하다. 지금부터 설명되는 내용은 모델링의 기본이므로 반드시 알고 있어야 하는 것들이다.

 

관계의 방향

엔티티간의 관계선은 Role, Cardinality, 관계속성의null 여부, 그리고 데이터의 전달방향을 나타낸다. 물론 관계선에는 이런 개념 이외에도 중요한 개념이 더 있지만, 오늘은 모델링 책에 자주 언급되고 있지 않는 데이터의 흐름(전달)과 그 방향에 관해 논의해보자.

 

물은 중력의 법칙 때문에 위에서 밑으로 흐른다. 물의 흐름과 데이터의 흐름도 비슷하다. 집합끼리의 관계에 의해서 최상위 부모로부터 최하위 자식까지 데이터는 순차적으로 물 흐르듯 흘러간다. 다시 말해, 데이터의 방향은 부모로부터 자식으로 흘러가는 것이다. 이런 일이 가능한 이유는 관계속성 때문이다.

 

관계속성의 정의

관계선을 긋는 순간 자식엔티티에 부모의 식별자가 상속된다. ER-WIN이나 파워디자이너 등의 모델링 툴을 써본 사람이라면 관계선을 긋는 순간 자식엔티티에 부모식별자에 해당하는 속성이 생성됨을 알 것이다. 이를 관계속성이라 한다. 관계선이 데이터의 이동 통로라고 비유한다면, 관계속성은 이동된 데이터의 도착장소이다. 부모집합은 관계속성이 존재함으로써 자식에 데이터를 전달(연결)할 수 있다. 쉬운 말로 표현하면, 관계속성은 부모식별자의 데이터를 자식의 공간에 집어넣어, 두 집합간의 관계를 완성한다.

 

고객, 상품, 주문, 주문상품을 통하여 데이터가 어떻게 흘러가는지 살펴보자. 아래의 그림에서 FK라고 표시된 것이 관계속성이다. 각 엔티티의 상세한 속성이 더 존재하지만 편의상 몇 개씩만 나타내었다.




우리의 예상대로 고객-->주문 , 주문-->주문상품 , 상품-->주문상품으로 데이터가 흘러감을 직관적으로 알 수 있다. 모델링을 해본 사람이라면 지극히 당연하다고 생각 할 것이다. 관계속성이 존재함으로 데이터가 흘러간다는 규칙은 업무에 무관하게 적용되는 모델링의 기본 법칙이다

 

관계선을 그으면 안 되는 경우

데이터가 전달되지 않을 때는 관계선을 그으면 안 된다. 관계속성이 생성되기 때문이다. 관계속성이 있다는 것은 데이터를 전달하겠다는 의미인데, 데이터가 전달되지 않는 경우에는 관계속성이 필요 없다.

 

 "부모 식별자의 데이터가 자식으로 전달(이행)되는 경우만 관계선을 그어라."

 

위에서 보는 것처럼 이 글에서 언급한 관계선의 규칙은 매우 간단하다. 하지만 아주 쉽고, 당연한 규칙이라도 실무에서는 지켜지지 않는 경우가 많다. 도대체, 언제쯤 대부분의 설계자들이 모델링의 기본규칙을 지키는 날이 올까? 만약 그랬다면 이 글의 서두에서 언급한 대화는 일어나지 않을 것이다.

 

여기까지가 배경지식이다. 지금부터 이미 언급된 부서-사원간의 관계가 왜 잘못된 것인지 알아보자. 결론부터 이야기 하자면 위에서 언급한 관계선의 규칙에서 벗어나기 때문이다.

 

현 소속부서의 함정

내가 본 많은 수의 부서-사원 모델은 관계명에현 소속부서로서가 명시되어 있다. 현 소속부서로서? 현 소속부서라는 것은 논리적으로 존재할 수 없다. 현 소속부서가 존재한다면 그것은 발령의 마지막 값을 물리적으로 역정규화 한 것이다.

 

관계선의 검증방법

관계선은 업무규칙을 나타내기도 하지만 데이터집합의 원천을 표시하는 용도가 있다. 즉 부서와 사원 사이에 관계선을 그렸다면, 사원엔티티의 부서코드 값들은 부서엔티티로부터 온 것인가? 라고 검증해보아야 한다. 실제로 부서와 사원의 관계선을 검증해보면, 사원의 부서코드는 부서집합으로부터 온 것이 아니다.. 인사시스템의 발령에서 사원의 부서코드로 데이터가 insert 혹은 update된다. 인사시스템의 발령이 데이터의 원천이므로 부서와 사원은 아무런 관계가 없다. 따라서 관계선을 삭제해야 하며 아래와 같이 나타내야 한다.

 



위의 그림은 인사시스템의 모델이다. 물론 발령에는 직무코드, 직위코드와 관련된 추가적인 관계가 존재한다. 하지만 부서와 사원에 집중하기 위해 생략하였다. 위의 모델에서는 당연하게도, 부서와 사원은 관계선이 없다. 즉 현 소속부서라는 집합은 인사발령에서 사원 별로 가장 최근 값만 추출한 것이다. 그럼 인사시스템이 아닌 다른 시스템이라면 어떻게 될까? 아래의 모델을 보자.

 

인사시스템이 아닌 타 시스템이라면 인사시스템의 부서와 사원테이블을 1:1로 중복시켜 놓을 것이다. 관계선에 D라고 표시한 것은 추출관계를 나타낸 것이다. 부서코드, 직위코드, 직무코드는 인사시스템의-발령엔티티에서 역정규화 된 것임을 알 수 있다. 가끔 인사시스템에서 부서코드, 직위코드, 직무코드를 미리 역정규화 해놓는 경우도 있다. 미리 역정규화 해놓은 것을 타시스템으로 1:1 Copy 해도 역정규화 되었다는 사실은 변하지 않는다위의 모델을 자세히 보아도 부서와 사원은 아무런 관계가 없음을 알 수 있다.

 

부서와 사원간의 FK는 필요 없다

부서와 사원간에 FK를 생성하려는 사람이 있다. 부서와 사원간에 FK에 의한 참조무결성은 쓸모가 없다. 데이터가 부모에서 자식으로 전달될 때, 올바른 값으로 전달(insert 혹은 update) 되었는지 체크하는 것이 참조무결성이다. 그런데 부서-사원간의 관계에서는 부모인 부서로부터 자식으로 데이터가 이행되지 않는다. 오히려 사원의 자식인 인사발령에서 데이터가 거꾸로 전달된다. 따라서 FK는 의미가 없다.

 

현소속부서라는 집합의 정합성을 검증하려면, 인사시스템의 발령에서 사원 별로 가장 최근 값만 추출하여 정합성을 검증해야 한다. 사원의 부서코드뿐만 아니라 직위코드, 직무코드도 마찬가지 방법으로 검증해야 한다. 실제로도 정합성 체크는 이렇게 하고 있다.

 

조회관계(Read Only Relationship)란 무엇인가?

조회관계란 데이터의 부모자식간의 데이터 전달이 목적이 아니라, 오직 두 집합을 연결하여 조회하려는 목적으로 탄생된 관계이다. 그래서 조회관계를 Read Only Relationship으로 부를 수 있다. 부서와 사원간의 관계 역시 역정규화에 의한 조회관계이다. 오직 사원의 자식인 인사-발령에서 현소속부서라는 데이터가 전달되므로, 부모인 부서집합에서의 전달관계는 없다. 하지만, 사원의 입장에서 현소속부서명과 부서의 위치를 알려고 하면, 부서와 사원을 연결할 수 있어야 조회가 가능하다. 특정 사원의 부서명을 조회하려면 부서와 조인하라.”는 정보가 필요하다. 따라서 조회관계라 하더라도 모델상에 어떤 식으로든 나타내어야 한다.

 
역정규화는 조회관계를 발생시킨다

조회관계는 역정규화를 하는 경우에 나타난다. 예를 들어 영국 프리미엄 리그를 보면, 리그와 팀을 배정해야 경기를 할 수 있다. 만약, 팀 엔티티의 속성에 리그코드가 있다면 그것 또한 역정규화에 의한 조회관계이다. 왜냐하면, 새로운 리그가 시작되기 전에, 지난 리그의 팀 성적에 따라서 각 팀들을 리그에 배정하는 작업이 존재할 것이기 때문이다. (예를 들면, 맨유는 1부 리그에 배정되었다.) 각 팀들을 리그에 배정하는 엔티티는 인사시스템의 발령에 해당한다. 물리모델단계에서 배정 엔티티의 리그코드는 역정규화 되어 팀 엔티티로 들어갈 수 있다. 하지만, 역정규화는 성능과 개발생산성을 위한 작업이므로 개념이나 논리모델에서 보다는 물리설계단계에서 나타내는 것이 적합하다. 

 

전달관계와 조회관계의 차이

일반적으로 우리가 알고 있는 관계는 전달관계이다. 전달관계는 부모식별자의 데이터를 자식에 전달하는 역할과, 두 집합을 조인하여 조회하는 역할을 모두 수행한다. 따라서 전달관계는 조회관계의 기능을 포함한다. 전달관계와 반대로 조회관계는 오직 두 집합을 연결하여 데이터를 조회하는 목적 밖에 없다.

 

조회관계를 어떻게 표현할 것인가

조회관계는 관계속성으로 데이터가 전달되지 않으므로 의미가 없다고 생각 할 수도 있다. 하지만 위에서 설명 한 것처럼 “특정 사원의 부서명을 조회하려면 부서와 조인하라.”는 정보를 인식할 수 있어야 한다. 따라서 아래와 같이 나타내는 것을 권장한다.

 

부서와 사원 사이의 관계선에 P를 표시하여 가상의 관계임을 나타내었다. 가상관계는 관계속성을 만들지 않는다. 또한 관계명에 조회관계라는 것을 명시해주어, 데이터가 부서에서 사원으로 전달되지 않음을 나타내었다. 그리고 부서코드와, 직위코드, 직무코드는 인사시스템의 발령테이블에서 역정규화된 된 속성이라는 것을 속성의 정의란에 나타내 주어야 한다. 회색부분은 외부(External) 엔티티를 나타낸 것이다. 외부엔티티를 사용하여 데이터의 원천을 나타내주면, 개발자가 데이터를 이행할 때 쉽게 참조할 수 있다. 즉 위의 모델을 그려놓으면인사시스템에서 데이터가 바뀌면 내 시스템의 부서와 사원 데이터를 동기화 해야 하겠군하고 명확히 판단할 수 있다.

 

위의 모델을 그림으로써 얻을 수 있는 정보는 세 가지이며, 다음과 같다.

1. 부서와 사원간의 관계는 전달관계가 아니라 조회관계이다.

2. 부서와 사원엔티티는 인사시스템이 원천이다.

3. 부서코드와, 직위코드, 직무코드에 해당하는 데이터는 인사시스템의 발령데이터가 원천이다.

 

또한 위의 세가지 정보로 다음과 같이 두 가지 장점을 얻을 수 있다.

1. 차세대 프로젝트의 데이터를 이행하는 사람은 데이터의 원천이 인사시스템의 부서, 사원, 발령 모델임을 인식하므로 매핑정의서를 쉽게 작성할 수 있다.

2. 개발자는 인사시스템의 부서나 사원, 발령의 데이터가 변경되면, 인사시스템이 아닌 타시스템의 부서와 사원도 동기화 해야 한다는 사실을 쉽게 알 수 있다. 물론, 동기화 프로그램의 작성도 모델을 참조할 수 있으므로 그만 큼 쉬워진다.

 

하지만 현실은……

실무에서는 거의 100% 아래와 같이 모델링 한다.



위의 모델에서는 어떤 정보와 어떤 장점을 얻을 수 있나? 거의 없다. 한가지 얻을 수 있는 것은 부서집합의 부서코드 데이터가 사원에 전달된다는 거짓정보이다. 이 정보에 의해서 사원의 부서코드는 부서로부터 상속되었다는 잘못된 생각을 하는 사람이 있다. 이에 따라 불필요한 FK를 생성하는 사람도 있다. 다시 한번 말하지만 사원의 부서코드는 부서 엔티티로부터 상속된 것이 아니라 인사시스템의 발령엔티티로부터 온 것이다. 

 

조회관계와 전달관계는 확실히 구분하기 바란다. 그렇게 하면, 모든 것이 드러나고 명확해진다.

 

반박의 논리

이 글을 몇몇 모델러에게 보여주었더니 반발이 있었다. 그런데 이상한 것은 대부분 반대입장만 표현하고, 반대의 적절한 이유가 없다는 것이다. 예를 들면, “내가 지금까지 이렇게 사용했어도 문제가 없었다혹은 “~책에 그렇게 하라고 되어있다가 대표적인 이유였다. 그런 것들은 이유가 될 수 없다. 반박을 하려면 이유가 있어야 한다. 이 글의 논리 중에 어느 부분이, 어떻게 잘못되었다고 지적 할 수 있는 능력이 필요하다. 그나마 이유를 댄 사람들은 아래와 같다.

 

전달관계로 표현해도 문제가 발생하지 않는다는 의견에 대해

그렇다. 전달관계로 표현해도 FK만 생성하지 않는다면 성능저하와 같은 문제는 발생하지 않는다. 하지만 프로젝트의 개발과정에서 여러 사람이 불편을 겪을 것이다. 조회관계의 개념을 모른다면 역정규화 되었다는 사실을 인식하기가 어렵다. 그러므로 인사시스템의 발령데이터가 변경되면, 트리거 성으로 타시스템에 동기화 해야 된다는 사실을 발견하는데 시간이 더 걸릴 것이다. 데이터를 이행하기 위한 매핑정의서를 작성할 때도 마찬가지로 어려움이 예상된다. 만약 모델러가 이런 모든 정보들을 안다고 해도 다른 사람들까지 모두 안다고 생각하면 안 된다. 모델은 정확히, 그리고 자세히 표현할수록 여러 사람이 얻는 이익이 많다.

 

우리회사는 발령이 없다는 의견에 대해

영세한 업체라면 발령이라는 엔티티가 없을 것이다. 인정한다. 그런 경우에는 부서-사원은 1:N로 직접적인 관계가 있으므로 관계선을 그어야 한다. 하지만 인사발령이 없는 영세한 업체라면 SI 프로젝트를 하지도 않을 것이며, 설계자나 모델러를 쓰지도 않을 것이다. 따라서 대부분의 경우 부서-사원의 현소속부서 전달관계가 존재한다면 잘못된 것이다.

 

우리 시스템에는 발령이 필요 없다는 의견에 대해

맞는 말이다. 인사시스템을 제외하면, 발령이라는 엔티티는 필요 없을 것이다. 하지만, 그 이유로 부서-사원간에 관계선을 긋는 것은 말이 안 된다. 발령이 필요 없다는 이유로, 존재하지도 않는 부서-사원간의 전달관계와 그에 따른 관계속성을 만든다는 것은 적절하지 않다. 사원의 부서코드는 전달관계속성이 아니라 역정규화된 추출속성이라는 엄연한 진실을 가리는 것이다.

 

모델링툴에서 조회관계를 표현하지 못한다는 의견에 대해

가장 그럴 듯한 반박논리다. 조회관계를 표현하는 기능이 없으므로 전달관계선을 그어야 한다는 것이다. 모델링툴 때문에 전달관계선을 긋는 것 보다는, 관계를 맺지 말고 누구나 볼 수 있도록 코멘트(Text Box)로 조회관계임을 기술하는 것이 더 나아 보인다. 어쩔 수 없이 전달관계선을 그을 수도 있다. 하지만, 개념을 알고 행동하는 것과 개념을 모르고 행동하는 것은 큰 차이가 있다. 다시 말해, 조회관계란 개념을 알고 있지만, 모델링툴에 기능이 없기 때문에 눈물을 머금고 관계선을 그은 것이라면 정당한 이유가 된다. 만약 그것이 아니라 부서-사원의 관계를 습관적으로 그은 것이거나 부서-사원의 관계가 1:N이라고 잘못 인식하고 관계를 맺었다면 옳지 않은 행동을 한 것이다.

 

현재 가장 대중적으로 사용하고 있는 ER-WIN이나 파워디자이너 같은 모델링툴은 조회관계를 나타낼 수 없다. 툴의 설계자가 조회관계라는 개념을 것을 모르니 당연한 것이다. 따라서 관계를 맺으면 무조건 전달관계와 전달관계속성을 만들어 버린다. 그에 따라 툴에서 제공하는 테이블 생성용 스크립트를 받아보면 예외 없이 FK를 생성해 버린다. 부모로부터 데이터가 전달되지 않으므로 참조무결성을 보장할 필요가 없는 데이터임에도 쓸데없이 FK를 생성하여 속도만 저하시킨다.

 

조회관계를 표현하는데 가장 유리한 모델링툴은 DA#이다. 필자가 가장 애용하는 툴이기도 하다. 이 툴에서 가상관계를 이용하면 관계속성을 만들지 않는다. 물론 가상관계가 아니라 조회관계를 표현할 수 있으면 좋겠지만, 그런 기능은 없으므로 현재로써는 가상관계로 처리하는 것이 최선이다. 위에서 그린 ERDDA#으로 표현한 것이다.

 

관계의 분류

관계는 여러 가지로 분류할 수 있다. 흔히 통용되는 관계분류의 예제는, 직접/간접 관계와 식별/비식별 관계이다. 직접관계란 1촌끼리의 관계를 의미한다. 즉 나와 아버지의 관계(1)이다. 관계형 데이터 모델에서는 직접관계만 표현하면 된다. 하지만 가끔 물리설계시에 SQL의 성능을 높이기 위해 할아버지가 직접 손자와 관계를 맺는 일도 있다. 이를 간접관계라고 한다. 식별관계는 부모의 식별자가 자식식별자의 일부로 상속되는 경우이다. 이와는 반대로 비식별관계는 부모의 식별자가 자식에 일반속성으로 상속된다. 이상으로 일반적인 관계의 분류방법을 알아보았다.

 

이 글에서 언급한 관계분류방법은 일반적으로 통용되는 분류방법과 다르다. 분류의 초점을 데이터의 전달유무에 맞추었다. 즉 전달/조회 관계로 새롭게 분류해 보았다. 직접/간접관계 분류법과 전달/조회관계 분류법은 많이 다르지만, 관계의 역정규화라는 점에서는 유사하다. 하지만, 데이터의 전달유무에서는 차이가 있다. 간접관계는 부모식별자의 데이터가 직접 자식으로 상속되는 전달관계이다. 이와는 반대로 조회관계는 부모로부터 데이터를 받지 않는다.  

개념이나 논리모델에서 조회관계 표현방법
될 수 있으면, 역정규화된 관계는 개념/논리모델단계에서 나타내지 말고, 물리설계단계에서 나타내기 바란다. 물리설계단계에서는 조회관계임을 명시하거나, 간접관계임을 나타내어 관계가 역정규화 되었음을 나타낼 수 있다. '그럼 개념이나 논리에서는 어떻게 나타내야 하는가?' 라고 질문할 수 있다. 개념모델단계에서는 부서와 사원 사이의 관계를 M:N으로 나타내면 되고, 논리모델단계라면 M:N 관계를 풀어서 외부엔티티인 인사발령을 표현해주면 된다. 논리모델에서 외부엔티티를 사용하는 것은, 물리모델링시에 조회관계(역정규화)로 나타낼 것임을 예고하는 것이다.  ( 2011.02.28 추가 )

 

결론

조회관계는 부모로부터 자식으로 데이터를 전달하지 못하고, 오직 조회를 목적으로 두 집합을 연결한다.

전달관계는 부모로부터 자식으로 데이터를 전달하고, 조회를 목적으로 두 집합을 연결도 한다.

부모로부터 자식으로 데이터가 이행되는 경우만 전달관계선을 그어야 한다.

부모로부터 자식으로 데이터의 전달이 끊기면 조회관계이다.

조회관계는 관계속성이나 FK를 생성하지 않는다.

역정규화에 의해서 조회관계가 발생된다.

부서--<사원은 조회관계이다.

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by extremedb

댓글을 달아 주세요

  1. Favicon of http://rainlethe.tistory.com BlogIcon 레인레테 2011.02.25 06:01 신고  댓글주소  수정/삭제  댓글쓰기

    FK에 대한 새로운 관점이군요. 찬찬히 생각을 해봐야 할 듯 합니다..

  2. 어느모델러 2011.02.25 08:23 신고  댓글주소  수정/삭제  댓글쓰기

    부끄럽습니다. 관계선을 그었던 1인
    동규님의 글은 공통점이 있네요.
    서론, 본론, 결론에 따라 내 생각이 아래처럼 바뀝니다.
    항상 이런 패턴으로 글을 쓰시는것 같습니다.

    서론 : 말도 안되는 글인데 어떤 이야기를 하는지 들어보자.
    본문 : 일리가 있는 글이군
    결론 : 앞으로 그렇게 하면 안되겠네

    감사합니다.

  3. 혈기린 2011.02.25 10:46 신고  댓글주소  수정/삭제  댓글쓰기

    김기창 수석님 블로그에서 댓글로 언급하셨던 내용에 대한 상세한 설명이시네요
    그 댓글보고 엔티티에 대해서 아무 생각없이 당연한 관계라고했던 것에 대한 생각을 고치는 계기가 되었네요 좋은글 계속 감사 드립니다 ~~
    모델링에 대한 글도 자주좀 올려주세요 눈이 번쩍 뜨이게 ㅎㅎ

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2011.02.25 11:06 신고  댓글주소  수정/삭제

      네 김수석님 블로그에 제가 이와 관련된 댓글을 작성한 적이 있습니다. 제가 링크를 함부로 달지 않는데, 김수석님 블로그는 너무 좋은 내용이 많아서 안달수가 없었습니다.
      그럼 수고하세요

  4. Favicon of http://xenerdo.com BlogIcon 제너시스템즈 2011.02.25 11:29 신고  댓글주소  수정/삭제  댓글쓰기

    엄청 어려운 일이네요. 쭈욱 두 번 읽어봤는데 사실 제 머리로는 아직 이해가 안가는 부분이 많아요^^;;; 다시 한번 더 읽어봐야겠어요^^

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2011.02.25 16:55 신고  댓글주소  수정/삭제

      두번 읽으셨는데 이해가 안가신다면 그건 제 잘못입니다.^^
      어느 부분이 이해가 안가시는지 설명해 주시면 설명을 추가하도록 하겠습니다.

      이 글의 핵심은 부모의 식별자 값이 자식의 관계속성으로 들어오면(insert 되면) 전달관계이고 들어오지 않으면 조회관계라는 것입니다. 부서(부모) 사원(자식)의 경우는 데이터가 부모로 부터 오는것이 아나라 오히려 자식격인 인사시스템의 발령에서 오는 것입니다. 따라서 조회관계라고 할 수 있습니다.

  5. 혈기린 2011.02.25 13:36 신고  댓글주소  수정/삭제  댓글쓰기

    한가지 궁금한게 있는데요 조회관계 전달관계의 명칭이 관계형 이론에 있는 관계의 종류인가요 아니면 오수석님께서 임의로 만든 용어인가요?
    몇권은 안되지만 제가 읽은 모델링 서적에는 없는 용어이기에 질문을 드립니다.
    모델러 마다 엔티티의 분류도 조금 다르더군요

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2011.02.25 13:58 신고  댓글주소  수정/삭제

      전달관계/조회관계는 제가 만든것 입니다. 용어를 만들었다기 보다는 개념을 만든것 입니다.

      EF 코드 박사가 제시한 관계형이론에는 조회/전달 관계라는 용어는 없습니다. 이 용어뿐만 아니라 직접/간접 관계라는 용어도 없습니다. 관계형이론은 아주 짧은 글이므로 그 이론이 만들어진 후에 여러 개인(전문가)이 추가적인 용어를 만든것 입니다. 혈기린님의 말에 의하면 관계형이론에 없는 것은 모두 임의로 만든거라 할 수 있습니다.^^ 하지만 임의로 만든것이라도 그것이 옳은 개념이고, 그 개념으로 더 나은 모델을 만들수 있다면 더 이상 개인적이고 임의적이라고 볼 수는 없겠지요. E사의 이화식 사장님과 오픈메이드의 김기창 수석도 마찬가지로 이론에 없는 여러가지 용어를 사용하고 있습니다.

      전달관계, 조회관계라는 용어는 제가 최초로 만든것이므로 그 어떤 모델링책에도 언급되지 않습니다. 부서-사원같은 잘못된 모델을 그대로 두고 볼 수 없기에 만든것 입니다. 하지만, 앞으로 나올 모델링 책에서는 이 개념을 사용하여 실수를 방지하는 것이 좋을 것입니다.

  6. finecomp 2011.03.01 01:38 신고  댓글주소  수정/삭제  댓글쓰기

    항상 좋은 글 감사합니다...;
    전달관계/조회관계...개념만큼이나 선택하신 용어도 맘에 딱 듭니다...^^;

    저는 이전부터 잘못된 원인을 약간 다른 관점에서 보고 있었습니다.
    부서-사원의 관계를 전달관계로 설정한 후, 필요에 의해 사원의 소속조직 이력관리의 개념으로 발령엔티티가 나타났고,
    발령을 관계맺은 후에도 처음 맺어졌던 부서-사원관계를 그대로 두었고,
    이 후 이런 모델을 만들었던 노련한 모델러 일수록 습관적으로 관계선을 그렸고 이것이 굳어져 현재는 오류로 보이는 듯 합니다.

    이와 유사하게 아직은 담당관리센터에 대한 이력관리가 필요치 않은 고객-센터(관리센터)의 예와 비슷할 듯 합니다.
    고객과 센터가 처음에는 전달관계로 설정되겠지요.
    이 후 필요에 의해 고객의 관리센터이력을 추가해야 할 필요성이 생기는 순간, 부서-사원과 동일한 문제가 발생하게 되겠지요.

    즉, 많은 경우의 전달관계에 대해서, 이런 유형의 이력이 생기는 순간 원래의 관계가 현행화 될 필요가 생길 수 있을 것 같습니다.

    결론적으로, 최초설계/변경 시에 좀 더 신중히 관계를 검토하고 조회관계 시엔 코멘트라도 잘 달아야겠다는 반성이 생기는군요...;

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2011.03.02 09:08 신고  댓글주소  수정/삭제

      저도 몇년 전 까지는 이런 오류를 범했습니다.
      그런데 finecomp님은 이미 잘못된 원인을 다른 관점에서 보고 있었네요. 그리고 개념과 용어가 마음에 드신다니 다행입니다.

  7. 에너자이져 2011.03.10 19:31 신고  댓글주소  수정/삭제  댓글쓰기

    전달관계=직접관계, 조회관계=간접관계 의 등식이 성립되는거 같습니다.
    직접/간접관계 보다는 전달/조회관계 라는 용어가 이해를 빠르게 하네요.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2011.03.11 10:07 신고  댓글주소  수정/삭제

      이해가 빠르다고 하시니 다행입니다.
      전달관계=직접관계, 조회관계=간접관계가 성립하듯이
      직접관계=전달관계, 간접관계=전달관계도 성립합니다.
      감사합니다.

  8. 김상래 2011.06.12 11:42 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 데이터 모델링을 하면서 항상 관계(Relationship)에 대해 많이 고민하게 되는데,
    상당히 의미있고 중요한 부분을 집어내어서 명확히 풀어내신것 같습니다. 저도 개인적으로
    머리속에 두서없이 비슷한 생각을 하고 있었는데 오늘 이 글을 통해 어느정도 자연스레 정리된 느낌이네요.

    저는 저의 언어로 이렇게 정리를 했습니다. 확인차 몇가지 질문도 함께 드려봅니다

    1. 저는 관계를 크게 엔터티간에 종속적인 관계와 참조적인 관계가 있다라고 보는데,
    블로그에 쓰신 전달관계와 조회관계라는 용어의 맥락에서 볼때
    종속적인 관계는 분명 부모 식별자의 데이터가 (관계속성으로) 자식으로 전달되니
    부모 자식의 관계가 명확한 종속적인 관계 = 전달관계로, 당연히 관계선이 표현되어야 하고
    RI 제약 생성의 대상이 된다고 볼수 있습니다.
    즉, 종속관계는 전달관계로 관계가 표현되어야 한다는 것은 의심의 여지가 없습니다.

    2. 문제는 조회관계와 참조관계인데.. 종속관계가 아닌 참조관계는 블로그에 언급된
    전달관계가 있는 참조관계와 단순 조회관계인 참조관계를 포함하는 개념으로 보아야 할것 같습니다.
    예를들어 고객의 직업에 있어서, 직업코드와 직업명을 관리하는 직업엔터티가 코드성으로 존재할 때
    고객 엔터티에 직업코드가 일반 속성으로 존재한다면 이 경우는 전달관계가 있는 일반적인 참조관계로 보고
    RI를 적용하여 FK Constraint를 생성하여 직업엔터티에 존재하는 직업코드만이
    고객의 직업코드로 들어올수 있게 한다는 개념으로 정리해도 될까요?

    3. 그렇다면 블로그에 언급하신 조회관계는 모두 역정규화에 의해 발생한 속성으로부터 발생된 것을
    의미하는 것인가요? 이 글에서 언급하신 사원의 부서코드와 같이 외부시스템(외부테이블)과의 관계에 의해
    나온, 즉 데이터 중복인 역정규화 속성으로 발생한 참조관계인 경우,
    이를 조회관계라는 용어로 언급하신게 맞는지 궁금합니다.

    정리하면 블로그에서 언급된 전달관계/조회관계라는 용어와 제가 생각하는
    종속관계/참조관계 용어의 추상화정도와 관점을 맞춘다고 봤을 때, 아래와 같이 귀결시킬수 있을지 의견 부탁드려봅니다.

    전달관계 : 종속관계 전체 및 역정규화된 속성에 의해 발생하는 단순 조회관계를 제외한
    참조관계(일반적인 Non-identifying)까지를 포함
    조회관계 : 외부테이블과의 관계에 의해 발생한 속성에 따른 참조관계로, Relationship을 관리할 필요가 없다.
    다만 Join의 대상이 되므로 모델링 툴에서 표현을 할 필요는 있다.

    아.. 그런데 이렇게 글로 정리하다보니 제가 생각하는 참조관계란 결국 애매하게 조회관계까지를 포함하는
    개념이었듯 한데, 엄밀하게 정리를 하자면 전달관계가 있는 종속관계와 전달관계가 있는 참조관계, 그리고 전달관계가 없는
    반정규화에 따른 조회관계가 남게 되는군요...

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2013.05.31 18:24 신고  댓글주소  수정/삭제

      2년이 지났지만 답변드리겠습니다.
      전달관계는 식별관계이든 아니든 상관없이 상위 엔티티의 식별자가
      하위 엔티티의 속성으로 상속되는 것입니다.
      위 쪽의 고객과 주문간의 관계는 일반 속성으로 상속되었으므로 비식별 관계이면서 전달 관계입니다. 이와는 반대로 상품과 주문상품의 관계는 식별자로 상속되었으므로 식별 관계이면서 전달 관계입니다.
      조회관계는 외부테이블 이든 아니든 역정규화에 의한 관계입니다. 위의 예제에서는 max(마지막) 값을 가져다 놓은 것을 언급했습니다.
      감사합니다.

  9. 김시준 2013.05.31 12:24 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사드립니다.

  10. 주지영 2013.09.26 17:32 신고  댓글주소  수정/삭제  댓글쓰기

    모델링 접한지 얼마안된 DB관련경력자입니다. 책을 보면서도 속시원하게 뭔가 풀리지 않고 답답한 구석이 있었는데 ...
    심지어 모델링 공부하는 사람에게 물어봐도 '이건 당연하게 사용했던거라...'라는 답변을 꼭 들어야만 했습니다.
    앞으로 종종 들러 많은 가르침 배우고 싶네요.
    감사합니다(__)~

  11. Favicon of http://oracledo.tistory.com BlogIcon #도상 2016.11.28 10:01 신고  댓글주소  수정/삭제  댓글쓰기

    잘 읽었습니다. 관계선에 대해 다시 한번 생각하고 정리 할 수 있는 기회였습니다.