From: DT

To: Editor

Date: 05 Jul 2004

 

I noticed what may be a conceptual flaw in the example view on page 297 of the 8th edition of AN INTRODUCTION TO DATABASE SYSTEMS (simplified by omitting the RENAME):

 

VAR REDPART VIEW

 { P WHERE COLOR = COLOR ('RED') } { ALL BUT COLOR };

 

Compare this to the relvars presented as bad examples on page 398 of the same book:

 

ACTIVITIES_2001 { ENTRY#, DESCRIPTION, AMOUNT, NEW_BAL }

ACTIVITIES_2002 { ENTRY#, DESCRIPTION, AMOUNT, NEW_BAL }

 

Consider them as views of an ACTIVITIES table with a YEAR attribute:

 

VAR ACTIVITIES_2001 VIEW

 { ACTIVITIES WHERE YEAR = 2001 } { ALL BUT YEAR };

 

If "encoding meaning into names -- of relvars or anything else -- violates the Information Principle", it seems to follow that a view defined by restricting on an attribute and then projecting away that attribute is a bad view.  You end up with a relvar where the meaning is encoded in the name, from the user's point of view at least.

 

Supposedly, the user should not have to know that REDPART is not a base relvar.  But an insert on REDPART will fail unless the default value for COLOR is RED (or something like the trigger on page 278 is used).  In the case of REDPART, the DBMS might be able to supply the correct value automatically.  But what could it do in the case of a ">" restriction, if the tested attribute were projected away?

 

It seems to me that the database manager should be discouraged from creating restricted views in which the attributes being tested are projected away. 

Do you agree?

 

 

C. J. Date Responds: You raise an interesting question.  Herewith some random, somewhat disconnected, but, I hope, relevant thoughts on the subject (all of which I reserve the right to revise later): 

 

1. In general, views serve two rather different purposes (AN INTRODUCTION TO DATABASE SYSTEMS, 8th edition, page 301).  There's no harm in defining REDPARTS simply as a shorthand, with no pretense that it's supposed to behave like a base relvar, if you're just trying to save yourself some writing.  The problems you raise occur only if you want REDPARTS to "look and feel" like a base relvar.  From this point forward, therefore, I assume you do want views to look and feel like base relvars. 

 

2. Suppose that at time t1 all parts are red, and we therefore define a parts base relvar with no color attribute at all: 

 

VAR REDPARTS RELATION { P#, PNAME, WEIGHT, CITY } ;

 

(simplified definition omitting attribute type names; I use the name REDPARTS here for consistency with the discussion that follows).  Suppose further that at time t2 > t1 some new parts come along that aren't red, and we therefore extend the base relvar to include a color attribute after all (à la SQL ALTER TABLE).  It seems to me, then, that it would be not only reasonable but indeed likely that we would want to define a view of the base relvar at time t2 that is essentially the view you ask about. 

 

3. On the other hand ... The very scenario sketched in Point 2 suggests that "ALTER TABLE" is not a good approach to this kind of situation.  It might be better to introduce a whole new base relvar, NONREDPARTS, say--

 

VAR NONREDPARTS RELATION { P#, PNAME, COLOR, WEIGHT, CITY } ;

 

(probably with the constraint that COLOR isn't red)--and to define another view thus: 

 

VAR P VIRTUAL (

 NONREDPARTS UNION

 ( EXTEND REDPARTS ADD ( 'Red' AS COLOR ) ) ) ;

 

Note the implication here that we would need to be able to update through a union, incidentally.  

 

4. Of course, we can--and, I presume, would--use the security mechanism to prohibit updates on views that, if permitted, would be liable to expose the fact that those views are views and not base relvars. 

 

5. "Encoding meaning into names violates The Information Principle."  I agree I said this in the book.  But it's only an approximation to the truth, and (sadly) it seems to be hard to make it completely precise.  A more specific observation might be:  If tuple t is presented for insertion into the database, then obviously there must be a procedure for deciding what relvar(s) need to be updated, and that procedure should be known to the system.  View REDPARTS satisfies this requirement, because a part tuple requires REDPARTS to be updated if and only if COLOR = 'Red'.  ACTIVITIES_2001, etc., do not, so long as they are (as suggested in the book) base relvars. 

 

6. I agree with your remarks on default values.  Indeed, the idea that a given attribute has just one default that must be used in all contexts is almost certainly too rigid.  Further investigation is needed, however, and further discussion is beyond the scope of these notes. 

 

Watch this space for developments ...

 

 

Posted: 09/24/04