Re: VIEWS compared to Nodes as Windows into data

• Post for FREE via your newsreader 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.

> IF I have this right, this seems to me to be a significant issue for
> relational databases -- how to get simplicity for the user without them
> having to care about which view to use to get the best performance and
> without making a large number of views in order to have those with and
> without many different tables in the join. Or are there database
> implementations that help this situation in some way or best practices
that
> make this less of an issue than I am suggesting? Thanks. --dawn

The relational model is just a language that allows one to talk about the data in a database.
If you think there are problems with the relational databases, you may search for them in:
- the implementation
- the expressiveness and succinctness of the language

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

• Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=