엔터티 분할하기

이번달부터 업무를 바꾸어 데이터 모델링을 수행하고 있습니다. 업무를 바꾸는 원래의 목적에 맞게, "일하며 배우며" 진행하기 위해서 일주일에 한번씩 글을 쓰려고 합니다. 일주일 동안에 새롭게 알게 된 내용이나, '맞아 역시 그렇군' 하며 다시 돌아보게 된 주제에 관해 적어 보겠습니다.

----------------------------------------------------------------------------------------------------

개념이나 논리가 아니라 실제 운영되고 있는 시스템의 ERD를 보면 많은 경우 유독 많은 컬럼을 가진 엔터티가 한두개쯤 있게 마련입니다. 인사 시스템이라면 '사원' 엔터티가 대표적이지요. 데이터 중에서 가장 중요하고 핵심적이기때문에 이러한 형태를 가지게 되는것이 어느 정도 당연하다고 생각됩니다.

그런데, 어떤 ERD를 보면 많은 컬럼을 가진 엔터티 여러개가 나란히 나란히 줄 서 있을 때가 있습니다. 이정도가 되면 고민이 되기 시작하죠. 이게 괜찮은걸까? 하구요. 이렇게 컬럼이 많은 엔터티를 만나면 어떻게 해야 할 지 생각을 해보겠습니다.  

도서관의 시스템을 예로들면 이렇게 컬럼이 많은 엔터티가 있을 수 있습니다. 컬럼을 나열하다 말았는데요 실제로 필요한 컬럼을 다 쓰다보면 훨씬 더 길어지겠지요. 

이런 형태는 대체로 업무를 전산화 한지 얼마 안되는 조직의 시스템에서 볼 수 있습니다. 그 이유는 일단 이런 모델은 종이 서류를 사용하던 내용을 그대로 옮겨놓은 형태이기 때문입니다. 생각해보시면, 도서관에 시스템이 없던 시절에는 대출 신청서 라는 위와같은 종이 서식을 썼을 테니까요.  

물론 시스템을 설계 할 때에는 사용 중인 종이 서식을 두루 조사해 시스템에 포함 시키는 것이 당연합니다. 사용자들이 우아하게! 새 시스템에 적응할 수 있도록 종이 서식의 형태를 그대로 살려서 화면을 설계해 주는것도 좋은 전략 입니다. 하지만, 데이터는 다릅니다. 데이터의 구조는 사용자의 눈에 직접 보여져야 하는 것은 아니기 때문에, 최종적인 단순 사용자 관점에서 이해하기 쉬울 필요는 없습니다. 대신, 데이터가 오류가 덜 발생하게 잘 관리될 수 있는 구조로 잘 정리되어 들어가 있으면 됩니다. 데이터의 구조와 화면 사이의 간극은 SQL이라는 훌륭한 언어가 메워주는 것이구요.

그럼 잘 관리될 수 있는 구조란 어떤 것인가 하는게 문제 인데요. 일단 오늘은 엔터티를 분할하는 관점에서 살펴보려고 합니다. 

데이터 모델을 그릴때는 "행위와 대상, 그리고 주체 데이터를 구분하라"고 말합니다. 위의 예에보는 '대출/반납'을 보면 이렇게 나누어 볼 수 있습니다.

그럼 하나라고 생각했던 엔터티가 각각 세개로 나누어 지게 되지요. 이렇게 되면 회원 자체의 정보가 제대로! 관리됩니다. 회원의 정보가 바뀌면 회원 엔터티에서 한 건의 데이터만 바꾸어 주면 되어, 오류 데이터가 생기는 것을 막을 수 있구요, 그 결과로 홍길동 이라는 회원이 몇 번의 대출을 했는지 등의 정보를 보다 정확하게 뽑아낼 수 있게 됩니다.

그런대, 현재 모델에 아직도 수정할 부분이 남아 있습니다. 행위 부분인데요. 행위가 대출/반납으로 뭔가 명확하지 않게 뒤섞여 있다는 점입니다. 

여기서 두번째 조언을 드릴 수 있는데요 "절차적으로 이루어지는 일들은 각각을 별도 데이터로 분할 할 수 있다" 입니다. 아까의 조언은 ~ 하라 였는데, 이번엔 ~ 할 수 있다 입니다. 무책임하게도 보입니다만, 쓰는 사람이 알아서 잘 적용하라는 거죠. :-) 

사실 모든 일은 절차적으로 이루어 지는데요, 그걸 얼마나 잘게 쪼갤 것이냐는 '사람' 만이 결정할 수 있습니다. 

위의 대출/반납을 봐도 그렇습니다. 대출과 반납은 시점도 상당히 떨어져 있구요. 어떤 경우는 엄마가 빌려가서 아들이 반납할 수도 있으니, 주체도 달라지고, 또 어떤 경우는 세 권을 빌려가서 한 권만 먼저 반납할 수도 있으니 대상이 되는 도서도 달라집니다. 이런 경우는 누가봐도 분할을 해야 겠죠. 

하지만 대출 만으로 한정해서 봐도 다시 고민이 시작됩니다. 왜냐하면 대출이라는 게 한 방에 훅~ 이루어 지는 일은 아닐 수 있거든요. 정말 작은 규모의 동네 도서관은 책을 들고가서 사서에게 건네주면, 사서가 한 번에 대출 처리를 해줘서 들고 나올 수도 있습니다. 하지만 큰 규모의 도서관인 경우에는 사용자가 대출 내용을 먼저 입력해 두었다가 도서관을 퇴실할 때 대출 처리를 하면 대출자가 책상태를 확인해서 입력하고 자신을 대출 처리자로 입력한 후 대출 할 수도 있거든요. 후자의 경우는 대출이라는 절차를 대출 신청과 대출 처리로 더 나누어 볼 여지도 있습니다. 

 

엔터티를 분할 할 지 여부는 trade-off를 고려해 결정해야 합니다. 분할의 장점이라면 데이터 중복이 줄어들어서 잘못된 데이터가 입력될 확률이 적어진다는 것과, 한 엔터티에 여러 프로세스가 몰리는 성능 저하를 사전에 막을 수 있다는 점이 있습니다. 반대로 단점이라면 엔터티 숫자가 늘어나 관리할 대상이 많아지고, 해당 화면에 대한 SQL을 만들때 많은 엔터티를 사용해야 하니까 SQL이 복잡해진다는 점이 있겠습니다. ( 이 부분 은 나중에 좀 더 자세히 설명할 기회가 있을 것 같네요. :-)  )

오늘은 엔터티를 분할하는 방법에 대해서 정리해 봤습니다. 기초적인 내용 일 수 있지만, 실제 ERD를 검토하다 보니 '아 정말 그렇구나'하며 다시한번 깨닫게 되어 정리해 봅니다. 분할이 기계적으로 할 수 있는 일이 아니고, 사람이 잘 살펴보고 장단점을 고려해서 해야하는 일이기는 합니다만, 유독 컬럼이 많은 엔터티는 집중해서 살펴보고 관리해야 한다는 것은 확실한 것 같습니다.