Modelos de dados DBMS explicados: Tipos, níveis e exemplos do PostgreSQL

Para gerenciar um banco de dados de forma eficaz e adequada, é preciso entender os fundamentos dos modelos de dados.

Em sistemas de gerenciamento de banco de dados (DBMS), os modelos de dados funcionam como projetos arquitetônicos que definem como as informações são armazenadas, relacionadas e acessadas.

Eles são a camada de tradução entre os requisitos comerciais (“Precisamos acompanhar clientes, pedidos e produtos”) e a implementação técnica (“Vamos armazenar isso em quatro tabelas conectadas por chaves estrangeiras”).

Um modelo de dados bem projetado ajuda a:

• Define o escopo do sistema
• Especifica as regras que mantêm os dados válidos.
• Garante escalabilidade a longo prazo
• Melhora o desempenho

Neste guia, vamos explorar modelos de dados clássicos e modernos, níveis de abstração, processos de design e estratégias avançadas de otimização — tudo ilustrado com um conjunto de dados de comércio eletrônico do PostgreSQL.

Por que os modelos de dados são importantes

Aqui estão algumas razões rápidas pelas quais você deve saber sobre modelos de dados e por que eles são importantes.

• Ponte entre as equipes: Analistas de negócios e desenvolvedores trabalham a partir da mesma estrutura lógica.
• Integridade dos dados: As restrições evitam dados inválidos, incompletos ou duplicados.
• : Bancos de dados bem modelados ajudam a fazer buscas e junções rápidas.
• Escalabilidade: Antecipa o crescimento futuro e novas necessidades.
• Consistência: Garantir que os dados tenham o mesmo significado em diferentes partes do sistema.

O que é um modelo de dados em DBMS?

Um modelo de dados em um Sistema de Gerenciamento de Banco de Dados (DBMS) é um plano usado por bancos de dados para definir como os dados são organizados, armazenados e acessados.

O modelo de dados oferece uma maneira estruturada de representar elementos de dados e suas relações, permitindo um gerenciamento e manipulação eficientes dos dados.

Ter um modelo de dados ajuda a responder perguntas como:

• Que tipo de dados a gente tem?
• “Como um tipo de dado se relaciona com outro?”
• “Que regras esses dados precisam seguir?”

Um modelo de dados torna todas as informações necessárias e as respostas a essas perguntas facilmente compreensíveis pelos administradores de bancos de dados.

Objetivos de um modelo de dados

Um modelo de dados estrutura e organiza as informações em um banco de dados. Isso garante clareza e consistência na forma como os dados são tratados dentro de um sistema.

Aqui estão algumas razões comuns pelas quais um modelo de dados é necessário:

• Estrutura: Organiza as informações de forma lógica.
• Relacionamentos: Mapeia como os elementos de dados interagem.
• Restrições: Mantém a integridade dos dados e aplica a lógica de negócios.
• Resumo: Protege os usuários, que não precisam se preocupar com a forma como os dados são fisicamente armazenados.

Por que isso é importante

Sem um modelo de dados definido, você corre o risco de ter:

• Dados duplicados sendo guardados em formatos diferentes.
• Registros órfãos que não têm nenhuma entidade pai válida.
• Interpretações diferentes dos mesmos dados.
• Desempenho ruim da consulta por causa de uma estrutura que não está otimizada.

Aqui está uma consulta SQL simples mostrando como um banco de dados pode ser modificado para incluir estrutura, relações e restrições.

ALTER TABLE Orders
ADD CONSTRAINT fk_customer
FOREIGN KEY (CustomerID)
REFERENCES Customer(CustomerID);

Isso garante que cada pedido esteja vinculado a um cliente existente, o que é uma maneira simples, mas eficaz, de manter a integridade.

Configuração do conjunto de dados de amostra usando PostgreSQL

Antes de continuarmos com mais explicações, vamos criar e usar um conjunto de dados simples de comércio eletrônico para mostrar os conceitos ao longo deste guia.

Vamos incluir as seguintes entidades no conjunto de dados.

1. Cliente: Armazena informações do comprador.
2. Produto: Armazena itens disponíveis para venda.
3. Pedidos: Registra cada transação de compra.
4. OrderItems: Armazena detalhes sobre quais produtos estão em cada pedido.

Aqui está um diagrama ER ASCII simples mostrando as relações entre as tabelas que vamos criar.

Customer ───< Orders ───< OrderItems >─── Product

Isso faz sentido assim:

• Um cliente → várias encomendas.
• Um pedido → vários itens do pedido.
• Um produto → pode aparecer em vários pedidos.

Criando o esquema da tabela

Depois, vou criar as tabelas e colocá-las no PostgreSQL para rodar as consultas.

Aqui está o esquema e o código SQL para criar as tabelas necessárias.

CREATE TABLE Customer (
    CustomerID SERIAL PRIMARY KEY,
    CustomerName VARCHAR(100) NOT NULL,
    Email VARCHAR(100) UNIQUE NOT NULL,
    Phone VARCHAR(20),
    CreatedAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE Product (
    ProductID SERIAL PRIMARY KEY,
    ProductName VARCHAR(100) NOT NULL,
    Category VARCHAR(50),
    Price NUMERIC(10, 2) NOT NULL
);

CREATE TABLE Orders (
    OrderID SERIAL PRIMARY KEY,
    CustomerID INT NOT NULL,
    OrderDate DATE NOT NULL,
    Status VARCHAR(20) DEFAULT 'Pending',
    FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);

CREATE TABLE OrderItems (
    OrderItemID SERIAL PRIMARY KEY,
    OrderID INT NOT NULL,
    ProductID INT NOT NULL,
    Quantity INT NOT NULL CHECK (Quantity > 0),
    FOREIGN KEY (OrderID) REFERENCES Orders(OrderID),
    FOREIGN KEY (ProductID) REFERENCES Product(ProductID)
);

Inserindo dados de amostra

Agora, vamos colocar algumas informações básicas no 

INSERT INTO Customer (CustomerName, Email, Phone)
VALUES
('Alice Brown’, 'alice@example.com', '91234567'),
('Bob McKee', 'bob@example.com', '98765432');

INSERT INTO Product (ProductName, Category, Price)
VALUES
('Laptop', 'Electronics', 1200.00),
('Wireless Mouse', 'Electronics', 25.50),
('Office Chair', 'Furniture', 150.00);

INSERT INTO Orders (CustomerID, OrderDate, Status)
VALUES
(1, '2025-08-01', 'Shipped'),
(2, '2025-08-02', 'Pending');

INSERT INTO OrderItems (OrderID, ProductID, Quantity)
VALUES
(1, 1, 1),
(1, 2, 2),
(2, 3, 1);

Seu diagrama ER para o banco de dados deve ficar assim:

Principais componentes de um modelo de dados DBMS

Um modelo de dados robusto tem quatro partes principais:

1. Entidades

Na modelagem de dados, as entidades são tipo os objetos ou conceitos principais e distintos dentro de um sistema sobre os quais a gente quer guardar dados. As entidades são frequentemente representadas como tabelas em um banco de dados. 

Exemplos de entidades em nosso conjunto de dados:

• Customer
• Product
• Orders
• OrderItems

Essas entidades se tornam os principais “substantivos” do banco de dados.

As entidades são a base. Todos os outros aspectos do modelo, como atributos, relações e restrições, se baseiam neles.

2. Atributos

Na modelagem de dados, atributos são características ou propriedades que descrevem uma entidade. Eles são os pontos de dados específicos que definem uma entidade, tipo o nome, e-mail ou endereço de um cliente.

Exemplos:

• Para Customer: CustomerName, Email, Phone.
• Para Product: ProductName, Price, Category.

Simplificando, atributos são os detalhes que você considera importantes para cada entidade. Normalmente são colunas em uma tabela.

3. Relacionamentos

As relações em um modelo de dados mostram como diferentes entidades ou tabelas estão conectadas, representando as associações entre elas. Pense nelas como conexões lógicas entre entidades.

Exemplos em nosso conjunto de dados:

• Um Customer pode ter muitos Orders (1 para muitos).
• Um Order pode ter vários Products através de OrderItems (muitos para muitos resolvidos por meio de uma tabela de junção).

As relações garantem que o modelo de dados represente com precisão as associações do mundo real.

4. Restrições

Na modelagem de dados, as restrições são regras que limitam os valores permitidos em um banco de dados, garantindo a precisão, consistência e integridade dos dados.

As restrições ajudam a manter a integridade do banco de dados, impedindo que dados inválidos ou inconsistentes sejam inseridos.

Exemplos:

• UNIQUE restrição em Customer.Email.
• CHECK restrição para garantir Quantity > 0 em OrderItems.

Exemplo do PostgreSQL

Aqui está um exemplo de como usar alguns tipos de restrições em uma consulta SQL.

CREATE TABLE OrderItems_Constraint (
    OrderItemID SERIAL PRIMARY KEY,
    OrderID INT NOT NULL,
    ProductID INT NOT NULL,
    Quantity INT NOT NULL CHECK (Quantity > 0),
    FOREIGN KEY (OrderID) REFERENCES Orders(OrderID),
    FOREIGN KEY (ProductID) REFERENCES Product(ProductID)
);

Neste exemplo, usamos as restrições PRIMARY, CHECK, NOT NULL e REFERENCES.

Tipos de modelos de dados em DBMS

Existem diferentes tipos de modelos de dados em bancos de dados. Isso mostra como os dados são guardados de acordo com o tipo de informação.

Modelos clássicos

Primeiro, vamos dar uma olhada em alguns modelos clássicos comuns usados em sistemas de gerenciamento de banco de dados.

Modelo hierárquico

Um modelo de dados hierárquico organiza os dados numa estrutura tipo árvore, onde cada registro (nó) tem um único pai (exceto a raiz) e pode ter vários filhos.

• Estrutura: Dados guardados em formato de árvore; cada pai pode ter vários filhos, mas cada filho tem apenas um pai.
• Casos de uso: Sistemas bancários e de reservas aéreas tradicionais.
• Prós: Muito rápido para pesquisas um-para-muitos.
• Contras: É complicado lidar com relações muitos-para-muitos.

Exemplo (representação tipo XML):

<Customer id="1">
    <Name>Alice Brown</Name>
    <Orders>
        <Order id="1" date="2025-08-01"/>
    </Orders>
</Customer>

Os equivalentes modernos geralmente aparecem no armazenamento XML/JSON, mas o modelo em si vem desde os primeiros DBMS de mainframe, como o IMS.

Modelo de Rede

Um modelo de dados em rede é uma maneira flexível de representar dados e relações, especialmente útil para conexões complexas e muitos-para-muitos. 

Ele usa uma estrutura gráfica com nós (que representam entidades) e arestas (que representam relações) para organizar os dados, permitindo caminhos de acesso mais eficientes e diretos em comparação com os modelos hierárquicos.

• Estrutura: Gráfico com registros conectados por meio de ponteiros.
• Prós: Lida com relações complexas de muitos para muitos.
• Contras: É complicado de consultar e manter.

Modelo Relacional

O modelo de dados relacional é uma maneira de organizar os dados em tabelas com linhas e colunas, permitindo armazenar, recuperar e gerenciar informações de forma eficiente.

• Estrutura: Dados em tabelas, linhas e colunas.
• Prós: Suporte a SQL, conformidade com ACID, normalização.
• Contras: As junções podem ser caras em grande escala.

Exemplo de consulta do nosso conjunto de dados:

SELECT c.CustomerName, o.OrderID, o.OrderDate
FROM Customer c
JOIN Orders o ON c.CustomerID = o.CustomerID;

Essa consulta mostra como usar a função ` JOIN ` para criar relações entre a tabela ` Customer ` e a tabela ` Orders `.

Isso gera a seguinte tabela como resultado:

Modelos modernos

Com o avanço da tecnologia de bancos de dados, alguns modelos modernos também surgiram. Aqui estão alguns exemplos:

Modelo orientado a objetos

O modelo orientado a objetos junta conceitos de banco de dados e programação orientada a objetos. Ele suporta herança e encapsulamento.

Modelo objeto-relacional

O modelo objeto-relacional é uma mistura do relacional e do orientado a objetos.

Modelos nosql

Os modelos de dados nosql são bem diferentes das estruturas rígidas baseadas em tabelas dos bancos de dados relacionais tradicionais, oferecendo esquemas flexíveis e vários métodos de organização de dados para lidar com grandes volumes de dados não estruturados e semiestruturados.

Aqui estão alguns exemplos de modelos nosql:

• Key-Value: Redis (pesquisas rápidas).
• Documento: MongoDB (flexible JSON).
• : Família de colunas: Cassandra (armazenamento em colunas largas).
• Gráfico: Neo4j (dados com muitas relações).

Aqui está um exemplo de um modelo de dados de documento (documento MongoDB):

{
    "CustomerName": "Alice Brown",
    "Orders": [
        {"ProductName": "Laptop", "Quantity": 1}
    ]
}

Níveis de abstração da modelagem de dados

O processo de modelagem de dados rola em três níveis diferentes: conceitual, lógico e físico.

Esses níveis são os diferentes estágios de detalhe usados ao projetar um banco de dados ou sistema de informação. Eles ajudam a lidar com a complexidade, focando em partes específicas dos dados e na sua estrutura.

Conceitual

O modelo conceitual de dados é a abstração de nível mais alto e independente de tecnologia no processo de modelagem de dados. Ele foca em definir as principais entidades e suas relações em um sistema, sem entrar em detalhes técnicos.

Essa camada mostra os requisitos e as relações do negócio.

Exemplo: Nosso diagrama ER mostrando Customer → Orders.

Lógico

O modelo de dados lógico é o segundo nível de abstração. Ele descreve entidades, atributos e relações sem mencionar nenhum banco de dados específico.

Essa camada transforma o modelo conceitual em um esquema específico do DBMS. Define tabelas, chaves e relações sem detalhes de armazenamento.

Físico

A camada do modelo de dados físicos implementa um esquema com índices, partições e parâmetros de armazenamento.

Aqui está um exemplo de um índice:

CREATE INDEX idx_order_customer ON Orders(CustomerID);

Agora vamos ver esse índice usando essa consulta:

SELECT indexname, indexdef
FROM pg_indexes
WHERE tablename = 'orders';

Como você pode ver no índice abaixo, criamos um novo índice chamado idx_order_customer.

Processo de modelagem de dados

A modelagem de dados é uma maneira organizada de transformar as necessidades do negócio em um plano técnico que decide como os dados vão ser armazenados, relacionados e recuperados. 

Quando bem feita, a modelagem de dados reduz a redundância, melhora a qualidade dos dados e facilita a manutenção futura.

Fonte: Folha de referência sobre dimensões da qualidade dos dados

O processo geralmente acontece em etapas. Vamos analisar isso.

1. Coleta de requisitos

A coleta de requisitos é a base de todo o processo de modelagem de dados. Nesta fase, você está tentando entender quais são as necessidades do negócio e por quê.

Tem várias maneiras de juntar os requisitos de forma eficaz. 

• Entrevistas com as partes interessadas te permitem conversar diretamente com as pessoas que vão usar ou depender do banco de dados, como analistas de negócios, gerentes ou desenvolvedores.
• A análise de documentos ajudam você a entender os sistemas existentes, analisando relatórios anteriores, fluxos de trabalho ou esquemas de bancos de dados legados.
• Os workshops podem reunir diferentes departamentos para alinhar definições de dados e identificar lacunas.

O resultado dessa fase deve ser um conjunto claro de requisitos documentados que descrevam as entidades de dados, as relações e as regras de negócios. 

Por exemplo, no nosso conjunto de dados de varejo de amostra, as partes interessadas podem dizer que querem acompanhar os pedidos dos clientes, os produtos e as datas dos pedidos para poderem calcular métricas como o total de vendas por categoria de produto e as taxas de clientes recorrentes.

2. Projeto conceitual

O design conceitual pega esses requisitos de negócios e transforma-os em uma representação visual de alto nível dos dados. 

Nesta fase, você se concentra nas entidades existentes e em como elas se relacionam, sem se preocupar com detalhes técnicos, como tipos de chaves primárias ou estratégias de indexação.

É aí que entram os diagramas Entidade-Relacionamento (ER). Os diagramas ER mostram entidades (por exemplo, Cliente, Produto, Pedido), seus atributos e as relações entre elas. 

Para o nosso conjunto de dados:

• Customer pode incluir ID do cliente, nome, e-mail.
• Product pode incluir ID do produto, nome, categoria.
• Order pode incluir OrderID, OrderDate.
• OrderItem pode incluir OrderItemID, OrderID, ProductID, Quantidade, Preço.

As relações podem ser:

• Um cliente pode fazer vários pedidos.
• Um pedido pode ter vários itens.
• Um produto pode aparecer em vários itens de pedido.

Esse diagrama vira uma referência comum tanto para as equipes comerciais quanto para as técnicas.

3. Projeto lógico

O design lógico se baseia no modelo conceitual, aplicando regras de banco de dados, principalmente a normalização. 

Normalização é o processo de organizar um banco de dados relacional para minimizar redundância e dependência. Isso geralmente é feito em etapas (1NF, 2NF, 3NF), cada uma com requisitos específicos.

• Em 1NF, você garante que todos os campos sejam atômicos (sem valores múltiplos em uma coluna) e que não haja grupos repetidos.
• 2NF tira dependências parciais — ou seja, se você tem uma chave composta, todos os atributos que não são chave precisam depender da chave inteira.
• 3NF tira as dependências transitivas, garantindo que os atributos que não são chaves só dependam da chave primária e não de outros atributos que não são chaves.

No nosso exemplo, o endereço de e-mail do cliente só aparece na tabela Customer, sem estar duplicado na tabela Order. Da mesma forma, as informações sobre categorias de produtos devem ficar na tabela Product, e não espalhadas por vários registros em OrderItem.

4. Design físico

O design físico pega o modelo lógico e adapta-o para um sistema de banco de dados específico, como PostgreSQL ou MySQL. Essa etapa envolve decisões sobre tipos de dados, otimização de armazenamento e ajuste de desempenho.

Os índices são uma consideração importante aqui. Por exemplo, adicionar um índice a OrderDate na tabela Order pode acelerar bastante as consultas que filtram por data.

A partição também pode ser usada em conjuntos de dados grandes, dividindo os dados em partes fáceis de gerenciar por data, intervalo ou chaves hash para melhorar o desempenho das consultas. 

Você também decide sobre restrições, como chaves estrangeiras, para garantir a integridade dos dados no nível do banco de dados.

5. Validação

Depois que o design estiver pronto, é preciso fazer as validações antes de colocar no ar. 

Isso envolve carregar dados de amostra, de preferência dados de teste realistas que reflitam os volumes esperados, e executar consultas que simulem o uso no mundo real.

Por exemplo, no nosso conjunto de dados de varejo, você pode fazer uma consulta para calcular os totais de vendas por mês, garantindo que os números correspondam ao que a empresa espera. 

Você também testaria casos extremos, como o que acontece quando um pedido é feito sem itens (o que deveria ser impossível se as restrições estiverem corretas).

6. Implantação

A última etapa é levar o projeto validado para a produção. Isso deve ser feito usando scripts de migração controlados por versão, para que as alterações sejam rastreadas ao longo do tempo.

A implantação também envolve configurar o monitoramento de desempenho e erros, além de garantir que o esquema esteja bem documentado para que futuras alterações possam ser feitas sem confusão. 

Depois da implementação, é normal revisar o projeto de vez em quando, já que novos requisitos também aparecem.

Vantagens dos modelos de dados

Um modelo de dados bem projetado traz várias vantagens.

1. Clarity: Os modelos de dados são tipo uma linguagem comum entre as equipes de negócios e técnicas. Quando todo mundo concorda sobre o que é um “Cliente” e como isso se relaciona com “Pedidos”, os mal-entendidos diminuem e o desenvolvimento fica mais rápido.
2. Integridade: Restrições como chaves estrangeiras e índices exclusivos garantem que dados inválidos não possam ser inseridos no sistema. Isso protege a qualidade dos dados e torna os relatórios mais confiáveis.
3. : Com o uso de índices e otimização de junções, os modelos de dados podem melhorar bastante a velocidade das consultas. Isso é super importante para consultas analíticas que processam grandes conjuntos de dados.
4. Escalabilidade: Um bom modelo é mais fácil de expandir. Se a empresa quiser recursos extras para acompanhar promoções ou pontos de fidelidade mais adiante, você pode adicionar novas tabelas sem mexer nos fluxos de trabalho que já existem.

Desvantagens dos modelos de dados

1. : Em sistemas grandes, o modelo de dados pode ser bem complicado, com centenas de tabelas e relações. Isso pode intimidar os novatos e exigir habilidades específicas para navegar.
2. Custo: Contratar modeladores de dados qualificados e comprar ferramentas de modelagem empresarial pode sair caro. Em empresas pequenas, isso pode ser um investimento bem grande.
3. Rigidez: Os esquemas relacionais não são tão flexíveis quanto as soluções nosql. Alterações nos modelos exigem um planejamento cuidadoso para evitar danos às aplicações e dependências a jusante.
4. Vendor lock-in: Depender muito de recursos de banco de dados exclusivos (como indexação específica do Oracle ou particionamento avançado do SQL Server) pode tornar as migrações futuras caras e complicadas.

Metodologias avançadas de modelagem

A modelagem de dados também pode ter métodos avançados para implementação.

1. Modelagem dimensional

A modelagem dimensional é comum no warehouse, onde o objetivo é tornar as consultas analíticas intuitivas e rápidas.

Isso envolve o uso de esquemas específicos:

• Esquema em estrela: Uma tabela de fatos central (por exemplo, OrderItems) guarda métricas, enquanto várias tabelas de dimensões (por exemplo, Customer, Product, Date) guardam atributos descritivos. Essa estrutura é fácil de consultar pelas ferramentas de BI.

Aqui está como poderia ser:

Fonte: Consultando o esquema em estrela

• Esquema Snowflake: As tabelas de dimensões são normalizadas em subtabelas, o que reduz o armazenamento, mas exige mais junções. Por exemplo, Product poderia ser dividido em tabelas Product e Category.

2. Modelagem de relações entre entidades (ER)

A modelagem ER é mais comum em sistemas transacionais. Ele dá uma ênfase na normalização pra garantir a integridade dos dados. Em alguns casos, a desnormalização é aplicada de forma seletiva para melhorar o desempenho da leitura, especialmente para dados acessados com frequência.

3. Modelagem poliglota

A modelagem poliglota usa diferentes tipos de banco de dados para diferentes cargas de trabalho. 

Por exemplo, você pode usar o PostgreSQL para transações de pedidos e o MongoDB para um catálogo de produtos com atributos flexíveis. Isso permite que você use a ferramenta certa para o trabalho certo, mas aumenta a complexidade operacional.

Otimização de desempenho e princípios de design

1. Anti-padrões comuns

• Supernormalização: Dividir os dados em muitas tabelas pequenas pode causar muitas junções e tornar as consultas lentas.
• Subindexação: Não indexar colunas filtradas com frequência pode causar varreduras completas das tabelas e problemas de desempenho.

2. Considerações sobre nosql

Nos sistemas nosql, o design geralmente é baseado em padrões de acesso em vez de uma normalização rígida. Os dados são organizados para minimizar o número de consultas necessárias para operações comuns, e o particionamento é essencial para evitar gargalos.

3. Compromissos ACID

Sistemas relacionais como o PostgreSQL suportam totalmente as propriedades ACID. ACID, garantindo a consistência dos dados. Muitos bancos de dados nosql relaxam essas garantias para melhorar a velocidade e a escalabilidade, trocando a consistência pela convergência final.

Conclusão

Os modelos de dados são uma parte essencial do design de bancos de dados e podem ter várias formas. Mas, nas empresas de hoje, pra garantir que esses modelos funcionem da melhor maneira possível, é preciso fazer algumas otimizações.

A tecnologia está sempre mudando e sendo atualizada, e aprender e se adaptar o tempo todo é uma necessidade no setor de dados. Para saber mais sobre bancos de dados, confira nosso curso sobre Design de Banco de Dados ou Introdução a bancos de dados relacionais em SQL para começar.

Prefere ler? Nossos artigos sobre Ferramentas de Modelagem de Dados ou Perguntas de entrevista sobre DBMS podem ser úteis.