PÓS-GRADUAÇÃO LATO SENSU

Transcrição

1 PÓS-GRADUAÇÃO LATO SENSU Curso: Banco de Dados Disciplina: Data Warehouse e Business Intelligence; Laboratório Professor: Fernando Zaidan Unidade

2 ACOMPANHAMENTO 9 CONTACTO ÁREAS DE NEGÓCIOS 1 PLANEJAMENTO/ LEVANTAMENTO DIFICULDADES DE INFORMAÇÃO GERENCIAL->OBJETIVO INDICADORES ESTRATÉGICOS-MÉTRICAS INICIAIS RESTRIÇÕES DE INFORMAÇÕES-ESTRUTURA-TECNOLOGIA INFORMAÇÕES JÁ EXISTENTES NO DW-METADADOS REUNIÕES JAD-PARTICIPAÇÃO INTENSA USUÁRIOS DEFINIÇÃO DE PATROCINADOR DEFINIÇÃO DE EQUIPE DE PROJETO IMPLEMENTAÇÃO 8 7 PROJETO DW/DM 2 3 REUNIÕES DE TRABALHO DETALHAMENTO DE NECESSIDADES DIMENSÕES-FATOS MÉTRICAS-GRANULARIDADE TESTE PROJETO-MODELAGEM DIMENSIONAL CONSTRUÇÃO ETC DEFINIÇÃO DO ETC- EXTRAÇAÕ-TRANSFORMAÇÃO-CARGA CUBOS RELATÓRIOS ANALÍTICOS INFERENCIAIS PROJETO FÍSICO DW/DM PROJETO OLAP MINING 2

3 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 3

4 Data Warehouse

5 MODELAGEM DIMENSIONAL A modelagem dimensional é a técnica utilizada para se ter uma visão multidimensional dos dados e não uma visão simplista. TABELAS FATOS MÉTRICAS E VALORES TABELAS DIMENSÃO TEXTOS, CAMPOS DIVERSOS 5

6 GRANULARIDADE HIERARQUIA DE DIMENSÕES MODELO DIMENSIONAL CONCEITOS DIMENSÃO PRODUTO PAIS CATEGORIA TABELAS DIMENSÃO REGIÃO SUB CATEGORIA ANO ESTADO PRODUTO TRIM CIDADE LOJA VENDAS TABELA FATO MES DIA DIMENSÃO GEOGRAFIA MÉTRICAS: QUANTIDADE VALOR DIMENSÃO TEMPO 6

7 MODELAGEM DIMENSIONAL ESTRUTURAS 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 7

8 MODELAGEM DIMENSIONAL ESTRUTURAS SCHEMA ESTRELA 8

9 MODELAGEM DIMENSIONAL ESTRUTURAS SCHEMA SNOWFLAKE 9

10 SCHEMA STARFLAKE GALAXY vários FATOS 10

11 SNOWFLAKE-TABELAS NORMALIZADAS, INDEPENDENTES, COM JOIN MODELO DIMENSIONAL CONCEITOS-II DIMENSÃO PRODUTO JOIN PAIS CATEGORIA REGIÃO CATEGORIA SUB SUB CATEGORIA CATEGORIA PRODUTO ESTADO CIDADE PRODUTO STAR SCHEMA-DADOS CONSOLIDADOS NUMA MESMA TABELA NÃO NORMALIZADA EVITA JOIN LOJA DIMENSÃO GEOGRAFIA VENDAS MÉTRICAS: QUANTIDADE VALOR 11

12 MODELO DIMENSIONAL CONCEITO STARFLAKE PAIS CATEGORIA DIMENSÃO PRODUTO REGIÃO ESTADO SUB CATEGORIA PRODUTO ANO TRIM CIDADE MÉTRICAS: QUANTIDADE VALOR MES LOJA VENDAS DIA DIMENSÃO GEOGRAFIA CLIENTE M X N C/C DIMENSÃO TEMPO DIMENSÃO CLIENTE CARACTE- RISTICAS 12

13 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 13

14 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 14

15 DIMENSÃO GEOGRAFIA MODELO DIMENSIONAL GRANULARIDADE PAIS CATEGORIA DIMENSÃO PRODUTO REGIÃO ESTADO SUB CATEGORIA PRODUTO ANO TRIM CIDADE MÉTRICAS: QUANTIDADE VALOR MES LOJA X VENDAS DIA ITEM NF GRANULARIDADE MENOR DIMENSÃO TEMPO 15

16 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 16

17 DIMENSÕES EM 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 17

18 DIMENSÕES EM 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 18

19 HIERARQUIAS DIMENSÕES CLIENTE PAÍS ESTADO CIDADE 2 HIERARQUIAS SHIP TO BILL TO VENDAS DIMENSÃO TEMPO ANO TRIM CLIENTE MES DIA ZONA VENDA REGIÃO VENDA PRODUTO MARCA CLASSE CALENDÁRIO NORMAL CALENDÁRIO FISCAL TERRIT. VENDAS DIMENSÕES PRODUTO 19

20 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) 20

21 DIMENSÃO TEMPO (QUASE) SEMPRE PRESENTE NOS MODELOS DIMENSIONAIS TABELA DIMENSÃO TEMPO PADRÃO: CHAVE DE DATA(PK) DATA-COMPLETA( ) 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 21

22 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 22

23 CHAVES DE DIMENSÕES E 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 23

24 CHAVES SURROGATE DIMENSÃO TFATO K1 P S K1 S MÉTRICAS CHAVE SURROGATE: NÚMERICA, NEUTRA GERADA, SEQUENCIAL TIPO IDENTITY NORMALMENTE 4 BYTES 24

25 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 25

26 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) 26

27 FATOS E DADOS HETEROGENEIDADE 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 27

28 CONTA CORRENTE CLASSIFICADOS EM BANCO PRODUTOS CONTA POUPANÇA É FORMADO DE PERTENCEM A POSSUEM ASSOCIADOS A EMPRÉSTIMO SFH AGÊNCIAS CLIENTE TRABALHAM COM ASSOCIADOS A POSSUEM ASSOCIADOS A DOMICÍLIO ASSOCIADOS A CONTAS RELATIVAS A INVESTIMENTO EMPRÉSTIMO PESSOAL CARTÃO CRÉDITO 28

29 FATOS MULTI-DADOS AGÊNCIA SALDO CONTA CHAVE-CONTA CHAVE-AGÊNCIA CHAVE-PRODUTO CHAVE-TEMPO PRODUTO MÉTRICA TEMPO 29

30 CONTA AGÊNCIA TEMPO FATOS CHAVE-CONTA CHAVE-PRODUTO- EMP.PESSOAL CHAVE-TEMPO CHAVE-AGÊNCIA PRODUTO EMP. PESSOAL MÉTRICAS EMP.PESSOAL FATOS CHAVE-CONTA CHAVE-PRODUTO- C.CRÉDITO CHAVE-TEMPO CHAVE-AGÊNCIA PRODUTO C.CRÉDITO MÉTRICAS C.CRÉDITO FATOS CHAVE-CONTA CHAVE-PRODUTO- INVESTIMENTO CHAVE-TEMPO CHAVE-AGÊNCIA PRODUTO INVESTIMENTO MÉTRICAS INVESTIMENTO FATOS CHAVE-CONTA CHAVE-PRODUTO- SFH CHAVE-TEMPO CHAVE-AGÊNCIA PRODUTO SFH MÉTRICAS SFH FATOS CHAVE-CONTA CHAVE-PRODUTO- POUPANÇA CHAVE-TEMPO CHAVE-AGÊNCIA PRODUTO POUPANÇA MÉTRICAS C.POUPANÇA FATOS CHAVE-CONTA CHAVE-PRODUTO- C.CORRENTE CHAVE-TEMPO CHAVE-AGÊNCIA PRODUTO C.CORRENTE MÉTRICAS C.CORRENTE DIMENSÕES COMPARTILHADAS DIMENSÕES ESPECIALIZADAS 30

31 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 31

32 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 32

33 Passos da Modelagem Dimensional 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 relacionamento Definição dos atributos da tabela fato - Definição das chaves - Definição das Métricas

34 Erros Comuns a Evitar em Projetos de Data Warehouse Aceitar a premissa de que os responsáveis pelos sistemas operacionais da organização são muito importantes e ocupados para gastar tempo com a equipe de DW. Assegurar para o pessoal de suporte do DW escritórios agradáveis no prédio da TI, que fica próximo dos usuários de negócio. Treinar cada usuário em cada característica da ferramenta de acesso a dados. Adiar o treinamento sobre conteúdo de dados porque a aula usa dados falsos (os dados reais não estarão prontos nos próximos dois meses). Fonte: Marcos André Gonçalves 34

35 Erros Comuns a Evitar em Modelagem 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. Fonte: Marcos André Gonçalves 35

36 Erros Comuns a Evitar em Modelagem Dimensional Não conversar com os usuários de negócio. Não encorajar os usuários de negócio a dar feedback contínuo ao longo do ciclo de desenvolvimento sobre novas fontes de dados e métricas chaves de desempenho que eles gostariam de acessar, e não assegurar a inclusão desses requisitos na release em desenvolvimento. Fonte: Marcos André Gonçalves 36

37 Exemplos de Modelagem

38 Exemplo 1 DER Sistema de Locadora

39 Exemplo 1 DW Sistema de Locadora

40 Debate: PK na Tabela Fato Qual o motivo usar a PK da tabela Fato, composta das FK das Dimensões, e não usar um novo atributo SK? 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. 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.

41 Exemplo 2 DW Sistema Acadêmico

42 ERROS Exemplo 3 DW Sistema Acadêmico

43 Exemplo 4 - DER - Sistema Vendas 1

44 Exemplo 4 - Sistema Vendas Ideia para modelagem

45 Exemplo 4 - DW - Sistema Vendas

46 Exemplo 5 - DER - Sistema Vendas 2

47 Exemplo 5 - DW - Sistema Vendas 2 Resolver o problema de Key Violation

48 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)

49 Bibliografia BARBIERI, Carlos. BI - Business Inteligence: Modelagem e tecnologia. Rio de Janeiro, Axcel Books, CAMPOS, M. L. Data Ware Housing. UFRJ, 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, 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 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.

50 Bibliografia INMON, William. What is Data Warehouse? UNjobs, acessado em 19 de abril de 2009, disponível em < SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. Tradução da 5ª Edição. São Paulo: Campus, TERESKO, John. Information Rich, Knowledge Poor? IndustryWeek.com, acessado em 19 de abril de 2009, disponível em < >

51 Obrigado e bom trabalho, Zaidan fhzaidan@gmail.com 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 Klink