Olá pessoal da madrugada, tenho uma dúvida: quando em um relacionamento percebo que a cardinalidade é oneToMany, ou manyToOne(não imorta) devo avisar o meu banco de dados mysql de alguma maneira? ou esse conceito é apenas ilustrativo em um diagrama de MER(ER) ?
Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas
respostas
Sobre cardinalidade
Thiago, os relacionamentos afetam o poscionamento de FKs (foreign keys - chaves estrangeiras). Decidir o tipo de relacionamento é justamente decidir onde ficam essas chaves e dizer como as tabelas se relacionam. Ex.:
Considere duas entidades: Aluno e Notas
Considere que em nossa escola, 1 aluno tem muitas Notas, mas a nota é vinculada a um unico aluno. então temos um relacionamento 1:N (OneToMany), logo a tabela nota deve ter o id do aluno que tem vinculo.
Considere agora que em 1 Aluno está em um unico curso e cada curso possui muitos alunos. Do ponto de vista do aluno N:1 (ManyToOne), a chave do curso deve estar no aluno.
Considere que nossa regra diz que 1 aluno tem muitas Cursos e 1 Curso tem muitos alunos; Logo temos um relacionamento N:N muitos para muitos, o qual cria uma tabela intermediaria com o relacionamento da chave do aluno e do curso.
Resumidamente, depende do nosso contexto e da regra de negócio e qual angulo olhamos. Decidir o relacionamento afeta a forma como os dados se relacionam. Falando a nível de banco, é decidir onde a chave quando O MER vira um DER, em APIs de ORM como Hibernate, isso é definido no código de mapeamento.
Existe uma regra? toda ver que tiver um N:N devo ter uma tabela intermediária com o ID de ambos. toda vez que tiver um 1:N a tabela que corresponde a N deve estar(ter chave) na 1. toda vez que tiver um N:1 a tabela que corresponde a 1 deve estar(ter chave) em N.
solução!
A regra é:
N:N -> sempre tem tabela intermediaria
1:N ou N:1 a chave sempre ta no N.
1:1 você escolhe onde fica a chave baseado em como você pretende executar um select de recuperação da informação.
Carlos, agora a parada fechou cara, vc é foda! ajudou p krl.