SóProvas


ID
191815
Banca
CESGRANRIO
Órgão
ELETROBRAS
Ano
2010
Provas
Disciplina
Banco de Dados
Assuntos

Numa grande multinacional, os dados relativos aos sistemas transacionais são lidos, transformados e carregados para posterior apresentação sob a forma dimensional. O departamento de TI reservou uma área de armazenamento específica às informações lidas e transformadas, denominada staging area. A respeito dessa área de dados, afirma-se que

Alternativas
Comentários
  • (...)Segundo Kimball, a Staging Area é parte do Data Warehouse responsável por receber a extração, transformação e carga (ETL) das informações dos sistemas transacionais legados, para posterior geração dos Data Marts de destino, com as características:

    * A Staging Area é considerada área fora do acesso dos usuários.
    * A Staging Area não deve suportar queries dos Usuários.
    * Ela pode ser composta por flat files (arquivos textos) ou tabelas de banco de dados na terceira forma normal (normalizadas).
     

    Fonte: litolima.wordpress.com/2010/01/13/etl-extracao-transformacao-e-carga-de-dados/

  • Primeiro, vamos à definição de Staging Area(ou ODS), segundo[1]:

    Representa um armazenamento intermediario entre o ambiente operacional e o DW. Nela, os dados são trazidos brutos do ambiente operacional(OLTP) para sofrerem o processo de ETL, e comporem o DW. 

    O ODS pode servir de base para analises do ambiente operativo, pois sua granularidade é normalmente compativel com os sistemas desse ambiente.

    [1] ainda afirma, na pagina 42, q em um primeiro cenario, os dados estao todos dispostos em um ambiente OLTP atual e em producao com as mesmas caracteristicas operacionais da staging area.

    Em um segundo cenario, devemos considerar a existencia de ambientes heterogeneos e com dados em mainframes, por exemplo.

    Neste caso, não podemos trazer os dados no formato original para um banco de dados relacional na staging area, e sim realizar um processo de extração e conversão dos dados do mainframe em flat files.

    Após essa definição, vamos às alternativas:

    a) a staging area armazena os dados exatamente como estão representados no sistema transacional. Errado! Os dados não são exatamente os do ambiente operacional. São compativeis e com as mesmas característica. Além disso, há dados também de servidor de produção, como os flat files gerados pelos mainframes.

    b) as tabelas da staging area não devem sofrer modificações estruturais ao serem carregadas para a presentation area. Errado! Muito pelo contrário. A staging area não eh volatil. Seus dados são armazenados ao longo do tempo e sofre alterações incrementais, podendo, com o decorrer do tempo, se transformar do DW.

    c) os dados aí contidos estão prontos para serem inquiridos para geração de consultas e relatórios gerenciais. Muito errado! Os dados da staging area são dados "sem tratamentos", sujos, com redundâncias que sofrerão um processo de limpeza para integrarem um DW. Por isso, não devem ser usados para consultas e relatorios gerenciais.

    d) os dados, na staging area, podem ser armazenados tanto de forma normalizada como na forma de arquivos flat.

    Correto! A forma normalizada corresponde ao primeiro cenario do comentario acima. E as de arquivo flato, ao segundo cenario.

    e) cada tabela existente na staging area equivale a uma tabela normalizada na presentation area.

    Errada! Usando-se a modelagem dimensional, os dados passam da staging area para a presentation area,  e ficam prontos para serem acessados pelas ferramentas OLAP. Então, da staging area para a presentation area, muita coisa ainda tem q ser feita.

    Fonte:

    [1] Tecnologia e projeto de datawarehouse, 6 Ed., Felipe Neri, editora Etica.

  • "os dados, na staging area, podem ser armazenados tanto de forma normalizada como na forma de arquivos flat." 

    Na boa, eu acho essa afirmação bem estranha. É verdade que em geral um arquivo flat está desnomarlizado, mas isso não é uma regra absuluta..

    Por exemplo,: imagine que um sistema de ETL precise acessar uma base SAP. Mas esse sistema não tem um conector implementato pra acessar diretamente a base SAP. Uma solução muito usada é o proffisiponal SAP criar uma rotina para diariamente disponilizar os arquivos que serão lidos pelos processos ETL. Esse arquivos não precisam ser desnormalizados. Ou seja: dados em arquivos flat não significa que esses dados estarão desnormalizados...