Desenvolvimento

Quando do início da análise, percebemos que um dos principais erros nesse banco de dados seria a falta de relacionamentos entre as chaves estrangeiras, visto que isso impede que os dados possam se relacionar entre tabelas, que por sua vez dificulta uma pesquisa de SELECT. Ademais, algumas tabelas que têm colunas duplicadas, infere-se que poderia haver alguma anomalia.

Neste banco de dados ainda há problemas da seguinte ordem: alguns campos possuem valores fora da devida proporção de volume, no qual pode causar um estado inconsistente.

ALGUNS PROBLEMAS FORAM ENVONTRADOS COMO:

-A maioria das tabelas estavam com as colunas de tipo varchar com bastante quantidade de caracteres. Isso poderia consumir memória desnecessariamente no banco de dados e no próprio SGBD.

-Um outro problema é a relação entre as tabelas. Algumas tabelas estão com o id disponível para atribuição de relação mas não foram acionadas as respectivas chaves estrangeiras, como na tabela "orgaoprocesso".

-Algumas consultas de SELECT possivelmente gerariam resultados vazios, devido a existência de muitas tabelas sem ligação de chave estrangeira.

Para corrigirmos esse banco de dados, utilizamos o processo de modelagem lógica para que ele tenha uma base correta e consistente, que por sua vez, proporcionaria uma perspectiva de como seria o modelo físico. De início, corrigimos no próprio modelo lógico, o uso desnecessário de varchar em várias colunas (bem como o equívoco do alto número de caracteres), os devidos relacionamentos entre tabelas e analisamos cada dados que seria inserido.

Após essas medidas, criamos o modelo físico, que apesar do modelo lógico finalizado, foi a partir do físico que alguns erros foram sanados durante a criação. Suas ligações foram definidas e os campos alterados. Com esse novo banco criado, podemos vêr a diferença entre um banco de dados e outro. Um novo banco de dados com mais consistência e segurança.

Depois disso, foram revisitados todos os pontos de falha e problemas identificados no banco de dados "pintegrador", com intuito de garantir a funcionalidade das intervenções realizadas.

É possível que os problemas e as falhas não apareçam logo no início do desenvolvimento do banco de dados. Normalmente os problemas vêm futuramente, causando assim uma enorme dor de cabeça, pois, para um ADMINISTRADOR DE BANCO DE DADOS, não há nada mais importante que a integridade e segurança dos dados de seu cliente.