长期以来，我们习惯了称关系型中的表为二维表。因为它有行和列，很容易我们就可以把它同一个二维平面联系起来，但事实上，这并非关系型数据库的初衷，也并非符合关系模型的。其实长久以来，我对此也只有一个很模糊的概念，对平面表的观点虽有怀疑，却一直无从验证。直到有一天，翻出一本老书——《关系数据库》（石树刚、郑振楣编著，清华大学出版社，1993年），这本老书没有什么流行的新噱头，却满满当当地净是数学理论。这本书读起来并不是很诱人，不过的确很严谨，澄清了我的很多不明之处。也激励我找来各种权威材料重头学起。薄薄一本书，定价只有9.9元，想想这应当是我在上学时，从旧书摊上买的，可能当时只花了不到五元钱。这肯定是我买的性价比最高的一本书了。
这个表存储一个空间内的一些点。我们可以很清楚地看到，每一个完整的行，才代表一个点。仅定位某行某列，它并不能表达这个表所定义的信息结构。当我们向这个表中插入或删除数据，它仍代表三维空间内的点集。但如果我们增加一列T（time)呢？那一切全变了，它不再是三维空间了，现在，这个表中存储的是四维的信息了（读过相对论的朋友应当了解，相对论中的时空就是一个四维坐标系）。删除一列呢？比如Z列，现在我们面对的就是X-Y平面了，这是一个二维坐标系。也就是说，在表中删除或增加或修改若干列，并不会改变这个表所代表的意义。而修改或增删列，就会改变表的结构，表所代表的意义也就不同于以前了。表的行和列，并不是平等的！我们不能简单地把它理解为一个平面！相反，我认为，将表的结构理解为一个代数空间更合适，这样，表中的每一行是这个代数空间中的一个点，那么当前表中的信息就形成了这个空间中的一个点集。当然，这个集合还可有其它的约束条件，下面我们从关系模型说起。
在严格意义上的关系模型中，一个关系模式，包括关系名、有限属性集、属性值域、属性列到值域的映射、完整性约束和属性间依赖。对应数据库中的结构，通常一个关系模式对应一个或多个表和视图。这些表和视图有其各自包括的列，而列有列名、列的数据类型、表和视图的主键约束、外键约束、检查、断言、触发器（在2000中，已可以在视图中定义索引和触发器，再加上视图本身的SQL脚本，视图以可以定义为一个完整的关系模式）。一个简单的关系模式可以只由一个表构成，而多个元组（表或视图）组成的关系，其相互的关联由外键和触发器来完成。在这个定义中，关系中的各个列（也就是说关系的模式）可以有很强的依赖性。比如某些列有主键约束，另一些列有引用外键。而行与行之间（也就是说关系之间）的依赖只存在于两种情况——外键和触发器。其中外键可以表达为模式上的（也就是列之间的）依赖。例如以下订单系统，它由客户表，订单表和
CUSTOMERIDINTNOTNULL,1 <script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
扫一扫
294
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
