Upload
doanphuc
View
214
Download
0
Embed Size (px)
Citation preview
PÓS-GRADUAÇÃO LATO SENSU
Curso: Banco de Dados
Disciplina: Data Warehouse e Business Intelligence;
Laboratório
Professor: Fernando Zaidan
Unidade 2.12016
PROJETODW/DM
REUNIÕES DE TRABALHODETALHAMENTO DE NECESSIDADESDIMENSÕES-FATOSMÉTRICAS-GRANULARIDADE
DEFINIÇÃO DO ETC-EXTRAÇAÕ-TRANSFORMAÇÃO-CARGA
ETC
PROJETO FÍSICO DW/DMPROJETO OLAPMINING
1
2
3
45
7
9
8
PROJETO-MODELAGEMDIMENSIONAL
PLANEJAMENTO/ LEVANTAMENTODIFICULDADES DE INFORMAÇÃO GERENCIAL->OBJETIVOINDICADORES ESTRATÉGICOS-MÉTRICAS INICIAISRESTRIÇÕES DE INFORMAÇÕES-ESTRUTURA-TECNOLOGIAINFORMAÇÕES JÁ EXISTENTES NO DW-METADADOSREUNIÕES JAD-PARTICIPAÇÃO INTENSA USUÁRIOSDEFINIÇÃO DE PATROCINADORDEFINIÇÃO DE EQUIPE DE PROJETO
CONTACTOÁREASDE NEGÓCIOS
IMPLEMENTAÇÃO
TESTE 6
ACOMPANHAMENTO
CONSTRUÇÃO
CUBOSRELATÓRIOSANALÍTICOSINFERENCIAIS
Fonte: Carlos Barbieri
2
LEVANTAMENTO DE NECESSIDADES
• DEFINIR AS NECESSIDADES DE INFORMAÇÃO PARA O NEGÓCIO:– DIFICULDADES-RESTRIÇÕES SUGEREM
OBJETIVOS• INDICADORES,MÉTRICAS,COMPARATIVOS• SEMPRE OBSERVAR “DIMENSÕES”/COMBINAÇÕES
– MODELO DE DADOS EXISTENTES:– ENTIDADES-RELACIONAMENTOS-ATRIBUTOS-
(KEYS-ORIGINAIS-DERIVADOS)-PROPORÇÕES
– ARQUIVOS, DADOS MANUAIS EXISTENTES
Fonte: Carlos Barbieri3
Data Warehouse
MODELAGEM DIMENSIONAL
• TABELAS FATOS– MÉTRICAS E VALORES
• TABELAS DIMENSÃO– TEXTOS, CAMPOS DIVERSOS
Fonte: Carlos Barbieri 5
A modelagem dimensional é a técnica utilizada para se ter uma visão multidimensional dos dados e não uma visão simplista.
MODELO DIMENSIONALCONCEITOS
VENDAS
PAIS
REGIÃO
ESTADOTRIM
ANO
DIMENSÃOGEOGRAFIA DIMENSÃO
TEMPO
DIMENSÃOPRODUTO
LOJA
CIDADE
DIA
MES
GRANULARIDADE
MÉTRICAS:•QUANTIDADE•VALOR
CATEGORIA
SUBCATEGORIA
PRODUTO
HIERARQUIA DE DIMENSÕES
TABELASDIMENSÃO
TABELAFATO
Fonte: Carlos Barbieri6
MODELAGEM DIMENSIONALESTRUTURAS
• SCHEMA ESTRELA:– DIMENSÕES DESNORMALIZADAS– VOLTADO PARA ACESSOS C/ PERFORMANCE– HIERARQUIAS ACHATADAS
• SCHEMA SNOWFLAKE (flocos de neve):– TRADICIONAL+ E/R(TABELAS EM CASCATA)– NORMALIZADO– HIERAQUIAS MANTIDAS– MUITAS TABELAS-->MUITAS JUNÇÕES-1:N
• SCHEMA STARFLAKE– COMBINAÇÃO DAS DUAS– DIMENSÕES COM M X N COM OUTRAS TABELAS
Fonte: Carlos Barbieri7
MODELAGEM DIMENSIONALESTRUTURAS
SCHEMA ESTRELA
8
MODELAGEM DIMENSIONALESTRUTURAS
SCHEMA SNOWFLAKE
9
SCHEMA STARFLAKE
GALAXY – vários FATOS
10
MODELO DIMENSIONALCONCEITOS-II
VENDAS
PAIS
REGIÃO
ESTADO
DIMENSÃOGEOGRAFIA
DIMENSÃOPRODUTO
LOJA
CIDADE
MÉTRICAS:•QUANTIDADE•VALOR
CATEGORIA
SUBCATEGORIA
PRODUTO
SNOWFLAKE-TABELAS NORMALIZADAS,INDEPENDENTES, COMJOIN
CATEGORIASUB
CATEGORIAPRODUTO
STAR SCHEMA-DADOS CONSOLIDADOSNUMA MESMA TABELANÃO NORMALIZADAEVITA JOIN
JOIN
Fonte: Carlos Barbieri11
MODELO DIMENSIONALCONCEITO STARFLAKE
VENDAS
PAIS
REGIÃO
ESTADOTRIM
ANO
DIMENSÃOGEOGRAFIA DIMENSÃO
TEMPO
DIMENSÃOPRODUTO
LOJA
CIDADE
DIA
MESMÉTRICAS:•QUANTIDADE•VALOR
CATEGORIA
SUBCATEGORIA
PRODUTO
CLIENTE C/C
CARACTE-RISTICAS
M X N
DIMENSÃOCLIENTE
Fonte: Carlos Barbieri12
MODELAGEM DIMENSIONAL
• TABELAS FATOS:• CONTÉM VALORES(MÉTRICAS)• PODEM TER VÁRIAS NO SCHEMA/DMART
– ESQUEMA MULTIFATO->N CUBOS– CONCEITO DE CONFORMIDADE DE DIMENSÕES
• PK=CONCATENAÇÃO DE FK DAS DIMENSÕES
• TABELAS DIMENSÕES• PONTOS DE ENTRADA• HIERARQUIAS-NÍVEIS DE QUEBRA• GRANULARIDADE COERENTE COM FATO
Fonte: Carlos Barbieri13
GRANULARIDADE DE FATOS E DADOS
– NÍVEL ATÔMICO DE DADOS NA(S) ENTIDADE(S)/TABELA(S) FATO/DIMENSÃO
– POSSIBILIDADES:• NÍVEL DE TRANSAÇÕES(DOCUMENTO-NF)• NÍVEL DE ÍTEM DE UM DOCUMENTO (NF,OC,
OEXPEDIÇÃO, APÓLICE)• TEMPO:
– NÍVEL DIÁRIO– NÍVEL SEMANAL– NÍVEL MENSAL, ETC
• CONSIDERAÇÕES:– VOLUMES DE DADOS– NECESSIDADE DE INFORMAÇÕES P/ NEGÓCIO– DISPONIBILIDADE DO DADO FONTE
Fonte: Carlos Barbieri14
MODELO DIMENSIONALGRANULARIDADE
VENDAS
PAIS
REGIÃO
ESTADOTRIM
ANO
DIMENSÃOGEOGRAFIA
DIMENSÃOTEMPO
DIMENSÃOPRODUTO
LOJA
CIDADE
DIA
MESMÉTRICAS:•QUANTIDADE•VALOR
CATEGORIA
SUBCATEGORIA
PRODUTO
ITEMNF
XGRANULARIDADE
MENOR
Fonte: Carlos Barbieri15
DIMENSÕES– PONTOS DE ENTRADAS DA ESTRUTURA– DIMENSÕES E SEUS ATRIBUTOS SERVEM TAMBÉM COMO
FILTROS E COMO HEADER DOS RELATÓRIOS
– DIMENSÕES TÍPICAS:• PRODUTO/SERVIÇO-O QUE VENDO• CLIENTE-QUEM COMPRA• TEMPO-QUANDO FOI FEITO A COMPRA• LOCAL(ARMAZÉM,LOJA,ETC)-ONDE• STATUS, PROMOÇÕES-CONDIÇÕES DA COMPRA
– DESCREVER TODOS OS ATRIBUTOS DAS DIMENSÕES– DEVEM SER ATRIBUTOS DESCRITIVOS SEM CAMPOS
NULOS– NORMALMENTE UM DM TEM ENTRE 4-15 DIMENSÕES
• MENOS=FALTOU OBSERVAÇÃO(TEMPO-ESPAÇO-TIPO)• MAIS=DIMENSÕES SUPÉRFLUAS
– SÃO OS DESCRITORES DAS TFATOS– CONCEITO DE SK (surrogate Key – chave sequencial) -
INDEPENDÊNCIA
Fonte: Carlos Barbieri16
DIMENSÕESEM HIERARQUIAS
• DIMENSÕES NORMALMENTE TEM HIERARQUIAS• HIERARQUIAS TEM NÍVEIS• NÍVEIS TEM MEMBROS(MEMBERS)• TIPOS DE HIERARQUIA-RELACIONAMENTOS 1:N
– BALANCEADA: N DIFERENTE DE ZERO EM TODOS OS NIVEIS-
• EX: ANO->MÊS->DIA
– DESBALANCEADA: N PODE SER ZERO• EX:ÓRGÃO->DIVISÃO(PODE TER ÓRGÃO SEM DIVISÃO)
– RAGGED: UM DO NÍVEIS PODE NÃO TER MEMBROS• EX: PAIS-ESTADO-CIDADE-EM ISRAEL NÃO TEM ESTADO.
EXISTE SOMENTE CIDADE E PAIS– ESTADO: ASSUME CHAVE DO PAIS OU BRANCO
Fonte: Carlos Barbieri17
DIMENSÕESEM HIERARQUIAS
• DIMENSÕES ESPECIAIS PODEM TER MÚLTIPLAS HIERARQUIAS. EXEMPLO: TEMPO
• TEMPO CALENDÁRIO NORMAL– ANO->TRIMESTRE->MÊS->DIA– COMEÇA EM JANEIRO
• TEMPO CALENDÁRIO FISCAL– ANO->TRIMESTRE->MÊS->DIA– COMEÇA EM ABRIL
• OS SERVIDORES OLAP TRATAM A DIMENSÃO TEMPO COMO ESPECIAL
– PODEM SER OBTIDAS DIRETAMENTE DE UMA FONTE SIMPLES-CAMPO DATA DE UMA TABELA
– PODEM SER OBTIDAS DE UMA TABELA FONTE-DIMENSÃO TEMPO BEM PROJETADA-COM DIA, FERIADOS,TAGS DE FIM DE SEMANA, ETC
• NORMALMENTE DEFINE-SE TEMPO COMO UMA DIMENSÃO A SER COMPARTILHADA COM OS CUBOS DO DMART
Fonte: Carlos Barbieri18
HIERARQUIAS
REGIÃOVENDA
ESTADO
CIDADE VENDAS
PRODUTO
MES
TRIM
ANODIMENSÕESCLIENTE
DIMENSÃOTEMPO
DIMENSÕESPRODUTO
CLIENTE
DIA
MARCA CLASSE
PAÍS
ZONAVENDA
TERRIT. VENDAS
2 HIERARQUIAS• SHIP TO• BILL TO
CALENDÁRIO NORMALCALENDÁRIO FISCAL
Fonte: Carlos Barbieri19
DIMENSÕES COMPARTILHADAS
• A DIMENSÃO É COMPARTILHADA ENTRE VÁRIOS PROJETOS DE DM/DW
• FUNDAMENTAL PARA A INTEGRAÇÃO ENTRE OS VÁRIOS “DMARTS”
• AS DIMENSÕES NORMALMENTE SÃO DESENVOLVIDAS EM SUA MAIOR GRANULARIDADE– TEMPO=> ANO-SEMESTRE-TRIMESTRE-MÊS-DIA– CLIENTE=> TIPO-CLIENTE– GEOGRAFIA==>PAIS-REGIÃO-ESTADO-CIDADE-LOJA
• AS DIMENSÕES PODEM SER COMPARTILHADAS EM HIERARQUIAS PARCIAIS. POR EX: CATEGORIA->SUBCATEGORIA->PRODUTO. SOMENTE VOU COMPARTILHAR NO MEU CUBO CATEGORIA, OU CATEGORIA->SUBCATEGORIA. DESABILITO O NIVEL INDESEJÁVEL(AUTOMATICAMENTE DESABILITAM OS NIVEIS MENORES)
Fonte: Carlos Barbieri20
DIMENSÃO TEMPO
• (QUASE) SEMPRE PRESENTE NOS MODELOS DIMENSIONAIS• TABELA DIMENSÃO TEMPO PADRÃO:
– CHAVE DE DATA(PK)– DATA-COMPLETA(01-01-2010)– DIA-SEMANA(6A FEIRA)– NÚMERO-DIA-MÊS(01)– NÚMERO-DIA-GERAL(CORRIDO NO ANO)(01 a 365)– NÚMERO-SEMANA-ANO(01 a 52)– NÚMERO-SEMANA-GERAL(CORRIDO)– MÊS– NÚMERO-MÊS-GERAL(CORRIDO)– TRIMESTRE– PERÍODO-FISCAL– TAG-DIA-SEMANA– TAG-ÚLTIMO-DIA-MÊS
Fonte: Carlos Barbieri21
DIMENSÃO CLIENTE• MAIOR DETALHAMENTO POSSÍVEL, COM MODELAGEM DOS
ATRIBUTOS COM ALTA INDEPENDÊNCIA ENTRE ELES• TABELA DIMENSÃO CLIENTE PADRÃO:
– CHAVE (PK)
– SAUDAÇÃO EX:MR– ESTILO DE SAUDAÇÃO EX:PROFISSIONAL– PRENOME E MEIO-NOME EX:R. JAMES– SOBRENOME EX: WOOD– SUFIXO EX:JR– ETNIA DO NOME EX:INGLÊS– GÊNERO EX:MASCULINO– TÍTULO EX:ADVOGADO– RELACIONAMENTO
EX:REPRESENTANTE DE JOHN DOE– ORGANIZAÇÃO EX:ABC GENERIC POWER– SUB-ORGANIZAÇÃO
EX:DEPARTAMENTO JURÍDICO– ……
Fonte: Carlos Barbieri22
CHAVES DE DIMENSÕESE DE FATOS
• RECOMENDAÇÃO - USAR SURROGATE KEY(SK)• SK=CHAVE SEQUENCIAL, SEM SENTIDO
EMBUTIDO• CRIA MAIOR ESTABILIDADE• EVITA CONFLITO DE MUDANÇAS DE CHAVES E
DE SUAS SEMÂNTICAS• EVITAR/TER CUIDADO COM O USO DE SMART
KEY(CHAVES COM SEMÂNTICA EMBUTIDA)• 4 BYTES: 2 BILHÕES DE OCORRÊNCIAS DE SK
Fonte: Carlos Barbieri23
CHAVES SURROGATE
K1
TFATO
K1 MÉTRICAS
DIMENSÃO
P S
S
CHAVE SURROGATE:NÚMERICA, NEUTRAGERADA, SEQUENCIALTIPO IDENTITYNORMALMENTE 4 BYTES
24
FATOS E DADOS– ESCOLHER PARA CADA TFATO OS ATRIBUTOS
NUMÉRICOS E ADITIVOS– TÍPICOS:
• QUANTIDADE VENDIDA• VALOR VENDIDO• CUSTO DO PRODUTO (VENDIDO)• LUCRO• CONSUMO
– MANTER CONFORMIDADE/COERÊNCIA TAMBÉM ENTRE FATOS E AS MEDIDAS/VALORES , COM O MESMO SENTIDO, FÓRMULAS DE CÁLCULOS, ETC
– GRANULARIDADE DA TFATO ESTA DIRETAMENTE RELACIONADA COM A DAS TDIM
– LEMBRE-SE PORÉM: AS TFATOS SÃO GIGANTESCAS(ALTO VOLUME) E ISSO REQUER COMPROMISSOS NA ESCOLHA DE SEUS CAMPOS
Fonte: Carlos Barbieri25
FATOS E DADOS• ESCOLHER COM CUIDADO OS CAMPOS, DEVIDO AO
TAMANHO EXPONENCIAL DAS TFATOS• ETERNO COMPROMISSO ENTRE PERFORMANCE E
ARMAZENAMENTO• CAMPOS CANDIDATOS A REMOÇÃO:
– CAMPOS USADOS POR POUCOS USUÁRIOS– CAMPOS POTENCIALMENTE DERIVADOS
• EX: VALOR UNITÁRIO E QUANTIDADE DO ITEM• ARMAZENO O VALOR TOTAL DA VENDA DO
ÍTEM????(V.UNITÁRIO*QUANTIDADE)
– CAMPOS QUE NÃO TENHAM VALOR DE NEGÓCIO – CAMPOS DE DIMENSÕES DEGENERADAS, COMO NÚMERO
DE ORDEM/PEDIDOS, CASO A GRANULARIDADE SEJA O ITEM DESSAS ENTIDADES
• ANALISAR O TAMANHO DE CADA CAMPO– USE CHAVES SURROGATE QUANDO POSSÍVEL(CHAVE DEFINIDA
PELO PROJETO, SEM SIGNIFICADO INTRÍNSECO)
Fonte: Carlos Barbieri26
FATOS E DADOSHETEROGENEIDADE
• PRODUTOS HETEROGÊNEOS• INDÚSTRIA FINANCEIRA• CONTA CORRENTE, SEGURO,EMPRÉSTIMO,
POUPANÇA,HABITAÇÃO, ETC• DIFERENTES FATOS E DADOS PARA CADA
LINHA DE NEGÓCIO• DIMENSÕES COMUNS(CLIENTES, AGÊNCIAS)• ESTRATÉGIA:
– MÚLTIPLAS TABELAS FATO E DADOS ESPECÍFICOS– DIMENSÕES ÚNICAS E CONFORMES
Fonte: Carlos Barbieri27
CLIENTE
AGÊNCIAS
CONTAS
BANCO PRODUTOS
É FORMADO DE
PERTENCEM A
ASSOCIADOS A
TRABALHAM COM
CARTÃOCRÉDITO
CONTACORRENTE
CONTAPOUPANÇA
EMPRÉSTIMOSFH
INVESTIMENTO
EMPRÉSTIMOPESSOAL
DOMICÍLIO
POSSUEM
ASSOCIADOS A
ASSOCIADOS A
RELATIVAS A
CLASSIFICADOS EM
POSSUEM
ASSOCIADOS A
Fonte: Carlos Barbieri28
SALDO
CONTA
AGÊNCIA
CHAVE-CONTACHAVE-AGÊNCIACHAVE-PRODUTOCHAVE-TEMPO
MÉTRICA
TEMPO
PRODUTO
FATOS MULTI-DADOS
Fonte: Carlos Barbieri29
CONTAAGÊNCIA TEMPO
FATOSCHAVE-CONTACHAVE-PRODUTO-EMP.PESSOALCHAVE-TEMPOCHAVE-AGÊNCIA
PRODUTOEMP.
PESSOAL
MÉTRICASEMP.PESSOAL
FATOSCHAVE-CONTACHAVE-PRODUTO-C.CRÉDITOCHAVE-TEMPOCHAVE-AGÊNCIA
PRODUTOC.CRÉDITO
MÉTRICASC.CRÉDITO
FATOSCHAVE-CONTACHAVE-PRODUTO-INVESTIMENTOCHAVE-TEMPOCHAVE-AGÊNCIA
PRODUTOINVESTIMENTO
MÉTRICASINVESTIMENTO
FATOSCHAVE-CONTACHAVE-PRODUTO-SFHCHAVE-TEMPOCHAVE-AGÊNCIA
PRODUTOSFH
MÉTRICASSFH
FATOSCHAVE-CONTACHAVE-PRODUTO-POUPANÇACHAVE-TEMPOCHAVE-AGÊNCIA
PRODUTOPOUPANÇA
MÉTRICASC.POUPANÇA
FATOSCHAVE-CONTACHAVE-PRODUTO-C.CORRENTECHAVE-TEMPOCHAVE-AGÊNCIA
PRODUTOC.CORRENTE
MÉTRICASC.CORRENTE
DIMENSÕESCOMPARTILHADAS
DIMENSÕES ESPECIALIZADAS
Fonte: Carlos Barbieri30
DADOS E FATOS
• ALGUMAS FERRAMENTAS CONSIDERAM A TFATO COMO MAIS UMA DIMENSÃO
• FACILITA O USO DE EXPRESSÕES• OS VALORES DA TFATO ESTÃO SEMPRE ASSOCIADOS A
ELEMENTOS FOLHA DAS DIMENSÕES• LEMBRAR QUE AS FATOS PODERÃO SER PROCESSADAS
POR VÁRIOS TIPOS DE ELABORAÇÃO:– SOMA ( MAIS COMUM)– VALOR MÁXIMO, MÍNIMO, CONTADOR,
CONTADOR(DISTINTO)• AS CÉLULAS DA TFATO PODEM SER CALCULADAS EM
FUNÇÃO DE VALORES DE OUTRAS CÉLULAS DA MESMA TFATO-SÃO OS MEMBROS CALCULADOS– EX: MÉDIA=TOTAL VENDAS/TOTAL UNIDADES VENDIDAS
Fonte: Carlos Barbieri31
DADOS E FATOS
• CONCEITO DE ELEMENTO VIRTUAL– ELEMENTO DEFINIDO NA TFATO, COMO MEDIDA– CALCULADO EM FUNÇÃO DE OUTRO ELEMENTO DA
MESMA DIMENSÃO– POR EXEMPLO: DEFINO UM CAMPO VIRTUAL EM
TFATO CHAMADO MEDIDA DOBRADA– FAÇO MEDIDA DOBRADA= 2 * VALOR DO PRODUTO– FUNCIONA COMO SE TIVESSE DEFINIDO UM NOVO
MEMBRO DE PRODUTO, CUJOS VALORES NA TFATO SÃO SEMPRE O DOBRO DO PRODUTO
Fonte: Carlos Barbieri32
Passos da ModelagemDimensional
Definição da área de negócios;
Definição da granularidade- Menor – mais espaço;- Maior – menos espaço;
Definição das tabelas dimensão;Normalização das tabelas dimensao;- Star Schema - ÑN- Snow Flakes Relacionamento dos atributos da tabela dimensão- Podem possuir ou não relacionamentoDefinição dos atributos da tabela fato- Definição das chaves- Definição das Métricas
Erros Comuns a Evitar emProjetos de Data Warehouse
• Aceitar a premissa de que os responsáveis pelos sistemasoperacionais da organização são muito importantes e ocupadospara gastar tempo com a equipe de DW.
• Assegurar para o pessoal de suporte do DW escritóriosagradáveis no prédio da TI, que fica próximo dos usuários denegócio.
• Treinar cada usuário em cada característica da ferramenta deacesso a dados. Adiar o treinamento sobre conteúdo de dadosporque a aula usa dados falsos (os dados reais não estarãoprontos nos próximos dois meses).
34Fonte: Marcos André Gonçalves
Erros Comuns a Evitar emModelagem Dimensional
• Colocar atributos de texto numa tabela de fatos.• Limitar atributos em dimensões para economizar espaço.• Ignorar a necessidade de cuidar de mudanças em atributos
de dimensões.• Resolver todos os problemas de desempenho de consultas
adicionando mais hardware.• Projetar o modelo dimensional baseado em um
relatório específico.
35
Fonte: Marcos André Gonçalves
Erros Comuns a Evitar emModelagem Dimensional
• Não conversar com os usuários de negócio.
• Não encorajar os usuários de negócio a dar feedbackcontínuo ao longo do ciclo de desenvolvimento sobre novasfontes de dados e métricas chaves de desempenho que elesgostariam de acessar, e não assegurar a inclusão dessesrequisitos na release em desenvolvimento.
36Fonte: Marcos André Gonçalves
Exemplos de Modelagem
Exemplo 1DER – Sistema de Locadora
Exemplo 1DW – Sistema de Locadora
Debate: PK na Tabela Fato
Qual o motivo usar a PK da tabela Fato, composta das FK dasDimensões, e não usar um novo atributo SK?
Agora, a resposta à questão inicial?
1. As chaves que vêm das Dimensões são suficientes para gerar a PK composta da Fato , não necessitando de mais um atributo na Fato.2. Se adicionarmos uma nova coluna na Fato, somente para gerar uma PK, pode criar um overhead desnecessário na manutenção desta tabela, uma vez que nenhuma consulta seria feita por esse campo .
Em primeiro lugar, está claro porque precisamos das PKs das Dimensões como FK da Fato?Para criamos o relacionamento PAI – FILHO (1-N) entre elas. Deste modo, conseguindo relacionar as tabelas.
Exemplo 2DW – Sistema Acadêmico
ERROS
Exemplo 3DW – Sistema Acadêmico
Exemplo 4 - DER - Sistema Vendas 1
Ideia para modelagemExemplo 4 - Sistema Vendas
Exemplo 4 - DW - Sistema Vendas
Exemplo 5 - DER - Sistema Vendas 2
Exemplo 5 - DW - Sistema Vendas 2Resolver o problema de Key Violation
FCS-EM PROJETOS DE DW
• DEFINIR UMA ORIENTAÇÃO METODOLÓGICA– DW OU DMART GRADATIVO-DMART ISOLADO– RALPH KIMBALL - BILL INMON
• DEFINIR UMA ARQUITETURA TECNOLÓGICA CONSISTENTE, MODERNA, EVOLUTIVA
– INTERFACE WEB É UM DIREFERENCIAL
• DEFINIR UMA METODOLOGIA PRÁTICA, ENXUTA, INTERATIVA,REFINAMENTOS SUCESSIVOS E PRODUTOS ENTREGUES EM PRAZO RAZOÁVEL
• DEFINIR EQUIPE, COM PRESERVAÇÃO DO CONHECMENTO APÓS O TÉRMINO DO PROJETO
– CUIDADO COM TERCEIROS-CONSULTORES
• OBTER PATROCINADORES FORTES PARA O PROJETO, COM OBJETIVOS DIRETOS NO NEGÓCIO DA EMPRESA
• DESENVOLVER UM FORTE ESQUEMA DE DEMONSTRAÇÃO DOS PRODUTOS DESENVOLVIDOS(VENDER BEM)
Fonte: Carlos Barbieri
Bibliografia
BARBIERI, Carlos. BI - Business Inteligence: Modelagem e tecnologia. Rio de Janeiro, Axcel Books, 2001.
CAMPOS, M. L. Data Ware Housing. UFRJ, 2007.
COME, Gilberto de. Contribuição ao Estudo da Implementação de Data Warehousing: um caso no setor de telecomunicações – São Paulo : FEA/USP, 2001. 133 p
FANTAUZZI, F. A. C.; ROCHA, Rogério Morais. Diretório de Softwares para Inteligência Competitiva Monografia apresentada ao Departamento de Ciência da informação como requisito para a conclusão do curso de especialização em Gestão Estratégica da Informação da Universidade Federal de Minas Gerais - UFMG, Belo Horizonte, ano de 2006.
FARIA, João Marcos Bonadio de. Artefatos da Semiótica Organizacional na Elicitação de Requisitos para Soluções de Data Warehouse Trabalho final (mestrado profissional) - Universidade Estadual de Campinas, Instituto de Computação, fevereiro de 2006.
Bibliografia
INMON, William. What is Data Warehouse ? UNjobs, acessado em 19 de abril de 2009, disponível em < http://unjobs.org/authors/w.-h.-inmon>
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. Tradução da 5ª Edição. São Paulo: Campus, 2006.
TERESKO, John. Information Rich, Knowledge Poor ? IndustryWeek.com, acessado em 19 de abril de 2009, disponível em < http://www.industryweek.com/PrintArticle.aspx?ArticleID=245 >
Obrigado e bom trabalho,
“Aí está o mérito do êxito de meus projetos: sempre fui muito exigente e rigoroso com procedimentos que aparentemente não faziam muito sentido na época.Mais tarde viu-se que esse rigor fez a diferença entre afundar ou não, concluir ou não um projeto”.
Amyr KlinkAmyr KlinkAmyr KlinkAmyr Klink