如何在 SQL 中实现聚合? (这与 GroupBy 无关)

How to implement an Aggregation in SQL? (This is not about GroupBy)

在大学项目的范围内,我应该实现我的数据库的聚合。
我得到了一个看起来类似于这个的实体关系模型: 现在我应该实现一个 SQL-Script 来创建这样的数据库,但是我在 google 或其他任何地方都找不到关于这个主题的任何信息。在我教授的幻灯片中说

  • For example, to represent aggregation manages between relationship works_on and entity set manager, create a schema
    manages(employee_id, branch_name, title,manager_name)
  • Schema works_on is redundant provided we are willing to store null values for attribute manager_name in relation on schema manages

所以我尝试将两张表放入我的 SQL-Script 中,一张名为 works-on,另一张名为 manages。在works-on中我把jobbranchemployee的所有主键都定义为外键。在 manages 中,我放置了所有这些主键,另外我还放置了 manager。现在的问题是,当我使用 MySQL-workbench 的逆向工程创建数据库的 EER 模型时,我没有从中得到任何与此聚合有关的信息.那么我在这里做错了什么?
根据@Barmar 的要求,我刚刚写了我会用于此的 CREATE TABLE-语句:

CREATE TABLE job
(jobid INT,
PRIMARY KEY(jobid));

CREATE TABLE employee
(employeeid INT,
PRIMARY KEY(employeeid));

CREATE TABLE branch
(branchid INT,
PRIMARY KEY(branchid));

CREATE TABLE manager
(managerid INT,
PRIMARY KEY(managerid));

CREATE TABLE works_on
(jobid INT, KEY(jobid),
branchid INT, KEY(branchid),
employeeid INT, KEY(employeeid));

CREATE TABLE manages
(jobid INT, KEY(jobid),
branchid INT, KEY(branchid),
employeeid INT, KEY(employeeid),
managerid INT, KEY(managerid));

ALTER TABLE works_on
ADD CONSTRAINT FK_workson_employee FOREIGN KEY(employeeid) REFERENCES employee(employeeid);
ALTER TABLE works_on
ADD CONSTRAINT FK_workson_branch FOREIGN KEY(branchid) REFERENCES branch(branchid);
ALTER TABLE works_on
ADD CONSTRAINT FK_workson_job FOREIGN KEY(jobid) REFERENCES job(jobid);

ALTER TABLE manages
ADD CONSTRAINT FK_manages_employee FOREIGN KEY(employeeid) REFERENCES employee(employeeid);
ALTER TABLE manages
ADD CONSTRAINT FK_manages_branch FOREIGN KEY(branchid) REFERENCES branch(branchid);
ALTER TABLE manages
ADD CONSTRAINT FK_manages_job FOREIGN KEY(jobid) REFERENCES job(jobid);
ALTER TABLE manages
ADD CONSTRAINT FK_manages_manager FOREIGN KEY(managerid) REFERENCES job(managerid);

您需要为 works_on table 提供一个主键,然后在 manages table 中引用它,而不是引用 employee , job, 和 branch 直接。

CREATE TABLE works_on (
    works_on_id INT PRIMARY KEY,
    jobid INT,
    branchid INT,
    employeeid INT,
    CONSTRAINT jobid FOREIGN KEY REFERENCES job(jobid),
    CONSTRAINT branchid FOREIGN KEY REFERENCES brahc(branchid),
    CONSTRAINT employeeid FOREIGN KEY REFERENCES employee(employeeid)

);
CREATE TABLE manages (
    managerid INT,
    works_on_id INT,
    CONSTRAINT managerid FOREIGN KEY REFERENCES manager(id),
    CONSTRAINT works_on_id FOREIGN KEY REFERENCES works_on(id)
)

您的 ER-Diagram 缺少一个重要信息:经理和从其他 4 个元素构建的新实体之间的基数 jobemployeemanagerbranchworks-on(这个新实体由它们周围的方块标记)。

从幻灯片上的引用我们可以推断出这是一种 0..1 关系, 这意味着 jobbranchemployee 的每个组合(或 works-on 中的每个条目)最多有一个 manager,但不需要一个(在与例如 composition).

对比

但您必须在实际任务中验证该基数。

您通常可以通过多种方式实现 ER 图,但幻灯片暗示了以下实现:

CREATE TABLE manages
( jobid INT not null,
  branchid INT not null,
  employeeid INT not null,
  managerid INT null,
  PRIMARY KEY (jobid, branchid, empoyeeid)
);

我省略了 tables jobemployeemanagerbranch 的琐碎外键。

使用此实现,您不再有 works-on 关系的显式 table,就像幻灯片中的第二个语句所说的那样。它包含在 manages table 中。这仅适用于 0..1 关系,这就是为什么可以推导出基数的原因。

如果您想为 works-on 保留 table,您可以使用

CREATE TABLE works_on
( jobid INT not null,
  branchid INT not null,
  employeeid INT not null,
  PRIMARY KEY (jobid, branchid, empoyeeid)
);

CREATE TABLE manages
( jobid INT not null,
  branchid INT not null,
  employeeid INT not null,
  managerid INT not null,
  PRIMARY KEY (jobid, branchid, empoyeeid),
  FOREIGN KEY (jobid, branchid, employeeid) 
    REFERENCES works_on (jobid, branchid, employeeid)
);

同样,我省略了琐碎的外键。

为了简化外键(也许是为了强调组合被认为是一个新实体),您可以按照@Barmar 的建议,向 works_on 添加一个额外的(通常是自动递增的)键-table 并在 manages-table 中使用此值,尽管此处的幻灯片并未这样做。

如果你需要实现一个0..n-关系(几个经理可以管理一个特定的works-on-组合),你不能在[=中吸收works-on-关系28=]-关系(所以你需要两个 tables),为了尊重 n,你必须在主键中包含 manageridPRIMARY KEY (jobid, branchid, empoyeeid, managerid)(但仍然需要保留 FOREIGN KEY (jobid, branchid, employeeid)).