Chris,
I do not see a description of the change the modelers have specified in your
message, so I will assume the oneway.pdf file is your design and the twoway.pdf
is theirs.
Their model does have a much simpler layout (fewer table joins), but a much
greater likelihood of data duplication and consequently error. I can easily see
the same customer having multiple records therein with different rules on how
their claim is handled. That may in the end run cause a nightmare for your
client not to mention a lot of egg on the face. Of course you'll be gone then,
so you won't have to live with it.
This is one of those cases where I would document your concerns and the
potential consequences thereof and submit that to damagement, also keep a copy
for yourself in the 'Pearl Harbor File'. Then do as they ask. Yeah, I know
it's dumb, but what are you as a consultant/contractor going to do?
Dick Goulet
____________________Reply Separator____________________
Author: "Grabowy; Chris" <[EMAIL PROTECTED]>
Date: 7/24/2001 7:51 AM
I am currently on a project where I have pretty much completed the
logical/physical models. Since the client has there own data modelers, they
have reviewed the models and wanted specific changes. I have agreed with
all there changes except for one. I have tried to explain why this change
would not be prudent, but they have insisted. To ensure that there change
is enforced they went to there management and have now placed there change
into the project requirements. Thereby, forcing us, the contractor, to
implement this change into the model. I have run this change by several
different people and they agree that it should not be implemented. I am now
looking for feedback from the list. If you are willing to provide feedback
then please read on...
This is a claims system. A mailed package was not delivered or is damaged,
so the customer files a claim. Every claim consists of the mailer's name
and address, and the addressee's name and address, plus some other
information. Aside from the average consumer, a Business Mailer(BM) can
also file a claim. The BM has a special agreement with the client and gets
special treatment when filing claims, and therefore a Business Mailer
profile is created.
Originally, I was going to describe the two versions of the model, but
decided to post PDF files of the model on the web. The ERDs are accessible
by clicking on the links below.
One way
-------
http://www.geocities.com/christophergrabowy/oneway.pdf
Two way
-------
http://www.geocities.com/christophergrabowy/twoway.pdf
Both models have a claim table, which contains all the miscellaneous claim
information.
Both models have an address table. Oneway.pdf separates the BM addresses
out, because they are not related to a claim. Twoway.pdf puts all the
addresses(claim addresses and BM profile addresses) into the address table,
and also includes the customer name fields.
Both models have a customer table. This is were the majority of the dispute
revolves around.
In oneway.pdf, the customer table contains the customer names(mailer and
addressee) that were submitted with the claim, it's PK is the claim_id. The
Business Mailer profile is not directly related to a specific claim, so it
is put into it's own table(a BM profile table), it's PK is the BM agreement
number.
In twoway.pdf, the customer table contains the name of the customer that
filed the claim, and the Business Mailer profiles. Since these types of
data use different fields, then the "top part" of the customer table
contains the customer name fields, and "bottom part" of the table contains
the Business Mailer profile fields. And since either part of the table
could be filled out, all the fields are null. Finally, since there is no
natural PK for the combination of these two records types, a synthetic PK is
generated.
If anyone has any questions then please don't hesitate to ask.
Again, any feedback would be greatly appreciated.
MANY THANKS!!!!
Chris
"May Oracle be with you...always"
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Grabowy, Chris
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
