Um relacionamento um-para-muitos em um banco de dados ocorre quando cada registro na Tabela A pode ter muitos registros vinculados na Tabela B, mas cada registro na Tabela B pode ter apenas um registro correspondente na Tabela A.
Um relacionamento um-para-muitos em um banco de dados é o design de banco de dados relacional mais comum e está no centro de um bom design.
Bancos de dados também podem implementar um relacionamento um para um e um relacionamento muitos para muitos.
Exemplo de um relacionamento de um para muitos
Considere a relação entre um professor e os cursos que ele ministra. Um professor pode ministrar várias aulas, mas o curso não teria a mesma relação com o professor.
Portanto, para cada registro na tabela Professores, pode haver muitos registros na tabela Cursos. Este exemplo ilustra uma relação de um para muitos: um professor para vários cursos.
Por que é importante estabelecer um relacionamento de um para muitos
Para representar um relacionamento um-para-muitos, você precisa de pelo menos duas tabelas. Vamos ver por quê.
Aderência ao primeiro desenho de forma normal
Talvez tenhamos criado uma tabela na qual queremos registrar o nome e os cursos ministrados. Podemos criar uma tabela de Professores e Cursos como esta:
| Teacher_ID | Nome_do professor | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia |
| Professor_002 | Verônica | Matemática |
| Professor_003 | Jorge | Inglês |
E se Carmen ministrar dois ou mais cursos? Temos duas opções com este design. Poderíamos adicioná-lo ao registro existente de Carmen, assim:
| Teacher_ID | Professor_Nome | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia, Matemática |
| Professor_002 | Verônica | Matemática |
| Professor_003 | Jorge | Inglês |
No entanto, o design acima é inflexível e pode resultar em problemas mais tarde ao inserir, editar ou excluir dados. Isso dificulta a pesquisa de dados.
Este projeto também viola o primeiro princípio da normalização de banco de dados, Primeira Forma Normal (1NF), que afirma que cada célula da tabela deve conter um único e discreto pedaço de dados.
A Segunda Regra da Forma Normal
Outra alternativa de design pode ser adicionar um segundo registro para Carmen:
| Professor_ID | Professor_Nome | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia |
| Teacher_001 | Carmen | Matemática |
| Professor_002 | Verônica | Matemática |
| Professor_003 | Jorge | Inglês |
Esta abordagem segue a 1NF, mas ainda é um design de banco de dados pobre porque introduz redundância e pode inchar um banco de dados grande desnecessariamente. Mais importante, os dados podem se tornar inconsistentes.
Por exemplo, e se o nome de Carmen mudasse? Alguém que trabalha com os dados pode atualizar seu nome em um registro e não conseguir atualizá-lo no segundo registro.
Este design viola o padrão da Segunda Forma Normal (2NF), que adere à 1NF e também deve evitar redundâncias de vários registros. A regra 2NF consegue isso separando subconjuntos de dados em várias tabelas e criando um relacionamento entre eles.
Como projetar um banco de dados com relacionamentos um-para-muitos
Para implementar um relacionamento um-para-muitos na tabela Professores e Cursos, divida as tabelas em duas e vincule-as usando uma chave estrangeira.
Aqui, removemos a coluna Curso na tabela Professores:
| Professor_ID | Professor_Nome |
|---|---|
| Teacher_001 | Carmen |
| Professor_002 | Verônica |
| Professor_003 | Jorge |
E aqui está a tabela de Cursos. Observe que sua chave estrangeira, Teacher_ID, vincula um curso a um professor na tabela Teachers:
| Course_ID | Nome_Curso | Teacher_ID |
|---|---|---|
| Curso_001 | Biologia | Teacher_001 |
| Curso_002 | Matemática | Teacher_001 |
| Curso_003 | Inglês | Professor_003 |
Desenvolvemos uma relação entre a tabela Professores e Cursos usando uma chave estrangeira. Esse arranjo nos diz que Carmen ensina Biologia e Matemática e que Jorge ensina inglês.
Podemos ver como esse design evita possíveis redundâncias, permite que professores individuais ensinem vários cursos e implementa um relacionamento de um para muitos.
