|
|
|
|
移动端

1.2 仅限基表:约束

《视图更新与关系数据库理论》本书详细介绍了数据库架构的设计和实现,同时讨论了视图更新及关系数据库理论。本节为大家介绍仅限基表:约束。

作者:田远帆 译来源:人民邮电出版社|2018-01-25 17:12

技术沙龙 | 6月30日与多位专家探讨技术高速发展下如何应对运维新挑战!


1.2 仅限基表:约束

另一个由可交换性原则引出的问题是表S、表LS和表NLS的行为不应该由基表和视图的分布来决定。为了解释这个问题,我们先假设它们全都是基表。

  1. CREATE TABLE S     ( ... , UNIQUE ( SNO ) ) ;  
  2. CREATE TABLE LS    ( ... , UNIQUE ( SNO ) ) ;  
  3. CREATE TABLE NLS   ( ... , UNIQUE ( SNO ) ) ; 

这样一来,所有的表就都受到约束的限制了。不过从实际情况来看,想在SQL中构造这些约束条件会非常复杂,因此为了便于表达和理解,我将用普通话来描述一下这些约束条件(大部分是大白话)。

{SNO}是每个表的键,同时,{SNO}对于LS和NLS来说是外键,引自于表S。注意:关于使用“{”和“}”的原因,请参阅《SQL and Relational Theory》[3]。

在任何时候,表LS都等同于表S中CITY值为London的限定,表NLS都等同于表S中CITY值不为London的限定。同时,表LS中每一行的CITY值都为London[4],表NLS中的每一行都不为London。

在任何时候,表S都等于表LS和NLS合并后的结果。同时要注意,这个合并是不相交的(对应的交集为空),没有数据会同时出现在表LS和表NLS中。具体来说就是:表S中的每一行都会根据限定条件准确地出现在表LS或表NLS中,而表LS或表NLS中的每一行也必定会出现在表S中。

最后,刚刚所说的由CITY值引发的约束以及{SNO}是所有三张表的键这个约束结合在一起,就会形成以下结果,即表S中每个具体的供应商编码(不仅是整行的信息)都会根据限定条件准确地出现在表LS和表NLS当中。而表LS或表NLS中的每一个具体的供应商编码也必定会出现在表S中。

当然,正如前面所说的几点所示,这些约束并不是完全独立毫不相干的,其中一些约束是另一些约束逻辑上导致的结果。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

3D游戏开发大全(高级篇)

在我的第一本书——《3D游戏开发大全》中,我们曾经对3D游戏开发完成了一次犹如探索原始丛林般的旅程:首先,我们对3D游戏产业进行了初步了...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊