Logically model never possible real world or my forever imperfect business?

From: OlegJay <olegjay_at_yahoo.com>
Date: 6 Mar 2003 09:58:58 -0800
Message-ID: <47d21956.0303060623.36b26a31_at_posting.google.com>

Please help me understand the proper 3rd Normal Form for the following simple Model.

If your new project has to live with old inefficient business rules do you logically model
(up to third normal form) the business with its limits it will always
live with or
do you data model an ideal world/business that it will never come close to?

When I get to the physical design and more complexities (such as resolving many to many
and including maintaining history) I'm sure I'll make chooses if needed that will
keep the design to the reality of my business rather than some standardized ideal world.

Just take as an example the real estate transactions recording business where "we use type
written documents as your input and have data entry people pick out transaction
info. and the system later accumulates it into a datawarehouse". This is very error prone and we
can't enforce all the constraints on all the various levels of human involvment to make
all the data come out perfectly. Its especially true that the historical records can
never be error corrected also. This is why the real estate business has Title Abstract
companies always doing research to ok everything.

Please help me understand whether I should logically model my business's real world
or the ideal world.

More specifics follow below.

I have a PARCEL (i.e., piece of land) and each PARCEL has one OWNER
(i.e., a person).

Therefore I think I should model my database as having two entities and its in 3rd normal form.

parcel id attribute			owner id attribute
parcel number attribute			ownername attribute

However my data source for parcels and owners comes from type written notes
and ownername could be coming to me mispelled. The same person may own
several parcels and each time his name could be mispelled differently.  Furthermore,
even after this database is constructed I will have no source of cleaning
ownernames up, so as far as the database knows it can not assume one 'JOHN SMITH'
is the same as another or if its the same as 'JON SMITH'.

My question is "For proper logical design and 3rd normal form, 1) is it right to leave the PARCEL and OWNER as separate entities or can I combine owners into parcels and end up with just one entity, since ownername are freehand? (I will always have exactly as many ownernames as parcels).
2) if I leave PARCEL and OWNER as separate and since ownername is not maintained cleanly (therefore there is a one to one relationship between PARCEL and OWNER), should/could I have the owner id U.I. be renamed and identical to the parcel id?

Another way to point out my problem is to think about a Blockbuster movie rental model.
What if I didn't hand out Customer membership cards (to determine) owners uniquely
and people just signed their names (with errors or short names at times). And several
people have the same name in the same family address so that won't help uniquely
identify the customer

Thanks in advance for any help. Received on Thu Mar 06 2003 - 18:58:58 CET

Original text of this message