Questões de Concurso sobre Arquitetura de DW

implementar um Data Warehouse Enterprise (EDW) baseado em banco de dados relacional com modelagem normalizada (3FN) para todos os dados, garantindo a integridade referencial tanto das vendas quanto dos logs, visto que a normalização é a única forma de garantir consistência ACID em escala de petabytes;

adotar uma arquitetura Data Lake pura (baseada em Hadoop/HDFS ou Object Storage), utilizando a abordagem Schema-on-Read para todos os consumidores; isso atenderá à equipe de ciência de dados, e a equipe de BI deverá adaptar suas ferramentas para realizar as agregações e junções em tempo de execução, aceitando a latência inerente à varredura de arquivos brutos;

manter a separação física, construindo um Data Mart dimensional para cada departamento dentro de um banco relacional proprietário e utilizando ferramentas de federação de dados (Data Virtualization) para que a equipe de ciência de dados consulte o Data Mart em tempo real, evitando assim a construção de um Data Lake e garantindo que o modelo de dados seja sempre Schema-on-Write;

utilizar um banco de dados NoSQL orientado a documentos (como MongoDB) para centralizar tanto as vendas quanto os logs, aproveitando a flexibilidade do esquema (schemaless) para ingerir dados heterogêneos rapidamente, e resolver a necessidade de BI através de processos de desnormalização extrema, armazenando todos os dados relacionados em um único documento aninhado para evitar joins;

implementar uma arquitetura Lakehouse, utilizando formatos de tabela abertos (como Delta Lake ou Apache Iceberg) sobre o armazenamento de objetos; isso permite aplicar transações ACID e Schema Enforcement nos dados de vendas, enquanto se adota uma modelagem dimensional (esquema estrela) na camada "Gold" para performance de BI, mantendo os dados brutos (camada "Bronze") acessíveis para Machine Learning.

a desnormalização tem como objetivo principal otimizar as operações de escrita (inserts e updates), pois, ao repetir os dados em uma única tabela, o banco de dados elimina a necessidade de verificar restrições de integridade referencial em múltiplas tabelas;

a estratégia adotada visa a reduzir a quantidade de junções (joins) necessárias durante as consultas analíticas, melhorando o desempenho de leitura, embora isso acarrete aumento do espaço de armazenamento e risco de anomalias de atualização;

a manutenção do modelo na Terceira Forma Normal (3FN) seria a escolha ideal para o Data Warehouse, pois a normalização maximiza a performance de consultas de agregação ao garantir que os dados não estejam duplicados, facilitando a leitura sequencial do disco;

desnormalização é um requisito obrigatório para bancos de dados NoSQL, mas é tecnicamente inviável em bancos de dados relacionais (SQL), visto que estes não suportam a existência de redundância de dados dentro de uma mesma tabela;

ao desnormalizar as tabelas, o arquiteto está transformando o modelo em um esquema floco de neve (Snowflake), que é caracterizado justamente pelo uso de tabelas de dimensão únicas e planas, contendo todos os atributos descritivos sem relacionamentos hierárquicos externos.

Banco OLTP com schema-on-select normalizado com histórico analítico consolidado e consultas agregadas.

Data Warehouse com ETL completo antes de qualquer persistência no armazenamento.

Data Warehouse relacional com schema-on-write e modelagem dimensional prévia.

Data Mart departamental com escopo restrito a relatórios de arrecadação configurados com schema-on-search.

Data Lake com schema-on-read para ingestão e retenção de dados brutos multiformato.

avaliar a qualidade dos dados em um conjunto de dados.

carregar os conjuntos de dados em outro Data Lake.

ter várias linhas em um conjunto de dados.

realizar o controle de acesso aos conjuntos de dados.

verificar se as cópias de segurança dos conjuntos de dados estão fiéis aos dados originais.

data mining.

data warehouse.

data lakehouse.

data mart.

data lake.