Melhor evitar tabela Associativa

Java Ninja Membro desde: 28/03/2006 09:55:47 Mensagens: 298 Offline

Mauricio Linhares wrote:Muitos materiais sobre orientação a objetos e modelagem de bancos de dados dizem que tabelas associativas não são comuns, porque a maior parte das associações tem algum "dado" a mais que termina virando uma coluna na tabela associativa e fazendo com que ela não seja mais uma simples tabela associativa. Então, associações N:N diretas normalmente simbolizam pouco conhecimento do modelo em questão (ou que você tem um problema bem incomum pra ser resolvido).

Achei isso meio controverso. Por mais que possam existir atributos em uma determinada associação, pode ser que para o seu modelo ele não seja relevante e vc tenha como resultado no modelo físico do banco apenas uma tabela associativa "simples". Posso estar enganado, mas não vejo como algo errado este tipo de tabela associativa.

Abraços,

bonfarj wrote:Achei isso meio controverso. Por mais que possam existir atributos em uma determinada associação, pode ser que para o seu modelo ele não seja relevante e vc tenha como resultado no modelo físico do banco apenas uma tabela associativa "simples". Posso estar enganado, mas não vejo como algo errado este tipo de tabela associativa.

Se no modelo físico já uma coluna de dados na tabela associativa e isso não é refletido no modelo da aplicação, ou o banco de dados ou a aplicação estão modelados de forma incorreta. Não existem dois modelos.

Java Ninja Membro desde: 28/03/2006 09:55:47 Mensagens: 298 Offline

Mauricio Linhares wrote:

bonfarj wrote:Achei isso meio controverso. Por mais que possam existir atributos em uma determinada associação, pode ser que para o seu modelo ele não seja relevante e vc tenha como resultado no modelo físico do banco apenas uma tabela associativa "simples". Posso estar enganado, mas não vejo como algo errado este tipo de tabela associativa.

Se no modelo físico já uma coluna de dados na tabela associativa e isso não é refletido no modelo da aplicação, ou o banco de dados ou a aplicação estão modelados de forma incorreta. Não existem dois modelos.

Talvez não tenha me expressado bem, hehe. Eu quis dizer que, considerando o "mundo real", até podem existir atributos para a associação, mas para o seu modelo esse atributo é totalmente irrelevante e não será considerado. Sendo assim, isso não será refletivo no banco e não porque esteja errado e sim porque não faz sentido.

Abraços,

Deixa eu me meter tambem?

1) Que eu me lembre, é uma boa pratica vc aplicar as regras de normalização (primeira, segunda e terceira formula normal) conforme a necessidade.

2) Quando uma tabela associativa recebe um atributo que não tem nada a ver com a associação, ela se torna automaticamente uma entidade forte deixando de ser simplesmente um recurso de implementação; ou seja, um aspecto muito importante no MODELO.

3) As tecnicas de normalização ACEITA o fato de que em alguns casos uma tabela não NORMALIZADA (formulas normais) possa resultar em maior performance, mas estes casos tem que ser mediante comprovação cientifica; ou seja, mediante testes que comprovam o resultado. Mesmo porque, os problemas de performance sempre estão relacionados a instruções sqls inadequadas, infraestrutura inadequada e uso inadequado/não uso de recursos especias do banco aplicado.

4) Quanto menor e mais otimizado os arquivos de indices mais rápida é a localização dos dados, eu acho que as tabelas associativas ajudam nesta parte.

5) Alto indice de redundancia em uma linha pode fazer com que a tabela fique grande e provocar particionamentos (dba faz isto) sem falar que se houver uma busca por leituras sequenciais em trechos (range scan) a perfomance pode ficar comprometida.

flws

bonfarj wrote:Talvez não tenha me expressado bem, hehe. Eu quis dizer que, considerando o "mundo real", até podem existir atributos para a associação, mas para o seu modelo esse atributo é totalmente irrelevante e não será considerado. Sendo assim, isso não será refletivo no banco e não porque esteja errado e sim porque não faz sentido.

Como eu disse, isso é geralmente, não sempre.

Só acho improvável que haja um atributo na associação e quem está desenvolvendo o modelo resolva ignorar esse atributo intencionalmente pra ficar com a tabela de associação simples. A não ser que o modelo que está sendo criado pra aplicação seja também uma coisa muito simples, que não precise captar realmente a abstração;

Java Ninja Membro desde: 28/03/2006 09:55:47 Mensagens: 298 Offline

Mauricio Linhares wrote:

bonfarj wrote:Talvez não tenha me expressado bem, hehe. Eu quis dizer que, considerando o "mundo real", até podem existir atributos para a associação, mas para o seu modelo esse atributo é totalmente irrelevante e não será considerado. Sendo assim, isso não será refletivo no banco e não porque esteja errado e sim porque não faz sentido.

Como eu disse, isso é geralmente, não sempre.

Só acho improvável que haja um atributo na associação e quem está desenvolvendo o modelo resolva ignorar esse atributo intencionalmente pra ficar com a tabela de associação simples. A não ser que o modelo que está sendo criado pra aplicação seja também uma coisa muito simples, que não precise captar realmente a abstração;

Sim, isso mesmo. Estou partindo do princípio de que o modelo é uma abstração do mundo real, não precisamos pegar tudo, apenas o que for relevante para o nosso contexto.

Um exemplo: imagine que eu tenha um relacionamento N-N entre jogadores e times onde eles já jogaram (um jogador já jogou em uma ou N equipes e uma equipe já teve N jogadores). Eu poderia incluir como atributo desta associação a temporada na qual o jogador X jogou na equipe Y, mas talvez isto não seja necessário para o meu modelo. Consequentemente, meu modelo físico do banco poderia usar uma tabela associativa "simples".

Abraços,

Notícias, artigos e o maior fórum brasileiro sobre Java