O que você vai
aprender hoje.
Objetivos
Reconhecer as três fontes geradoras de dados (pessoas, máquinas, corporações) e os principais tipos de bancos de dados, associando cada um às suas características.
Explicar a cadeia dado → informação → decisão e distinguir o uso operacional (OLTP) do analítico (OLAP) em situações concretas de negócio.
Classificar exemplos de fontes, dados e sistemas de acordo com as categorias apresentadas e mapear a jornada de um dado em um processo real.
Examinar como a estrutura de um banco de dados determina quais perguntas de negócio podem ou não ser respondidas, identificando lacunas arquiteturais.
Julgar se uma arquitetura de dados é adequada para suportar um determinado processo de decisão ou análise, argumentando com base nos conceitos da aula.
Três origens.
Todos os dados.
Pessoas gerando dados por meio de redes sociais e dispositivos móveis.
Pessoas
Redes sociais, transações, localização, comportamento digital.
Máquinas e sensores gerando dados em ambientes industriais.
Máquinas
Sensores IoT, drones, câmeras, equipamentos industriais.
Corporações gerando dados por meio de sistemas transacionais.
Corporações
ERP, CRM, sistemas transacionais, registros financeiros.
Do número bruto
à decisão de negócio.
DADO 847 contexto INFORMAÇÃO vendas caíram 12% em março padrão CONHECIMENTO a queda se repete todo mês de março pergunta DECISÃO
Dado
Número bruto. Sem contexto, não responde perguntas.
Informação
Dado + contexto + significado. Responde "o quê" e "quando".
Conhecimento
Informação + padrão + experiência. Responde "por quê" e permite antecipar.
Decisão
Conhecimento + pergunta certa = ação de negócio.
A mesma base.
Dois propósitos.
Comparação entre dado transacional (operacional) e dado analítico.
OLTP OPERACIONAL Registra transações Alta velocidade de escrita Dados atuais Tabelas normalizadas Ex: ERP, e-commerce, CRM VS OLAP ANALÍTICO Responde perguntas Alta velocidade de leitura Dados históricos Estrutura dimensional Ex: Data Warehouse, BI
Mesma base
Dados transacionais alimentam os sistemas analíticos após integração.
Propósitos
  • Operacional: executar o negócio.
  • Analítico: entender e decidir.
Granularidade
  • Operacional: guarda o evento individual — um pedido, um clique.
  • Analítico: agrega por dia, região ou produto.
Escolher a granularidade errada é perder a pergunta antes de fazê-la.
Sete critérios.
Duas lógicas.

Clique em cada critério para revelar a comparação.

Finalidade +
OLAP
Analisar grandes volumes de dados para apoiar a tomada de decisões.
OLTP
Gerenciar e processar transações em tempo real.
Fonte de dados +
OLAP
Dados históricos e agregados de várias fontes.
OLTP
Dados transacionais e em tempo real de uma única fonte.
Estrutura de dados +
OLAP
Bancos de dados multidimensionais (cubos) ou relacionais.
OLTP
Bancos de dados relacionais.
Modelo de dados +
OLAP
Esquema em estrela, esquema de floco de neve ou outros modelos analíticos.
OLTP
Modelos normalizados ou desnormalizados.
Volume de dados +
OLAP
Grandes requisitos de armazenamento — terabytes (TB) e petabytes (PB).
OLTP
Requisitos comparativamente menores — gigabytes (GB).
Tempo de resposta +
OLAP
Tempos de resposta mais longos — normalmente segundos ou minutos.
OLTP
Tempos de resposta mais curtos — normalmente milissegundos.
Aplicativos de exemplo +
OLAP
Analisar tendências, prever comportamento do cliente e identificar lucratividade.
OLTP
Processar pagamentos, gerenciar dados de clientes e processar pedidos.
Do dado bruto
à decisão.
01 Geração Fontes 02 Armazena- mento BD / Lake 03 Integração ETL / DW 04 Análise BI / ML 05 Decisão Gestão
Governança
Políticas de qualidade e uso dos dados permeiam cada etapa.
Integração
Múltiplos sistemas transacionais consolidados em Data Warehouse ou Data Lake.
Modelo de dados
Mapeia relações para atender às necessidades de negócio.
Quatro características.
Uma definição.
BANCO DE DADOS ESTRUTURADO Dados organizados RELACIONADO Dados conectados ELETRÔNICO Armazenado digitalmente ACESSÍVEL Gerenciado via SGBD
SGBD
Cria, modifica e gerencia objetos: tabelas, views, índices, schemas.
Operações
Gerencia requisições, transações e controle de acesso concorrente.
Seis categorias.
Da herança ao presente.
Categoria Exemplos Características
Dinossauros IMS, ADABAS Primeiras implementações. Sistemas legados.
Elefantes Oracle, IBM, Teradata Maduros, robustos, rodam em mainframes e minicomputadores.
Open Source MySQL, PostgreSQL, MariaDB Código aberto, baixo custo, ampla adoção.
In-Memory SAP HANA Dados na RAM: acesso muito mais rápido que discos.
NoSQL MongoDB, Cassandra, DynamoDB Dados não estruturados. Escala com a explosão digital.
DBaaS AWS RDS, Azure SQL Banco como serviço em cloud. Deploy rápido.
A arquitetura
limita as perguntas.
CAMADA 1 Arquitetura do Banco de Dados determina CAMADA 2 Perguntas Possíveis ? orienta CAMADA 3 Decisões de Negócio
Para o gestor
Entender a estrutura do BD é saber quais perguntas são possíveis de fazer.
Consequência
Perguntas fora da arquitetura exigem reestruturação ou novas fontes.
Implicação prática
Antes de decidir, verifique se os dados necessários estão estruturados.
Número que impressiona
não é número que decide.
O critério
Uma métrica só é acionável se a resposta a "e daí?" for uma ação concreta. Se ela apenas sobe e faz todo mundo se sentir bem, é métrica de vaidade. A diferença não está no número — está em o que ele permite decidir.
Métrica de vaidade
120 mil seguidores. Cresce sempre, nunca cai e não distingue quem compra de quem apenas observa. Nenhuma decisão de negócio muda em função dela.
Métrica acionável
Taxa de conversão por canal. Aponta onde investir e onde cortar verba. Uma queda tem causa rastreável e uma resposta possível.
Pergunta de testeVaidadeAcionável
Ela pode cair?Quase nuncaSim, e isso é um alerta
Aponta uma causa?NãoSim, é segmentável
Muda alguma decisão?NãoSim, define onde agir
Tem dono?Ninguém responde por elaUma área responde
Onde isso encontra a arquitetura
Transformar uma métrica de vaidade em acionável quase sempre exige dados que o banco ainda não guarda — origem do cadastro, data do primeiro pedido, canal de aquisição. É por isso que a estrutura de dados vem antes do dashboard: sem o campo armazenado, a pergunta não tem resposta.