Errata

The views seen by a given user can effectively be equivalent either (a) to the underlying base data in its entirety ? see the discussion of information equivalence later in this chapter ? or (b) to some proper subset of that underlying base data. The latter case constitutes one form of information hiding.

Date, C. J. (2012-12-20). View Updating and Relational Theory (Kindle Locations 1247-1249). O'Reilly Media. Kindle Edition.

Subset? How about a view involving an EXTEND with a time expression that generates, let's say, an expiry date attribute? There are many ways to realize: (c) information generation. Do we treat meta data as base data? System supplied time functions as base data? Depending on what we mean by "base data" determines if we admit or preclude (c). If base data means user supplied data and not application derived data then (c) stands. N.B., you did quote "base data" in its first appearance.

This is a comment, not a complaint exactly. I hope the author will consider it.

This is an important book because some of its conclusions are correct in a logical sense. But it either needs fewer chapters or an additional chapter to explain in formal terms why there are so many chapters. It could be made more obvious why the choice of which relations are base and which are not matters. This would lead to an understanding of view updating as being simply a matter of inverting functions that the data design expresses. The book raises confusions in various places when it tries to deal with relations that are not functions. If it had focused on inverse functions for inferring the domains of only relations that are functions perhaps only three chapters would have been needed. It is not the reversal of an update that is needed but the inversion of its predicate. But in roundabout ways the book does support the contention of David McGoveran that base updates are just a special case of view updates which are the general case.

Chapter 14 does mention an important concept actually a crucial concept, the updating of expressions. It expresses some disappointment that different expressions produce different results but relational expressions have predicate equivalents so there should be no surprise that relational expressions that differ in the relations and operations they mention produce different results. This may result from the treatment of predicates which is rather simplistic in the context of the overall database.

Of course the whole possibility of data Independence is distorted by the fact that today's database systems generally assume that the act of updating is based on operations from the file system era such as insert and delete. For example that basis and a few other mistakes means that such systems are essentially nothing more then advanced file systems.

The value of a join expresses an invertible function where the reversible domain and range express the extensions of the logical operands of the join, not necessarily the syntactic operands. This is part of the reason why Codd included projection in his essential operations, even if he didn't spell it out. Its necessity is an obvious assumption in his treatment of join updates in his 1990 book. (It encouraged confusion by including a supposed join update that does not involve a join.)

It is the join extension, not the operation of updating, that needs to be inverted in order to satisfy the unchanging predicate of a join, in other words to preserve its predicate.

The predicate of a join is not necessarily preserved by the predicates of the extensions of its operands. The latter may not even have been provided by the data design for example there may be subsets of those operands, understood individually as functions, whose domains are refined, for example suppliers that supply parts compared to suppliers that don't. A design that doesn't distinguish them explicitly must rely on the dbms to infer those subsets. The dbms can only infer from what it is given not from what it is not given.

Codd's normalization, having the purpose of storage optimization, usually doesn't preserve the predicate of either of those domains. In effect, the normalized data design frequently buries them because they are not distinguished by the definition in the data design of distinct relations, so they are not available to the system and are therefore irrelevant to its operation.

View updating can be understood more simply in terms of relations that are functions and the inverses of those functions. Of the four essential relational operations , join, union, minus and project, only two need to be examined on this basis, join AKA conjunction and project AKA quantification.

Something missing from the book is the importance of the catalog which can be used to alter the meaning of expressions unbeknownst to users. This can relieve users, potentially millions of application coders, from making logical mistakes that an automated dbms could avoid, that distort the intentions of data designers. For example a projection can be made insertable as it were if it is specified as a projection of a base relation that has been extended AKA joined with a singleton relation that has only one attribute value, an important possible use too involved to explain here. If data designers understand that they can synthesize relations that enforce their intentions in user-supplied relational expressions the economic benefit could be massive.