상품타입과 상품의 관계가 어떤 것인지 명확하지 않은거 같군요.

주문내역에 있는 상품코드, 상품타입은 어떤 의미를 갖고 있는 것인지?

상품타입마스터에는 상품타입, 상품코드 이런 식으로 있고

단지 판매한 상품이 어떤 상품타입으로 나갔는지 사후에 체크하시려는

목적인지?

일단 위의 문제는 정확한 모델의 의도를 모르니까 말씀드리기 곤란하고.

제기하신 문제점은 상품타입마스터가 자주 변경되어서 문제라는 거라면

상품타입마스터를 이력관리하면 될 것 같네요..

상품타입, 상품코드, 시작일, 종료일

상품타입의 관리방법은 실제로 상품을 빼거나 넣는것이 아니고

시작일과 종료일로 조정해주는 거죠..

이렇게해서 주문당시 주문일자에 유효한 상품타입의 상품만 가져오면

될 것 같은데요.

이력관리에 대한 자세한 내용은 여러가지 자료에 설명이 있으니

참조하시기 바랍니다.

문제점을 제대로 파악한 건지 모르겠네요.. ^^

상품타입 마스터란 다음과 같습니다. 일종의 세트죠. 넥타이와 와이셔츠 이런식으로요.

AAA - 1 이란 상품의 타입 1은 뭐 BBB와이 CCC넥타이 이런식으로 되어있지요.

그런데 가끔 사용자가 어떤한 업무조건에 부딪혀서 BBB와 CCC로 구성된 넥타이를 CCC로 바꿔버립니다. 그런데 실제 물건 BBB와 CCC로 이루어져 있죠.

얼래 AAA - 1 에 구성도는 시작일과 종료일 이런식으로 구성될수 없습니다. 왜냐면 항상 고정적으로 구성이 제품 생산 단계부터 정해져 있거든요. 근데 갑자기 대리점 출고시 그구성도를 바꿔서 곤란을 겪은 경우입니다. 그래서 애를 먹었죠. 얼래는 상품타입 마스터와 릴레이션을 해서 그구성도를 보여주었는데. 이제는 어떻게 해야 할찌 정말 모르겠네요.  입고시 상품마스터 정보와 출고시 갑자기 바뀌는 이런경우가 종종 있습니다.

제가 업무를 정확히 이해했는지는 모르겠지만...

우선 항상 설계시에는 실체를 명확히 파악하는 것이 중요합니다.

그 중에서도 중요한 것은 동일한 용어로 사용되지만 실체는 다른 엔티티와 반대로 서로 다른 용어로 사용되지만 실체가 동일한 놈들을 잘 걸러내야 합니다.

현재 상품타입이라는 놈이 문제가 되며 이 상품타입이라는 것이 주문 및 생산 시점과 출고 시에 의미가 달라진다는 것이 문제라고 하셨습니다...

그렇다면 별개의 실체로 보아야 합니다.

이런 문제는 일반적 이력관리의 성격을 갖는 것으로 보기보다는 논리적 실체가 다른 것으로 보아야 합니다.

아주 흔한 한가지 예를 들어 엔티티문제가 아닌 어트리뷰트문제에 있어서의 논리적으로 다른 실체에 대해 말씀을 드려보면..

상품과 단가 및 판매 단가에 대해 생각해 볼 수 있습니다.

판매대상상품이라는 엔티티가 있고 여기에는 상품코드,명,판매단가가 있다고 하고 판매라는 엔티티에는 상품코드,판매수량,판매처가 있다고 할때 판매엔티티에 판매단가를 가져가게 됩니다.

제가 읽어본 어떤 책에서는 이런 경우를 의도적인 데이타 중복성이라고 하는 책도 있고 판매단가의 일종의 이력관리라고 하는 경우도 있었습니다.그러나 이런경우는 의도적 중복성도 아니고 이력관리도 아닌 판매단가라는 어트리뷰트의 논리적 실체가 다른 것입니다. 논리적 실체가 다르다는 사실은 논리설계 시점에서 가장 적당한 이름을 명명하는 것으로 그 의미가 명확해지며 이해하기 쉬워집니다. 이 경우에는 판매 엔티티에 있는 판매단가어트리뷰트는 내용상 '판매시단가'의 의미이며 상품엔티티에 있는 판매단가 어트리뷰트는 '판매할단가'의 의미입니다. 즉 의미구조가 다른 것이지 중복이나 이력관리의 차원이 아니라는 것입니다.

말이 길어졌지만..

님의 경우도 상품타입의 명확한 이름을 찾아주어야 합니다.

그렇게 되면 상품타입의 논리적 설계기준이 확립되고 어떤 릴레이션과의 종속성이 핵심인지가 드러나게 될 것입니다.

더 자세한 내용을 아시고 싶다면...

구체적인 업무 케이스(일의 흐름 중심으로)와 주문관련 릴레이션들의 레이아웃을 올려주시면 좋겠습니다.(질문이 단편적이면 대답도 단편적이게 됩니다.또 다른 모든 분들이 님만큼 님의 업무를 알고 있는 것이 아니기에...)

엔티티를 표로 해서 드리고 싶지만 그리기는 좀 그렇고 다음과 같습니다.

일단 주문헤드와 디테일로 이루어 있습니다.

주문헤드는 주문전표와 거래처 코드

주문 디테일은 주문전표, 상품, 상품타입,단가,소비자가,부가세, 수량

이런식으로 되어있구요.

상품타입은 상품, 상품타입, 구성되는 상품 1

                  상품, 상품타입, 구성되는 상품2

이런식으로 되어있죠.

명세서를 찍을때 상품타입 엔티티와 주문 디테일 엔티티를 서로 조인해서 그구성도를 표시하죠. 실제 물건을 주문을 세트 단위 포장이라 안의 내용을 보지 않습니다.

상품타입은 세트로 구성되어 있고 고정된 구성을 가지고 있어야 하죠.

상품 및 상품 타입이 AAA-1 이이고 구성되는 상품이 B,A로 되어있으면 항상 고정되

어 있습니다. 어떤한 경우인지 모르지만 구성도를 작성하는 직원이 오타를 내서 하나를 빼먹거나 구성도를 잘못넣는 경우도 있고요. 또한 입고당시 정확하게 입력을 했는데 어떠한 이유인지 모르지만 구성도를 수정하는 경우가 가끔 발생을 하죠. 그렇게 하면 안되지만요. 수정에서 문제가 발생을 하죠.

너무 번번히 일어나서 주문당시 주문을 입력할때 주문디테일을 다음과 같이 수정을 했죠.

주문번호, 상품,  구성되는 상품1, 수량 1

주문번호, 상품, 구성되는 상품2, 수량1

이런식으로요. 그래서 상품 타입 마스터는 의미가 없어졌죠. 그런데 대신 주문 디테일 건수가 무진장 증가하게 되었죠. 이런경우 어떤식으로 해야할찌 모르겠습니다.

그리고 수정을 왜 하는지 저도 잘 모르겠고요.

왜 바꾸는지 알아내셔야 합니다.

담당자가 바꾸는 이유는(설계자의 의도와 달리 사용하는 이유)

실 업무를 전산화하다보면 얼마든지 생깁니다.

주로 이유가 설계자의 의도와 달리 추가되거나 한 부분에서 생기는 경우가 많으며...

대부분의 사용자는 보고서A에서 내가 원하는 대로 안나와요....

뭐 이런 이유를 댑니다.

그러나 그런 것을 잘 뜯어보면 설계 미스거나 원래의 설계의도를 벗어난 응용에서 기인하는 경우가 많습니다.

전산쟁이들은 주로 자신의 판단기준에 근거하기 때문에 업무를 형식적관계에서 파악하려는 버릇이 있습니다.(저도 마찬가지..) 이런 버릇은 업무의 실 내용을 몰라도 업무간의 형식적 관계만으로 설계가 나올 수 있는 경우가 많기 때문입니다...

그러나 업무를 내용적으로 파악하고(구체적으로 어떤데 쓰이는지... 전산화될 부분이 아니어도 업무는 전산화와 무관하게 선 파악 되어야 합니다.)보면 분명히 설계자의 의도인 상품타입과 사용자의 생각대로의 상품타입에는 차이가 있을 겁니다.

그걸 알려면 도대체 왜!!!! 하지말라는 짓을 하는지.... 상세히 알아보셔야 합니다.(땜빵하시지 마시고)