DES:BncDdsIntegridade

Edição de 11h37min de 11 de setembro de 2017

Integridade entre tabelas

Os bancos de dados dos sistemas da Unioeste foram agrupados por sistema. Por exemplo, o BdAcademicoProducao armazena as tabelas do sistema Academus, o BdRcrHumanos, as tabelas do SGRH. O banco BdUnioesteProducao agrupa tabelas que são utilizadas por mais de um sistema, sendo como um banco de dados central, agrupando as tabelas compartilhadas pelos demais sistemas.
Essa separação das tabelas em bancos menores sempre foi um problema, pois perde-se a integridade referencial dos bancos de dados relacionais, ocorrendo de registros filhos ficarem "órfãos", ou seja, o registro pai é excluído sem que seja feita uma checagem nas tabelas filhas de outros bancos de dados, permitindo assim a exclusão.
Para evitar isso, foi implementada a checagem de integridade por triggers nas tabelas pai, que fazem a consulta nas tabelas filhas, impedindo a exclusão de um registro caso exista registros dependentes em tabelas filhas.

Procedimentos implementados

• criação do banco de dados BdUnioesteModelo, contendo todas as tabelas de todos os bancos de dados. Este banco é gerado a partir do script do DER, onde as tabelas são especificadas como um banco de dados único, mantendo a integridade referencial entre todos os objetos
• implementação da stored procedure spGeraTriggerIntegridade no BdUnioesteModelo, responsável por gerar as triggers de integridade para as tabelas que possuem tabelas filhas. Este procedimento pode receber como parâmetro o nome da tabela pai, ou então pode-se passar NULL, para que sejam geradas as triggers para todas as tabelas do BdUnioesteModelo. O procedimento usa o BdUnioesteModelo para obter a lista de tabelas dependentes de uma tabela pai. A partir desta listagem, é construída a trigger, a qual é criada no banco de dados que possui a tabela pai. A trigger tem funcionamento simples: existem SELECTS para cada tabela filha em seu respectivo banco de dados. Se for encontrado um registro filho, é gerado um erro e a execução do DELETE é interrompida.
• criação da tabela LogDDL, a qual armazenará o nome das tabelas que sofreram altearções no BdUnioesteModelo
• implementação da trigger DDL BdUnioesteModelo_DDL no BdUnioesteModelo, a qual será executada nas operações CREATE_TABLE, ALTER_TABLE, DROP_TABLE, feitas sobre qualquer tabela do BdUnioesteModelo. Esta trigger irá gravar o nome de cada tabela alterada na LogDDL
• implementação da stored procedure spProcessaLogDDL no BdUnioesteModelo, responsável por buscar na tabela LogDDL as tabelas ainda não processadas. Para cada uma destas tabelas, será chamado a spGeraTriggerIntegridade, a qual fará a criação/atualização das triggers da tabela
• criação do job jUnioesteModelo_ProcessaDDLLog, o qual irá executar de 10 em 10 minutos, chamando a spProcessaLogDDL
• criação do job jUnioesteModelo_GeraTodasTriggerIntegridade, o qual irá executar todos os dias a noite, chamando a spGeraTriggerIntegridade

Funcionamento geral

Quando uma alteração/criação/exclusão de tabela precisar ser feita em qualquer banco de dados, o DBA deverá:

1. executar as alterações inicialmente em seu banco de dados produção
2. executar posteriormente as alterações no BdUnioesteModelo
3. a trigger DDL vai ser disparada, gravando as tabelas alteradas na LogDDL
4. o job vai executar em 10 minutos, fazendo então a alteração/criação das triggers de integridade para todas as tabelas alteradas pelo DBA

O DBA deverá seguir o roteiro acima, na ordem descrita, para garantir a correta criação das triggers de integridade.
Como forma de evitar que, por esquecimento, tabelas fiquem sem trigger de integridade, o job jUnioesteModelo_GeraTodasTriggerIntegridade será executado diariamente, re-criando as trigger para todas as tabelas.