【问题标题】:How to design a database for data which needs to be mapped at multiple levels? [closed]如何为需要在多个级别映射的数据设计数据库? [关闭]
【发布时间】:2020-11-23 06:12:03
【问题描述】:

我有以下这些数据库实体:

  1. 组织 - 顶级
  2. 项目 - 组织可以有许多项目。
  3. 团队负责人 - 项目可以有多个团队负责人。

我已经有以下这些数据库表:

  1. 组织
  • orgnization_id
  • (其他属性)
  1. organization_projects
    • organization_id(来自组织表)
    • project_id
    • (其他属性)
  2. projects_team_leads
    • organization_project_id(来自 organization_projects 表)
    • team_lead_id(员工表中的 id)

现在,我想在此处再添加一个实体,称为承包商。承包商的属性如下:

  1. 一个团队负责人可以有多个承包商。在团队领导和承包商之间的映射中会有某些属性相关联,例如 manage_start_date
  2. 还需要在承包商和项目之间建模一些信息。例如。 “项目”级别的承包商评级。
  3. 还需要在承包商和组织之间建模一些信息。例如。 “合同工期”

另外,请注意,只有一名团队负责人可以管理项目内的承包商。 承包商也有全局信息,例如姓名、出生日期等,它们驻留在雇员表中。但是,这个员工表在另一个微服务中。

当前的任务是为这个具有项目和组织的服务添加承包商,并在不同级别(团队领导级别、项目级别和组织级别)添加必要的属性。

我正在考虑在每个级别设置单独的表格。例如。

  1. organization_contractors
  • organization_id
  • contractor_id(来自不同微服务中的员工表)
  • contract_duration
  1. project_contractors
  • organization_contractor_id(来自 organization_contractors 表)
  • organization_project_id(来自 organization_projects 表)
  • 评分
  1. team_lead_contractors
  • project_team_lead_id(来自 project_team_leads 表)
  • contractor_project_id(来自 project_contractors 表)
  • manage_start_date

对此我唯一的疑虑是,在 team_lead_contractors 表中,可以从 project_team_lead_id 和contractor_project_id 推断出项目。

与其他方法相比,这种方法的优点和关注点是什么?

【问题讨论】:

    标签: sql postgresql database-design entity-relationship


    【解决方案1】:

    如果我理解正确的话,...

    1. 有组织和承包商。
    2. 组织可能与承包商 A、B、C 和 D 签订合同。
    3. 该组织中的一个项目可能与其中一些承包商相关,例如项目 P1 与 A、B 和 C 相关,而项目 P2 与 A 和 D 相关。
    4. 每个项目都有项目负责人。项目 P1 可能有线索 PL1 和 PL2。
    5. 再次,每个项目负责人可能与所有或仅部分项目承包商相关。 PL1 可能与 A 和 B 有关,PL2 可能与 A 和 C 有关。

    如果您希望您的 DBMS 保证所有这些实体的数据一致性,我建议您使用复合键。

    表组织 组织编号 ... 餐桌承包商 承包商_没有 ... 表组织_承包商 组织编号 承包商_没有 ... PK (organization_no,contractor_no) FK 组织 (organization_no) FK 承包商 (contractor_no) 表组织项目 组织编号 项目编号 ... PK (organization_no, project_no) FK 组织 (organization_no) 表组织项目承包商 组织编号 项目编号 承包商_没有 ... PK(organization_no、project_no、contractor_no) FK 组织项目(组织编号,项目编号) FK organization_contractor (organization_no,contractor_no) 表 organization_project_lead 组织编号 项目编号 铅号 ... PK (organization_no、project_no、lead_no) FK 组织项目(组织编号,项目编号) 表 organization_project_lead_contractor 组织编号 项目编号 铅号 承包商_没有 ... PK(organization_no、project_no、lead_no、contractor_no) FK organization_project_lead(organization_no、project_no、lead_no) FK organization_project_contractor (organization_no, project_no,contractor_no)

    【讨论】:

    • 感谢您的快速回答!我可以知道使用复合键有什么好处吗?不是可以用其他表中的键替换的冗余数据吗?例如。 organization_project_lead_contractor 可以有 organization_project_lead_id。
    • 不,复合键不是多余的。比如说,公司 1 有一个项目 1,公司 2 也有一个项目 1。这是两个不同的项目,所以您需要公司编号加上项目编号才能访问您所追求的项目。这没有什么多余的。
    • 使用单一 ID,您无法保证一致性。这有点难以解释。那么,一个项目负责人承包商行将导致一个项目负责人和一个承包商,项目负责人再次将导致一个项目。该项目将与承包商联系起来。但是如何保证项目主承包商在项目的承包商集合中呢?
    • 啊!好的!知道了。但是,在我们的例子中,该项目不能与另一个组织相关联。该组织内的所有项目都属于该组织本身。现在,对于团队领导,他们将永远在同一个组织之下。但是,他们可以处理多个项目。可以使用 organization_project_lead.id 来识别它们。在这种情况下,哪个更好?在organization_project_lead_contractor 中有organization_project_lead.id 还是有organization_id、project_id 和lead_id 的单独键?
    • 我不知道您的业务需求。我假设项目属于组织,并且他们的项目负责人将属于同一个组织。不是这样吗?
    猜你喜欢
    • 2021-04-29
    • 1970-01-01
    • 2020-10-03
    • 2011-01-19
    • 2010-09-09
    • 2011-01-21
    • 2019-08-30
    • 1970-01-01
    • 2011-01-13
    相关资源
    最近更新 更多