1546027450-1546027450-sql

61 - Capítulo 3 – DDL – DATA DEFINITION LANGUAGE
Porém, é necessário garantir a integridade relacional destes
relacionamentos de dados. Como isto deve ser feito? Através de outra
constraint denominada FOREIGN KEY (CHAVE ESTRANGEIRA).
Talvez você não conheça ainda o termo "integridade relacional". Pois
saiba que ele exerce um papel fundamental na consistência dos dados
do banco. Observe os exemplos a seguir:
Imagine que, além da tabela CLIENTE, nosso banco também tivesse
uma tabela PEDIDO com a seguinte estrutura:
• NR_PEDIDO
• DATA_PEDIDO
• VALOR_PEDIDO
• CODIGO_CLIENTE
Observamos que a tabela acima tem uma coluna com dados que devem
ser comuns à tabela CLIENTE. Estes dados estão contidos nas colunas
que receberam o mesmo nome nas duas tabelas: CODIGO_CLIENTE.
Como garantir, no entanto, que apenas clientes que foram inseridos
previamente na tabela CLIENTE possam realizar pedidos ou como garantir
que clientes que realizaram pedidos não sejam excluídos da tabela CLIENTE?
É exatamente para resolver isso que utilizamos a FOREIGN KEY ou
CHAVE ESTRANGEIRA.
Para melhor entendimento criaremos a seguir a tabela PEDIDO com
suas duas constraints (PRIMARY KEY e FOREIGN KEY):
CREATE TABLE PEDIDO (
NR_PEDIDO NUMBER (5),
DATA_PEDIDO DATE,
VALOR_PEDIDO NUMBER (6,2),
CODIGO_CLIENTE NUMBER (4),
CONSTRAINT PEDIDO_PK PRIMARY KEY (NR_PEDIDO),
CONSTRAINT PEDIDO_CLIENTE_FK FOREIGN KEY (CODIGO_CLIENTE)
REFERENCES CLIENTE (CODIGO_CLIENTE)
);