loading...
Cover image for Banco de dados e SQL: Chaves

Banco de dados e SQL: Chaves

thmmarra profile image Thalita Marra ・5 min read

Olá olá!

Esse é o segundo post da série Banco de Dados e SQL: o básico depois do básico, que fala sobre aquilo que a gente precisa saber depois de já saber o mínimo.

Anteriormente falamos sobre relacionamentos e como eles ajudam a organizar os dados. Hoje teremos um pouco de teoria sobre algo intrínseco a banco de dados e modelagem: as chaves.

Vou deixar com um (!) aquilo que eu uso bastante no meu dia a dia #ficaadica

Chave é um atributo ou conjunto de atributos que ajudam a identificar unicamente um registro em uma tabela

Elas são utilizadas para auxiliar na manipulação dos dados, na criação de relacionamentos entre tabelas e na manutenção da integridade dos dados, por exemplo.

Pense numa chave como a identidade do registro, tipo um CPF, RG ou número da CNH que não existe para mais de uma pessoa.

Tipos de chaves

Podemos classificar as chaves de um banco de dados de várias formas. Vou separá-las aqui em grupos e é importante lembrar que as chaves podem ter mais de uma classificação ao mesmo tempo. Bora lá!

Super keys:

O conceito de Super Chave é uma generalização que pode ser dividida em vários subtipos. São características das Super Chaves e seus subtipos:

  • Serem compostas por uma ou mais colunas da tabela
  • Não possuírem valores vazios (NULL)
  • Identificam cada registro de forma única

Vamos usar o exemplo do post anterior onde tínhamos que fazer um banco de dados para um grupo de escolas com seus professores e suas turmas.

Olhando a tabela de Escolas:

Modelagem da tabela Escolas

Temos as seguintes colunas:

  • id: número inteiro auto incremental (o próprio banco já insere automaticamente o último valor +1 nas novas linhas)
  • diretor_id: cópia do id da tabela Professores, que também é um número inteiro auto incremental
  • cep: parte do endereço da escola

Nenhum desses valores se repete, já que id é sequencial, o diretor_id corresponde a um relacionamento de 1:1 entre Professores e Escola e, no nosso negócio, temos apenas uma escola por endereço. Portanto temos 3 Super Chaves, três valores que não se repetem e que podem identificar cada registro na tabela de forma única.

Cada Super Chave pode ser classificada em:

Candidate Key:
Chave Candidata. Possui todas as características das Super Chaves e representa qualquer chave que exista na tabela que possa ser utilizada como Chave Primária.

No nosso exemplo, as três colunas que definimos como Super Chaves são nossas Chaves Candidatas: id, diretor_id e cep.

Primary Key:
Chave Primária. É a chave principal da tabela. Ao contrário das outras chaves, pode existir apenas uma Chave Primária por tabela. É ela que normalmente é referenciada nas demais tabelas quando criamos relacionamentos.

(!) Para definir qual das Chaves Candidatas irá se tornar uma Chave Primária nós precisamos analisar bem o nosso problema. Se nosso banco de dados for servido através de uma API, por exemplo, poderíamos consultar cada Escola através de uma URL mais ou menos parecida com:

GET http://nosso.site/api/escola/PK

Onde PK é a Chave Primária da tabela Escolas.

Agora vamos analisar cada chave:

  • cep: é um valor fácil de ser utilizado porém se uma escola mudar de endereço, o valor do campo será alterado e podemos não encontrar o registro que desejamos;
  • diretor_id: é um valor numérico, auto incremental e não se repete, mas se o diretor mudar então esse valor também irá mudar;
  • id: é apenas um valor numérico, auto incremental e não se repete. É um valor fácil de ser utilizado, não possui nenhuma pontuação ou máscara e não é alterado. Esse seria o candidato mais forte para ser promovido a Chave Primária.

Alternate Key:
Chave Alternativa. Toda chave da tabela que identifica de forma única um registro e que não é a Chave Primária é uma Chave Alternativa.

Continuando nosso exemplo, como definimos que a coluna id será nossa Chave Primária, todas as outras Super Chaves, diretor_id e cep, serão nossas Chaves Alternativas.

Foreign Key:
Chave Estrangeira. É a chave que cria o relacionamento entre tabelas. Também conhecida como FK pelos os íntimos.

(!) Se olharmos o relacionamento entre Escolas e Professores, que define qual professor vai ser o diretor da escola, vemos que ele é definido pela coluna diretor_idna tabela Escolas. Ou seja:

  • Professores.id é uma Chave Primária em Professores e
  • Escolas.diretor_id é a Chave Estrangeira que referencia a Chave Primária do professor na tabela Escolas.

Relacionamento entre Escolas e Professores

Classificação por composição:

As chaves podem ser categorizadas de acordo com a quantidade de colunas que estão em sua composição:

Simple Key:
(!) Chave Simples. É qualquer Super Chave que é formada apenas por uma coluna da tabela.

No exemplo da tabela Escolas, qualquer uma das chaves que falamos aqui (id, diretor_id e cep) é uma Chave Simples já que são formadas por apenas um campo cada.

Compound Key ou Composite Key:
(!) Chaves Compostas. São chaves formadas por dois ou mais campos da tabela. Pode existir Chave Primária Composta, Chave Única Composta, Chave Estrangeira Composta, etc.

Existe uma diferença quando usamos Compound Key e Composite Key:

  • Na Composite Key os elementos (colunas) podem ou não ser uma Chave Estrangeira
  • Na Compound Key pelo menos um dos seus elementos é uma Chave Estrangeira

Ou seja, toda Compound Key é uma Composite Key mas nem toda Composite Key é uma Compound Key.

No relacionamento entre Turmas e Professores vamos adicionar o campo horario. Assim sabemos que cada turma possui apenas um professor por horário mas o mesmo professor pode se repetir em horários diferentes:

Modelagem tabelas Turmas, Professores e a tabela associativa Turmas_Professores

Dessa forma, se quisermos colocar uma chave para ter certeza que cada turma só possui um professor por horário, podemos eleger os campos turma_id, professor_id e horario como partes integrantes de uma Composite Key que também é uma Compound Key, já que torna o registro único e é formado por pelo menos uma Chave Estrangeira.

Na tabela de Professores que vimos acima, se por algum motivo quisermos garantir que o professor não vai ser cadastrado com o mesmo nome e telefone duas vezes, podemos criar uma Composite Key com esses campos sem referenciar nenhuma Chave Estrangeira, portanto não é uma Compound Key.

Classificação por implementação:

Surrogate Key:
(!) Chave Substituta. É uma Chave Artificial pois ela não faz parte dos dados do negócio e existe com o único objetivo de facilitar o controle dos dados. Ela não existe fora da solução de software desenvolvida.

No exemplo da tabela Escolas, definimos que id, diretor_id e cep poderiam ser Super Chaves. Dessas colunas, id e diretor_id são apenas representações dos registros, "atalhos" para facilitar nossa manipulação dos dados. Sendo assim, ambas são classificadas como Chaves Substitutas.

Natural Key:
Chave Natural. Podemos dizer que uma chave é natural quando ela faz parte do conceito do negócio e pode ser utilizada como uma Super Chave.

A coluna cep da tabela Escolas faz parte das informações de uma escola e mesmo se mudarmos de banco de dados essa coluna ainda vai fazer sentido. Ou seja, ela faz parte do escopo do negócio e é uma Super Chave, portanto seria uma Chave Natural.

Como criar uma chave

(!) Nos SGBDs costumamos construir as chaves utilizando Constraints (restrições). Como esse post aqui já tá bem extenso, vou deixar uma publicação no Instagram falando sobre cada uma delas. Pra quem quiser visitar lá depois vou deixar em anexo no final também.


Como sempre, se você chegou até aqui, obrigada! Espero ter conseguido passar um pouco de informação.

Até a próxima!


Posted on by:

thmmarra profile

Thalita Marra

@thmmarra

Brasileira . ela / dela . Desenvolvedora web há alguns anos . Backend . Apaixonada por dados . INTJ-T

Discussion

pic
Editor guide