Como mergulhar em um banco de dados feio?

Tenho certeza que muitos de vocês estão / estavam lidando com um banco de dados feio. Você sabe, aquele banco de dados que não é normalizado, aquele banco de dados em que você precisa fazer uma grande consulta dolorosa para obter os dados mais triviais, aquele banco de dados que está em produção e você não pode mudar um pouco ... você sabe , "aquele".

Minha pergunta é: como você lida com isso?

• Você tenta criar um novo banco de dados?
• Você desiste e deixa em paz?
• Que conselho você pode dar?

• A primeira coisa que faço é criar um diagrama de relacionamento entre entidades (ERD). Às vezes, você pode simplesmente descrever os metadados com ferramentas de linha de comando, mas para economizar tempo, existem algumas ferramentas que podem gerar um diagrama automaticamente.

• Segundo, examine cada tabela e coluna para garantir que eu aprenda o significado do que ele armazena.

• Terceiro, examine cada relacionamento e verifique se eu entendo como as tabelas se relacionam.

• Quarto, leia todas as visualizações ou gatilhos para entender a execução personalizada da integridade de dados ou as operações em cascata.

• Quinto, leia todos os procedimentos armazenados. Leia também os privilégios de acesso ao SQL, se houver.

• Sexto, leia partes do código do aplicativo que usa o banco de dados. É aí que algumas regras comerciais adicionais e regras de integridade de dados são aplicadas.

atualização: Acabei de ler um artigo interessante " 9 coisas para fazer quando você herdar um banco de dados " com uma boa lista de verificação.

Resumo:

1. Backups
2. Pesquisa (as etapas de documentação do esquema mencionadas acima)
3. Fale com os ex-desenvolvedores
4. Um banco de dados de erros
5. Controle do código fonte
6. Converse com os usuários e / ou proprietários de empresas
7. Estabeleça credibilidade com os usuários corrigindo algumas coisas ou fazendo alguns aprimoramentos
8. Crie um ambiente de desenvolvimento
9. Soltar objetos obsoletos

Isso nem sempre é possível, mas uma coisa que funcionou para mim em determinadas situações é substituir algumas das tabelas por visualizações. Em seguida, você pode arrumar as tabelas e, em alguns casos, acabar com as visualizações. Como eu disse, só funciona em alguns casos.

O dicionário de dados é seu amigo. Além disso, tente fazer engenharia reversa do banco de dados com a ferramenta de engenharia reversa no Visio e criar seu próprio conjunto de diagramas. Como a engenharia reversa é interativa - você cria os diagramas - é muito mais atraente do que ler um dicionário de dados. A atividade do processo é sua vantagem e acho bastante relaxante fazer isso.

A maior parte do trabalho que faço é em data warehousing, onde bisbilhotar esquemas de banco de dados do sistema de origem é uma atividade essencial. Eu já fiz esse tipo de coisa em várias ocasiões e acho que funciona muito bem.

O Visio pro não é tão caro e o mecanismo de modelagem do Visio permite compartilhar um modelo entre vários diagramas. Como bônus, você pode adicionar chaves estrangeiras ausentes nos diagramas e obter um conjunto útil de documentação para o sistema no final.

Além das idéias de Bill Karwin, sugiro conversar com os usuários - ocasionalmente, os usuários sabem bastante sobre o uso de seu banco de dados, especialmente se fazem algum relatório a partir dele.

Eu lido com um muito feio para o software de um fornecedor, que além de fazer sugestões, não posso fazer muito para mudar isso. Estou sempre pressionando para que as coisas mudem, mas, como está fora do meu controle, estou preso ao lixo.

Uma das coisas que eu rapidamente comecei a usar, já que o banco de dados não tem absolutamente nenhum relacionamento, é uma consulta geral por Nome para o esquema:

--Find Column named like 'blah' in a specific table
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V') AND O.Name like '%TableName%'
ORDER by O.Name

ou

--Find all Columns in DB with name like 'blah'    
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V')
ORDER by O.Name

Como algumas das tabelas têm muitas colunas com nomes inadequados e muitas colunas para procurar, o que eu poderia usar para formar relacionamentos entre as tabelas.

Sei que isso não ajuda muito na parte de redesenho da questão, mas é muito útil para entender e decifrar o esquema ruim.

SchemaCrawler é a minha ferramenta de descoberta de banco de dados que possui alguns recursos que facilitam a exploração de um banco de dados feio. O SchemaCrawler possui uma funcionalidade semelhante a "grep", que permite procurar tabelas e colunas usando expressões regulares. Por exemplo, você pode procurar por tabelas e colunas com "CONTA" como parte do nome, e elas provavelmente estariam relacionadas de alguma forma.

SchemaCrawler também deduz relacionamentos de chave estrangeira, mesmo onde não há chaves estrangeiras. Ele faz isso encontrando "associações fracas" usando convenções de nomenclatura comuns, como tabelas são nomes geralmente plurais, mas nomes de colunas não são e nomes de colunas podem ter um prefixo _ID. Você pode encontrar tabelas relacionadas usando esses relacionamentos inferidos.

Depende de como é feio e de quanto controle você tem sobre o design e o que interage com ele. Tive que interagir com vários bancos de dados feios ao longo dos anos no meu trabalho atual, e aqui está como lidei com eles:

Dados do Funcionário

Existe o banco de dados que contém os dados dos funcionários. É um banco de dados de fornecedores, então não tenho controle sobre ele. Felizmente, não tenho acesso direto a ele. Recebo um despejo de DTS todas as manhãs.

O melhor que consegui gerenciar é escrever um script que limpe a entrada do despejo da manhã (sim, a escolha da palavra foi intencional) e migrá-la para um formato mais útil e trabalhar com os dados limpos.

Mesmo que eu pudesse mudar isso, provavelmente não mudaria - apenas porque há um grande número de outros programas que dependem da configuração do jeito que está, e não posso forçar uma mudança neles.

Dados de treinamento on-line

Isso foi uma bagunça do meu próprio design. Eu o construí recém-saído da faculdade, sem um mentor para me ajudar ... Desde então, tenho corrigido isso um pouco de cada vez. Como eu controlo o único programa que acessa os dados, conforme atualizo partes do site, "atualizarei" a configuração do banco de dados. Escreverei um script de transformação e testarei vigorosamente em uma cópia para garantir que todas as alterações que precisam ser feitas sejam feitas.

Tem sido um processo longo, mas está indo bem.

Dados de treinamento em sala de aula

Meu projeto piloto foi integrar dados de três bancos de dados diferentes, todos projetados de maneira um pouco diferente pelo meu antecessor ... que era um enfermeiro educador que fazia uma ou duas aulas de programação.

Esse tem sido outro processo lento. Desde que eu tenho controle total sobre os programas que acessam os dados, tenho mudado aos poucos, como os dados de treinamento on-line.

Em retrospecto, esse teria sido o principal candidato para começar de maneira limpa ... a visão posterior é sempre 20/20.

No final...

Não sei o quanto isso foi útil e posso elaborar mais (até certo ponto, o legal da empresa yada yada e tudo). A resposta final é "Depende".

Então, depois de ler todas as suas respostas, eu lhe dou as minhas:

Primeiro, procuro a "Tabela principal" e, em seguida, com caneta e papel, começo a mapear as relações com outras tabelas; depois disso, se houver algum código de aplicativo, começo a fazer alguns esboços brutos sobre como os dados fluem.

Depois de ter uma boa imagem de como o db funciona, eu apenas começo a procurar lugares onde mudar as coisas. É isso aí.

Não sei por que, mas prefiro papel do que qualquer software de modelagem de banco de dados.

Por usá-lo por aplicativo externo, você não pode alterar a "interface" do banco de dados. Não sei que tipo de banco de dados você está usando (oracle, mysql, mssql), mas vejo isso como uma das maneiras:

• criando interface de banco de dados usando tipos de objetos como exibição e procedimentos armazenados.
• refatoração passo a passo (normalização, renomeação de campo ...)
• alterando o aplicativo do cliente (se necessário)

Visualizações, procedimentos armazenados ocultam modificações internas nos bancos de dados (alterações).

Além de descobrir a estrutura do banco de dados, descobri que também é importante observar a qualidade dos dados . Depois de entender o significado de cada coluna, você pode procurar por lugares onde existem muitos valores ausentes. À medida que você se familiariza com os dados, também é possível examinar onde existem inconsistências entre os valores em diferentes colunas.

Depende de como você precisa interagir. Para cenários de uso em que o lote é aceitável, muitas vezes achei mais econômico (em termos de tempo de desenvolvimento e, portanto, o custo para o cliente) enviar os dados para uma estrutura mais amigável e trabalhar contra isso.

Se você pode segmentar o problema em problemas nos quais pode envolver seu cérebro, pode atacá-los um de cada vez. Às vezes, apenas o fato de saber que há uma tabela que não está totalmente bagunçada pode fornecer uma vantagem para você trabalhar. Dessa forma, você estende seu "ponto limpo" para abranger mais do banco de dados em pedaços.

Se você possui o Visio (parte do Microsoft Office), pode tentar a função de engenharia reversa . Não é bonito, mas pelo menos lhe dará um começo (a uma fração do custo de ferramentas "reais" como o Rational Rose).

Schema Spy é uma ferramenta muito boa para gerar um ERD.

Bill deu uma excelente resposta. Eu acrescentaria que entraria na interface do usuário como usuário de teste e tentaria entender exatamente o que os usuários fazem com os dados. Isso ajudará você a entender o por trás de alguns dos procs ou design armazenados. Compreender o que os dados significam e para os quais é usado é fundamental para entender um banco de dados.

Se o banco de dados estiver em uma função comercial ou assunto com o qual você geralmente não está familiarizado (digamos, ele faz planejamento de voo e anteriormente trabalhou apenas em aplicativos financeiros), peça aos usuários algum material de leitura sobre o assunto ou vá à biblioteca você mesmo ou pesquise na Internet sobre o assunto. Pergunte aos usuários se há problemas legais ou regulamentares dos quais você precisa estar ciente. Novamente, alguns desses antecedentes podem explicar o que parecem ser escolhas de design estranhas.

Se for um banco de dados de fornecedores (e eu vi alguns realmente ruins), tudo o que você pode fazer é reclamar com o fornecedor.

Para aplicativos construídos internamente, geralmente é preciso alguma instrução para os desenvolvedores e você pode começar a alterar o esquema para melhorar o desempenho. Leva tempo e geralmente é um processo lento.

Na minha experiência, construir um novo banco de dados não é realmente uma opção, pois mover centenas de GBs ou TBs de dados não é tão viável.

Deixá-lo sozinho também geralmente não é uma opção. À medida que a quantidade de dados no banco de dados aumenta, o desempenho fica cada vez pior (concedido quando vejo os problemas, eles geralmente são muito ruins). Eventualmente, os usuários não poderão usar o aplicativo porque o desempenho é muito ruim.

Ah ... o banco de dados feio. Quanto maior a empresa, mais bancos de dados herdados encontraremos.

• Ajustando para desempenho, as pessoas não reclamam desses bancos de dados até encontrarem problemas de desempenho. Portanto, em nossa organização, identificamos consultas individuais e as ajustamos como um patch.
• Limitando os dados agora sabemos onde está o lixo fedido, por isso tente evitar o fluxo de dados através desses bancos de dados. Crie bancos de dados temporários e redirecione seus dados para essas tabelas para começar e use os antigos como despejos de dados.
• Evite acumular dados Arquivar / truncar dados antigos que não são mais necessários. Deve haver uma equipe que decida quanto tempo os dados são necessários em um banco de dados. Depois disso, você pode movê-lo para arquivos simples ou mesmo para unidades de fita.
• Desative gradualmente assim que você conseguir o redirecionamento e o truncamento de dados. Convença as outras equipes a começarem a usar o novo banco de dados.

Nem sempre funciona, mas, se não nos esforçarmos, só vai piorar. Eu tento redesenhar bancos de dados junto com os aplicativos, pode adicionar mais trabalho para mim com a migração de dados, mas o desempenho é um truque de mágica que eu sempre uso.

Boa sorte com sua namorada feia;)

Veja se a opção de uma sessão de Transferência de conhecimento está disponível para você e, se estiver, aproveite ao máximo.

Além disso, muitos DBMS vêm com ferramentas que permitem desenhar / imprimir o esquema do banco de dados com algumas informações úteis (por exemplo, chaves estrangeiras).

Além disso, (roubado do NXC), você pode fazer engenharia reversa do banco de dados por meio de ferramentas como o Visio.

Eu gosto de iniciar um criador de perfil de consulta e observar o que acontece em um sistema de produção. Me dá uma idéia de quais tabelas são 'quentes' e o tipo de consultas que existem contra elas.

Coloque uma cópia de backup em um servidor sandbox e comece a escrever e executar consultas de teste. Eu sempre acho um sistema complexo mais fácil de entender se eu conseguir colocar as mãos nele e não me preocupar em quebrá-lo.

Além disso, eu gosto de abrir o The Daily WTF em uma janela do navegador. Assumir o design de outra pessoa geralmente envolve muitos momentos "Não acredito que eles fizeram {WTF}" e ajuda a ter um lugar para onde as pessoas entendam sua dor.