Re: Normalization, Natural Keys, Surrogate Keys
Date: Thu, 16 May 2002 20:46:00 GMT
In article <c1ec9b8f.0205151525.6dce24d2_at_posting.google.com>,
> 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
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: 123tiseo.paul_at_123mayo.edu (drop the numbers) Received on Thu May 16 2002 - 22:46:00 CEST