Re: Data Display & Modeling
Date: Thu, 13 May 2004 19:04:14 GMT
Message-ID: <OEPoc.2455$Ha7.869_at_newssvr16.news.prodigy.com>
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c7u49h$hb5$1_at_news.netins.net...
> "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.
Agreed.
> The definition of "function" in the cdt glossary covers the definition I
am using.
Ugh, can't find it - gone from my newsgroups. But again, unless that definition is totally divorced from math functions, what are the domain and range?
> > > 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.
Description is a nice byproduct of typing - but I assume you're talking about just a tag or label, rather than a real type? I suppose that's better than nothing at all, but far inferior to real typing. If you have application logic that uses Attribute X in some way, then that usage must be consistent with its values, or you've got the capacity for huge problems. Changing the type of an attribute is insane unless it's trivial and/or you have little code; cardinality is a slightly different issue that we've talked about...
> > 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.
Chlorine is useful, but I don't routinely swallow it. Types are meant to prohibit or at least strongly discourage certain classes of misuse. But I agree with you that a type system shouldn't be inherently limited.
> > 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.
And that's to Pick's credit.
> So, the POSSREPs have components, but the type Date doesn't.
No type has components, only operators that "return" logical "components". A type with components isn't a type - it's a type generator.
> It does have
> functions, however, so you can get the month as a logical consequence.
So,
> is Date atomic or compound?
It's atomic.
> 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.
SQL DBMSs? I agree there are bad implementations, but most of the problem was in representation-restricted ISAM/VSAM/etc. databases.
> > 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".
So our application logic now has to be written in such a way that we can't rely on any of the links really being there? I'm not sure in this case how the link is better than a foreign key. I certainly agree that some attributes can be URLs, but regard this as an intermediate step to some form of true integration, at least if we want to have a chance at implementing anything about which we can reason.
> 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
I understand, but am still unclear why you'd want this, and how the semantics of updates are to work in this scenario.
> 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.
Given the above, I'm not yet sure - it hinges on updates, to some degree.
> 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?
Yes, that's the confusion. In Java, for example, I can say Order o1 = new Order(). Then I have a variable o1 pointing to an Order value somewhere (it's a pointer because I can do "Order o2 = o1" and create another pointer). Exception that Order has variables as well, which are also pointers, or can be. It quickly becomes a dereferencing mess, and you'll find lots of papers on Citeseer detailing various ways to solve the "aliasing" problem. I think the Third Manifesto gives a much better account of the problem, its intricacies, etc. But you can find free articles by Date on dbdebunk.com. Of parciular interest is the old circle/ellipse subtyping argument...
- erk