Data Warehousing eo Desafio de Infra-estrutura
A natureza de um armazém de dados (que é composta principalmente, ou exclusivamente, de dados que vem de outros lugares, outros bancos de dados de aplicativos, e é convertido em um ativo de dados) significa que ele não pode ficar sozinho como uma entidade independente dentro da sua organização.
O crescimento fenomenal da computação distribuída (Internet e intranet, bem como dados de armazenamento de dados internos e externos) resultou em uma mudança fundamental na forma como as aplicações são construídas. Nos velhos dias de mainframes e minicomputadores, um único sistema físico contido em grande parte da infra-estrutura (sistemas, bancos de dados e sistemas de arquivos e comunicações e gerentes de transação operacional).
Com a computação distribuída agora o modelo dominante (mesmo mainframes e minicomputadores são geralmente parte de um ambiente distribuído maior), a infra-estrutura está espalhada por muitas plataformas diferentes em toda a empresa e, possivelmente, fora da sua empresa.
Quando você desenvolver qualquer aplicação ou sistema, seja o armazenamento de dados ou um aplicativo de processamento de transações mais tradicional, você tem dependências significativas em pedaços de o ambiente geral sobre as quais você não tem controle direto. Aqui estão alguns exemplos específicos para o armazenamento de dados:
Você criar um armazém de dados que, com base em requisitos de negócios e políticas de disponibilidade de dados das aplicações, deve ter cerca de 25 gigabytes de novo e dados atualizados extraídos de diversas fontes, todas as noites e enviadas através da rede para a plataforma de hardware em que o armazém de dados está em execução .
Sua infra-estrutura de rede corporativa ainda está subdimensionado. Depois de uma análise adicional, a rede não pode chegar perto de apoiar o rendimento necessário para mover os dados em seu armazém na janela de tempo disponível.
Durante a fase de escopo do projeto de armazenamento de dados, você determina que uma estratégia de impulso para atualizar o armazenamento de dados é o modelo mais adequado a seguir. Para implementar uma estratégia de impulso, porém, você deve modificar cada aplicativo de origem para incluir um código que detecta quando essa aplicação deve empurrar (Enviar) de dados para o data warehouse.
Os aplicativos legados que fornecem dados para o armazém são, infelizmente, tão difícil de entender que uma política de fazer nenhuma alteração, a menos que absolutamente necessário está em vigor para cada aplicação.
Você decidir prosseguir uma solução OLAP relacional (ou ROLAP) e executar uma série de benchmarks contra três SGBD relacionais produtos (RDBMS) para ver qual deles melhor suporte informacional e processamento de suporte à decisão (em vez de processamento de transações).
O produto que realizou mais mal em seus benchmarks é, infelizmente, também o seu padrão corporativo, e qualquer banco de dados relacional instalado em qualquer lugar na sua empresa deve ser desta variedade, não importa como você pretende usá-lo.
Pense conceitualmente (não se preocupar com detalhes de implementação) nos estágios iniciais de um projeto de armazenamento de dados, ou qualquer outro esforço de desenvolvimento de aplicativos - é não só aceitável, é também bons sistemas de prática de desenvolvimento.
Em algum momento, no entanto, você deve considerar hardware, software, custos, orçamento e outros tipos de constrangimentos do mundo real. Antes de iniciar a construção, não se esqueça de considerar tudo o que pode afetar seus projetos e planos para o seu data warehouse.
Este projeto é muito semelhante a construir uma casa. Você segue um processo pelo qual a determinar suas necessidades, e, em seguida, o arquiteto elabora projetos. Os planos destacar os materiais que você precisa para apoiar suas necessidades - garantindo que o produto acabado cumpre a visão estabelecida no início.