Dependências entre tabelas em um banco de dados

4.1 Introdução

Ao converter as tabelas do banco de dados em tabelas regulares, agora você pode analisar as relações entre elas. O número de elementos interagindo entre duas tabelas relacionadas é chamado de cardinalidade. A cardinalidade ajuda a controlar com que eficiência você particionou seus dados em tabelas.

Teoricamente, todas as entidades podem manter relacionamentos entre si, mas, na prática, existem três tipos de relacionamentos entre entidades:

• Um a um
• Um para muitos
• muitos para muitos

4.2 Comunicação um-para-um

Se houver apenas uma instância da entidade A para cada instância da entidade B, diz-se que elas têm um relacionamento um-para-um (geralmente denotado como "1:1"). Nos diagramas ER, tal relação é indicada por uma linha com uma pequena barra em cada extremidade:

Uma relação 1:1 geralmente indica que, a menos que você tenha um bom motivo para mantê-los separados, é melhor combinar os dados das duas tabelas em uma.

No entanto, em algumas circunstâncias, é razoável usar tabelas com relacionamentos 1:1. Se suas tabelas tiverem campos com dados opcionais, como descrições, e em muitos casos estiverem vazios, faz sentido mover todas as descrições para uma tabela separada, o que permitirá que você se livre de lacunas frequentes e aumente a eficiência do seu banco de dados .

Então, para mapear corretamente os dados, você terá que incluir pelo menos uma coluna idêntica em cada tabela (é melhor escolher uma chave primária para isso).

4.3 Relação um-para-muitos

Esse tipo de relacionamento ocorre quando um registro em uma tabela está associado a várias entidades em outra. Por exemplo, o mesmo cliente pode fazer vários pedidos ou um visitante da biblioteca pode pegar vários livros emprestados em uma única visita. As relações um-para-muitos (ou 1:M para abreviar) são expressas em um diagrama usando a notação pés de galinha, conforme mostrado no exemplo abaixo:

Para aplicar um relacionamento 1:M ao planejar um banco de dados, simplesmente adicione a chave primária da tabela "um" como um atributo à tabela "muitos". Se a chave primária estiver em outra tabela, ela é chamada de "chave estrangeira". A tabela "um" é considerada a tabela pai, enquanto a tabela "muitos" é considerada a tabela filha.

4.4 Relação muitos-para-muitos

Quando várias entidades em uma tabela podem ser conectadas a várias entidades em outra, elas são consideradas como tendo um relacionamento muitos-para-muitos (ou M:M). Por exemplo, existe essa relação entre alunos e turmas, pois cada aluno pode frequentar várias turmas diferentes e, consequentemente, muitos alunos podem vir a cada turma.

No diagrama ER, esse tipo de relacionamento é exibido da seguinte forma:

Infelizmente, é impossível implementar diretamente tal relacionamento no banco de dados. Portanto, ele terá que ser dividido em dois relacionamentos um-para-muitos.

Para fazer isso, você precisará criar uma nova entidade entre as duas tabelas. Se for estabelecida uma relação M:M entre vendas e produtos, a nova entidade pode ser chamada de “produtos vendidos” porque representará o conteúdo de cada venda.

Com "mercadorias vendidas" e a tabela "vendas" e a tabela "mercadorias" serão vinculadas pelo tipo 1:M. Em modelos diferentes, essas entidades intermediárias são chamadas de forma diferente - "tabelas de conexão", "entidades associativas" ou "tabelas de nós".

Cada entrada da tabela de links conecta duas entidades diferentes de tabelas adjacentes (e também pode conter informações adicionais). Por exemplo, uma tabela de links entre alunos e turmas pode ter esta aparência:

4.5 Obrigatório ou não?

Outra abordagem para análise de link é determinar qual das entidades conectadas é um pré-requisito para a presença de outra entidade. O lado do link opcional é marcado com um círculo no tronco.

Por exemplo, para que um estado tenha seu próprio representante na ONU, ele deve existir no mapa-múndi, mas a afirmação em contrário será falsa:

Duas entidades podem ser interdependentes (ou seja, uma não pode existir sem a outra).

links recursivos

Às vezes, uma tabela pode se referir a si mesma. Por exemplo, uma tabela de funcionários pode ter um atributo "manager" que nos remete a outro funcionário na mesma tabela. Este é o relacionamento recursivo.

Conexões extras

Os links são considerados redundantes se forem expressos mais de uma vez. Como regra, um deles pode ser excluído sem perder informações importantes. Por exemplo, se a entidade “alunos” estiver ligada à entidade “professores” não só diretamente, mas também indiretamente através de “aulas”, faz sentido retirar a relação entre as entidades “alunos” e “professores”. Esta decisão justifica-se pelo facto de ser possível atribuir alunos a professores apenas através de aulas.

4.6 Integridade referencial dos dados

Ao alterar as chaves primárias e estrangeiras, deve-se observar um aspecto como a integridade referencial dos dados . Sua ideia principal é manter duas tabelas em um banco de dados que armazenam os mesmos dados de forma consistente.

A integridade dos dados representa relacionamentos construídos corretamente entre tabelas com vinculação correta entre eles. Em que casos a integridade dos dados pode ser violada:

• Anomalia de deleção . Ocorre quando uma linha é excluída da tabela principal. Nesse caso, a chave estrangeira da tabela dependente continua a se referir à linha excluída da tabela principal.
• Anomalia de inserção . Ocorre quando uma linha é inserida em uma tabela dependente. Nesse caso, a chave estrangeira da tabela dependente não corresponde à chave primária de nenhuma das linhas da tabela mestre.
• Anomalia de atualização . Com tal anomalia, várias linhas de uma tabela podem conter dados pertencentes ao mesmo objeto. Se você alterar os dados em uma linha, eles podem entrar em conflito com os dados de outra linha.

Anomalia de exclusão

Para resolver a anomalia de exclusão, a chave estrangeira deve ser definida para uma das duas restrições:

Se uma linha de uma tabela dependente requer necessariamente uma linha da tabela mestre, a chave estrangeira é definida como exclusão em cascata. Ou seja, quando uma linha é excluída da tabela mestre, a(s) linha(s) associada(s) é(são) excluída(s) da tabela dependente.

Se uma linha de uma tabela dependente não permite nenhuma relação com uma linha da tabela principal (isto é, tal relação é opcional), a chave estrangeira é definida como NULL quando a linha relacionada é excluída da tabela principal. A coluna de chave estrangeira deve ser anulável.

Anomalia de inserção

Para resolver a anomalia de inserção ao adicionar a uma tabela de dados dependentes, a coluna que representa a chave estrangeira deve ser anulável. E assim, se o objeto que está sendo adicionado não tiver conexão com a tabela principal, a coluna da chave estrangeira terá um valor NULL.

Atualizar anomalias

Para resolver o problema de anomalia de atualização, a normalização é aplicada, o que foi discutido anteriormente.