이력 엔터티를 설계하는 10가지 방법 – 속성 단위 이력 관리 예제

이번 시간에는 속성 단위로 이력 관리하는 방법을 정리하는 의미로 다양한 예제를 설명드리겠습니다. 처음부터 다시 읽지 않으려면 잘 따라오셔야 합니다. ㅎㅎ

 

세 번째, 네 번째, 다섯 번째 방법처럼 한 속성만으로 이력 데이터를 설계하는 방법은 역할(Role)을 관리할 때 자주 사용합니다. 실체 엔터티 간 관계(역할)는 주로 별도의 엔터티에서 관리합니다.

 

계좌 관리 사원을 관리한다면 [그림1]과 같은 모델이 기본입니다.

[그림1]

 

위 모델에서 변경된 과거 관리 사원까지 관리한다면 [그림2]와 같이 됩니다.

[그림2]

 

계좌관리사원 엔터티에서 현재 계좌를 관리하고 있는 사원과 과거에 관리했던 사원을 함께 관리합니다. 현재 데이터도 관리하므로 ‘~이력’이란 단어를 엔터티명에 사용하지 않았고요.

 

역할을 관리하는 엔터티는 보통 조회 성능을 고려해야 합니다. 특정 계좌의 특정일 관리 사원에 대한 조회는 문제가 안 되지만 계좌를 가장 많이 관리하고 있는 ‘홍길동’이라는 사원의 전체 계좌에 대해 계좌번호와 잔고 등의 기본 데이터를 보여주는 화면이 존재하거나, 지점별로 관리자가 관리하는 계좌 숫자와 예수금 총액을 보여주는 화면 등이 있다면 성능 문제가 발생할 수 있습니다.

 

일반적으로 고객에게 제공하는 화면에는 문제가 없지만 사용자(직원)에게 보여주는 화면에 성능 문제가 있을 수 있습니다.

 

이때 선분 이력을 검토해야 합니다. 이번 시리즈에서는 변경일자만 사용하고, 실제로 변경일자만 관리해도 조회 성능 문제가 크지 않지만 요건에 따라 차이가 커질 수 있습니다.

 

선분 이력의 성능 문제는 다음 글을 참조해 보세요(오픈메이드컨설팅 오동규님의 글입니다).

 

3부 - 변경이력 테이블에 종료일자가 필요한가?
 

성능 문제를 해결하는 다른 방법은 비정규형입니다. [그림3] 모델과 같이 계좌 엔터티에 현재 관리 사원을 중복으로 관리할 수 있습니다.

[그림3]

 

이때 현재계좌관리사원번호 속성은 추출(Derived) 속성입니다. 계좌관리사원 엔터티에 존재하는 데이터 중 가장 최근에 관리 사원으로 지정된 사원, 즉 현재의 관리 사원을 계좌 엔터티에 추출 관계로 관리하는 것입니다.

 

계좌관리사원 엔터티에도 계좌의 현재 관리 사원 데이터가 존재하고 이 값이 원천 데이터입니다.

 

현재 역할이 중요하므로 대부분 요건은 현재 관리 사원과 관련돼 계좌 엔터티만으로 처리할 수 있습니다.

 

비록 무결성 저해 요소가 생기더라도 데이터 중복을 선택하는 것이 바람직할 때도 있습니다. 데이터 무결성(Integrity)이 최우선 요소지만 무조건 항상 그런 것은 아니라는 점이 어렵습니다.

 

[그림3] 모델에서 만약 계좌 엔터티에서는 현재 관리 사원만 관리하고 과거 관리 사원은 계좌관리사원 엔터티에서 관리한다면 [그림4]와 같은 모델이 될 것입니다.

[그림4]

 

과거 데이터만 관리하는 엔터티는 구분하기 위해 ‘~이력’을 붙여 계좌관리사원이력 엔터티명을 사용하고, 계좌 엔터티의 현재계좌관리사원번호 속성도 ‘현재’라는 단어를 굳이 안 붙여도 됩니다. 현재•최근•최초 등의 단어가 사용되면 일반적으로 추출 속성입니다.

 

하지만 [그림4] 모델에는 커다란 결점이 있습니다. 계좌와 사원 사이에는 관계(Role)가 하나만 존재하는 것은 아니라는 겁니다.

 

운용•실적•상담 사원 등이 존재할 수 있는데 이런 다양한 역할(Role)을 [그림4]와 같은 모델로 관리하는 것은 확장성이 떨어집니다.

 

미래에(아마도 가까운 미래에) 다른 역할이 존재하면 스키마가 변경됩니다. 계좌 엔터티가 변경되고, 관리자와 연관된 화면이나 프로그램도 많아 유지보수가 어려워집니다.

 

그래서 [그림5]와 같이 계좌관계사원 엔터티에서 여러 역할을 통합해 관리할 수 있습니다.

[그림5]

 

여러 역할을 통합 관리하므로 엔터티명과 속성명에 좀 더 일반적인 용어(관계사원)를 사용했습니다.

 

[그림5] 모델에서 현재의 관계 사원 데이터를 추출 속성으로 관리하려면 [그림6]과 같은 모델이 됩니다.

[그림6]

 

관리•운용•실적•상담 사원 중에서 관리 사원과 실적 사원만을 추출 속성으로 관리했습니다. 추출 속성은 주요한 일부 속성만을 사용해야 유지 보수가 수월해집니다. 모든 역할 속성을 추출 속성으로 관리한다면 확장성이 현저히 떨어지게 되고요.

 

이렇게 사원과 계좌 사이에는 역할로서 관계가 존재하는데 여러 역할이 존재할 수 있습니다. 역할은 부여하기에 따라 얼마든지 늘어날 수 있다는 사실을 염두에 두어야 합니다.

 

또한 거의 모든 데이터는 변하기 때문에 과거 이력 데이터를 고려해야 하는데요. 관리 사원이나 실적 사원같이 역할(Role)을 관리하는 데이터는 보통 과거 데이터도 철저하게 관리하게 됩니다.

 

역할(Role)의 확장성과 역할의 이력 데이터를 고려해서 모델을 설계해야 합니다.

 

다음에는 이력 엔터티를 설계하는 여섯 번째 방법, 변경 대상 속성을 코드로 관리하는 방법에 대해 설명하겠습니다.