Questão 607114

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2011
• Provas: CESGRANRIO - 2011 - Petrobras - Analista de Sistemas Júnior - Processos de Negócios - 2011
• Disciplina: Banco de Dados
• Assuntos: DW - Data Warehouse

Um dos grandes desafios na construção de bases de dados de data warehouses reside na qualidade dos seus dados. Como esses dados que servem de matéria- -prima para esses repositórios de dados podem ter as mais diversas procedências, vários tipos de problemas precisam ser resolvidos.

Um exemplo da situação acima descrita encontra-se no fato de que os

• A. campos numéricos das bases de dados de origem podem conter dados que não pertençam ao domínio de valores do atributo, por problemas relativos ao endereçamento dos cálculos efetuados pela ferramenta de extração, transformação e carga.
• B. campos que armazenam datas precisam fazer menção à latitude e à longitude onde se encontra a base de dados do data warehouse, sob pena de comprometer o processo de construção de eventuais datamarts em momentos posteriores.
• C. dados que representam medidas que ocorrem em diversas fontes de dados, como um atributo que armazene medições de temperatura de diversas regiões, podem, em algumas bases, se encontrar incompletos, necessitando tratamento.
• D. atributos categóricos, tais como, sexo ou categoria funcional, necessitam, na integração, ser convertidos em valores numéricos, pois ferramentas OLAP possuem limitações quanto ao tratamento de valores de atributos discretos.
• E. identificadores, tais como, atributos-chave de tabelas, podem, no processo de integração, conter valores de chaves primárias inválidas de outras tabelas, indicando problemas de integridade referencial e de unicidade.

Gabarito: C

Comentários

• PROBLEMAS EM DATAWAREHOUSE

  Campo texto em Dimensões e Fatos

  Os campos de texto aberto (como observações, detalhes e etc) podem causar oneração do DW. Esses atributos custam grande espaço de armazenamento na base consolidada, além de tirarem o foco gerencial das informações do DW. Por isso, devemos evitar ao máximo a inclusão desses dados, questionando sempre sua necessidade quando for solicitado.

  Construção do DW pensando apenas em necessidades operacionais

  O DW conceitualmente visa atender desejos estratégicos, pois as necessidades operacionais são essencialmente extraídas pelos próprios sistemas transacionais (OLTP). Construir o DW visando necessidades operacionais impede o real benefício à organização e transforma uma potencial solução em um enorme "elefante branco".

  Utilização de chaves operacionais para junção de Dimensões e Fatos

  Não podemos utilizar chaves das tabelas operacionais para junções entre Dimensões e Fatos. Devemos utilizar as surrogate keys (chaves artificiais ou substitutas) pois só assim é possível tratar dados históricos nas tabelas de Fatos e o versionamento (modificações) dos dados nas Dimensões. Sem as chaves substitutas esse artifício é inviabilizado.

  Modelar o DW com base em uma visão específica ou necessidade pontual

  O DW depois de pronto deve permitir a flexibilização de cruzamento das informações da forma que o usuário, por ventura, necessitar. Por isso, não devemos construir visando uma necessidade pontual ou uma análise única do problema.

  Não manter a conformidade entre Dimensões e Fatos nos diversos Data Marts

  Um grande problema é a falta de conformidade entre dados do DW, causando retrabalho e falta de padronização nas informações apresentadas. Por isso, devemos sempre elaborar a modelagem tendo em vista a reutilização dos objetos nos diferentes Data Marts para que, dessa forma, o projeto tenha eficácia e consistência.

  Negligenciar o versionamento (alterações) dos dados nas Dimensões

  Nos projetos de DW não podemos subestimar a necessidade de armazenar as mudanças dos campos (atributos) das Dimensões. Dizer que os dados nunca vão alterar ou que os usuários nunca precisarão saber das mudanças ocorridas nas informações ao longo do tempo requer ponderação e muito cuidado. Devemos considerar todas as possibilidades – incluindo a mudança de desejo do usuário – e elaborar o projeto (modelagem) de forma que suporte futuras alterações na estrutura do DW com o menor impacto possível.