foreign key

1. foreign key

Wa
LaraW

(usa Outra)

Enviado em 16/06/2016 - 15:51h

Caros colegas, estou com uma situação curiosa em relação à uma integridade referencial. Tenho duas tabelas no PostgreSQL, uma tabela pai e outra filha. Existe uma integridade referencial aplicada nessas tabelas da forma convencional:

ALTER TABLE TAB_FILHA ADD CONSTRAINT FK_TESTE FOREIGN KEY (CDTESTE) REFERENCES TAB_PAI (CDTESTE);

Só que o mais curioso é que quando procuro um determinado codigo, ele está na tabela tab_filha mas não está na tabela tab_pai.

Será que existe algum comando que quando ao inserir o registro seja solicitado que ignore as integridades referenciais? Pois a integridade com certeza está aplicada, mas esse registro não segue essa referencia. Tanto que fiz um backup desse banco e ao restaurá-lo deu problema.

Obrigada


  


2. Re: foreign key

Hugo Cerqueira
hrcerq

(usa Outra)

Enviado em 18/06/2016 - 20:20h

Olá.

Essa situação é perfeitamente possível, dependendo de como foi implementada essa foreign key.

Quando você define uma foreign key, tem a opção de definir algumas opções para ela. Imaginemos uma situação em que um registro na tabela filha faz referência a outro registro na tabela pai. Vamos supor que esse registro da tabela pai é removido. O que deverá acontecer com o registro da tabela filha que faz referência a ele? Isso é definido quando se aplica a foreign key. No comando que você citou, por exemplo:

ALTER TABLE TAB_FILHA ADD CONSTRAINT FK_TESTE FOREIGN KEY (CDTESTE) REFERENCES TAB_PAI (CDTESTE); 


Aí não há qualquer definição do que será feito, o que significa que se você tentar remover o registro referenciado na tabela TAB_PAI, receberá uma mensagem de erro.
Mas este comando poderia ser aplicado de outra forma, por exemplo:

ALTER TABLE TAB_FILHA ADD CONSTRAINT FK_TESTE 
FOREIGN KEY (CDTESTE) REFERENCES TAB_PAI (CDTESTE)
ON DELETE CASCADE;


Note que no final foi definida uma ação para quando o registro referenciado for removido (cascade). A opção "cascade" significa que se o registro pai for removido, o registro filho também será. Se em vez da opção "cascade", fosse escolhida a opção "restrict", então a deleção do registro seria proibida (semelhante ao que acontece quando não é definida nenhuma ação, porém o erro seria imediato e não no fim da transação).

Além dessas opções, que são as mais comuns, é possível também usar as opções "set null" e "set default", e aí é que está uma possível explicação para o seu caso. A opção "set null" significa que se o registro pai for removido, o registro filho muda o valor do campo que fazia referência para null. A opção "set default" é semelhante, porém em vez de mudar o valor para null, muda para um valor default que foi definido para aquele campo (se foi definido, senão será null).

Da mesma forma, é possível definir também uma ação para quando o registro pai for atualizado, por exemplo:

ALTER TABLE TAB_FILHA ADD CONSTRAINT FK_TESTE 
FOREIGN KEY (CDTESTE) REFERENCES TAB_PAI (CDTESTE)
ON UPDATE SET NULL;


No exemplo acima, quando o registro pai for atualizado, o registro filho mudará o valor da coluna que faz referência para null.

---

Atenciosamente,
Hugo Cerqueira






Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts