Menu de navegação

[eversonpizaParticipante]

Olá amigos,

Tenho um cliente que a base de dados dele, que foi montada por uma outra empresa, é super complexo, de forma que sempre que uma outra empresa precisa acessar essa base por algum motivo perca mais tempo entendendo a base do que desenvolvendo.

Me foi solicitada uma proposta de como deixar isso mais simples de se entender, o problema é que teria que ter pouco (ou melhor, praticamente nenhum) impacto no que esta rodando lá.

Alguém já passou por algo parecido, tem alguma dica de por onde começar a ver isso, uma luz, etc?

O pior, que é preciso preparar isso ainda hoje, para apresentar amanhã de manhã.

[/b]

[IshiiParticipante]

Olá,

O que pode ser feito neste post é apenas um esboço sobre o trabalho. O ideal seria contratar uma consultoria para isso. Vou tentar te passar um pouco e qualquer coisa me mande um e-mail.

1) Levantamento das Tablespaces
2) Levantamento dos datafiles com tamanho e localização física no servidor
3) Grupos de REDO Logs
4) Usuários – Nome, perfil, grants etc
5) Modelagem de Dados dos owners
6) Lista de Objetos dos Owners
7) Sinônimos públicos e privados

Isso apenas para começar, lógico que ainda é pouco pois faltam muitos dados de documentação que deveriam estar disponíveis. Como eu disse antes, melhor procurar uma consultoria específica e qualquer coisa me mande uma e-mail

[]s Ishii

[eversonpizaParticipante]

Olá Ishii

O objetivo inicial, não é nem arrumar a estrutura física da base, datafile, tablespace, etc. mas sim deixar o modelo de dados mais legível, criando por exemplo uma camada intermediária de views.

O problema é que nunca fiz nada parecido, e estou sem muito tempo para pesquisar, por isso recorri a vocês, para ver se alguem conhece alguma metodologia a ser aplicada aqui.

Obrigado,
Everson

[IshiiParticipante]

Olá,

Nem mencionei a estruturação de dados ou de acesso ou criação de views como um dicionário mesmo (e não o do Oracle) para isso, pois sei que isso será um bom trabalho. Comentei das tablespaces e datafiles apenas para início de uma documentação…

Uma idéia seria ter uma réplica do dicionário da Oracle com campos para comentários (dba_objects, dba_tab_columns etc) para que você possa começar a esboçar alguma documentação.

Com relação a criação de views via camada intermediária pode ser muito boa, mas qual seria o verdadeiro propósito desta camada intermediária? Interface como outros sistemas? Método de DML? Segurança de acesso?

Acho que isso já poderia ser um bom início…

[]s Ishii

[eversonpizaParticipante]

O objetivo disso seria deixar o MER de uma forma mais clara, onde as informações seriam mais facilmente rastreáveis, por exemplo, existem alguns casos onde o mesmo conjunto de informações esta dividido em tabelas diferentes, sendo necessário fazer joins entre estas tabelas, e só quem conhece muito bem o banco consegue dizer qual o caminho correto a percorrer, pois ele é muito pouco intuitivo.

Nem o atual ‘dono’ da aplicação sabe dizer pq esta assim, é algo que nasceu assim a muitos anos e foi se arrastando até agora.

Minha grande preocupação com as views seria a performance.
Outra idéia seria trabalhar com materialized views, mas o tempo de atualização passa a ser um problema.

Atn,
Everson

[vieriParticipante]

Seu problema então não é com a instância Oracle e sim com a modelagem de dados.

Baixa alguma ferramenta do tipo ERWIN,DBDESIGNER
faça uma engenharia reversa.
E use o SQL DEVELOPER,
para verificar a estrutura dos objetos,
a maneira mais simples é essa

[eversonpizaParticipante]

Olá Vieri.

Eu tenho o MER deles em formato PDF, gerado pelo Oracle Deigner, o problema é que mesmo tendo o MER ele é muito confuso, e o cliente pediu para deixá-lo mais simples.

[]’s
Everson

[IshiiParticipante]

Everson,

Sem querer te desanimar… mas esse trabalho é realmente de consultoria… Alteração de Modelagem…. a última vez que trabalhei nisso foram cerca de 1000 horas de consultoria e documentação… nem sei se vale a pena em alguns casos, pois a modelagem é tão ruim que é melhor começar do zero…

Isso depende do número de tabelas, do fluxo do Negócio, da necessidade do Cliente (apenas reduzir ou simplificar não é bem um parâmetro).

Para se ter uma idéia, trabalhei anos com um ERP que tinha 3.000 tabelas e mais de 5.000 objetos gerando cerca de mais de um milhão de linhas de código sem contar a GUI que devia ter mais um meio milhão de linhas… ter isso tudo documentado levou cerca de 5 anos e ainda não ficou 100%…

Este trabalho envolve muita gente, muita documentação, muita mudança e isso demanda tempo…

[]s Ishii

[eversonpizaParticipante]

Ishii,

Vc não me desanima com essa informação, infelizmente, é algo que eu previa.

Oq vou tentar fazer no curto prazo é criar uma documentação mais ‘refinada’ em cima do modelo já existente. Criando diferentes modelos para diferentes funcionalidades do sistema, envolvendo apenas as tabelas desta funcionalidade.

Acredito que mesmo assim o trabalho vá ser muito grande, pois teria que correr atrás de informações que ninguém sabe onde encontrar, mas é melhor do que criar um ‘workaround’ em uma camada intermediária.

Teria que ser algo bem pratico, para além de facilitar o entendimento, tb ajudar a evitar a redundância de informações. (espero)

Atn,
Everson

[juliano_sfParticipante]

O Ishii tah certo, meu isso dá mto trabalho… Porém, se você TEM que fazer isso, te sugiro começar pelos Relatórios… vê como os relatórios foram montados e pode criar views a partir deles

[CleitonHanzenParticipante]

Opá…

Bom com certeza isso não vai ser tarefa fácil. 90% dos bancos com que trabalho utilizam “software de prateleira” (Senior, Benner, Microsiga) e devo te dizer, que a modelagem desses caras é um lixo, sem comentar na forma como a aplicação é desenvolvida (geradores de código que para retornar um campo da tabela, fazem o select de todos os demais).
Se for esse teu caso, nem se esquenta, vc vai ficar 10 anos tentando arrumar e cada versão nova, os estagiários vão adicionar outras 200 cagadas..
Caso o sistema seja legado, aí é um “pouco” mais fácil, mas com certeza vc vai se deparar com sistemas antigos, migrados de outros bancos, que nenhum analista conhece e meter a mão vai ser uma M… total…
O que já vi empresas fazer (deu muito certo, apesar do trabalho), foi separar o único usuário que eles possuiam, para outros 5 novos,cada um com seus objetos específicos (tomar cuidado com os grants) e a partir daí, remodelar e fazer carga dos dados e ajustar a aplicação também para esta situação….Levou tempo, mas o resultado ficou show de bola e esta necessidade surgiu devido à empresas diferentes cuidarem de módulos diferentes do sistema…

Sem querer ser “sacana”, mas boa sorte e boas noites de sono com essa bomba nas mãos….rsrsrsrs

flws..

[vieriParticipante]

Tire um relátorio ADDM,ASH e verifique quais são as tabelas que são mais acessadas no database, e foque em cima delas,
provavelmente são nelas que são embutidas novas versões.

Tente destrinchar essas principais tabelas, relacionamentos , tente entender um pedaço importante do modelo e documente.

[Sergio WilliansMestre]

O que o Ishii disse no seu post é a mais pura verdade. É impossível alterar a modelagem sem um bom planejamento e TEMPO para se construir algo realmente funcional, ou pode se acabar criando um novo monstro.
Muitas vezes fica mais fácil e barato jogar o legado fora e implementar um ERP de mercado.
Mas como pelo jeito vocês não poderão fazer isso, a idéia do vieri vai te auxiliar bastante, pois quando falamos de MER, processo é intrínsicamente ligado a conjunto de objetos no banco de dados, portanto, ao mapear os mais utilizados, você mapeará também os principais processos utilizados.

[Autor]

Posts