logo DevMedia  
Home Entenda o site Revistas Canais Cursos Palestras Suporte Fórum +Serviços Assine Compre Créditos

Edição do Mês
  Fórum DevMedia
Fórum de Discussão
Conheça também o NOVO fórum da DevMedia, no endereço: www.devmedia.com.br/forum
O novo fórum possui diversas vantagens! Saiba mais em
www.devmedia.com.br/articles/viewcomp.asp?comp=14726
Estamos sempre trabalhando na melhora do site como um todo! Bons códigos!
Equipe DevMedia

 FAQFAQ   PesquisarPesquisar   MembrosMembros   GruposGrupos  RegistrarRegistrar   
 PerfilPerfil   Entrar e ver Mensagens ParticularesEntrar e ver Mensagens Particulares   EntrarEntrar 
Edição do Mês

Relacionamentos N:N
 
Novo Tópico   Responder Mensagem    Fórum DevMedia - Índice do Fórum -> DBA Area
Exibir mensagem anterior :: Exibir próxima mensagem  
Autor Mensagem
mazeu
Novato


Registrado em: Quinta-Feira, 16 de Setembro de 2004
Mensagens: 28

MensagemEnviada: Ter Ago 29, 2006 3:37 pm    Assunto: Relacionamentos N:N Responder com Citação

Olá Amigos do fórum gostaria de uma assessoria.

Em relacionamentos N:N (Binários ou de grau maior) é criado um terceira tabela. Até aqui tudo bem, porém observo que alguns utilizam as chaves primárias das outras tabelas como Chaves estrangeiras e primárias ao mesmo tempo para a nova tabela e outros optam por criar uma nova chave primária.

Na prática o que é melhor e porque?

Grato,


mazeu
Rolling Eyes
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular Enviar Email
raserafim
Membro Senior


Registrado em: Quinta-Feira, 9 de Outubro de 2003
Mensagens: 1071
Localiza?: Natal-RN

MensagemEnviada: Sáb Set 23, 2006 4:21 pm    Assunto: Responder com Citação

suponhamos que vc tem uma tabela chamada CURSOS (cod_curso) outra chamada ALUNOS (cod_aluno) e uma terceira CURSOS_ALUNOS

digamos que isto seja em um curso privado de informática, então o aluno pode fazer vários ao mesmo tempo.

então o correto é que a tabela CURSOS_ALUNOS tenha como chave primária a chave da tabela ALUNOS e a chave da tabela CURSOS. ou seja a chave primária da tabela CURSOS_ALUNOS será cod_curso e cod_aluno.

desta forma cada curso poderá ter vários alunos e vários alunos poderá estar em vários cursos. e assim vc impede que seja cadastrado o mesmo aluno para o mesmo curso.

se vc colocar um outro campo para ser a chave primária [que é totalmente desnecessário e modelalmente errado] vc não teria como evitar que o mesmo aluno seja cadastrado para o mesmo cursos várias vezes (a não ser que fizesse uma verificação com uma trigger, sendo assim mais um desperdício)

ou seja, o modo correto é que a chave primária da tabela resultante seja um composto da chave primária de uma tabela com a outra.
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
mazeu
Novato


Registrado em: Quinta-Feira, 16 de Setembro de 2004
Mensagens: 28

MensagemEnviada: Seg Set 25, 2006 9:00 am    Assunto: Responder com Citação

Obrigado pela ajuda.

Realmente não pensei neste detalhe. Mas para fechamos o assunto com chave de ouro, outra pergunta:


Muitos fazem isso em busca de performance, mesmo optando pela desnormalização?

Aguardo seu retorno

Grato


Mazeu
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular Enviar Email
raserafim
Membro Senior


Registrado em: Quinta-Feira, 9 de Outubro de 2003
Mensagens: 1071
Localiza?: Natal-RN

MensagemEnviada: Ter Set 26, 2006 12:45 am    Assunto: Responder com Citação

nao acho q tenha algo a ver com a performanca, pois é um campo a mais, e se é autoincremento vai ter uma trigger a mais.

as vezes isso é utilizado por questão de conveniência e praticidade quando esta tabela resultante vai se relacionar com alguma outra.

então no caso em que a tabela resultante tem apenas as chaves primária das outras duas tabela que ela se relaciona, para se relacionar com alguma outra tabela, digamos que 1:N, então seria necessário colocar nesta outra tabela os dois campos que formam a chave primária.

enquanto que se a tabela resultante tivesse um campo autoincremento, bastaria ir apenas este campo.
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
raserafim
Membro Senior


Registrado em: Quinta-Feira, 9 de Outubro de 2003
Mensagens: 1071
Localiza?: Natal-RN

MensagemEnviada: Ter Set 26, 2006 12:48 am    Assunto: Responder com Citação

agora cabe a você qual das duas opções prefere:

ou ficar com a normalização e a garantia de que nao vai ter registros duplicados.

ou então com a provavel praticidade
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular
mazeu
Novato


Registrado em: Quinta-Feira, 16 de Setembro de 2004
Mensagens: 28

MensagemEnviada: Ter Set 26, 2006 9:04 am    Assunto: Responder com Citação

obrigado pela ajuda.

Já trabalhei em várias software houses e infelizmente vejo que muitos programadores e analistas com muitos anos de experiência tem deficiência em modalagem de dados.
Prefiro modelar e depois iniciar a implementação isso tem sido bem produtivo.

Grato

Mazeu Laughing
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular Enviar Email
vanius
Membro Pleno


Registrado em: Quinta-Feira, 8 de Mai de 2003
Mensagens: 206

MensagemEnviada: Seg Nov 05, 2007 5:28 pm    Assunto: Responder com Citação

Boa tarde.

Assunto polemico e a resposta sempre será: "Depende do seu mini-mundo". rsrsrs

Relacionamentos N:N sempre geram 1 terceira tabela.
Se formos seguir a regra a PK da tabela Curso (CODCUR) e a PK da tabela Aluno (CODALU) irao se tornar a chave da tabela Curso_Aluno.
Se o aluno nunca repetir aquele curso a pk sempre tera apenas estes 2 campos. Agora se o aluno puder repetir o curso é bom colocar um campo como "data do curso" ou "periodo".

Algumas "normas" de mercado tem criado o péssimo habito de se criar a chave burra, como ja explicado pelo raserafim. O HSQL (hibernate) tem este pessimo habito.

O ideal é conhecer bem as tecnicas de modelagem de dados. Recomendo a leitura dos livros do Paulo Cougo.

abraços,

Vanius Girodo
Voltar ao Topo
Ver o perfil de Usuários Enviar Mensagem Particular Visitar a homepage do Usuário MSN Messenger
Mostrar os tópicos anteriores:   
Novo Tópico   Responder Mensagem    Fórum DevMedia - Índice do Fórum -> DBA Area Todos os horários são GMT - 3 Hours
Página 1 de 1

 
Ir para:  
Enviar Mensagens Novas: Proibído.
Responder Tópicos Proibído
Editar Mensagens: Proibído.
Excluir Mensagens: Proibído.
Votar em Enquetes: Proibído.


Powered by phpBB © 2001, 2005 phpBB Group
Traduzido por: Suporte phpBB