寻求扩展的Divide运算符说明

Question

我正在Inside Microsoft SQL Server 2008: T-SQL Querying by Itzik Ben-Gan, Lubor Kollar, Dejan Sarka, and Steve Kass阅读Codd的八个原始操作员，并且不理解Divide算子。

定义Divide运算符的引号：

  

“除数关系用于划分股息关系和   产生商关系。商关系由那些组成   红利表中一列的值，第二列的值   列包含除数中的所有值。“

此声明与Wikipedia's definition and example一致。

  

“Divide运算符的公式包含三个关系： a   除以 b 每 c ，其中 a 是被除数， b 是除数， c 是   调解员的关系。让关系 a 具有属性A和关系 b   属性B. Divide运算符返回包含的关系   所有来自除数的元组，使得元组{A，B}出现在   来自除数关系的所有元组的中介关系。“

下图用于演示此声明。我相信这些关系按以下顺序呈现：红利，除数，调解者和最终结果。

第二个关系（除数）对于元组有{a，x}，{a，z}，{b，x}和{b，z}。我的思考过程如下：因为有元组{b，x}和{b，z}，b应该包含在最终结果中。我已经检查了图书网站上的图书更正（在本文开头链接），并确定我错了。

为什么图示例的结果 a 而不是 a 和 b ？

Answer 1

图中的结果确实应该是行{a}和{b}。但这本书和你的信息混在一起。

有许多关系型DIVIDE变种。还有Codd的分歧，Date的Codd分界版本，Todd的分数，Date和Darwen的小（Codd-like）分数和Great（ Todd-like）div-per和他们的广义小而大的鸿沟，以及Darwen的每分红。

报价和图表来自书中。首先，他们试图谈论Codd的分歧，它有两个输入; ＆＃34;除数关系用于划分股息关系＆＃34;。 （这本书甚至说：＆＃34;这是最初定义Divide运算符的方式。＆＃34;）但它的第二句话是错误的。首先，它讨论列而不是不相交的列集。其次，它将其第二个操作数限制为仅具有第一个操作数列的子集。 （它的日期是Codd划分的简略版本。）第三，它是无法理解的。设A，B和C为不相交的属性集，AB和BC为属性集AUB和BU C的关系。然后，Codd的AB DIVIDEBY BC返回AB中出现的每个B子行中显示的子行。 / p>

wiki实际上描述了Codd的鸿沟。因此，只有当你忽略上述问题时，首先要引用＆＃34;与＆＃34;它

然后第二个引用是在讨论不同的＆＃34;扩展＆＃34;除运算符。这本书解释说，Codd的鸿沟并没有反映出使用＆＃34;对所有人而言的自然语言。在常见的情况下。然后他们不清楚地介绍了另一个运营商。他们试图定义小分数。输入＆＃34;包括三个关系：每c除以b＆＃34;。显示的图表甚至标记为＆＃34;扩展鸿沟＆＃34;。

不幸的是，这个定义不仅是不合语法的，而且是难以理解的。 DIVIDEBY B PER AB返回A中出现的行，这些行在AB中显示为子行，每行出现在B中。应该说它返回被除数中的元组{A}，使得元组{A，B}出现在在除数中具有所有元组{B}的调解者

那本书很乱。写作很可怕。证明阅读很糟糕。鉴于本节中的文字，没有理由期望答案是正确的。但是，你也没有仔细阅读。

然后你误解了图中的参数。但是你没有注意到，因为你没有遵循这个定义。因此没有注意到定义是难以理解的。该图显示了关系A-AB-B结果，它是红利 - 中介 - 除数 - 商。所以你再也不仔细阅读了。

确实，{a}和{b}行都应该在结果中。但我真的不能说你是对的＆＃34;因为你的思维过程＆＃34;似乎是＆＃34;得到一个模糊的印象＆＃34;。一些模糊性肯定是由于书中写得不好。但你似乎并没有注意到这本书是难以理解的。仔细阅读！

Answer 2

关系部门一直是一团糟，很可能会保持这种状态。它最初被发明为关系查询系统能够制定/回答问题的手段，例如，“什么是已订阅所有可能的保险单类型的客户列表”。也就是说，它旨在作为制定查询的工具，这些查询涉及某种通用量化作为确定结果集的谓词。

进一步阐述我的客户/政策示例，让我们假设“所有可能的保险政策类型”本身随时间变化，即随着时间的推移，新的政策类型可能出现，而其他政策类型可能会停止。让我们进一步假设某个查询中的“所有可能的保险单类型”，具体而言，是指“客户当前打开的所有策略类型”（即已停止的策略类型不属于此“ALL”的一部分） “类型”。

假设在某个时刻这组“所有可能的策略类型”是{TYPE1，TYPE3}。 TYPE2已经停产。我们还假设客户ES仍然具有TYPE2类型的策略，显然可以追溯到停止之前的状态。因此，客户ES具有{TYPE1，TYPE2，TYPE3}类型的策略。

现在回答这个客户是否有“所有当前可供订阅的政策类型”的问题。你的答案应该坚定'是'。您可能会了解这种情况：关系划分围绕着两个集的比较。一个是“比较”（客户的订阅策略类型集），另一个是“引用”（当前可供订阅的策略类型集）。

现在至少有两个有用的比较可以在集合之间进行：一个用于相等，另一个用于集合包含（子集）。在某些查询的情况下，您将需要进行相等性测试，而在其他情况下，您将需要进行包含测试。而关系运算符称为“除法”（无论其任何风味）都不允许进行区分。我认为这是你要问的这种现象，答案很简单，选择是通过设计来实现的，可以这么说，并且硬连接到运营商的定义中。它使运算符在其定义符合您的需求的情况下“有用”，而在其他情况下则无用。

好消息是，当你必须拼出一个关系分区的SQL时，除了平等和除division之间没有太大区别（尽管代数的事实是这样的）根据定义，运算符只是两者中的一个，而另一个甚至根本没有代数运算符。主要的问题是在SQL中表达集合相等本身是非常混乱的，并且在关系分区查询中并没有那么简单......

然后菲利普已经有了所有有效点。阅读它们，但要非常小心。