Re: Normalization, Natural Keys, Surrogate Keys

Kai Ponte wrote:

> Hmmm, you'd think that maybe somebody at this company woul've had some
> design classes. I believe this is System Design 101. :) Yes, they
> should've included all of the above and more, but haven't.
> Particularly when the project is costing around $80 million a year.
> As for a project plan, well...
>
> Anyway, they've indicated that because they're doing an "iterave"
> approach that they don't need detail design or requirements. Somehow
> the non-technical officals paying the bills have bought into this
> flawed concept.

Heh. Iterative approaches can work, if you're prototyping or doing Rapid Application Development (RAD). However, for a project this large, a phased approach, where individual subject areas or processes are migrated individually may be better. Regardless, not needing a detailed design or set of requirements is just a consultant's way of saying "Don't worry. If the system doesn't satisfy your needs, we'll be glad to fix it for you for $XX millions." :-)

> > Has the consulting firm made an effort to look at the existing data?
> Yes, they've done countless hours of data mapping. However, they've
> spent relatively little time understanding the business processes.

Be careful here. When I mean looking at the actual data, I don't mean trusting the IMS segment definitions and mapping from there. I'm talking about extracting the data into either flat files or a staging database and analyzing the content and quality of the data. Once you understand the data, then you can create a model that you know will work with the existing data or map to a fixed target based on the data. Without this, the consultants (or more likely YOU), may spend countless more hours massaging the data or the mappings to fit data you didn't know was there.

> > You mentioned the mainframe. What is the mainframe DBMS?
> IMS
I still recommend extracting the data and profiling it before agreeing to the data model. You don't know if you can migrate it successfully. Current profiling tools can help you extract the data as well, so you don't have to spend as much time coding extract programs.

> > A table of code tables can be used to more efficiently manage critical
> > sets of values. But this is a design issue, as opposed to a data model
> > issue.
> I can see your point here. Thanks.
>
> Thanks for your assessment. I just had to hear something from a
> third-party.

> KP
Received on Thu May 16 2002 - 11:18:40 CDT