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".
>
> I like my department stores to have departments in them so I can shop for
> items in the department I would think they would be in. Then if I don't
> find them there, I can look at the directory or wander around or ask
someone
> and find them in the classification the store decided on. Even though
> someone else might be looking for shirts and not care whether they were
> men's or women's shirts, 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!
>
> 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. 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).
>
> If, on the other hand, we provide the analogy to a men's department,
women's
> department, etc in our data, it might include departments like People,
> Organizations, Products, Courses, Doctors, Students, ... And, come to
find
> out, this makes perfect sense to users of the data when trying to retrieve
> it. These are logical, not physical views of the data. For each of these
> entry points, the user has a list of the vocabulary for what they can
query.
> The user doesn't have to think about grouping and ungrouping in any
> not-so-intuitive way in order to combine rows so the query returns one row
> per person, for example (if you are tracking with me, that will make
sense,
> else ask). They simply ask for those data they want and if this
department
> doesn't have what they need, they pick one of the handful of others and
look
> at the vocabulary (attributes) in those departments to see which to use
> instead.
>
> 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.
>
> 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 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.
>
> 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

This notion was implemented years ago in many reporting tools. For example, Cognos Impromptu has something called a "catalog". The catalog contains all of the joins necessary to connect all of the tables in the database that make sense to be joined and have a means of joining together. In other words, a superset of all possible views.

The catalog is created by someone who knows what the business needs are, what data is contained in the tables, and how the users need to use the data. This person, in Cognos-speak is the "administrator". This person may be a DBA, but doesn't have to be. The users then simply choose whatever columns they want from any table, apply whatever query constraints they want, and bingo- a report is created. In some cases, more than one catalog is needed as on occasion the same tables may be joined in different ways to support different business needs.

The catalog provides other rules as well. Optimization priorities can be specified, outer joins and/or Cartesian products premitted or disallowed, maximum number of rows returned, maximum processing time (to prevent runaway queries) can be specified as a warning or hard cutoff. Specific aggregates may or may not be specified in the catalog, and the users may or may not be given permission to create their own. There is a rich list of functions that may or may not be made available to the users. Catalogs can be varied to give permissions to the more sophisticated users, and denials made for the more naive users. Certain tables can be permitted or restricted. It is all very flexible.

Note that this is not an RDBMS implementing this notion, but the notion conforms to all relational rules, and is essentially platform independent. Received on Sat Jun 05 2004 - 17:17:46 CEST