본문 바로가기
Data Modeling

잘못된 관계를 설정 하면 발생하는 일

by csk 2013. 5. 23.

며칠전 프로젝트 참여인원을 대상으로 데이터 모델링의 기본내용을 강의할 일이 있었는데요, 엔터티란 무엇인가, 관계란 무엇인가, 관계의 유형은 어떤것이 있는가를 한참 설명하고 있는데 한 분이 질문을 하셨습니다.


"그런데, 만약에 관계를 잘못 맺으면요. 예를들어 1:1 관계인데, 1:M 으로 설정한다든지요. 그럼 어떤일이 생기나요?  혹은 잘못 맺었다는 것을 어떻게 알 수 있나요?" 


흡. 잠시 긴장 했더랬습니다. 당연히 제대로 그려야 한다는 생각만 해왔지, 어떤일이 생길지, 어떻게 알 수 있을지는 깊이 생각해 보지 않았던것 같습니다. 그래서, 잘못 그린다고 무슨일이 나서 알게되지는 않으나, 논리 데이터 모델은 업무 규칙을 잘 표현하려고 노력해야 하고 업무 규칙을 잘 아는 사람이 검증해야 한다고 답하고 마무리 했습니다. 


집에 돌아오니 찜찜하더라구요. 그래서 종이를 꺼내 생각을 좀 해보았습니다. 


사원과 병역의 관계가 있다고 해볼께요. 이것은 사실 싸이와 같이 특별한 케이스를 제외하고는 1:1의 관계라고 할 수 있습니다. 그런데, 이것을 1:M의 관계로 잘못 모델링을 하면 어떤일이 일어날까요? 





실제 데이터는 1:1의 형태로 발생하기 때문에 1:M 형태의 구조에 문제없이 입력이 됩니다. 그래서 잘못되었다는 것은 업무규칙을 잘 아는 사람이 지적해 내지 않는한, 알아내기 어렵고 별 문제없이 시스템이 운영되게 됩니다. 

시스템이 한동안 운영되고 난 후에 데이터를 가지고 검증을 해본다면 1:M으로 들어가 있는 데이터가 한건도 없다는 사실을 발견할 수도 있겠지요. (사실 이렇게 굳이 검증을 해보는 곳은 거의 드물다고 생각되므로 패스~ ^^;)


그럼 반대의 경우를 가정해 볼께요. 부서와 사원과 같이 1:M의 관계인데, 이것을 잘못 모델링하여 1:1로 작성하였다면 어떤일이 일어날까요? 




이것은 개발이나 테스트 단계에서 1:M 형태의 데이터를 입력하려고 할 확률이 매우 높기 때문에 모델링 오류를 발견하고 수정할 가능성이 농후 합니다.


정리하면 1:1을 1:M으로 잘 못 그린경우는 오류를 발견하기 어렵고, 시스템이 별 문제없이 운영될 수 있지만, 반대로 1:M을 1:1로 잘 못 모델링한 경우는 오류가 거의 발견될 수밖에 없다는 것입니다. 



이러한 현상은 optional에 관련된 아래의 경우들에서도 유사하게 나타납니다.  


2와 같이 필수적(mandatory)인 관계를 1과 같은 선택적(optional) 관계로 모델링 했다면, 이러한 실수를 발견하기 어렵고 큰 문제가 없이 지나갈 수 있습니다. 하지만 반대로 1의 업무규칙인데 이를 2와 같이 모델링 했다면 바로 잘못된것이 발견될 거라는 거죠. 



이런 내용들을 나열해서 살펴보니 하나의 원칙을 찾을 수 있더군요.


(상대적으로) 강한 관계를 약한 관계로 잘 못 모델링 한 경우는

한동한 운영하여 데이터를 확인해 보기 전에는, 오류를 발견하기 어렵습니다.


하지만 약한 관계인데 이것을 강한 관계로 잘 못 표현한 경우는

개발이나 테스트 등 이어지는 단계에서 바로 발견될 확률이 높습니다.


1:M은 1:1의 데이터를 포함할 수 있기 때문에 제약조건이 덜해서 약한 관계로 보았구요,

optional은 optional이 아닌, 필수 관계의 데이터의 처리가 가능하기 때문에 약한 관계로 보았습니다.


그럼, 어떤 방향을 추구하면 좋을까요?

확인된 수준에서 가장 강한 관계로 모델링을 해서 오류가 발견되도록 해가며 수정하는 편?

확인된 수준의 가장 약한 관계로 모델링을 해서 별  문제없이 개발하고 운영할 수 있도록 하는 편? 

이건 간단히 답하기는 어렵네요. 그때그때 다를 것 같아요. ;-p


세 명이 함께 걸어가면 그 중에 반드시 스승이 있다고 하더니,

처음 배우는 분의 질문에서도 새로운 깨우침을 얻게 되네요. ^^ 

'Data Modeling' 카테고리의 다른 글

선택적(optional) 관계의 모든것  (3) 2013.06.06
복합키 정리하기  (0) 2013.05.30
관계 종류 결정하기  (0) 2013.05.18
속성이냐 엔터티냐  (0) 2013.05.10
서브타입 해체하기  (0) 2013.05.01