Tabelas, linhas, colunas e domínios no modelo relacional

O modelo relacional representa fatos por relações

Na aula anterior, construímos um modelo entidade-relacionamento para tornar conceitos e regras do domínio discutíveis. Agora iniciamos o projeto lógico relacional: representaremos fatos em relações, formadas por atributos e tuplas cujos valores pertencem a domínios.

E. F. Codd apresentou o modelo relacional em 1970 com uma motivação que continua atual: proteger usuários e aplicações dos detalhes internos de organização dos dados. Em vez de navegar por ponteiros físicos entre registros, trabalhamos com valores e operações sobre conjuntos.

Uma tabela é a forma visual mais comum de apresentar uma relação: atributos aparecem como colunas e tuplas como linhas. Essa semelhança ajuda a aprender, mas relação matemática, tabela SQL e grade exibida na tela não são sinônimos perfeitos.

Um vocabulário conecta teoria e implementação

Considere a relação TRILHA:

Podemos nomear cada parte:

• relação: o conjunto de fatos sobre trilhas;
• esquema da relação: nome, atributos e domínios declarados;
• atributo: uma propriedade nomeada, como titulo;
• domínio: conjunto de valores admissíveis para um atributo;
• tupla: um fato completo, como a trilha identificada por 7;
• valor: um componente de uma tupla, como publicada.

Em linguagem SQL e de produtos, é comum dizer tabela, coluna e linha. Na teoria relacional, os termos correspondentes são relação, atributo e tupla. “Registro” e “campo” aparecem em conversas e interfaces, mas podem ser ambíguos.

Esquema descreve; estado muda

O esquema da relação pode ser escrito de forma compacta:

TRILHA(id_trilha, titulo, publicada_em, situacao)

Uma descrição mais completa associa cada atributo a um domínio. O esquema muda quando adicionamos, removemos ou redefinimos atributos e regras estruturais.

O estado da relação é o conjunto de tuplas válidas em um instante. Publicar outra trilha altera o estado, não necessariamente o esquema. Essa distinção aplica, no nível relacional, a diferença entre esquema e estado estudada na arquitetura de bancos.

Atributos possuem nome e significado

Um atributo identifica um papel dentro da relação. Não basta declarar que uma coluna contém texto: titulo e situacao podem usar representações textuais, mas possuem significados e conjuntos válidos diferentes.

Nomes devem ser claros no contexto da relação. data diz pouco; publicada_em expressa qual evento a data representa. Também convém evitar embutir apresentação no atributo: titulo_em_azul mistura dado editorial com decisão visual.

Na formulação relacional, uma tupla associa valores a atributos nomeados. Por isso, a posição visual da coluna não deveria carregar significado de negócio. Ferramentas SQL mantêm uma ordem declarada para exibição e para alguns comandos, mas consultas e aplicações robustas devem selecionar colunas pelo nome em vez de depender de “a terceira coluna”.

Domínio é mais do que um tipo de armazenamento

Um domínio é o conjunto de valores admissíveis para determinado papel. O atributo percentual pode aceitar números inteiros entre 0 e 100. situacao_trilha pode aceitar rascunho, publicada ou arquivada. publicada_em aceita datas coerentes com a regra editorial.

Um tipo SQL fornece representação e operações básicas. O domínio acrescenta significado e restrições. Dois atributos podem usar integer e ainda pertencer a domínios incompatíveis: id_estudante e percentual não deveriam ser somados, comparados ou trocados só porque compartilham o tipo físico.

No PostgreSQL, CREATE DOMAIN permite criar um tipo baseado em outro e anexar restrições. Um exemplo didático seria:

CREATE DOMAIN percentual_progresso AS integer
  CHECK (VALUE BETWEEN 0 AND 100);

Isso materializa parte da ideia de domínio no produto, mas o conceito não se limita ao comando. Regras como “a data de publicação não pode preceder a criação da trilha” dependem de mais de um atributo e não cabem em um domínio isolado.

Tupla registra um fato completo

Uma tupla reúne um valor para cada atributo da relação. A ordem em que os valores são escritos numa notação compacta precisa ser interpretada pelo esquema:

(7, "Banco de Dados e SQL", 2026-08-29, "publicada")

Sozinha, a sequência 7, texto, data, texto não explica o fato. Os atributos informam que 7 identifica a trilha, que a data representa publicação e que o último valor descreve situação.

Uma relação não precisa representar somente uma entidade. MATRICULA(id_estudante, id_trilha, matriculada_em, situacao) representa uma associação do domínio. Cada tupla afirma que determinado estudante se matriculou em determinada trilha, em uma data e situação.

Isso prepara o mapeamento do modelo ER, mas ainda não define chaves primárias ou estrangeiras. A próxima aula tratará justamente de como identificar tuplas e conectar relações com precisão.

Relações são conjuntos, não sequências de linhas

No modelo relacional clássico, uma relação é um conjunto de tuplas. Duas propriedades decorrem dessa base:

1. uma mesma tupla não aparece duas vezes no conjunto;
2. o conjunto não possui uma primeira, segunda ou última tupla por natureza.

Em uma tabela exibida, linhas aparecem em alguma ordem porque uma tela precisa desenhá-las. Essa ordem não pertence automaticamente ao significado da relação. O PostgreSQL documenta que, sem ORDER BY, a ordem retornada é indeterminada e não deve ser presumida.

SQL pode preservar duplicatas

Há outra diferença importante entre teoria e linguagem. Uma consulta SQL usa, por padrão, semântica que pode preservar linhas duplicadas. SELECT DISTINCT solicita sua eliminação no resultado. Tabelas SQL também precisam de restrições adequadas para impedir duplicação lógica.

Portanto, “relações não têm tuplas duplicadas” é uma propriedade do modelo matemático. Não é garantia automática de qualquer tabela ou resultado SQL. O projeto deve declarar como cada fato será identificado e quais repetições são válidas.

Grau e cardinalidade medem a forma atual

O grau, também chamado de aridade, é a quantidade de atributos de uma relação. TRILHA possui grau 4 no exemplo.

A cardinalidade da relação é a quantidade de tuplas em determinado estado. Se existem três trilhas, a cardinalidade de TRILHA é 3 naquele momento.

Esse uso de cardinalidade difere da aula de modelo ER. No ER, cardinalidade restringe quantas ocorrências podem participar de um relacionamento, como 0..N. No modelo relacional, cardinalidade frequentemente significa quantidade atual de tuplas.

O contexto evita confundir uma regra estrutural com uma contagem que muda.

Cada relação deve possuir um significado declarativo

Uma relação bem definida pode ser lida como um predicado. Para TRILHA, a frase seria:

Existe uma trilha identificada por id_trilha, com titulo, publicada em publicada_em e na situacao informada.

Cada tupla torna essa frase verdadeira para determinados valores. Essa leitura ajuda a localizar relações misturadas. Se algumas linhas descrevem trilhas e outras descrevem módulos, o significado não é uniforme.

Também ajuda a avaliar valores ausentes. Se uma trilha em rascunho ainda não possui data de publicação, devemos decidir se publicada_em admite ausência, se há outra relação para eventos ou se o predicado precisa ser reformulado. SQL representa ausência ou desconhecimento frequentemente com NULL, mas NULL não é um valor comum de todos os domínios e introduz lógica própria. Ele será aprofundado na aula de consultas.

Operações relacionais preservam uma forma consultável

O poder do modelo não está apenas em armazenar tabelas, mas em derivar novas relações por operações. Podemos:

• restringir tuplas por uma condição;
• projetar apenas determinados atributos;
• combinar relações por valores correspondentes;
• unir conjuntos compatíveis;
• calcular relações derivadas.

Uma consulta que combina MATRICULA e TRILHA pode produzir uma relação com estudante, título e situação da matrícula. O resultado continua organizado por atributos e tuplas, o que permite compor operações.

Não precisamos memorizar álgebra relacional nesta aula. O ponto central é que aplicações expressam qual resultado lógico desejam, enquanto o SGBD decide caminhos físicos para obtê-lo. Essa separação retoma a independência de dados estudada no primeiro módulo.

Da modelagem conceitual a relações candidatas

Como primeira aproximação, o domínio do Guia Estudos pode sugerir:

ESTUDANTE(id_estudante, nome)
TRILHA(id_trilha, titulo, publicada_em, situacao)
MODULO(id_modulo, id_trilha, titulo, ordem)
MATRICULA(id_estudante, id_trilha, matriculada_em, situacao)

Esse desenho ainda contém perguntas abertas:

• quais atributos identificam cada tupla?
• id_trilha em MODULO precisa corresponder a uma trilha existente?
• um estudante pode se matricular duas vezes na mesma trilha?
• ordem é única dentro de cada trilha?
• quais situações são permitidas e quais transições são válidas?

Essas perguntas não indicam fracasso. Elas mostram a sequência do projeto: primeiro definimos relações e domínios; depois identificamos chaves e conexões; em seguida, declaramos integridade e analisamos redundância.

Um roteiro para revisar uma relação

Para cada relação candidata, pergunte:

1. qual frase cada tupla torna verdadeira?
2. todos os atributos descrevem esse mesmo fato?
3. qual é o domínio semântico de cada atributo?
4. valores ausentes possuem significado definido?
5. como duas tuplas serão distinguidas?
6. alguma ordem visual foi confundida com regra?
7. o mesmo fato pode ser repetido sem intenção?
8. quais regras pertencem ao atributo, à tupla ou a várias relações?

As respostas formam o contrato que depois será implementado com tipos e restrições do SGBD.

Erros comuns

• tratar tabela como planilha sem regras: aparência retangular não garante identidade, domínios ou integridade;
• confundir tipo e domínio: dois inteiros podem representar conceitos incompatíveis;
• depender da posição da coluna: significado deve vir do nome e do esquema;
• presumir ordem das linhas: sem ordenação explícita, não existe sequência garantida;
• supor que SQL elimina duplicatas automaticamente: resultados podem preservar repetições;
• dizer que toda relação representa uma entidade: relações também registram associações e eventos;
• confundir esquema com estado: inserir tupla não altera necessariamente a estrutura;
• misturar cardinalidade ER com contagem de tuplas: a palavra possui sentidos diferentes;
• usar NULL como resposta para qualquer dúvida de modelagem: ausência precisa de semântica clara;
• antecipar índices como parte da relação: índices são estruturas físicas, não atributos do fato lógico.

O que você deve guardar

O modelo relacional representa fatos como relações. Um esquema nomeia atributos e associa domínios; o estado contém as tuplas existentes. Tabela, coluna e linha são aproximações práticas para relação, atributo e tupla, mas implementações SQL acrescentam comportamentos próprios.

Domínio é um conjunto de valores com significado, não apenas um tipo de armazenamento. Relações são conjuntos sem ordem inerente e sem tuplas repetidas, enquanto SQL pode preservar duplicatas e só garante ordem quando ela é solicitada. Grau conta atributos; cardinalidade da relação conta tuplas.

Na próxima aula, aprenderemos a identificar tuplas com chaves candidatas, primárias e compostas e a representar conexões com chaves estrangeiras.

Referências

• Codd, E. F. — A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 1970. Acesso em 29 ago. 2026.
• ACM, IEEE-CS e AAAI — CS2023: Data Management Core. Acesso em 29 ago. 2026.
• PostgreSQL Global Development Group — Concepts. Acesso em 29 ago. 2026.
• PostgreSQL Global Development Group — Sorting Rows. Acesso em 29 ago. 2026.
• PostgreSQL Global Development Group — Select Lists and DISTINCT. Acesso em 29 ago. 2026.
• PostgreSQL Global Development Group — CREATE DOMAIN. Acesso em 29 ago. 2026.
• Oracle — Database Concepts. Acesso em 29 ago. 2026.