Re: Base Normal Form

Eric Junkermann wrote:
> In message <1121162228.113616.139680_at_g14g2000cwa.googlegroups.com>, dawn
> <dawnwolthuis_at_gmail.com> writes
> [snip]
> >> Same here. (Holistic this side of the pond)
> >
> >Terrific! I'm forever reading statements about how we must be sure to
> >model the data separate from how they will be used.
> >
> >--dawn
> >
>
> You are all programmers at heart,

I'll accept that.

> you are tricked by your need to
> process data into believing that it is yours.

but not that. What I will accept is that changes will be required and I need to mitigate those changes I think are most likely, using a risk assessment strategy. That includes changes that affect all aspects of this application including the UI, the business rules, etc. and changes that include other "services" needing to work with the same data or share any other aspects of an application. If one application needs to "remember" (in human terms) anything and another application arises that needs access to that same "memory" (again, human terms), whether what is being remembered is called "code" or "data" or WHATEVER, then our design needs to accomodate this sharing of "memory".

> What you are writing today
> may be the only application now, but there _will_ be another,

and you can bet that I know that -- this is a huge reason I'm doing the poking around. I don't buy everything the eXtreme A/D folks claim in designing and implementing only for what is in front of me and not looking past my nose, but we just might be going too far when we try to think of data as if it needs no context.

> and
> another... If you don't consider the data in its own right, you are
> guaranteeing high cost (or even impossibility) for all future
> applications that will want to use this data.

Nope, I don't buy that. If we don't have flexible software development languages, models, tools, etc, then we are guaranteeing high costs. There are tradeoffs to constraining the length of a field, for example, and allowing any length. The latter is more flexible, which might yield better quality of data over time as requirements change if the user doesn't feel forced to truncate information to fit their existing software. The former forces more conformity, which might provide better quality of data by a tighter definition and enforcement of todays constraints, with the (often false) assumption that if requirements change then our implementation will change concurrently. There isn't one right way, but some choices are better than others in a given situation and some are commonly better choices than others.

> To put it another way, data is the corporate asset,

agreed

> corporate survival
> means being able to use assets in new ways when required.

yes, indeed, but be sure you are looking at the whole picture and not just focusing on one at the risk to others.

> How much expensive ETL would we now need if data design had always been
> given a high priority?

Do you really think that most ETL is done because data are NOT modeled relationally? I suspect (but do not know) that more is done because they are (and, of course, also because of a need to fix data at a point in time in systems that do not have a time dimension built in). It might even be the case that those shops that do the least ETL are those who are not using SQL-DBMS's. I have some anecdotal reasons to believe this might be the case.
Cheers! --dawn

> --
> Eric Junkermann
Received on Tue Jul 12 2005 - 23:01:53 CEST