对于我之前在 SO 上提出的问题，我有一个后续问题。

我想将以下内容转换为关系代数，而不是我最初的问题中的查询：

列出并非总是受双重投标影响的投标人的姓名和电话号码。

注意：当两个不同的投标人对同一件商品出价相同时，就会出现双重投标。

我有一些关于如何进行的想法：

• 找出所有有双重出价的投标人 (1)
• 找出所有出价不是双重出价的投标人 (2)
• 查找所有从未进行双重投标的投标人 (3)

从这里，我可以得到（1）和（2）的交集并将（3）加到这个交集上得到最终答案。（这是我的思考过程，如有不对请指正）

我可以找到所有双重出价的投标人，但随之而来的想法让我很困惑。这就是我对“所有双重出价的投标人”的看法：

• 投标？项目 - (Q1)

• 问题1？? _{出价？出价'，iid？iid'，价格？价格'}（Q1）-（Q2）

• ? _出价（？_{出价！=出价'}（Q2）？？_{价格=价格'}（Q2）？？_{iid = iid'}（Q2））-（Q3）

我如何使用它来找到不总是受双重投标影响的投标人？

顺便说一句，粗体文本仅用于标记目的，而不是答案的一部分。

我已经阅读了所有连接是关联和可交换的地方。

所以A join (B join C)应该是一样的(A join C) join B。

但我真的很难理解这是怎么回事。假设 A 与 B 有共同的财产，B 与 C 有共同的财产，但 A 和 C 没有共同的财产可以连接。

似乎在这种情况下，在第二个实例中(A join C) join B，当发生连接 A 和 C 的操作时，它会导致一个空集，使得与 B 的连接变得不可能。

而在第一种情况下它会起作用，因为 B 连接 C 会导致预期的连接表具有与 A 连接的属性。

采取以下关系方案：

• R(A, B, C)

• S(D, E, F)

其中属性A和D分别是主键。

假设有一个实例r的R with n tuples和实例s的S with m tuples。

此外，假设在C和 的主键之间具有参照完整性约束S。

现在，我被问到以下问题：

1. 如果连接谓词是， ?-joins和之间r包含多少个元组C = D？

2. 如果连接谓词是， ?-joins和之间r包含多少个元组B = E？

我的回答：

1. n tuples 因为这一切都取决于属于第二个关系的元组的数量，这些元组与属于第一个关系的元组相匹配

2. zero 因为没有共同的属性

我的推理正确吗？

晚上好！

我正在从以下 UML 类图（不幸的是法语）设计我的第一个实际数据库：

我正在创建它的关系草图，我是这样创建的：

然而，当试图向数据库询问哪些客户从未订购过第一产品时，它会产生一些问题？

确实，我不知道如何在 SQL 中做到这一点，因为Client，Commande和Produit之间似乎没有关系。它给出了以下sql代码：

CREATE TABLE Client (
IDClient INT NOT NULL,
AdresseClient VARCHAR(255)NOT NULL ,
NomContact VARCHAR(255)NOT NULL,
NumeroSIRET VARCHAR(14) NOT NULL,
CONSTRAINT cclient PRIMARY KEY (IDClient)
);

CREATE TABLE Produit (
IDProduit INT NOT NULL  ,
PrixVente INT NOT NULL ,
QuantiteEnStock INT NOT NULL ,
CONSTRAiNT cproduit PRIMARY KEY (IDProduit)
) ;

CREATE TABLE Commande (
IDNumeroCde INT NOT NULL  ,
Date DATE …

这可能是一个新手问题。但有时，我发现有必要使用诸如(SELECT * FROM A)在 SQL 中进行关系代数之类的东西（而不是使用关系A本身）。

例如，尝试在工作时，UNION两种关系A，并B具有相同的结构，下面

SELECT * FROM (A UNION B) t;

生成语法错误（使用 PostgreSQL 9.x）。

ERROR:  syntax error at or near "UNION"

我不得不做

SELECT * FROM ((SELECT * FROM A) UNION (SELECT * FROM B)) t;

我的问题是：

子查询的冗长性(SELECT * FROM A)在 SQL 语言中是否真的必要（或者我是否遗漏了一些更好的编写方式）？为什么这里不能直接使用A和关系B？

是(SELECT * FROM A)相当于A在关系代数？扩张(SELECT * FROM A)给我们带来了什么？什么时候需要长表格？

我有这些表：

        水手          

sid sname 分级年龄
--- ------ ------ ---
22 灰尘 7 45 
31 约翰 8 55 
58 本 10 35 

         船        

投标名称颜色
--- --------- -----
101 因特拉克蓝 
102Interlake红色  
103剪刀绿
104剪刀红  

       储备

sid投标日期
--- --- ----------
22 104 8/10/2014
22 103 7/05/2014
58 103 8/11/2014
31 102 8/11/2014

我试图找到水手，sname和rating，他们同时保留了红色和绿色的 船，我需要用关系代数符号来写。

我试过这个：

文本版本，用于复制/参考目的：

R1 := 船 ⋈ 服务
R2 := σ color='红色' (R1)
R3 := σ color='绿色' (R1)
R4 := R2 …

我试图向自己证明内部联接的顺序并不重要，但是，从抽象的意义上来说，我什么也没想到。

如何证明一组 INNER JOIN 的执行顺序（将多个表转换为单个表）不会影响结果集（即证明 INNER JOIN 操作的交换性和关联性）？

架构图： 为涉及姓氏为“史密斯”的员工（作为工人或作为控制项目的部门的经理）的项目列出项目编号。

给定的解决方案是：

但是，我认为仅使用以下表达式就足够了：

现在，我之所以相信这一点，主要是因为该EMPLOYEE关系包含对应于工人和经理的元组。现在，员工既可以是工人，也可以是经理。所以，按照这个逻辑，上面的表达式应该就足够了。我完全同意这样一个事实，即可以通过多个关系代数表达式表示给定的查询，但是按照给定的解决方案（较大的解决方案）执行上述建议是非常多余的。

综上所述，我的思路正确吗？

来源：Ramez Elmasri 和 Shamkant B. Navathe 的《数据库系统基础》，第 6 版，第 172 页查询 4。

问题

我曾经在测试中发现的一个问题是这样写的：

报告 ISBN=43221 图书的图书信息

一本书的关系模式如下所示：

π _{ISBN, title, type, NumPages, edition, sequel, name} (σ _ISBN=43221 (Book))

这基本上相当于

SELECT * FROM Book WHERE ISBN=43221.

我写出了测试的 Projection 语句中的所有属性，但我觉得有一种更快的方法来做到这一点。

题

是否有一种快捷方式可以在关系代数中显示一个元组的所有信息，或者必须在 Project 语句中写出所有属性？