definicoes modelagem dimensional

48
Sistemas de Suporte à Decisão Conceitos Fundamentais Wesley Vaz

Upload: davi-borges

Post on 04-Jul-2015

456 views

Category:

Documents


0 download

TRANSCRIPT

Sistemas de Suporte DecisoConceitos Fundamentais

Wesley Vaz

Definies DW Uma srie de snapshots extrados dos sistemas transacionais de negcio

Definies DW um repositrio Orientado a assuntos Integrado Variante no Tempo No-voltil

Objetivos do DW Acessar os dados da empresaO acesso deve ser simples e rpido

Prover dados consistentes Agrupar dados de acordo com as medidas do negcioDados so armazenados em dimenses de negcio (pontos de vista)

Prover acesso a ferramentas para filtragem, anlise e apresentao dos dados e resultados. Permitir publicaes dos dados disponveis Melhorar os processos de negcios empresariais

Objetivos do DWDados estranhos que batem porta do DW frequentemente ilustram a necessidade urgente da reengenharia dos processos de negcio

Ralph Kimball

Modelo Transacional x Dimensional Exerccio: Construir um modelo de dados que contemple a operacionalizao dos processos de uma loja que comercializa qualquer produto (alimentos, carros, roupas ntimas, etc.)

Modelo Transacional x Dimensional Exerccio: Construir um modelo de dados que contemple as consultas possivelmente demandadas para uma loja que comercializa qualquer produto (alimentos, carros, roupas ntimas, etc.)

Arquitetura de um SSD

Data Marts O crescimento do DW em tamanho e complexidade pode tornar seu uso complicado Usurios tpicos de um Data Mart o tomador de decises de uma parte funcional da organizao Atividades tpicas dos usurios so consultas aleatrias, ou uma pesquisa de excees, modelar variveis estatsticas e anlise what-if Ns devemos diferenciar entre Data Marts com ou sem dados do DW da companhia (data marts cooperativos ou independentes)

Data Marts O Data Mart Focado em um processo de negcio da empresa Usualmente composto por dados de um nmero reduzido de fontes de dados Serve a um nmero reduzido de usurios Necessita de menos armazenamento e capacidade de clculo Introduzido antes do DW Pode ser entendido e utilizado por usurios com menos esforo

Data Marts Cooperativos

Data Warehousing O DW no pode ser comprado. Deve ser construdo. Simplificadamente, um processo de Data Warehousing composto de: Projeto Implementao Alimentao Gerenciamento Uso

Projeto de DW Passos para a modelagem dimensional e projeto de DW Escolha dos processos de negcio a serem analisados Escolha a frequncia dos dados que descrevem o processo (gro) Encontre os objetos que descrevem o processo (dimenses) Encontre as medidas de negcio a serem analisadas O mais importante: sempre cheque se os dados requeridos esto disponveis nos sistemas fonte.

Sobre as fontes de dados O DW no produz novos dados, apenas os usa O DW reage aos dados errneos dos sistemas transacionais. Quando o crdito nos dados do DW diminui, o DW se torna intil Dados errneos no so enganos de usurios do demnio, mas frequentemente indica um stress entre processos de TI e processos de negcio A limpeza dos dados um dos mais dolorosos elementos dos processos de Data Warehousing

Lio #1

O DW no um produto. uma estratgia implementada atravs de um projeto de TI

Detalhamento dos Componentes do DW

Detalhamento dos Componentes do DW Data Staging Area Se situa entre as camadas de apresentao e origem dos dados No deve estar acessvel aos usurios e nem fornecer servios de consulta nem de apresentao rea de transformao Correes de erros Tratamento de elementos ausentes Combinao de dados de vrias origens Atribuio de chaves do DW

Pode conter estruturas de dados normalizadas ou formada por sistemas de arquivos simples Por padro, os bancos de dados normalizados so excludos da camada de apresentao do DW, que deve estar estruturada de forma dimensional

Detalhamento dos Componentes do DW rea de Apresentao Local onde os dados se tornam disponveis para serem consultados Geralmente se constitui de uma srie de data marts integrados Os data marts so modelados segundo os princpios dimensionais, cujos principais objetivos so: Facilidade de entendimento do usurio Desempenho de consulta Flexibilidade de adaptao mudanas

Preferncia no armazenamento de dados detalhados e atmicos Os dados devem obedecer arquitetura de barramento do DW (fatos e dimenses em conformidade) Pode se basear em bancos de dados relacionais ou bancos de dados multidimensionais (projeto lgico comum e implementao fsica diferente)

Detalhamento dos Componentes do DW Metadados Todas as informaes no ambiente do DW que no so os dados propriamente ditos Do suporte : Documentao dos processos de ETL Documentao dos bancos de dados de origem Descrio das variveis dos processos de negcio Descrio das regras de carga Documentao dos processos de segurana

A modelagem dos metadados difcil e to importante para a manuteno efetiva do DW quanto a sua modelagem dimensional

Agenda Reviso da arquitetura bsica de DW Tcnicas para obteno de requisitos de Sistemas de Suporte Deciso Atividade em grupo: Entrega do relatrio de levantamento preliminar do assunto resultado de franquias de fast food Orientao individual para o trabalho de concluso do curso

Detalhamento dos Componentes do DW

Operational Data Store (ODS) Cpias integradas e frequentemente atualizadas dos dados operacionais. implementado para produzir relatrios operacionais, ausentes nos sistemas legados, que atendem s exigncias de tomada de deciso da empresa. Ento, qual a diferena entre o ODS e o DW? As agregaes As sequncias histricas A ampla atribuio descritiva (metadados de negcio)

Alm disso, alguns ODS visam produzir informaes em tempo real O ODS se configura como um terceiro repositrio fsico alm do OLTP e DW A tendncia atual projetar o ODS no DW convencional (dados mais granulares e abrangentes)

Evoluo do Sistema de Suporte Deciso A existncia de ODS, a boa estruturao e documentao dos sistemas existentes e a infra-estrutura fsica so facilitadores da construo Portanto, construir um DW no se resume a implementar de forma melhorada os relatrios implementados no ODS. O processo permite a reavaliao das funcionalidades necessrias alm do nivelamento conceitual entre as partes envolvidas, em relao aos termos de negcio

Modelos para os componentes da arquitetura Fontes de dados: apresenta-se modelados atravs de diversas tecnologias: Relacional, Orientado a objetos Hierrquico Definio de estruturas de arquivos

Camada de ETL: camada de integrao, limpeza e preparao dos dados para insero no DW, podendo ser modelada como: Banco de dados: relacional, multidimensional ou hbrida Arquivos: estruturas de dados do mesmo

Modelos para os componentes da arquitetura Banco de dados do DW: Relacional (normalizado) Multidimensional ou modelo estrela (com ou sem representao explcita das hierarquias snow-flake)

Banco de dados do Data mart: Relacional (normalizado) Multidimensional ou modelo estrela (com ou sem representao explcita das hierarquias snow-flake)

Camada de apresentao: Normalmente em uma estrutura multidimensional com as hierarquias representadas de forma explcita

Modelo Multidimensional Consiste de abordagem lgica de modelagem que dispe os dados de forma intuitiva e que possibilite um acesso com alto desempenho [Kimball, 1998] Utiliza-se de princpios do modelo relacional, mas cada representao composta por uma tabela com mltiplas chaves (denominada de fato) e um conjunto de tabelas que se ligam a esta central (denominadas de dimenses)

Modelo Multidimensional Esta estrutura deriva terminologias alternativas para o modelo: Modelo estrela Star schema Modelo dimensional Modelagem de cubos

O propsito da abordagem consiste em representar os principais elementos do negcio da organizao que sero utilizados como base para o processo analtico e de suporte a deciso

Modelo Multidimensional Tabela Fato: consiste da representao dos elementos centrais do negcio sendo estes definidos por: Medidas: atributos numricos e aditivos que atribui valor ao negcio Dimenses: caracteriza as medidas presentes na fato, atribuindo significado e perspectivas de anlises das mesmas Atributos: consiste de dados descritivos das dimenses

Modelo Multidimensional Exemplo: anlise do volume de vendas de produtos por regio, produto, tempo e clienteTEMPO DATA REGIO MUNICIPIO ESTADO REGIAO FATO VENDAS VALOR QUANTIDADE

PRODUTO CODIGO NOME CATEGORIA

CLIENTE NOME ENDEREO TELEFONE

Modelagem Multidimensional Caractersticas - Kimball Adequado para o desenvolvimento das aplicaes analticas proporcionando uma organizao dos dados de forma intuitiva e prtica A organizao em estrela (star-join) proporciona ao usurio pontos de partida distintos para a realizao de suas anlises, permitindo diversas possibilidades para as mesmas Cada dimenso da fato se apresenta de forma equivalente para este processo

Modelagem Multidimensional Caractersticas - Kimball Atualizao do modelo de dados, realizada com critrio, pois deve-se considerar alguns pontos: Qualquer atualizao no esquema de dados j existente: insero de novos atributos nas dimenses Insero de novas dimenses para as fatos Insero de novas medidas nas fatos

Deve-se interpret-las que, para efeito de anlise, os dados anteriores (j carregados na base) no iro apresentar valores equivalentes para as novas estruturas

Modelagem Multidimensional Caractersticas - Kimball Atualizao do modelo de dados: Insero de novas realizada de forma transparente, resultando na possibilidade de um desenvolvimento incremental do DW/DM; Importante garantir a consistncia na definio das novas dimenses com as j existentes no modelo de dados Dimenses em conformidade

O conceito de cubo Viso da informao em vrias dimenses; Cada dimenso composta por um conjunto de atributos Permite a definio de diversos tipos de cruzamento de dados envolvendo as suas dimenses;

Regio

Produto Cubo com 3 dimenses

Te m po

Interpretando um cubo Um cubo com vrias dimenses representa um fato (item de negcio que ser base para anlise): Vendas;

Cada dimenso representa um fator que possa caracterizar a informao representada no fato: Produto Tempo Cliente Regio Volume de vendas; Valor das vendas; Descontos aplicados; Quantidade vendida

As clulas do cubo representa medidas sobre o fato:

Modelagem Multidimensional Terminologia Medidas: consiste em um dado que o analista utiliza em suas consultas, para avaliar ou medir o desempenho/ comportamento do negcio. Exemplos: Volume de vendas; Quantidade Vendida; Lucro obtido; Custo de divulgao da campanha; Custo de distribuio do produto; ....

Modelagem Multidimensional Terminologia Dimenso: consiste em uma entidade ou uma coleo de entidades, utilizada para caracterizar o conjunto de medidas presentes nos fatos. Ex: Produto, Cliente, Tempo, Regio, etc.

O conjunto de dimenses de um fato determina o contexto da informao a ser analisada e suas medidas. Ex: Volume de vendas que definido em funo do produto, cliente, tempo e regio.

As dimenses podem representar: entidades, atributos, hierarquias e caminhos para agregaes;

Modelagem Multidimensional Terminologia Fato: consiste em uma coleo medidas e suas dimenses associadas, representadas por suas chaves primrias; Um fato representa um objeto de negcio, uma transao comercial, ou um evento definido pelo analista de negcio; Os fatos contem: ligaes com as dimenses, medidas e atributos de suporte informao representada;

De onde vm as informaes que teremos para a construo de um SSD?

Levantamento de Requisitos Funcionais No-funcionais

A modelagem diretamente derivada dos requisitos funcionais de negcio Para que se possa definir os requisitos funcionais de negcio, necessrio que ocorram algumas atividades dentro da disciplina de requisitos Planejamento Anlise Detalhamento Reviso Homologao

Como obter os requisitos funcionais referentes ao DW?

O entendimento prvio do contexto aconselhvel, A organizao dos sistemas importante e O apoio dos usurios essencial!!! O principal questionamento inicial : o que ?, e no como ?. Os requisitos so considerados aps uma anlise inicial da disponibilidade dos dados

Requisitos Casos de uso so ferramentas conceituais que buscam descrever os requisitos baseadas nos cenrios onde eles se inserem Por serem os casos de uso ferramentas genricas de descrio de cenrios, eles se aplicam tambm ao desenvolvimento de data marts Para cada assunto definido, so necessrias os casos de uso referentes insero dos dados necessrios ao DW (disponibilizar) e apresentao dos dados ao usurio (analisar)

Requisitos Quatro diferentes tipos de casos de uso podem ser usados neste ambiente Os casos de uso do tipo inserir no DW ilustram as medidas, indicadores, dimenses e atributos de dimenses Os casos de uso do tipo analisar os dados ilustram os indicadores e medidas, alm dos relatrios padro requeridos pelos usurios Os casos de uso de arquitetura ilustram o ambiente e a ordem na qual as atividades devem ser executadas Os casos de uso de integrao ilustram os procedimentos necessrios para a garantia das funcionalidades previstas

Requisitos Os casos de uso responsveis por inserir e disponibilizar ao usurio informaes dos repositrios devem conter primordialmente Descrio e detalhamento das informaes desejadas (indicadores e medidas) Descrio e detalhamento das vises de anlise (dimenses) Descrio e detalhamento de relatrios requeridos

Duas reas de pesquisa importantes na rea se referem : documentao padronizada de requisitos usando casos de uso utilizao dos casos de uso para elaborao de mtricas de projetos de DW

Requisitos Regras bsicas para a eficcia de uma entrevista: Ouvir e absorver todas as informaes No se aprofundar muito rapidamente no assunto Estar atento terminologia de comunicao distintas entre empresas e departamentos Entender e usar o vocabulrio do usurio

Requisitos Quadrante de prioridades:

Alto

Game de Requisitos (parte I) Problema: A idia construir um modelo dimensional de dados que contemple um sistema de apoio deciso Conseguir extrair as informaes necessrias para um sistema de apoio deciso atravs de perguntas pontuais com o cliente Preencher o documento em anexo que auxilia a construo do modelo dimensional A turma ser dividida em grupos de quatro pessoas Confirme com o usurio os pontos levantados, considerando todos os dados por ele ilustrados estarem disponveis nos sistemas fonte

Objetivo:

Regras:

Dica:

Terminologia da Modelagem Dimensional Palavras-chave: Desempenho Capacidade de Compreenso

Tabelas de FATO Armazenam as medies numricas de variveis do negcio Todas as medies devem estar alinhadas na mesma granularidade Representam relaes de muitos-para-muitos em modelos dimensionais Geralmente sua chave primria composta com um subconjunto das chaves estrangeiras. Entretanto, excees sob perspectivas de negcio podem sugerir a criao de uma chave primria artificial como boa prtica

Terminologia da Modelagem Dimensional Tabelas de Dimenso Contm as descries dos pontos de vista dos processos de negcio Fonte de restries de consultas e agrupamentos dos relatrios Tende a ter muitos atributos e um nmero reduzido de linhas se comparada tabela fato Os melhores atributos para estas tabelas so os textuais e discretos Representam relaes hierrquicas ( aconselhvel implementar redundncia na descrio dos nveis hierrquicos optando pela simplicidade e acessibilidade)

FATO + DIMENSES =ACORDAOSEQ NOME_COLEGIADO_ACORDAO NUM_DECISAO ANO_DECISAO COD_TIPO_DECISAO NUM_ATA SIGLA_COLEGIADO_DECISAO

FK_SOB_ACORDAO_SOBRESTANTE

Star Schema x Snowflake Schema

ESTADO_PROCESSOEST_SEQ EST_COD_ESTADO_PROCESSO EST_DESCRICAO_ESTADO_PROCESSO EST_DATA_FIM EST_DATA_INICIO

FATO_SOBRESTAMENTOSEQ DESCR_SOBRESTAMENTO DATA_INICIO COMPLEMENTO_ASSUNTO DATA_ULTIMA_INSTRUCAO_MERITO NOME_RELATOR DATA_ENTRADA_UNIDADE_LOCAL SIGLA_TIPO_PROCESSO DATA_ULTIMA_APRECIACAO_CONC IND_PEND_INSTRUCAO_MERITO DATA_AUTUACAO SIGLA_UNIDADE_INTERESSADA SIGLA_UNIDADE_LOCALIZACAO IND_PEND_APRECIACAO_CONCLUSIVA SEQ COD_PROCESSO NUM_DV_PROCESSO NUM_PROCESSO DATA_FIM SEQ_ESTADO_PROC_SOBRESTANTE SEQ_PROCESSO_SOBRESTANTE SEQ_PROCESSO_SOBRESTADO SEQ_MOTIVO_SOBRESTAMENTO SEQ_ACORDAO_SOBRESTANTE

PROCESSO FK_SOB_PROCESSO_SOBRESTADO FK_SOB_PROCESSO_SOBRESTANTE

FK_SOB_ESTADO_PROC_SOBRESTANTE

Mitos que cercam a modelagem dimensional Os data marts so usados apenas para dados de resumo Os data marts so solues departamentais e no corporativas Os data marts no so escalonveis Os data marts so apropriados apenas quando existe um padro de utilizao previsvel Os data marts no podem ser integrados e, portanto, levam a solues isoladas

Armadilhas Ficar envolvido pela tecnologia e esquecer os objetivos da empresa No possuir um patrocinador influente e acessvel Desenvolver o projeto de forma monoltica e no iterativa Empenhar-se em construir uma staging area excelente ao invs de focar a rea de apresentao Priorizar a facilidade de desenvolvimento em detrimento do desempenho da consulta Tornar complexos de maneira desnecessria os dados da rea de apresentao Preencher os modelos dimensionais sem considerar as dimenses compartilhadas Carregar apenas dados de resumo Presumir que as exigncias da empresa, anlises e tecnologia so sempre estticos No aceitar que o sucesso est diretamente relacionado aceitao por parte de quem manda: os usurios