Re: Pizza Example

From: Dawn M. Wolthuis <>
Date: Mon, 12 Apr 2004 11:20:38 -0500
Message-ID: <c5efl5$eel$>

"Eric Kaun" <> wrote in message news:p4zec.53523$
> "Dawn M. Wolthuis" <> wrote in message
> news:c51s04$clg$
> > The way that PICK query statement piggy back on each other is through
> > are called SAVEDLISTS or SELECT LISTS where you can select sets (yes, in
> > this case precise) [or occasionally bags] of identifiers (key values or
> > values of any other attribute) that are then "passed into" any other
> > statement (without its knowledge) thus narrowing down the records that
> > available for the query.
> By bag do you mean a set with true duplicates?


> If so, what does it mean if I
> pass an ID like SS# = 123-45-6789 more than once?

I don't actually recall whether dups are ignored or whether they are "in there" multiple times -- it is not a common thing to do.

> Or do you mean you can
> pass sets of lists? And if you do query for child name (for example) =
> {"Sam", "Max"}, is that treated as an OR or an AND?


> > > And yes, relation-value attributes are a sound logical basis for both
> > > reporting (e.g. "parent/child" reports) and outer joins - killing two
> > birds
> > > with one stone, if only the language support were there...
> >
> > yes, it is almost enough to bring me back to relational theory if the
> > implementations of the model didn't push me away again
> It's a little difficult to argue with someone doing the non-relational
> "thang" when the existing SQL implementations are so lousy. Hopefully
> will give Dataphor a try (though I have to myself), or another one
> more come along).

I plan to at some point -- so much to do, so little time...

> > > > PICK idenfies whether data is physically stored or is
> virtually-defined
> > at
> > > > the field level, not the table/file level. So, all descriptions of
> > file
> > > > are "views".
> > >
> > > But isn't there usually a primary one?
> >
> > No -- there is no way to identify any primary one if there are n logical
> > "dictionaries" for a file. You might guess that if the dictionary name
> > based on the file name, then that one might be the more heavily used,
> > maybe now.
> I would venture that in 99% of cases there's a primary one, at least for
> one given field / attribute. Otherwise your data truly has multiple
> meanings, and that can get very hairy trying to serve more than one
> master... not to mention confusing.

Yes, typically it is easy to tell what the primary dictionary for a file is, but, in theory, there is no such thing as a primary dictionary. The dictionary is descriptive, not prescriptive, and has such things as a display length for a data field. So, even when there is a single dictionary, there might be multiple definitions for a single field -- one to display the field as left justified text and another to display it as right justified numbers (for example for an all-numeric idenfier field). If you use one, you have numeric operations you can apply to that field, while if you use the other you are working with character functions.

> > Some might think it unfortunate, but logical dictionaries for a file
> > describe all stored data or only derived data or any combination. AND,
> they
> > could be used (rarely these days, but there are plenty of 20 year old
> > applications IN USE today) something like card decks were in the old
> > (but without the field lengths) where you have an "M card" and then a "T
> > card" so that I know of a popular PICK application that holds people and
> > companies in the same, uh, file on the disk using separate schema
> > definitions (logical dictionaries).
> With an attribute that defines what a given record is? How would you avoid
> looking at a people record using a company schema, and vice versa?

Yes, that is where some of the very old-fashioned "M Card" thinking comes in - there has to be a way to tell that is stored so that you can read the r ecord and then determine what "template" (dictionary) to apply to it. This could be useful in cases such as one that someone mentioned a while back where you want to store "drafts" of the data until it is finally cleaned up enough to "publish" it as the actual data. You don't want to apply a template that treats a number as numeric until you know the data is cleaned up to that point, for example.

> > > I'd say it makes reporting data easier, at least as long as the
> > multi-value
> > > attributes are only used for display. Most such attributes I've seen
> start
> > > to acquire "intelligence" (e.g. establish themselves as more complex
> > > propositions), make a relation for them almost a foregone conclusion.
> >
> > Although one could say that about just about any attribute, whether
> > or multi-valued. We could put each in a separate base table with
> > keys and all ... sorry for typing that, but ... smiles. --dawn
> Actually, if you do a search for "binary relations", you'll find something
> just like that - a model where every relation is a pair: (key, value),
> value is for a single attribute. Constraints are then required ("even more
> so") to maintain the consistency - in effect combining binary predicates
> into N-ary ones. The N-ary ones communicate better to people, of course,
> are equivalent (I believe - I'm no expert) to the binary ones plus
> constraints.

Yes, in fact you can think of PICK as key-value pairs with some added built-in functions that can be applied to that "value" to split it out into separate values. However, the constraint logic is not declarative and must be "hand-coded" so to speak whenever it is not built in. One good thing is that when children are nested within parent files, the constraint IS built-in. If you remove the parent, the children go with it, for example.

--dawn Received on Mon Apr 12 2004 - 18:20:38 CEST

Original text of this message