O que você vai
aprender hoje.
Objetivos — Taxonomia de Bloom
Lembrar 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.
Compreender 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.
Aplicar Classificar exemplos de fontes, dados e sistemas de acordo com as categorias apresentadas e mapear a jornada de um dado em um processo real.
Analisar Examinar como a estrutura de um banco de dados determina quais perguntas de negócio podem ou não ser respondidas, identificando lacunas arquiteturais.
Avaliar 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 MÁQUINAS CORPORAÇÕES
Pessoas
Redes sociais, transações, localização, comportamento digital.
Máquinas
Sensores IoT, drones, câmeras, equipamentos industriais.
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 pergunta DECISÃO
Dado
Número bruto. Sem contexto, não responde perguntas.
Informação
Dado + contexto + significado. Responde "o quê" e "quando".
Decisão
Informação + pergunta certa = ação de negócio.
A mesma base.
Dois propósitos.
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.
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.