1.6 小结
抛砖引玉到此就要告一段落了。我们所用到的这个例子非常简单，从中得出的结论也是显而易见的。而其实我是想通过这个例子引出下面的理念，就是根据实际的定义把视图看作与特定的表相附生的基表，这对于整体考虑如何解决视图更新的问题是很有建设性的。我认为它不仅具有建设性，而且是一种“逻辑上正确”的方法。[8]总体思路如下。
1．视图定义表达式包含了某些特定的约束。例如，视图LS（“London suppliers”）的视图定义表达式表明了LS等同于表S中CITY值为London的约束。
2．这种约束反过来表明了特定的补偿性操作（如那些为了避免违反完整性约束，而需要在用户自行请求的更新之外进行的操作）。举例来说，正如前面讲到的，表S、LS和NLS的约束就代表相应的级联删除和级联插入。
这里我要强调第2点——这点很重要，就是在某些状况下，补偿性操作可以由相关视图的定义表达式决定。换句话说，这样的操作不需要显式指定，也不需要给已经超负荷的DBA[9]增加工作负担。对于这个问题和其他在本章中引出的问题，我都会在后面的章节进行更详细的探讨。
最后，如果你像大多数人一样跳过了前言直接开始阅读第1章，那么现在是时候翻回去阅读前言了，这对你继续阅读下面的章节会很有帮助。前言包含了本书的整体结构，同时还阐明了将要在下面的章节使用的重要的技术性假设，因此需要你对它们有所了解。
[1] 我在本章这个介绍性的章节使用SQL和SQL风格的语法是因为大家都对它比较熟悉，尽管它并不是我喜欢的风格，并且（更重要的是）事实上它可能会让这个抛砖引玉的例子更不容易解释清楚。
[2] 在本书中我都使用未经认证的“键”这个词来表示候选键，而不是一个特定的主键。实际上，在第2章中就会介绍到的“Tutorial D”对于主键和其他键在语法上并没有区别。但是，由于大家使用习惯的原因，我在图例中都使用双下画线来表示主键属性，如图1.1所示。
[3] 我在前言的时候就声明过，在本书中我将使用《SQL and Relational Theory》作为简写来引用我的另一本书《SQL and Relational Theory: How to Write Accurate SQL Code》（第2版，奥莱利出版，2012）。
[4] 正是由于这个原因，更真实一点版本的视图LS很可能会去掉CITY属性。在这里我选择不这样做，是为了让这个例子更简单易懂。
[5] 曾经有一位审阅者问我，为什么我在这里要选择“补偿性操作”这个词。当时我自己认为这个答案很明显，不过为了以防万一，我还是在这里做一个说明：之所以我把这些操作称为“补偿性”的，是因为它们都会导致第2次更新发生来补偿第1次的效果（当然是大体上来讲）。
[6] 级联删除通常都被认为是使用一个特定的外键约束，但是补偿性操作的概念其实更加通用，并且适合很多种约束。
[7] 我假设有些用户“可能”会被允许进行这样的操作，如果他或她在操作被拒绝的时候能够接受错误信息显示的只是“因为系统就是这么说的”，而没有更进一步的解释。关于这一点的进一步讨论详见第4章。
[8] 在此感谢David McGoveran，他在多年前启发我思考这些问题。
[9] DBA=database administrator，也就是数据库管理员。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。