【问题标题】:Relational database model with relational tables?具有关系表的关系数据库模型?
【发布时间】:2017-01-10 00:18:30
【问题描述】:

我面临以下问题。

想象一个有两个相关表的关系数据库:

表用户

  idUser | email       | otherColumns
  ------ | ----------- | ------------
       1 | a@gmail.com | ....

餐桌账单

  idBill | value | otherColumns
  ------ | ------| ------------
       1 | 100$ | ....

通过向账单表添加外键以将每个账单与一个用户相关联来建立公共关系。尽管如此,也可以像这样创建一个中间表:

关系表账单用户

  id     | idUser | idBill
  ------ | ------ | ------------
  1      | 1      | 1

有了这张表,我们可以取得相同的结果,但我认为组织更好。这个选项是否比其他选项更好?还是视情况而定?

最后,我想知道是否有任何标准可以创建这些关系。

谢谢。

【问题讨论】:

  • 不要在值字段中存储货币。使该字段成为数字数据类型而不是文本数据类型。当您想对该列进行算术运算时,它只会导致您稍后出现问题
  • 我每次都是根据关系来做的。如果是 1:N 我使用第一个选项和一个外键,如果有关系 M:N 我使用中间表。如果是关系 1:N,我认为没有必要创建下一个表。您必须分配更多空间,并且下一张表可能会使复杂的数据库设计难以阅读

标签: mysql sql relational-database


【解决方案1】:

是的,有一些标准——或者更确切地说,有很多关于数据库设计的书籍告诉你公认的智慧。我记得读过的最后一篇是 Christopher J. Date 的“数据库设计和关系理论:范式和所有爵士乐”。

第一个问题的答案取决于业务领域。用这样的伪语言总结系统通常会有所帮助:

用户由合成主键标识,并具有 属性 xyz。

bill 由合成主键标识,具有值,具有 一种货币,有 xyz。

账单只有一个用户。

(或)

账单有一个或多个用户。

(或)

bill只有一个用户,并且这种关系有 属性 x、y 和 z。

如果帐单只有一个用户,则将“用户”作为外键添加到帐单表中。没有其他信息可捕获。

如果一个帐单可以有多个用户,您可以创建一个链接/连接表,每个用户/帐单组合对应一行。

我的账单只有一个用户,并且这种关系还有一些其他属性 - 例如。该法案的税务状况 - 您可以使用任一解决方案。就个人而言,我更喜欢创建一个连接表来显示这些属性涉及账单和用户之间的关系,而不是账单本身。但是,其他人有不同的看法。

【讨论】:

  • 好答案@NevilleK 我会买这本书。
  • @Maik 事实证明,如果一个表等于一系列无损连接,其中公共列是 CK(候选键),那么规范化到 5NF 永远不会说你应该将该表取消连接回它们. (因为该表“满足”“由 CK 隐含”的“连接依赖关系”。)此处 Bill_User-plus-user-column 表无损地分解为公共 CK 上的 Bill & Bill_User,因此就是这种情况。答案的“取决于业务领域”是正确的,尽管它在规则方面的理由是模糊的。但这就是写书的原因。
【解决方案2】:

这与您的设计有关。假设根据我们的设计,one 用户可以拥有n 账单,而one 账单必须只属于one 用户。这意味着我们应该有1-n 关系。将其表示为物理表取决于您拥有的关系类型。对于1-n,我们可以这样做:

表用户

idUser(PK)    |    email     |  otherColumns
------        |    ------    |  ------------
1             |  a@gmail.com |  ....

餐桌账单

idBill(PK)    |    value     |  otherColumns  |  idUser(FK)
------        |    ------    |  ------------  |  ------
1             |     100$     |  ....          |  1
2             |      10$     |  ....          |  1

TableUser.isUser 是 PK 和 Unique。 TableBill.idUser 不是 PK 和 not unique 的一部分。我更喜欢这种方式来表示1-n,因为不需要多一张表(查询中少一张join 操作)。

或者正如你上面写的,我们可以创建关系表来链接它们:

表用户

idUser(PK)    |    email     |  otherColumns
------        |    ------    |  ------------
1             |  a@gmail.com |  ....

餐桌账单

idBill(PK)    |    value     |  otherColumns 
------        |    ------    |  ------------ 
1             |     100$     |  ....          
2             |      10$     |  ....         

关系表账单用户

idUser(FK)     |     idBill(FK)
------         |  ------------
1              |        1
1              |        2

在关系表中,idUser 字段是not unique,因为我们应该允许复制userids (1-n)。 idBill 必须是unique,因为一张账单必须只有一个所有者。您也可以根据您的设计要求对关系identifying 进行一些更改。

关系类型:careerride

关于设计问题(ER 图):tutorialspoint

ER 到表格:tutorialcup

【讨论】:

  • ER 模型中的关系不是由表之间的外键引用表示,而是由表中两个或多个键列的关联表示。在“关系表账单用户”中,(idUser, idBill) 这对列表示一个 ER 关系。从Bill_User.idBill 到Bill.idBill 的FK 约束只是一个完整性约束。此外,您的链接涉及质量差的教程,我建议读者在适当的教育机构的网站上寻找结果。
【解决方案3】:

我的建议是不要创建另一个表说“关系表账单”来映射账单表和客户。使用起来不太好:

在“Table Bill”中添加“iduser”列,这样您就可以轻松加入 billtable 和 customer 表:

餐桌账单

 idBill    |    value     |  otherColumns | iduser 
------    |    ------    |    ......      | ....
1         |     100$     |                | 1

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2016-05-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-09-06
    • 1970-01-01
    相关资源
    最近更新 更多