Re: In an RDBMS, what does "Data" mean?
Date: 15 Jun 2004 02:23:36 -0700
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:<cal43i$8f4$1_at_news.netins.net>...
> "Tony" <andrewst_at_onetel.net.uk> wrote in message
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > > Combination of metadata and data that is designed out of the relational
> > > model, such as orderings, and attributes with cardinality > 1 that are
> > > trimmed back to 1 for the relational model.
> > >
> > > Did that help or am I digging a deeper hole? --dawn
> > Yes, you are. Well, at least you are wrong. The relational model
> > doesn't force you to "design out" anything.
> No, it rather encourages it, however.
I wouldn't say "encourages". It "enables" it for sure: if the ordering of values is unimportant you are not forced to retain it. If it is important, you are not forced to retain it either, true. The database designer does have to THINK because the relational model gives him/her this choice.
> > If an ordering is
> > required, then the relational model requires that you state it
> > explicitly via an additional attribute, that is all. Attributes with
> > cardinality > 1 are moved to a separate table by the normalisation
> > process - again without loss of any information (not even
> > "meta-information").
> Ye-es, but, have you seen corporate implementations of the relational
> model(ish)? I'm particularly fond of those implementations where a single
> value is turned into a multivalue with the application developer coming up
> with a proprietary delimiter for a specific field so they can parse it.
> There are more instances when work is done to try to come up with single
> scalar values when multiples would make more sense.
Yes. So perhaps an RDBMS is less "idiot proof" than some other DBMSs. My preference would be have educated database designers designing the database, rather than ignorant aplication developers doing it. There really isn't that much to learn: the rules of normalisation can be taught in a day, surely. Received on Tue Jun 15 2004 - 11:23:36 CEST