Banco de dados

Data Vault

Pode ser aplicado na modelagem de Staging Area, DW e DM

Desafio

Foco continua na flexibilidade do modelo

Novos requisitos levam a evolução das aplicações

Evolução de aplicações ORIGENS podem impor ao DW evoluções dramáticas

Objetivo do Data Vault

Tornar o desenvolvimento e a evolução do DW flexível

Reduzir o ciclo de implementações

Incorporar a visão temporal e atemporal dos dados

Oferecer uma metodologia ágil de desenvolvimento de DW

Como?

Isola a identificação do objeto ou relacionamento de seus atributoa

Certa similaridade com a 6FN

Baseado na organização natural Hub-Spoke

Presente em neurônios e células

Notação

Data Valt utiliza as seguintes notações

Hub Entities

Representa conceitos centrais de um Universo de Discurso

Reúne as chaves próprias utilizadas pelas origens que identificam uma instância de certo objeto

HUB

O cliente "João" é identificado como 126176 pela Origem A e AX - 001233 pela Origem B

Não HUB

O Item de Nota Fiscal é identificado pelo IDProduto e IDNotalFiscal

Pode apresentar outros atributos

Surrogate Key

Data e Hora de carga

Outros atributos com dados relativos à proveniência

Link Entities

Denotam relacionamentos ou transações entre objetos (Hub)

Ex.:Médico FAZ CONSULTA Paciente

Assume sempre a cardinalidade N:N

Logo, sempre haverá um link (uma relação)

Podem haver

Vários objetos

Vários links

Pode ter atributos próprios, inclusive uma surrogate key

Satellite Entites

Denotam propriedades que descrevem os objetos (Hub) ou os relacionamentos (Link)

Ex.: Nome Cliente, Número Nota Fiscal, Nome FOrnecedor

Pode apresentar

Data e Horade carga

Outros atributos com dados relativos a proveniência

Duas estratégias temporais

Instante de mudança de qualquer valor de uma tupla (Versionamento simples)

Intervalo de Validade para cada atributo de um objeto (Versionamento Bitemporal)

Similar a Modelos Lógicos

Enfatiza a preocupação com o padrão de nomenclatura (como o Anchor Modeling)

Exemplo_Hospital

Hub

Paciente

Hub_Paciente

IDPaciente Número (4) PRIMARY KEY

Nro Registro Número(10)

DtCarga Datetime

Médico

Hub_Médico

ID_médico Número(4) PRIMARY KEY

DtCarga Datetime

Ala

Leito (Objetos do UdD)

Link

Paciente-> Atendimento-> Médico

Paciente-> internação-> leito

Médico -> Atua-> Ala

Ala-> Contém->Leito

Satellite

Paciente

Nome do Paciente

Número de Registro Paciente

Endereço do Paciente

Atendimento

DataHora Atendimento

Ala

Nome Ala

Sat_Ala

IDAla Número(4)

DtCarga Datetime

NomAla varchar2(50)

PRIMARY KEY (IDAla, DtCarga, FOREIGN KEY (IDAla) REFERENCES Hub_Ala(IDAla))

Leito

Nome Leito

Sat_Leito

IDLeito Número(4)

DtCarga Datetime

NomLeito varchar2(50)

PRIMARY KEY (IDLeito, DtCarga, FOREIGN KEY (IDLeito) REFERENCES Hub_Leito(IDLeito))

Implementação

Quais as implicações dessa estratégia para

Combinar dados temporais e atemporais?

Todos os hubs são atemporais (estáveis)

Satellites podem adotar:

Instante (Única Data) que indica quando algo mudou

Intervalo (Duas Datas) que indicam quando um específico valor mudou

Note que essa abordagem:

Não distingue Valid Time e Transaction Time (Overload)

Não determina quando algo foi alterado devido a um erro (Event Time)

Não distingue entre dados estáticos (atemporais) e temporais

Carga dos Dados? Qualquer uma pode ser utilizada?

Hubs e Links denotam conceitos estáveis

Carregados pela estratégia append-only

Não observa mudanças específicas sobre valores de tributos de uma tupla

Aplica estratégia append-only

Replica todos os dados não modificados (Versionamento Simples)

Carregar tudo sempre

Inviável em situações envolvendo grandes históricos

Evolução do Modelo?

Facilidde na adição de remoção de atributos (Versionamento Bitemporal)

Redução dos impactos na evolução de relacionamento

Certa flexibilidade na mudança de atributos

Temporal -> Atemporal ou vice-versa

Propicia carga assíncrona de dados de uma tupla

E a performance? O número de join é aceitável?

Sparcity: Não representa atributos com NULL

Uso eficiente de armazenamento

Reduz overlhead no tratamento de NULL

Aumenta a concorrência

Aumenta a eficiência da compressão de dados

Modelagem Multidimensional

Estratégia

Favorece

Estruturação dos dados pronta para análise, segundo certa perspectiva

Compartilhar dimensões e fatos corporativamente

Enterprise Fact Tables representam dados sem uma visão específica

Porém

Estrutura pode dificultar a derivação de novas métricas

Menor concentração na visão corporativa dos dados

SSE enforcar questões de grupos de usuários

Composto de

Tabela de fato

Tabela com chave composta

É composta por medidas

Medidas são geralmente numéricas e aditivas

A identificação é composta pela identificação das dimensões associadas

Os valores das medidas não são previsíveis durante a modelagem

Conformed Dimensions

'É uma dimensão que significa a mesma coisa em qualquer tabela fato a qual ela está vinculado

Agregações

Tabela de fato representando a sumarização das medidas de uma tabela fato básica

Cada agregação deve ser uma tabela de fato distinta e ser suportada por um conjunto de dimensões contendo somente atributos definidos para o seu nível de granularidade

Tabelas dimensões

Conjunto de tabelas menores (podem conter hierarquias)

É composta por atributos

Atributos são geralmente textos e não aditivos

Tem identificação própria

Os valores dos atributos são previsíveis durante a modelagem

Hierarquia

Corresponde a uma estrutura, composta por atributos de uma dimensão, que possibilita a visualização em níveis, das medidas da tabela fato a que a mesma está associada.

Nem todos os atributos da dimensão compõem uma hierarquia

Uma dimensão pode possuir mais do que hierarquia

Exemplos

Tempo

Ano

Mês

Quinzena

Semana

Dia

Produto

Marca

Linha de produto

Categoria

Produto

Mercado

Região

Estado

Cidade

Lojas

Hierarquias regulares

Quantidade de níveis é uniforme

Cada membro da hierarquia tem a mesma quantidade de níveis superiores

Hierarquia Parent Child

Quantidade de níveis é variável

Os membros da hierarquia são definidos com seus respectivos níveis superiores (auto-relacionamento)

Hierarquia Ragged

Quantidade de níveis é variável

Nem todos os membros da hierarquia tem a mesma quantidade de níveis superiores, pode existir um buraco entre os níveis

Hierarquia Múltipla

São criadas para mostrar as diferentes visões de uma dimensão

Exemplo

Período Fiscal

Ano

Trimestre

Mês

Semana

Dia

Período Calendário

Ano

Mês

Dia

Medida

Dados, normalmente numéricos e aditivos, dos quais podem derivar diferentes informações dependendo da visão empregada empregada sobre os mesmos

Medida não aditiva

É uma medida que não pode ser somada de forma alguma. Só pode ser analisada através de todas as dimensões da tabela fato em questão

Medida semi-aditiva

É uma medida que pode ser somada considerando-se apenas algumas dimensões da tabela fato em questão

Medidas derivadas

Geralmente corresponde a indicadores de evolução potencial do negócio que podem ser obtidos a partir de medidas básicas que compõem os fatos, sem necessariamente estarem fisicamente armazenados

FATO X DIMENSÃO

Dimensão

Perspectiva através da qual uma ou mais medidas da tabela fato podem ser analisadas

Uma dimensão é composta por atributos, altamente correlacionados, e é identificada através de um atributo chave, geralmente criado no Data Warehouse

Chave da Dimensão

A chave corresponde ao atributo que identifica univocamente cada instância da dimensão. Corresponde, na maioria das vezes, a uma chave artificial (Surrogate Key) criada no ambiente de data warehousing

Atributo da Dimensão

Dados, normalmente textos não aditivos, que descrevem e qualificam uma dimensão

Através de cada atributo de uma dimensão é possível visualizar as medidas da tabela fato

O poder de análise está intimamente relacionado à qualidade e profundidade dos atributos das dimensões

Fato

Conjunto de medidas que podem ser analisadas através de várias visões e que contribuem para apurar o resultado de um processo de interesse ou para sinalizar tendências e oportunidades de negócio.

Dados Temporais e Atemporais

Fatos e Dimensões são sempre históricos

Não distingue Valid Time e Transaction Time

Não termina quando algo foi alterado devido a um erro (Event Time)

Não distingue entre dados estáticos (atemporais) e temporais

Organização por assunto

Organiza métricas relativas ao assunto

Derivação de novas métricas é mais difícil em certas situações

Modelagem centrada em uma perspectiva inviabiliza o reuso

Carga de dados

Cargas evolutivas das dimensões mais trabalhosa

Evolução

Criação de novas métricas da mesma perspectiva é 4kids

Mas se a perspectiva mudar um pouquinho...

Uso de métricas semi-aditivas (requer programação)

Adição de novas dimensões é relativamente tranquilo

Mudança de hierarquia em dimensões pode ser muito complexo

Mudança de dimensões em conformidade pode ser um pesadelo

Performance

Melhor em certas operações de consulta

ETL

Visão Geral

Solução de mapeamento mais robusta

Demanda mais esforço e mais subestimada

Combinação de processos e tecnologias

Consome até 80% do desenvolvimento de um BI

Responsável pelas etapas

Extrair dados de diferentes fontes

Propagar dados para a Staging Area para aplicar várias transformações

Carregar dados no DW respeitando a visão histórica

Extração (E)

Objetivo: Capturar os dados brutos de interesse nas origens

Requisitos

Compreender as características das origens de dados

Local (arquivo, relação, etc) da melhor origem

Características gerais do SI que manipulam aquelas origens

Horários de execução, ciclo de vida dos dados, etc

Compreender a estrutura dos dados na diferentes origens

Regras semânticas, regras de integridade, domínio, etc.

Formatação de tipificação

Origens

Não Cooperativas

Snapshot: contém somente dados correntes sem marcações temporais ou lógicas de mudança

Formatos legados: Clipper, IMS

Coopertivas

Replicação

Call back: chamada a função ETL informando uma mudança

Internal Action: Ações internas do SI registra mudanças em local apropriado

Características são bases para definir

Fluxo "Pipeline" de extração

Freqüência de extração e janela disponível

Passos e respectivas dependêcias

Tratamento de erros e exceções

Modo de extração

ODBC

API do SGBD

Bulk copy

FTP

Planejamento da carga inicial do DW

Fluxo de captura dos dados iniciais do DW

Planejamento da abordagem incremental de extração

Fluxo de captura dos dados modificados desde a última carga do DW (delta)

Transformação (T)

Responsável por

Limpeza dos dados (Data Cleaning)

Parsing

Correcting

Standardizing

Matching

Consolidating

Transformar

Preparar os dados para carregar no DW ou no DM

Operações dessa etapa dependem de regras definidas e acordadas com o negócio ⚠

A flaw of operations

Formatação

Decodificar atributos

Derivar valores

Splitting de atributos

Merging

Conversões diversas (Caracter, Unidade de Medida, Data/Hora,...)

Sumarizações

Reestruturação de Chaves Primárias e estrangeiras

Deduplicação

O mesmo objeto existe em múltiplas origens

Hundred of algorithms, but:

Nenhum consegue ser 100%

Participação humana é requerida

Integração de múltiplas origens de dados

O mesmo objeto possui mais de uma origem

Sobreposição de atributos que o descrevem

Definição do melhor dado com base

Prioridade por origem

Regras baseadas em conteúdos de atributos corelatos

Regras baseadas em conteúdos do Master Data Management

Regras baseadas em métricas de qualidade dos dados das origens

Carga (L)**

Requisitos

Compreender os dados a serem carregados

Compreender as características do destino (DW, DM)

Compreender restrições do ambiente de ETL

Base para definir o Fluxo "Piperline" de Carga

Estratégia de Carga

Full Load ou Incremental Load

Ordem e dependências de carga das Entidades

Operações de tratamento de erros

Protocolo de limpeza da Stagging Area

Integração ao restante do "Pipeline"

Ordem

  1. Detectar a operação a realizar com os dados
  1. Aplicar a função de inserção para novos dados
  1. Constructive Merger: Aplicar a função de eliminação lógica para dados atualizados e inserir novas versões

Nova versão do objeto é inserido e indicado como último. Histórico Mantido.

  1. Destructive Merger: Aplicar a função de atualização direta para dados atualizados

Valor atualizado diretamente: Histórico perdido.

Ferramentas

Função equivalente a schema mapping da Virtual Data Integration

Provê diferentes funcionalidades que permitem extrair, transformar e carregar dados

Connectors: para diferentes formatos de dados

Import Filters: leitura e conversão

Data Transformations: join, aggregate, filter, Look-up

De-duplication: identificar e juntar (merge) de dados duplicados

Profiling: Estatísticas sobre dados, detecção de regras

Exemplos

Oracle Warehouse Builder (OWB)

SAP Data Services

IBM Infosphere Information Server

SAS Data Management

PowerCenter Informatica

Elixir Repertoire for Data ETL

Data Migrator (IBI)

SQL Server Integration Services (SSIS)

Talent Studio for Data Integration

Sagent Data Flow

Pervasive Data Integrator

Open Text Integration Center

Map Reduce: captura, transforma e carrega os dados no DW ou DM's de modo distribuído

Funções

map: captura dos dados desejados e os gera em um formato chave, valor (basicamente where)

shuffle: ordena as tuplas baseado e uma chave especificada

reduce: agregação de todas as tuplas com o mesmo agrupador

Data Warehouse

Histórico

Década de 90

Tornou-se viável com o surgimento de novas tecnologias para armazenar e processar uma grande quantidade de dados

Criado

Década de 60

IBM

Information Warehouse

Propósito

Armazenar dados históricos e integrados usados no processo de tomada de decisão

Propriedades

Integrado

Dados em DW são uniformizados, combinados e integrados para prover visão Corporativa

Temporal

Os dados remetem a lifespan limitado no tempo

Não volátil

Dados no DQ não são mais alterados. *Exceto em situações de erro!!! ⚠*

Operações CRUD não (deveriam) 🚫 são permitidas.

Garante que consultas subsequentes produzirão o mesmo resultado

Orientado a assunto

Conjunto de informações (entidades) fortemente relacionadas, geradas pelo mesmo processo do negócio

Assunto cliente

cliente

cliente pessoa física

cliente pessoa jurídica

endereço

Assunto venda

pedido de venda

contrato de venda

parcela do produto

Assunto produto

produto

família produto

regra de comercialização

Credibilidade

O uso do DW depende fortemente da qualidade de seus dados

Discrepância e defeitos podem ter grande impacto sobre análises

Processo de Avaliação contínua da Qualidade dos Dados

Tudo começa no "T" do ETL

Pouca compreensão de que é um INVESTIMENTO

Granularidade

Determina o nível de detalhe desejados dos dados

Qual detalhe? Qual dado? Quanto tempo?

Níveis de granularidade

Dados base detalhados (por exemplo, últimos 5 anos)

Dados sumarizados (por exemplo, últimos 10 anos)

Dados mais antigos (mantidos fora do DW)

Não esquecer que um DW deve atender

Processos TÁTICOS e ESTRATÉGICOS de uma organização

Flexibilidade

Estratégias

Entidade-Relacionamento Estendido

Modelo Dimensional

Data Vault

Anchor Modeling

Aspectos relevantes para qualquer estratégia

Gestão de dados (Dado como ATIVO)

Padronização de Nomenclatura

Glossário de Termos

Outros metadados

Design

Chave artificial (Surrogate Keys)

Chave primária, gerada pelo sistema, sem significado, que substitui a chave natural

Um item de dado atômico (não composto)

Invisível ao usuário

Número sequencial

Vantagens

Integração (visão corporativa)

A integração das chaves primárias, em algumas entidades básicas, só é possível, sem o uso da chave artificial, se elas já estiverem integradas nos sistemas fonte. Exemplo: pessoas, produtos, localidades

estabilidade

A chave artificial protege contra as mudanças e a reutilização das chaves nos sistemas fonte

Menos esforço na manutenção

aplicabilidade

A chave artificial permite registrar valores especiais, quando os dados não estão presentes nos sistemas fonte:

não identificado

não se aplica

performance

Geralmente menor que a chave natural

menor índice

chaves estrangeiras menores

índices das chaves estrangeiras menores

manipulação

É mais fácil manipular uma chave com um único atributo do que uma chave composta

Desvantagens

Criação de mais um item a ser controlado

Maior esforço no desenvolvimento

aumento do tamanho da linha (registro) na tabela original

necessidade de criação de índices adicionais

necessidade de manutenção de integridade referencial também da chave artificial para tabelas dependentes

Estratégias para Dados Temporais

Os objetos do negócio sofrem inúmeras modificações ao longo de sua vida

Forma um conjunto de posições ou versões

O modelo de dados tradicional tem duas dimensões

O modelo de dados com propriedades temporais tem 3 dimensões

Propósito é associar o elemento tempo ao valor de cada atributo ou objeto

Unidade de tempo deve ser significativo para o contexto

Proposta de modelo e um conjunto de regras necessárias para o tratamento da perspectiva tempo de forma a

garantir a veracidade

consistência dos dados durante as operações de manutenção

algumas estratégias

Versioning

State

Comparação com Aplicações operacionais

Foco

DW: Recuperação de dados para análises/decisões

Apl. Op.: Entrada de dados para as operações de negócio (transações)

Usuários

DW

Gestores de negócio

Knowledge workers

Apl. Op.

Funcionários operacionais

Funcionários de controle

Objeto da análise

DW

Processo decisório

Indicadores de desempenho

Apl. Op.

Fluxo de atividades operacionais

Tipos de dados

DW

Estáveis

Históricos

Alguns sumarizados

Apl. Op.

Dinâmicos

Correntes

Detalhados

Estrutura de dados

DW

Normalizada

Multidimensional

Apl. Op.

Normalizada

Tempo de resposta

DW: Vários segundos/minutos/horas

Apl. Op.: Frações de segundos ou alguns segundos

Classes

Classe i

quase síncrona (poucos segundos)

Transações replicadas do ambiente operacional

Dados envelhecem rapidamente

Dados não integrados

Complexa de construir

custo alto

classe ii

de minutos a várias horas

Transações integradas do ambiente operacional

Dados muito voláteis

Custo um pouco mais baixo

Alguma integração e transformação de dados

Um pouco mais fácil de construir

Classe iii

uma vez ao dia

Transações integradas do ambiente operacional

Alguns dados podem corresponder a uma fotografia no final do dia

Alto nível de integração e transformação de dados

Fácil de construir

custo baixo

Classe iv

intervalos regulares ou irregulares

Dados integrados vindos do data warehause

Necessita da existência do data warehouse

Mais fácil de construir

Custo mínimo

Problemas

Requisito visto como tempo "gasto" e não "investido"

Percepção focado na entrega

Percepção DO QUE um DW deve prover é, no geral, compreendido

MAS NÃO as implicações dessa percepção

Incompletude ou enviesamento produzem um DW

Difícil de evoluir

Ausente de uma visão conciliadora

Modelagem Entidade-Relacionamento

Estratégia convencional

Organização dos dados segundo sua semântica

Cada relação é uma semântia (e.g, Cliente, Nota Fiscal, Item)

Organização semântica corporativa dos dados é lenta

Orientada para transacionar com os dados

Reduz a redundância e aumenta o reúso

Facilita a derivação de qualquer perspectiva empresarial

Neste texto envolve perspectivas

Conceitual

Lógico

Elementos

Entidade

Cliente

Contrato

Produto

Agência (Banco)

Pagamento

Conta

Atributo da entidade

Cliente

Nome

Endereço

Sexo

Data de nascimento

Conta

Número

Data da abertura

Produto

Descrição

Contrato

Valor

Agência (Banco)

Endereço

Relacionamento

Atributo do relacionamento

Restrições de
Relacionamentos

Restrição explícita que indica o número de instâncias de uma entidade associadas a instâncias de outra entidade. Dado um elemento do conjunto A, com quantos elementos do conjunto B ele se relaciona? e vice-versa?

Restrição de Participação

Indica a opcionalidade do relacionamento (Classes: 0, 1, N ou número específico)

Razão de cardinalidade

representa a classe do Relacionamento (Classes: 1, N ou número específico)

Associação Opcional

Especialização e Generalização

Representar uma entidade em diferentes níveis de abstração

Generalizar

Implica em uma entidade genérica formada por um subconjunto de entidade

surge quando entidades diferentes compartilham propriedades comuns (atributos e/ou relacionamento)

Especializar

Implica em atribuir propriedades ou relacionamentos a um subconjunto de entidades de uma entidade genérica

Surge quando certas instâncias de uma entidade apresentam pequenas variações de comportamento

Agregações

Elemento significativo para o contexto

Enxergado como um objeto e não como um relacionamento

Agregação participa de outros relacionamentos

Dados temporais e Atemporais

Utiliza os conceitos de instante e intervalo temporal

Utiliza os conceitos de transaction time e valid time

Time valid: quando um fato foi válido para o negócio

Transaction time: quando o BD soube desse fato

Não força separar atributos atemporais e temporais do mesmo objeto

Estratégia de Carga dos Dados

Orientado para manipulação de carga no nível de tupla

Dificulta a carga assíncrona de porções de uma tupla

Possibilita carga assíncrona de tuplas

Carregar tudo sempre sobre objetos

Inviável somente em grandes históricos

Carga incremental

Todas as estratégias são suportadas

Evolução do modelo

Esforço na adição de atributos ou relacionamentos

Impacto nos processos ETL e de visualização correspondentes

Esforço na mudança de atributos e relacionamentos

Atemporal -> Temporal ou vice-versa

Certa complexidade na definição de índices

Abordagem NÃO naturalmente incremental, mas possível

Requer técnicas incrementais (refatoração de BD)

Mas....

Facilita o estabelecimento de regras integridade complexas

Performance

Não prepara um BD para análise in-situ

Overhead na representação de NULL

Bom nível de concorrência (depende da granularidade)

Reduzida eficiência na compressão das dados (alta entropia)

Melhora sensível com BD orientados a colunas (C-Stored DB)

Mas.....

Facilita o trabalho de ETL (quase transacional)

Conta com inúmeros recursos de melhoria de desempenho

Particionamento Vertical e Horizontal, Tipos de Índices, etc

Data Marts

Características

Assuntos de informação organizados para as necessidades de análise específicas

Análise fincanceira

Marketing

Campanhas

Contém uma porção dos dados do DW

Podem apresentar entre si

Sobreposição de assuntos

Granularidades distintas ou sobrepostas

Temporalidade sobrepostas

DM X DW

Design

DM:Denormalizada

DW: Normalizada

Histórico

DM:Contém apenas o essencial para algumas análises

DW: Contém todo o histórico necessário para BI

Granularidade

DM: Incentivo ä criação de agregações e sumarizações

DW: Contém o maior nível de detalhe necessário para BI

Tipos de usuário

DM: Predominantemente "gerente"

DW: Predominantemente "explorador" e "minerador"

Abrangência

DM: Modela as necessidades sob uma visão específica (departamental)

DW: Consolida as necessidades de toda a empresa (corporativo)

Requisitos para a tecnologia

DM

Facilidade de análise

Suportar dados altamente indexados

DW: Suportar alto volume de dados

Fonte de dados

DM: Única fonte de dados (Data Warehouse)

DW: Várias fontes de dados (Sistemas Operacionais)

Dependentes X Independentes

Independentes

Como garanto a qualidade? Como eu garanto que TODOS utilizam o mesmo conceito de "Cliente"?

Vantagens

Tempo menor de desenvolvimento

Desvantangens

Alto risco de contradição

Duplicação de dados

Em que situação poderíamos utilizar um DM Independente de modo vantajoso em uma organização?

Online Analytical Processing (OLAP)

Características

Tecnologia que possibilita diferentes perspectivas sobre modelos multidimensionais

Consultas que fornecem dados a respeito de medidas de desempenho, decompostas por uma ou mais dimensões

Cubo é a estrutura operacional para armazenar os dados

Computa todas ou parte os valores de todos os relacionamentos para todas as dimensões

As células do cubo contém valores mensuráveis e as bordas definem os possíveis tipos de visões

Podem existir mais que três dimensões no negócio (hipercubo)

Quase todos os tipos de dados podem ser representados como um cubo de dados

BD Multidimensional é a estrutura operacional para armazenar os dados

Computa todas ou parte os valores de todos os relacionamentos para todas as dimensões

PASSOS:

Gerar as agregações para todos os agrupamentos possíveis

Carregar cubo

Ler os dados do DM (provável origem)

Arquiteturas

ROLAP (Relational OLAP)

Próprio para grandes volumes de dados e necessidade de dados detalhados

Recomendado quando os usuários não sabem exatamente o que vão perguntar ao longo do tempo

Não consegue realizar operações complexas

Menor performance

Utiliza a estrutura de banco de dados relacional para armazenar "cubos" e agregações

Cubos gerados dinamicamente

Baseado em visões materializadas

HOLAP (Hybrid OLAP)

O acesso aos dados é mais rápido do que na tecnologia ROLAP

Contém dados pré-calculados, considerando todas as possíveis respostas para um dado conjunto de questões

Combina características do ROLAP e MOLAP

Os dados detalhados são armazenados em banco de dados relacional

As agregações são armazenados em banco de dados multidimensional

Algumas alterações levam à necessidade de reprocessar as agregações

MOLAP (Multidimensional OLAP)

As agregações são armazenadas dentro da estrutura multidimensional do banco de dados

Estrutura proprietária baseada em vetores multidimencionais

Algumas alterações levam à necessidade de reprocessar o cubo

Contém dados pré-calculados, considerando todas as possíveis respostas para um dado conjunto de questões

Excelente performance

Os cubos podem ficar muito grandes à medida que novas dimensões e dados detalhados são acrescentados

Alto consumo de espaço

DOLAP (Desktop OLAP)

Permite baixar um hipercubo para utilização off-line

Excelente performance

Acesso somente local

Indicado para mobile BI

Restrito em operações e com alto nível de agregações

Sem acesso a dados detalhados

Operações

DRILL-DOWN

Abertura dos dados em grânulos menores

SLICE

Recorte dos dados

Pode ocorrer por meio de uma ou mais dimensões

ROLL-UP

Agregação de dados

Pode envolver uma ou mais dimensões

PIVOT

Rotação de dados

DRILL-THROUGHT

Retorna aos dados contidos nas relações

DRILL-ACROSS

Acesso a outro cubo por meio da(s) conformed dimensions

Dependentes

Vantagens

Reuso de dados

Dados com qualidade

Desvantagens

Tempo maior de desenvolvimento

Visualização

Como transformar a montanha de dados em algo útil para as pessoas?

Visão Humana

Um dos sentidos + importantes, embora seja o + lento

Caracteríticas

Processamento paralelo e pré-atentivo

Inata capacidade de reconhecimento de padrões

Estende a capacidade cognitiva e memória

Pessoas tendem a pensar visualmente

Processo biológico químico-elétrico que mensura uma energia física que nos rodeia

Permite perceber formas de objetos e seu arranjo no mundo

Analisada em detalhes

Neurociência, mas nem sempre foi assim

Psicologia cognitiva

História

(450 A) Teoria de Intromissão

Demócrito sugeriu que pequenas partículas (átomos) emanavam dos objetos aos nossos olhos

Tais partículas retinham as características dos objetos

Teoria da Extramissão

Platão sugeriu que nossos olhos emanavam uma energia que capturava o mundo ao seu redor

(1038 DC)Teoria da Luz Intromissão

Discussão sobre percepção humana retomada pelo árabes

Abu Ali-Hasan discorda das teorias gregas e passa a enfatizar a luz como maior ingrediente da visão

Sugere...

Não olhamos passivamente o mundo ao nosso redor

Cena muda conforme movemos os olhos e inspecionamos certos objetos em detrimento de outros

Visualização de dados

Fornecer representações visuais interativas que favoreçam análise complexa de dados e amplifique a cognição

Combina o melhor de dois mundos

Recursos computacionais

Distinção semântica inata humana

Natureza multidisciplinar

Psicologia cognitiva, computação gráfica, HCI

Ciência da Computação, Matemática

Propósito

NÃO é criar figuras ou gráficos

SIM: Impulsionar o processo cognitivo

Proporcionar insights (Explicações, descoberta, ...)

Formar uma imagem sobre algo

Internalizar a compreensão sobre algo

DATA VISUALIZATION

Enfoca dados com estrutura implícita, como Imagem médica, Mapas, Grafos...

INFORMATION VISUALIZATION

Enfoca dados sem estrutura inerte, como clientes, notas Fiscais....

Algumas aplicações

Agricultura (agricultura de precisão)

Engenharia de software

Geografia e história

Banco de dados

Diagnósticos médicos

Administração de redes e cloud computing

Mercado financeiro

Educação

Desafios

Escalabilidade para grandes conjuntos de dados

Área de video é limitada

Ser humano possui um limite físico na interpretação visual

Diferentes tipos de dados

Cada qual requer técnicas distintas

Avaliação

Como provar que uma visualização é melhor?

Pessoas com diferentes características

Cognição Humana e seus sistemas

Cognição é o resultado de cooperação e influência mútua

Sistema percepção pessoal

Sistema analítico

Processamento Inicial de Visão

Estrutura eficiente e autônoma captura estímulos

Estímulos de acordo com primitivos visuais

Somos inconscientes a esse trabalho

Certas primitivas "saltam aos olhos"

Denominadas Primitivas Pré-Atentivas

Mesmo quando estão em regiões periféricas aos olhos

Processamento Org. Elementos

Percebemos o mundo conectado no espaço e tempo

Capturamos as primitivas de modo segmentado

Sistema visual

Determina contornos, linhas, superfícies, cores, etc...

Utiliza nossa memória de trabalho

Organiza as primitivas nas estruturas correspondentes

Somos inconscientes a esse trabalho

GESTALT

Simmetry

Remete a ideia de proporcionalidade e arranjo simétrico entre elementos. Assimetria nos causa uma ideia negativa de "algo errado, desconexo, esquisito"

Figure/Ground

Tendemos a separar a figura do seu fundo dependendo do contraste, cor, tamanho, etc

Proximity

Objetos ou formas próximas uma das outras é percebido como um grupo

Good continuation

Tendência instintiva de seguir naturalmente trajetórias até o ponto final

Similarity

Objetos distintos saltam aos olhos

Objetos com similaridade de formas, cor, tamanho ou textura são percebidos juntos

Closure

Para um objeto familiar, nosso cérebro completa os detalhes ausente

Refere-se a maneira como seres humanos observam grupos de objetos

Vemos o todo antes de partes individuais

Teoria que delineia que certo arranjo visual de elementos é mais coerente e comunicará melhor

Válida para apresentação visual, fotos, Web Design, Visualizações, etc.

Desenvolvida na década de 20 (Alemanha, Áustria)

Fundadores Max Wertheimer, Wolfgang Kohler e Kurt Koffka

Charge Blindness

Fenômeno que ocorre quando uma pessoa não detecta mudanças visuais no ambiente

Olhar para algo é diferente de prestar atenção ativa para algo

Ocorre devido a

Mudanças muito rápidas de cena (motor, cinema)

Mudanças muito lentas de cena

Observador presta atenção em certo aspecto e não em outros

Processamento atentivo

Atividade mental de direcionamento de recursos cognitivos

Recursos cognitivos são escassos

Capacidade analítica, memória de longo prazo

Atividade pode ser ativada por controle exógenos

Direcionamento voluntário

Interferência do conhecimento

Busca por padrão ou relacionamento compatível com uma tarefa

Agente humano utiliza visualização com um propósito

Projeto de visualizações

Como preencher o espaço de dados? Qualquer visualização "bunitinha" serve?

Basta ficar atento às características do Sistema de percepção visual humano

Visualização exige um projeto

Abordagem top-down

Valide a(s) visualização(ões) com o usuário

Escolha os componentes mais adequados

Compreenda o problema a ser resolvido

Refina o projeto na camada (ou camadas) necessárias

Caracterização do problema

Entenda como as pessoas make sense sobre algo

Similaridade de valores? Correlação por linha? Comparação por categoria?

Make sense

Processo de como construo o entendimento sobre algo

Processo ativo de buscar e interpretar

É individual e subjetivo

Compreender as estruturas conceituais

Exemplos de Domínios e Estruturas

Direito

Eventos

Pessoas

Cronologia dos eventos

Diagnóstico médico

Paciente

Eventos

Cronologia dos eventos

Padrão das enfermidades

Avaliação da Qualidade de Dados

Padrão

Variantes dos defeitos

Cada domínio possui uma estrutura que influencia as conceituações geradas pelos indivíduos

Compreenda o perfil do seu grupo de usuários

Descreve suas características gerais

Cada usuário possui habilidades e expectativas distintas

Determine requisitos relativos a

Familiaridade com visualizações

Nível de Acuracidade dos dados codificados

Capturando requisitos

Existe sempre uma tensão natural de

Como um computador pode implementar

Como o indivíduo pensa

Saber ouvir é uma arte e organizar tudo que ouviu é outra

Designing for appropriation

Tecnologia deve prover suporte e não controle aos indivíduos

Nunca antecipar soluções tecnológicas

Permitir indivíduos expressar a representação do domínio do problema

Entrevistas

Encontros planejados com os usuários

Quem?

Quando?

Em que local?

Por quanto tempo?

Intuito?

Condução

Evite questões gerais e de alto nível

Prefira questões que revelem detalhes sobre aspectos concretos

O que acontece quando....

Fale-me sobre como faz para....

Nunca aplicar perguntas que sugerem certa resposta

Como registrar e o que gerar?

Áudio, vídeo (se permitido)

Esboços, resumos de pontos chave, etc.

Inquérito Contextual (Similar a Etnografia)

Levantamento ocorre no local de trabalho do usuário

Observação das atividades (O que? Por quê? Como?)

Questionamentos (Minorar interrupções)

Condução

Envolve uma equipe de inquérito

Novamente, utilize questões concretas e não generalidades

Desafio de manter o usuário trabalhando de modo natural

Como registrar e o que gerar?

Video é muito bem vindo!

Fluxo de evento, Influência do Ambiente, Responsabilidades, etc.

Design de operações/dados

Passo 1: Determinar as abstrações visuais alinhadas a caracterização

Caso1: Correlações da evolução de instâncias temporais (Times series)

Caso 2: Planejar uma viagem

Elementos críticos: Orientação, localização e distância

Caso 3: Análise de relacionamentos em redes sociais

Elementos críticos: relacionamentos N:N, complexos

Passo 2: Abstrair seus dados em tipos genéricos

Caso 1: Correlação da evolução de instâncias temporais de certo atributo categórico de grande domínio

Caso 2: Análise de muitos relacionamentos hierarquizados

Design das codificações/interações

Passo 1: Mapear atributos para primitivas visuais

Passo 2: Definir as técnicas de interação

Crie a visualização (algoritmo)

Passo 1: Identifique pacotes que atendam as suas necessidades

Avalie com cuidado requisitos funcionais (codificação, interações)

Avalie com mais cuidado requisitos não-funcionais (escalabilidade, maturidade do pacote, facilidade de instalação e disponibilização, etc)

Passo 2: Implemente suas visualização

Crie sua visualização do Zero

Faça uma extensão sobre pacotes existentes

Resumo

Visualizações devem alavancar a percepção dos dados

Qualquer visualização pode prejudicar a análise

Importante considerar aspectos da percepção visual humana

O design de uma visualização é muito distinto de um interface visual de um software padrão

Usabilidade é uma pequena porção

Participação e avaliação dos usuários é mandatória