DES:BncDdsIntegridade
De Wiki Unioeste NTI
(Diferença entre revisões)
Liege.ciupak (disc | contribs) |
Liege.ciupak (disc | contribs) (→Procedimentos implementados) |
||
| (3 edições intermediárias de um usuário não apresentadas) | |||
| Linha 2: | Linha 2: | ||
== Integridade entre tabelas == | == 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. <br /> | + | 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. <br /> |
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. <br /> | 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. <br /> | ||
| − | 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. | + | 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 == | == Procedimentos implementados == | ||
* '''BdUnioesteModelo''': criado o banco de dados que contém 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 | * '''BdUnioesteModelo''': criado o banco de dados que contém 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 | ||
| − | * BdUnioesteModelo.'''spGeraTriggerIntegridade''': criada stored procedure que é 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. | + | * BdUnioesteModelo.'''LogDDL''': criada tabela para armazenar o nome das tabelas que sofreram alterações no ''BdUnioesteModelo'' |
| − | * BdUnioesteModelo.''' | + | * BdUnioesteModelo.'''BdUnioesteModelo_DDL''': ''trigger Data Definition Language'' (DDL) que será executada nas operações ''CREATE_TABLE'', ''ALTER_TABLE'', ''DROP_TABLE'', feitas em qualquer tabela do ''BdUnioesteModelo''. Esta ''trigger'' irá gravar o nome de cada tabela alterada na tabela ''LogDDL'' |
| − | + | * BdUnioesteModelo.'''spGeraTriggerIntegridade''': criada ''stored procedure'' que é 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. | |
| − | + | * BdUnioesteModelo.'''spProcessaLogDDL''': criada ''stored procedure'' que é 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 | |
| − | * '''jUnioesteModelo_ProcessaDDLLog''': criado job que irá executar todos os dias à noite, chamando a spProcessaLogDDL que, por sua vez, chama a spGeraTriggerIntegridade | + | * '''jUnioesteModelo_ProcessaDDLLog''': criado ''job'' que irá executar todos os dias à noite, chamando a ''spProcessaLogDDL'' que, por sua vez, chama a ''spGeraTriggerIntegridade'' |
| − | <!-- * '''jUnioesteModelo_AtualizaTriggersIntegridade''': criado job que irá executar todos os dias à noite, chamando a spGeraTriggerIntegridade--> | + | <!-- * '''jUnioesteModelo_AtualizaTriggersIntegridade''': criado ''job'' que irá executar todos os dias à noite, chamando a ''spGeraTriggerIntegridade''--> |
== Funcionamento geral == | == Funcionamento geral == | ||
Quando uma alteração/criação/exclusão de tabela precisar ser feita em qualquer banco de dados, o DBA deverá: | Quando uma alteração/criação/exclusão de tabela precisar ser feita em qualquer banco de dados, o DBA deverá: | ||
# executar as alterações inicialmente em seu banco de dados produção | # executar as alterações inicialmente em seu banco de dados produção | ||
| − | # executar posteriormente as alterações no BdUnioesteModelo | + | # executar posteriormente as alterações no ''BdUnioesteModelo'' |
| − | # a trigger DDL vai ser disparada, gravando as tabelas alteradas na LogDDL | + | # a ''trigger'' DDL vai ser disparada, gravando as tabelas alteradas na ''LogDDL'' |
| − | # o job jUnioesteModelo_ProcessaDDLLog | + | # o job ''jUnioesteModelo_ProcessaDDLLog'' é executado à noite, fazendo então a alteração/criação das ''triggers'' de integridade para todas as tabelas alteradas pelo DBA |
## se necessário, pode-se antecipar a execução, fazendo manualmente | ## se necessário, pode-se antecipar a execução, fazendo manualmente | ||
| − | O DBA deverá seguir o roteiro acima, na ordem descrita, para garantir a correta criação das triggers de integridade. | + | O DBA deverá seguir o roteiro acima, na ordem descrita, para garantir a correta criação das ''triggers'' de integridade. |
Edição atual tal como 08h12min de 30 de novembro de 2018
Voltar a Página Inicial - Menu Sistemas
[editar] 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.
[editar] Procedimentos implementados
- BdUnioesteModelo: criado o banco de dados que contém 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
- BdUnioesteModelo.LogDDL: criada tabela para armazenar o nome das tabelas que sofreram alterações no BdUnioesteModelo
- BdUnioesteModelo.BdUnioesteModelo_DDL: trigger Data Definition Language (DDL) que será executada nas operações CREATE_TABLE, ALTER_TABLE, DROP_TABLE, feitas em qualquer tabela do BdUnioesteModelo. Esta trigger irá gravar o nome de cada tabela alterada na tabela LogDDL
- BdUnioesteModelo.spGeraTriggerIntegridade: criada stored procedure que é 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.
- BdUnioesteModelo.spProcessaLogDDL: criada stored procedure que é 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
- jUnioesteModelo_ProcessaDDLLog: criado job que irá executar todos os dias à noite, chamando a spProcessaLogDDL que, por sua vez, chama a spGeraTriggerIntegridade
[editar] Funcionamento geral
Quando uma alteração/criação/exclusão de tabela precisar ser feita em qualquer banco de dados, o DBA deverá:
- executar as alterações inicialmente em seu banco de dados produção
- executar posteriormente as alterações no BdUnioesteModelo
- a trigger DDL vai ser disparada, gravando as tabelas alteradas na LogDDL
- o job jUnioesteModelo_ProcessaDDLLog é executado à noite, fazendo então a alteração/criação das triggers de integridade para todas as tabelas alteradas pelo DBA
- se necessário, pode-se antecipar a execução, fazendo manualmente
O DBA deverá seguir o roteiro acima, na ordem descrita, para garantir a correta criação das triggers de integridade.
