DW, modelagem e ETL

Aula 01
Business Intelligence para Concursos - Curso Regular

Professor: Thiago Rodrigues Cavalcanti
DW, ETL e Data Mart

Prof. Thiago Rodrigues Cavalcanti Aula 01
AULA 01: Data Warehouse, Modelagem

multidimensional e ETL
Sumrio
Data Warehouse ............................................................................................................................... 1
1.
DW ......................................................................................................................................... 1
1.1.
Conceitos e caractersticas ....................................................................................... 1
1.2.
Tipos de DW ................................................................................................................... 5
1.3.
Processo de DW ............................................................................................................ 7
1.4.
Arquitetura de DW ....................................................................................................... 8
1.5.
Kimball x Inmon.......................................................................................................... 11
2.
Modelagem multidimensional .................................................................................... 12
2.1.
Star Schema ................................................................................................................. 14
2.2.
Processo de design dimensional ........................................................................... 16
2.3.
Revisitando o modelo ............................................................................................... 18
2.4.
Esquemas multidimensionais ................................................................................. 24
3.
ETL ....................................................................................................................................... 25
3.1.
Componentes de ETL ................................................................................................ 26
3.2.
Processo de ETL .......................................................................................................... 30
Questes comentadas .............................................................................................................. 31
Questes extras .......................................................................................................................... 40
Consideraes Finais ..................................................................................................................... 50
Data Warehouse
1. DW
Nosso objetivo nesta aula tratar dos conceitos de Data Warehouse (DW)
e ETL. Comearemos pelos aspectos do DW e logo em seguida examinaremos as
especificidades relacionadas ETL.
16712855225
1.1. Conceitos e caractersticas

Vamos apresentar a definio de DW de trs diferentes autores:
Kimball: um conjunto de ferramentas e tcnicas de projeto, que quando

aplicadas s necessidades especficas dos usurios e aos bancos de dados
especficos permitir que planejem e construam um Data Warehouse.
Laudon&Laudon: Banco de dados, com ferramentas de consulta e

relatrio, que armazena dados atuais e histricos extrados de vrios
sistemas operacionais e consolidados para fins de analises e relatrios
administrativos.
Prof. Thiago Rodrigues Cavalcanti
www.estrategiaconcursos.com.br
1 de 50
DW, ETL e Data Mart

Inmon: uma coleo de dados orientados por assunto, integrados,

variveis com o tempo e no volteis, para dar suporte ao processo de
tomada de deciso.
Um primeiro comentrio interessante sobre essas definies, em especial

sobre as definies do Inmon e do Kimball, perceba que o Kimball apresenta
dentro do conceito um conjunto de ferramentas e tcnicas, ou seja, o processo
de estruturar um banco de dados conhecido como DW incluso dentro da
definio. Inmon, por sua vez, considera apenas a coleo de dados.
A ltima definio acima traz consigo quatro caractersticas que so de
suma importante para o entendimento do assunto. Juntam-se a elas a
granularidade e a credibilidades dos dados. Essas caractersticas precisam ser
entendidas para a compreenso do assunto.
Ser orientado por assunto refere-se ao fato do Data Warehouse

armazenar informaes sobre temas especficos importantes para o negcio
da empresa. So exemplos tpicos de temas: produtos, atividades, contas,
clientes. Em contrapartida, quando observamos o ambiente operacional
percebemos que ele organizado por aplicaes funcionais. Por exemplo, em
uma organizao bancria, estas aplicaes incluem emprstimos, investimentos
e seguros. Observe um exemplo na figura abaixo retirada do livro do Inmon.
16712855225
2 de 50
DW, ETL e Data Mart

Ser integrado refere-se consistncia de nomes, das unidades, das
variveis, etc. importante que os dados armazenados sejam transformados
at um estado uniforme. Por exemplo, considere sexo como um elemento de
dado. Uma aplicao pode codificar sexo como M/F, outra como 1/0 e uma
terceira como H/M. Conforme os dados so inseridos ou repassados para o Data
Warehouse, eles so convertidos para um mesmo padro. O atributo Sexo,
portanto, seria codificado apenas de uma forma.
Da mesma maneira, se um elemento de dado medido em centmetros
em uma aplicao, em polegadas em outra, ele ser convertido para uma
representao nica ao ser colocado no Data Warehouse. Vejam na figura abaixo
a ideia por traz do conceito de integrao.
O fato de ser no voltil significa que o Data Warehouse permite apenas

a carga inicial dos dados e consultas a estes dados. Aps serem integrados e
transformados, os dados so carregados em bloco para o Data Warehouse, para
que estejam disponveis aos usurios para acesso.
16712855225
No ambiente operacional, ao contrrio, os dados so, em geral,

atualizados registro a registro, em mltiplas transaes. Esta volatilidade requer
um trabalho considervel para assegurar integridade e consistncia atravs de
atividades de rollback, recuperao de falhas, commits e bloqueios. Vejam
abaixo uma figura que representa os diferentes ambientes e suas respectivas
operaes sobre os dados.
3 de 50
DW, ETL e Data Mart

Ser variante no tempo trata do fato de um registro em um Data

Warehouse referir-se a algum momento especfico, significando que ele no
atualizvel. Enquanto que o dado de produo atualizado de acordo com
mudanas de estado do objeto em questo, refletindo, em geral, o estado do
objeto no momento do acesso, em um DW, a cada ocorrncia de uma mudana,
uma nova entrada criada para marcar esta mudana.
O tratamento de sries temporais apresenta caractersticas especficas,
que adicionam complexidade ao ambiente do Data Warehouse. Deve-se
considerar que no apenas que os dados tenham uma caracterstica temporal,
mas tambm os metadados, que incluem definies dos itens de dados, rotinas
de validao, algoritmos de derivao, etc. Sem a manuteno do histrico dos
metadados, as mudanas das regras de negcio que afetam os dados no Data
Warehouse so perdidas, invalidando dados histricos.
Vejam na figura abaixo uma comparao entre os ambientes operacional
e analtico no que se refere a variao dos dados ao longo do tempo.
16712855225
A prxima caracterstica que temos nos DW o tratamento da

granularidade dos dados. A granularidade de dados refere-se ao nvel de
sumarizao dos elementos e de detalhe disponveis nos dados, considerado o
mais importante aspecto do projeto de um Data Warehouse. Em um nvel de
granularidade muito alto, o espao em disco e o nmero de ndices necessrios
4 de 50
DW, ETL e Data Mart

se tornam bem menores, h, porm, uma diminuio da possibilidade de
utilizao dos dados para atender a consultas detalhadas.
Em outras palavras a granularidade diz respeito ao nvel de detalhe ou de
resumo contido nas unidades de dados existentes no DW. Quanto maior o nvel
de detalhes, menor o nvel de granularidade. O nvel de granularidade afeta
diretamente o volume de dados armazenado no DW e ao mesmo tempo o tipo
de consulta que pode ser respondida.
Resumo: Requisitos e princpios que orientam um projeto de DW

DW: Organizados em assuntos
DW: capacidade de integrao
DW: deve ser flexvel o suficiente para atender s
exigncias de mudana rapidamente.
Dados: considerados no volteis e deve ser carregado em
massa.
Dados: existem em vrios nveis de granularidade.
1.2. Tipos de DW
A indstria atualmente reconhece pelo menos trs tipos diferentes de
Data Warehouses: Data Mart (DM), Data Warehouse Empresarial (EDW) e
Armazenamento de Dados Operacionais (ODS).
O qualificador "Empresarial" implica em ser grande e abrangente. Esta a
ideia tradicional de um armazm de dados. Algumas organizaes nunca vo
conseguir concluir um projeto de EDW, pois ele requer um compromisso enorme
de recursos. Ainda assim, se bem feito, um sistema abrangente acrescenta
toneladas de valor e produz um retorno considervel sobre o investimento.
conveniente, por vezes, a criao de uma coleo menor de dados
conhecida como Data Mart. Esta tem um pblico mais focado e normalmente
consiste em um subconjunto do EDW. Esse subconjunto pode ser definido pela
geografia (por exemplo, apenas os dados da Alemanha), linha de produtos (por
exemplo, apenas produtos para os cabelos), ou rea funcional (por exemplo, de
fabricao).
16712855225
O armazenamento de dados operacionais (ODS) se concentra em um

prazo mais curto para a anlise e assim um subconjunto definido por tempo
(por exemplo, apenas os dados desta semana). H um processo bem definido
para a criao e manuteno de um armazm de dados. Falaremos sobre ele
mais adiante neste curso.
Considerando que um armazm de dados combina bases de dados de
toda a empresa, um Data Mart (DM) geralmente menor e se concentra em um
5 de 50
DW, ETL e Data Mart

assunto ou departamento especfico. Um DM um subconjunto de um armazm
de dados, geralmente constitudos por uma nica rea temtica (por exemplo,
marketing, operaes).
O DM pode ser dependente ou independente. Ser dependente ser um
subconjunto que criado diretamente a partir do armazm de dados. Tem as
vantagens de usar um modelo de dados consistente e o fornecimento de dados
de qualidade. DM dependentes apoiam o conceito de um nico modelo de dados
em toda a empresa, mas o data warehouse deve ser construdo primeiro. O DM
dependente garante que o usurio final est vendo a mesma verso dos dados
que acessada por todos os outros usurios de data warehouse. O alto custo de
dados armazns limita seu uso para grandes empresas. Como uma alternativa,
muitas empresas usam uma verso em escala reduzida de um armazm de
dados referida como uma DM independente.
Um Data Mart independente um pequeno armazm concebido para
uma unidade estratgica de negcios ou um departamento, mas sua origem no
um EDW. Percebam que o DM tem como sua principal caracterstica o escopo
reduzido do projeto.
Outra definio importante para Data Mart vem do Date. Ele diz que um
Data Mart deve ser especializado e voltil. Por especializado queremos dizer que
ele possui uma estrutura baseada em um ambiente, tema, situao, rea, setor
ou aplicao especfica. Enquanto o EDW se baseia em vrias fontes de diversas
aplicaes, fontes e situaes para facilitar um suporte a deciso gerencial.
Quando falamos de voltil, segundo o Date, ele quer transmitir que os
dados so alterados frequentemente. Enquanto os dados do DW, por guardarem
histrico, s so alterados quando uma carga foi feita de forma errada, o DM por
ser baseado em aplicaes so mais frequentemente modificados.
O armazenamento de dados operacionais (ODS) fornece uma forma
relativamente recente dos arquivos de informaes dos clientes. Este tipo de
banco de dados muitas vezes usado como uma rea de estgio provisrio para
um data warehouse. Ao contrrio dos contedos estticos de um armazm de
dados, o contedo de um ODS atualizado durante todo o curso das operaes
de negcios.
16712855225
Um ODS usado para decises de curto prazo envolvendo aplicaes de

misso crtica, para o mdio e longo prazo as decises devem estar associadas
com o EDW. O ODS semelhante memria de curto prazo, na medida em que
armazena apenas as informaes mais recentes. Em comparao, um armazm
de dados como uma memria de longo prazo, porque ele armazena
informaes permanentes.
O EDW por sua vez um DW de larga escala usado pela organizao
como um todo. Congrega informaes de diversas fontes de dados. Vejam na
6 de 50
DW, ETL e Data Mart

figura a seguir uma hierarquia dos diferentes tipos de DW e sua relao com as
demais bases existentes dentro de uma organizao.
1.3. Processo de DW
Apresentamos abaixo uma figura que descreve o processo de DW/BI. Essa
figura exibe os componentes que fazem parte do sistema. Vejamos a descrio
sucinta de cada um deles.
16712855225
As fontes de dados (Data source) - Os dados so provenientes de vrios

sistemas operacionais "legados" independentes e, possivelmente, a partir de
provedores de dados externos. Os dados tambm podem vir de um
7 de 50
DW, ETL e Data Mart

processamento de transaes online (OLTP) ou sistema de ERP. Dados da Web
na forma de logs tambm podem alimentar um data warehouse.
Extrao e transformao de dados. (Data extraction and transformation)
- Os dados so extrados e devidamente transformados usando software
personalizado ou comercial chamado de ferramenta de ETL.
Carregamento dos dados. (Data loading) - Os dados so carregados para
uma rea de preparao (staging area), onde eles so transformados e limpos.
Os dados esto, ento, prontos para serem carregado no data warehouse e/ou
data marts.
Banco de dados abrangente. - Essencialmente, este o EDW para apoiar
todas as anlises de suporte deciso, fornecendo uma viso resumida
relevante e informaes detalhadas proveniente de fontes diferentes.
Metadados. - Os metadados so mantidos de forma a que possam ser
avaliados por diferentes pessoas e usurios de TI. Metadados incluem programas
sobre os dados e as regras para a organizao de resumos de dados que so
fceis de indexar e pesquisar, especialmente com as ferramentas da Web.
Ferramentas de middleware. - Ferramentas de middleware habilitam o
acesso ao DW. Usurios avanados, como os analistas de BI, podem escrever
suas prprias consultas SQL. Outros podem empregar um ambiente gerenciador
de consulta, como Business Objects, para acessar os dados. Existem muitas
aplicaes front-end que os usurios podem usar para interagir com os dados
armazenados nos repositrios de dados, incluindo a minerao de dados, OLAP,
ferramentas de relatrios e ferramentas de visualizao de dados.
1.4. Arquitetura de DW
H algumas arquiteturas bsicas de DW. As arquiteturas de 2 e 3
camadas so mais comuns. Hoffer as distingue dividindo o DW em trs partes:
1. O prprio DW, que contm os dados e o software associados, 2. Software de
aquisio de dados (retaguarda), que extrai dados de sistemas legados e fontes
externas, os consolida e resume, e depois os carrega e 3. Software cliente
(front-end), que permite aos usurios acessar e analisar dados a partir do DW.
16712855225
H quatro componentes separados e distintos a serem considerados no

ambiente de DW/BI: Sistemas operacionais de origem, Sistema de ETL, rea de
apresentao de dados e Aplicaes de business intelligence.
Quando juntamos
arquitetura temos:
os
componentes
dentro
das
8 de 50
trs
camadas
da
DW, ETL e Data Mart

1. Sistemas operacionais de origem + Sistema de ETL = Primeira
camada: sistema operacional com os dados e o software para
aquisio.
2. rea de apresentao de dados - Segunda camada: data warehouse.
3. Aplicaes de BI - Terceira camada: servidor de aplicao e cliente.
A figura a seguir mostra os diferentes tipos de arquitetura para sistemas
de DW. Em seguida apresentaremos as definies relacionadas cada uma
delas.
16712855225
Data Marts (DM) independentes. Esta sem dvida a arquitetura mais

simples e menos onerosa. Os DM so desenvolvidos para operar de forma
independente visando atender s necessidades das unidades organizacionais
individuais. Por causa da independncia, eles podem ter definies de dados
inconsistentes, diferentes dimenses e medidas, o que torna difcil analisar os
dados atravs dos Data Marts.
Arquitetura de barramento de Data Mart (KIMBALL). Esta
arquitetura uma alternativa vivel para os data marts independentes. Nela os
Data Marts individuais so ligadas entre si atravs de algum tipo de middleware.
9 de 50
DW, ETL e Data Mart

Como os dados so ligados entre os DM individuais, h uma melhor chance de
manter a consistncia entre os dados de toda a empresa (pelo menos no nvel
de metadados). Mesmo que se permita que consultas complexas utilizem dados
de diversos DMs, o desempenho destes tipos de anlise pode no ser
satisfatrio.
Hub-and-spoke (Inmon). Esta talvez a mais famosa de arquitetura de
DW. Aqui, a ateno est focada na construo de uma infraestrutura escalvel
e sustentvel (muitas vezes desenvolvidas de forma iterativa, assunto por
assunto) que inclui um data warehouse centralizado e vrios data marts
dependentes (um para cada unidade organizacional). Esta arquitetura permite
uma customizao fcil de interfaces de usurio e relatrios. No lado negativo,
esta arquitetura no tem a holstica, e pode levar a redundncia e a latncia de
dados. A latncia dos dados refere-se ao tempo mximo permitido para
disponibilizao dos dados atravs do sistema de BI.
Data warehouse centralizado. A arquitetura centralizada de data
warehouse similar arquitetura hub-and-spoke, exceto que no h Data Marts
dependentes, em vez disso, h um data warehouse da empresa inteira que
serve para a necessidade de todas as unidades organizacionais. Esta abordagem
centralizada fornece aos usurios acesso a todos os dados no warehouse em vez
de limitar-lhes a DM de dados. Adicionalmente, reduz-se a quantidade de dados
que a equipa tcnica tem de transferir, portanto, simplifica-se o gerenciamento e
administrao de dados. Se projetado e implementado corretamente, essa
arquitetura oferece uma viso oportuna e holstica da empresa quem, quando e
onde quer que esteja dentro da organizao. A arquitetura de armazns de
dados central, que defendida principalmente pela Teradata Corporation,
aconselha usar armazns de dados sem data marts.
Armazm de dados federado. A abordagem federada uma concesso
as foras naturais que minam os melhores planos para o desenvolvimento de um
sistema perfeito. Ela usa todos os meios possveis para integrar recursos
analticos de vrias fontes para atender evoluo das necessidades e condies
do negcio. Essencialmente, a abordagem envolve a integrao de sistemas
distintos. Em uma arquitetura federada de apoio deciso, estruturas existentes
so deixadas no lugar, e os dados so cedidos a partir dessas fontes, conforme
necessrio. A abordagem federada suportada por fornecedores de middleware
distribudos que propem consultar e juntar capacidades. Estas ferramentas
baseadas em eXtensible Markup Language (XML) oferecem aos usurios uma
viso global das fontes de dados distribudas, incluindo armazns de DM, sites,
documentos e sistemas operacionais.
16712855225
Quando os usurios escolherem objetos de consulta a partir deste ponto

de vista e pressionarem o boto de enviar, a ferramenta de consulta
automaticamente junta os resultados das fontes distribudas, e apresenta-os ao
usurio. Devido a questes de desempenho e qualidade de dados, a maioria dos
10 de 50
DW, ETL e Data Mart

especialistas concorda que os armazns de dados federados devem trabalhar
bem de forma complementar aos data warehouses, e no os substituir.
1.5. Kimball x Inmon

Considerados os dois principais autores de Data Warehoure, Bill Inmon e
Ralph Kimball travam h dcadas uma batalha terica no campo de BI.
Ralph Kimball um defensor da teoria de que o DW deve ser dividido para
depois ser conquistado, ou seja, que o mais vivel para as empresas
desenvolver vrios Data Marts para posteriormente integr-los e, assim, chegarse ao EDW. Na sua avaliao, as empresas devem construir Data Marts
orientados por assuntos. Ao final, teramos uma srie de pontos de conexo
entre eles, que seriam as tabelas Fato e Dimenses em conformidade. Dessa
forma, informaes entre os diferentes Data Marts poderiam ser geradas de
maneira ntegra e segura. Kimball batizou esse conceito de Data Warehouse Bus
Architeture.
Bill Inmon rebate essa teoria e prope justamente o contrrio. Na sua
avaliao deve-se construir primeiramente um Data Warehouse, modelando toda
a empresa para se chegar a um nico modelo corporativo, partindo
posteriormente para os Data Marts construdos por assuntos ou departamentais.
Inmon defende a ideia de que o ponto de partida seriam os CIF Corporate
Information Factory uma infraestrutura ideal para ambientar os dados da
empresa. O CIF seria alimentado pelos sistemas transacionais. A construo de
um ODS (Operational Data Store) seria facultativa, mas essa iniciativa ajudaria a
reduzir a complexidade da construo de um DW, uma vez que todo o esforo de
integrao entre os sistemas transacionais da empresa seria depositado nele.
Inmon considerado o pai do conceito de DW e sustenta a tese de que a
melhore estratgia seria a construo de um DW de forma TOP-DOWN. A sua
nfase sempre foi em um grande depsito central de informaes. O Kimball
considerado o criador do conceito de star schema. Ele prope uma abordagem
BOTTOM-UP para construo do DW, sendo considerado um estilo mais simples
com uma abordagem incremental. Vejam na figura abaixo a diferena entre as
duas arquiteturas. A esquerda temos a abordagem do Kimball e a direita do
Inmon. Veja que TOP-DOWN termina com N assim como Inmon. Apenas uma
dica para memorizao da diferena entre os modelos.
16712855225
11 de 50
DW, ETL e Data Mart

2. Modelagem multidimensional
Um modelo dimensional contm as mesmas informaes que um modelo
normalizado. Os pacotes de dados oferecem um formato com as seguintes
preocupaes: facilidade de compreenso ao usurio, desempenho da consulta e
resilincia s mudanas.
Imagine um executivo que descreve o seu negcio como, "Ns vendemos
produtos em vrios mercados e medimos o nosso desempenho ao longo do
tempo." Projetistas multidimensionais devem ouvir atentamente a nfase no
produto, mercado e tempo.
A modelagem multidimensional, ou dimensional como s vezes
chamada, a tcnica de modelagem de banco de dados para o auxlio s
consultas em um Data Warehouse nas mais diferentes perspectivas. A viso
multidimensional permite o uso mais intuitivo para o processamento analtico
pelas ferramentas OLAP (On-line Analytical Processing).
Toda modelagem dimensional possui dois elementos imprescindveis: as
tabelas Fatos e as tabelas Dimenses. Ambas so obrigatrias e possuem
caracterstica complementares dentro de um Data Warehouse. As Dimenses so
os descritores dos dados oriundos das tabelas Fato. Possui o carter qualitativo
da informao e relacionamento de um para muitos com a tabela Fato. a
Dimenso que permite a visualizao das informaes por diversos aspectos e
perspectivas.
16712855225
As tabelas Fato servem para o armazenamento, medidas (quase sempre)

numricas associadas a eventos de negcio. Uma tabela fato armazena as
medies de desempenho decorrentes de eventos dos processos de negcios de
uma organizao. Basicamente representa uma medida de negcios. Uma tabela
fato contm vrios fatos, correspondentes a cada uma das suas linhas. Cada
linha corresponde a um evento de medio. Os dados em cada linha esto a um
nvel especfico de detalhe, referido como o gro, por exemplo, uma linha por
produto vendido numa operao de venda.
12 de 50
DW, ETL e Data Mart

Uma nica linha da tabela fato tem uma relao um-para-um com o
evento de medio, como descrito pela granularidade da tabela fato. Uma tabela
fato corresponde a um evento fsico observvel, e no s exigncias de um
relatrio especfico. Dentro de uma tabela fatos, apenas fatos consistentes com
a granularidade definida so permitidos. Por exemplo, em uma transao de
vendas no varejo, a quantidade de um produto vendido e seu preo so bons
fatos. Veja a figura abaixo que representa uma tabela fato de vendas:
A ideia de que um evento de medio no mundo fsico tenha uma relao

de um-para-um com uma nica linha na tabela fato um princpio fundamental
para a modelagem dimensional. Tudo o resto constri a partir desta fundao.
Voc vai ver que os fatos so, por vezes aditivos, semi-aditivos ou mesmo noaditivos.
Fatos semi-aditivos, tais como saldos de conta, no podem ser resumidos
por meio da dimenso de tempo. Fatos no-aditivos, tais como preos unitrios,
nunca podem ser adicionados. teoricamente possvel que um fato medido seja
textual, no entanto, essa condio raramente aparece.
Na maioria dos casos, uma medio textual uma descrio de algo, e
traada a partir de uma lista de valores discretos. O designer deve fazer todos
os esforos para colocar os dados textuais em dimenses onde podem ser
correlacionadas de forma mais eficaz com os outros atributos de dimenso e
consumirem menos espao em disco.
Voc no deve armazenar informaes textuais redundantes em tabelas
de fatos. A menos que o texto seja exclusivo para cada linha na tabela de fato,
ele deve pertencer a tabela de dimenso. Um fato texto verdadeiro raro,
porque o contedo do fato imprevisvel, como um texto de comentrio de forma
livre, faz com que seja quase impossvel de se analisar.
16712855225
Todas as tabelas fato tm duas ou mais chaves estrangeiras que ligam

para as chaves primrias das tabelas de dimenso. Por exemplo, a chave do
produto na tabela coincide com o fato de sempre uma chave de produto
especfico na tabela de dimenso de produto. Quando todas as chaves na tabela
fato corretamente coincidirem com suas respectivas chaves primrias das
tabelas dimenso correspondentes, as tabelas satisfazem a integridade
referencial. Voc pode acessar a tabela de fatos atravs das tabelas de
dimenses por meio de join.
13 de 50
DW, ETL e Data Mart

As tabelas dimenses apresentam o contexto descritivo. So
companheiros integrais para uma tabela de fatos e contm o contexto textual
associado a um evento de medio dos processos de negcios. Elas descrevem o
"quem, o que, onde, quando, como e porqu" associado ao evento.
As dimenses contm os atributos descritivos usados pelas aplicaes de
BI para filtrar e agrupar os fatos. Com a granularidade de uma tabela de fato
definida, todas as possveis dimenses podem ser identificadas. Sempre que
possvel, a dimenso deve ter um valor nico associado a uma determinada
linha da tabela fato. Tabelas dimenso so chamadas a "alma" do DW, pois elas
contm os pontos de entrada e rtulos descritivos que permitem ao sistema de
DW/BI ser aproveitado para a anlise de negcios.
Um esforo necessrio para o desenvolvimento e o gerenciamento das
tabelas de dimenso, pois elas so os condutores da experincia de BI do
usurio. Dimenses fornecem os pontos de entrada para os dados, e as
etiquetas finais e os agrupamentos em todas as anlises de DW/BI. Vejam um
exemplo de uma tabela dimenso abaixo.
Ok! Antes de continuarmos nosso estudo e juntarmos as tabelas

dimenses e fatos vamos refletir sobre a seguinte pergunta: Uma quantidade
numrica um fato ou um atributo de dimenso? Geralmente a resposta a esse
questionamento segue a seguinte lgica: observaes numricas continuamente
valorizadas so quase sempre medidas da tabela fato; e observaes numricas
discretas e extradas de uma lista pequena, quase sempre so atributos de
dimenso.
16712855225
2.1. Star Schema

Cada processo de negcio representado por um modelo dimensional que
consiste em uma tabela fato contendo medies numricas do evento e, cercada
por um conjunto de tabelas dimenso que contm o contexto no momento em
que ocorreu o evento. Esta caracterstica de estrutura estrela (star schema)
muitas vezes chamada de juno estrela (star-join), um termo que remonta aos
primrdios de bancos de dados relacionais. Vejamos um exemplo de um modelo:
14 de 50
DW, ETL e Data Mart

A primeira coisa a notar sobre o esquema dimensional a sua

simplicidade e simetria. Obviamente, os usurios de negcios se beneficiam da
simplicidade, pois os dados so mais fceis de compreender e navegar. O
charme do desenho na figura acima que altamente reconhecvel para
usurios corporativos. Segundo Kimball: Temos observado, literalmente,
centenas de casos em que os usurios imediatamente concordam que o modelo
dimensional o seu negcio.
Alm disso, a reduo do nmero de tabelas e de a utilizao de
descries gerenciais torna-o mais fcil de navegar e menos suscetvel a erros. A
simplicidade de um modelo multidimensional tambm tem benefcios de
desempenho. Otimizadores de banco de dados processam esses esquemas de
forma mais simples, com menos joins e portanto de forma mais eficiente.
Um motor de banco de dados pode fazer suposies fortes sobre a
primeira restrio das tabelas de dimenso que so fortemente indexadas e, em
seguida, atacar a tabela de fatos de uma s vez com o produto cartesiano das
chaves das tabelas dimenses que satisfazem as restries do usurio.
Surpreendentemente, usando essa abordagem, o otimizador pode avaliar
arbitrariamente uma juno para uma tabela fato em uma nica passagem
atravs do ndice da tabela fato.
Finalmente, os modelos dimensionais so graciosamente extensveis para
acomodar a mudana. O framework previsvel de um modelo dimensional resiste
a mudanas inesperadas no comportamento do usurio. Vejam um exemplo de
um relatrio simples, gerado por meio de uma consulta SQL a um modelo.
16712855225
15 de 50
DW, ETL e Data Mart

2.2. Processo de design dimensional

O processo de desenvolvimento ou projeto de sistemas multidimensionais
segue basicamente quatro etapas: Selecionar o processo de negcio, Definir a
granularidade, Identificar as dimenses e Identificar os fatos. Esse processo
alimentado por informaes a respeito dos requisitos de negcio e da realidade
dos dados. Vamos ento passar pelas etapas e entender o que deve ser
realizado em cada uma delas.
Passo 01: Selecionando o processo de negcio
O primeiro passo decidir o processo de negcio para o modelo,
combinando a compreenso dos requisitos de negcio com a anlise dos dados
de origem disponveis. O primeiro projeto de BI/DW deve se concentrar no
processo de negcio que o mais crtico para os usurios de negcios
A viabilidade do projeto abrange uma srie de consideraes, incluindo a
disponibilidade e qualidade dos dados, e ainda a capacidade organizacional.
Suponha que os gestores querem entender melhor as compras dos clientes e o
processo de negcio que voc est modelando baseado nas transaes de
vendas de varejo. Esta informao permite que os usurios de negcios
analisem, por exemplo, quais produtos esto vendendo em que as lojas em que
dias em quais condies promocionais.
16712855225
Passo 02: Declare a granularidade

Declarar a granularidade um passo fundamental em um projeto
dimensional. Estabelece exatamente o que uma nica linha da tabela fato
representa. Torna-se um contrato vinculativo sobre o design. Deve ser declarada
antes de escolher dimenses ou fatos, porque cada dimenso candidata ou fato
relevante deve ser consistente com a granularidade.
16 de 50
DW, ETL e Data Mart

A atomicidade do gro refere-se ao nvel mais baixo no qual os dados so
capturados por um determinado processo de negcio. Kimball encoraja a
comear pelos dados de gros atmicos, porque resiste ao ataque de consultas
de usurios imprevisveis. A sumarizao realizada pela operao de roll-up
importante para o ajuste de desempenho, mas ela pressupe perguntas comuns
do negcio. Cada proposta de granularidade da tabela fato resultada em uma
tabela fsica separada, diferentes granularidades no devem ser misturadas na
mesma tabela fato.
Mas qual o nvel de detalhe dos dados que devem ser disponibilizados no
modelo dimensional? Voc deve desenvolver modelos dimensionais que
representem as informaes mais detalhadas, atmicas capturadas por um
processo de negcio. Um sistema de DW/BI exige quase sempre os dados
expressos no mais baixo possvel de granularidade. No porque as consultas
querem ver linhas individuais, mas porque as consultas precisam cortar os
detalhes de formas muito precisas.
Passo 03: Identificando as dimenses
Aps a granularidade da tabela fato ter sido escolhida, a escolha das
dimenses simples. A declarao cuidadosa da granularidade determina a
dimenso primria da tabela fato. Em seguida, adiciona-se mais dimenses para
a tabela fato, se essas dimenses adicionais tiverem apenas um valor para cada
combinao das dimenses principais.
Se a dimenso adicional viola a granularidade, fazendo com que linhas
adicionais da tabela fato sejam geradas, a dimenso precisa ser desclassificada
ou a granularidade precisa ser revista. Algumas dimenses descritivas
geralmente se aplicam a um modelo de loja: data, produto, loja, promoo,
caixa, e forma de pagamento. Alm disso, o nmero do bilhete da transao
includo como uma dimenso especial, dita dimenso degenerada para nmeros
de transao.
Mas o que seria uma dimenso degenerada? Uma chave de dimenso,
como o nmero de uma transao, nmero de fatura ou de ticket que no tenha
nenhum atributo associado, portanto no se constitui com uma tabela de
dimenso. Ela aparece apenas como uma das colunas da tabela fato.
16712855225
Passo 04: Identificando os fatos

A quarta e ltima etapa do projeto a determinao cuidadosa dos fatos
que aparecero na tabela fato. Mais uma vez, a declarao de granularidade
ajuda a ancorar o raciocnio. Ao considerar os fatos em potencial, voc pode
descobrir novamente ajustes precisam serem feitos tanto na granularidade
quanto na escolha das dimenses.
Os dados coletados pelo sistema incluem, por exemplo, a quantidade de
vendas por unidade regular, o desconto, preos lquidos pagos, valores de
vendas em dlares. O valor de vendas igual a quantidade de vendas
17 de 50
DW, ETL e Data Mart

multiplicado pelo preo unitrio. Da mesma forma, o valor do desconto a
quantidade de vendas multiplicada pelo valor do desconto unitrio.
2.3. Revisitando o modelo

Vamos agora revisitar as estruturas das tabelas fato e dimenses para
entender alguns conceitos relacionados com cada uma delas. Primeiramente
comearemos pelas tabelas fatos.
Uma tabela fato contm as medidas numricas produzidas por um evento
de medio operacional no mundo real. No nvel mais baixo de granularidade,
uma linha da tabela fato corresponde a um evento de medio (fato) e viceversa.
Alm das medidas numricas, uma tabela fato sempre contm chaves
estrangeiras para cada uma das suas dimenses associadas, bem como as
chaves de dimenso degenerados opcionais. As tabelas fatos so o principal alvo
de computaes e agregaes dinmicas decorrentes das consultas.
As medidas numricas em uma tabela de fatos podem ser dividas em trs
categorias. Os fatos mais flexveis e teis so totalmente aditivos. Medidas
aditivas podem ser agrupadas com qualquer das dimenses associadas tabela
de fatos. Medidas semi-aditivas podem ser agrupadas em algumas dimenses,
mas no todas. Valores de saldo so fatos comuns semi-aditivos, porque eles
so aditivos em todas as dimenses, exceto tempo. Finalmente, algumas
medidas so completamente no-aditivas, como ndices.
Medidas com valores nulos se comportam normalmente em tabelas
de fatos. As funes de agregao (SUM, COUNT, MIN, MAX e AVG) todas
fazem a "coisa certa" com fatos nulos. No entanto, os valores nulos devem
ser evitados em chaves estrangeiras da tabela de fatos, porque esses
valores nulos iriam provocar automaticamente uma violao de integridade
referencial. Ao invs de uma chave estrangeira nula, a tabela de dimenso
associado deve ter uma linha padro (com uma surrogate key) que
representa a condio desconhecida ou no aplicvel.
16712855225
Se a mesma medida aparece em tabelas fatos separados, os

cuidados devem ser tomados para garantir que as definies tcnicas dos fatos
so idnticas, se elas podem ser comparadas ou calculadas juntas. Se as
definies de fato separadas so consistentes, os fatos devem ser conformados
com nomes idnticos, mas se eles so incompatveis, devem ser nomeados de
forma diferente para alertar os usurios de negcios e aplicaes de BI.
Vamos agora falar dos tipos de tabelas fatos: tabela fato de transaes
(Transaction Fact Tables), tabela de snapshot peridicos e tabela de snapshot
acumulativos.
A linha em uma tabela de fatos de transaes corresponde a um evento
de medio em um ponto no espao e no tempo. As tabelas fato de
18 de 50
DW, ETL e Data Mart

transaes de granularidade atmicas so as tabelas mais expressivas e
dimensionais. Essa dimensionalidade robusta permite o mximo de operaes
de slice and dice sobre os dados. Tabelas fatos de transaes podem ser
densas ou esparsas, porque s existem linhas se as medies acontecem.
Estas tabelas de fatos sempre contm uma chave estrangeira para cada
dimenso associada, e, opcionalmente, contm carimbos (stamps) de hora
precisos e as chaves de dimenses degeneradas. Os fatos numricos medidos
devem ser consistentes com a granularidade da transao.
A linha em um snapshot peridico da tabela fato resume muitos
eventos de medio que ocorrem ao longo de um perodo normal, como um
dia, uma semana ou um ms. A granularidade o perodo, e no a transao
individual. Snapshots peridicos das tabelas de fatos muitas vezes contm
muitos fatos porque qualquer evento de medio de acordo com a granularidade
da tabela de fatos permitido. Estas tabelas de fatos so uniformemente
densas em suas chaves estrangeiras, porque mesmo que nenhuma atividade
ocorre durante o perodo, uma linha tipicamente inserida na tabela fato
contendo um zero ou o valor nulo para cada fato.
Uma linha numa tabela de snapshot de fatos acumulando resume os
eventos que ocorrem em etapas de medio previsveis entre o incio e o fim de
um processo, pipeline ou fluxo de trabalho, tais como cumprimento de ordem ou
processamento de pedidos, que tm um ponto definido de incio, etapas
intermedirias padres, e um ponto final definido podem ser modelados com
este tipo de tabela de fatos. Existe uma chave estrangeira data na tabela de
verdade para cada etapa crtica no processo. Uma linha individual em um
snapshot acumulando da tabela fato, correspondente, por exemplo, a uma linha
de uma ordem, inicialmente inserida quando a linha de ordem criada. Com o
progresso, o acmulo de linha na tabela revisto e atualizado. Alm da chave
estrangeira de data associada a cada passo crtico processo, a tabela de
snapshot acumulativo deve conter chaves estrangeiras para outras dimenses e,
opcionalmente, conter dimenses degeneradas. Eles geralmente incluem
medies numricas consistentes com o gro, juntamente com os contadores de
concluso marco. Vejam abaixo um exemplo terico do que seria representado
em cada um dos tipos de tabelas.
16712855225
19 de 50
DW, ETL e Data Mart

Embora a maioria dos eventos de medio capturem resultados
numricos, possvel que o evento apenas registre um conjunto de entidades
dimensionais que se juntam em um momento no tempo, so as conhecidas
tabelas fatos sem fatos. Por exemplo, um aluno assiste a uma aula em um
determinado dia pode no ter um fato numrico associado, mas uma linha fato
com chaves estrangeiras para o dia de calendrio, estudante, professor,
localizao e classe pode ser definida. Da mesma forma, a comunicao com o
cliente so eventos, mas pode no haver mtricas associadas.
Tabelas fato sem fato tambm podem ser usadas para analisar o que
no aconteceu. Essas consultas tm sempre duas partes: uma tabela fato de
cobertura que contm todas as possibilidades de eventos que podem acontecer e
uma tabela fato de atividade que contm os eventos que aconteceram. Quando
a atividade subtrada da cobertura, o resultado o conjunto de
acontecimentos que no aconteceram.
Muitas vezes conveniente combinar fatos de vrios processos em uma
nica tabela fato consolidada caso possam ser expressos na mesma
granularidade. Por exemplo, os valores reais de vendas podem ser consolidados
com as previses de vendas em uma nica tabela fato para tornar a tarefa de
analisar os valores reais contra previses simples e rpida, em comparao com
a montagem de um drill-across usando tabelas de fatos separadas. Tabelas de
fatos consolidados adicionam um peso ao processamento de ETL, mas aliviam a
carga analtica sobre as aplicaes de BI. Elas devem ser consideradas para
mtricas entre processos que so frequentemente analisados em conjunto.
A seguir apresentamos uma figura que mostra a composio bsica de
uma tabela fato:
16712855225
1. CESGRANRIO - 2008 - PETROBRS - ANALISTA DE SISTEMAS JNIOR

- PROCESSOS DE NEGCIOS
A empresa passou a sortear cupons de desconto para alguns clientes, os quais
do direito a um desconto nas compras em uma determinada data. A informao
sobre que clientes possuem cupons para que datas mantida de forma
20 de 50
DW, ETL e Data Mart

independente e consolidada no processo de extrao, transformao e carga,
resultando em um campo, na tabela fato, indicando se a venda foi realizada com
o desconto ou no. A soluo parecia atender bem s demandas dos usurios do
data warehouse, at que um deles tentou realizar uma consulta para saber quais
clientes no haviam realizado compras, mesmo tendo um cupom de desconto
para a data. Este tipo de demanda tipicamente ser resolvido introduzindo, no
data warehouse, uma
(a) tabela de fatos complementares (complimentary fact table).
(b) tabela de fatos sem dimenso (dimensionless fact table).
(c) tabela de fatos sem fatos (factless fact table).
(d) dimenso multivalorada (multivalued dimension).
(e) dimenso degenerada (degenerated dimension).
Comentrios: Vamos analisar cada uma das alternativas:
Tabela de fatos - Num esquema estrela, a tabela central com medidas numricas
de desempenho caracterizadas por uma chave composta, cada um dos
elementos uma chave estrangeira trazida de uma tabela de dimenso.
Tabela de fatos sem fatos (factless fact table) - Uma tabela de fatos que no
tem fatos, mas captura alguns relacionamentos muitos-para-muitos entre as
chaves de dimenses. Mais frequentemente usada para representar eventos ou
prover informao de cobertura que no aparece em outras tabelas de fatos.
Dimenso degenerada (degenerated dimension) - Uma chave de dimenso,
como o nmero de uma transao, nmero de fatura, de ticket, ou de bill-oflading, que no tenha nenhum atributo associado, portanto no se constitui com
uma tabela de dimenso.
Dimenso multivalorada (multivalued dimension) - Normalmente, uma tabela de
fatos possui conexes somente para dimenses representando um valor simples,
como uma data ou produto. Mas ocasionalmente, vlido conectar um registro
de fato a uma dimenso representando um nmero aberto de valores, como o
nmero de diagnsticos simultneos que um paciente pode ter num momento de
um mesmo tratamento. Neste caso, dizemos que a tabela de fatos tem uma
dimenso multivalorada. Tipicamente manipulada por uma tabela ponte.
Baseado no exposto, podemos concluir que a resposta se encontra na alternativa
C.
16712855225
Gabarito: C
Vamos agora apresentar algumas caractersticas e taxonomia para as
tabelas de dimenses.
Cada tabela de dimenso tem uma nica coluna de chave primria. Esta
chave primria incorporada como uma chave estrangeira em qualquer tabela
de fatos onde a descrio textual presente na linha da dimenso exatamente a
correta para a linha da tabela de fatos. Tabelas de dimenso so geralmente
grandes, desnormalizadas, com muitos atributos de texto de baixa
cardinalidade.
Embora os cdigos operacionais e os indicadores possam ser tratados
como atributos, os atributos de dimenso mais poderosos so preenchidos com
21 de 50
DW, ETL e Data Mart

descries verbais. Os atributos da tabela de dimenso so o principal alvo de
especificaes de restries e agrupamento de consultas em aplicaes de BI. Os
rtulos descritivos sobre os relatrios so tipicamente valores de domnio do
atributo da dimenso.
A tabela de dimenso projetada com uma coluna que funciona como
uma chave primria nica. Esta chave primria no pode ser a chave natural do
sistema operacional, pois haver vrias linhas de dimenso para a chave natural
quando as alteraes forem feitas ao longo do tempo. Alm disso, chaves
naturais para uma dimenso podem ser criadas por mais do que um sistema, e
estas chaves naturais podem ser incompatveis ou mal administradas.
O sistema de DW/BI precisa reivindicar o controle das chaves primrias de
todas as dimenses, ao invs de usar chaves naturais explcitas ou chaves
naturais com datas concatenadas, voc deve criar as chaves primrias inteiras
(numricas) annimas para cada dimenso. Essas chaves so conhecidas como
chaves artificiais.
Estas chaves substitutas para dimenso so nmeros inteiros simples,
atribudos em sequncia, comeando com o valor um, a cada vez que uma nova
chave necessria. A dimenso data isenta da regra fundamental da chave
substituta. Esta dimenso altamente previsvel e estvel pode usar uma chave
primria mais significativa.
Chaves naturais criadas pelos sistemas operacionais de origem esto
sujeitos s regras de negcios fora do controle do sistema de DW/BI. Por
exemplo, um nmero de funcionrio (chave natural) pode ser alterado se o
empregado se demite e depois recontratado. Quando o armazm de dados
quer ter uma chave nica para que o empregado, uma nova chave durvel
deve ser criada que seja persistente e no se altere nesta situao.
Esta chave muitas vezes referida como uma chave sobrenatural
durvel. As melhores chaves durveis tem um formato que independente do
processo de negcio original e, portanto, devem ser inteiros simples atribudos
em sequncia comeando de um. Enquanto vrias chaves de substituio
podem ser associadas com um funcionrio ao longo do tempo com as suas
alteraes do perfil, a chave durvel nunca muda.
16712855225
s vezes uma dimenso definida e no tem contedo, exceto a sua

chave primria. Por exemplo, quando uma nota fiscal tem vrios itens de linha,
cada linha da tabela fato herda dados de todas as dimenses descritivas por
meio das chaves estrangeiras da nota fiscal, e nota fica, portanto, sem contedo
exclusivo. Mas o nmero de fatura continua a ser uma chave de dimenso vlida
para as tabelas fatos no nvel de item de linha. Esta dimenso degenerada e
colocada na tabela fato, com o reconhecimento explcito que no h tabela de
dimenso associada. Dimenses degeneradas so mais comuns com tabelas fato
de snapshots e tabelas fato de acumulao.
22 de 50
DW, ETL e Data Mart

Em geral, os designers de modelos dimensionais devem resistir
normalizao, causada por anos de projetos de banco de dados operacionais e,
denormalizar as hierarquias de profundidade fixa em atributos separados em
uma linha de dimenso achatada. A desnormalizao da dimenso apoia os
objetivos individuais de modelagem dimensional de simplicidade e velocidade.
Muitas dimenses contm mais de uma hierarquia natural. Por exemplo, a
dimenso data de calendrio pode ter dias teis por semana na hierarquia de
perodo fiscal, assim como uma hierarquia para dia, ms e ano. Dimenses de
localizao podem ter vrias hierarquias geogrficas. Em todos estes casos, as
hierarquias separadas podem graciosamente coexistir na mesma tabela
dimenso.
Abreviaturas, flags de verdadeiro/falso, e indicadores operacionais devem
ser complementados nas tabelas de dimenso com palavras de texto completo
que tm significado quando vistos de forma independente. Cdigos operacionais
com significado embutido no valor do cdigo devem ser divididos e cada parte
do cdigo deve possuir uma dimenso descritiva separada para seu prprio
atributo (significado). Imagine o cdigo 101.2012.1342.23-1 nele cada subparte
descrever uma caracterstica do produto.
Valores nulos nos atributos da dimenso so resultado de uma
determinada linha de dimenso que no foi totalmente preenchida, ou quando
existem atributos que no so aplicveis a todas as linhas da dimenso. Em
ambos os casos, recomenda-se a substituio por uma sequncia descritiva,
como desconhecido ou no se aplica no lugar do valor nulo. Nulos em
atributos de dimenso devem ser evitados porque lidar com bancos de dados
diferentes, agrupando e restringindo os nulos, , muitas vezes, inconsistente.
Dimenses calendrio ou data esto ligadas a praticamente todas
as tabelas de fatos para permitir a navegao da tabela de fatos atravs de
datas familiares, meses, perodos fiscais, e dias especiais no calendrio. Voc
nunca iria querer calcular o feriado de pscoa usando SQL, mas sim querer
procur-lo na dimenso data do calendrio. A dimenso data do calendrio
normalmente tem muitos atributos que descrevem as caractersticas tais como
nmero da semana, o nome do ms, perodo fiscal, e um indicador de feriado
nacional. Para facilitar o particionamento, a chave primria de uma dimenso de
data pode ser mais significativa, como um inteiro representado por AAAAMMDD,
em vez de uma chave substituta sequencialmente atribuda.
16712855225
Uma nica dimenso fsica pode ser referenciada vrias vezes em uma
tabela de fato, com cada referncia ligando para um papel logicamente distinto
para a dimenso. Por exemplo, uma tabela de dados pode ter vrias datas, cada
uma delas representada por uma chave estrangeira para a dimenso de data.
essencial que cada chave estrangeira se refira a uma viso separada da
dimenso data de modo que as referncias sejam independentes. Estas
dimenses separadas (com nomes exclusivos de colunas de atributo) so
chamadas de papis.
23 de 50
DW, ETL e Data Mart

Processos de negcios transacionais normalmente produzem nmeros
variados, e uma baixa cardinalidade de bandeiras (flags) e indicadores. Ao invs
de fazer dimenses diferentes para cada bandeira (flag) e atributo, voc pode
criar uma nica dimenso junk e combin-las. Esta dimenso, muitas vezes
rotulada como uma dimenso de perfil de transao em um esquema, no
precisa ser o produto cartesiano de todos os valores possveis dos atributos, mas
deve conter apenas a combinao de valores que ocorrem realmente nos dados
de origem.
Quando uma relao hierrquica em uma tabela de dimenso
normalizada, os atributos de baixa cardinalidade aparecem como tabelas
secundrias ligadas tabela de dimenso base, por uma chave de atributo.
Quando este processo repetido com todas as hierarquias da tabela de
dimenso, uma estrutura caracterstica com vrios nveis criada. Chamamos
esse novo modelo de floco de neve.
Embora o floco de neve represente dados hierrquicos com preciso, voc
deve evitar os flocos de neve, porque difcil para os usurios de negcios
compreenderem e navegarem sobre os dados. Eles tambm podem afetar
negativamente o desempenho da consulta. A tabela de dimenso
desnormalizada contm exatamente a mesma informao como uma dimenso
Snowflaked.
A dimenso pode conter uma referncia para outra tabela dimenso. Por
exemplo, uma dimenso conta bancria pode fazer referncia a uma dimenso
separada representando a data em que a conta foi aberta. Estas referncias
dimenso secundria so chamadas dimenses outrigger. Dimenses
Outrigger so permitidas, mas devem ser usados com moderao. Na maioria
dos casos, as correlaes entre as dimenses devem ser rebaixadas para uma
tabela fato, quando as duas dimenses so representadas como chaves
estrangeiras separadas.
2.4. Esquemas multidimensionais

16712855225
Para finalizar o assunto vamos apresentar de forma grfica os esquemas

conhecidos como star schema, snowflake e multiestrela. Apresentaremos
tambm a dimenso conforme, que compartilhada entre diferentes tabelas
fatos. Vejam a figura abaixo.
24 de 50
DW, ETL e Data Mart

3. ETL
Um ambiente de DW devidamente projetado possui um trade off entre o
trabalho na sala de aplicaes de BI e o trabalho do sistema de ETL. O primeiro
deve ser feito repetidas vezes pelos usurios de negcios, enquanto o segundo
feito uma vez pela equipe de ETL.
O processo de ETL o processo mais crtico e demorado na construo de
um DW. ETL e as ferramentas de limpeza de dados consomem um tero do
oramento num projeto de DW e 80% do tempo de desenvolvimento de um DW
consiste no processo de ETL. Abaixo temos uma figura que descreve as etapas
de um processo de ETL.
16712855225
Antes de comear a desprender esforos para desenvolvimento de um

processo de ETL voc deve gastar um tempo refletindo sobre alguns aspectos.
Primeiramente preciso entender as necessidades de negcio e a conformidade
ou o contexto legal do sistema. A preocupao com a qualidade dos dados
tambm relevante, devemos definir o nvel de qualidade para o dado ser ou
25 de 50
DW, ETL e Data Mart

no aceito. A prxima etapa entender os requisitos de segurana e
privacidade.
Aps a definio dos requisitos de segurana importante entender a
forma de integrao dos dados (MDM) e a latncia dos dados, que descreve o
quo rpido os dados das fontes de dados de origem devem ser entregues aos
usurios de negcio por meio do sistema de BI/DW.
Voc deve listar todas as tabelas de fato e dimenso que sero
diretamente expostas as suas ferramentas de BI. Isto deve vir diretamente da
especificao do modelo dimensional. Listar todos os cubos OLAP e estruturas de
dados especiais exigidos por ferramentas de BI. Listar todos os ndices
conhecidos e agregaes que voc concordou em construir para apoiar o
desempenho do sistema de BI.
Voc deve inventariar o seu departamento: o sistema operacional,
ferramentas de ETL, linguagem de programao, SQL, SGBDs e habilidades
OLAP para voc entender como voc est exposto a uma falta ou perda dessas
habilidades. Enumerar as habilidades necessrias para apoiar seus sistemas
atuais e seus sistemas futuros provveis. Voc deve ainda listar os seus
sistemas legados avaliando se o seu uso exclusivo obrigatrio ou meramente
recomendado.
3.1. Componentes de ETL

As etapas do processo tm quatro componentes principais: extrao,
limpeza e conformidade, entrega e gesto. Cada uma dessas etapas dividida
em subsistemas conforme descrito abaixo.
Extrao. Coleta de dados brutos a partir dos sistemas de origem e,
geralmente, gravao em disco no ambiente de ETL antes de qualquer
reestruturao significativa dos dados. Subsistemas de 1 a 3 apoiam o processo
de extrao. (3)
Limpeza e conformidade. O envio de dados de origem atravs de
uma srie de etapas de processamento no sistema de ETL para melhorar a
qualidade dos dados recebidos a partir da fonte, e a fuso de dados a partir de
duas ou mais fontes para criar e aplicar as dimenses e mtricas conformes.
Subsistemas de 4 a 8 descrevem a arquitetura necessria para suportar os
processos de limpeza e conformidade (5)
16712855225
Entrega. Fisicamente corresponde a estruturao e o carregamento dos

dados em modelos multidimensionais de destino no servidor de apresentao.
Subsistemas de 9 a 21 fornecem a capacidade de entregar os dados ao servidor
de apresentao. (12)
Gesto. Gesto dos sistemas e processos relacionados do ambiente de
ETL, de uma forma coerente. Subsistemas de 22 a 34 descrevem os
26 de 50
DW, ETL e Data Mart

componentes necessrios para apoiar o gerenciamento contnuo do sistema de
ETL. (13)
Extrao: Trazendo os dados para o DW
1. Sistema de extrao - Obviamente, a extrao de dados dos
sistemas de origem um componente fundamental da arquitetura de ETL. O
sistema de ETL deve esperar dados a partir de uma ampla variedade de
sistemas que envolvem deferentes tipos de dados e outros desafios inerentes.
Se voc extremamente sortudo, todos os dados de origem estaro em um
nico sistema que pode ser facilmente extrado usando uma ferramenta de ETL.
2. Data profiling (perfil de dados) - Tcnica de anlise dos dados para
descrever o seu contedo, consistncia e estrutura. Fornece a equipe de ETL
uma orientao de quanto a limpeza de dados muito importante para o
projeto. Apenas para citar um exemplo, toda vez que voc executar uma
consulta SELECT DISTINCT investigativa em um campo do banco de dados, voc
est traando o perfil de dados.
3. Sistema de captura das alteraes nos dados Trata da
capacidade de transferir apenas as alteraes relevantes da fonte de dados
desde a ltima atualizao. A tarefa de isolar os dados de origem mais recentes
chamada de captura de alterao de dados (CDC). A ideia por trs do CDC
bastante simples: basta transferir os dados que foram alterados desde a ltima
carga.
Existem vrias maneiras de capturar as alteraes de dados de origem,
cada uma delas eficaz para uma determinada situao. Alguns exemplos de
tcnicas so: Colunas de auditoria (Audit Columns), Extrao de tempo (Timed
Extracts), Comparao diferencial total (Full Diff Compare), Log do banco de
dados (Database Log Scraping), Monitorar a fila de mensagens (Message Queue
Monitoring).
Limpeza e Conformidade de dados
1. Sistema de limpeza de dados - O processo de limpeza de dados do ETL
serve para corrigir dados sujos, mas ao mesmo tempo esperado que o
armazm de dados fornecesse um quadro preciso dos dados medida que forem
capturados dos sistemas de produo da organizao. Encontrar o equilbrio
adequado entre estes objetivos conflitantes essencial.
16712855225
2. Esquema de eventos de erro - O esquema de evento de erro um

esquema dimensional centralizado, cuja finalidade registrar todos os eventos
de erro lanada por uma tela em qualquer lugar do fluxo do mapa ETL. Embora
nosso foco seja no processamento ETL para o DW, esta abordagem pode ser
usada em integrao de dados genricos (DI) que so aplicaes onde os dados
esto sendo transferidos entre aplicaes legadas.
3. Dimenso de auditoria - A dimenso de auditoria contm o contexto
dos metadados no momento em que uma linha especfica da tabela de fatos
criada.
27 de 50
DW, ETL e Data Mart

4. Sistema de deduplicao - A sobrevivncia do sistema depende do
processo de combinar um conjunto de registros duplicados em uma imagem
unificada, que combina as colunas dos registros pareados em uma linha
conformada. A sobrevivncia envolve o estabelecimento de regras comerciais
claras que definem a sequncia de prioridade para os valores da coluna de todos
os sistemas de origem possveis para permitir a criao de uma nica linha com
os atributos mais relevantes e consistentes.
5. Sistema de conformidade O sistema de conformidade permite fazer
ajuste e verificaes dentro do processo de ETL. Observem a figura a seguir que
mostra um resumo do fluxo do processo de conformidade.
Entrega: Prepare-se para Apresentao

Conforme conversamos anteriormente, a entrega possui 13 subsistemas,
vamos nos limitar a lista-los abaixo para no excedermos o contedo necessrio
para provas de concursos.
16712855225
1. Gesto da alterao lenta da dimenso

2. Gerador de chave substituta
3. Gerencia de hierarquia
4. Gerencia de dimenses especiais
Date/Time Dimensions, Junk(lixo) Dimensions, Mini-Dimensions,

Shrunken Subset Dimensions, Small Static Dimensions
5. Construtores da tabela fato

6. Pipeline da chave substituta
28 de 50
DW, ETL e Data Mart

7. Construo da tabela ponte para dimenso multivaloradas
8. Gerenciador de dados atrasados
9. Sistema de gerenciamento das dimenses
10.Sistema provedor dos fatos
11.Construo dos agregados
12.Construo do cubo OLAP
13.Gerencia da propagao de dados
Gerenciando o ambiente de ETL
Para atingir seus objetivos, o sistema
constantemente para cumprir trs critrios:
de
ETL
deve
trabalhar
Confiabilidade - Os processos de ETL devem sempre ser executados

consistentemente. Eles devem fornecer dados em tempo hbil, confiveis e em
qualquer nvel de detalhe.
Disponibilidade - O DW deve cumprir seus acordos de nvel de servio
(SLAs). O armazm deve estar pronto e disponvel, como prometido.
Gerenciamento - Um DW de sucesso nunca est pronto. Ele cresce
constantemente e muda juntamente com o negcio. Os processos de ETL
tambm precisam evoluir.
Vejam que precisamos dos subsistemas de gerenciamento devem ser
utilizados para garantir a gesto do ambiente de ETL. Vamos mais uma vez
apresentar os subsistemas desta etapa do processo.
1. Agendador de Jobs
Job definition, Job scheduling, Metadata capture, Logging,

Notification
2. Sistema de backup
3. Sistema de recuperao e restart
16712855225
4. Sistema de controle de verso

5. Sistema de migrao de verso
6. Workflow Monitor
7. Sistema de ordenao
8. Analisador de ancestrais e dependncia
9. Sistemas para problemas de escala
10.Sistema de paralelismo/pipeline
11.Sistema de segurana
12.Gerenciamento de conformidade
29 de 50
DW, ETL e Data Mart

13.Gerenciar repositrio de Metadados
3.2. Processo de ETL

O processo de ETL de forma resumida composto das seguintes etapas:
Primeiramente necessrio desenvolver um plano. Voc deve criar um plano de
alto nvel, escolher a ferramenta de ETL, desenvolver um conjunto de
estratgias padro e fazer o Drill Down by Target Table. Nesta ltima etapa
preciso detalhar as estratgias de transformao necessrias para popular cada
tabela do DW. A prxima fase envolve desenvolver o documento de
especificao do ETL
Agora podemos finalmente partir para a primeira carga dos dados que
deve popular as tabelas dimenso com os dados histricos e executar a carga
histrica da tabela fato. Neste momento j temos o nosso DW devidamente
povoado com dados.
Num momento posterior devemos partir para o processo incremental do
ETL, nesta etapa estamos preocupados com o processamento incremental das
tabelas dimenses e da tabela fato. Alm disso, podemos trabalhar a carga das
tabelas agregadas e dos cubos OLAP.
A ltima etapa do processo incremental a operao e automao do
sistema de ETL, visando um melhor desempenho e resilincia.
Com isso terminamos nossa aula 01 de BI, as prximas pginas trazem
um conjunto de questes comentadas referente ao assunto visto nesta aula.
16712855225
30 de 50
DW, ETL e Data Mart

Questes comentadas
Apresentamos abaixo um conjunto de questes, principalmente das
bancas CESPE, FCC, ESAF sobre o assunto de BI. Esperamos que elas ajudem na
fixao da matria. Qualquer dvida, estamos s ordens!
2. ANO: 2015 BANCA: CESPE RGO: MEC PROVA: TCNICO DE NVEL

SUPERIOR - ANALISTA DE SISTEMAS
Com relao aos passos do processo de projeto de bancos de dados e de
modelagem de dados relacional e dimensional, julgue os itens subsequentes.
[1] Na modelagem dimensional, implementada em sistemas de data warehouse,
o esquema snowflake caracteriza-se por possuir diversas tabelas de fatos e de
dimenses, sendo estas ltimas organizadas hierarquicamente na terceira forma
normal (3FN).
Comentrios: O modelo snowflake caracteriza-se por possuir uma tabela fatos
e um conjunto de tabelas normalizadas para representao de cada dimenso.
Sendo assim a alternativas est errada por dizer que o modelo possui diversas
tabelas fato.
Gabarito: E
3. ANO: 2015 BANCA: CESPE RGO: MEC PROVA: TCNICO DE NVEL

SUPERIOR - ADMINISTRADOR DE DADOS
No que se refere a bancos de dados transacionais (OLTP) e a banco de dados
analticos (OLAP), julgue os itens que se seguem.
[1] Para melhor manter o controle sobre identificadores de registro de
ambientes de data warehouse (armazm de dados), em geral recomenda-se a
gerao de chaves substitutas (surrogate keys). Assim, cada juno entre as
tabelas de dimenso e tabelas fato em um ambiente de data warehouse deve se
basear nessas chaves substitutas, e no nas chaves naturais existentes.
16712855225
Comentrios: Existem vrios motivos para a utilizao de chaves substitutas ou

artificiais dentro dos nossos modelos de DW. A primeira seria a que a mudana
de estado de um tupla nos modelos operacionais pode gerar uma nova entrada
na tabela de DW. Se tivermos usando a mesma chave primria do objeto no
modelo operacional ns no conseguiramos incluir essa nova linha.
justamente sobre isso que a questo fala. O que torna a alternativa correta.
Gabarito: C
31 de 50
DW, ETL e Data Mart

4. ANO: 2013 BANCA: ESAF RGO: DNIT PROVA:
ADMINISTRATIVO - TECNOLOGIA DA INFORMAO
ANALISTA
O componente nal do processo de Business Intelligence

A Business balance management (BBM).
B Executive ofce team (EOT).
C Business performance management (BPM).
D Priority statement board (PSB).
E Business advisory management (BAM).
Comentrios: Essa questo segue os conceitos descritos no livro do Turban que
divide o processo de BI em quatro partes: 1. O ambiente do DW, com as fontes
de dados, que define como os dados so armazenados; 2. O ambiente de anlise
de negcio que fornece um conjunto de ferramentas para minerar, manipular e
analisar os dados; 3. A interface com o usurio que diz como apresentar e
distribuir os dados consolidados; e 4. Performance e estratgia para monitorar e
contribuir com a gesto da organizao.
Aproveitando para falar um pouco mais sobre BPM, ele tambm chamado de
Corporate Performance Management (CPM). BPM um conceito que veio ratificar
a importncia de ter sempre o alinhamento das informaes com a estratgia da
empresa. BPM (Business Performance Management), um conjunto de software,
processos de negcios e medidas de sucesso dos negcios (mtricas e KPI's key performance indicators) que, quando combinados, premitem a uma
organizao entender, agir e influenciar a performance de seus negcios.
16712855225
Gabarito: C
5. ANO: 2010 BANCA: ESAF RGO:

TECNOLOGIA DA INFORMAO
MPOG
PROVA:
BI Business Inteligence
A uma tcnica de otimizao da rvore de deciso.
32 de 50
ANALISTA
DW, ETL e Data Mart

B um mtodo de formao avanada de gestores.
C compreende ferramentas de anlise de dados para otimizar os processos
produtivos de uma empresa.
D so tcnicas, mtodos e ferramentas para minerao de dados na rea de
negcios de uma empresa.
E so tcnicas, mtodos e ferramentas de anlise de dados para subsidiar
processos de deciso de uma empresa.
Comentrio: Vejam que a alternativa que converge para um dos conceitos de
BI que vimos ao longo da nossa aula a alternativa presente na letra E. Apenas
para lembramos do conceito, vamos exibi-lo abaixo:
BI representa a habilidade de se estruturar, acessar e explorar informaes,
normalmente guardadas em um DW/DM (Data Warehouse/Data Mart), com o
objetivo de desenvolver percepes, entendimentos, conhecimento, os quais
podem produzir um melhor processo de tomada de deciso. Essa definio do
autor brasileiro Carlos Barbieri.
Gabarito: E
6. ANO: 2010 BANCA: ESAF RGO:

TECNOLOGIA DA INFORMAO
MPOG
PROVA:
ANALISTA
Um ambiente Datawarehouse
A uma coleo de dados volteis, invariantes em termos locais, integrados e
orientados a um assunto, direcionados a decises operacionais.
B ao ser projetado segundo a abordagem bottom-up, fundamenta-se nas
necessidades de informao de todos os nveis gerenciais da empresa.
C para ser implementado, requer a remoo de metadados e a integrao de
dados existentes em um banco de dados.
D ao ser projetado, segundo a abordagem
necessidades de informaes gerenciais.
top-down,
no
comporta
E uma coleo de dados no-volteis, invariantes em termos temporais,

integrados e orientados a um assunto, utilizados no suporte a decises
gerenciais.
16712855225
Comentrios: Vejam que a questo usa os termos da definio do Inmon para

DW. Apenas para reforar vamos ver novamente a definio do pai do conceito
de DW: uma coleo de dados orientados por assunto, integrados, variveis
com o tempo e no volteis, para dar suporte ao processo de tomada de
deciso. Sendo assim, podemos marcar sem medo a resposta correta na
alternativa E.
Gabarito: E
33 de 50
DW, ETL e Data Mart

7. ANO: 2013 BANCA: ESAF RGO: DNIT PROVA:
ADMINISTRATIVO - TECNOLOGIA DA INFORMAO
ANALISTA
So regras de avaliao de produtos OLAP:

A Transferncia ao usurio. Desempenho consistente na gerao de relatrios.
Dimensionalidade cumulativa. Operaes irrestritas com dimenses cruzadas.
B Viso conceitual multidimensional para restringir consultas. Transparncia ao
usurio. Dimensionalidade genrica. Manipulao dedutiva dos dados.
C Viso conceitual multidimensional para formular consultas. Desempenho
consistente na gerao de relatrios. Dimensionalidade genrica. Manipulao
intuitiva dos dados.
D Viso conceitual multidimensional para formular consultas. Dimensionalidade
genrica. Manipulao segmentada dos dados. Operaes irrestritas com
dimenses alternadas.
E Extenso conceitual dos dados. Transparncia ao dispositivo de acesso.
Manipulao intuitiva dos dados. Operaes irrestritas com indicaes cruzadas.
Comentrios: Para respondermos a essa questo precisamos conhecer as 12
regras de avalio de produtos OLAP. Vejam na lista abaixo as 12 regras de
avaliao definidas por Ted Codd.
1. Viso conceitual multidimensional
2. Transparncia
3. Acessibilidade
4. Desempenho consistente na gerao de relatrios
5. Arquitetura cliente-servidor
6. Dimensionalidade genrica
7. Manuseio dinmico de matriz esparsa
8. Suporte a multiusurios
9. Operaes irrestritas de cruzamento de dimenses
10. Manipulao de dados intuitiva
11. Relatrio flexvel
16712855225
12. Dimenses e agregao de nveis ilimitados

Vejam que de posse dessa lista fica fcil encontrar a resposta correta para a
questo. Essa busca nos leva a alternativa C.
Gabarito: C
8. ANO: 2010 BANCA: ESAF RGO: CVM PROVA: ANALISTA - ANALISTA

DE SISTEMAS
Ferramentas de processamento analtico on-line (OLAP)
A funcionam sobre dados multidimensionais, caracterizados por atributos de
dimenso e atributos de medida.
34 de 50
DW, ETL e Data Mart

B funcionam sobre dados unidirecionais, caracterizados por atributos de medida
e atributos de qualidade.
C funcionam sobre dados multidimensionais, caracterizados por atributos de
disperso e atributos de mediao.
D desconsideram dados multidimensionais.
E transformam dados unidimensionais em dados analticos, caracterizando
dimenso e medidas por atributos equivalentes.
Comentrios: A primeira grande caracterstica que precisamos relembrar da
nossa aula o fato de ferramentas OLAP funcionam sobre dados
multidimensionais. Ainda no estudamos a fundo as operaes e outros
conceitos relacionados OLAP, contudo, depois de termos visto todos os
conceitos de modelagem multidimensional, ns sabemos que estamos falando de
dados multidimensionais.
Os atributos de dimenses so aqueles que esto presentes nas tabelas de
dimenses dos nossos modelos e os atributos de medida so aqueles presentes
na tabela fato. Desta forma podemos mais uma vez convergir para a resposta,
presente na nossa alternativa A.
Gabarito: A
9. ANO: 2015 BANCA: FCC RGO: TRT - 4 REGIO (RS) PROVA:

ANALISTA JUDICIRIO - TECNOLOGIA DA INFORMAO
Considere a arquitetura geral de um sistema de BI - Business Intelligence
mostrada na figura abaixo.
16712855225
Nesta arquitetura
A Data Mining se refere ao processo que, na construo do Data Warehouse,
utilizado para composio de anlises e relatrios, armazenando dados
descritivos e qualificando a respectiva mtrica associada.
35 de 50
DW, ETL e Data Mart

B Data Marts representam reas de armazenamento intermedirio criadas a
partir do processo de ETL. Auxiliam na transio dos dados das fontes OLTP para
o destino final no Data Warehouse.
C OLAP um subconjunto de informaes extrado do Data Warehouse que pode
ser identificado por assuntos ou departamentos especficos. Utiliza uma
modelagem multidimensional conhecida como modelo estrela.
D os dados armazenados no Data Warehouse so integrados na base nica
mantendo as convenes de nomes, valores de variveis e outros atributos
fsicos de dados como foram obtidos das bases de dados originais.
E o Data Warehouse no voltil, permite apenas a carga inicial dos dados e
consultas a estes dados. Alm disso, os dados nele armazenados so precisos
em relao ao tempo, no podendo ser atualizados.
Comentrios: Vamos analisar cada uma das alternativas. Na letra A temos uma
definio equivocada de Data Mining. Apenas para apresentar um conceito
correto, podemos definir Data mining (minerao de dados) o processo de
extrao de conhecimento de grandes bases de dados, convencionais ou no.
Utiliza tcnicas de inteligncia artificial que procuram relaes de similaridade ou
discordncia entre dados. Seu objetivo encontrar padres, anomalias e regras
com o propsito de transformar dados, aparentemente ocultos, em informaes
teis para a tomada de deciso e/ou avaliao de resultados.
A alternativa B trata das reas de armazenamento temporrias, geralmente
conhecidas como Staging Area. Elas so utilizadas para manipulao dos dados
durante a transio do ambiente operacional para os DW. Vejam que Staging
Area no se assemelha de forma alguma com um Data Mart.
A alternativa C define Data Mart, mas associa a definio a OLAP.
A alternativa D trata da manuteno dos atributos como foram obtidos nas
bases originais. Se voc se lembrar da transformao de chaves naturais em
chaves artificiais tratada durante a aula vai visualizar o erro da alternativa.
Por fim, temos a letra E que se trata da nossa resposta.
Gabarito: E
16712855225
10. ANO: 2015 BANCA: FCC RGO: TRT - 15 REGIO (CAMPINASSP) PROVA: ANALISTA JUDICIRIO - TECNOLOGIA DA INFORMAO
No contexto de Business Intelligence, os sistemas OLAP e OLTP se diferenciam
em diversas caractersticas. Na tabela abaixo, no que diz respeito s
caractersticas, est INCORRETO:
36 de 50
DW, ETL e Data Mart

A Letra A
B Letra B
C Letra C
D Letra D
E Letra E
Comentrios: Vamos falar um pouco mais sobre OLAP na prxima aula. Mas se
lembrarmos do que vimos at aqui, podemos verificar que o texto presente na
caracterstica foco est trocado. OLAP foca no nvel estratgico da organizao,
enquanto OLTP visa atender as demandas operacionais. Desta forma a
alternativa E encontra-se incorreta. Como a questo pede para marcarmos a
incorreta, temos a nossa resposta.
Gabarito: E
11. ANO: 2015 BANCA: FCC RGO: TRE-RR PROVA: ANALISTA

JUDICIRIO - ANLISE DE SISTEMAS
Os dados de sistemas OLAP se baseiam nas informaes contidas nos diversos
softwares utilizados pela empresa (ERPs, planilhas, arquivos texto, arquivos XML
etc.). Estes sistemas possuem uma camada onde esto os dados originais e
outra camada onde esto os dados tratados (um gigantesco repositrio de dados
sobre assuntos diversos preparados para serem consultados por um sistema
OLAP), que chamamos de
16712855225
A Data Mining.
B Online Transactional Database.
C Data Mart.
D Datawarehouse.
E Big Data.
Comentrios: Vejam que a questo trata de um gigantesco repositrio de
dados que sabemos que o DW Data warehouse.
Gabarito: D
37 de 50
DW, ETL e Data Mart

12. ANO: 2015 BANCA: FCC RGO: CNMP PROVA: ANALISTA DO
CNMP - DESENVOLVIMENTO DE SISTEMAS
Solues informatizadas de Business Intelligence (BI) geralmente contm
sistemas que podem ser de diversos tipos, dependendo do objetivo das anlises
e do perfil do usurio, como:
A Online Analytical Processing (OLAP), tambm conhecidos como sintticos, que
baseiam-se em transaes, como: Sistemas Contbeis; Aplicaes de Cadastro;
Sistemas de Compra, Estoque, Inventrio; ERPs; CRMs.
B Decision Support Systems (DSS) ou Sistemas de Apoio a Deciso, voltados
para profissionais que atuam no nvel estratgico das empresas, como diretoria
e presidncia. Oferecem, para tanto, um conjunto de indicadores chave de
desempenho como o CMMI.
C Management Information Systems (MIS) ou Sistemas de Informaes
Gerenciais, que permitem anlises mais profundas, com a realizao de
simulaes de cenrios. Por vezes, utilizam-se de ferramentas de Data Mining
para identificao de cruzamentos no triviais. So utilizados por analistas de
negcio no nvel ttico.
D Online Transactional Processing (OLTP) ou Sistemas transacionais, que
fornecem subsdio para tomadas de deciso a partir de anlises realizadas sobre
bases de dados histricas, por vezes com milhes de registros a serem
totalizados.
E Executive Information Systems (EIS) ou Sistemas de Informaes Executivas,
que so baseados em relatrios analticos, normalmente utilizados por usurios
de nvel operacional.
Comentrios: Vamos ver o que tem de errado nas alternativas distintas a
resposta da questo. Na alternativa A listado um conjunto de sistemas
operacionais e associado essa lista a sistemas OLAP, que se trata da sigla para
sistemas analticos.
Sabemos que CMMI no um conjunto de indicadores bsicos de desempenho.
um certificado do nvel de maturidade no desenvolvimento de software de uma
determinada organizao. Sendo assim a alternativa B tambm est errada.
A alternativa C a nossa resposta, trata dos Sistemas de informaes gerenciais
de forma correta.
16712855225
Na alternativa D o erro est em associar os sistemas transacionais com subsdio

para tomada de decises.
Por fim, a alternativa E diz que relatrios analticos so utilizados por usurios
operacionais, o que est incorreto.
Gabarito: C
13.
ANO: 2010 BANCA: FCC RGO: TCE-SP PROVA: AGENTE DA
FISCALIZAO FINANCEIRA - CONHECIMENTOS BSICOS
Os conceitos de inteligncia empresarial ou organizacional esto intimamente
relacionados com o PETI que considera
38 de 50
DW, ETL e Data Mart

A o planejamento de sistemas de informao, apenas.
B o planejamento de sistemas de informao e conhecimentos, apenas.
C a informtica e os conhecimentos, apenas.
D a informtica, apenas.
E o planejamento de sistemas de informao, conhecimentos e informtica.
Comentrios: O Planejamento Estratgico da Tecnologia da Informao (PETI)
um processo dinmico e interativo para estruturar estratgica, ttica e
operacionalmente as informaes organizacionais, a TI (e seus recursos:
hardware, software, sistemas de telecomunicao, gesto de dados e
informao), os sistemas de informao e do conhecimento, as pessoas
envolvidas e a infraestrutura necessria para o atendimento de todas as
decises, aes e respectivos processos da organizao.
O PETI deve estar alinhado aos negcios. Para que esse alinhamento acontea, o
maior desafio dos gestores ainda fazer com que a TI desempenhe seu
relevante papel estratgico nas organizaes, agregando valores aos seus
produtos e/ou servios e auxiliando a promoo das inteligncias competitiva e
empresarial. fundamental, portanto, que os recursos computacionais da TI
disponibilizem informaes oportunas e conhecimentos personalizados que
possibilitem a gerao de cenrios decisrios.
Gabarito: E
16712855225
39 de 50
DW, ETL e Data Mart

Questes extras
14.
ANO: 2013 BANCA: FCC RGO: MPE-CE PROVA: ANALISTA
MINISTERIAL - CINCIAS DA COMPUTAO
Em relao ao entendimento do significado do termo Business Intelligence (BI) e
da soluo que prov, a definio que NO coerente com o termo Business
Intelligence a que
A consiste em uma metodologia que fornece objetivos de negcios ligados a
objetivos de TI, provendo mtricas e modelos de maturidade para medir a sua
eficcia e identificando as responsabilidades relacionadas dos donos dos
processos de negcios e de TI.
B se refere aplicao de tcnicas analticas para informaes sobre condies
de negcio no sentido de melhor-las, de uma maneira automatizada, mas com
a interpretao e respostas humanas, de forma a melhorar a tomada de
decises.
C rene recursos que provm a habilidade para que a pessoa certa receba a
informao adequada e no momento correto para tomar a melhor deciso.
D consiste em um sistema de negcios que inclui uma estrutura de busca efetiva
e acessvel, acurada, em tempo real, com informaes e relatrios que permitam
aos lderes das reas de negcio se manterem informados para tomar decises.
E uma soluo fcil de dizer, mas difcil de fazer corretamente pois envolve
mudanas na forma como a organizao conduz uma busca efetiva, bem como,
a necessidade de se possuir uma base de dados de qualidade para que se possa
tomar aes com o objetivo de otimizar a performance corporativa.
Gabarito: A
16712855225
15.
ANO: 2012 BANCA: FCC RGO:
JUDICIRIO - ANALISTA DE SISTEMAS
TST
PROVA:
ANALISTA
Em Business Intelligence (BI), as consultas de dados que NO esto disponveis

em relatrios peridicos, ou seja, consultas criadas sob demanda
especificamente para um contedo, layout ou clculo, agilizando ou facilitando a
tomada de deciso, so chamadas de consultas
A evolutivas.
B multidimensionais.
C single shot.
D data mining.
E ad hoc.
40 de 50
DW, ETL e Data Mart

Gabarito: E
16.
ANO: 2015 BANCA: FCC RGO: TRT - 3 REGIO (MG) PROVA:
TCNICO JUDICIRIO - TECNOLOGIA DA INFORMAO
Um tcnico de TI precisa utilizar um subconjunto de dados de um Data
Warehouse direcionado rea administrativa de um Tribunal. Esses dados sero
armazenados em um banco de dado modelado multidimensionalmente, que ser
criado capturando-se dados diretamente de sistemas transacionais, buscando as
informaes relevantes para os processos de negcio da rea administrativa.
Esse banco de dados ser um
A Big Data.
B Data Mart.
C OLAP.
D MOLAP.
E Data Mining.
Gabarito: B
17.
ANO: 2014 BANCA: FCC RGO: TCE-RS PROVA: AUDITOR
PBLICO EXTERNO - TCNICO EM PROCESSAMENTO DE DADOS
A granularidade de dados uma questo crtica no projeto de um Data
Warehouse (DW), pois afeta o volume de dados que reside no DW e, ao mesmo
tempo, afeta o tipo de consulta que pode ser atendida. Considere:
I. Quanto mais detalhe existir, mais baixo ser o nvel de granularidade. Quanto
menos detalhe existir, mais alto ser o nvel de granularidade.
II. Quando h um nvel de granularidade muito alto, o espao em disco e o
nmero de ndices necessrios se tornam bem menores, mas h uma
correspondente diminuio da possibilidade de utilizao dos dados para atender
a consultas detalhadas.
16712855225
correto afirmar que a afirmativa I

A equivalente a: quanto menos detalhes h nos dados, menor a
granularidade, consequentemente, quanto mais detalhes existem, maior a
granularidade.
B e a afirmativa II esto corretas e coerentes em relao ao nvel de
granularidade, espao em disco e tipos de consultas em um DW.
C est correta. A afirmativa II est incorreta, pois apresenta incoerncia em
relao ao nvel de granularidade, espao em disco e tipos de consultas em um
DW.
41 de 50
DW, ETL e Data Mart

D e a afirmativa II esto incorretas. Ambas apresentam incoerncia em relao
ao nvel de granularidade, espao em disco e tipos de consultas em um DW.
E est incorreta. A afirmativa II est correta, pois coerente em relao ao nvel
de granularidade, espao em disco e tipos de consultas em um DW.
Gabarito: B
18.
ANO: 2015 BANCA: FCC RGO: CNMP PROVA: ANALISTA DO
CNMP - DESENVOLVIMENTO DE SISTEMAS
Considere que a equipe de Analistas de Desenvolvimento de Sistemas do CNMP
est projetando a arquitetura para o Data Warehouse (DW) da instituio,
conforme mostra a figura abaixo:
correto afirmar que esta arquitetura

16712855225
A bottom-up, pois primeiro a equipe cria um DW e depois parte para a

segmentao, ou seja, divide o DW em reas menores gerando pequenos bancos
orientados por assuntos aos departamentos.
B bottom-up. Permite um rpido desenvolvimento, pois a construo dos Data
Marts altamente direcionada. Normalmente um Data Mart pode ser colocado
em produo em um perodo de 2 a 3 meses.
C top-down. A partir do DW so extrados os dados e metadados para os Data
Marts. Nos Data Marts as informaes esto em maior nvel de sumarizao e,
normalmente, no apresentam o nvel histrico encontrado no DW.
D top-down, pois possui um retorno de investimento muito rpido ou um
faster pay back. O propsito desta arquitetura a construo de um DW
incremental a partir de Data Marts independentes.
42 de 50
DW, ETL e Data Mart

E bottom-up. Garante a existncia de um nico conjunto de aplicaes para
ETL, ou seja, extrao, limpeza e integrao dos dados, embora os processos de
manuteno e monitorao fiquem descentralizados.
Gabarito: C
19.
ANO: 2015 BANCA: FCC RGO: TCM-GO PROVA: AUDITOR DE
CONTROLE EXTERNO - INFORMTICA
O Serpro relatou assim uma parceria com o Tribunal de Contas da Unio TCU:
O funcionamento do Sntese, simplificadamente, se dar da seguinte forma:
sero realizadas extraes de dados dos sistemas de informaes mantidos por
diversos rgos pblicos; esses dados sofrero transformaes para
compatibilizar codificaes e formatos, realizar classificaes, agrupar registros e
agregar valores; as informaes modificadas alimentaro o repositrio de dados
modelado especificamente para consultas analticas. O acesso ao repositrio ser
realizado pelo usurio final por meio de ferramentas que possuem uma interface
amigvel para elaborar consultas ou relatrios. A apresentao das consultas
pode ser em forma de matriz, grfico, documento de editor de texto ou planilha
eletrnica.
O repositrio de dados e as ferramentas, em destaque no texto, referem-se,
respectivamente, a
A ERP e SQL Server Reporting Service.
B SQL Server Reporting Service e Data Mining.
C Data Warehouse e OLAP.
D SQL Server Reporting Service e Business Intelligence.
E Data Warehouse e SQL Server Reporting Service.
Gabarito:C
16712855225
20.
JUDICIRIO - BANCO DE DADOS - DBA
TJ-AP
PROVA:
ANALISTA
Os sistemas de Data Warehouse utilizam-se de um modelo de dados diferente

dos bancos de dados tradicionais, que proporciona ganhos de desempenho nas
consultas. Esse modelo conhecido como modelagem
A dinmica.
B dimensional.
C fixa.
D online.
43 de 50
DW, ETL e Data Mart

E transacional.
Gabarito: B
21.
ANO: 2015 BANCA: FCC RGO: TRT - 3 REGIO (MG) PROVA:
TCNICO JUDICIRIO - TECNOLOGIA DA INFORMAO
A modelagem multidimensional utilizada especialmente para sumarizar e
reestruturar dados e apresent-los em vises que suportem a anlise dos
valores desses dados. Um modelo multidimensional formado por dimenses, e
por uma coleo de itens de dados composta de dados de medidas e de
contexto, denominada
A schema.
B pivot.
C slice.
D fato.
E verso.
Gabarito: D
22.
ANO: 2015 BANCA: FCC RGO: TCM-GO PROVA: AUDITOR DE
CONTROLE EXTERNO - INFORMTICA
Quando o modelo de dados multidimensionais comea a ser definido, elementos
bsicos de representao precisam ter sido estabelecidos, de modo a se criar um
padro de modelagem. Considere um modelo em que as dimenses e fatos so
representados em tabelas, podendo haver mltiplas dimenses e mltiplas
tabelas de fatos.
16712855225
Ao modelar cada tabela _____I_____

pontos:
devem ser considerados os seguintes
A chave primria composta, sendo um elemento da chave para cada

dimenso;
Cada elemento chave para a dimenso deve ser representado e descrito
na tabela _____II_____ correspondente (para efetuar a juno);
A dimenso tempo sempre representada como parte da chave
primria.
Deve haver uma tabela _____III_____
contendo
para cada dimenso do modelo,
Uma chave artificial (ou gerada) genrica;

Uma coluna de descrio genrica para a dimenso;
44 de 50
DW, ETL e Data Mart

Colunas que permitam _____IV_____;
Um indicador nvel que indica o nvel da hierarquia a que se refere a
linha da tabela.
As lacunas de I a IV so corretas, e respectivamente, preenchidas com:
A dimenso de fatos de tempo efetuar os filtros.
B dimenso de fatos de fatos a juno com as tabelas de fatos.
C de fatos de tempo dimenso sinalizar a presena de fatos para o
perodo de tempo indicado na linha.
D de fatos dimenso dimenso efetuar os filtros.
E de tempo dimenso de fatos a juno com as tabelas de dimenso.
Gabarito: D
23.
ANO: 2013 BANCA: FCC RGO: MPE-MA PROVA: ANALISTA
JUDICIRIO - BANCO DE DADOS
Considerando um data warehouse, podem ser utilizadas, para sua consulta, as
ferramentas MOLAP (Multidimensional OLAP), cuja caracterstica principal fazer
o acesso a um conjunto de dados previamente calculados, denominado
A matriz de dados.
B lista ligada.
C matriz hash.
D milestone.
E cubo de dados.
Gabarito: E
16712855225
24.
Na modelagem de um data warehouse, pode ser feito o snowflaking, que
significa
A criptografar as tabelas fato e dimenso.
B normalizar as tabelas dimenso.
C excluir atributos do tipo binrio.
D indexar as tabelas dimenso por todos seus atributos.
E duplicar a tabela fato.
45 de 50
DW, ETL e Data Mart

Gabarito: B
25.
Na modelagem dimensional de um data warehouse voltado para vendas, o tipo
de tabela fato que inclui pares de produtos adquiridos em uma mesma compra
recebe a denominao de
A cesta de mercado.
B tabela de degenerao.
C data mart.
D outrigger.
E pacote de integralizao.
Gabarito: A
26. ANO: 2009 BANCA: FCC RGO: TRT - 15 REGIO (CAMPINASSP) PROVA: ANALISTA JUDICIRIO - TECNOLOGIA DA INFORMAO
No contexto OLAP:
I. As vises materializadas agregadas a partir de uma tabela de fatos podem ser
identificadas exclusivamente pelo nvel de agregao para cada dimenso.
II. Quando aplicada a configurao star schema as tabelas de fatos e as de
dimenso so idnticas quanto totalidade dos atributos que contm e tambm
quanto ao grau de granularidade.
III. O esquema snow flake uma variao do star schema.
Est correto o que consta em
A I, somente.
16712855225
B I e III, somente.
C II e III, somente.
D III, somente.
E I, II e III.
Gabarito B
46 de 50
DW, ETL e Data Mart

27. ANO: 2012 BANCA: FCC RGO:
TST
PROVA:
ANALISTA
O processo de ETL em uma Data Warehouse possui vrias fases. Em uma destas
fases efetuada a
A extrao dos dados dos sistemas de origem.
B introduo de novos produtos no mercado.
C validao das interfaces de usurio.
D criao de diagramas estticos e comportamentais das classes e atributos.
E definio dos custos e prazos.
Gabarito: A
28.
ANO: 2010 BANCA: FCC RGO: TRT - 22 REGIO (PI) PROVA:
ANALISTA JUDICIRIO - TECNOLOGIA DA INFORMAO
No mbito dos DWs, uma outra concepo do ODS (Staging Area) est sendo
estabelecida por alguns autores. Trata-se de
A OLAP.
B Drill throught.
C ETL.
D Data Mining.
E Dynamic Data Storage.
Gabarito: E
16712855225
29. ANO: 2011 BANCA: FCC RGO: TRT - 14 REGIO (RO E AC)
PROVA: ANALISTA JUDICIRIO - TECNOLOGIA DA INFORMAO
No contexto de DW, uma categoria de ferramentas de anlise denominada
open-end e que permite ao usurio avaliar tendncias e padres no conhecidos
entre os dados. Trata-se de
A slice.
B star schema.
C ODS.
D ETL.
E data mining.
47 de 50
DW, ETL e Data Mart

Gabarito: E
30.
ANO: 2013 BANCA: FCC RGO: TRT - 15 REGIO (CAMPINASSP) PROVA: ANALISTA JUDICIRIO - TECNOLOGIA DA INFORMAO
Arquitetar e manter processos ETL considerado por muitos uma das tarefas
mais difceis de um projeto de data warehouse. Muitos projetos deste tipo
utilizam ferramentas para manter este processo. ......, por exemplo, prov
recursos de ETL e tira vantagem das capacidades de banco de dados inerentes.
A lacuna acima corretamente preenchida com Oracle
A Warehouse Builder (OWB).
B Loading Data (OLD).
C Data Transformation (ODT).
D Query and Input (OQI).
E Business Intelligence (OBI).
Gabarito: A
31.
TST
PROVA:
ANALISTA
Leia as afirmaes a seguir:

I. Um Data Warehouse um repositrio de dados atuais e histricos de uma
organizao que possibilita a anlise de grande volume de dados para suportar a
tomada de decises estratgicas, possuindo registros permanentes.
II. O processo de Data Mining, ou minerao de dados, tem por objetivo localizar
possveis informaes em um banco de dados atravs de comparaes com
dados informados pelo usurio e registros de tabelas.
16712855225
III. Um ERP, ou Sistema Integrado de Gesto Empresarial, conhecido por

integrar os dados de diferentes departamentos de uma organizao,
aumentando o uso de interfaces manuais nos processos.
IV. As ferramentas OLAP (On-line Analytical Processing) so capazes de analisar
grandes volumes de dados, fornecendo diferentes perspectivas de viso e
auxiliando usurios na sintetizao de informaes.
Est correto o que se afirma APENAS em
A I e II.
B II e III.
C I, III e IV.
D I, II e III.
E I e IV.
48 de 50
DW, ETL e Data Mart

Gabarito: E
16712855225
49 de 50
DW, ETL e Data Mart

Consideraes Finais
Chegamos ao final da nossa aula de business intelligence que tratou dos
aspectos de DW, modelagem e ETL!
Outros assuntos dentro deste tema estaro presentes nas prximas aulas.
At a prxima!
Thiago Cavalcanti
16712855225
50 de 50

DW, modelagem e ETL

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

DW, modelagem e ETL

Încărcat de

Drepturi de autor:

Formate disponibile

Aula 01

Business Intelligence para Concursos - Curso Regular

DW, ETL e Data Mart

AULA 01: Data Warehouse, Modelagem

1.1. Conceitos e caractersticas

Kimball: um conjunto de ferramentas e tcnicas de projeto, que quando

Laudon&Laudon: Banco de dados, com ferramentas de consulta e

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

Inmon: uma coleo de dados orientados por assunto, integrados,

Um primeiro comentrio interessante sobre essas definies, em especial

Ser orientado por assunto refere-se ao fato do Data Warehouse

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

O fato de ser no voltil significa que o Data Warehouse permite apenas

No ambiente operacional, ao contrrio, os dados so, em geral,

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

Ser variante no tempo trata do fato de um registro em um Data

A prxima caracterstica que temos nos DW o tratamento da

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

Resumo: Requisitos e princpios que orientam um projeto de DW

O armazenamento de dados operacionais (ODS) se concentra em um

DW, ETL e Data Mart

Um ODS usado para decises de curto prazo envolvendo aplicaes de

DW, ETL e Data Mart

As fontes de dados (Data source) - Os dados so provenientes de vrios

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

H quatro componentes separados e distintos a serem considerados no

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

Data Marts (DM) independentes. Esta sem dvida a arquitetura mais

DW, ETL e Data Mart

Quando os usurios escolherem objetos de consulta a partir deste ponto

DW, ETL e Data Mart

1.5. Kimball x Inmon

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

As tabelas Fato servem para o armazenamento, medidas (quase sempre)

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

A ideia de que um evento de medio no mundo fsico tenha uma relao

Todas as tabelas fato tm duas ou mais chaves estrangeiras que ligam

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

Ok! Antes de continuarmos nosso estudo e juntarmos as tabelas

2.1. Star Schema

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

A primeira coisa a notar sobre o esquema dimensional a sua

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

2.2. Processo de design dimensional

Passo 02: Declare a granularidade

DW, ETL e Data Mart

Passo 04: Identificando os fatos

Prof. Thiago Rodrigues Cavalcanti

DW, ETL e Data Mart

2.3. Revisitando o modelo

Se a mesma medida aparece em tabelas fatos separados, os

DW, ETL e Data Mart