Re: Pizza Example

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:uiZcc.9250$JF5.3816_at_newssvr32.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c518r5$lqk$1_at_news.netins.net...
> > <snip>
> > > Over what other operations are Pick data structures closed? Or rather,
> > what
> > > Pick operations are closed over its data structures?
> >
> > Eric -- because there is no such formalization of the PICK structures as
> > there is with relational ones, I'm being very imprecise here to the
extent
> > that I would call this an eyeballing feature -- if you write a SQL
> statement
> > and see the output on the screen, the output is 2D and includes
repeating
> > data.
>
> Imprecise is fine - I wasn't baiting you on the absence of a formal
theory.
> I was genuinely wondering to what degree you can take the output of Pick
> selection/listing and use it as the basis for another statement/query. In
> the case of SQL, I agree the attribute values repeat (depending on the
> query, of course, and assuming you're including "parent" data with "child"
> data), but would argue that those represent separate propositions
(composite
> ones), and that it's the duty of a reporting / output tool to eliminate
> those. If I'm doing the same listing for a particular individual, for
> example, then the name need not be in the output at all.

The way that PICK query statement piggy back on each other is through what 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 are available for the query.

> > For example: SELECT NAME, MAJORS FROM STUDENT_MAJOR_VIEW;
> >
> > might yield
> >
> > Davy Jones Philosophy
> > Davy Jones Mathematics
> >
> > There is no base table that is modeled with the name "Davy Jones" stored
> in
> > it twice, but a query on the view yields this output.
>
> Right - just what I was getting at. There's a difference between the
logical
> structures to be manipulated, and the output to be generated - more than
> just the above, too. I consider SQL an ugly amalgam of pseudo-relational
> notions and reporting notions, which serves neither well.

agreed.

> 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

> > PICK idenfies whether data is physically stored or is virtually-defined
at
> > the field level, not the table/file level. So, all descriptions of a
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 is based on the file name, then that one might be the more heavily used, but maybe now.

> Or rather, are there actually cases
> where there are two views, either of which could be considered primary? Do
> they differ primarily in how they view one or more attributes - or omit
> them, or add calculations? Just trying to get some ideas of usage.

Some might think it unfortunate, but logical dictionaries for a file could 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 PICK applications IN USE today) something like card decks were in the old days (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).

> > Queries on these yield results that look just like base
> > tables.
>
> I agree they look like them - but can they be used in all the places a
base
> file can? In relational the answer is yes - in SQL no.

No, unfortunately not.

> > The user just asks for fields from a given file -- the data could
> > come from anywhere (which is why I call the file descriptions views --
> they
> > would not be considered such from a SQL standpoint).
>
> Well, in SQL you can define views which pull data from several tables.

That is one big issue with PICK -- whether and how you can put data definitions from multiple dictionary "vocabularies" in one query is vender-dependent where the "standard" in the language is that you keep adding vocabularly to each logical dictionary and you use the vocabulary of the dictionary for any query against that dictionary (logical file).

> > If you ask for the
> > same data from a PICK file that we requested above you might ask: LIST
> > STUDENTS NAME MAJORS
> >
> > to get
> >
> > Davy Jones Philosophy
> > Mathematics
> >
> > The output looks like one record, just as the input for this information
> was
> > one entry from the end-user perspective. Obviously one can do gyrations
> and
> > have output from a relational database imitate the natural PICK way of
> doing
> > things, but it is not the natural way that SQL/relational databases
handle
> > data.
>
> I've defined functions in SQL for reports, to enable something like SELECT
> name, major_list(id) FROM students. However, that's a reporting function,
> not a data management one, in my opinion. A DBMS that returned a
> relation-valued attribute, and a reporting tool that could handle same,
> would let you do much else besides.

Yes -- SQL Server permits lists in user-defined functions where Oracle does not (if I recall correctly).

> > This is just that 1NF thing cropping up again. It seems like such a
minor
> > point and yet it can really make a significant difference in how easy it
> is
> > to establish and maintain data. --dawn
>
> 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 single or multi-valued. We could put each in a separate base table with foreign keys and all ... sorry for typing that, but ... smiles. --dawn

> - erk
>
>
Received on Wed Apr 07 2004 - 23:31:44 CEST