E-book 1 Estrutura e Modelagem de Dados

Prévia do material em texto

ESTRUTURA E 
MODELAGEM 
DE DADOS
E-book 1
 César Torres Fernandes 
Neste E-Book:
INTRODUÇÃO ����������������������������������������������4
BANCO DE DADOS: UMA VISÃO 
GERAL ������������������������������������������������������������ 5
EVOLUÇÃO HISTÓRICA �������������������������������������������5
DADO, INFORMAÇÃO, BANCO 
DE DADOS E SISTEMA DE 
GERENCIAMENTO DE BANCO DE 
DADOS ����������������������������������������������������������10
TERMOS COMUNS EM BANCO DE 
DADOS �����������������������������������������������������������11
TIPOS DE BANCO DE DADOS ���������������13
Arquiteturas de banco de dados �������������������������� 15
ABSTRAÇÃO DE DADOS: MODELOS 
CONCEITUAL, LÓGICO E FÍSICO ����������20
PROJETO DE BANCO DE DADOS �������� 22
MODELO ENTIDADE-
RELACIONAMENTO ���������������������������������24
ENTIDADE ��������������������������������������������������� 25
ATRIBUTOS �������������������������������������������������26
RELACIONAMENTOS �������������������������������28
2
DIAGRAMA ENTIDADE-
RELACIONAMENTO ��������������������������������� 35
CONSIDERAÇÕES FINAIS ����������������������39
SÍNTESE ������������������������������������������������������ 40
3
INTRODUÇÃO
Neste módulo, estudaremos a evolução históri-
ca dos bancos de dados e, em seguida, estudare-
mos a diferença entre dados, informação, banco 
de dados e sistemas de gerenciamento de banco 
de dados� Analisaremos a visão de três camadas: 
conceitual, lógica e física. Por fim, trataremos os 
sistemas de bancos de dados relacionais e o modelo 
Entidade-Relacionamento�
4
BANCO DE DADOS: UMA 
VISÃO GERAL
Neste tópico, abordamos a evolução histórica dos 
bancos de dados e o surgimento dos sistemas de 
gerenciamento de banco de dados� Vamos iniciar 
traçando um panorama da disciplina, ou seja, com 
sua evolução histórica�
EVOLUÇÃO HISTÓRICA
Com a evolução humana — isto é, o desenvolvimento 
da fala e escrita, bem como o surgimento das pri-
meiras sociedades primitivas —, surge a demanda 
de registrar fatos importantes sobre animais, cultivo, 
tempo e outros eventos do cotidiano� Nesse perío-
do, marcava-se tudo que era importante em ossos, 
pedaços de madeira, chifres, nós feitos em cordas 
ou escrevia-se em tábuas de argila/barro�
Esse ato de registrar os fatos acompanhou a evolu-
ção da sociedade e das tecnologias� A invenção de 
papiros, pergaminhos e papel possibilitou a capa-
cidade de armazenar mais dados, auxiliando gover-
nantes, comerciantes e diversos outros profissionais 
ao longo dos tempos�
Nesse sentido, a invenção de Johannes Gutenberg, 
por volta de 1430, gerou uma verdadeira revolu-
ção: estamos falando da imprensa� A partir de en-
5
tão, livros podiam ser produzidos e reproduzidos 
em quantidades muito maiores do que o processo 
manual existente, utilizando o papel como meio de 
armazenamento�
No final do século 19, Herman Hollerith (1860-1929) 
desenvolveu um sistema de codificação de dados 
que eram armazenados em uma fita de papel perfu-
rada e, posteriormente, eram lidos por uma máquina 
que processava os dados estatísticos� Seu sistema 
foi aperfeiçoado com a utilização de cartões perfu-
rados em vez da fita de papel perfurado; assim, em 
1889 Hollerith realizou a contagem do censo norte-
-americano, diminuindo em muito o tempo para se 
obter o resultado�
Apesar de todos esses avanços, aspectos como 
praticidade, rapidez na consulta, confiabilidade nos 
dados armazenados etc�, ainda não eram atendidos 
de forma plena, fato ocorrido somente com o surgi-
mento dos computadores�
Segundo Alves (2014), os primeiros programas de 
computador trabalhavam com arquivos sequenciais 
para o armazenamento de dados, em que a aplicação 
era responsável tanto pela definição quanto pelo 
gerenciamento dos dados, fazendo uso de recursos 
do sistema operacional para a leitura e gravação dos 
dados em discos ou fitas (Figura 1).
6
Aplicação 
Vendas
Aplicação 
Estoque
Arquivos dados
Estoque
Arquivos dados
Vendas
Sistema Operacional
Figura 1: Sistema de arquivos. Fonte: Adaptada de Alves (2014).
Esse tipo de sistema, apesar de melhorar a pratici-
dade e a rapidez no acesso aos dados, apresenta 
vários problemas, por exemplo, ausência de controle 
de acesso concorrente por múltiplos usuários, im-
possibilidade de execução de mais de um processo 
ao mesmo tempo sobre um mesmo arquivo de da-
dos, inconsistências, redundâncias, segurança dos 
dados e uma relação de dependência estrutural e 
de dados indesejada entre o arquivo de dados e as 
estruturas do arquivo codificadas na aplicação, tor-
nando o processo de manutenção de todo o sistema 
muito complexo�
7
Com isso, surge a necessidade de se criar um sis-
tema em que os dados fossem relacionados logi-
camente, bem como armazenados em um único 
repositório de dados, na tentativa de eliminar ou 
minimizar os problemas encontrados com o sistema 
de arquivos para armazenamento de dados� Dessa 
forma, surge o sistema de banco de dados (Figura 2):
Aplicação 
Estoque
Aplicação 
Vendas
Banco de 
Dados
Sistema de Banco de dados
Figura 2: Sistema de Banco de Dados. Fonte: Adaptada de Alves 
(2014).
O sistema de banco de dados surgiu como um con-
junto de componentes de software que auxilia na 
definição e regulação da coleta, do armazenamento, 
do gerenciamento e da utilização de dados (ROB; 
CORONEL, 2011). Os sistemas de banco de dados 
8
permitem, então, uma maior produtividade no desen-
volvimento e na manutenção tanto dos aplicativos 
quanto dos próprios bancos de dados, contribuindo 
para o aumento da qualidade, diminuição dos custos 
e melhores estimativas de prazos nos projetos de 
sistemas e softwares�
9
DADO, INFORMAÇÃO, 
BANCO DE DADOS 
E SISTEMA DE 
GERENCIAMENTO DE 
BANCO DE DADOS
Neste momento, mostra-se relevante formalizar-
mos alguns conceitos sobre dados, informação, 
banco de dados e, principalmente, o Sistema de 
Gerenciamento de Banco de Dados (SGBD).
Rob e Coronel (2011) afirmam que um dado repre-
senta um fato que ainda não foi processado para re-
velar o seu significado. Por exemplo: nome, endereço 
e telefone� A informação é o resultado do proces-
samento de dados, revelando assim seu significado 
dentro de um contexto com precisão, relevância e 
rapidez, permitindo ao usuário uma tomada de deci-
são mais adequada� Por exemplo: dados das peças 
em estoque, quando processados, possibilitam a 
obtenção de uma lista de peças em falta�
Um banco de dados, segundo Alves (2014), é uma 
estrutura formada por um conjunto lógico e orde-
nado de dados e metadados (dados sobre dados), 
fornecendo uma descrição das características dos 
dados e de relacionamentos� Um sistema de geren-
ciamento de banco de dados (SGBD) é composto de 
uma coleção de programas que permite a definição, 
construção e manipulação do banco de dados� A 
seguir, exploramos mais detalhadamente alguns 
pontos�
10
TERMOS COMUNS EM 
BANCO DE DADOS
Os bancos de dados têm um conjunto de termos 
técnicos (ALVES, 2014), do qual abordaremos os 
principais aqui:
 ● Campo (ou atributo): menor unidade de armaze-
namento de valores existente em uma tabela de um 
banco de dados; pode conter apenas um tipo de 
dado� Cada campo em uma tabela recebe um nome 
de identificação e seus atributos (a especificação 
do tipo de dado que será armazenado e o tamanho 
para armazenamento). 
 ● Registro (ou linha) também chamado de tuplas 
ou n-uplas: conjunto de campos de uma tabela que 
forma a unidade básica tanto para o armazenamento 
quanto para a recuperação de dados, identificando 
um único item de informação em uma tabela do 
banco de dados� Todos os registros de uma tabela 
de dados são do mesmo tipo, mas os campos que 
o constituem podem ser de diferentes tipos e tama-
nhos. Assim, a definição do formato dos registros é 
realizada durante o processo de estruturação das 
tabelas do banco de dados�
 ● Tabela de dados: conjunto ordenado de registros; 
cada tabela estrutura-se de modo a conter somente 
um tipo de informação� Assim, cada uma, dentro de 
umbanco de dados, deve ser identificada por um 
único nome�
11
 ● Índices: em um banco de dados, os índices permi-
tem que os registros possam ser encontrados com 
mais rapidez� Um índice pode ser simples, quando 
constituído por apenas um campo, ou composto, 
quando constituído por vários campos da tabela�
 ● Chave primária: atributo de uma tabela que per-
mite identificar de maneira única os registros, de-
terminando sua ordem física� O uso de uma chave 
primária evita a duplicidade de registros, além de 
melhorar a velocidade da pesquisa� Assim como 
os índices, uma chave primária pode ser simples ou 
composta� Para escolher a chave primária, devemos 
considerar dois critérios:
a) Se a chave for simples, devemos escolher um 
campo cujo tamanho não seja grande; se a chave 
for composta, devemos considerar o menor número 
possível de campos�
b) O valor armazenado não pode ser modificado. 
Dessa forma, os campos que formam as chaves 
primárias têm seu preenchimento obrigatório�
 ● Chaves candidatas: campos pertencentes à tabela 
de dados que podem ser utilizadas como chaves 
primárias�
 ● Chaves estrangeiras: chaves que permitem relacio-
nar registros de uma tabela com os de outra tabela 
de dados por meio da sua chave primária�
 ● Domínio: seus objetivos são definir os tipos de da-
dos e especificar os valores que podem ser aceitos 
pelos campos nas tabelas de dados�
12
TIPOS DE BANCO DE 
DADOS
Considerando alguns critérios, podemos classificar 
um banco de dados por número de usuários supor-
tados simultaneamente, localização física, modelo 
de dados adotado, grau de estruturação dos seus 
dados, entre outros. A partir da classificação por 
número de usuários, temos um banco de dados mo-
nousuário, quando apenas um usuário tem suporte 
por vez, ou um banco de dados multiusuário, quando 
vários usuários têm suporte ao mesmo tempo (ROB; 
CORONEL, 2011).
Em relação à classificação por localização, consi-
deramos o local onde o SGBD e o próprio banco de 
dados estão armazenados (ALVES, 2014). Quando 
um SGBD e o banco de dados estão localizados em 
um único local (também conhecido como servidor 
de banco de dados), temos um banco de dados cen-
tralizado. Quando o SGBD e o banco de dados estão 
distribuídos em diferentes locais e todos interligados 
em rede, temos um banco de dados distribuído�
Quanto à classificação pelo modelo de dados ado-
tado, isto é, no qual se baseia o SGBD, temos o se-
guinte: um modelo de dados é uma representação 
simples e normalmente gráfica de estruturas de 
dados mais complexas, facilitando a compreensão 
(ALVES, 2014). Na sequência, vamos aprender quais 
tipos de modelo existem�
13
No modelo de dados hierárquico, encontramos uma 
organização estrutural semelhante a uma árvore, for-
mada por tipos de registros e seus relacionamentos� 
O registro é uma coleção de valores que representam 
informações a despeito de uma entidade de um re-
lacionamento� Esses relacionamentos são do tipo 
pai-filho, sendo os registros que antecedem outros 
na hierarquia são denominados pai, já os registros 
que os sucedem são chamados filhos�
A princípio, o modelo de dados em rede é parecido 
com o modelo de dados hierárquico, com a diferença 
de que o em rede permite que um registro possa ter 
vários relacionamentos, pois elimina a hierarquia e 
dá acesso direto a determinado registro (nó da rede). 
Este modelo possui duas estruturas básicas: os re-
gistros, que contêm dados relacionados e agrupados 
em tipos de registros que armazenam os mesmos 
tipos de informações; e os conjuntos, que são a for-
ma de representação dos relacionamentos entre os 
diversos tipos de registros�
O modelo de dados relacional foi criado por Edgar 
Frank Codd em 1968 na IBM. Quando do desen-
volvimento deste modelo, Codd utilizou a teoria de 
conjuntos e a álgebra relacional, baseando-se na 
organização dos dados em tabelas (ou relações), 
formadas por linhas e colunas, permitindo a reali-
zação de operações entre essas tabelas�
Anos mais tarde, década de 1980, surge o modelo 
de dados orientado a objetos. Este modelo define 
um banco de dados por meio de objetos com suas 
14
propriedades e operações, atendendo à necessidade 
de armazenamento e processamento dos tipos de 
dados mais complexos, como os dados de sistemas 
de geoprocessamento e sistemas CAD/CAE/CAM, 
imagens de satélites etc�
No tocante ao grau de estruturação dos dados, 
temos o seguinte: os dados podem ser classifica-
dos em não estruturados, semiestruturados e es-
truturados (ROB; CORONEL, 2011). Os dados não 
estruturados são os que estão em estado original, 
no formato em que foram coletados, dificultando o 
processamento para a produção de informações� Os 
dados semiestruturados são aqueles que foram par-
cialmente processados� Os dados estruturados são 
provenientes do resultado da obtenção de dados não 
estruturados e de sua formatação, facilitando tanto 
seu armazenamento quanto seu processamento na 
geração de informações�
Arquiteturas de banco de dados
No decorrer do tempo, além dos vários modelos de 
banco de dados, também surgiram várias propostas 
de arquitetura com o intuito de auxiliar os projetos 
de sistemas de computador em camadas, conforme 
sua função ou prioridade� Nesse contexto, surgem 
alguns tipos de arquiteturas, analisadas a seguir�
A arquitetura centralizada concentrava nos main-
frames o processamento de funções do sistema, 
aplicações, programas de interface, entre outros 
15
programas e funcionalidades do SGBD. Os sistemas 
eram acessados pelos usuários via terminais de com-
putadores que apenas exibiam os resultados, sem 
processamento local, pois tudo era realizado nos 
mainframes, que, após processar o dado solicitado, 
enviava ao terminal as informações a serem exibidas 
e os controles (Figura 3):
Terminal Terminal Terminal
Mainframe Banco de 
Dados
Figura 3: Arquitetura centralizada: mainframe e terminais. Fonte: 
Elaboração própria.
Com o surgimento dos computadores pessoais (PC), 
a gradativa queda nos preços do hardware e a po-
pularização de novas tecnologias de comunicação 
de dados, os usuários foram substituindo paulatina-
mente os terminais de computadores (sem proces-
samento local) por computadores pessoais (com 
processamento local).
Tais mudanças resultaram no aparecimento da ar-
quitetura cliente-servidor de duas camadas, a qual 
possibilitou passar parte do processamento para o 
lado cliente (máquinas dos usuários), ou seja, pro-
gramas de interface e aplicação passaram a realizar 
seus processamentos localmente, mas sempre que 
16
precisam acessar o banco de dados, estabelecem 
uma conexão com o programa servidor que viabiliza 
o acesso aos dados via SGBD (Figura 4):
Computador Computador Computador
Servidor Banco de 
Dados
Figura 4: Arquitetura cliente-servidor em duas camadas. Fonte: 
Elaboração própria.
À medida que a internet apareceu e a World Wide 
Web se expandiu, novas necessidades vieram à tona, 
culminando no surgimento da arquitetura cliente-
-servidor de três camadas� Neste tipo de arquitetura, 
existe uma camada intermediária entre a máquina, 
o cliente e o servidor de banco de dados, chamada 
de servidor de aplicação (ou servidor Web), cujo ob-
jetivo é armazenar as regras de negócios, utilizadas 
para ter acesso aos dados no servidor de banco de 
dados (Figura 5).
Computador Computador Computador
Servidor
Aplicação 
ou Web
Servidor de 
Banco de 
Dados
Banco de 
Dados
Figura 5: Arquitetura cliente-servidor em três camadas. Fonte: 
Elaboração própria.
17
Na arquitetura distribuída, temos bancos de dados 
distribuídos através de uma rede de computadores, 
mas que estão logicamente inter-relacionados� O 
sistema de gerenciamento de banco de dados dis-
tribuído (SGBDD) tem o papel de gerenciar os ban-
cos de dados distribuídos, bem como o de tornar a 
distribuição e as transações transparentes para o 
usuário (Figura 6).
Computador
Servidor de 
Banco de 
Dados
Banco de 
Dados
Computador
Servidor de 
Banco de 
Dados
Banco deDados
Computador
Servidor de 
Banco de 
Dados
Banco de 
Dados
Figura 6: Arquitetura distribuída. Fonte: Elaboração própria.
Existem dois tipos de banco de dados distribuídos: 
os homogêneos, compostos por um único tipo de 
banco de dados; e os heterogêneos, compostos por 
mais de um tipo de banco de dados�
18
SAIBA MAIS
Saiba mais sobre o armazenamento de dados e 
sua evolução, assistindo a História do armazena-
mento de dados: trabalho de CAP, que se encontra 
disponível em: https://youtu.be/C87AKC4VQ3s� 
Acesso em: 14 nov. 2019.
19
https://youtu.be/C87AKC4VQ3s
ABSTRAÇÃO DE DADOS: 
MODELOS CONCEITUAL, 
LÓGICO E FÍSICO
Um modelo de banco de dados pode ser definido 
como um detalhamento, utilizando-se de descrições 
textuais, de gráficos ou diagramas, dos tipos de infor-
mações que devem ser armazenadas no banco de da-
dos que se deseja projetar� Isso permite a construção 
de um modelo de dados estruturado e consistente 
com níveis de abstração distintos, auxiliando o en-
tendimento dos usuários e dos diversos profissionais 
envolvidos no projeto�
Os níveis de abstração podem ser o modelo concei-
tual, o modelo lógico e o modelo físico�
O modelo conceitual descreve os dados e suas 
relações, que deverão ser armazenados no banco 
de dados, independentemente do SGBD. A aborda-
gem Entidade-Relacionamento é uma das técnicas 
utilizadas na construção de um modelo de dados 
conceitual, fazendo uso do diagrama Entidade-
Relacionamento, para representar as entidades (ob-
jetos do mundo real), seus atributos (características 
ou propriedades) e os relacionamentos (interações) 
entre entidades�
O modelo lógico possui um maior detalhamento da 
estrutura das tabelas (nome e definição das colunas) 
e seus respectivos relacionamentos, que compõem 
o banco de dados� Dessa forma, passa-se a ter uma 
20
dependência do tipo de SGBD a ser utilizado na im-
plementação, que vai depender de a abordagem ser 
relacional, hierárquica, de rede, orientada a objetos, 
entre outras� Nesse ponto, ainda não há referência a 
características particulares de cada atributo�
O modelo físico possui todo o detalhamento da es-
trutura física para a implementação do banco de 
dados por meio de um SGBD. A definição da estru-
tura do banco de dados é realizada por meio de uma 
linguagem declarativa, como a DDL (Linguagem de 
Definição de Dados) presente no SQL.
21
PROJETO DE BANCO DE 
DADOS
O processo de desenvolvimento de um banco de 
dados envolve um conjunto de fases: levantamento e 
análise das necessidades, projeto conceitual, projeto 
lógico e projeto físico, conforme ilustrado na Figura 7.
Visão Externa 1 Visão Externa n
Modelo conceitual
Modelo lógico
Modelo físico
Dependente do SGBD
Independente do SGBD
requisitosrequisitos
Banco de 
Dados
Figura 7: Projeto Top down de uma base de dados. Fonte: Adaptada 
de Guimarães (2003).
Partindo-se de uma parcela da realidade (minimun-
do), a qual se deseja informatizar, devemos realizar 
(ALVES, 2014):
a) Levantamento e análise das necessidades: por 
meio da utilização de diversas técnicas (entrevistas, 
22
reuniões, questionários etc.) somada à participação 
de cliente e usuários, procura-se entender, documen-
tar e especificar um conjunto de requisitos de dados 
e também de todos os requisitos funcionais, que são 
as operações que a aplicação deve executar sobre 
os dados�
b) Projeto conceitual: com base nos requisitos 
especificados na fase anterior, cria-se um modelo 
conceitual que contém uma descrição dos tipos de 
entidades, relacionamento e restrições� Esse tipo de 
modelo deve ter um alto nível de abstração, como o 
Modelo Entidade-Relacionamento (MER), cujo esque-
ma conceitual é denominado de Diagrama Entidade-
Relacionamento (DER).
c) Projeto lógico: com base no projeto conceitu-
al, nesta etapa é preciso descrever mais detalha-
damente as estruturas que são armazenadas, qual 
abordagem de banco de dados é a mais adequada 
(relacional, hierárquica, de rede...) e definir em qual 
SGBD se faz sua implementação.
d) Projeto físico: esta é a etapa em que se define 
toda a estrutura de armazenamento interno, bem 
como o método de acesso aos arquivos do banco 
de dados; além disso, nesta etapa são projetados os 
programas que posteriormente manipularão esses 
dados.
23
MODELO ENTIDADE-
RELACIONAMENTO
A modelagem conceitual tem por objetivo atingir uma 
descrição de alto nível, independentemente da sua 
implementação em computador, dos dados que serão 
armazenados no banco de dados. Em 1976, Peter 
Chen propôs uma forma gráfica e resumida de mo-
delagem conceitual, denominada Modelo Entidade-
Relacionamento, que, por meio de um conjunto de 
diagramas entidade-relacionamento (DER), descreve 
os dados e seus inter-relacionamentos�
Os conceitos principais da abordagem entidade-rela-
cionamento são entidade, relacionamento, atributo, 
generalização/especialização, entidade associati-
va e notação gráfica utilizada para representar os 
elementos�
24
ENTIDADE
Uma entidade representa um conjunto de objetos 
pertencentes à realidade a ser modelada, cujas 
características ou propriedades desejamos regis-
trar, podendo ter uma existência física ou abstrata 
(Figuras 8).
Figura 8. Entidades com existência física (à esquer-
da) e abstrata (à direita).
Cachorro Departamento
Carro Disciplina
Figura 8: Fonte: Elaboração própria.
25
ATRIBUTOS
Cada entidade possui um conjunto de características 
importantes, dentro do contexto, e que precisam ser 
registrados, os atributos. Todo atributo tem nome 
e valor específicos. Em um projeto, quando surge a 
necessidade de registrar os atributos de várias en-
tidades do mesmo tipo, criamos agrupamentos das 
entidades similares em um conjunto de entidades 
(CE), dando-lhe um nome significativo para identificá-
-lo, sendo que cada entidade em um CE possui a 
mesma lista de atributos, com os valores variando 
de uma entidade para outra�
Quando especificamos um CE, temos que levar em 
consideração o conceito de atributo determinante 
ou atributo chave� Trata-se de um dos atributos do 
próprio CE projetado para identificar de forma única 
qualquer entidade do CE� Dessa forma, um CE se ca-
racteriza no MER, dado o nome do CE, os nomes dos 
atributos do CE e o nome do atributo determinante 
(atributo sublinhado), utilizando-se uma forma textu-
al� Por exemplo, Pessoa(cpf, nome, data_nascimento, 
endereço, línguas)�
Podemos classificar os atributos de uma entidade 
da seguinte maneira:
 ● Atributo simples: armazena dado de um único 
tipo. Não se pode dividir (atômicos), como o atribu-
to data_nascimento�
 ● Atributo composto: pode ser subdivido em partes 
menores e ter tipos diferentes, como o atributo en-
26
dereço, que pode ser subdivido nos atributos tipo_lo-
gradouro, nome_logradouro, número, bairro e cep�
 ● Atributo monovalorado: admite somente um valor 
para o atributo, por exemplo o atributo nome, que 
admite o valor “João José da Silva”�
 ● Atributo multivalorado: admite vários valores para 
o atributo, como o atributo línguas, que admite os 
valores “português”, “espanhol” e “inglês”�
 ● Atributo derivado: pode conter valores derivados 
de outros atributos, como exemplo o atributo idade, 
que será calculado a partir do atributo data_nasci-
mento e a data atual�
 ● Atributo nulo: admite somente o valor nulo�
Observemos agora alguns exemplos desses atributos 
na Figura 9:
Pessoa
tipo_logradouro
nome_logradouro
númeroendereço
cpf
nome
línguas (1,n)
bairro
cep
Figura 9: Entidade Pessoa e seus atributos. Fonte: Elaboração própria.
27
RELACIONAMENTOS
Segundo Guimarães e Lages (2008), um relaciona-
mento entre dois conjuntos de entidades é uma lista 
de pares de entidades, na qual cada par representa 
uma associação entre uma entidade de um CE com 
outra entidade do outro CE, estabelecendo uma re-
lação de interdependência entre essas entidades�
Em um relacionamento entre duas entidades, o nú-
mero de ocorrências de uma entidade associado 
às ocorrências de outra entidade determinao grau 
do relacionamento ou a cardinalidade do relacio-
namento� Dessa forma, temos três possibilidades 
de relacionarmos os dados, ou seja, três graus de 
relacionamento:
Relacionamento 1 para 1 (ou 1:1): este tipo de rela-
cionamento acontece quando uma entidade de um 
conjunto de entidades só pode se associar a uma 
única entidade de outro conjunto de entidades e vice-
-versa (Figura 10):
Pessoa BicicletaPossui
(1,1)(1,1)
Figura 10: Relacionamento 1:1. Fonte: Elaboração própria.
28
 ● Relacionamento 1 para N (ou 1:N): este tipo de 
relacionamento acontece quando várias entidades 
de um conjunto de entidades só podem se associar 
a única entidade de outro conjunto de entidades� No 
sentido contrário, uma única entidade de um conjunto 
de entidades pode se associar a várias entidades do 
outro conjunto de entidades (Figura 11):
Departamento FuncionárioPossui
(1,n)(1,1)
sentido de leitura
sentido de leitura
Figura 11: Relacionamento 1:N. Fonte: Elaboração própria.
 ● Relacionamento N para N (ou N:N): este tipo de 
relacionamento ocorre quando uma entidade de um 
conjunto de entidades pode estar associada a várias 
outras entidades de outro conjunto de conjunto de 
entidades e vice-versa (Figura 12):
Estudante DisciplinaEstuda
(1,n)(1,n)
Figura 12: Relacionamento N:N. Fonte: Elaboração própria.
Os relacionamentos também podem ter atributos da 
seguinte forma (Figura13):
29
Funcionário Departamento
data
Gerência
(1,1)(1,1)
Figura 13: Relacionamento com atributo. Fonte: Elaboração própria.
Em alguns casos, temos a necessidade de fazer o 
relacionamento de um conjunto de entidades consigo 
mesmo, processo denominado autorrelacionamento 
(Figura 14).
Funcionário Supervisiona
supervisor
supervisionado
(1,1)
(1,n)
Figura 14: Autorrelacionamento. Fonte: Elaboração própria.
Os relacionamentos também podem ter restrições: 
razão de cardinalidade, restrição de participação e 
restrição estrutural�
A razão de cardinalidade é um tipo de restrição que 
determina quantas vezes uma entidade pode parti-
cipar de um relacionamento� A restrição de partici-
pação, por sua vez, estabelece a existência de uma 
entidade com a dependência de outra por meio do 
relacionamento entre elas, no caso de uma restrição 
de participação total, todas as entidades devem sa-
30
tisfazer a condição imposta no relacionamento e, no 
caso de uma restrição de participação parcial, ape-
nas parte das entidades participa do relacionamento� 
A restrição estrutural determina os valores mínimos 
e máximos de participações de uma entidade em um 
relacionamento�
Analisando os conjuntos de entidades e seus rela-
cionamentos, podemos encontrar casos em que a 
existência de um conjunto de entidades está condi-
cionada à existência de outro conjunto de entidades� 
Neste caso, um conjunto de entidades é denomina-
do conjunto de entidades fraco quando depende da 
existência de um conjunto de entidades forte� Um 
conjunto de entidades fraco não tem um atributo 
determinante e, em geral, utiliza o atributo determi-
nante do conjunto de entidades forte para gerar o 
seu atributo determinante (Figura 15).
Funcionário DependentePossui
(0,n)(1,1)
Figura 15: Entidade forte e entidade fraca. Fonte: Elaboração própria.
Outro conceito importante que podemos encontrar 
na abordagem entidade-relacionamento é o de gene-
ralização/especialização� Tal conceito nos permite 
atribuir propriedades particulares a um subconjunto 
das ocorrências (especializadas) de um conjunto 
de entidades (CE) genérico. Como complemento ao 
conceito de generalização/especialização, podemos 
pensar na ideia de herança, pois cada ocorrência do 
31
CE especializada além de suas próprias proprieda-
des (atributos, relacionamentos e generalizações/
especializações), também possui as propriedades da 
ocorrência do CE genérico correspondente, conforme 
mostrado na Figura 16.
Filme
Filme Estrangeiro Filme Nacional
Figura 16: Generalização/Especialização. Fonte: Elaboração própria.
Pode-se classificar o conceito de generalização/es-
pecialização em dois tipos: total ou parcial� Na gene-
ralização/especialização total, para cada ocorrência 
do CE genérico há sempre uma ocorrência em um 
CE especializada�
Na generalização/especialização parcial, nem toda 
ocorrência do CE genérico possui uma ocorrência 
correspondente em um CE especializada� Em relação 
ao número de níveis hierárquicos da generalização/
especialização, não há limites, pois um CE especia-
lizada em uma generalização/especialização pode 
ser um CE genérico em outra generalização/espe-
cialização, sendo possível, inclusive, que um mesmo 
32
CE seja especialização de diversos CEs genéricos, 
remetendo à ideia de herança múltipla, ilustrada na 
Figura 17.
Veículo
Veículo Terrestre Veículo Aquático
Veículo Anfíbio BarcoCaminhão
Figura 17: Generalização/Especialização. Fonte: Adaptada de Heuser 
(2008).
Podcast 1 
Na abordagem entidade-relacionamento, não se con-
templa a possibilidade de associar um CE ao seu 
relacionamento, nem mesmo associar dois relacio-
namentos entre si� No entanto, ao se construir ou 
modificar um diagrama entidade-relacionamento, é 
possível surgir condições nas quais seja desejável a 
associação de um CE a um relacionamento ou entre 
relacionamentos� Para que esse tipo de operação fos-
se permitido na abordagem entidade-relacionamento, 
33
https://famonline.instructure.com/files/407280/download?download_frd=1
desenvolveu-se o conceito de entidade associativa 
(Figura 18).
(1,n)
(0,n)
(0,n)
(1,n)
Medicamento
PacienteMédico
Prescrição
Consulta
Consultas
Figura 18: Entidade associativa. Fonte: Adaptada de Heuser (2008).
34
DIAGRAMA ENTIDADE-
RELACIONAMENTO
A construção do diagrama entidade-relacionamento 
envolve alguns passos:
a) Descrição detalhada das operações e a desco-
berta das regras de negócio de uma organização�
b) Identificação inicial das entidades, relaciona-
mentos principais e a construção de um diagrama 
entidade-relacionamento inicial�
c) Identificação de atributos, a determinação do atri-
buto determinante (chave primária) e a cardinalidade 
dos relacionamentos�
d) R e v i s ã o e a n á l i s e d o d i a g r a m a 
entidade-relacionamento�
Podcast 2 
Para a identificação das entidades, dos relaciona-
mentos e dos atributos nos diversos documentos que 
especificam os requisitos, podemos utilizar um con-
junto de regras estabelecidas por Peter Chen, quando 
da criação do modelo entidade-relacionamento e 
do diagrama entidade-relacionamento� Analisemos 
alguns exemplos dessas regras:
a) Entidades: são identificadas por substantivos.
b) Relacionamento: é identificado por verbos 
transitivos�
35
https://famonline.instructure.com/files/407281/download?download_frd=1
c) Atributos de uma entidade: são identificados por 
adjetivos�
d) Atributos de um relacionamento: são identifica-
dos por advérbios�
Quando da construção do diagrama entidade-relacio-
namento, normalmente se usa uma representação 
gráfica dos elementos do modelo entidade-relaciona-
mento proposta por Peter Chen. Observe a Figura 19.
Símbolo Significado
Tipo de Entidade
Tipo de Entidade-Fraca
Tipo de Relacionamento
Tipo de Relacionamento 
Identificador
Atributo
Atributo-Chave
Atributo Multivalorado
Atributo Composto
Atributo Derivado
Participação Total de E2 em R
Razão de Cardinalidade 1:N para 
E1:E2 em R
Restrição Estrutural (min, max) na 
participação de E em R
(min, max)
1
E1 E2
E1
R E
E2
R
R N
Figura 19: Resumo da notação gráfica proposta por Peter Chen. Fonte: 
Adaptada de Alves (2014).
36
As representações gráficas utilizadas neste texto 
correspondem às descritas por Heuser (2008) e 
que foram implementadas na ferramenta brModelo 
(Figura 20).
Conceito Símbolo
Tipo de Entidade
Relacionamento
Atributo
Atributo indicador
Relacionamento 
identificador
Generalização/ 
especialização
Entidade associativa
(U)
Figura 20: Resumo da notação gráfica utilizada. Fonte: Adaptada de 
Heuser (2008).
37
Duranteo processo de revisão e análise, existe a 
possibilidade da descoberta de novas entidades, atri-
butos e relacionamentos, que serão incorporados ao 
diagrama entidade-relacionamento existente� Dessa 
maneira, as atividades serão repetidas até que pro-
jetistas e usuários finais concordem que o diagrama 
entidade-relacionamento representa adequadamente 
a estrutura do banco de dados a ser implementado�
38
CONSIDERAÇÕES FINAIS
Neste texto, apresentamos uma visão geral sobre 
banco de dados com uma breve apresentação his-
tórica sobre os sistemas de arquivos e sistema de 
banco de dados� Estabelecemos conceitos básicos 
sobre dados, informação, banco de dados e sistemas 
de gerenciamento de banco de dados (SGBD), bem 
como a terminologia� Também apresentamos, sucin-
tamente, os tipos e arquiteturas de banco de dados 
e do conceito de abstração de dados (modelos con-
ceitual, lógico e físico). Nesse ponto, aproveitamos e 
descrevemos as fases do projeto de banco de dados�
Em relação à Modelagem Entidade-Relacionamento, 
apresentamos em detalhes seus principais elemen-
tos (entidade, relacionamento e atributos) e des-
crevemos breve e objetivamente os passos para a 
construção do diagrama entidade-relacionamento�
39
SÍNTESE
– Neste e-book, apresentamos uma breve visão histórica da evolução dos meios de 
armazenamento de dados, desde os primórdios das sociedades primitivas, passando 
por sistemas de arquivos e sistemas de banco de dados� Em seguida, abordamos 
conceitos importantes como dados, informação, banco de dados e sistemas de 
gerenciamento de banco de dados (SGBD), esclarecendo as diferenças entre eles�
– Estudamos, ainda, um conjunto de termos utilizados na área de banco de dados, os 
quais nos dão base para diversos assuntos tratados� Depois, os tipos e arquiteturas 
mais utilizados de banco de dados, bem como o conceito de abstração de dados 
(modelos conceitual, lógico e físico)�
– No projeto de banco de dados, fizemos uma breve apresentação das etapas para o 
desenvolvimento de um projeto de banco de dados� Finalizamos com a apresentação 
dos objetivos da utilização do modelo entidade-relacionamento e de seus 
componentes, visando à construção de diagramas entidade-relacionamento�
ESTRUTURA E 
MODELAGEM DE DADOS
MODELAGEM DE DADOS
Referências Bibliográficas 
& Consultadas
ALVES, W. P. Banco de Dados: teoria e desenvolvi-
mento. São Paulo: Érica, 2014.
ASCENCIO, A. F. G.; ARAÚJO, G. S. Estruturas 
de dados: algoritmos, análise da complexidade 
e implementações em JAVA e C/C++. São Paulo: 
Pearson Prentice Hall, 2010 [Biblioteca Virtual].
ELMASRI, R.; NAVATHE, S. B. Sistema de banco 
de dados. 6. ed. São Paulo: Pearson Addison-
Wesley, 2010 [Biblioteca Virtual].
GUIMARÃES, A. M.; LAGES, N. A. C. Algoritmos 
e estruturas de dados. Rio de Janeiro: LTC, 2008.
GUIMARÃES, C. C. Fundamentos de Bancos de 
Dados: modelagem, projeto e linguagem SQL. 
Campinas: Editora da Unicamp, 2003.
HEUSER, C. A. Projeto de banco de dados. 6. ed. 
Porto Alegre: Bookman, 2008 [Minha Biblioteca].
MEDEIROS, L. F.; Banco de dados: princípios e 
prática. Curitiba: InterSaberes, 2013 [Biblioteca 
Virtual].
PUGA, S.; FRANÇA, E.; GOYA, M. Banco de da-
dos: implementação em SQL, PL/SQL e Oracle 11g. 
São Paulo: Pearson Education do Brasil, 2013 
[Biblioteca Virtual].
RAMAKRISHNAN, R.; GEHRKE, J. Sistemas de 
gerenciamento de banco de dados. 3. ed. Porto 
Alegre: AMGH, 2008 [Minha Biblioteca].
ROB, P.; CORONEL, C. Sistemas de banco de da-
dos: projeto, implementação e gerenciamento. 8. 
ed. São Paulo: Cengage Learning, 2011.
TENENBAUM, A. M.; LANGSAM, Y.; 
AUGENSTEIN, M. J.; Estruturas de dados usando 
C. São Paulo: Pearson Makron Books, 2010.
	_GoBack
	INTRODUÇÃO
	BANCO DE DADOS: UMA VISÃO GERAL
	EVOLUÇÃO HISTÓRICA
	DADO, INFORMAÇÃO, BANCO DE DADOS E SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS
	Termos comuns em banco de dados
	Tipos de banco de dados
	Arquiteturas de banco de dados
	Abstração de Dados: Modelos Conceitual, Lógico e Físico
	PROJETO DE BANCO DE DADOS
	MODELO ENTIDADE-RELACIONAMENTO
	ENTIDADE
	Atributos
	Relacionamentos
	DIAGRAMA ENTIDADE-RELACIONAMENTO
	CONSIDERAÇÕES FINAIS
	Síntese