Restrição de Integridade

Considerando um determinado SGBD, as restrições de integridade

Restrição de integridade

Uma regra que deve ser obedecida por todos estados da
base de dados que são considerados consistentes.

Especificação do maior número possível de restrições de
integridade:

É possível evitar que o usuário leve a base de dados
inadvertidamente a um estado inconsistente.
Restrições de integridade/1
Restrições estáticas - Restrições dinâmicas

Restrições estáticas (de estado)

São restrições sobre um estado da base de dados. Para verificá-las basta
observar o estado atual da base de dados.

Exemplos:
 Restrições de domínio
 Restrições de chave
 Restrições de relacionamento entre diferentes atributos (o salário do
empregado não pode ser maior que o de seu gerente)
Restrições de integridade/3
Tipos de regras em um SGBD
podem ser classificadas em três categorias:

Implícitas
 Nesta categoria, enquadram-se todas as restrições que podem ser
declaradas (de forma não procedural) na DDL.
 No caso da abordagem relacional:
chave primária, integridade referencial, domínio,…

Explícitas
 Nesta categoria, enquadram-se todas as restrições que devem ser
explicitamente especificadas no SGBD em questão, quer através
de programação, quer através de instruções especiais.

Inerentes ao modelo
 São restrições de integridade inerentes ao modelo em questão e
que não necessitam ser especificadas (na abordagem relacional, o
fato de um atributo somente ter um valor)
Restrições de integridade/2
Restrições estáticas - Restrições dinâmicas

Restrições dinâmicas (de transição)

São restrições cuja verificação exige dois estados da base de dados, um
anterior e um posterior à transição.

Exemplo:
 O estado civil de uma pessoa, não pode mudar de casado para solteiro,
mas pode mudar de viúvo para casado.

Nos SGBD comerciais, normalmente não são oferecidas facilidades para
garantir este tipo de restrições. O controle da restrição fica por conta de
quem desenvolve as aplicações .
Restrições de integridade/4
 Restrições explícitas de integridade
Definição procedural por codificação explícita SQL – definição de restrições de integridade explícitas

Neste método, o usuário deve incluir dentro de cada transação de alteração o

código correspondente a verificação da restrição.
CHECK CONSTRAINT

Significa:
ASSERTION
 Incluir código em cada transação de inclusão, exclusão ou alteração
TRIGGER
de atributos.

Uma única restrição de integridade pode ficar espalhada dentro de diversas
transações
 Exemplo:
Integridade referencial entre empregado e departamento:
Ao incluir um empregado, verificar se o departamento existe.
Ao excluir um departamento, verificar se o mesmo está vazio.
Ao alterar o departamento de um empregado, garantir que o
mesmo existe.

Conseqüência:
Quando restrições de integridade mudam, todos trechos de código
referentes à restrição devem ser modificados.
Restrições de integridade/5 Restrições de integridade/6

CHECK CONSTRAINT ASSERTION

Especificação declarativa de uma expressão booleana que deve
Especificação declarativa de uma expressão booleana que deve
ser verdadeira para todas linhas de uma tabela (valores de uma ser verdadeira para toda a base de dados (pode envolver várias
coluna) tabelas)

Mesma sintaxe da cláusula WHERE do SELECT CREATE ASSERTION ValidaSalario

Exemplo: (NOT EXISTS
ALTER TABLE Cliente
SELECT * FROM emp
ADD CONSTRAINT ValidaCampos
WHERE
CHECK
emp.sal<
(TipoCli=“Pessoa Física” AND
CIC IS NOT NUL AND (SELECT sal
CGC IS NULL) OR FROM emp AS ger
(TipoCli=“Pessoa Jurídica” AND WHERE ger.cod_emp=emp.cod_emp_ger)
CIC IS NULL AND
Implementação em SGBD é restrita (problema de performance)
CGC IS NOT NULL)

Restrições de integridade/7 Restrições de integridade/8

TRIGGER Trigger

“Stored procedure” que é executada automaticamente quando da
Um trigger contém três partes:
atualização de uma tabela

evento (p.ex., atualizar um campo)

Pode ser usado para:
condição (p.ex.., uma consulta que faz um teste)

ação (p.ex., exclusão, inclusão,…, RAISEERROR)

Atualizações em cascata

Quanto o evento ocorre,

Verificação de restrições de integridade que não podem ser
1. Sistema testa condição e
verificadas pelas restrições implícitas nem pela cláusula 2. Executa ação
CHECK

Observação: triggers podem ter efeitos em cascata

Fornecedores de SGBD não esperaram os padrões

Restrições de integridade/9 Restrições de integridade/10

Opções de Trigger Variáveis usadas em Trigger

Eventos possíveis incluem
OLD

INSERT ON table
A linha modificada antes da ocorrência do evento.

DELETE ON table
NEW

UPDATE [OF column] ON table
A linha modificada após da ocorrência do evento.

INSTEAD OF
OLD_TABLE

Trigger pode ser ativado por
Uma tabela virtual que contém todas linhas modificadas no

FOR EACH ROW estado de antes da ocorrência do evento
 Ação é executada para cada linha modificada
NEW_TABLE

FOR EACH STATEMENT
Uma tabela virtual que contém todas linhas modificadas no

 Ação é executada uma vez somente para todas linhas

estado de após da ocorrência do evento
modificadas pela operação

Ação de modificação pode ser executada

AFTER ou BEFORE o evento

Restrições de integridade/11 Restrições de integridade/12

 Exemplo de Trigger – Row level Exemplo de Trigger - – For each statement

CREATE TRIGGER NoLowerPrices CREATE TRIGGER MatriculAutomaticaIntroducao

AFTER UPDATE OF preco ON Produto AFTER INSERT ON Aluno
REFERENCING REFERENCING NEW_TABLE AS novosAlunos
OLD AS OldTuple FOR EACH STATEMENT
NEW AS NewTuple INSERT INTO Matricula
FOR EACH ROW SELECT CodigoAl, ’Intro001’
WHEN (OldTuple.preco > NewTuple.preco) FROM novosAlunos
UPDATE Product WHERE CodigoAl NOT IN
SET preco = OldTuple.preco (SELECT CodigoAl FROM Matricula
WHERE nome = NewTuple.nome WHERE CodigoDisc = ’Intro001’)

Todos produtos com o mesmo são atualizados quando um deles
é atualizado
Matricula alunos novos em “Intor001” automaticamente

Exemplo de tratamento de redundância

Restrições de integridade/13 Restrições de integridade/14

Exemplo de Trigger – For each statement Exemplo de Trigger – Before Update

CREATE TRIGGER average-price-preserve

CREATE TRIGGER ImpedeAumentoExagerado
INSTEAD OF UPDATE OF preco ON Produto
REFERENCING BEFORE UPDATE OF salario ON Empregado
OLD_TABLE AS OldStuff REFERENCING OLD AS o NEW AS n
NEW_TABLE AS NewStuff FOR EACH ROW
FOR EACH STATEMENT WHEN (n.salario > 1.5 * o.salario)
WHEN (1000 < SET n.salario = 1.5 * o.salario
(SELECT AVG (preco)
FROM ((Produto EXCEPT OldStuff)
Impede aumentos de salário de mais de 50%
UNION NewStuff))
Observar que o conteúdo de NEW é alterado
DELETE FROM Produto
WHERE (nome, preco, empresa) IN OldStuff;
INSERT INTO Produto
(SELECT * FROM NewStuff)

Se a média de preços cai abaixo de 1000, alteração é desprezada
Restrições de integridade/15 Restrições de integridade/16
 Exemplo de Trigger - Validação Trigger – detalhes de implementação

CREATE TRIGGER OneSupplier
Chamada recursiva

BEFORE UPDATE OF CodFornec ON Embarq
Ação de um trigger pode disparar outro
REFERENCING NEW AS N
Pode entrar em um laço infinito
FOR EACH ROW
Interação com o teste de restrições de integridade pelo SGBD
WHEN (N.CodFornec IS NULL)
Quando testar se um trigger viola uma restrição:
SIGNAL SQLSTATE '70005'  Após a execução de um BEFORE trigger
(‘Coódigo do fornecedor deve ser fornecido') O trigger pode consertar a violação
 Antes de um AFTER trigger

Exemplo de Trigger para verificar restrição de integridade AFTER triggers podem ver o efeito de por exemplo

Forma de sinalizar erro varia de SGBD para SGBD exclusões em cascata causadas por restirções de
integridade referenciais

(Baseado no DB2 – cada produto tem sua política própria)

Restrições de integridade/17 Restrições de integridade/18

Segurança e controle de acesso Segurança em SQL

A base de dados deve ser protegida contra acesso, intencional ou não,
SQL possui uma instrução na forma:
por usuários não autorizados. GRANT <lista de privilégios>

O controle de acesso envolve especificar ao SGBD que usuário pode

ON <nome de tabela ou visão>
realizar que tipo de operação sobre que objetos da base de dados. TO <lista de usuários>

A <lista de privilégios> permite especificar os seguintes tipos de

Além disso são necessários mecanismos de autorização, isto é,
privilégios:
mecanismos para que o DBA delegue autoriazação a outros usuários
para estabelecer privilégios de acesso
RESOURCE
 Especifica que o usuário pode criar tabelas e visões

Os mecanismos oferecidos por SGBD comerciais são normalmente fracos
e não são suficientes para evitar acesso não autorizado intencional.
SELECT
 Especifica que o usuário pode ler os dados das tabelas ou
visões listadas

Restrições de integridade/19 Restrições de integridade/20

Segurança em SQL (continuação) Segurança em SQL (continuação)

DELETE
REFERENCES
 Especifica que o usuário pode excluir linhas das tabelas  Permite que um usuário crie tabelas que contém uma chave
ou visões listadas estrangeira de uma chave especificada.

INSERT  Também é atribuído a colunas específicas:
 Especifica que o usuário pode incluir linhas das tabelas ou  GRANT REFERENCES(código) ON depto TO u1,u2
visões listadas especifica que os usuários podem criar tabelas que referencia

UPDATE a chave primária da tabela de departamentos
 Especifica que o usuário pode alterar linhas das tabelas
Por exclusão, um usuário não pode conceder os privilégios recebidos a
ou visões listadas outros usuários, a menos que possua autorização explícita para tal
 Este privilégio é atribuído a colunas específicas:  GRANT SELECT ON DEPT TO u1,u2 WITH GRANT OPTION
 GRANT UPDATE(saldo) ON depósito TO u1,u2  A cláusula WITH GRANT OPTION especifica que o usuário
pode também conceder seus privilégios a outros usuários

Restrições de integridade/21 Restrições de integridade/22

Segurança em SQL (continuação)

Para revogar os direitos de acesso de um usuários é usada a

instrução:
REVOKE <lista de privilégios>
ON <nome de tabela ou visão>
FROM <lista de usuários>
 Quando um usuário perde um privilégio, todos os usuários
que dele receberam este privilégio também o perdem.

Restrições de integridade/23