Banco de Dados Apostila - Odt

Sumrio
1. CONCEITOS DE BANCOS DE DADOS.................................................................................................................... 9

1.1. DEFINIO.............................................................................................................................................................9
1.2. OBJETIVOS.............................................................................................................................................................9
1.3. SISTEMAS DE ARQUIVOS CONVENCIONAIS.................................................................................................9
1.4. USURIOS DE BANCO DE DADOS..................................................................................................................11
1.5. ABSTRAO DE DADOS................................................................................................................................... 11
1.6. INDEPENDNCIA DE DADOS...........................................................................................................................12
1.7. ARQUITETURA DE SISTEMAS DE BANCO DE DADOS [SILBERSCHATZ, 2006].....................................12
1.7.1. Sistemas Centralizados...................................................................................................................................12
1.7.2. Sistemas Cliente-Servidor..............................................................................................................................13
1.7.3. Sistemas Paralelos..........................................................................................................................................13
1.7.4. Sistemas distribudos......................................................................................................................................14
1.8. MODELOS DE BANCOS DE DADOS................................................................................................................14
1.8.1. Modelo em Rede.............................................................................................................................................14
1.8.2. Modelo Hierrquico.......................................................................................................................................15
1.8.3. Modelo Relacional..........................................................................................................................................16
1.8.4. Modelo Objeto-Relacional............................................................................................................................ 17
1.8.5. Modelo Orientados a Objetos........................................................................................................................17
1.9. ESTRUTURA GERAL DO SISTEMA..................................................................................................................18
1.9.1. Componentes de processamentos de consultas..............................................................................................18
1.9.2. Componentes para administrao do armazenamento de dados...................................................................18
1.9.3. Outras estruturas de dados............................................................................................................................ 18
1.10. LINGUAGEM DE DEFINIO DE DADOS (DDL)........................................................................................19
1.11. LINGUAGEM DE MANIPULAO DE DADOS (DML)................................................................................20
1.12. PROJETANDO BANCOS DE DADOS............................................................................................................. 20
2. MODELAGEM DE DADOS.......................................................................................................................................24
2.1. DEFINIO...........................................................................................................................................................24
2.2. ENTIDADES..........................................................................................................................................................24
2.4. RELACIONAMENTO...........................................................................................................................................25
2.4.1. Cardinalidade de relacionamento..................................................................................................................27
2.4.2. Tipos de Relacionamentos..............................................................................................................................29
2.4.3. Atributos de Relacionamentos [FALBO, 2009]..............................................................................................30
2.4.4. Generalizao / Especializao de conjuntos de entidades...........................................................................31
2.5. DICIONRIO DE DADOS................................................................................................................................... 32
2.6. FERRAMENTAS CASE........................................................................................................................................33
2.7. MODELO ER ESTENDIDO - EER.......................................................................................................................33
3. PROJETO LGICO DE BANCO DE DADOS........................................................................................................34
3.1. DEFINIO...........................................................................................................................................................34
3.2. ESTRUTURA DOS BANCOS DE DADOS RELACIONAIS..............................................................................34
3.3. CHAVES.................................................................................................................................................................35
3.4. PROPRIEDADES DO MODELO RELACIONAL [FALBO,2009]......................................................................36
3.5.1. Relacionamento 1:1........................................................................................................................................38
3.5.2. Relacionamento 1:N.......................................................................................................................................39
3.5.3. Relacionamento 1:N - identificado.................................................................................................................39
3.5.4. Relacionamento N:N......................................................................................................................................40
3.5.5. Generalizao e Especializao.....................................................................................................................40
3.5.6. Auto Relacionamento 1:N...............................................................................................................................41
3.5.7. Auto Relacionamento N:N..............................................................................................................................42
3.5.8. Atributos Multivalorados................................................................................................................................43
3.6. NORMALIZAO................................................................................................................................................43
3.6.1. Primeira Forma Normal (1FN)......................................................................................................................43
3.6.2. Segunda Forma Normal (2FN)......................................................................................................................44
3.6.3. Terceira Forma Normal (3FN).......................................................................................................................45
4. LINGUAGENS DE CONSULTA................................................................................................................................48
4.1. DEFINIO...........................................................................................................................................................48
4.2. LGEBRA RELACIONAL...................................................................................................................................48
4.2.1 Operaes Fundamentais................................................................................................................................49

4.2.2. Operaes No-Fundamentais.......................................................................................................................54
4.3. SQL.........................................................................................................................................................................58
4.3.1. Estrutura Bsica.............................................................................................................................................59
4.3.2. Linhas (tuplas) duplicadas.............................................................................................................................60
4.3.3. Predicados e ligaes.....................................................................................................................................60
4.3.4. Operaes de conjunto...................................................................................................................................62
4.3.5 Ordenando a exibio de tuplas......................................................................................................................62
4.3.6. Membros de conjuntos....................................................................................................................................63
4.3.7. Variveis tuplas (renomeao).......................................................................................................................63
4.3.8. Comparao de conjuntos..............................................................................................................................64
4.3.9. Testando relaes vazias................................................................................................................................64
4.3.10. Funes agregadas.......................................................................................................................................66
4.3.11. Removendo linhas de uma tabela.................................................................................................................68
4.3.12. Inserindo linhas em uma tabela...................................................................................................................68
4.3.13. Atualizando valores......................................................................................................................................69
4.3.14. Valores Nulos................................................................................................................................................70
4.3.15. Definio de dados.......................................................................................................................................71
4.3.16. Tipos de Domnios da Linguagem SQL........................................................................................................72
4.3.17. Integridade...................................................................................................................................................73
4.3.18. Implementando Integridade Referencial em SQL........................................................................................74
REFERNCIAS............................................................................................................................................................... 77
Captulo 1 -1. CONCEITOS DE BANCOS DE DADOS

1.1. DEFINIO
Um banco de dados, tambm conhecido como base de dados, um conjunto
de arquivos estruturados de forma a facilitar o acesso a conjuntos de dados.
Esses arquivos encontram-se, de alguma forma, relacionados. Por exemplo,
em um banco de dados de funcionrios de uma empresa podemos encontrar
alguns arquivos: dados pessoais (nome, endereo, dados de documentos,
lotao), dados funcionais (cargo, data de admisso, etc.) e dados para
pagamento (salrio base, faixas, etc.). Para obter informaes sobre um dado
funcionrio, como nome, cargo e salrio, ser necessrio consultar os trs
arquivos, que devem estar relacionados. Segundo Heuser, um banco de
dados um conjunto de dados integrados, cujo objetivo atender uma
comunidade de usurios [HEUSER, 2004].
Com o crescimento do volume e dos tipos de dados nas organizaes,
preciso utilizar softwares especiais para gerenciar os dados, os chamados
SGBDs (Sistemas Gerenciadores de Banco de Dados). Um SGBD um
software de carter geral para a manipulao eficiente de grandes colees
de informaes estruturadas e armazenadas de uma forma consistente e
integrada. Tais sistemas incluem mdulos para consulta, atualizao e as
interfaces entre o sistema e o usurio. Podemos afirmar, ento, que um
SGBD constitudo por um conjunto de dados associados a um conjunto de
programas para acesso a eles [SILBERSCHATZ, 2006].
1.2. OBJETIVOS
Dentre os principais objetivos do uso de Sistemas Gerenciadores de Bancos
de Dados, destacam-se:
Disponibilizar dados integrados para uma grande variedade de

usurios e aplicaes por meio de interfaces amigveis;
Garantir a privacidade dos dados por meio de medidas de segurana
dentro do sistema (como vises, permisses, senhas de acesso);
Permitir compartilhamento dos dados de forma organizada,
mediando a comunicao entre aplicaes e banco de dados e
administrando acessos concorrentes;
Possibilitar independncia dos dados, poupando ao usurio a
necessidade de conhecer detalhes de implementao interna,
organizao de arquivos e estruturas de armazenamento.
1.3. SISTEMAS DE ARQUIVOS CONVENCIONAIS

Os sistemas de processamento de arquivos caracterizam-se por uma srie de
registros guardados em diversos arquivos e uma srie de programas
aplicativos para extrair e adicionar registros nos arquivos apropriados.
Podemos citar como desvantagens desse sistema (arquivos), em relao aos

SGBDs [SILBERSCHATZ,2006]:
Redundncia e inconsistncia de dados. Considerando que diferentes
programadores tm a possibilidade de criar arquivos com estruturas
diferentes e aplicaes para acess-los, a possibilidade de se redundar dados
por esses arquivos muito grande. Alm disso, em funo dessa
redundncia, podero ocorrer as inconsistncias, considerando que os dados
podero ser atualizados em alguns arquivos e em outros no;
Dificuldade no acesso aos dados. Diferentemente dos SGBDs, os sistemas
de arquivos no possuem um ambiente para recuperao dos dados
armazenados. Com isso, para cada informao a ser gerada, necessrio
construir uma aplicao;
Isolamento de dados. Considerando a diversidade de formatos existen tes
dos arquivos e, consequentemente, dos dados armazenados neles, torna-se
uma tarefa difcil a construo de aplicaes para a recuperao desses
dados;
Problemas de atomicidade. O conceito de atomicidade est altamente
relacionado ao de tomo, que se caracteriza como algo indivisvel. Quando
se fala em atomicidade em banco de dados, fala-se de uma unidade de
trabalho que se deve executar totalmente ou que no se deve executar. Um
exemplo clssico de atomicidade seria uma transferncia de dinheiro entre
duas contas, A e B. Se desejarmos transferir, por exemplo, R$ 100,00 da
conta A para a Conta B, ou o ser transferido integralmente ou no ocorrer a
transferncia. No cabvel que o dinheiro saia da conta A e no entre na
conta B, por exemplo!
Anomalias de acesso concorrente. Considerando o acesso simultneo aos
arquivos, por diferentes aplicaes ou por diferentes usurios de uma mesma
aplicao, pode-se gerar inconsistncias nesses arquivos, devido a esses
acessos. Tomemos como exemplo que uma conta conjunta A - com saldo
igual a R$ 1000,00 - foi acessada de forma simultnea pelos correntistas
Gabriel e Luiza. Gabriel sacou R$100,00 e Luiza, R$200,00. Pergunta-se:
qual o saldo da conta aps os saques? Se ambos leram o valor do saldo igual
a R$1000,00, podemos ter como possveis valores : R$900,00, R$800,00,
levando-se em conta qual valor foi escrito por ltimo. Nesse caso, nenhum
dos dois valores so os corretos. O correto seria ter um saldo igual a
R$700,00.
Problemas de segurana. Nem todos os usurios possuem perfil para
acessar a todos os dados disponveis em um arquivo. Tomemos como
exemplo um arquivo de funcionrios, que possui, entre outros dados, o valor
do salrio do funcionrio. Embora tenhamos a curiosidade de saber o salrio
dos nossos colegas, principalmente do nosso chefe, no politicamente
correto que desrespeitemos seu direito privacidade. No entanto, no
possivel definir, para um arquivo, que alguns campos podero ser visveis
por um usurio e por outros no, o que gera vulnerabilidade nesses sistemas;
Problemas de integridade. Para explicar melhor esse item, tomemos como
exemplo dois arquivos, um de scios e outro de dependentes, de uma
10
locadora de vdeo. Um dependente est relacionado a um scio e, por

consequncia, a existncia daquele depende da existncia deste, ao qual
estar subordinado. Desse modo, a excluso de um scio acarreta a excluso
de seus dependentes. Esse tipo de integridade, denomina-se de integridade
referencial, porm, existem outras mais simples que os arquivos no
comportam.
1.4. USURIOS DE BANCO DE DADOS

Basicamente so quatro os tipos de usurios de sistemas de bancos de dados:
Usurios leigos: interagem com o banco de dados por meio das interfaces de
aplicaes escritas por programadores de aplicaes;
Usurios avanados: interagem com os bancos de dados por meio de
interfaces disponveis nesse ambiente. Escrevem consultas SQL e submetem
execuo sem a necessidade de escrever uma aplicao para esse fim;
Programadores aplicaes: usurios com formao em computao e que
se propem a construir aplicaes, por meio de ferramentas (compiladores)
destinadas para esse fim. Utilizando essas ferramentas, constroem interfaces
para as aplicaes, incluindo formulrios e relatrios, acessando bancos de
dados;
Administrador de Banco de Dados (DBA): usurios mais especializados
para um banco de dados. Cabe a eles a administrao dessas bases, definio
da melhor estrutura de armazenamento desses dados, definio de aspectos
de segurana, programao de cpias de segurana (backups), dentre outros.
1.5. ABSTRAO DE DADOS

Considerando que o nvel de conhecimento dos usurios de bancos de dados
muito varivel, oscilando entre aqueles que conhecem muito e outros que
so leigos, os Sistemas de Bancos de Dados devem prover de mecanismos
que administrem essa complexidade, simplificando as interaes dos
usurios com o sistema. Para isso, trs nveis de abstrao so considerados:
Nvel de Viso. Diz respeito forma como os dados so vistos pelos
usurios (individualmente). Diferentes usurios podero ter diferentes vises
de um mesmo banco de dados. Um determinado usurio, tanto pode ser um
programador de aplicaes, quanto um usurio final. O DBA um caso
especialmente importante. Ao contrrio dos usurios comuns, o DBA ter de
se interessar pelos nveis conceitual e fsico.
Lgico. O nvel lgico descreve quais dados esto armazenados no banco de
dados e qual a relao existente entre eles. Podemos dizer que a viso lgica
11
a viso dos dados como realmente so e no como os usurios so

forados a v-los devido s restries de linguagem ou hardware.
Fsico. Diz respeito forma como os dados esto armazenados fisicamente.
Preocupa-se em descrever as estruturas de dados complexas de baixo nvel.
A figura 1 representa graficamente os nveis listados acima.

Viso 1
Viso 2
...
Viso n
Nvel Lgico
Nvel Fsico
Figura 1: Nveis de abstrao de dados

Fonte: Silberschatz, Korth e Sudarshan, 2006. Adaptao.
1.6. INDEPENDNCIA DE DADOS

A independncia de dados pode ser definida como a imunidade das
aplicaes s alteraes feitas, seja no nvel fsico seja no nvel lgico de um
banco de dados. O objetivo alcanar o mximo de independncia possvel.
Pode ser classificada em:
Independncia Fsica de dados: habilidade de modificar o esquema fsico,
sem a necessidade de reescrever os programas aplicativos. As modificaes
no nvel fsico so ocasionalmente necessrias para melhorar o desempenho.
Independncia Lgica de dados: habilidade de modificar o esquema
conceitual, sem a necessidade de reescrever os programas aplicativos. As
modificaes no nvel conceitual so necessrias quando a estrutura lgica
do banco de dados alterada.
1.7. ARQUITETURA DE SISTEMAS DE BANCO DE

DADOS [SILBERSCHATZ, 2006]
A arquitetura de um sistema de banco de dados est altamente relacionada
s caractersticas do sistema operacional sobre o qual o SGBD ser
executado.
12
1.1.1.7.1. Sistemas Centralizados

Os sistemas centralizados so os executados sobre um nico sistema
operacional, no interagindo com outros sistemas. Eles podem ter a
envergadura de um sistema de banco de dados de um s usurio, executado
em um computador pessoal ou em sistemas de alto desempenho,
denominados de grande porte.
1.2.1.7.2. Sistemas Cliente-Servidor

Como os computadores pessoais tm se tornado mais rpidos, mais potentes
e baratos, h uma tendncia de seu uso nos sistemas centralizados. Terminais
conectados a sistemas centralizados esto sendo substitudos por
computadores pessoais. Como resultado, os sistemas centralizados
atualmente agem como sistemas servidores que atendem a solicitaes de
sistemas clientes.
A computao cliente-servidor um processamento cooperativo de
informaes de negcio por um conjunto de processadores, no qual
mltiplos clientes iniciam requisies que so realizadas por um ou mais
servidores centrais.
O termo cliente-servidor usado para descrever software que executa em
mais de um hardware de modo a realizar uma tarefa do negcio. A separao
de hardware a norma em aplicaes cliente-servidor, embora algumas
pessoas utilizem o termo para descrever diferentes componentes de software
se comunicando uns com os outros, ainda que rodando em uma mesma
mquina. A distncia entre processadores remotos varia desde computadores
localizados na mesma sala ou prdio, at aqueles localizados em diferentes
prdios, cidades ou mesmo espalhados pelo planeta.
Nessa arquitetura, as funcionalidades de um banco de dados podem ser
superficialmente divididas em duas categorias: front-end e back-end. O
back-end gerencia as estruturas de acesso, o desenvolvimento e a otimizao
de consultas, o controle de concorrncia e a recuperao. O front-end
consiste em ferramentas como formulrios, gerador de relatrios e recursos
de interface grfica. A interface entre o front-end e o back-end feita por
meio de SQL ou de um programa de aplicao.
1.3.1.7.3. Sistemas Paralelos

Sistemas paralelos imprimem velocidade ao processamento e CPU, por
meio do uso em paralelo de CPUs e discos.
No processamento paralelo muitas operaes so realizadas ao mesmo
tempo, ao contrrio do processamento serial, no qual os passos do
processamento so sucessivos. Um equipamento paralelo de granulaogrossa consiste em poucos e poderosos processadores (a maioria dos
13
servidores atuais), enquanto um paralelismo intensivo ou de granulao fina

usa milhares de pequenos processadores, com capacidade menor de
processamento. Computadores paralelos com centenas de processadores j
esto disponveis comercialmente.
As duas principais formas de avaliar o desempenho de um sistema de banco
de dados so pelo throughput e pelo tempo de resposta. O primeiro diz
respeito ao nmero de tarefas que podem ser executadas em um dado
intervalo de tempo. Um sistema que processa um grande nmero de
pequenas transaes pode aumentar o throughput por meio do
processamento de diversas transaes em paralelo. J o tempo de resposta
diz respeito ao tempo total que o sistema pode levar para executar uma nica
tarefa. Um sistema que processa um grande volume de transaes pode
reduzir o tempo de resposta por meio de processamento em paralelo.
1.4.1.7.4. Sistemas distribudos

Em um sistema distribudo, o banco de dados armazenado,
geograficamente, em diversos computadores, denominados sites. Os
computadores de um sistema de banco de dados distribudos comunicam-se
com outros, por intermdio de vrios meios de comunicao, como redes de
alta velocidade ou linhas telefnicas.
As principais diferenas entre os bancos de dados paralelos e os bancos de
dados distribudos so que, nos bancos de dados distribudos, h a
distribuio fsica geogrfica, a administrao ocorre de forma separada e h
uma intercomunicao menor. Outra grande diferena que nos sistemas
distribudos distinguimos transaes locais (acessa um nico computador,
em que a transao foi iniciada) e globais (envolve mais de um computador,
sendo necessria a participao de um coordenador).
H diversas razes para a utilizao de sistemas de bancos de dados
distribudos, dentre as quais: compartilhamento dos dados (usurios de um
local podem ter acesso a dados residentes em outros por exemplo: bancos),
autonomia (cada local administra seus prprios dados) e disponibilidade (se
porventura uma SGBD sai do ar, os demais podem continuar em operao).
H, no entanto, algumas desvantagens relacionadas ao seu uso, dentre as
quais: custo de desenvolvimento de software, maior possibilidade de bugs e
aumento do processamento e sobrecarga.
1.8. MODELOS DE BANCOS DE DADOS

Os modelos de bancos de dados definem a forma como os dados encontramse organizados internamente. Em ordem cronolgica, os modelos de banco
de dados classificam-se em redes, hierrquicos, relacionais, objetorelacionais e orientados a objetos. A seguir, h uma breve descrio sobre
cada um desses modelos.
14
1.1.1.8.1. Modelo em Rede

Um banco de dados em rede consiste em uma coleo de registros que so
concatenados uns aos outros por meio de ligaes. Um registro , em muitos
aspectos, similar a uma entidade no modelo entidade-relacionamento. Uma
ligao uma associao entre dois registros. Assim, uma ligao pode ser
vista como um relacionamento binrio no modelo ER [SILBERSCHATZ,
2006].
Tanto o Modelo Rede como o Modelo Hierrquico podem ser considerados
como estruturas de dados em nvel lgico mais prximo do nvel fsico.
Devido a essa proximidade ao nvel fsico, as estruturas de dados rede e
hierrquica exibem as rotas lgicas de acesso de dados de forma acentuada,
possibilitando a localizao lgica de um determinado registro no banco de
dados.
O Modelo Relacional, quando comparado Estrutura Rede e Hierrquica,
mais orientado para modelagem do que como modelo com rotas de acesso,
embora possamos considerar as diversas redundncias existentes em diversas
tabelas como sendo uma forma de rota de acesso.
O Modelo Rede utiliza como elemento bsico de dados a ocorrncia de
registro. Um conjunto de ocorrncia de registro de um mesmo tipo determina
um tipo de registro.
Um conjunto de tipos de registros relacionados entre si, por meio de
referncias especiais, forma uma estrutura de dados em rede. As referncias
especiais so conhecidas como ligaes, que, por sua vez, podem ser
implementadas sob a forma de ponteiros.
As referncias esto normalmente inseridas junto com as ocorrncias de
registro; assim, todo o acesso a um prximo registro utiliza o ponteiro
inserido no registro corrente disponvel.
Considere um banco de dados com registros de departamento e
empregado, em que empregado possui as seguintes caractersticas:
matrcula, nome e cidade; e departamento: cdigo e nome. A figura 2
mostra um exemplo do banco de dados, considerando os dois tipos de
registros informados.
Figura 2: Exemplo de Banco de Dados Modelo Redes.
15
O modelo de banco de dados da Figura 2 mostra as ligaes entre os

registros de departamento e empregado. Luiza, por exemplo, est lotada no
departamento de informtica, enquanto o departamento de Geografia, por
exemplo, possui dois funcionrios lotados, Matheus e Gabriel.
1.2.1.8.2. Modelo Hierrquico

Um banco de dados hierrquico consiste em uma coleo de registros
relacionados, uns aos outros, por meio de ligaes, como no modelo em
redes. A diferena entre eles se d pelo fato de o banco de dados hierrquico
organizar esses registros como colees de rvores, em vez de grficos
arbitrrios.
Um banco de dados hierrquico compe-se de um conjunto ordenado de
rvores, mais precisamente, de um conjunto ordenado de ocorrncias
mltiplas de um tipo nico de rvore.
O tipo rvore compe-se de um nico tipo de registro raiz, juntamente
com um conjunto ordenado de zero ou mais (nvel inferior) tipos de subrvores dependentes. Um tipo de subrvore, por sua vez, tambm se compe
de um nico tipo de registro. A associao entre tipos de registros segue uma
hierarquia estabelecida por diversos nveis. No primeiro nvel, o superior,
situa-se o tipo de registro Raiz . Subordinado a ele, em nvel 2, uma srie
de outros tipos de registros em nvel 2. A cada tipo de registro em nvel 2
subordina-se um outro conjunto de tipos de registros. A prpria estrutura
hierrquica define as suas rotas de acesso, facilitando, portanto, a
manuteno do banco de dados.
importante notar que um determinado tipo de registro A, num determinado
nvel K, possui ligao com um e somente um tipo de registro B, de nvel K1 (superior). Nessas condies, A denominado registro PAI de B, que, por
sua vez, registro FILHO de A . No entanto, um tipo de registro A pode estar
ligado a diversos filhos no nvel de B. Todas as ocorrncias de um dado tipo
de filho que compartilham uma ocorrncia de pai comum so chamadas de
gmeas.
Uma vantagem dos bancos de dados hierrquicos o tempo de resposta em
consultas. No entanto, a atualizao pode ser bastante custosa.
16
Figura 3: Exemplo de Banco de Dados Modelo Hierrquico.
1.3.1.8.3. Modelo Relacional

O modelo relacional, diferentemente dos modelos redes e hierrquico, usa
um conjunto de tabelas para representar tanto os dados quanto a relao
entre eles. As ligaes entre as tabelas feita por meio dos valores dos
atributos ou colunas, conforme descrito posteriormente. Cada tabela possui
mltiplas colunas, conforme Tabela 1 e Tabela 2.
Matricula
01
02
03
04
Nome
Maria
Matheus
Gabriel
Joana
Cidade
Vitria
Vila Velha
Serra
Aracruz
CodDepto
01
02
02
03
Tabela 1: Tabela de Empregados.
CodDepto
01
02
03
NomeDepto
Informtica
Geografia
Portugus
Tabela 2: Tabela de Departamentos.
1.4.1.8.4. Modelo Objeto-Relacional

O modelo objeto-relacional, tambm conhecido como relacional estendido,
um modelo intermedirio entre o relacional e o orientado a objetos. Na
verdade, os bancos de dados que se enquadram nesse modelo caracterizamse por usar a estrutura bsica do modelo relacional, incorporando algumas
caractersticas dos bancos de dados orientados a objetos. Caractersticas
estas que incluem : herana de tipos e tabelas e definio de novos tipos
complexos. A SQL-99 inclui recursos para dar suporte a esse modelo de
banco de dados.
17
1.5.1.8.5. Modelo Orientados a Objetos

O modelo relacional, hierrquico e redes foram muito bem sucedidos no
desenvolvimento da tecnologia de banco de dados necessria para a maioria
das aplicaes convencionais de bancos de dados comerciais, possuindo,
entretanto, algumas limitaes quando aplicaes mais complexas precisam
ser projetadas e implementadas, tais como sistemas de informaes
geogrficas e multimdias. Essas aplicaes tm requisitos e caractersticas
que as diferenciam das tradicionais aplicaes comerciais, tais como
estruturas complexas para objetos, armazenamento de imagens e textos
longos, dentre outras, alm da necessidade de definir operaes no
convencionais (NAVATE, 2005).
A abordagem orientada a objetos oferece a flexibilidade para lidar com
alguns desses requisitos, sem estar limitada pelos tipos de dados e
linguagens de consulta disponveis em sistemas de banco de dados
tradicionais. Nesses bancos, o projetista especifica a estrutura de objetos
complexos bem como as operaes que incidem sobre esses objetos.
Outra razo para o uso de banco de dados orientados a objetos a
predominncia das linguagens orientadas a objetos. No caso de uma
aplicao orientada a objetos utilizar um banco de dados relacional para
persistir os dados, necessrio fazer um mapeamento entre esses dois
mundos, o que d trabalho, considerando as limitaes impostas pelo modelo
relacional.
Embora existam muitos benefcios para a adoo do modelo orientado a
objetos, esses bancos de dados no foram muito bem aceitos no mercado, em
funo da simplicidade do modelo relacional. Com isso, h uma proposta de
um modelo hbrido, denominado objeto-relacional ou relacional estendido,
que se prope a implementar alguns conceitos de orientao a objetos sobre
a estrutura de um banco de dados relacional. Alguns SGBDs proprietrios e
livres disponveis no mercado enquadram-se nesse modelo, a exemplo do
Oracle e do PostegreeSQL.
1.9. ESTRUTURA GERAL DO SISTEMA

O sistema de banco de dados dividido em mdulos especficos, de modo a
atender a todas as suas funes, algumas delas fornecidas pelo sistema
operacional. Esses mdulos podem ser organizados em dois grandes grupos:
o de processamentos de consultas e o de administrao do armazenamento
de dados. A Figura 4 mostra como esses componentes se relacionam.
18
1.1.1.9.1. Componentes de processamentos de consultas

Compilador DML.: traduz comandos DML da linguagem de consulta em
instrues de baixo nvel, inteligveis ao componente de execuo de
consultas.
Interpretador DDL: interpreta os comandos DDL e registra-os em um
conjunto de tabelas que contm metadados, dados sobre dados.
Componentes para o tratamento de consultas: executam instrues de
baixo nvel geradas pelo compilador DML.
1.2.1.9.2. Componentes
armazenamento de dados
para
administrao
do
Gerenciamento de autorizaes e integridade: testa o cumprimento das

regras de integridade e a permisso ao usurio no acesso aos dados.
Gerenciamento de transaes: garante que o banco de dados permanecer
em estado consistente, a despeito de falhas no sistema, e que as transaes
concorrentes sero executadas sem conflitos em seus procedimentos.
Gerenciador de arquivos: gerencia a alocao de espao no
armazenamento em disco e as estruturas de dados usadas para representar
essas informaes armazenadas em disco.
Gerenciador de buffer: intermedia os dados entre o disco e a memria
principal e decide quais dados colocar em cach.
1.3.1.9.3. Outras estruturas de dados

Diversas outras estruturas de dados so requeridas como parte da
implementao do sistema fsico, incluindo:
Arquivo de Dados: armazena o banco de dados.
Dicionrio de Dados: armazena informaes sobre os dados do banco de
dados.
ndices: permite o acesso mais rpido aos dados.
Estatsticas: armazenam informaes sobre o banco de dados e so usadas
pelo seletor de estratgias.
19
Figura 4: Estrutura Geral do Sistema

Fonte: Silberschatz, Korth e Sudarshan, 2006. Adaptao.
1.10. LINGUAGEM DE DEFINIO DE DADOS (DDL)

Contm a especificao dos esquemas dos bancos de dados. O resultado da
compilao de uma consulta de definio de dados (DDL) armazenado em
um conjunto de tabelas que constituem um arquivo especial chamado
dicionrio de dados. Um dicionrio de dados um arquivo de metadados.
20
1.11. LINGUAGEM DE MANIPULAO DE DADOS

(DML)
A linguagem de manipulao de dados (DML) a linguagem que viabiliza o
acesso aos dados ou a sua manipulao de forma compatvel com o modelo
de dados apropriado.
So responsveis pela:
Recuperao da informao armazenada no banco de dados

(SELECT);
Insero de novos dados nos bancos de dados (INSERT);
Eliminao de dados nos bancos de dados (DELETE);
Modificao de dados armazenados no banco de dados (UPDATE);
1.12. PROJETANDO BANCOS DE DADOS

Antes de criarmos o banco de dados propriamente dito devemos identificar
uma forma de planej-la. Esse planejamento extremamente importante para
a estabilidade de todo o sistema. Estudos indicam que quanto maior o tempo
gasto no projeto do banco de dados, menor ser o tempo despendido na
manuteno do modelo.
Podemos comparar a criao de um sistema de banco de dados com a
construo de uma casa. Imagine que seja construda uma casa sem que
antes tenha sido feito um projeto de arquitetura, incluindo plantas baixas,
cortes e fachadas. Provavelmente, no futuro, ao submeter essa casa
manuteno, o proprietrio teria o inconveniente de construir quartos do lado
da cozinha ou mesmo ter que fazer puxadinhas para realizar a ampliao
da mesma. O mesmo acontece com sistemas mal-projetados ou noprojetados. Eles tornam-se pouco flexveis a manutenes futuras, quando
for necessrio agregar novas informaes ou mesmo, quando submetidos a
correes.
O processo de projetar um banco de dados inclui trs fases distintas e
integradas. A primeira delas consiste na construo de um modelo
conceitual. O Modelo Conceitual inclui caractersticas a serem includas no
sistema, mas que independem da tecnologia a ser utilizada, tanto de banco de
dados quanto de linguagem de programao. A segunda fase pressupe a
construo de um modelo lgico, tendo como base o Modelo Conceitual
criado e inclui a definio de tabelas, campos, restries de integridade, etc.
Nesse modelo, considera-se a tecnologia do banco de dados a ser usado,
como: relacional, orientado a objetos, etc. A terceira fase, que extrapola a
fase de projeto, consiste na criao fsica do banco de dados, tendo a
preocupao com estruturas de armazenamento e recuperao dos dados a
serem armazenados. Nos captulos que se seguem sero explorados a
modelagem conceitual e o projeto lgico de banco de dados, considerando o
modelo relacional.
21
Atividade 01
Faa os exerccios de fixao abaixo, referente ao capitulo 1.
1) Defina SGBDs.
2) Cite duas desvantagens do uso de sistemas de arquivos em
relao a SGBDs.
3) Defina uma vantagem de se usar sistemas de arquivos em
relao a SGBD.
4) Cite as quatro arquiteturas de banco de dados existentes no
mercado. Descreva, em poucas linhas, as caractersticas de
cada uma delas.
5) Quais so os nveis de abstrao proporcionados por um
SGBD? Enquadre, para cada grupo de usurio, abaixo
listados, o nvel em que o mesmo se encontra.
a. Administrador de Banco de Dados
b. Usurio de aplicaes
c. Programador e Analista de Aplicaes
6) Liste, em ordem cronolgica, os modelos de bancos de
dados existentes no mercado. Qual modelo de banco de dados
ser utilizado em nossa disciplina?
22
Atividade 02
1) Dadas as relaes abaixo, responda ao que se pede.
Funcionrio
Matricula
01
02
03
04
05
06
Cargos
Cdigo
01
02
03
04
05
Nom
e
Ana
Maria
Jos
Pedro
Joana
Joo
CPF
Cargo
123
234
245
125
435
467
2
1
3
1
2
1
Nome Cargo
Programador
Topgrafo
Engenheiro
Pedreiro
Motorista
Liste os nomes dos funcionrios para os seguintes cargos:

Topgrafo; Engenheiro; Programador:
Para quais cargos no h funcionrios lotados?
2) Informe se cada uma das consultas abaixo ser executada
pelo Compilador DML ou pelo Interpretador DDL.
a) create table...
b) create view...
c) insert into tabela...
d) alter table...
e) delete from tabela...
f) update tabela set campo 1 = valor 1, campo2 = valor2...
23
Atividade 03
1) Numere a segunda coluna de acordo com a primeira.
1. Possibilidade de
erros de acesso
concorrente
( ) Refere-se preciso ou
validade dos dados.
2. Abstrao
dados
( ) Tarefa de um SGBD.
de
3. Integridade
( ) Se alterar o esquema
conceitual, no necessrio
reescrever aplicaes.
4. Instncia
(
)
Responsvel
pela
modificao
de
dados
armazenados no banco de
dados.
5. Independncia
lgica de dados
( ) Se alterar o esquema fsico,

no necessrio reescrever
aplicaes.
6. Independncia
fsica de dados
( ) Contm a especificao dos

esquemas de banco.
7. Controle
concorrncia
de
( ) Conjunto de informaes
contidas em determinado banco
de dados, em um determinado
momento.
8. Linguagem de
Definio de Dados
(DDL)
( ) Trata-se de um modelo de
banco de dados.
9. Linguagem de
Manipulao
de
Dados (DML)
( ) Os usurios no precisam
saber como os dados so
armazenados e mantidos.
10.
ObjetoRelacional
( ) Desvantagem de sistemas de
arquivos.
24
Captulo 2 -2. MODELAGEM DE DADOS

2.1. DEFINIO
O principal objetivo da modelagem conceitual de dados construir modelos
que representem os requerimentos das informaes do negcio, segundo a
perspectiva do usurio. Partindo desse princpio, ao construir modelos
conceituais no h uma preocupao com a tecnologia a ser adotada para a
sua implementao. Um modelo de dados consiste em uma coleo de
ferramentas conceituais para descrio de dados, relacionamento entre os
dados, semntica e restries [SILBERSCHATZ,2006]. Neste captulo
exploraremos o modelo de entidades e relacionamentos (ER) para construo
de modelos de dados, considerando que se trata da tcnica de modelagem
mais difundida para representao de modelos conceituais.
O modelo ER uma tcnica de modelagem conceitual utilizada para
representar os dados a serem armazenados em um sistema de informao,
tendo sido desenvolvida originalmente para dar suporte ao projeto de bancos
de dados [CHEN,1990]. Esse modelo foi criado em 1976 por Peter Chen e
pode ser considerado como padro para a modelagem conceitual.
Basicamente, o modelo ER representa as entidades (coisas) e os
relacionamentos (fatos) do mundo real, em que h o interesse de monitorar o
comportamento no sistema de informao em tese.
2.2. ENTIDADES
Entidades so representaes abstratas de coisas, objetos do mundo real
modelado, para os quais temos interesse em manter informaes no banco de
dados. Podem representar tanto objetos concretos quanto abstratos. Quando
se trata de conjuntos de objetos com caractersticas semelhantes, usualmente
se denomina conjunto de entidades. Por exemplo, quando nos referimos ao
conjunto de entidade Departamentos estamos falando de um conjunto de
departamentos. Quando nos referimos ao departamento de informtica,
estamos falando da entidade, de uma instncia do conjunto.
Um conjunto de entidades ser representado por meio de um retngulo
contendo o nome do conjunto de entidades, em letra maiscula e no plural,
conforme mostra exemplo da Figura 5.
Ex: FUNCIONRIOS, CARGOS, PESSOAS ...
Figura 5: Exemplo de representao de conjunto de entidades
Caractersticas dos conjuntos de entidades [FALBO, 2009]:
25
So substantivos e perduram no tempo.

Cada elemento de um conjunto de entidades s ocorre uma nica vez
e a ordenao do conjunto irrelevante.
A princpio so representados em um conjunto de entidades todos os
elementos do mundo real referidos pelo conjunto. Ex:
FUNCIONRIOS = todos os funcionrios de uma empresa.
Para estabelecermos uma padronizao, usaremos nomes de
conjuntos de entidades sempre no plural e escritos em letras
maisculas. No entanto, isso no representa uma regra.
2.3. ATRIBUTOS
Descrevem propriedades relevantes de um conjunto de entidades. Podem ser
representados no diagrama ou em um dicionrio de dados. Adotaremos esta
ltima abordagem com o intuito de mantermos um modelo mais legvel.
Seguem algumas caractersticas de atributos, segundo Falbo (2009):
Um atributo deve ser Completo e Fatorado, ou seja, deve abranger

todas as informaes pertinentes e cada atributo deve capturar um
aspecto em separado.
Existem atributos que podem assumir um nico valor ou mltiplos
valores,
sendo
classificados
como
monovalorados
ou
multivalorados, respectivamente. Como exemplo de atributos
monovalorados, podemos citar o nome de um funcionrio. O
telefone de um funcionrio um atributo multivalorado, pois pode
assumir mltiplos valores ao mesmo tempo ou at mesmo nenhum
valor.
Ao definir um atributo de um conjunto de entidades, importante tambm

definir a obrigatoriedade de preenchimento do mesmo. Um atributo para o
qual no haja um valor associado ou este valor no seja conhecido no
momento da criao da entidade, ento este atributo deve ser modelado para
aceitar valores vazios ou nulos.
Na criao de um conjunto de entidade deve-se definir um identificador. Um
identificador um conjunto de um ou mais atributos que podem ser
utilizados para identificar uma entidade dentro do conjunto. Por exemplo, a
matrcula de um funcionrio pode ser um atributo identificador,
considerando que cada funcionrio ter uma matrcula nica. O atributo
nome, no entanto, no pode ser usado para identificar um funcionrio,
considerando que existem homnimos.
2.4. RELACIONAMENTO
Na seo anterior descrevemos atributos de conjuntos de entidades, que so
propriedades dos objetos a serem armazenados em um banco de dados. Alm
dos atributos, os conjuntos de entidades caracterizam-se por relacionar-se
com outros conjuntos de entidades, inclusive com ela mesma. A essas
associaes denominamos relacionamentos, conjunto de associaes entre
entidades (HEUSER, 2004).
26
Neste texto adotaremos a seguinte notao: um relacionamento ser

representado por um losango com um verbo para indicar a ao e uma seta
para informar o sentido de leitura, conforme mostra a Figura 6 abaixo.
Figura 6: Exemplo de representao de relacionamento
A leitura feita para o relacionamento da Figura 6 funcionrios so

enquadrados em cargos. Todo relacionamento possui uma leitura inversa;
assim, uma outra leitura do relacionamento seria cargos enquadram
funcionrios.
O relacionamento existente entre os conjuntos de entidades funcionrios e
cargos um relacionamento binrio, pois se trata de uma associao entre
dois conjuntos de entidades. Quando o relacionamento envolve trs
conjuntos de entidades conhecido como ternrio.
Outros exemplos de relacionamentos:
Alunos cursam disciplinas / Disciplinas so cursadas por alunos;

Editoras publicam livros / Livros so publicados por editoras;
Autores escrevem livros / Livros so escritos por autores;
Para facilitar a visualizao foi construdo um diagrama de ocorrncia,

referente ao modelo ER da Figura 6. Esse diagrama se prope a mostrar as
ocorrncias de entidades do conjunto funcionrios, representadas por : f1, f2,
..., fn; as ocorrncias do conjunto cargos, representadas por : c1, c2, .., cn e
dos relacionamentos existentes entre as entidades do conjunto de
funcionrios e de cargos. O funcionrio f1 est enquadrado no cargo c1
atravs do relacionamento r1. O cargo c1, por outro lado, possui os
funcionrios f1 e f3, nele enquadrados, atravs dos relacionamentos r1 e r3.
27
ENQUADRAMENTOS
FUNCIONRIOS
f1
f2
f3
f4
f5
f6
f7 .
.
.
r1
CARGOS
r2
c1
r3
c2
r4
r5
r6
.
.
.
c3
r7
Figura 7: Diagrama de ocorrncias
Fonte: Heuser, 2004. Adaptao.
Entre duas entidades, podem existir vrios tipos de relacionamentos. A

Figura 8 mostra os relacionamentos de alocao e de gerncia entre os
mesmos conjuntos de entidades : FUNCIONRIOS e PROJETOS.
Figura 8: Entidades com dois tipos de relacionamento
Alm disso, uma entidade pode participar de relacionamentos com quaisquer

outras entidades do modelo, inclusive com ela mesma, como mostra o
relacionamento chefiam na Figura 9. Nesse caso, denomina-se que h um
auto-relacionamento do conjunto de entidades FUNCIONRIOS.
28
Figura 9: Exemplo de auto-relacionamento
2.1.2.4.1. Cardinalidade de relacionamento

Indica os nmeros mnimo (cardinalidade mnima) e mximo (cardinalidade
mxima) de ocorrncias possveis, entre dois conjuntos de entidades, em um
relacionamento. No diagrama de ocorrncia da Figura 7, observamos que :
um cargo pode enquadrar vrios funcionrios, enquanto que um funcionrio
deve ser enquadrado em apenas um cargo.
A Figura 10 mostra a representao de cardinalidade no modelo ER. A
leitura feita da seguinte forma: um funcionrio enquadrado em, no
mnimo 1 e no mximo 1 cargo, enquanto um cargo pode enquadrarno
mnimo zero e no mximo n funcionrios. N um nmero arbitrrio.
Quando conhecemos esse nmero podemos represent-lo, em vez de o
determinarmos pela letra N. Para efeito de projeto de banco de dados, o
tratamento dado para esse nmero arbitrrio o mesmo, para qualquer valor
maior que 1.
Figura 10: Entidades com dois tipos de relacionamento
29
2.2.2.4.2. Tipos de Relacionamentos

O tipo de relacionamento uma classificao baseada na cardinalidade
mxima, podendo ser : 1:1, 1:N, N:1 e N:N. A seguir, sero explorados
todos os tipos de relacionamentos sobre um relacionamento existente entre
os conjuntos de entidades : FUNCIONRIOS E PROJETOS.
Relacionamento 1:1
A Figura 11 mostra um exemplo de relacionamento do tipo 1:1. Cada
Funcionrio ou Projeto podem aparecer no mximo em um nico par do
relacionamento Gerenciam (Funcionrio, Departamento). Nesse caso,
podemos dizer que um funcionrio pode gerenciar no mximo um projeto,
ou mesmo nenhum, enquanto um projeto s deve ter um gerente.
Figura 11: Exemplo de relacionamento 1:1
Relacionamento 1:N
A Figura 12 mostra um exemplo de relacionamento do tipo 1:N. Cada
Projeto pode aparecer no mximo em um nico par do relacionamento
Gerenciam, enquanto um Funcionrio pode aparecer em um nmero
arbitrrio de vezes. Nesse caso, podemos dizer que um funcionrio pode
gerenciar vrios projetos, enquanto um projeto s pode ter um gerente (tem
que haver pelo menos 1!).
Figura 12: Exemplo de relacionamento 1:N
30
Relacionamento N:N
A Figura 13 mostra um exemplo de relacionamento do tipo N:N. Cada
Funcionrio ou Projeto podem aparecer em um nmero arbitrrio de vezes
do relacionamento Gerenciam. Nesse caso, podemos dizer que um
funcionrio pode gerenciar vrios projetos, enquanto um projeto pode ter
vrios gerentes.
Figura 13: Exemplo de relacionamento N:N
Um outro conceito relacionado aos relacionamentos N:N o de Entidade

Associativa, tambm referenciada por alguns autores, como Agregao.
Uma Entidade Associativa uma abstrao por meio da qual
relacionamentos entre duas entidades so tratados como entidades em um
nvel mais alto de abstrao. Essa nova entidade, a associativa, pode,
ento, relacionar-se com outras entidades do modelo, como mostra a Figura
14. Um correntista uma agregao envolvendo os conjuntos de entidades
Clientes e Contas Correntes.
Figura 14: Exemplo de agregao N:N [Falbo, 2009]
2.3.2.4.3. Atributos de Relacionamentos [FALBO, 2009]

Assim como as entidades, os relacionamentos tambm podem ter atributos,
porm apenas os atributos de relacionamentos N:N so caracterizados como
atributos de relacionamentos, os demais podem ser enquadrados em um dos
conjuntos de entidades envolvidos no relacionamento.
31
Para os relacionamentos N:N h um teste que pode ser aplicado para se

deduzir se um atributo de um dos dois conjuntos de entidades ou se do
relacionamento.
Figura 15: Exemplo de relacionamento N:N [Falbo, 2009]
Fixa-se um material, como uma impressora, e variam-se os fornecedores

desse material. Se o valor do atributo mudar ao variarmos o elemento do
outro conjunto de entidades, porque este no atributo do primeiro
conjunto de entidades, no caso MATERIAIS.
O Procedimento anlogo deve ser feito, agora, para a outra entidade.
Fixando-se um fornecedor e variando-se os materiais temos: A Eletrocity
vende uma impressora por R$ 350,00 e um microcomputador por R$
2.000,00. O fato de o valor do atributo ter variado para a mesma entidade
indica que ele no atributo de FORNECEDORES.
Se no atributo nem de MATERIAIS, nem de FORNECEDORES, ento
um atributo do relacionamento entre os dois conjuntos de entidades.
2.4.2.4.4. Generalizao / Especializao de conjuntos de

entidades
Por muitas vezes, inclumos nos modelos ERs conjuntos de entidades com
diversas caractersticas em comum, diferenciando apenas em algumas delas.
Nesse caso, usando o conceito de generalizao, pode-se criar um conjunto
de entidades genrico, contendo as caractersticas em comum, e
especializam-se as demais com caractersticas parcialmente distintas. Um
exemplo clssico o de pessoa fsica em jurdica. Observe que existem
vrias caractersticas em comum entre ambas as pessoas, a exemplo de :
nome, endereo e telefone. Uma pessoa fsica, no entanto, alm dessas
caractersticas comuns, possui : sexo e CPF. Uma pessoa jurdica, alm
dessas caractersticas comuns, possui CNPJ e atividade principal. A Figura
16 mostra a representao desse conceito no modelo ER.
32
Figura 16: Exemplo de generalizao / especializao
As entidades: PESSOAS FSICAS e JURDICAS herdam as caractersticas

de clientes e incorporam outras adicionais, que so peculiares de cada um.
Um cliente pode ser pessoa fsica, jurdica ou nenhum dos dois, mas toda
pessoa fsica ou jurdica cliente.
Entidade Fraca
Um outro conceito referenciado nos modelos ERs o de Entidade Fraca.
Uma entidade fraca uma entidade que no tem existncia prpria. Ela s
aparece no modelo quando relacionada a outra entidade intitulada como
forte, sendo seus atributos identificadores compostos por pelo menos dois
campos, sendo um deles um atributo da entidade forte. A Figura 17 mostra
um exemplo em que o conjunto de entidades DEPENDENTES
denominada entidade fraca. Para a identificao de um dependente
necessrio que se tenha informao do scio. Os relacionamentos com essa
caracterstica so denominados identificados.
Figura 17: Exemplo de entidade fraca
2.5. DICIONRIO DE DADOS

O Dicionrio de Dados uma listagem organizada de todos os elementos de
dados pertinentes ao sistema, com definies precisas para que os usurios e
desenvolvedores possam conhecer o significado de todos os itens de dados
manipulados pelo sistema.
33
Em se tratando de Modelos de Dados, essa listagem contm, em ordem

alfabtica, as entidades e os relacionamentos com atributos de um DER.
Considerando que no h uma padronizao sobre a definio de dicionrio
de dados, no ser rotulado neste material, uma notao para estes, mesmo
por que, as ferramentas CASE normalmente incluem relatrios para gerao
desses dicionrios.
2.6. FERRAMENTAS CASE

Voc deve estar se perguntando como desenhar um diagrama ER. Ser no
Paint ou mo? A resposta simples. Existem vrias ferramentas
computadorizadas destinadas a auxiliar na construo de modelos e projetos
de bancos de dados. So denominadas ferramentas CASE. Dentre outras,
podemos citar Doctor CASE, ERWin e brModelo. Esta ltima uma
ferramenta desenvolvida sob a orientao do professor Carlos Heuser,
professor de Banco de Dados da UFRGS, e encontra-se disponvel para
download na Internet. Embora seja uma ferramenta simples, permite
trabalharmos com a construo de modelos conceituais e lgicos (tratados no
prximo captulo).
2.7. MODELO ER ESTENDIDO - EER

O modelo ER possui um poder de expresso muito grande, principalmente
quando se trata de modelagem de aplicaes convencionais, porm alguns
recursos so melhores representados por extenses feitas ao modelo bsico.
Recursos estes necessrios para modelagem de aplicaes mais complexas,
como Sistemas de Informaes Geogrficas e CAD.
Vrios modelos semnticos de dados tm sido propostos na literatura, sendo
denominados de modelo ER estendidos ou EER. No h uma notao padro
para representao desses modelos, como ocorre com a UML.
Segundo Navathe (2005), o modelo EER engloba todos os conceitos do
modelo ER bsico, acrescidos dos conceitos de subclasse e superclasse,
especializao
e
generalizao,
tipo
unio
e
herana
de
atributo/relacionamento.
34
Captulo 3 -3. PROJETO LGICO DE BANCO DE

DADOS
3.1. DEFINIO
Quando construmos um modelo conceitual, focamos apenas no que o
usurio deseja, abstraindo da plataforma em que este ser implementado. No
que se refere aos projetos de Banco de Dados, a preocupao centrada em
estabelecer de que forma os dados sero armazenados no sistema. Em funo
do modelo de banco de dados a ser usado, diferentes solues de projeto
devem ser adotadas, ou seja, se o software tiver de ser implementado em um
banco de dados hierrquico, por exemplo, um modelo hierrquico deve ser
produzido, adequando-se a modelagem conceitual de dados (ER ou diagrama
de classes) a essa plataforma de implementao.
Considerando que o modelo de banco de dados que predomina no mercado,
atualmente, o relacional, este captulo se prope a discutir conceitos de
projetos relacionados a esse modelo de bancos de dados.
3.2. ESTRUTURA
RELACIONAIS
DOS
BANCOS
DE
DADOS
O modelo relacional consolidou-se no mercado por ser flexvel, de simples

compreenso. Est fortemente baseado na teoria matemtica sobre relaes,
da o nome relacional.
Um banco de dados relacional consiste em uma coleo de tabelas, cada uma
das quais com um nome nico. Uma linha em uma tabela representa um
relacionamento entre um conjunto de valores. Uma vez que essa tabela
uma coleo de tais relacionamentos, h uma estreita correspondncia entre
o conceito de tabela e o conceito matemtico de relao, da a origem do
nome desse modelo de dados.
Considere a tabela EMPREGADOS Tabela 3. Ela possui trs colunas:
Matricula, Nome e Cidade. Seguindo a terminologia do modelo relacional,
tratamos os nomes dessas colunas como atributos. Para cada atributo h um
conjunto de valores permitidos, chamado domnio da coluna em questo.
Para o atributo Matricula, por exemplo, o domnio o conjunto de todas as
matrculas de funcionrios. Suponha que D1 denote esse conjunto, D2 o
conjunto de todos os nomes de pessoas e D3 o conjunto de todas as cidades.
Qualquer linha da tabela EMPREGADOS consiste necessariamente de uma
tupla (v1, v2, v3), em que v1 a matricula, (isto , v1 est no domnio D1),
v2 um nome do funcionrio e assim por diante. Em geral, um empregado
um conjunto de D1 x D2 x D3.
Matricula
01
Nome
Maria
Cidade
Vitria
35
02
03
04
Matheus
Gabriel
Joana
Vila Velha
Serra
Aracruz
Tabela 3: Tabela EMPREGADOS.
Matematicamente, define-se uma relao como um subconjunto de um

produto cartesiano de uma lista de domnios. Essa definio corresponde
quase exatamente definio de uma tabela. A nica diferena que
designamos nomes aos atributos, ao passo que matematicamente se usam
apenas "nomes" numricos. Como as tabelas em essncia so relaes,
podemos usar os termos matemticos relao e tupla no lugar de tabela e
linhas, respectivamente.
Um valor de domnio que pertence a qualquer domnio possvel o valor
nulo, que indica que um valor desconhecido ou no existe. Por exemplo,
suponhamos que incluamos o atributo numero_telefone na tabela
Empregado, pode ser que um Empregado no possua telefone ou que o seu
nmero seja desconhecido.
3.3. CHAVES
importante especificar como as entidades dentro de um dado conjunto de
entidades podem ser identificadas. Conceitualmente, entidades e
relacionamentos individuais so distintos, entretanto, na perspectiva do
banco de dados, a diferena entre ambos deve ser estabelecida em termos de
seus atributos. O conceito de chaves nos permite fazer tais distines.
Uma superchave um conjunto de um ou mais atributos que, tomados
coletivamente, permitem identificar de maneira unvoca uma entidade em
um conjunto de entidades. Considere a incluso de uma nova coluna na
tabela EMPREGADO, o CPF do empregado. Os atributos (matricula,nome)
e (nome,CPF) so suficientes para distinguir cada elemento do conjunto,
podendo ser considerados como superchaves. Da mesma forma, podemos
considerar o atributo CPF como superchave de empregado. O atributo nome
no pode ser considerado como superchave, porque algumas pessoas podem
ter o mesmo nome. Nosso interesse maior por superchaves para as quais
nenhum subconjunto possa ser uma superchave. Essas chaves so chamadas
de chaves candidatas. Das superchaves mencionadas anteriormente somente
(nome,CPF) no poderia ser considerada uma chave candidata, visto que o
CPF, sozinho, j o .
Podemos usar o termo chave primria para caracterizar a chave candidata,
que escolhida pelo projetista do banco de dados como de significado
principal para a identificao de entidades dentro de um conjunto de
entidades. Quaisquer duas entidades individuais em um conjunto de
entidades no podem ter, simultaneamente, os mesmos valores em seus
atributos-chave.
Em SGBDs, apenas os conceitos de chaves primrias e chaves candidatas
so de fato implementados!
36
Um outro conceito de chave, que muito ser explorado neste material, o

conceito de chave estrangeira. Uma chave estrangeira um atributo ( ou
combinao de atributos) de uma tabela que constitui a chave primria de
uma tabela, da o nome de estrangeira. a estratgia usada para implementar
os relacionamentos dos modelos conceituais. Essa tabela referenciada pode
ser a prpria tabela, para os casos de auto-relacionamento, ou outras
quaisquer do modelo. Outras denominaes tambm so usadas para essas
chaves, a exemplo de chaves externas e chaves transpostas. A Tabela 4
mostra um exemplo de chave estrangeira, o CodDepto. Os valores possveis
para essa coluna devem constar na Tabela referenciada por esse atributo, no
caso, a de Departamentos. Alm desses valores, dependendo do modelo de
dados, nulo pode ser um valor possvel.
Matricula
01
02
03
04
Nome
Maria
Matheus
Gabriel
Joana
Cidade
Vitria
Vila Velha
Serra
Aracruz
CodDepto
01
02
02
03
Tabela 4: Tabela de Empregados, destacando a chave estrangeira (CodDepto).
CodDepto
01
02
03
NomeDepto
Informtica
Geografia
Portugus
Tabela 5: Tabela de Departamentos.
3.4. PROPRIEDADES DO MODELO RELACIONAL

[FALBO,2009]
Nenhum campo componente de uma chave primria pode ser nulo.

Cada clula de uma relao pode ser vazia (exceto de uma chave
primria), ou ao contrrio, conter no mximo um nico valor.
A ordem das linhas irrelevante.
No h duas linhas iguais.
Cada coluna tem um nome e colunas distintas devem ter nomes
distintos.
Usando-se os nomes para se fazer referncia s colunas, a ordem
delas torna-se irrelevante.
Cada relao recebe um nome prprio distinto do nome de qualquer
outra relao da base de dados.
Os valores de uma coluna so retirados todos de um mesmo
conjunto, denominado domnio da coluna.
Duas ou mais colunas distintas podem ser definidas sobre um
mesmo domnio.
Um campo que seja uma chave estrangeira ou um item transposto s
pode assumir valor nulo ou um valor para o qual exista um registro
na tabela em que ela chave primria.
37
3.5. TRADUO
RELACIONAL
DO
MODELO
ER
PARA
O objetivo desta seo apresentar como se procede na elaborao do

projeto lgico de bancos de dados relacionais a partir de modelos conceituais
no caso o ER. O modelo lgico um modelo menos abstrato que o
conceitual e prov um nvel maior de detalhes. Para os diferentes modelos de
bancos de dados (redes, hierrquicos, relacionais...) diferentes solues de
projeto devem ser adotadas. Assim, este material ter como foco apenas o
projeto de banco de dados relacional.
A traduo do modelo ER para o relacional seguir os seguintes passos:
Mapeamento das entidades e atributos;
Mapeamento dos relacionamentos, considerando cada tipo {1:1, 1:N,

N:N};
Mapeamento de generalizaes e especializaes;
Mapeamento de atributos multivalorados.

Diferentes autores usam diferentes representaes para a especificao dos
modelos lgicos de bancos de dados relacionais, sendo alguns representados
de forma grfica e outros textuais. A abordagem usada neste material ser a
de Carlos Heuser (HEUSER,2004), que usa uma notao resumida para
definio do esquema, denominado Esquema Relacional, contendo as
seguintes informaes :
Tabelas que formam o banco de dados;
Colunas que compem cada tabela;
Restries de integridade (no caso, apenas as restries referentes s

chaves primrias e estrangeiras so representadas).
Para o exemplo das Tabelas 4 e 5 (Empregados e Departamentos), teremos a
seguinte representao:
Empregados (Matricula, Nome, Cidade, CodDepto)
CodDepto referencia Departamentos
Departamentos (CodDepto , NomeDepto)
Os atributos sublinhados representam as chaves primrias das tabelas
Empregados e Departamentos, respectivamente. CodDepto uma chave
estrangeira e que referencia a chave primria da tabela Departamentos. Para
os casos das chaves estrangeiras compostas, a representao fica da seguinte
forma: (coluna1, coluna2, ... colunaN) referencia <NomeTabela>.
A fim de facilitar o entendimento, sero usados os mesmos exemplos de
modelos descritos no captulo 2 para exemplificar os diferentes tipos de
relacionamentos. Consideremos tambm os atributos abaixo listados para os
conjuntos de entidades Funcionrios e Projetos, pois a opo foi de no
represent-los no modelo ER.
Funcionrios = Matricula, Nome, Cidade e Data de Admisso
Projetos = Cdigo, Nome e Data de Inicio
Seguindo os passos para elaborao do modelo conceitual temos, como
passo 1, a definio das Tabelas que formam o banco de dados. Via de regra,
todo conjunto de entidades gerar uma tabela no banco de dados relacional.
As excees sero tratadas, quando ocorrerem. Com relao nomenclatura
usada na tabela, ela no deve, necessariamente, ser a mesma do conjunto de
38
entidades, considerando que no pode haver espaos em branco e que

devemos evitar nomes extensos para facilitar o trabalho dos programadores.
No que se refere aos atributos dos conjuntos de entidades, eles devem ser
mapeados em colunas das respectivas tabelas, porm, h algumas diretrizes
para definio dessas colunas, conforme especificaes a seguir:
Evite usar nomes extensos. Ao fazer referncia ao nome de uma
coluna, normalmente escreve-se NomedaTabela.NomedaColuna o
que estende ainda mais o nome do atributo.
Considerando que a referncia s colunas ocorre do modo acima
descrito, evite incluir o nome da tabela nos nomes das colunas
dessas tabelas. A exemplo da coluna Nome, da tabela Projetos.
Algumas pessoas escrevem Nome_Projeto.
Crie padres de projeto para dar nomes s colunas, a exemplo de
Data_Admisso e Data_Inicio. Evite usar prefixos diferentes para
colunas com mesmo tipo de informao, como: Data_Admisso e
Dt_Inicio.
Ao definir a chave primria, escolha a coluna ou combinao destas
colunas com o menor tipo de dados possvel. Sobre os campos
chaves, seja chave primria, candidata, seja estrangeira, so criados
ndices, e esses ndices ocupam muito espao em disco.
Embora devamos evitar redundncias nos modelos conceituais, a
redundncia, muitas vezes, til em um banco de dados, por
questes de performance. Por exemplo, o valor de um pedido pode
ser obtido por meio dos valores dos seus itens, porm, se
guardarmos o valor total do pedido como uma coluna na tabela de
pedidos, evitamos alguns acessos a disco, melhorando, assim, a
performance das aplicaes.
3.1.3.5.1. Relacionamento 1:1

Considerando o relacionamento Gerenciam, da Figura 17, a melhor soluo
de projeto a se considerar : incluir a chave estrangeira na relao
PROJETOS, em vez de coloc-la em empregados, derivando o seguinte
esquema :
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao)
Projetos (Codigo, Nome, Dt_Inicio, Matricula_Gerente)
Matricula_Gerente referencia Funcionarios
Figura 17: Exemplo de relacionamento 1:1
Essa soluo foi adotada, considerando-se que todo projeto tem um gerente,
porm, nem todo funcionrio gerencia um projeto. Ainda assim, se a chave
estrangeira fosse criada em Funcionrios, no teramos problemas na
implementao dessa soluo, embora essa no seja a melhor abordagem.
39
Se o relacionamento Gerenciam fosse total em relao a Funcionrios e a

Projetos, ou seja, se a cardinalidade mnima fosse 1 (um) para ambos,
poderamos optar por criar uma nica tabela contendo todos os atributos.
3.2.3.5.2. Relacionamento 1:N

Para os relacionamentos 1:N deve-se criar a chave estrangeira na tabela que
representa o conjunto de entidades cuja cardinalidade mxima 1. No caso
da Figura 18, a chave estrangeira deve ser colocada em Projetos, pois cada
projeto participa do relacionamento Gerenciam no mximo 1 (uma) vez. O
esquema gerado ficaria da seguinte forma:
Projetos (Codigo, Nome, Dt_Inicio, Matricula_Gerente)
Matricula_Gerente referencia Funcionarios
3.3.3.5.3. Relacionamento 1:N - identificado

Para os relacionamentos 1:N, denominados identificados, como mostra o
exemplo da Figura 19, a identificao de um elemento da entidade, dita
fraca, requer a identificao da entidade, dita forte. Resumindo, temos nesses
casos a chave estrangeira fazendo parte da chave primria da tabela mapeada
pela entidade fraca. O esquema gerado ficaria da seguinte forma:
Scios (Matricula, Nome, Sexo, Dt_Matricula)
Dependentes (Matricula, Num_Dependente, Sexo, Dt_Nascimento)
Matricula referencia Scios
Figura 19: Exemplo de entidade fraca relacionamento identificado
Nesse caso, apenas o nmero do dependente no suficiente para identificlo, considerando que diferentes scios possuem dependentes 01, 02, 03,...
40
3.4.3.5.4. Relacionamento N:N

Os bancos de dados relacionais no implementam ligaes diretas para os
relacionamentos N:N, como para os demais tipos de relacionamentos : 1:1 e
1:N. Nesse caso, o relacionamento tambm deve ser mapeado em uma
tabela do banco de dados. A chave primria dessa nova tabela deve ser
composta, no mnimo, pela chave primria das tabelas relacionadas, ou seja,
tem-se pelo menos 02 chaves estrangeiras, e elas fazem parte da chave
primria da tabela criada. s vezes necessrio incluir mais um atributo
para compor a chave primria da tabela, pois apenas as chaves estrangeiras
no so suficientes para identific-los.
Considere o exemplo da Figura 20, agora com relacionamento N:N.
Considere tambm que o relacionamento Gerenciam possui os seguintes
atributos : Data de Inicio de Atividade e Percentual de dedicao.
O esquema gerado ficaria da seguinte forma:

Projetos (Codigo, Nome, Dt_Inicio)
Gerenciam (Matricula ,Codigo, Dt_Inic_Atividade, Perc_Dedicacao)
Matricula referencia Funcionarios
Codigo referencia Projetos
3.5.3.5.5. Generalizao e Especializao

Considere a Figura 21 para as discusses que se seguem. Considere tambm
que um cliente possui as seguintes caractersticas (atributos ) : Cdigo,
Nome e Endereo. Um cliente pessoa fsica, possui, adicionalmente, um CPF
e Carteira de Identidade e, um cliente pessoa jurdica, possui,
adicionalmente, um CNPJ e uma atividade principal.
41
Figura 21: Exemplo de generalizao / especializao
Para os casos em que h generalizao / especializao, h trs opes de

projeto que podem ser adotadas:
Opo 1: Criar uma tabela nica, fundindo os trs conjuntos de entidades.
Nesse caso, os campos oriundos das tabelas especializadas devem ter a
possibilidade de assumirem valores nulos. O esquema gerado ficaria da
seguinte forma:
Clientes (Codigo, Nome, Endereco, CPF, Carteira_Identidade, CNPJ,
Ativ_Principal)
Opo 2: Criar uma tabela para cada entidade da especializao, como
Pessoas Fsicas e Pessoas Jurdicas. Nesse caso, os atributos do conjunto de
entidades genrico Clientes devem ser includos em cada uma das tabelas
criadas. O esquema gerado ficaria da seguinte forma:
Clientes_PFisica (Codigo, Nome, Endereco, CPF, Carteira_Identidade)
Clientes_PJuridica (Codigo, Nome, Endereco, CNPJ, Ativ_Principal)
Opo 3: Criar uma tabela para cada conjunto de entidade da hierarquia.
Nesse caso, a chave primria das tabelas filhas (pessoas fsicas e jurdicas)
devem ser chaves estrangeiras e as mesmas do conjunto mais genrico, no
caso, de Clientes. O esquema gerado ficaria da seguinte forma:
Clientes (Codigo, Nome, Endereco)
Clientes_PFisica (Codigo, CPF, Carteira_Identidade)
Codigo referencia Clientes
Clientes_PJuridica (Codigo, CNPJ, Ativ_Principal)
Codigo referencia Clientes
3.6.3.5.6. Auto Relacionamento 1:N

Para os auto-relacionamentos 1:N, como existe um relacionamento entre o
mesmo conjunto de entidades, deve-se criar a chave estrangeira na nica
tabela que representa o conjunto de entidades. Nesse caso, deve-se ficar
42
atento em alterar o nome do campo chave estrangeira , pois no possvel

ter colunas diferentes e com o mesmo nome em uma tabela. A Figura 22
representa um modelo ER com esse tipo de relacionamento. O esquema
gerado ficaria da seguinte forma:
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao, Matricula_Chefe)
Matricula_Chefe referencia Funcionarios
3.7.3.5.7. Auto Relacionamento N:N

Para os auto-relacionamentos N:N, assim como para os relacionamentos N:N
tradicionais, cria-se uma nova tabela para mapear o relacionamento. Essa
tabela ter duas chaves estrangeiras, agora, porm, vindas da mesma tabela.
Essas chaves estrangeiras compem a chave primria da tabela criada. O
nome de pelo menos um campo deve ser alterado para evitar que haja dois
atributos com o mesmo nome em uma mesma tabela. A Figura 23 representa
um modelo ER com esse tipo de relacionamento. O esquema gerado ficaria
da seguinte forma:
Disciplinas (Codigo, Nome, Ementa)
Pre_Requisitos (CodigoDisciplinaPos, CodigoDisciplinaPre)
CodigoDisciplinaPre referencia Disciplinas
CdigoDisciplinaPos referencia Disciplinas
43
3.8.3.5.8. Atributos Multivalorados

Os atributos multivalorados de conjunto de entidades tambm devem ser
tratados, considerando-se que o modelo relacional no comporta mltiplos
valores em uma clula de uma tabela. Para ilustrar, consideremos que
telefone (0,n) seja um atributo multivalorado de Funcionrios. Para esses
atributos, uma soluo de projeto adotada a criao de uma tabela para
cada um deles. Para a tabela criada, deve ser aplicada a mesma soluo dos
relacionamentos 1:N identificados. Para o exemplo em tese, o esquema
gerado ficaria da seguinte forma:
Telefones (Matricula, Num_Telefone)
Nesse caso, no h limites de telefones para um funcionrio, tanto pode no
haver nenhum, como um ou vrios.
3.6. NORMALIZAO
Uma vez concludo o projeto lgico de banco de dados relacional, com
gerao do esquema correspondente, deve-se avaliar, para cada tabela, se a
projeo foi bem feita. Esse processo de verificao, composto por um
conjunto de regras, denomina-se forma normal. H diversas formas
normais usadas no processo de verificao, porm na nossa disciplina sero
exploradas apenas as trs primeiras formas normais, denominadas 1FN, 2FN
e 3FN. Normalmente as formas normais visam eliminar informaes
redundantes nas tabelas, cujo processo denominado normalizao.
3.1.3.6.1. Primeira Forma Normal (1FN)

Um banco de dados est na Primeira Forma Normal, quando no existem
dados repetidos em nenhuma das linhas da tabela.
44
Segundo DATE (2004), uma relao R existe na primeira forma normal

(1FN) se, e somente se, todos os domnios subjacentes contiverem apenas
valores atmicos.
Para ilustrar esse conceito, tomemos como exemplo a relao Funcionrios,
com a seguinte definio de esquema:
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao, Telefones)
No caso dessa relao, nem todos os domnios contm valores atmicos,
como o caso de telefones. Nesse caso, os valores no atmicos devem estar
contidos em uma outra tabela, relacionada original. Passando pelo processo
de normalizao (1FN), temos o seguinte esquema:
Telefones (Matricula, Num_Telefone)
Com isso, as duas tabelas geradas encontram-se normalizadas na primeira
forma normal.
3.2.3.6.2. Segunda Forma Normal (2FN)

Quando uma tabela possui uma chave composta, suas colunas devem ser
dependentes de toda a chave e no de apenas uma parte dela. Caso ocorra
essa dependncia parcial, dizemos que a tabela viola a segunda forma
normal.
Segundo DATE (2004), uma relao R existe na segunda forma normal
(2FN) se, e somente se, estiver na (1FN) e todos os atributos no chaves
forem dependentes da chave principal.
Exemplo: Considere o esquema de uma relao filmes, de um banco de
dados de uma locadora de vdeo, com o seguinte esquema:
Filmes (CodigodoFilme, CodigodoAtor, Titulo, NomedoAtor)
A coluna Ttulo depende somente do Nmero da Fita, e Nome do Ator,
depende somente do Nmero do Ator. Quase sempre a soluo dividir as
colunas em duas tabelas e criar uma terceira tabela que correlacione as linhas
das duas tabelas. Nesse caso geraramos os seguintes esquemas:
Filmes (CodigodoFilme, Titulo)
Atores (CodigodoAtor, NomedoAtor)
AtoresFilmes (CodigodoFilme, CodigodoAtor)
CodigodoFilme referencia Filmes
CodigodoAtor referencia Atores
45
3.3.3.6.3. Terceira Forma Normal (3FN)

Uma tabela encontra-se na Terceira Forma Normal se todas as suas colunas
dependerem de toda a chave principal e no houver interdependncia entre
as colunas que no so chaves da tabela.
Segundo DATE (2004), uma relao R existe na terceira forma normal
(3FN) se, e somente se, estiver na (2FN) e todos os atributos no chave
forem intransitivamente dependentes da chave principal.
Exemplo: Considere o esquema modificado da relao filmes de um banco
de dados de uma locadora de vdeo com o seguinte esquema:
Filmes (CodigodoFilme, Titulo, Categoria, Preco)
Suponha que a loja determine o preo dos filmes por categoria: filmes de
Terror, Drama e Comdia custam R$2,00; Musicais R$2,50 e Lanamentos
R$3,00. Nesse caso, a coluna Preo dependeria no s da coluna Cdigo do
filme, como tambm da coluna Categoria. Essa tabela no est na Terceira
Forma Normal. A soluo seria criar uma tabela adicional para armazenar os
valores por categoria do filme. Aps normalizao, os seguintes esquemas
so gerados:
Filmes (CodigodoFilme, Titulo,CodigoCategoria)
CodigoCategoria referencia Categorias
Categorias (CodigoCategoria, Preco)
Atividade 01
Muitas vezes, o DBA se depara com situaes em que possui o
esquema do banco de dados, porm no tem o modelo conceitual
equivalente. Baseado nisso, dada a definio do esquema abaixo,
gere o modelo conceitual equivalente (esse processo denomina-se
Engenharia Reversa).
Fabricante (codf, nomef)
Automovel (coda, nomea, preo, codf)
Codf referencia Fabricante
Pessoa (codp, nomep)
Venda (codp, coda, data, valor, cor)
Codp referencia Pessoa
Coda referencia Automovel
Atividade 02
Dado o modelo ER e dicionrio de dados abaixo, gere o esquema
relacional equivalente:
46
Dicionrio de Dados:
EQUIPES = CodEquipe + NomeEquipe
PILOTOS =
Altura +Peso
CodPiloto +NomePiloto + DataNascimento +
PAISES =
CodPais + Sigla + Nome
CORRIDAS = CodCorrida + DataCorrida + DuracaoProva +

NomeCircuito
PARTICIPACOES = PosicaoPilotoProva
47
Atividade 03
a) Dado a relao Perifericos, coloquem a mesma na terceira

forma normal, passo a passo.
Perifericos (Cod_Periferico, CodModelo, NoConfig,
Quantidade, NomeModelo, CodCPU, NomeCPU)
As dependncias funcionais que existem nesta tabela so as
seguintes:
(Cod_Periferico, CodModelo, NoConfig)
Quantidade
CodCPU NomeCPU
CodModelo NomeModelo
CodModelo CodCPU
CodModelo NomeCPU
X Y, significa dizer que : Y depende de X
b) Dado a relao Pedidos, coloquem a mesma na terceira

forma normal, passo a passo.
Pedidos (Numero_Pedido, Data, CodCliente, NomeCliente,
EnderecoCliente,
CodigoProduto*,
NomeProduto*,
ValorProduto*, QuantidadeProduto*, MatriculaEntregador,
NomeEntregador, PlacaVeiculoEntregador)
48
Captulo 4 -4. LINGUAGENS DE CONSULTA
4.1. DEFINIO
Uma linguagem de consulta uma linguagem na qual um usurio requisita
informaes do banco de dados. So classificadas como procedurais e no
procedurais. Numa linguagem procedural um usurio instrui o sistema para
executar uma sequncia de operaes no banco de dados, a fim de computar
o resultado desejado. Numa linguagem no-procedural o usurio descreve a
informao desejada, sem fornecer um procedimento especfico para obter
tal informao.
A lgebra relacional uma linguagem procedural, enquanto o clculo
relacional uma linguagem no procedural. Navathe (2005) afirma que
qualquer expresso escrita em lgebra relacional pode ser representada
tambm no clculo, dando o mesmo poder de expresso para ambas as
linguagens. Como o nosso propsito de usar uma linguagem de consulta
formal o de entendermos o que ocorre nos bastidores da execuo de
uma consulta, focaremos apenas na lgebra relacional.
A Linguagem SQL uma linguagem de consulta comercial, intitulada
padro pelo comit ANSI, desde 1986. uma linguagem declarativa, com
comandos muito mais amigveis do que as linguagens formais, embora seja
fundamentada nessas linguagens formais (na lgebra e no clculo).
Nas sees seguintes exploraremos a lgebra Relacional e a linguagem
SQL.
4.2. LGEBRA RELACIONAL

A lgebra relacional uma linguagem de consulta procedural. Ela consiste
em um conjunto de operaes que tomam uma ou duas relaes (tabelas)
como entrada e produzem uma nova relao como resultado. Inclui um
conjunto de operaes, classificadas como fundamentais e no fundamentais.
As operaes fundamentais da lgebra relacional so: selecionar, projetar,
renomear, (unrias) - produto cartesiano, unio e diferena de conjuntos
(binrias). Alm das operaes fundamentais, existem outras operaes, a
saber, interseo de conjuntos, ligao natural, entre outras, que so
definidas em termos das operaes fundamentais. As operaes no
fundamentais so usadas para simplificar consultas, considerando que uma
operao no fundamental engloba consultas fundamentais. A Figura 23
mostra, de forma grfica, cada uma das operaes da lgebra.
49
As operaes da lgebra relacional atuam sobre uma ou duas relaes, sendo

classificadas como unrias ou binrias. As relaes unrias trabalham sobre
uma relao e as binrias sobre duas relaes. Caso seja necessrio usar mais
de duas tabelas em uma consulta, operaes podem ser usadas de forma
encadeada. Como o resultado de uma consulta da lgebra uma nova
relao, esta pode ser usada como entrada para a prxima operao.
Produto
Selecionar
Projetar
Unio
a
a
b
b
c
c
x
y
a
b
c
x
y
x
y
x
y
Interseco
Diferena
Ligao (natural)
a1
a2
a3
b1
b1
b2
b1 c1
b2 c2
b3 c3
a1 b1
a2 b1
a3 b2
Dividir
c1
c1
c2
a
a
a
b
c
x
y
z
x
y
x
z
Figura 23: Viso geral das operaes da lgebra Relacional

Fonte: Heuser, 2004. Adaptao.
4.1.4.2.1 Operaes Fundamentais

Considere o seguinte esquema de banco de dados para exemplos posteriores,
ao longo deste captulo. Trata-se de um esquema bancrio, composto de
quatro tabelas: Agencias, Clientes, Depsitos e Emprstimos. Ele foi
adaptado de Silberschatz (2006).
Lembre sempre da definio deste esquema para

quando a ele nos referirmos ao longo deste captulo.
Agencias (CodigoAg, NomeAg, CidadeAg)
50
Clientes (CodigoCli, Nome, rua, cidade)

Depositos (CodigoAg, NumeroCont, CodigoCli,
saldo)
CodigoAg referencia Agencias
CodigoCli referencia Clientes
Emprestimos (CodigoAg, CodigoCli, NumeroEmp,
quantia)
CodigoAg referencia Agencias
CodigoCli referencia Clientes
Operao selecionar
A operao selecionar seleciona tuplas (linhas) que satisfazem a um dado

predicado. Usamos a letra minscula grega sigma () para representar a
seleo. O predicado aparece subscrito em . A relao argumento (entrada)
aparece entre parnteses, seguindo o . A Figura 24 representa graficamente
essa operao.
Sintaxe: <predicado>(Relao)
Figura 24: Operao seleo
Usando o nosso esquema exemplo para selecionar as tuplas da relao

emprstimo em que o cdigo da agncia 0662, escreve-se:
CodigoAg=0662(Emprestimos)
Podemos encontrar todas as tuplas em que a quantia emprestada seja maior
que 1200.
quantia >1200(Emprestimos)
As comparaes so permitidas, usando =, ,, , e e os conectivos e
(^) e ou ().
Operao Projetar
A operao projetar uma operao unria que retorna sua relao

argumento, com certas colunas deixadas de fora. A projeo representada
pela letra grega pi (). A Figura 25 representa graficamente essa operao.
Sintaxe: <lista de atributos>(Relao)
51
Figura 25: Operao projeo
Suponha que desejemos uma relao mostrando os clientes e as agncias nas

quais eles tomaram emprstimos, mas no nos importamos com a quantia e o
nmero do emprstimo. Escrevemos:
CodigoAg,CodigoCli(Emprestimos)
Encontre todos os clientes (Nome) que moram em Aracruz.
Devemos fazer uma seleo de todos os clientes que moram em Aracruz e,
em seguida, projetar o nome desses clientes.
Nome(clientes-cidade=Aracruz (Clientes))
Operao Produto Cartesiano
A operao produto cartesiano, representada por (X) capaz de combinar
informaes a partir de diversas relaes. Trata-se de uma operao binria.
Essa operao nos mostra todos os atributos das relaes envolvidas. A
Figura 26 representa graficamente essa operao.
Sintaxe: (Relao1 Relao2)
Figura 26: Operao produto cartesiano
Para selecionarmos todos os nomes dos clientes que possuam emprstimo na

agncia cujo cdigo 0662, escrevemos:
Nome (CodigoAg=0662 ^ Emprestimo. CodigoCli = Clientes. CodigoCli (Emprestimos X
Clientes))
Operao Unio (binria)
A operao unio de conjuntos, representada por (), permite-nos encontrar
tuplas que esto em uma das relaes envolvidas. A Figura 27 representa
graficamente essa operao.
52
Figura 27: Operao unio
Vamos supor que quisssemos conhecer todas as pessoas que possuam

Depsitos, Emprstimos, ou ambos, numa determinada agncia. Com os
recursos que temos at agora, no seria possvel conseguirmos tal
informao. Nessa situao, deveramos fazer a unio de todos que possuam
depsitos com todos que possuam emprstimos nessa agncia. Como
veremos no exemplo a seguir:
Ex. Selecionar todos os clientes que possuam depsitos, emprstimos, ou
ambos, na agncia 051.
Nome (CodigoAg=051 ^depositos. CodigoCli = Clientes. CodigoCli(Depositos X Clientes))
Nome (CodigoAg=051 ^emprestimos. CodigoCli = Clientes. CodigoCli(Emprestimos X Clientes))

Uma vez que as relaes so conjuntos, as linhas duplicadas so eliminadas.
Operao Diferena de conjuntos
A operao diferena de conjuntos, representada por (-), uma operao

binria e nos permite encontrar tuplas que esto em uma relao e no em
outra. A expresso r - s resulta em uma relao que contm todas as tuplas
que esto em r e no em s. A Figura 28 representa graficamente essa
operao.
Sintaxe: (Relao1 - Relao2)
Figura 28: Operao diferena de conjuntos
Ex. Encontrar todos os clientes que possuam um depsito, mas no possuem

um emprstimo na agncia 051.
Nome (CodigoAg=051 ^ depositos.CodigoCli = Clientes.CodigoCli(Depositos X Clientes))
Nome (CodigoAg=051 ^Emprestimos.CodigoCli = Clientes.CodigoCli (Emprestimos X Clientes))
53
Operao Renomear
A operao renomear, representada pela letra grega R (), necessria
sempre que uma relao aparece mais de uma vez em uma consulta. Ela faz
uma cpia da relao original.
Sintaxe: NomeNovo (Relao)
Ex. Encontre todos os clientes que moram na mesma rua e cidade que Joo.
Podemos obter a rua e a cidade de Joo da seguinte forma:
t rua, cidade (Nome=Joo (Clientes)) ou t Nome=Joo (Clientes)
Entretanto, para encontrar outros clientes com essa rua e cidade, devemos
referir-nos relao Clientes pela segunda vez. Perceba que inserir
novamente uma relao clientes na consulta, gerar ambigidade. Por isso,
deve-se renome-la.
Clientes2 (Clientes)
cliente2.cliente-.nome (clientes.cidade = clientes2.cidade ^ clientes.rua = clientes2.rua (t X Clientes2
(Clientes))
54
Atividade 01
Considere o esquema bancrio abordado anteriormente e construa
expresses em lgebra relacional para as questes que se seguem.
1. Selecionar todos os clientes (nomes) que possuam depsitos.
2. Selecionar todos os clientes que possuam depsito na mesma
cidade onde moram.
3. Encontrar todas as agncias que possuam clientes com nome
Maria (depsitos ou emprstimos).
4. Usando as Operaes Fundamentais, encontrar a conta com
maior saldo.
Atividade 02
Considere o esquema seguinte para construir expresses, usando
operaes fundamentais da lgebra relacional para as questes que
se seguem.
Pessoas (CodPessoa, Nome, Cidade, Chefe)
Empresas (CodEmpresa, Nome, Cidade)
Trabalha (CodPessoa, CodEmpresa, Salario)
CodPessoa referencia Pessoas
CodEmpresa referencia Empresas
5. Consulte todas as pessoas que trabalham. A consulta dever
retornar o nome das pessoas e a cidade onde moram.
6. Consulte o nome das empresas que possuem funcionrios que
ganham menos que um salrio mnimo (considere o valor do
salrio de R$400,00).
7. Consulte todas as pessoas (nomes) que trabalham em Vitria.
8. Consulte todas as pessoas (nomes) que trabalham na mesma
cidade onde moram.
9. Consulte todas as pessoas (nomes) que moram na mesma
cidade do chefe.
10. Consulte todas as empresas (nomes) que funcionam em
cidades em que no moram Maria.
11. Consulte todas as pessoas (nomes) que no trabalham em
Vitria e que ganham acima de R$ 2000.
12. Selecione o nome do funcionrio da empresa de cdigo 01
que possui o menor salrio.
4.2.4.2.2. Operaes No-Fundamentais

Utilizando as operaes fundamentais da lgebra relacional podemos
expressar qualquer consulta da lgebra relacional. Entretanto, algumas
consultas so longas ou complexas demais para serem expressas. Nesse caso,
o uso das operaes no fundamentais pode reduzir o tamanho e a
complexidade dessas consultas.
Operao Interseco de conjuntos
55
A operao Interseco de conjuntos, representada por (), uma operao

binria e nos permite encontrar tuplas que esto nas duas relaes envolvidas
na consulta. Pode ser expressa em funo das operaes fundamentais da
seguinte forma: r s = r (r s). A Figura 29 representa graficamente essa
operao.
Figura 29 : Operao Interseco de conjuntos
Suponha que desejemos encontrar todos os clientes com um emprstimo e

uma conta na agncia 051.
Escrevemos da seguinte forma:
Nome (CodigoAg=051 ^ Depositos.CodigoCli = Clientes.CodigoCli (Depositos X Clientes))
Nome (CodigoAg=051 ^ Emprestimos.CodigoCli = Clientes.CodigoCli (Emprestimos X

Clientes))
Operao Ligao natural
A ligao natural, representada pelo smbolo (|X|) uma operao binria
que permite combinar certas selees e um produto cartesiano em uma
operao. A operao ligao natural forma um produto cartesiano de seus
dois argumentos e faz uma seleo, forando uma equidade sobre os
atributos que aparecem em ambos os esquemas relao. A Figura 30
representa graficamente essa operao.
Sintaxe: (Relao1 |X| Relao2)
Figura 30: Operao Ligao Natural
Ex1: Encontre todos os clientes que tm emprstimos e a cidade em que

vivem.
Nome, cidade (Emprestimos |X| Clientes)
Ex2: Encontre todos os cliente que tm emprstimos e que moram em
Vitria.
Nome, cidade (cidade=Vitria (Emprestimos |X| Clientes))
Operao Diviso
56
A operao diviso, representada por (), usada em consultas em que os

atributos da relao final so os atributos da relao1 que no existem na
relao2. As linhas da relao final contm as linhas de R1 que incluem
todos os valores das colunas comuns a R2. Normalmente aplica-se a
consultas que incluem a frase para todos. A Figura 31 representa
graficamente essa operao.
Figura 31: Operao Diviso
Suponha que desejemos encontrar todos os clientes que tm uma conta em

todas as agncias localizadas em Vitria. Podemos obter todas as agncias
de Vitria por meio da expresso:
r1 CodigoAg (cidade=Vitria (Agncias))
Podemos encontrar todos os pares Nome, CodigoAg, nos quais um cliente
possui uma conta em uma agncia, escrevendo:
r2 Nome, CodigoAg (Depositos |X| Clientes)
Agora precisamos encontrar clientes que apaream em r2 com cada nome de
agncia em r1.
Escrevemos essa consulta da seguinte forma:
Nome, CodigoAg (Depositos |X| Clientes) CodigoAg (cidade=Vitria (Agncias))
Operao de Remoo
A operao remoo se faz necessria sempre que houver necessidade de
excluir tuplas de uma relao.
Sintaxe: R = R E , onde E uma consulta da lgebra relacional
Exemplo1: Excluir todos os depsitos do cliente de cdigo 01
Depositos = Depositos - (CodigoCli = 01 (Depositos))
Exemplo2: Excluir todas as contas de joo
E CodigoAg, NumeroCont, CodigoCli, saldo (Nome=joo (Depositos |X| Clientes))
Depositos = Depositos - E
Operao de Insero
A operao insero se faz necessria sempre que houver a necessidade de
incluir tuplas em uma relao.
Sintaxe: R = R E , onde E uma consulta da lgebra relacional
Exemplo1: Depositos = Depositos {(51, 980987, 1, 1200)}
Exemplo2: Gerar um depsito para todas as pessoas que possuem
emprstimos. A conta gerada ter o mesmo nmero do emprstimo e o valor
do depsito ser igual ao da quantia emprestada.
Depositos = Depositos CodigoAg, numeroEmp, CodigoCli, quantia (Emprestimos)
Operao de Atualizao
57
A operao atualizao representada pela letra grega delta () se faz

necessria sempre que houver a necessidade de alterar valores de tuplas em
uma relao.
Sintaxe: A E ( R), em que E uma consulta da lgebra relacional.
Exemplo1: Acrescer o saldo das contas de todas as pessoas em 5 %.
saldo saldo * 1.05 ( Depositos )
Exemplo2: Suponhamos que contas com saldos superiores a R$10.000,00
recebam 6% de juros e as demais 5%.
saldo saldo * 1.06 (saldo > 10000 ( Depositos ))
saldo saldo * 1.05 (saldo <= 10000 ( Depositos ))
58
Atividade 03
Considere o esquema seguinte para construir expresses,
usando operaes da lgebra relacional para as questes que
se seguem.
Automovel (coda, nomea, preco, codf)
1. Relacione os nomes das pessoas que compraram
algum carro.
2. Relacione os automveis (nomes) da Fiat.
3. Quem comprou Ford?
4. Quem comprou carro com gio (valor da venda
maior que o valor do automvel)?
5. Quem no comprou Ford?
6. Quem comprou Ford e no comprou Volks?
7. Qual o carro mais caro (nome)?
8. Atualizar os valores dos automveis da GM em
15%.
9. Exclua todas as vendas anteriores a 01/01/1990.
10. Selecione todas as pessoas que compraram mais de
um carro, de diferentes modelos, do mesmo
fabricante.
4.3. SQL
A linguagem SQL foi uma das grandes razes para a consolidao dos
bancos de dados relacionais no mercado. Desde sua definio como padro,
em 1986, passou por diversas revises, gerando publicaes de novas
verses. A verso original, denominada Sequel, foi desenvolvida no
Laboratrio de Pesquisa da IBM e implementada como parte do projeto
System R no incio dos anos 70. A linguagem evoluiu desde ento, e nome
foi mudado para SQL (Structured Query Language). A primeira verso ficou
conhecida como SQL-86 ou SQL1, a segunda verso foi denominada SQL92 ou SQL2, e a ltima verso publicada, que incluiu recursos para dar
suporte aos bancos de dados objetos-relacionais e orientados a objetos, ficou
conhecida como SQL-99 ou SQL3.
A maioria dos sistemas gerenciadores de bancos de dados comerciais
implementa suporte ao padro SQL. Alm disso, incorporam uma srie de
59
funes adicionais, visando facilitar o trabalho dos desenvolvedores. Essas

facilidades precisam ser usadas com cautela, pois, se apenas o padro for
utilizado, garante-se a portabilidade, caso haja a necessidade de troca de
SGBD. A linguagem SQL possui diversas partes:
Linguagem de Definio de Dados (DDL) - Inclui comandos para

definio de esquemas de relaes, excluso de relaes, criao de
ndices e modificaes do esquema de relaes;
Linguagem de manipulao de dados (DML) - Inclui comandos para
insero, excluso e modificao de tuplas no banco de dados;
Incorporao DML (SQL Embutida) - Uso de SQL em linguagens de
programao de uso geral, como Pascal, C,...;
Definio de Vises - A SQL DDL inclui comandos para definio
de vises;
Autorizao - A SQL DDL inclui comandos para especificao de
direitos de acesso a relaes e vises;
Integridade - A SQL DDL inclui comandos para especificao de
regras de integridade que os dados que sero armazenados no banco
de dados devem satisfazer;
Controle de Transaes - A SQL DDL inclui comandos para
especificao de iniciao e finalizao de transaes.
4.1.4.3.1. Estrutura Bsica

A estrutura bsica de uma expresso SQL consiste em trs clusulas: select,
from e where.
A clusula select corresponde operao projeo da lgebra

relacional. usada para listar os atributos desejados no resultado de
uma consulta.
A clusula from corresponde operao produto cartesiano da
lgebra relacional. Ela lista as relaes a serem examinadas na
avaliao da expresso.
A clusula where corresponde ao predicado de seleo da lgebra
relacional. Consiste em um predicado envolvendo atributos de
relaes que aparecem na clusula from.
Uma tpica consulta SQL tem a seguinte forma:

SELECT A1, A2, ..., An
FROM r1, r2, ..., rn
[WHERE P]
3
1
2
Cada Ai representa um atributo e cada ri uma relao. P um predicado.

Essa consulta equivalente expresso da lgebra relacional:
A1, A2, ..., An (P (r1 x r2 x ...x rn))
A lista de atributos A1, A2, ..., An pode ser substituda por um (*) para
selecionar todos os atributos (colunas) presentes nas tabelas da clusula
from.
60
A SQL forma o produto cartesiano das relaes chamadas na clusula from,

executa uma seleo da lgebra relacional usando o predicado da clusula
where e, ento, projeta o resultado para os atributos da clusula select. Na
prtica, a SQL pode converter essa expresso em uma forma equivalente que
pode ser processada mais eficientemente, mas para efeito didtico iremos
manter essa ordem de execuo.
Uma consulta completa pode ter as clusulas abaixo, sendo que apenas as
clusulas SELECT e FROM so obrigatrias. O nmero que segue cada
linha sugere a ordem de execuo.
SELECT A1, A2, ..., An
FROM r1, r2, ..., rn
[WHERE P]
[GROUP BY A1, A2, ..., An]
[HAVING Condio]
[ORDER BY A1, A2, ..., An]
6
1
2
3
4
5
Vamos considerar uma primeira consulta simples, usando nosso esquema de

exemplo. Encontre os nomes de todos os clientes na relao clientes. A
consulta SQL pode ser escrita da seguinte forma:
SELECT Nome
FROM Clientes
4.2.4.3.2. Linhas (tuplas) duplicadas

Em algumas situaes, uma consulta SQL pode retornar uma relao que
contenha tuplas (linhas) duplicadas. Nessa situao, inserimos a palavrachave distinct depois da clusula select para elimin-las.
Aproveitando o exemplo anterior, a relao resultante poder ter clientes que
possuam o mesmo nome. Nesse caso, podemos eliminar essas duplicaes,
usando a clusula distinct:
SELECT DISTINCT Nome
FROM Clientes
61
4.3.4.3.3. Predicados e ligaes

A SQL no tem uma representao da operao ligao natural. No entanto,
uma vez que a ligao natural definida em termos de um produto
cartesiano, uma seleo e uma projeo, relativamente simples escrever
uma expresso SQL para uma ligao natural.
Ex.: Encontre os nomes e cidades de clientes que possuam emprstimos em
alguma agncia. Na SQL, isso pode ser escrito da seguinte forma:
SELECT distinct Nome, Cidade
FROM Clientes, Emprestimos
WHERE Clientes.CodigoCli=Emprestimos.CodigoCli
A SQL inclui os conectores and, or e not ; caracteres especiais: (, ), ., :, _,

%,<, >, <= , >= , = , <>, +, - ,* e /; operador para comparao: between,
como mostra o exemplo a seguir.
Selecionar todas as contas que possuam saldo entre 10000 e 20000.

SELECT NumeroCont
FROM Depositos
WHERE saldo BETWEEN 10000 AND 20000
Que equivale a consulta
SELECT NumeroCont
FROM Depositos
WHERE saldo >= 10000 AND saldo <= 20000
A SQL inclui tambm um operador para comparaes de cadeias de
caracteres, o like. Ele usado em conjunto com dois caracteres especiais:
Por cento (%). Substitui qualquer subcadeia de caracteres.
Sublinhado (_). Substitui qualquer caractere.
Ex.: Encontre os nomes de todos os clientes cujas ruas incluem a subcadeia
na.
SELECT distinct Nome
FROM Clientes
WHERE rua LIKE %na%
Ou tambm
Ex.: Encontre os nomes de todos os clientes cujas ruas finalizem com a
subcadeia na, seguido de um caractere.
FROM Clientes
WHERE rua LIKE %na
62
Para que o padro possa incluir os caracteres especiais ( isto , % , _ , etc...),

a SQL permite a especificao de um caractere de escape. O caractere de
escape usado imediatamente antes de um caractere especial para indicar
que o caractere especial dever ser tratado como um caractere normal.
Definimos o caractere de escape para uma comparao like, usando a
palavra-chave escape. Para ilustrar, considere os padres seguintes, que
utilizam uma barra invertida como caractere de escape.
Like ab\%cd% escape \ substitui todas as cadeias comeando

com ab%cd;
Like ab\_cd% escape \ substitui todas as cadeias comeando com
ab_cd.
A procura por no-substituies em vez de substituies se d por
meio do operador not like.
4.4.4.3.4. Operaes de conjunto

A SQL inclui a operao de conjunto union que opera em relaes e
corresponde operao da lgebra relacional.
Uma vez que as relaes so conjuntos, na unio deslas, as linhas duplicadas
so eliminadas.
Ex. Se quisermos saber todos os clientes que possuem emprstimo na

agncia de cdigo 051, fazemos:
WHERE Clientes.CodigoCli=Emprestimos.CodigoCli AND CodigoAg =
051
Da mesma forma, se quisermos saber todos os clientes que possuem
depsitos na agncia de cdigo 051, fazemos:
FROM Clientes, Depositos
WHERE
Clientes.CodigoCli=
Depositos.CodigoAg = 051
Depositos.CodigoCli
AND
"Para achar todos os clientes que possuam um depsito, um emprstimo, ou

ambos, na agncia de cdigo 051, fazemos:
FROM Clientes, Depositos
WHERE Clientes.CodigoCli=epositos.CodigoCli AND Depositos.CodigoAg
= 051
UNION
63
WHERE Clientes.CodigoCli=Emprestimos.CodigoCli AND CodigoAg =

051
4.5.4.3.5 Ordenando a exibio de tuplas

A clusula order by organiza o resultado de uma consulta em uma ordem
determinada. Para listar em ordem alfabtica todos os clientes do banco,
fazemos:
FROM Clientes
ORDER BY Nome
Como padro, SQL lista tuplas na ordem ascendente. Para especificar a
ordem de classificao, podemos especificar asc para ordem ascendente e
desc para descendente. Podemos ordenar uma relao por mais de um
elemento. Como se segue:
SELECT *
FROM Emprestimos
ORDER BY quantia DESC, CodigoAg ASC
4.6.4.3.6. Membros de conjuntos

O conectivo in/not in testa os membros de conjunto, em que o conjunto
uma coleo de valores produzidos por uma clusula select. Para ilustrar,
considere a consulta Encontre todos os clientes que possuem uma conta e
no possuem emprstimo na agncia Princesa Isabel. A consulta SQL
pode ser escrita da seguinte forma:
FROM Clientes
WHERE Clientes.CodigoCli IN
(SELECT CodigoCli
FROM Depositos, Agencias
WHERE depositos.CodigoAg = agencias.CodigoAg
AND NomeAg = Princesa Isabel)
AND Clientes.CodigoCli NOT IN
(SELECT CodigoCli
FROM Emprestimos, Agencias
WHERE emprestimos.CodigoAg = agencias.CodigoAg
AND NomeAg = Princesa Isabel)
64
4.7.4.3.7. Variveis tuplas (renomeao)

A renomeao sempre necessria quando temos necessidade de usar a
mesma tabela mais de uma vez na mesma consulta, assim como na operao
renomear da lgebra relacional. Muitas vezes usamos este recurso com o
objetivo de reduzir o tamanho das expresses SQL. A renomeao feita
usando a palavra reservada AS, aps o nome da tabela na clusula FROM,
como mostra o exemplo a seguir.
Ex: encontre o nome e a cidade de todos os clientes que possuem depsito
em qualquer agncia.
SELECT distinct C.Nome, C.cidade
FROM Clientes AS C, Depositos AS D
WHERE C.CodigoCli = D.CodigoCli
Uma vez que as relaes Clientes e Depositos foram renomeadas para C e D,
quaisquer referncias a essas tabelas, na consulta, devem ser feitas a C e D, e
no mais aos nomes originais. Lembre-se da ordem de execuo de uma
consulta SELECT!
4.8.4.3.8. Comparao de conjuntos

Considere a consulta encontre todas as agncias que possuem ativos
maiores que alguma agncia de Vitria. Podemos escrever a seguinte
expresso SQL:
SELECT distinct Agencias.NomeAg
FROM Agencias , Agencias AS ag
WHERE agencias.ativos > ag.ativos AND ag.cidade = Vitria
Uma vez que uma comparao maior que, no podemos escrever a
expresso usando a construo in. Observe tambm que, como houve
necessidade de usar a mesma tabela (Agncias) duas vezes na consulta, ela
teve que ser renomeada.
A mesma consulta acima poderia ser escrita usando o operador any (pelo
menos um).
Comparaes do tipo >any, <any, >=any, <=any, =any so aceitos pela
linguagem. A consulta anterior pode ser escrita da seguinte forma:
SELECT NomeAg
FROM Agencias
WHERE ativos > any
(SELECT ativos
FROM agencias
WHERE agencias.cidade = Vitria)
Vamos modificando a consulta anterior levemente para encontrar todas as
agncias que possuem ativos maiores do que todas as agncias de Vitria. A
65
construo > all corresponde frase maior que todos. A consulta fica
como se segue:
SELECT NomeAg
FROM Agencias
WHERE ativos > all
(SELECT ativos
FROM Agencias
WHERE agencias.cidade = Vitria)
Como o operador Any, o operador all pode ser usado como: >all, <all,
>=all, <=all, =all e <> all.
4.9.4.3.9. Testando relaes vazias

A SQL possui um recurso para testar se uma subconsulta retorna alguma
tupla. A construo exists retorna true se a subconsulta retornar alguma
tupla. Para ilustrar, vamos escrever a consulta Encontre todos os clientes
que possuem depsito e no possuem emprstimo na agncia Princesa
Isabel .
SELECT Nome
FROM Clientes
WHERE EXISTS
(SELECT * FROM Depositos, Agencias
WHERE
depositos.CodigoCli=
clientes.CodigoCli
AND
agencias.CodigoAg = depositos.CodigoAg AND NomeAg =
Princesa Isabel)
WHERE NOT EXISTS
(SELECT * FROM emprestimos, agencias
WHERE emprestimos.CodigoCli= clientes.CodigoCli AND
agencias.CodigoAg = emprestimos.CodigoAg AND NomeAg =
Princesa Isabel)
Atividade 04
Considere o esquema abaixo para construir as expresses
seguintes, usando a linguagem SQL.

Chefe referencia Pessoas

1. Consulte todas as pessoas que moram em Vitria.
2. Consulte todas as pessoas que trabalham na mesma cidade
66
onde moram.
3. Consulte todas as pessoas que moram na mesma cidade
do chefe.
4. Consulte todas as empresas que funcionam em cidades em
que no moram pessoas cujo primeiro nome seja Maria
(usar operaes de conjunto).
5. Consulte todas as pessoas que no trabalham em Vitria e
que ganham acima de R$2000,00 em ordem decrescente.
6. Consulte todas as pessoas que no trabalham na empresa
cujos nomes comecem com inf_. O resultado dever ser
apresentado em ordem alfabtica.
67
Atividade 05

Automovel (coda, nomea, preo, codf)
1. Liste as pessoas que compraram algum carro.
2. Liste as pessoas que compraram automveis Ford
(fabricante).
3. Liste as pessoas que no compraram Ford.
4. Liste as pessoas que compraram carro com gio. O
resultado dever ser apresentado em ordem alfabtica.
5. Liste as pessoas que compraram Ford e no compraram
Volks.
4.10.4.3.10. Funes agregadas

A SQL oferece a habilidade para computar funes em grupos de tuplas,
usando a clusula group by. O(s) atributo(s) dado(s) na clusula group by so
usados para formar grupos. Tuplas com o mesmo valor em todos os atributos
na clusula group by so colocados em um grupo.
Funes agregadas:
Mdia: AVG
Mnimo: MIN
Mximo: MAX
Soma: SUM
Contar: COUNT
Para ilustrar, considere as consultas Encontre o saldo mdio das contas em
cada agncia
SELECT NomeAg, AVG(Depsitos.saldo) AS Saldo_Medio
WHERE Depositos.CodigoAg = Agencias.CodigoAg
GROUP BY NomeAg
Encontre a quantidade de depositantes de cada agncia
SELECT NomeAg, COUNT(distinct Nome) AS Qtd_Clientes
68

WHERE Depositos.CodigoAg = Agencias.CodigoAg
GROUP BY NomeAg
Note que nesta ltima consulta importante a existncia da clusula
distinct, pois um cliente pode ter mais de uma conta em uma agncia e
dever ser contado uma nica vez.
Encontre o maior saldo de cada agncia
SELECT NomeAg, MAX(Depositos.saldo) AS Maior_Saldo
WHERE Depositos.CodigoAg= agencias.CodigoAg
GROUP BY NomeAg
s vezes til definir uma condio que se aplique a grupos em vez de
tuplas. Por exemplo, poderamos estar interessados apenas em agncias em
que a mdia dos saldos seja maior que R$1200,00. Essa condio ser
aplicada a cada grupo e no a tuplas simples e definida pela clusula
having. Podemos escrever essa expresso SQL assim:
SELECT NomeAg, AVG(Depositos.saldo) AS Saldo_Medio
FROM Depositos
GROUP BY NomeAg
HAVING AVG(saldo)>1200
s vezes, desejamos tratar a relao inteira como um grupo simples. Nesses
casos, no usamos a clusula group by. Para encontrar a mdia de saldos de
todas as contas, escrevemos:
SELECT AVG (Depositos.saldo)
FROM Depsitos
Atividade 06
Considere o esquema bancrio para construir as expresses
1) Selecione todos os clientes que possuem contas em
agncia(s) que possui(em) o maior ativo.
2) Selecione o total de agncias por cidade, classificado por
cidade.
3) Selecione, por agncias, o(s) cliente(s) com o maior saldo.
4) Selecione o valor mdio de emprstimos efetuados por
cada agncia, em ordem crescente das cidades onde essas
agncias se situam.
5) Selecione a(s) agncia(s) que possui(em) a maior mdia
69
de quantia emprestada.
6) Selecione todas as agncias situadas fora de Vitria que
possuem a mdia de depsitos maior do que alguma
agncia localizada em Vitria.
7) Selecione o menor saldo de clientes, por agncias.
8) Selecione o saldo de cada cliente, caso ele possua mais de
uma conta no banco.
4.11.4.3.11. Removendo linhas de uma tabela

O comando Delete usado para remover tuplas em uma dada relao.
Lembre-se que s podemos remover tuplas inteiras, no podemos remover
valores apenas em atributos particulares.
Sintaxe:
DELETE
FROM r
[WHERE P]
Onde r representa uma relao e P um predicado.
Note que o comando delete opera em apenas uma relao. O predicado da
clusula where pode ser to complexo quanto o predicado where do
comando select.
Ex1.: Removendo todas as tuplas de emprstimo.
DELETE FROM emprestimos
Ex2.: Remover todos os depsitos de joo
DELETE FROM Depositos
WHERE depositos.CodigoCli in
(SELECT CodigoCli
FROM Clientes
WHERE Nome=joo)
Ex3.: Remover todos os emprstimos com nmeros entre 1300 e 1500.
DELETE FROM Emprestimos
WHERE numero between 1300 AND 1500
Ex4.: Remover todos os depsitos de agncias localizadas em Vitria.
DELETE FROM Depositos
WHERE depositos.CodigoAg in
(SELECT CodigoAg
FROM Agencias
WHERE cidade=Vitoria)
70
4.12.4.3.12. Inserindo linhas em uma tabela

Para inserir um dado em uma relao, ou especificamos uma tupla para ser
inserida ou escrevemos uma consulta cujo resultado seja um conjunto de
tuplas a serem inseridas. Obviamente, os valores dos atributos para tuplas
inseridas precisam ser membros do mesmo domnio do atributo.
Sintaxe:
INSERT INTO r (A1, A2, ..., An)
VALUES (V1, V2, ..., Vn)
Onde r representa uma relao A atributos e V valores a serem inseridos.
Suponha que desejamos inserir um novo depsito de Joo (cdigo = 1), cujo
valor seja R$1200,00, na conta 9000 da agncia de cdigo=2. Para isso,
fazemos o seguinte comando:
INSERT INTO depositos (CodigoAg, NumeroCont, CodigoCli, saldo)
VALUES (2,9000,1,1200)
Podemos querer tambm inserir tuplas baseadas no resultado de uma

consulta. Suponha que desejemos inserir todos os clientes que possuam
emprstimos na agncia Princesa Isabel na relao depsitos, com um
saldo de R$200,00.
INSERT INTO Depositos (CodigoAg, NumeroCont, CodigoCli, saldo)
SELECT emprestimos.CodigoAg, NumeroEmp, CodigoCli, 200
FROM Emprestimos, Agencias
WHERE emprestimos.CodigoAg=agencias.CodigoAg AND
NomeAg=Princesa Isabel
4.13.4.3.13. Atualizando valores

Em certas situaes, podemos desejar mudar valores em tuplas. Nesse caso,
o comando update deve ser aplicado.
Sintaxe:
UPDATE r SET a1 = v1, a2 = v2, ..., an = vn
[WHERE p]
Em que r representa uma relao, a atributos, p predicado e v os novos
valores para os respectivos atributos.
Suponha que esteja sendo feito o pagamento de juros e que sejam
acrescentados 5% em todos os saldos. Escrevemos
UPDATE Depositos
SET saldo = saldo * 1.05
71
Suponha que todas as contas com saldo superior a R$10000,00 recebam

aumento de 6% e as demais de 5%.
UPDATE Depositos
WHERE saldo >10000
UPDATE Depositos
WHERE saldo<=10000
A clusula where pode conter uma srie de comandos select aninhados.
Considere, por exemplo, que todas as contas de pessoas que possuem
emprstimos no banco tero acrscimo de 1%.
UPDATE Depositos
WHERE CodigoCli IN (SELECT CodigoCli FROM emprestimos)
4.14.4.3.14. Valores Nulos

possvel para tuplas inseridas em uma dada relao atribuir valores a
apenas alguns atributos do esquema. Os atributos restantes so designados
como nulos. Considere a expresso cujo objetivo o de incluir uma nova
agncia:
INSERT into Agencias (CodigoAg, NomeAg, CidadeAg, ativos)
VALUES (2,Centro,Vitria,null)
Nesse caso, est sendo atribudo o valor nulo para o atributo ativos. A
mesma consulta poderia ser reescrita omitindo esse atributo. Nesse caso,
automaticamente ele assumiria o valor nulo.
INSERT into Agencias (CodigoAg, NomeAg, CidadeAg)
VALUES (2,Centro,Vitria)
A palavra chave null pode ser usada em um predicado para testar se um valor
nulo. Assim, para achar todos os clientes que aparecem na relao
emprstimos com valores nulos para quantia, escrevemos:
WHERE Clientes.CodigoCli = Emprestimos.CodigoCli
AND Quantia IS NULL
O predicado is not null testa a ausncia de um valor nulo.
72
Atividade 07

Chefe referencia Pessoas

Observao: Estas atividades foram elaboradas para exercitar os
comandos de atualizao. Desconsidere a integridade referencial
dos dados.
1. Exclua todas as pessoas que possuem salario =
R$1000,00.
2. Exclua todas as pessoas que trabalham em empresas
situadas em Vitria.
3. Inclua na empresa de cdigo 01, com um salrio=
R$100,00, todos os moradores de Vitria
4. Uma determinada empresa de cdigo x vai contratar
todos os funcionrios da empresa de cdigo y que
ganham acima de R$1000,00, dando um aumento de
salrio de 10%. Faa comando(s) SQL para que tal
transao seja efetuada. Obs: As pessoas sero
remanejadas.
5. Uma determinada empresa de cdigo xyz quer contratar
todos que moram em Vitria e esto desempregados.
Sero contratados com salrio = R$200,00. Faa
comando(s) SQL para efetuar tal transao.
6. Faa um comando SQL para ajustar o salrio de todos os
funcionrios da empresa Campana em 5%.
7. Todas as pessoas que moram em Colatina e trabalham na
empresa Campana devero se mudar para Vitria,
devido aos requisitos do diretor da empresa. Faa
comando(s) SQL para efetivar a atualizao da cidade.
4.15.4.3.15. Definio de dados

O conjunto de relaes de um Banco de Dados precisa ser especificado ao
sistema por meio de uma linguagem de definio de dados (DDL).
A SQL DDL permite a especificao no apenas de um conjunto de relaes,
mas tambm de informaes sobre cada relao, incluindo:
O esquema para cada relao;

O domnio de valores associados a cada atributo;
O conjunto de ndices a ser mantido para cada relao;
Restries de integridade;
A estrutura fsica de armazenamento de cada relao no disco.
73
4.16.4.3.16. Tipos de Domnios da Linguagem SQL

A linguagem SQL inclui diversos tipos de domnios, conforme lista abaixo
[SILBERSCHATZ, 2006]:
Char(n): cadeia de caracteres de tamanho fixo, igual a n, definido pelo
usurio;
Varchar(n): cadeia de caracteres de tamanho varivel, no mximo igual a n,
definido pelo usurio;
Int: inteiro (subconjunto finito dos inteiros que depende do equipamento).
Smallint: inteiro pequeno (um subconjunto do domnio dos inteiros que
depende do equipamento);
Numeric(p,d): nmero de ponto fixo cuja preciso definida pelo usurio.
O nmero consiste de p dgitos , sendo que d dos p dgitos esto direita do
ponto decimal;
Real: nmeros de ponto flutuante cuja preciso depende do equipamento em
questo;
Float(n): nmero de ponto flutuante com a preciso definida pelo usurio
em pelo menos n dgitos;
Date: calendrio contendo um ano (com quatro dgitos), ms e dia do ms;
Time: representa horrio, em horas, minutos e segundos.
Uma relao SQL definida usando a instruo CREATE TABLE.

CREATE TABLE r (A1 D1, ..., An Dn)
Em que r uma relao, cada Ai o nome de um atributo no esquema de
relao r e Di o tipo de dados de valores no domnio de atributo Ai. O
comando create table inclui opes para especificar certas restries de
integridade, conforme veremos adiante.
A relao criada acima est inicialmente vazia. O comando insert poder ser
usado para carregar os dados para uma relao.
Para remover uma relao de banco de dados SQL, usamos o comando drop
table, que remove todas as informaes sobre a relao retirada do banco de
dados.
DROP TABLE r
Ex. : para excluir a relao Depsitos, podemos escrever a seguinte
expresso SQL.
74
DROP TABLE Depositos
O comando alter table usado para alterar a estrutura de uma relao

existente. Ao alterar a estrutura de uma tabela, possvel incluir novos
campos, excluir campos existentes ou incluir restries, a exemplo de chaves
primrias e estrangeiras.
Sintaxe:
alter table r <add,drop> A [dominio, integridade]
Em que r a relao a ser alterada; add, adiciona um atributo a r e drop,
remove um atributo de r.
Ex.: Incluindo uma coluna de CPF na tabela clientes. No ser possvel
incluir um cliente sem CPF, uma vez que foi definido como NOT NULL.
ALTER TABLE Clientes ADD cpf NUMERIC(11,0) NOT NULL
4.17.4.3.17. Integridade
Quando se fala em manter a integridade de dados, considera-se no s a
Integridade Fsica dos arquivos portadores do banco de dados, como tambm
manuteno da qualidade dos dados armazenados em termos de preciso e
consistncia.
As restries de integridade fornecem meios para assegurar que mudanas
feitas no banco de dados por usurios autorizados no resultem na perda da
consistncia dos dados. So vrios os tipos de integridade. Eles costumam
ser classificados da seguinte forma:
Integridade de Domnio
Domnio uma lista de valores que precisa estar associada a todo atributo.
Constitui a forma mais elementar de restrio de integridade. facilmente
testado pelo sistema cada vez que um novo item de dado inserido no banco
de dados.
Integridade de Vazio
Especifica se um campo de uma coluna pode ou no assumir valor nulo. No

pode permitir que os campos com entrada obrigatria assumam valores
nulos.
Integridade de Chaves
Especifica a unicidade dos valores para a chave primria e candidatas.
Integridade Referencial
Frequentemente desejamos assegurar que um valor que aparece em uma

relao para um dado conjunto de atributos, aparea tambm para um certo
75
conjunto de atributos em outra relao, o que se denomina Integridade

Referencial.
A existncia de uma chave estrangeira impede que anomalias ocorram em
funo de alteraes executadas no banco de dados, conforme elencadas
abaixo:
Ao incluir uma linha na tabela que contm a chave estrangeira, o

valor inserido tem que fazer parte da tabela em que ela chave
primria. O nico valor diferente desse que permitido o valor
nulo, quando for possvel;
Ao excluir uma linha da tabela que contm chave primria
referenciada por outras tabelas, pode-se implementar os seguintes
cenrios: excluir em cascata as linhas nas tabelas relacionadas em
que se encontram as chaves estrangeiras referentes a essa chave
primria ou impedir que a excluso seja feita;
Ao alterar o valor da chave primria referenciada por outras tabelas,
pode-se implementar os seguintes cenrios: alterar em cascata os
valores das chaves estrangeiras nas tabelas relacionadas ou impedir
que a alterao seja feita;
Ao se alterar o valor da chave estrangeira, deve-se ter garantia de
que o novo valor esteja constante na tabela em que ela chave
primria. Se no for, haver bloqueio na alterao.
4.18.4.3.18. Implementando Integridade Referencial em

SQL
A SQL original padro no incluiu instrues para especificar chaves
estrangeiras. Um subsequente recurso de aperfeioamento de integridade
foi aprovado como uma adio ao padro. Esse recurso permite a
especificao de chaves primrias, candidatas e estrangeiras como parte da
instruo create table.
A clusula primary key da instruo create table inclui uma lista de

atributos que compreende a chave primria.
A clusula unique da instruo create table inclui uma lista de
atributos que compreende a chave candidata.
A clusula foreign key da instruo create table inclui uma lista de
atributos que compreende a chave estrangeira e o nome da relao
referida pela chave estrangeira.
Criando as relaes clientes, agncias e depsitos para o esquema do banco.

CREATE TABLE Clientes
(CodigoCli int not null,
nome char(30) not null,
rua char(30),
cidade char(30),
cpf numeric(11,0),
PRIMARY KEY (CodigoCli)
UNIQUE (CPF))
76
CREATE TABLE Agencias

(codigoAg int not null,
NomeAg char(30),
CidadeAg char(30),
PRIMARY KEY (CodigoAg))
CREATE TABLE Depositos
(codigoAg int not null,
NumeroCont char(10) not null,
CodigoCli int not null,
saldo real,
PRIMARY KEY (codigoAg,NumeroCont),
FOREIGN KEY (CodigoCli) REFERENCES Clientes,
FOREIGN KEY (codigoAg) REFERENCES Agencias,
CHECK (Saldo >=0) )
A clusula Check garante integridade aos valores dos atributos e pode fazer
referncia, inclusive, a valores de atributos em outras tabelas.
77
Atividade 08
Dados os esquemas abaixo, faa comandos SQL DDL padro para
criar as estruturas das tabelas, usando o tipo de dados que melhor
se aplique a cada atributo e impondo integridade referencial.
a)
Alunos
(CodigoAl, NomeAl, CodigoCurso, Telefone,
CoeficienteRendimento)
CodigoCurso referencia Cursos
Cursos
(CodigoC, NomeC)
Disciplinas
(CodigoDisc, CodigoCurso, NomeDisc)
CodigoCurso referencia Cursos
Historico
(CodigoAl, CodigoDisc, Periodo, Nota)
CodigoAl referencia Alunos
CodigoDisc referencia Disciplinas
Pre_Requisitos (CodigoDiscPos, CodigoDiscPre)
CodigoDiscPos referencia Disciplinas
CodigoDiscPre referencia Disciplinas
b)
Clientes (CodCliente, NomeCliente, Telefone, DtNascimento)
Filmes
(CodFilme, NomeFilme, Lancamento, DtAquisicao,
CodClasse)
CodClasse referencia Classes
Fitas (CodFilme, NumeroFita, Dublada)
CodFilme referencia Filmes
Locacoes
(CodFilme, NumeroFita, CodCliente, DtLocacao,
DtDevolucao, VlrLocacao, Multa)
(CodFilme, NumeroFita) referencia Fitas
CodCliente referencia Clientes
Reservas (Codfilme, CodCliente, DtReserva, Situacao)
CodFilme referencia Filmes
CodCliente referencia Clientes
Classes (CodClasse, Nome, Valor)
Obs.: Considere a entrada obrigatria de todos os campos, exceto
os campos: telefones, data de devoluo de fitas e valor de multa.
No permita valores diferentes de S ou N nos campos
Lanamento, na tabela Filmes, e Dublada, na tabela Fitas.
78
Captulo 5 -REFERNCIAS
NAVATHE, E. Sistemas de Bancos de dados. 4. ed. So Paulo:

Pearson Addison Wesley, 2005.
DATE, C. J. Bancos de dados: introduo aos sistemas de bancos de
dados. 8. ed. Rio de Janeiro: Campus, 2004.
SILBERSCHATZ, Abraham. Sistema de banco de dados. 5. ed. So
Paulo: Campus, 2006.
CHEN, Peter. Modelagem de Dados - A abordagem EntidadeRelacionamento para Projeto Lgico. So Paulo: Makron Books,
1990.
HEUSER, Carlos Alberto. Projeto de Banco de Dados. Porto Alegre:
Sagra Luzzato, 2004.
FALBO, R. A. Projeto de Sistemas Notas de Aula. Disponvel em
http://www.inf.ufes.br/%7Efalbo/disciplinas/projeto.html. Acesso em
23 de maro de 2009.
Captulo 6 -
79
BIBLIOGRAFIA
Sem
comentrio padres ABNT

Banco de Dados Apostila - Odt

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Banco de Dados Apostila - Odt

Uploaded by

Copyright:

Available Formats

Sumrio

1. CONCEITOS DE BANCOS DE DADOS.................................................................................................................... 9

4.2.1 Operaes Fundamentais................................................................................................................................49

Captulo 1 -1. CONCEITOS DE BANCOS DE DADOS

Disponibilizar dados integrados para uma grande variedade de

1.3. SISTEMAS DE ARQUIVOS CONVENCIONAIS

Podemos citar como desvantagens desse sistema (arquivos), em relao aos

locadora de vdeo. Um dependente est relacionado a um scio e, por

1.4. USURIOS DE BANCO DE DADOS

1.5. ABSTRAO DE DADOS

a viso dos dados como realmente so e no como os usurios so

A figura 1 representa graficamente os nveis listados acima.

Figura 1: Nveis de abstrao de dados

1.6. INDEPENDNCIA DE DADOS

1.7. ARQUITETURA DE SISTEMAS DE BANCO DE

1.1.1.7.1. Sistemas Centralizados

1.2.1.7.2. Sistemas Cliente-Servidor

1.3.1.7.3. Sistemas Paralelos

servidores atuais), enquanto um paralelismo intensivo ou de granulao fina

1.4.1.7.4. Sistemas distribudos

1.8. MODELOS DE BANCOS DE DADOS

1.1.1.8.1. Modelo em Rede

Figura 2: Exemplo de Banco de Dados Modelo Redes.

O modelo de banco de dados da Figura 2 mostra as ligaes entre os

1.2.1.8.2. Modelo Hierrquico

Figura 3: Exemplo de Banco de Dados Modelo Hierrquico.

1.3.1.8.3. Modelo Relacional

Tabela 1: Tabela de Empregados.

1.4.1.8.4. Modelo Objeto-Relacional

1.5.1.8.5. Modelo Orientados a Objetos

1.9. ESTRUTURA GERAL DO SISTEMA

1.1.1.9.1. Componentes de processamentos de consultas

Gerenciamento de autorizaes e integridade: testa o cumprimento das

1.3.1.9.3. Outras estruturas de dados

Figura 4: Estrutura Geral do Sistema

1.10. LINGUAGEM DE DEFINIO DE DADOS (DDL)

1.11. LINGUAGEM DE MANIPULAO DE DADOS

Recuperao da informao armazenada no banco de dados

1.12. PROJETANDO BANCOS DE DADOS

Liste os nomes dos funcionrios para os seguintes cargos:

( ) Se alterar o esquema fsico,

( ) Contm a especificao dos

Captulo 2 -2. MODELAGEM DE DADOS

Figura 5: Exemplo de representao de conjunto de entidades

Caractersticas dos conjuntos de entidades [FALBO, 2009]:

So substantivos e perduram no tempo.

Um atributo deve ser Completo e Fatorado, ou seja, deve abranger

Ao definir um atributo de um conjunto de entidades, importante tambm

Neste texto adotaremos a seguinte notao: um relacionamento ser

Figura 6: Exemplo de representao de relacionamento

A leitura feita para o relacionamento da Figura 6 funcionrios so

Alunos cursam disciplinas / Disciplinas so cursadas por alunos;

Para facilitar a visualizao foi construdo um diagrama de ocorrncia,

Entre duas entidades, podem existir vrios tipos de relacionamentos. A

Figura 8: Entidades com dois tipos de relacionamento

Alm disso, uma entidade pode participar de relacionamentos com quaisquer

Figura 9: Exemplo de auto-relacionamento

2.1.2.4.1. Cardinalidade de relacionamento

Figura 10: Entidades com dois tipos de relacionamento

2.2.2.4.2. Tipos de Relacionamentos

Figura 11: Exemplo de relacionamento 1:1

Figura 12: Exemplo de relacionamento 1:N

Figura 13: Exemplo de relacionamento N:N