实体关系图 - 购买在哪里？

Question

考虑到这个社区有关于建模数据库的问题，我在这里寻求帮助。

我正在开发一个基于我正在阅读的书中看到的另一个拍卖系统的拍卖系统，而且我遇到了麻烦。问题的背景如下：

  

在拍卖系统中，用户发布产品公告（他/她定义产品）。它定义了   产品名称和初始报价（称为初始报价）。初始出价表示要提供的最低金额。一个   产品仅在用户通知时存在于数据库中。一个   用户定义了许多产品，但产品属于单个产品   用户。

     

每件商品都有失效日期。当某个日期到来时，如果   该产品没有优惠，也没有出售。如果有   对产品的报价，最高出价者赢得了给定的产品。

     

优惠有创建日期和提供的金额。报价是   来自用户的产品。用户可以为其制作不同的优惠   不同的产品。产品可以由不同的用户提供。该   同一个用户不能为同一产品提供两个以上的优惠。

这种情况对我来说很容易做到。 问题是我需要存储购买。（对不起，我不知道这个单词是用英文写的）。我需要一种方法来了解哪个优惠是成功的，并且实际上已经购买了＃34;一个产品。相对于所说的，我的概念模型（实体关系图）的一部分如下：

我尝试将USERS与PRODUCTS聚合在一起，并在聚合和PRODUCTS之间建立连接/关系，这将为我提供PURCHASES事件。当这个被分解（分解）时，我会有一张表格显示哪个产品买了什么产品。

然而，我会有基数问题。这个表有两个外键。一个用于BIDS，另一个用于产品。这将允许这两者的N-N关系，这意味着我可以保存多个出价作为产品的买方，或者相同的出价可以＆＃34;购买＆＃34;许多产品（所以我在最终的PURCHASES表中说）。

我在这里看不到什么？你能帮助我吗？感谢您的阅读，您的时间和耐心。如果您需要更多细节，请不要犹豫。

修改

该物业＆＃34;初始投标＆＃34;关于PRODUCTS实体不是一种关系。 此属性表示货币价值，即必须为特定产品提供的最低金额。

Answer 1

你正在倒退事物。首先，我们确定相关的应用程序关系，然后确定其属性。给定应用程序关系和可能出现的应用程序情况，只能出现某些关系/关联集/表。购买每个产品只能有一个出价，每个出价只能有一个产品。因此，出价：购买的产品基数为1：1只是一个事实。这样说的。无论您希望记录哪些其他应用程序关系，都是如此。如果这些实体之间存在不同的应用关系，那么基数可能会有所不同。等待 - USERS_PRODUCTS和BIDS形成了这样一对appplication关系，用户：产品对于前者为1：0..N，对于后者为0..N：0..N。每个参与者的基数反映（属性）钻石代表的特定应用关系。

类似地：外键是关系/关联集/表对的属性。声明它们会告诉DBMS强制参与者ID值出现在实体集/表中。即{bid}引用BIDS和{产品}引用产品。候选键（其中一个可以是主键）是关系集/表的属性。购买者的候选键导致声明强制执行其基数的约束。这并不是很多：许多出价：产品因为“出价BID以日期DATE的价格$ AMOUNT购买产品PRODUCT”并不多：许多出价：产品。由于其出价或其产品唯一标识购买，因此{bid}和{product}都是候选密钥。

Answer 2

要记录中标，需要功能依赖Product ID -> Bid ID。这可以作为一个或多个可空列（因为并非所有产品都已购买）在Products表中实现，或者更好地在单独的表（Purchases）中使用Product ID作为主键实现。

Answer 3

嗯......我试图按照给定的建议，并尝试按照我之前所说的做，使用聚合。在我看来，结果是正确的。请注意：

当然，用户提供产品报价。用户记录可以与PRODUCTS中的多个记录相关。同样，产品可以由多个用户提供，因此，产品中的记录可以与USERS上的多个记录相关。如果我错了，请纠正我。

从购买情况来看，我们发现产品只能通过单一出价正确购买。没有办法说用户购买产品或购买产品本身。通过USERS和PRODUCTS之间的关系，可以创建出价，这是一种能够购买产品的出价。因此，有必要聚合这种关系，然后设置购买事件。

我们必须记住，只能为一次出价购买一种产品。所以这里我们的基数为1比1.这里的分解将要求数据建模者自行决定。

通过分解这个概念模型，我们将得到以下逻辑模型：

请注意如何使用适当的属性来尊重关系。我们可以知道谁宣布了产品（卖家），我们可以知道提供了什么产品。

现在，正如我之前所说，有购买关系。由于我们在这里有1比1的关系，规则告诉我们必须选择解释关系的哪一方（哪个实体应保持这种关系）。

通常建议将未来可能存在的关系保持为“很多”。在这种情况下没有必要这样做，因为很明显这种关系不能保存在BIDS记录中。因此，我们在PRODUCTS实体上维持“赢家出价”所描绘的这种关系。如您所见，我为BIDS设置了唯一的标识符。通过定义物理模型，我们有一个代理键。

嗯，我在这里完成了答案，但我想我还不能正确考虑。如果可能的话，我希望有人发表评论。谢谢。

修改

我想道歉。似乎我的错误。好吧，我现在住在巴西，在这里我们学习ER-Diagram的方式在我看来与你们许多人习惯的方式不同。直到昨天，我一直在回答社区中与此主题相关的一些问题，我发现使用了一些不同的符号。直到现在我才注意到我们没有说同一种语言。我相信在某种程度上让我感到尴尬。对不起。真的，对不起。

哦，还有一件事（对某些人来说可能很有趣）：

• BIDS和产品之间的基数确实是错误的。这应该 如评论中所述，两者都是0比1。
• 这里没有与关系有关的关系。我们有 这里叫什么（在我的国家，或在我过去的课程） “聚合”（在第一个图中由带有剪切线的矩形表示）。分解时的内部关系（BIDS）会 成为一个实体，BIDS和产品之间的关系是 后来做的。聚合表示需要首先解决关系，以便它可以与另一个实体相关联。这会产生某种限制，这在某些业务规则中可能是必需的。它表示两个实体的连接定义了与另一个实体的记录相关的记录。
• 某些关系不一定需要命名。一旦您 打破某些类型的关系，没有必要（它是 命名它们（在关系N到N之间），特别是如果是新的 这些关系不会产生。当然，如果我要说出所呈现的白色关系，那么我们将拥有USER'S BIDS（在USERS和BIDS之间）和PRODUCT'BIDS（在BIDS和产品之间）。

关于我的学习材料，它都是葡萄牙语，我相信你不会理解，我不知道。但这是我过去上课时读过的一本书：

• ISBN：978-85-365-0252-6
• 标题：PROJETO de BANCO de DADOSUmaVisãoPrática
• 作者：Felipe Machado，Mauricio Abreu
• 出版公司：EDITORAÉRICA
• COVER：

• LINK： http://www.editorasaraiva.com.br/produtos/show/isbn:9788536502526/titulo:projeto-de-banco-de-dados-uma-visao-pratica-edicao-revisada-e-atualizada/

嗯......我现在该怎么办？哈哈......我不知道该怎么办。我会在这里留下我的问题。如果某人采用与我相同的方法帮助我，我将不胜感激。谢谢。