Re: Data Display & Modeling

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c7e3hr$t0c$1_at_news.netins.net...
> Let's say that someone likes to model data as functions [e.g.
> PERSON(key)=tuple], in non-1NF and in di-graphs (so you can navigate your
> way through it), with a target implementation in XML or PICK.

Uh oh... segueing into implementation already, after only 1 sentence? :-)

> I have heard
> people say that is a good way to "view" the data, but we need to model it
> using relational theory.

To act as devil's advocate, why, given your intentions above? Every function is a relation, though the converse isn't true.

> Given:
>
> 1. that there is a good non-relational way to view the data, such as one
> using di-graphs with functions on strings.
>
> 2. that relational theory provides us with a loss-less decomposition of
the
> data.

Are you talking specifically about decomposing those tuple attribute values that aren't scalar? If not, then the above is simply a sort of definition of primary key.

> 3. that we can mark-up the di-graph with information to permit automatic
> normalization of the data, so that we could switch between these two
> "pictures" of the data (O-R mappings, for example)

What sort of markup? I'm unclear what you mean here.

> Then, these two models are just two pictures of the same data and one
could
> pop back and forth between them.

The pop can only be 2-way if you assume the functional stance above as the basis, which is of course more limited than the stance of relations...

> Then the software/database developer could view the data model either way,
> and, therefore, never have to bother with relational notation at all.
>
> 4. Now figure that relational theory is not related to the physical
storage
> of the data.
>
> Then there is no reason to even add the notations to switch between the
> di-graph and relational provided that everything the system needs to store
> the data is provided in the di-graph "picture" -- there just needs to be a
> mapping between the di-graph and the physical model, which can be
optimized
> for machine processes (therfore, likely NOT relational!)

1. optimization is easier under relational theory than under other theories (and pseudo-theories); SQL != relational. Then again, since relational isn't physical, not sure why this statement is important or meaningful
2. "Everything the system needs to store the data" isn't the point - the point is (or was anyway) a good logical structure

> Therefore, I see no reason for that R part in any aspect of the system,

But you seem to want to deliberately exclude it, based on preference. If you're hinting that relational isn't needed to store data, you're right - all that's needed is a physical medium.

> other than (recent) tradition and the fact that a ton of data has been
> (unnecessarily)

But usefully.

> placed in 1NF. If the application of relational processes

Normalization, I assume?

> were really loss-less, then the data could be viewed the way I like to see
> it (but, alas, while non-1NF databases have no problem showing themselves
as
> if they were relational, the reverse is often not the case).

?

1. A relational scheme in 5NF/6NF can be viewed in many ways. Each of those views hides something, though the scalar values can be manipulated in such a way that they can be used to reconstitute the relations. One advantage of relations is that you can generate arbitrary hierarchies / views / reports / etc., and without a lot of work. Egalitarian, which admittedly makes an app-specific view more difficult (at least some of the time). If all you have is 1 output function, then anything will do.
2. What relational "version" of data has trouble showing itself as a non-1NF database? You mean the ordering discussed elsewhere, or is there something else? I would argue [again] that the attribute violating 1NF (e.g. the list in a tuple) must be exceedingly simple (e.g. a list of textutal items which no additional structure) for that "logical" 1NF expression not to have negative consequences.

> I'd like to see diagramming tools for data modeling to specify data in its
> more conceptually simple format of propositions as functions that need not
> be in 1NF, showing foreign key links and such -- a web of data.

A web (whatever it means) is simpler? In any event, I've heard relational schemas described as webs, and as a complaint against it. Hmmm.

> I have an appreciation for the relational model set theory and I think
2nd,
> 3rd, and 5th normal forms are useful (when not defined in terms of 1NF),
but
> I have very little use for the relational model outside of that

This is very confusing, since above you claimed to want to not use relational notation at all. Relational notation is orthogonal to normalization.

> -- certainly
> not for any human to and from computer nor computer to computer
> communication purposes. And my appreciation for SQL is almost completely
> related to the fact that it has given us some industry standards that are
> used extensively. It is a language begging for retirement.

Agreed.

> I'm not sure that there will always be a need for the "R" in O-R mappings
> and that would certainly save both human and computer processing cycles.
> You can figure I'm just ignorant (if that helps you in some way), but I
have
> not yet SEEN enough of what the R gives the IT profession to justify it
and
> it sure has cost us a bunch.

One could just as easily state that incomplete adherence to R has cost us a bunch. It's difficult to analyze costs of a model when the limitations of implementations of that model (which SQL at one point claimed to be) have obvious and well-cited downsides.

• erk