SQL Interview Prep · Aula

Modelagem ER e cardinalidade de relacionamentos

Transformando requisitos em entidades, relacionamentos e tabelas associativas.

Modelagem ER e cardinalidade de relacionamentos é uma aula grátis de SQL Interview Prep no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de SQL Interview Prep, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de SQL Interview Prep inclui 4 aulas no total.

Por que a modelagem ER aparece nas entrevistas

Depois da normalização, os entrevistadores testam se você consegue transformar requisitos em um esquema. A proposta geralmente é aberta: "Projete um banco de dados para um aplicativo de transporte por corrida" ou "Modele um sistema de biblioteca".

Este é um exercício de modelagem entidade-relacionamento (ER). Eles observam como você identifica entidades, atributos e os relacionamentos entre eles, incluindo a cardinalidade.

A habilidade consiste em converter substantivos e verbos do enunciado em tabelas e chaves estrangeiras.

Entidades, atributos e relacionamentos

Três blocos de construção formam todo modelo ER:

Entidade: algo sobre o qual você armazena dados (Cliente, Pedido, Produto). Normalmente, torna-se uma tabela.
Atributo: uma propriedade de uma entidade (nome, preço, data de criação). Normalmente, torna-se uma coluna.
Relacionamento: como as entidades se conectam (um Cliente faz um Pedido). É implementado com chaves estrangeiras ou tabelas de junção.

Dica extraída do enunciado: substantivos tornam-se entidades/atributos; verbos tornam-se relacionamentos.

Cardinalidade: o conceito central

A cardinalidade descreve quantas instâncias de uma entidade se relacionam com outra. Há três categorias:

Um para um (1:1): uma linha deste lado corresponde a no máximo uma linha do outro lado.
Um para muitos (1:N): uma linha deste lado corresponde a muitas linhas do outro lado (é o caso mais comum).
Muitos para muitos (M:N): as linhas de ambos os lados correspondem a muitas linhas do outro lado.

Acertar a cardinalidade determina onde ficam as chaves estrangeiras e se você precisa de uma tabela de junção.

Implementando um para muitos

Um relacionamento um para muitos é implementado colocando a chave estrangeira no lado "muitos". Um cliente tem muitos pedidos, então cada linha de pedido contém o identificador do cliente.

Em uma entrevista, sempre declare a direção explicitamente: "De um cliente para muitos pedidos; portanto, a FK fica nos pedidos."

CREATE TABLE customers (
  customer_id INT PRIMARY KEY,
  name        VARCHAR(100)
);

CREATE TABLE orders (
  order_id    INT PRIMARY KEY,
  customer_id INT NOT NULL,
  order_date  DATE,
  FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

Implementando muitos para muitos

Um banco de dados relacional não consegue armazenar M:N diretamente. A resposta que os entrevistadores esperam é uma tabela de junção (também chamada de tabela intermediária, de ligação ou associativa).

Estudantes se matriculam em muitos cursos, e os cursos têm muitos estudantes. Crie uma tabela enrollments cuja chave combine as duas chaves estrangeiras. Isso transforma M:N em dois relacionamentos 1:N.

CREATE TABLE students (
  student_id INT PRIMARY KEY,
  name       VARCHAR(100)
);

CREATE TABLE courses (
  course_id  INT PRIMARY KEY,
  title      VARCHAR(100)
);

CREATE TABLE enrollments (
  student_id INT,
  course_id  INT,
  enrolled_at DATE,
  PRIMARY KEY (student_id, course_id),
  FOREIGN KEY (student_id) REFERENCES students(student_id),
  FOREIGN KEY (course_id)  REFERENCES courses(course_id)
);

A tabela de junção pode armazenar dados

Uma pergunta complementar comum é: "Onde você armazena a nota que um estudante recebeu em um curso?"

A nota pertence ao relacionamento, e não apenas ao estudante ou ao curso. Portanto, ela deve ficar na tabela de junção. Esta é a ideia que os entrevistadores querem verificar: os atributos de um relacionamento M:N ficam na tabela intermediária.

Exemplos: data de matrícula, nota, quantidade em uma linha de pedido e uma função na participação em um projeto.

ALTER TABLE enrollments
  ADD COLUMN grade CHAR(2);
-- grade describes THIS student in THIS course,
-- so it belongs on the junction table

Implementando um para um

Relacionamentos 1:1 são mais raros. Você os implementa dando à tabela dependente uma chave estrangeira que também seja uma chave única (geralmente a própria chave primária).

Exemplo: um user e um user_profile com detalhes adicionais opcionais. Definir user_id como a chave primária da tabela de perfil garante no máximo um perfil por usuário.

CREATE TABLE users (
  user_id INT PRIMARY KEY,
  email   VARCHAR(255)
);

CREATE TABLE user_profiles (
  user_id INT PRIMARY KEY,           -- 1:1 enforced here
  bio     TEXT,
  avatar_url VARCHAR(255),
  FOREIGN KEY (user_id) REFERENCES users(user_id)
);

Opcionalidade e participação

A cardinalidade tem uma segunda dimensão valorizada pelos entrevistadores: a opcionalidade (também chamada de participação).

Obrigatória: todo pedido deve ter um cliente, portanto customer_id é NOT NULL.
Opcional: um usuário pode ter ou não um perfil, portanto o relacionamento pode estar ausente.

Você expressa a participação obrigatória usando NOT NULL na chave estrangeira. Mencionar a possibilidade de NULL mostra que você pensa em restrições reais, e não apenas em formatos.

Relacionamentos autorreferenciados

Alguns relacionamentos fazem uma entidade apontar para si mesma. Um funcionário tem um gerente que também é funcionário; uma categoria tem uma categoria pai.

Você modela isso com uma chave estrangeira que referencia a mesma tabela. Os entrevistadores esperam esse caso em organogramas e estruturas em árvore, e ele combina naturalmente com junções da própria tabela e CTEs recursivas.

CREATE TABLE employees (
  employee_id INT PRIMARY KEY,
  name        VARCHAR(100),
  manager_id  INT NULL,
  FOREIGN KEY (manager_id) REFERENCES employees(employee_id)
);
-- manager_id NULL = top of the hierarchy (e.g. CEO)

Uma breve resolução de modelagem

Pratique o método de transformar verbos em relacionamentos. Proposta: "Clientes fazem pedidos; cada pedido contém muitos produtos; produtos pertencem a fornecedores."

Cliente 1:N Pedido (chave estrangeira do cliente nos pedidos).
Pedido M:N Produto -> order_items, a tabela de junção (com a quantidade).
Fornecedor 1:N Produto (chave estrangeira do fornecedor nos produtos).

Declare cada cardinalidade e onde a chave fica. Essa explicação é o que garante o sucesso na entrevista.

Perguntas de esclarecimento a fazer

Os entrevistadores valorizam candidatos que fazem perguntas antes de projetar. Boas perguntas de esclarecimento:

"Um produto pode pertencer a mais de um fornecedor?" (decide entre 1:N e M:N).
"Todo pedido deve ter pelo menos um item?" (participação).
"Precisamos do histórico ou apenas do estado atual?" (determina tabelas adicionais).

As respostas alteram a cardinalidade e a quantidade de tabelas, portanto nunca presuma. Fazer perguntas demonstra senioridade.

Verificação rápida

Você está modelando estudantes e cursos, em que cada estudante pode fazer muitos cursos e cada curso tem muitos estudantes.

Recapitulação: modelagem de ER e cardinalidade

Agora você consegue conduzir uma questão aberta de modelagem de esquemas:

Transforme substantivos em entidades/atributos e verbos em relacionamentos.
1:N: coloque a chave estrangeira no lado muitos.
M:N: use uma tabela associativa contendo ambas as chaves estrangeiras, além de quaisquer atributos do relacionamento.
1:1: use uma chave compartilhada/única na tabela dependente.
Use NOT NULL para expressar participação obrigatória e chaves estrangeiras autorreferentes para hierarquias.
Faça perguntas de esclarecimento antes de definir a cardinalidade.

Perguntas Frequentes

A aula “Modelagem ER e cardinalidade de relacionamentos” é grátis?

Sim — o texto completo de “Modelagem ER e cardinalidade de relacionamentos” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de SQL Interview Prep, atualize para CoddyKit PRO. O curso de SQL Interview Prep inclui 4 aulas no total.

O que vou aprender em “Modelagem ER e cardinalidade de relacionamentos”?

Transformando requisitos em entidades, relacionamentos e tabelas associativas. Você pratica SQL Interview Prep com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar SQL Interview Prep?

Nenhuma experiência prévia é necessária. SQL Interview Prep no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.

Quanto tempo leva a aula “Modelagem ER e cardinalidade de relacionamentos”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de SQL Interview Prep?

Sim. Cada aula de SQL Interview Prep inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

Normalização até a 3FN
Modelagem ER e cardinalidade de relacionamentos
Esquema estrela e projeto de armazém de dados
Conjunto completo de problemas de entrevista simulada

← Voltar para SQL Interview Prep