Normalização de Dados na Área de Logística: Modelagem e Implementação de um Banco de Dados Relacional
Gerar link
Facebook
X
Pinterest
E-mail
Outros aplicativos
Apresentação introdutória:
A normalização de dados, no contexto de banco de dados relacionais, é um processo fundamental para a organização eficiente das informações. Ela garante que os dados sejam armazenados de forma estruturada, eliminando redundâncias e assegurando a integridade das informações.(Mannino,2014). Esse processo contribui para a melhoria do desempenho e facilita a manipulação dos dados dentro de um sistema de gerenciamento de banco de dado (SGBD). Por meio da normalização, as tabelas são organizadas de acordo com um conjunto de regras chamadas formas normais, que ajudam a distribuir os dados em diferentes tabelas, mantendo o relacionamento entre elas e evitando problemas como anomalias de inserção, exclusão e atualização. Dessa forma, a normalização permite que os banco de dados operem de maneira eficiente, oferecendo consistências e confiabilidade nas operações realizadas. (Ramahrishnan:Gehrke,2011)
Na área de desenvolvimento de sistemas, o desempenho e a organização dos dados são essencias para garantir que as operações de um banco de dados ocorram de forma eficiente. A normalização é uma técnica que evita redundância, inconsistências e anomalias de inserção, atualização e exclusão, permitindo um melhor gerenciamento das informações. (Elmasri;Navathi,2011)
O objetivo é estruturar as tabelas de forma otimizada., evitando dados duplicados e melhorando o desempenho das consultas e integridade dos registros. A normalização deve ser aplicada sempre que um banco de dados apresentar dificuldades de atualização, informações repetidas ou problemas de consistência, assegurando um sistema mais confiável e de fácil manutenção.
A aplicação correta das normalizações traz benefícios diretos para a integridade, a organização e o desempenho dos bancos de dados. Além disso , a normalização possibilita um melhor aproveitamento de recursos computacionais, otimizando o armazenamento e reduzindo o tempo de resposta em consultas e atualizações.
Ao iniciarem suas operações, muitas empresas estruturam seus bancos de dados sem um planejamento adequado, o que pode gerar tabelas com dados repetidos e difíceis de manter. A normalização permite reorganizar essas tabelas, garantindo maior integridade e eficiência nos processos.
Atualmente, uma empresa de logística mantém todas as informações relacionadas aos pedidos de logística armazenadas em uma única tabela desnormalizada. Essa abordagem tem ocasionado erros frequentes, inconsistências nos dados, lentidão na execução de consultas e dificuldades significativas na atualização das informações. Diante desse cenário, torna-se necessária a reestruturação da base de dados por meio da aplicação das técnicas de normalização, visando à criação de um banco de dados relacional que garanta integridade, desempenho e escalabilidade.
A tabela utilizada atualmente está organizada da seguinte forma:
A equipe de TI da empresa relatou que a estrutura da tabela apresenta diversos problemas, como duplicação de dados, dificuldades na atualização de clientes e motoristas e falta de padronização na informação dos produtos e apesar das violações, a desnormalização é aceitável em planilhas operacionais, relatórios de entrega, exportações para BI e prototipação de sistemas.
Entretanto, em sistemas transacionais (OLTP) o correto seria separar as entidades e criar um banco de dados relacional bem estruturado e garantir integridade, consistência e escalabilidade.
Violações identificadas na estrutura atual dos dados:
Para estruturar as tabelas de forma otimizada, a normalização deve ser aplicada sempre que um banco de dados apresentar dificuldades de atualização, informações repetidas ou problemas de consistência,
assegurando um sistema mais confiável e de fácil manutenção. Eis as violações identificadas:
Violação da 1FN:
Uma relação está na Primeira Forma Nominal quando todos os atributos possuem valores atômicos ou indivisíveis.Cada campo deverá conter apenas um valor por registro. Na coluna endereço do cliente contém a rua e número no mesmo campo.
Em um contexto relacional, esses dados deveriam ser separados entre rua, numero e complemento.
Sendo assim, a planilha não está na 1FN, pois possui atributos compostos na mesma coluna.
Violação na 2FN:
Uma relação está na Segunda Forma Normal quando está na 1FN e todos os atributos não-chave dependem totalmente da chave primária. Não devem existir dependências parciais e sim, dependencias funcionais totais. As violações identificadas são atribtos não-chave que dependem parcialmente da chave primária. Os atributos endereco, cidade e estado dependem parcialmente da entidade cliente. Sendo dependente também do pedido e/ou produto. Os atributos categoria do produto e preço unitário dependem parcialmente dos atributos de produto na tabela. Assim a tabela viola a 2FN, pois diversos atributos dependem apenas de parte da chave e não da chave completa.
Violação da 3FN:
Uma relação está na Terceira Forma Normal quanto estiver na 2FN e não existir dependências transitivas. Além disso, os atributos não-chave não devem depender de outros atributos não-chave. Os atributos estado depende do atributo cidade que depende do atributo endereco e que dependem do atributo não-chave cliente que por sua vez depende do atributo chave 'id_cliente.'
O atributo não-chave preço_unitario depende do atributo categoria do produto que por sua vez depende do atributo não-chave 'nome' do produto. O atributo não-chave veiculo autodepende do atributo não-chave cnh_motorista que autodepende do atributo não-chave nome_motorista. A tabela viola a 3FN, pois contém múltiplas dependências transitivas entre atributos não-chave.
Proposta ao novo modelo:
O processo foi conduzido de forma incremental, partindo da compreensão do domínio do problema, passando pela identificação das entidades e relacionamentos, até a validação das formas normais. Inicialmente, foi analisada uma planilha desnormalizada utilizada para o controle de entregas na área de logística. Essa planilha concentrava, em uma única estrutura, dados de pedidos, clientes, endereços, produtos, categorias, motoristas e veículos. A análise evidenciou a presença de redundâncias, dependências parciais e dependências transitivas, caracterizando violações das três primeiras formas normais. De acordo com Date (2012), esse tipo de estrutura é comum em planilhas operacionais, porém inadequado para ambientes de banco de dados relacionais, devido ao risco de inconsistências e dificuldades de manutenção.
Na planilha original podemos identificar somente uma coluna com chave primária. Mas a partir dela podemos identificar as entidades que podem possuir tabela própria.
Endereço separado para garantir atomicidade (1FN). Remove atributos compostos e permite múltiplos endereços por cliente.
Entidade: Pedido - Representa a solicitação de compra - (id_pedido(PK),data_pedido, id_cliente(FK))
O valores são atômicos e o atributo 'data_pedido' não-chave depende totalmente do atributo chave 'id_pedido'. Evitando assim, dependência transitiva.
Entidade: Produto - Dados exclusivos do produto - 'id_produto(PK), nome, preco_unitario, id_categoria(FK).
Os atributos não-chave 'nome' e 'preco_unitario' dependem totalmente do atributo chave 'id_produto'.
Entidade: Categoria - Classificação dos produtos - (id_categoria(PK), descrição)
O atributo que era não-chave 'produto' agora é chave para evitar dependência transitiva com o atributo não-chave 'categoria'. Que passa a ser um atributo chave que autodetermina o atributo 'descrição'. Que por sua vez autodepende totalmente do atributo chave 'id_categoria'.
Entidade: Item do Pedido - Tabela Associativa entre pedido e produto (N:N)
Para normalizar o relacionamento de muitos-para-muitos entre pedido e produto. Cria-se uma tabela associativa 'item_pedido'. Assim, a entidade associativa deverá recever os atributos chaves estrangeiras de 'produto' e 'categoria'.
O atributo não-chave 'quantidade' autodependia do atributo não-chave 'produto' que por sua vez autodependia do atributo não-chave 'categoria'.
Ambos os atributos agora são chaves de suas tabelas. Eliminando grupos repetitivos e dependencias parciais. Já que o atributo não-chave 'quantidade' agora é autodependente do atributo chave id_item_pedido(FK).
Entidade: Motorista - Dados do motorista - (id_motorista(PK), nome, cnh)
O atributo não-chave 'cnh' autodepende apenas do 'id_motorista' atributo chave da tabela Motorista.
O atributo não-chave 'nome' não depende do atributo 'cnh' e sim depende total também do atributo chave 'id_motorista'
Assim, o atributo não-chave 'descrição' depende totalmente do atributo chave 'id_veiculo'. O mesmo para o atributo não-chave autodepende apenas do atributo chave 'id_veiculo'.
Entidade associativa que irá possuir somente um atributo não-chave 'data_entrega' autodependente do atributo chave da tabela 'entrega'.
Os outros atributos são chaves estrangeiras de outras tabelas. Assim, não há dependências transitivas.
Modelagem Conceitual (MER)
Na etapa de modelagem conceitual, foi elaborado o Modelo Entidade-Relacionamento (MER), cujo foco é representar os principais elementos do domínio do negócio de forma abstrata, sem preocupações com implementação física. Essa etapa concentrou-se na compreensão do negócio, sem considerar aspectos de implementação física, conforme recomendado por Silberschatz, Korth e Sudarshan (2020).
Foram identificadas as entidades Cliente, Endereço, Pedido, Produto, Categoria, Item de Pedido, Motorista, Veículo e Entrega, bem como os relacionamentos existentes entre elas, refletindo as regras do negócio no contexto logístico. Além disso, foram definidos os relacionamentos entre essas entidades, respeitando as regras do negócio, como a relação entre pedidos e produtos, e entre entregas, motoristas e veículos.
Dessa forma o modelo conceitual do banco de dados deverá seguir a seguinte forma:
CLIENTE 1:N ENDERECO ( Um cliente pode possuir vários endereços mas um endereço pertence a um único cliente )
CLIENTE 1:N PEDIDO ( Um cliente pode fazer diversos pedidos mas o pedido só pertence a um cliente)
PEDIDO 1:N ITEM_PEDIDO ( Um pedido pode conter vários itens e cada item pertence a um único pedido)
PRODUTO 1:N ITEM_PEDIDO ( Um produto pode conter vários pedidos mas cada item referencia um único produto)
CATEGORIA 1:N PRODUTO ( Uma categoria pode conter vários produtos mas o produto pertence somente a uma categoria )
PEDIDO 1:1 ENTREGA ( Um pedido pode conter uma ou várias entregas mas cada entrega pertence a um único pedido)
PEDIDO 1:N ENTREGA (Um pedido pode conter vários entregas e várias entregas podem pertencer a um único pedido )
MOTORISTA 1:N ENTREGA ( Um motorista pode realizar várias entregas e cada entre tem um motorista )
VEICULO 1:N ENTREGA ( Um veículo pode realizar várias entregas e cada entrega usa somente um véiculo)
A reestruturação do modelo de dados teve como objetivo principal corrigir as limitações da planilha desnormalizada originalmente utilizada, adequando o banco de dados às boas práticas de modelagem relacional e às exigências da Terceira Forma Normal (3FN).
As melhorias da integridade dos dados são a eliminação de redundâncias. Na planilha original, informações como cliente, endereço, produto, categoria, motorista e veículo eram repetidas em várias linhas. Com a normalização cada entidade passou a possuir uma única tabela e cada informação é armazenada uma única vez.
A nova estrutura introduz PKs e FKs para controlar os relacionamentos. Assim impede registros órfãos, garante integridade referencial e facilita validações automáticas pelo SGBD.
No modelo desnormalizado cada novo pedido duplicava dados de cliente, produto e motorista. No modelo normalizado apenas novos relacionamentos são inseridos e dados mestres permanecem inalterados. Assim temos menor consumo de armazenamento, crescimento sustentável do banco e melhor desempenho em grandes volumes de dados.
A nova estrutura permite adicionar novos atributos (ex.: status da entrega) e criar novas entidades (ex.: transportadora, rota), além de alterar ou acrescentar restrições sem impacto em dados existentes.
Exemplo é um motorista pode trocar de veículo sem alterar registros históricos de pedidos.
As consultas se tornam mais precisas e otimizadas com os dados organizados por entidade. Assim os índices podem ser criados em PKs e FKs e as consultas ficam mais rápidas e previsíveis. JOINs representam corretamente os relacionamentos reais. Ex: Buscar todas as entregas de um motorista específico torna-se simples e eficiente.
A estrutura normalizada elimina anomalias de inserção, ou seja, não é mais necessário cadastrar um pedido para inserir um cliente. A estrutura normalizada também elimina anomalias de atualização, sendo assim, pode haver alteração de endereço em apenas um local. Já nas anomalias de exclusão, a estrutura normalizada permite a exclusão de pedido e não remove o cliente.
Modelagem Lógica (DER)
A partir do MER, foi desenvolvido o Diagrama Entidade-Relacionamento (DER), detalhando atributos, chaves primárias e chaves estrangeiras. Nessa etapa, foram aplicadas as técnicas de normalização com o objetivo de adequar o modelo até a Terceira Forma Normal (3FN).
As principais decisões de modelagem incluíram:
Separação de atributos compostos, garantindo a Primeira Forma Normal (1FN)
Criação de tabelas associativas para eliminar dependências parciais, atendendo à Segunda Forma Normal (2FN)
Eliminação de dependências transitivas por meio da separação de entidades, assegurando a Terceira Forma Normal (3FN).
A metodologia aplicada resultou em um modelo de dados robusto, escalável e alinhado às boas práticas de engenharia de dados. Embora a estrutura inicial desnormalizada seja adequada para controle operacional em planilhas, a normalização mostrou-se essencial para garantir eficiência, integridade e sustentabilidade em um ambiente de banco de dados relacional.
Segue abaixo o código relativo à modelagem lógica, executável na maioria de aplicativos de modelagem de dados:
CLIENTE {
id_cliente integer pk >* ENDERECO.id
nome string
CPF char unique
}
ENDERECO {
id_endereco int pk
logradouro string
numero string
cidade string
estado string
id_cliente integer >* CLIENTE.id_cliente
}
PEDIDO {
id_pedido integer
data_pedido date
date datetime
id_cliente integer >* CLIENTE.id_cliente
}
CATEGORIA {
id_categoria integer
descricao string
}
PRODUTO {
id_produto integer pk
nome string
preco_unitario decimal
id_categoria integer >* CATEGORIA.id_categoria
}
ITEM_PEDIDO {
id_item_pedido int pk
qunatidade int
id_pedido integer >* PEDIDO.id_pedido
id_produto integer >* PRODUTO.id_produto
}
MOTORISTA {
id_motorista int pk
nome varchar
cnh varchar
}
VEICULO {
id_veiculo int pk
tipo string
placa char
}
ENTREGA {
id_entrega int pk
data_entrega date
id_pedido integer >* PEDIDO.id_pedido
id_motorista integer >* MOTORISTA.id_motorista
id_veiculo integer >* VEICULO.id_veiculo
}
Modelagem Física (com SQL Alchemy)
A modelagem física corresponde à etapa em que o modelo lógico, representado pelo DER, é convertido em estruturas implementáveis em um Sistema Gerenciador de Banco de Dados (SGBD). Nessa fase, são definidos os tipos de dados, as chaves primárias, as chaves estrangeiras e as restrições de integridade, considerando as características do SGBD adotado (ELMASRI; NAVATHE, 2019).
Para a implementação do modelo físico deste trabalho, foi utilizada a biblioteca SQLAlchemy, amplamente empregada em aplicações Python para mapeamento objeto-relacional (ORM), permitindo a representação das tabelas do banco de dados como classes Python.
O SQLAlchemy foi escolhido por facilitar a implementação do modelo relacional normalizado afim de garantir integridade referencial por meio de relacionamentos ORM e permitir independência do SGBD (SQLite, PostgreSQL, MySQL). De acordo com Silberschatz, Korth e Sudarshan (2020), ferramentas ORM contribuem para a produtividade e reduzem erros comuns na manipulação direta de SQL.
A implementação física reflete diretamente o DER normalizado até a 3FN, no qual cada entidade foi convertida em uma classe Python mapeada para uma tabela do banco de dados. A modelagem física implementada reflete integralmente o DER proposto, mantendo a correspondência direta entre entidades e tabelas, o sso adequado de chaves primárias e estrangeiras e ausência de redundâncias com eliminação de dependências parciais e transitivas. Dessa forma, o banco de dados encontra-se adequado até a Terceira Forma Normal (3FN).
Considerações:
A utilização do SQLAlchemy permitiu a implementação fiel do modelo lógico normalizado, assegurando integridade referencial, escalabilidade e facilidade de manutenção. O modelo físico resultante está preparado para ser utilizado em sistemas reais de logística e pode ser facilmente adaptado para diferentes SGBDs, reforçando sua aplicabilidade acadêmica e profissional.
Integridade Referencial e Regras de Exclusão no Modelo de Dados Fisico
A definição adequada das regras de integridade referencial é um dos aspectos mais relevantes no projeto de bancos de dados relacionais, pois garante a consistência, a confiabilidade e a preservação do histórico das informações. No presente trabalho, as decisões relacionadas ao uso das cláusulas ON DELETE e dos mecanismos de cascade do ORM SQLAlchemy foram fundamentadas na natureza das entidades envolvidas e no grau de dependência existente entre elas.
De modo geral, adotou-se como princípio que entidades dependentes, que não possuem significado sem a existência de sua entidade principal, devem ser removidas automaticamente quando o registro pai é excluído. Por outro lado, entidades de cadastro base ou histórico devem ser protegidas contra exclusões acidentais, impedindo a remoção quando existirem registros associados.
Relação Cliente e Endereço
A entidade Endereço apresenta dependência total em relação à entidade Cliente, uma vez que um endereço não possui significado isolado no contexto do sistema. Dessa forma, foi adotada a regra ON DELETE CASCADE na chave estrangeira que relaciona endereço ao cliente, garantindo que, ao excluir um cliente, todos os seus endereços sejam automaticamente removidos pelo banco de dados.
Adicionalmente, no nível do ORM, foi utilizado o parâmetro cascade="all, delete-orphan" no relacionamento entre Cliente e Endereço. Essa abordagem assegura que, caso um endereço seja removido da coleção de endereços de um cliente, o registro correspondente seja automaticamente excluído do banco, evitando a existência de registros órfãos.
Relação Cliente e Pedido
A relação entre Cliente e Pedido foi tratada de forma distinta por se tratar de dados de natureza histórica. Pedidos representam transações realizadas e, portanto, devem ser preservados mesmo que o cadastro do cliente não esteja mais ativo.
Por esse motivo, não foi aplicado ON DELETE CASCADE nessa relação. A exclusão de um cliente é bloqueada caso existam pedidos associados, mantendo a integridade do histórico de compras. Essa decisão evita a perda de informações relevantes para auditoria, relatórios e análises futuras.
Relação Pedido e Item de Pedido
A entidade ItemPedido possui dependência total em relação à entidade Pedido, pois não faz sentido existir um item de pedido sem o pedido correspondente. Assim, foi adotado ON DELETE CASCADE na chave estrangeira que referencia o pedido, garantindo que, ao excluir um pedido, todos os seus itens sejam removidos automaticamente.
No ORM, foi aplicado cascade="all, delete-orphan", assegurando que a remoção de um item da coleção de itens de um pedido resulte na exclusão do registro no banco de dados. Essa estratégia mantém a consistência dos dados tanto no nível da aplicação quanto no nível do banco.
Além disso, foi definida uma restrição de unicidade para a combinação entre pedido e produto, impedindo que o mesmo produto seja registrado mais de uma vez em um único pedido, reforçando a integridade semântica do modelo.
Relação Pedido e Entrega
A entidade Entrega também apresenta dependência direta em relação ao Pedido, visto que uma entrega está necessariamente vinculada a um pedido específico. Dessa forma, adotou-se ON DELETE CASCADE na relação entre pedido e entrega, garantindo que, ao excluir um pedido, todas as entregas associadas sejam removidas automaticamente.
No nível do ORM, o uso de cascade="all, delete-orphan" assegura que entregas removidas da coleção de um pedido sejam excluídas do banco, evitando inconsistências e registros sem referência válida.
Relação Produto e Item de Pedido
A relação entre Produto e ItemPedido foi definida com a regra ON DELETE RESTRICT, uma vez que produtos fazem parte do cadastro base do sistema e podem estar associados a pedidos já realizados. Essa abordagem impede a exclusão de produtos que possuam histórico de vendas, preservando a rastreabilidade e a integridade das informações comerciais. Assim, evita-se a remoção acidental de produtos que já tenham sido utilizados em transações anteriores.
Relação Motorista, Veículo e Entrega
As entidades Motorista e Veículo também foram tratadas como entidades de cadastro e histórico operacional. Uma entrega realizada deve permanecer registrada mesmo que um motorista ou veículo deixe de fazer parte do cadastro ativo do sistema.
Dessa forma, adotou-se ON DELETE RESTRICT nas relações entre entrega, motorista e veículo, impedindo a exclusão desses registros caso existam entregas associadas. Essa decisão preserva o histórico logístico e garante a integridade dos dados operacionais.
Considerações Finais
As decisões adotadas no modelo físico refletem boas práticas de projeto de banco de dados relacional, combinando regras de integridade referencial no nível do banco de dados com mecanismos de controle de ciclo de vida das entidades no nível do ORM. A utilização criteriosa de ON DELETE CASCADE, ON DELETE RESTRICT e cascade="all, delete-orphan" contribui para um modelo robusto, seguro e alinhado às regras de negócio, evitando inconsistências, perdas de dados e registros órfãos.
Esse conjunto de decisões assegura que o sistema mantenha coerência entre seus dados operacionais e históricos, além de facilitar a manutenção e evolução futura da base de dados.
DB Browser for SQLite
O DB Browser for SQLite é uma aplicação de código aberto que fornece uma interface gráfica (GUI) para a administração de bancos de dados SQLite. Sua principal finalidade é permitir que usuários criem, editem e consultem bancos de dados sem a necessidade de escrever código em linguagens de programação, embora também ofereça suporte completo à escrita e execução de comandos SQL.
No DB Browser for SQLite, as consultas SQL são executadas diretamente sobre o banco de dados, sem camadas intermediárias de abstração.
Isso permite:
Visualização instantânea dos resultados;
Inspeção direta da estrutura do banco (esquema, tipos de dados, chaves);
Identificação rápida de erros sintáticos ou lógicos em consultas SQL.
Além disso, a ferramenta oferece histórico de consultas e visualização tabular dos resultados, o que contribui para a produtividade e a compreensão dos dados.
Ao utilizar pandas, as consultas SQL geralmente são executadas por meio de funções como read_sql_query(), que carregam os resultados em estruturas de dados do tipo DataFrame. Embora essa abordagem seja poderosa para análise e processamento, ela adiciona uma camada de abstração entre o usuário e o banco de dados, o que pode dificultar a inspeção direta do esquema e dos dados armazenados.
O DB Browser for SQLite, por outro lado, permite interação direta com o banco, facilitando a compreensão da modelagem e do relacionamento entre tabelas. Em consultas exploratórias ou de validação, o DB Browser for SQLite tende a ser mais eficiente, pois executa as consultas diretamente no banco e exibe apenas os resultados necessários.
Assim, conclui-se que ambas as abordagens são complementares: o DB Browser for SQLite é mais indicado para inspeção, validação e construção de consultas, enquanto o pandas é mais apropriado para análises complexas e processamento avançado de dados, especialmente em projetos acadêmicos e científicos.
Dessa forma, o projeto apresentado nos mostra quanto à sua reprodução e utilização, fator essencial em contextos acadêmicos e científicos. Inicialmente, o acesso à documentação disponível no GitHub permite ao usuário compreender rapidamente a estrutura, os objetivos e os requisitos do projeto. A partir dessa documentação, o processo de clonagem do repositório é direto, sendo realizado por meio de um único comando padrão do Git, o que garante portabilidade e reprodutibilidade do ambiente.
Após o clone, a execução do projeto ocorre de forma objetiva, seguindo as instruções descritas no repositório, sem necessidade de configurações complexas. A criação do banco de dados é automatizada pelo próprio fluxo do projeto, assegurando que a estrutura de tabelas seja gerada de acordo com a modelagem definida, incluindo as camadas de dados adotadas.
Para a análise e validação dos dados, o DB Browser for SQLite pode ser facilmente obtido por meio de seu site oficial:
A instalação da ferramenta é simples e multiplataforma, permitindo ao usuário abrir diretamente o arquivo do banco de dados gerado pelo projeto. Uma vez carregado o banco, torna-se possível executar consultas SQL de forma intuitiva, especialmente aquelas relacionadas à Camada Gold, que concentra os dados já tratados, consolidados e prontos para análise.
Dessa forma, a execução de consultas na camada Gold ocorre de maneira clara e eficiente, possibilitando a verificação dos resultados finais do pipeline de dados sem a necessidade de interação direta com o código-fonte. Essa abordagem reduz a complexidade operacional, facilita a validação dos dados e reforça a transparência do processo analítico, aspectos fundamentais em trabalhos acadêmicos.
Introdução: A crescente dependência das organizações em relação à informação torna o correto armazenamento, organização e recuperação de dados um fator estratégico para o sucesso dos sistemas de informação. Nesse contexto, a modelagem de dados destaca-se como uma das etapas mais importantes no desenvolvimento de sistemas, pois permite compreender, estruturar e representar a realidade de um domínio de negócio de forma clara, consistente e alinhada aos seus requisitos. Por meio de diferentes níveis de abstração, a modelagem possibilita ocultar detalhes técnicos do usuário final, ao mesmo tempo em que garante integridade, padronização e eficiência no uso das informações.O processo de modelagem de dados é tradicionalmente dividido em modelo conceitual, lógico e físico, cada um com objetivos e níveis de detalhamento específicos. Essa divisão permite uma evolução gradual do entendimento do negócio até a implementação técnica em um Si...
Introdução: Este projeto apresenta uma aplicação prática de Engenharia de Dados em um cenário empresarial realista , utilizando Python, SQL, Git e GitHub , com base na arquitetura conceitual Medallion (Bronze, Silver e Gold) , amplamente adotada em pipelines modernos de dados. O contexto do projeto está inserido no domínio de geoprocessamento, GIS e sensoriamento remoto , áreas que lidam com grandes volumes de dados espaciais, metadados técnicos e necessidade de rastreabilidade, qualidade e governança da informação. Para isso, são utilizados dados realistas em formato CSV , representando produtos e serviços geoespaciais comuns em empresas de tecnologia, engenharia e análise territorial. A solução contempla todo o ciclo de um pipeline de dados: Ingestão de dados brutos (Bronze) Tratamento, padronização e validação (Silver) Modelagem analítica e consolidação para consumo (Gold) Todo o desenvolvimento é realizado em um ambiente ...
Um breve conceito prático sobre Engenharia de Dados Introdução A Engenharia de Dados tem se consolidado como uma das áreas centrais dentro do ecossistema de tecnologia da informação, sendo responsável por projetar, construir e manter infraestruturas que possibilitam a coleta, o armazenamento, o processamento e a disponibilização de dados de forma confiável e escalável. Em um cenário cada vez mais orientado por dados, organizações de diferentes setores dependem diretamente dessas estruturas para apoiar processos decisórios, produtos digitais e estratégias de negócio. O ecossistema de Engenharia de Dados já foi previamente apresentado, contemplando suas principais camadas e fluxos. No entanto, além da compreensão conceitual do ecossistema, é fundamental conhecer quais ferramentas são utilizadas em cada etapa desse processo e como elas se integram no dia a dia de um engenheiro de dados. Nesse contexto, este módulo tem como foco o estudo da...
Comentários
Postar um comentário