Sim, a identificação de associações ou relacionamentos muitos-para-muitos (M:N para abreviar) é uma situação que um profissional de banco de dados enfrenta com bastante frequência ao elaborar um esquema conceitual. As associações das referidas razões de cardinalidade ocorrem em ambientes de negócios de natureza muito diferente e, quando devidamente representadas no nível lógico por meio de, por exemplo, um arranjo SQL-DDL, não introduzem redundâncias prejudiciais.

Desta forma, o objetivo de um exercício de modelagem de banco de dados deve ser espelhar as características relevantes do contexto de negócios de interesse com alta precisão ; portanto, se você identificar corretamente que existem inúmeras associações M:N, então você deve expressá-las (a) no esquema conceitual e também (b) nas respectivas declarações de nível lógico, não importa quantas conexões disso - ou qualquer outros tipos de taxas de cardinalidade devem ser abordadas.

Regras do negócio

Você forneceu uma pergunta bem contextualizada e também esclareceu que o banco de dados em que está trabalhando é puramente hipotético, o que é um ponto importante, pois considero que um cenário de negócios do “mundo real” como o que está sendo considerado seria muito mais extenso e, portanto, implicaria requisitos informacionais mais complexos.

Decidi (1) fazer algumas modificações e expansões nas regras de negócios que você forneceu para (2) produzir um esquema conceitual mais descritivo —embora ainda bastante hipotético—. Aqui estão algumas das formulações que eu montei:

• Uma Parte ¹ é uma Pessoa ou uma Organização
• Uma Party é classificada por exatamente um PartyType
• Um PartyType classifica zero-um-ou-muitos partidos
• Uma organização desenvolve zero-um-ou-muitos produtos
• Um produto é um sistema ou um jogo
• Um Produto é classificado por exatamente um ProductType
• Um sistema é catalogado por exatamente um SystemType
• Um jogo pode ser jogado através de sistemas um-para-muitos
• Um sistema é usado para jogar um-para-muitos jogos
• Um jogo é classificado por zero-um-ou-muitos gêneros
• Um gênero classifica jogos zero-um-ou-muitos
• Um produto origina trabalhos um-para-muitos
• Um Trabalho é realizado por zero-um-ou-muitos Pessoas , que desempenham o Papel de Colaboradores
• Uma pessoa é um colaborador em zero-um-ou-muitos trabalhos

^{1 Parte é um termo utilizado em contextos jurídicos quando se refere a um indivíduo ou a um grupo de indivíduos que compõem uma única entidade, pelo que esta denominação é adequada para representar Pessoas e Organizações .}

Diagrama IDEF1X

Posteriormente, criei o diagrama IDEF1X ² mostrado na Figura 1 (não deixe de clicar no link para vê-lo em maior resolução), consolidando em um único dispositivo gráfico as regras de negócio apresentadas acima (juntamente com algumas outras que me parecem relevantes):

^{2 Definição de integração para modelagem de informações ( IDEF1X ) é uma técnica de modelagem de dados altamente recomendável que foi estabelecida como padrão em dezembro de 1993 pelo Instituto Nacional de Padrões e Tecnologia (NIST) dos Estados Unidos. Baseia-se em (a) o material teórico inicial de autoria do único criador do modelo relacional, ou seja, Dr. EF Codd; sobre (b) a visão entidade-relacionamento de dados, desenvolvida pelo Dr. PP Chen ; e também sobre (c) a Logical Database Design Technique, criada por Robert G. Brown.}

Como você pode ver, descrevi apenas três associações M:N por meio dos tipos de entidades associativas correspondentes , ou seja:

• Colaborador
• SystemGame
• GameGenre

Entre outros aspectos, existem duas estruturas distintas de supertipo-subtipo , onde:

• Person e Organization são subtipos de entidade mutuamente exclusivos de Party , seu supertipo de entidade

• Produto é o supertipo de Sistema e Jogo , que por sua vez são subtipos mutuamente exclusivos

Caso você não esteja familiarizado com as associações supertipo-subtipo, você pode encontrar ajuda, por exemplo, minhas respostas às perguntas intituladas:

• “ Modelar um cenário em que cada Artista Musical é um Grupo ou um Artista Solo ”
• “ Como modelar um tipo de entidade que pode ter diferentes conjuntos de atributos? ”
• “ Desenvolver um banco de dados para um negócio de transferência de fundos onde (a) pessoas e organizações podem (b) enviar e receber dinheiro ”
• “ Modelando uma estrutura de banco de dados para vários tipos de usuários e suas informações de contato ”

Layout lógico SQL-DDL ilustrativo

Sucessivamente, devemos garantir que, no nível lógico:

• Cada tipo de entidade é representado por uma tabela base individual
• Cada propriedade única do tipo de entidade aplicável é indicada por uma coluna específica
• Um tipo de dados exato é fixado para cada coluna para garantir que todos os valores que ela contém pertençam a um conjunto específico e bem definido, seja INT, DATETIME, CHAR, etc. (claro, ao usar, por exemplo, Firebird ou PostgreSQL , você pode querer empregar os DOMAINs mais poderosos)
• Múltiplas restrições são configuradas (declarativamente) para garantir que as asserções em forma de linhas retidas em todas as tabelas cumpram as regras de negócio determinadas no nível conceitual

Então declarei o seguinte arranjo DDL com base no diagrama IDEF1X mostrado anteriormente:

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)
);

It is opportune to stress that there are declarations of composite PRIMARY KEY constraints across several tables, which stand for the hierarchy of connections that take place among conceptual entity types, arrangement that can be very beneficial with respect to data retrieval when, e.g., expressing SELECT operations that include JOIN clauses to obtain derived tables.

Yes, (i) every M:N association and (ii) every one of the associated entity types are denoted by (iii) the corresponding table in the logical DDL structure, so pay special attention to the PRIMARY and FOREIGN KEY constraints (and the notes I left as comments) of tables representing these conceptual elements, because they assist in ensuring that the connections between the relevant rows meet the applicable cardinality ratios.

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—.

Esses arranjos, quando bem administrados, também não trazem redundâncias prejudiciais. E, sim, se houver um determinado caso de uso em que você identifica que tais relacionamentos se apresentam entre os tipos de entidade do “mundo real”, você deve (i) modelar e (ii) declará-los com precisão no nível lógico.

• Aqui está uma pergunta e resposta onde analisamos um domínio de discurso sobre pesquisas , que inclui um exemplo de associação ternária.
• Nesta resposta muito boa , o @Ypercube apresenta um diagrama e a respectiva estrutura DDL para uma relação em forma de diamante interessante , que é muito semelhante a esta classe de cenários.