326 BancodeDados PDF

Fundao Educacional de Fernandpolis
Apostila de Banco de Dados

Prof. Evandro A. Jardini
1 de fevereiro de 2006
Sumrio
1
Introduo
1.1 Sistema de Processamento de Arquivos . . . . .
1.2 Independncia de Dados . . . . . . . . . . . . .
1.3 Sistema Gerenciador de Banco de Dados (SGBD)
1.3.1 Caracterticas de um SGBD . . . . . . .
1.4 Motivao para SGBDs . . . . . . . . . . . . . .
1.4.1 Linguagens de acesso a um SGBD . . . .
1.4.2 Arquitetura de um SGBD . . . . . . . . .
1.5 Exerccios . . . . . . . . . . . . . . . . . . . . .
1.6 Bibliografia . . . . . . . . . . . . . . . . . . . .
O Modelo Entidade-Relacionamento
2.1 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Chave Primria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Atributos Multivalorados . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Atributos Compostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Atributo Derivado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Entidades Fracas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Atributos de Relacionamento . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Cardinalidade dos Relacionamentos . . . . . . . . . . . . . . . . . . . . .
2.4.3 Grau dos Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3.1 Relacionamentos Binrios . . . . . . . . . . . . . . . . . . . . .
2.4.4 Relacionamentos Ternrios . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.5 Auto-Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 MER Estendido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Generalizao e Especilizao . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1.1 Relacionamentos entre Entidades Especializadas . . . . . . . . .
2.5.1.2 Multiplas Especializaes . . . . . . . . . . . . . . . . . . . . .
2.5.1.3 Restries da Abstrao de Generalizao . . . . . . . . . . . .
2.5.2 Agregao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.2.1 1 Caso do uso de Agregao (Opcionalidade) . . . . . . . . . . .
2.5.2.2 2 Caso do uso de Agregao (Identificador em Relacionamento) .
2.5.2.3 3 Caso do uso de Agregao (indica tempo) . . . . . . . . . . .
2.6 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.1 Primeira Lista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
6
7
8
8
9
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
11
12
12
13
13
14
14
15
16
16
16
16
18
18
18
20
20
20
22
23
23
23
23
23
27
SUMRIO
O Modelo Relacional
3.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Domnios . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Relaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Chave no Modelo Relacional . . . . . . . . . . . . . . . . . .
3.4.1 Superchave . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 Chave . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.3 Chave Candidata . . . . . . . . . . . . . . . . . . . .
3.4.4 Restries de Integridade . . . . . . . . . . . . . . . .
3.4.4.1 Chave Estrangeira (Integridade Referencial)
3.4.4.2 Exemplos de Restries de Integridade . . .
3.5 Outros tipos de Restries . . . . . . . . . . . . . . . . . . .
3.6 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapeamento do Modelo ER para Modelo Relacional

4.1 Introduo . . . . . . . . . . . . . . . . . . . . . .
4.2 Mapeando Entidades . . . . . . . . . . . . . . . .
4.3 Entidades Fracas . . . . . . . . . . . . . . . . . .
4.4 Relacionamento Binrio com Cardinalidade 1:1 . .
4.5 Relacionamento Binrio com Cardinalidade 1:N . .
4.6 Relacionamento Binrio com Cardinalidade M:N .
4.7 Relacionamentos Ternrios . . . . . . . . . . . . .
4.8 Exemplo 1 . . . . . . . . . . . . . . . . . . . . . .
4.9 Atributos Compostos e Multivalorados . . . . . . .
4.10 Generalizao . . . . . . . . . . . . . . . . . . . .
4.11 Agregao . . . . . . . . . . . . . . . . . . . . . .
4.12 Exemplo 2 . . . . . . . . . . . . . . . . . . . .
4.13 Resumo dos 6 passos . . . . . . . . . . . . . . . .
4.14 Bibliografia . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Normalizao de Relaes
5.1 Introduo . . . . . . . . . . .
5.2 Normalizao de Relaes . .
5.3 Anomalias de Modificaes . .
5.4 Primeira Forma Normal . . . .
5.5 Dependncia Funcional . . . .
5.6 Segunda Forma Normal (2FN)
5.7 Terceira Forma Normal (3FN)
5.8 Exemplo Prtico . . . . . . . .
5.9 Exerccios . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
lgebra Relacional
6.1 Introduo . . . . . . . . . . . . . . . . .
6.2 Operao Selecionar ( ) . . . . . . . . .
6.3 A Operao Projetar ( ) . . . . . . . . .
6.4 A Operao Unio ( ) . . . . . . . . . .
6.5 A Operao Interseco de Conjuntos ( )
6.6 A Operao Diferena de Conjuntos (-) .
6.7 A Operao Produto Cartesiano (X) . . .
6.8 A Operao Juno Natural (|X|) . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
29
29
30
30
30
31
31
31
32
33
33
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
34
35
35
35
36
36
37
38
39
39
40
40
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
42
42
42
43
44
44
45
46
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
50
51
52
52
53
53
54
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
SUMRIO
6.9 A Operao Diviso ( ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.10 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Captulo 1
Introduo
Um Sistema Gerenciador de Banco de Dados (SGBD) constitudo por um conjunto de dados associados a
um conjunto de programas para acesso a esses dados. O conjunto de dados, comumente chamado de
banco de dados, contm informaes sobre uma empresa em particular. O principal objetivo de um SGBD
proporcinar um ambiente tanto conveniente quanto eficiente para a recuperao e armazenamento das
informaes do banco de dados.
SGBDs so projetados para gerir grandes volumes de informaes. Devem possuir mecanismos para definio e
manipulao de dados, alm de prover compartilhamento e segurana dos mesmos.
1.1 Sistema de Processamento de Arquivos

Como exemplo, considere a rea de um banco responsvel por todas as informaes de seus clientes e de suas
contas-poupana. Um modo de guardar as informaes no computador armazen-las em sistemas de
arquivos permanentes. Para o acesso aos dados foram desenvolvidos os seguintes mdulos de programas:
Programa para dbito e crdito na contabilidade.

Programa para incluir novos registros na contabilidade.

Programa parabalano da contabilidade.
A medida que surge na necessidade, outros mdulos so desenvolvidos.

Considere que os programas foram desenvolvidos em Pascal (poderiam ter sido desenvolvidos em Clipper, Cobol, Basic, etc) e que a estrutura do registro de cliente :
type Cliente = record
nome:string;
rua:string;
cidade:string;
cep;
end;
Neste Sistema de Processamento deArquivos que acabamos de descrever, os registros so armazenados em vrios
arquivos e diversos programas so escritos para extrair e gravar estes registros.
Obter informaes organizacionais em sistemas de processamento de arquivos apresenta numerosas desvantagens:
4
CAPTULO 1. INTRODUO
Redundncia e inconsistncia de dados: Redundncia a caracterstica onde um elemento de informao

aparece duplicado em diversos lugares. Por exemplo, um clientede uma empresa pode esta cadastrado
tanto na base de dados do departamento de crdito assim como no departamento de contabilidade. Esta
redundncia pode causa a inconsistencia, visto que as informaes podem ser diferentes para o mesmo
cliente.

Dificuldade no acesso aos dados: Suponha que um diretor necessite encontrar os clientes que residem em
uma rea da cidade onde o CEP seja 12133-433. Se este modulo do sistema de informao no estiver
implementado, o diretor ter duas opes: ele pega a lista de clientes e extrai a informao necessria, ou
pede para o departamento de informtica implementar a rotina necessria para obteno do relatrio.

Isolamento de dados: Uma vez que os dados esto espalhados em diversos arquivos e podem ter formatos
diferentes, difcil escrever novos programasaplicativos para recuperar os dados adequados.

Anomalia de acesso concorrente: Evitar problemas relacionados a acesso concorrentes em um dado. Por
exemplo, se duas pessoas sacarem dinheiro de uma conta ao mesmo tempo, o resultado das operaes
concorrentes podemdeixar um saldo inconsistente. Considere uma conta com a quantia de $400 e dois
saques simultneo de $100 e $50. Se houver problema de concorrncia, a conta pode ficar com valores de
$300 ou de $350 ao invs de $250

Segurana: Cada usurio do sistema poder ter acesso aos dados relativos a sua funo. Por exemplo, um
caixa no pode ver dados pertencentes as diretoria.

Problemas de Integridade: Os valores armazenados BD devem satisfazer certos tipos de restries de

consistncias. Por exemplo, um filho de um funcionrio no pode ser cadastrado sem que o pai trabalhe na
empresa.
1.2 Independncia de Dados

O desenho a seguir representa um sistema de processamento de arquivo tpico:
Arquivo de Cliente
Figura 1.1: Sistema de Processamento de Arquivo

De acordo com a figura 1.1, nota-se que os programas gravam seus dados em disco, seguindo estruturas prprias.
Para acess-los necessrio conhecer sua estrutura.
Se vrios programas compartilham seus dados, todos devem conhecer e manipular as mesmas estruturas.
Se algum programa precisar de alguma mudana de dados, todos os programas tero que ser alterados, mesmo
que a alterao ocorra em dados que ele no utiliza.
CAPTULO 1. INTRODUO
Se entre os programas e os dados for colocado um sistema que converte o formato em que os dados esto gravados
para o formato especfico que cada programa precisa dos dados, ento cada programa:
V apenas os dados que lhe interessa;

No precisa entrar em detalhes de como seus dados esto fisicamente gravados;

No precisa ser modificado se a estrrutura de dados que ele no utiliza for mudada.

feita uma converso especfica dos dados gravados para a forma usada em cada programa. Alterar os dados
obriga a alterar a forma de converso para cada programa, mas no cada programa em si. As alteraes
ficam concentradas nesse sistema intermedirio.
Esse sistema intermedirio chamado de Sistema Gerenciador de Banco de Dados (Figura 1.2).
SGBD
Banco de Dados
Figura 1.2: Independencia de Dados provida pelo SGBD
1.3 Sistema Gerenciador de Banco de Dados (SGBD)

Como j foi dito, um SGBD e um conjunto de programas com a finalidade de manipular um conjunto de dados.
Com a introduo de um SGBD em uma organizao demanda o surgimento de um novo profissional, o Administrador de Banco de Dados (DBA).
O DBA responsvel pela manuteno do SGBD e da Base de Dados em si, centralizando todo o gerenciamento
sobre a estrutura dos dados da empresa.
1.3.1 Caracterticas de um SGBD

Segue as caracterticas que um SGBD tem de ter:
CONTROLE DE REDUNDNCIA:A redundncia, ou seja, a repetio de dados, deve ser evitada para se
minimizar possibilidade de inconsistncias.

COMPARTILHAMENTO DE DADOS:Em um ambiente multi-usurios deve-se possibilitar a manipulao

simultnea de dados distintos ou dos mesmos dados conforme regras abaixo.
CAPTULO 1. INTRODUO
CONTROLE DE ACESSO: Verificao automtica do tipo de acesso pedido por cada usurio. Os nveis
de segurana so estabelecidos para cada usurio independentemente, de acordo com suas necessidades.A
identificao de cada usurio, por parte do SGBD, feita pelo nome e senha cadastrados.

CONTROLE DE TRANSAO: Transao o conjunto de operaes que devem ser executadas completamente. So normalmente usadas em situaes crticas (atualizaes ou incluses) de longa durao que
podem afetar a consistncia do BD. Exemplo: bug milnio, corte dos 3 zeros, aumento geral dos produtos,
etc. O SGBD deve utilizar mecanismos internos para que nenhuma falha ocorra durante a execuo da
transao.

ACESSO EM MLTIPLAS INTERFACES: Possibilidade de usar diversas interfaces mesmo se o SGBD

estiver sendo utilizado. Por exemplo: Se existe uma aplicao emDelphi com o SGBD Interbase, se trocar
alinguagem para Visual Basic, no necessrio fazeralteraes no SGBD.

RESTRIES DE INTEGRIDADE: Estabelecimento de um formato para os dados inseridos de modo a

garantir uma certa integridade e facilitar oarmazenamento. Ex. Tamanho do nomes empreigual a 30 e em
maisculo, armazenamento dos salrios em dlar, etc. Algumas regras de integridade so estabelecidas
pelo prprio SGBD para manter o BD consistente e outras so definidas pelo DBA por meio de sentenas
condicionais queso verificadas toda vez que um dado armazenado no BD.

BACKUP E RECUPERAO:Estabelecer o backup automtico do BD total ou parcial em momentosestabelecidos pelo DBA.Proporcionar proteo contra a perda de informaes devido afalhas nodispositivo de
armazenamento (discos).

INDENPENDNCIA DE DADOS: A descrio fsica dos arquivos mantida internamente pelo SGBD e
de suainteira responsabilidade e exclusividade.Programas aplicativos no dispem da descrio fsica esim
de uma descrioexterna.Alteraes nos arquivos podem no afetar os programas aplicativos.

INDEXAO AUTOMTICA: Com a indicao explcita dos atributos quesero mais utilizados em consultas,o SGBD cria os arquivos de indexao que tornaro mais rpidas as pesquisas. A estrutura de indexao e de organizao dos arquivos de dados prprio decada SGBD e normalmente no de domnio
dos usurios comuns.

1.4 Motivao para SGBDs

A utilizao dos SGBDs traz os seguintes problemas:
um produto caro;

um sistema a mais a ser aprendido e gerenciado;

Ocupa espao de armazenagem no computador.

Porm traz vantagens muito maiores:
CONSISTNCIA DE DADOS E INDEPENDNCIA DE DADOS

Alm disso,

O SGBD a ferramenta por excelncia para promover a integrao dos diversos componentes de um sistema
de software;
CAPTULO 1. INTRODUO
Concentram o maior potencial para promover aceso compartilhado de informao, sem bloquear desnecessariamente o acesso compartilhado;

retiram dos programas aplicativos muita da complexidade de gerenciamento de estruturas de acesso aos
dados;

Facilitam a proteo contra a perda de dados, atraves de recursos de backup;

Promovem a adoo de padres para toda a empresa, facilitando seu emprego.

1.4.1 Linguagens de acesso a um SGBD

Existe uma linguagem especfica para definir o esquema conceitual e fsico de um SGBD. A linguagem utilizada
a Structured Query Language (SQL), que apesar de exitir um padro definido, varia de SGBD pra SGBD.
A SQL pode ser dividida em 3 grupos:
Linguagem de Definio de Dados (DDL): Reponsvel por criar e manipular os objetos de armazenamento de dados no SGBD.

Linguagem de Manipulao de Dados (DML): Responsvel por manipular os dados do SGBD.

Linguagem de Controle dos Dados (DCL): Responsvel por permitir o acesso de usurios ao SGBD.

Os aplicativos so escritos em uma linguagem de programao, que pode ser: DELPHI, VISUAL BASIC, COBOL, C, PASCAL, ETC. A SQL utilizada de forma embutida nestas linguagens.
A linguagem SQL engloba numa nica linguagem todos os recursos necessrios para a manipulao da Base de
Dados.
1.4.2 Arquitetura de um SGBD

A arquitetura de um SGBD se divide em trs nveis (Figura 1.3):
Nvel Interno ou Fsico: o mais prximo do meio de armazenamento fsico, ou seja, aquele que se ocupa
do modo como os dados so fisicamente armazenados.

Nvel Conceitual ou Lgico: Descreve quais dados esto armazenados no banco de dados e quais os interrelacionamentos entre eles. Este nvel utilizado pelos administradores.

Nvel externo: o mais prximo dos usurios, ou seja, aquele que se ocupa do modo como os dados so
vistos por usurios individuais.

Exemplos para compreenso dos nveis:

No nvel conceitual: O banco de dados contm informaes relativas a um tipo de entidade chamada EMPREGADO. Cada empregado contm um NMERO_EMPREGADO, um NMERO_DEPARTAMENTO
e um SALRIO.

No nvel interno: Os empregados so representados por um tipo de registro armazenado, denominado

EMP_ARMAZENADO, com 20 bytes de comprimento. Contm 4 campos: um prefixo de 6 bytes mais 3
campos de informao de empregado. Alm disso os registros so indexados sobre o campo EMP.

No nvel externo: O usurio SECRETRIA tem uma viso na qual cada empregado tem 2 campos: Nome
e Salrio. J o usurio CONTADOR tem uma viso que cada empregado tem os campos Nome e Salrio.
CAPTULO 1. INTRODUO
VISAO 1
S
G
B
D
VISAO 2
Esquema Conceitual
Esquena Fisico
Figura 1.3: Arquitetura de SGBD
1.5 Exerccios
1. Resolver em grupo as questes 1.2, 1.4, 1.7, 1.8, 1.9, 1.10, 1.17 e 1.23 do captulo 1 da bibliografia 2.
Ateno: Este captulo encontra-se no Xerox. 14 pginas.
2. Resolver em grupo as questes 2.3, 2.5, 2.7, 2.8 do captulo 2 da bibliografia 3.
1.6 Bibliografia
[1] Traina Jr, Caetano, Modelagem de Dados, Apostila, ICMC-USP.
[2] Kroenke, David M., Banco de Dados:Fundamentos, Projeto e Implementao, Editora LTC, 6 ed, Captulo
1, Rio de Janeiro, 1999
[3] Date, C. J., Introduo a Sistemas de Banco de Dados, Editora Campus, Ed. 7, Captulo 2, Rio de Janeiro,
2000.
Captulo 2
O Modelo Entidade-Relacionamento
Este captulo descreve e ilustra o uso do Modelo Entidade-Relacionamento (MER), que foi apresentado por
Peter Cher em 1976.
Hoje no existe um padro nico de modelo E-R aceito universamente; em vez disto, h um conjunto de conceitos
dos quais se origina a maioria das variantes do E-R.
No MER, os elementos que o compe so representados graficamente atravs da ferramenta denominada Diagrama Entidade - Relacionamento (DER).
A seguir so descritos os principais elementos que compe o MER.
2.1 Entidades
Define-se entidade como aquele objeto que existe no mundo real com uma identificao distinta e com um
significado prprio.
So as coisas que existem no negcio, ou ainda, descrevem o negcio.
Se alguma coisa , existente no negcio nos proporciona algum interesse em mantermos dados (informaes
armazenadas sobre ele), ista a caracteriza como uma Entidade do Negcio.
Alguns exemplos de entidades:
O FUNCIONRIO Joo;

O VEICULO Corsa;

A ALUNA Maria;

O CLIENTE Pedro;

O PRODUTO A323....
Entidades de um mesmo tipo so agrupadas em Classes de Entidade. Assim, a classe de entidades FUNCIONRIOS o conjunto de todas as instncias de funcionrios. Neste texto, classes de entidades esto
impressas em letra maiscula.
Cada ocorrncia de um funcionrio dentro da classe FUNCIONRIO denominado Instncia de Entidade.
A representao grfica de uma entidade no MER se realiza atravs de um retngulo, com o nome desta entidade
em seu interior, como mostra a figura 2.1.
10
CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

CLIENTE
PRODUTO
NOTA FISCAL
11
FUNCIONARIO
ORDEM DE PRODUCAO
Figura 2.1: Exemplos de Entidades
Importante: As instncias de uma entidade no so representadas no DER.
2.2 Atributos
Toda entidade possui propriedade que so descritas por Atributos. No MER supe que todas as instncias de
uma dada classe de entidade possuem os mesmos atributos.
Considere a entidade FUNCIONRIO uma empresa. O que descreve Funcionrio?
Funcionrio descrito por:
nmero de mtricula

nome

data da admisso
Como representado na tabela 2.1.

Tabela 2.1: Entidade Funcionrio
Matrcula
4455
4456
4457
4458
Nome Data Admisso

Joo
24/04/1991
Pedro
30/02/1992
Jos
14/04/1992
Manoel
01/01/1995
No DER os atributos PODEM ser representados por um circulo em torno de seu nome, como mostra a figura
2.2.
FUNCIONARIO
Matricula
Nome
Data Admissao
Figura 2.2: Represetnao de Atributos
Atributo
12
2.2.1 Chave Primria

No existe DUAS INSTNCIAS DE ENTIDADES IGUAIS.
Sempre haver atributo (ou atributos) que nunca se repete.
Este atributo tem a funo de atuar como identificador nico das instncias da entidade e denominado de
CHAVE PRIMRIA.
Na tabela 2.1, a chave primria o atributo MATRICULA.
Ento, como a chave primria identifica uma instncia da entidade, ela tem duas restries importantes:
No se repete;

No contm valor NULO.

Um VALOR NULO um valor que no tem significado algum para o mundo real, somente para o conceitual.
No DER, um atributo chave primria representa por um trao abaixo de seu nome, como mostra a figura 2.3.
ALUNO
RA
Data_Nasc
Chave
Primaria
Nome
Figura 2.3: Atributo Chave Primria

Alm da chave primria tambm temos:
Superchave: o conjunto de um ou mais atributos que, tomado coletivamente, permite-nos identificar
unicamente uma entidade no conjunto de entidade.

Chaves candidatas: chaves com unicidade em uma relao: Ex: CIC, RG, ttulo eleitoral. Todos os atributos
que conseguem identificar uma Relao.

Chave secundria: chave sem unicidade em uma relao. Ex: idade, sexo,endereo.
2.2.2 Atributos Multivalorados

So atributos que para cada instncia de um entidade, ele pode ocorre vrias vezes. No DER, representado por
duas elipses em torno do nome do atributo.
Ex.: Telefones para clientes ou alunos, Nomes de cidades beira de uma rodovia, Nomes dos autores de um
livro, etc.
A figura 2.4 representa o atributo telefone dos cliente de uma empresa.
A representao em um SGBD para atributos multivalorados mostrado na tabela 2.2:
13
Clientes
RG
Telefone
Nome
Figura 2.4: Atributos Multivalorados

Tabela 2.2: Representao em um SGBD de atributos multivalorados da entidade cliente
RG
11
16
Nome
Pedro
Afonso
RG_Cliente
16
16
11
Telefone
442
3244
1231
2.2.3 Atributos Compostos

So atributos formados por outros atributos.
Ex: Telefones, Enderecos, Nome, area de uma sala, etc
A figura 2.5, representa atributos compostos de uma entidade:
Em um SGBD, os atributos so representados da maneira como mostra a tabela 2.3
Tabela 2.3: Atributo Composto em um SGBD
numero comprimento largura
s1
5
3
s2
5
2
s3
7
3
altura
3
3
3
2.2.4 Atributo Derivado

So atributos derivados de outros atributos ou originados de algum calculo. Por exemplo, na figura 2.6, tm-se os
campos idade e qtidade_de_funcion. O primeiro calculado a partir da data de nascimento e o segundo obtido
atravs da contagem dos funcionrios. Por esta razo, este atributo no precisa ser armazenado.
14
Atributo Composto
Sala
Numero
Comprimento
Dimensao
Largura
Altura
Figura 2.5: Atributos Compostos
codigo
data_nasc
idade
FUNCIONARIO
qtde_de_funcion
Figura 2.6: Atributo derivado (representado pela linha pontilhada).
2.3 Entidades Fracas

Pode ocorrer que alguma instncia de entidade possua uma dependncia existencial com outra instncia de entidade e neste caso cada instncia daquela Entidade existe somente porque est associada a outra instncia
de entidade diferente.
Dizer que uma Entidade fraca, significa dizer:QUE NO INTERESSA MANTER NA BASE OS DADOS
DE UMA ENTIDADE SE ELA NO ESTIVER RELACIONADA COM OUTRA ENTIDADE.
Este tipo de Entidade denominada Entidade Fraca. Exemplo: Dependente um tipo de Entidade Fraca pois
existe somente se existir o funcionrio.
A figura 2.7 representa o DER da entidade fraca:
Considerando a entidade Funcionario e seus Dependentes, a tabela 2.4 representa as instncias de cada entidade:
2.4 Relacionamentos
Nenhuma informao armazenada no Banco de Dados existe isoladamente.
Todos os elementos pertencentes ao mundo real modelado de alguma forma est associado a outros elementos.
Normalmente essas associaes representam aes fsicas ou alguma forma de dependncia entre os elementos
envolvidos.
Relacionamento: a associao entre Entidades.
No DER, os relacionamentos so representados conforme mostra a figura2.8.
FUNCIONARIO
PRODUTOS
DEPENDENTE
LOTES
15
Entidades Fracas
Figura 2.7: Entidade Fraca
Tabela 2.4: Representao das entidades Funcionrios e Dependentes
Matrcula
4455
4456
4457
4458
Nome Data Admisso

Joo
24/04/1991
Pedro
30/02/1992
Jos
14/04/1992
Manoel
01/01/1995
Matricula_Funcionario Codigo_Depend
4456
01
4458
01
4456
02
Nome
Pedro Junior
Marcelo
Henrique
Agora que j temos as definies de Entidades e de Relacionamento, vamos aprender como encontr-los em
um problema:
Cliente faz emprestimos
Desta frase, o que Entidade e o que relacionamento?
Pode-se dizer que os SUBSTANTIVOS so as Entidades e os VERBOS so os Relacioanamentos. Sendo assim
tem-se:
Entidades:Cliente e Emprestimo.

Relacionamento: Faz
A figura 2.9 representa graficamente a modelagem deste enunciado.
2.4.1 Atributos de Relacionamento

Considere a figura 2.10.
Atributos de Relacionamentos so igualmente representados como elipses, ligadas aos conjuntos de Relacionamento
16
Relacionamento
Figura 2.8: Representao grfica de um relacionamento
CLIENTE
faz
EMPRESTIMO
Figura 2.9: Identificao de Entidade e Relacionamento

Perceba que Nota um atributo tipicamente do relacionamento Cursa.
Se fosse um atributo de Pessoa, cada pessoa teria apenas uma nota, no importa em qual disciplina.
Se fosse um atributo de Disciplina, todas as Pessoas matriculadas numa disciplina teriam a mesma nota.
Outro exemplo: A quantidade de Material fornecidos por um Fornecedor.
2.4.2 Cardinalidade dos Relacionamentos

A quantidade de Entidades envolvidas em um Relacionamento determinado pela Cardinalidade do Tipo de
Relacionamento, ou seja, pode-se estabelecer a quantidade mnima e mxima de Entidades envolvidas com
cada Entidade relacionada.
A Cardinalidade Mnima que determina a quantidade mnima de Entidades relacionadas determinada pelo
nmero representativo, ou seja, 0 (zero), 1, 2,... N(muitos).
A Cardinalidade Mxima que determina a quantidade mxima de Entidades relacionadas determinada pelo
nmero representativo, ou seja, 0 (zero), 1, 2,... N (muitos).
A figura 2.11 demonstra os tipos de Cardinalidades Mximas que se tem para os relacionamentos Binrios.
2.4.3 Grau dos Relacionamentos

Um Relacionamento pode envolver duas ou mais Entidades.
O Grau do Relacionamento o nmero de Entidades envolvidas.
Desta forma pode-se categorizar os tipos de relacionamento em:
2.4.3.1 Relacionamentos Binrios
Relacionamento que envolve duas Entidades. Figura 2.12.
2.4.4 Relacionamentos Ternrios

Relacionamento que envolve duas Entidades. Figura 2.13.
Colocar quando usar o relacionamento ternario. Exemplo : fornacedor, peca, e projeto (tudo M:N).
ALUNO
17
Cursa
DISCIPLINAS
Nota
Codigo
RA
Nome
Nome
Figura 2.10: Atributo de Relacionamento
Cardinalidade
EMENTA
Cardinalidade
M
ALUNO
(Um
Possui
Cardinalidade
TURMA
1:1
1:N
(Um
para
1
M:N
DISCIPLINA
para
Pertence
(Muitos
N
Cursa
UM)
Muitos)
1
para
CURSO
Muitos)
DISCIPLINAS
Figura 2.11: Tipos de Cardinalidade
Como Determinar as Cardinalidades de um Relacionamento Ternrio

Para determinar as Cardinalidades, por exemplo de ALUNO-PROFESSOR-DISCIPLINA, faa o seguinte:
1. Escolha uma Entidade, por exemplo ALUNO, e pergunte:Para cada Aluno, quantos pares Professor-Disciplina
eu tenho.
2. Coloque a resposta na Entidade ALUNO. Neste caso N. Isto , um Professor lecionando uma Disciplina
pode ter vrios Alunos.
3. Escolhendo a Entidade PROFESSOR. Pergunta-se: Para cada Professor, quantos pares Aluno-Disciplina
eu tenho.
4. Coloque a resposta na Entidade PROFESSOR. Neste caso 1. Isto , um Aluno no pode ter em uma certa
Disciplina mais do que um Professor.
5. Escolhendo a Entidade DISCIPLINA. Pergunta-se: Para cada Disciplina, quantos pares Aluno-Professor
eu tenho.
6. Coloque a resposta na Entidade Disciplina. Neste caso N. Isto , um Professor pode dar a um certo Aluno
mais do que uma Disciplina.
Compra
CLIENTE
CURSO
Inscreve
18
PRODUTO
CANDIDATO
Figura 2.12: Exemplo de Relacionamento Binrio

PROFESSOR
P-A-D
ALUNO
DISCIPLINA
CORRENTISTA
C-C-CM
CONTA
CARTAO_MAGNETICO
Figura 2.13: Exemplo de Relacionamento Ternrio
2.4.5 Auto-Relacionamentos
Uma instncia ou conjunto de instncia de uma mesma Entidade, pode se relacionar com outra(s) instncia(s) da
mesma Entidade.
Na figura 2.14 temos os seguintes exemplo:
Disciplina pr-requisito de Disciplina

Funcionrio gerencia Funcionrio
2.5 MER Estendido

Com o passar do tempo, percebeu-se que o MER original, criado por Peter Chen, no modelava alguns tipos de
progblemas. Surgiu ento, uma extenso do MER denominada MER Estendido ou MER-RX.
2.5.1 Generalizao e Especilizao

Algumas Entidades contm conjunto de atributos especficos. Quando ocorre a situao em que uma entidade
possuir atributos que no fazem parte de todas as instncias da entidade ou quando estas instncias se
relacionarem de maneira diferente com outras entidades, temos ai o conceito de GENERALIZAO/ ESPECIALIZAO.
19
N
Pre-Requisito
DISCIPLINA
M
N
Gerencia
FUNCIONARIO
1
Figura 2.14: Exemplo de Auto-Relacionamentos

Considere a entidade CLIENTE com os atributos nmeroCliente, NomeCliente e QuantiaDevida.
Suponha que um CLIENTE pode ser uma nica pessoa individual, uma associao ou uma coporao e que
sero armazenados dados adicionais dependendo do tipo.
Suponha ainda que estes dados adicionais so:
CLIENTE-INDIVIDUAL: Endereco, NumeroPrevidenciaSocial

CLIENTE-ASSOCIACAO: NomeAssociado, Endereco, Taxa

CLIENTE-CORPORACAO: PessoaContato, Fone, NumeroIdentificacao

Para modelar esta situao demos 2 alternativas:

1. Alocar todos estes atributos na entidade CLIENTE. Neste caso, alguns dos atributos no so aplicveis a
todas as entidades.
2. Definir 3 entidades para cada um dos tipos. As quais seriam: CLIENTE-INDIVIDUAL, CLIENTEASSOCIACAO e CLIENTE-CORPORACAO.
Outros exemplos:
FUNCIONARIO:CODIGO, NOME, ENDERECO

SECRETARIA:cursos, linguas
ENGENHEIRO:crea, especialidade

VEICULO:chassis, marca
UTILITARIO:capacidade_lugares
TRANSPORTE:Tara
A figura 2.15 demonstra esta situao do cliente. Uma vez que a entidade CLIENTE uma entidade genrica, ela
denominada de GENERALIZAO (ou entidade de nvel superior) e as entidades INDIVIDUAL, ASSOCIADO
e CORPORAO so denominadas ESPECIALIZAO (ou entidade de nvel inferior).
20
NumeroCliente
CLIENTE
NomeCliente
QuantiaDevida
INDIVIDUAL
Endereco
CORPORACAO
ASSOCIADO
PessoaContato
Endereco
NumPrevSocial
Telefone
Taxa
Figura 2.15: Generalizao e Especializao

2.5.1.1 Relacionamentos entre Entidades Especializadas
Entre as especializaes pode haver relacionamento. Considere a figura 2.16, ela demonstra o relacionamento
que existe entras as especializaes PROFESSOR e ALUNO.
cpf
idade
Pessoa
nrprof
ra
Aluno
nome
titulo
Professor
curso
Funcionario
nrfunc
funcao
Leciona
Figura 2.16: Relacionamento entre Especializaes

2.5.1.2 Multiplas Especializaes
As especializaes podem se especializar em outras especializaes, isto ocorre na figura 2.17.
2.5.1.3 Restries da Abstrao de Generalizao

Existem duas restries que devem ser definidas para cada Ocorrncia de Abstraes de Generalizao:

Excluso Mtua/Sobrepostos: Onde EXCLUSO MTUA exige que uma entidade de nvel superior
pode pertencer a apenas um conjunto de nvel entidades de nvel inferior. No exemplo da figura 2.15 uma
cliente s pode ser ou INDIVIDUAL ou ASSOCIADO ou CORPORATIVO. J SOBREPOSTOS, uma
entidade superior pode pertencer a mais de um conjunto de entidades de nvel inferior. O que o caso da
figura 2.17, onde um ALUNO pode ser um FUNCIONARIO da escola.

cpf
idade
Pessoa
nome
nrprof
ra
21
Aluno
titulo
Professor
Leciona
curso
Graduac
Pos_Grad
semestre
Orienta
area
Figura 2.17: Multiplas Especializacoes

Total/Parcial: Onde TOTAL, significa que cada entidade superior deve pertencer a um conjunto de entidades de nvel inferiores. J PARCIAL, significa que uma entidade superior pode pertencer a a um conjunto
de entidades de nvel inferior.

As possveis combinaes so:

Parcial Exclusiva: Por exemplo, Um departamento ministra disciplinas para cursos de graduao e psgraduao (deve haver estas entidades). Alm disso pode ministrar disciplinas para treinamento sob solicitao de empresas (no precisa haver a entidade empresa).

Uma discip. ou de graduac.

ou de ps, mas no pode
disciplina
ser as duas coisas.
Existem discip. que no
so nem de grad. nem de
ps.
Graduac
pos-grad
Figura 2.18: Parcial exclusiva

Parcial Sobreponvel: Um departamento contrata pessoal para desempenhar suas funes, tais como vigias, secretrios, bliblitecrios, etc.

pessoa
Um funcionrio pode acumular
mais de uma funo
Alm de Vigia, secret. e
bibliot. existem outras
funes
vigia
secretario
bibliotecrio
Figura 2.19: Parcial Sobreponvel

Total Exclusiva: Um departamento ministra disciplinas para cursos de grad.e pos-grad. Alm disso pode
ministrar disciplinas de especializao para treinamento sob solicitao de empresas.
22
Uma discip. ou de graduac.

disciplinaou de ps ou de especializ,
mas s pode ser uma dessas
coisas.
S existem discip. de grad.,
de ps ou de especializ.
Graduac pos-grad especializ
Figura 2.20: Total exclusiva

Total Sobreponvel: Os alunos de um departamento so de Graduao ou de Especializao, conforme os

cursos que frequentam.
Aluno
Um aluno pode cursar mais de um
curso ao mesmo tempo
S existem alunos de grad.,
ps ou de especializao.
grad
pos-grad especiliz
Figura 2.21: Total Sobreponvel
2.5.2 Agregao
Uma limitao do modelo E-R que no possivel expressar relacionamentos entre relacionamentos. Alm
Para ilustrar esta necessidade, considere um banco de dados descrevendo informaes sobre Funcionrios que
trabalham em um determinado Projeto e utilizam uma srie de diferentes Mquinas em seus trabalhos.
Usando o modelo bsico de construo E-R, obtemos o diagrama E-R da figura 2.22.
Horas
FUNCIONARIO
Id
Nome
Trabalho
PROJETO
N
N
Descricao
Usa
MAQUINA
Numero
Id
Descricao
Figura 2.22: Diagrama E-R com relacionamentos redundantes

No exemplo da figura 2.22, o relacionamento Usa deve empregar informaes j existentes previamente no conjunto de relacionamento Trabalho. Alm disso, h pares Funcionrio-Trabalho que no usam nenhuma
mquina, isto , no esto em Usa.
23
A soluo usar a Agregao. A agregao uma abstrao por meio da qual relacionamentos so tratados
como entidades de nvel superior. Assim, para nosso exemplo, o relacionamento Trabalho e as entidades
FUNCIONRIO e PROJETO, torna-se-o uma nica entidade.
Isto permite que relacionar o conjunto FUNCIONARIO, TRABALHO e PROJETO com a entidade MQUINA.
A figura 2.23, mostra a soluo de nosso problema em forma de agragao.
Nome
Descricao
Id
FUNCIONARIO
Horas
M
Trabalho
Numero
PROJETO
N
Usa
M
MAQUINA
Id
Descricao
Figura 2.23: Diagrama E-R com Agregao

Agora com a gregao, significa dizer que o conjunto Funcionrio-Projeto nem sempre utilizam mquinas.
Outros exemplos:Assassino-Vitima-Arma, Cliente-Conta-CartoCrdito, Rua-Bairro-Linha.
Agora que j temos a noo do uso da Agregao vamos analisar os casos em que se deve us-la:
Quando necessrio identificar-se cada relacionamento.

Quando necessrio mais de um relacionamento envolvendo as mesmas entidade (ACABAR)
2.5.2.1 1 Caso do uso de Agregao (Opcionalidade)

2.5.2.2 2 Caso do uso de Agregao (Identificador em Relacionamento)
2.5.2.3 3 Caso do uso de Agregao (indica tempo)
2.6 Exerccios
2.6.1 Primeira Lista
1 - Obtenha o modelo Entidade-Relacionamento dos seguinte enunciados. Coloque os atributos necessrios
das entidades. Coloque pelo menos 3 atributos em cada entidade.
1. Uma Empresa possui funcionrios. Um funcionrio trabalha em uma Empresa
2. Os Atletas participam de competies. Em uma compatio participam vrios atletas.
3. Deseja-se fazer um banco de dados para uma rede de hotelaria. Um hotel possui quartos. Cada quarto
pertence a apenas um hotel.
24
4. Um soldado, que possui as caractersticas nome, Registro Militar (RM), data de nascimento, possui armas.
Uma arma, que possui as caractersticas de srie, registro e calibre, de um soldado. Uma arma limpa
por vrios soldados. Um soldado limpa vrias armas.
5. Um funcionrio supervisionado por um gerente (o gerente tambm um funcionrio). Um gerente (que
tambm funcionrio) supervisiona vrios funcionrios. Do funcionrio deseja-se saber nome, cpf e endereo.
6. Um mdico trata de pacientes. Do mdico deseja-se saber CRM, nome e suas especialies. Um paciente,
no qual h a necessidade de sabermos seu nome, endereo e idade, tratado por vrios mdico. Um paciente
realiza vrios tipos de exames. Um tipo de exame, destes h a necessidade de guardar seu nmero, data e
descrio, feito por vrios paciente.
7. O aluno cursa disciplinas lecionadas por um professor cada uma. Para cada aluno deve-se manter as informaes de ra, nome e seus telefones. Uma disciplina cursada por vrios alunos e lecionada por um
professor. Das disciplinas deseja-se saber codigo, nmero de crditos e descrio. Os professores lecionam
diversas disciplinas cada um e em cada disciplina possui diversos alunos. Dos professores deseja-se saber
seu cdigo, nome e telefone.
8. Um mdico trata de pacientes. Do mdico deseja-se saber CRM, nome e suas especialies. O mdico pede
exames para vrios pacientes. Um paciente, no qual h a necessidade de sabermos seu nome, endereo e
idade, tratado por vrios mdico. Um paciente realiza vrios tipos de exames pedidos pelos mdicos. Um
tipo de exame, destes h a necessidade de guardar seu nmero, data e descrio, feito por vrios paciente
a pedido dos mdicos.
9. Uma empresa possui funcionrios. Os funcionrios podem ser engenheiros, secretrias ou tcnicos.
10. Uma empresa fabrica automveis. Os automveis podem ser carros de passeio, caminhes ou nibus.
Identifique as cardinalidade dos exerccios anteriores.
2 - Obtenha o modelo Entidade-Relacionamento dos seguinte enunciados. Coloque os atributos necessrios
das entidades. Coloque pelo menos 3 atributos em cada entidade.
1. Uma empresa deseja elaborar um cadastro completo de seus empregados e suas atividades. Para cada
empregado desejado armazenar seu nome, nmero funcional, telefone (ddd + nmero) e seus diversos dependentes (nem todo empregado possui dependente), o departamento no qual o empregado trabalha (todo
empregado trabalha em um departamento), o departamento o qual o empregado gerencia (nem todo empregado gerencia departamento) e os diversos projetos no qual o empregado trabalha (nem todo empregado
trabalha em projeto). Para cada departamento necessrio armazenar seu nome, nmero, os diversos empregados que o departamento possui (todo departamento possui empregado), o empregado que gerencia o
departamento (todo departamento gerenciado por um empregado) e os diversos projetos que o departamento controla (nem todo departamento controla projetos). Para cada projeto necessrio armazenar seu
nome, seu nmero, as diversas cidades nas quais o projeto desenvolvido, os diversos funcionrios que
trabalham no projeto (todo projeto possui funcionrios) e o departamento que controla o projeto (todo projeto controlado por um departamento). Para cada dependente necessrio armazenar seu nome, sexo, o
relacionamento com o empregado e o empregado do qual o dependente depende (todo dependente depende
de um empregado).
2. Um Hotel deseja montar um banco de dados de Hospedagem. Do cliente que hospeda-se no hotel, e
desejado saber seu nome, RG, Endereo, telefone e o quarto que esta hospedado. Dos quartos, deseja-se
saber seu numero, andar, a quantidade de leitos e os clientes que dormiram no quarto(um quarto pode
abrigar mais de um cliente). Deseja-se saber tambm a data de hospedagem e o que o cliente consumiu.
25
3. Uma Transportadora quer automatizar seu controle de transporte. Ela deseja ter as seguintes informaes
de seus caminhes: Marca, modelo, ano, capacidade de transporte e a data em que um motorista viajou
com o caminho(mais de um motorista pode dirigir um caminho). Do motorista deseja-se saber Nome,
RG, Idade, Endereo e o caminho com o qual j viajou. Um caminho pode transportar diversos produtos,
destes deseja-se saber nome, marca, fabricante e data de transporte( um tipo de produto pode viajar em
mais de um caminho).
4. A Federao Paulista de Futebol deseja elaborar um cadastro geral para o Campeonato Paulista de 1999.
Para cada time desejado armazenar seu nome, sua cidade, seu nmero de cadastro na FPF, a situao
do time no campeonato, o estdio que o time possui (todo time possui um estdio), os jogos que o time
participa (todos os times participam de jogos) bem como, o nmero de gols que o time marcou na partida,
as diversas torcidas organizadas que o time possui (um time no obrigado a possuir torcida organizada),
os diversos jogadores que compem o elenco do time (todo time possui jogadores no elenco) e os diversos
jogadores cujos passes pertencem ao time (um time no obrigado a possuir passes de jogadores). Para cada
jogo desejado armazenar seu nmero, a data, horrio, os diversos membro da comisso de arbitragem, o
estdio no qual o jogo realizado (todo jogo realizado em estdio), os times que participam do jogo (todo
jogo realizado por times), as diversas torcidas organizadas que frequentaram o jogo (nem todo jogo deve
frequentado por torcidas organizadas) e os diversos jogadores que participaram ativamente do jogo, sendo
desejado armazenar o nmero de gols, o nmero de cartes amarelos e o nmero de cartes vermelhos que
o jogador recebeu no jogo (todo jogo disputado por jogadores). Para cada estdio desejado armazenar
seu nome, localizao, o nmero de torcedores, os diversos jogos que o estdio abriga (um estdio no
obrigado a abrigar jogos) e o time proprietrio do estdio (um estdio pode ser pblico). Para cada torcida
organizada desejado armazenar seu nmero de cadastro na FPF, seu nome, o nome de seu presidente,
sua sede, o nmero de associados, os diversos jogos que a torcida frequenta (uma torcida no obrigada a
frequentar jogos) e o time para o qual a torcida torce (toda torcida torce para um time). Para cada jogador
desejado armazenar o nmero de cadastro do jogador na FPF, seu nome, apelido, idade, o time ao qual
o passe do jogador pertence (o jogador pode ter passe livre), o time para o qual o jogador atua (o jogador
pode estar cadastrado na FPF e no atuar em um time) e os jogos dos quais o jogador participa ativamente
(um jogador no obrigado a participar de jogos ativamente).
5. Uma universidade deseja elaborar um cadastro acadmico, envolvendo seus alunos, cursos e disciplinas.
Para cada faculdade desejado armazenar seu nome, seu nmero, os diversos departamentos que a faculdade possui (toda faculdade dividida em departamentos) e os diversos professores que a faculdade possui
(toda faculdade possui professores). Para cada departamento necessrio armazenar seu nmero, sendo que
para cada faculdade, a numerao de seus departamentos vai de 1 at N, seu nome, o professor que chefia
este departamento (todo departamento chefiado por um professor), a faculdade qual o departamento
pertence (todo departamento pertence a uma faculdade), as diversas disciplinas que o departamento oferece
(nem todo departamento oferece. Para cada curso desejado armazenar seu cdigo, seu nome, os diversos
perodos nos quais o curso oferecido, o departamento ao qual o curso pertence (todo curso pertence a
um departamento), os diversos alunos que frequentam o curso (se no hover alunos frequentando o curso
o mesmo no ser cancelado) e as diversas disciplinas que so oferecidas pelo curso (todo curso oferece
disciplinas). Para cada disciplina desejado armazenar seu nome, cdigo, carga horria, o departamento
pelo qual a mesma oferecida (toda disciplinas oferecida por um departamento), os diversos cursos para
os quais a disciplina oferecida (mesmo que uma disciplina no seja oferecida por um curso ela no ser
cancelada), os diversos professores que lecionam a disciplina (toda disciplina lecionada por professores)
e os diversos alunos que frequentam a disciplina, sendo necessrio armazenar para cada aluno a nota 1 N1,
nota 2 N2, as faltas F, a mdia final do aluno ((N1 + N2)/2) e a situao do aluno (mdia final > 7) e F
<= 25% aluno aprovado (se no houver alunos frequentando a disciplina, a mesma no ser cancelada).
Para cada aluno desejado armazenar seu nome, ra, seus endereos completos (o da cidade onde reside e
o da cidade da universidade) com rua, nmero, bairro, cep, cidade, seus telefones (o da cidade onde reside
e o da cidade da universidade) com DDD + nmero, o curso que o aluno frequenta (todo aluno frequenta
26
um curso, no podendo frequentar mais que um), as diversas disciplinas que o aluno frequenta (todo aluno
frequenta disciplina) e o professor que orienta o aluno (nem todo aluno orientado por professor). Para
cada professor desejado armazenar seu nmero funcional, seu nome, a faculdade qual ele pertence (todo
professor pertence a uma faculdade), o departamento o qual o professor chefia (um professor no obrigado
a chefiar um departamento) e as diversas disciplinas que o professor leciona (um professor no obrigado
a lecionar disciplinas).
6. Um hospital deseja elaborar um cadastro para controlar as atividades de suas clnicas. Para cada clnica
desejado armazenar seu nome, seu cdigo, sua especialidade e os diversos mdicos que a clnica possui
(toda clnica possui mdicos). Para cada mdico desejado armazenar seu nome, nmero do CRM, sua
especialidade, as diversas consultas que o mdico faz (o mdico no obrigado a realizar consultas), as
diversas cirurgias que o mdico faz (um mdico no obrigado a realizar cirurgias) e a clnica ao qual o
mdico pertence. Para cada consulta desejado armazenar seu nmero, sua data, horrio, o mdico que
realizou a consulta (toda consulta realizada por um mdico) e o paciente que foi consultado (toda consulta
feita em um paciente). Para cada cirurgia necessrio armazenar seu nmero, a data , o horrio, os
diversos mdicos que realizaram a cirurgia (toda cirurgia realizada por mdicos), as diversas enfermeiras
que auxiliaram na cirurgia (toda cirurgia auxiliada por enfermeiras) e o paciente no qual realizada
a cirurgia (toda cirurgia realizada em um paciente). Para cada paciente desejado armazenar seu cod,
nome, rg, dt de nascimento, endereo completo (rua, nmero, bairro, cep, cidade), as diversas consultas que
o paciente realizou (um paciente no obrigado a realizar consultas), as cirurgias que o paciente realizou
(um paciente no obrigado a realizar cirurgias) e as diversas enfermeiras que atenderam o paciente assim
como a data e o horrio do atendimento (nem todo paciente atendido por enfermeira). Caso o paciente seja
menor de idade e no possua RG, ento ser necessrio armazenar o RG do responsvel pelo mesmo. Para
cada enfermeira desejado armazenar seu nmero, seu nome, sua especialidade, as diversas cirurgias que
a enfermeira auxiliou (nem toda enfermeira auxlia em cirurgia) e os diversos pacientes que a enfermeira
atendeu (toda enfermeira atende paciente).
7. Uma empresa deseja elaborar um sistema para controlar suas vendas. Para cada vendedor necessrio
armazenar seu nome, seu nmero, endereo, os diversos clientes que o vendedor atende (todo vendedor
atende clientes) e as diversas notas fiscais que o vendedor emite (todo vendedor emite notas fiscais). Para
cada cliente necessrio armazenar seu cdigo, nome fantasia, nome da empresa, cgc, os diversos vendedores que atenderam este cliente (todo cliente atendido por vendedor) e todos os pedidos de compra que
os clientes emitiram (nem todo cliente cadastrado emite pedido de compra). Para cada pedido de compra
desejado armazenar o seu nmero, a data de emisso, o valor total do pedido de compra, o cliente que emitiu o pedido de compra (todo pedido de compra emitido por um cliente), as notas fiscais geradas para este
pedido de compra (todo pedido de compra gera notas fiscais) e os diversos itens de pedido de compra (todo
pedido de compra possui itens de pedido de compra). Cada item de pedido de compra identificado por seu
nmero que vai de 1..20 para cada pedido de compra, a quantidade, o valor do item, o pedido de compra
ao qual o item pertence (todo item pertence a um pedido de compra) e o produto que o item descreve (todo
item de pedido descreve um produto). Para cada nota fiscal necessrio armazenar seu nmero, sua srie
(a numerao varia pela srie), a data de emisso, o valor total da nota, o vendedor que emitiu a nota (toda
nota emitida por um vendedor), o pedido de compra que gerou a nota (toda nota gerada por um pedido
de compra) e os diversos itens de nota que a mesma contm (toda nota contm itens de nota). Para cada
item de nota necessrio armazenar seu nmero que vai de 1..20 para cada nota fiscal, a quantidade de
produto, o valor total do item, a nota fiscal ao qual o item pertence (todo item pertence a uma nota fiscal e
o produto que o item descreve (todo item de nota fiscal descreve um produto). Cada produto descrito por
seu cdigo, descrio, valor unitrio, os diversos itens de pedido de compra nos quais o mesmo citado
(um produto no obrigado a estar citado em um item de pedido de compra) e todos os itens de nota fiscal
nos quais o produto descrito (nem todo produto deve ser descrito em item de nota fiscal).

3 - Resolver os seguintes exerccios da Bibliografia 2:
2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.8, 2.14, 2.15, 2.16 e 2.18
2.7 Bibliografia
[1] - Machado, F.; Mauricio, A. Projeto de Banco de Dados, Editora. rica, 5 ed., Captulo 4.
[2] - Korth, H.; Silberschatz, A. Sistema de Banco de Dados. Editora Makron Books, 3 ed., 1999
27
Captulo 3
O Modelo Relacional
3.1 Introduo
Criado por Edgar Codd, nos anos 70, comeou a ser realmente utilizado nas empresas a partir de 1987, atravs
do SGBDs. A abordagem relacional est baseada no princpio de que as informaes em uma base de dados
podem ser consideradas como relaes matemticas e que esto representadas de maneira uniforme, atravs do
uso de tabelas, ou falando de uma forma mais direta, um arquivo. Porm, um arquivo mais restrito que uma
tabela. Toda tabela pode ser considerada um arquivo, porm, nem todo arquivo pode ser considerado uma tabela.
Este princpio coloca os dados (entidades e relacionamentos) dirigidos para estruturas mais simples de armazenar
dados, que so as tabelas.
O conceito principal vem da teoria dos conjuntos (lgebra relacional) atrelado idia de que no relevante
ao usurio saber onde os dados esto nem como os dados esto (transparncia). Os usurios manipulam objetos
dispostos em linhas e colunas das tabelas, como mostra a figura a seguir. O usurio pode lidar com estes objetos,
conta com um conjunto de operadores e funes de alto nvel, constantes na lgebra relacional.
Terminologia do modelo relacional:
Tabela chamada de RELAO;

Linha de uma tabela chamada de TUPLA;

Coluna chamado de ATRIBUTO;

O tipo de dado que descreve cada coluna chamado de DOMNIO.
28
CAPTULO 3. O MODELO RELACIONAL
29
A figura 3.1 repesenta uma tabela de alunos:
RA Nome Ender Telef Idade

Tupla
Relacao
Atributo
Figura 3.1: Representao de uma tabela no Modelo Relacional
Uma relao representada da seguinte maneira:
Aluno={Ra, Nome, Ender, Telef, Idade}
3.2 Domnios
O Domnio de um atributo , em geral, um tipo de dado que especifica o que o atributo pode receber.
Exemplo:
Nmero de salas de aula

Conjunto dos nmeros de 1 a 150, inteiros no formato 999.

Nomes de alunos

Conjunto de todos os nomes possveis para pessoas no formato String[60].

Cdigos de Disciplinas
Conjunto de trs letras seguidas de um trao e de trs dgitos:AAA-999.
um conjunto de valores atmicos.

Valor Atmico significa um valor indivisvel e monovalorado.
3.3 Relaes
Dado o seguinte esquema de uma Relao de Alunos:
Aluno = {Nome, RG, Idade}
uma possvel instanciao para esse esquema a Relao:
R(Aluno)={<Jos, 12345, 21>,
<Pedro, 54321, 18>,
<Paulo, 32123,22>}
30
Como um esquema de uma Relao R definido como um cojunto, no existe a idia de ordem. Assim, desde
que se indique que cada valor Vi corresponde a um atributo Ai, a ordem dos atributos em esquemas de
relaes apenas uma questo de disposio fsica.
Importante: A instncia de uma relao em um determinado momento, toda a relao no momento, ou seja,
uma instncia de Alunos so todos os alunos cadastrados no momento. Se amanh acrescentar mais
alunos, a instncia ser todos os alunos antigos mais os novos
3.4 Chave no Modelo Relacional

3.4.1 Superchave
Um cojunto de atributos de uma relao R que identifica univocamente cada tupla na relao R chamada uma
SUPERCHAVE.
Considere a seguinte relao Aluno:
Aluno = {Nome, Endereco, Telefone, RA, Idade}
Superchave(Aluno)={Nome, Endereco, Telefone, RA, Idade}
Superchave(Aluno)={Nome, Endereco} (Considerendo que no existem duas pessoas com o
nome em uma residncia)
Superchave(Aluno)={Nome, Telefone}
Superchave(Aluno)={RA, Nome}
Superchave(Aluno)={RA}
3.4.2 Chave
CHAVE uma Superchave da qual no se pode retirar nenhum atributo e ainda preservar-se a propriedade de
identificao unvoca.
Exemplo:
Superchave(Aluno)={Nome, Endereco, Telefone, RA, Idade}: No chave, pois se retirarmos idade,
ainda consiguiremos identificar um nico aluno.
Superchave(Aluno)={Nome, Endereco}: chave, pois se retirarmos um atributo no consiguiremos
identificar um aluno.
Superchave(Aluno)={Nome, Telefone}: chave.
Superchave(Aluno)={RA, Nome}: No chave.
Superchave(Aluno)={RA}: chave.
Em geral, adota-se a conveno de que os atributos chaves so grifados. Se mais de um atributo participa de uma
mesma chave, grifam-se esses atributos todos com o mesmo nmero de traos.
Exemplo:
mesm
31
3.4.3 Chave Candidata

comum que exista mais de uma chave para uma mesma relao. Neste caso, cada uma das chaves chamada
de Chave Candidata.
Quando existe mais de uma, grifa-se cada chave candidata com um nmero diferente de traos.
Exemplo
Aluno = {Nome, Endereco, Telefone,
, Idade}
3.4.4 Restries de Integridade

So regras a respeito dos valores que podem ser armazenados nas relaes que devem ser sempre satisfeitas.
Existem 3 que so consideradas necessrias a uma base de dados relacional:
Restrio de Integridade da Chave: Uma chave candidata qualquer no pode ter o mesmo valor em duas
tuplas distintas da mesma relao.

Restrio de Integridade da Entidade:A chave primria de qualquer relao no pode ser nula em nenhuma tupla dessa relao.

Restrio de Integridade Referencial: Informalmente, a restrio de integridade referencial declara que

uma tupla em uma relao, que faz referncia a outra relao, deve se referir a uma tupla existente nessa
relao. O conceito de Integridade Referencial depende do conceito de Chave Estrangeira.
3.4.4.1 Chave Estrangeira (Integridade Referencial)

Uma Chave Estrangeira ocorre quando um conjunto de atributos C R1 que no chave em R1, compatvel
com outro conjunto de domnio de atributos D R2 que a Chave Primria da relao R2.

Exemplo:
Curso={Cod_Cur, Nome, Qtidade_Max_Aluno}
Aluno={RA, Nome, Endereco, Idade, Num_Curso}
Dom(Cod_Cur) = Dom(Num_Curso)
Se (Cod_Cur) Chave Primria de Curso, ento (Num_Curso) Chave Estrangeira em Aluno.
Importante: A chave estrangeira pode ter o valor NULO.
Nao existe uma representao formal para chave estrangeira. Normalmente, identifica-se com um arco direto
de cada chave estrangeira relao que ela faz referncia. Para maior clareza, a seta deve apontar para a chave
primria da relao referida (figura 3.2).
Uma outra maneira colocar a sigla FK (Foreign Key) na frente de cada campo. Neste caso se os nomes dos
atributos no forem os mesmos (chave primria com chave estrangeira) fica difcil de identificar de qual relao
o atributo chave estrangeira.
32
funcionario = {codFunc, nome, numD
departamento={numDep, descricao, c
Figura 3.2: Representao de Chave Estrangeira
3.4.4.2 Exemplos de Restries de Integridade
Aluno={ Nome,
RA, Idade}
{ <Mario, 1234,
20>
<Paulo, 4312
18>
<Jose, 1212
21>
<Marta 3322 19>}
Disciplina={ Sigla RA_Monitor}
{ D-104
1234
D-123
1212
D-149
1234
D-189
NULL}
Dom(aluno.RA)=Dom(disciplina.RA_Monitor)
Relaes Vlidas: Apesar de RA_Monitor ser chave estrangeira, ela no Chave Candidata.
====================================================================
Aluno={ Nome,
RA, Idade}
{ <Mario, 1234,
20>
<Paulo, 4312
18>
<Jose, 1212
21>
<Marta 3322 19>}
{ D-104
1234
D-123 2222 (Errado)
D-149
1234
D-189
}
Relaes Invlidas: Valor 222 para RA_Monitor inexistente na tabela Aluno
Integridade Referencial Violada
====================================================================

Aluno={ Nome,
RA,
{ <Mario,
1234,
<Paulo, NULL(Errado)
<Jose,
1212
<Marta 1212 (Errado)
33
Idade}
20>
18>
21>
19>}

{ D-104
1234
D-123
1212
D-149
1234
D-189
NULL}
Relaes Invlidas: Valor NULL para o atributo RA na relao Aluno e existem duas chaves primrias com o mesmo valor.
Integridades de Entidade e de Chave Violadas Respectivamentes
3.5 Outros tipos de Restries

As restries apresentadas so restries do prprio modelo relacioanal. Existem outros tipos, como por exemplo,
as restries de integridade semnticas.
Os exemplos destas restries so O salrio de um empregado no deve exceder o do supervisor em um
banco de dados relacioanal e o nmero mximo de horas que um empregado pode trabalhar por semana em
todos os projetos 56.
Essas restries podem ser especificadas e impostas dentro dos programas de aplicao que atualizam o banco
de dados ou pelo prprio SGBD atravs de Stored Procedure e Triggers. (Estes recursos sero vistos posteriomente no curso).
Outro tipo de restrio a dependncia funcional, que estabelece um relacionamento funcional entre dois
conjuntos de atributos X e Y. Essa restrio especifica que o valor de X determina o valor de Y em todos os
estados de uma relao.
3.6 Bibliografia
[1] - Machado, F.; Mauricio, A. Projeto de Banco de Dados, Editora. rica, 5 ed., Captulo 13.
[2] - Traina Jr, Caetano Apostila de Modelagem de Dados, USP-So Carlos.
Captulo 4
Mapeamento do Modelo ER para Modelo
Relacional
4.1 Introduo
O MER um Modelo Conceitual: Pode ser usado para especificar conceitualmente a estrutura de dados de uma
aplicao.
O Modelo Relacional um Modelo Lgico (porm bem prximo ao Fsico): uma descrio de um banco de
dados no nvel de abstrao visto pelo usurio do SGBD. Assim, o modelo lgico dependente do tipo
particular de SGBD que est sendo usado.
O Mapeamento permite que se traduzam os esquemas concebidos com um modelo de contedo semntico mais
alto para uma implementao utilizando um modelo lgico (ou fsico).
O Mapeamento do MER para o Mod. Relacional (MRel) um procedimento executado em 6 passos consecutivos
apresentados a seguir.
4.2 Mapeando Entidades

Cada Conjunto de Entidades mapeada como uma relao que envolve todos os atributos do conjunto de entidades.
Os atributos CHAVES comporo a chave da relao (figura 4.1).
34
CAPTULO 4. MAPEAMENTO DO MODELO ER PARA MODELO RELACIONAL
35
Nome
Aluno
RA
Aluno={Nome,RA}
Figura 4.1: Mapeamento Entidades
4.3 Entidades Fracas

Conjunto de Entidades Fracas(CEF) so mapeadas numa relao formada por todos os atributos do CEF mais
os atributos que so chave das relao ao qual o CEF depende (figura 4.2).
Dependente
rg
possui
Funcionario
codigo
nome
nome
idade
telefone
funcionario={codigo, nome, telefone}

dependente={rg, nome, idade, codigo_func}
Figura 4.2: Mapeamento de Entidades Fracas
4.4 Relacionamento Binrio com Cardinalidade 1:1

Conjunto de Relacionamentos Binrios (CRB) de Cardinalidade 1:1 no so representados como novas relaes.
Seus atributos so acrescentados numa das relaes que mapeiam os Conjuntos de Entidades (CE) envolvidos
(qualquer uma). Nessa mesma relao inclui-se tambm tambem os atributos chave da relao que mapeia o
outro CE (Figura 4.3).
4.5 Relacionamento Binrio com Cardinalidade 1:N

CRB de cardinalidade 1:N tambm no so representados como novas relaes. Seus atributos so acrescentados
na relao que mapeia o CE que ocupa o papel de cardinalidade N. Os atributos chave da relao que mapeia o
CE que participa com cardinalidade 1 so tabm acrescentados na CE com papel de cardinalidade N (Figura 4.4).

1
Ementa
nome
possui
36
Disciplina
Sigla
Data Aprov
nome
Num. de Creditos
disciplina = {sigla, nome, num_creditos}

ementa = {nome, data_aprov, sigla_discip}
Figura 4.3: Mapeamento de Relacionamentos 1:1
Professor
possui
Disciplina
codigo
Sigla
Horario
nome
nome
Num.
de
Creditos
professor={codigo, nome}
disciplina={sigla, nome, num_creditos, horario, codigo_prof}
Figura 4.4: Relacionamento Binrio com Cardinalidade 1:N
4.6 Relacionamento Binrio com Cardinalidade M:N

Cada CR Binrio de Cardinalidade M:N representado como uma nova relao. Os atributos da relao so os do
CR mais os atributos chave das relaes que mapeiam os CEs envolvidos. A Chave da Relao a concatenao
dos atributos chaves das relaoes que mapeiam os CEs envolvidos (Figura 4.5).
Aluno
matriculado
ra
nome
Disciplina
Sigla
Nota
nome
Num. de Creditos
aluno={ra, nome} | disciplina={sigla, nome, num_creditos}

matriculado={ra, sigla, nota}
Figura 4.5: Relacionamento Binrio com Cardinalidade M:N
4.7 Relacionamentos Ternrios

Conjuntos de Relacionamentos de ordem maior do que dois com cardinalidade diferente de M:N:P tm um mapeamento complexo. Assim, usualmente se mapeiam os cjs. de Relac. ternrios, quartenrios, etc. como se todos
fossem de cardinalidade vrios para vrios para vrios... etc (Figura 4.6).
Aluno
ra
monitora
P
nome
Disciplina
Sigla
nome
professor
Num. de Creditos
codigo
nome
aluno={ra, nome} | disciplina={sigla, nome, num_creditos} | professor={codigo, nome}

monitora={ra, sigla, codigo}
Figura 4.6: Relacionamento Ternrio com Cardinalidade M:N:P
4.8 Exemplo 1
A figura 4.7 demonstra um exemplo de mapeamento de um DER completo para o modelo Relacional.
37

1
Professor
ministra
Turma
cod_prof
38
cod_turma
nome
numero_alunos
N
Aluno
ra
Monitora
matricula
composto
por
N
1
Disciplina
nome
sigla
num_credito
nome
professor = {cod_prof, nome} | disciplina = {sigla, nome, n_credito} | aluno = {ra, nome}
turma = {cod_turma, sigla, n_aluno, cod_prof} | monitora = {cod_prof, ra, cod_turma, sigla}
matricula = {sigla, ra}
Figura 4.7: Exemplo de DER completo mapeado para o Relacional
4.9 Atributos Compostos e Multivalorados

Os atributos compostos sero decompostos nas relaes e os multivalorados torna-se-o relaes cuja chave primria ser composta pela chave da entidade posuidora do atributo mais o atributo multivalorado (Figura 4.8).

num_funcional
rua
Secretaria
endereco
numero
telefone
secretaria={num_funcional, rua, numero} | secretaria_endereco={num_funcional, telefone}

Figura 4.8: Mapeamento de atributos composto e multivalorado
4.10 Generalizao
A figura 4.9 mostra o mapeamento DER-Relacional de uma Generalizao/Especializao.
num_func
Funcionario
Secretaria
idioma
nome
Engenheiro
crea
curso
funcionario={num_func, nome, tipo_funcionario} | secretaria = {num_func, idioma, curso}

engenheiro={num_func, crea}
Figura 4.9: Mapeamento Generalizao/Especializao
4.11 Agregao
A figura 4.10 mostra o mapeamento DER-Relacional de uma Agregao.
39

valor
num_func
num_proj
nome
M
Projeto
participa
Funcionario
M
usa
N
fabricante
Maquina
cod_maq
projeto={num_proj, valor} | funcionario={num_func, nome} | maquina={cod_maq, fabricante}

participa={num_proj, num_func} | usa={num_proj, num_func, cod_maq}
Figura 4.10: Mapeamento Agregao
4.12 Exemplo 2
valor
num_func
num_proj
Projeto
nome
M
participa
Funcionario
M
usa
N
fabricante
cod_maq
Tecnico
Engenheiro
formacao
crea
coordena
N
Atividade
Maquina
cod_atividade
duracao
projeto={num_proj, valor} | funcionario={num_func, nome} | maquina={cod_maq, fabric}

participa={num_proj, num_func} | usa={num_proj, num_func, cod_maq}
tecnico={num_func, formacao} | engenheiro={num_func, crea}
atividade={cod_atividade, duracao, num_func}
Figura 4.11: Exemplo 2 de DER completo mapeado para o Relacional
4.13 Resumo dos 6 passos

1. Mapear todos os Cj. de Entidades Regulares do Diagrama ER.
2. Mapear todos os Cj. de Entidades Fracas do Diagrama ER.
3. Mapear todos os Cj. de Relacionamentos 1:1 do Diagrama ER.
4. Mapear todos os Cj. de Relacionamentos 1:N do Diagrama ER.
5. Mapear todos os Cj. de Relacionamentos M:N do Diagrama ER.
6. Mapear todos os Cj. de Relacionamentos Ordem > 2 do Diagrama ER.
40
4.14 Bibliografia
[1] - Traina Jr, Caetano Apostila de Modelagem de Dados, USP-So Carlos.
[2] - Setzer, Valdemar Banco de Dados:Conceitos, Modelos, Gerenciadores, Projeto Lgico e Fsico, Editora Edgard
Blucher Ltda, 3 ed.
[3] - Machado, F.; Mauricio, A. Projeto de Banco de Dados, Editora rica, 5 ed., Captulo 13.
41
Captulo 5
Normalizao de Relaes
5.1 Introduo
O controle de Consistncia pode ser feito:
Pelo SGBD

Pelo Aplicativo

Pela prpria construo do sistema
O controle obtido pela prpria construo do sistema , em geral, a melhor, pois no incorre em perda de
eficincia durante a execuo.
O controle atravs da prpria construo do sistema obtido no Modelo Relacional construindo-se as relaes
segundo regras que garantem a manuteno de certas propriedades.
As relaes que atendem a um determinado conjunto de regras diz-se estarem em uma determinada Forma
Normal.
5.2 Normalizao de Relaes

O processo de Normalizao permite ao programador controlar quanto da consistncia garantida pela maneira
de construo do sistema, e quanto deve ser responsabilidade dos aplicativos e/ou SGBD.
Normalizar demais diminui a eficincia dos aplicativos e de menos abre flacos para inconsistncia.
Antes de entrarmos em detalhes sobre as formas normais, vamos olhar alguns problamas de relaes mal normalizadas
5.3 Anomalias de Modificaes

Considere a figura 5.1, ela demonstra uma tabela contndo nome de alunos de uma academia e suas respectivas
atividades fsicas com seus respectivos valores.
Esta tabela representada pela seguinte relao:
cliente = {nome, atividade, taxa}
42
CAPTULO 5. NORMALIZAO DE RELAES
43
Tabela 5.1: Relao Aluno

Nome
Atividade
Taxa
Jos
Musculacao 30,00
Pedro
Jud
35,00
Manoel
Judo
35,00
Suponha a tupla do aluno Jos, bem neste caso, perdemos, alm do nome do aluno, as informaes referentes a
atividade Musculao, bem como seu valor.
Este problema denominado Anomalia de Eliminao.
Outro problema ocorre quando a academia implanta um novo curso e no podemos inseri-lo at que um aluno
tenha a disposio de faze-lo.
Isto denominado Anomalia de Insero.
Agora, note que Jud, est grafado de forma errada na tupla do aluno Manoel. Se uma busca for feita por Jud,
s ir aparecer 1 aluno e no 2 alunos
Denominamos estes problema como Anomalia de Modificao.
5.4 Primeira Forma Normal

As Formas Normais tm nomes pelas quais so conhecidas.
Para o modelo relacional, a Forma Normal (FN) mais importnte a chamada 1 forma normal (1FN).
Definio da 1FN
Uma relao est na 1FN quando todos os seus atributos so Atmicos e Monovalorados.
Um atributo atmico aquele que no tratado em partes separadas.
Um atributo monovalorado aquele que possui somente um valor (no uma lista).
Considere a seguinte relao:
cliente={CPF, nome, endereo, (telefone)}
A relao Cliente no est na 1FN, porque Nome e Endereco so atributos compostos e telefone um atributo
multivalorado.
A normalizao desta relao resulta nas seguintes relaes:
cliente={CPF, nome, sobrenome, rua, numero_casa, bairro}
cliente_telefone = {CPF, DDD, numero_tel}
Note que Telefone foi para uma nova relao composta pela chave primria de cliente mais o telefone (decomposto). Todos os atributos da relao Cliente_Telefone fazem parte da chave primria.
Outros exemplos
44
curso = {cod_curso, descricao, (ra_aluno, nome_aluno)

obra = {cod_obra, preco, (cidades))
De forma geral, para determinar a chave primria de uma tabela originada pela regra da 1FN deve-se proceder
como segue:
1. Tomar como parte da chave primria da tabela na 1FN a chave primria da tabela Original.
2. Verificar se esta chave primria suficiente para identificar as linhas da tabela na 1FN.
(a) Caso seja suficiente, a chave primria da tabela na 1FN a mesma que a da tabela Original.
(b) Caso contrrio, deve-se determinar quais as demais colunas que so necessrias para identificar as
linhas da tabela na 1FN, compondo assim a chave primria na 1FN.
5.5 Dependncia Funcional

Para entender as duas formas normais que sero apresentadas a seguir necessrio compreender o conceito
Dependncia Funcional.
Dependncia Funcional um relacionamento entre pelo menos dois atributos.
Se o valor de um conjunto de atributos A permite descobrir o valor de um outro conjunto B, dizemos que A
determina funcionalmente B ou que B depende de A. Denotamos esta rela da seguinte forma:
A -> B
Exemplo:
RA -> Nome, Idade, Curso
(Sigla, Sala, Hora) -> Codigo_Turma
Importante:
As dependncias Funcionais devem ser identificadas pelo projetista do sistema sendo desenvolvido, NO EXISTE MANEIRA DE INFERIR AS DEPENDNCIAS A PARTIR DA DESCRIO
DA BASE.
5.6 Segunda Forma Normal (2FN)

A 2 FN est relacionada com as Dependncias Funcionais.
Definio da 2FN
Uma tabela encontra-se na segunda forma normal, quando, alm de estar na 1FN, no contm
Dependncias Funcionais Parciais, ou seja, todos atributos no chave devem depender funcionamente da chave primria composta.
Importante:
Deve-se verificar a violao da 2FN somente se a relao contiver chaves compostas.
Considere o seguinte exemplo:
45
aluno_disciplina = {ra_aluno, cod_discip, nome_aluno, carga_horar_discip, nota}

As dependncias funcionais so:
ra_aluno -> nome_aluno
cod_discip -> carga_horar_discip
(ra_aluno,cod_aluno) -> nota
Pela demonstrao das dependncias percebemos que existem atributos que contm dependncia parcial da
chave, neste caso, nome_aluno depende ra_aluno e carga_horar_discip depende cod_discip.
Isto caracteriza a violao da 2FN, visto que nesta regra no deve-se existir dependncia parcial da chave.
A normalizao desta relao ficaria da seguinte forma.
aluno_discipla = {ra_aluno, cod_discip, nota}
disciplina = {cod_discip, carga_horar_discip}
aluno = {ra_aluno, nome_aluno}
A normalizao foi feita da seguinte forma:
1. Mantm-se na tabela original as chaves e os atributos que dependem totalmente dela.
2. Para cada chave que possua atributos dependentes, cria-se uma nova relao, neste caso Aluno e Disciplina.
Outros exemplos:
projeto_funcionario = {cod_proj, cod_func, nome, categoria, salario, data_ini, temp_proj}
onde:
(cod_proj,cod_func) -> data_ini, temp_proj
cod_func -> nome, categoria, salario
cliente_produto = {cpf_cli, cod_prod, nome_cli, end_cli, (telef_cli), valor_unit, qtdade)
onde:
(cfp_cli, cod_prod) -> qtdade
cpf_cli -> nome_cli, end_cli, telef_cli
cod_prod -> valor_init
5.7 Terceira Forma Normal (3FN)

A 3FN resolve problemas relacionados com Dependcias Transitivas.
Diz-se que um atributo tem dependncia transitiva quando depender de outro atributo que no a chave primria
da relao. Observe o exemplo:
compra = {cod_compra, cod_cliente, nome_cliente, valor_compra, tel_cliente}
cod_compra -> cod_cliente, valor_compra
cod_cliente -> nome_cliente, tel_cliente
Perceba que o atributo chave primria cod_compra identifica os atributos cod_cliente e valor_compra e que o
atributo cod_cliente, que no chave primria, identifica os atributos nome_cliente e tel_cliente. Ento,
tanto nome_cliente como tel_cliente depende transitivamente de um atributo (neste caso cod_cliente) que
no chave primria.
46
Definio da 3FN:
Uma Relao est na 3 Forma Normal quando estiver na 1 FN e no existir dependncia transitiva dos atributos.
A normalizao de uma relao para a 3FN dar-se pela seguinte maneira:
Verifica-se um grupo de atributo que depende no diretamente da chave.

Retira-se da relao esse grupo de atributos.

Cria-se uma nova relao que contm esse grupo de atributos e inclui-se nela como chave os atributos dos
quais esse grupo depende diretamente.

Repetem-se esses passos at que todos os atributos restantes na relao original dependam diretamente de
toda sua chave.
Exemplos
* compra = {cod_compra, cod_cliente, nome_cliente, valor_compra, tel_cliente}
compra = {cod_compra, cod_cliente, valor_compra}
cliente = {cod_cliente, nome_cliente, tel_cliente}
* chamada_funcionario = {rg_funcion, num_chamado, duracao_chamada, nome_funcion, cod_cidade_chamad

nome_cidade_chamada}
chamada_funcionario = {rg_funcion, num_chamado, duracao_chamada, cod_cidade}
funcionario = {rg_funcion, nome_funcion}
cidade = {cod_cidade, nome_cidade}
5.8 Exemplo Prtico

Vamos agora considerar um exemplo prtico, baseado em uma nota fisca de compra representada pela figura 5.1.

Numero Nota Fiscal:
Codigo do Cliente:
Nome do Cliente:
Logradouro Cliente
(rua, bairro,etc):
Cod.Prod
Desc.Prod
47
Data da Nota:
Telefone Cliente:
Qtdade Val.Prod Val.Total
Figura 5.1: Nota Fiscal

Considere que um analista mapeou a nota para o seguinte esquema relacional:
nota_fiscal = {num_nota, cod_cliente, nome_cliente, logradouro_cliente, telefone_cliente, data_nota_fiscal,
(cod_produto, desc_produto, qtdade, valor_produto, valor_total)}
Ao analisarmos esta relao, notamos que mesma causar problemas de inconsistncia de dados. Bem, para
evitarmos futuros problemas, vamos aplicar as formas normais e corrigir erros na relao.
1. Primeira forma normal:
A relao no est na 1FN pois existem atributos mutivalorados e compostos. Vamos ento passar para a
1FN:
nota_fiscal = {num_nota, cod_cliente, rua_cliente, bairro_cliente, cep_cliente, cidade_cliente, telefone_cliente,
data_nota_fiscal}
nota_produto = {num_nota, cod_produto, desc_produto, qtdade, valor_produto, valor_total}
2. Segunda forma normal:
A relao no est na 2FN pois existem atributos com dependncia parcial da chave primria:
nota_fiscal = {num_nota, cod_cliente, rua_cliente, bairro_cliente, cep_cliente, cidade_cliente, telefone_cliente,
data_nota_fiscal}
nota_produto = {num_nota, cod_produto, qtdade, valor_total}
produto = {cod_produto, desc_produto, valor_produto}
3. Terceira forma normal:
A relao no est na 3FN pois existem atributos com dependncia transitiva:
nota_fiscal = {num_nota, cod_cliente, data_nota_fiscal}
cliente = {cod_cliente, rua_cliente, bairro_cliente, cep_cliente, cidade_cliente, telefone_cliente}
nota_produto = {num_nota, cod_produto, qtdade, valor_total}
produto = {cod_produto, desc_produto, valor_produto}
Temos:
Dom(cliente.cod_cliente) = Dom(nota_fiscal.cod_cliente)
Dom(nota_fiscal.num_nota) =Dom(nota_produto.num_nota)
Dom(produto.cod_produto) = Dom(nota_produto.cod_produto)
48
5.9 Exerccios
1. Identifique, nas relaes abaixo, as dependncias funcionais e se h violao de alguma forma normal (1, 2 e
3), se houver, normalize-as. Obs: Os campos que esto entre (parnteses) , indicam campos multivalorados.
(a) Funcionario={RG, nome, endereco, dada_nasc.}
(b) Projeto={Codigo, descricao, (cidade),ano}
(c) Atleta={ID_Atleta, Nome, numero_entidade_patricinadora, ender_entidade_patrocinadora, sexo, (numero_documento, orgao_expedidor_documento, data_expedicao_documento)}
(d) Pedido= {Numero, data, item, descricao_item, quatidade, valor_do_pedido}
(e) Aluno={ RA, nome_aluno, Endereco, cod_professor, nome_professor, cod_disciplina, descricao_disciplina}
(f) Emprestimo={ Cod_agencia, cidade_agencia, cic_cliente, nome_cliente, (endereco_cliente), valor_emprsti

(g) Salario={RG_Func, nome_funcion, (data_salario, valor)}
(h) Gerencia={Cod_Depart, RG_Gerente, descricao_depart}
2. D o conjunto de dependncias funcionais para o esquema relacional R(A,B,C,D) com chave primria nos
atributos AB. Sabe-se que a relao est na 1FN mas no est na 2FN.
3. Defina a terceira forma normal. D um exemplo de uma relao em 2FN mas no em 3FN. Transforme a
relao em relao em 3FN.
Captulo 6
lgebra Relacional
6.1 Introduo
A lgebra relacional uma linguagem de consulta procedural. Consiste em um conjunto de operaes que usam
uma ou mais relaes como entrada e produz uma nova relao.
Importante
Toda as operaes da lgebra sobre uma relao produz uma outra relao. Mesmo que a relao
resultante seja vazia.
As principais operaes so:
Seleo

Projeo

Unio

Diferena

Inteseco

Produto Cartesiano

Juno

Diviso
Antes de estudarmos cada uma destas operaes, considere as instncias das relaes que compe o banco de
dados:
cod_cli
c1
c3
c2
c4
nome_cli
rua
Joao
Rua TT
Pedro
Rua A4
Marcos Rua XY
Maria
Rua A
cidade
Rio Preto
Sao Paulo
Sao Paulo
Belo Horizonte
cod_agenc
ag1
ag4
ag3
ag2
49
nome_agenc
Sao Jose
Botafogo
Praiana
Bom Retiro
gerente
cidade
Pedro
Sao Paulo
Manoel Rio de Janeiro
Dario
So Paulo
Pedro Belo Horizonte
CAPTULO 6. LGEBRA RELACIONAL
50
Relao Cliente
Relao Agncia
cod_agenc cod_cli num_emprest valor
ag3
c4
e100
1500
ag2
c2
e500
800
ag2
c2
e550
100
ag1
c1
e230
1200
ag3
c1
e150
150
Relao Emprstimo
cod_agenc cod_cli num_conta saldo

ag1
c3
101
500
ag2
c2
215
780
ag1
c1
102
400
ag3
c4
305
350
ag3
c3
105
230
Relao Conta
6.2 Operao Selecionar ( )

A operao Selecionar seleciona tuplas que satisfazem um dado predicado.

representada pela letre grega Sigma ( ).
Considere a consulta:
Encontre os emprestimos feito na agncia ag2.
A resposta em lgebra relacional seria:
cod_agenc=ag2 (emprestimo);
O resultado desta consulta traria as seguintes tuplas:
cod_agenc
ag2
ag2
cod_cli
c2
c2
num_emprest
e500
e550
valor
800
100
Podemos querer saber todas as contas que possuem saldo maior do que 400 escrevendo:
saldo>400(conta);
cod_agenc
ag1
ag2
cod_cli num_conta saldo

c3
101
500
c2
215
780
Geralmente, permitimos as comparaes =,

, <,

, >,

Alm disso, diversos predicados podem ser combinados em um predicado maior usando os conectivos AND ( )
e OR ( ).

Por exemplo, para encontrar os emprestim os maiores do que 500 e realizados na agncia ag2.
cod_agenc=ag2
cod_agenc
ag2
valor > 500 (emprestimo);
cod_cli num_emprest valor

c2
e500
800
51
6.3 A Operao Projetar ( )

Representada pela letra grega pi ( ), a operao projetar seleciona (projeta)atributos especficos de uma relao.
O resultado da projeo uma nova relao com os atributos selecionados.
Suponha que desejemos saber o nome de todos os clientes de um banco:

nome_cli(cliente);
Teriamos como resposta:

nome_cli
Joao
Pedro
Marcos
Maria
Agora queremos saber o nome dos gerentes e suas respectivas agncias:
gerente, nome_agenc(agencia);
gerente nome_agenc
Pedro
Sao Jose
Manoel
Botafogo
Dario
Praiana
Pedro
Bom Retiro
Suponha que desejemos saber o nome de todos os gerentes, sem saber suas agncias:
gerente(agencia);
gerente
Pedro
Manoel
Dario
Note que apareceu apenas um gerente de nome Pedro. Isto se d ao fato que que para a lgebra, uma relao
um conjunto de elementos, e eu um conjunto no existem valores repedidos.
Podemos combinar as operaes de projeo com seleo.
Considere a consulta no qual desejemos os nomes dos clientes que residem em So Paulo:
nome_cli ( cidade=Sao Paulo(cliente));

nome_cli
Pedro
Marcos
Ou seno o codigo da agncia e o codigo do cliente cujo saldo da conta seja inferior ou igual a 400:
52
cod_agenc, cod_cli ( saldo 400(saldo));

cod_agenc
ag1
ag3
ag3
cod_cli
c1
c4
c3
IMPORTANTE
As operaes de Projetar e Selecionar so consideradas unrias. Pois operam sobre apenas uma
nica relao.
As operaes estudadas a seguir devem operar sobre relaes compatveis em domnio, ou seja, devem possuir
o mesmo nmero de atributos e os atributos nas colunas correspondentes devem vir do mesmo domnio.
6.4 A Operao Unio ( )

A unio de duas relaes formada pela adio das tuplas de uma relao s tuplas de uma segunda relao, para
produzir uma terceira.
representada, como na teoria dos conjuntos, pelo smbolo .
Como exemplo, queremos saber todos os clientes (cod_cli) que possuem contas ou qaue fizeram emprstimos na
agncia ag3. Existe duas maneiras de realizar esta consulta:
Maneira 1:
R1 = cod_cli( cod_agenc=ag3(conta));
R2 = cod_cli( cod_agenc=ag3(emprestimo));
R3 = R1 R2;
Maneira 2:
cod_cli( cod_agenc=ag3(conta))
cod_cli( cod_agenc=ag3(emprestimo));
Resultado
cod_cli
c4
c1
c3
6.5 A Operao Interseco de Conjuntos ( )

Esta operao produz atua sobre duas relao compatveis em domnio e produz uma terceira contendo as tuplas
que aparecem simultaneamente nas duas relaes. representada pelo smbolo .
Consulta: Encontre os codigos dos cliente que possuem contas e que fizeram emprestimos.
53
R1 = cod_cli (conta);
R2 = cod_cli (emprestimo);
R3 = R1 R2;
cod_cli
c4
c2
c1
6.6 A Operao Diferena de Conjuntos (-)

A diferena de duas relaes uma terceira relao contendo as tuplas que ocorrem na primeira relao mas no
ocorrem na segunda.
representado pela smbolo -.
Considere que desejemos encontrar todos os clientes (cod_cli) que possuem contas mas no fizeram emprestimos:
R1= cod_cli(conta);
R2= cod_cli(emprestimo);
R3=R1-R2;
cod_cli
c3
As operaes a seguir no necessitam ser compatveis em domnio.
6.7 A Operao Produto Cartesiano (X)

O produto de duas relaes a concatenao de todas as tuplas de uma relao com todas as tuplas de uma
segunda relao.
O produto da relao A (tendo m tuplas) com a relao B (tendo n tuplas) um relao contendo m vezes n
tuplas.
A representao do produto cartesiano feito pelo smbolo X.
Consulta: Encontre o nome dos clientes e o nmero de suas respectivas contas bancrias que possuem saldo
maior do que 450:
R1= saldo>450(conta);
R2=cliente X R1;

cliente. cliente.
cliente.
cod_cli nome_cli
rua
c1
Joao
Rua TT
c1
Joao
Rua TT
c3
Pedro
Rua A4
c3
Pedro
Rua A4
c2
Marcos Rua XY
c2
Marcos Rua XY
c4
Maria
Rua A
c4
Maria
Rua A
54
cliente.
conta.
conta.
conta.
conta.
cidade
cod_agenc cod_cli num_conta saldo
Rio Preto
ag1
c3
101
500
Rio Preto
ag2
c2
215
780
Sao Paulo
ag1
c3
101
500
Sao Paulo
ag2
c2
215
780
Sao Paulo
ag1
c3
101
500
Sao Paulo
ag2
c2
215
780
Belo Horizonte
ag1
c3
101
500
Belo Horizonte
ag2
c2
215
780
R3= nome_cli, num_conta( cliente.cod_cli = conta.cod_cli(R2));

nome_cli num_conta
c3
101
c2
215
6.8 A Operao Juno Natural (|X|)

Percebemos na operao de produto cartesiano que foi necessrio realizar uma seleo dos dados (R3= nome_cli,
num_conta( cliente.cod_cli = conta.cod_cli(R2));) em cima do produto entre as relaes conta e R1. Alm
do mais, um problema que ocorre no produto cartesiano o consumo excessivo de memria. Imagine duas
relao onde uma contm 3000 tuplas de 100 bytes cada e outra com 5000 tuplas de 200 bytes cada. Seria
necessrio 4.5 mb de memria para armazenar a relao resultante.
A operao juno natural as operaes de seleo e produto cartesiano em uma nica operao.
representada pelo smbolo |x|.
A operao de juno natural forma um produto cartesiano de seus dois argumentos, faz uma seleo forando
uma igualdade sobre os atributos que aparecem em ambas relaes e finalmente remove colunas duplicadas.
Vamos considerar novamente a consulta no qual desejemos saber o nome dos clientes e suas respectivas contas
bancrias que possuem saldo maior que 450. Pode ser realizado de duas maneiras:
Maneira 1:
R2= nome_cli, num_conta(cliente|x|num_cli=num_cli(R1));
Maneira 2:
R2= nome_cli, num_conta(cliente|x|R1)
// importante frisar que desta maneira, os atributos de juno esto implcitos no smbolo de
juno;
nome_cli num_conta
c3
101
c2
215
55
6.9 A Operao Diviso ( )

A operao diviso, representada por , retorna as tuplas da relao A que se relaciona com todas as tuplas da
relao B ao mesmo tempo. No uma operao importante como as anteriores.
Considere a consulta de que querer encontrar todos os clientes (cod_cli) que tem pelo menos uma conta em
todas as agncias de So Paulo:
R1= cod_agenc( cidade=Sao Paulo(agencia));
cod_agenc
ag1
ag3
R2= cod_cli, cod_agenc(conta);
cod_cli cod_agenc
c3
ag1
c2
ag2
c1
ag1
c4
ag3
c3
ag3
R3 = cod_cli, cod_agenc(R2)
cod_cli cod_agenc
c3
ag1
c3
ag3
cod_agenc(R1);
56
6.10 Exerccios
Considere as seguintes relaes para resoluo dos exerccios:
Relao Empregado
Relao Departamento
Nome
RG
CIC
Depto
RG_Gerent
Salrio
Joo Luiz
Fernando
Ricardo
Jorge
101010
202020
303030
404040
111111
222222
33333
444444
1
2
3
2
NULO
101010
101010
202020
3.000,00
2.500,00
2.300,00
4.200,00
Relao Projeto
PNum
5
10
20
PValor
PLocal
5.000,00 Sao Paulo
7.800,00 Rio Preto
9.500,00 Campinas
Relao Depart_Projeto
Dept_Num Num_Proj
2
5
3
10
2
20
Relao Dependente
RGResp DepenNome
101010
Jorge
101010
Luiz
202020
Fernanda
202020
Angelo
303030
Andreia
DNome
DNum
RG_Gerent
Contabil
Eng. Civil
Eng. Mecn.
1
2
3
101010
303030
202020
Data_Nasc Parent.
27/12/94
Filho
18/11/93
Filho
14/02/99
Filha
10/02/95
Filho
01/05/00
Filho
Sexo
M
M
F
M
M
Relao Emp_Proj
RG_Emp Num_Proj Horas
202020
5
10
202020
10
25
303030
5
35
404040
20
30
1. Obtenha as seguintes consultas.

(a) consulta = dnum>=1(departamento);
(b) consulta = rg_gerent=101010(empregado);
(c) consulta = nome, rg ( salario <= 2500(empregado));
(d) consulta = dept_num(depart_proj);

(e) consulta = rg_emp,num_proj( horas=35 (emp_proj);

(f) consulta = depennome( rgresp=202020( sexo="m"(dependentes)));

(g) consulta1= nome (empregado);

consulta2= depennome (dependentes);
consulta3= consulta1 consulta2;
(h) consulta = emp_proj X projeto;

(i) consulta = empregado|X| rg=rgresp(dependentes)
2. Forme as expresses em lgebra relacional dos seguintes enunciados:
(a) Liste o nome de todos funcionrios
(b) Liste o valor e a localizao de todos os projetos
(c) Liste o nome de todos os departamentos
(d) Encontre o nome, rg do responsvel e a data de nascimento de todos os dependentes
(e) Encontre o nome de todos os empregados que possuem dependentes
57
(f) Encontre o nome e salrio dos funcionrios que recebem acima de 2000
(g) Consulte os nomes dos empregados que trabalham em todos os projetos controlados pelo departamento 2.
(h) Encontre os nomes dos funcionrios que no possuem dependentes
(i) Para cada nome de empregado, obtenha o departamento que este gerencia.
(j) Com o nome do empregado Ricardo, monte uma pesquisa utilizando a lgebra relacional que mostre
os projetos que o funcionrio participa.
(k) Monte uma pesquisa em lgebra relacional utilizando o mesmo enunciado acima (enunciado L), porm
no utilizando a relao empregado_projeto.
(l) Liste o nome dos gerentes que possuem dependentes.
(m) Selecione todos os empregados que trabalham no departamento nmero 2 ou que supervisionam empregados que trabalham no departamento nmero 2.
3. Elabore a lgebra relacional para as consultas baseadas nas seguintes relaes. O Aluno pode instanciar as
relaes e inserir alguns dados.
Reside ={nome_pessoa, rua, cidade}
Trabalha ={nome_pessoa, nome_companhia, salrio}
Localizado ={nome_companhia, cidade}
Gerencia ={nome_pessoa, nome_gerente}
(a) D todos os funcionrios que moram na mesma cidade da companhia em que trabalham.
(b) D todos os funcionrios que vivem na mesma cidade que seu gerente.
(c) D todos os empregados que no trabalham para a empresa "Kangle Corporation"

326 BancodeDados PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

326 BancodeDados PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Fundao Educacional de Fernandpolis

Apostila de Banco de Dados

Mapeamento do Modelo ER para Modelo Relacional

6.9 A Operao Diviso ( ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

1.1 Sistema de Processamento de Arquivos

Programa para incluir novos registros na contabilidade.

Programa parabalano da contabilidade.

A medida que surge na necessidade, outros mdulos so desenvolvidos.

Redundncia e inconsistncia de dados: Redundncia a caracterstica onde um elemento de informao

Problemas de Integridade: Os valores armazenados BD devem satisfazer certos tipos de restries de

1.2 Independncia de Dados

Figura 1.1: Sistema de Processamento de Arquivo

No precisa entrar em detalhes de como seus dados esto fisicamente gravados;

Figura 1.2: Independencia de Dados provida pelo SGBD

1.3 Sistema Gerenciador de Banco de Dados (SGBD)

1.3.1 Caracterticas de um SGBD

COMPARTILHAMENTO DE DADOS:Em um ambiente multi-usurios deve-se possibilitar a manipulao

ACESSO EM MLTIPLAS INTERFACES: Possibilidade de usar diversas interfaces mesmo se o SGBD

RESTRIES DE INTEGRIDADE: Estabelecimento de um formato para os dados inseridos de modo a

1.4 Motivao para SGBDs

um sistema a mais a ser aprendido e gerenciado;

Ocupa espao de armazenagem no computador.

Porm traz vantagens muito maiores:

CONSISTNCIA DE DADOS E INDEPENDNCIA DE DADOS

Facilitam a proteo contra a perda de dados, atraves de recursos de backup;

Promovem a adoo de padres para toda a empresa, facilitando seu emprego.

1.4.1 Linguagens de acesso a um SGBD

Linguagem de Manipulao de Dados (DML): Responsvel por manipular os dados do SGBD.

1.4.2 Arquitetura de um SGBD

Exemplos para compreenso dos nveis:

No nvel interno: Os empregados so representados por um tipo de registro armazenado, denominado

Figura 1.3: Arquitetura de SGBD

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Figura 2.1: Exemplos de Entidades

Importante: As instncias de uma entidade no so representadas no DER.

Como representado na tabela 2.1.

Nome Data Admisso

Figura 2.2: Represetnao de Atributos

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

2.2.1 Chave Primria

No contm valor NULO.

Figura 2.3: Atributo Chave Primria

2.2.2 Atributos Multivalorados

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Figura 2.4: Atributos Multivalorados

2.2.3 Atributos Compostos

2.2.4 Atributo Derivado

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Figura 2.6: Atributo derivado (representado pela linha pontilhada).

2.3 Entidades Fracas

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Nome Data Admisso

A figura 2.9 representa graficamente a modelagem deste enunciado.

2.4.1 Atributos de Relacionamento

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Figura 2.8: Representao grfica de um relacionamento

Figura 2.9: Identificao de Entidade e Relacionamento

2.4.2 Cardinalidade dos Relacionamentos

2.4.3 Grau dos Relacionamentos

2.4.4 Relacionamentos Ternrios

CAPTULO 2. O MODELO ENTIDADE-RELACIONAMENTO

Figura 2.11: Tipos de Cardinalidade

Como Determinar as Cardinalidades de um Relacionamento Ternrio