是的，多对多（简称 M:N）关联或关系的识别是数据库从业人员在布置概念模式时经常面临的情况。所述基数比的关联出现在性质非常不同的商业环境中，并且当通过例如SQL-DDL安排在逻辑级别上适当地表示时，它们不会引入有害的冗余。

这样，数据库建模练习的目标应该是高精度地反映感兴趣的业务上下文的相关特征；因此，如果您正确地识别出有许多 M:N 关联，那么您必须在 (a) 概念模式和 (b) 相应的逻辑级声明中表达它们，无论它们有多少连接 - 或任何其他——必须解决基数比。

商业规则

您提供了一个上下文相关的问题，并且还澄清了您正在处理的数据库纯粹是假设的，这是很重要的一点，因为我认为像正在考虑的那样的“现实世界”业务场景会更加广泛因此，这意味着更复杂的信息需求。

我决定 (1) 对您提供的业务规则进行一些修改和扩展，以便 (2) 产生更具描述性的概念模式——尽管仍然是假设性的——。以下是我整理的一些配方：

• 第¹方是个人或组织
• 一个Party由完全一个PartyType分类
• PartyType对零个或多个缔约方进行分类
• 一个组织开发零一或多产品
• 产品是系统或游戏_
• 一个产品被精确地分类为一个ProductType
• 一个System由一个SystemType编目
• 可以通过一对多系统玩游戏
• 系统用于玩一对多游戏
• 游戏按零一或多类型分类
• 流派对零一或多游戏进行分类
• 一个产品产生一对多的工作
• 一项工作由零个或多个人完成，他们扮演协作者的角色
• 一个人是零一或多工作中的协作者

^{1 Party是法律上下文中使用的术语，指的是组成单个实体的个人或一组个人，因此该名称适用于代表人和组织。}

IDEF1X 图

随后，我创建了如图 1所示的 IDEF1X ²图表（确保单击链接以更高分辨率查看它），将上面介绍的业务规则（以及其他一些似乎相关的规则）合并到一个图形设备中：

^{2 信息建模集成定义( IDEF1X ) 是一种高度推荐的数据建模技术，于 1993 年 12 月由美国国家标准与技术研究院(NIST)确立为标准。它基于 (a) 由关系模型的唯一创始人，即 EF Codd 博士撰写的早期理论材料；关于 (b) 数据的实体关系视图，由PP Chen 博士开发；以及 (c) Robert G. Brown 创建的逻辑数据库设计技术。}

如您所见，我仅通过相应的关联实体类型描述了三个 M:N 关联，即：

• 合作者
• 系统游戏
• 游戏类型

除其他方面外，还有两种不同的超型-亚型结构，其中：

• Person和Organization是Party的互斥实体子类型，它们的实体超类型

• Product是System和Game的超类型，它们又是互斥的子类型

如果您不熟悉超类型-子类型关联，您可能会找到帮助，例如，我对以下问题的回答：

• “模拟每个音乐艺术家是一个团体或一个独奏者的场景”
• “如何对可以具有不同属性集的实体类型进行建模？”
• “为资金转移业务开发数据库，​​ (a) 个人和组织可以 (b) 发送和接收资金”
• “为多种用户类型及其联系信息建模数据库结构”

说明性逻辑 SQL-DDL 布局

接下来，我们必须确保在逻辑层面：

• 每个实体类型都由一个单独的基表表示
• 适用实体类型的每个单一属性由特定列表示
• 为每一列固定了一个精确的数据类型，以确保它包含的所有值都属于一个特定且定义明确的集合，无论是 INT、DATETIME、CHAR 等（当然，在使用Firebird或PostgreSQL时，您可能希望使用更强大的 DOMAIN）
• （以声明方式）配置多个约束，以保证所有表中保留的行形式的断言符合在概念级别确定的业务规则

所以我根据之前展示的IDEF1X图声明了以下DDL安排：

CREATE TABLE PartyType ( -- Stands for an independent entity type.
    PartyTypeCode CHAR(1)  NOT NULL, -- To retain 'P' or 'O'.
    Name          CHAR(30) NOT NULL, -- To keep 'Person' or 'Organization'.
    --  
    CONSTRAINT PartyType_PK PRIMARY KEY (PartyTypeCode)
);

CREATE TABLE Party ( -- Represents an entity supertype.
    PartyId         INT       NOT NULL,
    PartyTypeCode   CHAR(1)   NOT NULL, -- To hold the value that indicates the type of the row denoting the complementary subtype occurrence: either 'P' for 'Person' or 'O' for 'Organization'.
    CreatedDateTime TIMESTAMP NOT NULL,  
    --
    CONSTRAINT Party_PK            PRIMARY KEY (PartyId),
    CONSTRAINT PartyToPartyType_FK FOREIGN KEY (PartyTypeCode)
        REFERENCES PartyType (PartyTypeCode)
);

CREATE TABLE Person ( -- Denotes an entity subtype.
    PersonId        INT      NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    FirstName       CHAR(30) NOT NULL,
    LastName        CHAR(30) NOT NULL,
    GenderCode      CHAR(3)  NOT NULL,
    BirthDate       DATE     NOT NULL,
    --
    CONSTRAINT Person_PK PRIMARY KEY        (PersonId),
    CONSTRAINT Person_AK UNIQUE             (FirstName, LastName, GenderCode, BirthDate), -- Composite ALTERNATE KEY.
    CONSTRAINT PersonToParty_FK FOREIGN KEY (PersonId)
        REFERENCES Party (PartyId)
);

CREATE TABLE Organization ( -- Stands for an entity subtype.
    OrganizationId  INT      NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    Name            CHAR(30) NOT NULL,
    FoundingDate    DATE     NOT NULL,
    --
    CONSTRAINT Organization_PK        PRIMARY KEY (OrganizationId),
    CONSTRAINT Organization_AK        UNIQUE      (Name), -- Single-column ALTERNATE KEY.
    CONSTRAINT OrganizationToParty_FK FOREIGN KEY (OrganizationId)
        REFERENCES Party (PartyId)
);

CREATE TABLE ProductType ( -- Represents an independent entity type.
    ProductTypeCode CHAR(1)  NOT NULL, -- To enclose the values 'S' and 'G' in the corresponding rows.
    Name            CHAR(30) NOT NULL, -- To comprise the values 'System' and 'Person' in the respective rows.
    --
    CONSTRAINT ProductType_PK PRIMARY KEY (ProductTypeCode)
);

CREATE TABLE Product ( -- Denotes an entity supertype.
    OrganizationId  INT      NOT NULL,
    ProductNumber   INT      NOT NULL,
    ProductTypeCode CHAR(1)  NOT NULL, -- To keep the value that indicates the type of the row denoting the complementary subtype occurrence: either 'S' for 'System' or 'G' for 'Game'.
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Product_PK               PRIMARY KEY (OrganizationId, ProductNumber), -- Composite PRIMARY KEY.
    CONSTRAINT ProductToOrganization_FK FOREIGN KEY (OrganizationId)
        REFERENCES Organization (OrganizationId),
    CONSTRAINT ProductToProductType_FK  FOREIGN KEY (ProductTypeCode)
        REFERENCES ProductType (ProductTypeCode)
);

CREATE TABLE SystemType ( -- Stands for an independent entity type.
    SystemTypeCode CHAR(1)  NOT NULL,
    Name           CHAR(30) NOT NULL,
     --
    CONSTRAINT SystemType_PK PRIMARY KEY (SystemTypeCode)
);

CREATE TABLE MySystem ( -- Represents a dependent entity type.
    OrganizationId   INT      NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    SystemNumber     INT      NOT NULL,
    SystemTypeCode   CHAR(1)  NOT NULL,
    ParticularColumn CHAR(30) NOT NULL,
    --
    CONSTRAINT System_PK              PRIMARY KEY (OrganizationId, SystemNumber),
    CONSTRAINT SystemToProduct_FK     FOREIGN KEY (OrganizationId, SystemNumber)
        REFERENCES Product (OrganizationId, ProductNumber),
    CONSTRAINT SystemToSystemType_FK  FOREIGN KEY (SystemTypeCode)
        REFERENCES SystemType (SystemTypeCode)
);

CREATE TABLE Game ( -- Denotes an entity subtype.
    OrganizationId INT      NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    GameNumber     INT      NOT NULL,
    SpecificColumn CHAR(30) NOT NULL,
    --
    CONSTRAINT Game_PK          PRIMARY KEY (OrganizationId, GameNumber),
    CONSTRAINT GameToProduct_FK FOREIGN KEY (OrganizationId, GameNumber)
         REFERENCES Product (OrganizationId, ProductNumber)
);

CREATE TABLE Genre ( -- Stands for an independent entity type.
    GenreNumber INT      NOT NULL,
    Name        CHAR(30) NOT NULL,  
    Description CHAR(90) NOT NULL,
    --
    CONSTRAINT Genre_PK  PRIMARY KEY (GenreNumber),
    CONSTRAINT Genre_AK1 UNIQUE      (Name),
    CONSTRAINT Genre_AK2 UNIQUE      (Description)
);

CREATE TABLE SystemGame ( -- Represents an associative entity type or M:N association.
    SystemOrganizationId INT      NOT NULL,  
    SystemNumber         INT      NOT NULL,  
    GameOrganizationId   INT      NOT NULL,    
    GameNumber           INT      NOT NULL,
    CreatedDateTime      DATETIME NOT NULL,
    -- 
    CONSTRAINT SystemGame_PK         PRIMARY KEY (SystemOrganizationId, SystemNumber, GameOrganizationId, GameNumber), -- Composite PRIMARY KEY.
    CONSTRAINT SystemGameToSystem_FK FOREIGN KEY (SystemOrganizationId, SystemNumber) -- Multi-column FOREIGN KEY.
        REFERENCES MySystem (OrganizationId, SystemNumber),
    CONSTRAINT SystemGameToGame_FK   FOREIGN KEY (SystemOrganizationId, GameNumber) -- Multi-column FOREIGN KEY.
        REFERENCES Game (OrganizationId, GameNumber)  
);

CREATE TABLE GameGenre ( -- Denotes an associative entity type or M:N association.
    GameOrganizationId INT      NOT NULL,    
    GameNumber         INT      NOT NULL,
    GenreNumber        INT      NOT NULL,  
    CreatedDateTime    DATETIME NOT NULL,
    -- 
    CONSTRAINT GameGenre_PK        PRIMARY KEY (GameOrganizationId, GameNumber, GenreNumber), -- Composite PRIMARY KEY.
    CONSTRAINT GameGenreToGame_FK  FOREIGN KEY (GameOrganizationId, GameNumber)
        REFERENCES Game (OrganizationId, GameNumber), -- Multi-column FOREIGN KEY.
    CONSTRAINT GameGenreToGenre_FK FOREIGN KEY (GenreNumber)
        REFERENCES Genre (GenreNumber) 
);

CREATE TABLE Job ( -- Stands for an associative entity type or M:N association.
    OrganizationId  INT      NOT NULL,
    ProductNumber   INT      NOT NULL,
    JobNumber       INT      NOT NULL,
    Title           CHAR(30) NOT NULL,  
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Job_PK          PRIMARY KEY (OrganizationId, ProductNumber, JobNumber), -- Composite PRIMARY KEY.
    CONSTRAINT Job_AK          UNIQUE      (Title), -- Single-column ALTERNATE KEY.
    CONSTRAINT JobToProduct_FK FOREIGN KEY (OrganizationId, ProductNumber) -- Multi-column FOREIGN KEY.
        REFERENCES Product (OrganizationId, ProductNumber)
);

CREATE TABLE Collaborator ( -- Represents an associative entity type or M:N association.
    CollaboratorId   INT      NOT NULL,    
    OrganizationId   INT      NOT NULL,
    ProductNumber    INT      NOT NULL,
    JobNumber        INT      NOT NULL,
    AssignedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Collaborator_PK         PRIMARY KEY (CollaboratorId, OrganizationId, ProductNumber, JobNumber), -- Composite PRIMARY KEY.
    CONSTRAINT CollaboratorToPerson_FK FOREIGN KEY (CollaboratorId)
    REFERENCES Person (PersonId),  
    CONSTRAINT CollaboratorToJob_FK    FOREIGN KEY (OrganizationId, ProductNumber, JobNumber) -- Multi-column FOREIGN KEY.
       REFERENCES Job (OrganizationId, ProductNumber, JobNumber)
);

值得强调的是，在多个表中声明了复合PRIMARY KEY 约束，它们代表概念实体类型之间发生的连接层次结构，这种排列对于数据检索非常有益，例如，表达 SELECT包含 JOIN 子句以获取派生表的操作。

是的，(i) 每个 M:N 关联和 (ii) 每个关联的实体类型都由 (iii) 逻辑 DDL 结构中的相应表表示，因此要特别注意 PRIMARY 和 FOREIGN KEY 约束（以及我作为评论留下的注释）代表这些概念元素的表格，因为它们有助于确保相关行之间的连接符合适用的基数比。

The usage of composite keys was introduced by Dr. E. F. Codd from the very origin of the relational paradigm, as demonstrated in the examples he included in his 1970 seminal paper entitled A Relational Model for Large Shared Data Banks (which, precisely, also presents the most elegant method to handle conceptual M:N associations).

I put up a db<>fiddle and a SQL Fiddle, both running on Microsoft SQL Server 2014, so that the structure can be tested “in action”.

Normalization

Normalization is a logical-level procedure that implies, basically speaking:

1. Eliminating non-atomic columns via first normal form so that data manipulation and constriction are much easier to cope with by the data sublanguage of use (e.g., SQL).

2. Getting rid of undesirable dependencies among the columns of a specific table by virtue of the successive normal forms to avoid update anomalies.

Naturally, one has to take into account the meaning carried by the table(s) and column(s) at issue.

I like to think of normalization as a test founded on science that a designer applies to the pertinent elements once he or she has delineated a stable logical-level arrangement in order to determine whether its items comply with every one of the normal forms or not. Then, if needed, the designer takes the appropriate correcting measures.

Redundancy

In the relational model, while duplication of values contained in columns is not only acceptable but expected, duplicate rows are forbidden. To that extent, as far as I can see, duplicate rows and other kinds of harmful redundancies are prevented in all the tables comprised in the logical layout exposed before, perhaps you would like to clarify your concern in this regard.

Anyway, you can certainly (a) evaluate on your own said structure by dint of the normal forms to define if it meets the requirements and (b) modify it if necessary.

Related resources

• In this series of posts I present some deliberations about a straightforward M:N association that can interrelate the instances of two different entity types.
• In this other one I propose an approach to handle an occurrence of the “Bill of Materials” or “Parts Explosion” construct, in which I describe how to connect distinct instances of the same type of entity.

Ternary associations

There is another important aspect that you brought up via comments (posted in an now-deleted answer):

Every time I try to make a bridge the elements in that bridge also have a Many to Many, I'm under the impression that isn't allowed or at least discouraged.

That circumstance seems to indicate that one of your concerns has to do with conceptual ternary associations. Basically speaking, this sort of associations comes about when there exists (1) a relationship involving (2) two other relationships, in other words “a relationship between relationships” —a typical situation too, since a relationship is an entity in its own right—.

如果管理得当，这些安排也不会带来有害的裁员。而且，是的，如果在某个用例中，您确定此类关系在“现实世界”实体类型中出现，您必须 (i) 建模并 (ii) 在逻辑级别准确地声明它们。

• 这是一个问题和答案，我们分析了一个关于调查的话语领域，其中包括一个三元关联的例子。
• 在这个非常好的答案中，@Ypercube为有趣的菱形关系提供了一个图表和相应的 DDL 结构，这与此类场景非常相似。