Diferença entre relacionamento um-para-muitos e muitos-para-um

Qual é a diferença real entre relacionamento um-para-muitos e muitos-para-um? É apenas invertido, mais ou menos?

Não consigo encontrar nenhum tutorial 'bom e fácil de entender' sobre este tópico além deste: SQL para iniciantes: Parte 3 - Relacionamentos de banco de dados

Sim, é vice-versa. Depende de qual lado do relacionamento a entidade está presente.

Por exemplo, se um departamento pode empregar vários funcionários, então, departamento para funcionário é um relacionamento de um para muitos (1 departamento emprega muitos funcionários), enquanto o relacionamento de funcionário para departamento é de muitos para um (muitos funcionários trabalham em um departamento).

Mais informações sobre os tipos de relacionamento:

Relacionamentos de banco de dados - documentação do IBM DB2

Nesta página sobre Terminologia de Banco de Dados

A maioria das relações entre as tabelas é de um para muitos.

Exemplo:

• Uma área pode ser o habitat de muitos leitores.
• Um leitor pode ter várias assinaturas.
• Um jornal pode ter muitas assinaturas.

Uma relação de muitos para um é o mesmo que um para muitos, mas de um ponto de vista diferente.

• Muitos leitores vivem em uma área.
• Muitas assinaturas podem ser de um mesmo leitor.
• Muitas assinaturas são para o mesmo jornal.

Qual é a diferença real entre relacionamento um-para-muitos e muitos-para-um?

Existem diferenças conceituais entre esses termos que devem ajudá-lo a visualizar os dados e também possíveis diferenças no esquema gerado que devem ser totalmente compreendidos. A diferença, porém, é principalmente de perspectiva.

Em um relacionamento um-para-muitos , a tabela local possui uma linha que pode ser associada a muitas linhas em outra tabela. No exemplo do SQL para iniciantes , um Customerpode estar associado a vários Orders.

No relacionamento oposto muitos para um , a tabela local pode ter muitas linhas associadas a uma linha em outra tabela. Em nosso exemplo, muitos Orders podem estar associados a umCustomer . Essa diferença conceitual é importante para a representação mental.

Além disso, o esquema que suporta o relacionamento pode ser representado de forma diferente nas tabelas Customere Order. Por exemplo, se o cliente tiver colunas ide name:

id,name
1,Bill Smith
2,Jim Kenshaw

Então, para que um Orderseja associado a a Customer, muitas implementações SQL adicionam à Ordertabela uma coluna que armazena o iddo associado Customer(neste esquema customer_id:

id,date,amount,customer_id
10,20160620,12.34,1
11,20160620,7.58,1
12,20160621,158.01,2

Nas linhas de dados acima, se olharmos para a customer_idcoluna id, vemos que Bill Smith(customer-id # 1) tem 2 pedidos associados a ele: um de $ 12,34 e outro de $ 7,58. Jim Kenshaw(ID do cliente # 2) tem apenas 1 pedido por $ 158,01.

O que é importante perceber é que normalmente a relação um-para-muitos não adiciona nenhuma coluna à tabela que é "um". O Customernão tem colunas extras que descrevem o relacionamento com Order. Na verdade, o Customerpoder também têm um relacionamento um-para-muitos com ShippingAddresse SalesCallmesas e ainda não têm colunas adicionais à Customertabela.

No entanto, para que um relacionamento muitos-para-um seja descrito, geralmente uma idcoluna é adicionada à tabela "muitos" que é uma chave estrangeira para a tabela "um" - neste caso, uma customer_idcoluna é adicionada ao Order. Ao pedido nº 10 associado por $ 12,34 Bill Smith, atribuímos a customer_idcoluna ao Bill Smithid 1 de.

No entanto, também é possível que haja outra tabela que descreva o relacionamento Customere Order, de forma que nenhum campo adicional precise ser adicionado à Ordertabela. Em vez de adicionar um customer_idcampo à Ordertabela, pode haver uma Customer_Ordertabela que contém chaves para Customere Order.

customer_id,order_id
1,10
1,11
2,12

Nesse caso, o um-para-muitos e muitos-para-um são todos conceituais, pois não há mudanças de esquema entre eles. Qual mecanismo depende de seu esquema e implementação de SQL.

Espero que isto ajude.

Não há diferença. É apenas uma questão de idioma e preferência para definir o relacionamento.

A resposta à sua primeira pergunta é: ambos são semelhantes,

A resposta à sua segunda pergunta é: um para muitos -> um homem (mesa MAN) pode ter mais de uma esposa (mesa MULHERES) muitos para um -> mais de uma mulher se casou com um homem.

Agora, se você deseja relacionar esta relação com duas tabelas MAN e WOMEN, uma linha da tabela MAN pode ter muitas relações com as linhas da tabela WOMEN. espero que esteja claro.

Exemplo

Duas tabelas com uma relação

SQL

Em SQL, existe apenas um tipo de relacionamento, é chamado de Referência. (Seu front end pode fazer coisas úteis ou confusas [como em algumas das Respostas], mas isso é uma história diferente.)

• Uma chave estrangeira em uma tabela (o referenc ing tabela)
  Referências
  a chave primária em outra tabela (o referenc ed tabela)

• Em termos SQL, Bar faz referência a Foo
  Não o contrário

  CREATE TABLE Foo (
      Foo   CHAR(10)  NOT NULL, -- primary key
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK             -- constraint name
          PRIMARY KEY (Foo)     -- pk
      )  
  CREATE TABLE Bar (
      Bar   CHAR(10)  NOT NULL, -- primary key
      Foo   CHAR(10)  NOT NULL, -- foreign key to Foo
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK                -- constraint name
          PRIMARY KEY (Bar),       -- pk
      CONSTRAINT Foo_HasMany_Bars  -- constraint name
          FOREIGN KEY   (Foo)      -- fk in (this) referencing table
          REFERENCES Foo(Foo)      -- pk in referenced table
      )

• Uma vez que Foo.Fooé uma chave primária, é única, há apenas uma linha para qualquer valor deFoo

• Como Bar.Fooé uma referência, uma chave estrangeira e não há um índice exclusivo nela, pode haver muitas linhas para qualquer valor deFoo
• Portanto, a relação Foo::Baré de um para muitos
• Agora você pode perceber (olhar para) a relação ao contrário,Bar::Foo é de muitos para um
  • Mas não se deixe confundir: para qualquer Barlinha, há apenas uma Foolinha que faz referência
• Em SQL, é tudo o que temos. Isso é tudo o que é necessário.

Qual é a diferença real entre um para muitos e muitos para um relacionamento?

Existe apenas uma relação, portanto não há diferença. A percepção (de um "fim" ou de outro "fim") ou a leitura de trás para frente não muda a relação.

Cardinalidade

A cardinalidade é declarada primeiro no modelo de dados, o que significa Lógico e Físico (a intenção), e depois na implementação (a intenção realizada).

Cardinalidade

Um para zero para muitos
No SQL, isso (acima) é tudo o que é necessário.

Um para um para muitos
Você precisa de um transação para impor o um na tabela de Referência.

Um para zero para um que
você precisa em Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

Um para um,
você precisa de uma transação para fazer valer o que está na tabela de referência.

Muitos para muitos
Não existe tal coisa no nível Físico (lembre-se, existe apenas um tipo de relação no SQL).

Nos primeiros níveis lógicos durante o exercício de modelagem, é conveniente traçar tal relação. Antes que o modelo chegue perto da implementação, é melhor que ele seja elevado para usar apenas coisas que podem existir. Essa relação é resolvida com a implementação de uma Tabela Associativa.

Resolvido muitos para muitos

Um-para-Muitos e Muitos-para-Um são semelhantes em Multiplicidade, mas não em Aspectos (ou seja, Direcionalidade).

O mapeamento de associações entre classes de entidade e os relacionamentos entre tabelas. Existem duas categorias de relacionamentos:

1. Multiplicidade (termo ER: cardinalidade)
   • Relacionamentos um-para-um : exemplo marido e mulher
   • Relacionamentos de um para muitos : exemplo mãe e filhos
   • Relações muitos para muitos : exemplo de aluno e assunto
2. Direcionalidade : não afeta o mapeamento, mas faz diferença em como podemos acessar os dados.
   • Relacionamentos unidirecionais : um campo ou propriedade de relacionamento que se refere à outra entidade.
   • Relacionamentos bidirecionais : Cada entidade possui um campo ou propriedade de relacionamento que se refere à outra entidade.

Não há diferença prática. Apenas use o relacionamento que faz mais sentido, dada a maneira como você vê o seu problema, conforme ilustrado por Devendra.

• --- Um para muitos --- A Os pais podem ter dois ou mais filhos.

• --- Muitos para um --- Esses 3 filhos podem ter pais solteiros.

  Ambos são semelhantes. Isso pode ser usado pertence à necessidade. Se você quer encontrar filhos para alguns pais em particular, pode escolher o Um-para-muitos. ou então, quer encontrar pais para gêmeos, você pode ir com o Muitos-para-um. Da mesma forma....,

um-para-muitos tem classe pai contém n número de filhos, portanto, é um mapeamento de coleção.

muitos para um tem n número de filhos contém um pai, então é um mapeamento de objeto