Re: Normalization, Natural Keys, Surrogate Keys

From: drop the numbers <Paul>
Date: Thu, 16 May 2002 20:46:00 GMT
Message-ID: <>

In article <>, says...
> Unfortunately, I firmly believe the company is
> blowing smoke and has sent us a bunch of ERD's, UML's and various
> descriptions of data theory. (There are no screen descriptions or
> workflow items.)

        Are these things forthcoming? I usually establish a first-pass at a data model first, with some use cases, with the intent of getting to a requirements list, with some process modeling coming in a second iteration, with data model and use cases mods.  

> The database being proposed for this applicaiton is Oracle. Fine
> enough. (I prefer MS SQL or MySQL, just because I'm used to them.)

        Watch out. Might be overkill. I find that it is too common to see Oracle prescribed for projects that could get away with much less. The same occurs in Java Application Servers. In fact, Gartner put out a report on this very issue a few months back that might be ammo you can use with upper management.  

> The document went on to say, "natural keys are necessary to determine
> functional dependence and the efficient normalization of the the data
> model."

        Actually, neither is "needed" in a conceptual modeling exercise, although it is natural in ER to put either in at the same time.

> To make matters worse, they later describe the use of a "code table"
> to store various codes. This is something I've often seen in IMS and
> various btrieve-based databases and I don't believe belongs anywhere
> in a relational model.

        IMO, it isn't proper relational modeling. Do they have a reason for it?  

> Can somebody please comment on this? Am I totally wrong?

        No. You raise valid flags that should be explained by the contractor, if only for your own piece-of-mind.

(Any opinions expressed are strictly mine only and not my employer's)

Paul Tiseo, Intermediate Systems Programmer Reply To: (drop the numbers) Received on Thu May 16 2002 - 22:46:00 CEST

Original text of this message