Partilhar via


Processamento de transações online contra apoio à decisão

Muitos aplicativos se enquadram nas duas categorias principais de aplicativos de banco de dados:

  • Processamento de transações online (OLTP)

  • Apoio à decisão

As características desses tipos de aplicativo têm um efeito dramático nas considerações sobre o design de banco de dados.

Processamento de transações online (OLTP)

Os aplicativos de banco de dados com processamento de transações online são os melhores para gerenciar dados variáveis. Esses aplicativos normalmente têm muitos usuários que executam transações, ao mesmo tempo em que alteram os dados em tempo real. Embora as solicitações individuais de usuários para obter os dados normalmente façam referência a poucos registros, muitas dessas solicitações são realizada simultaneamente. Exemplos comuns desses tipos de bancos de dados são os sistemas de emissão de passagens áreas e transações bancárias. As principais preocupações desses tipos de aplicativos são a simultaneidade e a atomicidade.

Controles de simultaneidade em um sistema de banco de dados garantem que dois usuários não possam alterar os mesmos dados, ou que um usuário não altere uma parte dos dados antes que o outro usuário tenha terminado. Por exemplo, se você estiver falando com um agente de passagens áreas para reservar o último assento disponível em um vôo e o agente iniciar o processo reserva do assento em seu nome, outro agente não poderá dizer a outro passageiro que o assento está disponível.

A atomicidade garante que todas as etapas em uma transação sejam concluídas com êxito como um grupo. Se qualquer passo falhar, nenhuma outra etapa será concluída. Por exemplo, uma transação bancária pode envolver duas etapas: tirar fundos de sua conta corrente e depositá-los em sua poupança. Se a etapa que retira os fundos de sua conta corrente tiver êxito, você vai querer assegurar-se que os fundos foram depositados em sua poupança ou devolvidos à sua conta corrente.

Considerações sobre o design de processamento de transações online

Os bancos de dados do sistema de processamentos de transações deveriam ser projetados para promover o seguinte:

  • Bom posicionamento de dados

    Os afunilamentos de E/S são uma grande preocupação dos sistemas de OLTP, devido ao número de usuários que modificam dados em todo o banco de dados. Quando projetar um banco de dados, estabeleça prováveis padrões de acesso dos dados e combine os dados que são freqüentemente acessados em simultâneo. Use grupos de arquivos e sistemas de RAID (matriz redundante de discos independentes) para auxiliar.

  • Transações curtas para minimizar bloqueios a longo prazo e melhorar a simultaneidade

    Evite a interação com o usuário durante as transações. Sempre que possível, execute um único procedimento armazenado para processar a transação inteira. A ordem para se referir às tabelas dentro de suas transações podem afetar a simultaneidade. Posicione as referências às tabelas acessadas freqüentemente no final da transação para minimizar a duração que os bloqueios são mantidos.

  • Backup online

    Sistemas de OLTP freqüentemente são caracterizados por operações contínuas cujo tempo de inatividade é mantido em um mínimo absoluto. Quer dizer, operam 24 horas por dia, 7 dias por semana. Embora o Mecanismo de Banco de Dados do SQL Server possa fazer backup de um banco de dados enquanto está sendo usado, programe o processo de backup para ocorrer durante horas de baixa atividade e minimizar os efeitos nos usuários.

  • Normalização excessiva do banco de dados

    Reduza as informações redundantes para aumentar a velocidade de atualizações e melhorar a simultaneidade. Reduzir dados também melhora a velocidade de backups, porque há menos dados para fazer backup.

  • Dados mínimos, sem histórico ou agregados

    Os dados podem ser arquivados em bancos de dados separados ou movidos de tabelas muito atualizadas para tabelas que só contêm dados históricos. Isso mantém as tabelas tão pequenas quanto possível e melhora os tempos de backup e desempenho de consultas.

  • Uso cuidadoso de índices

    Os índices devem ser atualizados toda vez que uma linha é adicionada ou modificada. Para evitar excesso de índices em tabelas muito atualizadas, mantenha os índices restringidos. Use o Orientador de Otimização do Mecanismo de Banco de Dados para criar os seus índices.

  • Configuração de hardware ótima para controlar um grande número de usuários simultâneos e os tempos de resposta rápidos necessários para um sistema de OLTP

Apoio à decisão

Aplicativos de banco de dados de apoio a decisão são ótimos para consultas que não alteram os dados. Por exemplo, uma empresa pode resumir seus dados de vendas periodicamente por data, região de vendas ou produto e armazenar essas informações em um banco de dados separado, que será usado para análise pelo gerenciamento sênior. Para tomar decisões comerciais, os usuários devem poder verificar as tendências de vendas rapidamente examinando dados baseados em vários critérios. Entretanto, eles não precisam alterar esses dados. As tabelas em um banco de dados de apoio à decisão são extremamente indexadas e os dados brutos freqüentemente são pré-processados e organizados, para oferecer suporte aos vários tipos de consultas que serão usadas. Como os usuários não alteram os dados, a simultaneidade e os problemas de atomicidade não são uma preocupação; os dados apenas são alterados periodicamente, por atualizações em massa, realizadas em períodos fora de hora, de pouco tráfego no banco de dados.

Considerações sobre design de apoio à decisão

Os bancos de dados do sistemas de apoio à decisão deveriam ser projetados para promover o seguinte:

  • Indexação pesada

    Sistemas do apoio de à decisão têm pouca necessidade de atualização, porém grandes volumes de dados. Use muitos índices para melhorar o desempenho de consulta.

  • Desnormalização de banco de dados

    Introduza dados pré-agregados ou dados resumidos para atender às necessidades de consultas comuns e melhorar os tempos de resposta de consulta.

  • Utilize um esquema de estrela ou de floco de neve para organizar os dados no banco de dados.