Você está na página 1de 27

APOSTILA DE

BANCO DE
DADOS I

2015/01

SUMRIO
1 INTRODUO .......................................................................................................................... 3
O que so Dados? ................................................................................................................... 3
O que Informao? .............................................................................................................. 3
O que Banco de Dados? ....................................................................................................... 3
O que Transao em Banco de Dados? ................................................................................. 5
2 HISTRICO............................................................................................................................... 6
O INCIO DO ARMAZENAMENTO DE DADOS............................................................................... 6
O que um Sistema Gerenciador de Banco de Dados? ........................................................... 7
3 MODELOS DE BANCO DE DADOS ............................................................................................. 8
Modelo Hierrquico ................................................................................................................ 8
Modelo de Rede ..................................................................................................................... 9
Modelo Relacional .................................................................................................................. 9
Modelo Orientado a Objetos................................................................................................. 10
Resumo ................................................................................................................................ 10
4 MODELAGEM DE DADOS ....................................................................................................... 12
O que um Modelo de Dados? ............................................................................................. 12
MODELO CONCEITUAL ............................................................................................................. 12
MODELO LGICO ..................................................................................................................... 14
MODELO FSICO ....................................................................................................................... 15
Quais so as fases de um projeto de Banco de Dados?.......................................................... 15
Modelagem Conceitual: ........................................................................................................ 15
Modelagem Lgica:............................................................................................................... 15
Projeto Fsico: ....................................................................................................................... 15
Lista de Questes ................................................................................................................. 16
5 MODELAGEM CONCEITUAL ................................................................................................... 17
DOMNIO ................................................................................................................................. 17
Entidade .................................................................................................................................. 18
Atributo ................................................................................................................................ 19
RELACIONAMENTO .................................................................................................................. 21
CARDINALIDADE DE RELACIONAMENTOS ................................................................................ 21
Cardinalidade mxima .......................................................................................................... 21
Classificao de relacionamentos binrios ............................................................................ 22
Cardinalidade mnima ........................................................................................................... 24
Exemplo de uso de entidades e relacionamentos .................................................................. 24
Lista de Questes ................................................................................................................. 25
Entidade Associativa ............................................................................................................. 26

Faculdade de Engenharia de Software

U N I D A D E

1 INTRODUO
O que so Dados?
Dados so itens referentes a uma descrio primria de objetos, eventos, atividades e
transaes que so gravados, classificados e armazenados, mas no chegam a ser organizados de
forma a transmitir algum significado especfico.
Os dados compreendem os fatos conhecidos em sua forma primria, que podem ser
armazenados e que servem de base para a resoluo de um problema.
Dado qualquer elemento identificado em sua forma bruta que, por si s, no conduz a uma
compreenso de determinado fato ou situao.

O que Informao?
Os dados teis o que chamamos de informao. E esses dados so o que armazenamos em
uma base de dados.
Informao um conjunto de fatos organizados de tal forma que adquirem valor adicional (o
conhecimento), alm do valor do fato em si.
Exemplos:
Dado: data de nascimento: 16/07/69.
Informao: idade: 41 anos.
Dado: soma de preo unitrio x quantidade.
Informao: valor total da fatura: R$2.500,00.
Por conveno, na rea de banco de dados, os termos dado e informao significam a
mesma coisa. Isso ocorre porque devemos armazenar apenas aquilo que til para a nossa aplicao.
Sendo assim, daqui para a frente, os dois termos sero usados como sinnimos.
O que Banco de Dados?
Alguns exemplos de banco de dados: lista telefnica, controle do acervo de uma biblioteca, sistema de controle dos
recursos humanos de uma empresa.

H uma grande necessidade em se realizar o armazenamento de informaes que no se


encontram isoladas umas das outras. Alm de uma forma adequada para definir o armazenamento
destas informaes, os usurios desejam realizar operaes sobre esta coleo de dados, tais como,
adicionar (inserir) novos dados, recuperar (consultar) um determinado subconjunto de dados,
atualizar ou modificar a estrutura dos dados e eliminar informaes no mais necessrias.
Uma soluo para este problema foi apresentada com o advento da tecnologia em Bancos de
Dados (Bases de Dados, BD, Database em Ingls, Bases de Donnes em Francs, Bases de Datos em
Espanhol, Databaser em Russo). Uma definio mais precisa de Banco de Dados no existe
formalmente contudo pode-se dizer que:

Prof. Joo Graciano

Faculdade de Engenharia de Software

a). Um Banco de Dados uma coleo logicamente coerente de dados com um determinado
significado inerente. Isto significa que um conjunto aleatrio de dados no pode ser considerada um
Banco de Dados.
b). Um Banco de Dados projetado, construdo e composto por um conjunto de dados para
um propsito especfico. Existe um grupo de usurios ou algumas aplicaes pr-concebidas onde
estes dados sero utilizados.
c). Um Banco de Dados representa aspectos de uma parte restrita do mundo real, denominado
de mini-mundo. Alteraes que ocorra no mini-mundo so refletidas no Banco de Dados.
Resumindo, um BD representa uma fonte de onde informaes so derivadas, possui um nvel
de interao com eventos que ocorrem no mundo real, e uma audincia que est interessada em seu
contedo.
Alm do conceito de BD, outros esto so necessrios para se compreender o ambiente de um
BD . Um Sistema de Gerenciamento de Bancos de Dados (SGBD) uma coleo de programas que
permite ao usurio definir, construir e manipular Bancos de Dados para as mais diversas aplicaes.
Definir um BD envolve a especificao e a descrio detalhada dos tipos de dados a serem
armazenados.
Construir um BD o processo de armazenamento dos dados em si em um determinado meio
fsico que controlado pelo SGBD.
Manipular um BD inclui uma srie de funes para se realizar operaes de consulta,
atualizaes e remoes de dados do BD.
O Banco de Dados e seu software so juntos denominados de Sistema de Bancos de Dados
(SBD).
Armazenar dados em bancos de dados apresenta algumas vantagens, tais como:
Os bancos de dados armazenam dados substituindo grandes volumes de papis.
A obteno e a atualizao dos dados acontecem de forma mais rpida do que um ser humano
manipulando papis.
Os sistemas de bancos de dados realizam o trabalho repetitivo e montono.
Disponibilizam dados atualizados a qualquer momento.
A tecnologia dos bancos de dados permite a manipulao rpida e segura de grandes volumes
de dados.

Um banco de dados serve para:


Armazenar grandes volumes de dados.
Localizar e atualizar rapidamente os dados.
Organizar os dados em diferentes ordens.
Produzir listas ou relatrios.
Gerar estatsticas.
Um banco de dados formado por vrios registros e, principalmente, os bancos de dados que
compem grandes sistemas so integrados e compartilhados.

Um banco de dados integrado quando armazena dados de diversos arquivos em um s. Com


isso praticamente eliminada a duplicidade de dados (redundncia). Veremos o conceito de
redundncia mais adiante.
Observe o exemplo:

Prof. Joo Graciano

Faculdade de Engenharia de Software

No sistema de uma instituio financeira existem vrios arquivos, como, por exemplo, aquele
que armazena os dados cadastrais dos clientes (nome, endereo, cidade, UF, CEP, RG, CPF, etc.) e o
que armazena as operaes realizadas por cada cliente (depsitos, saques, aplicaes, etc.). Esse
arquivo de operaes necessita identificar o cliente que realizou determinada operao, mas no
necessrio que ele armazene todos os dados do cliente, pois aconteceria redundncia de dados. Ele
necessita somente de alguma informao que identifique o cliente (por exemplo, o nmero da conta
corrente) e, a partir dessa informao, possvel conseguir os dados do cliente acessando o outro
arquivo.
Um banco de dados compartilhado quando permite que vrios usurios acessem e
compartilhem simultaneamente os mesmos dados. Esse compartilhamento s possvel porque o
banco de dados integrado (todos os dados integrados em um nico local).
Mesmo com a integrao dos dados, pode ser que ocorra alguma redundncia de dados entre
arquivos diferentes (ou at mesmo seja desejada alguma redundncia, para efeito de segurana, em
caso de perda de dados). Aceitando o fato de que alguma redundncia possa ocorrer, o que deve ser
evitado a qualquer custo a inconsistncia dos dados, ou seja, os mesmos dados sobre determinado
assunto, armazenados em mais de um local, apresentem valores diferentes.
O que Transao em Banco de Dados?
Uma transao uma operao realizada com um banco de dados (gravao, leitura,
atualizao, excluso, etc.). Algumas questes ligadas s transaes so: atomicidade, consistncia e
durabilidade. Observe um exemplo da transferncia de materiais de um estoque para outro:

Se ocorrerem falhas que interrompam o processo de atualizao de valores de estoque, o


sistema deve manter os valores antigos. Este o princpio da atomicidade.
Se a transao for completada sem problemas, a soma das quantidades existentes em estoque
do produto transferido (nos dois estoques), antes e depois da transao, deve ser a mesma.
Este o princpio da consistncia.
Alm disso, as novas quantidades de estoque devem se manter, mesmo que ocorram falhas
depois de terminada a transao. Este o princpio da durabilidade.

Prof. Joo Graciano

Faculdade de Engenharia de Software

2 HISTRICO
O INCIO DO ARMAZENAMENTO DE DADOS
No incio, os dados eram armazenados em fichas de papel, escritos manualmente ou com
auxlio de mquinas de escrever. Com o passar do tempo, a quantidade de fichas aumentou muito,
dificultando a recuperao dos dados armazenados. A partir dos anos de 1960, a tecnologia dos
sistemas de computao comeou a ser usada para armazenar os dados. As primeiras aplicaes
comerciais que utilizavam banco de dados eram voltadas para determinados setores da empresa. Os
bancos de dados eram baseados diretamente nos processos realizados pelo setor. O desenvolvimento
fez vrios setores passarem pelo processo de informatizao, portanto foram construdos diversos
sistemas isolados e cada programa tinha os seus arquivos prprios e independentes, como mostra a
figura 1.

Figura 1 Sistema com aplicaes e arquivos isolados

Esse tipo de sistema apresentava o grande problema da redundncia de dados. Em primeiro


lugar, dois setores diferentes poderiam utilizar os mesmos dados, portanto eram necessrios arquivos
diferentes com os mesmos dados, o que poderia causar inconsistncia desses dados. Para resolver
esse problema, eliminou-se a duplicidade, utilizando a integrao dos dados. Ou seja, dados sobre a
mesma entidade passaram a ser armazenados em um nico arquivo acessados por todas as
aplicaes, como mostra a figura 2.

Figura 2 Arquivo integrado

Apesar de resolver o problema da redundncia, essa integrao dos dados ocasionou outro
problema: vrias aplicaes passaram a compartilhar os mesmos dados integrados em um nico
arquivo, utilizando a mesma representao. Assim, quando uma aplicao necessitava alterar a
estrutura do arquivo compartilhado (por exemplo, acrescentar um novo campo ao arquivo), todas as
Prof. Joo Graciano

Faculdade de Engenharia de Software

aplicaes que compartilhavam os dados do arquivo eram afetadas, e tinham de ser alteradas. Se as
aplicaes no fossem alteradas, no conseguiriam mais acessar os dados.
Como soluo para esse novo problema, surgiu a ideia de separar as aplicaes dos arquivos
de dados, colocando um gerenciador para realizar a comunicao entre ambos. Esse gerenciador
recebeu o nome de Sistema Gerenciador de Banco de Dados (SGBD), conforme ilustra a figura 3.

Figura 3 Sistema gerenciador de banco de dados

Nessa configurao, os dados so armazenados em um depsito geral (evitando


redundncia e inconsistncia e implantando a integrao dos dados) e cada aplicao acessa os dados
necessrios ao seu funcionamento de forma independente, mas compartilhando os mesmos dados
que outras aplicaes. Quem realiza a tarefa de gerenciamento desses acessos aos dados o SGBD.
Assim, um dos principais objetivos de um sistema gerenciador de banco de dados viabilizar a
independncia entre aplicaes e os dados que elas utilizam.
O que um Sistema Gerenciador de Banco de Dados?
A programao de aplicaes em computadores sofreu profundas modificaes desde seus
primrdios. No incio, usando linguagens como COBOL, Basic, C e outras, os programadores
incorporavam em um programa toda funcionalidade desejada. O programa continha as operaes da
interface de usurio, as transformaes de dados e clculos, as operaes de armazenamento de
dados, bem como as tarefas de comunicao com outros sistemas e programas.
Com o tempo, foram sendo identificadas funcionalidades comuns a muitos programas. Por
exemplo, hoje, a grande maioria dos programas comunica-se com os usurios atravs de interfaces
grficas de janelas. Entretanto, normalmente, os programas no contm todo o cdigo referente
exibio dos dados na interface, mas utilizam gerenciadores de interfaces de usurio, conjuntos de
rotinas que incluem as funcionalidades que um programador vai necessitar frequentemente ao
construir uma interface de usurio. Da mesma forma, para comunicar-se com processos remotos, os
programas usam gerenciadores de comunicao. Para manter grandes repositrios compartilhados de
dados, ou seja, para manter bancos de dados, so usados sistemas gerenciadores de banco de dados.
Sistema gerenciador de banco de dados (SGBD)=Software que incorpora as funes de definio, recuperao e
alterao de dados em um banco de dados.

Essa modularizao de programas tem vrias vantagens. Amanuteno de programas torna-se


mais simples, pois uma separao clara de funes facilita a compreenso dos programas. A
produtividade dos programadores tambm aumenta, j que os programas ficam menores, pois usam
funes j construdas.
Os SGBDs permitem que aplicaes diferentes possam acessar os mesmos dados ao mesmo
tempo, o que implica a necessidade de mecanismos de proteo contra alteraes erradas ou
consultas a dados por pessoas no autorizadas.
Prof. Joo Graciano

Faculdade de Engenharia de Software

Em um processamento de arquivos, as aplicaes (e os usurios) fazem acesso direto aos


dados armazenados, mas com os SGBDs o processo diferente. As aplicaes devem solicitar ao
SGBD os dados que desejam manipular, o SGBD recupera esses dados do disco e os apresenta para as
aplicaes. Isso garante um bom nvel de segurana no acesso aos dados, pois no existe acesso fsico
direto por meio das aplicaes, o que poderia causar danos aos dados armazenados.
possvel compreender o SGBD como sendo um interpretador de uma linguagem de
consulta utilizada pelos programas, para buscar, armazenar, excluir ou alterar os dados armazenados,
criando um ambiente eficiente para essas operaes.
Alm disso, os SGBDs devem dar suporte a vrias tarefas, tais como:

Definir e manipular dados.


Otimizar e executar comandos especficos.
Cuidar da recuperao de dados perdidos.
Monitorar o desempenho dos bancos de dados.

Os SGBDs so projetados para gerenciar grandes quantidades de dados, por isso permitem a
definio das estruturas de armazenamento dos dados e os mecanismos para manipulao desses
dados. Com isso oferecem um controle centralizado dos dados armazenados. Algumas vantagens
dessa centralizao so:

Reduzir a redundncia dos dados, apesar de que, em alguns casos, a redundncia pode ser
aceita (ou mesmo necessria) para efeito de melhoria de desempenho. Claro que para existir
redundncia necessrio um controle muito grande dela para que no exista inconsistncia.
Evitar a inconsistncia dos dados utilizando procedimentos de controle e verificao que
evitem que erros em aplicaes gerem dados conflitantes.
Compartilhamento de dados.
Manuteno da integridade dos dados, garantindo que os dados armazenados so corretos.
Por exemplo, no caso de duas pessoas acessarem um sistema de estoque simultaneamente e
solicitarem quantidades da mesma pea, o SGBD no deve permitir que as duas transaes
sejam realizadas, se no existir quantidade suficiente de peas para atender os dois pedidos.
Alm disso, os SGBDs devem manter imagens anteriores modificao, pois em caso de
falhas possvel recuperar os dados originais.
Aplicao de polticas de segurana para garantir que dados importantes no sero perdidos
por aes voluntrias ou involuntrias dos usurios ou por falhas de aplicao ou de
equipamentos. Outro aspecto relacionado segurana a privacidade dos dados
armazenados, ou seja, o SGBD deve controlar o acesso dos usurios aos dados, permitindo
somente determinadas aes ou barrando completamente o acesso aos dados.
Fornecimento de suporte a transaes, ou seja, permitir que as aplicaes ou usurios possam
realizar operaes de incluso, excluso, alterao, consulta e outras com os dados
armazenados.

3 MODELOS DE BANCO DE DADOS


Os sistemas gerenciadores de banco de dados podem ser classificados de diversas maneiras,
como por modelo de dados, por numero de usuarios, por localizacao, entre outros.
Ao classifica-los por modelos de dados, obtemos as seguintes classificaes:
Modelo Hierrquico
Este modelo de banco de dados e descrito por um diagrama de estrutura de arvore, com dois
componentes bsicos: as caixas correspondentes aos tipos de registro e as linhas que representam as
ligaes entre os tipos de registro. Pode ser representado diretamente quando os dados so definidos
Prof. Joo Graciano

Faculdade de Engenharia de Software

com relacionamentos hierrquicos, isto e, um segmento raiz, localizado no topo da estrutura, que se
relaciona com outros segmentos de cima para baixo, da esquerda para a direita, denominado de
diagrama de estrutura de dados ou de arvore (relacionamento do topo para baixo e das folhas para
dentro).
Este modelo se tornou vivel quando a estrutura dos discos de armazenamento se tornou
enderevel, possibilitando a representao hierrquica das informaes coma utilizao do
endereamento fsico daqueles dispositivos. Todos os bancos de dados apresentam vantagens e
desvantagens em sua utilizao, e com o banco de dados modelo hierrquico no e diferente. Ele e
um modelo bastante simplificado, representa naturalmente sistemas que possuem uma hierarquia
bem definida, no representando sistemas que no possuem tais caractersticas, alm de aumentar
os ndices de redundncia (duplicidade), possuir tempos de consulta e processamento
reconhecidamente altos.
Modelo de Rede
Pode ser visto como uma extenso mais completa do modelo hierrquico, apenas livre das
dificuldades encontradas no modelo anterior. Os controles existentes quanto aos recursos de
armazenamento, estrutura e caminhos utilizados para navegar de um registro a outro tornam o
modelo de rede mais completo.
O banco de dados em rede e composto de uma estrutura mais completa, possui as
propriedades bsicas de registros, conjuntos e ocorrncias, e utiliza a linguagem de definio de
banco de dados (DDL) e a linguagem de manipulao de dados (DML), alm de permitir uma evoluo
mais eficiente do modelo.
A estrutura e formada de entidade (registros), atributos (itens de dados), tipos de registros e
ocorrncia do registro. Tanto no modelo hierrquico quanto o de rede so chamados de sistemas de
navegao, pois as aplicaes devem ser construdas para atravessar um conjunto de registros
interligados previamente.
A maior vantagem do modelo de rede frente ao hierrquico e um melhor controle sobre a
redundncia de dados.
Modelo Relacional
O banco de dados mais utilizado atualmente e o banco de dados relacional, principalmente
pelas suas fortes caractersticas de seguranas, compartilhamento e integridade dos dados, fatores
primordiais para uma administrao eficaz da informao de qualquer empresa.
Com o prprio nome diz, esse tipo de banco de dados e composto de relaes entre entidades,
denominadas tabelas, seguindo o mesmo conceito matemtico de relao. As tabelas se relacionam
por meio de chaves denominadas estrangeiras, que podem ser simples, formadas por apenas um
atributo, ou compostas, formadas por vrios atributos. Por atributo compreende-se a representao
de um tipo de informao.
Para que um modelo seja considerado relacional, os dados devem ser armazenados em
tabelas, nenhum ponteiro ou ligao deve ser visvel ao usurio, a linguagem de consulta deve ser
relacionalmente completa e as consultas podem ser expressas sem uso de iteraes ou recurses.
Cada linha da tabela, formada por um conjunto de colunas, representa um registro (ou tupla).
Os registros no precisam necessariamente conter dados em todas as colunas, ou seja, seus valores
podem ser nulos.
Prof. Joo Graciano

Faculdade de Engenharia de Software

As colunas de uma tabela so tambm chamadas de campos. Os campos possuem


caractersticas que definem o dado que ser armazenado. Os sistemas de banco de dados possuem
normas que iro reger os dados que so armazenados.
Em um banco de dados pode existir uma ou centenas de tabelas. O limitador imposto
exclusivamente pela ferramenta computacional ou SGBD utilizado.
Cada coluna de uma tabela obedece as regras definidas na sua criao. Cada coluna recebe um
tipo de dado, que representa o conjunto de valores que podem ser armazenados em cada uma das
colunas. Basicamente, cada coluna representa o tipo de cada dado, ou seja, as regras de entrada dos
dados, evitando a incompatibilidade. J as linhas representam todos os dados cadastrados, ou seja,
um conjunto de colunas ou campos. As linhas representam o nmero de registros cadastrados na
tabela e as colunas representam os tipos de dados ou campos cadastrados.
Alguns campos da tabela, alm do tipo de dados, possuem uma propriedade adicional. Esses
campos recebem o nome de chave.
Existem dois tipos de chaves: chave primria (E a chave que identifica cada registro, dandolhe unicidade. Essa chave nunca de se repetira dentro da estrutura da tabela) e chave estrangeira
(E a chave formada pela chave primaria de outra tabela e a chave de um campo da tabela externa que
recebe o relacionamento. Essa chave, de forma resumida, define um relacionamento entre as tabelas
e pode ocorrer repetidas vezes).
Modelo Orientado a Objetos
Trata-se basicamente de um sistema em que a unidade de armazenamento e vista como um
objeto, ou seja, ela tem propriedades e no campos. A principal caracterstica desse tipo de banco de
dados e a abstrao dos dados. Combina os benefcios e conceitos da programao orientada a
objetos com a funcionalidade dos banco de dados. A vantagem e a lgica contida no objeto e a
possibilidade de ser reutilizado vrias vezes em diversas aplicaes.
Resumo
Banco de Dados - Representa o arquivo fsico de dados, armazenado em dispositivos
perifricos, onde esto armazenados os dados de diversos sistemas, para consulta e
atualizao pelo usurio.
Tabelas Lgicas - Representam as estruturas de armazenamento de dados (arquivos) dos
sistemas.
S.G.D.B. (Sistema Gerenciador de Banco de Dados) - o software responsvel pelo
gerenciamento (armazenamento e recuperao) dos dados no Banco de Dados.
Dado - o valor do campo quando armazenado no Banco de Dados. Ex. O valor do campo
"nome do cliente" para quem est fazendo a entrada de dados.
Contedo do campo - o valor do campo armazenado no Banco de Dados. Ex. O valor do
campo "nome do cliente" sem estar, momentaneamente, sendo utilizado.
Informao - o valor que este campo representa para as atividades da empresa. Ex.
Resposta a uma consulta. Qual os nomes do clientes localizados no Rio de Janeiro?
Modelo de Banco de Dados: Modelo Relacional, Modelo Hierrquico e Modelo em Rede.
Representa a estrutura fsica no qual o armazenamento dos dados foram projetados.

Prof. Joo Graciano

10

Faculdade de Engenharia de Software

O modelo identifica a estrutura interna de recuperao e armazenamento dos dados


no qual o SGBD foi projetado.

Prof. Joo Graciano

11

Faculdade de Engenharia de Software

4 MODELAGEM DE DADOS
O que um Modelo de Dados?
Um modelo de (banco de) dados uma descrio dos tipos de informaes que esto
armazenadas em um banco de dados. Por exemplo, no caso de um sistema de vendas, o modelo de
dados poderia informar que o banco de dados armazena informaes sobre produtos e que, para cada
produto, so armazenados seu cdigo, descrio e preo. Observe que o modelo de dados no
informa quais os produtos que esto armazenados no banco de dados, mas apenas que o banco de
dados contm informaes sobre produtos.
Modelo de dados = Descrio formal da estrutura de um banco de dados.

Para construir um modelo de dados, usa-se uma linguagem de modelagem de dados.


Linguagens de modelagem de dados podem ser classificadas de acordo com a forma de apresentar
modelos, em linguagens textuais ou linguagens grficas. Existem linguagens de modelagem para
descrever modelos de dados em diferentes nveis de abstrao e com diferentes objetivos. Cada
representao de um modelo de dados atravs de uma linguagem de modelagem de dados recebe a
denominao esquema de banco de dados.
De acordo com a inteno do modelador, um banco de dados pode ser modelado (descrito)
em vrios nveis de abstrao. Um modelo de dados que servir para explicar a um usurio leigo em
informtica qual a organizao de um banco de dados provavelmente no conter detalhes sobre a
representao em meio fsico das informaes. J um modelo de dados usado por um tcnico para
otimizar a performance de acesso ao banco de dados conter mais detalhes de como as informaes
esto organizadas internamente e, portanto, ser menos abstrato
Assim como possvel construir modelos de dados em vrios nveis de abstrao, tambm
possvel usar diferentes tcnicas, aplicando diferentes conceitos ao construir modelos. Ao conjunto de
conceitos usados na construo de um modelo denominamos abordagem de modelagem.

MODELO CONCEITUAL
Representa e descreve a realidade do ambiente do problema, constituindo-se em uma viso
global dos principais dados e seus relacionamentos (estruturas de informao), completamente
independente dos aspectos de sua implementao tecnolgica. Quando falamos em modelo
Prof. Joo Graciano

12

Faculdade de Engenharia de Software

conceitual, estamos nos referindo aquela que deve ser a primeira etapa de um projeto de um banco
de dados.
O objetivo do modelo conceitual e descrever de forma simples e facilmente compreendida
pelo usurio final as informaes de um contexto de negcios, as quais devem ser armazenadas em
um banco de dados. E uma descrio de alto nvel, mas que tem a preocupao de captar e retratar a
realidade de uma organizao, processo de negcio, setor, repartio, departamento, etc.
Devemos destacar que o modelo conceitual no retrata nem e vinculado aos aspectos ligados
a abordagem de banco de dados que ser utilizado e tampouco se preocupa com as formas de acesso
ou estruturas fsicas implementadas por SGBD especifico.
O resultado de um modelo conceitual e um esquema grfico que representa a realidade das
informaes existentes em um determinado contexto de negcios, assim como as estruturas de
dados em que esto organizadas essas informaes.
O modelo conceitual nunca deve ser construdo com consideraes sobre processos de
negcios. O foco deve ser dirigido sempre ao entendimento e representao de uma realidade de um
contexto.
Um modelo conceitual uma descrio do banco de dados de forma independente de
implementao em um SGBD. O modelo conceitual registra que dados podem aparecer no banco de
dados, mas no registra como estes dados esto armazenados em nvel de SGBD.
Modelo conceitual = Modelo de dados abstrato, que descreve a estrutura de um banco de dados de
forma independente de um SGBD particular.

A tcnica de modelagem conceitual mais difundida a abordagem entidade relacionamento


(ER). Nesta tcnica, um modelo conceitual usualmente representado atravs de um diagrama,
chamado diagrama entidade-relacionamento (DER). A figura 5 apresenta um DER parcial para um
problema de uma loja de produtos de informtica.

Figura 5 Exemplo de modelo conceitual

Entre outras coisas, este modelo informa que o banco de dados contm dados sobre produtos
e sobre tipos de produtos. Para cada produto, o banco de dados armazena o cdigo, a descrio, o
preo, bem como o tipo de produto ao qual est associado. Para cada tipo de produto, o banco de
dados armazena o cdigo, a descrio, bem como os produtos daquele tipo.

Prof. Joo Graciano

13

Faculdade de Engenharia de Software

MODELO LGICO
Ele somente tem o seu incio aps a criao do modelo conceitual. O modelo logico descreve
em formato as estruturas que estaro no banco de dados de acordo com as possibilidades permitidas
pela sua abordagem, mas sem considerar, ainda, nenhuma caracterstica especifica de SGBD. Isso
resulta em um esquema logico de dados sob a tica de uma das abordagens citadas, atravs do
emprego de uma tcnica de modelagem de dados orientada as restries de cada abordagem.
Um modelo lgico uma descrio de um banco de dados no nvel de abstrao visto pelo
usurio do SGBD. Assim, o modelo lgico dependente do tipo de SGBD que est sendo usado.
Modelo lgico = Modelo de dados que representa a estrutura de dados de um banco de dados
conforme vista pelo usurio do SGBD

Nesta apostila, sero tratados apenas modelos lgicos referentes a SGBD relacional. Em um
SGBD relacional, os dados esto organizados na forma de tabelas. A Figura 6 mostra um exemplo de
BD relacional projetado a partir do modelo conceitual mostrado na Figura 5

Figura 6 Exemplo de tabelas de BD relacional

Um modelo lgico de um BD relacional deve definir quais as tabelas que o banco contm e,
para cada tabela, quais os nomes das colunas. O modelo lgico para o BD em questo o seguinte:

TipoDeProduto (CodTipoProd, DescrTipoProd)


Produto (CodProd, DescrProd, PrecoProd, CodTipoProd)
CodTipoProd referencia TipoDeProduto

O modelo lgico descreve a estrutura do banco de dados, conforme vista pelo usurio do
SGBD. Detalhes de armazenamento interno de informaes, que no tm influncia sobre a
programao de aplicaes no SGBD, mas podem afetar o desempenho das aplicaes (por exemplo,
as estruturas de arquivos usadas no acesso s informaes) no fazem parte do modelo lgico. Estes
detalhes so representados no modelo fsico. Modelos fsicos no so tratados nesta apostila. Eles so
usados apenas por profissionais que fazem sintonia de banco de dados, procurando otimizar o
desempenho. As linguagens e notaes para o modelo fsico no so padronizadas e variam de SGBD
a SGBD. A tendncia em produtos mais modernos esconder o modelo fsico do usurio e transferir a
tarefa de otimizao ao prprio SGBD.
importante destacar que somente possvel construir o modelo de dados aps todos os requisitos terem sido
levantados e analisados, ou seja, aps o conhecimento de todas as expectativas dos usurios. Este processo chamado
de Levantamento e Anlise de Requisitos.

Prof. Joo Graciano

14

Faculdade de Engenharia de Software

MODELO FSICO
O modelo fsico ser construdo a partir do modelo logico e descreve as estruturas fsicas de
armazenamento de dados, tais como:

Tipo e tamanho de campos;


ndices;
Domnio de preenchimento desses campos;
Nomenclaturas;
Exigncia de contedo;
Gatilhos; etc.

Estas so projetadas de acordo com os requisitos de processamento e uso mais econmico


dos recursos computacionais. Esse modelo detalha o estudo dos mtodos de acesso ao SGBD para a
criao dos ndices necessrios para cada informao colocada nos modelos conceitual e logico.
Quais so as fases de um projeto de Banco de Dados?
O projeto de um novo banco de dados d-se em trs fases, descritas a seguir:
Modelagem Conceitual:
A modelagem conceitual refere-se ao desenvolvimento de um modelo inicial da base de dados
que reflita as necessidades do usurio. Essa modelagem preocupa-se em descrever quais dados sero
armazenados na base de dados e quais dados se relacionam. Para fazer o modelo conceitual,
necessrio entender o que o usurio final espera que o sistema armazene e que informaes este
usurio espera que o sistema disponibilize (como por exemplo, relatrios). Para obter as informaes
necessrias para desenvolver a modelagem conceitual do sistema, devem-se realizar entrevistas com
o usurio para entender os objetivos do sistema e as expectativas que o usurio tem em relao a ele.
Um dos principais diagramas dessa etapa o DER (Diagrama Entidade-Relacionamento).
Modelagem Lgica:
A modelagem lgica compreende o processo de descrever como os dados sero armazenados
no sistema e como iro se relacionar. Isso significa transformar o modelo conceitual obtido na
primeira fase num modelo mais prximo da implementao, em um modelo lgico. Para banco de
dados relacionais, o modelo utilizado nessa fase o modelo relacional. Tambm necessrio
descrever o dicionrio de dados da base de dados nessa etapa. Antes da fase de implementao
necessrio, ainda verificar se o modelo est normalizado e em caso negativo deve-se normalizar o
modelo.
Projeto Fsico:
Na etapa de projeto fsico, o modelo do banco de dados enriquecido com detalhes que
influenciam no desempenho do banco de dados, mas no interferem em sua funcionalidade. O
modelo obtido nesse passo o modelo fsico do banco de dados. Alteraes neste modelo no afetam
as aplicaes que usam o banco de dados, j que o modelo no envolve aspectos funcionais do banco
de dados. Na prtica, o projeto fsico um processo contnuo, que ocorre mesmo depois de o banco
de dados j estar implementado e em funcionamento. Este processo normalmente chamado de
sintonia (tuning) de banco de dados.

Prof. Joo Graciano

15

Faculdade de Engenharia de Software

A fase de modelagem a principal etapa no desenvolvimento de uma base de dados. Por isso
muito importante que se dedique tempo e esforo no desenvolvimento de uma boa modelagem da
base de dados.
Lista de Questes
1.

Enumere as principais diferenas entre o desenvolvimento de software com arquivos


convencionais e o desenvolvimento de software com SGBD.

2.

Descreva quais as vantagens e desvantagens da utilizao de um SGBD.

3.

Explique quais as ocupaes (tarefas de pessoas) relacionadas com a manuteno do


funcionamento dos bancos de dados e suas atribuies.

4.

Discuta alguns tipos de funcionalidades de banco de dados, ferramentas e suas funes.

5.

Um tcnico em informtica juntamente com um futuro usurio definem formalmente que


informaes devero estar armazenadas em um banco de dados a ser construdo. O resultado
deste processo um modelo conceitual, um modelo lgico ou um modelo fsico?

6.

Um programador recebe um documento especificando precisamente a estrutura de um banco


de dados. O programador dever construir um software para acessar o banco de dados
atravs de um SGBD conforme esta estrutura. Esse documento um modelo conceitual, um
modelo lgico ou um modelo fsico?

7.

UML (Unified Modeling Language) um conjunto de conceitos usados para modelar um


software, que, entre outras coisas, serve para modelar bases de dados no nvel conceitual.
UML uma abordagem de modelagem de dados ou um modelo de dados?

8.

Crie uma lista de dados pessoais que voc acha necessrio para se ter em uma ficha de
cadastro.

Prof. Joo Graciano

16

Faculdade de Engenharia de Software

U N I D A D E

I I

5 MODELAGEM CONCEITUAL
A tcnica de modelagem de dados mais difundida e utilizada a abordagem entidade
relacionamento (ER). Nesta tcnica, o modelo de dados representado atravs de um modelo
entidade-relacionamento (modelo ER). Geralmente, um modelo ER representado graficamente
atravs de um diagrama entidade-relacionamento (DER). A abordagem ER foi criada em 1976 por
Peter Chen, podendo ser considerada como um padro de fato para a modelagem conceitual. Mesmo
as tcnicas de modelagem orientada a objetos, que tm surgido nos ltimos anos, como a UML,
baseiam-se nos conceitos da abordagem ER.
A abordagem relacional representa uma forma de descrever um banco de dados atravs de
conceitos matemticos simples: a teoria dos conjuntos.
Voltada, principalmente, a melhorar a viso dos dados pelos usurios, a abordagem relacional
faz com que os usurios vejam o banco de dados como um conjunto de tabelas bidimensionais,
originadas em linhas e colunas.
So conjuntos de dados vistos segundo um conjunto de TABELAS, e as operaes que as utilizam so feitas por
linguagens que o manipulam, no sendo procedurais, ou seja, manipulando conjuntos de uma s vez.

O conceito principal vem da teoria dos conjuntos atrelado a concepo de que no e relevante
ao usurio saber onde os dados esto nem como os dados esto (transparncia).
Os usurios manipulam estes objetos dispostos em linhas e colunas das tabelas que possuem
informaes sobre o mesmo assunto de forma estruturada e organizada.
Para lidar com estes objetos, o usurio conta com um conjunto de operadores e funes de
alto nvel, constantes na lgebra relacional.
A Teoria Relacional possui premissas que definem uma tabela de dados:

Cada uma das tabelas e chamada de relao;


O conjunto de uma linha e suas colunas e chamado tupla;
Cada coluna dessa tabela tem um nome e representa um domnio da tabela;
No ha duas linhas iguais;
Usamos nomes para fazer referncia as colunas;
Cada tabela tem um nome prprio, distinto de qualquer outra tabela no banco de dados.

DOMNIO
Representa o conjunto de valores atmicos admissveis de um componente (coluna) de uma
relao (tabela).
Exemplo

Telefone: conjunto de 10 digitos;


Idade_Empregado: 16 idade 70;
Departamentos: conjunto de departamentos de uma empresa.
A cada domnio est associado um tipo de dados ou formato.

Exemplo
Prof. Joo Graciano

17

Faculdade de Engenharia de Software

Telefone: (ddd) dddd-ddddd, onde d={0,1,2,3,4,5,6,7,8,9}


Idade_Empregado: nmero inteiro entre 16 e 70

Restries de domnio so estabelecidas determinando-se domnios de valores para cada


coluna de uma tabela. Normalmente so estabelecidos e definidos os valores que uma coluna de uma
tabela pode ter, isto e, o domnio da coluna. Permitem, por exemplo:

Verificar os valores inseridos em um banco de dados;


Testar consultas para garantir que as comparaes tinham sentido;
Em geral, o domnio e especificado por tipos primitivos de dados, tais como: interger, float,
char, date, Money, time, etc.

Tambm, podem ser descritos pela definio de subconjuntos de tipos primitivos ou de listas
enumeradas, ou seja, listas de valores possveis de existir na coluna.

ENTIDADE
O conceito fundamental da abordagem ER o conceito de entidade.
Entidade = Conjunto de objetos do mesmo tipo do mundo real e sobre os quais se pretende
armazenar dados.

Uma entidade representa um conjunto de objetos da realidade modelada. Como o objetivo de


um modelo ER modelar de forma abstrata um BD, interessa-nos somente os objetos sobre os quais
se deseja manter informaes. Vejamos alguns exemplos. No sistema de informaes de vendas que
usamos na unidade 1, alguns exemplos de entidades poderiam ser os produtos, os tipos de produtos,
as vendas ou as compras. J em um sistema de contas correntes, algumas entidades podem ser os
clientes, as contas correntes, os cheques e as agncias. Observe que uma entidade pode representar
tanto objetos concretos da realidade (uma pessoa, um automvel) quanto objetos abstratos (um
departamento, um endereo). Em um DER, uma entidade representada atravs de um retngulo
que contm o nome da entidade. Alguns exemplos so mostrados na figura 7.

Figura 7 - Representao grfica de entidades

Como dito acima, cada retngulo, cada entidade representa um conjunto de objetos sobre os
quais se deseja guardar informaes. Assim, no exemplo da figura 7, o primeiro retngulo designa o
conjunto de todas as pessoas sobre as quais se deseja manter informaes no banco de dados,
enquanto o segundo retngulo designa o conjunto de todos os departamentos sobre os quais se
deseja manter informaes. Caso seja necessrio referir um objeto particular (uma determinada
pessoa ou um determinado departamento) fala-se em ocorrncia de entidade. Mais recentemente,
por influncia da programao orientada a objetos, usa-se tambm o termo "instncia" de entidade.

Prof. Joo Graciano

18

Faculdade de Engenharia de Software

Atributo
Alm de uma entidade representar objetos do mundo real, ela tambm deve possuir um
conjunto de propriedades que a caracterize e a descreva, bem como aos seus objetos. A esse
conjunto de propriedades d-se o nome de atributos.
Atributo = Dado que associado a cada ocorrncia de uma entidade ou de um relacionamento.

Atributos so representados graficamente por uma elipse, conforme mostra a figura 8. A


figura expressa que cada ocorrncia de PESSOA tem associado exatamente um nome, uma data de
nascimento, um endereo e um telefone.
O nome dos atributos deve representar o que aquele atributo armazena.
Na prtica, muitas vezes os atributos no so representados graficamente, para no
sobrecarregar os diagramas, j que entidades podem possuir um grande nmero de atributos.
Prefere-se usar uma representao textual que aparece separadamente do diagrama ER.

Figura 8 Atributos de uma entidade

Pode-se tambm representar os atributos de uma entidade apenas indicando o nome de cada
atributo, os quais so ligados a entidade atravs de uma linha, conforme mostra a figura 8.1.

Figura 8.1 Atributos de uma entidade

Outro exemplo, para uma entidade chamada Cadeira, os possveis atributos dessa entidade
sero: nmero de pernas, cor, tamanho, peso, altura, tecido, etc.
Uma entidade deve ter ao menos dois atributos. Uma entidade que possui apenas um atributo
no entidade e esse nico atributo deveria estar em alguma outra entidade do modelo.
Todo atributo possui um tipo de dado que representa os valores permitidos para aquele
atributo. A esse tipo de dados d-se o nome de domnio do atributo. Por exemplo: o atributo "nmero
Prof. Joo Graciano

19

Faculdade de Engenharia de Software

de pernas" da entidade "Cadeira" do tipo inteiro, ou seja, s permite que sejam armazenados
valores inteiros para esse atributo.
Os tipos de dados dependem do SGBD que o desenvolvedor est utilizando. De forma geral,
todos os SGBD disponibilizam tipos de dados como: inteiro, caracter, real (ou float), data e hora.
Quando se define o tipo de um atributo, pode-se definir inclusive o tamanho mximo que o
atributo vai permitir armazenar. Por exemplo, o atributo "nome" do tipo caracter (500), ou seja,
armazena no mximo 500 caracteres.
Os atributos podem ainda ser divididos em 6 categorias: simples, compostos, monovalorado,
multivalorado, derivado e nulo. importante ressaltar que os atributos podem pertencer a mais de
uma categoria ao mesmo tempo. Isso significa que comum um nico atributo ser simples,
monovalorado e derivado ao mesmo tempo. A seguir, ser explicada e exemplificada cada uma das
categorias.
Atributo simples: o atributo indivisvel, que no pode ou no deve ser decomposto. Por
exemplo: "CPF", "numero da matrcula", "RG", "preo do produto", etc.
Atributo composto: o atributo que pode ser decomposto em outros atributos simples. Por
exemplo, o atributo "endereo" pode ser decomposto em "nome da rua", "nmero" e
"complemento".
interessante que atributos compostos sejam decompostos ainda no primeiro diagrama ER, uma vez que isso vai ter
que ocorrer obrigatoriamente no modelo relacional. Alguns atributos como, por exemplo, "nome do aluno" pode ser
classificado como simples ou composto dependendo da aplicao. Se na aplicao forem realizadas consultas pelo
sobrenome do aluno, interessante que este atributo seja decomposto em dois atributos simples: "primeiro nome" e
"sobrenome". Isso ocorre por questo de desempenho.

Atributo monovalorado: o atributo que permite apenas o armazenamento de um valor por


vez. Por exemplo, o atributo "CPF" monovalorado porque uma pessoa possui apenas um nmero de
CPF. Caso o CPF seja alterado ele substitudo pelo novo valor. Assim, uma pessoa nunca ter
cadastrado mais de um CPF no mesmo campo.
Atributo multivalorado: o atributo que permite armazenar mais de um valor ao mesmo
tempo no mesmo campo. Por exemplo, o atributo e-mail pode ser multivalorado uma vez que uma
pessoa possui, normalmente, mais de um endereo de e-mail.
O atributo multivalorado deve ser evitado sempre que possvel. No entanto, em situaes em que no possvel evitlo, ele deve ser representado no diagrama como multivalorado. Quando formos passar o DER para o Modelo Relacional,
vamos entender o que acontece com esse atributo. Outro ponto importante: quem determina se o atributo
multivalorado ou no, muitas vezes, o prprio usurio do sistema. No caso do exemplo do atributo "e-mail", o usurio
pode determinar que somente seja necessrio armazenar um e-mail e sendo assim o atributo deixa de ser multivalorado
e passa a ser monovalorado.
Valor nulo diferente de valor zero!!! O valor nulo (representado por null em banco de dados) significa que aquele
campo est vazio.

Atributo nulo: o atributo que permite que seja inserido um valor nulo para ele. Valor nulo
representa a inexistncia de um valor, ou seja, significa que o usurio no precisa cadastrar um valor
para o atributo e pode deix-lo vazio. Em algumas situaes, inevitvel que permitamos valores
nulos para os atributos. Vamos usar novamente o atributo "e-mail" como exemplo. Como nem todas
as pessoas possuem e-mail, esse atributo deve permitir valores nulos, porque se ele no permitir
algumas pessoas no podero se cadastrar ou tero que criar um e-mail para poder efetivar o
cadastro. Novamente o usurio quem, muitas vezes, vai definir se um atributo obrigatrio ou no.
Prof. Joo Graciano

20

Faculdade de Engenharia de Software

O valor nulo na base de dados pode levar o banco a ficar inconsistente e ter baixo
desempenho. Mesmo que o atributo no seja obrigatrio, interessante que ele receba um valor
padro (default) via aplicao ou via SGBD para evitar os valores nulos.
Atributo derivado: o atributo cujo valor para ele deriva de outro(s) atributo(s). Por exemplo,
suponha que a sua entidade se chame compra e que ela tenha os seguintes atributos: "nmero da
compra", "data da compra", "valor da compra", "percentual de desconto" e "valor da compra com o
desconto". O valor para este ltimo atributo calculado considerando-se o "valor da compra" e o
"percentual de desconto". Assim, esse atributo derivado porque seu valor deriva dos valores de
outros atributos e calculado automaticamente pela aplicao ou pelo SGBD.

RELACIONAMENTO
Uma das propriedades sobre as quais pode ser desejvel manter informaes a associao
entre objetos. Exemplificando, pode ser desejvel saber quais pessoas esto associadas a quais
departamentos em uma organizao. A propriedade de entidade que especifica as associaes entre
objetos o relacionamento.
Relacionamento = Conjunto de associaes entre ocorrncias de entidades.

Em um DER, um relacionamento representado atravs de um losango, ligado por linhas aos


retngulos representativos das entidades que participam do relacionamento. A Figura 9 apresenta um
DER contendo duas entidades, ALUNO e DISCIPLINA, e um relacionamento, CURSA.

Figura 9 Representao grfica de relacionamento

Este modelo expressa que o BD mantm informaes sobre:

um conjunto de objetos classificados como pessoas (entidade ALUNO);


um conjunto de objetos classificados como departamentos (entidade DISCIPLINA); e
um conjunto de associaes, cada uma ligando um departamento a uma pessoa
(relacionamento CURSA).

CARDINALIDADE DE RELACIONAMENTOS
Cardinalidade (mnima, mxima) de entidade em relacionamento = Nmero (mnimo, mximo) de
ocorrncias de entidade associadas a uma ocorrncia da entidade em questo atravs do relacionamento.

Para fins de projeto de banco de dados, uma propriedade importante de um relacionamento


a de quantas ocorrncias de uma entidade podem estar associadas a uma determinada ocorrncia
atravs do relacionamento. Esta propriedade chamada de cardinalidade de uma entidade em um
relacionamento. H duas cardinalidades a considerar: a cardinalidade mxima e a cardinalidade
mnima.
Cardinalidade mxima
Para exemplificar o conceito de cardinalidade, vamos retomar o exemplo da figura 9. Vamos
considerar as cardinalidades mximas descritas abaixo.

Entidade ALUNO tem cardinalidade mxima 1 no relacionamento CURSA.

Prof. Joo Graciano

21

Faculdade de Engenharia de Software

Isso significa que uma ocorrncia de ALUNO pode estar associada a no mximo uma
ocorrncia de CURSO ou, em outros termos, que um aluno pode estar cursando no mximo um curso.

Entidade CURSO tem cardinalidade mxima 35 no relacionamento CURSA.

Isso significa que uma ocorrncia de CURSO pode estar associada a no mximo 35 ocorrncias
de ALUNO ou, em outros termos, que um curso pode ter nele cursando no mximo 35 alunos.
Para o projeto de banco de dados, especialmente de bancos de dados relacionais, no
necessrio distinguir entre diferentes cardinalidades mximas maiores que um. Por este motivo,
apenas duas cardinalidades mximas so geralmente consideradas:

A cardinalidade mxima um (1); e


A cardinalidade mxima ilimitada, usualmente chamada de cardinalidade mxima "muitos" e
referida pela letra n.

Assim, no exemplo acima, diz-se que a cardinalidade mxima da entidade DISCIPLINA no


relacionamento CURSA n.
Em um DER, a cardinalidade mxima representada conforme indicado na Figura 10. Observe
a conveno usada. primeira vista, ela pode parecer pouco natural, j que a cardinalidade vai
anotada "do outro lado" do relacionamento ao qual se refere. Exemplificando, a cardinalidade
mxima da entidade ALUNO no relacionamento CURSA anotada junto ao smbolo da entidade
DISCIPLINA.

Classificao de relacionamentos binrios


A cardinalidade mxima pode ser usada para classificar relacionamentos binrios. Um
relacionamento binrio aquele cujas ocorrncias contm duas ocorrncias de entidade. Podemos
classificar os relacionamentos binrios em n:n, 1:n e 1:1. As figuras 11, 12 e 13 apresentam exemplos
de relacionamentos com cardinalidades mximas 1:1, 1:n e n:n, respectivamente. A seguir
comentamos a interpretao de alguns relacionamentos apresentados nestas figuras.
Na figura 11, no relacionamento CASAMENTO, as cardinalidades mximas expressam que uma
pessoa pode possuir no mximo um marido e que uma pessoa pode possuir no mximo uma esposa.
Mais precisamente, as cardinalidades expressam que uma instncia de pessoa pode estar associada
via relacionamento a no mximo uma instncia de pessoa no papel de esposa e vice-versa, uma

Prof. Joo Graciano

22

Faculdade de Engenharia de Software

instncia de pessoa pode estar associada via relacionamento a no mximo uma instncia de pessoa
no papel de marido.

Figura 11 Relacionamento 1:1

Observe que o relacionamento CASAMENTO (figura 11) tambm um relacionamento binrio,


apesar de envolver apenas uma entidade. O que determina o fato de o relacionamento ser binrio o
nmero de ocorrncias de entidade que participam de cada ocorrncia do relacionamento. De cada
ocorrncia de CASAMENTO participam exatamente duas ocorrncias da entidade PESSOA(um marido
e uma esposa).
A figura 12 mostra exemplos de relacionamentos 1:n. O relacionamento INSCRIO modela a
inscrio de alunos em uma universidade pblica, onde existe a restrio de um aluno estar inscrito
em no mximo um curso.
O relacionamento entre as entidades EMPREGADO e DEPENDENTE (figura 12) modela a
associao entre um empregado e seus dependentes para fins de imposto de renda. Neste caso, um
dependente pode estar associado a no mximo um empregado. Cabe observar que, no DER, no foi
anotado o nome do relacionamento. No caso de no DER no constar o nome do relacionamento, este
denominado pela concatenao de nomes das entidades participantes. Assim, neste caso, o
relacionamento denominado EMPREGADO DEPENDENTE.

Figura 12 Relacionamentos 1:N

O tipo menos restrito de relacionamento o de cardinalidade n:n. Afigura 13 apresenta alguns


relacionamentos deste tipo.

Figura 13 Relacionamentos N:N

Prof. Joo Graciano

23

Faculdade de Engenharia de Software

Cardinalidade mnima
Alm da cardinalidade mxima, outra informao que pode ser representada por um modelo
ER o nmero mnimo de ocorrncias de entidade associadas a uma ocorrncia de uma entidade
atravs de um relacionamento. Para fins de projeto de BD, consideram-se apenas duas cardinalidades
mnimas: a cardinalidade mnima 0 e a cardinalidade mnima 1.
A cardinalidade mnima 1 tambm recebe a denominao de "associao obrigatria", j que
ela indica que o relacionamento deve obrigatoriamente associar uma ocorrncia de entidade a cada
ocorrncia da entidade em questo. Com base na mesma linha de raciocnio, a cardinalidade mnima 0
recebe a denominao "associao opcional".
A cardinalidade mnima anotada no diagrama junto cardinalidade mxima, conforme
mostrado na figura 14. Nesta figura, aparece novamente o exemplo da alocao de empregados a
mesas. Aqui, a cardinalidade mnima usada para especificar que cada empregado deve ter a ele
alocada obrigatoriamente uma mesa (cardinalidade mnima 1) e que uma mesa pode existir sem que
a ela esteja alocado um empregado (cardinalidade mnima 0).

Figura 14 Cardinalidade mnima de relacionamento

Exemplo de uso de entidades e relacionamentos


A figura 15 apresenta um exemplo de um modelo ER mais abrangente que os anteriores,
envolvendo diversas entidades e relacionamentos. Como se v, um diagrama ER apresentado na
forma de um grafo. A distribuio dos smbolos de DER no papel totalmente arbitrria e no tem
maior significado do ponto de vista formal. Entretanto, para tornar o diagrama mais legvel comum
evitar cruzamentos de linhas. Para isso, a recomendao geral a posicionar os retngulos
representativos de entidades que participam de muitos relacionamentos no centro do diagrama.
O modelo da figura 15 uma parte do modelo de dados de um sistema de controle acadmico
de uma universidade fictcia. O modelo descreve o seguinte:

Deseja-se manter informaes sobre alunos, cursos, disciplinas e departamentos.


Alm disso, deseja-se manter informaes sobre a associao de alunos a cursos, de
disciplinas a cursos, de disciplinas a departamentos, bem como de disciplinas a suas disciplinas
pr-requisitos.
Atravs das cardinalidades expressa-se que:

Cada disciplina possui exatamente um departamento responsvel, e um departamento


responsvel por muitas disciplinas, inclusive por nenhuma. Note-se que, apesar de sabermos que os
departamentos em uma universidade existem para ser responsveis por disciplinas, especificamos a
cardinalidade mnima de DEPARTAMENTO em RESPONSVEL como sendo 0. Com isto admitimos a
possibilidade de existirem departamentos vazios. Esta cardinalidade foi especificada considerando o
estado do banco de dados imediatamente aps a criao de um novo departamento, bem como o
estado imediatamente aps a eliminao da ltima disciplina de um departamento. Da forma como a
restrio foi especificada, possvel incluir o departamento em uma transao, para, depois, em
transaes subsequentes, vincul-lo s disciplinas sob sua responsabilidade. Se tivesse sido
especificada a cardinalidade mnima "1", ao menos uma disciplina teria que ser vinculada ao
Prof. Joo Graciano

24

Faculdade de Engenharia de Software

departamento j na prpria transao de incluso do departamento. Como se observa da discusso


acima, para especificar as cardinalidades mnimas necessrio possuir conhecimento sobre a ordem
de execuo das transaes de incluso e excluso das entidades.
Uma disciplina pode possuir diversos pr-requisitos, inclusive nenhum. Uma disciplina pode
ser pr-requisito de muitas outras disciplinas, inclusive de nenhuma.
Uma disciplina pode aparecer no currculo de muitos cursos (inclusive de nenhum) e um curso
pode possuir muitas disciplinas em seu currculo (inclusive nenhuma).
Um aluno est inscrito em exatamente um curso e um curso pode ter nele inscritos muitos
alunos (inclusive nenhum).

Figura 15 DER para o controle acadmico de uma universidade]

Lista de Questes
1.

Mostre os nomes de cada elemento do diagrama abaixo:

2.

Descreva o que cardinalidade.

3.

Crie uma entidade que mantenha o cdigo, descrio, unidade, preo unitrio e fornecedor
para PRODUTO

Generalizao/Especializao
Alm de relacionamentos e atributos, propriedades podem ser atribudas a entidades atravs
do conceito de generalizao/especializao. A partir deste conceito possvel atribuir propriedades
particulares a um subconjunto das ocorrncias (especializadas) de uma entidade genrica. No DER, o
smbolo para representar generalizao/especializao um tringulo issceles, conforme mostra a
Prof. Joo Graciano

25

Faculdade de Engenharia de Software

Figura 16. A generalizao/especializao mostrada nesta figura expressa que a entidade CLIENTE
dividida em dois subconjuntos, as entidades PESSOA FSICA e PESSOAJURDICA, cada uma com
propriedades prprias.

Figura 16 Generalizao/especializao

Associada ao conceito de generalizao/especializao est a ideia de herana de


propriedades. Herdar propriedades significa que cada ocorrncia da entidade especializada possui,
alm de suas prprias propriedades (atributos, relacionamentos e generaliza- es/especializaes),
tambm as propriedades da ocorrncia da entidade genrica correspondente. Assim, segundo o DER
da figura 16, a entidade PESSOA FSICA possui, alm de seus atributos particulares, CPF e sexo,
tambm todas as propriedades da ocorrncia da entidade CLIENTE correspondente, ou seja, os
atributos nome e cdigo, o seu identificador (atributo cdigo), bem como o relacionamento com a
entidade FILIAL. Resumindo, o diagrama expressa que toda pessoa fsica tem como atributos nome,
cdigo, CPF e sexo, identificada pelo cdigo e est obrigatoriamente relacionada a exatamente uma
filial. Da mesma maneira, toda pessoa jurdica tem como atributos nome, cdigo, CNPJ e tipo de
organizao, identificada pelo cdigo e est obrigatoriamente relacionada a exatamente uma filial.
Entidade Associativa
Um relacionamento uma associao entre entidades. Na modelagem ER no foi prevista a
possibilidade de associar uma entidade com um relacionamento ou ento de associar dois
relacionamentos entre si. Na prtica, quando estamos construindo um novo modelo ER ou
modificando um modelo ER existente, surgem situaes em que desejvel permitir a associao de
uma entidade a um relacionamento. A ttulo de exemplo, considere-se o modelo da figura 17.

Figura 17 DER a ser modificado

Suponha que seja necessrio modificar este modelo da seguinte forma. necessrio saber que
medicamentos existem e que medicamentos foram prescritos em cada consulta. Para saber que
medicamentos existem, cria-se uma nova entidade, MEDICAMENTO. A questo agora : com que
entidade existente deve estar relacionada a nova entidade? Se MEDICAMENTO fosse relacionado a
MDICO, ter-se-ia apenas a informao de que mdico prescreveu que medicamentos, faltando a
informao do paciente que os teve prescritos. Por outro lado, se MEDICAMENTO fosse relacionado
PACIENTE, faltaria a informao do mdico que prescreveu o medicamento. Assim, deseja-se
relacionar o medicamento consulta, ou seja, deseja-se relacionar uma entidade (MEDICAMENTO) a
Prof. Joo Graciano

26

Faculdade de Engenharia de Software

um relacionamento (CONSULTA), o que no est previsto na abordagem ER. Para tal, foi criado um
conceito especial, o de entidade associativa. Uma entidade associativa nada mais que a redefinio
de um relacionamento, que passa a ser tratado como se fosse tambm uma entidade. Graficamente,
isso feito como mostrado na figura 18. O retngulo desenhado ao redor do relacionamento
CONSULTA indica que este relacionamento passa a ser visto como uma entidade (associativa, j que
baseada em um relacionamento). Sendo CONSULTA tambm uma entidade, possvel associ-la
atravs de relacionamentos a outras entidades, conforme mostra a figura.

Figura 18 Entidade associativa

Caso no se desejasse usar o conceito de entidade associativa, seria necessrio transformar o


relacionamento CONSULTA em uma entidade, que ento poderia ser relacionada a MEDICAMENTO,
conforme mostrado na figura 19.

Figura 19 Substituindo relacionamento por entidade

No modelo da figura, o relacionamento foi substitudo por uma entidade homnima, junto
com dois relacionamentos. Para manter a equivalncia com o modelo anterior (figura 18), uma
consulta est relacionada com exatamente um mdico e exatamente um paciente (a cardinalidade
mnima e mxima um). Uma consulta identificada pelo paciente e pelo mdico a ela ligados. Tendo
substitudo o relacionamento CONSULTA pela entidade, basta relacionar a entidade CONSULTA com a
entidade MEDICAMENTO.
Observe-se que o diagrama da figura 19 equivalente ao diagrama da figura 18. Equivalente
aqui significa que ambos geram o mesmo banco de dados relacional.

Prof. Joo Graciano

27