Re: Base Normal Form

Eric Junkermann wrote:
> In message <1121202113.304417.98600_at_z14g2000cwz.googlegroups.com>, dawn
> <dawnwolthuis_at_gmail.com> writes
> >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
> [snip]
> >our design needs to accomodate this sharing of "memory".

>

I'm with you there.

> What I am saying is that if you use data in a
> certain way you will tend to bundle it in that way, even if you are
> trying to be flexible,

Yes, I completely agree.

> so the best bundle is an open bundle, which will
> have different ways in.

That is a bit vague. It is best to weigh the options and risks for various approaches.

> [snip]
> >There are tradeoffs to constraining the length of a field, for example,
> >and allowing any length.
>
> but this is a physical issue,

I don't think of the conceptual data model as having such constraints in it, but I do think of such constraints being in the logical model if such a constraint is required.

> an implementation issue, not a design
> issue, the logical data design does not care.

Hmm. If our current business logic is that our product codes are a maximum of eight characters, then I would think that would be a constraint in the logical design, no?

> [snip]

>

I guess not, but it is only relational theorists that I have heard suggest that data be considered outside of any context (I might not be saying that right, so perhaps you can restate your original point in your own words?)

> ETL happens because data is the wrong "shape", the type of system it is
> stored in is not the main problem.

I agree with you on the "shape" issue. The systems I have seen that do not end up forcing customers into data marts to the hilt include more operations than just relational ones & permit more complex data types than simply relations, thereby providing what I would see as more "shapes" for the data. That was my point.

> Given similar needs, the ones that
> do the least ETL are those with the most flexible data design.

Yes, and those I have seen get some of that that flexibility from not being tied to only the relational model.

> Maybe I shouldn't have dragged ETL in, but my main point remains that
> data independence is a good thing -

There simply is no such thing as useful words (data & metadata) without context.

> which is where Codd came in, whether
> you like his answer or not.

I could be wrong, but I don't think that was the point of his efforts. Codd modeled sets of propositions as relations and worked with set operators and such, thereby introducing some much needed formalism. Don't get me wrong, that was definitely a good thing.

My point is that if you have a business domain that you are modeling, you need to model the data from front to back in this system in line with the known requirements. You should identify risks by understanding what you are modeling.

So, for example, if you model a toenail as if it were a property of a person, it is a good idea to be aware whether that toenail can still be a toenail without a person anywhere around. It is the risk assessment that should determine whether or not it is wise to give individual toe numbers their own identity and prepare a relationship between people and toenails rather than making toenail an attribute of person. There is obviously a cost in doing so and all involved parties might consider this toenail situation and deem it to be so unlikely that the owner of this application asset would ever care about the toenails after they have been clipped or torn off a person that there is no reason to model them as anything other than a property of the person.

Does that explain my position in a way you agree with or do you still think you can do some "data in a vacuum" (my words, not yours, so feel free to correct my understanding of your position) type of modeling?

cheers! --dawn

> Regards,
>
> Eric
> --
> Eric Junkermann
Received on Thu Jul 14 2005 - 19:17:32 CEST