Re: Entry Points to the Data

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c9smih$j0p$1_at_news.netins.net...
> Starting a new thread re Eric's question "What about the users with other
> entry points?" when talking about how users might retrieve data through
any
> relation or through a simplified set of "portals".
> [...]
> the department store sets up departments (portals,
> namespaces, entry points) so that you don't have a choice but to use their
> classifications. And THAT'S A GOOD THING!

Agreed.

> The relational model attempts something like this, with the concept of a
> VIEW to show a logical picture of the data that is different from the base
> relations. However, these views are typically only constructed when the
> need arises.

Huh? a) not true in my experience, and b) irrelevant to their utility for other purposes

> If some are designed up front, they are often rewritten to
> eliminate various unneeded tables for specific reports (from what I have
> seen, which is not a huge base).

They're used typically to further abstract for the benefit of reports and queries. Well, that's one use at least that I'm most familiar with. Some other useful options are functions in the DBMS...

> I'm working on this namespace/portal/entry points/views angle because it
> appears to me that this is one area where SQL-DBMS's have largely failed
and
> could learn from other models (e.g. PICK). The VIEW notion not only
doesn't
> get us there, it seems unlikely it ever will. Defining these portals as
> logical departments with behind the scenes definitions like "if I start in
> this physical department what is the navigation path to grab this data for
> the customer when they ask for it" has a different kind of elegance than
the
> defined view of "here is now the set of everything the user might want in
> this logical department" -- that department is big and unweildy to query.

I'm not sure what you mean here - users can select what they want from a view as well.

There is one big difference: for applications, it seems useful to provide something nested, which represents a "thing" (a hierarchy) that a user wants to work with. Different users want different hierarchies, which is why the relational model as a logical foundation makes sense. I'm starting to think that the relational and Pick/MV folks have been arguing apples and pears, to some degree.

> It might be the case that a SQL-DBMS user could set up these departments
> with the proper groupings in advance to simulate this approach. I've
tried
> it and the biggest problem comes in performance tuning but there is also
the
> problem of just what the set looks like -- if the view includes
aggregations
> to simplify the department, then it loses detail. That isn't the case
with
> a PICK approach simply because you don't need to do the aggregation -- if
> you define your portal to start at Person, for example, then you can pull
in
> everything related to Person

Not necessarily everything, just what you've defined as relating to a person. In other words, if you think of a relational model with many links all around, you could obviously go round and round in circles if you felt like it - a Person could eventually link to every "file" in the database! However, you typically define a path: from Person to their job history to the details of the jobs, and stop (rather than going on to accumulate other people who have held those jobs, department heads, etc. etc.). But keep in mind that's a very (usefully) restricted view of the data.

> and any query the user does will not explode to
> more than one returned "line" (not quite a row, because there could be
> multiple majors for a student, for example, that would take multiple rows,
> but not duplicate the rest of the data -- it's that dimensional thing).
The
> only way the user gets multiple lines per person is if they request the
data
> to be exploded so that you do get a second line for a second major.

Another interesting part is drill-down - what happens when the user wants to go further. It sounds like you'd write more functions to access other files and their attributes, which essentially layers functionality on top of a (potentially) relationally-normalized model.

> Right now this is a big issue for me, while it is possible that someone
> could show me how the relational model can do something that to the user
> looks the same. I just don't see it at this point. Cheers! --dawn

While I still have no doubts about the relational model as a logical foundation, there are clearly useful application-specific logics, which may be generally hierarchical, that I could see layered on top of that. Updates are tricky, of course - the above refers only to queries. What happens when the user wants to update something that is derived using a function? I assume in Pick it's non-updatable?

• erk