Integridade de Dados

Este capítulo explica como as constraints de integridade impõem as regras de negócios associadas a um banco de dados e impedem a entrada de informações inválidas nas tabelas.

Introdução à Integridade de Dados

É importante que os dados mantenham a integridade dos dados, que é a conformidade com as regras de negócios determinadas pelo administrador do banco de dados ou pelo desenvolvedor de aplicativos.

As regras de negócios especificam condições e relacionamentos que devem ser sempre verdadeiros ou sempre falsos. Por exemplo, cada empresa define suas próprias políticas sobre salários, números de funcionários, rastreamento de estoque, etc.

Técnicas para garantir a integridade dos dados

Ao projetar um aplicativo de banco de dados, os desenvolvedores têm várias opções para garantir a integridade dos dados armazenados no banco de dados.

Essas opções incluem:

Consulte Também:

Vantagens das Restrições de Integridade

Uma restrição de integridade é um objeto de esquema que é criado e eliminado com o uso da SQL. Para impor a integridade dos dados, use constraints de integridade ou asserções sempre que possível.

As vantagens de restrições de integridade e asserções sobre alternativas para impor a integridade dos dados incluem:

Consulte Também:

Tipos de Constraints de Integridade

O Oracle AI Database permite que você aplique restrições no nível da tabela e da coluna e asserções que envolvem várias tabelas.

Uma restrição especificada como parte da definição de uma coluna ou atributo é uma especificação em linha. Uma constraint especificada como parte da definição de tabela é uma especificação off-line.

Uma chave é a coluna ou o conjunto de colunas incluído na definição de determinados tipos de restrições de integridade. As chaves descrevem os relacionamentos entre as tabelas e as colunas de um banco de Dados Relacional. Os valores individuais de uma chave são denominados valores de chave.

A tabela abaixo descreve os tipos de restrições. Cada um pode ser especificado em linha ou fora de linha, exceto para NOT NULL, que deve estar em linha.

Tabela 1 - Tipos de Constraints de Integridade

Tipo de Restrição Descrição Consulte Também
NOT NULL Permite ou desativa inserções ou atualizações de linhas que contêm um nulo em uma coluna especificada. "Restrições de Integridade NOT NULL"
Chave exclusiva Proíbe que diversas linhas tenham o mesmo valor na mesma coluna ou combinação de colunas, mas permite alguns valores serem nulos. "Restrições Exclusivas"
Chave principal Combina uma restrição NOT NULL e uma restrição exclusiva. Ela proíbe várias linhas de terem o mesmo valor na mesma coluna ou combinação de colunas e proíbe que valores sejam nulos. "Restrições de Chave Primária"
Chave estrangeira Designa uma coluna como a chave estrangeira e estabelece um relacionamento entre a chave estrangeira e uma chave primária ou exclusiva, denominada chave referenciada. "Restrições de Chaves Estrangeiras"
Cheque Exige que um valor de banco de dados obedeça a uma condição especificada. "Verificar Restrições"
REF Dita tipos de manipulação de dados permitidos em valores em uma coluna REF e como essas ações afetam valores dependentes. Em um banco de dados objeto-relacional, um tipo de dados incorporado chamado REF encapsula uma referência a um objeto de linha de um tipo de objeto especificado. As restrições de integridade referencial nas colunas REF garantem que haja um objeto de linha para a REF. Oracle AI Database Object-Relational Developer's Guide para saber mais sobre as restrições do REF
Assertions Asserções são expressões boolianas que envolvem subconsultas em tabelas de banco de dados de um aplicativo. As asserções têm a semântica de uma restrição, ou seja, o banco de dados é encarregado de garantir a verdade dessas expressões boolianas enquanto as transações alteram dados e confirmam essas alterações. Asserções SQL para saber mais sobre asserções

Consulte Também:

Constraints de Integridade NOT NULL

Uma restrição NOT NULL requer que uma coluna de uma tabela não contenha valores nulos. Um nulo é a ausência de um valor. Por padrão, todas as colunas de uma tabela permitem valores nulos.

As restrições NOT NULL são destinadas a colunas que não devem conter valores. Por exemplo, a tabela hr.employees requer um valor na coluna email. A tentativa de inserir uma linha de funcionário sem um endereço de e-mail gera um erro:

SQL> INSERT INTO hr.employees (employee_id, last_name) values (999, 'Smith');
.
.
.
ERROR at line 1:
ORA-01400: cannot insert NULL into ("HR"."EMPLOYEES"."EMAIL")

Você só poderá adicionar uma coluna com uma restrição NOT NULL se a tabela não contiver linhas ou se você especificar um valor padrão.

Consulte Também:

Constraints Exclusivas

Uma constrição de chave exclusiva requer que todos os valores de uma coluna ou conjunto de colunas sejam exclusivos, Nenhuma linha de uma tabela pode ter valores duplicados em uma única coluna (a chave exclusiva) ou em um conjunto de colunas (a chave exclusiva composta) com uma restrição de chave exclusiva.

Observação: o termo key refere-se somente às colunas definidas na restrição de integridade. Como o banco de dados impõe uma restrição exclusiva criando ou reutilizando implicitamente um índice nas colunas de chaves, o termo chave exclusiva às vezes é usado incorretamente como sinônimo de restrição de chave exclusiva ou de índice exclusivo.

As constraints de chave exclusiva são apropriadas para todas as colunas em que valores duplicados não são permitidos. Constraints exclusivas são diferentes de constraints de chave primária, cuja finalidade é identificar cada linha da tabela de forma exclusiva, e geralmente contêm valores que não têm importância além de serem exclusivos. Exemplos de chaves exclusivas incluem:

Conforme mostrado no Exemplo 4-1, existe uma restrição de chave exclusiva na coluna email da tabela hr.employees. A parte relevante da declaração é a seguinte:

CREATE TABLE employees    ( ...
    , email          VARCHAR2(25)
        CONSTRAINT   emp_email_nn  NOT NULL ...
    , CONSTRAINT     emp_email_uk  UNIQUE (email) ... );

A restrição emp_email_uk garante que dois funcionários não tenham o mesmo endereço de e-mail, conforme mostrado no exemplo a seguir:

SQL> SELECT employee_id, last_name, email FROM employees WHERE email = 'PFAY';

EMPLOYEE_ID LAST_NAME                 EMAIL
----------- ------------------------- -------------------------
        202 Fay                       PFAY

SQL> INSERT INTO employees (employee_id, last_name, email, hire_date, job_id)
  1  VALUES (999,'Fay','PFAY',SYSDATE,'ST_CLERK');
.
.
.
ERROR at line 1:
ORA-00001: unique constraint (HR.EMP_EMAIL_UK) violated

A menos que uma restrição NOT NULL também seja definida, um valor nulo sempre satisfaz uma restrição de chave exclusiva. Assim, as colunas com restrições de chave exclusivas e restrições NOT NULL são típicas. Essa combinação força o usuário a inserir valores na chave exclusiva e elimina a possibilidade de novos dados de linha entrarem em conflito com dados de linha existentes.

Observação: Por causa do mecanismo de pesquisa para restrições de chave exclusiva em várias colunas, não é possível ter valores idênticos nas colunas não nulas de uma restrição da chave exclusiva composta parcialmente nula.

Exemplo 7-1 Constraint Exclusiva

SQL> SELECT employee_id, last_name, email FROM employees WHERE email = 'PFAY';

EMPLOYEE_ID LAST_NAME                 EMAIL
----------- ------------------------- -------------------------
        202 Fay                       PFAY

SQL> INSERT INTO employees (employee_id, last_name, email, hire_date, job_id)
  1  VALUES (999,'Fay','PFAY',SYSDATE,'ST_CLERK');
.
.
.
ERROR at line 1:
ORA-00001: unique constraint (HR.EMP_EMAIL_UK) violated

Consulte Também:

Constraints de Chave Primária

Em uma restrição de chave primária, os valores no grupo de uma ou mais colunas sujeitas à restrição identificam exclusivamente a linha. Cada tabela pode ter uma chave primária, que, de fato, nomeia a linha e garante a ausência de linhas duplicadas.

Uma chave primária pode ser natural ou substituta. Uma chave natural é um identificador significativo feito de atributos existentes em uma tabela. Por exemplo, uma chave natural pode ser um código postal em uma tabela de pesquisa.

Por outro lado, uma chave substituta é um identificador de incremento gerado pelo sistema que garante a exclusividade em uma tabela. Geralmente, uma sequência ou um UUID gera chaves substitutas.

A implementação do Oracle AI Database da restrição de chave primária garante que as seguintes afirmações sejam verdadeiras:

Uma situação típica que exige uma chave primária é o identificador numérico de um funcionário. Cada funcionário deve ter um ID exclusivo. Um funcionário deve ser descrito por apenas uma linha na tabela employees.

O exemplo em Restrições Exclusivas indica que um funcionário existente tem o ID de funcionário 202, em que o ID de funcionário é a chave primária. O exemplo a seguir mostra uma tentativa de adicionar um funcionário com o mesmo ID e um funcionário sem ID:

SQL> INSERT INTO employees (employee_id, last_name, email, hire_date, job_id)
  1  VALUES (202,'Chan','JCHAN',SYSDATE,'ST_CLERK');
.
.
.
ERROR at line 1:
ORA-00001: unique constraint (HR.EMP_EMP_ID_PK) violated

SQL> INSERT INTO employees (last_name) VALUES ('Chan');
.
.
.
ERROR at line 1:
ORA-01400: cannot insert NULL into ("HR"."EMPLOYEES"."EMPLOYEE_ID")

O banco de dados impõe restrições de chave primária com um índice. Em geral, uma restrição de chave primária criada para uma coluna cria implicitamente um índice exclusivo e uma restrição NOT NULL. Observe as seguintes exceções para esta regra:

Por padrão, o nome do índice criado implicitamente é o nome da restrição de chave primária. Você também pode especificar um nome definido pelo usuário para um índice. Você pode especificar opções de armazenamento para o índice incluindo a cláusula ENABLE na instrução CREATE TABLE ou ALTER TABLE usada para criar a restrição.

Consulte Também: Oracle AI Database Get Started with Oracle AI Database Development e Oracle AI Database Development Guide para aprender a adicionar restrições de chave primária a uma tabela

Constraints de Chave Estrangeira

Sempre que duas tabelas contiverem uma ou mais colunas comuns, o Oracle AI Database poderá impor o relacionamento entre as duas tabelas por meio de uma restrição de chave estrangeira, também chamada de restrição de integridade referencial.

Uma constraint de chave estrangeira requer que, para cada valor na coluna na qual a constraint é definida, o valor na outra tabela e coluna especificadas devem ser correspondentes. Um exemplo de regra de integridade referencial é que um funcionário pode trabalhar somente em um departamento existente.

A tabela a seguir lista os termos associados às constraints de integridade referencial.

Termos da Constraint de Integridade Referencial da Tabela 2

Termo Definição
Chave estrangeira

A coluna ou o conjunto de colunas incluído na definição da restrição que faz referência a uma chave referenciada. Por exemplo, a coluna department_id no employees é uma chave estrangeira que faz referência à coluna department_id no departments.

Chaves estrangeiras podem ser definidas como várias colunas. No entanto, uma chave estrangeira composta deve fazer referência a uma chave primária ou exclusiva composta com o mesmo número de colunas e os mesmos tipos de dados.

O valor das chaves estrangeiras pode corresponder ao valor de chave primária ou exclusiva referenciado ou ser nulo. Se alguma coluna de uma chave estrangeira composta for nula, a parte não nula da chave não precisará corresponder a nenhuma parte correspondente de uma chave pai.
Chave referenciada A chave exclusiva ou a chave primária da tabela referenciada por uma chave estrangeira. Por exemplo, a coluna department_id no departments é a chave referenciada para a coluna department_id no employees.
Tabela dependente ou filho A tabela que inclui a chave estrangeira. Esta tabela depende dos valores presentes na chave exclusiva ou primária referenciada. Por exemplo, a tabela employees é um filho de departments.
Tabela referenciada ou pai A tabela que é referenciada pela chave estrangeira da tabela filho. É a chave referenciada desta tabela que determina se inserções ou atualizações específicas são permitidas na tabela filho. Por exemplo, a tabela departments é um pai de employees.

A Figura 7-1 mostra uma chave estrangeira na coluna employees.department_id. Ela garante que todos os valores dessa coluna devem corresponder a um valor na coluna departments.department_id. Portanto, não podem existir números de departamento errados na coluna employees.department_id.

Figura 1: Restrições de Integridade Referencial

Descrição da ilustração cncpt056.gif

Restrições de Integridade Referencial Automática

Uma restrição de integridade autorreferencial é uma chave estrangeira que faz referência a uma chave pai na mesma tabela.

Na figura a seguir, uma restrição autorreferencial garante que cada valor na coluna employees.manager_id corresponda a um valor existente na coluna employees.employee_id. Por exemplo, o gerente do funcionário 102 deve existir na tabela employees. Essa restrição elimina a possibilidade de números de funcionários errados na coluna manager_id.

Figura 2: Restrições Referenciais de Tabela Única

Descrição da ilustração cncpt057.gif

Chaves Nulas e Estrangeiras

O modelo relacional permite que o valor de chaves estrangeiras corresponda ao valor de chave primária ou exclusiva referenciado ou seja nulo. Por exemplo, uma linha em hr.employees pode não especificar um ID de departamento.

Se alguma coluna de uma chave estrangeira composta for nula, a parte não nula da chave não precisa corresponder a nenhuma parte correspondente de uma chave pai. Por exemplo, uma tabela reservations pode conter uma chave estrangeira composta nas colunas table_id e date, mas table_id é nulo.

Modificações de Chave Pai e Chaves Estrangeiras

O relacionamento entre a chave estrangeira e a chave pai tem implicações para a exclusão de chaves pai. Por exemplo, se um usuário tentar excluir o registro desse departamento, o que acontecerá com os registros dos funcionários desse departamento?

Quando uma chave pai é modificada, as constraints de integridade referencial podem especificar as seguintes ações a serem executadas em linhas dependentes em uma tabela filho:

A Tabela 7-3 descreve as instruções DML permitidas pelas diferentes ações referenciais nos valores de chave da tabela pai e nos valores de chave estrangeira da tabela filho.

Tabela 3 Instruções DML Permitidas por Atualizar e Excluir Sem Ação

Instrução DML Emitido na Tabela Pai Emitido na Tabela Filho
INSERT Sempre OK se o valor da chave pai for exclusivo OK somente se o valor da chave estrangeira existir na chave pai ou for parcialmente ou tudo nulo
UPDATE NO ACTION Permitido se a instrução não deixar nenhuma linha na tabela filho sem um valor de chave pai referenciado Permitido se o novo valor de chave estrangeira ainda fizer referência a um valor de chave referenciado
DELETE NO ACTION Permitido se nenhuma linha na tabela filho fizer referência ao valor da chave pai Sempre OK
DELETE CASCADE Sempre OK Sempre OK
DELETE SET NULL Sempre OK Sempre OK

Observação: Outras ações referenciais não suportadas pelas restrições de integridade FOREIGN KEY do Oracle Database podem ser impostas usando triggers de banco de dados. Consulte "Visão Geral de Triggers".

Consulte Também: Referência de Linguagem SQL do Oracle AI Database para saber mais sobre a cláusula ON DELETE

Índices e Chaves Estrangeiras

Como regra geral, as chaves estrangeiras devem ser indexadas. A única exceção é quando a chave primária ou exclusiva correspondente nunca é atualizada ou excluída.

A indexação de chaves estrangeiras em tabelas filho oferece os seguintes benefícios:

Consulte Também:

Constraints de Verificação

Uma restrição de verificação em uma coluna ou em um conjunto de colunas requer que uma condição especificada seja verdadeira ou desconhecida para cada linha.

Se DML resultar na condição da constraint ser avaliada como falsa, será feito rollback da instrução SQL. O principal benefício das constraints de verificação é a capacidade de impor regras de integridade muito específicas. Por exemplo, você pode usar constraints de verificação para impor as seguintes regras na tabela hr.employees:

O exemplo a seguir cria uma restrição de salário máximo em employees e demonstra o que acontece quando uma instrução tenta inserir uma linha que contenha um salário que excede o máximo:

SQL> ALTER TABLE employees ADD CONSTRAINT max_emp_sal CHECK (salary < 10001);
SQL> INSERT INTO employees (employee_id,last_name,email,hire_date,job_id,salary)
  1  VALUES (999,'Green','BGREEN',SYSDATE,'ST_CLERK',20000);
.
.
.
ERROR at line 1:
ORA-02290: check constraint (HR.MAX_EMP_SAL) violated

Uma única coluna pode ter várias restrições de verificação que fazem referência à coluna em sua definição. Por exemplo, a coluna salary pode ter uma restrição que impede valores acima de 10000 e uma restrição separada que impede valores inferiores a 500.

Se existirem várias restrições de verificação para uma coluna, elas deverão ser criadas para que suas finalidades não entrem em conflito. Nenhuma ordem de avaliação das condições pode ser assumida. O banco de dados não verifica se as condições de verificação não são mutuamente exclusivas.

Consulte Também: Referência de Linguagem SQL do Oracle AI Database para aprender sobre restrições de verificação

Constraints CHECK Pré-verificáveis

Uma restrição de verificação marcada como PRECHECK pode ser verificada fora do banco de dados.

A definição de uma restrição de verificação para o estado PRECHECK é feita durante a criação ou alteração da tabela. O estado PRECHECK complementa os estados ENABLE e VALIDATE de uma restrição e uma restrição que você pode ter todos os três estados ativos ao mesmo tempo.

Se você estiver usando JSON para expressar a restrição de verificação, o Oracle AI Database permitirá que você exporte um esquema JSON e valide dados JSON em relação a um validador de esquema JSON no cliente do aplicativo. Quando uma restrição é definida para o estado PRECHECK, ela indica que a restrição tem um esquema JSON equivalente que preserva a semântica da restrição. Os desenvolvedores de aplicativos clientes podem pré-validar a restrição dentro do aplicativo cliente. O banco de dados verifica a restrição e um erro será gerado se a restrição não puder ser expressa no esquema JSON.

Tópicos Relacionados

Asserções

Asserções são expressões boolianas que envolvem subconsultas em tabelas de banco de dados de um aplicativo.

As asserções têm a semântica de uma restrição, ou seja, o banco de dados é encarregado de garantir a verdade dessas expressões boolianas enquanto as transações alteram dados e confirmam essas alterações.

A instrução SQL a seguir cria uma asserção, chamada NO_TRAINERS_IN_BOSTON, para exigir que não haja instrutores empregados nos departamentos baseados em Boston. O NOT EXISTS de nível superior representa uma expressão Booliana que exige que o conjunto de resultados da junção entre as tabelas EMP e DEPT permaneça vazio.

CREATE ASSERTION no_trainers_in_boston CHECK
(NOT EXISTS
   (SELECT 'trainer in Boston'
    FROM   emp e, dept d
    WHERE  e.deptno = d.deptno
      AND  e.job = 'TRAINER'
      AND  d.loc = 'BOSTON'));

Asserções são objetos no nível do esquema. Isso implica que, se as tabelas de outros esquemas forem referenciadas pela expressão booliana, o privilégio de objeto ASSERTION REFERENCES será necessário para acessar essas tabelas. Isso não é diferente de uma chave estrangeira que abrange dois esquemas, ou seja, um privilégio de objeto REFERENCES deve estar em vigor para criar com sucesso uma chave estrangeira que "aponte" para uma chave primária de uma tabela em outro esquema.

Asserções são restrições genéricas de integridade de dados. Eles poderiam ser usados para substituir as constraints CHECK, PRIMARY KEY, UNIQUE e FOREIGN KEY.

Por exemplo, suponha as seguintes restrições na tabela EMP:

Essas restrições podem ser implementadas com as seguintes afirmações:

CREATE ASSERTION commission_not_greater_than_salary CHECK
(NOT EXISTS
  (SELECT ''
   FROM   emp e
   WHERE  e.comm > e.sal));
CREATE ASSERTION emp_empno_pk CHECK
(NOT EXISTS
  (SELECT ''
   FROM   emp e1, emp e2
   WHERE  e1.empno = e2.empno
     AND  e1.rowid != e2.rowid));
CREATE ASSERTION emp_ename_deptno_uk CHECK
(NOT EXISTS
  (SELECT ''
   FROM   emp e1, emp e2
   WHERE  e1.ename = e2.ename
     AND  e1.deptno = e2.deptno
     AND  e1.rowid != e2.rowid));
CREATE ASSERTION emp_fk_dept CHECK
(NOT EXISTS
  (SELECT ''
   FROM   emp e
   WHERE  NOT EXISTS
     (SELECT ''
      FROM   dept d
      WHERE  d.deptno = e.deptno)));

No entanto, fortemente aconselhamos que você sempre use restrições sempre que possível e só use asserções quando não puder usar uma restrição.

Tópicos Relacionados

Estados de Restrições e Asserções de Integridade

Como parte da definição de restrição ou asserção, você pode especificar como e quando o Oracle AI Database deve impor a restrição ou asserção, determinando assim o estado da restrição ou asserção.

Verifica Dados Modificados e Existentes

O banco de dados permite que você especifique se uma restrição ou asserção se aplica a dados existentes ou futuros. Se uma constraint ou asserção estiver ativada, o banco de dados verificará os novos dados à medida que forem inseridos ou atualizados. Dados que não estão em conformidade com a restrição ou asserção não podem entrar no banco de dados.

Por exemplo, ativar uma restrição NOT NULL em employees.department_id garante que cada linha futura tenha um ID de departamento. Se uma constraint for desativada, a tabela poderá conter linhas que violam a constraint.

Você pode definir restrições e asserções para um dos seguintes modos de validação:

O comportamento de VALIDATE e NOVALIDATE sempre depende de a restrição ou asserção estar ativada ou desativada. A tabela seguinte resume as relações.

Tabela 4 Verificações de Dados Modificados e Existentes

Dados modificados Dados Existentes Resumo
ENABLE VALIDATE Os dados existentes e futuros devem obedecer à restrição ou asserção. Uma tentativa de aplicar uma nova restrição ou asserção a uma tabela preenchida resultará em um erro se as linhas existentes violarem a restrição ou asserção.
ENABLE NOVALIDATE O banco de dados verifica a constraint ou a asserção, mas não precisa ser verdadeiro para todas as linhas. Portanto, as linhas existentes podem violar a restrição ou asserção, mas as linhas novas ou modificadas devem estar em conformidade com as regras. Esse modo geralmente é usado em data warehouses que contêm dados existentes cuja integridade já foi verificada.
DISABLE VALIDATE O banco de dados desativa a constraint, elimina seu índice e impede a modificação das colunas com restrição. Uma asserção não pode estar neste estado.
DISABLE NOVALIDATE A restrição ou asserção não é verificada e não é necessariamente verdadeira.

Consulte Também: Oracle AI Database SQL Language Reference para saber mais sobre os estados de restrição

Quando o Banco de Dados Verifica Restrições e Asserções de Validade

Cada restrição e asserção está em um estado não adiável (padrão) ou adiável. Esse estado determina quando o Oracle AI Database verifica a validade da restrição ou asserção.

O gráfico a seguir mostra as opções para restrições e asserções diferíveis.

Figura 3: Opções para Restrições e Asserções Diferíveis

Descrição da ilustração cncpt313.gif

Restrições e Asserções Não Diferíveis

Em uma restrição não rastreável, o Oracle AI Database nunca transfere a verificação de validade da restrição ou asserção para o final da transação. Em vez disso, o banco de dados verifica a restrição ou asserção no final de cada instrução. Se a restrição ou asserção for violada, a instrução será revertida.

Por exemplo, existe uma restrição NOT NULL não adiável para a coluna employees.last_name. Se uma sessão tentar inserir uma linha sem sobrenome, o banco de dados fará rollback imediatamente da instrução porque a restrição NOT NULL foi violada. Nenhuma linha foi inserida.

Restrições e Asserções Diferíveis

Uma restrição ou asserção adiável permite que uma transação use a cláusula SET CONSTRAINT para adiar a verificação dessa restrição ou asserção até que uma instrução COMMIT seja emitida. Se você fizer alterações no banco de dados que possam violar a restrição ou asserção, essa definição permitirá que você desative a restrição ou asserção até que todas as alterações sejam concluídas.

Você pode definir o comportamento padrão para quando o banco de dados verifica a restrição ou asserção adiável. Você pode especificar um dos seguintes atributos:

Suponha que uma restrição NOT NULL adiável em employees.last_name esteja definida como INITIALLY DEFERRED. Um usuário cria uma transação com 100 instruções INSERT, algumas das quais têm valores nulos para last_name. Quando o usuário tenta fazer commit, o banco de dados faz rollback de todas as 100 instruções. No entanto, se essa restrição fosse definida como INITIALLY IMMEDIATE, o banco de dados não faria rollback da transação.

Se uma constraint causar uma ação, o banco de dados considerará essa ação como parte da instrução que a causou, seja ela diferida ou imediata. Por exemplo, a exclusão de uma linha em departments causa a exclusão de todas as linhas em employees que fazem referência à linha do departamento excluída. Nesse caso, a exclusão de employees é considerada parte da instrução DELETE executada em departments.

Consulte Também: Referência de Linguagem SQL do Oracle AI Database para obter informações sobre atributos de restrição e seus valores padrão

Exemplos de Verificação de Constraint e Asserção

Os exemplos a seguir ajudam a ilustrar quando o Oracle AI Database executa a verificação de restrições e asserções.

Pressuponha o seguinte:

Exemplo: Inserção de um Valor em uma Coluna de Chave Estrangeira Quando Não Existe Valor de Chave Pai

Este exemplo diz respeito à inserção da primeira linha na tabela employees. No momento, não há linhas. Então, como uma linha pode ser inserida se o valor na coluna manager_id não puder fazer referência a um valor existente na coluna employee_id?

Algumas possibilidades são:

Os valores padrão são incluídos como parte de uma instrução INSERT antes de a instrução ser analisada. Portanto, os valores de coluna padrão estão sujeitos a todas as verificações de constraint de integridade.

Exemplo: Atualização de Todos os Valores de Chave Estrangeira e Chave Pai

Neste exemplo, uma restrição autorreferencial torna as entradas na coluna manager_id de employees dependentes dos valores da coluna employee_id.

A empresa foi vendida. Por causa dessa venda, todos os números de funcionário devem ser atualizados para que sejam o valor atual mais 5000 para coordenar com os números de funcionário da nova empresa. Conforme mostrado no gráfico a seguir, alguns funcionários também são gerentes:

Figura 4: Tabela de funcionários antes das atualizações

Descrição da ilustração cncpt058.gif

Como os números dos gerentes também são números de funcionários, eles também devem aumentar em 5000. Você poderia executar a seguinte instrução SQL para atualizar os valores:

UPDATE employees SET employee_id = employee_id + 5000,
  manager_id = manager_id + 5000;

Embora uma restrição seja definida para verificar se cada valor manager_id corresponde a um valor employee_id, a instrução anterior é válida porque o banco de dados verifica efetivamente as restrições após a conclusão da instrução. A Figura 7-5 mostra que o banco de dados executa as ações de toda a instrução SQL antes de verificar as restrições.

Figura 5: Verificação de Restrição

Descrição da ilustração cncpt059.gif

Os exemplos nesta seção ilustram o mecanismo de verificação de restrição durante as instruções INSERT e UPDATE, mas o banco de dados usa o mesmo mecanismo para todos os tipos de instruções DML. O banco de dados usa o mesmo mecanismo para todos os tipos de restrições, não apenas restrições autorreferenciais. Observação: as operações em uma exibição ou em um sinônimo estão sujeitas às restrições de integridade definidas nas tabelas base.

Exemplo: Todo Gerente Deve Ter um Funcionário no Mesmo Departamento

Este exemplo cria uma asserção para garantir que cada gerente tenha um funcionário no mesmo departamento.

Este exemplo exige que você insira o funcionário primeiro, depois o gerente. Ao executar várias inserções de linha, como com restrições, as asserções são validadas após a execução de cada instrução INSERT. Você poderia definir essa asserção como DEFERRABLE para permitir que você insira o gerente primeiro e, em seguida, o funcionário. A validação ocorreria no COMMIT, em vez de em cada instrução INSERT.

CREATE ASSERTION manager_has_clerk check
(NOT EXISTS
  (SELECT 'manager without clerk'
   FROM   employees m
   WHERE  m.job_id = 'ST_MAN'
     AND  NOT EXISTS
            (SELECT 'a clerk in same department'
             FROM   employees c
             WHERE  c.job_id = 'ST_CLERK'
               AND  c.department_id = m.department_id)));