Re: VIEWS compared to Nodes as Windows into data

>"x" <x-false_at_yahoo.com> wrote in message news:40923df6$1_at_post.usenet.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c6m06j$r1h$1_at_news.netins.net...
> > Given a database application implemented in an RDBMS with 632 tables
where
> > we want to give Pat an online data catalog from which to shop for data
> > values by way of metadata, we would likely provide a set of SQL VIEWS,
> > correct?
>
> SQL VIEWS are the SQL DBMSs equivalent of derived relations.
> An user view of a relational database is the USER SCHEMA.
> An user schema could be made of many base and/or derived relations.
>
> > I have concluded, perhaps incorrectly, that the number of "windows into
> the
> > data" (VIEWS) for Pat would be considerably larger than, say, the number
> of
> > filing cabinets that Pat might have had to use to get the same
information
> > in the past. This is so that the user can see the data from a variety
of
> > perspectives, is not limited to a single filing cabinet when viewing the
> > data AND so that the VIEWS can help optimize performance for various
> reports
> > (those that use table XYZ and those that don't, for example).
>
> Are you saying that there is a problem with RDBMSs
> because of the need of an user schema for each perspective on data?
>
> > If viewing the data in a data tree through a particular node, where you
> are
> > really navigating and not joining sets, there is no additional overhead
> from
> > any given view if you can see fields from XYZ through that view and
don't
> > use them. So, conceptually, the user asks questions of top-level nodes
> > which would be roughly the same as the named filing cabinets, with the
> > exception that through these windows into the data values, the user can
> > choose to see values from anywhere to which one could navigate. [Note:
> The
> > user need not DO the navigation as the vocabularly for the node can be
> > extended to include any data to which one could get from this node.]
>
> What made you think the joins are actually performed when you define a
view
> ?
> Maybe the joins are not performed until you actually use those fields.

Yes -- good --that might be the question I should ask -- if one creates a view that joins in table G and then Pat queries against this view and includes no columns from G, does the join get executed? I would think that under certain conditions the join would be required, such as in the case of an inner join where there would be more rows if the join were not performed. But do current RDBMS's figure out when they don't need to include the join bz they know (how?) that the join will not result in a different row set and there are no attributes from table G in the query against the view?

Thanks in advance. --dawn
<snip> Received on Mon May 03 2004 - 18:19:40 CEST