8 — Mapeando os Casos que Faltavam: 1:1 e Multivalorado

1. O que já sabemos (revisão rápida)

Desde o Encontro 5, vocês já mapeiam, na prática, quase tudo:

Conceitual	Vira, no relacional
Entidade	Tabela
Atributo simples	Coluna
Atributo identificador	Chave primária (PK)
Atributo composto	Quebra em colunas separadas
Relacionamento 1:N	FK no lado N
Relacionamento N:N	Tabela associativa, com FK para os dois lados

Isso é só relembrar — vocês já fizeram tudo isso com as próprias mãos, no Workbench. O que falta são dois casos que a turma ainda não tocou: relacionamento 1:1 e atributo multivalorado.

2. O problema do 1:1 (e por que ele é diferente)

No relacionamento 1:N, colocamos uma FK comum no lado N — e pronto, funciona. Mas se tentarmos usar essa mesma solução para um relacionamento 1:1 (por exemplo, Aluno 1:1 Cartão_Biblioteca), aparece um problema: uma FK comum não impede que dois Cartões apontem para o mesmo Aluno. Nada no banco garante que a relação seja realmente "um para um" — na prática, ficaria igual a um 1:N.

A solução: marcar a coluna da FK como UNIQUE (chave única). Isso impede valores repetidos naquela coluna — ou seja, cada Aluno só pode aparecer em, no máximo, um Cartão.

No MySQL Workbench existe até uma ferramenta própria para isso: "1:1 Identifying Relationship" — nela, a FK também é a própria chave primária da tabela filha, o que já garante o 1:1 automaticamente (já que toda PK é única por definição).

Como fazer no Workbench

1. Crie a tabela cartao_biblioteca: numero_cartao (PK), data_emissao.
2. Adicione a coluna matricula_aluno (vai virar a FK).
3. Escolha a ferramenta "1:1 Non-Identifying Relationship".
4. Clique em cartao_biblioteca e depois em aluno.
5. Abra a tabela cartao_biblioteca, vá na aba Columns, e marque a caixinha UQ (unique) na coluna matricula_aluno.

3. Atributo multivalorado, na prática

Já vimos a regra: um atributo multivalorado (ex.: telefone) vira uma tabela nova, com uma FK para a entidade original. Hoje vamos construir isso de verdade pela primeira vez.

Forma lógica (planejamento no papel, antes de construir):

TELEFONE_ALUNO(matricula_aluno FK, telefone)

Por que a chave precisa ser composta? Se a PK fosse só matricula_aluno, o aluno só poderia ter um telefone na tabela — cada PK só pode aparecer uma vez, e isso contradiria o motivo de a tabela existir. Se a PK fosse só telefone, o mesmo número não poderia aparecer em mais de uma linha — o que impediria, por exemplo, dois alunos de uma mesma família compartilharem um telefone fixo. A combinação dos dois resolve isso: um aluno pode aparecer em várias linhas (um telefone por linha), e um telefone pode se repetir entre alunos diferentes — só não pode repetir a mesma combinação aluno+telefone duas vezes.

Como fazer no Workbench

1. Crie a tabela telefone_aluno: telefone (sem PK própria ainda).
2. Escolha "1:n Non-Identifying Relationship" e clique em telefone_aluno (lado N) e depois em aluno (lado 1).
3. O Workbench cria a FK matricula_aluno automaticamente.
4. Marque, na aba Columns, tanto telefone quanto matricula_aluno como parte da PK (chave composta).

4. A notação lógica como ferramenta de planejamento

Escrever a forma lógica no papel antes de abrir o Workbench (como fizemos acima) não é só um exercício teórico — é um hábito profissional: planejar rapidinho no papel evita ficar tentando e testando direto na ferramenta.

5. Prévia do próximo encontro

No Encontro 9, vamos consolidar tudo o que foi visto: modelar um cenário completo, do zero, e revisar para a Avaliação.

---

Vídeos sobre o assunto

• Modelagem de Banco de Dados: Cardinalidade de relacionamento 1:1 — vídeo que explica o relacionamento entre entidades de cardinalidade 1:1.
• Modelagem de Banco de Dados: Identificadores Compostos e Atributos Multivalorados — vídeo que explica os atributos identificadores e os multivalorados e como tratá-los no modelo conceitual para evitar a existência de dados que não sejam repetidos e atômicos, respectivamente

Para se aprofundar

• How to Design One-to-One Relationships in MySQL — artigo (em inglês) explicando por que o 1:1 exige UNIQUE, com exemplos de código.
• MySQL Workbench Manual — Adding Foreign Key Relationships — documentação oficial sobre as ferramentas de relacionamento, incluindo 1:1 Identifying e Non-Identifying.