Júlio Battisti Livros e Cursosa sua sala de aula na internet

Utilizamos FOREIGN KEY Constraints para implementar a Integridade Referencial no Banco de Dados. Ao definirmos uma FOREIGN KEY associada a uma coluna (ou um conjunto de colunas), estamos definindo esta coluna como uma Chave Estrangeira. A Chave Estrangeira representa o lado vários de um relacionamento do tipo Um para Vários.

É muito importante, eu diria até indispensável, que você tenha entendido todos os conceitos sobre o Modelo Relacional de dados, apresentados no Capítulo 1. Se você tiver qualquer dúvida sobre um destes conceitos – Chave Primária, Chave estrangeira, relacionamentos, tipos de relacionamentos e integridade referencial, por favor, volte ao Capítulo 1 e revise estes conceitos, antes de seguir adiante.

Por exemplo, temos um relacionamento do tipo Um para Vários entre a tabela Fornecedores (lado Um) e a tabela Produtos (lado Vários). Na tabela Fornecedores, o campo CódigoDoFornecedor é uma Chave Primária. Na tabela Produtos, o campo CódigoDoFornecedor é uma Chave Estrangeira. O campo CódigoDoFornecedor é o lado vários, na tabela Produtos, pois um mesmo fornecedor, pode fornecer vários produtos. Por exemplo, se um fornecedor fornecer 50 produtos diferentes, haverá 50 registros na tabela Produtos, onde o campo CódigoDoFornecedor terá o código do respectivo fornecedor, nos 50 registros. Observe que, neste exemplo, o campo irá aparecer 50 vezes, ou genericamente, várias vezes. Sendo que as duas tabelas são relacionadas através de um relacionamento do tipo Um para Vários, significando que Um fornecedor pode fornecer Vários produtos.

Uma Chave Estrangeira pode ser relacionada com um campo em que temos uma PRIMAY KEY Constraint ou uma UNIQUE Constraint.

Para que possamos estabelecer o relacionamento entre uma Chave Estrangeira e uma Chave Primária, algumas regras devem ser observadas:

• O número de colunas da Chave Estrangeira e os tipos de dados especificados no comando FOREIGN KEY devem coincidir com os especificados na cláusula REFERENCE. Porém, o nome das colunas não precisa ser o mesmo. Veja a sintaxe do comando mais adiante e exemplos de uso destes comandos.
• Quando criamos uma FOREIGN KEY Constraint não é criado, automaticamente, um índice. Porém, na prática, pode ser útil a criação de um índice associado à Chave Estrangeira. Para aprender sobre a criação e manutenção de índices consulte o Capítulo 4.
• Para modificar dados em uma tabela que possui uma Constraint do tipo FOREIGN KEY, o usuário deve ter permissões SELECT ou REFERENCE na tabela primária. Por exemplo, vamos considerar o relacionamento entre as tabelas Categorias (lado Um) e Produtos (lado Vários), relacionadas através do campo CódigoDaCategoria. Na tabela Categorias, o campo CódigoDaCategoria é uma Chave Primária, já na tabela Produtos, o campo CódigoDaCategoria é uma Chave Estrangeira. Para que o usuário possa alterar dados na tabela Produtos, ele precisa ter permissão SELECT ou REFERENCE, na tabela Categorias, que é a tabela relacionada com Produtos.
• Podemos criar uma referência entre duas colunas da mesma tabela. Neste caso, utilizamos apenas a cláusula REFERENCES, sem a cláusula FOREIGN KEY.

Vamos pôr em prática toda esta teoria. Nos exemplos anteriores criamos uma tabela Clientes e uma tabela Pedidos, com os campos indicados na Figura 9.7.

Figura 9.7 Tabelas Clientes e Pedidos, criadas nos exemplos anteriores.

Observe que o campo CPF existe nas duas tabelas e, na tabela Clientes, este campo é uma Chave Primária – indicado por uma pequena chave amarela ao lado do campo. Vamos criar um relacionamento entre estas duas tabelas. O relacionamento será do tipo Um (tabela Clientes) para Vários (tabela Pedidos). Para definirmos este relacionamento, vamos criar uma FOREIGN KEY Constraint no campo CPF da tabela Pedidos, sendo que esta FOREIGN KEY irá fazer referência (em bom Português vai se relacionar com) ao campo CPF da tabela Clientes.

Para criar uma FOREIGN KEY no campo CPF da tabela Pedidos, vamos executar o seguinte comando:

ALTER TABLE Pedidos

ADD CONSTRAINT Rel_Ped_Cli FOREIGN KEY(CPF)

REFERENCES Clientes(CPF)

Uma vez executado este comando, teremos criado um relacionamento entre as tabelas Clientes e Pedidos, conforme indicado na Figura 9.8.

Figura 9.8 Relacionamento criado entre as tabelas Clientes e Pedidos.

Observe que definimos uma Constraint do tipo FOREIGN KEY em uma tabela já existente. Porém podemos definir este tipo de Constraint no momento da criação da tabela.

Vamos supor que foi solicitada a criação de uma tabela chamada Dependentes. Um cliente poderá autorizar um ou mais dependentes, para que façam compras em seu nome. Neste caso, teremos um relacionamento do tipo Um para Vários entre a tabela Clientes e a tabela Dependentes. O campo que irá relacionar as duas tabelas é o campo CPF. A tabela Clientes é o lado um do relacionamento e a tabela Dependentes é o lado vários. Neste caso, a Constraint do tipo FOREIGN KEY será criada na tabela Dependentes. Como a tabela Dependentes ainda não existe, iremos criá-la e, durante a criação, especificar uma FOREIGN Constraint no campo CPF, a qual referencia o campo CPF da tabela Clientes. A tabela Dependentes terá os seguintes campos:

CPF       Char(14) FOREIGN KEY relacionada com o campo CPF da tabela Clientes.

Nome      Char(50)

Fone      Char(25)

e_mail    Char(50)

Para criar a tabela Dependentes e definir o relacionamento solicitado, devemos executar o seguinte comando:

CREATE TABLE Dependentes

(

CPF               Char(14)     NOT NULL,

Nome              Char(50)     NOT NULL,

Fone              Char(25)     NOT NULL,

e_mail            Char(50),

CONSTRAINT        Rel_Cli_Dep  FOREIGN KEY(CPF)

REFERENCES        Clientes(CPF)

)

Após a execução deste comando teremos o relacionamento entre as tabelas Clientes e Dependentes já definido. A Figura 9.9 mostra as tabelas Clientes, Pedidos e Dependentes e os respectivos relacionamentos.

Figura 9.9 Mais um relacionamento criado: Clientes e Dependentes.

Vamos fazer alguns testes referentes à Integridade referencial. Uma vez definido o relacionamento entre as tabelas Clientes e Dependentes, o SQL Server 2005 não deve deixar que seja adicionado um registro na tabela Dependentes, para um cliente que ainda não tenha sido cadastrado na tabela Clientes. Vamos fazer o seguinte teste, tentaremos adicionar um dependente para o cliente com o CPF 999.999.999-99. Acontece que este cliente não existe na tabela Clientes. Tente executar o seguinte comando

INSERT INTO Dependentes (CPF,Nome,fone,e_mail)

VALUES (‘999.999.999-99’, ‘Faustino da Silva’, ‘2222222’,‘faustino@abc.com’)

O comando não será executado e a seguinte mensagem de erro será exibida:

Msg 547, Level 16, State 0, Line 1

INSERT statement conflicted with FOREIGN KEY constraint 'Rel_Cli_Dep'.

The conflict occurred in database 'PubsIntF', table 'Clientes', column 'CPF'.

The statement has been terminated.

Observe o seguinte trecho desta mensagem:

The conflict occurred in database ‘pubs’, table ‘Clientes’, column ‘CPF’.

Este trecho, embora não muito claramente, está nos dizendo que não existe o CPF 999.999.999-99, na tabela Clientes, ou seja, que estamos tentando cadastrar um dependente para um cliente que ainda não existe. Agora vamos alterar o comando anterior, substituindo o CPF inexistente pelo CPF de um cliente cadastrado nos exercícios anteriores. Execute o seguinte comando:

INSERT INTO Dependentes (CPF,Nome,fone,e_mail)

VALUES (‘666.333.333-33’, ‘Faustino da Silva’, ‘2222222’,‘faustino@abc.com’)

Agora sim, o comando é executado com sucesso e um dependente é adicionado na tabela Dependentes.

Com este exemplo, podemos observar como o SQL Server gerencia, automaticamente, a Integridade Referencial, uma vez definidos os relacionamentos. Quando trabalhamos com o SQL Server 2005, ou qualquer outro Banco de Dados que segue o modelo Relacional, é de fundamental importância que entendamos os conceitos apresentados no Capítulo 1 e aqui exemplificados. Sem o domínio destes conceitos, iremos projetar Bancos de Dados com problemas, ou melhor, com muitos problemas. Muitas vezes, estes problemas somente aparecem quando colocamos uma ou mais aplicações em produção. Surgem desde consultas com desempenho “sofrível”, até inconsistência e falta de Integridade dos dados.