integridade de dados

INTEGRIDADE

DE DADOS

MAURO GUIMARÃESKILMER PETERRAFAEL PINHEIRO

Nessa era da informação sob demanda não podemos nos contentar que os dados são apenas registros armazenados em um banco de dados sem a devida garantia de sua integridade. De nada adianta termos imensos bancos de dados armazenando incontáveis bytes de dados, que são constantemente inseridos, modificados, eliminados, se não podemos transformá-los em informação. E, de preferência, informação útil.

E sem garantir que os dados armazenados estão íntegros, dificilmente conseguimos transformar esses bytes em informação real.

Não importa quão avançada sejam suas ferramentas ou técnicas de aplicação em seu ambiente, nada irá adiantar se não houver um investimento na qualidade de seus dados.

INTEGRIDADE DE DADOS


Ao falarmos de integridade de dados, podemos citar alguns exemplos que podem e ajudam a garanti-la:

Firewalls

Sistema Gerenciador de Banco de Dados (SGDB)

Revisão regular de privilégio aos dados

Encriptação

Controle na prevenção de corrupção de dados

Compliance

Fácil recuperação de dados e performance

Integração com os sistemas de armazenamento (discos, fitas)

Tráfego dos dados pela rede

E mais...


As regras de integridade fornecem a garantia de que mudanças feitas no banco de dados por usuários autorizados não resultem em perda da consistência de dados.

As regras de integridade protegem o banco de dados de danos acidentais.


As regras de integridade possuem a seguinte forma:

Declaração de chaves: o conjunto de inserções e atualizações válidas é restrito àquelas que não criem duas entidades com o mesmo valor de chave.

Classe de relacionamento: muitos para muitos, um para muitos, um para um. Restringe o conjunto de relacionamentos válidos entre os diversos conjuntos de entidades.


Restrições de domínios

O princípio para o domínio de atributos é similar aos tipos de variáveis em linguagens de programação. Conjunto dos valores possíveis associados a um atributo.

Integridade Referencial

Condição que garante que um valor que aparece em uma relação para um dado conjunto de atributos também apareça para um certo conjunto de atributos de outra relação.


Asserção

Uma asserção é um predicado que exprime uma condição

que gostaríamos de ver sempre satisfeita na base de

dados.

Quando se define uma asserção, o sistema testa-a, e volta

a testá-la, sempre que há modificações na base de dados

(que a possam violar) Estes testes podem introduzir um

overhead significativo; logo as asserções são para usar

com cuidado e de forma comedida.


Gatilhos (triggers)

Um gatilho é um “comando” que é executado

automaticamente pelo sistema, em conseqência de uma

modificação no banco de dados

Para definir um trigger, há que:

Especificar quando é que o trigger deve ser executado e em

que condições. Especificar o que fazer quando o trigger é executado.

Os gatilhos são mecanismos úteis para avisos a usuários ou para executar automaticamente determinadas tarefas quando as condições para isso são criadas.


Uma dependência funcional é uma restrição entre dois conjuntos de atributos de uma base de dados.

Dados os atributos “A” e “B” de uma entidade, diz-se que “B” é funcionalmente dependente de “A” se e somente se, a cada valor de “A” está associado um único valor de “B”. Ex.:

Dependência funcional


Dependência Funcional Composta

Dado um atributo ou um conjunto de atributos “B” de uma entidade, sendo a chave composta por um conjunto de atributos “A”, diz-se que “B” é completamente dependente funcional da chave primária, se e somente se, a cada valor da chave (e não a parte dele), está associado um valor para cada atributo do conjunto “B”.

Ex.:


Dependência Funcional Transitiva

Dados os atributos “A”, “B” e “C” de uma entidade, sendo “A” a chave, diz-se que “B” e “C” são dependentes transitivos se e somente se, forem funcionalmente dependente de “A” além de existir uma dependência funcional entre eles.

Ex.:

integridade de dados

Technology