Olá a todos!!Conversando com meu professor, não tive exatamente uma fixa conclusão de não criar tabelas associativas.
Se você precisa criar um relacionamento M para N, é necessário criar uma tabela associativa - mas isso é só representado no modelo físico, não no modelo lógico.
Não entendi se isso era uma pergunta ??? E se for, qual é a pergunta ???
É que alguns professores disseram que é melhor evitar as tabelas associativas. Gostaria de saber o porquê?
Pergunte ao seu professor.
Que eu saiba, toda vez que você tiver um relacionamento M para N você precisa criar no modelo FÍSICO uma tabela associativa.
No modelo LÓGICO essa tabela não existe, porque é um artefato de implementação.
Você quer dizer que no diagrama (físico) preciso demonstrar, e não implementando (lógico)!?
uma vez eu trabalhei num lugar onde tinha uma tabela que tinha 13 chaves extrangeiras dentro dela, algo como
tabela produto
id_produto
id_item1
id_item2
…
id_item13
ou seja, produto só pode ter no máximo 13 itens, se tiver um 14 item vai ter que usar um alter table ai…
uma das vantagens de voce ter uma tabela associativa é vc evitar isso… agora tudo depende to tipo de BD que vc vai usar, se a query (join) que vc vai ter que usar para recuperar os dados vai ficar pesado, etc…
Valeu ai thingol, andré!
[quote=André Fonseca]uma vez eu trabalhei num lugar onde tinha uma tabela que tinha 13 chaves extrangeiras dentro dela, algo como
tabela produto
id_produto
id_item1
id_item2
…
id_item13
ou seja, produto só pode ter no máximo 13 itens, se tiver um 14 item vai ter que usar um alter table ai…
uma das vantagens de voce ter uma tabela associativa é vc evitar isso… agora tudo depende to tipo de BD que vc vai usar, se a query (join) que vc vai ter que usar para recuperar os dados vai ficar pesado, etc…
[/quote]
Peço desculpas por atuar como coveiro, mas essa realmente me deixou impressionado, não vejo razão para isto.
E aproveitando, gostaria de saber por que este professor afirma que não é uma boa usar tabelas associativas, fiquei curioso.
Abraços,
Em alguns casos (sistemas de extrema-alta-super-ultra performance) não é legal mesmo usar. Imagine uma tabela que tem 4 associações e que tem mais ou menos 400 entradas por segundo… Mais ou menos em casos assim.
[]'s
Verdade, mas se pensarmos em performance boa parte das “boas práticas” de BD vai pro saco, normalização etc. Sendo assim, acho estranho que este professor tenha ressaltado que tabelas associativas não são uma boa, deve ter alguma outra razão que não consigo ver.
Abraços,
Nada. Talvez tenha falado isso apenas p/ se achar ou então é daqueles que gostam de escovar bits.
Tem um sistema bancário aqui que por ex: metade dele é com associativas (a parte que é menos usada), algumas outras partes tem, e as de alta performance não tem nenhuma associação sequer.
[]'s
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).
Um exemplo disso pode ser encontrado no capítulo 5 do livro Domain Driven Design (o exemplo começa na página 82).
Já me intrometendo… rsrs
No modelo logico vc não cria a tabela associativa, apenas destaca a relação. Por exemplo: N produtos podem ser comprados por N clientes.
No modelo fisico vc tem a tabela produto, a tabela cliente e mais a tabela que relacionado os produtos comprados com os clientes.
abraços.
Nem 8 nem 80, normalizar tudo deixa tudo bonitinho, mas joins entre tabelas muito grandes derrubam a performance do banco.
Pergunta pro pessoal do DW se eles gostam de ter que ficar esperando a geração de relatórios que os chefões pedem.
Alguns dados são melhores estarem desnormalizados mesmo, mas tudo depende.
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,
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.
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.[/quote]
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?
-
Que eu me lembre, é uma boa pratica vc aplicar as regras de normalização (primeira, segunda e terceira formula normal) conforme a necessidade.
-
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.
-
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.
-
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.
-
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
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;