MODELO

RELACIONAL
2

MODELO RELACIONAL
CARDINALIDADE
No modelo conceitual estudamos a cardinalidade é um modelo gráfico para demostrar o
número de ocorrências de entidade associadas à uma ocorrência da outra entidade em questão
através do relacionamento.

Quando falamos em cardinalidade no modelo relacional (tabelas) essa representação é mate-

rializada por meio de tabelas, e agora iremos trabalhar várias cardinalidades e sempre em conjunto
com o modelo conceitual, pois é comum as bancas colocarem uma cardinalidade no modelo con-
ceitual e cobrar como seria essa representação no modelo relacional.

CARDINALIDADE 1:1
Quando trabalhamos com cardinalidade 1:1 isso quer dizer que cada elemento de uma enti-
dade só pode ter 0 (zero) ou 1 (um) elemento da outra entidade.
No nosso exemplo, um homem pode casar com nenhuma mulher ou casar com apenas uma
mulher, e uma mulher pode não casar com nenhum homem ou com apenas um homem.

Observe que a materialização do relacionamento no modelo relacional é por meio da inclu-

são da chave estrangeira (FK) em um dos lados do relacionamento. E como o relacionamento é 1
 Modelo RELACIONAL 3

(obrigatório) a restrição de integridade referencial garante que o campo da chave estrangeira deve
ser único (unique).
Como a cardinalidade mínima é opcional não há melhor lado para colocar a chave estrangeira.
Vamos ver quando um dos lados é obrigatório:

Veja que nesse nosso relacionamento um funcionário pode usar 0 ou 1 carro, e um carro pode
ser utilizado por 1 e apenas 1 funcionário.
Nesse caso a materialização do relacionamento dar-se por meio da fusão de tabelas, e a
chave estrangeira será a chave primária do relacionamento obrigatório.
No exemplo anterior a restrição de integridade referencial garante que o campo chave estran-
geira seja não nulo e único.
FUSÃO DE TABELA é a criação de uma tabela única (uma tabela à parte), onde aparecerá todos os dados (de
funcionário e carro).

CARDINALIDADE 1:N
Quando temos um relacionamento 1:N a materialização do relacionamento dar-se por meio
de uma chave estrangeira (FK) que deve ficar do lado N do relacionamento.
4

CARDINALIDADE N:N
 Modelo RELACIONAL 5

Quando temos uma cardinalidade N:N a materialização do relacionamento dar-se por meio
de uma criação de uma nova tabela (alguns autores chamam de tabela associativa), a qual será
formada pelas chaves primárias (PK) das tabelas que se relacionam, veja:

E quando no relacionamento uma entidade pode relacionar-se “n” vezes com a outra entidade,
nesse caso a tabela associativa terá linhas duplicadas (e isso não pode).

Repare que nesse cenário houve duplicidade de registros, por isso há a necessidade de colocar
o atributo “DATA” no relacionamento para registrar de maneira única cada instância.
6

AUTO RELACIONAMENTO
No auto relacionamento há a necessidade de referenciar-se como chave estrangeira (FK) a
chave primária (PK) da mesma tabela.
Observe no exemplo que o supervisor de um funcionário é o próprio funcionário, e a restrição
de integridade referencial referencia a chave primária da mesma tabela.
 Modelo RELACIONAL 7

No modelo 1 Funcionário pode ser supervisionado por apenas 1 supervisor e um supervisor

poder supervisionar por N funcionários.

RESTRIÇÃO DE INTEGRIDADE
A restrição de integridade são regras que devem ser garantidas nativamente pelo SGBD e
permitem assegurar a exatidão e a consistência dos dados, e são divididas em:
ͫ Integridade Referencial: garante que o valor da chave estrangeira deve aparecer na chave
candidata da tabela referenciada.

ͫ Integridade de Domínio: os valores que um campo pode assumir, devem ser definidos
previamente. Exemplo: Sexo [M ; F]
8

ͫ Integridade de Vazio: o nosso já estudado not null, ou seja, se o campo de uma coluna
pode ser nulo (vazio).
ͫ Integridade de Chave: garante a unicidade da chave primário, assegurando que um reg-
istro seja único.
ͫ Integridade de Unicidade: garantia se é permitido uma coluna possuir valores idênticos
(Exemplo: A coluna sexo pode repetir, porém o campo Matrícula não pode), ou restringir
pessoas com o mesmo nome.
ͫ Integridade de Entidade: a chave primária não pode ser nula, seu preenchimento é
obrigatório.

REFERÊNCIAS BIBLIOGRÁFICAS
BERTALANFFY, Ludwig Von. Teoria Geral dos Sistemas: fundamentos, desenvolvimento e apli-
cações. Petrópolis: Vozes, 2014.
DATE, C. J. Introdução a Sistemas de Bancos de Dados. 8. ed. Rio de Janeiro: GEN LTC, 2004.
KORTH, Henry F.; SILBERSCHATZ, Abraham; SUDARSHAN, S. Sistema de Banco de Dados. 5. ed
ed. Rio de Janeiro: Elsevier, 2012.
LAUDON, Kenneth C.; LAUDON, Jane P. Sistemas de Informação Gerenciais. 11. ed. São Paulo:
Pearson Education, 2015.
NAVATHE, Shamkant, B.; ELMARSI, Ramez. Sistemas de Banco de Dados. 6. ed. São Paulo:
Pearson Education, 2010.
SOMMERVILLE, Ian. Engenharia de Software. 10. ed. São Paulo: Pearson Education, 2019.