Armazenamento de dados e o 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 de sua organização.
O crescimento fenomenal de computação distribuída (Internet e intranet, bem como os dados de armazenagem de dados internos e externos) resultou em uma mudança fundamental na forma como as aplicações são construídos. Nos velhos tempos 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 em funcionamento).
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, do lado de fora da sua empresa.
Quando você desenvolver qualquer aplicação ou sistema, ou armazenamento de dados ou um aplicativo de processamento de transações mais tradicional, você tem dependências significativos sobre peças do ambiente geral sobre as quais você não tem controle direto. Aqui estão alguns exemplos específicos para o armazenamento de dados:
Você projetar um data warehouse 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 várias fontes, todas as noites e enviados 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 data warehouse, você determinar 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 o código que detecta quando essa aplicação deve empurrar (Enviar) 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 mudança menos que seja 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 você determinar as 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.