Re: Data Display & Modeling

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:Orroc.367$uL5.198_at_newssvr33.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c7jflf$3dj$1_at_news.netins.net...
> > "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> > news:409d3e6c$0$65124$e4fe514c_at_news.xs4all.nl...
> > > 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.
>
> I don't see how the above is a function, as relations are N-ary, and (for
> example) can have multiple candidate keys.

I will be as precise as I can be then -- mathematical functions are a sub-set of mathematical relations. The definition of "function" in the cdt glossary covers the definition I am using.

> > 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.
>
> What value does it provide?

In today's buzzwords, it would be "agility" -- but I think of it as big bang for the buck and ease of maintenance.

> > > 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.
>
> In relational theory, all types can have functions defined over them. Not
> sure what's different here. A list's internal structure can be linked
list,
> for example, but its type has operations. The problem with a list is the
> usual: list of what? A list is a type generator, not a type itself.

I see no reason to disallow any useful types.

> > > 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?
>
> What difference does atomic and structured make? In particular, what can
one
> do with a structured type that one can't do with, for example, a string?
Or
> a date?

I'm not the one who makes the distinction, although I try to work with the distinction when others care about it. A Date in PICK is typically handled as atomic (from my perspective) and that is why pick shops had very little work with Y2K -- they weren't splittin' that puppy apart all the time, but were working with an odd "days since Dec 31, 1967" internally stored number that simply permits the type of arithmetic one does with dates. It can be viewed as MM/DD/YYYY or in any other format, but it is not stored that way. So, the POSSREPs have components, but the type Date doesn't. It does have functions, however, so you can get the month as a logical consequence. So, is Date atomic or compound? I don't care what you call it, but don't handle it the way SQL-DBMS's or at least DBMS developers have done in the past, resulting in the Y2K maintenance costs.

> 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 suspect that what you have here is a link type, and a function to
resolve
> that link to whatever's at the other end. That resolution could throw an
> exception, or return an EmptyResource or such.
>
> However, recognize now that you're in the usual OO value/variable
confusion.
> A link (say a URL) is a value. But resolving can return whatever's
currently
> "at" that target link, meaning it's sort of a variable. And you want to
use
> that sort of structure for all business data? What is such a structure
> especially good for? I know the Web gives us all visions of sugar-coated
> systems dancing merrily in lockstep, but I suspect that this is a "data
> structure" only from a very great distance that views the Web as a
database
> of stuff it doesn't care much about; which is to say, a distance few of us
> live near.

Consider a record (like a row) with metadata and data values as a single document of Type "Order" (for example). For each foreign key value in that record (each value of a variable specified as a foreign key), make it hyperlink to another document of a similar ilk, but different Type, say "Customer".

If you think in terms of functions, we have Order(www.mysite.com\orders\12345) =(resolves to/shows/brings up) orderdocument.xml (for example) and then CustomerLink(Order(www...))= customerdocument.xml

we are talking functions and values here, but could put it in terms of variables instead if useful. I don't see where an OO variable/value confusion comes in. I have had difficulty understanding that value/variable confusion except when using the term "object" and being confused whether it is mutable or not. Can you provide more clues on where the confusion lies with this?

--dawn Received on Wed May 12 2004 - 23:17:36 CEST