A modelagem é uma fase fundamental no desenvolvimento de sistemas, pois é a partir dela que sabemos quais classes teremos na aplicação, bem como quais tabelas serão criadas no banco de dados.
Há, no entanto, situações que na hora da modelagem se mostram mais complexas do que pareciam inicialmente. Por exemplo, podemos ficar em dúvida sobre qual tipo de relacionamento ocorre entre duas entidades, se 1:N ou N:N. De forma semelhante, mesmo sabendo o relacionamento pode ser preciso repetir dados entre as tabelas, gerando certa redundância para atender algum cenário específico. Essas e outras situações foram apresentadas e discutidas nesse DevCast.
Situações curiosas de modelagem
Nesse DevCast discutimos algumas situações interessantes de modelagem que são ilustradas abaixo:
Tópico 1: Produtos x Categorias
O primeiro cenário apresentado foi a modelagem de um portal de conteúdo (artigos, vídeos, etc.). Inicialmente consideramos que cada post possuía apenas um autor, o que nos levou à modelagem ilustrada na Figura 1.
No entanto, com o passar do tempo percebemos que cada conteúdo poderia sim ter mais de um autor, porém a modelagem inicial não suportava isso. Para atender esses casos seria necessário que a modelagem fosse feita como na Figura 2, com um relacionamento do tipo N:N.
Situação semelhante se dá em um cadastro de produtos com suas categorias. Se considerarmos que um produto só pertence a uma categoria, podemos modelar como na Figura 3, da forma 1:N.
Porém, se considerarmos que um produto pode estar vinculado a mais de uma categoria, então a modelagem mais adequada seria do tipo N:N, como mostra a Figura 4:
Tópico 2: Replicação de dados na venda
Outro assunto tratado no DevCast foi a replicação de dados entre tabelas, mesmo havendo entre elas um relacionamento bem definido. Por exemplo, em um cenário em que temos uma venda com vários itens, apesar de o item armazenar o código/id do produto a que se refere, é comum a repetição de dados como Nome e Preço do produto no item, para manter o histórico dessas informações, como ilustra a Figura 5.
Situação semelhante ocorre quando temos a emissão de notas fiscais. Nesses casos normalmente optamos por manter a redundância de dados tanto na venda quanto na nota e seus itens, como vemos na Figura 6.
Observe que aqui há uma dupla redundância: os dados do cliente se repetem tanto na venda, quanto na nota. Da mesma forma os dados do produto se repetem tanto no item da venda quanto no item da nota. Isso permite efetuar consultas e procedimentos isoladamente em cada entidade (venda e nota), sem que uma dependa da outra.
Tópico 3: Relacionamentos N:N
Um caso comum de relacionamento N:N se dá entre alunos e turmas. Um aluno pode estar vinculado a várias turmas, da mesma forma que uma turma é composta por vários alunos. Nesses casos sempre surge uma tabela intermediária responsável por armazenar o relacionamento entre as duas entidade principais, como vemos na Figura 7.
Ainda no contexto de relacionamentos N:N comentamos aqui do que ocorre em um sistema de consultório odontológico. Quando um paciente vai se consultar ele pode efetuar procedimentos (serviços) em vários dentes. E pode, ainda, efetuar mais de um procedimento no mesmo dente. Ou seja, um dente pode receber vários procedimentos e um procedimento é aplicável a vários dentes. Esse cenário está ilustrado na Figura 8.
