Data Warehouse - Modelagem

Tecnologia em Gestão da Tecnologia da Informação

Administração de Banco de Dados Criação e Manutenção de Data Warehouse

GRADUAÇÃO

Prof. Rudson Kiyoshi Souza Carvalho [email protected]

Versão 1.0 Agosto/2014

1

Parte 2


2

Conceitos Fundamentais

Modelagem -‐ Revisão

Tecnologia em Gestão da Tecnologia da Informação 3

•  Para construir um modelo de dados, usa-‐se uma linguagem de modelagem de dados. •  Existem linguagens textuais e linguagens gráficas. •  É possível descrever os modelos em diferentes níveis de abstração e com diferentes

objeYvos. •  Cada descrição recebe o nome de esquema de banco de dados.

Modelagem -‐ Revisão


Modelagem de sistemas, tanto a nível funcional quanto de dados, é um requisito fundamental para a obtenção de produtos de so\ware de maior qualidade e confiabilidade.

Modelo Conceitual


•  Modelo conceitual é um diagrama em blocos que demonstra todas as relações entre as enYdades, suas especializações, seus atributos e auto-‐relações. (Wikipedia)

•  É uma descrição de banco de dados de forma independente de implementação num sistema de gerenciamento.

•  Com o objeYvo de registrar QUE dados podem aparecer no banco, mas não registra COMO estes dados estão armazenados no SGBD

Modelo Lógico


Compreende uma descrição das estruturas que serão armazenadas no banco e que resulta numa representação gráfica dos dados de uma maneira lógica, inclusive nomeando os componentes e ações que exercem uns sobre os outros, representando fielmente o NEGÓCIO, e NÃO necessariamente a base de dados desejada, a qual será construída posteriormente por ocasião do Projeto Físico;

Modelo Físico


Inclui a análise das caracterísYcas e recursos necessários para armazenamento e manipulação das estruturas de dados (estrutura de armazenamento, endereçamento, acesso e alocação nsica), sendo uma sequência de comandos executados em SQL a fim de criar as tabelas, estruturas e ligações projetadas até então e finalmente criar o banco de dados. (Wikipedia)

Tipos de Relacionamentos


•  Um-‐para-‐um (1:1): uma instância em “A” esta associada com no máximo uma instância em “B”, e uma instância em “B” esta associada com no máximo uma instância em “A”;

•  Um-‐para-‐muitos (1:n): uma instância em “A” esta associada a qualquer número de instâncias em “B”, e uma instância em “B”, todavia, pode estar associado a no máximo uma instância em “A”;

•  Muitos-‐para-‐muitos (n:n): uma instância em “A” esta associada a qualquer número de instâncias em “B” e vice-‐versa. Alguns autores preferem chamar esta cardinalidade de m:n, por considerar que podem representar valores diferentes.

(KORTH, SILBERCHATZ e SUDARSHAN, 2006)

Formas Normais


•  1a Forma Normal (1FN): toda relação deve ter uma chave primária e deve-‐se garanYr que todo atributo seja atômico. Atributos compostos devem ser separados. Por exemplo, um atributo Endereço deve ser subdividido em seus componentes: Logradouro, Número, Complemento, Bairro, Cidade, Estado e CEP.

•  2a Forma Normal (2FN): toda relação deve estar na 1FN e devem-‐se eliminar dependências funcionais parciais, ou seja, todo atributo não chave deve ser totalmente dependente da chave primária. Por exemplo, uma relação que contenha os atributos Código da Obra, Código do Fornecedor, Nome do Fornecedor e Preço de Venda, considerando que a chave primária é composta pelos atributos Código da Obra e Código do Fornecedor. Uma nova relação entre as enYdades Fornecedor e Obra deverão ser criadas.

•  3a Forma Normal (3FN): toda relação deve estar na 2FN e devem-‐se eliminar dependências funcionais transiYvas. Na terceira forma normal temos de eliminar aqueles campos que podem ser obYdos pela equação de outros campos da mesma tabela.

(Saber Digital: Revista Eletrônica do CESVA, Valença, v. 1, n. 1, p. 33-‐69)


10

Modelagem de Dados para Data Warehouse

Modelagem de Dados para Data Warehouse


O sucesso no desenvolvimento de um Data Warehouse (DW) bem modelado depende do planejamento realizado e a escolha correta das estratégias a serem adotadas, de forma que sejam adequadas às caracterísYcas do negócio da organização as necessidades específicas do ambiente onde será implementado.

Modelagem MulIdimensional


A modelagem mulYdimensional é uma técnica de concepção e visualização de um modelo de dados de um conjunto de medidas que descrevem aspectos comuns de negócio. Sua uYlização ajuda na sumarização e reestruturação dos dados e apresenta visões que suportam a análise dos valores destes dados

(MACHADO, F.N.R. Projeto de Data Warehouse, São Paulo: Érica, 2004.)

Modelagem MulIdimensional -‐ Fatos


Fatos – Um fato é uma coleção de itens de dados, composta de dados de medidas e de contexto. Cada fato representa um item, uma transação ou um evento de negócio e é uYlizado para analisar o processo de negócio de uma empresa. É tudo aquilo que reflete a evolução dos negócios do dia a dia de uma organização.


Modelagem MulIdimensional -‐ Dimensões


Dimensoões – Conceitualmente são os elementos que parYcipam de um fato, assunto de negócios. São as possíveis formas de visualizar os dados, ou seja, são os “por” dos dados: por mês, por país, por produto, por região. Representam o contexto de um assunto de negócio.


Modelagem MulIdimensional -‐ Medidas


Medidas – são os atributos númericos que representam um fato, a performance de um indicador de negócio relaYvo às dimensões que parYcipam desse fato. Uma medida é determinada pela combinação das dimensões que parYcipam de um fato e estão localizados como atributos de um fato. Por exemplo, o valor em reais das vendas, o número de unidades vendidas de produtos e a quanYdade em estoque.


Modelo Estrela e ou Star Schema


Modelo Estrela

•  O conceito de Esquema Estrela (em inglês: Star Schema) foi criado pelo estadunidense Dr. Ralph Kimball, ao propor uma visão para a modelagem de base de dados para sistemas de apoio a decisão. Sua principal caracterísYca é a presença de dados altamente redundantes, melhorando o desempenho.

•  Sendo a estrutura básica de um modelo mulYdimensional.

•  Star schema ou esquema em estrela é uma metodologia de modelagem de dados uYlizada do desenho de um Data warehouse.



Modelo Estrela Fonte: Machado (2004)



18

Esquema Estrela

Modelo Floco de Neve e ou Snowflake Schema


Esquema Floco de Neve

•  Esquema floco de neve é uma variação do esquema estrela, no qual todas as tabelas de dimensão são normalizadas na terceira forma normal (3FN), ou seja, são reYrados das tabelas os campos que são funcionalmente dependentes de outros campos que não são chaves. Este modelo é o resultado da decomposição de uma ou mais dimensões que possuem hierarquias entre seus membros.

•  Recomenda-‐se uYlizar o esquema floco de neve apenas quando a linha de dimensão ficar muito longa e começar a ser relevante do ponto de vista de armazenamento.






21

Esquema Floco de Neve

Análise Dimensional


22

Inicialmente para montarmos um modelo dimensional, devemos buscar responder a 4 perguntas base básicas:

1.  Quando aconteceu o fato? 2.  Quem é o personagem do fato? 3.  Onde aconteceu o fato? 4.  O que é o objeto do fato?

Fato

Quando

O quê

Onde

Quem

A Dimensão Tempo (Quando)


•  A dimensão Tempo (Data) é muito importante em toda a modelagem. Como tal deve ser tratada de forma diferenciada em relação às outras dimensões. Usualmente esta presente em todo Data Mart, pois o Data Warehouse é histórico.

•  Costuma ser complexa no mundo real: – Dia, Mês, Trimestre, Semestre, Ano – Dia Acumulado no Mês, no Ano – Período Fiscal, Semana de Cinco Dias – Feriados, Fim de semana

•  Qual a granularidade é a ideal? (depende do projeto) – Com granularidade diária, podemos organizar os dados por dias, meses, anos, por

períodos fiscais (arYficiais) da empresa, etc. Essa modelagem é mais flexível a mudanças nos requisitos do negócio. •  Diferente das outras dimensões, a tabela Data pode ser carregada antecipadamente, de

uma só vez e não requer fonte de dados.

A Dimensão Tempo (Quando)


Os Ypos de dados padrões dos bancos de dados, não suportam esta riqueza de formatações.

A Dimensão Onde


•  Essa dimensão sempre existe em um fato, seja qual for ele.

Agrupamentos MulIdimensionais


Realizar o Estudo de Caso 1 – Exercício Cinema


•  Faça a modelagem mulYdimensional para o modelo transacional do sistema de gerenciamento de cinemas projetado em sala de aula, seguindo a seguinte premissa:

•  Os gerentes de área da distribuidora desejam acompanhar a evolução do público e o valor arrecadado na região do país.

Realizar o Estudo de Caso 2 – Exercício Hotel


•  Faça a modelagem mulYdimensional para o modelo transacional do sistema de gerenciamento de hoteis conforme próximo slide, seguindo a seguinte premissa:

•  Visualizar ao longo do tempo o faturamento; •  Evolução do faturamento pelo Ypo de aparamento; •  Faturamento de serviços com consumo de bebidas e alimentos; •  Faturamento por profissão de hóspede;

ConInuação Estudo de Caso 2 – Exercício Hotel




30

Fim Parte 2


31

Education

Data Warehouse - Modelagem