이력테이블 설계 문의드립니다.
steadylove 수험생

답변 채택시 : 0코아

답변 2 추천 0 조회 5286 2014.08.27

안녕하십니까?

 

이제는 무식한 DB설계가 아니라 체계적으로 DB를 설계하고 싶습니다.

 

거래처관리 테이블이 있는데, 현재 기본키는 사업자등록번호입니다.

기본키가 사업자등록번호일경우 사업자등록번호가 변경시 이력관리를 할 수가 없습니다.

 

어떻게 엔티티를 설계를 해야 이력관리를 할 수 있을까?

 

댓글 (0)
목록 답변등록
이력테이블 설계 문의드립니다.
marvin 2014.09.01

 현재 내용만으로는 질문자의 의도가 불확실하지만 일단 다음과 같은 질문이라고 가정하겠읍니다.

1. 거래처는 특정 위치에 존재하는 매장과 같은 개념이다.
2. 거래처 단위의 각종 업무 행위(주문, 배송 등) 를 관리하고자 한다.
3. 거래처에는 반드시 사업자가 배정되는데, 경우에 따라 거래처의 배정된 사업자가 변경될 수 있다.
   즉, 지입승계 또는 명의변경의 개념이 존재한다.

4. 거래처의 사업자와는 계약에 의하여 임대료 정산등의 업무를 관리하고자 한다.


상기와 같은 가정에서 사업자등록번호가 식별자인 거래처 엔터티에 대하여  사업자가 변경될 경우 문제점은

1.  식별자인 사업자등록번호를  변경하면 해당 엔터티의 식별자를 상속받는 모든 하위 엔터티에 대한 식별자 변경이 발생하며,

2. 별도의  사업자등록번호를  새로 생성하면 매장 관점의 순수 거래처 기반의 업무 행위(주문,배송 등)에 대한 통합 관리가 복잡해질 수밖에 없다.


이런 경우 적절한 방안은 아래 모델처럼 사업자등록번호에 대한 독립 집합인 파트너, 위치 기반의 거래처,  파트너와 거래처 간의  거래처 계약을 정의하고, 개별적으로 종속된 행위를 관리하도록 합니다.



메장.png

댓글 (0)
이력테이블 설계 문의드립니다.
stbo 2014.09.01

위의 얘기를 미루어 짐작해 본 결과 기본키인 사업자등록번호가 다른 테이블에 상속되어버리는 경우 - , 자식을 가지는 경우 - 값이 변경될 경우 갱신등 파급효과 등으로 일반적으로 기본키는 변경되지 않는 값으로 설정하는 것이 일반적입니다.

 

예를 들어, 홍길동이란 사람이 A라는 사업장을 내었다가 폐지하고 다시 B라는 사업장을 냈을 경우 물리적으로 한 사람이 관리했던 거래처이지만 논리적으로 두 업체가 되어버려 이력을 따로 가야 하는 등 관리가 어려운 단점이 있습니다. 이럴때는 비즈니스 적으로 사업자등록번호가 다른 경우 두개의 업체로 봐야할 것인가 하나의 업체로 봐야 할 것인가에 따라 판단을 내려야 하며 만약 하나의 업체로 봐야 할 경우 기본키가 사업자관리번호 이기 때문에 이력관리를 하려면 다른 판단 기준 로직이 필요할 것입니다. (이를 테면 홍길동의 고객번호등과 조인해서 같은 업체인지 판단하는 로직)

 

이 때, 자주 쓰는 방법은 [거래처번호] 컬럼과 같이 인조식별자를 써서 그 테이블의 Unique한 키 값으로 기본키를 대체하고 사업자관리번호를 Unique하게 관리하고 싶다면 Unique인덱스를 걸어 DBMS적으로 중복값을 배제시키는 방법이 있습니다. 이런식으로 하면 거래처의 [거래처번호]로 보았을 경우 이력테이블에는 여러 개의 사업자등록번호를 가지는 이력관리가 가능합니다.

댓글 (0)