Definindo relacionamentos

Agora vamos definir os relacionamentos entre as tabelas. Este procedimento é muito simples. Basta você arrastar o índice da tabela pai (lado um) do relacionamento para o índice da tabela filho (lado muitos). Por exemplo, arrastar o índice id_cliente para cima do índice.

Defina então os seguintes relacionamentos:

Tabela 8

Tabela Pai Tabela Filha
Clientes->id_cliente ContaReceber->id_cliente
Fornecedores->id_fornece ContaPagar->id_fornece
Usuarios->id_usuario ContaReceber->id_usuario
Usuarios->id_usuario ContaPagar->id_usuario

Após definidos os relacionamentos, teremos a seguinte aparência no banco de dados. Neste caso, reposicionei as tabelas para dar destaque às linhas ligando as tabelas:

Figura 14 – Tabelas relacionadas

Os relacionamentos do tipo um para muitos são os mais comuns e mais fáceis de serem definidos, como é o caso que fizemos aqui. Note que o lado um do relacionamento há uma notação parecida com um sinal de mais ( + ) e do lado muitos há uma espécie de gancho com três pontas.

Para definir um relacionamento do tipo um para um através da Database Designer, é necessário que ambos os índices sejam do tipo chave primária.

É muito importante saber como editar o relacionamento entre as tabelas, pois pode ser que por falta de atenção arrastemos um índice para outro que não seja o seu correspondente causando assim uma falha de relacionamento. Nenhum erro ocorrerá, mas muito provavelmente o resultado não será o esperado.

Editando um relacionamento

Para editar um relacionamento, basta clicar sobre a linha de relacionamento entre as tabelas com o botão direito e escolher “Edit Relationship“… Aparecerá um diálogo como o apresentado a seguir na figura 15:

Figura 15 – Editando relacionamento

Observe de acordo com a figura acima, que o lado esquerdo representa a tabela a qual o relacionamento inicia-se e o lado direito é a tabela à qual ela se relaciona. A informação Relationship type exibe se o relacionamento é do tipo um para muitos (One To Many) ou um para um (One To One). Note também que há um botão Referential Integrity. Através deste botão podemos definir a integridade referencial entre as duas tabelas.

Para gerar integridade referencial, é necessário abrir o banco de dados em modo exclusivo. Muito provavelmente seu banco já estará aberto em modo exclusivo, mas caso receba uma mensagem como esta:

Figura 16

Você deverá fechar o seu banco de dados e então abri-lo em modo exclusivo. Em nosso caso, basta digitar o seguinte na janela de comandos:

CLOSE ALL ALL

OPEN DATABASE cpedras.dbc EXCLUSIVE

MODIFY DATABASE cpedras.dbc

Definindo a integridade referencial entre as tabelas

Como vimos na figura “Edit Relationship, é possível definir a integridade referencial a partir do diálogo de edição do relacionamento. Mas essa não é a única forma. Temos ainda as opções de acessar através do menu Database ou do menu de contexto clicando com o botão direito sobre a linha do relacionamento e escolhendo Edit Referential Integrity.

Vamos então clicar com o botão direito sobre o relacionamento entre a tabela de clientes e a tabela ContasReceber e escolher Edit Referential Integrity. Aparecerá um diálogo semelhante ao seguinte:

Figura 17 – Selecionar Builder

Este diálogo aparece a fim de selecionarmos o Builder (criador) que será usado para definir a integridade referencial. O Builder padrão do VFP para esssa tarefa é o Referential Integrity Builder. Após selecionar, clique em “OK“.

Agora temos o Builder aberto. Clique sobre a aba “Rules for Deleting” (Regras para apagar).

Figura 18 – definindo integridade referencial

Em nosso caso vamos criar regras (rules) apenas para ações de apagar (delete). Faremos isso para garantir que quando um registro de uma tabela pai for apagado, os registros da tabela filha não fiquem órfãos.

As opções são:

Cascade: apaga todos os registros relacionados na tabela filha.

Restrict: proíbe de apagar se houver registros relacionados na tabela filha.

Ignore: permite apagar e mantém intactos os registros relacionados na tabela filha.

Do ponto de vista funcional, a melhor das opções é a Restrict, uma vez que não permitirá apagar um cliente caso esse possua algum lançamento de conta a receber.

Caso você ainda não tenha feito, defina as regras conforme mostra a figura acima, e depois clique em “OK“. Aparecerá o seguinte diálogo:

Figura 19 – Escolher fazer ou não cópia das Stored Procedures existentes

Escolha “Yes“. Caso você venha a modificar alguma Stored Procedure gerada automaticamente pelo VFP, se você refizer a integridade através do Builder você perderá as modificações. Por isso a opção de fazer a cópia antes.

Aparecerá o diálogo a seguir, informando que houve modificação no banco de dados e pergunta se você quer recarregá-lo. Informe “Yes“.

Figura 20

Agora vamos dar uma olhada no código gerado:

Figura 21 – Stored Procedures da integridade referencial

Nunca remova as linhas de comentários antes e depois do código de integridade referencial.

Algumas definições:

Para garantir essa funcionalidade de forma automática, o VFP irá criar triggers, ou seja, disparadoras automáticos para a ação de excluir das tabelas clientes e fornecedores, apagando os registros de ContasReceber e ContasPagar, respectivamente.

Um trigger (disparador) é uma expressão ligada a uma tabela e que é invocado sempre que há algum tipo de modificação na mesma. Podemos associar expressões trigger’s para incluir, modificar e apagar registros.

Trigger’s podem ser criados para as mais diversas funções, por exemplo, criar índices, selecionar determinados registros, fazer lançamentos ou processamentos em tabelas, e assim por diante. O código escrito para um trigger é armazenado como stored procedure (procedimentos armazenados) no banco de dados.

Uma Stored Procedure é um procedimento ou função, porém este estará armazenado no próprio banco de dados e sua utilização será sempre para manipular ou retornar algum dado.

Continua em Desenvolvendo em VFP – Parte 5

Print Friendly, PDF & Email

Sobre o Autor