Page 1. Restrição de Integridade. TRIGGER e SEGURANÇA. Restrições estáticas - Restrições dinâmicas. Tipos de regras em um SGBD

Transcrição

1 Restrição de Integridade TRIGGER e SEGURANÇA 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. Prof. Edson Thizon Tipos de regras em um SGBD Considerando um determinado SGBD, as restrições de integridade 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: Explícitas chave primária, integridade referencial, domínio, 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 à abordagem São restrições de integridade inerentes à abordagem em questão e que não necessitam ser especificadas (na abordagem relacional, o fato de um atributo somente ter um valor) 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) 4 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. 5 Restrições explícitas de integridade Definição procedural por codificação explícita 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. Significa: Incluir código em cada transação de inclusão, exclusão ou alteração de atributos. Uma única restrição de integridade pode ficar espalhada dentro de diversas transações Exemplo: Conseqüência: 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. Quando restrições de integridade mudam, todos trechos de código referentes à restrição devem ser modificados. 6 Page

2 SQL definição de restrições de integridade explícitas CHECK CONSTRAINT ASSERTION TRIGGER CHECK CONSTRAINT Especificação declarativa de uma expressão booleana que deve ser verdadeira para todas linhas de uma tabela (valores de uma coluna) Mesma sintaxe da cláusula WHERE do SELECT Exemplo: ALTER TABLE Cliente ADD CONSTRAINT ValidaCampos CHECK (TipoCli= Pessoa Física AND CIC IS NOT NULL AND CGC IS NULL) OR (TipoCli= Pessoa Jurídica AND CIC IS NULL AND CGC IS NOT NULL) 7 8 ASSERTION TRIGGER Especificação declarativa de uma expressão booleana que deve ser verdadeira para toda a base de dados (pode envolver várias tabelas) CREATE ASSERTION ValidaSalario (NOT EXISTS SELECT * FROM emp WHERE emp.sal< (SELECT sal FROM emp AS ger WHERE ger.cod_emp=emp.cod_emp_ger) Implementação em SGBD é restrita (problema de performance) Stored procedure que é executada automaticamente quando da atualização de uma tabela Pode ser usado para: Atualizações em cascata Verificação de restrições de integridade que não podem ser verificadas pelas restrições implícitas nem pela cláusula CHECK 9 0 Trigger Opções de Trigger Um trigger contém três partes: evento (p.ex., atualizar um campo) condição (p.ex.., uma consulta que faz um teste) ação (p.ex., exclusão, inclusão,, RAISEERROR) Quando o evento ocorre,. Sistema testa condição e. Executa ação Observação: triggers podem ter efeitos em cascata Fornecedores de SGBD não esperaram os padrões Eventos possíveis incluem INSERT ON table DELETE ON table UPDATE [OF column] ON table INSTEAD OF Trigger pode ser ativado por Ação é executada para cada linha modificada FOR EACH STATEMENT Ação é executada uma vez somente para todas linhas modificadas pela operação Ação de modificação pode ser executada AFTER ou BEFORE o evento (normalmente antes) Page

3 Variáveis usadas em Trigger OLD A linha modificada antes da ocorrência do evento. NEW A linha modificada após da ocorrência do evento. OLD_TABLE Uma tabela virtual que contém todas linhas modificadas no estado de antes da ocorrência do evento NEW_TABLE Uma tabela virtual que contém todas linhas modificadas no estado de após da ocorrência do evento Exemplo de Trigger Row level CREATE TRIGGER AFTER UPDATE OF REFERENCING OLD AS OldTuple NEW AS NewTuple NoLowerPrices preco ON Produto WHEN (OldTuple.preco > NewTuple.preco) UPDATE Produto SET preco = OldTuple.preco WHERE nome = NewTuple.nome Todos produtos com o mesmo são atualizados quando um deles é atualizado Exemplo de tratamento de redundância 4 Exemplo de Trigger - For each statement CREATE TRIGGER MatriculAutomaticaIntroducao AFTER INSERT ON Aluno REFERENCING NEW_TABLE AS novosalunos FOR EACH STATEMENT INSERT INTO Matricula SELECT CodigoAl, Intro00 FROM novosalunos WHERE CodigoAl NOT IN (SELECT CodigoAl FROM Matricula WHERE CodigoDisc = Intro00 ) Matricula alunos novos em Intro00 automaticamente Exemplo de Trigger For each statement CREATE TRIGGER average-price-preserve INSTEAD OF UPDATE OF preco ON Produto REFERENCING OLD_TABLE AS OldStuff NEW_TABLE AS NewStuff FOR EACH STATEMENT WHEN (000 < (SELECT AVG (preco) FROM ((Produto EXCEPT OldStuff) UNION NewStuff)) 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 000, alteração é desprezada 5 6 Exemplo de Trigger Before Update CREATE TRIGGER ImpedeAumentoExagerado BEFORE UPDATE OF salario ON Empregado REFERENCING OLD AS o NEW AS n WHEN (n.salario >.5 * o.salario) SET n.salario =.5 * o.salario Impede aumentos de salário de mais de 50% Observar que o conteúdo de NEW é alterado Exemplo de Trigger - Validação CREATE TRIGGER OneSupplier BEFORE UPDATE OF CodFornec ON Embarq REFERENCING NEW AS N WHEN (N.CodFornec IS NULL) SIGNAL SQLSTATE '70005' ( Código do fornecedor deve ser fornecido') Exemplo de Trigger para verificar restrição de integridade Forma de sinalizar erro varia de SGBD para SGBD 7 8 Page

4 Trigger detalhes de implementação Chamada recursiva Ação de um trigger pode disparar outro Pode entrar em um laço infinito Interação com o teste de restrições de integridade pelo SGBD Quando testar se um trigger viola uma restrição: Após a execução de um BEFORE trigger O trigger pode consertar a violação Antes de um AFTER trigger AFTER triggers podem ver o efeito de por exemplo exclusões em cascata causadas por restirções de integridade referenciais (Baseado no DB cada produto tem sua política própria) Segurança e controle de acesso A base de dados deve ser protegida contra acesso, intencional ou não, por usuários não autorizados. O controle de acesso envolve especificar ao SGBD que usuário pode realizar que tipo de operação sobre que objetos da base de dados. Além disso são necessários mecanismos de autorização, isto é, mecanismos para que o DBA delegue autorização a outros usuários para estabelecer privilégios de acesso Os mecanismos oferecidos por SGBD comerciais são normalmente fracos e não são suficientes para evitar acesso não autorizado intencional. 9 0 Criação de Usuários Segurança em SQL No Oracle o usuário DBA é o SYSTEM e a senha default é MANAGER. Para criar usuário utilize o seguinte comando: CREATE USER _USUARIO IDENTIFIED BY SENHA_USUARIO; OBS: PODE SER UTILIZADO A FERRAMENTA ENTRERPISE CONSOLE OU DBA STUDIO DA ORCALE. SQL possui uma instrução na forma: GRANT <lista de privilégios> ON <nome de tabela ou visão> TO <lista de usuários> A <lista de privilégios> permite especificar os seguintes tipos de privilégios: RESOURCE Especifica que o usuário pode criar tabelas e visões SELECT Especifica que o usuário pode ler os dados das Segurança em SQL (continuação) DELETE Especifica que o usuário pode excluir linhas das INSERT UPDATE Especifica que o usuário pode incluir linhas das Especifica que o usuário pode alterar linhas das Este privilégio é atribuído a colunas específicas: GRANT UPDATE(saldo) ON depósito TO u,u Segurança em SQL (continuação) REFERENCES Permite que um usuário crie tabelas que contém uma chave estrangeira de uma chave especificada. Também é atribuído a colunas específicas: GRANT REFERENCES(código) ON depto TO u,u especifica que os usuários podem criar tabelas que referencia a chave primária da tabela de departamentos Por exclusão, um usuário não pode conceder os privilégios recebidos a outros usuários, a menos que possua autorização explícita para tal GRANT SELECT ON DEPT TO u,u WITH GRANT OPTION A cláusula WITH GRANT OPTION especifica que o usuário pode também conceder seus privilégios a outros usuários 4 Page 4 4

5 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. AUDITORIA DE DADOS Para auditar informações em um banco de dados pode-se utilizar ferramentas de terceiros (como a própria auditoria fornecida por alguns SGBD) ou podemos construir a nossa própria auditoria. A seguir veremos maneiras de construir auditoria de dados nos Banco de Dados utilizados pelas aplicações Auditoria sem informações históricas Esta é a maneira mais fácil e com melhor performance de termos auditoria de informações nos Banco de Dados, porém com esta implementação não teremos a história das atualizações realizadas. Para implementarmos esta auditoria criaremos alguns campos adicionais em todas as tabelas que queremos auditar no Banco de Dados. Os campos são: Data e Hora de inserção; Usuário que inseriu a informação; Data e Hora da última alteração; Usuário que alterou por último a informação; Data e hora de deleção; Usuário que deletou a informação; - Auditoria sem informações históricas (cont...) Exemplo: SALARIO 000,00 500,00 000,00 Tabela empregado com colunas adicionais para auditoria SALARIO DT_INSERT USER_I DT_UPDATE USER_U DT_DEL USER_D 000,00 500,00 000, Auditoria sem informações históricas (cont...) SALARIO 000,00 000,00 000,00 DT_INSERT 0/08/004 :00 0/0/004 :45 5/0/004 4:00 USER_I ELIZA DT_UPDATE /0/004 5:00 USER_U DT_DEL 6/0/004 0:00 USER_D - Auditoria com informações históricas Esta é uma maneira de implementar auditoria com a história de todas as atualizações realizadas. Para implementarmos esta auditoria criaremos trigger em todas as tabelas que queremos auditar e uma tabela chamada AUDITORIA com os seguintes campos: Data e Hora; Operação (Insert, Delete ou Update); Com as colunas que acrescentamos na tabela empregado podemos descobrir que o usuário inseriu a informação do empregado Usuário; João e alterou as informações do empregado Maria, também sabemos Tabela; que o usuário inseriu as informações do empregado Maria e excluiu o empregado Pedro. Em todas estes informações sabemos a Dados; data e o horário que foi feito, porém não temos como saber quantas vezes já foram alterados os dados do empregado Maria, sabemos que o último que fez a alteração foi o usuário. Com estas colunas temos várias informações, porém não temos a história das atualizações realizadas. 9 0 Page 5 5

6 - Auditoria com informações históricas(cont...) Exemplo: Tabela AUDITORIA TABELA DATA 0/08/004 :00 0/0/004 :45 5/0/004 4:00 /0/004 5:00 6/0/004 0:00 OPERACAO I I I U D USUARIO ELIZA DADOS SALARIO 000,00 500,00 000,00 Com a tabela AUDITORIA podemos descobrir que o usuário inseriu a informação do empregado João e alterou as informações do empregado Maria, também sabemos que o usuário inseriu as informações do empregado Maria e excluiu o empregado Pedro. Em todas estes informações sabemos a data e o horário que foi feito. Também teremos como saber quantas vezes já foram alterados os dados do empregado pois assim temos a história de todas as atualizações realizadas. - Implementação da auditoria com informações históricas(cont...) Criação da tabela AUDITORIA: CREATE TABLE AUDITORIA ( TABELA VARCHAR(50) NOT NULL, DATA DATE NOT NULL, OPERACAO CHAR() NOT NULL, USUARIO VARCHAR(50) NOT NULL, DADOS VARCHAR(000) NOT NULL); Criação da Trigger na tabela : CREATE TRIGGER TRG_AUDIT_ AFTER DELETE OR INSERT OR UPDATE ON DECLARE DADOS VARCHAR(000); BEGIN IF DELETING THEN DADOS := 'CÓDIGO : ' :OLD. : ' :OLD. SALÁRIO : ' :OLD.SALARIO; INSERT INTO AUDITORIA VALUES('',SYSDATE,'D',USER,DADOS); END IF; IF INSERTING THEN DADOS := 'CÓDIGO : ' :NEW. : ' :NEW. SALÁRIO : ' :NEW.SALARIO; INSERT INTO AUDITORIA VALUES('',SYSDATE,'I',USER,DADOS); END IF; IF UPDATING THEN DADOS := 'CÓDIGO OLD: ' :OLD. OLD: ' :OLD. SALÁRIO OLD: ' :OLD.SALARIO 'CÓDIGO NEW: ' :NEW. NEW: ' :NEW. SALÁRIO NEW: ' :NEW.SALARIO; INSERT INTO AUDITORIA VALUES('',SYSDATE,'U',USER,DADOS); END IF; END; Referência Bibliográfica HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4ª Edição. Ed. Sagra, 00. Capítulo: Restrições de Integridade. FERNANDES, Lúcia. Oracle 9i para desenvolvedores : Oracle developer 6i curso completo. Rio de Janeiro : Axcel Books, p. Page 6 6