我了解到,就表中的元组(例如行)而言,没有顺序的概念,但根据维基百科, “元组是元素的有序列表”。这是否意味着属性确实有顺序?如果是,为什么它们会被区别对待,不能向表中添加另一列(这就是元组没有顺序的原因)?
“在这种表示法中,属性-值对可以按任何顺序出现。” 这是否意味着属性没有顺序?
我了解到,就表中的元组(例如行)而言,没有顺序的概念,但根据维基百科, “元组是元素的有序列表”。这是否意味着属性确实有顺序?如果是,为什么它们会被区别对待,不能向表中添加另一列(这就是元组没有顺序的原因)?
“在这种表示法中,属性-值对可以按任何顺序出现。” 这是否意味着属性没有顺序?
可以这么说,有 2 种元组。有“纯数学”,确实有元组通常被定义为“值的有序列表”。因此,在数学理论中,谈论“元组中的第一个值”等是有意义的。这可能是您的维基百科文章所指的意义或上下文。
Haskell 语言支持这种元组,例如,它也有一个 fst() 运算符来从这种元组中提取“第一个”值。
然而,Codd 意识到,当将元组作为有序列表的这种数学概念应用于数据管理领域时,这将是极其不切实际的。在数据管理中,他希望通过属性名称而不是按序号位置对值进行寻址。确实,想象一下如果从表中删除“五个属性中的第二个”会产生毁灭性的后果,现在所有处理同一个表的“第三个”和“第四个”属性的程序现在都必须被发明和调整。
所以在关系模型中,元组是命名值的集合,因此,在数据关系模型中发挥作用的元组中,确实没有任何值排序的概念。
然后正如其他响应中所指出的那样,存在 SQL 及其与关系理论的亵渎神明的偏差。在 SQL 中,元组和标题中属性的排序是非常有意义的,其后果无处不在。在 FK 声明中,各个引用属性和被引用属性的对应关系是按序号位置,而不是按名称。其他情况是使用 UNION 和 EXCEPT。取一个表 T,列 X 和 Y 的类型相同。
从 T 中选择 X、Y 并从 T 中选择 Y、X
本身不是无效的,但标准规定结果中的列名是系统定义的(!)。“做明智的事情”并偏离这一点的实现,分别生成一个包含名为 X 和 Y 的列的表,然后面对他们的用户,结果是前一个表达式与
从 T 中选择 Y,X 从 T 中选择 X,Y
(因为列排序 X,Y 是 Y,X 之外的另一个排序,因此标题不相等,因此表不相等。)
从 T 中选择 X,Y 除了从 T 中选择 Y,X
给出的结果会让许多 SQL 新手摸不着头脑。
通常理解和使用的关系数据库模型的操作当然不依赖于关系中属性的顺序。关系变量的属性总是可以通过名称而不是位置来识别。然而,关系数据库理论中使用的符号并不总是指定属性名称(或属性类型),有时确实暗示了有序的属性。这主要是书面符号的问题,而不是关系模型的结构或行为。以下参考资料中对这些不同的“命名”和“有序”视角进行了更多讨论。 http://webdam.inria.fr/Alice/pdfs/Chapter-3.pdf
EFCodd 最早关于关系模型的论文实际上提出了一个同时支持有序和无序关系版本的关系系统。从那以后,这个想法似乎已经被遗忘或忽视了,即使是科德本人。它不构成现代关系数据库理论的一部分。
不幸的是,SQL 确实有列顺序的概念。它是 SQL 语法和语义的重要组成部分,并且是每个 SQL DBMS 都支持以符合 ISO SQL 标准的东西。SQL 不是关系型的,这只是它与关系型模型不同的方式之一。SQL 模型和关系模型之间的尴尬差异给同样使用 SQL 的关系模型的学生带来了一定的困惑。