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 Sistema Gerenciador de Banco de Dados (SGBD).
Ferramentas como o Modelo Entidade-Relacionamento (MER) e o Diagrama Entidade-Relacionamento (DER) são amplamente utilizadas nesse processo, auxiliando na visualização das entidades, atributos, relacionamentos e restrições que compõem o banco de dados.Além dos aspectos técnicos, a modelagem de dados precisa estar diretamente conectada ao contexto organizacional no qual o sistema será aplicado.
No caso do setor varejista, caracterizado pela venda direta ao consumidor final e por um alto volume de transações, a estruturação adequada dos dados é essencial para garantir eficiência operacional, controle de estoque, gestão de clientes, fornecedores e apoio à tomada de decisão. Dessa forma, compreender tanto os fundamentos da modelagem de dados quanto o funcionamento do setor de varejo é indispensável para o desenvolvimento de soluções de banco de dados robustas, escaláveis e alinhadas às necessidades do negócio.
Modelagem de dados:
É o estudo das informações existentes em um contexto sob observação para a construção de um modelo inicial de representação.Dessa forma, a modelagem estrutura o conjunto de informações obtidas pelos requisitos de negócio.
Uma das principais características da modelagem de dados é fornecem níveis de abstração de dados que omitem do usuário final detalhes sobre o armazenamento de dados. A abstração das informações existentes é um processo que usamos quando selecionamos várias características e propriedades de um conjunto de objetos ou fatos e excluímos outras que não são relevantes em um determinado contexto.
Dessa forma, podemos estruturar o projetos em modelos que irão nos ajudar a montar o projeto em questão por meio de entidades ( que são objetos do mundo real ) e como eles se relacionam com outros objetos. A maioria dos projetos de banco de dados são elaborados em torno de três modelos de relacionamento de entidades: conceitual, lógica e física. Esses modelos nos auxiliam na compreensão e construção dos elementos do mundo real para o mundo virtual.
Modelo Conceitual:
Esse modelo oferece uma visão de alto nível dos dados contidos. Analistas de negócios os utilizam em projetos de design de banco de dados em larga escala, como data warehouses. Os modelos conceituais de dados geralmente apresentam entidades e relacionamentos, sem aprofundar em tabelas e nem em cardinalidades.
Durante a modelagem de dados conceitual, deve se concentrar na obsevação dos objetos relevantes que existem em uma realidade com a finalidade de construir um modelo de compreensão e conceitos existentes nessa realidade. (pequeno-mundo). O modelo conceitual em um projeto de banco de dados é representar a realidade do ambiente do problema. Abstraindo uma visão global para uma visão local com os principais elementos contituidos por objetos, dados e relacionamentos. É uma descrição de alto nível com a preocupação de captar e retratar a realidade abstraida de uma organização, processo de negócio, setor ou departamento.
Modelo Lógico:
Somente tem início após a criação do modelo conceitual. Podendo ser abordada em diferentes formatos. O modelo lógico pode ser relacional, hieráquico, em rede, orientada a objetos, a grafos e etc. Os modelos lógicos são semelhantes aos modelos conceituais, mas com um pouco mais de detalhes. Em um modelo de dados lógico, as colunas ou atributos dentro de cada entidade são definidas, assim como as entidades operacionais e transacionais. Os analistas de negócios usam modelos de dados lógicos para projetos de design de banco de dados de menor escala.
Desde de Peter Chen introduziu o primeiro modelo de Entidade-Relacionamento na década de 1970, vários tipos de diagramas surgiram para preencher uma gama cada vez maior de casos de uso. Os diagramas de Peter Chen se parecem com fluxogramas clássicos, com várias formas conectadas por linhas. A cardinalidade é mostrada com os caracteres 1,M ou N ao longo das linhas de conexão, representando o número de iterações entre as entidades.
Modelo Físico:
São os modelos concretos para projetos de design de banco de dados específicos. Eles incluem o máximo de detalhes, como cardinalidade e com chaves primárias e estrangeiras explícitas. Designers e engenheiros de banco de dados criam modelos de dados físicos a partir de modelos conceituais e lógicos fornecidos a eles pelo analistas de negócios. Esses modelos descrevem as estruturas físicas de armazenamento de dados como o tipo e tamanho. Além disso, dentro do modelo físico, declarar índices, gatilhos (triggers) e procedimentos (procedures) são fundamentais para concluir com o projeto de acordo com as necessidades do negócio.
Esses modelos são projetados de acordo com os requisitos de processamento e uso mais econômico de recursos computacionais. O modelo físico detalha os métodos de acesso ao SGBD para a criação de índices necessários para cada informação colocada nos modelos conceituais e lógico.
Construção de um projeto de Banco de dados:
O projeto inicial começa com a abstração do mundo real para o requisitos de negócios.
1. Análise de requisitos:
- Levantamento das necessidade de informação;
- Estudos de viabilidades;
- Nível de abstração alto.
2. Projeto Conceitual:
- Estruturação das necessidades abstraídas;
- Estruturação do Diagrama de Entidade-Relacionamento (DER) com especificações das entidades e relacionamentos.
3. Projeto Lógico (mapeamento):
- Padronização das entidades, atributos e relacionamentos;
- Padronização de restrições e acesso;
- Mapeamento do esquema conceitual para o esquema lógico.
4. Projeto Físico (especificações):
- Análise das opções de recursos computacionais e sistemas operacionais;
- Especificações das características físicas de um sistema de banco de dados
- Mapeamento dos acessos ao banco de dados
- Transformar o projeto lógico em um formato adequado para um SGBD específico
5. Projeto de implementação de aplicação:
- Desenvolvimento da Interface (UI): Criação das telas onde o usuário irá interagir com os dados (telas de PDV/Caixa, cadastro de produtos e painéis de estoque).
- Conectividade (Drivers/APIs): Configuração da "ponte" que permite ao software conversar com o banco de dados físico criado na Fase 4.
A fase 5 é o estágio onde o banco de dados deixa de ser uma estrutura estática e passa a interagir com o software que os funcionários do supermercado vão usar no dia a dia.
MER X DER - Qual a diferença?
A modelagem de um banco de dados é um dos primeiros e mais importantes passos no desenvolvimento de um sistema. Para garantir que as informações sejam armazenadas de forma organizada e acessível, utilizam-se as modelagens que representam as relações e entidades do negócio, sendo os dois principais o MER e o DER.
Enquanto o MER fornece uma visão conceitual das entidades e seus relacionamentos, o DER detalha essa estrutura, definindo tabelas, atributos e chaves.
Embora ambos sejam utilizados para modelar banco de dados, o MER e DER tem finalidades diferentes, o MER é um modelo conceitual, focado no planejamento da estrutura e dos relacionamentos do banco de dados sem considerar detalhes técnicos. O DER é um modelo lógico que transforma o planejamento do MER em um estrutura real e quase pronta para a implementação. Considerando os detalhes técnicos.
Setor Varejo:
O setor de varejo é o segmento da economia responsável pela venda direta de bens ou serviços ao consumidor final, em quantidades geralmente pequenas e para uso pessoal ou familiar. Ele atua como o elo final da cadeia produtiva, conectando fabricantes, distribuidores e atacadistas aos consumidores. Além disso, é responsável pela comercialização direta de produtos e serviços ao consumidor final, sendo essencial para a geração de empregos, arrecadação de impostos e dinamização da economia. Sua diversidade de segmentos e alta dependência de tecnologia tornam o varejo um dos setores mais estratégicos e desafiadores do mercado.
Diferente do atacado, que vende grandes volumes para empresas, o varejo foca na experiência do cliente, conveniência, preço, atendimento e disponibilidade imediata do produto. O varejo é bastante diversificado e pode ser dividido em vários tipos:
- Varejo alimentar: Venda de produtos essenciais e de consumo frequente. Ex: Supermercados e hipermercados (Carrefour, Assaí, Pão de Açúcar) e mercados de bairro, atacarejos (modelo híbrido entre atacado e varejo).
- Varejo de vestuário e calçados: Focado em moda, tendências e sazonalidade. Ex: Lojas de roupas (Renner, C&A, Riachuelo) e lojas de calçados e acessórios.
- Varejo farmacêutico: Comercialização de medicamentos e produtos de saúde. Ex: Farmácias e drogarias (Drogasil, Droga Raia)e produtos de higiene e beleza.
- Varejo de eletroeletrônicos e bens duráveis: Produtos de maior valor agregado. Ex: Eletrodomésticos, Informática e telefonia ( Magazine Luiza, Casas Bahia)
- Varejo digital (e-commerce): Realizado por meio de plataformas online, Marketplaces ( Amazon, Mercado Livre), Lojas virtuais próprias e modelos omnichannel (integração loja física + online)
- Varejo de serviços: Venda de serviços diretamente ao consumidor. Ex: Salões de beleza, Lavanderias, Assistência técnica
O Varejo e o seu papel estratégico no funcionamento econômico:
O setor é o que mais emprega no país e no mundo e absorve mão de obra com diferentes níveis de qualificação. Após um período de transformações digitais intensas, o setor físico e o "omnichannel" (integração físico-digital) voltaram a impulsionar o mercado de trabalho. De acordo com o Novo Caged (Ministério do Trabalho e Emprego) e dados compilados pelo IBGE, o setor de comércio manteve uma trajetória de crescimento consistente ao longo de 2025.
O Brasil encerrou o ciclo de 2025 com aproximadamente 10,5 milhões de pessoas ocupadas formalmente no comércio. O varejo sozinho responde por cerca de 72,7% (7,7 milhões de trabalhadores) de todos os empregos do setor comercial. O país gerou 1,8 milhão de novos empregos formais no total. O setor de Comércio foi o segundo maior motor dessa expansão, contribuindo com saldos mensais médios entre 25 mil e 36 mil novas vagas.
Inovação e Tecnologia:
A integração dessas tecnologias no varejo moderno transformou o setor de uma operação baseada em intuição para uma operação baseada em dados em tempo real. O ERP (Enterprise Resource Planning) é o "cérebro" da empresa. É um software que centraliza todas as informações de diferentes departamentos em um só lugar. Ele integra o faturamento (caixa/PDV), o estoque, o financeiro e a contabilidade. Quando uma venda é feita no caixa, o ERP automaticamente dá baixa no estoque, registra a entrada de dinheiro no financeiro e calcula os impostos. Isso evita erros manuais e retrabalho.
Enquanto o ERP foca nos processos internos, o CRM (Customer Relationship Management) foca no cliente. Ele armazena o histórico de compras, preferências, data de aniversário e canais de contato preferidos. Se o sistema sabe que você compra fraldas a cada 15 dias, o CRM pode disparar um cupom de desconto personalizado no seu WhatsApp no 14º dia, aumentando as chances de fidelização.
A Gestão de Estoque e Automação visa otimizar o estoque parado do varejista. Sensores, etiquetas de RFID (identificação por radiofrequência) e softwares de previsão de demanda. O sistema avisa automaticamente quando um produto está acabando e pode até gerar um pedido de compra para o fornecedor sozinho. Isso evita a ruptura (falta de produto na prateleira) e o excesso (produto vencendo ou ocupando espaço desnecessário).
O BI (Business Intelligence) transforma os dados brutos gerados pelo ERP e CRM em gráficos e indicadores (Dashboards) para tomada de decisão. O gestor olha para um painel e decide, com base em números, se deve abrir uma nova loja em determinada região ou se precisa mudar a estratégia de preços de uma categoria específica.
A IA é a camada mais avançada, que permite ao sistema "aprender" e agir de forma preditiva. A IA analisa os preços dos concorrentes em tempo real e ajusta o preço do site automaticamente para garantir competitividade. Os Chatbots de atendimento, gerados por IA, resolvem problemas de status de pedido sem intervenção humana. Além disso, a IA consegue prever que, devido a um evento específico ou previsão do tempo, a demanda por determinado item subirá 20% na próxima semana, permitindo que a logística se antecipe.
No contexto de modelagem de dados e bancos de dados, tema que venho trabalhando bastante, o varejo depende fortemente de sistemas para controle de estoque, gestão de pedidos e vendas, cadastro de clientes/fornecedores e análise de comportamento de compra dos clientes.
No setor de varejo, um DER bem estruturado pode otimizar o controle de estoque, o gerenciamento de pedidos, a relação com fornecedores e o registro das compras dos clientes, reduzindo falhas operacionais e melhorando a eficiência dos processos comerciais. Por isso, um bom modelo conceitual, lógico e físico é fundamental para reduzir erros operacionais, melhorar decisões estratégicas e aumentar a competitividade.
Projeto SmartRetail: Modernização Sistêmica para a Eficiência Operacional.
A rede de supermercados opera atualmente com um sistema de gestão (ERP) legado, que não se comunica com as novas demandas do mercado. As informações estão retidas em 'silos de dados', resultando em uma visão parcial da operação. O sistema atual possui uma interface de baixa produtividade, falta de suporte para integração de APIs e processamento de dados em lote (não em tempo real), o que gera latência na tomada de decisão e inconsistências graves entre o estoque físico e o digital.
A rede de supermercados tem as seguintes regras de negócio:
- Cada produto deve estar obrigatoriamente vinculado a um fornecedor;
- Um cliente pode realizar múltiplos podidos ao longo do tempo;
- Cada pedido pode conter vários produtos, e um mesmo produto pode ser comprado em diferentes pedidos;
- Cada fornecedor pode fornecer múltiplos produtos, mas um produto só pode ter um fornecedor.
Com base no problema e nas regras de negócio, as entidades principais são:
1.Produto - Onde a regra "um fornecedor por produto" é aplicada.
2.Fornecedor - A âncora do seu supply chain.
3.Cliente - Sua base de CRM.
4.Pedido - Onde será a tabela de registro de cada venda.
5.Item_Pedido - A Tabela da Salvação
A entidade Item_Pedido é fundamental para representar corretamente a relação entre pedidos e produtos.
MER - Modelo Entidade-Relacionamento padrão:
Fornecedor (CNPJ, nome_fantasia, contato, email)
Produto (nome, preço, quantidade_estoque)
Cliente (CPF, nome, email, telefone)
Pedido (data_pedido, valor_total)
Item_Pedido (quantidade, preço_venda_momento)
Relacionamentos:
Fornecedor fornece Produto (1:N)
Cliente realiza Pedido (1:N)
Pedido possui Item_Pedido (1:N)
Produto compõe Item_Pedido (1:N)
Após definição abstrata do modelo conceitual podemos definir certos vínculos:
Fornecedor <-> Produto
Tipo: 1:N (um-para-muitos)
Descrição:
Um fornecedor pode fornecer vários produtos.
Um produto obrigatoriamente pertence a um único fornecedor.
Cliente <-> Pedido
Tipo: 1:N (um-para-muitos)
Descrição:
Um cliente pode realizar vários pedidos.
Cada pedido pertence a apenas um cliente.
Pedido <-> Produto:
Tipo: N:N (muitos-para-muitos)
Descrição:
Um pedido pode conter vários produtos.
Um produto pode aparecer em vários pedidos.
Implementação: A relação 'pedido/produto' (N:N) exige uma tabela associativa (geralmente chamada de ITENS_PEDIDO), que quebrará essa relação para dois relacionamentos de 1:N.
A entidade Item_Pedido é necessária entre Pedido e Produto. Permite armazenar atributos da transação como quantidade e preço do produto no momento da compra. Sem ela, o modelo ficaria inconsistente e perderia informações importantes.
Sendo assim:
Pedido <-> Item_pedido
Tipo: 1:N
Descrição: Um pedido possui vários itens.
Produto <-> item_pedido
Tipo: 1:N
Descrição: Um produto pode aparecer em vários itens de pedido.
A partir da modelagem conceitual, definimos os seguintes atributos e os tipos de dados na modelagem de dados lógica. No DER ocorre as validações de: Tabelas, Colunas, Tipos de dados, PK/FK e Restrições.
Entidade: Fornecedor
Atributo: id_fornecedor Tipo de dados: Números inteiros [PK,NOT NULL,UNIQUE]
Atributo: nome_fantasia Tipo de dados: Texto variado
Atributo: cnpj Tipo de dados: Texto variado * [UNIQUE]
Atributo: telefone Tipo de dados: Texto variado *
Atributo: email Tipo de dados: Texto variado *
* Os dados que possuem números inteiros, não devem ser declarados como número. São dados que não são usados para cálculos e sim como uma identificação. Assim, por boa prática é recomendado usar caracteres com limite. No modelo lógico não há preocupação com o tipo de dados específico.
Entidade: Produto
Atributo: id_produtos Tipo de dados: Números inteiros (PK,NOT NULL,UNIQUE)
Atributo: nome Tipo de dados: Texto
Atributo: categoria Tipo de dados: Texto
Atributo: preço Tipo de dados: Números decimais
Atributo: quantidade_estoque Tipo de dados: Números inteiros
Atributo: id_fornecedor Tipo de dados: Números inteiros (FK,NOT NULL,UNIQUE)
Entidade: Clientes
Atributo: id_clientes Tipo de dados: Números inteiros (PK,NOT NULL,UNIQUE)
Atributo: nome Tipo de dados: Texto
Atributo: cpf Tipo de dados: Texto variado * [UNIQUE]
Atributo: telefone Tipo de dados: Texto variado *
Atributo: email Tipo de dados: Texto variado *
* Os dados que possuem números inteiros, não devem ser declarados como número. São dados que não são usados para cálculos e sim como uma identificação. Assim, por boa prática é recomendado usar caracteres com limite. No modelo lógico não há preocupação com o tipo de dados específico.
Entidade: Pedidos
Atributo: id_pedido Tipo de dados: Números inteiros (PK,NOT NULL,UNIQUE)
Atributo: data_pedido Tipo de dados: Data
Atributo: valor_total Tipo de dados: Números decimais
Atributo: id_cliente Tipo de dados: Números inteiros (PK,NOT NULL,UNIQUE)
Entidade: Item_pedido (entidade associativa)
Atributo: quantidade Tipo de dados: Números inteiros
Atributo: preco_unitario Tipo de dados: Números decimais
Atributo: id_pedido Tipo de dados: Números inteiros (FK,NOT NULL,UNIQUE)
Atributo: id_produto Tipo de dados: Números inteiros (FK,NOT NULL,UNIQUE)
Os esquemas reduzem o fim da duplicidade ao vincular o produto diretamente ao fornecedor. Elimina-se o erro de ter o mesmo produto cadastrado duas vezes para fornecedores diferentes. Além disso, se um lote de um produto apresentar problema, você consegue rastrear no banco de dados: Produto -> Fornecedor e, simultaneamente, ver quais Clientes compraram esse item através da tabela ITENS_PEDIDO. A tabela ITENS_PEDIDO armazena o preço que o produto foi vendido naquele dia. Mesmo que o preço mude na tabela PRODUTO amanhã, o registro do passado permanece íntegro.
Modelagem no DBDesigner.net
O uso do DBDesigner.net (ou ferramentas de modelagem visual) é o que separa um sistema amador de um sistema profissional e escalável. Para uma rede de supermercados que está saindo de um processo "ultrapassado", ele funciona como a planta baixa de um edifício antes da construção começar. Em sistemas antigos ou manuais, as regras de negócio ficam "escondidas" na cabeça dos funcionários ou em planilhas soltas. No DBDesigner.net conseguimos visualizar graficamente a sua regra de que "Um produto só pode ter um fornecedor". O maior problema de sistemas obsoletos é a inconsistência (ex: um pedido registrado para um cliente que não existe). Com o DBDesigner.net, você está projetando uma arquitetura. Ele transforma um problema de "informação manual e inconsistente" em uma estrutura de dados organizada, rastreável e pronta para automação.
Se a rede de supermercados precisar de uma manutenção daqui a 2 anos, o diagrama explica visualmente como os dados se conversam. Sendo assim, a documentação tem uma duração longa pra utilização. Somente em casos de uma nova estruturação para refazê-la. A maioria dessas ferramentas, como DB Designer, permite exportar o código SQL pronto. Além disso, ao visualizar o diagrama, fica claro se você esqueceu de vincular um produto a um fornecedor (conforme sua regra de negócio).
DER
Como mencionado anteriormente, o Diagrama de Entidade-Relacionamento (DER) tem o propósito de validar as tabelas, colunas, tipos de dados, PK/FK e Restrições (NOT NULL, UNIQUE) de uma maneira simplificada. Segue abaixo, um modelo DER utilizado no mercado atual em formato 'dbml'.
dbml simplicada:
fornecedores {
id_fornecedores integer pk >* produtos.id_fornecedores
_cnpj char(14)
_contato varchar
_nome_fantasia varchar
_email varchar'
}
produtos {
id_produtos integer pk >* itens_pedido.id_produtos
_nome varchar
_preco decimal(10,2)
id_fornecedores integer *> fornecedores.id_fornecedores
_quantidade_estoque integer
}
clientes {
id_clientes integer pk
_cpf char(11)
_nome varchar
_email varchar
_telefone varchar
}
pedidos {
id_pedidos integer pk >* itens_pedido.id_pedidos
data_pedido timestamp
id_clientes integer > clientes.id_clientes
valor_total decimal(10,2)
}
itens_pedido {
quantidade integer
id_pedidos integer > pedidos.id_pedidos
id_produtos integer > produtos.id_produtos
preco_venda decimal(10,2)
}
Observações importantes:
1. 'itens_pedido' geralmente usam chave primária composta:
PK (id_pedidos, id_produtos)
2. Emails, nomes e telefone o uso do VARCHAR está correto, é recomendado definir tamanho máximo para evitar desperdício.
3. CPF e CNPJ → não usar apenas varchar genérico como são identificadores, devem ser texto de tamanho fixo e preferencialmente sem máscara.
Correto: CPF → CHAR(11) // CNPJ → CHAR(14)
4. Preço e valores → não usar float. O FLOAT pode gerar erros de arredondamento, o que é crítico em valores financeiros. O uso correto e recomendado é DECIMAL(10,2).
Integração com a linguagem de programação Python usando o framework SQL Alchemy para persistência do banco de dados.
O objetivo da integração é a implementação do modelo lógico em um formato adequado para um SGBD. Essa implementação dá-se por meio de classes Pyhton (ORM) e mapeamento objeto-relacional (ORM). Essa abordagem viabiliza a tradução das entidades e relacionamentos definidos no DER em classes Python e tabelas relacionais, garantindo integridade, manutenção e escalabilidade do banco de dados.
A implementação e documentação do projeto se encontra no link abaixo:
Referências:
ELMASRI, R.; NAVATHE, S. B. Sistemas de Banco de Dados. 4a. ed., São Paulo:Pearson, 2005.
HEUSER, C. A. Projeto de Banco de Dados. 5a. Edição. Porto Alegre: Sagra Luzzatto,2004.
MACHADO, Felipe Nery Rodrigues. Projeto e implementação de banco de dados. 3.ed. São Paulo: Érica, 2014
IBM. O que é um diagrama de entidade-relacionamento? IBM Think. Disponível em: https://www.ibm.com/br-pt/think/topics/entity-relationship-diagram. Acesso em: 1 jan. 2026.
BRASIL. Ministério do Trabalho e Emprego. Novo Caged: Relatórios de movimentação de empregados de Outubro e Novembro de 2025. Brasília: MTE, 2025. Disponível em: [Portal gov.br]. Acesso em: 1 jan. 2026.
CONFEDERAÇÃO NACIONAL DO COMÉRCIO DE BENS, SERVIÇOS E TURISMO (CNC). Análise e Projeções para o Setor de Comércio 2025-2026. Rio de Janeiro: CNC, 2025.
FEDERAÇÃO DO COMÉRCIO DE BENS, SERVIÇOS E TURISMO (FECOMERCIO). Pesquisa de Empregabilidade no Setor Varejista. São Paulo: FecomercioSP, 2025.
INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA (IBGE). Pesquisa Anual de Comércio (PAC) e Pesquisa Nacional por Amostra de Domicílios Contínua (PNAD Contínua). Rio de Janeiro: IBGE, 2025.
DBDESIGNER.NET. Online Database Design Tool. [S. l.], 2026. Disponível em: https://www.dbdesigner.net. Acesso em: 1 jan. 2026.
HEUSER, Carlos Alberto. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 7. ed. São Paulo: Pearson Education, 2018.
Comentários
Postar um comentário