Visão Geral dos Modelos de Dados

O que é um modelo de dados

Um modelo de dados é uma representação formal que define três coisas: a estrutura dos dados, as restrições sobre eles e as operações permitidas para manipulá-los. Ele descreve como os dados se organizam e se acessam, sem depender de disco, arquivo ou endereço físico.

O mesmo mini-mundo (livros, contas, peças) pode ser gravado de dezenas de jeitos no hardware. Sem um contrato estável, cada aplicação dependeria do layout concreto do arquivo. O modelo isola quem usa o banco de quem o implementa: conjuntos de objetos, atributos e relacionamentos, mais regras de integridade.

Numa biblioteca, Livro, Autor e Usuário são conjuntos de objetos; título e ISBN são atributos de Livro; “escreve” e “empresta” são relacionamentos. A regra “ISBN único” e a regra “um volume emprestado não se empresta de novo ao mesmo tempo” são restrições do modelo, independentemente do arquivo. Acrescentar um índice B+ sobre o ISBN, ou mudar o layout da página no disco, não muda o conjunto Livro.

Independência física: você muda disco, índice ou layout de página e as consultas continuam a falar em relações, documentos ou objetos. Independência lógica: acrescenta um atributo ou um conjunto novo e as aplicações que não o usam não precisam ser reescritas. Sem o modelo, as duas mudanças propagam-se para o código da aplicação.

Famílias de modelos

Os modelos que importam nesta página:

• Relacional — tabelas (relações) com chave
• Entidade-relacionamento (ER) — desenho conceitual do mini-mundo
• Semiestruturado — árvore ou grafo com esquema parcial (XML, JSON)
• Orientado a objetos — objetos com estado e comportamento
• Hierárquico (e o em rede, que o generaliza) — árvore ou grafo de registros

O ER é o modelo de projeto. Relacional, semiestruturado, OO e hierárquico são propostas de como os dados ficam e se consultam. O diagrama ER descreve o mundo; a tabela relacional implementa relações.

Modelo relacional

O modelo relacional representa os dados por relações: tabelas de tuplas (linhas) e atributos (colunas). Formalmente, uma relação $R$ é um subconjunto do produto cartesiano de domínios $D_1 \times D_2 \times \cdots \times D_n$, onde cada $D_i$ é o domínio do atributo $A_i$. Cada relação tem uma chave primária que identifica as tuplas; chaves estrangeiras ligam relações.

Tabelas funcionam porque o produto cartesiano deixa explícito o domínio de cada coluna, e a chave garante que duas tuplas não descrevem o mesmo fato. Quem consulta não navega ponteiro a ponteiro: combina relações com operações. Essas operações — seleção, projeção, junção, união, produto, diferença, renomeação — pertencem à álgebra relacional. Esta página cita só os nomes; as definições ficam na página da álgebra.

A ordem das linhas não faz parte do modelo: duas tabelas com as mesmas tuplas em ordem diferente são a mesma relação. O modelo fixa o esquema (nomes e domínios) e as restrições de chave. O endereço da página no disco fica fora do escopo do modelo.

Clientes(ID, Nome, Cidade) e Pedidos(ID_Pedido, ID_Cliente, Valor) são duas relações. Pedidos com valor maior que $100$ junto do cliente correspondente é uma consulta relacional — escrita em álgebra ou em SQL, não redefinida aqui.

Modelo entidade-relacionamento

O modelo ER descreve o mini-mundo em conjuntos de entidades, atributos e relacionamentos, em geral num diagrama (retângulo, elipse, losango). Serve para negociar o significado antes de escolher tabelas, documentos ou objetos.

Cardinalidade, entidade fraca e especialização são decisões de significado. Se essas decisões ficam só para o esquema armazenado, significado e implementação se misturam. O diagrama é o lugar em que se discute “um autor escreve vários livros?” sem já escolher chave estrangeira ou documento aninhado.

Livro e Autor no diagrama, com um losango “escreve” muitos-para-muitos, diz o que o mini-mundo é. Ainda não diz se isso vira três tabelas, um JSON ou uma classe.

Modelo semiestruturado

O modelo semiestruturado admite estrutura flexível: esquema parcial ou ausente. Os dados formam grafos ou árvores — nós são objetos ou valores; arestas ligam partes. Elementos opcionais simplesmente não aparecem. Formatos usuais: XML e JSON. Consultas navegam a árvore (XPath, XQuery, JSONiq).

Catálogos, documentos e APIs em que cada item traz um subconjunto diferente de campos pedem esse modelo. Forçar todos os campos em colunas rígidas gera tabela cheia de nulos ou esquema que muda a cada produto novo.

<funcionario>
  <nome>Maria Silva</nome>
  <departamento>TI</departamento>
  <telefone>1234-5678</telefone>
</funcionario>

Um segundo funcionário pode omitir telefone e incluir celular. Os dois documentos convivem sem alterar um esquema global. Essa é a flexibilidade do modelo.

No relacional, o mesmo par exigiria ou uma coluna telefone nula no segundo funcionário, ou um esquema novo. O semiestruturado aceita a ausência do campo; o relacional exige que o atributo exista no esquema, mesmo que a tupla não tenha valor.

Orientado a objetos, hierárquico e em rede

• Orientado a objetos. Dados como objetos: estado (atributos) e comportamento (métodos), com herança e encapsulamento. Serve quando o mini-mundo já é uma hierarquia de classes (Veículo → Carro, Caminhão) e as operações (calcular imposto) viajam com o dado. Carro e Caminhão herdam placa e redefinem o cálculo; o banco guarda o objeto, não só a linha.

• Hierárquico. Árvore: cada registro tem um pai e vários filhos. Bom para hierarquias estritas (país–estado–cidade). Relacionamentos muitos-para-muitos não cabem sem duplicar subárvores: uma cidade em dois recortes administrativos viraria duas cópias.

• Em rede. Generaliza o hierárquico: um registro pode ter vários pais (grafo dirigido). Liga dispositivos ou peças com mais de um superior, ao custo de navegação mais trabalhosa — a consulta segue ponteiros, não uma operação sobre conjuntos.

No hierárquico o tipo da árvore é fixo (todo estado tem o mesmo formato de filho); no semiestruturado o formato de cada documento pode variar.

Comparação

A escolha segue o mini-mundo e o tipo de consulta que ele exige. Quando importam integridade e consultas tabulares, o caminho usual é o relacional (depois do ER). Atributos que mudam de item para item pedem o semiestruturado. Comportamento acoplado ao dado sugere OO. Hierarquia estrita de registros encaixa no hierárquico; vários pais, na rede.

Escolher o modelo inadequado tem consequências visíveis: um catálogo só em JSON perde a unicidade de código de produto; um N:N forçado em árvore hierárquica duplica subárvores; um ER pulado vira tabela que mistura significado com arquivo.

O ER continua útil mesmo quando o armazenamento final não é relacional: o diagrama fixa “produto em várias categorias” antes de se decidir se isso vira tabela de ligação, documento aninhado ou grafo em rede.

A tabela contrasta estrutura e consulta. Quando o programa já é orientado a objetos e o armazenamento é relacional, o custo seguinte é traduzir um mundo no outro: a divergência de impedância.

Divergência de impedância

A divergência de impedância é o atrito de traduzir um programa orientado a objetos para tabelas. O par em desencontro é a linguagem OO e o modelo relacional: de um lado herança, identidade de objeto e coleções; do outro, relações de esquema fixo, tuplas e atributos atômicos. Quando o banco também é orientado a objetos, o armazenamento já espelha herança, identidade e coleção, e esse atrito estrutural diminui.

O mapeamento percorre quatro cortes.

• Herança. Carro e Caminhão herdam Veículo. Na relação, ou cada classe vira uma tabela ligada pela chave, ou uma tabela só carrega todos os atributos e uma coluna de tipo, com nulos onde a subclasse não se aplica.
• Identidade. Duas instâncias na memória seguem distintas mesmo com atributos iguais. Na relação, a chave identifica o fato, e duas tuplas de mesma chave não coexistem.
• Coleções. A lista de revisões não é atributo atômico: cada elemento vai para outra relação, ligado por chave estrangeira.
• Navegação. Seguir a referência no programa vira uma junção entre essas relações.

Mapeamento objeto-relacional é o nome dessa tradução.

O atrito existe porque o grão muda. O objeto agrupa hierarquia, identidade e coleção numa unidade; a relação exige esquema plano e liga fatos por chave.

Objeto persistente e objeto transiente

Com o banco também orientado a objetos, o armazenamento espelha o objeto. Resta o ciclo de vida: a instância continua no banco depois que o processo termina. Um objeto é persistente quando o banco o grava de forma durável: sobrevive ao fim do processo que o criou e outro programa pode recuperá-lo depois. Um objeto transiente existe só na memória desse processo e desaparece quando a execução acaba.

A gravação é o corte entre dado de trabalho e dado do banco. Sem o registro durável, encerrar o processo apaga o objeto. Com ele, a identidade gravada serve a uma execução posterior, que pede essa identidade e recebe o estado guardado.

Um domínio, quatro encaixes

Uma loja tem produtos, categorias, pedidos e um catálogo em que cada produto traz um conjunto diferente de fichas técnicas.