钻石模式：那是如何（去）规范化的？

Question

假设我们有以下实体：

• 制作工作室
• 记者
• 相机操作员
• 新闻片段

在这个简单的世界里，制作工作室有很多记者和摄像师。每个记者都属于一个工作室。运营商也是如此。新闻片段由一名记者和一名操作员制作，他们都来自同一个工作室。

这是我将此模型放入关系数据库的幼稚方法：

CREATE TABLE production_studios(
  id                   SERIAL PRIMARY KEY,
  title                TEXT NOT NULL
);

CREATE TABLE journalists(
  id                   SERIAL PRIMARY KEY,
  name                 TEXT NOT NULL,
  prodution_studio_id  INTEGER NOT NULL REFERENCES production_studios
);

CREATE TABLE camera_operators(
  id                   SERIAL PRIMARY KEY,
  name                 TEXT NOT NULL,
  production_studio_id INTEGER NOT NULL REFERENCES production_studios
);

CREATE TABLE news_footages(
  id                   SERIAL PRIMARY KEY,
  description          TEXT NOT NULL,
  journalist_id        INTEGER NOT NULL REFERENCES journalists,
  camera_operator_id   INTEGER NOT NULL REFERENCES camera_operators
);

此架构形成形状精美的菱形 ERD 和一些问题。

问题在于，新闻片段可以将来自不同制作工作室的记者与摄影师联系在一起。我知道这可以通过编写相应的约束来解决，但是为了实验，我们假设我们正在做范式数据库设计的练习。

1. 第一个问题是关于术语的：声明这个模式是非规范化的是否正确？如果是，它打破了哪种范式？或者这种异常有什么更好的名称，比如记录间冗余、多路径关系等？

2. 如何更改此架构以使所描述的异常成为不可能？

当然，我非常感谢参考解决这个特定问题的论文。

Answer 1

天真的方法是让你的记者和camera_operators依赖实体，依赖于他们工作的工作室。这意味着制作工作室的外键成为其主键的一部分。然后，您的 news_footage 表有一个由 4 个组件组成的主键：

• production_studio_id
• journalist_id
• camera_operator_id
• footage_id

还有两个外键：

• journalist_id,production_studio_id，指向记者桌，然后
• camera_operator,production_studio_id，指向相机操作员表

简单。

要么不。 现在你已经在你的 ER 模型中定义了这样一个概念，即摄影师或记者的存在取决于他们工作的工作室.这并不能很好地反映实际工作：在此模型中，人们无法更换雇主。

我们不要那样做。

在您的原始模型中，您将 人 与他们扮演的 _role（记者或摄像师）混淆了，并且您缺少一个实际上负责新闻制作的临时实体素材：[工作室特定] 制作团队。

我的 E-R 模型看起来像这样：

create table studio
(
  id int not null primary key ,
  title varchar(200) not null ,
)

create table person
(
  id int not null primary key ,
  title varchar(200) not null ,
)

create table team
(
  studio_id          int not null ,
  journalist_id      int not null ,
  camera_operator_id int not null ,

  primary key ( studio_id , journalist_id , camera_operator ) ,

  foreign key ( studio_id          ) references studio ( id ) ,
  foreign key ( journalist_id      ) references person ( id ) ,
  foreign key ( camera_operator_id ) references person ( id ) ,

)

create table footage
(
  studio_id          int not null ,
  journalist_id      int not null ,
  camera_operator_id int not null ,
  id                 int not null ,
  description        varchar(200) not null ,

  primary key ( studio_id , journalist_id , camera_operator_id , id ) ,

  foreign key     ( studio_id , journalist_id , camera_operator_id )
  references team ( studio_id , journalist_id , camera_operator_id ) ,

)

现在您拥有一个人们可以在其中扮演不同角色的世界：同一个人在某些情况下可能是摄像师，而在其他情况下可能是记者。人们可以更换雇主。工作室特定团队由一名记者和一名摄像师组成。在某些情况下，同一个人可能在团队中同时扮演两个角色。最后，一段新闻片段由一个且只有一个工作室特定团队制作。

这更好地反映了现实世界，并且更加灵活。

编辑添加示例查询：

要找到为特定工作室工作的记者：

select p.*
from studio s
join team   t on t.studio_id = s.id
join person p on p.id        = t.journalist_id
where s.title = 'my desired studio name'

这将为您提供一组现在（或曾经）与工作室相关联的记者角色。不过应该注意的是，在现实世界中，人们为雇主工作了一段时间：要正确建模，您需要一个开始/结束日期，并且您需要使用现在的相对概念来限定查询。