Cardinalidade

Ewerton J. Silva
Introdução
Banco de dados são acessados por sistemas para inserção, consulta ou
edição de dados. No exemplo abaixo, temos uma tela onde é
necessário o acesso a diversas tabelas diferentes.
Uso de relacionamento
Neste exemplo, em uma tela de vendas, é possível acessar dados das
tabelas relacionadas, permitindo que o usuário tenha maior
usabilidade no sistema.
Uso de relacionamento
A tela mostrada anteriormente
é referente a tabela de
“Vendas”, porém é possível
acessar os dados das tabelas
relacionadas como “Clientes” e
“Funcionários”.
 Como ficam os registros no banco de dados?
A vantagem da utilização de tabelas relacionadas, se dá
pelo fato de que não há necessidade de escrever o nome
de um cliente toda vez que efetuamos uma venda, bem
como informações relacionadas ao mesmo. Imagina, que
toda vez que uma venda for realizada, precisássemos
inserir informações como endereço, data de nascimento,
etc... Não seria viável, além do fato de consumir mais
espaço ao gravar uma informação de venda, também
poderiam ocorrer erros na inserção da mesma
informação diversas vezes, dessa forma ao criar um
relacionamento, podemos inserir apenas uma referência
a um cliente que tem seus dados inseridos no sistema
apenas uma vez. Essa referência é chamada de chave
estrangeira.
Relacionando dados
Com o relacionamento é possível acessar qualquer uma das colunas da
tabela “Clientes”, quando houver uma FK representando o
relacionamento.
Dados relacionados
Nesse exemplo, estamos listando as vendas com os nomes dos clientes,
qualquer informação da tabela clientes poderia ser inserida nesta
pesquisa, sem aumentar o armazenamento de dados da tabela de
vendas.
Integridade
A integridade existente nos SGDBs permite que não seja possível
registrar uma venda com um código de funcionário inexistente.
Relacionamento entre tabelas
Imagine que em um sistema exista a necessidade de cadastrar os
alunos e suas respectivas cidades de residência.

aln_cod aln_nome cid_cod cid_nome

1 Zé 59 Tupã
2 Bila 78 Iacri
3 Tonho 79 Parapuã
Tipos de cardinalidade
Em modelagem de dados a cardinalidade é um dos princípios
fundamentais sobre relacionamento de um banco de dados relacional.
Nela são definidos o graus de relação entre duas entidades ou tabelas.
A cardinalidade máxima pode nos mostrar onde fica a chave
estrangeira, já a mínima nos mostra a necessidade de um campo.
A cardinalidade máxima tem valores como “1” e “N”. O “N” aponta
onde deve ficar a chave estrangeira.
Já a cardinalidade mínima tem valores como “1” e “0”. Aqui o 1
representa a obrigatoriedade do campo, além de nos auxiliar na
identificação de qual tabela deve ter suas informações inseridas
primeiro.
Símbolos que representam as cardinalidades
• Máxima

1 N

• Mínima

0 1
Identificando cardinalidade
Para relacionar as informações, é necessário identificar a cardinalidade
mínima e máxima entre as tabelas.
Um registro de aluno pode estar associado a
no máximo quantos registros de cidades.
Um registro de aluno pode estar associado a no
mínimo quantos registros de cidades? É
obrigatória relacionar a cidade que será
cadastrada no sistema a um aluno?
Um registro de cidade no banco de dados, pode
estar associado a no máximo quantos alunos?
Um registro de cidade no banco de dados, pode
ter no mínimo quantos alunos associados a ela? É
necessário ter alunos associados a uma cidade no
momento de cadastro da mesma?
Tipo de relacionamento: N : 1
A representação deste relacionamento é N : 1, pois utilizamos a
cardinalidade máxima para representar o tipo de relacionamento. A
chave estrangeira, por padrão, sempre está associada ao lado N
(muitos) do relacionamento.
Obrigatoriedade no relacionamento: N : 1
A cardinalidade mínima representa a obrigatoriedade de selecionar a
cidade no momento do cadastro de alunos. Dessa forma, recomenda-
se que as cidade sejam cadastradas antes dos alunos.
Identificando cardinalidade
Em uma escola, um aluno pode estar matriculado em mais de um curso
seja simultaneamente ou não, já o curso pode ter vários discentes.
Um registro de aluno pode ser relacionado a
no máximo quantos cursos?
Um registro de aluno pode estar relacionado
a no mínimo quantos cursos? É possível
cadastrar um aluno sem selecionar o curso
que este está matriculado?
Um curso, pode ter no máximo quantos
registros de alunos relacionados a ele?
Um curso, pode ter no mínimo quantos
alunos relacionados a ele? Para cadastrar um
curso, é necessário que exista um aluno
relacionado a este?
Tipo de relacionamento: N : N
Quando um relacionamento N:N é identificado, será necessário que
este se torne 1:N, pois não é possível associar os registros nas duas
tabelas ao mesmo tempo.
 Impossibilidade de se representar o N : N
Ao inserir a chave estrangeira no lado que representa o “N”, é possível
identificar que não é possível que um aluno seja matriculado em mais de
um curso, pois o aluno é identificado pela sua chave primária, uma chave
primária não pode ser repetida, e caso seja definida outra chave, o registro
não será mais o mesmo.
Impossibilidade de se representar o N : N
A mesma ideia vale para representar a chave estrangeira na tabela
“CURSOS”, pois só seria possível representar o aluno frequentando
vários cursos e não um curso tendo vários alunos.
Tabela de junção
A solução para este problema, é a criação de uma tabela que possibilite
representar a relação entre os alunos e os cursos, esta tabela é
chamada de tabela de junção.
Como regra, representamos sempre como “N” a
cardinalidade máxima entre a tabela que deu
origem a junção e a tabela de junção.
É recomendado que para a cardinalidade
mínima, seja definido “0”, pois assim, tanto o
curso quanto os alunos podem ser
cadastrados sem que exista a necessidade do
relacionamento entre eles.

0 0
Nas tabelas de origem a cardinalidade máxima deve ser
“1”, enquanto a mínima será de 1 também, pois, neste
exemplo, seria necessário selecionar tanto um aluno
quanto um curso existente antes de gravar uma
informação na tabela ALUNO_CURSO.

1 0 0 1
Definindo as chaves na tabela de junção
Uma das formas de representar as chaves na tabela de junção, é
definindo uma chave primária para esta tabela, além de uma chave
estrangeira que represente cada relacionamento existente com as
tabelas de origem.

1 0 0 1
Chave primária independente
Esta forma de representar os relacionamento
da tabela de junção não é valida para nosso
exemplo, porque ao definir uma chave
primária independente das tabelas de
origem, abdicamos o controle do número de
vezes que um registro de aluno pode ser
relacionado a um curso. Note na imagem ao
lado, que podemos relacionar um aluno mais
de uma vez a um curso, e neste exemplo a
repetição não traz nenhuma vantagem, pois
um alunos só precisa ser relacionado ao
curso uma única vez.
Chave primária independente
Esta forma de representar os
relacionamento entre as tabelas de
origem e a tabela de junção é
recomendada quando existe a
necessidade de representar mais de uma
vez a um mesmo relacionamento, como
por exemplo em no cupom fiscal que um
caixa de supermercado, onde um
produto pode ser representado em uma
venda diversas vezes.
Definindo as chaves na tabela de junção
Outra forma de representar as chaves neste relacionamento, e a mais
correta para esta situação, é defini-las como primárias e estrangeiras ao
mesmo tempo

1 0 0 1
Chave primária dependente
Ao definir as chaves como primárias e estrangeiras ao mesmo tempo,
ambas serão obrigatórias e não devem ser auto incrementáveis, pois é
necessário que estas estejam ligadas a um registro existente. Neste tipo
de relacionamento é impossível representar a relação entre aluno e
curso mais de uma vez, pois como temos uma chave composta por dois
campos, e a inserção de valores repetidos em chave primária não pode
ocorrer.
Identificando o relacionamento
Imagine um sistema de uma clinica médica, onde os
usuários do sistema podem ser médicos ou
funcionários.
Ao cadastrar qualquer usuário que não seja um médico,
teremos informações que nunca serão preenchidas.
Identificando cardinalidade
Uma forma de evitar esta situação é criando uma nova tabela que
contenha informações relevantes apenas aos médicos cadastrados. E
relacionamos esta tabela com a tabela USUARIOS, assim um médico
pode ser um usuário do sistema, e um usuário não tem a necessidade
de ser médico.
Um registro de usuário pode ser
representado no máximo quantas vezes na
tabela médicos?
Um usuário pode ser representado no
mínimo quantas vezes na tabela médicos?
Um usuário cadastrado precisa ser médico?
Um registro de médico pode estar associado
a no máximo quantos usuários?
Um registro de médico está relacionado a no
mínimo quantos usuários? Um usuário
precisa existir para criar um registro de
médico?
Tipo de relacionamento: 1 : 1
Este tipo de relacionamento ocorre quando só podemos associar um
único registro de uma tabela a um outro de outra tabela. É importante
definir a tabela de origem, neste exemplo a tabela usuários, pois a
chave primária na tabela relacionada será a mesma da tabela de
origem e será definida como chave estrangeira também para que seja
garantida a integridade.

Obs: Neste exemplo o campo usu_cod na

tabela MEDICOS não pode ser auto
incremento.
Tipo de relacionamento: 1 : 1
A cardinalidade mínima, define que para o médico ser cadastrado é
necessário que exista um registro na tabela USUARIOS para cadastrar
um na tabela MEDICOS.
ATIVIDADES
Elabore o diagrama de relacionamentos e o dicionário de dados para cada caso abaixo:
1. Uma universidade tem muitos estudantes e um estudante pode se matricular em
apenas uma universidade.
2. Uma aeronave pode ter muitos passageiros, mas um passageiro só pode estar em um
voo de cada vez.
3. Uma nação possui vários estados, e um estado, muitas cidades. Um estado só poderá
estar vinculado a uma nação e uma cidade só poderá estar vinculado a um estado.
4. Um encontro de eventos esportivos pode ter muitos competidores e um competidor
pode participar de mais de um evento.
5. Um paciente pode ter muitos médicos e um médico muitos pacientes.
6. Um aluno faz parte de uma turma onde pode frequentar mais de uma disciplina e uma
mesma disciplina pode ter muitos alunos.