CONVERSA INICIAL

Fundamentos de Banco de Dados

O tema Banco de Dados é um conhecimento que deve ser adquirido pelos
profissionais da área de tecnologia, pois basicamente todas as informações, de
uma forma ou outra, encontram-se armazenadas em Bancos de Dados.
Neste estudo, abordaremos os conceitos e as técnicas que você precisará
para ingressar no universo de Banco de Dados Relacional, abrangendo desde
os aspectos de modelagem até a utilização da linguagem Structured Query
Language (SQL) para a manipulação das informações.
Apresentaremos e discutiremos tópicos que o ajudarão a desenvolver
habilidades para a interpretação e análise de informações, ingressando, assim,
em um processo de reflexão sobre o desenvolvimento de um Banco de Dados e
as melhores práticas de atuação como profissional da área.
Aliando a teoria e a prática, apoiaremos você em cada passo desse
caminho, acompanhando-o no processo de construção de uma base de dados e
BANCO DE DADOS discutindo sobre as melhores abordagens, metodologias existentes, suas formas

AULA 1 de aplicação e implementação em soluções práticas no desenvolvimento.

Nesta primeira etapa, apresentaremos os principais conceitos sobre o
Sistema Gerenciador de Banco de Dados (SGBD), os tipos de modelos de
dados, as etapas da modelagem de dados, a construção do Modelo Entidade-
Relacionamento (MER) e a influência da cardinalidade exercida sobre o modelo
de dados.
Vale salientar que desenvolver uma forte base conceitual sobre Banco de
Dados servirá de suporte fundamental na construção prática de projetos de
Banco de Dados. São conceitos que você deverá manter em sua memória, pois
com certeza os utilizará frequentemente no dia a dia de sua profissão.
Bons estudos e sucesso!

TEMA 1 – CONCEITOS, DEFINIÇÕES E MODELOS

Em todas as organizações existe a necessidade do armazenamento de

informações. Além de uma forma adequada para definir o armazenamento
dessas informações, os usuários realizam consultas em determinado conjunto
de dados, atualizam ou modificam a estrutura dos dados e eliminam informações
não necessárias.
Prof. Ricardo Sonaglio Albano e Profª. Silvie Guedes Albano
2
 Também é importante ressaltar que as empresas se baseiam nas 1.2 Banco de Dados (BD)
informações para a tomada de decisões e que, por esse motivo, a informação
tem grande importância e valor para as organizações. Existem diversos conceitos utilizados para definir um Banco de Dados.

Sendo assim, a informação, além de ser precisa, deve ser cada vez mais Vejamos alguns deles:

ágil e instantânea. Essa busca pela informação tem ajudado no desenvolvimento • Coleção de dados persistentes usados pelos sistemas de aplicação de
dos chamados sistemas de processamento de informações. determinada empresa;
• Conjunto de dados inter-relacionados representando informações de um
1.1 Dado x informação
domínio específico;

É importante destacar a diferença entre dado e informação, pois no • Sistema que registra e mantém dados baseados em computador;

cotidiano é comum serem utilizados como sinônimos. Porém, quando se trata de • Sistema computadorizado de armazenamento de registros, cujo objetivo
computadores, é importante que tenhamos a diferença bem definida entre esses é armazenar informações e permitir aos usuários buscar e atualizar essas
dois termos. informações quando necessário;
Para exemplificarmos essa diferença de forma simples, vamos imaginar • Todo o conjunto de dados que segue determinado modelo de dados.
uma simples fórmula matemática de adição. Ela é composta por dados que Resumindo, um Banco de Dados (BD) é o local onde são armazenados
serão processados pelo computador. O resultado obtido é a informação. os dados de uma aplicação.
Vejamos: Exemplo de um Banco de Dados: sistema de delivery, em que a empresa
deseja armazenar as informações sobre os clientes, produtos, entregadores,
Figura 1 – Dado x informação
restaurantes, entre outros. Cada um desses elementos serão as entidades
básicas sobre as quais a aplicação de delivery precisará registrar informações.

1.2.1 Modelos de Banco de Dados

Fonte: Albano; Albano, 2022. É a representação do Banco de Dados, demonstrando a relação existente
entre os dados.
Perceba que a fórmula apresentada na imagem acima possui três dados:
Os modelos de Banco de Dados são:
dois números e a operação a ser realizada (símbolo da adição).
À medida que os dados são organizados ou agrupados de uma forma • Hierárquico;
significativa, tornam-se uma informação. Portanto, podemos afirmar que a • Rede;
informação é um conjunto de fatos organizados de tal forma que adquirem um • Orientado a objetos;
valor adicional além do valor do dado em si. Dessa forma, devido ao seu grande • Relacional;
valor, necessitam ser armazenadas de forma apropriada, permitindo o rápido • NoSQL ou não-relacional.
acesso e, ao mesmo tempo, garantindo a integridade e segurança desses fatos
organizados. Para isso, existe o Banco de Dados que trataremos logo a seguir. 1.2.1.1 Modelo hierárquico

O Sistema de Banco de Dados Hierárquico (Hierarquical Database

System – HDS) surgiu na década de 1960 com a primeira linguagem de Banco

3 4
 de Dados, conhecida como DL/I, desenvolvida pela IBM e a North American definição do comportamento de cada um, cuja manipulação é feita por meio de
Aviation. métodos. Não apresenta a obrigatoriedade referente às limitações quanto aos
Nesse modelo os dados são armazenados em estruturas no formato de tipos de dados característicos de um SGBD e as linguagens de consulta.
árvore. Cada estrutura de dados parte de um nodo raiz (nó) e se ramifica criando
relações pai-filho com outras classes de dados, gerando relações de um para
1.2.1.4 Modelo relacional
muitos elementos.
O Modelo de Dados Relacional (Relational Data Model – RDM) foi criado
A desvantagem está na rigidez da estrutura de dados, em que, no caso
na década de 1970 por um pesquisador da IBM, Dr. Edgar Frank Codd, sendo
de alterações da classe principal ou de classes dependentes, obrigaria que fosse
descrito no artigo “Relational Model of Data for Large Shared Data Banks”. Tal
refeito todo o Banco de Dados.
modelo é, inclusive, considerado o primeiro modelo de dados descrito

1.2.1.2 Modelo de rede teoricamente e tinha por objetivo desenvolver uma representação mais simples
dos dados, por meio de um modelo matemático de conjuntos de tabelas inter-
Também conhecido como Sistema de Banco de Dados em Rede (Network relacionadas.
Database System – NDS), esse modelo surgiu entre as décadas de 1960 e 1970 Esse modelo era bastante inovador, pois deixava de lado todos os
como uma extensão do modelo hierárquico, adicionando recursos para criação conceitos anteriores e apresentava uma visão totalmente nova com estruturas
de mais de uma relação pai-filho e estabelecendo relações entre os seus mais flexíveis, tanto na forma de representação das relações entre os dados
elementos. como também no processo de manutenção da estrutura.
Esse modelo possui a vantagem de uma pesquisa mais rápida e flexível, O Banco de Dados relacional está estruturado em relações (tabelas)
pois não depende de um único nó raiz como vetor de inicialização da pesquisa. relacionadas entre si, relações essas que possuem atributos. Tais conceitos
Apesar disso, o modelo de rede ainda apresenta os problemas relatados no serão estudados em um próximo momento.
modelo anterior no que se refere à relação ao projeto de estrutura do modelo Vale salientar que, nesse estudo, adotaremos o Banco de Dados relacional.
hierárquico. Qualquer alteração feita em uma classe de dados implicaria na
criação de uma nova estrutura para suportar àquela alteração.
1.2.1.5 Modelo NoSQL ou modelo não-relacional
Nesse caso, as relações entre os registros são feitas por meio de
Atualmente, além do modelo de Banco de Dados relacional, existem
ponteiros que armazenam endereços de memória, indicando os endereços em
também os Bancos de Dados denominados NoSQL, que armazenam e
que os dados realmente se encontram armazenados.
manipulam as informações de uma forma diferente, sendo utilizados de forma
O modelo em rede trabalha com registros vinculados uns aos outros,
mais flexível no acesso e manipulação de grandes volumes de dados e em
gerando conjuntos de dados.
situações em que a informação é apresentada de forma não estruturada ou

1.2.1.3 Modelo orientado a objetos semiestruturada.

Alguns exemplos de aplicação desse tipo de modelo são: redes sociais,
Incorpora as características da metodologia de desenvolvimento streaming, games, Internet of Things (IoT), Big Data, entre outros.
orientado a objetos com os conceitos de Sistema Gerenciador de Banco de Esse tipo de modelo apresenta as seguintes características:
Dados (SGBD).
• Flexibilidade: caracteriza-se pela ausência de esquemas padronizados de
Nesse modelo de dados, a informação é organizada e,
definição de estrutura de dados, permitindo que os dados sejam
consequentemente, armazenada sob a forma de objetos, inclusive com a
armazenados de forma mais livre, podendo manipular, de forma mais

5 6
 simples, qualquer formato de dados. Dessa forma, possibilita-se não só Como objetivos, o SGBD deve:
um desenvolvimento mais rápido, mas também uma melhor performance
• Ocultar dos usuários os detalhes mais técnicos de funcionamento do
no tratamento de volumes muito grandes de requisições, gerando
Banco de Dados, também conhecido como abstração de dados;
respostas mais rápidas;
• Prover independência de dados às aplicações (estrutura física de
• Escalabilidade: são projetados para expandir seus recursos de forma
armazenamento e a estratégia de acesso).
horizontal, isto é, adicionando máquinas comuns (nodes) a estrutura já
Destacamos alguns SGBDs amplamente utilizados: DB2 (IBM), Microsoft
disponível, bem mais baratas que os caros servidores.
SQL Server, Oracle, MySQL, PostgreSQL, entre outros.
Consequentemente, expande-se sua capacidade para suportar o
aumento de tráfego, sua disponibilidade no recebimento de requisições e
2.1 Características de um SGBD
aumenta a performance em tempo de execução e resposta;
• Alta performance: focado na otimização de modelos de dados e padrões Um SGBD deve ter algumas características que são essenciais para o seu
de acesso, gerando maior performance em comparação a outros modelos funcionamento, tais como:
de dados.
• Controle de redundância: consiste no armazenamento de uma mesma
No NoSQL existem quatro tipos principais de modelos de dados: chave- informação em locais diferentes, provocando duplicidade e possíveis
valor, documento, gráfico e família de colunas. inconsistências. Em um Banco de Dados, as informações encontram-se
Vale salientar que existem situações em que sua aplicação não é armazenadas em um único local, não existindo duplicação dos dados;
considerada a mais adequada e, dessa forma, o Banco de Dados relacional é a • Compartilhamento dos dados e concorrência: o SGBD deve incluir o
melhor alternativa. controle de concorrência no acesso aos dados, possibilitando o
compartilhamento dos dados e garantindo que, se vários usuários
TEMA 2 – SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD) E
realizarem operações de atualização sobre um mesmo conjunto de
APLICAÇÕES DE BANCO DE DADOS dados, o resultado dessas operações será correto;
• Controle de acesso: o SGDB deve disponibilizar recursos para o
Entre os dados armazenados fisicamente no disco rígido e os usuários do
gerenciamento de acesso dos usuários, definindo permissões, como, por
sistema, que manipulam esses dados, existe uma camada de software
exemplo, um usuário poderá ter acesso total, enquanto outro usuário terá
conhecida como Sistema Gerenciador de Banco de Dados (SGBD).
apenas acesso de leitura de dados;
O Sistema Gerenciador de Bancos de Dados é a interface entre os dados
• Controle de transações: uma transação é um conjunto de operações
de baixo nível, armazenados em um Banco de Dados, e os usuários e as
sobre o Banco de Dados que devem ser executadas integralmente e sem
aplicações, que desejam acessar e manipular esses dados.
falhas ou interrupções;
O sistema de Banco de Dados é um sistema de manutenção de registros
• Possibilidade de múltiplas interfaces: um SGBD pode ser acessado por
por computador e, para tanto, possui diversos recursos à disposição do usuário,
diversas interfaces diferentes (aplicação WEB, aplicativo mobile, entre
possibilitando a realização de várias operações, como por exemplo:
outros). Logo, o SGBD deve garantir que todos tenham acesso aos dados
• Adição, remoção e atualização de tabelas no Banco de Dados; da mesma forma;
• Inserção de novos dados; • Restrições de integridade: deve garantir que as regras de integridades
• Recuperação, atualização e exclusão de dados. definidas no momento da criação do Banco de Dados sejam aplicadas

7 8
 corretamente. Por exemplo, a data de nascimento não pode ser maior que 1. Hardwares: dispositivos em que as informações são armazenadas
a data atual; fisicamente;
• Backup e recuperação de dados: garantir o backup e a restauração de 2. SGBD: software que permite o acesso dos usuários às informações
dados é tarefa essencial para qualquer SGBD, mesmo que as falhas não armazenadas no Banco de Dados;
sejam originadas pelo próprio SGBD, mas sim falhas de software ou 3. Aplicações: softwares que realizam requisições para o SGBD com a
hardware; finalidade de interagir com as informações do Banco de Dados;
• Independência de dados: os dados armazenados no Banco de Dados 4. Usuários: estão divididos em três categorias:
devem ser totalmente independentes de qualquer aplicação que o acesse. o Programador de aplicações – responsável pela definição dos
Inclusive, os aplicativos não possuem a descrição real de como os dados programas de aplicação que utilizam o Banco de Dados;
estão fisicamente armazenados; o Administrador de Banco de Dados ou DBA – responsável pelo controle
• Eliminação de inconsistências: trata-se do armazenamento da informação e gerenciamento;
em um único local com acesso descentralizado, sendo compartilhado por o Usuário final – interage com o sistema a partir de um computador
vários sistemas, mantendo uma informação confiável. A inconsistência conectado ao Banco de Dados.
ocorre quando um mesmo campo tem valores diferentes em sistemas
Figura 2 – Representação de um sistema de Banco de Dados
diferentes;
• Padronização dos dados: permite que os atributos sejam definidos
baseando-se em um formato de armazenamento predeterminado. Por
exemplo, os atributos de data armazenados no formato “aaaa/mm/dd”.

2.2 Pontos de atenção em um SGBD

• Sem dispositivos de controle adequados, a segurança pode estar em

risco. Por exemplo, no caso de acesso não autorizado aos dados;
• A integridade das informações pode ser comprometida se não houver
mecanismos de controle. Por exemplo, no caso de manipulação
concorrente de dados;
Fonte: Albano; Albano, 2022.
• Levantamento de dados de forma muito precisa e cuidadosa para evitar
que informações não correspondam à realidade; 2.4 Administrador de Banco de Dados (DBA)
• A administração do sistema de Banco de Dados pode se tornar muito
complexa em ambientes distribuídos, com grande volume de informações Podendo ser um ou mais responsáveis pela tarefa de gerenciamento do

manipuladas por uma grande quantidade de usuários. Banco de Dados, esses profissionais são responsáveis pela autorização de
acesso ao Banco de Dados para os demais usuários, coordenação e
2.3 Sistema de Banco de Dados monitoração do uso, ou seja, são eles que coordenam todas as atividades do
sistema de Banco de Dados e possuem conhecimento sobre os recursos de
Um sistema de Banco de Dados é um ecossistema que engloba quatro
informação da empresa e suas necessidades. Suas funções incluem:
componentes principais:

9 10
 • Definição do Banco de Dados; 4. Modelo físico.
• Estrutura de armazenamento e definição de acesso aos dados; Aqui compartilhamos uma pequena dica com você: todo e qualquer
• Esquema físico e organização dos dados; projeto é guiado do início ao fim pelas regras de negócio, que representam as
• Conceder acesso aos usuários; orientações e restrições que servem como reguladoras das operações de uma

• Cuidar da integridade dos dados; empresa. Essas regras são fornecidas pelo solicitante ou contratante.

• Acompanhar o desempenho do Banco de Dados; Podemos citar alguns exemplos de regras de negócio:

• Atividades de manutenção e backups. • Uma pessoa para se matricular em um curso superior, obrigatoriamente,
deverá apresentar o certificado de conclusão do Ensino Médio ou
TEMA 3 – MODELAGEM DE DADOS
equivalente;
• Um candidato a ser motorista de aplicativo deverá possuir a carteira de
O objetivo da modelagem de dados é a representação do cenário
habilitação válida.
observado e suas necessidades, analisando, documentando, normalizando e
detectando como as informações relacionam-se entre si, bem como fornecendo Figura 3 – Fases de um projeto de Banco de Dados
processos de validação que nos permitem avaliar a veracidade dos modelos
desenvolvidos.
Um Banco de Dados pode ser descrito ou modelado em vários níveis de
abstração, sendo, assim, definidos três modelos básicos:

1. Modelo conceitual;
2. Modelo lógico;
3. Modelo físico.

Antes de iniciar a construção de um Banco de Dados é essencial a

existência do projeto desse banco. Os modelos ajudam a demonstrar Fonte: Albano; Albano, 2022.

graficamente o Banco de Dados que será construído. Um modelo de dados é a

3.2 Modelo conceitual
descrição formal de um Banco de Dados.

É a descrição do Banco de Dados de maneira independente do tipo de

3.1 Projeto de Banco de Dados
SGBD que será escolhido, ou seja, define quais os dados que precisam estar
Todo bom sistema de Banco de Dados deve apresentar um projeto com presentes no Banco de Dados, sem se importar com a implementação do modelo
objetivo de organizar as informações e utilizar técnicas para promover a criação físico.
de um sistema que apresente boa performance, além de facilitar o processo de O modelo conceitual representa as regras de negócio sem preocupar-se
manutenção que porventura possa ser necessária. O projeto de Banco de Dados com limitações tecnológicas ou de implementação, por isso, é a etapa mais
consiste em quatro etapas: adequada para o envolvimento do usuário que não precisa ter conhecimentos
técnicos. Nesse modelo, temos:
1. Análise de requisitos;
2. Modelagem conceitual; • Visão geral do negócio;
3. Modelo lógico; • Facilitação do entendimento entre usuários e desenvolvedores;

11 12
 • Somente as entidades e campos principais; • Adequação ao padrão de nomenclatura;
• Independente da implementação e do SGBD; • Relações e atributos documentados;
• Descrição mais abstrata do Banco de Dados; • Dependente do SGBD.
• Ponto de partida para o projeto de um Banco de Dados. O modelo lógico do Banco de Dados relacional deve definir quais as
Uma das técnicas mais utilizadas entre os profissionais da área é a relações (tabelas) e quais os atributos que compõem as relações, bem como os
abordagem Entidade-Relacionamento (ER), em que o modelo é representado tipos de dados (número inteiro, data, cadeia de caracteres, entre outros) que
por meio do Modelo Entidade-Relacionamento (MER). serão armazenados nesses atributos.
Baseado no exemplo anterior, podemos definir o modelo lógico conforme:
Figura 4 – Exemplo de Modelo Entidade-Relacionamento (MER)
• Cliente: codigo (integer), nome (varchar), endereco (varchar) e codcidade
(integer);
• Cidade: codigo (integer), descricao (varchar) e UF (char).

É importante ressaltar que os detalhes internos de armazenamento não

são descritos no modelo lógico, uma vez que essas informações fazem parte do
modelo físico, que nada mais é que a tradução do modelo lógico para a
Fonte: Albano; Albano, 2022. linguagem do software escolhido para implementar o sistema.

O modelo acima nos apresenta informações sobre as entidades Cliente e Figura 5 – Exemplo de modelo lógico
Cidade, em que para cada cliente será armazenado seu código de identificação,
nome, endereço e código da cidade onde reside. Para cada cidade
armazenaremos o código, o nome da cidade e a unidade federativa
correspondente.
Vale salientar que, no exemplo acima, a relação ou associação existente
entre as duas entidades se baseia na premissa que UM cliente reside apenas
em UMA cidade, mas UMA cidade poderá ter NENHUM ou VÁRIOS clientes
residentes. Essa relação é denominada cardinalidade e será abordada com mais
detalhes em um próximo tópico desse material de estudo.
Fonte: Albano; Albano, 2022.

3.3 Modelo lógico

3.4 Modelo Físico
Nesta fase, descrevemos o Banco de Dados no nível do SGBD, ou seja,
Considera os limites impostos pelo Sistema Gerenciador de Banco de
todo modelo considerará as limitações e as características particulares do tipo
Dados (SGBD) e pelos requisitos não funcionais dos programas que acessam
de tecnologia presente no Banco de Dados escolhido. Suas características são:
os dados.
• Deriva do modelo conceitual; Características:
• Define as chaves primárias das entidades;
• Elaborado a partir do modelo lógico;
• Normalização até a 3ª forma normal;

13 14
 • Pode variar segundo o SGBD; formar as tabelas do Banco de Dados. Por exemplo, informações sobre
• Pode ter tabelas físicas (log); clientes, produtos, entregadores, restaurantes, entre outros;
• Descrição detalhada de como a base de dados está armazenada • Campo: características particulares de cada entidade. Por exemplo, o
internamente; cliente possui nome, data de nascimento, cidade onde reside, entre outras
• Linguagens e notações para o modelo físico variam de produto para informações. O conjunto de informações contidas nos campos formam o
produto (SGBD). que chamamos de registro;
• Relacionamento: representa a associação entre duas ou mais entidades.
Figura 6 – Exemplo de modelo físico
Por exemplo, o cliente reside em determinada cidade.

4.1 Entidade
create table cliente (
• codigo int, Como já mencionamos, a entidade no modelo conceitual representa um
• nome varchar (100) , objeto do qual desejamos armazenar as informações que serão utilizadas em
• endereco varchar (100) , uma aplicação.
• codCidade int ) ; Por exemplo, o sistema de delivery necessita armazenar informações
sobre os clientes. Como existem diversas informações sobre cada cliente, nesse
create table cidade ( caso, se faz necessário criar uma entidade com a função de representar esse
• codigo int, objeto.
• descricao varchar (100) ,
• uf char (02) ) ; 4.1.1 Tipos de entidades

De acordo com a estrutura da chave primária e baseado no grau de

Fonte: Albano; Albano, 2022. dependência que uma entidade possui em relação às demais entidades do
modelo, uma entidade poderá ser enquadrada como:
TEMA 4 – MODELO ENTIDADE RELACIONAMENTO (MER)
• Entidade fundamental;
O Modelo Entidade-Relacionamento (MER) foi desenvolvido pelo • Entidade associativa;
professor Peter Chen (1990) a fim de representar as estruturas de dados de uma • Entidade fraca.
forma mais natural e mais próxima do mundo real dos negócios.
Vale salientar que alguns dos conceitos citados acima serão esclarecidos
O Modelo Entidade-Relacionamento (MER) é um modelo de dados
após o aprofundamento dos conceitos do MER.
conceitual de alto nível. Foi projetado para estar o mais próximo possível da
visão que o usuário possui referente aos dados, não se preocupando em 4.1.1.1 Entidade fundamental
representar como esses dados estarão realmente armazenados.
O MER propõe que a realidade seja visualizada sob os seguintes É a entidade que possui chave primária simples, ou seja, a sua chave

conceitos fundamentais: primária não é composta pela chave primária de nenhuma outra entidade. Dessa
forma, a entidade fundamental não necessita da existência de qualquer outra
• Entidade: representação abstrata de um objeto do mundo real que
entidade para existir, pois é independente.
desejamos armazenar informações e, que na maioria dos casos, irão
15 16
 Por exemplo, entidades Cliente, Produto, Entregador, Restaurante, entre 4.1.2 Instância de uma entidade
outras.
São as informações armazenadas nos campos de uma entidade, as quais
4.1.1.2 Entidade associativa podem ser concretas (pessoa, conta, livro, entre outras) ou abstratas (pedido,
transação, entre outras).
É a entidade definida a partir da simplificação de um relacionamento de
Instâncias do mesmo assunto são agrupadas sob uma mesma entidade.
muitos para muitos entre duas ou mais entidades. Por exemplo, em um
Por exemplo, o registro contendo as informações Wilquison Souza, CPF.
relacionamento entre a entidade Pedido e a entidade Produto, ocorre a seguinte
789.123.456.11, residente na Avenida 7 de Setembro, 1, caracteriza-se por ser
situação: um pedido pode conter um ou vários produtos e um produto pode ser
uma instância da entidade Pessoa.
vendido em nenhum ou vários pedidos.
Com esse tipo de relacionamento surge a necessidade da criação de uma Figura 8 – Instância de uma entidade

nova entidade (explicaremos melhor esse tipo de relacionamento no tópico sobre

cardinalidade). Essa nova entidade poderá ser chamada de ItemPedido e nela
serão armazenados alguns campos específicos, tais como quantidade vendida,
valor do produto, desconto do produto, entre outros.

4.1.1.3 Entidade fraca

Fonte: Albano; Albano, 2022.

Essa entidade caracteriza-se pela dependência existencial, isto é, a

4.1.3 Regras para nomear uma entidade
entidade depende de uma outra entidade para poder existir no modelo.
Em casos em que exista a entidade fraca, tanto o relacionamento quanto • Deve ser única no modelo, isto é, não pode haver outra entidade com o
a entidade deverão serem representados com borda dupla. mesmo nome;
Por exemplo, em uma relação entre as entidades Funcionário e • O nome não pode conter espaços em branco;
Dependente, sabemos que um funcionário poderá possuir nenhum ou vários • O nome não pode conter caracteres especiais (ç, &, *, ˜, entre outros);
dependentes. Dessa forma, a entidade Dependente apenas existe por causa da • Preferencialmente, opte por nomes curtos e significativos.
entidade Funcionário. Se eliminarmos a entidade Funcionário,
Exemplos de nomes de entidades: Cliente, Produto, Entregador,
consequentemente, a entidade Dependente desaparecerá devido a sua
Restaurante, entre outros.
dependência.

4.1.4 Forma de representação de uma entidade

Figura 7 – Exemplo de entidade fraca

As entidades são representadas no Modelo Entidade-Relacionamento

(MER) por um retângulo. No centro do retângulo deve ser inserido o nome da
entidade.
Fonte: Albano; Albano, 2022.

17 18
 Figura 9 – Exemplo de representação de uma entidade • O quadro de funcionários dessa empresa também precisa ser
contemplado, pois a empresa necessita dessas informações;
• Clientes, restaurantes, entregadores e produtos seguem a mesma
linha de raciocínio;
• Quanto a movimentação dos pedidos, a empresa precisa ter um controle
Fonte: Albano; Albano, 2022.
do que foi vendido, para quem foi vendido e qual restaurante vendeu.

4.1.5 Estudo de caso Perceba que cada objeto que armazena informações foi definido como
uma entidade. É possível que você tenha encontrado outras entidades que não
Para aprimorar os conceitos, vamos implementar passo a passo um
foram listadas nesse momento. Não se preocupe, durante a evolução do modelo
estudo de caso sobre uma rede de restaurantes que decidiu ter um aplicativo de
é comum a inclusão e a exclusão de entidades até chegarmos ao modelo ideal.
delivery.
Isso faz parte do processo de construção do projeto de Banco de Dados.
O restaurante “Comer é Bom Demais” forneceu, inicialmente, as seguintes
Baseado nas entidades que já descobrimos, vamos analisar qual a
regras de negócio:
relação que cada uma pode possuir com as demais:
1. O restaurante possui diversas filiais espalhadas pelo território nacional,
• Restaurante:
podendo ter mais de uma filial na mesma cidade. Essas informações
o Possui várias filiais que estão instaladas em diferentes cidades;
devem estar devidamente cadastradas.
o Cada filial receberá vários pedidos por meio do aplicativo;
2. O restaurante possui vários funcionários.
o Possui muitos funcionários em cada filial;
3. Os pedidos são entregues por entregadores autônomos.
• Cliente:
4. O aplicativo deverá possuir produtos.
o Realiza um pedido por meio do aplicativo;
5. Os pedidos referentes a cada restaurante deverão ser devidamente
o Reside em uma cidade;
armazenados.
• Funcionário:
6. Para fazer um pedido no sistema de delivery, o cliente deverá estar
o Faz parte do quadro de funcionários de uma das filiais;
previamente cadastrado.
o Reside em uma cidade;
Vale ressaltar que, ao longo do desenvolvimento do modelo, serão • Entregador:
incluídas novas regras de negócio com o objetivo de aprofundar e aplicar os o Realiza as entregas dos pedidos;
conceitos aqui discutidos. o Está locado em uma cidade;
Para começar, vamos definir as entidades que representaram cada objeto • Pedido:
do mundo real da empresa de delivery, baseando-se sempre nas regras de o Precisa-se manter as informações sobre quem fez o pedido, para qual
negócio já conhecidas. filial e qual(is) foi(ram) o(s) produto(s) escolhido(s);
Avalie as regras de negócio perguntando-se sobre quais objetos ou itens • Produto:
têm características ou informações próprias a serem armazenadas. Pensando o Sempre será referenciado dentro de um pedido;
dessa forma, já podemos identificar as seguintes entidades:
• Cidade:
• Como a empresa atua em âmbito nacional, seria importante o Pertence a um estado;
armazenarmos informações sobre os estados e as cidades; • Estado:

19 20
 o Possui diversas cidades em seu território. 4.2 Campos
A partir dessa análise prévia, vamos construir nosso primeiro modelo
São as propriedades que caracterizam uma entidade, isto é,
conceitual (MER).
características particulares do objeto que está sendo analisado. Os campos são
Figura 10 – Estudo de caso: Primeiro modelo conceitual baseados nas informações definidas nas regras de negócio.
No caso do nosso exemplo sobre o sistema de delivery, a entidade Cliente
possuirá como campos o nome, o endereço, a data de nascimento, o sexo, o
CPF e as demais características necessárias.

4.2.1 Tipos de campos

De acordo com a sua finalidade ou conteúdo, um campo pode ser

classificado da seguinte forma:

• Obrigatório;
• Opcional;
• Simples;
• Composto;
• Monovalorado;
• Multivalorado;
• Derivado.
Fonte: Albano; Albano, 2022.

O próximo passo é aprendermos sobre os campos que pertencem a cada 4.2.1.1 Campo obrigatório
uma das entidades do nosso modelo conceitual.
É aquele campo que deve possuir, para uma instância de uma entidade
ou relacionamento, obrigatoriamente um valor, ou seja, o campo deve ter um
conteúdo, não podendo ficar sem informação. Por exemplo, nome do cliente,
descrição do produto, nome da cidade, entre outros.

4.2.1.2 Campo opcional ou nulo

É aquele que para uma instância da entidade ou relacionamento pode

possuir um valor, ou seja, seu preenchimento não é obrigatório. Por exemplo,
telefone, complemento do endereço, entre outros.

21 22
 4.2.1.3 Campo simples ou atômico • Código do cliente: o domínio é definido como um conjunto de números
inteiros positivos com quatro algarismos;
São os campos que não podem ter o seu conteúdo dividido, ou seja, não • Nome do entregador: conjunto de caracteres alfanuméricos com no
há como separar os dados. Campos desse tipo não são divisíveis ou máximo 100 caracteres;
decompostos. Por exemplo, estado civil, bairro, gênero, raça, entre outros.
• Salário: valor numérico positivo com duas casas decimais;
• Gênero: são os mnemônicos M ou F.
4.2.1.4 Campo composto
4.2.3 Regras para nomear um campo
Os campos compostos podem ser divididos em partes menores que,
dependendo do caso, podem inclusive gerar novos campos.
• Devem ser únicos na entidade;
O próprio nome de uma pessoa pode ser classificado como um campo
• Nomes sem espaços em branco;
composto, pois pode ser estruturado em prenome, nome intermediário e
• Nomes sem caracteres especiais;
sobrenome.
• Utilizar nomes significativos que identifiquem o seu conteúdo;

4.2.1.5 Campo monovalorado • Preferencialmente nomes curtos.

Todo e qualquer campo que possua um único valor para uma entidade é 4.2.4 Formas de representação de um campo
considerado um campo monovalorado. Por exemplo, nome, CPF, gênero, data
No Modelo Entidade-Relacionamento (MER) o campo é representado por
de nascimento, entre outros.
meio de uma linha que o liga a uma determinada entidade que o corresponde.
4.2.1.6 Campo multivalorado Essa linha também possui uma ponteira que representa a prioridade que o
campo exerce dentro da entidade, podendo ser um campo principal da entidade,
Os campos que podem possuir mais de um valor para uma entidade são denominado chave primária ou Primary Key (PK, o único campo a ser
chamados de campos multivalorados. Por exemplo, uma pessoa pode possuir representado pela ponteira preenchida), campos que assumem as funções de
mais de um número de telefone. chave secundária (Secondary Key), estrangeira (Foreign Key – FK) ou,
4.2.1.7 Campo derivado simplesmente, um campo comum.
Um campo derivado é aquele que é derivado de outros campos ou
Figura 11 – Exemplo de representação de campos
entidades relacionados a ele. Por exemplo, o campo idade é derivado dos
campos data de nascimento e data atual.

4.2.2 Domínio do campo

Cada campo possui um domínio, que é um conjunto de valores que pode

representá-lo. O domínio é um conjunto de valores que possuem determinadas
propriedades em comum. Ao conjunto de todos os valores possíveis para
determinado campo dá-se o nome de domínio. Exemplo:

Fonte: Albano; Albano, 2022.

23 24
 4.2.5 Tipos de chaves de um campo Figura 12 – Exemplo de chave primária

Uma entidade deve ter a capacidade de identificar cada uma de suas

instâncias separadamente em um Banco de Dados, além de manter a
capacidade de relacionar-se com as demais entidades. Para isso, utilizamos o
conceito de chaves.

4.2.5.1 Chave primária ou Primary Key

Uma chave primária é um ou um conjunto de campos que permite

Fonte: Albano; Albano, 2022.
identificar unicamente uma instância da entidade. Tem por função diferenciar
uma instância da entidade de outra instância, tornando essa instância única, ou Vamos analisar a entidade (tabela):
seja, diferente das demais instâncias.
• As colunas que contêm, respectivamente, o nome do cliente, a data de
Características de uma chave primária:
nascimento e o endereço não armazenam um valor único que represente
• Identificada pela sigla PK (Primary Key); o registro, isso porque podem existir homônimos (pessoas com o mesmo
• O valor contido nesse campo deve ser único para cada instância da nome), pessoas que nascem na mesma data e, para concluir, em um
entidade, ou seja, nunca se repetirá. Além disso, não poderá sofrer mesmo endereço pode morar uma família;
alteração, garantindo que cada instância possua a característica de • Sendo assim, a melhor escolha para ser a chave primária é o campo
unicidade; código, uma vez que cada cliente possui um número que difere de cliente
• Não poderá receber valores duplicados ou nulos. Dessa forma, também para cliente, o que torna seu conteúdo único, inalterável e intransferível.
não poderá ser composta por um campo opcional; Perceba que o campo código não é um campo natural da entidade Cliente,
• Chave primária que apresente mais de um campo é denominada de chave ele existe pela necessidade de diferenciar um cliente de outro cliente.
primária composta;
• Preferencialmente, a chave primária deve ser um campo numérico, uma
4.2.5.2 Chave estrangeira ou Foreign Key
vez que isso ajudará na performance do Banco de Dados.
A chave estrangeira é um campo ou um conjunto de campos presentes
Chave primária não natural: existem situações em que não temos um em uma entidade, mas que pertencem a outra entidade. Além disso, esse campo
campo “natural”, ou seja, próprio da entidade que possa ser a chave primária. deverá ser uma chave primária na sua entidade de origem.
Nesse caso, usaremos o conceito de chave substituta ou chave artificial Vale salientar que a presença de chaves estrangeiras em uma entidade
(Surrogate Key). Geralmente, esse campo numérico é sequencial caracteriza a associação entre entidades, isto é, só existe chave estrangeira se
(autoincremento), sendo sua única função diferenciar uma instância de outra. houver um relacionamento direto entre as entidades envolvidas.
Para melhor compreensão, vamos exemplificar a definição de uma chave Características de uma chave estrangeira:
primária utilizando a entidade Cliente. Procure analisar cada campo da entidade
• Identificada pela sigla FK (Foreign Key);
a seguir, levando em conta as regras já discutidas anteriormente. Pergunte-se:
• Utilizada para referenciar o relacionamento com outra entidade;
qual o campo (coluna) ideal para ser eleito como chave primária?
• Sempre será uma chave primária de outra entidade associada;

25 26
 • Caso a chave primária seja composta na origem, a chave estrangeira 4.2.6 Estudo de caso
também será composta;
• O valor da chave estrangeira poderá se repetir; Baseado no conhecimento adquirido sobre campos, vamos continuar o
desenvolvimento do nosso projeto de Banco de Dados sobre um aplicativo de
• Não poderá ser composta por campo opcional, ou seja, campo que aceite
delivery.
um valor nulo.
Regras adicionais:
Exemplo:
• O acesso ao aplicativo, tanto por clientes quanto por funcionários, deverá
Figura 13 – Exemplo de chave estrangeira ser por meio de um login e uma senha, sendo que o login corresponde ao
e-mail do usuário;
• Como é um sistema de delivery, o endereço de entrega deve ser bem
detalhado, contemplando as seguintes informações: nome da rua, número
do imóvel, complemento (caso houver), bairro, ponto de referência e CEP;
• O restaurante sempre presenteia os aniversariantes com um desconto;
• Os pedidos possuem um status, isto é, a situação em que se encontra,
podendo estar no estado “A confirmar”, “Em preparação”, “Saiu para a
entrega”, “Entregue” e “Cancelado”;
• Os entregadores autônomos, obrigatoriamente, deverão ter registrada a
carteira de habilitação no sistema;
• Os produtos são divididos em categorias, sendo: lanches, pratos prontos,
bebidas e sobremesas.
Fonte: Albano; Albano, 2022.
Vale salientar que, além das regras adicionais, alguns campos se fazem
Analisando a entidade Cliente podemos verificar que ela possui um campo necessários, por exemplo, informações do cliente, do produto, do funcionário,
que armazenará a cidade onde reside cada cliente. Essa informação, porém, tem entre outros.
uma característica repetitiva, em que é possível que a mesma cidade seja usada Importante ressaltar que o modelo conceitual apresentado não contempla
em diversos registros de clientes. Dessa forma, para garantir agilidade e precisão os campos resultantes dos relacionamentos entre as entidades. Tais campos
nos dados informados foi criada uma nova entidade chamada Cidade. serão incluídos no momento da aplicação das regras de cardinalidade.
No caso da entidade Cidade, ela conterá todos os registros de cada uma
das cidades e, dessa forma, a entidade Cliente apenas irá fazer a referência ao
código correspondente a cidade desejada.
Perceba que as duas entidades se comunicam apenas por meio do código
da cidade, que é a chave estrangeira dessa relação.

27 28
 Figura 14 – Inclusão de campos no modelo conceitual Figura 15 – Representação de relacionamento

Fonte: Albano; Albano, 2022.

Por exemplo, a entidade Cliente relaciona-se com a entidade Cidade,

onde um cliente reside em uma cidade e uma cidade pode ter nenhum ou vários
clientes residentes.

Figura 16 – Exemplo de relacionamento

Fonte: Albano; Albano, 2022.

Fonte: Albano; Albano, 2022. 4.3.2 Relacionamento recursivo ou autorrelacionamento

4.3 Relacionamento ou associação Os relacionamentos recursivos, também chamados de

autorrelacionamentos, são casos especiais em que uma entidade se relaciona
Um relacionamento pode ser entendido como uma associação entre as
consigo mesma, isto é, ocorre um relacionamento associado a uma única
entidades devido as regras de negócio. Normalmente, ocorre entre duas ou mais
entidade.
entidades, porém, há situações que pode ocorrer entre instâncias da mesma
Podemos exemplificar esse tipo de relacionamento utilizando o
entidade, conhecido como autorrelacionamento.
gerenciamento de funcionários de uma empresa, em que o gerente é um
Por exemplo, um cliente (entidade Cliente) reside em determinada cidade
funcionário que possui um relacionamento com outros funcionários que lhe são
(entidade Cidade). Dessa forma, estabelece-se uma ligação, isto é, um
subordinados. Porém, o gerente também é um funcionário da empresa e
relacionamento entre as entidades Cliente e Cidade.
subordinado a outro funcionário que ocupa um cargo superior ao de gerente.
Dessa forma, seu papel como funcionário oscila entre gerente e subordinado.
4.3.1 Forma de representação
Esse relacionamento pode ser representado da seguinte forma:
Para representar a ocorrência de relacionamentos utilizamos um losango
Figura 17 – Representação de relacionamento recursivo
que estabelece a ligação entre as entidades envolvidas, conectando-as por meio
de uma linha.

Fonte: Albano; Albano, 2022.

29 30
 O autorrelacionamento pode possuir uma cardinalidade do tipo 1:1 (um Lembre-se, havendo um relacionamento, teremos um ou mais campos em
para um), 1:n (um para muitos) ou n:n (muitos para muitos), dependendo da comum entre as entidades envolvidas, que são responsáveis pela ligação entre
política de negócio que estiver envolvida. O tema cardinalidade será discutido elas.
posteriormente nesse material de estudo. De forma básica, a cardinalidade é representada de três formas:

1. Um para um (1:1);
4.3.3 Especialização e generalização
2. Um para muitos / muitos para um (1:n) / (n:1);
A especialização ocorre quando existe a presença de propriedades 3. Muitos para muitos (n:n) / (n:m).
particulares em uma entidade, provocando uma subdivisão devido a Além dos tipos citados acima, também abordaremos a cardinalidade
necessidade de campos específicos para cada situação. máxima e mínima, extremamente utilizadas.
No caso da generalização, essa é exatamente o inverso da
especialização, isto é, agregando as similaridades presentes das 5.1 Um para um (1:1)
especializações. É quando as entidades podem ser reunidas em apenas uma.
Ocorre quando UMA instância da entidade está associada a apenas UMA
O clássico exemplo do cliente pessoa física ou pessoa jurídica ilustra
instância de outra entidade e, de forma inversa, o mesmo acontece.
claramente como ocorre uma situação de especialização. Analisando o conjunto
Por exemplo, baseado na regra de negócio que uma pessoa só pode estar
de campos é possível verificar que uma pessoa física possui campos diferentes
casada legalmente com outra pessoa (cônjuge), como estabeleceríamos a
de uma pessoa jurídica, mas ambos são clientes.
cardinalidade existente entre as entidades?
Veja o modelo a seguir:

Figura 19 – Exemplo de relacionamento

Figura 18 – Exemplo de especialização e generalização

Fonte: Albano; Albano, 2022.

Passo a passo:

1. UMA pessoa (1) possui apenas UM cônjuge (1).

2. Avalie a cardinalidade obtida realizando a leitura de forma inversa: UM
cônjuge (1) possui apenas UMA pessoa (1).
Fonte: Albano; Albano, 2022.
3. Perceba que a cardinalidade permaneceu igual, não importando a direção

TEMA 5 – CARDINALIDADE da leitura. Dessa forma, a cardinalidade resultante é 1:1.

A cardinalidade é um elemento fundamental no relacionamento entre

entidades de um modelo. É por meio dela que determinamos se a relação entre
as entidades está correta. A cardinalidade é baseada em suas instâncias. Além
disso, a cardinalidade define em qual entidade será adicionada a chave
estrangeira (Foreign Key – FK).

31 32
 Figura 20 – Exemplo de cardinalidade 1:1 Vale ressaltar que quando ocorrer um relacionamento 1:1, sua existência
é opcional, ou seja, analisando as entidades envolvidas no relacionamento você
pode decidir eliminar uma delas. No exemplo, a entidade Cônjuge poderia ser
transformada em um campo da entidade Pessoa. Eliminar ou não a entidade é
uma decisão pessoal de quem está modelando, não havendo uma regra definida.

5.2 Um para muitos / muitos para um (1:n / n:1)

Uma entidade está associada a várias instâncias de outra entidade, mas

de forma inversa, uma entidade apenas pode estar associada a no máximo UMA
instância da entidade. Também é importante ressaltar que a cardinalidade n
sempre terá precedência sobre a cardinalidade 1.
Por exemplo, um cliente está associado unicamente a uma cidade, mas o
mesmo não ocorre de forma inversa, pois uma cidade possui vários clientes
associados a mesma.
Passo a passo:

Fonte: Albano; Albano, 2022. 1. UM cliente (1) reside em apenas UMA cidade (1).
2. Leitura inversa: UMA cidade (1) possui MUITOS residentes (n).
5.1.1 Definição da Chave Estrangeira – Foreign Key (FK) 3. Perceba que a leitura da cardinalidade apresentou diferenças. Por causa
disso, devemos aplicar a regra da precedência do n em relação a
Em um relacionamento 1:1 a chave estrangeira poderá ficar em qualquer
cardinalidade 1, resultando em uma cardinalidade de 1:n.
uma das entidades. Como é um relacionamento exclusivo (1:1), não faz
diferença se a chave primária da entidade Pessoa for adicionada na entidade Figura 22 – Exemplo de cardinalidade 1:n
Cônjuge ou de forma inversa.

Figura 21 – Chave estrangeira em cardinalidade 1:1

Fonte: Albano; Albano, 2022.

Fonte: Albano; Albano, 2022.

33 34
 5.2.1 Definição da chave estrangeira – Foreign Key (FK) Passo a passo:

1. UMA conta (1) possui MUITOS clientes (n).

Em um relacionamento 1:n ou n:1, a chave estrangeira deverá ficar
2. Leitura inversa: UM cliente (1) pode ter MUITAS contas (n).
sempre na entidade do lado n do relacionamento.
3. Aplique a regra da precedência e a cardinalidade resultante é n:n.
No exemplo, a chave primária da entidade Cidade será adicionada na
entidade Cliente. Nessa entidade, esse campo será a chave estrangeira, ou seja, Figura 24 – Exemplo de cardinalidade n:n
será a ligação entre as entidades Cliente e Cidade.
Você pode estar se perguntando: por que não colocamos a chave
estrangeira (FK) no lado do relacionamento 1? Essa não seria uma boa opção,
pois teríamos que armazenar na entidade Cidade inúmeros clientes, o que não
seria muito prático ou viável. Sendo assim, a chave estrangeira fica na entidade
que terá somente um valor a ser associado, ou seja, um cliente reside somente
em uma cidade.

Figura 23 – Exemplo de chave estrangeira

Fonte: Albano; Albano, 2022.

5.3.1 Definição da chave estrangeira – Foreign Key (FK)

Este caso é o mais complexo para analisarmos. Já estudamos que a regra

define que a chave estrangeira (FK) é indicada no lado n, porém, nesse caso, os
dois lados resultaram em uma cardinalidade muitos para muitos (n:n). Dessa
Fonte: Albano; Albano, 2022.
forma, precisamos ponderar sobre algumas questões:

5.3 Muitos para muitos (n:n / n:m) • Podemos adicionar a chave primária da entidade Conta na entidade
Cliente?
Neste caso, uma entidade está associada a várias instâncias de outra
• Ou adicionar a chave primária da entidade Cliente na entidade Conta?
entidade e o inverso ocorre da mesma maneira.
A resposta para as duas questões é não, pois em ambos os casos
Por exemplo, considere a regra de negócio que define que um cliente
teríamos que armazenar mais de um valor em um mesmo campo. Então, qual é
poderá possuir várias contas e que uma conta poderá ser conjunta, isto é,
a solução?
pertencer a mais de um cliente.

35 36
 Relacionamentos cuja cardinalidade resulte em n:n sempre gerarão uma Saiba mais
nova entidade. Essa entidade, como já vimos, é conhecida como entidade Após finalizar a aplicação da cardinalidade no Modelo Entidade-
associativa. Nela adicionaremos a chave primária das entidades envolvidas no Relacionamento (MER), não poderá existir nenhum relacionamento n:n. Todos
relacionamento, nesse caso, as entidades Conta e Cliente. Inclusive, se houver os relacionamentos resultantes deverão apresentar cardinalidades 1:n e 1:1.
necessidade, podemos adicionar mais campos.
A partir do momento em que ocorre a inclusão dessa nova entidade, o
5.4 Cardinalidades mínima e máxima
relacionamento torna-se automaticamente 1:n.
Com a evolução do modelo conceitual (MER) e com o objetivo de melhorar
Outro aspecto importante nessa situação que precisamos avaliar é: qual
a implementação das regras de negócio, foi introduzido o conceito de
será a chave primária dessa nova entidade?
cardinalidades mínima e máxima. Tal conceito representa a frequência de
Existem duas alternativas para a definição dessa chave:
relações entre as entidades, isto é, restringe a quantidade de ocorrências que
1. A chave primária será composta pelas chaves estrangeiras das entidades
podem existir entre as entidades que participam do relacionamento. Essas
Conta e Cliente. Isso mesmo que você está lendo, um campo pode ser
ocorrências também são denominadas instâncias.
chave estrangeira e fazer parte da chave primária ao mesmo tempo.
A cardinalidade é representada por uma cardinalidade mínima e uma
2. Criar uma chave artificial, denominada Surrogate Key (chave substituta),
cardinalidade máxima, possuindo uma notação (m, M), onde:
que será um campo com a função de diferenciar uma instância da outra.
• Cardinalidade mínima (m) – Estabelece o número mínimo de instâncias
Figura 25 – Formas de representação de uma entidade associativa que podem existir entre uma entidade e outras entidades participantes do
relacionamento;
• Cardinalidade máxima (M) – Define o número máximo de instâncias que
podem existir entre uma entidade e outras entidades envolvidas no
relacionamento.

Figura 26 – Cardinalidades mínima e máxima

Fonte: Albano; Albano, 2022.

Com a prática na criação de modelos, você irá naturalmente antever um

relacionamento n:n e já criará as entidades sem a necessidade de representar a
entidade associativa (representação 2).
Observe que na representação 2 da entidade ContaCliente foi utilizado
como chave primária uma Surrogate Key (SK), em vez da chave composta
apresentada na representação 1. Fonte: Albano; Albano, 2022.

37 38
 É importante ressaltar que a notação da cardinalidade é sempre Figura 28 – Tipos de notações de cardinalidades
apresentada no lado oposto. Por exemplo, na relação existente entre as
entidades Cliente e Cidade:

1. UM cliente reside em apenas UMA cidade. Dessa forma, tanto a

cardinalidade mínima quanto a máxima serão 1, sendo a cardinalidade
resultante (1,1). A notação será apresentada ao lado da entidade Cidade.
2. Leitura inversa: UMA cidade poderá ter NENHUM (zero) ou MUITOS
residentes associados a ela, resultando em uma cardinalidade (0,n). A
notação será apresentada ao lado da entidade Cliente.

Fonte: Albano; Albano, 2022.

Figura 27 – Exemplo de cardinalidades mínima e máxima

5.5 Estudo de caso

Agora que você já conhece todos os tipos de cardinalidades, vamos aplicar

no modelo do nosso estudo de caso.

Figura 29 – Inclusão de cardinalidades no modelo conceitual

Fonte: Albano; Albano, 2022.

É importante ressaltarmos que, independentemente da ferramenta

utilizada, a cardinalidade possui mais de um padrão de notação. A seguir
apresentaremos as mais comuns.

Fonte: Albano; Albano, 2022.

39 40
 Entendendo as cardinalidades: • Produto/Pedido: um pedido pode ter um ou vários produtos e um produto
pode estar em nenhum ou vários pedidos. A cardinalidade resultante n:n.
• Estado/Cidade: uma cidade pertence a um estado e um estado pode
Aqui devemos observar que é necessário criar uma entidade associativa
possuir várias cidades em seu território. Cardinalidade resultante 1:n. A
e, nesse caso, vamos chamar a entidade de PedidoProduto. Tal entidade
chave estrangeira será o ID da entidade Estado na entidade Cidade.
possuirá como campos as chaves primárias das entidades Produto e
Recorde que a chave estrangeira sempre será inserida na entidade cuja
Pedido, que assumem a função de chave estrangeira. Como chave
cardinalidade resultou em muitos (n).
primária usaremos a chave artificial ID. Além disso, outras informações
• Funcionário/cidade: um funcionário mora em uma cidade e uma cidade
também devem ser armazenadas nessa entidade, a quantidade do
pode ter nenhum ou vários funcionários morando. Cardinalidade
produto, o valor unitário do produto e o desconto do produto
resultante 1:n. A chave estrangeira será o ID da entidade Cidade na
(aniversariantes).
entidade Funcionário.
• Restaurante/Cidade: um restaurante está instalado em uma cidade e uma Com a aplicação da cardinalidade, concluímos o desenvolvimento do
cidade pode ter nenhum ou vários restaurantes instalados. Cardinalidade modelo conceitual do nosso estudo de caso.
resultante 1:n. A chave estrangeira será o ID da entidade Cidade na
FINALIZANDO
entidade Restaurante.
• Entregador/Cidade: um entregador trabalha em uma cidade e uma cidade Nesta etapa aprendemos sobre os conceitos fundamentais de Banco de
pode ter nenhum ou vários entregadores trabalhando. Cardinalidade Dados, conhecemos os modelos de armazenamento de dados, dos mais antigos
resultante 1:n. A chave estrangeira será o ID da entidade Cidade na (rede, hierárquico e orientação a objetos) até os atuais (relacional e No-SQL) e
entidade Entregador. entendemos, ainda, como se dá a estrutura do Banco de Dados, com suas
• Cliente/Cidade: um cliente reside em uma cidade e uma cidade pode ter entidades, campos e relacionamentos.
nenhum ou vários clientes residindo. Cardinalidade resultante 1:n. A Discutimos também sobre a importância do SGBD, que é o software que
chave estrangeira será o ID da entidade Cidade na entidade Cliente. faz a comunicação entre o Banco de Dados, os usuários e as aplicações que
• Funcionário/Restaurante: um funcionário trabalha em um restaurante e acessam esses dados.
um restaurante pode ter um ou vários funcionários trabalhando. Aprendemos sobre as etapas do projeto de Banco de Dados e, juntos,
Cardinalidade resultante 1:n. A chave estrangeira será o ID da entidade desenvolvemos um modelo conceitual, baseado em um estudo de caso. O
Restaurante na entidade Funcionário. modelo desenvolvido é uma abstração de alto nível, ou seja, não apresenta a
• Restaurante/Pedido: um pedido é recebido por um restaurante e um definição de detalhes técnicos.
restaurante recebe um ou vários pedidos. Cardinalidade resultante 1:n. A Compreendemos o que é uma entidade, seus tipos, campos e os
chave estrangeira será o ID da entidade Restaurante na entidade Pedido. relacionamentos entre as entidades. Aprendemos sobre conceitos de chave
• Entregador/Pedido: um pedido será entregue por um entregador e um primária, que diferencia uma instância das outras em uma entidade, e de chave
entregador faz a entrega de um ou vários pedidos. Cardinalidade 1:n. A estrangeira, que é o campo que faz a ligação entre as entidades.
chave estrangeira será o ID da entidade Entregador na entidade Pedido. Por fim, estudamos o que é cardinalidade, seus tipos (1:1, 1:n e n:n) e
• Cliente/Pedido: um pedido será realizado por um cliente e um cliente descobrimos que um relacionamento muitos para muitos (n:n) provoca o
realiza um ou vários pedidos. Cardinalidade 1:n. A chave estrangeira será surgimento de uma nova entidade. Com isso, pudemos perceber a importância
o ID da entidade Cliente na entidade Pedido. que a cardinalidade exerce na definição dos relacionamentos entre as entidades

41 42
 do modelo, conceitos esses que também foram aplicados passo a passo no REFERÊNCIAS
desenvolvimento do nosso estudo de caso.
Procure revisar os conceitos e os exemplos apresentados neste material CHEN, Peter. Modelagem de Dados: A abordagem entidade-relacionamento

para que você esteja preparado para os próximos passos que abrangerão a para projeto lógico. São Paulo: Makron Books, 1990.

conversão do modelo conceitual para o modelo lógico e, subsequentemente, do

lógico para o modelo físico.

43 44