What do you think?
Rate this book
View Updating and Relational Theory: Solving the View Update Problem
Views are virtual tables. That means they should be updatable, just as "real" or base tables are. In fact, view updatability isn’t just desirable, it’s crucial, for practical reasons as well as theoretical ones. But view updating has always been a controversial topic. Ever since the relational model first appeared, there has been widespread skepticism as to whether (in general) view updating is even possible.
In stark contrast to this conventional wisdom, this book shows how views, just like base tables, can always be updated (so long as the updates don’t violate any integrity constraints). More generally, it shows how updating always ought to work, regardless of whether the target is a base table or a view. The proposed scheme is 100% consistent with the relational model, but rather different from the way updating works in SQL products today.
This book can:
Help database products improve in the future
Help with a "roll your own" implementation, absent such product improvements
Make you aware of the crucial role of predicates and constraints
Show you how relational products are really supposed to behave
Anyone with a professional interest in the relational model, relational technology, or database systems in general can benefit from this book.
In stark contrast to this conventional wisdom, this book shows how views, just like base tables, can always be updated (so long as the updates don’t violate any integrity constraints). More generally, it shows how updating always ought to work, regardless of whether the target is a base table or a view. The proposed scheme is 100% consistent with the relational model, but rather different from the way updating works in SQL products today.
This book can:
Help database products improve in the future
Help with a "roll your own" implementation, absent such product improvements
Make you aware of the crucial role of predicates and constraints
Show you how relational products are really supposed to behave
Anyone with a professional interest in the relational model, relational technology, or database systems in general can benefit from this book.
258 pages, Paperback
First published December 20, 2012
4 people are currently reading
10 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
May 15, 2019
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.
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.
Displaying 1 of 1 review