Apostila Sistemas de Banco de Dados

Br asl i a-DF, 2011.
Si st emas de Banc o de Dados

S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
2
Elaborao:
Taylor Montedo Machado
Produo:
Equipe Tcnica de Avaliao, Reviso Lingustica e Editorao
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
3
Sumrio
Apresentao...........................................................................................................................................
Organizao do Caderno de Estudos e Pesquisa ...................................................................................
Organizao da Disciplina ......................................................................................................................
Introduo ...............................................................................................................................................
Unidade I Introduo Modelagem Conceitual ................................................................................
Captulo 1 Bancos de Dados e seus Usurios ..........................................................................
Captulo 2 Conceitos e Arquiteturas de um SGBD ...................................................................
Captulo 3 Modelagem de Dados Utilizando o MER .................................................................
Unidade II Introduo Modelagem Conceitual ...............................................................................
Captulo 4 Modelo de Dados Relacional ..................................................................................
Captulo 5 Projeto de Banco de Dados Relacional Utilizando o MER .........................................
Captulo 6 SQL Structured Query Language .........................................................................
Unidade III Teoria e Metodologia do Projeto de Banco de Dados ....................................................
Captulo 7 Dependncia Funcional e Normalizao ..................................................................
Captulo 8 Metodologia para Projeto Prtico de Banco de Dados .............................................
Unidade IV Armazenagem de Dados, Indexao, Processamento de Consultas e Projeto Fsico ..
Captulo 9 Algoritmos para Processamento e Otimizao de Consultas ...................................
Captulo 10 Tcnicas de Controle de Concorrncia .................................................................
Captulo 11 Tcnicas de Recuperao de Dados .....................................................................
Para (no) Finalizar ................................................................................................................................
Referncias ..............................................................................................................................................
Apndice I Palavras-Chave do SQL ....................................................................................................
Apndice II Expresses de Valor ........................................................................................................
Apndice III Comandos SQL ...............................................................................................................
04
05
06
07
09
09
16
28
41
41
48
52
81
81
92
95
95
99
108
122
123
124
137
143
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
4
Caro aluno,
Bem-vindo ao estudo da disciplina Sistemas de Banco de Dados.
Este o nosso Caderno de Estudos e Pesquisa, material elaborado com o objetivo de contribuir para a realizao e o
desenvolvimento de seus estudos, assim como para a ampliao de seus conhecimentos.
Para que voc se informe sobre o contedo a ser estudado nas prximas semanas, conhea os objetivos da disciplina, a
organizao dos temas e o nmero aproximado de horas de estudo que devem ser dedicadas a cada unidade.
A carga horria desta disciplina de 80 (oitenta) horas, cabendo a voc administrar o tempo conforme a sua disponibilidade.
Mas, lembre-se, h uma data-limite para a concluso do curso, incluindo a apresentao ao seu tutor das atividades
avaliativas indicadas.
Os contedos foram organizados em unidades de estudo, subdivididas em captulos, de forma didtica, objetiva e
coerente. Eles sero abordados por meio de textos bsicos, com questes para reflexo, que faro parte das atividades
avaliativas do curso; sero indicadas, tambm, fontes de consulta para aprofundar os estudos com leituras e pesquisas
complementares.
Desejamos a voc um trabalho proveitoso sobre os temas abordados nesta disciplina. Lembre-se de que, apesar de
distantes, podemos estar muito prximos.
A Coordenao
Apresentao
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
5
Organizao do Caderno de Estudos e Pesquisa
Apresentao: Mensagem da Coordenao.
Organizao da Disciplina: Apresentao dos objetivos e da carga horria das unidades.
Introduo: Contextualizao do estudo a ser desenvolvido por voc na disciplina, indicando a importncia desta para
sua formao acadmica.
cones utilizados no material didtico
Provocao: Pensamentos inseridos no material didtico para provocar a reflexo sobre sua prtica e
seus sentimentos ao desenvolver os estudos em cada disciplina.
Para refletir: Questes inseridas durante o estudo da disciplina para estimul-lo a pensar a respeito
do assunto proposto. Registre sua viso sem se preocupar com o contedo do texto. O importante
verificar seus conhecimentos, suas experincias e seus sentimentos. fundamental que voc reflita
sobre as questes propostas. Elas so o ponto de partida de nosso trabalho.
Textos para leitura complementar: Novos textos, trechos de textos referenciais, conceitos de
dicionrios, exemplos e sugestes, para lhe apresentar novas vises sobre o tema abordado no texto
bsico.
Sintetizando e enriquecendo nossas informaes: Espao para voc fazer uma sntese dos textos
e enriquec-los com sua contribuio pessoal.
Sugesto de leituras, filmes, sites e pesquisas: Aprofundamento das discusses.
Praticando: Atividades sugeridas, no decorrer das leituras, com o objetivo pedaggico de fortalecer o
processo de aprendizagem.
Para (no) finalizar: Texto, ao final do Caderno, com a inteno de instig-lo a prosseguir com a
reflexo.
Referncias: Bibliografia consultada na elaborao da disciplina.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
6
Organizao da Disciplina
Ementa:
Sistemas de banco de dados. Sistemas de gerenciamento de banco de dados. Modelagem de dados. Modelos conceituais. O
modelo relacional. Normalizao. A linguagem SQL. Projeto de banco de dados. Implementao de SGBDs. Armazenamento
de dados. Estruturas de ndices. Processamento e otimizao de consultas. Processamento de transaes. Controle de
concorrncia. Recuperao.
Objetivos:
Contribuir para a capacitao do participante quanto anlise, planejamento, estruturao e implementao
de sistemas de gerenciamento de banco de dados.
Apresentar aos participantes os principais conceitos sobre modelagem, projeto, implementao de
sistemas de gerenciamento de banco de dados.
Estimular a conscientizao das potencialidades e restries inerentes aos sistemas de gerenciamento de
banco de dados.
Unidade I Introduo Modelagem Conceitual
Carga horria: 20 horas
Contedo Captulo
Banco de Dados e seus Usurios 1
Conceitos e Arquiteturas de um SGBD 2
Modelagem de Dados Usando o MER 3
Unidade II Introduo Modelagem Conceitual
Contedo Captulo
O Modelo de Dados Relacional 4
Projeto de Banco de Dados Relacional Utilizando o MER 5
SQL Structured Query Language 6
Unidade III Teoria e Metodologia do Projeto de Banco de Dados
Contedo Captulo
Dependncia Funcional e Normalizao 7
Metodologia para Projeto Prtico de Banco de Dados 8
Unidade IV Armazenamento de Dados, Indexao, Processamento de Consultas e Projeto Fsico
Contedo Captulo
Algoritmos para processamento e Otimizao de Consultas 9
Tcnicas de Controle de Concorrncia 10
Tcnicas de Recuperao de Dados 11
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
7
Introduo
Ao olharmos para os processos modernos que nos prestam servios ou mesmo nos que somos os prprios prestadores de
servios, possvel inferir que existem gigantescas bases de dados que do suporte ou at mesmo gerenciam nossas vidas.
Questes como a nossa conta bancria. As instituies bancrias mantm bancos de dados que permitem o gerenciamento
de todas as transaes financeiras realizados. So esses registros que permitem que seja possvel acompanhar saldos,
aplicaes, saques e manter todo histrico de cada conta de cada cliente.
Processos como a apurao das eleies ou mesmo o processamento da declarao do imposto de renda tambm so
suportados por bancos de dados mantidos pelo governo e que permitem que seja possvel, como no caso deste ltimo,
acompanhar o histrico de cada cidado.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
8
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
9
Captulo 1 Bancos de Dados e seus Usurios
Hoje em dia o termo banco de dados bastante popular em diversas
reas de atuao. Com o aumento da utilizao de computadores na
manipulao de dados que envolvem diversas aplicaes, os bancos
de dados esto sendo desenvolvidos e aplicados nas diferentes
reas que envolvem o comrcio, a indstria, a pesquisa acadmica,
entre outras.
1. Introduo
Segundo Silberschatz (2006), um banco de dados um conjunto de dados inter-relacionados. Podemos afirmar que
esses bancos possuem informaes que representam o dia a dia de uma empresa, de uma loja, de uma locadora de vdeo,
enfim, de qualquer ambiente que possa ter suas informaes coletadas e representadas de uma forma organizada. Tais
bancos de dados, alm de manter todo esse volume de dados organizado, tambm devem permitir atualizaes, incluses e
excluses de dados, sem nunca perder a consistncia. E, alm disso, necessrio considerar que muitas vezes estaremos
lidando com vrios acessos simultneos e concorrentes em vrias partes diferentes de nosso banco de dados.
Heuser (2001) define dado como sendo um fato do mundo real que est registrado e possui um significado implcito no
contexto de um domnio de aplicao. Um banco de dados possui as seguintes propriedades:
uma coleo lgica coerente de dados com um significado inerente; uma disposio desordenada dos dados
no pode ser referenciada como um banco de dados;
projetado, construdo e populado com dados para um propsito especfico; um banco de dados possui um
conjunto pr-definido de usurios e aplicaes;
representado por algum aspecto do mundo real, o qual chamado de minimundo; qualquer alterao efetuada
no minimundo automaticamente refletida no banco de dados.
Um banco de dados pode ser criado e mantido por um conjunto de aplicaes desenvolvidas especialmente para a
tarefa, denominada Sistema de Gerenciamento de Banco de Dados (SGBD). Um SGBD permite aos usurios criar e
manipular bancos de dados de propsitos gerais. Silberschatz (2006) define SGBD como sendo uma coleo de dados
inter-relacionados e um conjunto de programas para acessar esses dados.
Unidade I
Introduo Modelagem Conceitual
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
10
Introduo Modelagem Conceitual Unidade I
1.1. Metadados
Uma caracterstica importante da abordagem Banco de Dados que o SGBD mantm no somente os dados, mas
tambm a forma como esses so armazenados, uma vez que contm uma descrio completa do banco de dados.
Essas informaes so armazenadas no catlogo do SGBD, o qual contm informaes como a estrutura de cada arquivo,
o tipo e o formato de armazenamento de cada tipo de dado, restries. Segundo Heuser (2001), o conjunto de informaes
armazenadas no catlogo de dados denominado Metadados.
No processamento tradicional de arquivos, o programa que ir manipular os dados deve conter este tipo de informao,
ficando limitado a manipular as informaes que ele conhece. Por outro lado, utilizando a abordagem banco de dados, a
aplicao pode manipular diversas bases de dados diferentes.
1.2. Programas versus Dados
O processamento tradicional de arquivos pressupe que a estrutura de dados est incorporada ao prprio programa de
acesso. Assim sendo, uma alterao na estrutura de arquivos resulta na alterao do cdigo fonte de todos os programas.
Porm, a abordagem de banco de dados permite que as alteraes sejam efetuadas apenas no catlogo de dados, sem
necessitar alteraes nos programas de acesso.
1.3. Abstrao de Dados
Uma das funes de um SGBD fornecer aos usurios uma representao conceitual dos dados sem que, para tanto,
necessite fornecer muitos detalhes de como os dados esto armazenados.
Um Modelo de Dados uma forma de abstrao dos dados que utilizada para fornecer essa representao conceitual,
utilizando conceitos lgicos como objetos, suas propriedades e seus relacionamentos (ALVES, 2004).
Os nveis de abstrao tm como funo, inclusive, ocultar a complexidade e simplificar o processo de interao com os
usurios. Sob esse ponto de vista, podemos classificar a abstrao em trs nveis (SILBERSCHATZ, 2006).
Fsico: o nvel de abstrao mais baixo e descreve como os dados so realmente armazenados no banco de
dados. Nesse nvel, um registro de dado pode ser descrito como um bloco consecutivo de memria.
Lgico: nvel de abstrao intermedirio, que descreve que os dados esto armazenados no banco de dados
e quais so as relaes existentes entre eles. Nesse nvel, um registro de dado descrito por um tipo definido
(como um tipo em linguagem de programao) e as inter-relaes entre dados so definidas.
Visualizao: o nvel de abstrao mais alto, que descreve a parte do banco de dados de maior interesse
para o usurio final. Nesse nvel, podemos dizer que se trata de subconjunto de dados que podem existir
apenas durante a execuo de uma operao.
1.4. Mltiplas Vises de Dados
Uma vez que um banco de dados deve permitir o acesso de um conjunto diverso de usurios a todo o seu contedo,
possvel inferir que cada usurio, ou grupo de usurios, pode ter uma necessidade especfica. Desse modo, necessrio
que cada conjunto de usurio tenha a possibilidade de ter vises diferentes da base de dados.
Assim, uma viso definida como um subconjunto de uma base de dados, formando desse modo, um conjunto virtual
de informaes (SILBERSCHATZ, 2006).
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
11
2. Usurios
Em todo grande banco de dados existe um grande nmero de pessoas envolvidas que varia desde sua concepo e seu
projeto at sua manuteno.
2.1. Administrador de Banco de Dados (DBA)
Um ambiente de banco de dados envolve vrios recursos que vo desde o banco de dados em si at o SGBD e outros
softwares. Cabe ao Administrador de Banco de Dados (DBA) o seu gerenciamento, envolvendo tarefas como a
autorizao de acesso a ele, a sua coordenao e a monitorao de seu uso.
2.2. Projetista de Banco de Dados
Cabe ao Projetista de Banco de Dados a identificao dos dados que devem ser armazenados, bem como a definio
da estrutura adequada para represent-los e armazen-los. funo do projetista tambm avaliar as necessidades de
cada grupo de usurios para definir as vises que sero necessrias, integrando-as, fazendo com que o banco de dados
seja capaz de atender a todas as necessidades dos usurios.
2.3. Usurios Finais
Os usurios finais so as pessoas que utilizam o banco de dados fazendo consultas, atualizaes e gerando documentos.
Podemos agrupar esses usurios em trs categorias:
casuais: acessam o banco de dados casualmente, mas podem necessitar de diferentes informaes a cada
acesso; utilizam sofisticadas linguagens de consulta para especificar suas necessidades;
novatos ou paramtricos: utilizam pores predefinidas do banco de dados, valendo-se de consultas
preestabelecidas que j foram exaustivamente testadas;
usurios avanados: so usurios que esto familiarizados com o SGBD e realizam consultas complexas.
2.4. Analistas de Sistemas e Programadores de Aplicaes
Os Analistas de Sistemas so responsveis pela determinao dos requisitos dos usurios finais e pelo desenvolvimento
das especificaes para atender aos requisitos mapeados. Por sua vez, os Programadores so responsveis pela
implementao das especificaes definidas na forma de programas, testando, depurando, documentando e dando
manuteno.
3. Esquemas de Dados
Segundo Silberschatz (2006), os esquemas de dados dizem respeito ao projeto geral do banco de dados e um aspecto
que raramente modificado.
Um esquema de base de dados especificado durante o projeto da base de dados e a forma de visualizao de um
esquema chamada Diagrama do Esquema.
Os SGBDs possuem vrios esquemas de banco de dados que variam em funo do nvel de abstrao dos dados:
esquema fsico: tem como objetivo descrever o projeto do banco de dados no nvel fsico;
esquema lgico: diz respeito descrio do banco de dados no nvel lgico;
subesquema de visualizao: diz respeito descrio das visualizaes possveis para um banco de dados.
Muitos modelos de dados tm certas convenes para, diagramaticamente, mostrar esquemas especificados neles.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
12
Alguns autores defendem que uma das maiores contribuies dos primeiros SGBDs foi introduzir a separao entre os
dados armazenados e a descrio da estrutura dos dados, o esquema de dados.
4. Vantagens e desvantagens do uso de um SGBD
Como toda e qualquer ferramenta, o uso de banco de dados apresenta um conjunto de vantagens e desvantagens quanto
ao seu uso.
4.1. Desvantagens
4.1.1. Altos Custos
As organizaes tm se tornado cada vez mais complexas e os processos de negcio, por sua vez, refletem a necessidade
da disponibilidade de dados de forma rpida, precisa e flexvel. Como conseqncia, os bancos de dados acabam por se
tornar cada vez mais complexos, volumosos e onerosos.
Apesar dos custos relativos ao armazenamento de dados estarem sendo reduzidos em ritmo acelerado, juntamente com
a popularizao do hardware necessrio, aspectos como a concepo, o gerenciamento e a manuteno de bancos de
dados cada vez mais pesam no oramento de seu projeto. Por vezes, os custos podem se tornar um empecilho para a
adoo de um banco de dados.
4.1.2. Gerenciamento e Manuteno
A par e passo com a evoluo da necessidade de informaes, os bancos de dados tambm necessitam de manuteno
evolutiva e/ou corretiva. Uma vez que um processo na organizao, que suportado por um banco de dados, sofre alguma
mudana, a necessidade de informaes para geri-lo adequadamente tambm muda. Alm disso, a evoluo tecnolgica
dos SGBDs imprime a necessidade de ajustes de verso de software e/ou upgrades para que seja possvel usufruir dos
benefcios que estes sistemas oferecem.
Desse modo, a necessidade de uma estrutura para gerenciar o banco de dados, bem como a necessidade de mant-lo,
gera custos que podem tornar o seu uso proibitivo.
4.2. Vantagens
4.2.1. Controle de Redundncia
No processamento tradicional de tratamento de arquivos, necessrio que cada grupo de usurios mantenha seu prprio
conjunto de arquivos e dados, o que pode fazer com que acabe ocorrendo redundncias que prejudiquem o sistema com
problemas como:
toda vez que for necessrio atualizar um arquivo de um grupo, todos os grupos devem ser atualizados para
manter a integridade dos dados no ambiente como um todo;
a redundncia desnecessria de dados leva ao armazenamento excessivo de informaes, ocupando espao
que poderia estar sendo utilizado com outras informaes.
4.2.2. Compartilhamento de Dados
A utilizao de um SGBD permite que mltiplos usurios acessem o banco de dados ao mesmo tempo, permitindo que
mltiplas aplicaes integradas possam acess-lo.
O SGBD multiusurio necessita manter o controle de acessos simultneos (concorrncia) para assegurar a qualidade
do resultado de atualizaes, bem como fornecer recursos que permitam a construo de mltiplas vises.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
13
4.2.3. Restrio a Acesso no Autorizado
Um SGBD permite que seja criado um subsistema de autorizao e segurana, o qual utilizado pelo DBA para criar
contas de acesso e especificar as restries de cada conta, sendo estendido tanto para acesso aos dados quanto ao
uso de softwares inerentes ao SGBD.
4.2.4. Representao de Relacionamentos Complexos entre Dados
Um banco de dados permite que seja catalogada uma variedade de dados que esto inter-relacionados de vrias formas.
Por sua vez, um SGBD fornece uma srie de recursos para representar uma grande variedade de relacionamentos entre
os dados, bem como recuper-los e atualiz-los de maneira prtica e eficiente.
4.2.5. Padronizao
A abordagem de base de dados permite que o DBA defina e obrigue a padronizao entre os usurios da base de dados
em grandes organizaes. Isso facilita a comunicao e a cooperao entre vrios departamentos, projetos e usurios.
Padres podem ser definidos para formatos de nomes, elementos de dados, telas, relatrios, terminologias.
possvel utilizar esse recurso, com maior facilidade, em um ambiente de base de dados centralizado, em comparao
com um ambiente onde cada usurio ou grupo tem o controle de seus prprios arquivos e programas de aplicao.
4.2.6. Flexibilidade
Mudanas nos requisitos podem acarretar a necessidade de modificaes na estrutura de um banco de dados. Por
exemplo, um novo grupo de usurios pode surgir com necessidade de informaes adicionais, ainda no disponveis na
base de dados. Alguns SGBDs permitem que tais mudanas na estrutura da base de dados sejam realizadas sem afetar
a maioria dos programas de aplicaes existentes.
4.2.7. Reduo do Tempo de Desenvolvimento de Aplicaes
Uma das caractersticas mais significativas da abordagem de base de dados o tempo reduzido para o desenvolvimento
de novas aplicaes, como a recuperao de certos dados da base de dados para a impresso de novos relatrios.
Projetar e implementar uma nova base de dados pode tomar mais tempo do que escrever uma simples aplicao
especializada de arquivos. Porm, uma vez que a base de dados esteja em uso, geralmente bastante reduzidoo tempo
para se criar novas aplicaes, usando-se os recursos de um SGBD. O tempo para se desenvolver uma nova aplicao em
um SGBD estimado em 1/4 a 1/6 do tempo de desenvolvimento, usando-se apenas o sistema de arquivos tradicional,
devido s facilidades de interfaces disponveis em um SGBD.
4.2.8. Disponibilidade de Informaes Atualizadas
A abordagem de banco de dados permite que to logo um usurio modifique uma base de dados, todos os outros usurios
podem usufruir imediatamente dessa modificao. Essa disponibilidade de informaes atualizadas essencial para muitas
aplicaes, tais como sistemas de reservas de passagens areas ou bases de dados bancrias.
4.2.9. Economia de Escala
A abordagem de banco de dados permite a consolidao de dados e de aplicaes, reduzindo-se, desse modo, o desperdcio
em atividades redundantes de processamento em diferentes projetos ou departamentos.
4.3. Quando no Utilizar um SGBD
No raro, o uso de um SGBD pode representar um acrscimo desnecessrio de custos, se comparado abordagem de
processamento tradicional de arquivos. Exemplificando, podemos ter:
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
14
alto investimento inicial na compra de software e hardware adicionais;
generalidade que um SGBD fornece na definio e processamento de dados;
sobrecarga na proviso de controle de segurana, de controle de concorrncia, na recuperao e na integrao
de funes.
necessrio reconhecer que problemas adicionais podem ocorrer como da resultado especificao inadequada do projeto
e/ou da implementao das aplicaes de forma no apropriada. Caso o DBA no administre o banco de dados de forma
adequada, tanto a segurana quanto a integridade dos sistemas podem ser comprometidas. A sobrecarga causada pelo
uso de um SGBD e a m administrao justificam a utilizao da abordagem de processamento tradicional de arquivos
em casos como:
o banco de dados e as aplicaes sejam simples, bem-definidos e no sejam esperadas mudanas no projeto;
sej necessrio processamento em tempo real de certas aplicaes, que so terrivelmente prejudicadas pela
sobrecarga causada pelo uso de um SGBD;
no haja mltiplo acesso ao banco de dados.
5. Um Breve Histrico da Aplicao de Banco de Dados
Entre a dcada de 1950 e o incio dos anos 1960, as fitas magnticas eram utilizadas para o armazenamento de dados
e as tarefas de processamento de dados eram efetuadas quase que de forma mecanizada. Os registros tambm podiam
ser alimentados por decks de carto perfurado e necessitavam que fossem carregados seqencialmente, na mesma
ordem em que estavam gravados nas fitas magnticas.
No final dos anos 1960, a tecnologia de armazenamento em discos rgidos levou a uma mudana radical no cenrio do
processamento de dados, pois permitiam o acesso direto aos dados, independentemente de sua posio no disco.
Entre as dcadas de 1960 e 1970, vrias pesquisas foram desenvolvidas no sentido de desenvolver tecnologias que
permitissem a simplificao dos processos de escritrio que conduziram automao. Tarefas como armazenar e organizar
arquivos, que dependiam nica e exclusivamente de mo-de-obra intensiva, poderiam ser simplificadas com o uso de
solues mecnicas mais eficientes e mais baratas. Desse modo, muitas pesquisas foram desenvolvidas e resultaram na
criao dos modelos hierrquicos, de rede e relacionais.
Nesse cenrio, empresas, como a IBM, tomaram a dianteira e, em 1970, um pesquisador daquela empresa, Ted Codd,
publicou o primeiro artigo sobre bancos de dados relacionais, que tratava de um mtodo que permitia que usurios
no tcnicos pudessem armazenar e recuperar grande quantidade de dados, a partir da utilizao de comandos que
manipulassem dados armazenados em tabelas.
Na dcada de 1980, com base nesse estudom, a IBM montou um grupo de pesquisa conhecido como Sistema R (System R)
que objetivava a criao de um banco de dados relacional que tivesse viabilidade comercial. O primeiro sistema comercial
baseado no conceito desenvolvido pela IBM, foi lanado em 1976 pela Honeywell Information Systems Inc. No entanto,
o primeiro SGBD construdo nos padres SQL s comeou a surgir no mercado a partir do incio da dcada de 1980 com
o Oracle 2, da empresa Oracle, e, posteriormente, com o SQL/DS, da IBM.
No incio da dcada de 1990, um dos produtos do Sistema R foi a criao de uma linguagem denominada SQL
Structured Query Language (Linguagem de Consulta Estruturada). A linguagem SQL tornou-se um padro na indstria
para bancos de dados relacionais e hoje em dia, um padro ISO (International Organization for Standardization
1
), o
que permitiu o desenvolvimento e refinamento de softwares de banco de dados relacionais. Outros aspectos relevantes
que contriburam para o refinamento e popularizao dos bancos de dados relacionais foram: o retorno que os usurios
desses sistemas davam para o aprimoramento da linguagem, o desenvolvimento de sistemas para novas indstrias e
1 A ISO a organizao internacional de padronizao responsvel pelos padres tcnicos internacionais
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
15
aumento do uso de computadores pessoais e sistemas distribudos. O padro SQL passou da IBM para a ANSI (American
National Standards Institute) Instituto Nacional Americano para Padres que, juntamente com a ISO, formaram um
grupo de trabalho para continuar o desenvolvimento. Este desenvolvimento ainda acontece com outras novas verses
dos padres definidos at os dias atuais.
O final da dcada de 1990 foi marcado pela massificao do uso da World Wide Web (WWW), fazendo com que
os sistemas de banco de dados tivessem de trabalhar com taxas de processamento de transao cada vez maiores e
disponibilidade de 24x7, ou seja, disponibilidade 24 horas por dia, 7 dias por semana.
Em meados de 2000, surge a Linguagem Extensvel de Formatao ou Extended Markup Language (XML) como
uma nova tecnologia de banco de dados. O XML uma especificao tcnica desenvolvida pela W3C World Wide
Web Consortium
1
.

1 A W3C a entidade responsvel pela definio da rea grfica da internet. (http://www.w3.org).
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
16
Captulo 2 Conceitos e Arquiteturas de um SGBD
Tenha certeza da completa compreenso das informaes
organizacionais durante o estudo de Modelagem Conceitual, pois
inseguranas durante os estgios posteriores da disciplina podem
ser extremamente caras, prejudicando a aprendizagem.
1. Modelos de Dados, Esquemas e Instncias
1.1. Esquemas e Instncias
Uma distino importante para qualquer modelo de dados a que deve ser feita entre a descrio do banco de dados e o
prprio banco. A descrio de um banco de dados chamada de esquema de um banco de dados e especificada durante
o projeto do banco de dados. Geralmente, poucas mudanas ocorrem no esquema do banco de dados.
Uma instncia
1
do banco de dados diz respeito coleo de dados armazenados em um banco de dados em um determinado
momento (SILBERSCHATZ, 2006). A instncia modifica toda vez que uma alterao no banco de dados feita. O SGBD
responsvel por garantir que toda instncia do banco de dados satisfaa o seu esquema do banco de dados, respeitando
sua estrutura e suas restries.
O esquema de um banco de dados tambm pode ser chamado de intenso de um banco de dados e a instncia, de extenso
de um banco de dados.
A diferenciao entre esquema e instncia de um banco de dados pode ser melhor compreendida fazendo uma analogia
com um programa, conforme ilustrado na Figura 2.1.
Figura 2.1 Analogia entre um Programa e um Banco de Dados
Declarao da
Varivel
Esquema do Banco de
Dados
PROGRAMA BANCO DE DADOS
Valor da
Varivel
Instncia do Banco de
Dados
1.2. Modelos de Dados
Uma das vantagens mais relevantes de um banco de dados a possibilidade de fornecer alguns nveis de abstrao de
dados para o usurio final, omitindo os detalhes de como estes so armazenados.
1 Tambm pode ser chamada de ocorrncia ou estado de um banco de dados
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
17
Segundo Silberschatz, um Modelo de Dados uma coleo de ferramentas conceituais para descrever dados, relaes
de dados, semntica de dados e restries de consistncia. Um modelo de dados permite descrever a estrutura
1
de
um banco de dados de forma lgica e fsica. Alm disso, vrios Modelos de Dados tambm definem um conjunto de
operaes para especificar como recuperar e modificar a base de dados.
Desse modo, podemos dizer que o Modelo de Dados a principal ferramenta que fornece a abstrao a um BD.
Os modelos de dados podem ser basicamente de dois tipos:
alto nvel: ou modelo conceitual de dados, que fornece uma viso mais prxima do modo como os usurios
realmente visualizam os dados;
baixo nvel: ou modelo fsico de dados, que fornece uma viso mais detalhada do modo como os dados esto
realmente armazenados no computador.
1.2.1. Modelo de Dados Hierrquico
O primeiro modelo de dados a ser reconhecido foi o modelo hierrquico, que s pde ser desenvolvido devido consolidao
dos discos de armazenamento endereveis. Esses discos possibilitaram a explorao de sua estrutura de endereamento
fsico para viabilizar a representao hierrquica das informaes.
No modelo hierrquico, os dados so estruturados em hierarquias ou rvores. Os ns das hierarquias contm ocorrncias
de registros, onde cada registro uma coleo de campos (atributos), cada um contendo apenas uma informao.
O registro-pai o registro da hierarquia que precede a outros, sendo esses outros denominados registros-filhos. Uma
ligao uma associao entre dois registros. Possui cardinalidade 1:N o relacionamento entre um registro-pai e vrios
registros-filhos.
Organizando os dados segundo o modelo hierrquico, esses podem ser acessados por meio de uma seqncia hierrquica
com uma navegao do topo para as folhas e da esquerda para a direita. Um registro pode estar associado a vrios
registros diferentes, desde que seja replicado.
O Information Management System da IBM Corp (IMS) foi o sistema comercial mais divulgado no modelo hierrquico.
Uma boa parte das restries e consistncias de dados estava contida dentro dos programas escritos para as aplicaes
Para acessar o banco de dados, era necessrio escrever os programas na ordem.
O esquema de um banco de dados hierrquico descrito por meio de um diagrama de estrutura de rvore. Tal diagrama
consiste em dois componentes bsicos: Caixas, as quais correspondem aos tipos de registros, e Linhas, que correspondem
s ligaes entre os tipos de registros. Como exemplo do modelo hierrquico, considere a Figura 2.2.
Figura 2.2. Diagrama de Estrutura de rvore Cliente-Conta Corrente
Nome Rua Cidade
N
o
Conta Corrente Saldo
Joo R121 Braslia
51935 100,00
Pedro R231 Guar
61893 500,00

Fonte: Adaptado de Silberschatz (2006).
1 Por estrutura podemos compreender o tipo dos dados, os relacionamentos e as restries que podem recair sobre os dados.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
18
O Modelo Hierrquico apresenta algumas restries devido a:
complexidade dos diagramas de estrutura de rvore;
no permitir ciclos no grfico bsico de um diagrama de estrutura de rvore;
existncia de restries cardinalidade dos links (de muitos para muitos (N:M) e de muitos para um (N:1));
ausncia de facilidades de consultas declarativas;
necessidade de navegao por ponteiros para acesso informaes;
alta complexidade das consultas.
Alm disso, a replicao possui duas grandes desvantagens: pode causar inconsistncia de dados, quando houver
atualizao, e o desperdcio de espao inevitvel.
1.2.2. Modelo de Dados de Rede
O surgimento do modelo de rede deu-se como uma extenso ao modelo hierrquico; dessa forma, foi eliminando o conceito
de hierarquia e permitindo que um mesmo registro estivesse envolvido em vrias associaes.
Os registros, no modelo em rede, so organizados em grafos onde aparece um nico tipo de associao (set) que define
uma relao 1:N entre 2 tipos de registros: proprietrio e membro. Nesse sentido, possvel construir um relacionamento
M:N entre A e D, dados dois relacionamentos 1:N entre os registros A e D e entre os registros C e D.
Com linguagem prpria para definio e manipulao de dados, o gerenciador Data Base Task Group (DBTG) da CODASYL
(Committee on Data Systems and Languages) estabeleceu uma norma para esse modelo de banco de dados. Como os
dados tinham uma forma limitada de independncia fsica, a nica garantia era que o sistema deveria recuperar os dados
para as aplicaes como se eles estivessem armazenados na maneira indicada nos esquemas.
Concorrncia e segurana foram definidas, pelos geradores de relatrios da CODASYL, como dois aspectos chaves dos
sistemas gerenciadores de dados. Para cada um desses aspectos foram definidas sintaxes. O mecanismo de segurana
fornecia uma facilidade em que parte do banco de dados (ou rea) pudesse ser bloqueada para prevenir acessos simultneos,
quando necessrio. A sintaxe da segurana permitia que uma senha fosse associada a cada objeto descrito no esquema.
Ao contrrio do modelo hierrquico, o modelo em rede possibilita acesso a qualquer n da rede sem passar pela raiz. O
CAIDMS da Computer Associates o sistema comercial mais divulgado do modelo em rede. O diagrama para representar
os conceitos do modelo em redes consiste em dois componentes bsicos: Caixas, que correspondem aos registros, e
Linhas, que correspondem s associaes. A Figura 2.3 ilustra um exemplo de diagrama do modelo em rede.
Figura 2.3. Diagrama Esquemtico da Estrutura de Dados Cliente-Conta Corrente
Cliente Conta
Nome Rua Cidade N
o
Cliente Conta
Pedro R231 Guar 61893 500,00
Joo R121 Braslia 51935 100,00
R_Link
R_Link
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
19
O Modelo de Rede apresenta algumas restries devido:
forte dependncia da implementao;
necessidade de criao de registros artificiais para implementar relacionamentos muitos para muitos;
alta complexidade das consultas, pois o programador forado a pensar em termos de links e como percorr-
los para obter as informaes necessrias (manipulao de dados navegacional).
1.2.3. Modelo de Dados Relacional
O modelo relacional surgiu devido s necessidades de aumentar a independncia de dados nos sistemas gerenciadores de
banco de dados; de prover um conjunto de funes apoiadas em lgebra relacional para armazenamento e recuperao de
dados, de permitir o processamento ad hoc1. Esse modelo, tendo por base a teoria dos conjuntos e a lgebra relacional,
foi resultado de um estudo terico realizado por CODD[1]2.
Esse modelo foi o que revelou ser o mais flexvel e adequado ao solucionar os vrios problemas que se colocam no
nvel da concepo e implementao da base de dados. Sua estrutura fundamental a relao (tabela). Uma relao
constituda por um ou mais atributos (campos) que traduzem o tipo de dados a armazenar. Tupla (registro) o nome dado
a cada instncia do esquema (linha).
O modelo relacional no tem caminhos pr-definidos para se fazer acesso aos dados como nos modelos que o precederam
e implementa estruturas de dados, organizadas em relaes.
Figura 2.4. Diagrama de Estrutura Relacional Cliente-Conta Corrente
Cd_Cliente Nome Rua Cidade
1 Joo R121 Braslia
2 Pedro R231 Guar
Cd_Cliente N
o
Conta Corrente
1 61893
2 51935
N
o
61893 500,00
51935 100,00
Cd_Cliente Nome Rua Cidade
Cd_Cliente N
o
Conta Corrente
N
o
Algumas restries devem ser impostas para que se trabalhe com essas tabelas e evitar aspectos indesejveis como: repetio
de informao, incapacidade de representar parte da informao e perda de informao. Essas restries so: integridade
referencial, chaves e integridade de junes de relaes. A Figura 2.4 traz exemplos de tabelas sob o modelo relacional.
1.2.4. Modelo de Dados Orientado a Objetos
Em meados de 1980, comearam a se tornar comercialmente viveis os bancos de dados orientados a objeto. Seu
surgimento foi motivado em funo dos limites de armazenamento e representao semntica impostas no modelo
relacional. Os sistemas de informaes geogrficas (SIG), os sistemas CAD e CAM, que so mais facilmente construdos
usando tipos complexos de dados, so alguns dos exemplos que podem ser citados.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
20
Uma caracterstica das linguagens de programao orientadas a objetos a habilidade para criar os tipos de dados
necessrios. Contudo, esses sistemas necessitam guardar representaes das estruturas de dados que utilizam no
armazenamento permanente.
O ODMG (Object Database Management Group) foi quem criou a estrutura padro para os bancos de dados orientados a
objetos. Esse grupo formado por representantes dos principais fabricantes desses bancos disponveis comercialmente.
Os membros do grupo tm o compromisso de incorporar o padro em seus produtos.
Modelo Orientado a Objetos um termo usado para documentar o padro que contm a descrio geral das facilidades
de um conjunto de linguagens de programao orientadas a objetos e a biblioteca de classes que pode formar a base para
o Sistema de Banco de Dados. Algumas das falhas perceptveis do modelo relacional pareceram ter sido solucionadas
quando os bancos de dados orientados a objetos foram introduzidos e acreditava-se que tais bancos de dados ganhariam
grande parcela do mercado.
Acredita-se que nos dias atuais, enquanto os sistemas relacionais continuaro a sustentar os negcios tradicionais, onde
as estruturas de dados baseadas em relaes so suficientes, os Bancos de Dados Orientados a Objetos sero usados
em aplicaes especializadas.
O diagrama de classes UML serve geralmente como o esquema para o modelo de dados orientado a objetos. Observe o
exemplo da Figura 2.5. e compare as diferenas com o modelo anterior.
Figura 2.5. Diagrama UML Cliente-Conta Corrente
Cliente
Nome: String
Rua: String
Cidade: String
Conta
N
o
Conta Corrente: Inteiro
Saldo: Real
1..* 1..*
1.2.5. Modelo de Dados para Sistemas Objeto-Relacionais
Os sistemas relacionais convencionais tm dificuldade de representar e manipular dados complexos, visando ser mais
representativos em semntica e construes de modelagens; com isso, a rea de atuao dos sistemas Objeto-Relacional
tenta suprir essas dificuldades. A soluo proposta a adio de facilidades para manusear tais dados utilizando-se
das facilidades SQL (Structured Query Language) existentes. Para isso, foi necessrio adicionar: extenses dos tipos
bsicos no contexto SQL; representaes para objetos complexos no contexto SQL; herana no contexto SQL e sistema
para produo de regras.
1.3. A Arquitetura Trs Esquemas
O principal objetivo da arquitetura trs esquemas permitir a separao das aplicaes do usurio do banco de dados
fsico. Uma representao grfica da arquitetura trs esquemas apresentada na Figura 2.6. Com base nessa arquitetura,
possvel classificar os esquemas:
nvel interno: ou esquema interno, que descreve a estrutura de armazenamento fsico do banco de dados;
utiliza um modelo de dados e descreve detalhadamente os dados armazenados e os caminhos de acesso ao
banco de dados;
nvel conceitual: ou esquema conceitual, que descreve a estrutura do banco de dados como um todo; uma
descrio global do banco de dados, que no fornece detalhes do modo como os dados esto fisicamente
armazenados;
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
21
nvel externo: ou esquema de viso, que descreve as vises do banco de dados para um grupo de usurios;
cada viso descreve as pores do banco de dados s quais um grupo de usurios ter acesso.
1.4. Independncia de Dados
Segundo Oppel (2004), possvel definir a independncia de dados como a capacidade de se alterar um esquema em
um nvel em um banco de dados sem ter que alterar um nvel superior. possvel classificar a independncia de dados
em dois tipos:
independncia de dados lgica: a capacidade de alterar o esquema conceitual sem ter que alterar o
esquema externo ou as aplicaes do usurio;
independncia de dados fsica: a capacidade de alterar o esquema interno sem ter que alterar o esquema
conceitual, o esquema externo ou as aplicaes do usurio.
Figura 2.6. Arquitetura Trs Esquemas
Viso Externa 1 Viso Externa n
Usurios Finais
Esquema Conceitual
Esquema Interno
NVEL
EXTERNO
NVEL
CONCEITUAL
NVEL
INTERNO
Banco de Dados Armazenado
...
Mapeamento
Conceitual
Externo
Mapeamento
Conceitual
Externo
2. Linguagens de Banco de dados
Cada camada e/ou funo de um banco de dados necessita de um tipo de linguagem especfica, conforme podemos ver.
2.1. Linguagem de Definio de Dados
A Linguagem de Definio de Dados ou Data Definition Language (DDL) a linguagem utilizada pelo DBA e pelos
projetistas de banco de dados para definir seus esquemas. O SGBD, por sua vez, possui um compilador para processar
descries em DDL e construir a descrio do esquema armazenado no catlogo.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
22
2.2. Linguagem de Manipulao de Dados
A Linguagem de Manipulao de Dados ou Data Manipulation Language (DML) a linguagem pela qual os usurios
manipulam os dados em um SGBD. Manipulaes comuns como recuperao, insero, remoo e modificao de dados
so realizadas pela DML.
2.3. Linguagem de Definio de Armazenamento
Em situaes onde a separao entre os nveis conceitual e interno de um SGBD bem clara, utiliza-se a Linguagem
de Definio de Armazenamento ou Storage Definition Language (SDL) para a especificao do esquema interno,
sendo que a especificao do esquema conceitual fica por conta da DDL.
2.4. Linguagem de Definio de Vises
Sistemas de Banco de Dados que utilizam a arquitetura trs esquemas necessitam de uma linguagem para a definio
de vises, a Linguagem de Definio de Vises ou Vision Definition Language (VDL).
3. O Ambiente de Sistemas de Banco de Dados
O Ambiente dos Sistemas de Banco de Dados diz respeito ao conjunto de elementos necessrio para que ocorram as
transaes relativas ao armazenamento, processamento e recuperao de dados, conforme representado pela Figura 2.7.
3.1. Componentes de um Sistema Gerenciador de Banco de Dados
3.1.1. Processamento de Consultas
O componente de processamento de consultas composto pelos seguintes elementos:
Compilador DML: o elemento que traduz os comandos DML em instrues de baixo nvel, entendidos pelo
componente de execuo de consultas. Tambm responsvel pela otimizao de solicitaes do usurio.
Pr-compilador para comandos DML inseridos em programas de aplicao: so os elementos que
convertem comandos DML em chamadas de procedimentos normais da linguagem hospedeira. Tambm
interagem com o compilador DML de modo a gerar o cdigo apropriado.
Interpretador DDL: o elemento que interpreta os comandos DDL e os registra no dicionrio de dados.
Componente de execuo de consultas: o elemento que executa instrues de baixo nvel geradas pelo
compilador DML.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
23
Figura 2.7. Um ambiente de Sistema de Banco de Dados
G
e
r
e
n
c
i
a
d
o
r

d
e

M
e
m
r
i
a
Usurios
Interface
Usurios
Navegadores
Usurios
Avanados
Administradores
de BD
Programadores de
Aplicaes
Interface com
Aplicaes
Programas de
Aplicaes
Esquema de
Banco de Dados
Consultas
(Queries)
Programas de
Aplicaes em
Cdigo Objeto
Pr-compilador de
Comandos DML
Interpretador DDL Compilador DML
Componente
de Execuo de
Consultas
Gerenciador de
Buffer
P
r
o
c
e
s
s
a
d
o
r

d
e

C
o
n
s
u
l
t
a
s
Gerenciador de
Arquivos
Gerenciador de
Transaes
Arquivos de
Dados
ndices
Dicionrio de
Dados
Dados
Estatsticos
Banco de
Dados
S
i
s
t
e
m
a

G
e
r
e
n
c
i
a
d
o
r

d
e

B
a
n
c
o

d
e

D
a
d
o
s
A
m
b
i
e
n
t
e

d
o

S
i
s
t
e
m
a

G
e
r
e
n
c
i
a
d
o
r

d
e

B
a
n
d
o

d
e

D
a
d
o
s
3.1.2. Gerenciador de Memria
O componente Gerenciador de Memria o responsvel por traduzir os diversos comandos DML em comandos de baixo
nvel de sistemas de arquivos, o que lhe confere especial importncia uma vez que um dos principais objetivos de um
SGBD simplificar e otimizar o acesso aos dados. Visto que esse componente responsvel por fazer a interface entre
o armazenamento de dados em um nvel mais baixo e as consultas e programas de aplicaes submetidos ao sistema,
possvel afirmar que o Gerenciador de Memria um dos principais elementos de um SGBD.
O componente de gerenciamento de memria composto pelos seguintes elementos:
Gerenciamento de Autorizaes e Integridade: so os elementos que testam o cumprimento das regras
de integridade e a permisso ao usurio no acesso ao dado.
Gerenciamento de Transaes: so os elementos responsveis pela execuo das transaes.
Administrao de Buffer
1
: o elemento responsvel pela intermediao de dados do disco para a memria
principal e pela deciso de quais dados alocar em memria auxiliar.
Administrao de Arquivos: o elemento que gerencia a alocao de espao no armazenamento em disco
e as estruturas de dados usadas para representar essas informaes armazenadas.
1 Unidade de armazenamento temporria (relativo a computador). Fonte: http://www.merriam-webster.com/dictionary
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
24
3.1.3. Mdulo Banco de Dados
O Mdulo Banco de Dados no se limita apenas a armazenar dados, uma vez que tambm contm definies e descries
sobre a estrutura que forma o Banco de Dados (metadados). Os metadados, por sua vez, contm definies da estrutura
de cada arquivo, o tipo e formato de armazenamento de cada item de dados e as restries dos dados. Todas essas
definies ficam armazenadas no Catlogo de Dados (dicionrio de dados) do Banco de Dados e so utilizadas pelo SGBD.
O Mdulo Banco de Dados composto por:
Arquivo de Dados: o elemento que armazena os dados (o banco de dados propriamente dito).
Dicionrio de Dados: o elemento que armazena os metadados.
ndices: o elemento estrutural que otimiza o acesso aos itens de dados.
Estatstica de Dados: o elemento que armazena informaes estatsticas relativas aos dados contidos
no banco de dados. Essas informaes so usadas pelo processador de consultas para seleo de meios
eficientes para execuo de consultas.
3.3. Arquiteturas de Banco de Dados
Os mainframes eram utilizados pelas primeiras arquiteturas para executar o processamento principal e de todas as funes
do sistema, incluindo os programas aplicativos, programas de interface com o usurio, bem como a funcionalidade dos
SGBDs. Essa a razo pela qual a maioria dos usurios fazia acesso aos sistemas via terminais que no possuam poder
de processamento, mas, somente a capacidade de visualizao. Apenas as informaes a serem visualizadas e os controles
eram enviados do mainframe para os terminais de visualizao e todos os processamentos eram feitos remotamente,
conectados a ele por redes de comunicao.
Muitos usurios trocaram seus terminais por Computadores Pessoais (PC) e estaes de trabalho devido queda dos
preos do hardware. No comeo, os SGBDs usavam esses computadores da mesma maneira que usavam os terminais.
O SGBD era centralizado e toda sua funcionalidade, execuo de programas aplicativos e processamento da interface
do usurio eram executados em apenas uma mquina.
Os SGBDs, gradualmente, comearam a explorar a disponibilidade do poder de processamento no lado do usurio, o que
levou arquitetura cliente-servidor. Essa arquitetura foi desenvolvida para dividir ambientes de computao onde um
grande nmero de PCs, estaes de trabalho, servidores de arquivos, impressoras, servidores de banco de dados e outros
equipamentos so conectados juntos por uma rede.
A idia era definir servidores especializados, tais como servidor de arquivos, que mantm os arquivos de mquinas clientes,
ou servidores de impresso que podem estar conectados a vrias impressoras; assim, quando se desejar imprimir algo,
todas as requisies de impresso so enviadas a esse servidor. As mquinas clientes disponibilizam para o usurio as
interfaces apropriadas para utilizar esses servidores, bem como o poder de processamento para executar aplicaes locais.
A arquitetura cliente-servidor se tornou muito popular por causa da facilidade de implementao dada clara separao
das funcionalidades e dos servidores; pelo servidor ser inteligentemente utilizado porque as tarefas mais simples so
delegadas s mquinas-clientes mais baratas e tambm porque o usurio pode executar uma interface grfica que lhe
familiar, ao invs de usar a interface do servidor.
Aos SGBDs comerciais, foi incorporada a arquitetura cliente-servidor e diferentes tcnicas foram propostas para se
implementar essa arquitetura, sendo que a mais adotada pelos Sistemas Gerenciadores de Banco de Dados Relacionais
(SGBDRs) comerciais a incluso da funcionalidade de um SGBD centralizado no lado do servidor. Permanecem no
servidor de consulta ou servidor de transao as consultas e a funcionalidade transacional. assim que um servidor
SQL fornecido aos clientes.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
25
Os clientes tm que formular suas consultas SQL, prover a interface do usurio e as funes de interface usando uma
linguagem de programao. Podem tambm se referir a um dicionrio de dados, que inclui informaes sobre a distribuio
dos dados em vrios servidores SQL, bem como sobre os mdulos para a decomposio de uma consulta global em um
nmero de consultas locais que podem ser executadas em vrios stios.
O servidor SQL tambm chamado de back-end machine e o cliente de front-end machine. Como SQL prov uma linguagem
padro para o SGBDRs, esta criou o ponto de diviso lgica entre o cliente e o servidor.
Atualmente, existem vrias tendncias para arquitetura de Banco de Dados, nas mais diversas direes.
As principais arquiteturas de SGBDs so:
Plataformas centralizadas: nessa arquitetura existe um computador com grande capacidade de
processamento, sendo esse o hospedeiro do SGBD e emulador para os vrios aplicativos. Sua principal
vantagem a de permitir que muitos usurios manipulem grande volume de dados e sua principal desvantagem
est no seu alto custo, pois exige ambiente especial para mainframes e solues centralizadas.
Sistemas de Computador Pessoal: fazem seus processamentos sozinhos e, com isso, trabalham em sistema
stand-alone. No comeo esse processamento era bastante limitado, porm, com a evoluo do hardware,
tem-se hoje PCs com grande capacidade de processamento. Utilizam o padro Xbase e, em se tratando de
SGBDs, funcionam como hospedeiros e terminais. Desta forma, possuem um nico aplicativo a ser executado
na mquina e sua principal vantagem a simplicidade.
Banco de Dados Cliente-Servidor: nessa arquitetura, o cliente (front_end) executa as tarefas do aplicativo
fornecendo a interface do usurio (tela e processamento de entrada e sada). O servidor (back_end)
executa as consultas no DBMS e retorna os resultados ao cliente. Embora sendo uma arquitetura bastante
popular, so necessrias solues sofisticadas de software que possibilitem: o tratamento de transaes,
as confirmaes de transaes (commits), desfazer transaes (rollbacks), linguagens de consultas (stored
procedures) e gatilhos (triggers). A principal vantagem dessa arquitetura a diviso do processamento entre
dois sistemas, o que reduz o trfego de dados na rede. (Ver Figura 2.8)
Banco de Dados Distribudos (N camadas): como se pode observar na Figura 2.9, a informao, nessa
arquitetura, est distribuda em diversos servidores. Cada servidor atua como no sistema cliente-servidor,
porm as consultas oriundas dos aplicativos so feitas para qualquer servidor indistintamente. Caso a
informao solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se de obter a
informao necessria, de maneira transparente para o aplicativo, que passa a atuar consultando a rede,
independente de conhecer seus servidores. As bases de dados corporativas, em que o volume de informao
muito grande e, por isso, deve ser distribudo em diversos servidores so exemplos tpicos. Porm, no
dependente de aspectos lgicos de carga de acesso aos dados, ou de base de dados fracamente acopladas, em
que uma informao solicitada vai sendo coletada numa propagao da consulta numa cadeia de servidores.
A existncia de diversos programas aplicativos consultando a rede para acessar os dados necessrios a
caracterstica bsica, porm, sem o conhecimento explcito de quais servidores dispem desses dados.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
26
Figura 2.8. Arquitetura Cliente-Servidor
Fonte: Produzido pelo autor.
Figura 2.9. Arquitetura Distribuda N Camadas
Fonte: Adaptado de Silberschatz (2006)
4. Classificao dos SGBDs
O principal critrio utilizado para classificar um SGBD o modelo de dados no qual baseado. A grande maioria dos
SGBDs atuais so baseados no modelo relacional, alguns em modelos conceituais e outros em modelos orientados a
objetos. Outras classificaes possveis.
Quanto aos usurios: um SGBD pode ser monousurio, comumente utilizado em computadores pessoais ou
multi-usurios, utilizado em estaes de trabalho, minicomputadores e mquinas de grande porte.
Quanto localizao: um SGBD pode ser localizado ou distribudo; se ele for localizado, ento todos os
dados estaro em uma s mquina (ou em um nico disco); se distribudo, os dados estaro distribudos por
diversas mquinas (ou diversos discos).
Quanto ao ambiente: ambiente homogneo o ambiente composto por um nico SGBD e um ambiente
heterogneo o ambiente composto por diferentes SGBDs.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
27
5. Exemplos de Sistemas Gerenciadores de Banco de Dados
Existem, atualmente no mercado, vrios aplicativos que exercem a funo de Sistemas Gerenciadores de Banco de Dados.
A seguir, apresentamos alguns exemplos.
dBASE: um aplicativo lanado pela Ashton-Tate e posteriormente adquirido pela Borland. Teve verses
para DOS e Windows, trabalhava com gerenciamento de arquivos planos baseados em listas invertidas e
possua uma linguagem de programao prpria para desenvolvimento de aplicaes. A partir da verso 7, os
direitos foram vendidos pela Borland.
Paradox: teve verses para DOS e hoje possui apenas verses para Windows. Possui ambiente integrado de
desenvolvimento para criao de aplicativos e seus direitos de produo foram vendidos para a Corel.
DataFlex: teve verses para DOS e Windows e popular para ambiente Unix. Hoje comercializado com o
nome de Visual Data Flex e possui ambiente integrado para o desenvolvimento de aplicaes.
FoxBase/FoxPro: um aplicativo concorrente do dBase, com total compatibilidade em termos de arquivos
e programas-fontes. Possui recursos adicionais como a capacidade de pr-compilao dos cdigos-fontes
para melhorar o desempenho. Hoje, se chama Visual FoxPro aps a aquisio pela Microsoft da Fox Software
(produtora original).
Access: um aplicativo que, por possuir ambiente integrado, permite a criao e gerenciamento do banco
de dados, desenvolvimento de aplicaes e gerao de relatrios. Sua linguagem de programao deriva do
Visual Basic. Para microcomputadores do ambiente Windows padro em banco de dados.
Oracle: o primeiro em Banco de Dados Corporativos (cliente/servidor) possuindo grande variedade de
distribuies (para Macintosh, Windows, Linux, FreeBSD, Unix) e para computadores de grande porte.
padro SQL com uma linguagem prpria para desenvolvimento de aplicaes.
Interbase: teve uma verso liberada como Open Source e foi includo, pela Borland, nas suas ferramentas de
desenvolvimento (Delphi, C++Builder, JBuider).
MS-SQL Server: as verses atuais so independentes e operam exclusivamente sobre Windows. Foi
produzido pela Microsoft. Inicialmente era uma verso especial do Sybase.
Sybase SQL Anywhere: as aplicaes para esse banco de dados so desenvolvidas com o PowerBuilder. No
mercado, seu concorrente corporativo o Oracle.
MySQL: alm de gratuito, possui verses para Windows, Solaris, Unix, FreeBSD, Linux. Usado principalmente
para desenvolvimento WEB como servidor de dados para comrcio eletrnico.
PostgreSQL: alm de ser gratuito, tem boa aceitao. Foi concebido para rodar em Linux e possui verses
para Windows. , principalmente, usado para comrcio eletrnico, juntamente com a linguagem PHP.
Informix: aplicativo comercializado pela IBM. Possui boa escalabilidade e desempenho.
BD2: aplicativo produzido pela IBM, nasceu nos ambientes de grande porte, sendo posteriormente portado
para plataformas mais simples (microcomputadores).
Firebird: aplicativo nascido de uma iniciativa da Borland em abrir o cdigo do InterBase 6. Este sistema
open source e esbanja versatilidade e robustez. Possui recursos de trigger, store procedures e transaes
concorrentes.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
28
Captulo 3 Modelagem de Dados Utilizando o MER
Uma entidade dever ter atributos que necessitam ser conhecidos
do ponto de vista dos negcios ou ento no uma entidade no
escopo dos requisitos do negcio.
1. O Modelo Entidade-Relacionamento (MER)
O Modelo Entidade-Relacionamento (MER) foi definido por Peter Chen,
,
em 1976, e teve como base a teoria relacional
criada por E.F.Codd (1970). Segundo Chen, a viso de uma dada realidade baseia-se no relacionamento entre entidades,
que retratam os fatos que governam essa mesma realidade, e que cada um (entidade ou relacionamento) pode possuir
atributos (qualificadores dessa realidade).
um modelo de dados conceitual de alto nvel, cujos conceitos foram projetados para estar o mais prximo possvel da
viso que o usurio tem dos dados, no se preocupando em representar como esses dados estaro realmente armazenados.
Baseia-se na percepo de um mundo real que consiste em uma coleo de objetos bsicos, denominados entidades, e
de relaes entre esses objetos.
O MER utilizado principalmente durante o processo de projeto de banco de dados e , atualmente, a tcnica mais
difundida, chegando a confundir-se com a prpria modelagem de dados.
A Figura 3.1 faz uma descrio simplificada do processo de projeto de um banco de dados.
1.1. Caractersticas do MER
O modelo ER apresenta as seguintes caractersticas.
Expressividade: suporta relacionamentos n-rios; inclui os trs mecanismos de abstrao: classificao,
agregao e generalizao.
Simplicidade: possui uma riqueza de conceitos e com isso se torna uma poderosa ferramenta para a
descrio da realidade. No um modelo muito simples, especialmente no que diz respeito aos conceitos de
cardinalidade, cobertura de generalizao e identificao. Uma soluo produzir diagramas ER em diferentes
nveis de detalhe.
Minimalidade: nenhum conceito do modelo pode ser descrito em termos dos demais, com exceo dos
atributos compostos. O fato de a mesma realidade poder ser modelada de diferentes maneiras no invalida a
minimalidade do modelo.
Formalidade: possui o necessrio grau de formalidade, uma vez que cada um de seus conceitos possui uma
interpretao nica, precisa e bem-definida.
Representao grfica: todos os seus conceitos possuem um smbolo grfico associado, por isso, um
modelo graficamente completo. Os diagramas ER so fceis de serem entendidos pelos usurios.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
29
2. Uma aplicao
A Figura 3.1 descreve uma base de dados COMPANHIA, que ser utilizada para ilustrar o processo de projeto de base
de dados. So listados os requisitos da base de dados e criado o seu esquema conceitual passo a passo ao mesmo tempo
em que so introduzidos os conceitos de modelagem usando o MER.
A base de dados COMPANHIA armazena os dados dos empregados, departamentos e projetos. Supe-se que aps a
Obteno e Anlise dos Requisitos, os projetistas da base de dados produziram a seguinte descrio do minimundo
parte da companhia a ser representada na base de dados.
A companhia organizada em departamentos. Cada departamento tem um nome, um nmero e um empregado
que o gerencia. Armazena-se a data de incio em que o empregado comeou a gerenciar o departamento. Um
departamento pode ter diversas localizaes.
Um departamento controla inmeros projetos, sendo que cada um tem um nome, um nmero e uma localizao.
Do empregado armazena-se o nome, nmero do seguro social, endereo, salrio, sexo e a data de nascimento.
Todo empregado associado a um departamento, mas pode trabalhar em diversos projetos, que no so
necessariamente controlados pelo mesmo departamento. Armazena-se, tambm, o nmero de horas que o
empregado trabalha em cada projeto. Mantm-se, ainda, a indicao do supervisor direto de cada projeto.
Os dependentes de cada empregado so armazenados com o propsito de garantir os benefcios do seguro.
Para cada dependente ser armazenado o nome, sexo, data de nascimento e o relacionamento com o
empregado.
Figura 3.1: Esquematizao da Modelagem de Dados usando o MER
Obteno e Anlise Requisitos
Projeto Conceitual
Projeto Fsico
Mini-Mundo
Requisitos da Base de Dados
Modelo Conceitual (Alto-Nvel)
Esquema Conceitual (SGBD especfico)
Esquema Interno
Banco de Dados
C
o
m
u
m

a

t
o
d
o
s

o
s

t
i
p
o
s

d
e

S
G
B
D
C
o
n
f
o
r
m
e

o

S
G
B
D

Mapeamento do Modelo de Dados
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
30
3. Entidades e Atributos
O objeto bsico tratado pelo modelo ER a entidade, que pode ser definida como um objeto do mundo real, concreto ou
abstrato e que possui existncia independente.
Cada entidade possui um conjunto particular de propriedades que a descreve, denominado atributos. Para cada atributo
existe um conjunto de valores permitidos, que chamado de domnio desse atributo. Um atributo pode ser dividido em
diversas partes menores com significado independente entre si, recebendo o nome de atributo composto. Um atributo
que no pode ser subdividido chamado de atributo simples ou atmico.
O atributo que pode assumir apenas um determinado valor em uma determinada instncia denominado atributo
simplesmente valorado, enquanto que um atributo que pode assumir diversos valores em uma mesma instncia denominado
multivalorado. Um atributo que gerado a partir de outro chamado de atributo derivado.
4. Tipos Entidade, Conjunto de Valores, Atributo Chave
Um banco de dados costuma conter grupos de entidades que so similares, possuindo os mesmos atributos, porm, cada
entidade conta com seus prprios valores para cada atributo. Esse conjunto de entidades similares forma tipo entidade.
Cada tipo entidade identificado por seu nome e pelo conjunto de atributos que definem suas propriedades. A descrio
do tipo entidade chamada de esquema do tipo entidade, onde so especificados o nome do tipo entidade, o nome
de cada um de seus atributos e qualquer restrio que incida sobre as entidades.
5. Relacionamentos
5.1. Tipos de Relacionamento
Um tipo relacionamento R entre n entidades E
1
, E
2
, ..., E
n
um conjunto de associaes possveis entre entidades desse
tipo. Em outras palavras, cada instncia de relacionamento r
1
em R uma associao de entidades. Isso significa que
essas entidades esto relacionadas de alguma forma no minimundo.
A Figura 3.2 mostra um exemplo entre dois tipos entidade (empregado e departamento) e o relacionamento entre eles
(trabalha para). Repare que para cada relacionamento participa apenas uma entidade de cada tipo entidade, porm, uma
entidade pode participar de mais de um relacionamento.
Figura 3.2. Exemplo de um Relacionamento Binrio
R
1
R
2
R
3
R
4
R
5
R
6
Trabalha Para Empregado
E
1
E
2
E
3
E
4
E
5
E
6
Departamento
D
1
D
2
D
3
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
31
5.2. Grau de um Relacionamento
O grau de um tipo relacionamento o nmero de tipos entidade que participam do tipo relacionamento. No exemplo
da Figura 3.2, temos um relacionamento binrio. O grau de um relacionamento ilimitado, porm, a partir do grau 3, a
compreenso e a dificuldade de se desenvolver a relao corretamente se tornam extremamente complexas.
Um exemplo de um tipo de relacionamento ternrio Fornece para, ilustrado na Figura 3.3. Cada instncia de
relacionamento R
1
associa trs entidades um fornecedor F, uma pea E e um projeto P onde o fornecedor F fornece
a pea E para o projeto P. Podem existir tipos de relacionamento de qualquer grau, porm mais freqente encontrar o
tipo de relacionamento de grau dois.
5.3. Relacionamentos como Atributos
Algumas vezes conveniente pensar em um relacionamento como um atributo. Considere o exemplo da Figura 3.2. Podemos
pensar departamento como sendo um atributo da entidade empregado, ou empregado, como um atributo multivalorado
da entidade departamento. Se uma entidade no possuir existncia muito bem definida, talvez seja mais interessante
para a coeso do modelo lgico que ela seja representada como um atributo.
Figura 3.3. Exemplo de um Relacionamento Ternrio
R
1
R
2
R
3
R
4
R
5
R
6
Fornecer para
Peas
E
1
E
2
E
3
E
4
E
5
E
6
Projeto
P
1
P
2
P
3
Fornecedor
F
1
F
2
5.4. Nomes de Papis e Relacionamentos Recursivos
Cada tipo entidade que participa de um tipo relacionamento desempenha um papel particular no relacionamento. O nome do
papel representa o papel que uma entidade de um tipo entidade participante desempenha no relacionamento. No exemplo
da Figura 3.2, ns temos o papel empregado ou trabalhador para o tipo entidade EMPREGADO e o papel departamento
ou empregador para a entidade DEPARTAMENTO.
Nomes de papis no so necessariamente importantes quando todas as entidades participantes desempenham papis
diferentes. Algumas vezes, o papel torna-se essencial para distinguir o significado de cada participao. Isso muito
comum em relacionamentos recursivos.
Um relacionamento recursivo um relacionamento entre entidades do mesmo tipo entidade, conforme ilustrado na Figura
3.4.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
32
Na Figura 3.4, temos um relacionamento entre o tipo entidade EMPREGADO, onde um empregado pode supervisionar
outro empregado e um empregado pode ser supervisionado por outro empregado.
Figura 3.4. Um Relacionamento Recursivo
Supervisiona
R
1
R
2
R
3
R
4
R
5
R
6
Empregado
E
1
E
2
E
3
E
4
E
5
E
6
Supervisiona
Supervisionando
6. Refinando o Projeto de Entidade-Relacionamento
6.1. Tipos Entidades Fracas
Em alguns casos, alguns tipos entidade podem no ter um atributo chave por si s. Isso implica que no poderemos distinguir
algumas entidades porque as combinaes dos valores de seus atributos podem ser idnticas. Esses tipos entidade so
chamados entidades fracas. As entidades desse tipo precisam estar relacionadas com uma entidade pertencente ao
tipo entidade proprietria. Esse relacionamento chamado de relacionamento identificador.
Na Figura 3.5, o tipo entidade DEPENDENTE uma entidade fraca uma vez que no possui um mtodo de identificar
uma entidade nica. O EMPREGADO no uma entidade fraca uma vez que possui um atributo para identificao
(atributo chave).
O nmero do CPF de um empregado pode identificar um nico empregado, porm um dependente de 5 anos de idade no
possui necessariamente um documento como esse. Dessa forma, essa entidade um tipo entidade fraca.
Figura 3.5. Exemplo de um Relacionamento com uma Entidade Fraca
Possui Dependente
R
1
R
2
R
3
Empregado
E
1
E
2
E
3
Dependente
D
1
D
2
D
3
Um tipo entidade fraca possui uma chave parcial que, juntamente com a chave primria da entidade proprietria,
forma uma chave primria composta.
No exemplo da Figura 3.5 a chave primria do EMPREGADO pode ser o CPF. A chave parcial do DEPENDENTE
pode ser o seu nome, pois dois irmos no podem ter o mesmo nome. Desse modo, a chave primria desta entidade
fica sendo o CPF do pai ou da me mais o nome do dependente.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
33
6.2. Atributos em Tipos de Relacionamentos
Os tipos de relacionamento tambm podem ter atributos da mesma maneira que os tipos de entidades. Exemplificando,
tomemos a situao representada pela Figura 3.6 e acrescentemos a necessidade de representar a data em que um
EMPREGADO comeou a gerenciar um DEPARTAMENTO por meio de um atributo Data_Incio para o tipo de
relacionamento GERNCIA.
Figura 3.6. Exemplo de um Relacionamento
Gerncia
R
1
R
2
R
3
Departamento
D
1
D
2
D
3
Empregado
E
1
E
2
E
3
E
4
E
5
E
6
Nesse caso, possvel perceber que atributos de tipos de relacionamento 1:1 ou 1:N podem ser includos como atributos
de um dos tipos de entidades participantes. Assim, o atributo Data_Incio para o tipo de relacionamento GERNCIA
pode ser um atributo tanto de EMPREGADO quanto de DEPARTAMENTO embora, conceitualmente, ele pertena
ao relacionamento GERNCIA. Isso ocorre porque GERNCIA um relacionamento 1:1, uma vez que toda entidade
DEPARTAMENTO ou EMPREGADO participam em apenas uma instncia de relacionamento e, dessa forma, o valor do
atributo Data_Incio pode ser representado em qualquer uma das entidades participantes.
No caso de um tipo de relacionamento 1:N, um atributo de relacionamento pode somente ser colocado no tipo de
entidade que est do lado N do relacionamento. Isso pode ser visto na Figura 3.2, pois se o relacionamento TRABALHA-
PARA tiver um atributo Data_Incio, indicando quando um empregado comeou a trabalhar para um DEPARTAMENTO,
esse atributo pode ser colocado como atributo de EMPREGADO. Isso ocorre porque o relacionamento 1:N de modo
que cada entidade EMPREGADO participa apenas uma nica vez em uma instncia de TRABALHA-PARA.
Uma vez que o valor de um atributo determinado pela combinao das entidades participantes em uma instncia de
relacionamento, e no apenas por uma das entidades, ento o atributo deve ser especificado como um atributo de
relacionamento. Esse o caso de atributos de tipos de relacionamentos M:N, porque as entidades dos tipos de entidades
participantes podem participar em inmeras instncias de relacionamento.
Exemplificando, tomemos a situao descrita na Figura 3.2 e acrescentemos a necessidade de incluir o atributo Horas_
Trabalhadas do relacionamento M:N TRABALHA-PARA. O nmero de horas que um empregado trabalha em um projeto
determinado pela combinao empregado-projeto e no separadamente.
6.3. Modelo Entidade-Relacionamento Estendido (ERE)
Os conceitos do modelo Entidade-Relacionamento, discutidos anteriormente, so suficientes para representar logicamente
a maioria das aplicaes de banco de dados. Porm, com o surgimento de novas aplicaes, surgiu tambm a necessidade
de novas semnticas para a modelagem de informaes mais complexas.
O modelo Entidade-Relacionamento Estendido (ERE) visa fornecer esta semntica para permitir a representao
de informaes complexas. importante frisar que, embora o modelo ERE trate classes e subclasses, ele no possui a
mesma semntica de um modelo orientado a objetos.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
34
O modelo ERE engloba todos os conceitos do modelo E-R mais os conceitos de subclasse, superclasse, generalizao,
especializao e o de herana de atributos.
6.3.1. Subclasses, Superclasses e Especializaes
O primeiro conceito do modelo ERE, que ser abordado, o de subclasse de um tipo entidade.
Como visto anteriormente, um tipo entidade utilizado para representar um conjunto de entidades do mesmo tipo. Em
muitos casos, um tipo entidade possui diversos subgrupos adicionais de entidades que so significativas e precisam ser
representadas explicitamente, devido ao seu significado, aplicao de banco de dados. Considere o seguinte exemplo:
Para um banco de dados de uma empresa temos o tipo entidade empregado, o qual possui as seguintes caractersticas:
nome, RG, CPF, nmero funcional, endereo completo (rua, nmero, complemento, CEP, bairro, cidade), sexo, data de
nascimento e telefone (ddd e nmero); caso o(a) funcionrio(a) seja um(a) engenheiro(a), ento deseja-se armazenar
as seguintes informaes: nmero do CREA e especialidade (Civil, Mecnico, Eletrnico); caso o(a) funcionrio(a) seja
um(a) secretrio(a), ento se deseja armazenar as seguinte informaes: qualificao (bi ou trilngue) e os idiomas em
que possui fluncia verbal e escrita.
Se as informaes nmero do CREA, especialidade, tipo e idiomas forem representados diretamente no tipo entidade
empregado estaremos representando informaes de um conjunto limitado de entidades empregado para os todos os
funcionrios da empresa. Nesse caso, podemos criar duas subclasses do tipo entidade empregado: engenheiro e secretria,
as quais iro conter as informaes acima citadas. Alm disto, engenheiro e secretria podem ter relacionamentos
especficos.
Uma entidade no pode existir meramente como componente de uma subclasse. Antes de ser componente de uma
subclasse, uma entidade deve ser componente de uma superclasse. Isto leva ao conceito de herana de atributos; ou
seja, a subclasse herda todos os atributos da superclasse. Isso porque a entidade de subclasse representa as mesmas
caractersticas de uma mesma entidade da superclasse. Uma subclasse pode herdar atributos de superclasses diferentes.
Uma representao diagramtica do exemplo mencionado ilustrada na Figura 3.7.
Figura 3.7. Representao de Superclasse e Subclasses
Nome
N
o
Funcional
CPF
RG
Dt. Nascimento
Sexo
Endereo
Empregado
Funo
d
Engenheiro Engenheiro
N
o
Registro
Especializao
Qualificao
Idiomas
6.3.2. Especializao
Especializao o processo de definio de um conjunto de classes de um tipo entidade; esse tipo entidade chamado
de superclasse da especializao. O conjunto de subclasses formado com base em alguma caracterstica que distinga
as entidades entre si.
No exemplo da Figura 3.7, temos uma especializao, que podemos chamar de funo. Veja agora no exemplo da Figura
3.8, temos a entidade empregado e duas especializaes.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
35
Figura 3.8. Duas Especializaes para Empregado: Funo e Categoria Salarial
Engenheiro Horista Secretria Mensalista
Empregado
Funo
Categoria
Salarial
d
d
Como visto anteriormente, uma subclasse pode ter relacionamentos especficos com outras entidades ou com a prpria
entidade, que a sua superclasse. Veja o exemplo da Figura 3.9.
Figura 3.9. Relacionamentos entre Subclasses e Entidades
d
Secretria
Empregado
Engenheiro
Projeto
desenvolvido por
N
N
S
N
liderado
Lidera
Participa
Funo
O processo de especializao nos permite:
definir um conjunto de subclasses de um tipo entidade;
associar atributos especficos adicionais para cada subclasse;
estabelecer tipos relacionamentos especficos entre subclasses e outros tipos entidades.
6.3.3. Generalizao
A generalizao pode ser pensada como um processo de abstrao reverso ao da especializao, no qual so suprimidas
as diferenas entre diversos tipos entidades, identificando suas caractersticas comuns e generalizando essas entidades
em uma superclasse.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
36
Figura 3.10. Tipos Entidades Engenheiro e Secretria
Figura 3.11. Generalizao Empregado para os Tipos Entidades Engenheiro e Secretria
importante destacar que existe diferena semntica entre a especializao e a generalizao. Na especializao, podemos
notar que a ligao entre a superclasse e as subclasses feita por meio de um trao simples, indicando participao
parcial por parte da superclasse. Analisando o exemplo da Figura 3.9, observado que um empregado no obrigado a
ser um engenheiro ou uma secretria. Na generalizao, podemos notar que a ligao entre a superclasse e as subclasses
feita por intermdio de um trao duplo, indicando participao total por parte da superclasse. Analisando o exemplo
da Figura 3.10, observado que um empregado obrigado a ser um engenheiro ou uma secretria.
A letra d dentro do crculo que especifica uma especializao ou uma generalizao significa disjuno. Uma disjuno
em uma especializao ou generalizao indica que uma entidade do tipo entidade que representa a superclasse pode
assumir apenas um papel dentro dela. Analisando o exemplo da Figura 3.11 temos duas especializaes para a superclasse
Empregado, as quais so restringidas por meio de uma disjuno. Nesse caso, um empregado pode ser um engenheiro ou
uma secretria e ele pode ser horista ou mensalista.
Alm da disjuno, podemos ter um overlap, representado pela letra o. No caso do overlap, uma entidade de uma
superclasse pode ser membro de mais que uma subclasse em uma especializao ou generalizao. Analise a generalizao
no exemplo da Figura 3.12. Suponha que uma pea fabricada em uma tornearia pode ser manufaturada ou torneada, ou
ainda, pode ter sido manufaturada e torneada.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
37
Figura 3.12. Uma Generalizao com Overlap
6.3.4. Lattice ou Mltipla Herana
Uma subclasse pode ser definida por meio de um lattice, ou mltipla herana, ou seja, ela pode ter diversas superclasses,
herdando caractersticas de todas. Tomemos como base a situao de que uma construtora possui diversos funcionrios,
que podem ser engenheiros ou secretrias. Um funcionrio pode tambm ser assalariado ou horista. Todo gerente de
departamento da construtora deve ser um engenheiro e assalariado.
O modelo lgico da expresso acima tem o seguinte formato (Figura 3.13):
Figura 3.13. Um Lattice com a Subclasse Gerente Compartilhada
Nesse caso, ento, um gerente ser um funcionrio que, alm de possuir as caractersticas prprias de Gerente, herdar
as caractersticas de Engenheiro e de Mensalista.
7. Diagrama Entidade-Relacionamento
O Diagrama Entidade-Relacionamento (DER) composto por um conjunto de objetos grficos que visa representar
todos os objetos do modelo Entidade Relacionamento, tais como entidades, atributos, atributos chaves, relacionamentos,
restries estruturais etc.
O diagrama ER oferece uma viso lgica do banco de dados, fornecendo um conceito mais generalizado de como esto
estruturados os dados de um sistema.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
38
7.1. Tipos de Notao do Modelo Entidade-Relacionamento
Vrias formas de notao de um MER foram desenvolvidas. Entre elas podemos destacar:
ER Peter Chen
UML OMG (Grady, Booch, Rumbaugh)
IE (Information Engineering) J. Martin
IDEF1X (US Federal Governament)
Apesar de todas se destinarem, em suma, mesma finalidade, a notao mais utilizada ainda a ER, proposta por Peter
Chen.
Os elementos grficos que compem o Diagrama Entidade-Relacionamento (DER), proposto por Chen (1976), so:
Retngulos: conjuntos de entidades.
Linhas duplas: conjuntos de entidades fracas.
Elipses: atributos. Os atributos da chave primria so sublinhados.
Losangos: conjuntos de relacionamentos. Linhas duplas representam conjuntos de relacionamentos envolvidos
com entidades fracas.
Linhas: unem atributos aos conjuntos de entidades e esses aos conjuntos de relacionamentos.
Linhas direcionadas: a seta indica a cardinalidade um.
Elipses duplas: atributos multivalorados. Linhas duplas indicam participao total de uma entidade em um
conjunto de relacionamentos.
A Figura 3.14 apresenta os objetos que compem o diagrama E-R.
Apresentamos, na Figura 3.15, um DER para o esquema da base de dados COMPANHIA.
Mapeando a descrio apresentada na Figura 3.14, teremos:
Os tipos de entidades tais como EMPREGADO, DEPARTAMENTO e PROJETO so mostrados em retngulos.
Os tipos de relacionamentos tais como TRABALHA-PARA, GERENCIA, CONTROLA e TRABALHA-EM so
mostrados em losangos interligados a tipos de entidades participantes.
Os atributos so mostrados em elipses conectadas a tipos de entidades ou relacionamentos.
Os componentes de um atributo composto so tambm representados em elipses, porm conectados ao
atributo ao qual eles pertencem (atributo Nome de EMPREGADO).
Os atributos multivalorados so denotados em elipses com linhas duplas (atributo Localizao de
DEPARTAMENTO).
Os atributos-chaves so representados de forma sublinhada.
Os atributos derivados so representados em elipses com linhas tracejadas (atributo Nmero De Empregados
de DEPARTAMENTO).
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
39
Os tipos de entidades-fracas so distinguidos por retngulos com linhas duplas e os relacionamentos de
identificao, por losangos com linhas duplas (tipo de entidade-fraca DEPENDENTE e tipo de relacionamento
de identificao DEPENDENTE-DE).
Figura 3.14. Objetos que Compem o Diagrama ER
A chave-parcial de um tipo de entidade-fraca sublinhada com linha tracejada.
So mostradas as razes de cardinalidade para cada tipo de relacionamento binrio. A razo de cardinalidade
de DEPARTAMENTO: EMPREGADO em GERNCIA 1:1, para DEPARTAMENTO: EMPREGADO em
TRABALHA-PARA 1:N e M:N para TRABALHA em.
As restries de participao parcial so especificadas por linhas simples. As linhas paralelas denotam
participao total (dependncia existencial).
So apresentados os nomes de papis para o tipo de relacionamento SUPERVISIONA porque o tipo de entidade
EMPREGADO ocupa dois papis nesse relacionamento.
Na Figura 3.15 apresentado o mesmo esquema da Figura 3.16, porm com a utilizao da notao alternativa para
ilustrar as restries estruturais de tipos de relacionamentos.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
40
Figura 3.15. DER para o Esquema Companhia
Figura 3.16. DER para o Esquema Companhia com Notao Alternativa
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
41
Captulo 4 Modelo de Dados Relacional
Hoje em dia o termo banco de dados bastante popular em diversas
reas de atuao. Com o aumento da utilizao de computadores na
manipulao de dados que envolvem diversas aplicaes, os bancos
de dados esto sendo desenvolvidos e aplicados nas diferentes
reas que envolvem o comrcio, a indstria e a pesquisa acadmica
entre outras.
1. Introduo
Segundo Silberschatz (2006), Modelo de Dados uma coleo de ferramentas conceituais para descrever dados, relaes
de dados, semntica de dados e restries de consistncia, constituindo-se em uma maneira de descrever o projeto de
um banco de dados nos seus vrios nveis de abstrao.
As bases do modelo relacional foram lanadas por Edgar Codd, nos anos 1970, e comeou a ser realmente utilizado
nas empresas a partir de 1987, por meio do SGBDs, tendo como finalidade representar os dados como uma coleo de
relaes, onde cada relao representada por uma tabela. O conceito principal vem da teoria dos conjuntos (lgebra
relacional) atrelado idia de que no relevante ao usurio saber onde os dados esto nem como os dados esto.
Quando uma relao pensada como uma tabela de valores, cada linha nessa tabela representa uma coleo de dados
relacionados. Esses valores podem ser interpretados como fatos descrevendo uma instncia de uma entidade ou de um
relacionamento. O nome da tabela e das colunas so utilizados para facilitar a interpretao dos valores armazenados
em cada uma de suas linhas. Todos os valores em uma coluna so necessariamente do mesmo tipo.
Na terminologia do modelo relacional temos:
cada tabela chamada de relao;
cada linha de uma tabela chamada de tupla;
cada coluna denominada atributo;
o tipo de dado que descreve cada coluna chamado de domnio;
o grau da relao o nmero do atributos da relao.
Unidade II
Sistemas de Banco de Dados:
conceitos e arquiteturas
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
42
Sistemas de Banco de Dados: conceitos e arquiteturas Unidade II
Segundo Takai (2005), quando uma relao vista como uma tabela de valores, cada linha representa uma coleo de
valores relacionados. Esses valores podem ser interpretados como um fato que descreve uma entidade ou uma instncia
de relacionamento. O nome da tabela e os nomes das colunas so usados para ajudar a interpretar o significado dos
valores em cada linha da tabela.
Exemplificando, na Figura 4.1, a primeira tabela chamada ESTUDANTE porque cada linha representa o fato sobre uma
particular entidade estudante. Os nomes das colunas Nome, Nmero, Classe, Departamento especificam como
interpretar os valores em cada linha, baseando-se nas colunas em que cada um se encontra. Todos os valores de uma
coluna so, normalmente, do mesmo tipo.
Figura 4.1. Exemplo de uma base de dados relacional
ESTUDANTE Nome Matrcula Classe Departamento
Jos 3217 1 DCT
Ana Maria 2325 2 DCT
Carla 4112 1 ENG
CURSO Nome Cdigo Crditos Departamento
Banco de Dados I BD1322 4 DCT
Redes Neurais RN1132 4 DCT
Banco de Dados II BD1323 4 DCT
Cculo I CA1011 4 ENG
SEO Nmero Curso Semestre Ano Professor
11 RN1132 1 2007 Antnio
13 BD1322 1 2007 Pedro
13 BD1323 2 2007 Anglica
10 CA1011 1 2006 Pedro
Tomemos como exemplo de uma relao esquema R de grau 4, que descreve estudantes universitrios:
R
ESTUDANTE
(Nome, Nmero, Classe, Departamento)
Nessa relao-esquema, ESTUDANTE o nome da relao esquema, que tem 4 atributos. Podemos especificar alguns
domnios para cada atributo da relao ESTUDANTE:
dom(Nome)=Nomes
dom(Matrcula)=Nmero da matrcula dos alunos
dom(Classe)=Nmero de identificao das turmas
dom(Departamento)=Cdigo relativo ao departamento a que os cursos esto vinculados
Uma relao r
1
da relao esquema R(A
1
, A
2
, ..., A
n
), tambm denotada por r(R), um conjunto de tuplas r={ t
1
, t
2
, ...,
t
m
}. Cada tupla t uma lista ordenada de n valores t=<v
1
, v
2
, ..., v
n
>, onde cada valor v
i
, 1 i n, um elemento
do dom(A
i
) ou um valor especial null. So utilizados, com freqncia, os termos inteno da relao para o esquema R e
extenso da relao para a instncia r(R).
1.1. Atributos-chave de uma relao
Uma relao definida como um conjunto de tuplas. Pela definio, todos os elementos de um conjunto so distintos.
Assim, todas as tuplas de uma relao tambm so distintas. Isso significa que nenhuma tupla pode ter a mesma
1 Tambm chamada de instncia de relao
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
43
combinao de valores para todos os seus atributos. Normalmente, existem subconjuntos de atributos de uma relao
esquema R com a propriedade de que nenhuma tupla de uma relao r de R tenha a mesma combinao de valores para
esses atributos. Suponha que esse subconjunto seja denotado por SC; ento, para quaisquer tuplas t
1
e t
2
em r de R,
deve valer a regra:
t
1
[SC] t
2
[SC]
Assim, SC chamada Super-Chave da relao esquema R. Toda relao tem ao menos uma Super-Chave, que o
conjunto de todos os seus atributos. Uma chave C, de uma relao esquema R, uma Super-Chave de R com a propriedade
adicional de no se poder remover qualquer atributo A de C e continuar a ser Super-Chave de R. Assim, uma chave
uma Super-Chave mnima; uma super-chave da qual no se pode remover qualquer atributo.
Por exemplo, considere a relao ESTUDANTE da Figura 4.1. O conjunto de atributos {Nmero} uma Super-Chave
de ESTUDANTE, porque se sabe que nenhum estudante ir ter o mesmo nmero de matrcula, e tambm uma chave,
pois no se pode remover nenhum atributo. Qualquer conjunto de atributos que inclua Nmero - por exemplo, {Nmero,
Nome, Anos} - ser uma Super-Chave.
No entanto, o conjunto {Nmero, Nome, Departamento} no uma chave de ESTUDANTE porque, removendo Nome
ou Anos, ou ambos, o conjunto resultante ser ainda uma Super-Chave.
A chave deve ser determinada pelo significado dos atributos na relao esquema e deve ser invariante ao tempo. Por
exemplo, o atributo Nome da relao ESTUDANTE no pode ser indicado como chave, uma vez que nada garante a no
ocorrncia de homnimos. Em geral, uma relao esquema pode ter mais que uma chave. Nestes casos, cada chave
chamada chave-candidata. Por exemplo, o esquema da relao ESTUDANTE poderia ter um atributo adicional Cdigo,
para indicar o cdigo interno de estudantes na escola. Assim, o esquema teria duas chaves candidatas: Nmero e
Cdigo. comum designar uma das chaves-candidatas como a Chave-Primria da relao. A indicao no modelo de
qual Chave-Candidata a Chave-Primria efetuada sublinhando-se os atributos que formam a Chave-Candidata
escolhida. Quando uma relao esquema tem muitas Chaves-Candidatas, a escolha da Chave-Primria arbitrria.
No entanto, sempre melhor escolher a Chave-Primria com o menor nmero de atributos.
Dicas
O sinnimo um nome alternativo para a entidade. So muito utilizados quando dois grupos de usurios
tm diferentes nomes para o mesmo objeto significante.
2. Restries do Modelo Relacional
2.1. Restries em Tipos Relacionamentos
Em geral, os tipos relacionamentos sofrem certas restries que limitam as possveis combinaes das entidades
participantes. Essas restries so derivadas de restries impostas pelo estado dessas entidades no minimundo.
A Figura 3.6 representa a situao de que um empregado pode gerenciar apenas um departamento, enquanto que um
departamento pode ser gerenciado por apenas um empregado.
Esse tipo de restrio chamado de cardinalidade. A cardinalidade indica o nmero de relacionamentos dos quais uma
entidade pode participar.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
44
A cardinalidade apresenta as seguintes possibilidades:
um para um (1:1);
um para vrios (1:N);
vrios para vrios (M:N).
No exemplo da Figura 3.6, a cardinalidade 1:1, pois cada entidade EMPREGADO pode gerenciar apenas um
DEPARTAMENTO e um DEPARTAMENTO pode ser gerenciado por apenas um EMPREGADO.
No exemplo da figura 3.3, no relacionamento FORNECEDOR - Fornece Para - PROJETO, o relacionamento M:N, pois
um fornecedor pode fornecer vrias peas para vrios projetos.
Uma restrio muito importante a participao. A participao define a existncia de uma entidade por intermdio do
relacionamento, podendo ser parcial ou total.
No exemplo da Figura 3.6, a participao do empregado parcial, pois nem todo EMPREGADO gerencia um
DEPARTAMENTO, porm a participao do departamento nesse relacionamento total, pois todo DEPARTAMENTO
necessita ser gerenciado por um EMPREGADO. Dessa forma, todas as entidades do tipo entidade DEPARTAMENTO
precisam participar do relacionamento, mas nem todas as entidade do tipo entidade EMPREGADO precisam
participar do relacionamento.
Na Figura 3.2, ambas as participaes so totais, pois todo EMPREGADO precisa trabalhar em um DEPARTAMENTO
e todo DEPARTAMENTO tem que ter EMPREGADOS trabalhando nele. Essas restries so chamadas de restries
estruturais.
2.2. Restries de Integridade
As chaves-candidatas de cada relao esquema so especificadas pelas restries de chave. Essas chaves-candidatas
possuem valores que devem ser nicos para todas as tuplas de quaisquer instncias da relao esquema.
Alm da restrio de chave, existem dois outros tipos de restries no modelo relacional: a integridade de entidade e a
integridade referencial.
Na restrio de integridade de entidade nenhum valor da chave-primria pode ser nulo, pois o valor de uma chave-
primria utilizado para identificar tuplas em uma relao. Por exemplo, se duas ou mais tuplas tiverem o valor null para
a chave primria, no haver como diferenciar uma tupla da outra.
As restries de chave e de integridade de entidade aplicam-se apenas a relaes individuais.
A restrio de integridade referencial usada para manter a consistncia entre tuplas de duas relaes. Informalmente,
a restrio de integridade referencial estabelece que uma tupla de uma relao que se refere outra relao deve se
referir a uma tupla existente naquela relao.
Por exemplo, na Figura 4.2, o atributo NDEP de EMPREGADO indica o nmero do departamento que cada empregado
trabalha. Assim, todos os valores de NDEP nas tuplas da relao EMPREGADO devem pertencer ao conjunto de valores
do atributo DNMERO da relao DEPARTAMENTO. Para definir formalmente a restrio de integridade referencial,
h a necessidade de, antes, definir o conceito de chave-estrangeira (CE). As condies para uma chave-estrangeira,
descritas abaixo, especificam uma restrio de integridade referencial entre duas relaes esquemas R1 e R2.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
45
Um conjunto de atributos CE na relao esquema R1 ser uma chave-estrangeira de R1 se ele satisfizer as seguintes regras:
os atributos em CE tm o mesmo domnio dos atributos da chave-primria CP da outra relao esquema R
2
.
Diz-se que os atributos CE referenciam ou referem-se relao R
2
;
uma CE na tupla t
1
ou tem um valor que ocorre como CP de alguma tupla t
2
de R
2
ou tem o valor null.
No primeiro caso, tem-se t
1
[CE] = t
2
[CP], e diz-se que t
1
referencia ou refere-se tupla t
2
. Uma base de dados tem
muitas relaes e possui muitas restries de integridade referencial. O projetista deve ter um claro entendimento do
significado ou papel que os atributos desempenham nas diversas relaes esquemas da base de dados para que essas
restries sejam especificadas. Normalmente, as restries de integridade referencial so derivadas dos relacionamentos
entre entidades representadas pelas relaes esquemas. Por exemplo, considere a base de dados mostrada na 4.2.
Na relao EMPREGADO, o atributo NDEP refere-se ao departamento em que cada empregado trabalha; desse modo,
designa-se NDEP como a chave-estrangeira de EMPREGADO, referenciando a relao DEPARTAMENTO. Isso significa que
um valor de NDEP em alguma tupla t1 da relao EMPREGADO deve ter um valor correspondente para a chave-primria
da relao DEPARTAMENTO o atributo DNMERO em alguma tupla t2 da relao DEPARTAMENTO ou o valor de
NDEP pode ser null se o empregado no pertencer a nenhum departamento. Na Figura 4.2, a tupla do empregado John
Smith referencia a tupla departamento de Pesquisa, indicando que John Smith trabalha para esse departamento.
Note que uma chave-estrangeira pode referenciar sua prpria relao.
Por exemplo, o atributo NSSSUPER em EMPREGADO refere-se ao supervisor de um empregado, isto , outro empregado.
Pode-se, diagramaticamente, mostrar as restries de integridade desenhando-se arcos direcionados, partindo da chave-
estrangeira para a relao referenciada.
A Figura 4.4 ilustra o esquema apresentado na Figura 4.3, com as restries de integridade referencial anotadas dessa
maneira.
Caso o projetista tenha interesse em manter as restries vlidas para toda a base de dados, essas restries de
integridade deveriam ser especificadas no esquema da base de dados relacional.
No sistema relacional, a linguagem de definio de dados (DDL) deveria fornecer recursos para especificar os vrios tipos
de restries tal que o SGDB possa verific-las automaticamente. Muitos sistemas de gerenciamento de base de dados
relacionais permitem restries de chave e de integridade de entidade, mas alguns no permitem a integridade referencial.
Figura 4.2. Instncias da base de dados COMPANHIA
EMPREGADO
PNOME MNOME SNOME NSS DATANASC ENDEREO SEXO SALRIO NSSSUPER NDEP
John S Smith 123456789 09-JAN-55 R. A. 1 M 3000 3334666 5
Franklin T Wong 333445555 08-DEZ-45 R. B. 2 M 4000 888665565 5
Alicia J Zelaya 999887777 19-JUL58 Av. C. 3 F 2500 987654321 4
Jeniffer S Wallace 987654321 20-JUN-31 Trav. D. 4 F 6300 888664444 4
Ramesh K Narayan 666884444 15-SET-52 R. E. 5 M 3800 333445555 5
Joyce A English 453453453 31-JUL-52 R. F. 6 F 2500 333445565 5
Ahmet V Jabbar 987987987 29-MAR-50 Av. G. 7 M 2500 987654321 4
James E Borg 888665555 10-NOV-27 Av. H. 8 M 5500 null 1
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
46
DEPARTAMENTO
DNOME DNMERO NSSGER DATINICGER
Pesquisa 5 333445555 22-MAI-78
Administrativo 4 9876543231 01-JAN-85
Gerencial 1 888655555 19-JUN-71
LOCAIS_DEPTO
DNMERO DLOCALIZAO
1 Housson
4 Stafford
5 Bellaire
5 Sugariand
5 Housson
PROJETO
PNOME PNMERO PLOCALIZAO DNUM
ProdutoX 1 Bellaire 5
ProdutoY 2 Sugarland 5
ProdutoZ 3 Houston 5
Automao 10 Stafford 4
Reorganizao 20 Houston 1
Beneficiamento 30 Stafford 4
TRABALHA EM
NSSEMP PNRO HORAS
123456789 1 32,5
123456789 2 7,5
666884444 3 40,0
453453453 1 20,0
453453453 2 20,0
333445555 2 10,0
333445555 3 10,0
333445555 10 10,0
999887777 20 10,0
999887777 30 30,0
987987987 10 10,0
987987987 10 35,0
987654321 30 5,0
987654321 30 20,0
321654987 20 Null
DEPENDENTE
NSSEMP NOMEDEPENDENTE SEXO DATANIV RELAO
333445555 Alice F 05-ABR-76 FILHA
333445555 Theodore M 25-OUT-73 FILHO
333445555 Joy F 03-MAI-48 ESPOSA
987654321 Abner M 29-FEV-78 MARIDO
123456789 Michael M 01-JAN-78 FILHO
123456789 Alice F 31-DEZ-78 FILHA
1234565789 Elizabeth F 05-MAI-57 ESPOSA
Fonte: Adaptado de Takai, Italiano, Ferreira , 2005.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
47
Figura 4.3. Esquema da base de dados relacional COMPANHIA
EMPREGADO
DEPARTAMENTO
DNOME ONMERO NSSGER DATINICGER
LOCAIS_DEPTO
DNMERO DLOCALIZAO
PROJETO
TRABALHA EM
NSSEMP PNRO HORAS
DEPENDENTE
Fonte: Adaptado de Takai, italiano, Ferreira, 2005.
Figura 4.4. Esquema COMPANHIA com restries de integridade
EMPREGADO
DEPARTAMENTO
LOCAIS_DEPTO
DNMERO DLOCALIZAO
PROJETO
TRABALHA EM
NSSEMP PNRO HORAS
DEPENDENTE
Fonte: Adaptado de Takai, Italiano, Ferreira, 2005.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
48
Captulo 5 Projeto de Banco de Dados Relacional Utilizando o MER
1. Mapeamento do MER para o Modelo de Dados Relacional
Em projetos de banco de dados, comum que os dados sejam modelados por intermdio de um modelo de dados de
alto-nvel. Os produtos gerados por esse processo so os esquemas de vises que so posteriormente integrados para
formar um nico esquema.
O Modelo Entidade-Relacionamento (MER) o modelo de dados de alto-nvel normalmente adotado, e o esquema das
vises e de toda a base de dados especificado em diagramas entidade-relacionamento (DER). O prximo passo a ser
dado para que os dados sejam modelados o mapeamento do diagrama da base de dados global, obtido na fase anterior,
para um modelo de dados de implementao.
Uma estratgia de traduo, ou de mapeamento, bastante utilizada a do modelo de dados relacional. Para isso, considere
o esquema relacional mostrado na Figura 5.1, que foi derivado do DER da Figura 3.14, seguindo um procedimento de
mapeamento. Esse procedimento apresentado passo-a-passo, a partir do exemplo do DER COMPANHIA.
Figura 5.1. Modelo relacional para o esquema COMPANHIA
EMPREGADO
DEPARTAMENTO
LOCAIS_DEPTO
DNMERO DLOCALIZAO
PROJETO
TRABALHA EM
NSSEMP PNRO HORAS
DEPENDENTE
cp
cp
cp
cp
Ce
cp
cp
Ce
Ce
Ce
Ce
Ce Ce
Ce
Fonte: Adaptado de Takai et al.(2005).
1.1. Passos para o Mapeamento do MER
Passo 1:
Para cada entidade regular E no DER, criar uma relao R que inclua todos os atributos simples de E. Para um atributo
composto, inclua apenas os atributos simples que compem o atributo composto. Escolha um dos atributos-chave de E
como sendo a chave-primria de R. Se a chave escolhida de E for composta, ento o conjunto de atributos simples que o
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
49
compem iro formar a chave-primria de R. No exemplo, foram criadas as relaes EMPREGADO, DEPARTAMENTO e
PROJETO, correspondentes s entidades regulares EMPREGADO, DEPARTAMENTO e PROJETO presentes no DER. Os
atributos indicados com CE (chave-estrangeira) ou * (atributos de relacionamento) no foram includos ainda; eles sero
adicionados durante os passos subseqentes. Foram escolhidas as chaves primrias NSS, DNMERO e PNMERO para
as relaes EMPREGADO, DEPARTAMENTO e PROJETO, respectivamente.
Passo 2:
Para cada tipo de entidade fraca W do DER, com o tipo de entidade de identificao E, criar uma relao R e incluir todos
os atributos simples (ou os componentes simples de atributos compostos) de W como atributos de R. Alm disso, incluir
como a chave-estrangeira de R a chave-primria da relao que corresponde ao tipo de entidade de identificao; isso
resolve o problema do tipo do relacionamento de identificao de W. A chave-primria de R a combinao da chave-
primria do tipo de entidade de identificao e a chave-parcial do tipo de entidade fraca W. No exemplo, foi criada a
relao DEPENDENTE, correspondente ao tipo de entidade fraca DEPENDENTE do DER. Foi includa a chave-primria da
relao EMPREGADO que corresponde ao tipo de entidade de identificao como um atributo de DEPENDENTE; foi
renomeado o atributo NSS para NSSEMP, embora no seja necessrio. A chave-primria da relao DEPENDENTE a
combinao {NSSEMP, NOMEDEPENDENTE} porque NOMEDEPENDENTE chave-parcial de DEPENDENTE.
Passo 3:
Para cada tipo de relacionamento binrio 1:1 R do DER, criar as relaes S e T, que correspondem aos tipos de entidade
participantes em R. Escolher uma das relaes, por exemplo, S, que inclua como chave-estrangeira de S a chave-primria
de T. melhor escolher o tipo de entidade com participao total em R como a relao S. Inclua todos os atributos simples
(ou os componentes simples de atributos compostos) do tipo de relacionamento 1:1 R como atributos de S. No exemplo,
foi mapeado o tipo de relacionamento 1:1 GERNCIA, escolhendo o tipo de entidade participante DEPARTAMENTO para
fazer o papel de S porque sua participao no tipo de relacionamento GERNCIA total (todo departamento tem um
gerente). Foi includa a chave-primria da relao EMPREGADO como a chave-estrangeira na relao DEPARTAMENTO,
que foi chamado de NSSGER. Tambm foi includo o atributo simples Data-Incio do tipo de relacionamento GERNCIA
na relao DEPARTAMENTO e foi renomeado como DATINICGER. Note-se que uma alternativa para o mapeamento de
um tipo de relacionamento 1:1 seria unir os dois tipos de entidade e o tipo de relacionamento numa nica relao. Isso
particularmente apropriado quando ambas as participaes so total e quando os tipos de entidade no participam em
quaisquer outros tipos de relacionamentos.
Passo 4:
Para cada tipo de relacionamento binrio regular 1:N (no fraca) R, identificar a relao S, que representa o tipo de
entidade que participa do lado N do tipo de relacionamento. Incluir como chave-estrangeira de S a chave-primria da
relao T, que representa o outro tipo de entidade que participa em R; isso porque cada instncia da entidade do lado
1 est relacionada a mais de uma instncia de entidade no lado N do tipo de relacionamento. Por exemplo, no tipo de
relacionamento 1:N TRABALHA-PARA cada empregado est relacionado a um nico departamento. Incluir tambm
quaisquer atributos simples (ou componentes simples de atributos compostos) do tipo de relacionamento 1:N como
atributos de S. No exemplo, foram mapeados os tipos de relacionamentos 1:N TRABALHA-PARA e SUPERVISIONA.
Para TRABALHA-PARA incluiu-se a chave-primria da relao DEPARTAMENTO como a chave-estrangeira na relao
EMPREGADO e foi chamado DNUM. Para SUPERVISIONA incluiu-se a chave-primria da relao EMPREGADO como a
chave-estrangeira na relao EMPREGADO e foi denominado NSSSUPER. O relacionamento CONTROLA mapeado da
mesma maneira.
Passo 5:
Para cada tipo de relacionamento binrio M:N R, criar uma nova relao S para representar R. Incluir como chave-estrangeira
em S as chaves-primrias das relaes que representam os tipos de entidades participantes; sua combinao ir formar
a chave-primria de S. Incluir tambm qualquer atributo simples do tipo de relacionamento M:N (ou componentes simples
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
50
dos atributos compostos) como atributos de S. Note-se que no se pode representar um tipo de relacionamento M:N como
uma simples chave-estrangeira em uma das relaes participantes como foi feito para os tipos de relacionamentos
1:1 e 1:N por causa da razo de cardinalidade M:N. Relacionamentos M:N sempre derivam uma nova relao, para o
tipo de relacionamento.
Passo 6:
Para cada atributo A multivalorado, criar uma nova relao R que inclua um atributo correspondendo a A e a chave-primria
K da relao que representa o tipo de entidade ou o tipo de relacionamento que tem A como atributo. A chave-primria
de R a combinao de A e K. Se o atributo multivalorado composto, incluir os atributos simples que o compem.
Passo 7:
Para cada tipo de relacionamento n-rio R, n>2, criar uma nova relao S para representar R. Incluir como chave-
estrangeira em S as chaves-primrias das relaes que representam os tipos de entidades participantes. Incluir tambm
qualquer atributo simples do tipo de relacionamento n-rio (ou componentes simples dos atributos compostos) como
atributo de S. A chave-primria de S normalmente uma combinao de todas as chaves-estrangeiras e referencia as
relaes que representam os tipos de entidades participantes. Porm, se a restrio de participao (min, max) de um
dos tipos de entidades E que participa em R tiver max=1, ento a chave-primria de S pode ser a chave-estrangeira que
referencia a relao E correspondente a E; isso porque cada entidade em E ir participar em apenas uma instncia de R
e, portanto, pode identificar univocamente essa instncia de relacionamento.
O principal ponto que deve ser considerado em um esquema relacional, quando comparado ao esquema do MER, que
os tipos de relacionamento no so representados explicitamente; eles so representados por dois atributos A e B, um
para a chave-primria e outra para a chave-estrangeira sobre o mesmo domnio includos em duas relaes S e T.
Duas tuplas em S e T esto relacionadas quando elas tiverem o mesmo valor para A e B, ou seja, os relacionamentos
so definidos pelos valores dos atributos A e B.
Figura 5.2. Exemplo de mapeamento de um relacionamento ternrio
FORNECEDOR
FNOME ...
PROJETO
PNOME ...
PEA
NMERO ...
FORNECE
FNOME PNOME NMERO QUANTIDADE
Fonte: Adaptado de Takai et al.(2005).
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
51
A Figura 5.3 mostra uma representao esquemtica dos passos que devem ser seguidos para a traduo de um MER.
Figura 5.3. Representao esquemtica dos passos para o mapeamento do MER.
Fonte: Adaptado de Takai, italiano, Ferreira, 2005.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
52
Captulo 6 SQL Structured Query Language
1. Introduo
No incio dos anos 1970, no laboratrio de San Jos, surgiu a Linguagem SQL, como fruto de um projeto da IBM.
Empenhavam-se num projeto de uma linguagem que se adequasse ao modelo relacional. Esse projeto trabalhava em
paralelo com outro que visava desenvolver um sistema de gerncia de Banco de Dados relacional, chamado System R.
O primeiro sistema de Banco de Dados baseado em SQL tornou-se disponvel comercialmente no final dos anos 1970.
A primeira verso padronizada da linguagem SQL foi publicada em meados de 1980 e dois institutos trabalharam na
sua padronizao, o ANSI e o ISO. Desde ento, a linguagem vem evoluindo e culminando na criao de novas verses
padronizadas, tais como a verso SQL-92 e a SQL-99, assim chamadas em referncia aos anos em que foram publicadas.
Figura 6.1. Ambiente da linguagem SQL
A linguagem SQL utilizada na grande maioria dos sistemas de Bancos de Dados relacionais, tais como MySQL, DB2,
SQLServer, e se tornou a mais poderosa ferramenta de definio e manipulao de Bancos de Dados relacionais.
2. Aplicabilidade e Uso
A linguagem SQL bem diferente das linguagens comuns de programao por ser, basicamente, uma linguagem de
consulta a banco de dados. Ao contrrio da maioria das linguagens de programao, a linguagem SQL no uma linguagem
procedural
1
. Na linguagem SQL no se especifica como ou em que ordem sero executados os processos que iro fornecer
os resultados requeridos; eles so apenas informados com base nos resultados desejados. Desse modo, o sistema de
banco de dados o responsvel por escolher adequadamente os procedimentos a serem executados, de forma que os
resultados sejam obtidos com a maior eficincia possvel.
Com a Linguagem SQL podemos tanto definir e construir relaes, como manipular diversas relaes, de forma a obter
resultados desejados. Por isso, ela considerada uma linguagem de definio e de manipulao de dados.
1 Linguagem de programao na qual o elemento bsico de programao a procedure (uma sequncia de instrues rotina, sub-rotina ou funo associadas a um nome prprio).
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
53
A linguagem SQL pode estar presente numa imensa quantidade de sistemas de banco de dados, estando visvel ou mascarada
(embutida). Na forma visvel o usurio digita os comandos na linguagem SQL diretamente em um prompt de comando, de
onde tambm possvel visualizar os resultados. J na forma embutida, a linguagem SQL no est visvel diretamente
ao usurio; os programadores podem embutir os comandos em SQL, dentro de um programa, e criar uma interface mais
amigvel com o usurio comum esse pode interagir mais facilmente com a interface do que com a prpria linguagem SQL.
Dessa forma, usurios comuns podem manipular um banco de dados sem mesmo ter algum conhecimento sobre de SQL.
A linguagem SQL composta por um conjunto de declaraes que usado para acessar os dados utilizando gerenciadores
de banco de dados. Nem todos os gerenciadores utilizam SQL.
Uma entrada SQL constituda por uma sequncia de comandos onde um comando composto por uma sequncia de
termos (tokens
1
), terminada por um ponto-e-vrgula (;). O fim do fluxo de entrada tambm termina o comando, sendo
vlido os termos dependendo da sintaxe particular de cada comando.
Um termo pode ser uma palavra-chave, um identificador, um identificador entre aspas, um literal (ou constante), ou um
caractere especial. Geralmente, os termos so separados por espao em branco (espao, tabulao ou nova-linha), mas
no h necessidade se no houver ambiguidade (normalmente s acontece quando um caractere especial est adjacente
a um termo de outro tipo). Alm disso, podem existir comentrios na entrada SQL e esses comentrios no so termos,
constituindo-se, na realidade, em equivalentes a espao em branco.
A seguir apresentada uma entrada SQL, sintaticamente vlida para servir de exemplo.
Figura 6.2. Exemplo de uma entrada SQL sintaticamente vlida
SELECT * FROM MINHA_TABELA;
UPDATE MINHA_TABELA SET A = 5;
INSERT INTO MINHA_TABELA VALUES (3, oi voc);
A sequncia apresentada na Figura 6.2 consiste de uma sequncia de trs comandos, um por linha. Mesmos no existindo
um limitador que obrigue que a sintaxe seja escrita dessa forma, pode haver mais de um comando na mesma linha, e um
nico comando pode ocupar vrias linhas.
A sintaxe da linguagem SQL no diferencia claramente quais termos identificam comandos e quais so operandos ou
parmetros. Em geral, os primeiros termos so o nome do comando e, portanto, no exemplo da Figura 6.2 pode-se dizer
que esto presentes os comandos SELECT, UPDATE e INSERT. Entretanto, para exemplificar, o comando UPDATE
sempre requer que o termo SET aparea em uma determinada posio, e essa forma particular do comando INSERT
tambm requer a presena do termo VALUES para estar completa. As regras precisas da sintaxe de cada comando
esto descritas na Parte VI.
2.1. Identificadores e Palavras-Chave
Os termos SELECT, UPDATE e VALUES mostrados no exemplo da Figura 6.2 so exemplos de palavras-chave, ou
seja, palavras que possuem um significado definido na linguagem SQL. Os termos MINHA_TABELA e A so exemplos
de identificadores, os quais identificam nomes de tabelas, colunas e outros objetos do banco de dados, dependendo do
comando onde so utilizados. Portanto, algumas vezes so simplesmente chamados de nomes. As palavras-chave e os
identificadores possuem a mesma estrutura lxica, significando que no possvel saber se o termo um identificador
ou uma palavra chave sem conhecer a linguagem.
Os identificadores e as palavras-chave do SQL devem iniciar por uma letra (a-z e, tambm, letras com diacrtico
2
...
e letras no latinas), ou o caractere sublinhado (_). Os demais caracteres de um identificador, ou da palavra-chave,
1 Token em computao um segmento de texto ou smbolo que pode ser manipulado por um parser, que fornece um significado ao texto; em outras palavras, um conjunto de
caracteres (de um alfabeto, por exemplo) com um significado coletivo.
2 diacrtico do Gr. diakritiks, que se pode distinguir diz-se dos sinais grficos com que se notam os caracteres alfabticos para lhe dar um valor especial
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
54
podem ser letras, sublinhados, dgitos (0-9) ou o cifro ($). Deve ser observado que, de acordo com o padro SQL, o
cifro no permitido em identificadores e, portanto, pode tornar a aplicao menos portvel. O padro SQL no ir
definir palavra-chave contendo dgitos, ou comeando ou terminando por sublinhado e, portanto, os identificadores com
essa forma esto a salvo contra possveis conflitos com extenses futuras do padro.
O sistema no utiliza mais que NAMEDATALEN-1 caracteres de um identificador; podem ser escritos nomes mais
longos nos comandos, mas so truncados. Por padro, NAMEDATALEN 64 e, portanto, o comprimento mximo de
um identificador 63. Se esse limite causar problema, pode ser aumentado, modificando a constante NAMEDATALEN.
Os identificadores e as palavras-chave no fazem distino entre letras maisculas e minsculas. Portanto, a expresso
UPDATE MINHA_TABELA SET A = 5; tambm pode ser escrita como uPdAtE Minha_TaBeLa SeT a = 5;.
De forma geral, utiliza-se a conveno de escrever as palavras-chave em letras maisculas e os nomes em letras minsculas,
tornando a expresso da seguinte forma: UPDATE minha_tabela SET a = 5;.
Um segundo tipo de identificador o identificador delimitado ou identificador entre aspas, formado pela colocao de
uma sequncia arbitrria de caracteres entre aspas (). Um identificador delimitado sempre um identificador, e
nunca uma palavra-chave. Portanto, a expresso select pode ser usada para fazer referncia a uma tabela ou coluna
chamada select, enquanto select sem aspas sempre uma palavra-chave ocasionando, por isso, um erro do analisador
quando usado onde um nome de tabela ou de coluna for esperado.
Identificadores entre aspas podem conter qualquer caractere que no sejam as prprias aspas. Essa funcionalidade
permite criar nomes de tabelas e de colunas que no seriam possveis de outra forma, como os contendo espaos ou
e-comercial (&). O limite do comprimento ainda se aplica.
A linguagem SQL diferencia as letras maisculas de minsculas ao colocarmos um identificador entre aspas, enquanto
as letras dos nomes no delimitados por aspas so sempre convertidas em minsculas. Por exemplo, os identificadores
FOO e foo so considerados o mesmo identificador.
2.2. Constantes
A linguagem SQL
1
define, basicamente, trs tipos de constante com tipo implcito. So eles: cadeias de caracteres,
cadeias de bits e numricas. As constantes tambm podem ser especificadas com tipo explcito, o que permite uma
representao mais precisa, e um tratamento mais eficiente por parte do sistema.
2.2.1. Constantes do Tipo Cadeia de Caracteres
Uma constante cadeia de caracteres no SQL uma sequncia arbitrria de caracteres envolta por apstrofos ().
Exemplificando, suponhamos a seguinte expresso: Esta uma cadeia de caracteres.
A forma de escrever um apstrofo dentro de uma constante cadeia de caracteres, em conformidade com o padro
SQL, colocar dois apstrofos adjacentes como, por exemplo, Maria DAlmeida. Alguns SGBDs permitem, tambm, a
utilizao da contrabarra (\) como caractere de escape para colocar apstrofos dentro de cadeia de caracteres como,
por exemplo, Maria D\Almeida.
O SGBD PostgreSQL permite a utilizao dos escapes de contrabarra no estilo da linguagem C. Comando como o \b
para voltar apagando (backspace), \f para avano de formulrio (form feed), \n para nova-linha, \r para retorno do
carro, \t para tabulao e \xxx, onde xxx um nmero octal, o byte com o cdigo. Nesse caso, para incluir uma
contrabarra em uma constante do tipo cadeia de caracteres devem ser escritas duas contrabarras adjacentes.
1 A quantidade de tipos de constantes pode variar conforme o Sistema Gerenciado de Banco de Dados que usa a linguagem SQL.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
55
Na linguagem SQL, duas constantes cadeias de caracteres separadas apenas por espao em branco com pelo menos um
caractere de nova-linha, so concatenadas e tratadas efetivamente como se a cadeia de caracteres tivesse sido escrita
em uma constante. Desse modo, vejamos a expresso descrita na Figura 6.3. Porm, a expresso SELECT foo bar;
interpretada como uma expresso de sintaxe invlida.
2.2.2. Constantes do Tipo Cadeia de Bits
Uma constante do tipo cadeia de bits se parece com uma constante do tipo cadeia de caracteres contendo a letra B
(maiscula ou minscula) imediatamente antes do apstrofo de abertura (sem espaos separadores) como, por exemplo,
B1001. Os nicos caracteres permitidos dentro de uma constante do tipo cadeia de bits so 0 e 1.
Figura 6.3. Exemplo de uma constante de caracteres.
SELECT foo
bar;
Equivale a:
SELECT foobar;
Como forma alternativa, constantes do tipo cadeia de bits podem ser especificadas usando a notao hexadecimal,
colocando a letra X (maiscula ou minscula) no incio como, por exemplo, X1FF. Essa notao equivale a uma constante
do tipo cadeia de bits contendo quatro dgitos binrios para cada dgito hexadecimal.
As duas formas de constantes do tipo cadeia de bits podem ocupar mais de uma linha, da mesma forma que uma constante
do tipo cadeia de caracteres.
2.2.3. Constantes Numricas
De forma geral, so aceitas constantes numricas nas seguintes formas gerais:
dgitos
dgitos.[dgitos][e[+-]dgitos]
[dgitos].dgitos[e[+-]dgitos]
dgitos[e[+-]dgitos
Nas formas gerais descrita, dgitos so um ou mais dgitos decimais (0 a 9), devendo haver pelo menos um dgito antes
ou depois do ponto decimal, caso esse seja usado.
Deve haver, tambm, pelo menos um dgito aps a marca de expoente (e), caso esteja presente. No podem existir
espaos ou outros caracteres incorporados constante. Deve ser observado que os sinais menos e mais que antecedem
a constante no so, na verdade, considerados parte da constante, e sim um operador aplicado constante.
Abaixo so mostrados alguns exemplos de constantes numricas vlidas:
42
3.5
4.
.001
5e2
1.925e-3
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
56
Uma constante numrica no contendo o ponto decimal nem o expoente presumida, inicialmente, como sendo do tipo
integer se o seu valor for apropriado para o tipo integer (32 bits); seno, presumida como sendo do tipo bigint, se o seu
valor for apropriado para o tipo bigint (64 bits); caso contrrio, assumida como sendo do tipo numeric. As constantes
que contm pontos decimais e/ou expoentes so sempre presumidas, inicialmente como sendo do tipo numeric.
O tipo de dado atribudo inicialmente para a constante numrica apenas o ponto de partida para os algoritmos de resoluo
de tipo. Na maioria dos casos, a constante automaticamente convertida no tipo mais apropriado conforme o contexto.
2.2.4. Constantes de Outros Tipos
Pode ser declarada uma constante de um tipo arbitrrio utilizando uma das seguintes notaes:
tipo cadeia de caracteres
cadeia de caracteres::tipo
O texto da constante cadeia de caracteres passado para a rotina de converso da entrada para o tipo chamado tipo. O
resultado uma constante do tipo indicado. A converso explcita de tipo pode ser omitida caso no haja ambiguidade
com relao ao tipo que a constante deva ter (por exemplo, quando atribuda diretamente para uma coluna de uma
tabela), e nesse caso convertida automaticamente.
Tambm possvel especificar a converso de tipo utilizando a sintaxe semelhante chamada de funo: nome_do_tipo
( cadeia de caracteres ). Porm, nem todos os nomes de tipo podem ser usados dessa forma.
2.3. Operadores
A linguagem SQL define que um nome de operador uma sequncia com at NAMEDATALEN-1 (por padro 63) caracteres
da seguinte lista:
+ - * / < > = ~ ! @ # % ^ & | ` ?
Porm, existem algumas restries para os nomes de operadores:
No podem ocorrer as sequncias -- e /* em nenhuma posio no nome do operador, porque so consideradas
incio de comentrio.
Um nome de operador com vrios caracteres no pode terminar por + ou por -, a no ser que o nome tambm
contenha ao menos um dos seguintes caracteres: ~ ! @ # % ^ & | ` ?. Por exemplo, @- um nome de
operador permitido, mas *- no .
2.4. Caracteres Especiais
Alguns caracteres no alfanumricos possuem significado especial diferente de ser um operador.
O caractere cifro ($) seguido por dgitos utilizado para representar parmetros posicionais no corpo da
definio de uma funo. Em outros contextos, o caractere cifro pode ser parte de um identificador.
Os parnteses (()) possuem seu significado usual de agrupar expresses e impor a precedncia. Em alguns
casos, os parnteses so requeridos como parte da sintaxe fixada para um determinado comando SQL.
Os colchetes ([]) so utilizados para selecionar elementos da matriz.
As vrgulas (,) so utilizadas em algumas construes sintticas para separar elementos da lista.
O ponto-e-vrgula (;) termina um comando SQL, no podendo aparecer em nenhum lugar dentro do comando,
exceto dentro de constantes do tipo cadeia de caracteres ou identificadores entre aspas.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
57
Os dois-pontos (:) so utilizados para selecionar fatias de matrizes. Em certos dialetos do SQL, como a
linguagem SQL incorporada, os dois-pontos so utilizados como prefixo dos nomes das variveis.
O asterisco (*) utilizado em alguns contextos para denotar todos os campos da linha de uma tabela ou de
um valor composto. Tambm possui um significado especial quando utilizado como argumento da funo de
agregao COUNT.
O ponto (.) utilizado nas constantes numricas, e para separar os nomes de esquemas, tabelas e colunas.
2.5. Comentrios
A linguagem SQL define que um comentrio uma sequncia arbitrria de caracteres comeando por dois hfens e
prosseguindo at o fim da linha como, por exemplo, a expresso Este um comentrio em conformidade com o padro
SQL-99. Alternativamente, possvel utilizarem-se blocos de comentrios no estilo da linguagem C, conforme apresentado
na Figura 6.4, onde o comentrio comea por /* e se estende at encontrar a ocorrncia correspondente de */. Esses
blocos de comentrios podem estar aninhados, conforme especificado no padro SQL, mas diferentemente da linguagem
C, permitindo transformar em comentrio grandes blocos de cdigo contendo blocos de comentrios.
Os comentrios so removidos do fluxo de entrada antes de prosseguir com a anlise sinttica, sendo substitudos por
espao em branco.
Figura 6.4. Exemplo de comentrios utilizando o formato da linguagem C
/* comentrio de vrias linhas
* com aninhamento: /* bloco de comentrio aninhado */
*/
2.6. Precedncia Lxica
Um item lxico, tambm chamado de token, uma unidade bsica do texto correspondente ao programa fonte sendo,
normalmente, representado internamente pelo analisador lxico por trs funes:
Classe: diz respeito classificao lxica do token. Sob essa tica, um item pode ser classificado, por
exemplo, com sendo um identificador, uma constante, um operador ou mesmo uma sequncia de caracteres.
Valor ou Lexema: diz respeito ao valor lxico do token, que depende da classe e pode ser categorizado como:
Token Simples: so aqueles que no possuem argumentos uma vez que sua classe os define completamente.
Ex. operadores matemticos, relacionais, lgicos.
Token com Argumento: so aqueles que possuem um valor associado e correspondem aos elementos da
linguagem definidos pelo programador. Ex. o valor de uma constante numrica.
Posio: diz respeito ao que identifica a localizao do token no programa fonte, auxiliando no processo de
correo de erros.
A precedncia lxica diz respeito ordem de processamento dos comandos por parte do analisador lxico, sendo que a
maioria dos operadores possui a mesma precedncia e associatividade esquerda. A precedncia e a associatividade dos
operadores esto codificadas no analisador lxico, podendo ocasionar um comportamento contra-intuitivo. Exemplificando,
os operadores booleanos < e > possuem uma precedncia diferente dos operadores booleanos <= e >=.
Tambm, em alguns casos necessrio adicionar parnteses ao utilizar uma combinao de operadores unrios e
binrios. Tomemos a expresso SELECT 5! 6; para anlise. Caso a expresso seja apresentada conforme descrita, o
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
58
interpretador a analisar como SELECT 5! (-6);, o que decorre do fato de que o interpretador no tem como identificar
que o smbolo ! definido como operador unrio-direito e no um operador binrio que foi colocado entre os operandos.
Para que a expresso seja interpretada corretamente, necessrio apresent-la com o uso adequado do parntese e deve
ser escrita como SELECT (5!) 6;. A ttulo de exemplo, a tabela 6.1 apresenta a precedncia e a associatividade
dos operadores no PostgreSQL.
2. Definio de Dados Utilizando SQL
Nos bancos de dados relacionais, os dados so armazenados em tabelas, portanto, necessrio entender como as tabelas
so criadas e modificadas, e as funcionalidades disponveis para controlar que dados podem ser armazenados nas tabelas.
2.1. Noes Bsicas de Tabela
Uma tabela em um banco de dados relacional muito semelhante a uma tabela no papel: formada por linhas e colunas.
O nmero e a ordem das colunas so fixos, e cada coluna possui um nome. O nmero de linhas varivel, refletindo a
quantidade de dados armazenados em um determinado instante. O padro SQL no d nenhuma garantia sobre a ordem
das linhas na tabela.
Quando a tabela lida, as linhas aparecem em uma ordem aleatria, a no ser que a classificao seja requisitada
explicitamente. Alm disso, o SQL no atribui identificadores nicos para as linhas e, portanto, possvel existirem
vrias linhas totalmente idnticas na tabela. Isto uma consequncia do modelo matemtico subjacente ao SQL, mas
geralmente no desejvel. Mais adiante, neste captulo, ser mostrado como lidar com essa questo.
Tabela 6.1. Precedncia dos operadores em ordem Decrescente
Operador/Elemento Associatividade Descrio
. esquerda separador de nome de tabela/coluna
:: esquerda converso de tipo estilo PostgreSQL
[ ] esquerda seleo de elemento de matriz
- direita menos unrio
^ esquerda exponenciao
* / % esquerda multiplicao, diviso, mdulo
+ - esquerda adio, subtrao
IS IS TRUE, IS FALSE, IS UNKNOWN, IS NULL
ISNULL teste de nulo
NOTNULL teste de no nulo
(qualquer outro) esquerda os demais operadores nativos e os definidos pelo usurio
IN membro de um conjunto
BETWEEN contido em um intervalo
OVERLAPS sobreposio de intervalo de tempo
LIKE ILIKE SIMILAR correspondncia de padro em cadeia de caracteres
< > menor que, maior que
= direita igualdade, atribuio
NOT direita negao lgica
AND esquerda conjuno lgica
OR esquerda disjuno lgica
Cada coluna de uma tabela possui um tipo de dado que o fator que restringe o conjunto de valores que podem ser
atribudos coluna e atribui semntica
1
aos dados armazenados na coluna. Cada SGBD possui um conjunto de tipos
1 semntica do Gr. semantik, da significao estudo da linguagem humana do ponto de vista do significado das palavras e dos enunciados. PRIBERAM - Lngua Portuguesa
On-Line . (N. do T.)
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
59
de dado nativos, adequados para muitas aplicaes e, de forma geral, os usurios tambm podem definir seus prprios
tipos de dado.
Alguns dos tipos de dado mais utilizados so o integer para nmeros inteiros, numeric para nmeros possivelmente
fracionrios, text para cadeias de caracteres, date para datas, time para valores da hora do dia, e timestamp para valores
contendo tanto data quanto hora.
2.2. Criao de Tabelas
Para criar uma tabela utiliza-se o comando CREATE TABLE. Esse comando necessita que sejam especificados, ao menos,
o nome da nova tabela, os nomes das colunas, e o tipo de dado de cada coluna (Figura 6.4).
A sintaxe do comando :
CREATE TABLE tabela (campo1 tipo [(tamanho)] [NOT NULL] [ndice1] [, campo2 tipo [(tamanho)] [NOT NULL] [ndice2]
[, ...]] [, CONSTRAINT ndicedemulticampos [, ...]])
Os elementos da sintaxe do comando CREATE TABLE so apresentados na Tabela 6.2.
Tabela 6.2. Elementos do Comando CREATE TABLE
Parte Descrio
tabela O nome da tabela a ser criada.
campo1, campo2 O nome do campo ou campos a serem criados na nova tabela. Uma tabela deve
ter pelos menos um campo.
tipo O tipo de dados de campo na nova tabela.
tamanho O tamanho do campo em caracteres (somente os campos Texto e Binrio)
ndice1, ndice2 Uma clusula CONSTRAINT que define um ndice de campo nico.
indice de multicampos Uma clusula CONSTRAINT que define um ndice hde campos mltiplos.
A sintaxe da Figura 6.5 cria a tabela chamada minha_primeira_tabela contendo duas colunas, onde a primeira coluna
denominada primeira_coluna e possui o tipo de dado text, e a segunda coluna chama-se segunda_coluna e possui
o tipo de dado integer. necessrio observar que a lista de colunas deve ser envolta por parnteses e os elementos da
lista separados por vrgula.
Figura 6.5. Exemplo de Expresso para a Criao de uma Tabela
CREATE TABLE minha_primeira_tabela (
primeira_coluna text,
segunda_coluna integer
);
De forma geral, so dados nomes para as tabelas e para as colunas condizentes com as informaes armazenadas
(Figura 6.6.)
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
60
Figura 6.6. Exemplo de Expresso para a Criao de uma Tabela
CREATE TABLE produtos (
cod_prod integer not null,
nome text (30),
preco decimal (7,2)
);
Existe um limite quanto quantidade de colunas que uma tabela pode conter pode variar entre 250 e 1600, dependendo
dos tipos de dados das colunas.
Dica 1: Quando so criadas tabelas inter-relacionadas, aconselhvel escolher um padro coerente para
atribuir nomes s tabelas e colunas.
Dica 2: A restrio not null indica que o atributo deve ser obrigatoriamente preenchido; se no for especificado,
ento o default que o atributo possa assumir o valor nulo.
2.3. Remoo de Tabelas
Caso uma tabela no seja mais necessria, possvel remov-la utilizando-se o comando DROP TABLE sintaxe do
comando :
DROP {TABLE tabela | INDEX ndice ON tabela}
Os elementos da sintaxe do comando DROP TABLE so apresentados na Tabela 6.3.
Tabela 6.3. Elementos do Comando DROP TABLE.
Parte Descrio
Tabela O nome da tabela a ser excluda ou a tabela a partir da qual um ndice deve ser
excluido.
ndice O nome do ndice a ser excludo da tabela.
Figura 6.7. Exemplo de Remoo de uma Tabela.
DROP TABLE minha_primeira_tabela;
DROP TABLE produtos;
Dica 1: Observe que, no caso em que a chave primria da tabela removida composta de elementos de
diversas outras tabelas, essas devem ser devidamente corrigidas. Isso pode resultar na alterao do projeto
fsico de diversas tabelas e acabar implicando a construo de uma nova base de dados.
2.4. Incluso de Atributos em uma Tabela
O comando ALTER TABLE permite que o usurio faa a incluso de novos atributos em uma tabela (Figura 6.8.). A
sintaxe do comando :
ALTER TABLE tabela {ADD {COLUMN campo tipo[(tamanho)] [NOT NULL] [CONSTRAINT ndice] | CONSTRAINT
ndicedemulticampos} | DROP {COLUMN campo I CONSTRAINT nomedondice} }
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
61
Os elementos da sintaxe do comando ALTER TABLE so apresentados na Tabela 6.4.
Figura 6.8. Exemplo de Incluso de Coluna em uma Tabela
ALTER TABLE minha_primeira_tabela add terceira_coluna interger;
Tabela 6.4. Elementos do Comando ALTER TABLE
Parte Descrio
Tabela O nome da tabela a ser alterada.
Campo O nome do campo a ser adicionado ou excludo da tabela.
Tipo O tipo de dados de campo.
Tamanho O tamanho do campo em caracteres (somente os campos Texto e Binrio).
ndice O ndice para campo.
ndicedemulticampos A definio de um ndice de campos mltiplos a ser adicionado tabela.
Nomedondice O nome do ndice de campo mltiplo a ser removido.
Alm de permitir adicionar colunas em uma tabela, no comando ALTER TABLE, voc pode alterar uma tabela existente
utilizando:
ADD CONSTRAINT para adicionar um ndice de campos mltiplos. (Para maiores informaes sobre ndices
de campos mltiplos, consulte o tpico da clusula CONSTRAINT).
DROP COLUMN para excluir um campo. Voc especifica somente o nome do campo.
DROP CONSTRAINT para excluir um ndice de campos mltiplos. Voc especifica somente o nome do ndice
aps a palavra reservada CONSTRAINT.
NOT NULL em um campo nico ou dentro de uma clusula CONSTRAINT nomeada, que se aplica a uma
CONSTRAINT de campo nico ou campos mltiplos. Contudo, voc pode aplicar a restrio NOT NULL
somente uma vez a um campo pois, seno, ocorrer um erro em tempo de execuo.
Voc no pode adicionar ou excluir mais de um campo ou ndice de cada vez.
Dica 1: No caso do comando ALTER TABLE, a restrio NOT NULL no permitida, pois assim que se insere
um novo atributo na tabela, o valor para o mesmo em todas as tuplas da tabela recebero o valor NULL.
2.5. Colunas do Sistema
Implicitamente definidas pelo SGBD, toda tabela possui diversas colunas do sistema. Desse modo, esses nomes no
podem ser utilizados como nomes de colunas definidas pelo usurio. A Tabela 6.5 apresenta os nomes usuais das colunas
do sistema.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
62
Tabela 6.5. Nome das Colunas do Sistema
Nome Descrio
oid
o identificador de objeto (object ID) de uma linha e consiste de um nmero serial adicionado
pelo SGBD, automaticamente, a todas as linhas da tabela (a no ser que a tabela seja criada
com WITHOUT OIDS e, nesse caso, esta coluna no estar presente). O tipo desta coluna
oid (o mesmo nome da coluna).
tableoid
o OID da tabela que contm esta linha. Esse atributo particularmente til nas consultas
fazendo seleo em hierarquias de herana, porque sem ele difcil saber de que tabela se
origina cada linha. Pode ser feita uma juno entre tableoid e a coluna oid de pq_class para
obter o nome da tabela.
xmin
o identificador da transao de insero (transaction ID) para esta verso da linha. Uma
verso da linha um estado individual da linha; cada atualizao da linha cria uma nova verso
de linha para a mesma linha lgica.
cmin o identificador do comando, comeando por zero, dentro da transao de insero.
xmax
o identificador da transao de excluso (transaction ID), ou zero para uma verso de linha
no excluda.
cmax o identificador do comando dentro da transao de excluso, ou zero.
ctid a localizao fsica da verso da linha dentro da tabela.
Os OIDs, os identificadores de transaes e os identificadores de comandos so quantidades de 32 bits atribudas a partir
de um contador nico para todo o agrupamento de bancos de dados. Na prtica, essas quantidades criam um limite de
232 (4 bilhes) de comandos SQL dentro de uma nica transao.
Dica 1: Deve-se observar que essa restrio de uso do nome de uma coluna definida pelo sistema diferente
do nome ser uma palavra-chave ou no, pois colocar o nome entre aspas no faz esta restrio deixar de
ser aplicada.
3. Especificando as Restries Bsicas em SQL
Apesar dos tipos de dados funcionarem como uma forma de limitar os dados que podem ser armazenados em uma tabela,
vrias aplicaes necessitam de restries com um refinamento maior. Em uma tabela, onde uma coluna que contenha
dados sobre preos de produtos deveria, em princpio, aceitar apenas valores positivos. Porm, no existe qualquer tipo
de dado que aceite, apenas esses valores. Outro problema bastante comum a situao em que essa mesma tabela de
produtos necessita limitar a insero de produtos de forma que exista apenas uma linha para cada cdigo de produto.
A linguagem SQL permite que sejam definidas restries quanto a colunas e tabelas, de forma a controlar os dados
que so armazenados nela. Desse modo, possvel impedir que o usurio armazene dados em uma coluna da tabela
que acabe por violar a integridade do contedo. Tais restries permitem que se tenha controle sobre os dados que so
armazenados na tabela.
3.1. Restries de Verificao
3.1.1. Restries de Coluna
Entre os tipos de restries existentes, a restrio de verificao a mais genrica, pois permite que sejam especificados
os valores que podem ser armazenados em uma determinada coluna para estar de acordo com uma expresso booleana
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
63
(valor-verdade
1
). Na Figura 6.9, apresentada uma expresso onde verificado se os valores relativos aos preos so
positivos.
Figura 6.9. Exemplo de Restrio de Verificao em uma Coluna de uma Tabela
cod_prod integer,
nome text,
preco numeric CHECK (preco > 0)
);
Na linguagem SQL, a definio da restrio vem aps o tipo de dado, assim como a definio do valor padro. J o
valor padro e a restrio podem estar em qualquer ordem, sendo que a restrio de verificao formada pela palavra
chave CHECK, seguida por uma expresso entre parnteses. Cabe salientar que a expresso da restrio de verificao
necessita envolver a coluna sendo restringida.
Por outro lado, tambm possvel atribuir um nome individual para a restrio, tornando a mensagem de erro mais clara
e permitindo fazer referncia restrio quando se desejar alter-la (Figura 6.10).
Figura 6.10. Exemplo de Restrio de Verificao em uma Coluna Atribuindo um Nome para a Restrio
cod_prod integer,
nome text,
preco numeric CONSTRAINT chk_preco_positivo CHECK (preco > 0)
);
A palavra-chave CONSTRAINT permite que seja atribudo um nome para a restrio e deve ser seguida por um identificador
(nome que ser dado restrio) e um valor que definir a restrio.
Alm disso, possvel definir uma restrio de verificao que referencie mais de uma coluna. Na Figura 6.11, temos
uma expresso onde verificado o valor armazenado tanto do preo quanto do preo com desconto. Nesse caso, o que
se espera que o valor relativo ao preo seja maior do que o valor relativo ao preo com desconto.
Figura 6.11. Exemplo de Restrio de Verificao em uma Coluna Referenciando mais de uma Coluna
cod_prod integer,
nome text,
preco numeric CHECK (preco > 0),
preco_com_desconto numeric CHECK (preco_com_desconto > 0),
CHECK (preco > preco_com_desconto)
);
1 Na lgica, o valor-verdade (truth-value) um valor indicando at que ponto uma declarao verdadeira.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
64
3.1.2. Restries de Tabela
Diferentemente da restrio de coluna, a restrio de tabela utiliza uma nova sintaxe, e no est anexada a uma coluna
em particular, aparecendo como um item parte na lista de colunas separadas por vrgula. As definies das colunas e
as definies dessas restries podem estar em qualquer ordem.
As Figuras 6.12 e 6.13 apresentam o exemplo da Figura 6.9, reescrito na forma de restrio de tabela.
Figura 6.12. Exemplo de Restrio de Verificao em uma Tabela (Sintaxe I)
cod_prod integer,
nome text,
preco numeric,
CHECK (preco > 0),
preco_com_desconto numeric,
CHECK (preco_com_desconto > 0),
CHECK (preco > preco_com_desconto)
);
Figura 6.13. Exemplo de Restrio de Verificao em uma Tabela (Sintaxe II)
cod_prod integer,
nome text,
preco numeric CHECK (preco > 0),
preco_com_desconto numeric,
CHECK (preco_com_desconto > 0 AND preco > preco_com_desconto)
);
3.2. Restries de No Nulo
Uma Restrio de No Nulo define que o valor de uma coluna no pode ser nulo, ou seja, que necessita conter algum valor
(Figura 6.14). Cabe lembrar que uma Restrio de No Nulo sempre escrita como restrio de coluna e no uma restrio
de tabela, sendo que essa funcionalmente equivalente a criar uma restrio de verificao CHECK (nome_da_coluna
IS NOT NULL.
Como uma coluna pode possuir mais de uma restrio, para considerar todas as restries necessrias, basta escrever
uma restrio em seguida da outra (Figura 6.15), sendo que a ordem em que as restries so escritas no determina
necessariamente sua ordem de checagem.
Figura 6.14. Exemplo de Restrio de No Nulo
cod_prod integer NOT NULL,
nome text NOT NULL,
preco numeric
);
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
65
Figura 6.15. Exemplo de Mais de uma Restrio
cod_prod integer NOT NULL,
nome text NOT NULL,
preco numeric NOT NULL CHECK (preco > 0)
);
Dica 1: Em grande parte dos projetos de banco de dados, a maioria das colunas deve ser especificada como
no-nula.
3.3. Restries de Unicidade
A restrio de unicidade procura garantir que os dados contidos em uma coluna, ou mesmo em um grupo de colunas,
seja nico com relao a todas as outras linhas da tabela. A Figura 6.16 apresenta um exemplo desse tipo de restrio
aplicada a uma coluna e a Figura 6.17, um exemplo desta mesma restrio aplicada a uma tabela.
Figura 6.16. Exemplo de Restrio de Unicidade aplicada a uma Coluna
cod_prod integer UNIQUE,
nome text,
preco numeric
);
Figura 6.17. Exemplo de Restrio de Unicidade aplicada a uma Tabela
cod_prod integer,
nome text,
preco numeric,
UNIQUE (cod_prod)
);
Caso uma restrio de unicidade faa referncia a um grupo de colunas, essas devem ser listadas separadas por vrgula,
conforme a Figura 6.18. Esse tipo de restrio especifica que a combinao dos valores das colunas indicadas deve ser
nica para toda a tabela, embora no seja necessrio que cada uma das colunas seja nica.
Figura 6.18. Exemplo de Restrio de Unicidade aplicada a um Grupo de Colunas
CREATE TABLE exemplo (
a integer,
b integer,
c integer,
UNIQUE (a, c)
);
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
66
Alm disso, possvel atribuir nomes s restries de unicidade (Figura 6.19).
Figura 6.19. Exemplo de Restrio de Unicidade em uma Coluna Atribuindo um Nome para a Restrio
cod_prod integer CONSTRAINT unq_cod_prod UNIQUE,
nome text,
preco numeric
);
3.4. Chaves Primrias
De modo geral, a restrio de chave primria diz respeito combinao da restrio de unicidade com a restrio de no-
nulo. Desse modo, possvel definir esse tipo de restrio de mais de um modo, conforme apresentado na Figura 6.20.
Figura 6.20. Exemplo de Restrio de Chave Primria versus Restrio de No-Nulo e Unicidade
1) CREATE TABLE produtos (
cod_prod integer UNIQUE NOT NULL,
nome text,
preco numeric
);
2) CREATE TABLE produtos (
cod_prod integer PRIMARY KEY,
nome text,
preco numeric
);
Por outro lado, as chaves primrias tambm podem restringir valores em mais de uma coluna (Figura 6.21).
Figura 6.21. Exemplo de Restrio de Chave Primria em Mais de uma Coluna
CREATE TABLE exemplo (
a integer,
b integer,
c integer,
PRIMARY KEY (a, c)
);
3.5. Chaves Estrangeiras
Uma restrio de chave estrangeira procura especificar que o valor de uma coluna, ou mesmo grupo de colunas, corresponda
a algum valor existente em uma linha de outra tabela, de forma a manter a integridade referencial
1
entre duas ou mais
tabelas relacionadas.
1 Integridade Referencial um conceito de banco de dados que garante que todos os relacionamentos propostos entre tabelas no modelo de entidade-relacionamento (ER) sero
respeitados, dando a certeza que os dados de um banco de dados estaro ntegros.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
67
A ttulo de exemplo, tomemos a tabela criada pela sintaxe do segundo item apresentado na Figura 6.20. Adicionalmente,
criemos outra tabela destinada a conter os dados dos pedidos relativos aos produtos. Como existe uma relao entre as
duas tabelas (pedidos e produtos) em que cada pedido precisa conter um ou mais produtos, podemos impor a restrio
de chave-estrangeira para garantir que no sejam includos produtos em um pedido que no estejam cadastrados na
tabela produtos (Figura 6.22).
Figura 6.22. Exemplo de Restrio de Chave Estrangeira
CREATE TABLE pedidos (
cod_pedido integer PRIMARY KEY,
cod_prod integer REFERENCES produtos (cod_prod),
quantidade integer
);
No exemplo utilizado, podemos dizer que a tabela de pedidos a que faz referncia, e a tabela de produtos a referenciada.
Esse tipo de restrio necessita que exista correspondncia entre o nmero e tipo das colunas referenciadas.
Por outro lado, uma tabela tambm pode conter mais de uma restrio de chave estrangeira, o que utilizado para
implementar relacionamentos muitos-para-muitos entre tabelas (Figura 6.22). Na Figura 6.23 exemplificada uma relao
em que a tabela itens_pedidos faz referncia s tabelas pedidos e produtos para poder armazenar os dados relativos
a que pedido os itens se referem e que produto dever constar de cada item.
A partir da restrio imposta, sabemos que a chave estrangeira no permite a criao de pedidos no relacionados com
algum produto. No entanto, necessrio considerar a situao onde um produto seja removido aps a criao de um
pedido fazendo referncia a esse produto. A linguagem SQL permite tratar essa situao no sentido de que quando se
desejar remover um produto referenciado por um pedido (por meio da tabela itens_pedidos), isso no ser permitido, pois
caso um pedido seja removido, os itens do pedido tambm sero removidos.
Figura 6.23. Exemplo de Restrio de Chave Estrangeira em uma Relao M:M
nome text,
preco numeric
);
endereco_entrega text,
...
);
CREATE TABLE itens_pedidos (
cod_prod integer REFERENCES produtos,
cod_pedido integer REFERENCES pedidos,
quantidade integer,
PRIMARY KEY (cod_prod, cod_pedido)
);
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
68
De forma geral, as opes mais comuns so restringir ou mesmo excluir em cascata (Figura 6.24). O comando RESTRICT,
utilizado para garantir a integridade, tambm pode ser escrito como NO ACTION, e tambm o padro se nada for
especificado.
Alm das opes apresentadas, ainda possvel outras duas opes sobre o que deve acontecer com as colunas da chave
estrangeira quando a chave primria excluda, SET NULL e SET DEFAULT. Deve ser observado que isso no livra da
obedincia s restries. Por exemplo, se uma ao especificar SET DEFAULT, mas o valor padro no satisfizer a chave
estrangeira, a excluso da chave primria no vai ser bem-sucedida.
Semelhante ao comando ON DELETE existe tambm o comando ON UPDATE, utilizada quando uma coluna referenciada
atualizada, sendo que as aes possveis so as mesmas.
Figura 6.24. Exemplo de Restrio e Deleo em Cascata
nome text,
preco numeric
);
endereco_entrega text,
...
);
CREATE TABLE itens_pedidos (
cod_prod integer REFERENCES produtos ON DELETE RESTRICT,
cod_pedido integer REFERENCES pedidos ON DELETE CASCADE,
quantidade integer,
PRIMARY KEY (cod_prod, cod_pedido)
);
Dica 1: A chave estrangeira deve referenciar colunas de uma chave primria ou de uma restrio de unicidade.
4. Comandos para Alterao de Esquema SQL
Em um banco de dados podem existir vrios esquemas e dentro de cada esquema podemos criar vrias tabelas. Ao invs
de criar vrios bancos de dados, criamos um e criamos esquemas dentro desse. Isso permite uma maior flexibilidade,
pois uma nica conexo ao banco permite acessar todos os esquemas e suas tabelas. Portanto, devemos planejar com
eficincia para saber quantos bancos precisaremos, quantos esquemas em cada banco e quantas tabelas em cada esquema.
Cada banco ao ser criado traz um esquema public, que onde ficam todas as tabelas, caso no seja criado outro esquema.
Esse esquema public no padro ANSI. Caso se pretenda ao portvel, devemos excluir esse esquema public e criar
outros. Por default todos os usurios criados tm privilgio CREATE e USAGE para o esquema public.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
69
Um esquema essencialmente um espao de nomes: contm objetos com nome (tabelas, tipos de dado, funes e
operadores), cujos nomes podem ser iguais aos de outros objetos existentes em outros esquemas. Os objetos com nome
so acessados qualificando seus nomes, usando o nome do esquema como prefixo, ou definindo um caminho de procura
que inclua os esquemas desejados.
Existem diversas razes pelas quais pode-se desejar utilizar esquemas:
Para permitir vrios usurios utilizarem o mesmo banco de dados sem que um interfira no outro.
Para organizar objetos do banco de dados em grupos lgicos tornando-os mais gerenciveis.
Para poder colocar, em esquemas separados, aplicaes desenvolvidas por terceiros, de modo a no haver
coliso com nomes de outros objetos.
Os esquemas so anlogos aos diretrios no nvel do sistema operacional, exceto os esquemas que no podem ser
aninhados.
4.1. Criao de Esquema
A instruo CREATE SCHEMA pode criar um esquema, as tabelas e as exibies contidas e as permisses GRANT,
REVOKE ou DENY em qualquer item protegido em uma nica instruo. Deve ser executada como um lote separado
sendo que os objetos gerados por ela so criados diretamente no esquema ativo. As transaes CREATE SCHEMA so
atmicas e, caso algum erro ocorra durante a execuo da instruo, nenhum item protegido especificado ser criado e
nenhuma permisso ser concedida.
Os itens protegveis criados por CREATE SCHEMA podem ser listados em qualquer ordem, com exceo das exibies que
fazem referncia a outras exibies. Nesse caso, a exibio mencionada deve ser criada antes da exibio que a menciona.
Portanto, uma instruo GRANT pode conceder permisses em um objeto antes que o objeto propriamente dito seja criado,
ou uma instruo CREATE VIEW pode aparecer antes das instrues CREATE TABLE, que criam as tabelas mencionadas
pela exibio. Alm disso, as instrues CREATE TABLE podem declarar chaves estrangeiras definidas posteriormente
na instruo CREATE SCHEMA
CREATE SCHEMA nome_do_esquema [AUTHORIZATION nome_do_usurio ] [elemento_do_esquema [ ... ] ] CREATE
SCHEMA AUTHORIZATION nome_do_usurio [ elemento_do_esquema [ ... ] ]
A Tabela 6.6 apresenta as partes que integram a sintaxe do comando.
Tabela 6.6. Elementos do Comando CREATE SCHEMA
Parte Descrio
Nome_do_esquema O nome do esquema a ser criado. Se for omitido, ser usado o nome do usurio
como nome do esquema. O nome no pode comear por pq_, porque esses nomes
so reservados para os esquemas do sistema.
Nome_do_usurio O nome do usurio que ser o dono do esquema. Se for omitido, tem como padro
o usurio que est executando o comando. Somente os superusurios podem criar
esquemas pertencentes a outros usurios.
Elemento_do_esquema Um comando SQL definindo um objeto a ser criado no esquema. Atualmente,
somente CREATE TABLE, CREATE VIEW, CREATE INDEX, CREATE SEQUENCE,
CREATE TRIGGER e GRANT so aceitos como clusula no comando CREATE
SCHEMA. Os objetos de outros tipos podem ser criados por comando em separado,
aps o esquema ter sido criado.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
70
Na Figura 6.25 apresentada uma expresso em que um esquema e uma viso esto mostrando os filmes premiados.
Deve ser observado que os subcomandos individuais no terminam por ponto-e-vrgula.
Figura 6.25. Exemplo de Criao de um Esquema
CREATE SCHEMA cinema
CREATE TABLE filmes (titulo text, lancamento date, premios text[])
CREATE VIEW premiados AS
SELECT titulo, lancamento FROM filmes WHERE premios IS NOT NULL;
Dica 1: As instrues que contm CREATE SCHEMA AUTHORIZATION, mas no especificam um nome, so
permitidas somente para compatibilidade com verses anteriores.
Dica 2: As instrues CREATE SCHEMA oferecem suporte para DENY e REVOKE. As clusulas DENY e
REVOKE sero executadas na ordem em que aparecem na instruo CREATE SCHEMA.
4.1.1. Modificando um Esquema
O comando ALTER SCHEMA altera a definio de um esquema. Para utilizar o comando ALTER SCHEMA necessrio
ser o dono do esquema ou ter privilgio para tal. Para mudar o nome do esquema tambm necessrio possuir o privilgio
CREATE no banco de dados.
Para alterar o dono, tambm necessrio ser um membro direto ou indireto do novo papel dono, alm de possuir o
privilgio CREATE no banco de dados.
ALTER SCHEMA nome_do_esquema RENAME TO novo_nome_do_esquema
ALTER SCHEMA nome_do_esquema OWNER TO nome_do_novo_usurio
Dica 1: Apesar do padro SQL no possuir esse tipo de recurso, boa parte dos SGBDs j o disponibilizam
como aprimoramento da linguagem.
4.1.2. Removendo um Esquema
O comando DROP SCHEMA objetiva remover esquemas do banco de dados. O esquema somente pode ser removido pelo
seu dono ou por um dba. Deve ser observado que o dono pode remover o esquema (e, portanto, todos os objetos que
esse contm), mesmo que no seja o dono de alguns objetos contidos no esquema.
DROP SCHEMA nome_do_esquema [, ...] [ CASCADE | RESTRICT ]
A opo CASCADE permite que sejam removidos os objetos (tabelas, funes) contidos no esquema, e a opo RESTRICT
permite que seja verificada a existncia de algum objeto vinculado ao esquema e impede que o esquema seja removido
quando tem algum contedo. Essa uma opo padro para a instruo DROP SCHEMA.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
71
4.2. O Esquema Pblico
Na Figura 6.24 o esquema criado recebeu o nome de cinema e os demais componentes (tabela e viso) tambm foram
nominados. No entanto, caso no fosse indicado um nome para o esquema e para os elementos criados, por padro, as
tabelas (e outros objetos) seriam colocadas automaticamente em um esquema chamado public. Todo banco de dados
novo possui esse esquema. Portanto, poderamos reescrever o exemplo da Figura 6.25 da seguinte forma (Figura 6.26),
sem qualquer prejuzo quanto criao do esquema desejado.
Figura 6.26. Exemplo de Criao de um Esquema Public
CREATE SCHEMA
CREATE TABLE filmes (titulo text, lancamento date, premios text[])
CREATE VIEW premiados AS
SELECT titulo, lancamento FROM filmes WHERE premios IS NOT NULL;
Com base no exemplo da Figura 6.26, a tabela filmes no seria criada por uma instruo como CREATE TABLE cinema.
filmes e sim como CREATE TABLE public.filmes.
4.3. O Caminho de Procura do Esquema
Os nomes qualificados so desagradveis de escrever, sendo geralmente melhor no ligar o aplicativo a um esquema
especfico. Por isso, geralmente as tabelas so referenciadas por meio de nomes no qualificados, formados apenas pelo
nome da tabela. O sistema determina que tabela est sendo referenciada seguindo o caminho de procura, que uma lista
de esquemas para procura. A primeira tabela correspondente encontrada no caminho de procura assumida como sendo
a desejada. No havendo nenhuma correspondncia no caminho de procura relatado um erro, mesmo que uma tabela
correspondendo ao nome exista em outro esquema no banco de dados.
O primeiro nome de esquema no caminho de procura chamado de esquema corrente. Alm de ser o primeiro esquema a
ser procurado, tambm o esquema onde as novas tabelas so criadas quando o comando CREATE TABLE no especifica
o nome do esquema.
A sintaxe para mostrar o caminho de procura corrente :
SHOW search_path
O retorno obtido pelo comando, na situao padro :
a) Search path
b) $user,public
O primeiro elemento especifica que deve ser procurado o esquema com o mesmo nome do usurio corrente. Se esse
esquema no existir, essa entrada ser ignorada. O segundo elemento se refere ao esquema pblico visto anteriormente.
O primeiro esquema existente do caminho de procura o local padro para a criao dos novos objetos. Essa a razo
pela qual, por padro, os objetos so criados no esquema pblico. Quando os objetos so referenciados em qualquer outro
contexto sem qualificao pelo esquema (comandos de modificao de tabelas, modificao de dados ou consultas) o
caminho de procura percorrido at que o objeto correspondente seja encontrado. Portanto, na configurao padro,
qualquer acesso no qualificado somente pode fazer referncia ao esquema pblico.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
72
4.4. Esquemas e Privilgios
Por padro, os usurios no podem acessar objetos em esquemas que no so seus. Para poderem acess-los, o dono
do esquema precisa conceder o privilgio USAGE para o esquema. Para permitir os usurios utilizarem os objetos do
esquema necessrio conceder privilgios adicionais, conforme seja apropriado para cada objeto.
Pode ser permitido, tambm, que um usurio crie objetos no esquema de outro usurio. Para permitir que isso seja feito,
deve ser concedido o privilgio CREATE para o esquema. Deve ser observado que, por padro, todos os usurios possuem
o privilgio CREATE e USAGE para o esquema public. Isso permite a todos os usurios que podem se conectar ao banco
de dados criarem objetos no esquema public.
Se isso no for desejado, esse privilgio poder ser revogado, utilizando a seguinte sintaxe:
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
O primeiro public no comando acima o nome do esquema, enquanto o segundo public significa todos os usurios.
Na primeira ocorrncia um identificador, enquanto que na segunda ocorrncia uma palavra-chave; por isso, na primeira
vez est escrito em minsculas, enquanto que, na segunda vez, em maisculas.
4.5. O Esquema do Catlogo do Sistema
Alm do esquema public e dos esquemas criados pelos usurios, cada banco de dados inclui o esquema contendo as
tabelas do sistema e todos os tipos de dados, funes e operadores nativos (nome do esquema pode variar de acordo com
o SGBD). Esse catlogo sempre parte efetiva do caminho de procura. Se no for colocado explicitamente no caminho
de procura, ento ser procurado implicitamente antes dos esquemas do caminho de procura. Isso garante que os nomes
nativos sempre possam ser encontrados. Entretanto, possvel colocar explicitamente o nome do catlogo no final do
caminho de procura, se for desejado que os nomes definidos pelo usurio substituam os nomes nativos.
4.6. Modelos de Utilizao
Os esquemas podem ser utilizados para organizar os dados de vrias maneiras. Existem uns poucos modelos de utilizao
recomendados, facilmente suportados pela configurao padro:
Se no for criado nenhum esquema, ento todos os usurios acessaro o esquema pblico implicitamente,
simulando a situao onde os esquemas no esto disponveis. Essa configurao recomendada,
principalmente, quando existe no banco de dados apenas um usurio, ou alguns poucos usurios colaborativos.
Essa configurao tambm permite uma transio suave de uma situao sem esquemas.
Pode ser criado um esquema para cada usurio com o mesmo nome do usurio. Lembre-se que o caminho de
procura padro comea por $user, que resolvido como o nome do usurio. Portanto, se cada usurio possuir
um esquema separado, vo acessar seus prprios esquemas por padro.
Se essa configurao for utilizada, tambm poder ser revogado o acesso ao esquema pblico (ou mesmo
remov-lo), deixando os usurios totalmente restritos aos seus prprios esquemas.
Para instalar aplicaes compartilhadas (tabelas utilizadas por todos, funes adicionais fornecidas por
terceiros), essas devem ser colocadas em esquemas separados. Devem ser concedidos, tambm, os privilgios
necessrios para permitir o acesso pelos outros usurios. Os usurios podero, ento, fazer referncia a
esses objetos adicionais qualificando seus nomes com o nome do esquema, ou podero adicionar esquemas
ao caminho de procura, conforme julgarem melhor.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
73
4.7. Portabilidade
No padro SQL, no existe a noo de objetos no mesmo esquema pertencendo a usurios diferentes. Alm disso, algumas
implementaes no permitem criar esquemas com nome diferente do nome de seu dono. Na verdade, os conceitos de
esquema e de usurio so praticamente equivalentes em sistemas de banco de dados que implementam somente o suporte
bsico a esquemas especificado no padro. Portanto, muitos usurios consideram os nomes qualificados na verdade
formados por nome_do_usurio.nome_da_tabela.
Obviamente, alguns sistemas de banco de dados SQL podem no implementar esquemas de nenhuma maneira, ou oferecer
suporte a espaos de nomes, permitindo apenas acesso entre bancos de dados. Se for necessrio trabalhar com esses
sistemas, ser obtido o mximo de portabilidade, no utilizando nada relacionado a esquemas.
5. Consultas em SQL
Uma consulta expressa em uma linguagem de consulta de alto nvel, como a SQL, deve primeiramente ser examinada,
analisada e validada. O examinador identifica os smbolos da linguagem como por exemplo palavras chaves da SQL,
nomes de atributos e nomes de relaes no texto de consulta, enquanto o analisador verifica a sintaxe de consulta para
determinar se ela est formulada de acordo com as regras de sintaxe (regras de gramtica) da linguagem de consulta.
Alm disso, a consulta tambm deve ser validada, verificando se todos os nomes de atributos e relaes so vlidos e
semanticamente significativos no esquema do banco de dados especfico que est sendo consultado. Uma representao
interna da consulta , ento, criada, geralmente em forma de uma estrutura de dados de rvore
1
, denominada rvore de
consulta. Tambm possvel representar a consulta utilizando-se de uma estrutura grfica de dados denominada grfico
de consulta. O SGBD deve ento planejar uma estratgia de execuo para recuperar o resultado da consulta, a partir dos
arquivos de banco de dados. Uma consulta geralmente tem muitas estratgias de execuo e o processamento utilizado
para escolher uma estratgia que seja adequada para processar uma consulta conhecido como otimizao de consulta
5.1. O comando SELECT
O comando select permite a seleo de tuplas e atributos em uma ou mais tabelas. A sintaxe bsica para o uso do
comando select :
SELECT [atributo] { * | tabela.* | [tabela.]campo1 [AS alias1] [, [tabela.]campo2 [AS alias2] [, ...]]}
FROM expressodetabela [, ...] [IN bancodedadosexterno]
[WHERE... ]
[GROUP BY... ]
[HAVING... ]
[ORDER BY... ]
[WITH OWNERACCESS OPTION]
1 rvore uma estrutura de dados que herda as caractersticas das topologias em rvore. Conceitualmente difere das listas encadeadas, em que os dados se encontram numa
sequncia, pelo fato dos dados estarem dispostos de forma hierrquica.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
74
Tabela 6.7. Elementos do Comando SELECT
Parte Descrio
Atributo
Um dos atributos a seguir: ALL, DISTINCT, DISTINCTROW ou TOP. Voc utiliza
o atributo para restringir o nmero de registros retornados. Se nenhum for
especificado, o padro ser ALL.
*
Especifica que todos os campos da tabela ou tabelas especificadas esto
selecionados.
tabela
O nomde da tabela contendo os campos a partir dos quais os registros so
selecionados.
campo1, campo2
Os nomes dos campos contendo os dados que voc deseja recuperar. Se voc
incluir mais de um campo, eles sero recuperados na ordem listada.
alias1, alias2
Os nomes a serem utilizados como cabealhos de coluna em lugar dos nomes
originais de coluna em tabela.
expressodetabela O nome da tabela ou tabelas contendo os dados que voc deseja recuperar.
bancodedadosexternos
O nome do banco de dados que contm as tabelas em expresso de tabela se elas
no estiverem no banco de dados atual.
Por exemplo, suponhamos que estamos trabalhando com um banco de dados onde existe o cadastro de pessoal de uma
empresa. Nesse caso, para selecionar o nome e o RG dos funcionrios que trabalham no departamento nmero 2, na
tabela EMPREGADOS utilizamos o seguinte comando:
SELECT nome, rg
FROM EMPREGADOS
WHERE depto = 2;
O resultado obtido com a consulta, ento, o seguinte:
Nome RG
Fernando 20202020
Ricardo 30303030
Jorge 40404040
Na linguagem em SQL tambm permitido o uso de condies mltiplas, conforme o seguinte exemplo:
SELECT nome, rg, salario
FROM EMPREGADOS
WHERE depto = 2 AND salario > 2500.00;
Nome RG Salrio
Jorge 40404040 4.200,00
A instruo que envolver as clusulas SELECT-FROM-WHERE em SQL permite envolver quantas tabelas forem necessrias.
Tomemos como exemplo a situao em que desejamos selecionar o nmero do departamento que controla projetos
localizados em Braslia. Para tanto, podemos utilizar o seguinte comando:
SELECT t1.numero_depto
FROM departamento_projeto t1, projeto t2
WHERE t1.numero_projeto = t2.numero;
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
75
Na expresso anterior, t1 e t2 so chamados alias (apelidos) e representam a mesma tabela a qual esto referenciando.
Um alias muito importante quando h redundncia nos nomes das colunas de duas ou mais tabelas que esto envolvidas
em uma expresso. Ao invs de utilizar o alias, tambm possvel utilizar o nome da tabela, mas isso pode se tornar
muito trabalhoso em consultas muito complexas, alm do que impossibilitaria a utilizao da mesma tabela mais que
uma vez em uma expresso SQL.
Suponhamos que desejamos selecionar o nome e o RG de todos os funcionrios que so supervisores. Para tanto, podemos
utilizar o seguinte comando:
SELECT e1.nome, e1.rg
FROM empregado e1, empregado e2
WHERE e1.rg = e2.rg_supervisor;
Nome RG
Joo Luiz 10101010
Fernando 20202020
A utilizao do operador * dentro do especificador SELECT permite selecionar todos os atributos de uma tabela, enquanto
que a excluso do especificador WHERE faz com que todas as tuplas de uma tabela sejam selecionadas. Vejamos o
comando apresentado a seguir:
SELECT *
FROM empregados;
O resultado obtido com a consulta, ento, :
Nome RG CPF Depto. RG Supervisor Salrio
Joo Luiz 10101010 11111111 1 NULO 3.000,00
Fernando 20202020 22222222 2 10101010 2.500,00
Ricardo 30303030 33333333 2 10101010 2.300,00
Jorge 40404040 44444444 2 20202020 4.200,00
Renato 50505050 55555555 3 20202020 1.300,00
Um ponto importante a considerar que a operao SELECT em SQL permite a gerao de tuplas duplicadas como resultado
de uma expresso. Para evitar isto, necessrio utilizar o especificador DISTINCT. Suponhamos o seguinte exemplo:
SELECT depto FROM empregado;
Depto.
1
2
2
2
3
No entanto, veja o mesmo exemplo com o especificador DISTINCT.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
76
SELECT DISTINCT depto FROM empregado;
Depto.
1
2
3
Outra possibilidade da linguagem SQL a gerao de consultas aninhadas utilizando o especificador IN, que permite
que seja feita uma comparao do especificador WHERE da consulta mais externa com o resultado da consulta mais
interna. Suponhamos que desejamos selecionar o nome de todos os funcionrios que trabalham em projetos localizados
em Braslia. O comando a ser utilizado ser:
SELECT e1.nome, e1.rg, e1.depto FROM empregado e1, empregado_projeto e2 WHERE e1.rg = e2.rg_empregado
AND e2.numero_projeto IN (select numero FROM projeto WHERE localizacao = Braslia);
Caso seja necessrio selecionar um conjunto de tuplas de forma ordenada devemos utilizar o comando ORDER BY.
Suponhamos que desejamos selecionar todos os empregados por ordem alfabtica. O comando a ser utilizado ser:
SELECT nome, rg, depto
FROM empregado
ORDER BY nome;
6. Comandos INSERT, DELETE e UPDATE em SQL
6.1. O comando INSERT
O comando INSERT objetiva inserir novas linhas na tabela. Podem ser inseridas uma ou mais linhas especificadas por
expresses de valor, ou zero ou mais linhas resultantes de uma consulta.
Os nomes das colunas de destino podem ser listados em qualquer ordem sendo que quando no fornecida nenhuma lista
de nomes de colunas, o padro usar todas as colunas da tabela na ordem em que foram declaradas; ou os primeiros N
nomes de colunas, se existirem apenas N colunas fornecidas na clusula VALUES ou na consulta. Os valores fornecidos
pela clusula VALUES ou pela consulta so associados lista de colunas explcita ou implcita da esquerda para a direita.
As colunas que no esto presentes na lista de colunas explcita ou implcita so preenchidas com o valor padro, seja
o valor padro declarado ou nulo se no houver nenhum.
Se a expresso para alguma coluna no for do tipo de dado correto, ser tentada uma converso de tipo automtica.
A clusula opcional RETURNING faz com que o comando INSERT compute e retorne valores baseados em cada linha
realmente inserida. Sua utilidade principal obter valores fornecidos por padro, como o nmero sequencial de uma
coluna serial. Entretanto, permitida qualquer expresso que utilize as colunas da tabela. A sintaxe da lista RETURNING
idntica da lista de sada do comando SELECT. Alm disso, necessrio possuir o privilgio INSERT na tabela para
poder inserir linhas, e o privilgio SELECT para utilizar RETURNING. Se for utilizada a clusula consulta para inserir linhas
a partir de uma consulta, tambm ser necessrio possuir o privilgio SELECT em todas as tabelas usadas pela consulta.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
77
A sintaxe geral para o comando INSERT INTO :
INSERT INTO destino [IN bancodedadosexterno] [(campo1[, campo2[, ...]])] SELECT [origem.]campo1[, campo2[, ...]
FROM expressodetabela
Suponhamos que desejamos inserir os seguintes dados:
nome: Jorge Gonalves
rg: 60606060
cic: 66666666
departamento: 3
rg_supervisor: 20202020
salrio: R$ 4.000,00
O comando a ser utilizado ser:
INSERT INTO empregados
VALUES (Jorge Goncalves, 60606060, 66666666, 3, 20202020, 4000,00);
Como nesse exemplo, todos os campos foram inseridos, no necessrio especificar o nome das colunas na sintaxe.
Suponhamos que desejamos agora inserir os seguintes dados:
nome: Joao de Campos
rg: 70707070
cic: 77777777
departamento: 3
salrio: R$2.500,00
INSERT INTO empregados (nome, rg, cic, depto, salario)
VALUES (Joao de Campos, 70707070, 77777777, 3, 2500,00);
Tabela 6.8. Elementos do Comando INSERT
Parte Descrio
destino O nome da tabela ou consulta qual acrescentar os registros.
bancodedadosexterno0
O caminho at um banco de dados externo. Para obter uma descrio do caminho,
consulte a clusula IN.
origem O nome da tabela ou consulta a partir da qual os registros vo ser copiados.
campo1, campo2
Nomes do campos aos quais os dados sero acrecentados, se se seguirem a um
argumento destino, ou os nomes dos campos a partir dos quais os dados sero
obtidos, se se seguirem a um argumento origem.
Expressodetabela
O nome da tabela ou das tabelas das quais os registros so inseridos. Esse
argumento pode ser um nome de tabela simples ou um composto resultante de
uma operao INNER JOIN, LEFT JOIN ou RIGHT JOIN ou uma consulta salva.
valor1, valor2
Os valores a serem inseridos nos campos especficos do novo registro. Cada valor
inserido no campo que corresponde posio do valor na lista: valor1 inserido
no campo1 do novo registro, valor 2 no campo2, e assim por diante. Voc deve
separar os valores com uma vrgula e colocar os campos de texto entre aspas ( )
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
78
Nesse exemplo, como o campo rg_supervisor no foi inserido, foi necessrio especificar as colunas que deveriam receber
dados. Outra forma de se elaborar essa insero seria:
INSERT INTO empregados
VALUES (Joao de Campos, 70707070, 77777777, 3, , 2500,00);
Nessa situao utilizaram-se os caracteres para se declarar que um valor nulo seria inserido nesta coluna, o que dispensa
a necessidade e se especificar as colunas.
6.2. O comando UPDATE
A modificao dos dados armazenados no banco de dados referida como atualizao. Pode ser atualizada uma linha da
tabela, todas as linhas da tabela, ou um subconjunto das linhas. Cada coluna pode ser atualizada individualmente, no
afetando as outras colunas.
A sintaxe geral para o comando UPDATE :
UPDATE tabela SET novovalor WHERE critrios
Tabela 6.9. Elementos do Comando UPDATE.
Parte Descrio
tabela O nome da tabela contendo os dados que voc quer modificar.
Novovalor
Uma expresso que determina o valor a ser inserido em um campo especfico dos
registros atualizados.
critrios
Uma expresso que determina quais registros sero atualizados. Apenas os
registros que satisfazem expresso so atualizados.
Suponhamos que desejamos agora atualizar os dados relativos ao salrio de todos os empregados que trabalham no
departamento 2 para R$ 3.000,00. O comando a ser utilizado ser:
UPDATE empregado SET salario = 3.000,00 WHERE depto = 2;
Caso a clusula WHERE seja omitida, todas as linhas da tabela sero atualizadas. Quando est presente, apenas as
linhas atendendo a condio escrita aps o WHERE sero atualizadas. Observe que o sinal de igual na clusula SET
uma atribuio, enquanto o sinal de igual na clusula WHERE uma comparao, mas isto no causa ambiguidade
Dica 1: O comando UPDATE no gera um conjunto de resultados. Alm disso, depois de atualizar os registros
usando uma consulta de atualizao, voc no poder desfazer a operao. Se quiser saber quais os registros
que foram atualizados, examine antes os resultados de uma consulta seleo que usem os mesmos critrios e,
depois, execute a consulta de atualizao. Mantenha sempre cpias de backup dos dados. Se voc atualizar
os registros errados, poder recuper-los a partir das cpias.
6.3. O comando DELETE
O comando DELETE permite que seja excluda uma ou mais linhas de uma tabela. Assim como s possvel adicionar
dados para toda uma linha, tambm uma linha s pode ser removida por completo de uma tabela. Se for necessrio excluir
valores de um campo especfico, basta criar uma consulta atualizao que altere os valores para Null.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
79
A linguagem SQL no oferece funcionalidade para enderear diretamente linhas especficas. Portanto, a remoo de linhas
s pode ser feita por meio da especificao das condies que as linhas a serem removidas devem atender. Referenciando
uma chave primria na tabela, ento, possvel especificar exatamente a linha. Porm, tambm pode ser removido um
grupo de linhas, atendendo a uma determinada condio, ou podem ser removidas todas as linhas da tabela de uma s vez.
A sintaxe geral para o comando DELETE :
DELETE [tabela.*] FROM tabela WHERE critrios
Tabela 6.10. Elementos do Comando DELETE
Parte Descrio
tabela.* O nome opcional da tabela da qual so excludos registros.
tabela O nome da tabela da qual so excludos registros.
Critrios Uma expresso que determina os registros a ser excludos
Suponhamos que desejamos agora excluir os dados relativos aos registros nos quais o empregado trabalhe no departamento
2 e possua salrio maior que R$ 3.500,00. O comando a ser utilizado ser:
DELETE FROM empregado WHERE salario > 3.500,00 AND depto = 2;
A funo DELETE especialmente til quando se deseja excluir muitos registros pois, para excluir uma tabela inteira do
banco de dados, possvel usar o mtodo Execute com uma instruo DROP, o que resulta na excluso dos dados e da
estrutura da tabela. Em contrapartida, ao utilizar o comando DELETE, somente os dados so excludos e a estrutura da
tabela e todas as suas propriedades, como atributos de campo e ndices, permanecem intactos.
possvel utilizar o comando DELETE para remover registros de tabelas que esto em um relacionamento um-paramuitos
com outras tabelas. As operaes de excluso em cascata fazem com que os registros em tabelas que esto no lado
muitos do relacionamento sejam excludos quando o registro correspondente no lado um do relacionamento excludo
na consulta.

Dica 1: Depois de remover os registros utilizando uma consulta excluso, voc no poder desfazer a operao.
Se quiser saber quais registros foram excludos, examine antes os resultados de uma consulta seleo que
use os mesmos critrios e, depois, execute a consulta excluso.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
81
Captulo 7 Dependncia Funcional e Normalizao
1. Dependncia Funcional
Dependncia Funcional diz respeito a uma restrio entre dois conjuntos de atributos de uma base de dados. Tambm
pode ser vista como um conjunto de restries ao conjunto de relaes vlidas. Suponha que o esquema de uma base
de dados R possua n atributos A
1
, A
2
,..., A
n
e considere que em R = { A
1
, A
2
, ... , A
n
} como a representao universal
da base de dados.
Uma dependncia funcional, representada por X Y entre dois conjuntos de atributos X e Y que so subconjuntos de R
especificam uma restrio nas tuplas que podem compor uma instncia relao r de R. A restrio estabelece que para
qualquer par de tuplas t
1
e t
2
em r de forma que t
1
.[X] = t
2
.[X], obrigado a existir t
1
.[Y] = t
2
.[Y]. Isto significa que os
valores do componente Y em uma tupla em r dependem de, ou so determinados pelos valores do componente X.
Para X Y l-se: Y funcionalmente dependente de X, ou X infere sobre Y.
Suponhamos o seguinte exemplo de dependncias funcionais:
a. RG { Nome, CPF, Depto., RG_Supervisor, Salrio}
b. Nmero_Projeto { Nome_Projeto, Localizao}
c. { RG_Empregado, Nmero_Projeto } Horas
A dependncia (a) implica que o nmero de um RG define de forma nica o nome do empregado e o seu CPF do empregado.
A dependncia (b) implica que o nmero do projeto define de forma nica o nome do projeto e sua localizao e a
dependncia (c) implica que o RG do empregado mais o nmero do projeto define de forma nica o nmero de horas
que o empregado trabalhou no projeto.
Em outras palavras, uma dependncia funcional pode ser vista como uma propriedade do significado ou semntica dos
atributos em um esquema de relao R. Utiliza-se o entendimento da semntica de atributos de R isto , como eles
se relacionam para especificar as dependncias funcionais envolvidas em todas as instncias da relao r (extenso)
de R. As instncias r que satisfazem as restries de dependncia funcional especificadas sobre atributos de R so
chamadas extenses legais, pois obedecem as restries de dependncia funcional. Assim, a principal utilizao das
dependncias funcionais a de descrever um esquema de relao R, especificando restries sobre seus atributos, que
devem ser vlidas todas as vezes.
A especificao das inferncias deve ser elaborada pelo projetista de banco de dados em conjunto com o analista de
sistemas, pois eles devero ter conhecimento da semntica da base de dados.
Unidade III
Teoria e Metodologia do Projeto de
Banco de Dados
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
82
Teoria e Metodologia do Projeto de Banco de Dados Unidade III
Analisando o conceito de dependncia funcional, podemos identificar algumas variaes.
a) Dependncia funcional total: Numa relao R, o atributo y funcionalmente dependente total de x (x,
y R), no caso de x ser um atributo composto, se, e apenas se, funcionalmente dependente de x e no
funcionalmente dependente de qualquer subconjunto dos atributos de x.
b) Dependncia funcional parcial: Uma dependncia funcional parcial uma dependncia funcional X Y
se existir um atributo A qualquer do componente X que pode ser removido e a dependncia funcional X
Y no deixa de existir.
c) Dependncia funcional transitria: Uma dependncia funcional R: x _ y transitria, se existe um
atributo z que no um subconjunto de x, tal que x _ z e z _ y.
d) Dependncia funcional multivalor: Uma dependncia multivalor s se verifica nos casos em que a relao
tem pelo menos 3 atributos _ Numa relao R, o atributo y tem uma dependncia funcional multivalor
relativamente a x (x, y R), se para cada par de tuplas de R contendo os mesmos valores de x, tambm
existe um par de tuplas de R correspondentes troca dos valores de y no par original.
1.1. Normalizao
O processo de normalizao pode ser visto como o processo no qual so eliminados esquemas de relaes (tabelas) no
satisfatrios, decompondo-os, por meio da separao de seus atributos em esquemas de relaes menos complexas, mas
que satisfaam as propriedades desejadas.
O processo de normalizao, proposto inicialmente por Codd (1972), conduz um esquema de relao por meio de conjunto
de testes para certificar se o ele est na 1
a
, 2
a
e 3
a
Formas Normais. Essas trs Formas Normais so baseadas em
dependncias funcionais dos atributos do esquema de relao.
1.1.1. Primeira Forma Normal
A 1
a
Forma Normal pressupe que todos os atributos de uma tabela devem ser atmicos, ou seja, no so permitidos
atributos multivalorados, atributos compostos ou atributos multivalorados compostos. Consideremos o seguinte exemplo:
CLIENTE
1. Cdigo
2. {Telefone}
3. Endereo: (Rua, Nmero, Cidade)
A Tabela 7.1 apresenta uma estrutura para armazenar os dados do exemplo.
Tabela 7.1. Representao da tabela Cliente
Cliente Cdigo
Telefone 1 Endereo
Telefone n Rua N
o
Cidade
Considerando os pressupostos da 1
a
Forma Normal, necessrio reestruturar a Tabela 7.1, pois seus atributos no so
atmicos. Para que a Tabela 7.1 atenda aos pressupostos da 1a Forma Normal temos que eliminar os atributos no
atmicos. O resultado a gerao das Tabelas 7.1a e 7.1b.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
83
Tabela 7.1a. Representao da tabela Cliente normalizada (1 FN)
Cliente Cdigo Rua No Cidade
Tabela 7.1b. Representao da tabela Cliente normalizada (1 FN)
Cliente_Telefone Cdigo_Cliente Telefone_Cliente
1.1.2. Segunda Forma Normal
A 2 Forma Normal baseia-se no conceito da dependncia funcional total. Conforme mencionamos anteriormente,
uma dependncia funcional X Y total se removemos um atributo A qualquer do componente X e, desta forma, a
dependncia funcional deixa de existir.
Tomemos como exemplo, a dependncia funcional (c) mencionada no item 7.1.
(c) {RG_Empregado, Nmero_Projeto} Horas
Podemos dizer que se trata de uma dependncia funcional total, pois se removermos o atributo RG_Empregado ou o
atributo Nmero_Projeto, a dependncia funcional deixa de existir.
Desse modo, podemos dizer que uma tabela T atende 2 Forma Normal se estiver na 1 Forma Normal e todo atributo que
no compem a chave primria C for em sua totalidade funcionalmente dependente da chave primria C. Se uma tabela
no est na 2 Forma Normal, ela pode ser normalizada gerando outras tabelas cujos atributos que no faam parte da
chave primria sejam funcionalmente dependentes dela em sua totalidade, passando, assim, a assumir a 2 Forma Normal.
1.1.3. Terceira Forma Normal
A 3 Forma Normal, por sua vez, baseia-se no conceito de dependncia transitria. Como apresentado anteriormente,
uma dependncia funcional transitria e uma dependncia funcional X Y em uma tabela T se existir um conjunto de
atributos Z que no um subconjunto de chaves de T e as dependncias X Z, Z Y, so vlidas.
Consideremos o seguinte exemplo:
Tabela 7.2a. Representao da Tabela Empregado
Empregado RG Nome No_Departamento Nome_Depto RG_Ger_Depto
Analisando a Tabela 7.2a, temos a seguinte dependncia transitiva:
a. RG {Nome_Depto, RG_Ger_Depto}
b. RG No_Departamento
c. No_Departamento {Nome_Depto, RG_Ger_Depto}
Analisando a Tabela 7.2a, temos a seguinte dependncia transitiva:
Tabela 7.2b. Representao da Tabela Empregado
Empregado RG CPF Nome No_Funcional
d. RG {Nome, No_Funcional}
e. RG CPF
f. CIC {Nome, No_Funcional}
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
84
Conforme pode ser visto na Tabela 7.2b, o CPF, por ser naturalmente um identificador do empregado, pode ser encarado
como uma chave-candidata.
Uma tabela est na 3
a
Forma Normal se estiver na 2
a
Forma Normal e no houver dependncia transitiva entre atributos
no chave.
2. A lgebra Relacional
A lgebra Relacional uma coleo de operaes cannicas que so utilizadas para manipular as relaes. Segundo
Silberschatz (2006), a lgebra Relacional um conjunto de operadores que tomam relaes como seus operandos e
retorna uma relao como seu resultado.
Essas operaes so utilizadas para selecionar tuplas de relaes individuais e para combinar tuplas relacionadas de
relaes diferentes para especificar uma consulta em um determinado banco de dados. O resultado de cada operao
uma nova operao, a qual tambm pode ser manipulada pela lgebra relacional.
Algumas aplicaes da lgebra relacional so:
Definir um escopo para busca.
Definir um escopo para atualizao (dados inseridos, alterados ou eliminados).
Definir restries de integridade (definir restrio ao qual o BD dever obedecer).
Definir variveis de relaes derivadas (vises e snapshots).
Definir requisitos de segurana (definir os dados sobre os quais ser concedida alguma espcie de autorizao).
2.1. A Operao SELECT
A operao SELECT utilizada para selecionar um subconjunto de tuplas de uma relao, sendo que essas tuplas devem
satisfazer uma condio de seleo. A forma geral de uma operao SELECT :
c
<condio de seleo>

( <nome da relao> )
A letra grega c utilizada para representar a operao de seleo; <condio de seleo> uma expresso booleana
aplicada sobre os atributos da relao e <nome da relao> o nome da relao sobre a qual ser aplicada a
operao SELECT.
Exemplificando, tomemos a seguinte expresso:
Consulta
1
= c
salrio < 2.500,00
(EMPREGADO)
A partir da expresso da consulta
1
, teremos os seguintes resultados:
Tabela 7.3. Tabela com resultados da Consulta
1
Nome RG CIC Depto. RG Supervisor Salrio
Ricardo 30303030 33333333 2 10101010 2.300,00
Renato 50505050 55555555 3 20202020 1.300,00
Tomemos agora a expresso:
Consulta
2
= c
(relao = Filho) .AND. (sexo = Feminino)

(DEPENDENTES)
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
85
2
2
RG Responsvel Nome Dependente Dt. Nascimento Relao Sexo
30303030 Adreia 01/05/90 Filho Feminino
Os operadores relacionais que podem ser aplicadas na operao SELECT so: <, >, , , =, = alm dos operadores
booleanos: and, or, not.
A operao select unria, ou seja, s pode ser aplicada a uma nica relao. No possvel aplicar a operao sobre
tuplas de relaes distintas.
2.2. A Operao PROJECT
A operao PROJECT seleciona um conjunto determinado de colunas de uma relao. A forma geral de uma operao
PROJECT :

<lista de atributos>
(<nome da relao>)
A letra grega representa a operao PROJECT, <lista de atributos> representa a lista de atributos que o usurio
deseja selecionar e <nome da relao> representa a relao sobre a qual a operao PROJECT ser aplicada.
Consulta
3
=
Nome, Dt. Nascimento

(DEPENDENTES)
3,
teremos os seguintes resultados:
3
Nome Dependente Dt. Nascimento
Jorge 27/12/86
Luiz 18/11/79
Fernanda 14/02/69
Angelo 10/02/95
Adreia 01/05/90
2.3. Seqencialidade de Operaes
As operaes PROJECT e SELECT podem ser utilizadas de forma combinada, permitindo que apenas determinadas
colunas de determinadas tuplas possam ser selecionadas.
A forma geral de uma operao sequencializada :
<lista de atributos>
(c
<condio de seleo>

(<nome da relao>)
)
Consulta
4
=
nome, depto., salario
(c
salario < 2.500,00
(EMPREGADO)
)
A partir da expresso da Consulta
4,
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
86
4
Nome Depto. Salrio
Ricardo 2 2.300,00
Renato 3 1.300,00
Por outro lado, a Consulta
4
pode ser reescrita em duas outras expresses.
a) Consulta
5
= c
salario < 2.500,00
(EMPREGADO)
5
Tabela 7.7a. Tabela com resultados da Consulta
5
Ricardo 30303030 33333333 2 10101010 2.300,00
Renato 50505050 55555555 3 20202020 1.300,00
b) Consulta
6
=
nome, depto., salario
(CONSULTA
5
)
6,
Tabela 7.7b. Tabela com resultados da Consulta
6
Nome Depto. Salrio
Ricardo 2 2.300,00
Renato 3 1.300,00
Como pode ser visto nas Tabelas 7.7a e 7.7b, o resultado das consultas acaba sendo o mesmo, porm mais simples
utilizar a forma descrita na Consulta
4
.
2.4. Operaes Matemticas
Levando em considerao que as relaes podem ser tratadas como conjuntos, podemos ento aplicar um conjunto de
operaes matemticas sobre elas. Essas operaes so: unio (L) , interseco () e diferena (-).
Esse conjunto de operaes no unrio, ou seja, pode ser aplicado sobre mais de uma tabela, porm, existe a necessidade
de as tabelas possurem tuplas exatamente do mesmo tipo.
Essas operaes apresentam as seguintes caractersticas.
Unio operao representada por R L S, tem como resultado: uma relao T, que inclui todas as tuplas
que se encontram em R e todas as tuplas que se encontram em S.
Interseco operao representada por R S, tem como resultado uma relao T, que inclui as tuplas
que se encontram em R e em S ao mesmo tempo.
Diferena operao representada por R - S, tem como resultado uma relao T, que inclui todas as tuplas
que esto em R, mas no esto em S.
Suponhamos que uma consulta deseja selecionar todos os empregados que trabalham no departamento nmero 2 ou que
supervisionam empregados que trabalham no departamento nmero 2.
Em primeiro lugar, vamos primeiro selecionar todos os funcionrios que trabalham no departamento nmero 2. Para
tanto, utilizaremos a seguinte expresso:
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
87
Consulta
7
= c
depto = 2
(EMPREGADOS)
7,
Tabela 7.8a. Tabela com resultados da Consulta
7
Fernando 20202020 22222222 2 10101010 2.500,00
Ricardo 30303030 33333333 2 10101010 2.300,00
Jorge 40404040 44444444 2 20202020 4.200,00
Em seguida, selecionaremos os supervisores dos empregados que trabalham no departamento nmero 2, utilizando a
seguinte expresso:
Consulta
8
=
rg_supervisor

(CONSULTA
7
)
8
Tabela 7.8b. Tabela com resultados da Consulta
8
RG Supervisor
10101010
20202020
Com base na Consulta
7
, vamos buscar apenas o rg dos empregados selecionados, com base na seguinte expresso:
Consulta
9
=
rg
(CONSULTA
7
)
9
Tabela 7.8c. Tabela com resultados da Consulta
9
RG
20202020
30303030
40404040
Por fim, necessitamos unir as Tabelas 7.8b e 7.8c, obtendo o resultado final.
Consulta
10
= CONSULTA
8
L CONSULTA
9
10
Tabela 7.8d. Tabela com resultados da Consulta
10
RG
20202020
30303030
40404040
10101010
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
88
2.5. Produto Cartesiano
O produto cartesiano uma operao binria que combina todas as tuplas de duas tabelas. Diferente da operao unio,
o produto cartesiano no exige que as tuplas das tabelas possuam exatamente o mesmo tipo. O produto cartesiano
permite ento a consulta entre tabelas relacionadas utilizando uma condio de seleo apropriada. O resultado de um
produto cartesiano uma nova tabela formada pela combinao das tuplas das tabelas sobre as quais se aplicou a
operao.
O formato geral do produto cartesiano entre duas tabelas R e S : R X S
Suponhamos que uma consulta deseja encontrar todos os funcionrios que desenvolvem projetos em Braslia. Para tanto,
utilizaremos a seguinte expresso:
Consulta
11
= EMPREGADO/PROJETO X PROJETO
11
Tabela 7.9a. Tabela com Resultados da Consulta
11
RG Empregado Nmero Projeto Nome Nmero Localizao
20202020 5 Financeiro 1 5 So Paulo
20202020 5 Motor 3 10 Rio Claro
20202020 5 Prdio Central 20 Campinas
40404040 20 Prdio Central 20 Braslia
Em seguida, necessitamos selecionar as tuplas resultantes que esto devidamente relacionadas, que so as que possuem o
mesmo valor em nmero do projeto e nmero e cuja localizao seja Braslia. Para tanto, utilizaremos a seguinte expresso:
Consulta
12
=
rg_empregado, nmero
(c
(nmero_projeto = nmero) .and. (localizao = Braslia)
(CONSULTA11))
12
Tabela 7.9b. Tabela com Resultados da Consulta
12
RG Nmero
40404040 20
50505050 20
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
89
2.6. Operao Juno
A operao juno atua de forma similar operao produto cartesiano, porm, a tabela resultante conter apenas
as combinaes das tuplas que se relacionam de acordo com uma determinada condio de juno. A forma geral da
operao juno entre duas tabelas R e S a seguinte:
R
<condio de juno>
S
Suponhamos que uma consulta deseja encontrar todos os funcionrios que desenvolvem projetos em Braslia. Para tanto,
utilizaremos a seguinte expresso:
Consulta
13
= EMPREGADOS/PROJETOS
nmero_projeto = nmero
PROJETOS
13
Tabela 7.10a. Tabela com Resultados da Consulta
13
RG_Empregado Nmero_Projeto Nome Nmero Localizao
Para finalizar o processo, necessitamos selecionar as tuplas onde a localizao seja igual a Braslia.
Consulta
14
= c
localizao = Braslia
(CONSULTA
13
)
14
Tabela 7.10b. Tabela com Resultados da Consulta
14
RG_Empregado Nmero_Projeto Nome Nmero Localizao
Conforme pode ser visto a partir da comparao dos resultados das Tabelas 7.9b e 7.10b, a operao de juno e o
produto cartesiano fornecem o mesmo resultado, porm a operao juno permite que o processamento seja mais simples.
3. Forma Normal de Boyce-Codd
A forma normal de Boyce-Codd (FNBC) foi proposta como uma forma mais simples que a 3 FN, mas foi considerada mais
restrita na medida em que toda relao que est na FNBC tambm est na 3 FN, entretanto, o inverso no verdadeiro.
A definio formal da FNBC difere ligeiramente da definio da 3 FN. Um esquema da relao R est na FNBC se,
sempre, uma dependncia funcional no-trivial
1
X A se mantiver em R, X for uma superchave de R. A condio b
da 3 FN est ausente. De forma esquemtica, podemos representar a FNBC como (Figura 7.1):
Figura 7.1. Representao esquemtica da FNBC
Uma relao R est em BCNF se:
Para todas as DFs de R no triviais X Y.
X for superchave de R.
(Basta existir uma DF em que X no seja superchave, para R no estar em
BCNF. Se isso acontecer, diz-se que essa DF viola a condio de BCNF)
1 o tipo de dependncia que indica que um determinante identifica outro atributo qualquer.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
90
Consideremos o seguinte exemplo:
Tabela 7.11. Representao da tabela Empregado
Empregado RG Nome CodDepartamento Nome_Depto RG_Ger_Depto
Como possvel perceber, na Tabela 7.11 temos as seguintes dependncias funcionais:
a. RG {Nome_Depto, RG_Ger_Depto}
b. RG CodDepartamento
c. CodDepartamento {Nome_Depto, RG_Ger_Depto}
Analisando a Tabela 7.11, sob a tica das regras da FNBC, possvel perceber que a tabela em anlise no atende a
todos os requisitos que a regra define, pois a chave RG no uma superchave da tabela Empregado.
Figura 7.2. Representao esquemtica da regra para normalizao FNBC
A idia usar uma DF X Y que viole a condio de BCNF.
Calcula-se X
+
.
No d todos os atributos, caso contrrio X seria superchave.
Decompe-se R em duas relaes, R
1
e R
2
, com os seguintes esquemas:
1. R
1
R
+
2. R
2
X L (atrib(R) (X
+
))
Para transformarmos a Tabela 7.11 na FNBC necessrio decompor a tabela em esquemas menores.
Tabela 7.12a. Representao da tabela Empregado
Empregado RG Nome
Tabela 7.12b. Representao da tabela Departamento
Departamento CodDepartamento Nome_Depto RG
Tabela 7.12c. Representao da tabela Gestores
Gerentes RG Nome CodDepartamento
Analisando as dependncias funcionais das Tabelas 7.12a, 7.12b e 7.12c, temos:
a. RG {Nome}
b. RG {CodDepartamento, Nome_Depto}
c. RG {Nome, CodDepartamento}
Como pode ser visto nas apresentadas, como RG passou a ser uma superchave, podemos dizer que as relaes agora
atendem aos pressupostos da FNBC.
Diz-se que uma decomposio de R em R
1
e R
2
sem perda (Lossless join) quando, ao juntarmos as tuplas de R
1
com as
tuplas de R2 (igualando os atributos com o mesmo nome), obtivermos exatamente as tuplas de R.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
91
4. 4 e 5 Formas Normais
Alm das formas funcionais descritas, existem outras que representam um refinamento das formas anteriores.
4.1. 4 Forma Normal
Uma relao R est na quarta forma normal (4FN) se est na FNBC e para qualquer dependncia multivalor no trivial
X Y, X uma superchave.
4.2. 5 Forma Normal
Uma relao R est na quinta forma normal (5FN) se est na 4FN e no tem nenhuma dependncia de juno. Uma
dependncia de juno a situao onde uma relao R e certas projees R
1
, . . . ,R
n
, diz-se que h uma dependncia
de juno (de R em relao a R
1
, . . . ,R
n
) se R pode ser reconstituda como a juno de R
1
, . . . ,R
n
.
Apesar do refinamento que apresentam, as formas funcionais mais especializadas que a FNBC costumam ser raramente
utilizadas pois, alm da dificuldade de aplicao, podem redundar em reduo de performance. A Figura 7.3 mostra uma
representao esquemtica das formas de normalizao.
Figura 7.3. Representao esquemtica do processo de normalizao
5
a
FN
4
a
FN
Boyce-Codd
3
a
FN
2
a
FN
1
a
FN
1
a
FN Todos atributos assumem valores
atmicos ou elementares.
2
a
FN Estar na 1
a
FN e todos os
atributos que no participam da chave
so dependentes funcionalmente de toda a
chave e no de parte dela.
3
a
FN Estar na 2
a
FN cada atributo no
chave depende diretamente da chave, no
havendo dependncia transitiva.
FNBC Estar na 3
a
FN e uma dependncia
funcional no-trivial X A se mantiver
em R, X for uma Superchave de R.
4
a
FN Estar na FNBC e no apresentar
dependncia multivalor.
5
a
FN Estar na 4
a
FN e no apresentar
dependncia de juno.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
92
Captulo 8 Metodologia para Projeto Prtico de Banco de Dados
1. Aspectos Relevantes a serem Considerados
Atualmente, devem-se considerar alguns aspectos relevantes para atingir a eficincia e a eficcia dos sistemas
informatizados desenvolvidos, a fim de atender seus usurios nos mais variados domnios de aplicao.
Entre os mais relevantes, podemos destacar:
a. Os projetos Lgico e Funcional do Banco de Dados devem ser capazes de prever o volume de informaes
armazenadas a curto, mdio e longo prazo. Os projetos devem ter uma grande capacidade de adaptao
para os trs casos mencionados.
b. Deve-se ter generalidade e alto grau de abstrao de dados, possibilitando confiabilidade e eficincia no
seu armazenamento e permitindo a utilizao de diferentes tipos de gerenciadores de dados por meio
de linguagens de consultas padronizadas.
c. Deve-se ter projeto com uma interface gil e com uma rampa ascendente para propiciar aprendizado
suave ao usurio, no intuito de minimizar o esforo cognitivo;
d. Implementao de um projeto de interface compatvel com mltiplas plataformas (UNIX, Windows NT,
Windows Workgroup).
e. Independncia de Implementao da Interface em relao aos SGBDs que daro condies s operaes
de armazenamento de informaes (ORACLE, SYSBASE, INFORMIX, PADRO XBASE).
f. Converso e mapeamento da diferena semntica entre os paradigmas utilizados no desenvolvimento
de interfaces (Imperativo (ou procedural), Orientado a Objeto, Orientado a evento), servidores de dados
(Relacional) e programao dos aplicativos (Imperativo, Orientado a Objetos).
2. Ambiente de Desenvolvimento de Aplicativos
A Figura 8.1 ilustra um ambiente genrico de desenvolvimento de aplicativos. Nessa Figura, a diferena (gap semntico)
entre os paradigmas utilizados para a construo de interfaces, o armazenamento de informaes, e a programao dos
aplicativos so detalhados para ressaltar a importncia de estruturas Case e Cursores. As estruturas Case so
utilizadas para converter as alteraes e solicitaes ocorridas na interface do aplicativo em uma linguagem que seja
capaz de ser processada pelos servidores de dados. A construo da linguagem feita por intermdio da composio de
cadeias de caracteres, usualmente utilizando o padro SQL empregado nos servidores de dados relacionais. Quando um
acesso ao SGBD requerido, o programa estabelece uma conexo com o SGBD que est instalado no servidor.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
93
Figura 8.1. Representao de um ambiente genrico de desenvolvimento de aplicativos
Uma vez que a conexo criada, o programa cliente pode se comunicar com o SGBD. Um padro chamado de Conectividade
Base de Dados Aberta (Open DataBase Connectivity ODBC) prov uma Interface para Programao de Aplicaes
(API), que permite que os programas no lado cliente possam chamar o SGBD, desde que as mquinas clientes, como
o servidor, tenham o necessrio software instalado. Muitos vendedores de SGBDs disponibilizam drivers especficos
para seus sistemas. Dessa maneira, um programa cliente pode se conectar a diversos SGBDRs e enviar requisies de
consultas e transaes usando API, que so processados nos servidores. Aps o processamento de uma chamada de
funo (levando uma cadeia de caracteres ou programas armazenados), o resultado fornecido pelo servidor de dados
por meio de tabelas em memria. Os resultados das consultas so enviados para o programa cliente, que pode process-lo
ou visualiz-lo conforme a necessidade. O conjunto resposta para uma consulta pode ser uma tabela com zero, uma ou
mltiplas tuplas, dependendo de quantas linhas foram encontradas com o critrio de busca.
Quando uma consulta retorna mltiplas linhas, necessrio declarar um CURSOR para process-las. Um cursor similar
a uma varivel de arquivo ou um ponteiro de arquivo, que aponta para uma nica linha (tupla) do resultado da consulta. Em
SQL os cursores so controlados por trs comandos: OPEN, FETCH, CLOSE. O cursor iniciado com o comando OPEN,
que executa a consulta, devolve o conjunto resultante de linhas e coloca o cursor para a posio anterior primeira linha
do resultado da consulta. O comando FETCH, quando executado pela primeira vez, devolve a primeira linha nas variveis
do programa e coloca o cursor para apontar para aquela linha. Subsequentes execues do comando FETCH avanam o
cursor para a prxima linha no conjunto resultante e retornam a linha nas variveis do programa. Quando a ltima linha
processada, o cursor desbloqueado com o comando CLOSE. Os cursores existem principalmente para que linguagens de
programao que no permitem abstrao para conjunto de registros, como C, possam receber as linhas da resposta de
uma consulta SQL uma de cada vez. Com a utilizao de CURSORES, apresentam-se esses dados como resultados das
consulta, por meio de itens que representam os elementos de interface com o usurio, atendendo os preceitos impostos
pelos diferentes paradigmas possivelmente envolvidos. Com isso os resultados so mostrados utilizando o objeto padro
da interface, disponveis nas ferramentas de construo de interfaces. Dessa forma, o ciclo de busca de informao nos
mais variados servidores tem incio e fim na interface com o usurio.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
94
Figura 8.2. Arquitetura Cliente-Servidor
de fundamental importncia que se construam aplicativos cujos projetos de interface sejam ortogonais aos projetos
de implementao de acesso aos servidores de dados. Na implementao de sistemas de informao, deve-se utilizar uma
arquitetura de base de dados relacional que seja independente de um determinado repositrio de dados (gerenciadores
Access, Oracle, Sybase, Informix).
A Figura 8.2 ilustra a utilizao de conversores genricos tanto para interfaces quanto para os servidores de dados. Esses
conversores so construdos para padronizar o controle de compartilhamento de dados, independente da ferramenta de
interface ou do servidor de dados.
Em situaes prticas, esses conversores so denominados comumente de drivers.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
95
Captulo 9 Algoritmos para Processamento e Otimizao de Consultas
1. Processamento de Consultas
Um dos principais componentes de todo sistema de gerncia de bancos de dados o processador de consultas que, ao
receber uma consulta Q, prepara um plano de execuo para Q, consistindo de operaes de mais baixo nvel, implementadas
pelo subsistema de armazenamento.
Diferentes tcnicas podem ser usadas para processar, otimizar e executar consultas de alto nvel, como as consultas feitas
usando SQL. Uma consulta deve ser examinada (por meio de um scanner), analisada (por meio de um parser) e validada.
O scanner identifica os componentes da linguagem (tokens) no texto da consulta, enquanto o parser checa a sintaxe
da consulta para determinar se essa foi formulada seguindo as regras de sintaxe (regras de gramtica) da linguagem. A
consulta tambm validada por meio da checagem de que todos os nomes de atributos e tabelas so vlidos e corretos
semanticamente. Uma representao interna da consulta ento criada, geralmente usando-se uma estrutura de rvores
ou grafos, chamada de rvore de consulta ou grafo de consulta.
O SGBD deve, ento, determinar uma estratgia de execuo para recuperao dos resultados da consulta, dos arquivos
internos do banco de dados. Uma consulta geralmente possui vrias possveis estratgias de execuo, e o processo
para escolher entre elas, umas das melhores, conhecido como otimizao de consultas.
Duas abordagens so usadas no processamento de consultas: utilizao de regras heursticas e estimativa de custo.
Usualmente, estas duas abordagens so combinadas na otimizao de uma consulta. Portanto, a otimizao envolve:
determinao de uma expresso equivalente mais eficiente; e
seleo da melhor estratgia de processamento para a consulta (plano de acesso).
1.1. Etapas no Processamento de uma Consulta
1. Anlise Sinttica/Semntica (Scanner, Parser e Validao), que contm as etapas de verificao de
sintaxe, verificao dos identificadores (relaes, atributos) e a verificao de autorizao de acesso.
2. Traduo para uma estrutura de armazenamento bem definida (rvore de Consulta).
3. Otimizao da Consulta.
4. Escolha de um Plano de Acesso.
5. Gerao de Cdigo e Execuo da Consulta.
Unidade IV
Armazenamento de Dados, Indexao,
Processamento de Consultas e
Projeto Fsico
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
96
Armazenamento de Dados, Indexao, Processamento de Consultas e Projeto Fsico Unidade IV
A Figura 9.1 apresenta um esquema reduzido contendo as etapas para o processamento de consultas de alto nvel.
Figura 9.1. Representao esquemtica das etapas de processamento de consultas
Consulta numa linguagem de alto nvel
SCANNER, PARSER E VALIDAO
Forma intermediria da consulta
OTIMIZADOR DE CONSULTAS
Plano de acesso (ou plano de execuo)
GERADOR DE CDIGO
Cdigo para executar a consulta
PROCESSADOR DO BANCO DE DADOS

Resultado da consulta
2. Otimizao de Consultas
A otimizao de consultas consiste na escolha de estratgias eficientes para o processamento de consultas, visando minimizar:
o nmero de acessos memria secundria (disco);
a quantidade de memria principal necessria.
Para o entendimento dessa definio, devemos ter em mente as seguintes informaes.
Quando expressamos uma consulta, apenas informamos o resultado que desejamos obter, mas no o melhor
caminho para obt-lo. Logo, o SGBD deve se encarregar dessa tarefa.
As consultas expressas em uma linguagem de alto nvel (SQL, por exemplo) so transformadas pelos sistemas
(SGBD) para poderem ser processadas.
O processamento da consulta a busca de uma expresso equivalente, que torne mais rpida a execuo
dessa consulta (reduo no tamanho das tabelas intermedirias e menor custo de acesso).
O tempo gasto no processo de otimizao deve ser menor do que o tempo de acesso sem a otimizao.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
97
Suponhamos que um banco de dados apresente as seguintes tabelas:
Fornecedores: codf, nomef, cidade (100 tuplas)
Peas: codp, nomep, cor, peso (200 tuplas)
Embarques: codf, codp, qtde (10000 tuplas)
Suponhamos agora que se deseja executar uma consulta que busque o nome de todos os fornecedores que fornecem a pea
cujo cdigo P2. A expresso para executar a consulta pode ser:
SELECT nomef FROM fornecedores, embarques WHERE codf = codf and codp = P2;
Para efetuar a consulta podemos utilizar dois processos:
a. Processamento Normal:
Produto Cartesiano de fornecedores e embarques (100 x 10000 = 1000000 tuplas)
Seleo das tuplas desse produto que satisfazem a condio (50 tuplas, por exemplo, com 6 atributos)
Projeo sobre o nomef (50 tuplas, com um atributo)
b. Estratgia para otimizar:
Seleo das tuplas de embarques onde codp = P2 (50 tuplas)
Juno Natural desse resultado com a relao fornecedores (50 tuplas)
Projeo sobre nomef (50 tuplas)
2.2. O Processo de Otimizao
Existem duas tcnicas bsicas para otimizao: as baseadas em heursticas para a ordenao das operaes de acesso
ao banco de dados que participaro da estratgia de acesso; e as que estimam sistematicamente o custo de estratgias
de execuo diferentes e escolhem o plano de execuo com o menor custo estimado.
2.2.1. Otimizao Heurstica
A representao de consultas por meio de uma estrutura bem definida permite a transformao da consulta em uma srie
de expresses equivalentes. Nessa etapa, so feitas transformaes de uma expresso que representa uma consulta em
outras equivalentes mediante o uso de regras. Uma srie de transformaes baseadas em heursticas podem ser aplicadas
em uma consulta para melhor-la com relao ao seu desempenho de execuo.
2.3. Regras Gerais para Otimizao
1. Executar operaes de seleo o mais cedo possvel.
2. Combinar selees com um produto cartesiano de forma a produzir uma juno natural.
3. Aplicar operaes de projeo de forma antecipada (transferir ou inserir projees, sempre que
necessrio). Os nicos atributos que devem permanecer num esquema so aqueles que aparecem no
resultado ou aqueles necessrios para o processamento de consultas subseqentes.
4. Aplicar operaes em grupo medida que se percorre as tuplas (evita a gerao de muitas tabelas
intermedirias).
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
98
5. Procurar subexpresses comuns em uma rvore (comput-las uma nica vez e guard-las em uma tabela
temporria).
Ainda nas regras, as seguintes consideraes so importantes:
A combinao de operaes evita repetitivas leituras s mesmas relaes.
Operaes unrias (seleo e projeo) so mais econmicas que operaes binrias, pois trabalham sobre uma
nica relao. Sempre que possvel, devem ser antecipadas.
As expresses na lgebra relacional possuem vrias formas de se apresentarem, assim como as expresses matemticas.
Deve-se valer das propriedades de associatividade e comutatividade a fim de simplificar ao mximo tais consultas.
2.3.1. Rotinas de Acesso para o Processamento de Consultas
Cada SGBD implementa um certo nmero de rotinas de acesso a bancos de dados, as quais so escritas para implementar
as operaes relacionais, tais como Seleo ou Juno ou combinaes destas operaes. Uma estratgia de execuo
usualmente implementada por meio da chamada de uma ou mais dessas rotinas de acesso.
2.4. Otimizao de Planos de Acesso
O processo de otimizao de planos de acesso gera planos de operadores para as verses das consultas resultantes do
processo de transformaes lgicas, estabelece os custos de cada plano gerado e escolhe o de menor custo para processar
a consulta. Esse processo geralmente dividido em trs etapas: gerao de planos, avaliao de custos e escolha de planos.
2.4.1. Gerao de Planos
Essa etapa mapeia a consulta resultante das transformaes lgicas em seqncias de operaes denominadas planos de
acesso. Na gerao de planos, o otimizador deve planejar suas estratgias de acesso, utilizando da melhor forma possvel
os caminhos de acesso j existentes e estimar custos de processamento em termos de tamanho das tabelas e acessos
ao disco. Um Plano de acesso para uma consulta inclui no somente as relaes operacionais a serem executadas, mas
tambm os ndices a serem utilizados e a ordem em que as tuplas devem ser acessadas, bem como a ordem de execuo
das operaes.
2.4.2. Estimativas de Custo de Acesso
Fatores que influenciam na estimativa de custos de acesso:
proximidade fsica das tuplas;
ordenao fsica das tuplas;
presena de ndices e o seu tipo (ndice clustering ou no, hash etc.)
2.5. Otimizao Baseada em Custos
As funes do custos so baseadas em estatsticas geradas pelo prprio SGBD. So apenas estimativas e, por no serem
exatas, correm o risco de gerar resultados dos quais a estratgia escolhida para otimizao possa no ser a melhor. As
estatsticas so baseadas em informaes armazenadas para utilizao nessas funes, tais como o nmero de tuplas
da tabela, os ndices secundrios e suas chaves e a cardinalidade entre as tabelas.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
99
Captulo 10 Tcnicas de Controle de Concorrncia
Em nvel lgico, o banco de dados descrito por um esquema conceitual global consistindo em um conjunto de objetos
lgicos; em nvel fsico, descrito por uma srie de esquemas internos, um para cada n onde est armazenado; cada
esquema interno consiste em um conjunto de objetos fsicos.
Os mapeamentos do esquema conceitual global para os esquemas internos definem a forma de distribuio do banco e
a correspondncia entre objetos fsicos e objetos lgicos. Esses mapeamentos podero determinar que certos conjuntos
de objetos fsicos armazenem cpias dos mesmos dados. Os objetos lgicos so manipulados por meio de comandos da
LMD e os objetos fsicos mediante aes elementares.
Uma transao de banco de dados uma unidade de interao com um SGBD ou com um sistema similar de processamento
de transaes, que deve ser integralmente completada ou abortada. Um sistema de banco de dados deve assegurar as
propriedades de Atomicidade, Consistncia, Isolamento e Durabilidade (ACID) para cada transao. Na prtica, essas
propriedades so frequentemente relaxadas de certa forma para aperfeioar a execuo e melhorar o desempenho do
sistema. Em alguns sistemas, transaes so tambm vistas como Unidades Lgicas de Trabalho (LUW - Logical Unit
of Work). Em SGBDs, a capacidade de manipular transaes enseja ao usurio garantir a integridade do banco de dados
mantida.
Essa garantia s pode ser alcanada devido a um conjunto de operaes que tm origem em um estudo ligado em quatro
regras fundamentais para gerenciamento de dados em ambientes multiusurio. Essas regras, as propriedades ACD, esto
relacionadas ao seguinte.
Atomicidade: a propriedade que garante que todas as transaes sejam indursvas em sua execuo ou
nenhuma delas ser.
Consistncia: O banco de dados deve estar em um estado legal, quando a transao se inicia e quando for
executada. Uma operao no deve violar as regras ou restries de integridade do banco, que deve continuar
consistente.
Isolamento: Mesmo que vrias transaes ocorram paralelamente, elas devem parecer isoladas uma das
outras. Isso significa que nenhuma operao fora da transao pode ver o dado em um estado intermedirio
e nenhuma operao deve influenciar as outras. Resultados parciais de uma transao no podem ser vistos
por outras transaes concorrentes.
Durabilidade: Segurana em que se uma transao finalizada com sucesso, seus resultados sero
persistentes e no sero desfeitos, a no ser por outra transao, mesmo se houver falhas no sistema aps
a sua finalizao.
A execuo de uma transao controlada pelo gerente de transaes (GT) do n onde foi submetida. Em nvel lgico,
a execuo de uma transao consiste em todas as operaes ali executadas entre o comeo e o fim da transao.
delimitada pelo.
COMEO-DE-TRANSAO: o GT, ao interceptar este comando, cria uma rea de trabalho para a transao;
comandos da LMD: consultas puras acessam objetos lgicos do banco de dados trazendo-os para a rea
de trabalho, se j l no estiverem. Atualizaes sobre os objetos lgicos so mantidas na prpria rea de
trabalho, no se tornando visveis de imediato a outras transaes;
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
100
FIM-DE-TRANSAO: invoca o protocolo bifsico para modificar todas as cpias de todos os objetos lgicos
afetados por atualizaes executadas pela transao. Os valores dos objetos lgicos so obtidos da rea de
trabalho.
Suponhamos que em cada n participando do processamento da transao h uma rea de trabalho da transao.
Todas as operaes a nvel lgico so sempre traduzidas em sequncias de operaes a nvel fsico. Mais precisamente,
uma execuo de um grupo de transaes gera, em cada n, onde o banco est armazenado, uma sequncia de aes
elementares, que presumimos de dois tipos:
R(X) ao de leitura que recupera os valores dos objetos fsicos, cujo nome est no conjunto X para a rea de
trabalho local da transao que gerou a ao;
W(X) ao de atualizao que escreve os novos valores dos objetos fsicos em X no banco de dados local.
Assim, a execuo de um comando da LMD (que uma operao em nvel lgico) poder gerar vrias aes do tipo R(X)
para recuperar objetos fsicos que ainda no esto na rea de trabalho da transao. Porm, um comando da LMD nunca
gerar aes elementares do tipo W(X) pois o banco de dados no alterado de imediato. Apenas quando o protocolo
bifsico atingir a segunda fase, aes elementares do tipo W(X) sero geradas para efetivar alteraes nos bancos de
dados locais.
H duas suposies importantes para controle de concorrncia a se ressaltar aqui:
1. Controle de concorrncia ser feito em nvel dos objetos fsicos. Portanto, um mecanismo de controle de
concorrncia dever disciplinar a intercalao das aes elementares de diferentes transaes em cada n.
2. A semntica das transaes no ser levada em conta pelos mecanismos de controle de concorrncia.
Como consequncia, o controle de concorrncia dever depender apenas das sequncias de operaes de leitura/atualizao
sobre os objetos fsicos armazenados nos vrios bancos de dados locais, ou seja, das sequncias de operaes R(X)
e W(X) executadas contra os bancos de dados locais. Uma execuo concorrente E de um conjunto T de transaes
pode, ento, ser abstrada por um conjunto L= { L1 ,..., Ln }, onde Li a sequncia de aes elementares R(X) ou W(X)
executadas contra o banco de dados do n i que foram geradas em E. O conjunto L chamado de um escalonamento
global para T e a sequncia Li chamada do escalonamento local ao n i para T. Usaremos Ri(X) ou Wi(X) para indicar
aes elementares R(X) ou W(X) executadas a favor da transao Ti em um escalonamento local.
Frequentemente escreveremos Ri (x1,..., xk ) em lugar de Ri ( { x1 ,..., xk } ), e semelhantemente para aes de atualizao.
Como exemplos desses conceitos, considere um banco de dados distribudo armazenado em dois ns. Os esquemas
internos so modelados por dois conjuntos de objetos fsicos, D1 = { x1 ,y1 } e D2 = { x2 }, onde x1 e x2 armazenam
cpias dos mesmos dados.
Um escalonamento global para duas transaes T1 e T2 nesse contexto poderia ser L = { L1 , L2 }, onde L1 = R1(y1)
R2(x1) W2(x1) W1(x1) e L2 = R1(x2) W1(x2) W2(x2)
Ou seja, L1 representa a seguinte sequncia de aes elementares executadas no primeiro n:
T1 l o objeto fsico y1
T2 l o objeto fsico x1
T2 escreve no objeto fsico x1
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
101
Para o segundo n, L2 representa a seguinte sequncia:
T1 l o objeto fsico x2
Tanto a teoria de correo quanto o estudo do comportamento dos mtodos de controle de concorrncia sero baseados
em propriedades de escalonamentos globais.
2. Isolamento da Transao
O padro SQL define quatro nveis de isolamento de transao em termos de trs fenmenos que devem ser evitados
entre transaes simultneas.
Dirty read
1
(leitura suja): situao onde uma transao l dados escritos por uma transao simultnea no
efetivada (uncommitted).
Nonrepeatable read
2
(leitura que no pode ser repetida): situao onde uma transao l novamente dados
lidos anteriormente, e descobre que os dados foram alterados por outra transao (que os efetivou aps ter
sido feita a leitura anterior).
Phantom read
3
(leitura fantasma): situao onde uma transao executa uma segunda vez uma consulta
que retorna um conjunto de linhas que satisfazem uma determinada condio de procura, e descobre que
o conjunto de linhas que satisfazem a condio diferente por causa de uma outra transao efetivada
recentemente.
Os quatro nveis de isolamento de transao, e seus comportamentos correspondentes, esto descritos na Tabela 10.1.
Tabela 10.1. Nveis de Isolamento da Transao SQL
Nvel de isolamento Dirty Read Nonrepeatable Read Phantom Read
Read uncommitted Possvel Possvel Possvel
Read committed Impossvel Possvel Possvel
Repeatable read Impossvel Impossvel Possvel
Serializable Impossvel Impossvel Impossvel
2.1. Nvel de isolamento Read Committed
Quando uma transao processada sob o nvel de isolamento Read Committed (l efetivado), o comando SELECT enxerga
apenas os dados efetivados antes da consulta comear; nunca enxerga dados no efetivados, ou as alteraes efetivadas
pelas transaes simultneas durante a execuo da consulta. Entretanto, o SELECT enxerga os efeitos das atualizaes
anteriores executadas dentro da sua prpria transao, mesmo que ainda no tenham sido efetivadas. Na verdade, o
1 Dirty read A transao SQL T1 altera uma linha. Em seguida, a transao SQL T2 l essa linha antes de T1 executar o comando COMMIT. Se depois T1 executar o comando
ROLLBACK, T2 ter lido uma linha que nunca foi efetivada e que, portanto, pode ser considerada como nunca tendo existido. (ISO-ANSI Working Draft) Foundation (SQL/
Foundation), August 2003, ISO/IEC JTC 1/SC 32, 25-jul-2003, ISO/IEC 9075-2:2003 (E) (N. do T.)
2 Nonrepeatable read A transao SQL T1 l uma linha. Em seguida a transao SQL T2 altera ou exclui essa linha e executa o comando COMMIT. Se T1 tentar ler essa linha
novamente, pode receber o valor alterado ou descobrir que a linha foi excluda. (ISO-ANSI Working Draft) Foundation (SQL/Foundation), August 2003, ISO/IEC JTC 1/SC 32,
25-jul-2003, ISO/IEC 9075-2:2003 (E) (N. do T.)
3 Phantom read A transao SQL T1 l um conjunto de linhas N que satisfazem a uma condio de procura. Em seguida, a transao SQL T2 executa comandos SQL que geram
uma ou mais linhas que satisfazem a condio de procura usada pela transao T1. Se depois a transao SQL T1 repetir a leitura inicial com a mesma condio de procura, ser
obtida uma coleo diferente de linhas. (ISO-ANSI Working Draft) Foundation (SQL/Foundation), August 2003, ISO/IEC JTC 1/SC 32, 25-jul-2003, ISO/IEC 9075-2:2003 (E) (N.
do T.)
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
102
comando SELECT enxerga um instantneo do banco de dados, como esse era no instante em que a consulta comeou a
executar. Deve ser observado que dois comandos SELECT sucessivos podem enxergar dados diferentes, mesmo estando
dentro da mesma transao, se outras transaes efetivarem alteraes durante a execuo do primeiro comando SELECT.
Os comandos UPDATE, DELETE e SELECT FOR UPDATE se comportam do mesmo modo que o SELECT para encontrar
as linhas de destino: somente encontram linhas de destino efetivadas at o momento do incio do comando. Entretanto,
no momento em que foi encontrada, alguma linha de destino pode ter sido atualizada (ou excluda ou marcada para
atualizao) por outra transao simultnea. Nesse caso, a transao que pretende atualizar fica aguardando a transao
de atualizao que comeou primeiro: efetivar ou desfazer. Se a transao de atualizao que comeou primeiro desfizer
as atualizaes, ento seus efeitos so negados e a segunda transao de atualizao pode prosseguir com a atualizao
da linha original encontrada. Se a transao de atualizao que comeou primeiro efetivar as atualizaes, a segunda
transao de atualizao ignora a linha caso tenha sido excluda pela primeira transao de atualizao, seno tenta
aplicar sua operao na verso atualizada da linha. A condio de procura do comando (a clusula WHERE) avaliada
novamente para verificar se a verso atualizada da linha ainda corresponde condio de procura. Se corresponder, a
segunda transao de atualizao prossegue sua operao comeando a partir da verso atualizada da linha.
Devido regra acima, possvel um comando de atualizao enxergar um instantneo inconsistente: pode enxergar os
efeitos dos comandos simultneos de atualizao que afetam as mesmas linhas que est tentando atualizar, mas no
enxerga os efeitos desses comandos de atualizao nas outras linhas do banco de dados. Esse comportamento torna o
Read Committed inadequado para os comandos envolvendo condies de procura complexas. Entretanto, apropriado
para casos mais simples.
Exemplificando, consideremos a atualizao do saldo bancrio pela transao mostrada Figura 10.1.
Figura 10.1. Exemplo de Atualizao de Saldo Bancrio
BEGIN;
UPDATE conta SET saldo = saldo + 100.00 WHERE num_conta = 12345;
UPDATE conta SET saldo = saldo - 100.00 WHERE num_conta = 7534;
COMMIT;
Se duas transaes desse tipo tentam mudar simultaneamente o saldo da conta 12345, claro que se deseja que a
segunda transao comece a partir da verso atualizada da linha da conta. Uma vez que cada comando afeta apenas
uma linha predeterminada, permitir enxergar a verso atualizada da linha no cria nenhum problema de inconsistncia.
Como no modo Read Committed, cada novo comando comea com um novo instantneo incluindo todas as transaes
efetivadas at esse instante; de qualquer modo, os prximos comandos na mesma transao vo enxergar os efeitos
das transaes simultneas efetivadas. O ponto em questo se, dentro de um nico comando, enxergada uma viso
totalmente consistente do banco de dados.
O isolamento parcial da transao fornecido pelo modo Read Committed adequado para muitas aplicaes, e esse
modo rpido e fcil de ser utilizado. Entretanto, para aplicaes que efetuam consultas e atualizaes complexas,
pode ser necessrio garantir uma viso do banco de dados com consistncia mais rigorosa que a fornecida pelo modo
Read Committed.
2.2. Nvel de Isolamento Serializvel
O nvel Serializvel fornece o isolamento de transao mais rigoroso. Esse nvel emula a execuo serial das transaes,
como se todas as transaes fossem executadas uma aps a outra, em srie, em vez de simultaneamente. Entretanto, as
aplicaes que utilizam esse nvel de isolamento devem estar preparadas para tentar executar novamente as transaes,
devido a falhas de serializao.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
103
Quando uma transao est no nvel serializvel, o comando SELECT enxerga apenas os dados efetivados antes da
transao comear; nunca enxerga dados no efetivados ou alteraes efetivadas durante a execuo da transao
por transaes simultneas. Entretanto, o comando SELECT enxerga os efeitos das atualizaes anteriores executadas
dentro da sua prpria transao, mesmo que ainda no tenham sido efetivadas. diferente do Read Committed, porque
o comando SELECT enxerga um instantneo do momento de incio da transao, e no do momento de incio do comando
corrente dentro da transao. Portanto, comandos SELECT sucessivos dentro de uma mesma transao sempre enxergam
os mesmos dados.
Os comandos UPDATE, DELETE e SELECT FOR UPDATE se comportam do mesmo modo que o comando SELECT para
encontrar as linhas de destino: somente encontram linhas de destino efetivadas at o momento do incio da transao.
Entretanto, alguma linha de destino pode ter sido atualizada (ou excluda ou marcada para atualizao) por outra transao
simultnea no momento em que foi encontrada. Nesse caso, a transao serializvel aguarda a transao de atualizao
que comeou primeiro efetivar ou desfazer as alteraes. Se a transao que comeou primeiro desfizer as alteraes,
ento seus efeitos so negados e a transao serializvel pode prosseguir com a atualizao da linha original encontrada.
Porm, se a transao que comeou primeiro efetivar (e realmente atualizar ou excluir a linha, e no apenas selecionar
para atualizao), ento a transao serializvel cancelada e apresentada uma mensagem de erro, pois uma transao
serializvel no pode alterar linhas alteradas por outra transao aps a transao serializvel ter comeado.
Quando a aplicao receber essa mensagem de erro dever interromper a transao corrente e tentar executar novamente
toda a transao a partir do incio. Da segunda vez em diante, a transao passa a enxergar a alterao efetivada
anteriormente como parte da sua viso inicial do banco de dados e, portanto, no existir conflito lgico em usar a nova
verso da linha como ponto de partida para atualizao na nova transao.
Deve ser observado que somente as transaes que fazem atualizaes podem precisar de novas tentativas; as transaes
somente para leitura nunca esto sujeitas a conflito de serializao.
O modo serializvel fornece uma garantia rigorosa que cada transao enxerga apenas vises totalmente consistentes do
banco de dados. Entretanto, a aplicao deve estar preparada para executar novamente a transao quando atualizaes
simultneas tornarem impossvel sustentar a iluso de uma execuo serial. Como o custo de refazer transaes complexas
pode ser significativo, esse modo recomendado somente quando as transaes, efetuando atualizaes, contenham
lgica suficientemente complexa a ponto de produzir respostas erradas no modo Read Committed. Habitualmente, o
modo serializvel necessrio quando a transao executa vrios comandos sucessivos que necessitam enxergar vises
idnticas do banco de dados.
3. Bloqueio Explcito
Diversos SGBDs, baseados na linguagem SQL, fornecem vrios modos de bloqueio para controlar o acesso simultneo
aos dados nas tabelas. A maioria dos comandos SQL obtm, automaticamente, bloqueios nos modos apropriados para
garantir que as tabelas referenciadas no sero excludas ou alteradas de forma incompatvel enquanto o comando
estiver executando. Por exemplo, o comando ALTER TABLE no pode executar simultaneamente com outras operaes
na mesma tabela.
3.1. Bloqueios no Nvel de Tabela
Os nomes dos modos de bloqueio so histricos pois, de alguma forma, os nomes refletem a utilizao tpica de cada
modo de bloqueio mas as semnticas so todas as mesmas. A nica diferena real entre um modo de bloqueio e
outro o conjunto de modos de bloqueio que cada um conflita. Duas transaes no podem obter bloqueios com modos
conflitantes na mesma tabela ao mesmo tempo (Entretanto, uma transao nunca conflita consigo mesma. Por exemplo,
pode obter o bloqueio ACCESS EXCLUSIVE e posteriormente obter o bloqueio ACCESS SHARE na mesma tabela). Podem
ser obtidos simultaneamente modos de bloqueio no conflitantes por muitas transaes. Em particular, deve ser observado
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
104
que alguns modos de bloqueio so autoconflitantes. Por exemplo, o modo de bloqueio ACCESS EXCLUSIVE no pode ser
obtido por mais de uma transao ao mesmo tempo, enquanto outros no so autoconflitantes. Por exemplo, o modo de
bloqueio ACCESS SHARE pode ser obtido por vrias transaes ao mesmo tempo. Uma vez obtido, o modo de bloqueio
permanece at o fim da transao.
3.1.1. Modos de Bloqueio no Nvel de Tabela
A seguir, apresentamos alguns modos de bloqueio em nvel de tabela.
ACCESS SHARE: Conflita apenas com o modo de bloqueio ACCESS EXCLUSIVE. O comando SELECT e o
comando ANALYZE obtm um bloqueio nesse modo nas tabelas referenciadas. Em geral, qualquer comando
que apenas l a tabela sem modific-la obtm esse modo de bloqueio.
ROW SHARE: Conflita com os modos de bloqueio EXCLUSIVE e ACCESS EXCLUSIVE. O comando SELECT
FOR UPDATE obtm o bloqueio nesse modo na(s) tabela(s) de destino (alm do bloqueio no modo ACCESS
SHARE para as demais tabelas referenciadas mas no selecionadas FOR UPDATE).
ROW EXCLUSIVE: Conflita com os modos de bloqueio SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE e
ACCESS EXCLUSIVE. Os comandos UPDATE, DELETE e INSERT obtm esse modo de bloqueio na tabela de
destino (alm do modo de bloqueio ACCESS SHARE nas outras tabelas referenciadas). Em geral, este modo
de bloqueio obtido por todos os comandos que alteram os dados da tabela.
SHARE UPDATE EXCLUSIVE: Conflita com os modos de bloqueio SHARE UPDATE EXCLUSIVE, SHARE,
SHARE ROW EXCLUSIVE, EXCLUSIVE e ACCESS EXCLUSIVE. Este modo protege a tabela contra alteraes
simultneas no esquema e a execuo do comando VACUUM. Obtida pelo comando VACUUM (sem a opo
FULL).
SHARE: Conflita com os modos de bloqueio ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE ROW
EXCLUSIVE, EXCLUSIVE e ACCESS EXCLUSIVE. Esse modo protege a tabela contra alteraes simultneas
nos dados. Obtido pelo comando CREATE INDEX.
SHARE ROW EXCLUSIVE: Conflita com os modos de bloqueio ROW EXCLUSIVE, SHARE UPDATE
EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE e ACCESS EXCLUSIVE. Esse modo de bloqueio
no obtido automaticamente por nenhum comando do PostgreSQL.
EXCLUSIVE: Conflita com os modos de bloqueio ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE,
SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE e ACCESS EXCLUSIVE. Esse modo permite apenas bloqueios
ACCESS SHARE simultneos, ou seja, somente leituras da tabela podem prosseguir em paralelo com uma
transao que obteve esse modo de bloqueio. Esse modo de bloqueio no obtido automaticamente por
nenhum comando do PostgreSQL.
ACCESS EXCLUSIVE: Conflita com todos os modos de bloqueio (ACCESS SHARE, ROW SHARE, ROW
EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE e ACCESS
EXCLUSIVE). Esse modo garante que a transao que o obteve a nica acessando a tabela de qualquer
forma. Obtido pelos comandos ALTER TABLE, DROP TABLE, REINDEX, CLUSTER e VACUUM FULL. Esse ,
tambm, o modo de bloqueio padro para o comando LOCK TABLE sem a especificao explcita do modo.
Dica 1: Somente o bloqueio ACCESS EXCLUSIVE bloqueia o comando SELECT (sem a clusula FOR UPDATE).
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
105
3.2. Bloqueios no Nvel de Linha
Alm dos bloqueios em nvel de tabela, existem os bloqueios no nvel de linha. O bloqueio em nvel de linha obtido
automaticamente para uma linha especfica quando a linha atualizada (ou excluda ou marcada para atualizao). O
bloqueio mantido at a transao efetivar ou desfazer as alteraes. Os bloqueios em nvel de linha no afetam a
consulta aos dados; bloqueiam apenas escritas na mesma linha. Para obter um bloqueio em nvel de linha sem, na verdade,
modific-la, a linha deve ser selecionada por meio do comando SELECT FOR UPDATE. Deve ser observado que, aps ser
obtido um bloqueio em nvel de linha, a transao pode atualizar essa linha vrias vezes sem medo de conflito.
De forma geral, os SGDs baseados em SQL no guardam em memria qualquer informao sobre as linhas alteradas,
portanto no existe limite de nmero de linhas bloqueadas de cada vez. Entretanto, o bloqueio de uma linha pode causar
escrita no disco; por exemplo, o comando SELECT FOR UPDATE altera as linhas selecionadas para marc-las, ocasionando
escrita em disco.
Alm dos bloqueios de tabela e de linha, tambm so utilizados bloqueios compartilhados e exclusivos no nvel de pgina,
para controlar o acesso de leitura e escrita nas pginas da tabela no shared buffer pool. Esses bloqueios so liberados
imediatamente aps a linha ser lida ou atualizada.
Normalmente os desenvolvedores de aplicao no precisam se preocupar com bloqueios em nvel de pgina, sendo
mencionados somente para o assunto ficar completo.
3.3. Impasses
A utilizao de bloqueios explcitos pode aumentar a probabilidade de acontecerem impasses (deadlocks), onde duas (ou
mais) transaes mantm bloqueios que a outra deseja. Por exemplo, se a transao 1 obtiver um bloqueio exclusivo
na tabela A e, depois, tentar obter um bloqueio exclusivo na tabela B, enquanto a transao 2 j possui um bloqueio
exclusivo na tabela B, e agora deseja obter um bloqueio exclusivo na tabela A, ento nenhuma das duas transaes
pode prosseguir. Nesse tipo de situao, necessrio que o SGBD detecte as situaes de impasse, resolvendo-as,
interrompendo uma das transaes envolvidas, permitindo que a(s) outra(s) prossiga(m). O ponto sensvel desse tipo de
soluo saber exatamente qual transao ser interrompida; difcil prever, no se devendo confiar na previso de
tratamento automtico.
Deve ser observado que os impasses tambm podem ocorrer como resultado de um bloqueio no nvel de linha, podendo
ocorrer mesmo que no se use bloqueios explcitos. Considere o caso onde existam duas transaes simultneas alterando
uma tabela. A primeira transao executa a instruo apresentada na Figura 10.2.
Figura 10.2. Exemplo de Atualizao de Saldo Bancrio (atualizao I)
Esse comando obtm um bloqueio no nvel de linha na linha com o nmero da conta especificado. Depois, a segunda
transao executa (Figura 10.3):
Figura 10.3. Exemplo de Atualizao de Saldo Bancrio (atualizao II)
UPDATE conta SET saldo = saldo 100.00 WHERE num_conta = 11111;
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
106
O primeiro comando UPDATE bem-sucedido ao obter o bloqueio no nvel de linha na linha especificada e, prossegue,
atualizando a linha. Entretanto, o segundo comando UPDATE descobre que a linha a ser atualizada est bloqueada e, fica
aguardando a transao que obteve o bloqueio terminar. A transao 2, agora, est aguardando a transao 1 completar
para poder continuar. Agora, a transao 1 executa (Figura 10.4):
Figura 10.4. Exemplo de Atualizao de Saldo Bancrio (atualizao III)
UPDATE conta SET saldo = saldo - 100.00 WHERE num_conta = 22222;
A transao 1 tenta obter um bloqueio no nvel de linha na linha especificada, mas no pode: a transao 2 j possui esse
bloqueio. Portanto, fica aguardando a transao 2 terminar. Assim sendo, a transao 1 est bloqueada pela transao
2, e a transao 2 est bloqueada pela transao 1: uma condio de impasse. Nesse caso, necessrio que o SGBD
detecte essa situao e interrompa uma das transaes.
Geralmente a melhor defesa contra os impasses evit-los, tendo certeza de que todas as aplicaes que utilizam o banco
de dados obtm bloqueios em vrios objetos em uma ordem consistente. No exemplo anterior, se as duas transaes
tivessem atualizado as linhas na mesma ordem, no teria ocorrido nenhum impasse. Deve-se garantir, tambm, que o
primeiro bloqueio obtido em um objeto em uma transao seja aquele com o modo mais alto que ser necessrio para
esse objeto. Se for impraticvel verificar essa situao antecipadamente, ento os impasses podem ser tratados em
tempo de execuo tentando executar novamente as transaes interrompidas pelos impasses.
Enquanto a situao de impasse no for detectada, uma transao em busca de um bloqueio no nvel de tabela ou no nvel
de linha ficar aguardando indefinidamente pela liberao dos bloqueios conflitantes. Isso significa que uma pssima
idia as aplicaes manterem transaes abertas por longos perodos de tempo (por exemplo, aguardando a entrada de
dados pelo usurio).
4. Verificao da Consistncia dos Dados no Nvel da Aplicao
De certa forma, podemos dizer que cada transao enxerga um instantneo do contedo do banco de dados, e as
transaes, executando simultaneamente, podem, perfeitamente bem, enxergar instantneos diferentes. Portanto, o
prprio conceito de agora, de alguma forma mal definido. Normalmente isso no um grande problema quando as
aplicaes cliente esto isoladas umas das outras, mas se os clientes podem se comunicar por meio de canais externos
ao banco de dados, ento podem acontecer srias confuses.
Para garantir a validade corrente de uma linha e proteg-la contra atualizaes simultneas, deve ser utilizado o comando
SELECT FOR UPDATE ou uma declarao LOCK TABLE apropriada. O comando SELECT FOR UPDATE bloqueia apenas
as linhas retornadas contra atualizaes simultneas, enquanto o LOCK TABLE bloqueia toda a tabela.
As verificaes de validade globais requerem consideraes extras. Por exemplo, uma aplicao bancria pode desejar
verificar se a soma de todos os crditos em uma tabela igual soma de todos os dbitos em outra tabela, num momento
em que as duas tabelas esto sendo ativamente atualizadas. Comparar os resultados de dois comandos SELECT SUM(...)
sucessivos no funciona confiavelmente no modo Read Committed, porque o segundo comando, provavelmente, vai
incluir resultados de transaes no contados pelo primeiro comando. Realizar as duas somas em uma mesma transao
serializvel fornece uma imagem precisa dos efeitos das transaes efetivadas antes do incio da transao serializvel
mas pode ser legitimamente questionado se a resposta ainda era relevante na hora em que foi entregue.
Se a prpria transao serializvel introduziu algumas alteraes antes de tentar efetuar a verificao de consistncia,
o valor prtico da verificao se torna ainda mais discutvel, porque agora so includas algumas, mas no todas as
alteraes ocorridas aps o incio da transao. Em casos como esse, uma pessoa cuidadosa pode desejar bloquear
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
107
todas as tabelas necessrias para a verificao, para obter uma imagem da situao atual acima de qualquer suspeita.
Um bloqueio no modo SHARE (ou superior) garante no haver alteraes no efetivadas na tabela bloqueada, fora as
alteraes efetuadas pela prpria transao corrente.
Deve ser observado, tambm, que quando se depende de bloqueios explcitos para evitar alteraes simultneas, deve ser
utilizado o modo Read Committed ou, no modo serializvel, tomar o cuidado de obter os bloqueios antes de executar os
comandos. Um bloqueio obtido por uma transao serializvel garante que nenhuma outra transao alterando a tabela
est executando, mas se o instantneo enxergado pela transao for anterior obteno do bloqueio, pode ser que seja
anterior a algumas alteraes na tabela que agora esto efetivadas.
O instantneo de uma transao serializvel , na verdade, tirado no incio da sua primeira consulta ou comando de
alterao de dados (SELECT, INSERT, UPDATE ou DELETE) sendo, portanto, possvel obter bloqueios explicitamente
antes do instantneo ser tirado.
5. Bloqueio e ndices
Os vrios tipos de ndice so tratados como mostrado a seguir.
ndices B-tree: So utilizados bloqueios no nvel de pgina, compartilhados ou exclusivos, de curta durao,
para acesso de leitura/escrita. Os bloqueios so liberados imediatamente aps cada linha do ndice ser lida ou
inserida. Os ndices B-tree fornecem a mais alta simultaneidade, sem condies de impasse.
ndices GiST e R-tree: So utilizados bloqueios no nvel de ndice, compartilhados ou exclusivos, para acesso
de leitura/escrita. Os bloqueios so liberados aps o comando terminar.
ndices Hash: So utilizados bloqueios no nvel de pgina compartilhados e exclusivos para acessos de
leitura/escrita. Os bloqueios so liberados aps a pgina ser processada. Os bloqueios no nvel de pgina
fornecem uma simultaneidade melhor que os bloqueios no nvel de ndice, mas podem ocorrer impasses.
Em resumo, o ndice B-tree oferece o melhor desempenho para aplicaes simultneas; uma vez que tambm possui mais
funcionalidades do que o ndice hash, o tipo de ndice recomendado para aplicaes simultneas que necessitam indexar
dados escalares. Para tratar dados no escalares, os ndices B-tree obviamente no podem ser utilizados; nessa situao,
os que desenvolvem a aplicao devem estar cientes do desempenho relativamente pobre dos ndices GiST e R-tree.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
108
Captulo 11 Tcnicas de Recuperao de Dados
1. Introduo
Existem algumas tarefas de manuteno que precisam ser realizadas regularmente para manter um servidor funcionando
sem problemas. responsabilidade do administrador do banco de dados instalar os scripts apropriados, e verificar se a
execuo est sendo bem-sucedida.
Uma tarefa de manuteno bvia a gerao das cpias de segurana dos dados em perodos regulares. Sem uma cpia
de segurana recente, no h como fazer a recuperao aps um desastre (falha de disco, incndio, remoo por engano
de uma tabela crtica).
Outra tarefa de manuteno importante a limpeza peridica do banco de dados, alm do gerenciamento do arquivo de
registro (log).
2. Rotina de Limpeza
Cada SGBD possui um conjunto de comandos para efetuar rotinas de limpeza. No PostgreSQL o comando VACUUM
utilizado para essa funo e necessita ser executado regularmente para:
recuperar o espao em disco ocupado pelas linhas atualizadas e removidas.
atualizar as estatsticas dos dados utilizadas pelo planejador de comandos do PostgreSQL.
proteger contra perda de dados muito antigos devido ao recomeo do ID de transao.
A frequncia e a abrangncia das operaes de VACUUM, realizadas devido aos motivos acima, variam dependendo
das necessidades da instalao. Portanto, os administradores de banco de dados devem compreender essas questes e
desenvolver uma estratgia de manuteno apropriada.
2.1. Recuperao do Espao em Disco
De forma geral, um comando UPDATE ou DELETE em uma linha no remove imediatamente a verso antiga da linha. Essa
abordagem necessria para obter os benefcios do controle de simultaneidade multiverso. A verso da linha no pode
ser removida enquanto houver possibilidade de ser acessada por outras transaes. Mas no final, uma verso de linha
desatualizada ou excluda no ter mais interesse para nenhuma transao. O espao ocupado deve ser recuperado para
ser reutilizado pelas novas linhas, evitando um crescimento sem fim da necessidade de espao em disco.
Obviamente, uma tabela que recebe atualizaes ou excluses frequentes necessita ser limpa com mais frequncia que
uma tabela que atualizada raramente.
A forma padro encontra as verses antigas das linhas e torna seus espaos disponveis para ser utilizado novamente
dentro da tabela, mas no faz muito esforo para diminuir o tamanho do arquivo da tabela e devolver o espao em disco
para o sistema operacional.
No PostgreSQL, se for necessrio devolver espao em disco para o sistema operacional pode ser utilizado o comando
VACUUM FULL mas qual a vantagem de liberar espao em disco que dever ser alocado novamente em breve?
Execues do comando VACUUM padro com frequncia moderada uma abordagem melhor do que a execuo do
comando VACUUM FULL com baixa frequncia, para manuteno de tabelas muito atualizadas.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
109
A prtica recomendada para a maioria das instalaes agendar o comando VACUUM para todo o banco de dados uma
vez por dia, em horrio de pouca utilizao, suplementado por limpezas mais frequentes das tabelas muito atualizadas se
for necessrio (Havendo vrios bancos de dados em um agrupamento, no deve ser esquecido de limpar cada um deles;
o programa vacuumdb pode ser til). Deve ser utilizado o VACUUM simples, e no o VACUUM FULL, para recuperao
rotineira de espao.
O comando VACUUM FULL recomendado para os casos onde se sabe que foi excluda a maior parte das linhas da
tabela e, portanto, o tamanho estvel da tabela pode ser reduzido substancialmente pela abordagem mais agressiva do
comando VACUUM FULL.
Havendo uma tabela cujo contedo excludo periodicamente, deve ser considerada a execuo do comando TRUNCATE
em vez de utilizar DELETE seguido por VACUUM.
2.2. Atualizao das Estatsticas do Planejador
O planejador de comandos depende das informaes estatsticas sobre o contedo das tabelas para poder gerar bons
planos para os comandos. Essas estatsticas so coletadas pelo comando ANALYZE, que pode ser chamado por si prprio
ou como um passo opcional do comando VACUUM. importante que as estatsticas estejam razoavelmente precisas,
seno o desempenho do banco de dados poder ser degradado por planos mal escolhidos.
Assim como a execuo do comando VACUUM para recuperar espao, atualizaes frequentes das estatsticas so mais
teis para tabelas muito atualizadas que para tabelas raramente atualizadas, mas mesmo nas tabelas muito atualizadas
pode no haver necessidade de atualizar as estatsticas, se a distribuio dos dados no mudar muito. Uma regra emprica
simples pensar sobre quanto os valores mnimos e mximos das colunas da tabela mudam. Por exemplo, uma coluna
timestamp contendo a data e hora da atualizao da linha ter um valor mximo aumentando constantemente na medida
em que forem atualizadas ou adicionadas linhas tabela; esse tipo de coluna, provavelmente, precisa de atualizaes
mais frequentes das estatsticas do que, digamos, uma coluna contendo URLs de pginas acessadas em stios da Web. A
coluna URL pode ser modificada com a mesma frequncia, mas a distribuio estatstica de seus valores provavelmente
muda de forma relativamente lenta.
possvel executar o comando ANALYZE em tabelas especficas, e mesmo em colunas especficas da tabela. Portanto,
existe flexibilidade para atualizar algumas estatsticas com mais frequncia que outras se for requerido pela aplicao.
Entretanto, na prtica, a utilidade dessa funcionalidade duvidosa.
A prtica recomendada, para a maioria das instalaes, agendar a execuo do comando ANALYZE para todo o banco
de dados uma vez por dia, em horrio de pouca utilizao; til sua combinao com a execuo do comando VACUUM
todas as noites. Entretanto, nas instalaes onde as estatsticas das tabelas mudam de forma relativamente lenta,
pode-se considerar que essa frequncia seja demasiada, e que a execuo do comando ANALYZE com uma frequncia
mais baixa seja suficiente.
Dica 1: Embora possa no ser muito produtivo aumentar a frequncia de execuo do comando ANALYZE
por coluna, pode valer a pena fazer ajustes por coluna do nvel de detalhe das estatsticas coletadas pelo
comando ANALYZE. Colunas que so muito utilizadas em clusula WHERE, e que contm uma distribuio
de dados muito irregular, podem requerer um histograma dos dados com granulao mais fina que as demais.
Veja o comando ALTER TABLE SET STATISTICS.
3. Rotina de Reindexao
Em algumas situaes vale a pena reconstruir ndices periodicamente, utilizando o comando REINDEX. Existe, tambm,
a aplicao contrib/reindexdb que pode reindexar todo o banco de dados.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
110
4. Manuteno do Arquivo de Registro
uma boa ideia salvar a sada do registro (log) do servidor de banco de dados em algum lugar, em vez de simplesmente
direcionar para /dev/null. A sada do registro valiosa para fazer diagnstico de problemas. Entretanto, a sada do registro
tende a se tornar volumosa (especialmente nos nveis altos de depurao), e no ser desejado salv-la indefinidamente.
necessrio fazer a rotao dos arquivos de registro, para que sejam iniciados novos arquivos e os arquivos antigos
sejam removidos periodicamente.
Se for simplesmente direcionada a sada stderr do postmaster para um arquivo, haver uma sada de registro, mas a
nica maneira de truncar o arquivo de registro ser parando e reiniciando o postmaster, o que pode ser adequado em
um ambiente de desenvolvimento, mas poucos ambientes de produo vo considerar esse comportamento aceitvel.
Outra abordagem para gerenciar a sada do registro, apropriada para ambientes de produo, enviar a sada para syslog
e deixar que algum programa cuide da rotao do registro. Se for desejado automatizar a rotao do registro, pode ser
configurado o programa logrotate para trabalhar com os arquivos de registro do syslog
1
.
Como para tudo que contm dados importantes, devem ser feitas cpias de segurana dos bancos de dados regularmente.
Embora o procedimento seja essencialmente simples, importante possuir uma compreenso bsica das tcnicas e
princpios subjacentes.
Existem duas abordagens fundamentalmente diferentes para fazer cpia de segurana dos dados do PostgreSQL:
Mtodo SQL-dump.
Cpia de segurana no nvel de sistema operacional.
5. Mtodo SQL-dump
A ideia por trs do Mtodo SQL-dump gerar um arquivo texto contendo comandos SQL que, ao serem processados pelo
servidor, recriam o banco de dados no mesmo estado em que esse se encontrava quando o arquivo foi gerado.
O PostgreSQL disponibiliza o programa utilitrio pg_dump para essa finalidade. A forma bsica de utilizao desse
programa :
pg_dump nome_do_banco_de_dados > arquivo_de_sada
Conforme pode ser visto, o programa pg_dump escreve o seu resultado na sada padro. Ser visto abaixo como isso
pode ser til.
O pg_dump uma aplicao cliente normal do PostgreSQL (embora seja particularmente astuta). Isso significa que o
procedimento de cpia de segurana pode ser realizado a partir de qualquer hospedeiro remoto que possua acesso ao
banco de dados. Porm, deve ser lembrado que o pg_dump no opera com permisso especial. Em particular, necessrio
possuir acesso de leitura a todas as tabelas que se deseja fazer cpia de segurana. Portanto, na prtica, quase sempre
necessrio ser um superusurio do banco de dados.
Para especificar qual servidor de banco de dados o pg_dump deve se conectar devem ser utilizadas as opes de linha
de comando -h hospedeiro e -p porta. O hospedeiro padro o hospedeiro local, ou o que estiver especificado na varivel
de ambiente PGHOST. De maneira semelhante, a porta padro indicada pela varivel de ambiente PGPORT ou, na falta
dessa, pelo padro de compilao.
1 Syslog um mecanismo que permite que qualquer comando registre mensagens na console do sistema e/ou em um arquivo. O daemon syslogd recebe as mensagens dos comandos
e envia para o destino descrito no arquivo de configurao ( /etc/syslog.conf ). O syslogd daemon l a configurao quando inicializado e quando recebe um signal de hangup (
kill -HUP processo )
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
111
Assim como qualquer outra aplicao cliente do PostgreSQL, o pg_dump se conecta por padro ao banco de dados cujo
nome igual ao nome do usurio corrente do sistema operacional. Para que seja outro, deve ser especificada a opo
-U, ou definida a varivel de ambiente PGUSER. No deve ser esquecido que as conexes do pg_dump esto sujeitas aos
mecanismos normais de autenticao de cliente.
As cpias de segurana criadas pelo pg_dump so consistentes internamente, ou seja, as atualizaes feitas no banco
de dados enquanto o pg_dump est executando no esto presentes na cpia de segurana. O pg_dump no bloqueia
outras operaes no banco de dados enquanto est executando (Exceto as operaes que necessitam operar com modo
de bloqueio exclusivo, como o VACUUM FULL).
Dica 1: Quando o esquema do banco de dados dependente dos OIDs (como chaves-estrangeiras, por exemplo)
deve-se instruir o pg_dump para que tambm inclua os OIDs. Para que isso seja feito, deve ser utilizada
a opo de linha de comando -o. Tambm, no so feitas cpias de segurana dos objetos grandes por
padro. Se forem utilizados objetos grandes, deve ser vista a pgina de referncia do programa pg_dump .
5.1. Restaurao da Cpia de Segurana
Os arquivos-texto criados pelo programa pg_dump so feitos para serem lidos pelo programa psql. A forma geral do
comando para restaurar uma cpia de segurana :
psql nome_do_banco_de_dados < arquivo_de_entrada
O arquivo_de_entrada o que foi utilizado como arquivo_de_sada pelo programa pg_dump. O banco de dados nome_
do_banco_de_dados no ser criado por esse comando, devendo ser criado a partir de template0 antes de executar o
psql (por exemplo, usando createdb -T template0 nome_do_banco_de_dados). O psql possui opes semelhantes s do
pg_dump para controlar a identificao do servidor de banco de dados e o nome do usurio.
Se no banco de dados original os objetos pertencem a usurios diferentes, ento a cpia de segurana instrui o psql a
se conectar como cada usurio afetado por vez, e depois a criar os objetos relevantes. Dessa forma, o dono original
preservado. Entretanto, isso tambm significa que todos esses usurios devem existir, e que possvel se conectar como
cada um deles. Portanto, pode ser necessrio fazer um relaxamento temporrio das definies de autenticao de clientes.
Uma vez feita a restaurao, sensato executar o comando ANALYZE em cada um dos bancos de dados, para que o
otimizador possua estatsticas teis. Uma forma fcil de fazer executando vacuumdb -a -z para efetuar o VACUUM
ANALYZE de todos os bancos de dados; equivale a executar VACUUM ANALYZE manualmente.
A capacidade do pg_dump e do psql de escrever e ler de pipes torna possvel replicar um banco de dados de um servidor
para outro diretamente; por exemplo:
pg_dump -h hospedeiro1 nome_do_banco_de_dados | psql -h hospedeiro2 nome_do_banco_de_dados
Dica 1: As cpias de segurana produzidas pelo pg_dump so relativas a template0. Isso significa que todas
as linguagens, procedimentos, etc., adicionados a template1, tambm sero includos na cpia de segurana
feita pelo pg_dump. Como resultado, se estiver sendo utilizado um banco de dados template1 personalizado,
ao ser feita a restaurao deve ser criado um banco de dados vazio a partir de template0, conforme mostrado
no exemplo acima.
5.2. Utilizao do pg_dumpall
O mecanismo mostrado acima no cmodo nem apropriado para fazer a cpia de segurana de todo o agrupamento de
bancos de dados. Por esse motivo, fornecido o programa pg_dumpall . O pg_dumpall faz a cpia de segurana de todos
os bancos de dados de um agrupamento, e tambm salva dados de todo o agrupamento, como os usurios e grupos. A
forma bsica de utilizao desse programa :
pg_dumpall > arquivo_de_sada
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
112
A cpia de segurana gerada pode ser restaurada pelo psql usando:
psql template1 < arquivo_de_entrada
Na verdade, pode ser especificado qualquer nome de banco de dados existente para comear, mas se estiver sendo feita
a restaurao em um agrupamento vazio, ento template1 a nica escolha disponvel. sempre necessrio possuir
acesso de superusurio do banco de dados para fazer a restaurao de uma cpia de segurana gerada pelo pg_dumpall,
para poder restaurar as informaes de usurio e de grupo.
5.3. Tratamento de Bancos de Dados Grandes
Uma vez que o PostgreSQL permite a existncia de tabelas maiores do que o tamanho mximo de arquivo do sistema
operacional, pode ser problemtico fazer a cpia de segurana de uma tabela como essa em um arquivo, uma vez que
o arquivo resultante provavelmente ser maior do que o tamanho mximo permitido pelo sistema operacional. Como o
pg_dump pode escrever na sada padro, podem ser utilizadas as ferramentas padro do Unix para superar esse possvel
problema.
5.3.1. Utilizao de cpias de segurana comprimidas.
Pode ser utilizado o programa de compresso favorito como, por exemplo, o gzip.
pg_dump nome_do_banco_de_dados | gzip > nome_do_arquivo.gz
Restaurar com o seguinte comando:
createdb nome_do_banco_de_dados
gunzip -c nome_do_arquivo.gz | psql nome_do_banco_de_dados
ou
cat nome_do_arquivo.gz | gunzip | psql nome_do_banco_de_dados
5.3.2. Utilizao do comando split.
O comando split permite dividir a sada em blocos de tamanho aceitvel para o sistema de arquivos subjacente. Por
exemplo, para fazer blocos de 1 megabyte:
pg_dump nome_do_banco_de_dados | split -b 1m - nome_do_arquivo
Restaurar com
createdb nome_do_banco_de_dados
cat nome_do_arquivo* | psql nome_do_banco_de_dados
5.3.3. Utilizao de formatos de cpia de segurana personalizados.
Se o PostgreSQL foi construdo em um sistema com a biblioteca de compresso zlib instalada, o formato de cpia de
segurana personalizado comprime os dados ao escrever o arquivo de sada. Produz cpias de segurana com tamanhos
semelhantes s produzidas, utilizando o gzip, mas tem a vantagem adicional de permitir a restaurao seletiva das
tabelas. O comando abaixo gera a cpia de segurana do banco de dados, utilizando o formato de cpia de segurana
personalizado (custom dump format):
pg_dump -Fc nome_do_banco_de_dados > nome_do_arquivo
O formato de cpia de segurana personalizado no um script para o psql, devendo ser restaurado pelo pg_restore.
Para obter detalhes devem ser vistas as pginas de referncia do pg_dump e do pg_restore .
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
113
5.4. Precaues
O pg_dump (e consequentemente o pg_dumpall) possui algumas poucas limitaes causadas pela dificuldade de reconstruir
certas informaes a partir dos catlogos do sistema.
Especificamente, a ordem utilizada pelo pg_dump para escrever os objetos no muito sofisticada. Isso pode causar problemas
como, por exemplo, quando so utilizadas funes como valor padro de colunas. A nica soluo reorganizar manualmente
a cpia de segurana. Se forem criadas dependncias circulares no esquema, ento haver mais trabalho a ser feito.
Por motivo de compatibilidade com as verses anteriores, o pg_dump no faz cpia de segurana dos objetos grandes
por padro. Para fazer cpia de segurana dos objetos grandes deve ser utilizado o formato de sada personalizado ou o
formato tar, e utilizada a opo -b do pg_dump. Para obter detalhes deve ser vista a pgina de referncia do pg_dump.
O diretrio contrib/pg_dumplo, da rvore do cdigo fonte do PostgreSQL, tambm contm um programa que pode ser
utilizado para fazer cpias de segurana dos objetos grandes.
6. Cpia de Segurana no Nvel de Sistema de Arquivo
Uma estratgia alternativa para fazer cpia de segurana, copiar diretamente os arquivos que o PostgreSQL usa para
armazenar os dados dos bancos de dados. Pode ser utilizada a forma preferida para fazer as cpias de segurana usuais
dos arquivos do sistema como, por exemplo:
tar -cf copia_de_seguranca.tar /usr/local/pgsql/data
Entretanto, existem duas restries que fazem com que esse mtodo seja impraticvel ou, pelo menos, inferior ao pg_dump:
1. O servidor de banco de dados deve estar parado para que se possa obter uma cpia de segurana
utilizvel. Meias medidas, como impedir todas as conexes, no funcionam, porque sempre existe
alguma buferizao em andamento. Por essa razo tambm no aconselhvel confiar em sistemas
de arquivo que dizem suportar instantneos consistentes (consistent snapshots). desnecessrio
dizer que, tambm, necessrio parar o servidor antes de restaurar os dados.
2. Caso tenha se aprofundado nos detalhes da organizao do sistema de arquivos do banco de dados,
poder estar tentado a fazer cpias de segurana ou restaurao de apenas algumas determinadas
tabelas ou bancos de dados a partir de seus respectivos arquivos ou diretrios. Isso no funciona,
porque as informaes contidas nesses arquivos possuem apenas meia verdade. A outra metade est
nos arquivos de registro de efetivao pg_clog/*, que contm o status de efetivao de todas as
transaes. O arquivo da tabela somente possui utilidade com essa informao. claro que tambm
no possvel restaurar apenas uma tabela e seus dados associados em pg_clog, porque isso torna
todas as outras tabelas do agrupamento de bancos de dados inteis. Portanto, as cpias de segurana
do sistema de arquivos somente funcionam para a restaurao completa de todo o agrupamento de
bancos de dados.
Uma abordagem alternativa para cpias de segurana do sistema de arquivos fazer um instantneo consistente do
diretrio de dados, se o sistema de arquivos possuir essa funcionalidade (e se h confiana que foi implementado de
forma correta). Esse tipo de instantneo salva os arquivos do banco de dados em um estado onde o servidor de banco
de dados no foi parado de forma apropriada; portanto, quando o servidor de banco de dados iniciado acessando um
diretrio restaurado a partir de uma cpia de segurana desse tipo, considera que o servidor caiu e refaz o registro do
WAL. Isso no um problema, mas deve-se estar atento a esse fato (e certifique-se de incluir os arquivos do WAL na
cpia de segurana).
Deve ser observado que a cpia de segurana do sistema de arquivos no ser necessariamente menor que a do Mtodo
SQL-dump. Ao contrrio, mais provvel que seja maior; por exemplo, o pg_dump no necessita fazer cpia de segurana
dos ndices, mas apenas dos comandos para recri-los.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
114
7. Cpia de segurana em-linha
Durante todo o tempo, o PostgreSQL mantm o registro de escrita prvia (WAL = write ahead log) no subdiretrio
pg_xlog do diretrio de dados do agrupamento. O WAL contm todas as alteraes realizadas nos arquivos de dados
do banco de dados. O WAL existe, principalmente, com a finalidade de fornecer segurana contra quedas: se o sistema
cair, o banco de dados pode retornar a um estado consistente, refazendo as entradas gravadas desde o ltimo ponto
de verificao. Entretanto, a existncia do WAL torna possvel uma terceira estratgia para fazer cpia de segurana
de banco de dados: pode ser combinada a cpia de segurana do banco de dados, no nvel de sistema de arquivos, com
cpia dos arquivos de segmento do WAL. Se for necessrio fazer a recuperao, pode ser feita a recuperao da cpia
de segurana do banco de dados no nvel de sistema de arquivos e, depois, refeitas as alteraes a partir da cpia dos
arquivos de segmento do WAL, para trazer a restaurao para o tempo presente.
A administrao dessa abordagem mais complexa que a administrao das abordagens anteriores, mas existem alguns
benefcios significativos:
O ponto de partida no precisa ser uma cpia de segurana totalmente consistente. Toda inconsistncia
interna na cpia de segurana corrigida quando o WAL refeito (o que no muito diferente do que
acontece durante a recuperao de uma queda). Portanto, no necessrio um sistema operacional com
capacidade de tirar instantneos, basta apenas o tar, ou outra ferramenta semelhante.
Como pode ser reunida uma sequncia indefinidamente longa de arquivos de segmento do WAL para serem
refeitos, pode ser obtida uma cpia de segurana contnua simplesmente continuando a fazer cpias dos
arquivos de segmento do WAL. Isso particularmente til para bancos de dados grandes, onde pode no ser
conveniente fazer cpias de segurana completas regularmente.
No existe nada que diga que as entradas do WAL devem ser refeitas at o fim. Pode-se parar de refazer
em qualquer ponto, e obter um instantneo consistente do banco de dados como se tivesse sido tirado no
instante da parada. Portanto, essa tcnica suporta a recuperao para um determinado ponto no tempo:
possvel restaurar voltando o banco de dados para o estado em que se encontrava a qualquer instante
posterior ao da realizao da cpia de segurana base.
Se outra mquina, carregada com a mesma cpia de segurana base do banco de dados, for alimentada
continuamente com a srie de arquivos de segmento do WAL, ser criado um sistema reserva a quente (hot
standby): a qualquer instante essa outra mquina pode ser ativada com uma cpia quase atual do banco de
dados.
Da mesma forma que o mtodo de cpia de segurana no nvel de sistema de arquivos simples, esse mtodo suporta
apenas a restaurao de todo o agrupamento de bancos de dados, e no a restaurao de apenas um subconjunto desse.
Requer, tambm, grande volume de armazenamento de arquivos: a cpia de segurana base pode ser grande, e um sistema
carregado gera vrios megabytes de trfego para o WAL que precisam ser guardados. Ainda assim, o mtodo de cpia
de segurana preferido para muitas situaes onde necessria uma alta confiabilidade.
Para fazer uma recuperao bem-sucedida utilizando cpia de segurana em-linha, necessria uma sequncia contnua de
arquivos de segmento do WAL guardados, que venha desde, pelo menos, o instante em que foi feita a cpia de segurana
base do banco de dados. Para comear, deve ser configurado e testado o procedimento para fazer cpia dos arquivos de
segmento do WAL, antes de ser feita a cpia de segurana base do banco de dados. Assim sendo, primeiro ser explicada
a mecnica para fazer cpia dos arquivos de segmento do WAL.
7.1. Cpia dos arquivos de segmento do WAL
Em um sentido abstrato, a execuo do sistema PostgreSQL produz uma sequncia indefinidamente longa de entradas
no WAL. O sistema divide fisicamente essa sequncia em arquivos de segmento do WAL, normalmente com 16 MB cada
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
115
(embora o tamanho possa ser alterado durante a construo do PostgreSQL). So atribudos nomes numricos aos arquivos
de segmento para refletir sua posio na sequncia abstrata do WAL. Quando no feita cpia dos arquivos de segmento
do WAL, normalmente o sistema cria apenas uns poucos arquivos de segmento e, depois, recicla-os, renomeando os
arquivos que no so mais de interesse com nmero de segmento mais alto. Assume-se no existir mais interesse em um
arquivo de segmento cujo contedo preceda o ponto de verificao anterior ao ltimo, podendo, portanto, ser reciclado.
Quando feita a cpia dos arquivos de segmento do WAL, deseja-se capturar o contedo de cada arquivo quando esse
completado, guardando os dados em algum lugar antes do arquivo de segmento ser reciclado para ser reutilizado.
Dependendo da aplicao e dos perifricos disponveis, podem haver muitas maneiras de guardar os dados em algum
lugar: os arquivos de segmento podem ser copiados para outra mquina usando um diretrio NFS montado, podem ser
escritos em uma unidade de fita (havendo garantia que os arquivos podero ser restaurados com seus nomes originais),
podem ser agrupados e gravados em CD, ou de alguma outra forma. Para que o administrador de banco de dados tenha a
mxima flexibilidade possvel, o PostgreSQL tenta no assumir nada sobre como as cpias sero feitas. Em vez disso, o
PostgreSQL deixa o administrador escolher o comando a ser executado para copiar o arquivo de segmento completado para
o local de destino. O comando pode ser to simples como cp, ou pode envolver um script complexo para o interpretador
de comandos tudo depende do administrador.
O comando a ser executado especificado por meio do parmetro de configurao archive_command, que, na prtica,
sempre colocado no arquivo postgresql.conf. Na cadeia de caracteres do comando, todo %p substitudo pelo caminho
absoluto do arquivo a ser copiado, enquanto todo %f substitudo pelo nome do arquivo apenas. Se for necessrio
incorporar o caractere % ao comando, deve ser escrito %%. A forma mais simples de um comando til algo como:
archive_command = cp -i %p /mnt/servidor/dir_copias/%f </dev/null
Esse comando ir copiar os arquivos de segmento do WAL, prontos para serem copiados, para o diretrio /mnt/servidor/
dir_copias (Isso um exemplo, e no uma recomendao, e pode no funcionar em todas as plataformas).
O comando para realizar a cpia executado sob a propriedade do mesmo usurio que est executando o servidor
PostgreSQL. Como a srie de arquivos do WAL contm efetivamente tudo que est no banco de dados, deve haver
certeza que a cpia est protegida contra olhos curiosos; por exemplo, colocando a cpia em diretrio sem acesso para
grupo ou para todos.
importante que o comando para realizar a cpia retorne o status de sada zero se, e somente se, for bem-sucedido. Ao
receber o resultado zero, o PostgreSQL assume que a cpia do arquivo de segmento do WAL foi bem-sucedida, e remove
ou recicla o arquivo de segmento. Entretanto, um status diferente de zero informa ao PostgreSQL que o arquivo no foi
copiado; sero feitas tentativas peridicas at ser bem-sucedida.
Geralmente o comando de cpia deve ser projetado de tal forma que no sobrescreva algum arquivo de cpia preexistente.
Essa uma caracterstica de segurana importante para preservar a integridade da cpia no caso de um erro do
administrador (tal como enviar a sada de dois servidores diferentes para o mesmo diretrio de cpias). Aconselha-se a
testar o comando de cpia proposto para ter certeza que no sobrescreve um arquivo existente, e que retorna um status
diferente de zero nesse caso. Tem sido observado que cp -i faz isso corretamente em algumas plataformas, mas no em
outras. Se o comando escolhido no tratar esse caso corretamente por conta prpria, deve ser adicionado um comando
para testar a existncia do arquivo de cpia. Por exemplo, algo como:
archive_command = test ! -f .../%f && cp %p .../%f
Ao projetar a configurao de cpia deve ser considerado o que vai acontecer quando o comando de cpia falhar repetidas
vezes, seja porque alguma funcionalidade requer interveno do operador, ou porque no h espao para armazenar a
cpia. Essa situao pode ocorrer, por exemplo, quando a cpia escrita em fita e no h um sistema automtico para
troca de fitas: quando a fita ficar cheia, no ser possvel fazer outras cpias enquanto no for trocada. Deve-se garantir
que qualquer condio de erro, ou solicitao feita a um operador humano, seja relatada de forma apropriada para que
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
116
a situao possa ser resolvida o mais rpido possvel. Enquanto a situao no for resolvida, continuaro sendo criados
novos arquivos de segmento do WAL no diretrio pg_xlog.
A velocidade do comando de cpia no importante, desde que possa acompanhar a taxa mdia de gerao de dados
para o WAL. A operao normal prossegue mesmo que o processo de cpia fique um pouco atrasado. Se o processo de
cpia ficar muito atrasado, vai aumentar a quantidade de dados perdidos caso ocorra um desastre. Significa, tambm,
que o diretrio pg_xlog vai conter um nmero grande de arquivos de segmento que ainda no foram copiados, podendo,
inclusive, exceder o espao livre em disco. Aconselha-se que o processo de cpia seja monitorado para garantir que
esteja funcionando da forma planejada.
Havendo preocupao em se poder recuperar at o presente instante, devem ser efetuados passos adicionais para garantir
que o arquivo de segmento do WAL corrente, parcialmente preenchido, tambm seja copiado para algum lugar. Isso
particularmente importante no caso do servidor gerar pouco trfego para o WAL (ou tiver perodos ociosos onde isso
acontece), uma vez que pode levar muito tempo at que o arquivo de segmento fique totalmente preenchido e pronto para
ser copiado. Uma forma possvel de tratar essa situao definir uma entrada no cron [1] que, periodicamente, talvez
uma vez por minuto, identifique o arquivo de segmento do WAL corrente e o guarde em algum lugar seguro. Ento, a
combinao dos arquivos de segmento do WAL guardados, com o arquivo de segmento do WAL corrente guardado, ser
suficiente para garantir que o banco de dados pode ser restaurado at um minuto, ou menos, antes do presente instante.
Atualmente esse comportamento no est presente no PostgreSQL, porque no se deseja complicar a definio de
archive_command requerendo que esse acompanhe cpias bem-sucedidas, mas diferentes, do mesmo arquivo do WAL. O
archive_command chamado apenas para segmentos do WAL completados. Exceto no caso de novas tentativas devido
falha, s chamado uma vez para um determinado nome de arquivo.
Ao escrever o comando de cpia, deve ser assumido que os nomes dos arquivos a serem copiados podem ter comprimento
de at 64 caracteres, e que podem conter qualquer combinao de letras ASCII, dgitos e pontos. No necessrio
recordar o caminho original completo (%p), mas necessrio recordar o nome do arquivo (%f).
Deve ser lembrado que embora a cpia do WAL permita restaurar toda modificao feita nos dados dos bancos de dados do
PostgreSQL, no restaura a alteraes feitas nos arquivos de configurao (ou seja, nos arquivos postgresql.conf, pg_hba.
conf e pg_ident.conf), uma vez que esses arquivos so editados manualmente, em vez de por meio de operaes SQL.
O procedimento para fazer a cpia de segurana base relativamente simples:
1. Garantir que a cpia dos arquivos de segmento do WAL esteja ativada e funcionando.
2. Conectar ao banco de dados como um superusurio e executar o comando.
3. Utiliza SELECT pg_start_backup(rtulo); onde rtulo qualquer cadeia de caracteres que se deseje
usar para identificar unicamente essa operao de cpia de segurana (Uma boa prtica utilizar o
caminho completo de onde se deseja colocar o arquivo de cpia de segurana). A funo pg_start_backup
cria o arquivo rtulo da cpia de segurana, chamado backup_label, com informaes sobre a cpia de
segurana, no diretrio do agrupamento. Para executar esse comando, no importa qual banco de dados
do agrupamento usado para fazer a conexo. O resultado retornado pela funo pode ser ignorado;
mas se for relatado um erro, esse deve ser tratado antes de prosseguir.
4. Realizar a cpia de segurana utilizando qualquer ferramenta conveniente para cpia de segurana do
sistema de arquivos, como tar ou cpio. No necessrio, nem desejado, parar a operao normal do
banco de dados enquanto a cpia feita.
5. Conectar novamente ao banco de dados como um superusurio e executar o comando: SELECT
pg_stop_backup(); Se a execuo for bem sucedida, est terminado.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
117
No necessrio ficar muito preocupado com o tempo decorrido entre a execuo de pg_start_backup e o incio da
realizao da cpia de segurana, nem entre o fim da realizao da cpia de segurana e a execuo de pg_stop_backup;
uns poucos minutos de atraso no vo criar nenhum problema. Entretanto, deve haver certeza que as operaes so
realizadas sequencialmente, sem que haja sobreposio.
Deve haver certeza que a cpia de segurana inclui todos os arquivos sob o diretrio do agrupamento de bancos de
dados (por exemplo, /usr/local/pgsql/data). Se estiverem sendo utilizados espaos de tabelas que no residem sob esse
diretrio, deve-se ter o cuidado de inclu-los tambm (e ter certeza que a cpia de segurana guarda vnculos simblicos
como vnculos, seno a restaurao vai danificar os espaos de tabelas).
Entretanto, podem ser omitidos da cpia de segurana os arquivos sob o subdiretrio pg_xlog do diretrio do agrupamento.
Essa pequena complicao a mais vale a pena ser feita porque reduz o risco de erros na restaurao. fcil de ser feito
se pg_xlog for um vnculo simblico apontando para algum lugar fora do agrupamento, o que uma configurao comum
por razes de desempenho.
Para poder utilizar essa cpia de segurana base, devem ser mantidas por perto todas as cpias dos arquivos de segmento
do WAL gerados no momento ou aps o incio da mesma. Para ajudar a realizar essa tarefa, a funo pg_stop_backup
cria o arquivo de histrico de cpia de segurana, que armazenado imediatamente na rea de cpia do WAL. Esse
arquivo recebe um nome derivado do primeiro arquivo de segmento do WAL, que necessrio possuir para fazer uso da
cpia de segurana.
Por exemplo, se o arquivo do WAL tiver o nome 0000000100001234000055CD, o arquivo de histrico de cpia de
segurana vai ter um nome parecido com 0000000100001234000055CD.007C9330.backup. A segunda parte do nome
do arquivo representa a posio exata dentro do arquivo do WAL, podendo normalmente ser ignorada.
Uma vez que o arquivo contendo a cpia de segurana base tenha sido guardado em local seguro, podem ser apagados
todos os arquivos de segmento do WAL com nomes numericamente precedentes a esse nmero. O arquivo de histrico
de cpia de segurana apenas um pequeno arquivo texto. Contm a cadeia de caracteres rtulo fornecida funo
pg_start_backup, assim como as horas de incio e fim da cpia de segurana. Se o rtulo for utilizado para identificar
onde est armazenada a cpia de segurana base do banco de dados, ento basta o arquivo de histrico de cpia de
segurana para se saber qual o arquivo de cpia de segurana a ser restaurado, no caso disso precisar ser feito.
Uma vez que necessrio manter por perto todos os arquivos de segmento do WAL copiados desde a ltima cpia de
segurana base, o intervalo entre essas cpias de segurana geralmente deve ser escolhido tendo por base quanto
armazenamento se deseja consumir para os arquivos do WAL guardados.
Tambm deve ser considerado quanto tempo se est preparado para despender com a restaurao, no caso de ser
necessrio fazer uma restaurao o sistema ter que refazer todos os segmentos do WAL, o que pode ser muito
demorado se tiver sido decorrido muito tempo desde a ltima cpia de segurana base.
Tambm vale a pena notar que a funo pg_start_backup cria no diretrio do agrupamento de bancos de dados um
arquivo chamado backup_label, que depois removido pela funo pg_stop_backup. Esse arquivo fica guardado como
parte do arquivo de cpia de segurana base. O arquivo rtulo de cpia de segurana inclui a cadeia de caracteres rtulo
fornecida para a funo pg_start_backup, assim como a hora em que pg_start_backup foi executada, e o nome do
arquivo de segmento inicial do WAL. Em caso de dvida, possvel olhar dentro do arquivo de cpia de segurana base
e determinar com exatido de qual sesso de cpia de segurana esse arquivo provm.
Tambm possvel fazer a cpia de segurana base enquanto o postmaster est parado. Nesse caso, obviamente no
podem ser utilizadas as funes pg_start_backup e pg_stop_backup, sendo responsabilidade do administrador controlar a
que cpia de segurana cada arquivo pertence, e at quanto tempo atrs os arquivos de segmento do WAL associados vo.
Geralmente melhor seguir os procedimentos para cpia de segurana mostrados acima.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
118
7.2. Recuperao a partir de cpia de segurana em-linha
Suponhamos que seja necessrio recuperar a partir da cpia de segurana. O procedimento est mostrado abaixo:
1. Parar o postmaster, se estiver executando.
2. Copiar, se houver espao para isso, todo o diretrio de dados do agrupamento, e todos os espaos de
tabelas, para um lugar temporrio, para o caso de necessidade. Deve ser observado que essa medida
de precauo requer que haja espao no sistema suficiente para manter duas cpias do banco de
dados existente. Se no houver espao suficiente, necessrio pelo menos uma cpia do contedo do
subdiretrio pg_xlog do diretrio de dados do agrupamento, porque pode conter arquivos de segmento
do WAL que no foram copiados quando o sistema parou.
3. Apagar todos os arquivos e subdiretrios existentes sob o diretrio de dados do agrupamento, e sob os
diretrios raiz dos espaos de tabelas em uso.
4. Restaurar os arquivos do banco de dados a partir da cpia de segurana base. Deve-se tomar cuidado
para que sejam restaurados com o dono correto (o usurio do sistema de banco de dados, e no o
usurio root), e com as permisses corretas. Se estiverem sendo utilizados espaos de tabelas, deve
ser verificado se foram restaurados corretamente os vnculos simblicos no subdiretrio pg_tblspc/.
5. Remover todos os arquivos presentes no subdiretrio pg_xlog; porque esses vm da cpia de segurana
base e, portanto, provavelmente esto obsoletos. Se o subdiretrio pg_xlog no fizer parte da cpia
de segurana base, ento esse subdiretrio deve ser criado, assim como o subdiretrio pg_xlog/
archive_status.
6. Copiar para o diretrio pg_xlog, arquivos de segmento do WAL, porventura existentes e que no foram
copiados para o diretrio de cpias, mas que foram salvos no passo 2; melhor copi-los em vez de
mov-los, para que ainda existam arquivos no modificados, caso ocorra algum problema e o processo
tenha de ser recomeado.
7. Criar o arquivo de comando de recuperao recovery.conf no diretrio de dados do agrupamento (consulte
Recovery Settings). Tambm pode ser til modificar temporariamente o arquivo pg_hba.conf, para impedir
que os usurios comuns se conectem at que se tenha certeza que a recuperao foi bem-sucedida.
8. Iniciar o postmaster. O postmaster vai entrar no modo de recuperao e prosseguir lendo os arquivos do
WAL necessrios. Aps o trmino do processo de recuperao, o postmaster muda o nome do arquivo
recovery.conf para recovery.done (para impedir que entre novamente no modo de recuperao no caso
de uma queda posterior), e depois comea as operaes normais de banco de dados.
9. Deve ser feita a inspeo do contedo do banco de dados para garantir que a recuperao foi feita
at onde deveria ser feita. Caso contrrio, deve-se retornar ao passo 1. Se tudo correu bem, liberar o
acesso aos usurios retornando pg_hba.conf sua condio normal.
A parte chave de todo esse procedimento a definio do arquivo contendo o comando de recuperao, que descreve
como se deseja fazer a recuperao, e at onde a recuperao deve ir. Pode ser utilizado o arquivo recovery.conf.sample
(geralmente presente no diretrio de instalao share) na forma de um prottipo
1
.
O nico parmetro requerido no arquivo recovery.conf restore_command, que informa ao PostgreSQL como trazer de
volta os arquivos de segmento do WAL copiados. Como no archive_command, esse parmetro uma cadeia de caracteres
para o interpretador de comandos. Pode conter %f, que substitudo pelo nome do arquivo do WAL a ser trazido de volta,
e %p, que substitudo pelo caminho absoluto para onde o arquivo do WAL ser copiado. Se for necessrio incorporar o
caractere % ao comando, deve ser escrito %%. A forma mais simples de um comando til algo como:
1 O arquivo recovery.conf.sample est presente no diretrio /src/backend/access/transam da distribuio do cdigo fonte e do CVS. (N. do T.)
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
119
restore_command = cp /mnt/servidor/dir_copias/%f %p
Esse comando ir copiar os arquivos de segmento do WAL previamente guardados a partir do diretrio /mnt/servidor/
dir_copias. claro que pode ser utilizado algo muito mais complicado, talvez um script que solicite ao operador a
montagem da fita apropriada.
importante que o comando retorne um status de sada diferente de zero em caso de falha. Ser solicitado ao comando
os arquivos do WAL cujos nomes no estejam presente entre as cpias; deve retornar um status diferente de zero quando
for feita a solicitao. Essa no uma condio de erro. Deve-se tomar cuidado para que o nome base do caminho %p
seja diferente de %f; no deve ser esperado que sejam intercambiveis.
Os arquivos de segmento do WAL que no puderem ser encontrados entre as cpias, sero procurados no diretrio pg_xlog/;
isto permite que os arquivos de segmento recentes, ainda no copiados, sejam utilizados. Entretanto, os arquivos de
segmento que estiverem entre as cpias tero preferncia sobre os arquivos em pg_xlog. O sistema no sobrescreve os
arquivos presentes em pg_xlog quando busca os arquivos guardados.
Normalmente, a recuperao prossegue por meio de todos os arquivos de segmento do WAL, portanto restaurando o banco
de dados at o presente momento (ou to prximo quanto se pode chegar utilizando os segmentos do WAL). Mas se for
necessrio recuperar at algum ponto anterior no tempo (digamos, logo antes do DBA jnior ter apagado a tabela principal
de transao de algum), deve-se simplesmente especificar no arquivo recovery.conf o ponto de parada requerido. O ponto
de parada, conhecido como destino da recuperao, pode ser especificado tanto pela data e hora quanto pelo trmino
de um ID de transao especfico. At o momento em que este manual foi escrito, somente podia ser utilizada a opo
data e hora, pela falta de ferramenta para ajudar a descobrir com preciso o identificador de transao a ser utilizado.
Dica 1: O ponto de parada deve estar situado aps o momento de trmino da cpia de segurana base (o
momento em que foi executada a funo pg_stop_backup). A cpia de segurana no pode ser utilizada
para recuperar at um momento em que a cpia de segurana base estava em andamento (Para recuperar
at esse ponto, deve-se retornar para uma cpia de segurana base anterior e refazer a partir dessa cpia).
7.2.1. Definies de recuperao
Essas definies somente podem ser feitas no arquivo recovery.conf, e so aplicadas apenas durante a recuperao. As
definies devero ser definidas novamente nas prximas recuperaes que se desejar realizar. As definies no podem
ser alteradas aps a recuperao ter comeado.
1. restore_command (string): O comando, para o interpretador de comandos, a ser executado para trazer
de volta os segmentos da srie de arquivos do WAL guardados. Esse parmetro requerido. Todo %f
presente na cadeia de caracteres substitudo pelo nome do arquivo a ser trazido de volta das cpias,
e todo %p substitudo pelo caminho absoluto para onde o arquivo ser copiado no servidor. Se for
necessrio incorporar o caractere % ao comando, deve ser escrito %%. importante que o comando
retorne o status de sada zero se, e somente se, for bem-sucedido. Ser solicitado ao comando os
arquivos cujos nomes no estejam presentes entre as cpias; deve retornar um status diferente de zero
quando for feita a solicitao.
2. recovery_target_time (timestamp): Esse parmetro especifica o caminho do tempo at onde a
recuperao deve prosseguir. Somente pode ser especificado um entre recovery_target_time e
recovery_target_xid. O padro recuperar at o fim do WAL. O ponto de parada preciso tambm
influenciado por recovery_target_inclusive.
3. recovery_target_xid (string): Esse parmetro especifica o identificador de transao at onde a
recuperao deve prosseguir. Deve-se ter em mente que enquanto os identificadores so atribudos
sequencialmente no incio da transao, as transaes podem ficar completas em uma ordem numrica
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
120
diferente. As transaes que sero recuperadas so aquelas que foram efetivadas antes (e opcionalmente
incluindo) da transao especificada. Somente pode ser especificado um entre recovery_target_xid e
recovery_target_time. O padro recuperar at o fim do WAL. O ponto de parada preciso tambm
influenciado por recovery_target_inclusive.
4. recovery_target_inclusive (boolean): Especifica se a parada deve acontecer logo aps o destino de
recuperao especificado (true), ou logo antes do destino de recuperao especificado (false). Aplica-
se tanto a recovery_target_time quanto a recovery_target_xid, o que for especificado para essa
recuperao. Indica se as transaes que possuem exatamente a hora de efetivao ou o identificador
de destino, respectivamente, sero includas na recuperao. O valor padro true.
5. recovery_target_timeline (string): Especifica a recuperao de uma determinada cronologia. O padro
recuperar ao longo da cronologia que era a cronologia corrente quando foi feita a cpia de segurana
base. Somente ser necessrio definir esse parmetro em situaes de re-recuperaes complexas,
onde necessrio retornar para um estado a que se chegou aps uma recuperao para um ponto no
tempo.
7.3. Cronologias
A capacidade de restaurar um banco de dados para um determinado ponto anterior no tempo cria algumas complexidades
que so semelhantes s das narrativas de fico cientfica sobre viagem no tempo e universos paralelos. Por exemplo,
na histria original do banco de dados talvez tenha sido removida uma tabela importante s 5:15 da tarde de tera-feira.
Imperturbvel, o administrador pega a cpia de segurana e faz uma restaurao para o ponto no tempo 5:14 da tarde
de tera feira, e o sistema volta a funcionar. Nessa histria do universo do banco de dados, a tabela nunca foi removida.
Mas suponha que mais tarde seja descoberto que essa no foi uma boa ideia, e que se deseja voltar para algum ponto
posterior da histria original. Mas isso no poder ser feito, porque quando o banco de dados foi posto em atividade
esse sobrescreveu alguns dos arquivos de segmento do WAL que levariam ao ponto no tempo onde agora quer se chegar.
Portanto, realmente necessrio fazer distino entre a srie de entradas no WAL geradas aps a recuperao para um
ponto no tempo, e aquelas geradas durante a histria original do banco de dados.
Para lidar com esses problemas, o PostgreSQL possui a noo de cronologias (timelines). Cada vez que feita uma
recuperao no tempo anterior ao fim da sequncia do WAL, criada uma nova cronologia para identificar a srie de
registros do WAL geradas aps a recuperao (entretanto, se a recuperao prosseguir at o final do WAL, no criada
uma nova cronologia: apenas se estende a cronologia existente). O nmero identificador da cronologia parte dos
nomes dos arquivos de segmento do WAL e, portanto, uma nova cronologia no sobrescreve os dados do WAL gerados
pelas cronologias anteriores. possvel, na verdade, guardar muitas cronologias diferentes. Embora possa parecer uma
funcionalidade sem utilidade, muitas vezes de grande valia. Considere a situao onde no se tem certeza absoluta de
at que ponto no tempo deve ser feita a recuperao e, portanto, devem ser feitas muitas tentativas de recuperao at
ser encontrado o melhor lugar para se desviar da histria antiga. Sem as cronologias, esse processo em pouco tempo
cria uma confuso impossvel de ser gerenciada. Com as cronologias, pode ser feita a recuperao at qualquer estado
anterior, inclusive os estados no desvio de cronologia abandonados posteriormente.
Toda vez que criada uma nova cronologia, o PostgreSQL cria um arquivo de histria da cronologia, que mostra de
que cronologia foi feito o desvio, e quando. Os arquivos de cronologia so necessrios para permitir o sistema buscar
os arquivos de segmento do WAL corretos ao fazer a recuperao a partir de uma rea de cpias que contm vrias
cronologias. Portanto, esses arquivos so guardados na rea de cpias como qualquer arquivo de segmento do WAL. Os
arquivos de cronologia so apenas pequenos arquivos-texto sendo, portanto, barato e apropriado mant-los guardados
indefinidamente (ao contrrio dos arquivos de segmento que so grandes). possvel, caso se deseje faz-lo, adicionar
comentrios aos arquivos de cronologia para fazer anotaes personalizadas sobre como e porque foi criada uma
determinada cronologia. Esses comentrios so muito teis quando h um grande nmero de cronologias criadas como
resultado de experincias.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
121
O comportamento padro de recuperao faz-lo ao longo da cronologia, que era a cronologia corrente quando foi feita
a cpia de segurana base. Se for desejado executar a recuperao utilizando uma cronologia filha (ou seja, deseja-se
retornar para algum estado que foi gerado aps uma tentativa de recuperao), necessrio especificar o identificador
da cronologia de destino no arquivo recovery.conf. No possvel fazer a recuperao para um estado que foi um desvio
anterior cpia de segurana base.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
122
Para (no) Finalizar
Ao chegarmos ao final da disciplina, esperamos que os conhecimentos aqui transcritos e os trabalhos desenvolvidos
tenham contribudo no sentido de incrementar suas habilidades no trato com Sistemas de Gerenciamento de Banco de
Dados, bem como para despertar para a importncia do tema.
No intuito de aprimorarmos o nosso trabalho, solicitamos que sejam enviadas sugestes ou crticas sobre a disciplina
para o tutor.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
123
Referncias
ALVES, W. P. Fundamentos de banco de dados. 1. Ed. So Paulo: rica, 2004
CODD, E. F. A relational model of data for large shared data banks. Revista CACM volume = 6,1970
_____. Further normalization of the data base relational model, In: Rustin [1972], pg 33-64 (1972).
DATE, C. J. Introduo a sistemas de bancos de dados. Rio de Janeiro: Campus, 1983.
ELMASRI, R. Sistema de banco de dados - Fundamentos e Aplicaes, 4. Ed. s/l: Pearson Education, s/d.
HEUSER, C. A. Projeto de banco de dados, 4. ed. Porto Alegre: Livros Didticos, Porto Alegre, 2001
_____. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2000.
KORTH, H. F.; SILBERSCHATZ, A. Sistema de banco de dados. So Paulo: Makron Books, 1995.
KROENKE, D. M. Banco de dados fundamentos, projeto e implementao. Rio de Janeiro: LTC, 1998.
MACHADO, F. Projeto de banco de dados. So Paulo: rica, 1996
MECENAS, I. Banco de dados: do modelo conceitual implementao fsica. Rio de Janeiro: Alta Books, 2005.
NADEAU, T.; LIGHTSTONE, S.; TEOREY, T. Projeto e modelagem de bancos de dados, 4. Ed. Campus/Elsevier.
OPPEL, A. Banco de dados desmistificado. Rio de Janeiro: Alta Books, 2004
RAMALHO, J. A. A.. SQL: A Linguagem dos bancos de dados. So Paulo: Berkeley Brasil, 1999.
SETZER, V. W. Banco de dados. So Paulo: Edgard Blcher, 1990.
SQL Language Oracle reference manual; Version 7.2
SUDARSHAN, S.; SILBERSCHATZ, A.; KORTH, F.H. Sistemas de banco de dados. 3. Ed. S. Paulo: Makron Books,
1999
TAKAI, O. K.; ITALIANO, I. C.; FERREIRA, J. E. Introduo a banco de dados. So Paulo: DCC/IME/USP, 2005.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
124
Apndice I
Apndice I Palavras-Chave do SQL
A Tabela I.1 lista todos os termos (tokens) que so palavras-chave no padro SQL. O padro SQL faz distino entre
palavras-chave reservadas e no reservadas. De acordo com o padro, as reservadas so as nicas palavras-chave reais;
nunca so permitidas como identificadores. As no reservadas somente possuem significado especial em determinados
contextos; podem ser utilizadas como identificador em outros contextos. Em sua maior parte, as palavras-chave no
reservadas so, na verdade, nomes de tabelas e funes nativas especificadas pelo padro SQL.
Essencialmente, o conceito de palavra-chave no reservada existe apenas para declarar a associao dessa palavra com
um significado predefinido em alguns contextos.
Existem algumas palavras-chave no reservadas que no podem ser utilizadas como nome de funo ou de tipo de dado,
estando devidamente indicado. Em sua maioria, essas palavras representam funes nativas ou tipos de dado com sintaxe
especial. A funo ou o tipo ainda est disponvel, mas no pode ser redefinido pelo usurio. Na coluna reservada
esto os termos permitidos apenas como ttulos de coluna utilizando AS e, talvez, em muito poucos outros contextos.
Algumas palavras-chave reservadas so permitidas como nome de funo; isso tambm est indicado na tabela.
Como regra geral, se acontecerem erros indevidos do analisador em comandos contendo como identificador qualquer
uma das palavras-chave listadas, deve-se tentar colocar o identificador entre aspas para ver se o problema desaparece.
Palavra-chave SQL 99 SQL 92
ABORT
ABS no reservada
ABSOLUTE reservada reservada
ACCESS
ACTION reservada reservada
ADA no reservada no reservada
ADD reservada reservada
ADMIN reservada
AFTER reservada
AGGREGATE reservada
ALIAS reservada
ALL reservada reservada
ALLOCATE reservada reservada
ALTER reservada reservada
ANALYSE
ANALYZE
AND reservada reservada
ANY reservada reservada
ARE reservada reservada
ARRAY reservada
AS reservada reservada
ASC reservada reservada
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
125
Apndice I
ASENSITIVE no reservada
ASSERTION reservada reservada
ASSIGNMENT no reservada
ASYMMETRIC no reservada
AT reservada reservada
ATOMIC no reservada
AUTHORIZATION reservada reservada
AVG no reservada reservada
BACKWARD
BEFORE reservada
BEGIN reservada reservada
BETWEEN no reservada reservada
BIGINT
BINARY reservada
BIT reservada reservada
BITVAR no reservada
BIT_LENGTH no reservada reservada
BLOB reservada
BOOLEAN reservada
BOTH reservada reservada
BREADTH reservada
BY reservada reservada
C no reservada no reservada
CACHE
CALL reservada
CALLED no reservada
CARDINALITY no reservada
CASCADE reservada reservada
CASCADED reservada reservada
CASE reservada reservada
CAST reservada reservada
CATALOG reservada reservada
CATALOG_NAME no reservada no reservada
CHAIN no reservada
CHAR reservada reservada
CHARACTER reservada reservada
CHARACTERISTICS
CHARACTER_LENGTH no reservada reservada
CHARACTER_SET_CATALOG no reservada no reservada
CHARACTER_SET_NAME no reservada no reservada
CHARACTER_SET_SCHEMA no reservada no reservada
CHAR_LENGTH no reservada reservada
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
126
Apndice I
CHECK reservada reservada
CHECKED no reservada
CHECKPOINT
CLASS reservada
CLASS_ORIGIN no reservada no reservada
CLOB reservada
CLOSE reservada reservada
CLUSTER
COALESCE no reservada reservada
COBOL no reservada no reservada
COLLATE reservada reservada
COLLATION reservada reservada
COLLATION_CATALOG no reservada no reservada
COLLATION_NAME no reservada no reservada
COLLATION_SCHEMA no reservada no reservada
COLUMN reservada reservada
COLUMN_NAME no reservada no reservada
COMMAND_FUNCTION no reservada no reservada
COMMAND_FUNCTION_CODE no reservada
COMMENT
COMMIT reservada reservada
COMMITTED no reservada no reservada
COMPLETION reservada
CONDITION_NUMBER no reservada no reservada
CONNECT reservada reservada
CONNECTION reservada reservada
CONNECTION_NAME no reservada no reservada
CONSTRAINT reservada reservada
CONSTRAINTS reservada reservada
CONSTRAINT_CATALOG no reservada no reservada
CONSTRAINT_NAME no reservada no reservada
CONSTRAINT_SCHEMA no reservada no reservada
CONSTRUCTOR reservada
CONTAINS no reservada
CONTINUE reservada reservada
CONVERSION
CONVERT no reservada reservada
COPY
CORRESPONDING reservada reservada
COUNT no reservada reservada
CREATE reservada reservada
CREATEDB
CREATEUSER
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
127
Apndice I
CROSS reservada reservada
CUBE reservada
CURRENT reservada reservada
CURRENT_DATE reservada reservada
CURRENT_PATH reservada
CURRENT_ROLE reservada
CURRENT_TIME reservada reservada
CURRENT_TIMESTAMP reservada reservada
CURRENT_USER reservada reservada
CURSOR reservada reservada
CURSOR_NAME no reservada no reservada
CYCLE reservada
DATA reservada no reservada
DATABASE
DATE reservada reservada
DATETIME_INTERVAL_CODE no reservada no reservada
DATETIME_INTERVAL_PRECISION no reservada no reservada
DAY reservada reservada
DEALLOCATE reservada reservada
DEC reservada reservada
DECIMAL reservada reservada
DECLARE reservada reservada
DEFAULT reservada reservada
DEFAULTS
DEFERRABLE reservada reservada
DEFERRED reservada reservada
DEFINED no reservada
DEFINER no reservada
DELETE reservada reservada
DELIMITER
DELIMITERS
DEPTH reservada
DEREF reservada
DESC reservada reservada
DESCRIBE reservada reservada
DESCRIPTOR reservada reservada
DESTROY reservada
DESTRUCTOR reservada
DETERMINISTIC reservada
DIAGNOSTICS reservada reservada
DICTIONARY reservada
DISCONNECT reservada reservada
DISPATCH no reservada
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
128
Apndice I
DISTINCT reservada reservada
DO
DOMAIN reservada reservada
DOUBLE reservada reservada
DROP reservada reservada
DYNAMIC reservada
DYNAMIC_FUNCTION no reservada no reservada
DYNAMIC_FUNCTION_CODE no reservada
EACH reservada
ELSE reservada reservada
ENCODING
ENCRYPTED
END reservada reservada
END-EXEC reservada reservada
EQUALS reservada
ESCAPE reservada reservada
EVERY reservada
EXCEPT reservada reservada
EXCEPTION reservada reservada
EXCLUDING
EXCLUSIVE
EXEC reservada reservada
EXECUTE reservada reservada
EXISTING no reservada
EXISTS no reservada reservada
EXPLAIN
EXTERNAL reservada reservada
EXTRACT no reservada reservada
FALSE reservada reservada
FETCH reservada reservada
FINAL no reservada
FIRST reservada reservada
FLOAT reservada reservada
FOR reservada reservada
FORCE
FOREIGN reservada reservada
FORTRAN no reservada no reservada
FORWARD
FOUND reservada reservada
FREE reservada
FREEZE
FROM reservada reservada
FULL reservada reservada
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
129
Apndice I
FUNCTION reservada
G no reservada
GENERAL reservada
GENERATED no reservada
GET reservada reservada
GLOBAL reservada reservada
GO reservada reservada
GOTO reservada reservada
GRANT reservada reservada
GRANTED no reservada
GROUP reservada reservada
GROUPING reservada
HANDLER
HAVING reservada reservada
HIERARCHY no reservada
HOLD no reservada
HOST reservada
HOUR reservada reservada
IDENTITY reservada reservada
IGNORE reservada
ILIKE
IMMEDIATE reservada reservada
IMMUTABLE
IMPLEMENTATION no reservada
IMPLICIT
IN reservada reservada
INCLUDING
INCREMENT
INDEX
INDICATOR reservada reservada
INFIX no reservada
INHERITS
INITIALIZE reservada
INITIALLY reservada reservada
INNER reservada reservada
INOUT reservada
INPUT reservada reservada
INSENSITIVE no reservada reservada
INSERT reservada reservada
INSTANCE no reservada
INSTANTIABLE no reservada
INSTEAD
INT reservada reservada
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
130
Apndice I
INTEGER reservada reservada
INTERSECT reservada reservada
INTERVAL reservada reservada
INTO reservada reservada
INVOKER no reservada
IS reservada reservada
ISNULL
ISOLATION reservada reservada
ITERATE reservada
JOIN reservada reservada
K no reservada
KEY reservada reservada
KEY_MEMBER no reservada
KEY_TYPE no reservada
LANCOMPILER
LANGUAGE reservada reservada
LARGE reservada
LAST reservada reservada
LATERAL reservada
LEADING reservada reservada
LEFT reservada reservada
LENGTH no reservada no reservada
LESS reservada
LEVEL reservada reservada
LIKE reservada reservada
LIMIT reservada
LISTEN
LOAD
LOCAL reservada reservada
LOCALTIME reservada
LOCALTIMESTAMP reservada
LOCATION
LOCATOR reservada
LOCK
LOWER no reservada reservada
M no reservada
MAP reservada
MATCH reservada reservada
MAX no reservada reservada
MAXVALUE
MESSAGE_LENGTH no reservada no reservada
MESSAGE_OCTET_LENGTH no reservada no reservada
MESSAGE_TEXT no reservada no reservada
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
131
Apndice I
METHOD no reservada
MIN no reservada reservada
MINUTE reservada reservada
MINVALUE
MOD no reservada
MODE
MODIFIES reservada
MODIFY reservada
MODULE reservada reservada
MONTH reservada reservada
MORE no reservada no reservada
MOVE
MUMPS no reservada no reservada
NAME no reservada no reservada
NAMES reservada reservada
NATIONAL reservada reservada
NATURAL reservada reservada
NCHAR reservada reservada
NCLOB reservada
NEW reservada
NEXT reservada reservada
NO reservada reservada
NOCREATEDB
NOCREATEUSER
NONE reservada
NOT reservada reservada
NOTHING
NOTIFY
NOTNULL
NULL reservada reservada
NULLABLE no reservada no reservada
NULLIF no reservada reservada
NUMBER no reservada no reservada
NUMERIC reservada reservada
OBJECT reservada
OCTET_LENGTH no reservada reservada
OF reservada reservada
OFF reservada
OFFSET
OIDS
OLD reservada
ON reservada reservada
ONLY reservada reservada
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
132
Apndice I
OPEN reservada reservada
OPERATION reservada
OPERATOR
OPTION reservada reservada
OPTIONS no reservada
OR reservada reservada
ORDER reservada reservada
ORDINALITY reservada
OUT reservada
OUTER reservada reservada
OUTPUT reservada reservada
OVERLAPS no reservada reservada
OVERLAY no reservada
OVERRIDING no reservada
OWNER
PAD reservada reservada
PARAMETER reservada
PARAMETERS reservada
PARAMETER_MODE no reservada
PARAMETER_NAME no reservada
PARAMETER_ORDINAL_POSITION no reservada
PARAMETER_SPECIFIC_CATALOG no reservada
PARAMETER_SPECIFIC_NAME no reservada
PARAMETER_SPECIFIC_SCHEMA no reservada
PARTIAL reservada reservada
PASCAL no reservada no reservada
PASSWORD
PATH reservada
PENDANT
PLACING
PLI no reservada no reservada
POSITION no reservada reservada
POSTFIX reservada
PRECISION reservada reservada
PREFIX reservada
PREORDER reservada
PREPARE reservada reservada
PRESERVE reservada reservada
PRIMARY reservada reservada
PRIOR reservada reservada
PRIVILEGES reservada reservada
PROCEDURAL
PROCEDURE reservada reservada
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
133
Apndice I
PUBLIC reservada reservada
READ reservada reservada
READS reservada
REAL reservada reservada
RECHECK
RECURSIVE reservada
REF reservada
REFERENCES reservada reservada
REFERENCING reservada
REINDEX
RELATIVE reservada reservada
RENAME
REPEATABLE no reservada no reservada
REPLACE
RESET
RESTART
RESTRICT reservada reservada
RESULT reservada
RETURN reservada
RETURNED_LENGTH no reservada no reservada
RETURNED_OCTET_LENGTH no reservada no reservada
RETURNED_SQLSTATE no reservada no reservada
RETURNS reservada
REVOKE reservada reservada
RIGHT reservada reservada
ROLE reservada
ROLLBACK reservada reservada
ROLLUP reservada
ROUTINE reservada
ROUTINE_CATALOG no reservada
ROUTINE_NAME no reservada
ROUTINE_SCHEMA no reservada
ROW reservada
ROWS reservada reservada
ROW_COUNT no reservada no reservada
RULE
SAVEPOINT reservada
SCALE no reservada no reservada
SCHEMA reservada reservada
SCHEMA_NAME no reservada no reservada
SCOPE reservada
SCROLL reservada reservada
SEARCH reservada
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
134
Apndice I
SECOND reservada reservada
SECTION reservada reservada
SECURITY no reservada
SELECT reservada reservada
SELF no reservada
SENSITIVE no reservada
SEQUENCE reservada
SERIALIZABLE no reservada no reservada
SERVER_NAME no reservada no reservada
SESSION reservada reservada
SESSION_USER reservada reservada
SET reservada reservada
SETOF
SETS reservada
SHARE
SHOW
SIMILAR no reservada
SIMPLE no reservada
SIZE reservada reservada
SMALLINT reservada reservada
SOME reservada reservada
SOURCE no reservada
SPACE reservada reservada
SPECIFIC reservada
SPECIFICTYPE reservada
SPECIFIC_NAME no reservada
SQL reservada reservada
SQLCODE reservada
SQLERROR reservada
SQLEXCEPTION reservada
SQLSTATE reservada reservada
SQLWARNING reservada
STABLE
START reservada
STATE reservada
STATEMENT reservada
STATIC reservada
STATISTICS
STDIN
STDOUT
STORAGE
STRICT
STRUCTURE reservada
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
135
Apndice I
STYLE no reservada
SUBCLASS_ORIGIN no reservada no reservada
SUBLIST no reservada
SUBSTRING no reservada reservada
SUM no reservada reservada
SYMMETRIC no reservada
SYSID
SYSTEM no reservada
SYSTEM_USER reservada reservada
TABLE reservada reservada
TABLE_NAME no reservada no reservada
TEMP
TEMPLATE
TEMPORARY reservada reservada
TERMINATE reservada
THAN reservada
THEN reservada reservada
TIME reservada reservada
TIMESTAMP reservada reservada
TIMEZONE_HOUR reservada reservada
TIMEZONE_MINUTE reservada reservada
TO reservada reservada
TOAST
TRAILING reservada reservada
TRANSACTION reservada reservada
TRANSACTIONS_COMMITTED no reservada
TRANSACTIONS_ROLLED_BACK no reservada
TRANSACTION_ACTIVE no reservada
TRANSFORM no reservada
TRANSFORMS no reservada
TRANSLATE no reservada reservada
TRANSLATION reservada reservada
TREAT reservada
TRIGGER reservada
TRIGGER_CATALOG no reservada
TRIGGER_NAME no reservada
TRIGGER_SCHEMA no reservada
TRIM no reservada reservada
TRUE reservada reservada
TRUNCATE
TRUSTED
TYPE no reservada no reservada
UNCOMMITTED no reservada no reservada
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
136
Apndice I
UNDER reservada
UNENCRYPTED
UNION reservada reservada
UNIQUE reservada reservada
UNKNOWN reservada reservada
UNLISTEN
UNNAMED no reservada no reservada
UNNEST reservada
UNTIL
UPDATE reservada reservada
UPPER no reservada reservada
USAGE reservada reservada
USER reservada reservada
USER_DEFINED_TYPE_CATALOG no reservada
USER_DEFINED_TYPE_NAME no reservada
USER_DEFINED_TYPE_SCHEMA no reservada
USING reservada reservada
VACUUM
VALID
VALIDATOR
VALUE reservada reservada
VALUES reservada reservada
VARCHAR reservada reservada
VARIABLE reservada
VARYING reservada reservada
VERBOSE
VERSION
VIEW reservada reservada
VOLATILE
WHEN reservada reservada
WHENEVER reservada reservada
WHERE reservada reservada
WITH reservada reservada
WITHOUT reservada
WORK reservada reservada
WRITE reservada reservada
YEAR reservada reservada
ZONE reservada reservada
Tabela I.1 Palavras-chave dos padres SQL92 e SQL99.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
137
Apndice II
Apndice II Expresses de valor
As expresses de valor so utilizadas em diversos contextos, como na lista de seleo do comando SELECT, como
novos valores das colunas nos comandos INSERT e UPDATE, e na condio de procura em vrios comandos. Algumas
vezes, o resultado de uma expresso de valor chamado de escalar, para distingui-lo do resultado de uma expresso de
tabela (que uma tabela). As expresses de valor so, portanto, chamadas tambm de expresses escalares (ou mesmo
simplesmente de expresses). A sintaxe da expresso permite o clculo de valores a partir de partes primitivas utilizando
operaes aritmticas, lgicas, de conjunto e outras.
A expresso de valor pode se apresentar como uma das seguintes.
Um valor constante ou literal.
Uma referncia coluna.
Uma referncia ao parmetro posicional, no corpo da definio de funo ou de comando preparado.
Uma expresso de ndice.
Uma expresso de seleo de campo.
Uma chamada de operador.
Uma chamada de funo.
Uma expresso de agregao.
Uma converso de tipo.
Uma subconsulta escalar.
Um construtor de matriz.
Existe outra expresso de valor entre parnteses, til para agrupar sub-expresses e mudar precedncias. Em acrscimo
a essa lista, existem diversas construes que podem ser classificadas como uma expresso, mas que no seguem
qualquer regra geral de sintaxe. Possuem, normalmente, a semntica de uma funo ou de um operador. Um exemplo
a clusula IS NULL.
1. Referncias coluna
Uma coluna pode ser referenciada usando a forma correlao.nome_da_coluna, onde correlao o nome de uma tabela,
possivelmente qualificado pelo nome do esquema, ou definido por meio da clusula FROM, ou uma das palavras-chave
NEW ou OLD (NEW e OLD somente podem aparecer nas regras de reescrita, enquanto os outros nomes de correlao
podem ser usados em qualquer declarao SQL). O nome da correlao e o ponto separador podem ser omitidos se o
nome da coluna for nico entre todas as tabelas utilizadas no comando corrente.
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
138
Apndice II
2. Parmetros posicionais
utilizada uma referncia a um parmetro posicional para indicar um valor fornecido externamente a uma declarao
SQL. Os parmetros so utilizados na definio de funes SQL e de comandos preparados. Algumas bibliotecas cliente
tambm suportam a especificao de valores de dados, separado da cadeia de caracteres do comando SQL e, nesses
casos, os parmetros so utilizados para fazer referncia a valores de dados fora de linha. A forma de fazer referncia
a um parmetro : $nmero
Por exemplo, considere a definio da funo dept como sendo:
CREATE FUNCTION dept(text) RETURNS dept AS SELECT * FROM dept WHERE nome = $1 LANGUAGE SQL;
Nesse caso, $1 ser substitudo pelo primeiro argumento da funo quando essa for chamada.
3. ndices
Se uma expresso produzir um valor do tipo matriz, ento um elemento especfico do valor matricial pode ser extrado
escrevendo:
expresso [ndice]
e vrios elementos adjacentes podem ser extrados escrevendo:
expresso [ndice_inferior:ndice_superior].
Nesse caso, os colchetes [ ] devem aparecer literalmente. Cada ndice por si s uma expresso, que deve produzir um
valor inteiro.
Geralmente, a expresso matricial deve estar entre parnteses, mas os parnteses podem ser omitidos quando a expresso
a ser indexada apenas a referncia a uma coluna ou a um parmetro posicional. Podem ser concatenados vrios ndices
quando a matriz original for multidimensional. Por exemplo:
minha_tabela.matriz_coluna[4]
minha_tabela.matriz_duas_dim[17][34]
$1[10:42]
(funcao_matriz(a,b))[42]
4. Escolha de campo
Se uma expresso produzir um valor do tipo composto (tipo linha), ento pode-se extrair um campo especfico da linha
escrevendo:
expresso.nome_do_campo
Geralmente, a expresso de linha deve estar entre parnteses, mas os parnteses podem ser omitidos quando a expresso
de seleo for apenas uma referncia a tabela ou a um parmetro posicional. Por exemplo,
minha_tabela.minha_coluna
$1.alguma_coluna
(funcao_de_linha(a,b)).col3
Portanto, uma referncia coluna qualificada , na verdade, apenas um caso especial da sintaxe de seleo de campo.
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
139
Apndice II
5. Chamadas de operador
Existem trs sintaxes possveis para chamada de operador:
expresso operador expresso (operador binrio-intermedirio);
operador expresso (operador unrio-esquerdo);
expresso operador (operador unrio-direito).
onde o termo operador segue as regras de sintaxe ou uma das palavras-chave AND, OR ou NOT, ou um nome de
operador qualificado na forma:
OPERATOR(esquema.nome_do_operador)
Quais so os operadores existentes, e se so unrios ou binrios, depende de quais operadores foram definidos pelo
sistema e pelo usurio.
6. Chamadas de funo
A sintaxe para chamada de funo o nome da funo (possivelmente qualificado pelo nome do esquema), seguido por
sua lista de argumentos entre parnteses:
funo ([expresso [, expresso ... ]] )
Por exemplo, a funo abaixo calcula a raiz quadrada de 2:
sqrt(2)
7. Funes de agregao
Uma expresso de agregao representa a aplicao de uma funo de agregao nas linhas selecionadas pela consulta.
Uma funo de agregao reduz vrios valores de entrada a um nico valor de sada, tal como a soma ou a mdia dos
valores entrados. A sintaxe da expresso de agregao uma das seguintes:
nome_da_agregao (expresso);
nome_da_agregao (ALL expresso);
nome_da_agregao (DISTINCT expresso);
nome_da_agregao ( * ).
onde nome_da_agregao uma agregao definida anteriormente (possivelmente qualificado pelo nome do esquema),
e expresso qualquer expresso de valor que no contenha uma expresso de agregao.
A primeira forma de expresso de agregao chama a funo de agregao para todas as linhas de entrada onde a
expresso fornecida produz um valor no nulo (na verdade, deciso da funo de agregao ignorar ou no os valores
nulos porm, todas as funes-padro o fazem). A segunda forma idntica primeira, porque ALL o padro. A
terceira forma chama a funo de agregao para todos os valores distintos no nulos da expresso, encontrados nas
linhas de entrada. A ltima forma chama a funo de agregao uma vez para cada linha de entrada, independentemente
do valor ser nulo ou no; como nenhum valor especfico de entrada especificado, geralmente til apenas para a funo
de agregao count().
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
140
Apndice II
Por exemplo, count(*) retorna o nmero total de linhas de entrada; count(f1) retorna o nmero de linhas de entrada, onde
f1 no nulo; count(distinct f1) retorna o nmero de valores distintos no nulos de f1.
Uma expresso de agregao pode aparecer apenas na lista de resultados ou na clusula HAVING do comando SELECT.
Seu uso proibido nas outras clusulas, tal como WHERE, porque essas clusulas so avaliadas logicamente antes dos
resultados das agregaes estarem formados.
Quando uma expresso de agregao aparece em uma subconsulta, normalmente a agregao avaliada a partir das
linhas da subconsulta. Porm ocorre uma exceo quando o argumento da agregao contm apenas variveis do nvel
externo: a agregao ento pertence ao nvel externo mais prximo, sendo avaliada a partir das linhas dessa consulta.
A expresso de agregao como um todo , ento, uma referncia externa para a subconsulta onde aparece, agindo
como uma constante em qualquer avaliao da subconsulta. A restrio de aparecer apenas na lista de resultados ou na
clusula HAVING se aplica com respeito ao nvel da consulta que a agregao pertence.
8. Converses de tipo
Uma converso de tipo (type cast) especifica a converso de um tipo de dado em outro. O PostgreSQL aceita duas
sintaxes equivalentes para converso de tipo:
CAST ( expresso AS tipo )
expresso::tipo
Quando a converso aplicada a uma expresso de valor de tipo conhecido, representa uma converso em tempo de
execuo. A converso ser bem sucedida apenas se estiver disponvel uma operao de converso de tipo adequada.
Deve ser observado que isso sutilmente diferente da utilizao de converso com constantes. Uma converso aplicada a
uma literal cadeia de caracteres sem adornos representa a atribuio inicial do tipo ao valor constante literal e, portanto,
ser bem-sucedida para qualquer tipo (se o contedo do literal cadeia de caracteres possuir uma sintaxe vlida para
servir de entrada para o tipo de dado).
Geralmente a converso explcita de tipo pode ser omitida quando no h ambigidade em relao ao tipo que a expresso
de valor deve produzir (por exemplo, quando atribuda a uma coluna de tabela); o sistema aplica automaticamente a
converso de tipo nesses casos. Entretanto, a converso automtica de tipo feita apenas para as converses marcadas
nos catlogos do sistema como OK para aplicar implicitamente. As outras converses devem ser chamadas por meio
da sintaxe de converso explcita. Essa restrio tem por finalidade impedir que aconteam converses surpreendentes
aplicadas em silncio.
Tambm possvel especificar uma converso de tipo utilizando a sintaxe na forma de funo:
nome_do_tipo ( expresso )
Entretanto, somente funciona para os tipos cujos nomes tambm so vlidos como nome de funo. Por exemplo, double
precision no pode ser utilizado dessa maneira, mas a forma equivalente float8 pode. Tambm, os nomes interval, time e
timestamp somente podem ser utilizados dessa maneira se estiverem entre aspas, devido a conflitos sintticos. Portanto, o
uso da sintaxe de converso na forma de funo pode ocasionar inconsistncias, devendo ser evitada em novas aplicaes.
9. Subconsultas escalares
Uma subconsulta escalar um comando SELECT comum, entre parnteses, que retorna exatamente uma linha com uma
coluna. O comando SELECT executado e o nico valor retornado utilizado na expresso de valor envoltria. errado
utilizar uma consulta que retorne mais de uma linha ou mais de uma coluna como subconsulta escalar, porm, se durante
uma determinada execuo a subconsulta no retornar nenhuma linha, no acontece nenhum erro: o resultado escalar
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
141
Apndice II
assumido como nulo. A subconsulta pode fazer referncia a variveis da consulta envoltria, as quais atuam como
constantes durante a avaliao da subconsulta.
Por exemplo, a consulta abaixo retorna a maior populao de cidade de cada estado:
SELECT nome, (SELECT max(populacao) FROM cidades WHERE cidades.estado = estados.nome) FROM estados;
10. Construtores de matriz
Um construtor de matriz uma expresso que constri um valor matriz a partir dos valores de seus elementos membros.
Um construtor de matriz simples composto pela palavra-chave ARRAY, um abre colchetes [, uma ou mais expresses
(separadas por vrgula) para os valores dos elementos da matriz e, finalmente, um fecha colchetes ]. Por exemplo,
SELECT ARRAY[1,2,3+4];
array
---------
{1,2,7}
(1 linha)
O tipo de dado do elemento da matriz o tipo comum das expresses membro, determinado pela utilizao das mesmas
regras das construes UNION e CASE.
Os valores matriz multidimensional podem ser construdos aninhando construtores de matriz. Nos construtores internos,
a palavra chave ARRAY pode ser omitida. Por exemplo, esses dois comandos produzem o mesmo resultado:
SELECT ARRAY[ARRAY[1,2], ARRAY[3,4]];
array
---------------
{{1,2},{3,4}}
(1 linha)
SELECT ARRAY[[1,2],[3,4]];
array
---------------
{{1,2},{3,4}}
(1 linha)
Uma vez que as matrizes multidimensionais devem ser retangulares, os construtores internos no mesmo nvel devem
produzir submatrizes com dimenses idnticas. Os elementos construtores de matriz multidimensional podem ser qualquer
coisa que produza uma matriz do tipo apropriado, e no apenas uma construo sub-ARRAY. Por exemplo:
CREATE TABLE arr(f1 int[], f2 int[]);
INSERT INTO arr VALUES (ARRAY[[1,2],[3,4]], ARRAY[[5,6],[7,8]]);
SELECT ARRAY[f1, f2, {{9,10},{11,12}}::int[]] FROM arr;
array
------------------------------------------------
{{{1,2},{3,4}},{{5,6},{7,8}},{{9,10},{11,12}}}
(1 linha)
Tambm possvel construir uma matriz a partir do resultado de uma subconsulta. Nessa forma, o construtor de matriz
escrito com a palavra chave ARRAY seguida por uma subconsulta entre parnteses, e no entre colchetes. Por exemplo:
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
142
Apndice II
SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE bytea%);
?column?
-------------------------------------------------------------
{2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31}
(1 linha)
A subconsulta deve retornar uma nica coluna. A matriz unidimensional produzida ter um elemento para cada linha no
resultado da subconsulta, com o tipo do elemento correspondendo ao da coluna de sada da subconsulta.
11. Regras para avaliao de expresso
A ordem de avaliao das subexpresses no definida. Em particular, as entradas de um operador ou funo no so
necessariamente avaliadas da esquerda para a direita, ou em qualquer outra ordem fixada.
Alm disso, se o resultado da expresso puder ser determinado avaliando apenas algumas de suas partes, ento as outras
subexpresses podem nem ser avaliadas. Por exemplo, se for escrito
SELECT true OR alguma_funcao();
ento alguma_funcao() no ser (provavelmente) chamada. Esse o mesmo caso de quando escrito
SELECT alguma_funcao() OR true;
Deve ser observado que isso no o mesmo que os curtos circuitos esquerda para direita de operadores booleanos
encontrados em algumas linguagens de programao.
Como conseqncia, no bom utilizar funes com efeitos colaterais como parte de expresses complexas.
particularmente perigoso confiar em efeitos colaterais, ou na ordem de avaliao nas clusulas WHERE e HAVING, porque
essas clusulas so reprocessadas inmeras vezes como parte do desenvolvimento do plano de execuo. As expresses
booleanas (combinaes de AND/OR/NOT) nessas clusulas podem ser reorganizadas em qualquer forma permitida pelas
leis da lgebra booleana.
Quando for essencial obrigar a ordem de avaliao, pode ser utilizada uma construo CASE. Por exemplo, essa uma
forma no confivel para tentar evitar uma diviso por zero na clusula WHERE:
SELECT ... WHERE x <> 0 AND y/x > 1.5;
Mas esta forma segura:
SELECT ... WHERE CASE WHEN x <> 0 THEN y/x > 1.5 ELSE false END;
A construo CASE utilizada dessa forma impede as tentativas de otimizao devendo, portanto, ser utilizada
apenas quando for necessrio (Nesse exemplo em particular, sem dvida seria melhor evitar o problema escrevendo
y > 1.5*x).
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
143
Apndice III
Apndice III Comandos SQL
Esta parte contm informao de referncia para os comandos SQL.
ABORT interrompe a transao corrente
ALTER AGGREGATE altera a definio de uma funo de agregao
ALTER CONVERSION altera a definio de uma converso de codificao
ALTER DATABASE altera um banco de dados
ALTER DOMAIN altera a definio de um domnio
ALTER FUNCTION altera a definio de uma funo
ALTER GROUP altera um grupo de usurios
ALTER LANGUAGE altera a definio de uma linguagem procedural
ALTER OPERATOR CLASS altera a definio de uma classe de operadores
ALTER SCHEMA altera a definio de um esquema
ALTER SEQUENCE altera a definio de um gerador de sequncia
ALTER TABLE altera a definio de uma tabela
ALTER TRIGGER altera a definio de um gatilho
ALTER USER altera uma conta de usurio do banco de dados
ANALYZE coleta estatsticas do banco de dados
BEGIN inicia um bloco de transao
CHECKPOINT fora um ponto de controle no registro de transao
CLOSE fecha o cursor
CLUSTER agrupa a tabela de acordo com um ndice
COMMENT define ou muda o comentrio sobre um objeto
COMMIT efetiva a transao corrente
COPY copia dados entre um arquivo e uma tabela
CREATE AGGREGATE cria uma funo de agregao
CREATE CAST cria uma converso de tipo de dado
CREATE CONSTRAINT TRIGGER cria um gatilho de restrio
CREATE CONVERSION cria uma converso de codificao
CREATE DATABASE cria um banco de dados
CREATE DOMAIN cria um domnio
CREATE FUNCTION cria uma funo
CREATE GROUP cria um grupo de usurios
CREATE INDEX cria um ndice
S
i
s
t
e
m
a
s

d
e

B
a
n
c
o

d
e

D
a
d
o
s
144
Apndice III
CREATE LANGUAGE cria uma linguagem procedural
CREATE OPERATOR cria um operador
CREATE OPERATOR CLASS cria uma classe de operadores
CREATE RULE cria uma regra de reescrita
CREATE SCHEMA cria um esquema
CREATE SEQUENCE cria um gerador de sequncia
CREATE TABLE cria uma tabela
CREATE TABLE AS cria uma tabela a partir dos resultados de uma consulta
CREATE TRIGGER cria um gatilho
CREATE TYPE cria um tipo de dado
CREATE USER cria uma conta de usurio do banco de dados
CREATE VIEW cria uma viso
DEALLOCATE remove um comando preparado
DECLARE define um cursor
DELETE exclui linhas de uma tabela
DROP AGGREGATE remove uma funo de agregao
DROP CAST remove uma converso de tipo de dado
DROP CONVERSION remove uma converso de codificao
DROP DATABASE remove um banco de dados
DROP DOMAIN remove um domnio
DROP FUNCTION remove uma funo
DROP GROUP remove um grupo de usurios
DROP INDEX remove um ndice
DROP LANGUAGE remove uma linguagem procedural
DROP OPERATOR remove um operador
DROP OPERATOR CLASS remove uma classe de operadores
DROP RULE remove uma regra de reescrita
DROP SCHEMA remove um esquema
DROP SEQUENCE remove uma sequncia
DROP TABLE remove uma tabela
DROP TRIGGER remove um gatilho
DROP TYPE remove um tipo de dado
DROP USER remove uma conta de usurio do banco de dados
DROP VIEW remove uma viso
END efetiva a transao corrente
EXECUTE executa um comando preparado
P
s
-
G
r
a
d
u
a
o

a

D
i
s
t
n
c
i
a
145
Apndice III
EXPLAIN mostra o plano de execuo de um comando
FETCH traz linhas de uma consulta usando um cursor
GRANT define privilgios de acesso
INSERT cria novas linhas na tabela
LISTEN ouve uma notificao
LOAD carrega ou recarrega um arquivo de biblioteca compartilhada
LOCK bloqueia uma tabela
MOVE posiciona o cursor
NOTIFY gera uma notificao
PREPARE prepara um comando para execuo
REINDEX reconstri ndices
RESET redefine o valor de um parmetro em tempo de execuo com seu valor padro
REVOKE revoga privilgios de acesso
ROLLBACK interrompe a transao corrente
SELECT retorna linhas de uma tabela ou de uma viso
SELECT INTO cria uma tabela a partir dos resultados de uma consulta
SET muda um parmetro de tempo de execuo
SET CONSTRAINTS define os modos de verificao da restrio na transao corrente
SET SESSION AUTHORIZATION define o identificador do usurio da sesso e o identificador do usurio corrente, da
sesso corrente.
SET TRANSACTION define as caractersticas da transao corrente
SHOW mostra o valor de um parmetro de tempo de execuo
START TRANSACTION inicia um bloco de transao
TRUNCATE esvazia a tabela
UNLISTEN para de escutar uma notificao
UPDATE atualiza linhas de uma tabela
VACUUM limpa e opcionalmente analisa um banco de dados

Apostila Sistemas de Banco de Dados

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Apostila Sistemas de Banco de Dados

Hochgeladen von

Copyright:

Verfügbare Formate

Br asl i a-DF, 2011.

Si st emas de Banc o de Dados

Das könnte Ihnen auch gefallen