Relações um-para-muitos em um banco de dados

Índice:

Relações um-para-muitos em um banco de dados
Relações um-para-muitos em um banco de dados
Anonim

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.

Image
Image

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.

Recomendado: