Construindo Um Projeto de Analise de Dados de Um Sistema de E-Commerce - LinkedIn

10
Home My Network Jobs Messaging Notifications Me For Business
Construindo um Projeto
de Analise de Dados de
um Sistema de E-
commerce
Wesley Steve
Engenheiro de Dados | Desenvolvedor ETL | 2 articles Follow
Analista de BI | Data Engineer | Python | SQL |…
November 11, 2022
Open Immersive Reader
RESUMO
Este artigo apresenta uma proposta de uma modelagem de

dados dimensional baseado em um modelo de dados
relacional existente, { III Desenvolvimento [2] Data
Warehouse} . Este modelo tem como proposta melhorar as
atividades de Business Intelligence (BI), onde elas não são
executadas de forma eficiente, quando utilizamos banco de
dados transacional. Com um banco de dados dimensional
implantado, podemos dizer que as atividades analíticas
serão centralizadas no mesmo, isso garantindo que o
banco de dados transacional fique livre para trabalhar as
operações diárias da empresa e o banco de dados
dimensional fique disponível para atividades analíticas
como gerar relatórios diversos. Através desta separação
podemos dizer que não haverá concorrência dos dados e
recursos computacionais, isso evitando lentidão na base de
dados transacional. Por isso foi proposto a criação de um
Data Warehouse para o armazenamento de dados
históricos da empresa onde os usuários que atuam nas
áreas de relatórios poderão trabalhar de forma eficiente
não atrapalhando o banco de dados transacional da
empresa. O resultado esperado será que com essa
implementação, as responsabilidades dos usuários fiquem
melhor definidas e a facilidade do acesso à informação
ficarão melhores. Isso ajudará aos tomadores de decisão a
se organizarem e tirarem um maior proveito do sistema
como um todo.
Palavras chave
Data Warehouse, business intelligence, banco de dados
I - INTRODUÇÃO
1. Contexto
A tecnologia da informação está em constante evolução e

empresas que conseguem compreender esta evolução mais
rápido, tendem a sair na frente de seus concorrentes. Nos
dias de hoje considera-se que dados são o novo petróleo
para as empresas, independente de seu segmento.
Empresas que ainda não compreendem esta realidade,
estão ficando para traz, em relação a outras empresas que
já começaram a mudar suas estratégias para tomada de
decisão orientado a dados. Para que empresas utilizem de
técnicas relacionadas a análise de dados, elas precisam de
profissionais capacitados para trabalharem com este tipo
de cenário, além de profissionais é muito importante que as
empresas adquiram ferramentas que auxiliem o trabalho
destes profissionais para que os mesmos possam entregar
resultados relevantes para as empresas. Atualmente análise
de dados está diretamente ligado a dois principais tipos de
analises, onde o primeiro tipo é o business intelligence (BI)
onde ele por sua vez tem o propósito de analisar dados
históricos com o objetivo de avaliar os resultados das ações
que foram tomadas pelos tomadores de decisão, já o
segundo tipo é a ciência de dados, e ela tem o propósito
de utilizar de dados históricos como entrada para diversos
algoritmos com o objetivo de prever resultados com base
em possíveis ações que seriam tomadas pelos tomadores
de decisões. Esses dados históricos normalmente possuem
categorias como: planilhas eletrônicas, onde possibilitam a
análise e o armazenamento de dados de forma tabular;
sistemas OLAP (Online Analytical Processing), onde
possibilitam a análise e visualização de dados
multidimensionais em diferentes formatos e Data
Warehouse, onde possibilitam o armazenamento de dados
atuais e históricos centralizando em um único repositório
para serem utilizados posteriormente em análises. O setor
de e-commerce é um segmento que utiliza fortemente os
recursos de BI, onde profissionais fazem o uso de diversas
ferramentas relacionadas para trazerem resultados para os
interessados como: faturamento total de vendas,
faturamento por ano, qual o tipo de pagamento mais
frequente etc. Será apresentado a criação de um data
warehouse a partir de um banco de dados relacional
existente em um projeto para empresa do setor de e-
commerce.
2. Objetivo
O objetivo deste trabalho é construir um data warehouse

para que usuários da empresa utilizem destes dados que
serão armazenados em um DW para geração de relatórios
objetivando a responder perguntas de negócio, através de
visualizações que serão construídas utilizando a ferramenta
Power BI Desktop e publicadas online para o consumo
destes dados.
3. Motivação
No banco de dados da empresa estão armazenados dados

valiosos, onde usuários de análise possuem dificuldades de
gerar relatórios para empresa sem prejudicar o trabalho
dos demais usuários de outros departamentos. Essas
atividades de análise concorrem recursos com atividades
transacionais. Com a implementação de um data
warehouse usuários de análise utilizaram deste recurso para
executar seus trabalhos de análise enquanto os demais
usuários utilizaram dos sistemas transacionais para
executarem suas atividades na empresa.
4. Matérias
Este trabalho esta sendo realizado utilizando os seguintes
recursos tecnológicos, modelos ou práticas
• Python como linguagem de programação utilizando junto

a biblioteca Pandas para o entendimento dos dados
• Jupyter Notebook para fazer as analises iniciais entendo

os dados
• Sistema gerenciador de banco de dados PostgreSQL
• Docker / Docker-compose para subir o banco de dados

PostgreSQL
• Ferramentas para o ETL Pentaho 9.3 PDI
• Ferramenta para a modelagem do banco de dados SQL

Power Architect
• Ferramenta DBeaver para visualizar as estruturas dos

dados
• Ferramenta para construção dos dashboards Power BI

desktop
• Git para controle de versão
• Github para o armazenamento do projeto
5. Metodologia do Trabalho
Este trabalho está sendo realizando utilizando as seguintes

etapas
• Definição do problema
• Perguntas de negócio
• Coleta dos dados
• Modelo de dados transacional
• Conhecendo os dados
• Modelagem do Data Warehouse
• Desenvolvimento do processo ELT
• Apresentando os resultados
• Técnicas utilizadas
II REVISÃO DE TECNOLIGIAS E
PRÁTICAS
1. Data Warehouse
Data warehouse (DW) está classificado como um
repositório central para armazenagem de dados que são
coletados de diferentes fontes de dados, como (Sistemas
ERPs, planilhas Excel, sistemas de CRMs entre outros). Ele é
projetado para fornecer suporte a atividades relacionadas à
business inteligence (BI). Os data warehouses, tem como
propósito armazenar dados de diversas fontes que foram
tratadas e estruturadas de acordo com o modelo de dados
dimensional, mantendo um histórico dos dados que foram
coletados, onde este histórico permite que as empresas
levantem insights que as auxiliem nas tomadas de decisões
importantes. Empresas que visam utilizar de recursos de
analises dos dados para melhorar as áreas da empresa que
trazem valor a ela, deveriam utilizar do recurso de data
warehouse (armazém de dados) para armazenagem dos
dados e permitindo que as análises sejam mais
performáticas do que se utilizar do recurso de banco de
dados transacional (OLTP) da empresa, onde cada um
possui papeis diferentes para uma organização (empresa).
O Banco de dados transacional (OLTP), tem como o seu
principal objetivo processar transações de forma contínua,
onde sistemas de diversos segmentos utilizam deste
modelo, como um sistema de armazenamento dos dados.
Já o data warehouse (DW) possui seu modelo de dados do
tipo dimensional e tem como seu principal objetivo
armazenar e organizar dados históricos de diversas fontes
de dados, para analises onde são buscados padrões que
são adquiridos com o tempo. Um projeto de data
warehouse (DW) tem como seu principal papel responder
questões relacionadas as áreas de negócio, sendo que se a
empresa não tiver um proposito definido, de nada irá
adiantar coletar dados de diversos sistemas armazenando e
organizando em um DW. Um esquema de dados de banco
transacional, possui várias tabelas que se relacionam para
organizar e armazenar os dados de forma consistente, já o
esquema de dados de um banco dimensional possui menos
tabelas e menos relacionamentos entre elas, onde se usa
uma ou mais tabelas do modelo transacional para criar o
modelo dimensional. Este modelo dimensional possui dois
tipos, sendo eles: o modelo estrela e o modelo floco de
neve, onde ambos os modelos possuem suas tabelas com
os respectivos nomes (dimensões e fatos). O modelo floco
de neve possui tabela(s) que iram conter dados que
auxiliaram uma ou mais tabelas dimensão, como por
exemplo a (dimensão produto pode ter uma tabela de
categoria de produtos), onde esta tabela de categoria de
produtos esta diretamente ligada a dimensão produto
somente, sendo que a dimensão produto esta ligada a
tabela fato de vendas por exemplo. Já o modelo estrela não
possui essas tabela(s) auxiliares ele somente possui tabelas
dimensão e fato, onde as tabelas dimensões armazenam
dados descritivos e contextuais, que auxiliam a tabela fato a
responder as perguntas de negócio. Já as tabelas fato
armazenam dados calculados. Essas perguntas são feitas à
tabela fato, com os seguintes padrões (o que, onde, como e
por que) aconteceu uma determinada situação. Esta
estrutura de dados é utilizada para oferecer melhor
desempenho durante a execução de consultas complexas,
onde são executas em dados que são do tipo leitura e não
necessitam garantir integridade.
2. ETL
A sigla ETL tem como seu significado (Extração,

Transformação e Carga ou em inglês Extract, Transform e
Load), onde seu objetivo é coletar, transformar e carregar
dados em algum local com o propósito de responder a
perguntas de negócio. Estes dados são extraídos de
diversas fontes como: (sistemas OLTPs, arquivos de texto
entre outros).
• Extração: nesta etapa é executada a fase de extração

(coleta) dos dados de diversas fontes onde são
armazenados em um local temporário para que possa ser
executado a próxima etapa do processo.
• Transformação: nesta etapa é executada a fase de

transformação (limpeza) dos dados, onde são corrigidos,
padronizados e tratados deixando-os de acordo com as
regras de negócio.
• Carga: nesta etapa é executada a fase da carga dos dados

que foram extraídos e transformados nas etapas anteriores,
onde é executada a persistência dos dados em algum local
como por exemplo um DW.
3. ELT
A sigla ELT tem como seu significado (Extração, Load e

Transformação), diferente do ETL que extrai, transforma e
carrega.
Ambos os processos tem o mesmo objetivo, mas o trabalho
é executado em ordens diferentes.
Podemos verificar este processo de forma representativa de

acordo com a imagem abaixo
Processo ELT
Após o processo de ELT estiver sido concluído, ele irá gerar

a estrutura base para o DW, onde terá as tabelas
Dimensões e Fatos de um ambiente de DW.
4. Power BI
O Power BI é um conjunto de ferramentas de business

inteligence da empresa MICROSOFT disponibiliza como
produto final várias visualizações gráficas de informações
de forma iterativa para usuários finais. Lançado em 2014
sem sua versão ONLINE e as versões (DESKTOP e Mobile)
respectivamente lançadas em JULHO de 2015 onde ele foi
criado com base no conceito de SELF-SERVICE BI,
permitindo que analistas possam fazer seu trabalho sem a
dependência direta do departamento de TI e também sem
a necessidade de ter conhecimentos profundo sobre o
banco de dados de um sistema ERP (Enterprise Resource
Planning). Ambas as versões desktop e mobile possuem o
seu uso de forma gratuita, onde na versão desktop que é
realizado as publicações dos dashboards online. Já a versão
mobile é uma versão para visualização dos dashboards que
foram criados e publicados pela versão desktop.
Exemplos de telas de cada aplicativo

III Desenvolvimento
1. Problema de Negócio
O gestor deseja saber algumas informações sobre

como está a saúde de sua empresa.
2. Perguntas de Negócio
[] Quantos produtos por pedido
[] Quais os top 10 produtos mais vendem
[] Quais os top 10 produtos menos vendem
[] Quais são as top 10 vendedores que mais vendem
[] Quais são as top 10 vendedores que menos vendem
[] Quais são as top 10 clientes que mais compram
[] Quais são as top 10 clientes que menos compram
[] Quantos produtos foram cancelados
[] Quantos produtos foram entregues
[] Quais os tipos de pagamento existentes
[] Quantos vendedores estão cadastrados por estado
[] Quantos clientes estão cadastrados por estado
[] Quais os tipos de pagamentos cadastrados
[] Quais os tipos de pagamentos mais frequentes
[] Quais os tipos de pagamentos menos frequentes
[] Quais os top 10 pagamentos efetudos mais caros
[] Quais os top 10 pagamentos efetudos mais baratos
[] Quais os top 10 estados que realizam mais pedidos
[] Quais os top 10 estados que realizam menos

pedidos
[] Qual o faturamento total das vendas
[] Qual o faturamento de vendas por ano
[] Qual o faturamento de vendas por mes
[] Qual o faturamento de vendas por dia
[] Qual o faturamento de vendas por produto
[] Qual o faturamento de compras por cliente
[] Qual o faturamento de vendas por vendedor
[] Quais os top 10 fretes mais caros
[] Quais os top 10 fretes mais baratos

[] Qual o estado que mais compra
[] Qual o estado que menos compra
[] Qual o estado que mais vende
[] Qual o estado que menos vende
3. Coleta de Dados
Nesta etapa foi feito a extração dos dados

diponibilizados no Kaggle.
link: https://www.kaggle.com/datasets/olistbr/brazilia
n-ecommerce
4. Banco de Dados
O modelo de dados relacional apresentado na Figura 2, é

baseado em uma estrutura existente de um banco
transacional apresentado na Figura 1. O sistema de banco
de dados escolhido para armazenar tal estrutura e seus
respectivos dados já existentes em arquivos (.csv)
disponibilizados no site
{https://www.kaggle.com/datasets/olistbr/brazilian-
ecommerce}, foi o PostgreSQL
Figura 1 - Estrutura base para modellagem do banco de dados transacional
Figura 2 - Modelo de Dados Transacional

5. Conhecendo os Dados
Nesta etapa foi realizado uma analise dos dados, para

entender como será desenvolvido o modelo
dimensional que terá como foco responder as
perguntas de negócio, sem que atrapalhe as operações
diárias do sistema transacional.
Foi utilizado a linguagem de programação Python

junto a biblioteca Pandas para realizar esta análise dos
dados.
6. Data Warehouse
O modelo de dados dimensional apresentado na Figura 3,

foi estruturado com base na modelagem de dados
transacional apresentado na Figura 2. O modelo
dimensional apresentado abaixo é chamado de modelo
estrela, o mesmo tem como seu principal objetivo manter a
redundância dos dados, evitando fortes ligações entre
tabelas, obtendo melhores resultados no retorno de
consultas feitas no banco de dados dimensional.. O sistema
de banco de dados escolhido para armazenar tal estrutura
e seus respectivos dados gerados a partir de uma base de
dados existente transacional, foi o PostgreSQL.
Figura 3 - Modelo de Dados Dimensional
O modelo de dados apresentado na figura 3, possui

alguns campos que foram definidos e que não estão sendo
utilizados no momento, como por exemplo na dimensão
dim_products os valores (product_photos_qty,
product_width_cm, product_height_cm, product_length).
Esses valores tem como proposta de entrarem como
valores relevantes para analises, onde por exemplo o
campo product_photos_qty poderá ser utilizado para
determinar se um cliente comprará um produto ou não.
Isso pode ser levando em consideração quando falamos de
várias fotos de diferentes ângulos do produto podem
influenciar na decisão do cliente em comprar o produto ou
não. Expor várias fotos ao cliente transmite uma experiência
de analisar o produto como se ele estivesse vendo o
produto fisicamente.
7. ELT
Nesta etapa de ELT foram definidas as tarefas que serão

realizadas enquanto os dados do banco transacional são
extraídos e carregados na Staging.
Na sequencia são extraídos da Staging e transformados

para serem carregados no Data Warehouse.
Na fase de extração foi definido que os dados serão

copiados da base de dados transacional para uma base
Staging todo dia durante a madrugada. Assim que o
processo de extração é concluído a fase de transformação
de dados é executada, tratando os dados com base em
regras de limpeza e transformações nos dados. Com a
etapa de transformação concluída é iniciada a fase de carga
dos dados no Data Warehouse, onde é executada a
persistência dos dados extraídos e transformados nas
etapas anteriores. Após a carga de dados estiver concluída,
os dashboards serão atualizados automaticamente.
Para a execução de tal tarefa serão criadas rotinas para o

tratamento dos dados que serão extraídos do banco de
dados transacional da empresa e armazenado na Staging.
Um job que será disparado todo dia durante madrugada,
onde o mesmo será responsável em fazer a extração dos
dados da base transacional e sua respectiva carga ao final
da execução do job na base staging. Na sequencia será
disparado um job de extração, transformação e carga ao
final da execução do job na base Data Warehouse.3.1
Passo-a-passo do processo de ELT.
7.1. Representação do processo ELT
• Nesta etapa podemos visualizar uma representação do

processo de ELT completo que será realizado.
7.1.1. Etapa 1 Carga dos arquivos .csv no banco

de dados OLTP
Figura 4 - Etapa 1 Carga dos arquivos .csv no banco de dados OLTP
7.1.2. Etapa 2 Carga dos dados do OLTP para

STAGING
Figura 5 - Etapa 2 Carga dos dados do OLTP para STAGING
7.1.3. Etapa 3 Limpeza e transformações

carregando no Data Warehouse
Figura 6 - Etapa 3 Limpeza e transformações carregando no Data Warehouse
7.1.4. Etapa 4 Apresentação dos Resultados

Figura 7 - Etapa 4 Apresentação dos Resultados
8. Configuração docker-compose
Nesta etapa foi adicionado um arquivo docker-

compose.yml com as configurações dos bancos de
dados que serão utilizados.
O serviço de oltp será responsável por armazenar as

tabelas do banco de dados transacional, que serão
carregados dos arquivos .csv que foram obtidos já em
etapas anterios.
O serviço de dw será responsável por armazenar as

tabelas do banco de daaos analitico, que serão
carregados com a extração dos dados que estão no
banco de dados transacional.
9. Definição de conexões com os bancos de

dados
Figura 8 - Definição de conexões com os bancos de dados
10. Conexões do Pentaho PDI
Figura 9 - Conexões com os bancos de dados no Pentaho PDI
10.1. Job Start_oltp_full
A estrutura na figura 10 representa a execução do Job

“Start_oltp_full” com sucesso, onde cada componente
transform com um nome representa uma tabela no banco
de dados onde o processo segue para o próximo quando o
atual finaliza até chegar no componente “Sucess”, onde é
finalizado o Job “Start_oltp_full”
Figura 10 - Job Start_oltp_full
10.2. Representação da referencia da transform

geolocation do Job Start_oltp_full
Figura 11 - Representação de referencia da transform geolocation no Job

Start_oltp_full
As demais referencias das transforms (sellers, customers,

products, payments, orders, order_items) seguem o mesmo
estilo representado na imagem acima figura 11
10.3. Transform Geolocation
A estrutura na figura 12 representa a transform

“Geolocation”, onde é feito uma consulta nos dados que
estão armazenados em um arquivo “.csv” onde esses dados
serão armazenados em uma tabela no banco de dados oltp
que foi estruturada com base no arquivo “.csv”
Figura 12 - Transform Geolocation
10.3.1. SQL Geolocation
CREATE TABLE public.geolocation (
geolocation_zip_code_prefix int8 NOT NULL,
geolocation_lat numeric(18, 15) NULL,
geolocation_lng numeric(18, 15) NULL,
geolocation_city varchar(100) NULL,
geolocation_state varchar(2) NULL,

CONSTRAINT geolocation_pk PRIMARY KEY
(geolocation_zip_code_prefix)
);
10.4. Transform Sellers
A estrutura na figura 13 representa a transform “Sellers”,

onde é feito uma consulta nos dados que estão
armazenados em um arquivo “.csv” onde esses dados serão
armazenados em uma tabela no banco de dados oltp que
foi estruturada com base no arquivo “.csv”
Figura 13 - Transform Sellers
10.4.1 SQL Sellers
CREATE TABLE public.sellers (
seller_id varchar(32) NOT NULL,
seller_zip_code_prefix int8 NULL,
seller_city varchar(100) NULL,
seller_state varchar(2) NULL,
CONSTRAINT sellers_pk PRIMARY KEY (seller_id)
);
10.5. Transform Customers

“Cutomers”, onde é feito uma consulta nos dados que
que foi estruturada com base no arquivo “.csv”
Figura 14 - Transform Customers

10.5.1. SQL Customers
CREATE TABLE public.customers (
customer_id varchar(32) NOT NULL,
customer_unique_id varchar(32) NULL,
customer_zip_code_prefix int8 NULL,
customer_city varchar(100) NULL,
customer_state varchar(2) NULL,
CONSTRAINT cutomers_pk PRIMARY KEY (customer_id)
);
10.6. Transform Products
A estrutura na figura 15 representa a transform “Products”,

foi estruturada com base no arquivo “.csv”
Figura 15 - Transform Products
10.6.1. SQL Products
CREATE TABLE public.producs (
product_id varchar(32) NOT NULL,
product_category_name varchar(100) NULL,
product_name_lenght int8 NULL,
product_description_lenght int8 NULL,
product_photos_qty int8 NULL,
product_weight_g int8 NULL,
product_length_cm int8 NULL,
product_height_cm int8 NULL,
product_width_cm int8 NULL,

CONSTRAINT products_pk PRIMARY KEY (product_id)
);
10.7. Transform Payments

“Payments”, onde é feito uma consulta nos dados que
que foi estruturada com base no arquivo “.csv”.
Figura 16 - Transform Payments
10.7.1. SQL Payments
CREATE TABLE public.order_payments (
order_id varchar(32) NOT NULL,
payment_sequential int8 NOT NULL,
payment_type varchar(11) NULL,
payment_installments int8 NULL,
payment_value int8 NULL,
CONSTRAINT order_payments_pk PRIMARY KEY (order_id,

payment_sequencial)
);
10.8. Transform Orders
A estrutura na figura 17 representa a transform “Orders”,

foi estruturada com base no arquivo “.csv”.
Figura 17 - Transform Orders

10.8.1. SQL Orders
CREATE TABLE public.orders (
order_id varchar(32) NOT NULL,
customer_id varchar(32) NULL,
order_status varchar(16) NULL,
order_purchase_timestamp date NULL,
order_approved_at timestamp NULL,
order_delivered_carrier_date date NULL,
order_delivered_customer_date date NULL,
order_estimated_delivery_date date NULL,
CONSTRAINT orders_pk PRIMARY KEY (order_id)
);
10.9. Transform Order_Items

“Order_Items”, onde é feito uma consulta nos dados que
que foi estruturada com base no arquivo “.csv”.
Figura 18 - Order_Items
10.9.1. SQL Order_Items
CREATE TABLE public.order_items (
order_id varchar(32) NULL,
order_item_id int8 NOT NULL,
product_id varchar(32) NULL,
seller_id varchar(32) NULL,
shipping_limit_date date NULL,
price int8 NULL,
freight_value int8 NULL,

CONSTRAINT order_items_pk PRIMARY KEY (order_id,
order_item_id)
);
11. Job Start_staging_full

“Start_staging_full” com sucesso, onde cada componente
finalizado o Job “Start_staging_full”
Figura 19 - Job Start_staging_full
11.1. Transform Sellers
A estrutura na figura 20 representa a transform “Sellers”,

onde é feito uma consulta no banco de dados OLTP e
carregado no banco de dados STAGING para que possa ser
feito os tratamentos nos dados e carregados em um Data
Warehouse, onde ferramentas de visualização iram
conectar para desenvolver Dashboards representando as
respostas das perguntas de negócio.
Figura 20 - Transform Sellers
As demais transforms (Geolocation, Customers, Products,

Payments, Orders e Order_Items) seguem a mesma
estrutura da figura 20
11.1.1. SQL Sellers
CREATE TABLE public.sellers (
seller_id varchar(32) NOT NULL,

CONSTRAINT sellers_pk PRIMARY KEY (seller_id)
);
12. Job Start dw full

“Start_dw_full” com sucesso, onde cada componente
finalizado o Job “Start_dw_full”
Figura 21 - Job Start_ dw_full
12.1. Transform Dim_Sellers

“Dim_Sellers”, onde é feito uma consulta no banco de
dados STAGING realizando as transformações necessárias e
carregado no banco de dados Data Warehouse, onde
ferramentas de visualização iram conectar para desenvolver
Dashboards representando as respostas das perguntas de
negócio.
Figura 22 - Dim_Sellers
12.1.1. SQL Dim_Sellers
CREATE TABLE public.dim_sellers (
sk_seller_id bigserial NOT NULL,
nk_seller_id varchar(32) NULL,

dt_load date NULL
);
CREATE UNIQUE INDEX idx_dim_sellers_pk ON

public.dim_sellers USING btree (sk_seller_id);
12.2. Transform Dim_Customers

“Dim_Customers”, onde é feito uma consulta no banco de
negócio.
Figura 23 - Dim_Customers
12.2.1. SQL Dim_Customers
CREATE TABLE public.dim_customers (
sk_customer_id bigserial NOT NULL,
nk_customer_id varchar(32) NULL,
customer_unique_id varchar(32) NULL,
customer_zip_code_prefix int8 NULL,
customer_city varchar(100) NULL,
customer_state varchar(2) NULL,
dt_load date NULL
);
CREATE UNIQUE INDEX idx_dim_customers_pk ON
public.dim_customers USING btree (sk_customer_id);
12.3. Transform Dim_Products

“Dim_Products”, onde é feito uma consulta no banco de
negócio.
Figura 24 - Dim_Products
12.3.1. SQL Dim_Products
CREATE TABLE public.dim_products (
sk_product_id bigserial NOT NULL,
nk_product_id varchar(32) NULL,
product_category_name varchar(100) NULL,
product_name_lenght int8 NULL,
product_description_lenght int8 NULL,
product_photos_qty int8 NULL,
product_weight_g int8 NULL,
product_length_cm int8 NULL,
product_height_cm int8 NULL,
product_width_cm int8 NULL,
dt_load date NULL
);
CREATE UNIQUE INDEX idx_dim_products_pk ON
public.dim_products USING btree (sk_product_id);
12.4. Transform Dim_Payments

“Dim_Payments”, onde é feito uma consulta no banco de
negócio.
Figura 25 - Dim_Payments
12.4.1. SQL Dim_Payments
CREATE TABLE public.dim_payments (
sk_payments bigserial NOT NULL,
nk_order_id varchar(32) NULL,
nk_payment_sequential int8 NULL,
payment_type varchar(11) NULL,
payment_installments int8 NULL,
payment_value int8 NULL,
dt_load date NULL
);
CREATE UNIQUE INDEX idx_dim_payments_pk ON

public.dim_payments USING btree (sk_payments);
12.5. Transform Dim_Tempo

“Dim_Tempo”, onde é feito uma consulta no banco de
negócio.
Figura 26 - Dim_Tempo
12.5.1. SQL Dim_Tempo
CREATE TABLE public.dim_tempo (
sk_tempo_id bigserial NOT NULL,
order_approved_at timestamp NULL,
ano int4 NULL,
mes int4 NULL,
dia int4 NULL,
dt_load date NULL
);
CREATE UNIQUE INDEX idx_dim_tempo_pk ON

public.dim_tempo USING btree (sk_tempo_id);
Report this
Published by
Wesley Steve 2 Follow

Engenheiro de Dados | Desenvolvedor ETL | Analista de BI | Data Engineer | Pyt…
Published • 12mo
articles
Like Comment Share 4 1 comment
Reactions
1 Comment
Most relevant
Add a comment…
Wallace Camargo • 3rd+ 12mo

Consultor de Business Intelligence | BI Developer | Data Engineer | Data
Analyst | ETL & ELT | Big Data | DataViz | SQL Developer | Power BI | Python |
Spark | Databricks | Azure | GCP | Airflow
Muito bom Wesley!!! Parabéns!!@

See translation
Like · 1 Reply
Wesley Steve
Engenheiro de Dados | Desenvolvedor ETL | Analista de BI | Data Engineer | Python |
SQL | Power BI | Pentaho | Linux |
Follow
More from Wesley Steve
Quem sou eu?
Wesley Steve on LinkedIn

Construindo Um Projeto de Analise de Dados de Um Sistema de E-Commerce - LinkedIn

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Construindo Um Projeto de Analise de Dados de Um Sistema de E-Commerce - LinkedIn

Enviado por

Direitos autorais:

Formatos disponíveis

10

Home My Network Jobs Messaging Notifications Me For Business

November 11, 2022

Open Immersive Reader

Este artigo apresenta uma proposta de uma modelagem de

Data Warehouse, business intelligence, banco de dados

A tecnologia da informação está em constante evolução e

O objetivo deste trabalho é construir um data warehouse

No banco de dados da empresa estão armazenados dados

• Python como linguagem de programação utilizando junto

• Jupyter Notebook para fazer as analises iniciais entendo

• Sistema gerenciador de banco de dados PostgreSQL

• Docker / Docker-compose para subir o banco de dados

• Ferramentas para o ETL Pentaho 9.3 PDI

• Ferramenta para a modelagem do banco de dados SQL

• Ferramenta DBeaver para visualizar as estruturas dos

• Ferramenta para construção dos dashboards Power BI

• Git para controle de versão

• Github para o armazenamento do projeto

Este trabalho está sendo realizando utilizando as seguintes

• Coleta dos dados

• Modelo de dados transacional

• Modelagem do Data Warehouse

• Desenvolvimento do processo ELT

A sigla ETL tem como seu significado (Extração,

• Extração: nesta etapa é executada a fase de extração

• Transformação: nesta etapa é executada a fase de

• Carga: nesta etapa é executada a fase da carga dos dados

A sigla ELT tem como seu significado (Extração, Load e

Podemos verificar este processo de forma representativa de

Após o processo de ELT estiver sido concluído, ele irá gerar

O Power BI é um conjunto de ferramentas de business

Exemplos de telas de cada aplicativo

O gestor deseja saber algumas informações sobre

[] Quantos produtos por pedido

[] Quais os top 10 produtos mais vendem

[] Quais os top 10 produtos menos vendem

[] Quais são as top 10 vendedores que mais vendem

[] Quais são as top 10 vendedores que menos vendem

[] Quais são as top 10 clientes que mais compram

[] Quais são as top 10 clientes que menos compram

[] Quantos produtos foram cancelados

[] Quantos produtos foram entregues

[] Quais os tipos de pagamento existentes

[] Quantos vendedores estão cadastrados por estado

[] Quantos clientes estão cadastrados por estado

[] Quais os tipos de pagamentos cadastrados

[] Quais os tipos de pagamentos mais frequentes

[] Quais os tipos de pagamentos menos frequentes

[] Quais os top 10 pagamentos efetudos mais caros

[] Quais os top 10 pagamentos efetudos mais baratos

[] Quais os top 10 estados que realizam mais pedidos

[] Quais os top 10 estados que realizam menos

[] Qual o faturamento total das vendas

[] Qual o faturamento de vendas por ano

[] Qual o faturamento de vendas por mes

[] Qual o faturamento de vendas por dia

[] Qual o faturamento de vendas por produto

[] Qual o faturamento de compras por cliente

[] Qual o faturamento de vendas por vendedor

[] Quais os top 10 fretes mais caros

[] Quais os top 10 fretes mais baratos

[] Qual o estado que menos compra