Conceitos Básicos de Banco de Dados – Primary e Foreign Keys: Restrições e Integridade de Dados

Em uma estrutura de Banco de Dados Relacional, a maneira pelo qual podemos garantir a integridade das informações é através das ‘Constraints’ ou em ‘bom português’, simplesmente ‘Restrições’.

Estas ‘restrições’, visam evitar que, os dados tornem-se inconsistentes ou 'repetidos' e são a raiz do bom desempenho e confiabilidade das informações.

Basicamente, existem 2 tipos de Constraint:

• Primary Keys (Chaves Primarias)
• Foreign Keys (Chaves Estrangeiras)

Independente do SGDB (Sistema Gerenciador de Banco de Dados) utilizado, vamos ilustrar a seguinte situação:

• Você possui uma tabela chamada CLIENTES 
• Nesta tabela existem apenas 2 campos 
• CLIENTE_ID 
• NOME 

A ‘primeira’ Constraint que esta (assim como toda) tabela deverá possuir é a ‘Primary Key’, em português ‘Chave Primária’ ou simplesmente ‘PK’.

Primary Keys / Chaves Primarias

Uma chave primária, como o próprio nome sugere é a primeira restrição, controle de um registro e garante que os registros não se repitam em uma tabela, ou seja, em nosso exemplo, você não terá o mesmo cliente cadastrado 2x ou mais já que, cada registro será único e é, justamente por isto que dentre outros critérios, uma chave primaria nunca poderá ser um campo que ‘possivelmente’ ser repetirá, como ‘nome’ por exemplo.

Mas esta seleção de ‘qual campo ou campos irão compor a Primary Key’, deverá considerar outros fatores, além é claro da forma como a tabela está sendo planejada, estes campos não poderão estar ‘vazios’ ou seja, possuir valores nulos, propriedade esta conhecida por ‘NOT NULL’, ou seja, além dos valores nunca poderem se repetir, nenhum campo que componha a chave primaria poderá estar ‘vazio’.

No exemplo, criamos então um campo simplesmente chamado CLIENTE_ID, pois, para eventuais consultas, Selects, Updates e demais operações, será mais fácil identificar o registro por um campo numérico (este é um dos outros fatores que, devem ser levados em consideração quando da definição de uma PK, porém isto não é uma regra, esta e outras dependerão de qual modelo de ‘normalização’ será utilizada em seu BD).

Sendo assim, definiremos a PK da tabela CLIENTES como sendo o campo CLIENTE_ID, este que, por sua vez, poderá receber a propriedade ‘auto incremento’ ou seja, a cada registro incluído, um novo código/número será associado a este campo. Dependendo do SGDB utilizado, este poderá possuir um ‘tipo’ já preparado para este fim, porém no caso do “Oracle”, tem-se que recorrer a outros recursos, como a utilização de ‘Sequences’ (sequencias), estas que deverão ser acionadas através de ‘Triggers’ (gatilhos) ou de outros modos, no entanto este assunto, trataremos em uma próxima oportunidade.

Para ilustras o que falamos agora, os comandos (no Oracle) para criação de nossa tabela seriam os que seguem abaixo:

-- Criação da tabela

CREATE TABLE CLIENTES

(

  CLIENTE_ID NUMBER NOT NULL,

  NOME VARCHAR2(60)

);

-- Criando a Primary Key

ALTER TABLE

  CLIENTES

ADD CONSTRAINT

  PKCLIENTES

PRIMARY KEY

  (CLIENTE_ID);

Nesta tabela de clientes, não seria necessária acrescentar mais que um campo para nossa Primary Key, porém, caso queira fazê-lo, basta acrescentar, no comando onde é adicionado a PK, além do código o nome do campo desejado. Geralmente isto ocorre em tabelas ‘filhas’, onde a PK é composta da PK da tabela ‘mãe’ mas sua própria, o que pode por exemplo ser ilustrado pelo exemplo abaixo:

• Tabela PEDIDOS
  
  • Esta tabela contém dentro outros campos:
    • PEDIDO_ID (que é a PK desta tabela)
    • CLIENTE
    • DATA
      

• Tabela PEDIDO_ITENS
  • Esta tabela conterá os ‘itens/produtos’ dos pedidos, ou seja para ‘evitar’ redundância, ela conterá apenas os campo
    • PEDIDO_ID (Primary Key desta tabela e Foreign Key, referenciada a tabela PEDIDOS)
    • PEDIDO_ITEM_ID (Primary Key desta tabela)
    • QUANTIDADE
    • PRECO
      

Se observarmos, a PK da tabela PEDIDO_ITENS, é composta de 2 campos, PEDIDO_ID e PEDIDO_ITEM_ID, ou seja, a tabela é desta forma ‘filha’ da tabela PEDIDOS, assunto que trataremos logo abaixo.

Foreign Keys / Chaves Estrangeiras

Quando se está planejando um banco de dados, uma das preocupações é a redundância ou repetição de informações. Exemplo prático:

• Existe uma tabela chamada CLIENTES.
• Você precisa definir de forma consistente a ‘cidade’ a qual seus clientes pertencem (já que um campo ‘digitável’ não lhe trará muita segurança visto ser livre e consequente aberto a erros, duplicações, etc.), sendo assim, cria uma nova tabela chamada CIDADES, porém, como ter ‘certeza’ de que, os clientes estão associados a cidades que estejam realmente cadastradas? A resposta a esta pergunta se chama “Foreign Keys” ou apenas “FK”

Então uma Foreign Key nada mais é do que uma ‘ligação’ entre tabelas que, serve para garantir que um registro ‘referenciado’ em um tabela, realmente exista na tabela ‘referenciada’.

Neste raciocínio, teríamos então 2 tabelas como seguem:

• Tabela CIDADES
• Contendo os campos:
• CIDADE_ID (Primary Key)
• NOME
• Tabela CLIENTES
• Contendo os campos:
• CLIENTE_ID (Primary Key)
• NOME
• CIDADE (Foreign Key referenciada a tabela CIDADES)

Assim, poderíamos cadastrar a cidade “Goiânia”, que receberia o CIDADE_ID igual a “1” por exemplo, e finalmente cadastrar “N” clientes associando-os a ela. Desta maneira garantiríamos que, todo cliente cadastrado em nossa tabela CLIENTES, possua uma cidade registrada na tabela CIDADES.

Este tipo de estratégia então, evita que, sua aplicação tenha de fazer este tipo de tratamento em tempo de execução, já que, caso isto venha a ocorrer (por um erro no front-end), o próprio banco de dados irá ‘recusar’ por assim dizer a gravação, lhe retornando um erro de FK.

Exemplos de criação das tabelas CIDADES e CLIENTES e das respectivas Primary e Foreign Keys:

-- Criação da tabela

CREATE TABLE CIDADES

(

  CIDADE_ID NUMBER NOT NULL,

  NOME      VARCHAR2(60)

);

-- Adicionando a Primary Key

ALTER TABLE

  CIDADES

ADD CONSTRAINT

  PKCIDADES

PRIMARY KEY

  (CIDADE_ID);

-- Criação da tabela

CREATE TABLE CLIENTES

(

  CLIENTE_ID NUMBER NOT NULL,

  CIDADE     NUMBER NOT NULL,

  NOME       VARCHAR2(60)

);

-- Adicionando a Primary Key

ALTER TABLE

  CLIENTES

ADD CONSTRAINT

  PKCLIENTES

PRIMARY KEY

  (CLIENTE_ID);

-- Adicionando a Foreign Key

ALTER TABLE

  CLIENTES

ADD CONSTRAINT

  FK_CIDADES

FOREIGN KEY

  (CIDADE)

REFERENCES

  CIDADES (CIDADE_ID);

No script acima, podemos observar que, criamos primeiramente a tabela CIDADES e, na sequencia após criamos a tabela CLIENTES, adicionamos além da Primary Key, uma chave estrangeira, associando o campo CIDADE ao campo CIDADE_ID da tabela CIDADES. Este campo porém, na tabela CLIENTES poderia sem problema alguém ter, o mesmo nome CIDADE_ID, apenas o deixei diferente para ilustrar que, este, pode sim, possuir nomes diferentes de acordo com a necessidade.

Em breve, falaremos de outros conceitos de aplicação e uso destas restrições, até a próxima!

Gostou? Algum equívoco? Não deixe de comentar!