No caso da relação entre Item_pedido e Livro eu fiquei com duvida. 1 pedido pode conter n itens no pedido, ok. Porém, nesses vários itens eu posso ter vários livros não posso? Porque vc colocou 1:1? Em cada pedido é um livro?
No caso da relação entre Item_pedido e Livro eu fiquei com duvida. 1 pedido pode conter n itens no pedido, ok. Porém, nesses vários itens eu posso ter vários livros não posso? Porque vc colocou 1:1? Em cada pedido é um livro?
hoje, com a Alura e o Google Gemini
Ou isso foi feito justamente para resolver o problema de n:n
Oiii Bruno, como você está?
Peço desculpas pela demora.
A tabela ITENS_PEDIDO foi feita sim para resolver o problema n:m (muitos para muitos). Ela concentra as ocorrências de muitos livros em muitos pedidos de forma a cada ocorrência ter uma identificação única.
Vamos voltar ao modelo conceitual para observar esse comportamento.
Se destrincharmos a entidade associativa, ela estaria representada da seguinte forma:
A cardinalidade (1,1) ao lado da tabela Livro diz respeito ao sentido de leitura “item_pedido contém livro”:
No sentido de leitura “livro está contido em item_pedido” temos a seguinte interpretação:
Caso o mesmo livro (com o mesmo id_livro) seja vendido em mais de uma unidade em um mesmo pedido, uma boa solução é criar um atributo de quantidade na entidade associativa.
Veja o exemplo na imagem. Por questões didáticas, desprezei os outros atributos das entidades Pedido e Livro, deixando apenas suas chaves primárias, que são estrangeiras em item_pedido.
Assim, a cada linha da tabela Item_pedido teremos as seguintes informações:
Bruno, espero que tenha ficado mais claro. Não hesite em me contar caso tenha ficado alguma dúvida.
Abraço!