Prévia do material em texto

Conceitos em 
Banco de Dados
Material Teórico
Responsável pelo Conteúdo:
Prof. Ms. Rodrigo da Rosa
Revisão Técnica:
Prof. Me. Douglas Almendro
Revisão Textual:
Profa. Esp. Kelciane da Rocha Campos
Modelos: Relacional e Entidade-Relacionamento
• Modelo Relacional de Dados
• Chaves Primária e Estrangeira
• Modelo Entidade-Relacionamento (MER)
• Grau de Relacionamentos
• Cardinalidade – Notação de Chen
 · O aluno deverá, ao final deste módulo, reconhecer a importância da 
modelagem de dados relacional e Entidade-Relacionamento em um 
projeto de banco de dados. Além disso, deverá ser capaz de elaborar 
tabelas e diagramas relacionais.
OBJETIVO DE APRENDIZADO
Modelos: Relacional e 
Entidade-Relacionamento
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja uma maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como o seu “momento do estudo”.
Procure se alimentar e se hidratar quando for estudar, lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo.
No material de cada Unidade, há leituras indicadas. Entre elas: artigos científicos, livros, vídeos e 
sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você também 
encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão sua 
interpretação e auxiliarão no pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discussão, 
pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o contato 
com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar, lembre-se de que uma 
Não se esqueça 
de se alimentar 
e se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Modelos: Relacional e Entidade-Relacionamento
Modelo Relacional de Dados
O modelo relacional de dados é o modelo mais utilizado hoje em dia e é por 
esta razão que iremos estudá-lo com mais profundidade. Foi criado em 1970 pelo 
matemático Edgar Frank Codd. Codd baseou-se na teoria dos conjuntos, que é um 
ramo da matemática, para propor este modelo que descreve a organização dos 
dados por meio de relações, por vezes chamadas de tabelas, que possuem linhas 
e colunas.
Importante!
Um banco de dados relacional consiste em uma coleção de tabelas, cada uma com um 
nome único atribuído. Uma linha em uma tabela representa uma relação entre um 
conjunto de valores (SILBERSCHATZ; KORTH; SUDARSHAN, 2012).
Trocando ideias...
O quadro a seguir apresenta as características das tabelas relacionais, conforme 
Rob e Coronel (2011):
Quadro 1 – Características das tabelas relacionais (ROB; CORONEL, 2011)
1 A tabela é vista como uma estrutura bidimensional composta de linhas e colunas.
2 Cada linha, chamada de tupla, representa uma única ocorrência de entidade no interior do conjunto de entidades.
3 Cada coluna de tabela representa um atributo e possui um nome diferente.
4 Cada intersecção entre linha e coluna representa um valor único.
5 Todos os valores em uma coluna devem se adequar a um mesmo formato.
6 Cada coluna possui uma faixa específica de valores conhecida como domínio de atributos.
7 A ordem das linhas e das colunas é insignificante para o SGBD.
8 Cada tabela deve apresentar um atributo ou uma combinação de atributos que identifique exclusivamente cada linha.
Para facilitar nosso entendimento a respeito destas características, vamos tomar 
a tabela a seguir como exemplo:
Tabela cliente
CLI_COD CLI_NOME CLI_END CLI_CID CLI_UF CLI_CEP CLI_TEL
100090 João Pedro Rua x, 1 São Paulo SP 03748-987 1139840987
100091 Rua y, 92 Lapa SP 03748-987 11984567586
100092 Jonas Barbosa Rua z, 39 São Paulo SP 04987-978 11977893846
• Item 1: a tabela cliente é bidimensional, composta de 3 linhas e 7 colunas;
• Item 2: cada linha da tabela cliente representa uma única ocorrência de 
entidade no interior do conjunto de entidades. Isso porque não existem linhas 
(tuplas) repetidas;
• Item 3: cada coluna possui um nome diferente umas das outras;
8
9
• Item 4: cada intersecção entre linhas e colunas representa um valor único. 
Tal intersecção é o cruzamento entre linha e coluna, muitas vezes chamado de 
célula. Perceba que não existe em qualquer cruzamento valores incoerentes, 
ou seja, na coluna CLI_CID não iremos encontrar dados pertencentes à coluna 
CLI_UF, por exemplo;
• Item 5: todos os valores em uma coluna estão adequados ao mesmo formato, 
pois em CLI_COD o formato dos dados deve ser numérico, enquanto que em 
CLI_NOME o formato dos dados deve ser do tipo string;
• Item 6: a faixa de valores específica é definida para cada coluna no momento 
da criação da tabela. Significa, por exemplo, que a coluna CLI_COD poderá 
conter, no máximo, 6 números, enquanto que em UF somente 2 caracteres;
• Item 7: a ordem de cada linha é insignificante para o SGBD. Caso a ordem 
das linhas fosse alterada, permaneceria a mesma organização e registro 
dos dados;
• Item 8: cada tabela deve apresentar um atributo ou uma combinação de 
atributos que identifique exclusivamente cada linha. Isto ocorre com a coluna 
CLI_COD, pois na medida em que novas linhas forem sendo inseridas na 
tabela, não ocorrerá repetição de dado ali. Isto não acontece nas demais, já 
que em CLI_NOME, por exemplo, embora não existam dados repetidos, há a 
possibilidade de ser cadastrado outro cliente chamado Ricardo Toledo.
Chaves Primária e Estrangeira
Já vimos que o item 8 da tabela de características de tabelas relacionais nos diz 
que cada tabela deve apresentar um atributo ou uma combinação de atributos que 
identifique exclusivamente cada linha.
Importante!
A chave primária é este atributo, ou coluna, que faz uma linha ser única em uma tabela. 
Esta coluna não terá, em hipótese alguma, um valor repetido.
Você Sabia?
O conceito de chave primária e chave estrangeira são fundamentais para que 
sejam estabelecidos relacionamentos entre diversas tabelas do banco de dados de 
maneira consistente.
As duas características principais de uma chave primária são:
1. não é permitido que haja, nesta coluna, valores iguais;
2. não é permitido que haja, nesta coluna, valor nulo. Um campo com valor 
nulo é um campo sem qualquer valor escrito.
9
UNIDADE Modelos: Relacional e Entidade-Relacionamento
O modelo relacional a seguir apresenta duas tabelas, cliente e dependente. Sabemos que a 
chave primária na tabela cliente é CLI_COD. Qual é a chave primária na tabela dependente?Ex
pl
or
Modelo relacional – tabelas cliente e dependente
Tabela Cliente
Tabela Dependente
CLI_COD CLI_NOME CLI_END CLI_CID CLI_UF CLI_CEP CLI_TEL
100090 João Pedro Rua x, 1 São Paulo SP 03748-987 1139840987
100091 Ricardo Toledo Rua y, 92 Lapa SP 04987-978 11984567586
100092 Jonas Barbosa Rua z, 39 São Paulo SP 02983-987 11977893846
DEP_COD DEP_NOME DEP_FONE CLI_COD
900000 Rafael Toledo 11987997364 100091
900001 Frank Barbosa 11957466378 100092
900002 Richard Barbosa 11946578992 100092
Ao nos utilizarmos do conceito aprendido sobre chave primária, fica claro que 
ela é apresentada na tabela dependente como DEP_COD.
É muito comum imaginar que a chave primária da tabela dependente é CLI_
COD, a exemplo da tabela cliente, uma vezque esta coluna aparece nas duas 
tabelas. Entretanto, perceba que na tabela dependente a coluna CLI_COD possui 
valores repetidos (2ª e 3ª linhas).
Mesmo que não houvesse valores repetidos apresentados em CLI_COD na tabela 
dependente, sabemos que haveria a possibilidade de isso acontecer, pois um cliente pode 
ter mais do que um dependente cadastrado no banco de dados.
Ex
pl
or
Agora que sabemos o que é uma chave primária, precisamos definir o que é uma 
chave estrangeira.
Importante!
Segundo Damas (2007), a chave estrangeira é a coluna ou conjunto de colunas de uma 
relação que é chave primária em outra relação.
Trocando ideias...
10
11
Podemos perceber por esta definição que o conceito de chave estrangeira 
está diretamente associado ao conceito de chave primária. Na verdade, a chave 
estrangeira só existe porque existe também uma chave primária na relação.
Vamos, então, a partir das tabelas a seguir, entender melhor este conceito.
Tabelas cliente e dependente sem a existência de relacionamento
Tabela Cliente
Tabela Dependente
CLI_COD CLI_NOME CLI_END CLI_CID CLI_UF CLI_CEP CLI_TEL
100090 João Pedro Rua x, 1 São Paulo SP 03748-987 1139840987
100091 Ricardo Toledo Rua y, 92 Lapa SP 04987-978 11984567586
100092 Jonas Barbosa Rua z, 39 São Paulo SP 02983-987 11977893846
DEP_COD DEP_NOME DEP_FONE
900000 Rafael Toledo 11987997364
900001 Frank Barbosa 11957466378
900002 Richard Barbosa 11946578992
Dadas as tabelas cliente e dependente, podemos perceber que, exceto pelo 
sobrenome, não existe a possibilidade de sabermos quais clientes possuem 
dependentes e quais são eles. Isto somente é possível quando estabelecemos o 
relacionamento entre as tabelas a partir da coluna que é chave primária em cliente 
(CLI_COD). Esta coluna deve ser inserida no contexto da tabela dependente para 
que tenhamos este entendimento.
Relacionamento entre as tabelas cliente e dependente
Tabela Cliente
Tabela Dependente
CLI_COD CLI_NOME CLI_END CLI_CID CLI_UF CLI_CEP CLI_TEL
100090 João Pedro Rua x, 1 São Paulo SP 03748-987 1139840987
100091 Ricardo Toledo Rua y, 92 Lapa SP 04987-978 11984567586
100092 Jonas Barbosa Rua z, 39 São Paulo SP 02983-987 11977893846
DEP_COD DEP_NOME DEP_FONE CLI_COD
900000 Rafael Toledo 11987997364 100091
900001 Frank Barbosa 11957466378 100092
900002 Richard Barbosa 11946578992 100092
11
UNIDADE Modelos: Relacional e Entidade-Relacionamento
Deste modo, podemos dizer que a CLI_COD é chave primária em cliente e é cha-
ve estrangeira em dependente, pois este é o elo, a ligação, entre estas duas tabelas.
As características da chave estrangeira não podem ser confundidas com as 
características da chave primária, pois:
1. na coluna que é chave estrangeira, é permitido haver valores repetidos. Um 
cliente pode ter muitos dependentes nesta tabela;
2. esta coluna pode conter valores nulos.
Modelo Entidade-Relacionamento (MER)
O modelo E-R (MER) foi idealizado por Peter Pin-Shan Chen, 1976. Trata-se de 
uma representação gráfica (às vezes chamado de Diagrama E-R) baseada em uma 
percepção do mundo que apresenta como as entidades envolvidas relacionam-se 
entre si. Os principais elementos de um MER são:
• Entidades: ao lembrarmos o modelo relacional de dados, as entidades 
estão associadas à representação das tabelas. Elas servem para descrever 
“algo” existente na realidade e utiliza-se um substantivo para nomeá-la (por 
exemplo: CLIENTE, DEPENDENTE, CONTA, DEPARTAMENTO, ALUNO). 
Apresentam lugares, pessoas, objetos, fatos, dentre outros. São representadas 
por um retângulo e seu nome (único) no singular deverá estar contido nele. A 
figura a seguir apresenta exemplos de entidades:
Figura 1 – Exemplo de três entidades distintas
A entidade ALUNO descreve todos os alunos de uma determinada instituição e 
não somente um deles. Assim acontece com qualquer outra entidade.
• Atributos: são elementos que descrevem as entidades, ou seja, as características 
delas. Associados à ideia do modelo relacional, os atributos seriam as colunas 
das tabelas. São representados no MER por elipses, conforme figura a seguir:
Figura 2 – Exemplo de três atributos distintos
12
13
Os atributos, na representação do diagrama, deverão estar sempre ligados a 
uma (e única) entidade, conforme abaixo:
Figura 3 – Entidade CLIENTE e seus atributos
Neste arranjo, podemos perceber que o atributo CLI_COD está em destaque. 
Isso porque se trata da chave primária desta entidade. Seria possível destacar este 
atributo também por meio de um sublinhado, por exemplo.
• Relacionamentos: são elementos que servem para associar uma entidade 
a outra(s).
Importante!
Essa conexão lógica entre duas ou mais entidades defi nimos como relacionamento, 
que é representado em um diagrama E-R por meio de uma linha unindo as entidades 
associadas, contendo ainda um losango com o nome do relacionamento (um verbo 
fl exionado) ao centro (MACHADO, 2008).
Trocando ideias...
Um exemplo de relacionamento está na figura a seguir:
Figura 4 – Exemplo de três relacionamentos distintos
Perceba que utilizamos um verbo apenas, que normalmente indica uma ação ou 
fato que acontece entre as entidades, embora existam duas ações, uma que ocorre 
da direita para a esquerda e outra que ocorre da esquerda para a direita.
Figura 5 – Ação em ambos os sentidos em um relacionamento.
No caso da figura anterior, um professor leciona disciplina(s) e uma disciplina é 
lecionada por professor(es).
13
UNIDADE Modelos: Relacional e Entidade-Relacionamento
Um diagrama simples que poderíamos elaborar a partir da descrição destes três 
elementos vistos até aqui seria o diagrama a seguir:
Figura 6 – Modelo E-R simples entre duas entidades
Grau de Relacionamentos
O grau de um relacionamento diz respeito à quantidade de entidades envolvidas 
em uma relação. Basicamente são três:
• Binário: são os mais comuns e ocorrem quando existem duas entidades 
conectadas a um relacionamento.
Figura 7 – Relacionamento binário
No exemplo acima, pretendemos descrever que informações sobre quais funcio-
nários pertencem a quais empresas.
Há outro tipo de relacionamento binário (ou relacionamento unário), porém não 
é tão comum quanto o apresentado, chamado de relacionamento binário recursivo. 
Neste caso, uma entidade está relacionada com ela mesma.
14
15
Figura 8 – Relacionamento binário recursivo
Para o exemplo anterior, a leitura que se faz é que um funcionário pode ser 
gerenciado por outro funcionário, uma vez que um gerente também é funcionário 
de uma empresa.
• Ternário: ocorre quando existem três entidades conectadas a um relacionamento.
Figura 9 – Relacionamento ternário
Neste exemplo, estamos interessados em saber em quais projetos de uma 
determinada empresa trabalha um determinado funcionário.
• E-nário: a partir de quatro entidades conectadas em um relacionamento, 
podemos dizer que temos um relacionamento e-nário. É bastante incomum, 
porém existe a possibilidade de ocorrer.
Figura 10 – Relacionamento e-nário
Nosso interesse, neste exemplo, é informar quais são os funcionários, as empre-
sas, as máquinas e os patrocinadores que trabalham em um determinado projeto.
15
UNIDADE Modelos: Relacional e Entidade-Relacionamento
Um projeto de banco de dados é composto por um conjunto de relacionamentos 
e não somente por um deles. Um exemplo bastante simples é o da figura a seguir:
Figura11 – Exemplo simples de relacionamentos em um projeto de banco de dados
É claro que ainda faltam muitos elementos em um projeto de banco de dados 
como o apresentado na figura anterior, como os atributos de cada entidade e a 
cardinalidade dos relacionamentos. De qualquer maneira, serve para termos ideia 
de como são elaborados.
Cardinalidade – Notação de Chen
A cardinalidade descreve o número de ocorrências que podem estar associadas 
a cada linha de registro de outra entidade.
Os valores de cardinalidade podem ser de dois tipos: um ou muitos. São estas as 
possíveis em um modelo de dados:
• Relacionamentos 1:1 (lê-se um paraum): são, de certa forma, raros. 
Utilizados quando para cada ocorrência da entidade A existe no máximo uma 
ocorrência da entidade B e para cada ocorrência da entidade B existe no 
máximo uma ocorrência da entidade A.
Figura 12 – Relacionamento 1:1
Para se alcançar o valor da cardinalidade de cada relacionamento, devemos 
analisar as associações em cada um dos dois sentidos da relação. No caso da figura 
acima, podemos notar que:
1. Esquerda para a direita: cada departamento (1) pode ser gerenciado por 
apenas um funcionário (1) da empresa;
16
17
2. Direita para a esquerda: cada funcionário/gerente (1) pode gerenciar ape-
nas um departamento (1) da empresa.
Esta situação é bastante comum no mundo real.
Como nos dois sentidos temos 1 para 1, dizemos que o relacionamento é 1:1.
• Relacionamentos 1:N (lê-se um para muitos): utilizados quando para cada 
ocorrência da entidade A existem duas ou mais ocorrências (muitas) da entidade 
B, e para cada ocorrência da entidade B existe no máximo uma ocorrência da 
entidade A.
Figura 13 – Relacionamento 1:N
No caso da figura acima, podemos notar que:
1. Esquerda para a direita: em cada departamento (1) pode haver muitos 
funcionários (N) da empresa trabalhando;
2. Direita para a esquerda: cada funcionário (1) pode trabalhar em apenas 
um departamento (1) da empresa.
Como em um sentido temos 1 para 1 e no outro temos 1 para N, dizemos que 
o relacionamento é 1:N.
• Relacionamentos N:N (lê-se muitos para muitos): utilizados quando para 
cada ocorrência da entidade A existem duas ou mais ocorrências (muitas) 
da entidade B, e para cada ocorrência da entidade B existem duas ou mais 
ocorrências (muitas) da entidade A.
Figura 14 – Relacionamento N:N
No caso da figura acima, podemos notar que:
1. Esquerda para a direita: cada professor (1) pode lecionar muitas disci-
plinas (N);
2. Direita para a esquerda: cada disciplina (N) pode ser lecionada por muitos 
professores (N).
Como nos dois sentidos temos N para N, dizemos que o relacionamento é N:N.
17
UNIDADE Modelos: Relacional e Entidade-Relacionamento
No que diz respeito a cardinalidade, temos as seguintes possibilidades:
=
= OU
=
Figura 15 – Cardinalidade
Um exemplo simples de modelo de dados relacional pode ser observado na 
figura a seguir:
Figura 16 – Modelo simples de modelo E-R
18
19
Podemos perceber que há neste modelo:
1. quatro entidades;
2. atributos associados a cada entidade. Por se tratar de um exemplo, elencamos 
alguns possíveis atributos. Em um modelo completo, teríamos muito mais 
para cada uma das entidades;
3. três relacionamentos;
4. uma chave primária em cada entidade;
5. uma chave estrangeira na entidade FUNCIONÁRIO;
6. uma chave estrangeira na entidade DEPENDENTE;
7. duas chaves estrangeiras no relacionamento CONTRATA;
Importante!
Se a cardinalidade for N:N, o relacionamento irá possuir as chaves das entidades 
associadas a ele (serão chaves estrangeiras). Se a cardinalidade for 1:N, a entidade 
que tiver o N irá possui a chave da entidade que tiver o 1 (será chave estrangeira). Se 
a cardinalidade for 1:1, qualquer uma das entidades poderá possuir a chave da outra 
entidade (será chave estrangeira).
Você Sabia?
19
UNIDADE Modelos: Relacional e Entidade-Relacionamento
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Oracle
http://www.oracle.com.br
SIS 4
http://sis4.com/brModelo/
 Vídeos
Curso MySQL #14 – Modelo relacional
https://youtu.be/8fxKJWJcRTw
 Leitura
Análise da Produção Monográfica Discente
SILVEIRA, André da; RIBEIRO, Vinicius Gadis. Análise da produção monográfica 
discente: um estudo de caso em uma instituição de ensino superior do Rio Grande 
do Sul.
https://goo.gl/X7tUlU
20
21
Referências
DAMAS, Luís. SQL – Structured Query Language. 6ª ed. Rio de Janeiro: LTC, 
2007. 384 p.
MACHADO, Felipe Nery Rodrigues. Projeto e implementação de banco de 
dados. 2ª ed. São Paulo: Érica, 2008.
ROB, Peter; CORONEL, Carlos. Sistemas de banco de dados – projeto, 
implementação e administração. 8ª ed. São Paulo: Cengage Learning, 2011. 711 p.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de 
banco de dados. 6ª ed. Elsevier, 2012. 904 p.
21