ERD에서 올바른 관계(relationship) 맺어주기

요즘은 현재 운영중인 시스템의 ERD를 보면서 테이블들 간의 관계를 찾아주는 작업을 하고 있습니다. 초기 ERD는 운영 Database에서 reverse 해서 만들었는데, 테이블간의 관계는 전혀 없습니다. 

이걸 들여다 보면서 나름 해독하고, 업무 설명 문서를 읽고, 그래도 모르겠는 내용은 물어가며, 이렇게 저렇게 상상의 나래까지 더해서 관계를 찾아가고 있는데요. 꽤 재미있네요. :-) 

오늘은 이렇게 관계를 찾아나가던 중, 세 번이나 관계를 바꾸고 나서야 만족스러운 결과를 얻었던 사례를 말씀드리려고 해요.

우리 도서관에 연체한 회원의 목록을 타 도서관에 보내서, 그 쪽 도서관에도 연체한 사람인지 알아보려고 하는 업무라고 가정할께요. 다른 도서관은 우리 도서관의 타 지역 분원 일 수 있구요, 아니면 아예 다른 도서관 일 수도 있습니다.

그럼 연체확인요청하는 대상자와 그 결과를 받은 내역을 모델링한 테이블이 다음과 같다고 해볼께요.

<그림1. 연체확인 요청 대상 및 결과 테이블>

우리 도서관에서 이번달에 생긴 연체자 목록을 확인 대상자 테이블에 담아 전송하면 상대편 도서관에서 그 내역을 확인하고 그중에서 자기네 도서관에도 연체된 사람이라면 언제부터 대출을 중단했다는 정보를 돌려주는 거죠.

이 둘의 관계를 고민하다가, 처음에 딱 테이블 이름을 보고는, '아, 일반적으로 정보를 요청하면 그 결과를 여러건 받게되니까' 하면서 이렇게 연결했습니다. 

<그림2. 1:M 관계>

 그런데, 조금 더 자세히 속성을 들여다보니,  관계가 반대라는 생각이 들더라구요. 왜냐하면 결과내역에는 키가 처리년월, 주민번호 이렇게 두 개 인데, 요청내역에는 키가 그 두 개에 회원번호까지 있어서 세 개 거든요. 

그래서 이렇게 생각을 바꿨죠. '아 요청내역에서 혹시 회원번호가 달라도 주민번호가 같은 사람은 한 건의 결과가 돌아올테니까 M을 요청해서 1일 돌아오는 형태로구나' 하구요. 참 쉽게 마음을 바꾸고, 또 논리를 급조합니다. ;-) 그래서 그림2에서의 관계를 바로 뒤집어서는 이렇게 관계를 그려주었네요.

<그림3. M:1 관계>

그런데, 업무 설명을 더 들어보고 곰곰이 생각해보니, 이것도 이상합니다.

 

확인대상을 요청하면 그중에 연체가 있는 사람만 결과가 온다고 하잖아요. 뭔가 요청을 해야 결과가 오고 이게 1:1이라는 냄새가? 나는 거죠. 

마지막으로 '아하! 요청에 대해 결과가 있을 수도 없을 수도 있고, 요청 한건에 대한 결과가 해당 월에는 한건 오는 거로구나!' 하고 관계를 수정했습니다.

<그림4. 1:1 관계>

이게 제가 오늘 관계를 세번 고치면서 올바른 관계를 찾아간 과정입니다. 오늘의 교훈은 "테이블명만으로 이해해서도 안되고, 속성 만으로 이해해서도 안되고, 업무의 설명까지 확인해야 정확한 관계를 설정할 수 있다"  간단히 말해서, "속단하지 말자!" 네요.