ESTRUTURA E

MODELAGEM
DE DADOS
César Torres Fernandes

E-book 1
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 Aplicação
Estoque Vendas

Sistema Operacional

Arquivos dados Arquivos dados

Estoque Vendas

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 Aplicação
Vendas Estoque

Sistema de Banco de dados

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
um banco 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 Servidor de
Banco de
Aplicação Banco de Dados
ou Web 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 Computador Computador

Servidor de Servidor de Servidor de

Banco de Banco de Banco de
Dados Dados Dados

Banco de Banco de Banco de

Dados Dados 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
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

requisitos requisitos
Modelo conceitual

Independente do SGBD
Modelo lógico
Dependente do SGBD

Modelo físico

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:

nome

tipo_logradouro

nome_logradouro

endereço número

bairro
Pessoa
cep

línguas (1,n)

cpf

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 determina o 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):

(1,1) (1,1)
Pessoa Possui Bicicleta

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):

sentido de leitura

(1,1) (1,n)
Departamento Possui Funcionário

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):

(1,n) (1,n)
Estudante Estuda Disciplina

Figura 12: Relacionamento N:N. Fonte: Elaboração própria.

Os relacionamentos também podem ter atributos da

seguinte forma (Figura13):

29
 (1,1) (1,1)
Funcionário Gerência Departamento

data

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).

supervisor

(1,1)

Funcionário Supervisiona
(1,n)

supervisionado

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).

(1,1) (0,n)
Funcionário Possui Dependente

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
Veículo Terrestre
Aquático

Caminhão Veículo Anfíbio Barco

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
desenvolveu-se o conceito de entidade associativa
(Figura 18).

Consultas
(1,n) (1,n)
Médico Consulta Paciente

(0,n)

Prescrição

(0,n)

Medicamento

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 do diagrama
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
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

E1 R E2 Participação Total de E2 em R

E1
1
R
N
E2 Razão de Cardinalidade 1:N para
E1:E2 em R

R
(min, max)
E
Restrição Estrutural (min, max) na
participação de E em R

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 (U)
identificador

Generalização/
especialização

Entidade associativa

Figura 20: Resumo da notação gráfica utilizada. Fonte: Adaptada de

Heuser (2008).

37
Durante o 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

ESTRUTURA E
MODELAGEM DE DADOS

MODELAGEM DE DADOS

– 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�
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.