Re: Pizza Example
Date: Wed, 07 Apr 2004 20:14:18 GMT
Message-ID: <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 eliminatethose. If I'm doing the same listing for a particular individual, for example, then the name need not be in the output at all.
> 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.
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...
> 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? 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.
> 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.
> 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.
> 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.
> 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.
- erk