Re: Data Display & Modeling

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:409d3e6c$0$65124$e4fe514c_at_news.xs4all.nl...
> Dawn M. Wolthuis wrote:
>
> > mAsterdam wrote:
> >>Dawn M. Wolthuis wrote:
> >>
> >>>Therefore, I see no reason for that R part in any aspect of the system,
> >>>other than (recent) tradition and the fact that a ton of data has been
> >>>(unnecessarily) placed in 1NF. If the application of relational
> >>>processes 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).
> >>>
> >>>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.
> >>
> >>Could you please refine a little on what's wrong with 1NF ?
> >>
> >>I take 1NF to mean:
> >> a. no duplicates
> >
> > If you work with functions (as a type of relation) this is automatic --
you
> > map a key to a tuple -- so count me in on this one.
> >
> >> b-1. no internal structure in attributes
> >
> > Complete disagreement on this. The purpose of this, as best I can tell,
is
> > to keep the model as simple as possible (but no simpler). But
> > mathematically simple and conceptually simple are not the same thing.
So,
> > even if you have to map the more mathematically complex, but
conceptually
> > easier, approach of permitting types with internal structure in your
model
> > to the relational model for some reason, it is worth it. A significant
> > number of relational theorists seem to now permit attributes with
internal
> > structures, at least relation-valued attributes now.
> >
> >> b-2. no lists/array attributes (MV)
> >
> > This follows from the previous one -- once you have no problem with
> > non-scalar types, lists are fine.
> >
> >>You have been talking a lot about b-2, but what about
> >>a and b-1 (or aspects I've missed) ?
> >
> > I accept a and pour b-1 and 2 together.
>
> Ok. Clear enough.
>
> What would be an approprate name for this construct?
> Not "relation", as that would prevent any sensible dicussion.
> I could not think of one yet.

Yes, it is a relation and, in particular, a function. The model I'm working with has names as "descriptive" (and therefore synonyms are prevelent), allowing the ordering of the tuple to be what is fixed (and that fits with the def of a relation). Typing is also descriptive rather than the database employing types (even sizes) as constraints. This gives the builder enough rope to hang themselves, but also provides some freedom not available to developers in SQL-DBMS's.

> The only difference with a relation (or relational variable)
> would be that it's attributes would be allowed have an exposed
> internal structure, b-2 (lists) being a relatively simple case
> of that.

Yes, internal structure and also functions can be defined at any level and need not be only set-functions (or type functions). For example, you can have navigation functions and record (row-ish) functions.

> Say model H allows relations and these constructs.
> One preliminary thing: I suspect it is practical that
> we should be able to easily distinguish attributes
> as either atomic or structured.

We really only need to know what functions can be used on what, right?

> One approach is historical : Why the restriction?
>
> Anoter one is: Qualify existing systems as being more H-ish or
> more R-ish, and let the proponents brag about their qualities.
>
> Yet another one is:
> - what nice thing can't we do with H what we can with R,
> (or less absolute: what is more difficult), that is: what do we lose?
> - what we can we still do <duck> what nice properties does this
> construct inherit from relation </duck>
> - what nice thing can we do with H what we can't do with R?
> (or less absolute: what is easier), that is: what do we win?

Here is one nice thing that can be done with H -- a link could be defined without requiring a constraint. So, you can link to things outside of a centrally managed data source and if you navigate to the link and it is not there (because you can't control it), then you can simply let the user know that it is not there.

I'm in one of those not-thinking-clearly modes right now, however (this over 40 thing sucks!) so, I'll think about it more when I get my brain back. Time to do dishes or something now. --dawn Received on Sat May 08 2004 - 22:24:01 CEST