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 um banco de dados é o projeto de banco de dados relacional mais comum e está no centro do bom design.
Considere a relação entre um professor e os cursos que eles ensinam. Um professor pode ensinar vários cursos, mas o curso não teria o mesmo relacionamento com o professor.
Portanto, para cada registro em uma tabela Professores, pode haver muitos registros na tabela Cursos. Este é um relacionamento um-para-muitos: um professor para vários cursos.
Por que estabelecer um relacionamento um-para-muitos é importante
Para representar um relacionamento um-para-muitos, você precisa de pelo menos duas tabelas. Vamos ver porque.
Talvez tenhamos criado uma tabela na qual queríamos registrar o nome e os cursos ministrados. Podemos projetar assim:
| Teacher_ID | Nome do professor | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia |
| Professor_002 | Veronica | Matemática |
| Professor_003 | Jorge | Inglês |
E se Carmen ensinar dois ou mais cursos? Nós temos duas opções com este design. Poderíamos apenas adicioná-lo ao registro existente de Carmen, assim:
| Teacher_ID | Professor_Nome | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia, Matemática |
| Professor_002 | Veronica | Matemática |
| Professor_003 | Jorge | Inglês |
O design acima, no entanto, é inflexível e pode resultar em problemas mais tarde ao tentar inserir, editar ou excluir dados.
Isso dificulta a pesquisa de dados. Esse design viola o primeiro princípio de normalização do banco de dados, First Normal Form (1NF), que determina que cada célula da tabela deve conter uma única parte discreta de dados.
Outra alternativa de design pode ser simplesmente adicionar um segundo registro para Carmen:
| Professor_IDENTIDADE | Professor_Nome | Curso |
|---|---|---|
| Teacher_001 | Carmen | Biologia |
| Teacher_001 | Carmen | Matemática |
| Professor_002 | Veronica | Matemática |
| Professor_003 | Jorge | Inglês |
Isso adere a 1NF, mas ainda é um projeto de banco de dados ruim, pois introduz redundância e pode sobrecarregar desnecessariamente um banco de dados muito grande. Mais importante, os dados podem se tornar inconsistentes. Por exemplo, e se o nome de Carmen fosse alterado? Alguém que trabalha com os dados pode atualizar o nome dela em um registro e não conseguir atualizá-lo no segundo registro. Esse design viola a Segunda Forma Normal (2NF), que adere a 1NF e também deve evitar as redundâncias de vários registros, separando subconjuntos de dados em várias tabelas e criando um relacionamento entre eles.
Como criar um banco de dados com relacionamentos de um para muitos
Para implementar um relacionamento um-para-muitos na tabela Professores e Cursos, dividimos as tabelas em duas e as vinculamos usando uma chave estrangeira.
Aqui, removemos a coluna Curso na tabela Professores:
| Professor_IDENTIDADE | Professor_Nome |
|---|---|
| Teacher_001 | Carmen |
| Professor_002 | Veronica |
| Professor_003 | Jorge |
E aqui está a tabela Cursos. Observe que sua chave estrangeira, Teacher_ID, vincula um curso a um professor na tabela Professores:
| Identidade do curso | Nome do curso | Teacher_ID |
|---|---|---|
| Course_001 | Biologia | Teacher_001 |
| Course_002 | Matemática | Teacher_001 |
| Course_003 | Inglês | Professor_003 |
Desenvolvemos uma relação entre a tabela Professores e Cursos usando uma chave estrangeira.
Isso nos diz que Biologia e Matemática são ensinadas por Carmen e que Jorge ensina inglês.
Podemos ver como esse design evita possíveis redundâncias, permite que os professores individuais ensinem vários cursos e implemente um relacionamento um-para-muitos.
Os bancos de dados também podem implementar um relacionamento um-para-um e um relacionamento muitos-para-muitos.
