Trabalho de Gerência de Dados

Este trabalho tem como objetivo aprofundar o estudo e a aplicação de diferentes paradigmas de modelagem e gerenciamento de dados Para isso o aluno deverá selecionar e definir um problema real ou hipotético que possa ser resolvido eou aprimorado através da aplicação de diferentes abordagens de banco de dados A proposta abrange a elaboração e análise comparativa de soluções utilizando tecnologias de banco de dados consagradas e emergentes As atividades a serem desenvolvidas incluem 1 Definição do Problema O primeiro passo fundamental será a identificação e descrição detalhada de um problema de negócio ou científico Este problema servirá como base para a aplicação das diferentes abordagens de modelagem de dados Exemplos de possíveis problemas o Sistema de Gerenciamento de Pedidos Online Como modelar e gerenciar dados de produtos clientes pedidos e histórico de compras em diferentes paradigmas o Plataforma de Monitoramento de Sensores IoT Como coletar armazenar e processar dados de telemetria de sensores em tempo real além de persistir dados históricos para análise o Rede Social Simplificada Como armazenar perfis de usuários conexões amizadesseguidores postagens e comentários e otimizar consultas de relacionamentos o Análise de Dados Financeiros de Transações Bancárias Como registrar transações manter saldos de contas e identificar padrões ou fraudes em um fluxo contínuo de operações o Sistema de Rastreamento de Logística de Entregas Como gerenciar a localização de veículos status de entregas e otimizar rotas com dados em movimento 2 Elaboração de um Modelo Relacional e Uso de um Banco de Dados NoSQL para a Resolução do Mesmo Problema Após a definição do problema o aluno deverá analisar projetar e implementar um modelo de dados relacional para a solução Em seguida deverá elaborar e implementar um modelo de dados NoSQL podendo ser documento chave valor grafo coluna larga etc que resolva o mesmo problema O objetivo é explorar as diferenças de abordagem desempenho e flexibilidade entre os dois paradigmas para o cenário escolhido 3 Elaboração de um Modelo para Ingestão de Stream de Dados Desenvolvimento de um modelo e arquitetura para a ingestão processamento e opcionalmente análise de dados em tempo real stream de dados aplicando conceitos e tecnologias apropriadas para este cenário ex Apache Kafka Apache Flink Apache Spark Streaming etc Este modelo deve se integrar à solução do problema definido lidando com a natureza dinâmica dos dados Entrega O projeto final deverá ser formalizado em um relatório técnicocientífico e acompanhado dos artefatos de código desenvolvidos Os itens de entrega esperados são Descrição do Problema Uma descrição clara e detalhada do problema definido pelo aluno incluindo seu contexto requisitos funcionais e nãofuncionais escopo e justificativa para a escolha das diferentes abordagens de modelagem Relatório com os Modelos Relacional NoSQL Stream o Modelo Relacional Diagrama EntidadeRelacionamento DER DDL Data Definition Language para criação das tabelas e opcionalmente população de dados de exemplo o Modelo NoSQL Esquema lógico do modelo NoSQL adotado ex estrutura de documentos JSON nós e relacionamentos para grafos exemplos de dados e queries representativas o Modelo de Stream Diagrama de arquitetura da solução de ingestão e processamento de stream descrição dos componentes e fluxo de dados Justificativa do Uso dos Modelos Análise comparativa aprofundada das vantagens e desvantagens de cada modelo Relacional NoSQL e Stream para o problema específico escolhido Incluir justificativas para as escolhas tecnológicas considerações de desempenho escalabilidade flexibilidade e custo Código Adotado para o Desenvolvimento dos Modelos Todo o códigofonte desenvolvido incluindo scripts de criação de schemas populações de dados queries de exemplo scripts de processamento de stream e qualquer outro código necessário para reproduzir e validar os modelos e as soluções propostas O código deve ser bem organizado e documentado Relatório TécnicoCientífico Análise Comparativa de Paradigmas de Modelagem de Dados para um Sistema de Logística Resumo Este trabalho apresenta um estudo aprofundado sobre a aplicação de diferentes paradigmas de modelagem de dados na resolução de um problema complexo de logística Foi definido um cenário hipotético para a empresa LogiEntregas cujas necessidades abrangem desde transações consistentes até o processamento de dados de rastreamento em tempo real Foram projetados e analisados três modelos distintos um Relacional para o núcleo transacional um NoSQL orientado a documento para dados de telemetria e uma arquitetura de Stream para a ingestão de dados em tempo real A análise comparativa final demonstra a superioridade de uma abordagem híbrida que combina as forças de cada paradigma para criar uma solução robusta escalável e performática 1 Descrição do Problema A etapa inicial deste projeto consiste na identificação e descrição detalhada de um problema de negócio que servirá como base para a aplicação das diferentes abordagens de modelagem de dados O problema selecionado foi o Sistema de Rastreamento de Logística de Entregas um cenário que encapsula desafios de consistência transacional grande volume de dados Big Data e processamento em tempo real 11 Contexto Definese como estudo de caso a LogiEntregas uma empresa fictícia de logística que opera em um mercado altamente competitivo impulsionado pelo crescimento exponencial do e commerce A expectativa dos clientes por entregas rápidas e rastreamento preciso tornouse um diferencial crítico Atualmente a empresa utiliza um sistema legado monolítico e sustentado por um único banco de dados relacional Esta arquitetura embora funcional no passado tornouse um gargalo operacional resultando em Lentidão em Consultas A equipe de logística enfrenta demoras para gerar relatórios e consultar o status de entregas especialmente em horários de pico Dificuldade de Processamento O sistema não foi projetado para o fluxo contínuo e massivo de dados de localização GPS enviados pela frota resultando em informações de rastreamento desatualizadas Reclamações de Clientes A imprecisão no rastreamento gera insatisfação e aumenta os custos com atendimento ao cliente Rigidez para Inovação A introdução de novos serviços como o monitoramento de temperatura para cargas refrigeradas é inviabilizada pela rigidez do esquema do banco de dados atual Diante deste cenário a LogiEntregas necessita de uma nova arquitetura de dados que seja moderna escalável e flexível para sustentar seu crescimento e competitividade 12 Requisitos Funcionais Os requisitos funcionais detalham as operações que o sistema deve ser capaz de executar Gerenciamento de Cadastros O sistema deve permitir operações de CRUD Criar Ler Atualizar Deletar para as entidades centrais Clientes Motoristas e Veículos Gestão de Pedidos Deve ser possível registrar novos pedidos de entrega associandoos a um cliente definindo origem destino e destinatário Alocação de Entregas A plataforma deve permitir que a equipe de logística associe um pedido a um motorista e um veículo dando início à operação de entrega Ingestão de Telemetria Deve existir um endpoint ou serviço capaz de receber e armazenar dados de telemetria no mínimo latitude longitude e timestamp enviados pelos veículos em intervalos regulares ex a cada 30 segundos Atualização de Status O status de uma entrega ex Aguardando Coleta Em Trânsito Entregue deve ser atualizado tanto por eventos automáticos baseados na localização quanto por ações manuais dos motoristas Consulta de Rastreamento Visão do Cliente Clientes devem poder consultar através de uma interface simples o status atual e o último local conhecido de sua entrega Visão da Logística A equipe de logística deve ter acesso a um painel para visualizar a posição de toda a frota em um mapa em tempo real 13 Requisitos Não Funcionais Os requisitos não funcionais definem os atributos de qualidade do sistema Escalabilidade O sistema deve ser projetado para escalar horizontalmente suportando um crescimento projetado de 50 na frota e 100 no volume de dados de telemetria no próximo ano sem a necessidade de investimentos maciços em hardware escalabilidade vertical Disponibilidade O serviço de consulta de rastreamento para o cliente final é uma funcionalidade crítica e deve ter uma disponibilidade de 999 uptime Baixa Latência O tempo entre o envio de uma coordenada GPS por um veículo e sua disponibilização para consulta endtoend latency deve ser inferior a 5 segundos Flexibilidade e Extensibilidade A arquitetura de dados deve ser flexível o suficiente para permitir a adição de novos tipos de dados de sensores ex temperatura umidade aceleração no futuro sem exigir migrações de esquema complexas e demoradas Consistência As informações transacionais dados financeiros do pedido associação com o cliente devem ser armazenadas com garantias de consistência forte ACID assegurando a integridade e a confiabilidade dos dados de faturamento 14 Escopo e Justificativa O escopo deste trabalho está estritamente focado na modelagem e na arquitetura de dados da solução excluindo o desenvolvimento de interfaces de usuário frontend ou a implementação de regras de negócio complexas como otimização de rotas A justificativa para a análise de múltiplos paradigmas reside na natureza heterogênea dos dados e requisitos do problema Modelo Relacional Constitui a escolha natural para o núcleo transacional do sistema A necessidade de consistência forte ACID para operações de cadastro e faturamento aliada à integridade referencial garantida por chaves estrangeiras torna este modelo indispensável para a confiabilidade dos dados mestres Modelo NoSQL O volume a velocidade e a variedade dos dados de telemetria caracterizam um problema de Big Data Um banco de dados NoSQL orientado a documento é ideal para este cenário oferecendo a flexibilidade de esquema necessária para a evolução dos sensores e a escalabilidade horizontal para lidar com o crescimento massivo de dados de forma econômica Modelo de Stream Os dados de GPS são dados em movimento e perdem valor se não forem processados rapidamente Uma arquitetura de processamento de stream é essencial para a ingestão e análise desses dados em tempo real permitindo a atualização de status com baixa latência e a alimentação de painéis ao vivo funcionalidades impossíveis de serem implementadas de forma eficiente com uma abordagem de banco de dados tradicional 2 Modelo Relacional A abordagem relacional foi projetada para suportar os domínios transacionais e cadastrais do sistema LogiEntregas A adoção deste modelo fundamentase na necessidade de garantir consistência integridade e atomicidade propriedades ACID para as operações que formam o núcleo do negócio como o cadastro de clientes e o registro de pedidos A estrutura rígida e bem definida do modelo relacional previne anomalias de dados e assegura a confiabilidade das informações financeiras e contratuais 21 Diagrama EntidadeRelacionamento DER O modelo conceitual foi estruturado para representar as principais entidades do sistema e suas interconexões O diagrama subsequente ilustra a estrutura lógica do banco de dados ImagemdeumDiagramaEntidadeRelacionamentoparaosistemadelogı stica ˊ 211 Detalhamento das Entidades e Relacionamentos Entidades de Cadastro CLIENTES Armazena os dados das empresas contratantes O atributo cnpj é definido como chave única UNIQUE para evitar duplicidade de cadastros MOTORISTAS Mantém o cadastro dos motoristas da frota A cnh também é uma chave única VEICULOS Contém as informações dos veículos A placa é a chave única que identifica unicamente cada veículo Entidades Transacionais PEDIDOS Representa cada solicitação de entrega sendo uma entidade central que se conecta a um cliente ENTREGAS Entidade associativa que materializa a operação de entrega conectando um PEDIDO a um MOTORISTA e a um VEICULO A criação de um registro nesta tabela representa a alocação de recursos para a execução de um serviço Relacionamentos e Cardinalidade CLIENTES 1N PEDIDOS Um cliente pode realizar um ou muitos pedidos mas um pedido pertence a um único cliente garantindo que todo pedido seja faturável PEDIDOS 11 ENTREGAS Cada pedido resulta em exatamente uma operação de entrega O relacionamento é 1 para 1 e a chave estrangeira idpedido na tabela ENTREGAS possui uma restrição de unicidade para garantir essa regra MOTORISTASVEICULOS 1N ENTREGAS Um motorista ou um veículo pode ser alocado para várias entregas em momentos distintos mas uma entrega específica é executada por um único motorista e um único veículo 22 DDL Data Definition Language O script SQL a seguir implementa o modelo relacional descrito criando a estrutura física do banco de dados com todas as tabelas colunas tipos de dados e restrições de integridade Habilitar a verificação de chaves estrangeiras para garantir a integridade referencial PRAGMA foreignkeys ON Tabela para armazenar os dados dos clientes empresas da LogiEntregas O CNPJ é UNIQUE para evitar cadastros duplicados CREATE TABLE CLIENTES idcliente INTEGER PRIMARY KEY AUTOINCREMENT nome VARCHAR255 NOT NULL cnpj VARCHAR18 NOT NULL UNIQUE emailcontato VARCHAR255 NOT NULL Tabela para o cadastro dos motoristas da frota A CNH é UNIQUE para garantir que cada motorista seja cadastrado apenas uma vez CREATE TABLE MOTORISTAS idmotorista INTEGER PRIMARY KEY AUTOINCREMENT nomecompleto VARCHAR255 NOT NULL cnh VARCHAR11 NOT NULL UNIQUE Tabela com as informações dos veículos da frota A PLACA é UNIQUE pois é o identificador legal e único de um veículo CREATE TABLE VEICULOS idveiculo INTEGER PRIMARY KEY AUTOINCREMENT placa VARCHAR8 NOT NULL UNIQUE modelo VARCHAR100 NOT NULL capacidadecargakg DECIMAL10 2 Tabela central que armazena as solicitações de entrega pedidos Contém uma chave estrangeira FOREIGN KEY para garantir que todo pedido esteja associado a um cliente existente CREATE TABLE PEDIDOS idpedido INTEGER PRIMARY KEY AUTOINCREMENT idcliente INTEGER NOT NULL datasolicitacao TIMESTAMP DEFAULT CURRENTTIMESTAMP enderecodestino TEXT NOT NULL nomedestinatario VARCHAR255 NOT NULL statusgeral VARCHAR50 NOT NULL FOREIGN KEY idcliente REFERENCES CLIENTESidcliente Tabela que associa um pedido a uma operação de entrega motorista e veículo O idpedido é UNIQUE aqui para forçar o relacionamento 1 para 1 com a tabela PEDIDOS Múltiplas chaves estrangeiras conectam a entrega aos seus respectivos recursos CREATE TABLE ENTREGAS identrega INTEGER PRIMARY KEY AUTOINCREMENT idpedido INTEGER NOT NULL UNIQUE idmotorista INTEGER NOT NULL idveiculo INTEGER NOT NULL dataefetivaentrega TIMESTAMP FOREIGN KEY idpedido REFERENCES PEDIDOSidpedido FOREIGN KEY idmotorista REFERENCES MOTORISTASidmotorista FOREIGN KEY idveiculo REFERENCES VEICULOSidveiculo 221 Justificativa das Restrições Constraints PRIMARY KEY AUTOINCREMENT Utilizado para gerar um identificador numérico único e sequencial para cada registro simplificando as referências NOT NULL Aplicado em colunas essenciais como nome cnpj placa para garantir que nenhum registro seja inserido com informações vitais ausentes UNIQUE Impede a duplicidade de registros com base em um identificador de negócio CNPJ CNH Placa mantendo a consistência dos dados cadastrais FOREIGN KEY Constitui a base da integridade referencial do modelo Garante que um registro em uma tabela dependente ex PEDIDOS só possa existir se referenciar um registro válido em uma tabela principal ex CLIENTES prevenindo a existência de pedidos órfãos 3 Modelo NoSQL Em contraste com a adequação do modelo relacional para dados cadastrais sua aplicação mostrase ineficiente para os dados de rastreamento Para suprir tal requisito optouse por um banco de dados NoSQL especificamente um modelo orientado a documento como o MongoDB Esta escolha é motivada pela necessidade de armazenar e consultar dados semiestruturados e de grande volume com alta performance e flexibilidade 31 Justificativa da Escolha do Modelo de Documento Dentre os tipos de bancos NoSQL chavevalor colunar grafo o modelo de documento foi selecionado por ser o mais natural para representar o objeto de negócio entrega Uma entrega é uma entidade autocontida que agrega diversas informações cliente destino histórico pontos de GPS O formato JSON permite encapsular toda essa complexidade em um único documento otimizando drasticamente as operações de leitura que são o caso de uso primário para a funcionalidade de rastreamento do cliente 32 Esquema Lógico e Estratégias de Modelagem O modelo é centrado em uma única coleção entregas Cada documento nesta coleção representa uma entrega e foi modelado utilizando as seguintes estratégias Denormalização Embedding Em vez de referenciar IDs de outras tabelas informações relevantes de cliente motorista e veiculo são embutidas embedded diretamente no documento da entrega Justificativa Esta é uma troca deliberada que aumenta a redundância de dados para obter uma performance de leitura massivamente superior Para consultar o histórico de uma entrega o sistema lê um único documento evitando a necessidade de múltiplos JOINs que são operações computacionalmente caras e o principal gargalo de performance no modelo relacional para este caso de uso Arrays de Objetos para Dados de Série Temporal O histórico de status e os pontos de rastreamento são dados que crescem com o tempo Eles são modelados como arrays de objetos embutidos historicostatus e pontosrastreamento Justificativa Este padrão Bucket Pattern é extremamente eficiente para dados de série temporal Ele mantém todos os dados relacionados a uma entidade juntos e permite atualizações atômicas e eficientes como adicionar um novo ponto de GPS ao final do array Estrutura do Documento JSON id ObjectId64e8a5b2 idpedidoorigem 101 statusatual Em trânsito datasolicitacao 20250820T100000Z cliente nome Empresa Exemplo LTDA cnpj 12345678000199 destino destinatario João da Silva endereco Rua das Flores 123 São Paulo SP motorista idmotorista 1 nome Carlos Souza veiculo idveiculo 1 placa ABC1234 historicostatus status Aguardando Coleta data 20250820T110000Z status Em trânsito data 20250820T150500Z pontosrastreamento latitude 203194 longitude 403378 timestamp 20250820T150510Z latitude 203215 longitude 403401 timestamp 20250820T151015Z 33 Queries Representativas e Performance As consultas no modelo de documento são projetadas para serem simples e eficientes explorando a estrutura denormalizada para obter alta performance A primeira consulta representativa é a busca por uma entrega completa para fins de rastreamento utilizando o comando dbentregasfindOne idpedidoorigem 101 Em termos de performance esta é a operação mais otimizada possível pois utiliza um índice no campo idpedidoorigem para localizar um único documento e retornálo por inteiro A ausência de JOINs resulta em um custo operacional mínimo garantindo a baixa latência exigida pelo requisito não funcional A segunda operação fundamental é a de escrita especificamente para adicionar um novo ponto de GPS a uma entrega em andamento Isso é realizado através da query dbentregasupdateOne idpedidoorigem 101 push pontosrastreamento A análise de performance desta operação revela sua alta eficiência O operador push é otimizado para adicionar elementos a um array sem a necessidade de reescrever o documento inteiro o que torna as atualizações de telemetria extremamente rápidas e atômicas no nível do documento sendo ideal para o fluxo contínuo de dados proveniente do modelo de stream Finalmente uma consulta mais avançada demonstra a capacidade de manipulação de dados no lado do servidor como a busca pelas últimas cinco posições de uma entrega A query dbentregasfindOne idpedidoorigem 101 pontosrastreamento slice 5 exemplifica este poder Em vez de transferir milhares de pontos de GPS pela rede para serem filtrados na aplicação o operador slice permite que o próprio banco de dados selecione e retorne apenas os últimos cinco elementos do array Esta abordagem economiza significativamente a banda de rede e o processamento no lado do cliente contribuindo para uma aplicação mais responsiva 4 Modelo de Stream de Dados O atendimento ao requisito de rastreamento em tempo real com baixa latência impõe a necessidade de uma arquitetura de processamento de stream Abordagens tradicionais de processamento em lote batch que processam dados em janelas de tempo são inadequadas para este cenário pois introduziriam um atraso inaceitável na visibilidade da localização dos veículos O modelo de stream processa cada evento de dado individualmente assim que ele é gerado 41 Justificativa da Escolha Tecnológica Apache Kafka Para a implementação do broker de mensagens foi selecionado o Apache Kafka Esta tecnologia é o padrão de mercado para a construção de pipelines de dados em tempo real por diversas razões Alto Throughput Kafka é capaz de lidar com milhões de mensagens por segundo garantindo que o sistema possa escalar para uma frota de milhares de veículos Durabilidade e Tolerância a Falhas As mensagens publicadas em um tópico Kafka são persistidas em disco e replicadas entre os nós do cluster Isso garante que mesmo que a aplicação de processamento falhe os dados de localização não serão perdidos Desacoplamento Kafka atua como um buffer intermediário desacoplando completamente os produtores veículos dos consumidores aplicação de processamento Isso permite que múltiplos consumidores ex um para atualizar o banco outro para um sistema de detecção de anomalias leiam o mesmo fluxo de dados de forma independente 42 Diagrama de Arquitetura A arquitetura proposta segue o padrão ProdutorConsumidor um design clássico e robusto para sistemas de streaming Veículo Sensor Tópico Kafka Aplicação de Processamento MongoDB Produtor posicoesveiculos Consumidor Coleção Entregas 43 Detalhamento dos Componentes e Fluxo de Dados 1 Fonte de Dados Produtor Responsabilidade Simular o dispositivo GPS de um veículo Implementação Um script que gera uma mensagem JSON em um intervalo de tempo fixo O formato da mensagem é crucial idveiculo int latitude float longitude float timestamp float O idveiculo é a chave que conecta o dado de telemetria ao sistema cadastral e o timestamp é vital para garantir a ordenação correta dos eventos 2 Broker de Mensagens Apache Kafka Responsabilidade Ingerir persistir e disponibilizar o fluxo de mensagens de forma confiável e escalável Implementação As mensagens dos produtores são enviadas para um tópico chamado posicoesveiculos Este tópico funciona como um log de eventos distribuído e imutável Internamente o tópico pode ser dividido em partições para permitir o consumo paralelo e aumentar a vazão do sistema 3 Aplicação de Processamento Consumidor Responsabilidade Aplicar a lógica de negócio aos dados em tempo real Implementação Um serviço que se inscreve no tópico posicoesveiculos Para cada mensagem recebida ele executa os seguintes passos 1 Consumo e Deserialização Lê a mensagem do Kafka e a converte de JSON para um objeto em memória 2 Enriquecimento de Dados Executa uma consulta no MongoDB para encontrar o documento da entrega com status Em trânsito que corresponde ao idveiculo da mensagem 3 Lógica de Atualização Se uma entrega ativa é encontrada a aplicação executa o comando updateOne com o operador push para adicionar a nova coordenada ao array pontosrastreamento 4 Tratamento de Exceção Se nenhuma entrega ativa for encontrada a mensagem pode ser descartada ou registrada em um log para auditoria 4 Destino Banco de Dados NoSQL Responsabilidade Persistir o dado processado de forma otimizada para consulta Implementação O MongoDB Atlas com o modelo de documento da coleção entregas serve como o sink destino final do pipeline de dados 5 Justificativa e Análise Comparativa dos Modelos Concluída a implementação dos modelos esta seção apresenta a análise comparativa aprofundada avaliando cada paradigma frente aos requisitos do problema A análise evidencia a inadequação de uma abordagem monolítica de banco de dados defendendo uma solução híbrida como a mais eficaz 51 Análise Comparativa por Critério Critério Modelo Relacional Modelo NoSQL Documento Modelo de Stream Kafka Desempenho de Leitura Baixo a Médio Adequado para relatórios com JOINs em dados estruturados mas ineficiente para buscar o histórico completo de uma entrega Muito Alto A consulta de uma entrega é uma operação de busca de documento único de baixíssima latência ideal para a API de rastreamento NA Ingestão Não é um sistema de consulta mas de transporte de dados Desempenho de Médio Eficiente para Alto Otimizado para Muito Alto Projetado Escrita transações ACID mas a atualização de múltiplos índices e restrições pode gerar gargalos com milhões de inserções de telemetria escritas rápidas A operação push para adicionar um ponto de GPS a um array é atômica e performática para ingestão de altíssimo volume throughput Escalabilidade Vertical Scaleup A escalabilidade primária ocorre pelo aumento de recursos CPU RAM de um único servidor uma abordagem de alto custo e com limite físico Horizontal Scaleout Escala distribuindo a carga e os dados entre múltiplos servidores de baixo custo commodity hardware Horizontal Scaleout Altamente distribuído A capacidade é aumentada pela adição de mais nós brokers ao cluster Flexibilidade de Esquema Baixa Schemaon Write O esquema é rígido e predefinido A adição de um novo sensor exigiria uma migração ALTER TABLE processo complexo em produção Alta Schemaon Read O esquema é flexível Novos campos podem ser adicionados a novos documentos sem impactar os existentes Alta O Kafka é agnóstico ao formato dos dados transportando bytes e permitindo que o esquema das mensagens evolua sem alterar a infraestrutura Consistência Forte ACID Garante atomicidade consistência isolamento e durabilidade Essencial para os dados cadastrais e financeiros Eventual BASE Oferece garantias mais flexíveis priorizando disponibilidade e performance A consistência é garantida no nível do documento NA Garantia de Entrega Oferece diferentes garantias de entrega de mensagens mas não é um sistema de consistência de dados Custo Médio a Alto O custo da escalabilidade Baixo a Médio A escalabilidade Médio O custo de hardware pode ser vertical e de licenciamento de SGBDs comerciais pode ser elevado horizontal em hardware comum reduz o custo de armazenamento para grandes volumes de dados baixo mas a complexidade operacional pode aumentar o custo total de propriedade TCO 52 Conclusão da Análise A Superioridade da Arquitetura Híbrida A análise comparativa demonstra que não existe uma solução única Cada modelo possui características que o tornam ideal para uma parte específica do problema O Modelo Relacional é insubstituível para o sistema de registro System of Record onde a consistência e a integridade dos dados de pedidos e clientes são a maior prioridade O Modelo NoSQL é a escolha ideal para o sistema de engajamento System of Engagement onde a experiência do usuário de rastreamento exige leituras de baixa latência e o volume de dados demanda escalabilidade horizontal O Modelo de Stream funciona como o sistema nervoso central conectando o mundo físico ao digital em tempo real e sendo o único capaz de atender ao requisito de baixa latência na ingestão de dados Portanto a solução mais eficaz robusta e escalável é uma arquitetura híbrida também conhecida como Polyglot Persistence Nesta abordagem os diferentes modelos de dados coexistem e colaboram cada um resolvendo a parte do problema para a qual foi projetado 6 Código Adotado para o Desenvolvimento Nesta seção são consolidados os artefatos de código desenvolvidos com descrições para sua utilização na reprodução e validação dos modelos propostos O código é apresentado de forma organizada e documentada para facilitar o entendimento 61 Modelo Relacional DDL e População de Dados O código a seguir define a estrutura do banco de dados relacional e inclui exemplos de inserção de dados DML para criar um cenário de teste funcional Script Completo DDL DML schemarelacionalsql Habilitar a verificação de chaves estrangeiras PRAGMA foreignkeys ON Definição das Tabelas DDL CREATE TABLE IF NOT EXISTS CLIENTES idcliente INTEGER PRIMARY KEY AUTOINCREMENT nome VARCHAR255 NOT NULL cnpj VARCHAR18 NOT NULL UNIQUE emailcontato VARCHAR255 NOT NULL CREATE TABLE IF NOT EXISTS MOTORISTAS idmotorista INTEGER PRIMARY KEY AUTOINCREMENT nomecompleto VARCHAR255 NOT NULL cnh VARCHAR11 NOT NULL UNIQUE CREATE TABLE IF NOT EXISTS VEICULOS idveiculo INTEGER PRIMARY KEY AUTOINCREMENT placa VARCHAR8 NOT NULL UNIQUE modelo VARCHAR100 NOT NULL capacidadecargakg DECIMAL10 2 CREATE TABLE IF NOT EXISTS PEDIDOS idpedido INTEGER PRIMARY KEY AUTOINCREMENT idcliente INTEGER NOT NULL datasolicitacao TIMESTAMP DEFAULT CURRENTTIMESTAMP enderecodestino TEXT NOT NULL nomedestinatario VARCHAR255 NOT NULL statusgeral VARCHAR50 NOT NULL FOREIGN KEY idcliente REFERENCES CLIENTESidcliente CREATE TABLE IF NOT EXISTS ENTREGAS identrega INTEGER PRIMARY KEY AUTOINCREMENT idpedido INTEGER NOT NULL UNIQUE idmotorista INTEGER NOT NULL idveiculo INTEGER NOT NULL dataefetivaentrega TIMESTAMP FOREIGN KEY idpedido REFERENCES PEDIDOSidpedido FOREIGN KEY idmotorista REFERENCES MOTORISTASidmotorista FOREIGN KEY idveiculo REFERENCES VEICULOSidveiculo População de Dados de Exemplo DML INSERT INTO CLIENTES nome cnpj emailcontato VALUES Loja Varejista SA 11222333000144 contatovarejistacom INSERT INTO MOTORISTAS nomecompleto cnh VALUES Carlos Souza 12345678901 INSERT INTO VEICULOS placa modelo capacidadecargakg VALUES ABC1234 Fiat Fiorino 6500 INSERT INTO PEDIDOS idcliente enderecodestino nomedestinatario statusgeral VALUES 1 Rua das Flores 123 São Paulo SP João da Silva Aguardando Coleta INSERT INTO ENTREGAS idpedido idmotorista idveiculo VALUES 1 1 1 Utilização Este script pode ser executado em qualquer SGBD compatível com SQL para criar e popular as tabelas permitindo a validação dos relacionamentos 62 Modelo NoSQL Documento e Queries Os artefatos para o modelo NoSQL consistem na estrutura do documento e nas queries para sua manipulação Estrutura do Documento de Exemplo entregaexemplojson idpedidoorigem 1 statusatual Aguardando Coleta datasolicitacao 20250820T100000Z cliente nome Loja Varejista SA cnpj 11222333000144 destino destinatario João da Silva endereco Rua das Flores 123 São Paulo SP motorista idmotorista 1 nome Carlos Souza veiculo idveiculo 1 placa ABC1234 historicostatus status Aguardando Coleta data 20250820T110000Z pontosrastreamento Utilização Este documento JSON pode ser inserido em uma coleção entregas no MongoDB As queries do Capítulo 3 podem ser executadas para testar a manipulação dos dados 63 Modelo de Stream Scripts de Simulação Os scripts Python abaixo simulam o pipeline de dados em tempo real Requerem um ambiente com Kafka e as bibliotecas kafkapython e pymongo Produtor simuladorveiculopy Script que simula um dispositivo IoT enviando sua localização para o Kafka import json import time from kafka import KafkaProducer Configuração do produtor Kafka producer KafkaProducer bootstrapserverslocalhost9092 valueserializerlambda v jsondumpsvencodeutf8 VEHICLEID 1 TOPICNAME posicoesveiculos printfSimulador do veículo VEHICLEID iniciado Enviando para o tópico TOPICNAME try while True message idveiculo VEHICLEID latitude 203194 timetime 100 10000 longitude 403378 timetime 100 10000 timestamp timetime producersendTOPICNAME message printfPosição enviada message timesleep5 except KeyboardInterrupt printSimulação encerrada finally producerclose Consumidor processadorentregaspy Script que simula a aplicação de processamento consumindo dados do Kafka import json from kafka import KafkaConsumer from pymongo import MongoClient Descomentar para integração com MongoDB Configuração do consumidor Kafka consumer KafkaConsumer posicoesveiculos bootstrapserverslocalhost9092 groupidprocessadoresdeentregas autooffsetresetearliest valuedeserializerlambda m jsonloadsmdecodeutf8 printProcessador de entregas iniciado aguardando mensagens try for message in consumer locationdata messagevalue printfNova localização recebida locationdata LÓGICA DE NEGÓCIO SIMULADA 1 Buscar no MongoDB a entrega ativa para o idveiculo 2 Executar o update com push no documento encontrado except KeyboardInterrupt printProcessador encerrado finally consumerclose Utilização Com o Kafka em execução o script processadorentregaspy deve ser iniciado seguido pelo simuladorveiculopy A troca de mensagens em tempo real validará o fluxo da arquitetura 7 Conclusão Final O presente trabalho teve como propósito o aprofundamento do estudo e da aplicação de diferentes paradigmas de modelagem de dados através de um problema prático de logística A análise dos modelos Relacional NoSQL e de Stream demonstrou de forma conclusiva que problemas de negócio contemporâneos raramente são resolvidos de maneira ótima por uma única tecnologia de banco de dados 71 Síntese dos Resultados Os resultados confirmaram as hipóteses iniciais O Modelo Relacional provou ser indispensável para a governança e consistência dos dados mestres clientes pedidos onde as garantias ACID são inegociáveis O Modelo NoSQL com sua flexibilidade e otimização para leitura mostrouse fundamental para atender aos requisitos de desempenho e escalabilidade da funcionalidade de rastreamento que lida com um volume massivo de dados de telemetria A Arquitetura de Stream emergiu como o único paradigma capaz de atender ao requisito de processamento em tempo real funcionando como o sistema nervoso que conecta os eventos do mundo físico à lógica de negócio digital com baixa latência A tentativa de utilizar um único modelo para todos os fins levaria a compromissos inaceitáveis um sistema puramente relacional seria lento e caro para escalar um sistema puramente NoSQL exigiria uma complexa lógica aplicacional para garantir a consistência transacional 72 Implicações e Relevância A principal implicação deste estudo é a validação da abordagem de Persistência Poliglota Polyglot Persistence como um padrão de arquitetura essencial para o desenvolvimento de sistemas complexos A decisão sobre qual tecnologia de banco de dados utilizar não deve ser um dogma mas sim uma escolha estratégica baseada nos requisitos específicos de cada parte do sistema Este caso de uso da LogiEntregas é um microcosmo de desafios encontrados em diversas indústrias como ecommerce IoT mercado financeiro e redes sociais onde dados transacionais analíticos e em tempo real precisam coexistir 73 Trabalhos Futuros e Desdobramentos A arquitetura proposta serve como uma base sólida para diversas evoluções e aprofundamentos incluindo Processamento de Stream Avançado A aplicação consumidora poderia ser aprimorada com ferramentas como Apache Flink ou Spark Streaming para executar análises mais complexas em tempo real como detecção de desvios de rota cálculo de tempo estimado de chegada ETA dinâmico ou alertas de segurança Exploração de Outros Modelos NoSQL Para o problema de otimização de rotas um banco de dados de Grafo como o Neo4j poderia ser integrado à solução para modelar o mapa de ruas e calcular os caminhos mais eficientes de forma muito mais performática que modelos relacionais ou de documento Data Lake e Analytics Os dados brutos do tópico Kafka poderiam ser direcionados também para um Data Lake ex Amazon S3 servindo como fonte para análises de Business Intelligence BI e treinamento de modelos de Machine Learning para predição de demanda e otimização da frota Em suma este trabalho cumpriu seu objetivo ao não apenas projetar e comparar diferentes modelos de dados mas também ao demonstrar como sua integração estratégica em uma arquitetura híbrida é a chave para construir soluções digitais que são ao mesmo tempo consistentes performáticas flexíveis e prontas para o futuro