Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta

Escolha de lados para representar a cardinalidade entre duas entidades no relacionamento

Olá!

Trago uma dúvida semelhante a de muitos, mas de forma um pouco diferente. Fiquem a vontade para sugerir alguma resposta pré-existente que ajude. Porém a resposta da Maria Gabriela infelizmente não ajudou a validar meu raciocínio que está antes ainda da regra de negócio.

Quando vou pensar na cardinalidade envolvendo duas entidades, encontro uma forma de facilitar o pensamento e assim "automatizá-lo" para lidar com vários casos. Vou usar o controverso caso "Livro-Estoque" em comparação a outro, mas poderia ser qualquer relacionamento.

Eu faço:

  • Uma contagem (daí a cardinalidade) para cada uma das duas entidades A e B relacionadas, evidenciando a quantidade mínima e máxima de relacionamentos com sua "entidade-par";

  • Dessa forma, eu coloco do lado da entidade A a cardinalidade referente à quantidade de relacionamentos de registros dela para com a entidade B.

Por exemplo no caso CLIENTE-PEDIDO, ao lado de CLIENTE eu coloco a quantidade de registros de cliente que estará relacionada a um único registro de pedido.

Assim: CLIENTE(1, 1) - PEDIDO (x, y) pois haverá no mínimo 1 e no máximo 1 registro de cliente relacionado a cada registro de pedido.

  • Finalizando, eu procuro fazer basicamente o mesmo, desta vez na entidade B relacionada à entidade A. E é aí que costumam aparecer problemas. Mas não ainda.

Completando o exemplo anterior, ao lado de PEDIDO eu coloco a quantidade de registros de pedido que estará relacionada a um único registro de cliente.

Assim: CLIENTE(x, y) - PEDIDO (1, n) pois haverá no mínimo 1 e no máximo n registros de pedido relacionados a cada registro de cliente.

Finalizando: CLIENTE(1, 1) - PEDIDO (1, n) o que bate com o raciocínio do professor.

Caso "Livro-Estoque"

Seguindo a premissa de que um livro sempre precisa estar registrado no estoque (independente da quantidade disponível) e que não há sentido em duplicar registros de um mesmo livro eu consigo seguir com meu raciocínio anterior sem problemas:

LIVRO(1, 1) - ESTOQUE (x, y) pois haverá no mínimo 1 e no máximo 1 registro de um determinado livro relacionado a cada registro de estoque.

Porém, veja o que acontece se eu seguir o mesmo raciocínio novamente para o estoque:

LIVRO(x, y) - ESTOQUE (1, 1) pois haverá no mínimo 1 e no máximo 1 registro de estoque relacionado a cada registro de livro. Neste caso eu assumo que, a princípio para uma livraria pequena, um único registro de estoque será sempre suficiente. Mas que deve haver pelo menos um estoque na loja.

Note que, independente das questões de regra de negócio, eu sempre coloco entre parênteses a cardinalidade da entidade que está mais à esquerda:

  • ENTIDADE B (cardinalidade mínima de registros de B, cardinalidade máxima de registros de B)

Já no exemplo do professor a ideia, que eu entendi, foi colocar a cardinalidade do estoque se referindo ainda aos livros e não ao estoque:

  • ENTIDADE B (cardinalidade mínima de A em B, cardinalidade máxima de A em B)

Visto que ele diz: "Eu posso ter um estoque sem livros, e posso ter muitos livros no estoque". Bem, o que está sendo contado ainda não é o estoque, e sim os livros novamente! Para mim, isto poderia ser uma abordagem alternativa para LIVRO (x, y) e não ESTOQUE (x, y).

A minha maior angústia aqui é que em vários casos ele utiliza um raciocínio equivalente ao meu. Mas em outros ele usa este, se referindo duas vezes uma mesma entidade A dos dois lados do relacionamento e deixando a contagem da entidade B ignorada (como foi o caso do estoque).

No mínimo eu gostaria de saber quando eu deveria fazer isso. Mais uma coisa que eu não entendi é porque ele se refere ao PEDIDO ao falar da cardinalidade da entidade LIVRO no relacionamento entre livro e estoque, e não no relacionamento Livro-Pedido, que aliás é abordado apenas na aula seguinte.

Entendo que ele possa se basear numa regra de negócio que tenha motivação em outros relacionamentos do esquema, mas não entendo porque isso deva invalidar o meu raciocínio que se baseia sempre em apenas duas entidades à luz de uma regra pré-definida apenas para elas, momentaneamente.

Eu poderia até inverter a indicação da cardinalidade:

CLIENTE(1, n) - PEDIDO (1, 1), se eu considerar que o que está entre parênteses faz referência a uma chave estrangeira da outra entidade. Ou seja: CLIENTE(1 pedido, n pedidos) - PEDIDO (1 cliente, 1 cliente)

Mas isto ainda segue meu raciocínio original, mudando apenas a convenção dos lados. E aí entra minha terceira e última dúvida, se ambas as formas de definir o lado estariam corretas, desde que seja feito da mesma forma no resto da documentação.

DESCULPEM O TEXTÃO :/

1 resposta
solução!

Oi Felipe, tudo bem?

Desculpa por demorar em te retornar com uma resposta, vamos lá.

Visto que ele diz: "Eu posso ter um estoque sem livros, e posso ter muitos livros no estoque". Bem, o que está sendo contado ainda não é o estoque, e sim os livros novamente! Para mim, isto poderia ser uma abordagem alternativa para LIVRO (x, y) e não ESTOQUE (x, y).

Aqui, nesse caso eu não sei te responder se a cardinalidade está correta ou não, mas eu concordo contigo, o professor acabou ligando essa parte com o pedido e ficou super confuso.

Entendo que ele possa se basear numa regra de negócio que tenha motivação em outros relacionamentos do esquema, mas não entendo porque isso deva invalidar o meu raciocínio que se baseia sempre em apenas duas entidades à luz de uma regra pré-definida apenas para elas, momentaneamente

Isso não invalida o seu raciocínio, tudo bem? Ele faz super sentido.

É bastante complicado essa parte de modelagem, causa bastante confusão na gente. E sinto muito que você e os outros alunos estejam passando por esse tipo de dúvidas.

Essa aula em específico, está sendo regravada. Logo será disponibilizada.

De alguma forma, espero ter ajudado. Qualquer coisa estou por aqui :)

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software