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?
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
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?
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!