Re: beginner's question

Hi Sandy,
  I have never thought of an Entity-Relationship (E-R) diagram from a graph theory perspective but I feel it will be nice to analyze it that way. I think that an E-R diagram at best can be a connected graph for those set of tables concerned with a certain application.

  Not all tables in a schema need to be connected and hence there can be vertices which cannot be reached from a certain vertex. For e.g., an application which requires employee and department tables will be totally different from an application which would store vertices and calculate the minimum spanning tree. Both set of tables can reside in the same schema but these sets need not be related at all. At best they can be disjoint connected subgraphs.

  In a relational database, the direction of the joins really does not matter to the best of my knowledge - I might be wrong. So, the graphs need not really be directed graphs.

  To answer the later parts of your e-mail, a couple of things need to be clarified. First - are you setting the parameters for the problem by saying that the various fields found on a screen have just two states? Second - why are you assuming that the joins are always going to be of the type "primary key = foreign key"? Alan has clearly explained this in his response.

  A (table_name, column_name, datatype) collection and the states of fields alone cannot determine a "query" - assuming at this point you are not trying to insert/update/delete records. A query can result in a single record or multiple records or can be used to find out aggregate values like max, min, avg, count etc. So, you will need to input the mode (query/insert/update/delete) as well as the functions that operate on various columns to define completely what you want the output to be.

  I hope this helps.

Cheers,
  Bala.

In article <8269qg$jit$1_at_autumn.news.rcn.net>,   "Alan Shein" <alanshein_at_erols.com> wrote:
> Two things:
>
> 1. The "connection" (join) is always part of the WHERE clause in a
 given
> query.
> 2. You don't necessarily want to make that join part of the query. It
> depends on what you are trying to do.
> 3. You may want a left, right, or full outer join, or perhaps even a
> non-equijoin.
>
> (okay, that was 3 things)
>
> In any event, merely reading the fact (either from the data
 dictionary or
> from a screen) that tables are related is not sufficient cause to
 include
> this fact in a query, nor is it possible from this information to
 conclude
> in what way it should be included in a query. This is one set of
 reasons why
> it always takes a human to create a query.
>
> Sandy Pittendrigh <sandy_at_nervana.montana.edu> wrote in message
> news:3846A1FE.B27718EB_at_nervana.montana.edu...
> > For any schema where any table can (somehow) be connected
> > to any other table through a connected path of
> > primary_key/foreign pairs, it must be possible for an
> > external parsing routine to read the data dictionary and
> > construct a connected, directional graph of the entire
> > schema.
> >
> > Given this, and also given an arbitrary collection of GUI
> > query screens, where each widget in the query screen can be
> > toggled on or off, and where each widget in the query screen
> > is associated with a (tablename, column_name, data_type)
> > touple, then it must be (is it?) possible for that external
> > parsing routine to read the "widget state" of the screen
> > and dynamically construct the "foreign_key=primary_key"
> > clauses needed to make a logical select statement.
> >
> > In other words, any query screen that interactively prompts
> > for the "SELECT columns" part of a select statement as well
> > as the "WHERE constraints" part of the select statement, the
> > only hard part left is to add in the "link this table to
> > that table" clauses. The programmer who designed the schema
> > can do this. But what about a parsing routine that only
> > knows the state of the query screen?
> >
> > --
> > /* Sandy Pittendrigh >--oO0>
> > * sandy_at_nervana.montana.edu
> > * http://nervana.montana.edu/~sandy
> > */
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Wed Dec 15 1999 - 00:00:00 CET