Banco Dados

INTRODUO A BANCOS DE DADOS
1os Lus Carneiro

Salvador
2004
Introduo a Bancos de Dados
Indice
APRESENTAO 3
SISTEMAS DE BANCOS DE DADOS 4
Conceitos Iniciais 4
Componentes de um Sistema de Banco de Dados 5
Volatilidade em um Sistema de Banco de Dados 6
Entidades e Relacionamentos 6
Modelos de Dados 7
Por que usar um SGBD? 9
Independncia de Dados 10
A arquitetura de um Sistema de Banco de Dados 11
Atribuies do Administrador de Banco de Dados 15
Funes de um Sistema Gerenciador de Banco de Dados 16
Arquitetura Cliente/Servidor 18
Processamento Distribuido 19
BANCOS DE DADOS RELACIONAIS 22
Relaes 22
Vises 23
DeIinio Iormal de uma relao 24
Propriedades de uma relao 25
Chaves 25
Normalizao 26
O Dicionario de Dados 29
Integridade 30
LINGUAGEM DE ACESSO ESTRUTURADA (SQL) 32
Caracteristicas da SQL 32
Estrutura da SQL 33
Instrues SQL 35
Ferramentas oIerecidas pela linguagem SQL 51
TPICOS ADICIONAIS 57
Transaes 57
Concorrncia 58
Segurana do Banco de Dados 61
Otimizao 63
BIBLIOGRAFIA 65
Jose Luis Carneiro 2
Apresentao
A maioria das atividades desenvolvidas em uma empresa envolve, de uma Iorma ou de outra,
a manipulao de dados e inIormaes. As inIormaes de uma empresa muitas vezes valem
mais que seu patrimnio Iisico.
Fosse em antiquados sistemas de arquivamento em papel, ou em sistemas computadorizados,
o arquivamento e acesso aos dados da empresa sempre tiveram papel Iundamental.
No mercado atual, altamente competitivo, esse papel tornou-se crucial: a ineIicincia em
recuperar dados e processar inIormaes pode determinar o Iracasso de uma empresa.
Podemos concluir que os bancos de dados tm atualmente uma enorme importncia. Esse
curso pretende auxilia-lo(a) a obter um conhecimento geral sobre bancos de dados, de Iorma a
desempenhar as Iunes de Analista de Sistemas.
Veremos, inicialmente, uma introduo a teoria de bancos de dados com o objetivo de obter
os conhecimentos necessarios para um estudo aplicado utilizando o PostgreSQL, um dos
sistemas gerenciadores de bancos de dados de baixo custo mais completos e conIiaveis
atualmente.
Essa apostila Ioi desenvolvida para oIerecer uma noo basica de banco de dados sem a
obrigatoriedade de um livro-texto. Entretanto, e imprescindivel, para aqueles que desejam se
aproIundar, adquirir um bom livro sobre o assunto. Existem varios, muitos deles ja traduzidos
para o portugus. Tomaremos como guia o livro 'Introduo a Sistemas de Banco de Dados
de C. J. Date.
Sistemas de Bancos de Dados
Conceitos Iniciais
O curso e sobre 'bancos de dados. Mas o que signiIica 'dado?
Sabemos que a palavra derivou do latim 'datu e que um dos seus signiIicados e 'conceder.
Ou seja, so fatos fornecidos que descrevem uma caracterstica de um objeto ou evento
do mundo real (na verdade o termo 'objeto no e o ideal, mas para o momento basta).
Podemos dizer que a data de nascimento de uma pessoa e um dado sobre ela.
Coloquialmente e comum utilizarmos 'dado e 'inIormao como sinnimos. Para eIeito do
nosso estudo, no entanto, vamos diIerencia-los. Enquanto dados so os componentes basicos a
partir dos quais a inIormao e criada, consideraremos que informao um dado inserido
num contexto; uma concluso a que podemos chegar analisando um ou mais dados
apresentados. Voltando ao nosso exemplo, se consideramos a data de nascimento como um
dado, devemos considerar a idade dessa pessoa como uma inIormao sobre ela (obtida a
partir da data de nascimento).
Vale observar que ha ocasies em que a Ironteira entre dados e inIormaes e muito tnue.
Enquanto um dado pode ser apenas um amontoado de caracteres incompreensiveis Iora de um
contexto, a inIormao comunica algo que outra pessoa entende. Logo, alguns dados so
inIormao para quem os compreende: o nome de uma pessoa, 'Yoko Ono por exemplo, e
apenas um dado para uns enquanto e uma inIormao para outros.
E o que viria a ser um banco de dados? Um conjunto de dados relacionados entre si
armazenados segundo uma determinada lgica de forma para que possam ser
recuperados quando necessrio. Por esse raciocinio, um cadastro de clientes (contendo seu
nome, data de nascimento e endereo) pode ser considerado um exemplo de banco de dados.
DeIinio Simplista de 'Sistema de Banco de Dados
Grosso modo, um 'Sistema de Banco de Dados e a metodologia utilizada para manter e
acessar os dados armazenados num banco de dados. E essa metodologia que ira deIinir que
dados esto armazenados, em que Iormato, sua classiIicao, etc.
Podemos comear comparando-o a um Iichario destinado a conter os dados que se deseja
armazenar. Para ser util, esse nosso Iichario deve permitir algumas operaes basicas:
1. Acrescimo de Iichas e de pastas que as agruparo por aIinidade.
2. Localizao de um determinado dado contido em uma ou em varias Iichas.
3. Atualizao dos dados contidos em cada Iicha.
4. Eliminao de Iichas e pastas indesejadas.
Portanto, um sistema inIormatizado de banco de dados, em principio, diminuiria o trabalho de
manter esse Iichario.
Realmente, os primeiros sistemas inIormatizados que utilizavam bancos de dados o Iaziam de
Iorma bastante similar ao antigo armazenamento em armarios e Iicharios. Cada departamento
possuia o seu banco de dados, normalmente uma verso eletrnica de Iormularios em papel
pre-existentes, contendo exclusivamente os dados utilizados pelos Iuncionarios daquele
departamento.
Repetio de dados em bancos espalhados por varios departamentos (e as vezes dentro de um
mesmo departamento) era comum e Ireqentemente causava inconsistncias entre os dados e
a duplicao do trabalho de atualizao ja que os sistemas no se comunicavam entre si.
Os atuais sistemas de bancos de dados tm muito mais atribuies e vantagens que seus
antepassados.
Componentes de um Sistema de Banco de Dados
Observando um sistema mais moderno de banco de dados podemos destacar alguns
componentes principais: hardware, software, usuarios e dados.
O hardware dependera da quantidade de dados a ser manipulada, do tempo de resposta e nivel
de disponibilidade desejados, dos requisitos de segurana e dos recursos disponiveis. E um
equilibrio delicado que envolve conhecimentos de equipamentos que Iogem ao escopo deste
curso.
O software (tambem conhecido Sistema de Gerenciamento de Bancos de Dados ou SGBD)
servira de interIace entre os usuarios e os dados armazenados, dispensando que a maioria dos
usuarios (os usuarios Iinais) tenha conhecimento de detalhes tecnicos de armazenamento.
Dessa Iorma, ao usuario medio basta saber como solicitar as operaes desejadas ao SGBD,
que se encarregara de executa-las.
Os usuarios podem ser divididos em trs categorias:
1. Os Usurios Finais so aqueles que utilizaro o sistema de banco de dados
rotineiramente. O objetivo Iinal de um sistema de banco de dados e atender as suas
necessidades da Iorma mais eIiciente possivel garantindo inIormao coerente,
consistente e segura, na hora e na Iorma desejada, com o minimo de conhecimento
tecnico possivel.
2. Os Administradores de Bancos de Dados (DBA database administrator) e os
Administradores de Dados (DA data administrator) so as pessoas responsaveis
por analisar as necessidades dos usuarios Iinais e desenhar o banco de dados de Iorma
a atend-las. E responsabilidade do administrador de dados, entre outras coisas,
determinar quais dados devem ser armazenados, por quanto tempo e quem tera acesso
a eles. Ao DBA cabe implementar essas deIinies e manter o banco de dados sempre
disponivel.
3. Os Programadores de Aplicaes so responsaveis por desenvolver (normalmente
em linguagens de alto nivel) os aplicativos que recebero as solicitaes dos usuarios
Iinais. Esses aplicativos encaminharo as solicitaes ao SGBD e traro de volta o
resultado. Esses aplicativos, hoje normalmente visuais, muitas vezes eliminaro dos
usuarios Iinais ate mesmo a necessidade de aprenderem os comandos de operao do
SGBD.
Volatilidade em um Sistema de Banco de Dados
Durante sua operao, um sistema de banco de dados manipula diversos dados internos,
muitas vezes criados pelo proprio sistema, como variaveis, acumuladores e resultados de
consulta. Esses dados tm um alto grau de volatilidade, sendo criados e apagados
continuamente.
Enquanto estes dados so criados e apagados de Iorma transparente para o usuario, os dados
inseridos no banco de dados pelo usuario so persistentes, isto e, permanecem
indeIinidamente no banco de dados, sendo removidos somente com uma solicitao expressa
do usuario.
Podemos ento deIinir um banco de dados como uma coleo de dados persistentes
utilizados pelas aplicaes de uma organizao.
Entidades e Relacionamentos
Durante a analise dos dados para o desenho de um sistema de bancos de dados, podemos
observar que existem determinados objetos (ou eventos) do mundo real sobre os quais
desejamos armazenar inIormaes.
De um proIessor podemos armazenar, por exemplo, seu nome, a disciplina que leciona e seu
salario. De um aluno, as disciplinas a que assiste, suas notas e sua Ireqncia. E de uma
disciplina, suas turmas, sua carga horaria e seus pre-requisitos. Dizemos que proIessores,
alunos e disciplinas so as entidades basicas do nosso banco de dados e que os dados que
desejamos armazenar so suas propriedades.
Podemos dizer que entidades so objetos (ou eventos) do mundo real que tm dados a serem
armazenados e, portanto precisam ser representadas no banco de dados.
Ainda podemos observar, em muitos casos, que na vida real existem relacionamentos entre
essas entidades que tambem devem ser representados no banco de dados: um proIessor
leciona uma determinada disciplina; um aluno assiste a uma determinada disciplina; e uma
disciplina tem determinados pre-requisitos (que normalmente so outras disciplinas).
Uma coisa que devemos salientar e que os proprios relacionamentos tm, muitas vezes,
inIormaes que so necessarias: o relacionamento 'aluno-assiste-a-disciplina gera a
pergunta 'Em que sala?. Concluimos que os proprios relacionamentos tm propriedades a
serem armazenadas, caracterizando-se tambem como entidades.
As propriedades que armazenamos em nosso banco de dados nos permitem Iormular
aIirmaes sobre essas entidades. Essas aIirmaes podem ser exclusivamente verdadeiras ou
Ialsas. Do ponto de vista logico, chamamos essas aIirmaes de proposies. Ou seja, o dado
que armazenamos na propriedade esta correto (proposio verdadeira) ou esta incorreto
(proposio Ialsa).
Consideremos tambem que, exceto em caso de erro de entrada, os dados armazenados num
banco de dados esto corretos, ja que correspondem a Iatos Iornecidos pelo mundo real
(obtidos da propria entidade observada).
Podemos agora deduzir um outro conceito para Banco de Dados:
'Se as entidades so objetos do mundo real que tm dados a serem armazenados, se estes
dados podem ser avaliados como proposies (verdadeiras ou Ialsas) e se no Iaz sentido
armazenar proposies Ialsas num banco de dados, podemos dizer que um banco de dados
uma coleo de proposies verdadeiras.
Modelos de Dados
Um modelo de dados e uma deIinio abstrata dos objetos representados por estes dados, dos
relacionamentos desses objetos entre si e de um conjunto de operadores e regras que os
usuarios Iinais utilizam para interagir com o banco de dados. Como esses dados estaro
implementados no importa aos usuarios Iinais, dai o termo 'deIinio abstrata.
Os bancos de dados que utilizam entidades e seus relacionamentos baseiam-se num modelo
Iormal, Iundamentado na logica e na matematica, chamado de Modelo Relacional de Dados.
As caracteristicas principais deste modelo so:
1. Os dados so representados por relaes em que cada linha pode ser lida como uma
proposio verdadeira. Para Iacilitar a compreenso neste momento, considere que
uma relao e muito semelhante a uma tabela.
2. OIerece operadores relacionais que, aplicados as relaes, permitem extrair novas
relaes a partir das primeiras. Temos por exemplo, o operador restrio que extrai um
determinado conjunto de linhas, e o operador projeo que extrai um determinado
conjunto de colunas. Obviamente podemos considerar um conjunto de linhas e colunas
como uma nova relao.
O Modelo Relacional e o unico que realmente podemos considerar um modelo real, visto que
e o unico que demonstrou, matematicamente, ser completo e consistente. Sobre a deIinio
teorica ento, Ioram desenvolvidos os sistemas de banco de dados.
Nos caso de outros 'modelos, ocorre o inverso: a deIinio veio para explicar o sistema de
banco de dados ja desenvolvido.
Desse modo, muitos dos sistemas no-relacionais utilizam artiIicios de implementao (como
ponteiros) para que possam Iuncionar. O Modelo Relacional no utiliza esses artiIicios ja que
e Iuncional desde o mbito teorico (note porem, que isso no signiIique que um SGBDR no
utilize ponteiros no nivel Iisico; na verdade, e quase certo que utilize, mas esses detalhes de
armazenamento esto ocultos do usuario).
Enquanto no modelo relacional de dados o usuario v os dados como tabelas, nos sistemas
no-relacionais os dados so apresentados de outras Iormas:
1. Na Abordagem Hierrquica (IMS da IBM), os dados so apresentados como
colees de registros e as ligaes entre eles. Essas ligaes obedecem a uma
hierarquia, Iormando uma estrutura de arvore. Os operadores oIerecidos ao usuario
so ponteiros que permitem seu deslocamento na arvore. E mais indicado para
representar estruturas hierarquicas como relacionamentos 'um para um e 'um para
muitos, pois apresenta alto nivel de redundncia de inIormaes e ineIicincia em
estruturas mais complexas como os relacionamentos 'muitos para muitos.
2. Na Abordagem em Rede ou CODASYL (IDMS da Computer Associates e TOTAL
da Cincon Svstems), os dados tambem so representados como colees de registros e
ligaes entre eles, embora no haja uma relao hierarquica deIinida. Como um
registro pode ter qualquer quantidade de superiores e dependentes imediatos,
representa relacionamentos 'muitos para muitos mais diretamente que a abordagem
hierarquica, mas seu esquema de deIinio tende a se tornar extremamente complexo.
Os operadores oIerecidos tambem so ponteiros, e permitem o deslocamento na rede.
Uma variao dessa abordagem e a utilizao de listas invertidas, apresentada pelo
ADABAS (Adaptable Data Base Svstem) da Software AG.
Existe ainda a Abordagem Orientada a Objeto, que aplica os conceitos da Teoria de
Orientao a Objetos aos sistemas de bancos de dados. Atualmente poucos so os SGBD que
apresentam essas caracteristicas, o que mais se aproxima e o Oracle9i.
Uma curiosidade sobre o Modelo Relacional e que, ao contrario dos sistemas no-relacionais,
ainda no ha um produto comercial que implemente todas as suas caracteristicas.
Por que usar um SGBD?
A essa altura, voc deve estar se perguntando: 'Mas por que eu deveria usar um sistema
gerenciador de banco de dados?. Existem vantagens obvias e outras menos aparentes. As
principais so:
1. Menos trabalho repetitivo.
2. Os dados consultados so mais atualizados, uma vez que a maquina trabalha muito
mais rapido que o homem.
3. Varias aplicaes podem trabalhar sobre os mesmos dados, evitando o re-trabalho de
desenhar um novo banco de dados para cada aplicao e reduzindo a redundncia de
dados.
4. Menos inconsistncia e maior integridade dos dados, ja que com menos redundncia, e
menos provavel que uma alterao numa ocorrncia de um dado no seja realizada nas
demais ocorrncias.
5. Maior segurana dos dados. Basta protegermos um banco de dados contra Ialhas e
acidentes. A segurana de acesso e proporcionada pelo SGBD.
6. Os dados podem ser padronizados. Por exemplo, quando houve a reduo de digitos
de codigo teleInico de DDD, pudemos assegurar num banco de dados bem
desenhado que todos os codigos de DDD haviam sido alterados.
7. Os atuais SGBD oIerecem suporte a transaes (um conjunto de operaes unidas
logicamente em torno de um unico evento). Se uma operao no puder ser concluida,
nenhuma das outras e eIetuada. Isso ajuda a evitar inconsistncias em caso de
problemas que interrompam a atualizao dos dados. Veremos mais sobre transaes
adiante.
8. Independncia de dados. Um sistema de banco de dados constitui-se numa camada
entre o usuario e a implementao dos dados. O que o usuario v e uma
representao dos dados armazenados. A Iorma como essa representao e
implementada e de conhecimento apenas do DBA e do SGBD.
Independncia de Dados
De todas as vantagens de um SGBD, a independncia de dados e a mais aparente para os
administradores de dados, administradores de bancos de dados e programadores de
aplicaes. A independncia de dados e a imunidade oIerecida pelo SGBD das aplicaes e
usuarios as mudanas ocorridas no banco de dados. Existem dois tipos de independncia de
dados:
1. Independncia Fsica Imunidade as alteraes na representao Iisica e no metodo
de acesso aos dados. Dessa Iorma, os bancos de dados podem ser projetados da Iorma
mais eIiciente possivel. Quando do desenvolvimento de novas aplicaes, os dados
modelados podem ser aproveitados sem alteraes: o SGBD disponibiliza os dados no
Iormato esperado por cada aplicao, independente do Iormato em que Ioram
armazenados. E, caso seja necessario alterar o Iormato dos dados devido a mudanas
nos requisitos, isso pode ser Ieito com o minimo impacto sobre os sistemas
envolvidos. Um bom exemplo dessas alteraes Ioi a mudana nos campos de datas,
aumentando de dois para quatro o numero de digitos do ano, que causou tanta
polmica na virada do milnio.
2. Independncia Lgica Imunidade as mudanas na estrutura logica do banco de
dados. Enquanto a independncia Iisica permite alteraes transparentes ao Iormato de
armazenamento dos dados modelados, a independncia logica minimiza o impacto
causado por uma possivel alterao na modelagem dos dados. Se o administrador de
dados veriIicar que uma propriedade no deveria pertencer a uma determinada
entidade e sim a uma outra, ou que mais propriedades so necessarias, o DBA pode
realizar a alterao sem ter que reescrever todas as aplicaes envolvidas.
Por essa razo, quando Ialamos de SGBD, Iazemos uma distino entre campos, registros e
arquivos armazenados e lgicos (ou visualizados). O dado que esta armazenado no precisa
ser igual ao dado que e visualizado por um usuario (ou por uma aplicao).
Como exemplo, um dado que aparentemente pertence a uma entidade pode ser o resultado da
juno de dados de diversas entidades diIerentes; ou um dado numerico pode estar
armazenado em Iormato hexadecimal (por questes de eIicincia) enquanto os usuarios o
vem no Iormato decimal, mais natural para nos humanos.
Aproveitaremos para deIinir os termos 'campo, 'registro e 'arquivo, ja que apareceram
com certa Ireqncia daqui pra Irente.
Campo e a menor unidade de dado sobre uma entidade. E o armazenamento de uma de suas
propriedades. Considerando a entidade 'ProIessor, o nome do proIessor seria um campo.
Um registro e uma coleo de campos relacionados entre si. DeIine uma instncia (um
exemplar) daquela entidade. Ainda considerando a entidade 'ProIessor, cada um dos
proIessores seria uma instncia dessa entidade, e para cada um deles haveria um registro.
Ja um arquivo e a coleo de todas as instncias de um mesmo tipo de registro. No nosso
exemplo, todos os proIessores existentes no nosso banco de dados.
A arquitetura de um Sistema de Banco de Dados
Em 1972 Ioi criado um grupo de estudos para deIinir uma arquitetura padro para um sistema
de banco de dados que atendesse as demandas teoricas. O nome desse grupo Ioi
'ANSI/X3/SPARC Studv Group on Data Base Management Svstems, e a arquitetura passou a
ser conhecida como ANSI/SPARC.
Segundo essa arquitetura, um sistema de banco de dados pode possui trs niveis:
1. Nivel Interno ou Fisico Responsavel pelo armazenamento dos dados.
2. Nivel Conceitual ou Logico Comunitario Serve de interIace entre o primeiro e o
terceiro niveis.
3. Nivel Externo ou Logico do Usuario Responsavel pela visualizao dos dados por
parte do usuario.
O Nivel Externo (ou Viso Externa)
O nivel externo constitui-se na viso que o usuario tem do banco de dados; como os dados so
visualizados por ele. Dessa Iorma, havera tantas dessas vises quantas Iorem as Iormas
distintas que os dados podem ser visualizados (usuarios diIerentes, aplicaes diIerentes, etc.).
Por usuario, podemos entender tanto o proprio DBA (ou um desenvolvedor de aplicaes)
quanto um usuario Iinal. Porem, observemos agora o usuario Iinal: ele so estara interessado
em uma determinada parte do banco de dados e, do seu ponto de vista, essa viso e o banco de
dados completo.
O termo ANSI/SPARC para essa viso e 'viso externa. Ela independe da Iorma como os
dados esto armazenados (independncia lgica dos dados, como vimos).
A cada viso externa, corresponde um esquema externo que contem as deIinies de tipo dos
dados que so disponibilizados.
A viso externa podera ser acessada de diversas Iormas, inclusive por meio de Ierramentas
bastante amigaveis, muitas vezes visuais (normalmente voltadas para o usuario Iinal).
O desenvolvedor, entretanto, utilizara uma linguagem de alto nivel para produzir o aplicativo
desejado. As linguagens para desenvolvimento de aplicaes normalmente utilizaro um
subconjunto de comandos para acessar e manipular o banco de dados.
Chamamos a esse subconjunto de 'sublinguagem de dados e a linguagem de alto nivel que o
utiliza, de linguagem 'hospedeira.
Dessa Iorma, enquanto a linguagem hospedeira e responsavel pelos recursos de programao
(como variaveis, estruturas de deciso e repetio), a sublinguagem de dados responsabiliza-
se pelo acesso ao banco de dados. Atualmente a sublinguagem de dados mais utilizada e a
SQL. Veremos mais detalhes sobre ela adiante.
Dizemos que a sublinguagem de dados esta embutida na linguagem hospedeira e, pela
Iacilidade com que podemos distinguir entre elas, podemos classiIica-las como fracamente
acopladas (quando so Iacilmente distinguiveis) ou fortemente acopladas (quando so podem
ser distinguidas com diIiculdade).
Como a linguagem SQL normalmente no oIerece suporte ao acoplamento Iorte, atualmente a
grande maioria das linguagens possui acoplamento Iraco. Porem, isso so e veriIicado do ponto
de vista do desenvolvedor. Do ponto de vista do usuario Iinal, isso e transparente.
Qualquer que seja a 'sublinguagem de dados, ela divide-se em pelo menos duas partes:
1. DDL (Data Definition Language) Instrues para deIinio de estruturas, esquemas
e vises no banco de dados.
2. DML (Data Manipulation Language) Instrues para manipulao dos dados no
banco de dados, permitindo incluso, alterao, excluso e consulta a esses dados.
Veremos mais sobre DDL e DML, quando tratarmos sobre SQL.
O Nivel Conceitual (ou Viso Conceitual)
Enquanto a viso externa e uma representao do banco de dados como ele e visto por um
determinado usuario, a viso conceitual e uma representao dos dados como eles 'realmente
so no mundo real.
E descrita pelo esquema conceitual e serve de interIace entre a viso externa e o Iormato de
armazenamento dos dados, sendo a responsavel pela independncia fsica dos dados.
Prov uma deIinio teorica dos dados, sem as limitaes tecnicas de implementao (como
caracteristicas de hardware e software) ou mesmo limitaes de acesso de cada usuario.
Portanto, a viso conceitual deve compreender todo o banco de dados, inclusive suas
restries de integridade e segurana, sem mencionar detalhes de armazenamento.
Por essa razo, a viso conceitual e a mais proxima da deIinio teorica obtida no
levantamento do banco de dados. Dessa Iorma, sendo a viso conceitual independente dos
dados, a viso externa, baseada nela, tambem sera.
InIelizmente no ha, atualmente, nenhum sistema que atenda completamente a essas
condies. Todos eles, em maior ou menor grau, poluem a viso conceitual com detalhes de
implementao. Pode ser que no Iuturo existam sistemas comerciais que consigam tal grau de
abstrao, mas nos sistemas atuais, a viso conceitual e pouco mais que a reunio de todas as
diIerentes vises externas e mais algumas restries de segurana e integridade. Longe do
ideal teorico.
O Nivel Interno (ou Viso Interna)
A viso interna e a camada de mais baixo nivel das trs, sendo a que mais se aproxima dos
dados armazenados. E descrita pelo esquema interno e nela so deIinidas, por exemplo, a
seqncia de armazenamento e os Iormatos de cada campo (o campo 'X devera ser
armazenado em decimal ou em binario?), os indices que sero utilizados e as otimizaes
necessarias ao bom Iuncionamento do banco de dados.
Entretanto, a viso interna no abrange deIinies Iisicas do banco de dados, no ha
preocupao com dispositivos de armazenamento, nem com numero de cilindros ou trilhas.
Essas deIinies esto restritas ao Nvel Fsico, responsavel pela manipulao dos registros
Iisicos, Iora da arquitetura de banco de dados.
Vale observar que, no nivel Iisico, no nos reIerimos a registros, mas a blocos (ou pginas)
que so as menores unidades de inIormao manipuladas numa unica operao de entrada e
saida. Um bloco tem um tamanho Iixo (normalmente 1 kb, 2 kb ou 4 kb) diIerente para cada
sistema de banco de dados, que no corresponde necessariamente ao tamanho de um registro
deIinido no nivel conceitual. Na verdade, dependendo do tamanho dos registros, um bloco
pode conter varios deles ou apenas parte de um.
Mapeamentos
Como pudemos observar, as deIinies de cada viso no so diretamente correspondentes
entre si. Nem sempre as deIinies de uma viso correspondem as deIinies de uma outra
viso (como as vises externas e a viso conceitual, por exemplo).
A correspondncia (ou 'traduo) das deIinies de uma viso para outra e chamada de
mapeamento. Dessa Iorma, existe um mapeamento conceitual/interno (responsavel pela
correspondncia entre esses niveis) e diversos mapeamentos externos/conceituais (um para
cada viso externa distinta).
Como o proprio nome diz, o mapeamento conceitual/interno especiIica como os registros
deIinidos no nivel conceitual so representados no nivel interno. Qualquer alterao na
estrutura do banco de dados (mesmo a criao de um novo indice ou a otimizao de uma
pesquisa) reIletira numa mudana neste mapeamento de Iorma a manter a independncia de
dados fsica caracteristica do nivel conceitual.
Um mapeamento externo/conceitual realiza um trabalho semelhante, so que deIine a
correspondncia entre uma (determinada) viso externa e o nivel conceitual. Portanto, existem
diversos mapeamentos externos/conceituais, um para cada viso externa.
Quanto a mutabilidade, o comportamento e analogo: qualquer alterao no nivel conceitual
deve ser logo reIletida em todos os mapeamentos externos/conceituais aIetados por ela. Dessa
Iorma, as vises externas no precisam ser alteradas, mantendo a independncia de dados
lgica.
Existem ainda mapeamentos externos/externos que permitem que vises externas possam ser
baseadas em outras vises externas, ao inves de serem baseadas obrigatoriamente na viso
conceitual. Isso poupa trabalho quando temos diversas vises externas semelhantes, evitando
deIinir todas elas a partir do nivel conceitual. Esse tipo de mapeamento e comum em sistemas
de banco de dados relacionais.
Atribuies do Administrador de Banco de Dados
Relembrando, o administrador de dados e responsavel pela deIinio do Projeto Logico da
empresa, por exemplo: quais entidades devem ser avaliadas, quais dados sobre elas devem ser
armazenados, quem deve ter acesso a esses dados e quais as restries de integridade que so
aplicaveis. Por sua vez, o DBA possui o conhecimento tecnico necessario para implementar
essas deIinies em um SGBD.
Agora podemos deIinir mais claramente as atribuies do DBA:
1. Definir o esquema conceitual: Uma vez que o administrador de dados tenha deIinido
o projeto logico, contendo as deIinies conceituais do banco de dados como um todo,
o DBA criara o esquema conceitual (utilizado na deIinio da viso conceitual).
2. Definir o esquema interno: Com a viso conceitual pronta, cabe ao DBA determinar
como esses dados devem ser armazenados de Iorma a obter o melhor desempenho
possivel. Qual o melhor Iormato para cada campo? Qual o melhor indice para tratar os
dados? Respostas a essas e a outras perguntas compem o que chamamos de Projeto
Fisico do Banco de Dados (no conIundir com Nivel Fisico!). Pronto o projeto Iisico,
o DBA criara o esquema interno (que servira de base para a viso interna) e o
mapeamento conceitual/interno.
3. Ligao com os usurios: E papel do DBA prover aos usuarios a inIra-estrutura para
que possam explorar o banco de dados. Para isso, o DBA e responsavel pela deIinio
(e implementao) das diversas vises externas, seus esquemas externos e os
respectivos mapeamentos externos/conceituais. De Iorma similar, o DBA deve dar
consultoria e suporte no desenvolvimento de aplicativos e na resoluo de problemas
relacionados ao banco de dados.
4. Definir a poltica de descarga e recarga: Devido a importncia dos dados para a
empresa e ao Iato do DBA ser o responsavel tecnico pelo banco de dados, e sua
responsabilidade deIinir a politica de copias de segurana periodicas do banco de
dados (descarga), seu armazenamento e eventual restaurao (recarga) em caso de
necessidade, da Iorma mais rapida e transparente possivel aos usuarios.
5. Monitorar o desempenho do banco de dados e responder a requisitos de
mudanas: Como vimos anteriormente, cabe ao DBA manter o banco de dados com o
melhor desempenho possivel. E sua atribuio conIigurar o banco de dados de Iorma a
otimizar esse desempenho. Podem ser necessarias reorganizaes periodicas no banco
de dados ou mesmo alteraes em seu nivel interno (e as conseqentes alteraes no
mapeamento conceitual/interno) para adequa-lo a novas necessidades ou tecnologias.
E responsabilidade do DBA coordenar essas paradas de manuteno.
Funes de um Sistema Gerenciador de Banco de Dados
Agora podemos estimar com mais preciso o volume de trabalho desempenhado pelo sistema
gerenciador de banco de dados.
Uma consulta simples que apenas identiIique e exiba alguns registros em uma viso externa
seria trabalhada em varias etapas:
Primeiro a solicitao do usuario seria interpretada e analisada.
Seria veriIicado ento o esquema para identiIicar quais os campos necessarios e os
seus respectivos tipos de dados.
Os campos conceituais envolvidos seriam identiIicados no mapeamento
externo/conceitual correspondente.
O processo continuaria da mesma Iorma, passando pelo esquema conceitual e o
mapeamento conceitual/interno, ate chegar ao esquema interno.
Os registros internos necessarios seriam ento selecionados pelo SGBD e o processo
seria reiniciado no sentido inverso eIetuando todas as operaes e converses de tipo
necessarias para devolver ao usuario, segundo as especiIicaes da viso externa, os
registros desejados no Iormato esperado.
Como dissemos antes, o SGBD serve de interIace para o usuario, realizando todo o trabalho
de manuteno do banco de dados de Iorma transparente. Dessa Iorma podemos considerar
como Iunes de um SGBD:
1. Aceitar e 'compreender as diversas deIinies de dados (esquemas externos,
conceitual e interno e os mapeamentos associados) de Iorma a realizar as converses
necessarias. Para isso e necessario um interpretador/compilador de DDL.
2. 'Compreender as solicitaes de manipulao de dados dos usuarios (incluses,
alteraes de dados, excluses e pesquisas). Para isso e necessario um
interpretador/compilador de DML.
3. Otimizar as requisies de DML de Iorma a obter o melhor desempenho possivel
durante sua execuo. Vale observar que existem dois tipos de solicitaes DML:
3.1. Planejadas Solicitaes rotineiras na empresa, normalmente em
nivel operacional, repetidas diversas vezes sem alteraes (muitas
vezes programadas). So previstas pelo DBA que ajustara o banco de
dados (no nivel interno) de Iorma serem executadas eIicientemente.
3.2. No Planejadas Solicitaes que no so rotineiras na empresa,
normalmente solicitaes de pesquisa utilizadas como apoio ao
processo de tomada de deciso. Por serem imprevisiveis pelo DBA,
sero executadas da melhor maneira possvel (no necessariamente a
mais eIiciente) pelo SGBD, de acordo com os projetos Iisico e logico
do banco de dados.
4. Como dito anteriormente, o SGBD deve supervisionar todo e qualquer acesso aos
dados de Iorma a garantir que as restries de integridade e de segurana esto sendo
obedecidas.
5. Prover meios para recuperao de transaes, isto e, no caso de impossibilidade de
concluso bem sucedida de uma transao, retornar o banco de dados ao estado
anterior. Isso sera mais explicado ao estudarmos transaes.
6. Realizar o controle de concorrncia, ou seja, gerenciar o acesso simultneo de mais
de um usuario aos mesmos dados. O objetivo e, quando num acesso simultneo, um
usuario alterar os dados armazenados, garantir que todos os demais usuarios tenham
acesso imediato as inIormaes atualizadas. Isso evita a situao em que dois usuarios
acessam os mesmos dados num estado 'A e o primeiro deles altera os dados para um
estado 'B, enquanto o segundo usuario, trabalhando agora com um estado 'A no
correspondente a realidade, os altera para um estado 'C, comprometendo a
integridade dos dados.
7. Disponibilizar um Dicionrio de Dados. Nele esto armazenados descritores (ou
metadados), que so inIormaes necessarias ao Iuncionamento do banco de dados,
como as deIinies de todos os tipos de dados utilizados, os mapeamentos e os
esquemas (interno, conceitual e externo) e as restries de segurana e integridade.
Podera ainda incluir inIormaes como: os usuarios e aplicaes que acessam o
sistema, suas consultas customizadas e atividades pre-deIinidas de execuo rotineira
e automatica.
Os 'sistemas gerenciadores de bancos de dados utilizados antigamente estavam mais
proximos na verdade de Sistemas Gerenciadores de Arquivos. Ou seja, eles apenas
administravam arquivos armazenados onde podiam realizar operaes simples de busca e
atualizao. No entanto, comparando com os SGBD:
1. No possuiam conhecimento interno da estrutura dos arquivos armazenados, por isso
no tinham as mesmas converses de tipo e independncia (logica e Iisica) de dados
que o SGBD.
2. OIereciam pouco (ou nenhum) suporte a restries de segurana e integridade.
3. No oIereciam um dicionario de dados.
4. No oIereciam integrao e compartilhamento de arquivos. Cada arquivo era privativo
do usuario ou da aplicao que o utilizava (dai a redundncia de dados nos 'bancos de
dados espalhados pelos diversos departamentos).
5. No oIereciam suporte a transaes. Se, durante uma atualizao em varias etapas,
uma dessas etapas no tivesse sucesso, teriamos que desIazer, manualmente cada uma
das etapas ja concluidas de Iorma a retornar o banco de dados a situao anterior.
Arquitetura Cliente/Servidor
Uma vez que os sistemas de banco de dados existem basicamente para Iornecer a inIra-
estrutura necessaria ao desenvolvimento e execuo de aplicaes de banco de dados,
podemos analisa-la por uma diviso logica de responsabilidades mais simples que a
arquitetura ANSI/SPARC, possuindo apenas dois niveis:
O primeiro nivel, composto pelas aplicaes que acessaro o banco de dados, e chamado de
cliente.
O segundo nivel, composto pelo proprio SGBD, e chamado de servidor, pois e responsavel
por prover (servir) os clientes com a inIra-estrutura necessaria ao seu Iuncionamento (as
Iunes de um SGBD como deIinio e manipulao de dados, controle de concorrncia e
restries de segurana e integridade).
O nome dessa arquitetura e 'Arquitetura Cliente/Servidor e permite uma separao clara
entre as duas principais partes de um sistema de banco de dados (clientes e servidores). Nessa
arquitetura, e indiIerente ao servidor a localizao dos clientes, que podem ser executados
tanto na mesma maquina que ele, quanto em maquinas distintas. Isso permite o
desenvolvimento do sistema de Iorma a executar cada parte em uma maquina diIerente. Com
isso, podemos somar as vantagens trazidas pelo SGBD, o processamento distribuido (como
veremos logo adiante). O processamento e dividido entre o cliente e o servidor, diminuindo a
carga e o traIego de inIormaes entre eles.
Do ponto de vista do servidor, os clientes so quaisquer aplicaes que utilizem os seus
servios, podendo ser:
Aplicaes desenvolvidas pelos programadores de aplicaes em linguagens de alto
nivel acopladas a uma sublinguagem de dados.
Ferramentas, muitas vezes Iornecidas pelo proprio Iabricante do SGBD, para que o
proprio usuario Iinal possa interagir com o banco de dados sem necessidade de
desenvolvimento elaborado, como geradores de relatorios, Ierramentas case e de 'data
ware house.
Utilitarios, obrigatoriamente Iornecidos pelo Iabricante do SGBD, que atraves de
acesso de baixo nivel (normalmente direto ao nivel interno) realizam atividades de
manuteno no banco de dados. Alguns exemplos dessas atividades so: rotinas de
reorganizao, carga inicial de dados, descarga e recarga, levantamento de estatisticas
e otimizao.
A quantidade (e qualidade) dos utilitarios assim como das Ierramentas para o usuario Iinal,
varia para cada SGBD. Essa avaliao, principalmente em relao as Ierramentas para o
usuario Iinal, tem grande relevncia no processo de escolha do SGBD a ser adotado.
Processamento Distribuido
E o nome dado a conexo simultnea de mais uma maquina de Iorma que o processamento
possa ser distribuido entre elas, melhorando o desempenho.
Existe tambem a expresso 'processamento paralelo que descreve uma situao bastante
semelhante. No processamento paralelo a ideia central e desmembrar um problema grande em
problemas menores que possam ser resolvidos simultaneamente. Varias maquinas
conjugadas trabalhando de Iorma a simular o Iuncionamento de uma maquina de maior
capacidade (clustering). Ja no processamento distribuido, o objetivo e distribuir tareIas
relacionadas entre maquinas independentes de Iorma a reduzir sobrecarga e gargalos.
No processamento distribuido apesar de serem interligadas, as tareIas tm sua execuo
independente. Dessa Iorma, enquanto no processamento paralelo as maquinas tendem a
manter proximidade Iisica, no processamento distribuido isso no e imprescindivel. Para
nosso estudo de bancos de dados, vamos nos ater ao processamento distribuido.
Ha muitas variedades de processamento distribuido em um sistema de banco de dados. A
mais simples e quando o servidor (back end) e executado em uma maquina enquanto o cliente
(front end) e executado em outra. De Iato, o termo 'cliente/servidor deixou de ser
relacionado estritamente a arquitetura para ser quase um sinnimo dessa variedade de
processamento distribuido.
Algumas vantagens dessa variedade:
1. Aumento de desempenho ja que as tareIas relacionadas ao cliente e o processamento
no servidor so executados simultaneamente.
2. A maquina servidora pode ter uma conIigurao mais adequada, muitas vezes
multiprocessada, com grande capacidade de memoria e componentes redundantes,
oIerecendo melhor desempenho e segurana.
3. A maquina cliente tambem pode ser mais adequada, muitas vezes com a conIigurao
minima para executar suas tareIas, diminuindo os custos.
4. Varias maquinas clientes podem acessar o mesmo servidor simultaneamente
compartilhando o banco de dados. Esse recurso e muito utilizado uma vez que uma
dos principais objetivos de um SGBD e compartilhar o banco de dados.
5. Uma maquina cliente pode acessar dados de varios servidores, possibilitando que os
dados da empresa estejam distribuidos em mais de um servidor.
Esse ultimo recurso e muito desejado uma vez que, normalmente as empresas tm os seus
dados espalhados por muitas maquinas ao inves de Iicarem concentrados num unico servidor.
Esse acesso multiplo pode ser Ieito de duas Iormas:
O cliente so pode acessar um servidor de cada vez. Dessa Iorma no e possivel
combinar dados de mais de um servidor numa unica operao e o usuario precisa
conhecer a localizao dos dados nos diversos servidores.
O cliente pode acessar varios servidores simultaneamente, combinando dados de mais
de um servidor numa unica operao. Do ponto de vista do cliente, os servidores
aparentam ser um unico, no importando a localizao dos dados.
A segunda Iorma caracteriza um Sistema de Banco de Dados Distribudo. Um sistema de
banco de dados distribuido implica que um cliente deve conseguir acesso a diversos bancos de
dados distintos, gerenciados por gerenciadores diIerentes, em maquinas distintas, Iuncionando
sob sistemas operacionais diversos, comunicando-se por meio de redes de computadores
diIerentes, de Iorma transparente.
Do ponto de vista do cliente, e como se todos os dados se originassem de um mesmo SGBD
rodando em uma unica maquina. Ou seja, um sistema de banco de dados distribudo um
timo exemplo de independncia lgica.
Atualmente, essa e uma das tecnologias de banco de dados que mais recebe investimentos dos
Iabricantes de SGBD.
Bancos de Dados Relacionais
Ja vimos sobre os bancos de dados relacionais e algumas de suas caracteristicas principais.
Uma vez que ele e o unico modelo de dados real e (principalmente) devido a sua importncia
comercial, concentraremos nossos estudos nesse modelo.
O modelo relacional Ioi publicado em 1969 por Edgar F. Codd, um matematico da IBM. O
trabalho de Codd comeou a servir de base para o trabalho de outros pesquisadores. Um
grupo, em Berkeley, desenvolveu o SGBD Ingres enquanto outro grupo, na IBM, desenvolveu
a primeira verso da linguagem SQL.
A medida que o tempo passou, o modelo relacional Ioi conquistando mais espao no mercado
e sendo aprimorado, a tal ponto que certas caracteristicas ainda no Ioram totalmente
implementadas.
Os Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDR) aumentaram em
quantidade. Existe hoje, desde opes de baixo custo ate opes extremamente custosas e
abrangentes. Mesmo assim, todas oIerecem um alto nivel de qualidade e proIissionalismo.
Escolher um SGBDR, hoje, e selecionar qual melhor se adapta (e atende) as necessidades do
sistema de banco de dados.
Relaes
O modelo relacional e claramente baseado no conceito de matrizes, onde as linhas das
matrizes seriam os registros e as colunas (das matrizes) seriam os campos. Entretanto, essa
terminologia no e adequada a expressar os conceitos do modelo relacional.
Descreveremos agora os termos utilizados pelo modelo relacional, para chegarmos a deIinio
de relaes.
Como vimos anteriormente, atributos so os elementos de dados que, juntos, descrevem
uma entidade. Considerando a entidade aluno, o nome, sexo e data de nascimento seriam
atributos.
Cada atributo tem um conjunto de valores possiveis para ele, por exemplo, so ha dois valores
possiveis para sexo: masculino e Ieminino. Domnio o conjunto de valores possveis para
um atributo.
Cada ocorrncia da entidade representada pela relao (no exemplo, cada aluno) possui um
conjunto de valores que o descrevem. Tupla o conjunto de valores que, juntos,
descrevem um elemento (uma instncia) da entidade.
O modelo relacional tem esse nome porque representa os dados contidos em um banco de
dados atraves de relaes que contem inIormaes sobre as entidades representadas e as
interaes entre elas (relacionamentos). Mas o que so relaes?
InIormalmente, uma relao o conjunto de tuplas que descreve todas as ocorrncias,
representadas no banco de dados, de uma determinada entidade ou evento do mundo
real.
Entretanto devemos observar que, segundo a terminologia aplicada ao Modelo Relacional, os
valores existentes em uma relao num determinado momento so chamados de Valores de
Relao, e as variaveis que os contem de Variveis de Relao.
E muito comum utilizarmos o termo 'relao quando, na verdade, nos reIerimos a uma
variavel de relao. Em situaes menos Iormais a troca no e to problematica, mas como
essa pratica tende a causar uma certa conIuso, e bom observarmos com cuidado o uso desses
termos.
Vises
Uma viso e um tipo especial de variavel de relao, que e derivada da avaliao de uma
expresso relacional aplicada sobre outras variaveis de relao nesse instante.
A deIinio de uma viso e armazenada no dicionario de dados e e percebida por um usuario
como uma variavel de relao igual as demais. Dizemos que as vises so variveis de
relaes virtuais enquanto chamamos as variaveis de relao propriamente ditas de variveis
de relaes reais.
As vises no so Iisicamente armazenadas, portanto no so copias dos dados das variaveis
de relaes reais. Qualquer alterao nos dados contidos numa viso sera reIletida
instantaneamente nas variaveis de relaes subjacentes.
As vises so a Iorma, prevista no modelo relacional, de proporcionar a independncia de
dados logica, entretanto, no devemos conIundir as vises do modelo relacional com as vises
externas vistas na arquitetura ANSI/SPARC. O equivalente, no modelo relacional, as vises
externas ANSI/SPARC seria o conjunto de diversas variaveis de relaes (tanto reais quanto
virtuais) e as suas deIinies Iormariam o 'esquema externo.
DeIinio Iormal de uma relao
Uma relao e dividida em duas partes, uma parte abstrata que descreve os dominios que a
compem, chamada cabealho. E outra parte chamada corpo, concreta, com os dados que
representam cada uma das instncias da entidade descrita pela relao.
Ateno' Apesar da semelhana com uma tabela (linhas, colunas, cabealho e
corpo), uma relao no uma tabela. Uma relao e uma definio puramente
conceitual, no tendo uma representao fisica exata. Sua representao mais
proxima no mundo real e uma tabela. Na verdade, uma tabela a e representao
mais proxima de uma variavel de relao. Por essa ra:o, os SGBDR implementam
relaes por meio de tabelas e, neste trabalho, quando precisarmos representar
uma variavel de relao, usaremos o mesmo artificio.
Considere, como exemplo, a tabela (contendo a representao de algumas tuplas) abaixo:
CIDADE UF TEMPMIN TEMPMAX
Salvador BA 22,5 29,5
Vitoria da Conquista BA 18,2 27,3
Rio de Janeiro RJ 20,8 43,0
Gramado RS -2,0 26,7
Pelotas RS -0,5 32,0
Dados Iicticios
No cabealho esto descritos os atributos que compem a relao (CIDADE, UF,
TEMPMIN e TEMPMAX).
Essa relao apresenta quatro atributos, porem dois deles (TEMPMIN e TEMPMAX)
compartilham o mesmo dominio (temperaturas de -30 a 60 Celsius). Um atributo precisa ser
unico numa relao, um dominio no. O numero de atributos numa relao e chamado de
cardinalidade da relao. Essa e uma relao de cardinalidade quatro.
O corpo da relao e composto pelas tuplas que compem a relao.
A relao do nosso exemplo possui cinco tuplas. O numero de tuplas em uma relao
determina o grau da relao. Essa e uma relao de grau cinco.
Observemos agora uma deIinio mais Iormal do termo 'relao (C. J. Date):
'Dada uma coleo de n tipos ou dominios Ti (i 1, 2, ..., n), no necessariamente
todos distintos, r sera uma relao sobre esses tipos se consistir em duas partes, um
cabealho e um corpo, onde:
a. O cabealho e um conjunto de n atributos da Iorma Ai:Ti, onde Ai (que devem
ser todos distintos) so nomes de atributos de r e Ti so os nomes de tipos
correspondentes (i 1, 2, ..., n).
b. O corpo e um conjunto de m tuplas t, onde t e por sua vez um conjunto de
componentes da Iorma Ai:vi no qual vi e um valor do tipo Ti o valor do
atributo correspondente ao atributo Ai da tupla t (i 1, 2, ..., n).
Os valores m e n so chamados respectivamente cardinalidade e grau da relao r.
Propriedades de uma relao
Para que consideremos que um conjunto de atributos e uma relao, de acordo com o modelo
relacional, este conjunto precisa apresentar algumas propriedades especiIicas:
1. As tuplas devem ser unicas O corpo da relao e um conjunto de tuplas e os
conjuntos (em matematica) no possuem itens duplicados.
2. As tuplas no so ordenadas Tambem derivado do Iato do corpo da relao ser um
conjunto; os conjuntos (em matematica) no so ordenados.
3. Os atributos no so ordenados De modo similar a propriedade anterior, no ha
obrigatoriedade que os atributos tenham alguma ordem especiIica.
4. Cada tupla contem apenas um valor para cada atributo De acordo com a propria
deIinio Iormal, um tupla e um conjunto de pares ordenados na Iorma Ai:vi (i 1,
2, ..., n) no admitindo mais de um valor por atributo. Quando uma relao apresenta
essa propriedade, dizemos que esta na primeira forma normal. Veremos mais
detalhes quando tratarmos de normalizao.
Chaves
Por deIinio, o modelo relacional no permite a existncia de tuplas duplicadas, ou seja,
tendo todos os elementos de uma tupla, podemos reIerencia-la unicamente em uma variavel
de relao. Acontece que, normalmente, no sabemos todos os valores de uma tupla,
conhecemos apenas alguns e desejamos obter os demais. Para atender a essa necessidade, o
modelo relacional oIerece o instrumento das chaves.
Seja uma variavel de relao R. Na pratica, e Ireqente que um subconjunto K dos atributos
de R tenha o carater de unicidade. Dizemos que K e uma Chave Candidata de R se
apresentar ambas as propriedades a seguir:
1. Unicidade No existe duas tuplas de R com o mesmo valor de K.
2. Irredutibilidade Nenhum subconjunto de K tem a propriedade de unicidade.
Dessa Iorma, toda variavel de relao possui pelo menos UMA chave candidata. Dentre o
conjunto de todas as chaves candidatas de uma variavel de relao, o modelo relacional
escolhe uma para ser eleita Chave Primria, aquela utilizada como item identiIicador das
tuplas. As demais chaves candidatas recebem o nome de Chaves Alternativas. Elas tambem
identiIicam unicamente cada uma das tuplas e podem ser utilizadas em alguma circunstncia
especial para isto.
Ja vimos que o modelo relacional no utiliza ponteiros para conectar duas relaes entre si.
Essa ligao e realizada pelo aparecimento, nos atributos de uma relao, de um elemento de
ligao comum a ambas.
Sejam duas variaveis de relaes R1 e R2. Para que a variavel de relao R1 seja conectada a
variavel de relao R2, e necessario que um dos atributos de R2 reIerencie um atributo de R1,
e que esse atributo seja uma Chave Candidata de R1.
Dessa Iorma, uma Chave Estrangeira e um conjunto de atributos de uma variavel de relao,
cujos valores correspondem obrigatoriamente aos valores de uma chave candidata de outra
variavel de relao conectada a ela.
Normalizao
Normalizao e o processo ao qual devemos submeter uma relao para que possamos evitar
redundncias e tornar o projeto do nosso banco de dados mais eIiciente.
Dependncia Funcional
Para que possamos compreender o processo de normalizao de uma relao, precisamos do
conceito de Dependncia Funcional. Dizemos que um atributo A e dependente
Iuncionalmente de um atributo B, quando o valor de A e determinado pelo valor de B.
Considere a variavel de relao representada a seguir:
Gnero Sigla Ttulo Atores Principais Emissora Canal
Fco TOS Star Trek
Wam Shatner
Leonard Nmoy
Do P o : o s o l l o ,
USA 105
Fco TNG
Star Trek:
A Nova Gerao
Patrck Stewart
Brent Spnner
USA 105
Fco DS9
Star Trek:
Deep Space 9
Avery Brooks
Nana Vs tor
No no .ubo : ] o no i s
USA 105
Fco VOY
Star Trek:
Voyager
Kate Mugrew
Robert Pcardo
USA 105
Fco ENT Enterprse
Scott Bakua
|o ene Baock
o nno : I: i nno o :
AXN 103
Independente da existncia da chave primaria (EstiloSigla, as colunas sombreadas), o canal e
determinado pela emissora de cada serie. Dizemos portanto, que o atributo Canal depende
funcionalmente do atributo Emissora.
Formas Normais
Vimos que uma das propriedades de uma relao e estar na 'primeira Iorma normal, o
estagio inicial de normalizao. Entretanto, existem outros niveis de normalizao. Quanto
mais alto o nivel, mais proximo da Iorma relacional pura estara o banco de dados. Estudiosos
ja identiIicaram diversos niveis de normalizao (ou Iormas normais), entretanto os trs
primeiros so os mais utilizados, e bastam para o nosso estudo.
Primeira Forma Normal (1FN)
Uma variavel de relao estara na 1FN se e somente se, em todo valor valido dessa variavel
de relao, cada tupla contiver somente um valor para cada atributo. Ou seja, um atributo no
podera conter uma estrutura ou uma outra relao (valores multiplos).
No nosso exemplo, o atributo Atores
Principais apresenta mais de um valor para
cada tupla. Para que a variavel de relao
esteja na 1FN, devemos criar uma segunda
variavel de relao contendo apenas os
nomes dos autores e conectada a primeira
por meio de uma relao 'um-para-muitos.
Sigla Ator Nome
TOS 001 Wam Shatner
TOS 002 Leonard Nmoy
TOS 003 DeForest Keey
TNG 001 Patrck Stewart
TNG 002 Brent Spnner
DS9 001 Avery Brooks
DS9 002 Nana Vstor
DS9 003 Rene Auber|onos
VOY 001 Kate Mugrew
VOY 002 Robert Pcardo
ENT 001 Scott Bakua
ENT 002 |oene Baock
ENT 003 Connor Trnneer
Segunda Forma Normal (2FN)
Uma variavel de relao estara na 2FN se e somente se, ela estiver na 1FN e todo atributo
no-chave Ior irredutivelmente dependente da chave primaria. Ou seja, caso a chave primaria
seja composta por mais de um atributo, nenhum dos atributos no-chave podera depender de
parte da chave primaria.
Ainda no nosso exemplo, a chave primaria e composta pelos atributos Gnero e Sigla,
entretanto, os demais atributos dependem Iuncionalmente apenas do atributo Sigla. Para que a
variavel de relao esteja na 2FN, basta retirarmos o atributo Gnero da chave primaria
deixando-o como um atributo no-chave normal. A chave primaria passaria a ser apenas o
atributo Sigla.
Terceira Forma Normal (3FN)
Uma variavel de relao estara na 3FN se e somente se, ela estiver na 2FN e todo atributo
no-chave Ior dependente exclusivamente da chave primaria. Ou seja, nenhum atributo podera
ser Iuncionalmente dependente de outro atributo que no pertena a chave primaria. Vale
ressaltar que, no caso de existirem chaves candidatas que no sejam a chave primaria essa
Iorma normal no e muito adequada, devendo ser substituida pela Forma Normal de Boyce-
Codd (BCFN):
Uma variavel de relao estara na BCFN se e somente se, os unicos determinantes
so chaves candidatas.
Voltando ao nosso exemplo, o atributo Canal
no depende da chave primaria, e sim do
atributo Emissora.. Para que a variavel de
relao esteja na 3FN, devemos criar uma
terceira variavel de relao contendo apenas
os canais e emissoras, e conectada a primeira
por meio de uma relao 'um-para-muitos.
Emissora Nome Canal
001 USA 105
002 AXN 103
Regras praticas para normalizao
Podemos resumir o processo de normalizao na aplicao de algumas regras praticas que
garantiro que o banco de dados atendera as condies das 3 Iormas normais:
CertiIique-se que todos os atributos na variavel de relao estejam relacionados
entre si.
Evite a redundncia, dentro de cada tupla e dentro da variavel de relao.
Assegure-se que todo atributo em uma variavel de relao dependa Iuncionalmente
da chave primaria e apenas dela.
Altere o Iormato das variaveis de relao desmembrando tuplas e variaveis de relao sempre
que preciso.
O Dicionario de Dados
Uma das Iunes do SGBD e Iornecer o dicionario de dados. O dicionario de dados contem as
deIinies de todos os objetos contidos no banco de dados, como os esquemas (interno,
conceitual e os varios externos), o mapeamento externo/conceitual e o mapeamento
conceitual/interno, as diversas variaveis de relaes e seus indices, as relaes de integridade
e segurana e os usuarios e suas permisses.
Essas inIormaes so utilizadas pelo SGBD para realizar suas Iunes. Quando um usuario
Iaz uma requisio, por exemplo, o SGBD utiliza as inIormaes de usuarios e restries de
segurana para permitir o acesso e, uma vez aceita a requisio, as deIinies dos indices e
estruturas de armazenamento so utilizadas para otimizar requisio.
Uma vez que o Modelo Relacional e baseado na teoria de conjuntos, a maioria das operaes
realizadas nesse modelo so no-procedurais (ou no-procedimentais), ou seja, especiIica-
se o 'que e no o 'como. Dessa Iorma, especiIicamos os dados que desejamos, e cabe ao
SGBD decidir a melhor maneira de obt-los. A propria navegao entre os dados e
transparente para o usuario. Dessa Iorma, o dicionario de dados e uma Ionte de inIormaes
Iundamental para que o SGBD realize essas tareIas da Iorma mais eIiciente. Quando
estudarmos sobre otimizao, veremos mais detalhes sobre isso.
O Simbolo NULL
Existem situaes em que e necessario representar a ausncia de um valor num banco de
dados. Muitas vezes porque no conhecemos o valor para inIorma-lo (qual o tipo sangineo
do proIessor Fulano?), outras porque o valor no se aplica (qual o numero de Iilhos de uma
criana recem-nascido?).
Para esses casos, o modelo relacional oIerece a noo de NULL. NULL no e exatamente um
valor, pode ser considerado um simbolo que representa o vazio. A traduo para o portugus
seria 'nulo, entretanto a mais adequada as nossas necessidades seria 'desconhecido.
O modelo relacional determina que NULL no coincidira com nenhum valor, nem mesmo
com NULL. Dessa Iorma, no pode ser comparado a nada, qualquer comparao devolve um
valor NULL como resposta.
Como tudo, NULL tem suas vantagens e desvantagens. A principal vantagem e que permite a
representao da inexistncia de valores, Iacilitando a criao de restries que envolvam essa
situao. Sua principal desvantagem e o aumento da complexidade na logica de qualquer
desenvolvimento que utilize SQL , uma vez que passam a existir trs resultados para a
maioria dos testes logicos (mais detalhes em Operadores Logicos).
Existe muita controversia sobre a utilizao do NULL, autores de renome como C. J. Date e o
proprio E. F. Codd ainda no chegaram a um acordo sobre esse valor especial, discutindo
sobre a validade de utiliza-lo no modelo relacional. No temos a inteno de resolver essa
questo neste trabalho. Apenas reconheceremos que esse simbolo existe (e implementado em
todos os SGBDR) e tem varias utilidades.
Com os devidos cuidados quanto aos testes logicos, e uma Ierramenta muito util. E como
acontece com qualquer Ierramenta, a deciso de utiliza-lo e prerrogativa do desenvolvedor
(administrador de dados e DBA).
Integridade
A integridade de um banco de dados reIere-se a preciso ou correo dos dados nele
armazenados. Garantimos essa integridade por meio de Restries de Integridade que so
armazenadas no dicionario de dados. O SGBD encarrega-se ento de, a cada operao que
acarrete alterao nos dados, veriIicar se a alterao solicitada viola as restries de
integridade. Em caso aIirmativo, a operao e interrompida.
As restries de integridade caracteristicas da empresa proprietaria do banco de dados so
normalmente chamadas de Regras de Negocio, pois descrevem o Iuncionamento do negocio
da empresa. So deIinidas pelo Administrador de Dados e evitam o armazenamento de dados
em desacordo com a politica da empresa. Por exemplo, se uma politica da empresa determina
que o desconto comercial maximo concedido a um cliente e de dez por cento, uma operao
de atualizao no banco de dados que inIorme um desconto de vinte por cento sera
interrompida.
Alem das regras de negocio, existem restries que visam a manter a integridade dos dados do
banco de dados, independente da politica da empresa. Podemos classiIicar essas restries de
integridade em restries de: tipos de dados, integridade de entidade e integridade reIerencial.
Restries de Tipos de Dados
Evitam que dados incompativeis com os tipos de dados selecionados para seus atributos
(como datas invalidas) sejam aceitos pelo banco de dados.
Restries de Integridade de Entidade
Garantem que as chaves primarias tenham valores validos, uma vez que o objetivo de uma
chave primaria e a identiIicao de uma tupla.
Restries de Integridade ReIerencial
Garantem a integridade das relaes entre duas ou mais variaveis de relaes, devendo uma
chave estrangeira apontar para uma tupla existente.
Quando uma variavel de relao esta conectada a outra por meio de uma chave estrangeira, a
incluso (ou alterao) de dados numa tupla deve ser supervisionada para evitar que a chave
estrangeira armazene dados invalidos.
Durante a excluso de uma tupla apontada pelas chaves estrangeiras de tuplas de outras
variaveis de relaes, podem ser utilizadas trs estrategias para manter a integridade:
A operao sera interrompida.
As tuplas relacionadas sero excluidas em cascata. Essa estrategia deve ser
utilizada com cuidado por razes obvias, aIinal ninguem quer dados sendo
excluidos em seqncia do banco de dados.
Os valores das chaves estrangeiras nas tuplas relacionadas sero alterados para
apontarem para uma outra tupla ou para um valor padro (podendo inclusive ser o
valor NULL).
Linguagem de Acesso Estruturada (SQL)
A especiIicao de E. F. Codd para o Modelo Relacional determinava que os usuarios teriam
acesso ao banco de dados atraves de uma linguagem de consulta e que ela seria a nica Iorma
de acesso aos dados.
Em 1974, cinco anos apos a publicao do Modelo Relacional, Ioi iniciado na IBM o
desenvolvimento do System/R, o primeiro prototipo de um SGBDR. Para o acesso, Ioi criada
uma linguagem denominada SEQUEL. Mais tarde seu nome Ioi alterado para Structured
Querv Language (Linguagem de Consulta Estruturada) ou SQL. Atualmente a palavra 'SQL
deixou de ser um acrnimo para ser o proprio nome da linguagem.
Na decada de 80, a linguagem SQL Ioi escolhida pelo American National Standards Institute
(ANSI) e pouco depois, pelo International Standards Institute (ISO), como a linguagem de
consulta padro para bancos de dados relacionais.
O primeiro padro, publicado em 1989 pelas duas organizaes, Iicou conhecido como SQL1
ou SQL-89. Em 1992, esse padro Ioi revisado e e o atual, conhecido como SQL/92, SQL-92
ou SQL2. Seu nome oIicial agora e International Standard Database Language SQL (1992).
E esse padro que veremos neste trabalho.
Um novo padro (SQL3 ou SQL:1999) Ioi desenvolvido para ser uma 'SQL orientada a
objetos, para atender ao acesso a bancos de dados orientados a objeto. Poucos SGBD
implementam algumas de suas extenses (Oracle9i), e ainda no ha nenhum que consiga
implementar todas.
Caracteristicas da SQL
E uma linguagem simples e Iacil de aprender. Os comandos so escritos quase em linguagem
natural (ingls) permitindo que mesmo aqueles que no so programadores possam escrever
suas consultas relativamente rapido. No e necessario conhecer logica de programao. As
instrues so executadas separadamente, dessa Iorma, aprender SQL e aprender a sintaxe de
cada instruo SQL e o que ela Iaz.
Por isso e por ter sido desenhada originalmente para ser uma sublinguagem de dados, a SQL
no contem instrues de controle de Iluxo, laos ou de redirecionamento de entrada e saida.
O objetivo inicial era que a SQL dependesse de uma linguagem hospedeira que oIerecesse tais
recursos.
Com a introduo, em 1996, do recurso de Modulos Armazenados Persistentes (Persistent
Data Modules PSM) a SQL tornou-se mais poderosa. No entanto, o nosso estudo sera
concentrado no padro SQL/92.
A SQL no adota, rigorosamente, o modelo relacional. Entre as diIerenas podemos observar:
O termo 'tabela substitui os termos 'variavel de relao e 'relao.
Os termos 'coluna e 'campo substituem o termo 'atributo.
Os termos 'linha e 'registro substitui o termo 'tupla.
Podem existir linhas duplicadas, enquanto no modelo relacional as tuplas devem ser
unicas.
A SQL no possui um numero ilimitado de tipos de dados, ao contrario do modelo
relacional.
Apesar disso, a SQL implementa o modelo relacional de maneira muito conIiavel.
A SQL e uma linguagem muito grande. O documento padro da SQL/92 (ISO 9075) possui
mais de 600 paginas. Faremos, portanto, um estudo superIicial da linguagem, enIocando os
pontos mais utilizados. Sera o suIiciente, porem, para executar as tareIas mais exigidas na
criao e acesso a um banco de dados relacional.
Estrutura da SQL
A SQL no e case-sensitive, ou seja, no diIerencia letras maiusculas ou minusculas. Isso
quer dizer que 'SELECT e 'SeLeCt tm o mesmo signiIicado. Tradicionalmente
escrevemos as palavras reservadas em maiusculas e os demais nomes em minusculas (exceto
as constantes), mas isso no e obrigatorio.
Utilizamos o caractere ponto-e-virgula (';) como indicador de termino de instruo.
Os nomes de campos, tabelas, vises e demais objetos devem conter apenas letras, numeros e
alguns caracteres especiais, em particular o trao ('-) e o sublinhado ('). Espaos no so
permitidos.
Palavras Reservadas
A SQL/92 possui mais de 300 palavras reservadas (palavras que no podem ser utilizadas
como nomes de campos ou de variaveis). Desse grande numero, apenas algumas so
utilizadas com mais Ireqncia:
Palavras reservadas - SQL/92
ABSOLUTE ACTION ADA ADD ALL
ALLOCATE ALTER AND ANY ARE
AS ASC ASSERTION AT AUTHORIZATION
AVG BEGIN BETWEEN BIT BIT_LENGTH
BOTH BY CASCADE CASCADED CASE
CAST CATALOG CHAR CHAR_LENGTH CHARACTER
CHARACTER_LENG
TH
CHECK CLOSE COALESCE COLLATE
COLLATION COLUMN COMMIT CONNECT CONNECTION
CONSTRAINT CONSTRAINTS CONTINUE CONVERT CORRESPONDING
COUNT CREATE CROSS CURRENT CURRENT_DATE
CURRENT_TIME
CURRENT_TIMEST
AMP
CURRENT_USER CURSOR DATE
DAY DEALLOCATE DEC DECIMAL DECLARE
DEFAULT DEFERRABLE DEFERRED DELETE DESC
DESCRIBE DESCRIPTOR DIAGNOSTICS DISCONNECT DISTINCT
DOMAIN DOUBLE DROP ELSE END
END-EXEC ESCAPE EXCEPT EXCEPTION EXEC
EXECUTE EXISTS EXTERNAL EXTRACT FALSE
FETCH FIRST FLOAT FOR FOREIGN
FORTRAN FOUND FROM FULL GET
GLOBAL GO GOTO GRANT GROUP
HAVING HOUR IDENTITY IMMEDIATE IN
INCLUDE INDEX INDICATOR INITIALLY INNER
INPUT INSENSITIVE INSERT INT INTEGER
INTERSECT INTERVAL INTO IS ISOLATION
|OIN KEY LANGUAGE LAST LEADING
LEFT LEVEL LIKE LOCAL LOWER
MATCH MAX MIN MINUTE MODULE
MONTH NAMES NATIONAL NATURAL NCHAR
NEXT NO NONE NOT NULL
NULLIF NUMERIC OCTET_LENGTH OF ON
ONLY OPEN OPTION OR ORDER
OUTER OUTPUT OVERLAPS PAD PARTIAL
PASCAL POSITION PRECISION PREPARE PRESERVE
PRIMARY PRIOR PRIVILEGES PROCEDURE PUBLIC
READ REAL REFERENCES RELATIVE RESTRICT
REVOKE RIGHT ROLLBACK ROWS SCHEMA
SCROLL SECOND SECTION SELECT SESSION
SESSION_USER SET SIZE SMALLINT SOME
SPACE SOL SOLCA SOLCODE SOLERROR
SOLSTATE SOLWARNING SUBSTRING SUM SYSTEM_USER
TABLE TEMPORARY THEN TIME TIMESTAMP
TIMEZONE_HOUR
TIMEZONE_MINUT
E
TO TRAILING TRANSACTION
TRANSLATE TRANSLATION TRIM TRUE UNION
UNIOUE UNKNOWN UPDATE UPPER USAGE
USER USING VALUE VALUES VARCHAR
VARYING VIEW WHEN WHENEVER WHERE
WITH WORK WRITE YEAR ZONE
Tipos de dados
A SQL no permite que os usuarios deIinam os seus proprios tipos de dados, eles podem criar
dominios que utilizem os tipos ja existentes. Observem os mais comuns:
Tipos de dados mais comuns - SQL/92
CHAR(n)
CHARACTER (n)
n bytes
Cadeia de caracteres, com tamanho Iixo de ate 254
bytes.
VARCHAR (n)
CHAR VARYING (n)
CHARACTER VARYING (n)
n bytes
Cadeia de caracteres, com tamanho variavel de ate 254
bytes.
LONG VARCHAR (n) Variavel
Cadeia de caracteres, com tamanho no Iixado maior
que 254 bytes. E equivalente ao BLOB.
DATE 8 bytes
Armazena Datas. Possui dez posies e seu Iormato
padro e YYYY-MM-DD.
TIME 8 bytes
Armazena Horas. Possui oito posies e seu Iormato
padro e HH:MM:SS.
TIMESTAMP
DATETIME
8 bytes Armazena, simultaneamente, inIormao de data e hora.
INTEGER
INT
4 bytes
Armazena numeros inteiros de ate 10 digitos.
-2147483648 a 2147483647
SMALLINT 2 bytes
Armazena numeros inteiros de ate 5 digitos.
-32.768 a 32.768
FLOAT (n) 12 bytes
Armazena valores de ponto Ilutuante com preciso
simples (7 digitos).
1,175 x 10
-38
a 3,402 x 10
38
DOUBLE 16 bytes
Armazena valores de ponto Ilutuante com preciso dupla
(15 digitos).
2,225 x 10
-308
a 1,797 x 10
308
DECIMAL (p, s)
2, 4 ou 8
bytes
Armazena valores com numero Iixo de casas decimais. p
e o numero digitos para representar os inteiros e s e o
numero de digitos para representar os decimais.
Instrues SQL
Podemos dividir as instrues da linguagem SQL em trs grupos:
1. Data Definition Language (DDL) Comandos responsaveis pela criao dos proprio
banco de dados, suas tabelas, indices, vises, etc.
2. Data Control Language (DCL) Comandos relacionados a segurana do banco de
dados, atribuindo privilegios de acesso aos usuarios do banco de dados.
3. Data Manipulation Language (DML) Comandos para acesso (consulta e alterao)
aos dados do banco de dados.
Veremos algumas instrues de cada um desses trs grupos nas trs proximas sees.
Apesar de desenvolvida para ser portavel, e diIicil utilizar um trecho de codigo em SQL
escrito para um SGBD em outro, sem nenhuma alterao. Em parte, isso e conseqncia da
existncia de trs padres diIerentes e do Iato de cada SGBD acrescentar extenses
proprietarias visando a otimizar o seu proprio Iuncionamento. Felizmente as alteraes
necessarias so, normalmente, simples e rapidas.
Neste trabalho manteremos a sintaxe mais proxima da SQL/92, exceto quando o PostreSQL
tiver uma sintaxe diIerente. Neste caso, optaremos pela sintaxe mais simples. Quando
possivel, as clausulas mais complexas (e menos utilizadas) sero omitidas.
Notao utilizada
Ao descrevermos a sintaxe de um comando, utilizaremos a notao mais comum no meio da
inIormatica:
1. Palavras-chaves estaro em NEGRITO.
2. Parmetros Iornecidos pelo usuario estaro em itlico.
3. Parmetros Iornecidos pelo usuario, que podem ser divididos em elementos menores,
estaro <destacados>.
4. Quando houver mais um parmetro aplicavel a uma determinada situao:
4.1. As opes disponiveis estaro separadas por uma '| (barra vertical).
4.2. Os parmetros obrigatorios estaro entre {chaves}. Apenas um desses
parmetros deve ser digitado.
4.3. Os parmetros opcionais estaro entre [colchetes].
Instrues DDL
As instrues DDL so responsaveis pela criao, alterao e excluso dos elementos do
banco de dados. No so executadas com Ireqncia e quando so, demandam cuidado pois
so permanentes, no oIerecendo condio de desIazer (rollback) alguma alterao. So
normalmente executados pelo DBA e por um seleto grupo de usuarios.
Create Database
CREATE DATABASE database;
Cria o banco de dados (quando o SGBD pode manipular mais de um banco de dados).
Instruo no implementada na SQL/92, o SGBD trabalha somente com um banco de dados.
Drop Database
DROP DATABASE database;
Exclui um banco de dados existente no SGBD. Uma vez executada essa instruo, nenhum
dado do banco de dados excluido podera ser recuperado. Instruo no implementada na
SQL/92.
Connect
CONNECT database;
Seleciona um banco de dados dentre os existentes no SGBD para trabalhar. Instruo no
implementada na SQL/92.
Create Table
CREATE TABLE table( <coldef> |, <coldef> | <tconstraint> ...| );
Onde:
<coldef> = col { <datatype> | COMPUTED | BY | (<expr>)} | NOT NULL |
| DEFAULT { literal | NULL | USER } |, | <colconstraint> |
<datatype> = um dos t pos de dados def n dos na SOL2.
<expr> = Uma expresso SOL v da que resu te em um nco vaor .
<colconstrai nt > = | CONSTRAlNT constraint |
{ PRlMARY KEY
| UNlUE
| REFERENCES othertable |(othercol |, othercol ...|)|
| ON DELETE { NO ACTlON | CASCADE | SET NULL | SET DEFAULT } |
| ON UPDATE { NO ACTlON | CASCADE | SET NULL | SET DEFAULT } |
| CHECK ( condition ) }
<tconstrai nt > = | CONSTRAlNT constraint |
{ { PRlMARY KEY | UNlUE} ( col |, col ...| )
| FORElGN KEY ( col |, col ...| ) REFERENCES | othertable ( othercol |,
othercol ...| ) |
Cria uma tabela no banco de dados corrente, deIinindo as colunas (campos), chaves primarias,
chaves estrangeiras, indices alternativos e restries.
Observaes:
table e o nome da tabela a ser criada.
col e o nome da coluna a ser criada. A deIinio das colunas de uma tabela e Ieita
relacionando-as uma apos a outra.
datatvpe contem o tipo e tamanho dos campos deIinidos para a tabela, segundo o
padro SQL/92.
COMPUTED BY Campos calculados, onde o valor e obtido atraves de uma
expresso que pode envolver outras colunas das tabelas (as colunas devem ser
deIinidas antes da coluna calculada). O conteudo de um campo calculado no e
armazenado, e sim resolvido quando se pede ao SGBD.
NOT NULL Exige o preenchimento do campo, ou seja, e obrigatorio que possua um
conteudo.
DEFAULT Preenche o campo com valores pre-deIinidos de acordo com o tipo do
campo, caso no seja especiIicado o seu conteudo no momento da incluso de novas
linhas. Os valores pre-deIinidos so:
Campos numericos: Zero
Campos alIanumericos: Caractere branco (ASCII 32)
Campo Iormato Date: Data corrente.
Campo Iormato Time: Horario corrente.
NULL: valores nulos
USER: o nome do usuario que esta alterando a linha no momento
CONSTRAINT DeIine o nome para a restrio.
PRIMARY KEY DeIine qual a coluna que sera a chave primaria da tabela. Caso a
tabela tenha mais de uma coluna como chave, elas devero ser relacionadas entre
parnteses e separadas por virgulas.
FOREIGN KEY DeIine quais as colunas que sero chaves estrangeiras. Na clausula
REFERENCES deve ser especiIicada a tabela relacionada.
ON DELETE Esta clausula deIine o comportamento quando houver a excluso de
uma linha nas tabelas reIerenciadas nas chaves estrangeiras, determinando se a
excluso deve ser propagada na tabela atual. As opes so:
NO ACTION No permite a excluso de uma linha na tabela relacionada, se
houver alguma linha na tabela atual reIerenciado-o. O mesmo que a opo
'RESTRICT.
CASCADE Exclui todas as linhas da tabela atual que esto relacionados a
linha excluida na tabela relacionada.
SET NULL Atribui o valor NULL a chave estrangeira em todos as linhas da
tabela atual que estejam relacionadas ao registro excluido.
SET DEFAULT Atribui o valor DEFAULT a chave estrangeira em todas as
linhas da tabela atual que estejam relacionadas a linha excluida.
ON UPDATE Esta clausula deIine o comportamento quando houver alterao nas
colunas reIerenciada nas chaves estrangeiras, determinando se a alterao deve ser
propagada na tabela atual. As opes so as mesmas da clausula ON DELETE.
CHECK Esta clausula permite criar uma restrio de linha. Isto e, uma restrio que
veriIica a validade de uma expresso a cada tentativa de incluso ou alterao de uma
linha.
Drop Table
DROPTABLE table;
Exclui a tabela do banco de dados corrente. Ao ser executada essa instruo, alem da
estrutura, sero excluidos os dados e os indices relacionados a tabela.
Alter Table
ALTER TABLE table<operation> |, <operation> ... |;
Onde:
<operat i on> = { ADD <coldef>
| ADD <tconstraint>
| ALTER | COLUMN | colname <altcolclause>
| DROP col
| DROP CONSTRAlNT constraint }
<al tcol cl ause > = { TO newcolname
| TYPE newdatatype
| POSlTlON newposition}
<datatype> = um dos t pos de dados def n dos na SOL2.
<expr> = Uma expresso SOL v da que resu te em um nco vaor .
<colconstrai nt > = | CONSTRAlNT constraint |
{ PRlMARY KEY
| UNlUE
| REFERENCES othertable | ( othercol |, othercol ... | ) |
<tconstrai nt > = | CONSTRAlNT constraint |
{ { PRlMARY KEY | UNlUE } ( col |, col ... | )
| FORElGN KEY ( col |, col ...| ) REFERENCES othertable | ( othercol |,
othercol ...| )|
Altera a estrutura de uma tabela acrescentando, alterando e retirando colunas ou restries de
integridade.
Observaes:
ADD Inclui uma nova coluna ou restrio.
ALTER Troca o nome da coluna, seu tipo de dado e posio.
DROP Exclui uma coluna ou restrio.
Create View
CREATE VlEW view | column | , ... | |
AS SELECT expr | AS colname | |, ... |
FROM table
| WHERE <condition> |;
Onde:
<condi t i on> = Cr tr os de seeo de nhas a serem nc u das.
Cria uma viso no banco de dados corrente, deIinindo as colunas a serem exibidas e os
criterios de seleo utilizados para selecionar as linhas exibidas na viso.
Drop View
DROPVlEW view;
Exclui a viso do banco de dados corrente. Ao ser executada essa instruo apenas a estrutura
da viso sera excluida, os dados das tabelas subjacentes no sero aIetados.
Create Index
CREATE | UNlUE | | ASC|ENDlNG| | DESC|ENDlNG| | lNDEX index
ON table ( col |, col ...| );
Cria um indice de acesso para uma ou mais colunas em uma tabela. O uso de indices aumenta
a velocidade de acesso aos dados em uma operao de seleo. Instruo no implementada
na SQL/92.
Observaes:
UNIQUE impede a existncia mais de uma linha com o mesmo valor na(s) coluna(s)
especiIicadas.
ASC|ENDING| classiIica as linhas em ordem crescente. Opo padro.
DESC|ENDING| classiIica as linhas em ordem decrescente.
Drop Index
DROP lNDEX index;
Exclui o indice do banco de dados. Instruo no implementada na SQL/92.
Alter Index
ALTER lNDEX index { ACTlVE | lNACTlVE };
Ao contrario do esperado, a instruo ALTER INDEX no permite alterar um indice ja
existente acrescentando ou excluindo colunas. Ela permite ativar ou desativar um indice. E
utilizada normalmente antes da incluso de um grande numero de linhas para aumentar a
velocidade, ja que quando inativo, o indice no e atualizado. Ao reativa-lo, o indice e
atualizado de uma so vez de Iorma a corresponder a situao atual da tabela. Para adicionar ou
remover colunas em um indice, utilize a instruo DROP INDEX para exclui-lo e ento
utilize a instruo CREATE INDEX para recria-lo. Instruo no implementada na SQL/92.
Instrues DCL
Devido a importncia dos dados, muitas vezes no e desejavel que qualquer usuario tenha
acesso a eles. Por essa razo, e possivel deIinir niveis de acesso num banco de dados,
restringindo o acesso a determinadas tabelas a um numero restrito de usuarios. Ou ainda,
limitar certas tareIas a um grupo especiIico de usuarios: certos usuarios teriam permisso
apenas para consultar registros enquanto a outros seria dada permisso para alterar os dados
armazenados.
Create Group
CREATE GROUP <groupname> | WlTH | SYSlD <gid> | | USER <username> |, ... | | |;
Onde:
<groupname> = Nome de um grupo de usur os.
<gid> = Nmero de dent f cao do grupo no PostgreSOL. Se no nformado, ut zado o
prxmo nmero dsponve (tmo exstente mas um).
<username> = Usuros ( | exstentes) a serem nc u dos no grupo.
Permite criar um grupo de usuarios que recebera privilegios de acesso a determinados objetos
do banco de dados. Somente o DBA tem permisso de criar, alterar e excluir grupos. Essa
instruo no existe no padro SQL/92. O padro SQL/92 implementa a instruo ROLE que
desempenha papel semelhante.
Alter Group
ALTER GROUP <groupname> ADD USER <username> |, ... |;
ou
ALTER GROUP <groupname> DROP USER <username> |, ... |;
Onde:
<username> = Usuros a serem nc u dos no grupo ou removdos dee.
Permite alterar os usuarios que compem um grupo. No caso de incluso de usuarios no
grupo, os usuarios devem ter sido criados previamente. Os usuarios no soIrem nenhuma
alterao exceto a saida do grupo.
Drop Group
DROPGROUP <groupname>;
Onde:
Exclui um grupo do banco de dados. Os usuarios no soIrem nenhuma alterao exceto a
saida do grupo.
Grant
GRANT <pri vi l eges > ON <object_list> TO {PUBLlC | GROUP usergroup | username };
Onde:
<pri vi l eges > = { ALL | PRlVlLEGES | | <privilege_list> }
<pri vi l ege_l i s t > = SELECT | lNSERT | UPDATE | DELETE | RULE
<object_ l i s t > = Nomes de tabeas ou vses, separados por v rguas.
Permite ao criador de um objeto (tabela ou viso) atribuir privilegios de acesso para um
determinado usuario ou grupo de usuarios. Nenhum usuario tem permisso sobre um
determinado objeto do banco de dados, exceto quando permitido pelo criador do objeto. O
criador de um objeto tem, por deIinio, acesso total ao objeto.
Observaes:
Os privilegios listados devem ser separados por virgulas.
Os nomes dos objetos listados devem ser separados por virgulas.
As opes de privilegios a serem atribuidos so:
ALL Acesso total a tabela ou viso.
SELECT Permisso para acessar todas as colunas da tabela numa seleo
INSERT Permisso para incluir dados em todas as colunas da tabela.
UPDATE Permisso para atualizar dados em todas as colunas da tabela.
DELETE Permisso para eliminar linhas da tabela.
RULE Permisso para deIinir regras para a tabela.
Os usuarios que recebero os privilegios podem ser especiIicados um de cada vez
(pelo seu username), por meio de grupos (GROUP) ou por meio da clausula PUBLIC
que atribui o privilegio a todos os usuarios do banco de dados.
Revoke
REVOKE <pri vi l ege > ON <objectlist> FROM {PUBLlC | GROUP usergroup | username};
Onde:
<privilege> = { ALL [ PRIVILEGES ] | <privilege_list> }
<privilege_list> = SELECT | INSERT | UPDATE | DELETE | RULE
<objectlist> = Uma lista com nomes de tabelas ou vises, separados por vrgulas.
Permite ao criador de um objeto (tabela ou viso) retirar privilegios de acesso para um
determinado usuario ou grupo de usuarios.
Observaes:
Os privilegios listados devem ser separados por virgulas.
Os nomes dos objetos listados devem ser separados por virgulas.
As opes de privilegios a serem atribuidos so:
ALL Impede todo o acesso a tabela ou viso.
SELECT Impede o acesso as colunas da tabela numa seleo
INSERT Impede a insero de dados nas colunas da tabela.
UPDATE Impede a atualizao de dados nas colunas da tabela.
DELETE Impede a excluso de linhas da tabela.
RULE Impede a deIinio de regras para a tabela.
Os usuarios que perdero os privilegios podem ser especiIicados um de cada vez (pelo
seu username), por meio de grupos (GROUP) ou por meio da clausula PUBLIC que
retira o privilegio de todos os usuarios do banco de dados.
Instrues DML
As instrues DML so responsaveis pela manipulao dos dados de um banco de dados.
Permitem a incluso de novas linhas e a alterao e excluso das existentes. So instrues
executadas com bastante Ireqncia e por um grande numero de usuarios e, devido ao suporte
a transaes, permitem que um comando seja desIeito caso ocorra algum problema.
Insert
lNSERT lNTO table| ( col | , ... | ) |
{ DEFAULT VALUES | VALUES ( expr | , ... | ) | SELECT query };
Insere nova(s) linha(s) em uma tabela ou viso. Os valores podem ser constantes
especiIicadas ou o resultado de uma expresso especiIicada. E possivel ainda a incluso de
um conjunto de linhas deIinido por meio de uma consulta SQL. As linhas devero atender as
restries de integridade e segurana deIinidas para o banco de dados, caso contrario a
instruo Ialhara.
Observaes:
table e o nome da tabela que recebera as novas linhas.
col e o nome da coluna que tera os valores deIinidos.
expr e uma expresso valida, ou uma constante literal.
querv e uma consulta SQL que resultara num conjunto de linhas a serem incluidas.
Update
UPDATE tableSET col = expr | , ... |
| WHERE condition |;
Altera os valores nas colunas especiIicadas para todas as linhas. Caso seja especiIicada uma
condio na clausula opcional WHERE, somente as linhas que satisIizerem a essa condio
sero aIetadas. Devero aparecer na instruo todas as colunas que sero alteradas. Caso as
alteraes solicitadas no atendam as restries de integridade e segurana, a instruo
Ialhara.
Observaes:
table e o nome da tabela que sera alterada.
col e o nome da coluna que tera os valores alterados.
expr e uma expresso valida, ou uma constante literal.
condition condio SQL que determinara quais linhas sero aIetadas.
Delete
DELETE FROM table
| WHERE condition |;
Exclui linhas da tabela especiIicada. Caso seja especiIicada uma condio na clausula
opcional WHERE, somente as linhas que satisIizerem a essa condio sero aIetadas.
Observaes:
table e o nome da tabela que sera alterada.
Ateno: Sem a clausula WHERE, a instruo excluira todas as linhas da tabela
especiIicada.
Begin Transaction
BEGlN | WORK | TRANSACTlON |;
Inicia uma transao. Normalmente o SGBD considera cada instruo do usuario como uma
transao isolada. Essa instruo indica que as instrues a seguir compem uma unica
transao.
Observaes:
Tanto a clausula WORK quanto a clausula TRANSACTION so opcionais. Servem
apenas para tornar a instruo mais inteligivel para os usuarios.
Commit
COMMlT | WORK | TRANSACTlON |;
Torna permanente e encerra a transao corrente. Todas as alteraes Ieitas tornam-se visiveis
para os demais usuarios.
Observaes:
Tem como sinnima, a instruo END.
Rollback
ROLLBACK | WORK | TRANSACTlON |;
Interrompe a transao atual, desIazendo todas as alteraes ocorridas durante ela.
Observaes:
Tem como sinnima, a instruo ABORT.
Select
SELECT | ALL | DlSTlNCT |
<selectedcolumns > | FROM <from_item> |, ...| |
| WHERE condition |
| GROUP BY <columndef> | , ... | |
| HAVlNG condition | , ... | |
| { UNlON | ALL | | lNTERSECT | ALL | | EXCEPT | ALL | } <other_select> |
| ORDER BY <columndef> | ASC | DESC |;
Onde:
<selectedcolumns > = { * | < showncolumns> |, ...| }
<showncolumns> = <columndef> | AS outputname |
<columndef> = { col | expr }
<f rom_i tem> = { tablename | | AS | alias |
| ( other_select ) | AS | alias
| <from_item> <join_type> <from_item> | ON join_condition
| USlNG ( join_column_list ) | }
Uma refernca a uma tabea, o resutado de uma nstruo SELECT ou o resutado de
uma cusua |OIN.
<joi n_type > = { | lNNER | ]OlN | LEFT | OUTER | ]OlN | RlGHT | OUTER | ]OlN
| FULL | OUTER | ]OlN | CROSS ]OlN }
<other_sel ect > = Uma outra nst ruo SELECT (sem as cusuas GROUP BY, HAVING e ORDER
P Y) guo s o : o o mbi nada o o m a p: i mo i : a.
Essa instruo recupera dados de uma ou mais tabelas retornando-os em uma tabela resultante
(mesmo que temporaria). Essa tabela tera como colunas as expresses listadas em
selectedcolumns~. As linhas que satisIizerem a clausula WHERE sero as linhas da nova
tabela. Se no houver clausula WHERE, todas as linhas sero selecionadas.
Observaes:
condition e uma expresso que aplicada as linhas, resulte nos valores logicos
Verdadeiro ou Falso. Essa expresso sera utilizada para selecionar as linhas que
aparecero na tabela gerada pela instruo.
col e o nome da coluna que sera incluida na seleo.
expr e uma expresso SQL valida que resulte num valor.
alias e o nome alternativo dado a uma origem de dados (tabela ou resultado de
instruo SELECT).
DISTINCT Elimina linhas duplicadas do resultado da instruo.
ALL Retorna todas as linhas no resultado da instruo, inclusive as linhas
duplicadas. Opo padro.
FROM EspeciIica a(s) tabela(s) que origina(m) as colunas selecionadas.
WHERE Determina, por meio de uma expresso logica, quais linhas da(s) tabela(s)
de origem devem ser exibidas no resultado da instruo.
GROUP BY Agrupa, em uma unica linha, as linhas da tabela resultante que
apresentarem o mesmo valor na coluna especiIicada.
HAVING Da mesma Iorma que a clausula WHERE permite a Iiltragem das linhas a
serem exibidas, a clausula HAVING Iiltra os grupos (deIinidos na clausula GROUP
BY) que devero ser exibidos.
UNION Calcula a unio entre duas instrues SELECT, exibindo todas as linhas
das duas instrues. As linhas duplicadas so omitidas, exceto quando a clausula ALL
e especiIicada.
INTERSECT Calcula a interseo entre duas instrues SELECT, exibindo apenas
as linhas que so comuns as duas. As linhas duplicadas so omitidas, exceto quando a
clausula ALL e especiIicada.
EXCEPT Calcula a diferena entre duas instrues SELECT, exibindo as linhas
retornadas pela primeira instruo, mas no as retornadas pela segunda.
ORDER BY Permite ordenar os dados apresentados na tabela resultante do
SELECT. Essa ordenao pode ser de ascendente (ASC opo padro) ou
descendente (DESC).
A instruo SELECT e uma das mais complexas da linguagem SQL, com varias combinaes
possiveis entre suas diversas clausulas. Independente da complexidade, e uma das mais
utilizadas, por isso, observaremos com mais detalhes algumas de suas clausulas mais
utilizadas:
Clusula FROM
Essa clausula especiIica uma ou mais tabelas de origem para a instruo SELECT. Se mais de
uma tabela Ior especiIicada, o resultado e o produto cartesiano de todas as linhas em todas as
colunas.
Uma vez que as instrues SQL geram tabelas como resultado, a origem pode ser tambem
uma instruo SELECT separada por parnteses. Nesse caso, e necessario um alias para a
tabela resultante desta instruo. Pode ainda, apresentar uma clausula JOIN que combinara
duas outras origens. Logo veremos mais sobre clausulas JOIN.
Clusula WHERE
Esta e uma clausula comum a muitas instrues SQL (como UPDATE, SELECT e DELETE),
permite restringir a execuo do comando por meio de criterios de seleo. Qualquer
expresso logica envolvendo os campos das tabelas e valida. Sua utilizao e sempre a
mesma, independente da instruo SQL.
Clusula GROUP BY
Uma instruo SELECT apresenta as linhas de Iorma analitica, muitas vezes desejamos
consolidar esses dados para que possam ser manipulados mais Iacilmente. Essa e a Iuno da
clausula GROUP BY. Perde-se a inIormao detalhada em nivel de registros para Iicarmos
com as inIormaes consolidadas (como subtotais num relatorio).
Clusula HAVING
Caso seja necessario Iiltrar as inIormaes consolidadas pela clausula GROUP BY, devemos
utilizar esta clausula. Dessa Iorma podemos exibir somente os agrupamentos desejados. E o
equivalente a clausula WHERE aplicado a um GROUP BY.
Clusula ORDER BY
Uma vez que os dados armazenados em um banco de dados relacional no obedecem a
nenhuma classiIicao, muitas vezes desejamos classiIica-los antes de sua apresentao. Essa
e a Iuno da clausula ORDER BY. Os campos constantes nesta clausula devem
obrigatoriamente aparecer na clausula SELECT. No necessaria a existncia de um indice no
banco de dados, mas se ele existir, o comando sera executado de Iorma mais rapida.
Unies
De Iorma equivalente a operao de UNIO da teoria de conjuntos, a clausula UNION agrega
resultados de duas instrues SELECT. Deve existir compatibilidade de colunas e as linhas
duplicadas sero desprezadas. Sintaxe:
SELECT <select_expressi onJ >
UNlON
SELECT <select_expression2>;
1unes
A operao de juno une duas tabelas com base em valores iguais numa coluna comum.
Normalmente, isso e utilizado quando temos duas tabelas relacionadas com dados
complementares e desejamos apresentar a inIormao de Iorma consolidada. No Modelo
Relacional isso e representado pelas relaes 'um-para-um, 'um-para-muitos e 'muitos-
para-muitos.
Consideremos duas tabelas: uma contendo os dados das pacientes numa maternidade e outra
contendo os dados dos seus Iilhos. Na segunda tabela, cada Iilho teria um campo com dados
que permitissem identiIicar sua me de Iorma unica (uma chave estrangeira).
Como na tabela das mes no constam dados dos Iilhos, caso desejemos um relatorio
apresentando cada me e seu(s) respectivo(s) Iilho(s), utilizaremos uma juno.
Podemos classiIicar as junes em:
Juno Interna (ou Natural)
E a juno mais simples, sua compreenso e intuitiva (dai o seu nome).
Dadas duas relaes A e B com uma coluna comum Y, sua juno natural C apresentara as
colunas (no duplicadas) de A e B, e suas linhas sero as linhas de A e B cujos valores Y
Iorem iguais.. Um bom exemplo e o exemplo da maternidade dado ha pouco.
Formalmente sua sintaxe e a seguinte:
SELECT { col | , col ... | | * }
FROM <tableA> | lNNER | ]OlN <table8>
| ON <searchcondition>|
| WHERE <searchcondition>|;
No entanto, normalmente e implementada atraves do proprio comando SELECT,
especiIicando as ligaes envolvidas na clausula FROM e as condies de ligao na clausula
WHERE.
Juno Externa
So menos utilizadas que as junes internas. Ao contrario delas, os valores sem
correspondncia na outra tabela so incluidos (apresentando o valor simbolico NULL).
Formalmente sua sintaxe e:
SELECT { col | , col ... | | * }
FROM <tableA> { LEFT | RlGHT | FULL } | OUTER | ]OlN <table8>
| ON <searchcondition>|
| WHERE <searchcondition>|;
De acordo com a especiIicao do usuario classiIicam-se em:
Left Outer Join (Juno Externa a Esquerda) Retornam todas as linhas da tabela
da esquerda (tableA) e quaisquer linhas da tabela da direita (tableB) que atendam
ao criterio especiIicado na clausula ON.
Right Outer Join (Juno Externa a Direita) Retornam todas as linhas da tabela
da direita (tableB) e quaisquer linhas da tabela da esquerda (tableA) que atendam
ao criterio especiIicado na clausula ON.
Full Outer Join (Juno Externa Completa) Combinao das duas anteriores.
Retorna todas as linhas de ambas as tabelas, independente do criterio de seleo.
Lock
LOCK | TABLE | tabe IN | ROW | ACCESS | { SHARE | EXCLUSlVE } MODE;
ou
LOCK | TABLE | tabe IN SHARE ROW EXCLUSlVE MODE;
Solicita explicitamente o bloqueio de uma tabela inteira ou de linhas individuais durante uma
transao.
Observaes:
ROW Bloqueia linhas individualmente.
ACCESS Bloqueia a estrutura da tabela. Opo padro.
SHARE Permite que outras transaes solicitem o bloqueio SHARE. Impede o
bloqueio EXCLUSIVE.
EXCLUSIVE Bloqueio que impede a solicitao de bloqueio por outras transaes.
Opo padro.
Set Transaction Isolation Level
SET TRANSAClONlSOLATlON LEVEL | READCOMMlTTED | SERlALlZABLE |;
DeIine o nivel de isolamento da transao atual (que dados a transao pode ver quando ha
outras transaes concorrentes). No tem eIeito em transaes posteriores.
Pelo padro SQL/92, essa instruo no pode ser executada com uma transao em
andamento. Entretanto no PostgreSQL deve ser a primeira instruo apos o inicio da
transao (BEGIN TRANSACTION).
Observaes:
READ COMMITTED A transao so v as alteraes que Ioram gravadas
(COMMIT) antes do seu inicio. Opo padro.
SERIALIZABLE A transao atual so v as alteraes que Ioram gravadas
(COMMIT) antes da primeira instruo DML desta transao.
Explain
EXPLAlN | VERBOSE | query;
Exibe o plano de execuo utilizado pelo otimizador do PostgreSQL para executar a instruo
DML especiIicada. Essa instruo no existe no padro SQL/92.
Observaes:
VERBOSE Exibe toda a representao interna da arvore de sintaxe abstrata utilizada
na execuo da instruo.
Ferramentas oIerecidas pela linguagem SQL
Alem das instrues, a linguagem SQL oIerece alguns outros elementos para complementar as
instrues e permitir a manipulao dos dados. O conhecimento dessas Ierramentas e to
importante quanto o conhecimento das instrues SQL propriamente ditas. Seguindo o nosso
escopo (elementos mais utilizados na linguagem SQL), apresentaremos apenas os operadores
e Iunes de uso mais comum.
Operadores
A linguagem SQL possui logicos, matematicos, de manipulao de strings e de comparao.
Estes ultimos incluem ainda algumas construes especiais, como veremos adiante.
Operadores Logicos
Todas as operaes logicas so Ieitas utilizando combinaes de apenas trs operadores:
Operador binario representando o 'E logico.
Operador binario representando o 'OU logico.
Operador unario representando o 'NO logico.
A linguagem SQL utiliza tabelas verdade com trs valores logicos (FALSO, VERDADEIRO
e NULL). Observe as avaliaes do valor especial NULL (em italico):
P O NOT P P AND O P OR O
VERDADEIRO VERDADEIRO FALSO VERDADEIRO VERDADEIRO
VERDADEIRO FALSO FALSO FALSO VERDADEIRO
VERDADEIRO NULL FALSO NULL VERDADEIRO
FALSO VERDADEIRO VERDADEIRO FALSO VERDADEIRO
FALSO FALSO VERDADEIRO FALSO FALSO
FALSO NULL VERDADEIRO FALSO NULL
NULL VERDADEIRO NULL NULL VERDADEIRO
NULL FALSO NULL FALSO NULL
NULL NULL NULL NULL NULL
Operadores de Comparao
So operadores binarios que retornam valores logicos de acordo com o resultado da
comparao entre os valores. Os dois operandos devem ser de tipos de dados compativeis, ou
seja, comparaveis entre si (no Iaz sentido comparar um dado do tipo VARCHAR com um
dado do tipo FLOAT). As comparaes so Ieitas binariamente, da esquerda para a direita
(exceto quando o uso de parntesis altere a precedncia). Comparaes do tipo '1 2 3
no so validas, pois so resolvidas como '1 2 (VERDADEIRO) e 'VERDADEIRO 3
que no Iaz sentido.
Operador Descrio
Menor que
~ Maior que
Menor ou igual a
~ Maior ou igual a
Igual a
~ (ou !) DiIerente de
Existem ainda as construes especiais a seguir que podem substituir uma comparao de
intervalos com a mesma eIicincia e so mais amigaveis:
Construo equivalente a
a BETWEEN x AND y a >= x AND a <= y
a NOT BETWEEN x AND y a < x OR a > y
a IN (x, y, z ) a = x OR a = y OR a = z
Quanto ao valor especial NULL, uma vez que no pode ser comparado pelas vias normais
(qualquer comparao envolvendo NULL devolve NULL, lembra-se?), utilizamos outras duas
construes especiais:
Construo Substitui a comparao
expr IS NULL expr = NULL
expr IS NOT NULL expr <> NULL
Exste anda um operador de comparao de strings ut zado normamente na cusua WHERE
guando do s o ] amo s o bo : as l i nhas o m guo o s val o : o s do uma o o l una s i gam um do o : mi nado
pad: ao .
O operador LIKE utiliza os caracteres especiais ' (porcentagem) e ' (sublinhado), e
segue a sintaxe abaixo:
SELECT { col | , col ... | | * }
FROM <table>
WHERE <column> LlKE <pattern>;
O posicionamento dos caracteres porcentagem e sublinhado deIinem o padro a ser
procurado. O caractere de sublinhado signiIica que qualquer caractere naquela posio sera
considerado valido, enquanto o caractere de porcentagem signiIica que uma seqncia de
caracteres naquela posio sera considerada valida. Observe os exemplos abaixo:
Condio Significado
WHERE NOME LIKE |OSE%
Qualquer nome que comece com JOSE`
WHERE NOME LIKE %CARNEIRO
Qualquer nome terminado em CARNEIRO`
WHERE NOME LIKE __R%
Qualquer nome em que a terceira letra seja R`.
Operadores Matematicos
O conjunto de operadores matematicos oIerecido pela linguagem SQL e bastante completo,
abrangem inclusive operaes binarias ('E, 'OU, 'NOT e deslocamento binarios).
Apresentaremos apenas os mais utilizados:
Operador Descrio
Soma
- Subtrao
* Multiplicao
/ Diviso
` Exponenciao
! Fatorial
Operadores para Strings
Basicamente existe apenas um operador para lidar com strings (cadeias de caracteres), o
operador binario ',, que realiza a concatenao de caracteres. Ou seja:
"Postgre" || "SOL" resulta em "PostgreSOL".
Funes
As Iunes oIerecidas pela linguagem SQL podem ser classiIicadas em sete grupos principais:
Manipulao de Strings
Matematicas
Estatisticas
Formatao e Converso de Tipos
Data e Hora
Geometricas
Neste trabalho, daremos mais ateno aos trs primeiros grupos.
Funes de manipulao de Strings
As Iunes de manipulao de strings so utilizadas tanto no tratamento de resultados de
consultas e relatorios, quanto na deIinio regras de restrio e valores para campos. As mais
comuns so:
Funo Descrio
ASCII( text )
Codigo ASCII do primeiro caractere
CHAR_LENGTH( str i ng )
H.N. IP NL P X IH{ string )
Comprimento da string
CHR( integer )
Caractere correspondente ao codigo ASCII
INITCAP( text )
Converso das iniciais para maiusculas
LOWER( str i ng )
Converso para minusculas
LPAD( str i ng, x, | substring | )
Preenchimento com caracteres a esquerda
LTRIM( str i ng, substring )
Remoo de caracteres a esquerda
REPEAT( str i ng, x )
Repeties da string especiIicada
RPAD( str i ng, x, | substring | )
Preenchimento com caracteres a direita
RTRIM( str i ng, substring )
Remoo de caracteres a direita
STRPOS( str i ng, substring )
Localizao de substring
SUBSTR( str i ng, x, | y | )
Extrao de substring
UPPER( str i ng )
Converso para maiusculas
Funes Matematicas
Funo Descrio
ABS(x)
Valor absoluto
ACOS(x)
Arco cosseno
ASIN(x)
Arco seno
ATAN(x)
Tangente inversa
CBRT(x)
Raiz cubica
CEIL(x)
Inteiro posterior
COS(x)
Cosseno
COT(x)
Cotangente
DEGREES(x)
Converso de radianos para graus
EXP(x)
Exponenciao
FLOOR(x)
Inteiro anterior
LN(x)
Logaritmo Neperiano
LOG(x)
Logaritmo na base 10
LOG(x, y)
Logaritmo na base especiIicada
MOD(x, y)
Resto da diviso
PI()
Constante
POW(x, y)
Potenciao
RADIANS(x)
Converso de graus para radianos
RANDOM()
Numero aleatorio entre 0 e 1
ROUND(x, y)
Arredondamento
SIN(x)
Seno
SORT(x)
Raiz quadrada
TAN(x)
Tangente
TRUNC(x, y)
Trunca um numero
Funes Estatisticas
As Iunes estatisticas permitem agrupar os valores constantes numa tabela devolvendo um
resultado unico (como a soma ou a media dos valores encontrados). So muito uteis em
relatorios e consultas de carater gerencial.
Funo Descrio
AVG(x)
Media aritmetica
COUNT(x)
Contagem de ocorrncias encontradas
MAX(x)
O maior valor encontrado
MIN(x)
O menor valor encontrado
STDDEV(x)
Desvio padro
SUM(x)
Somatorio
VARIANCE(x)
Varincia
Permitem, alem da tradicional restrio com clausula WHERE, a utilizao dos parmetros
(ALL e DISTINCT) que determinam o conjunto de linhas a serem consideradas.
Stored Procedures (Procedimentos Armazenados)
So basicamente programas pre-compilados que Iicam armazenados no servidor e so
executados por solicitao do cliente. A execuo e restrita ao servidor. O cliente solicita a
execuo, aguarda o seu termino e recebe de volta somente o seu resultado.
Suas principais vantagens so:
Aumentam o desempenho em ambientes Cliente/Servidor pois diminuem o traIego
de inIormaes entre os clientes e o servidor.
Possibilitam um maior grau de independncia de dados pois ocultam do usuario
detalhes do banco de dados e do SGBD.
OIerecem maior segurana. Os usuarios podem no ter autorizao para alterar
determinados dados, mas serem autorizados a executar uma stored procedure que
os atualiza.
Criam uma camada contendo todas as regras de negocio da empresa, tornando-as
independentes do cliente. Uma alterao nas regras de negocio no implicaria em
alteraes na camada de clientes.
Como exemplo de stored procedures podemos citar as operaes em batch (lote) muito
comuns em sistemas de grande porte e operaes compostas por diversas operaes menores,
como a conciliao de contas.
Com os avanos tecnologicos, tanto nos sistemas operacionais quanto no desenvolvimento de
aplicaes, e cada vez mais comum a utilizao das tecnicas de multiprocessamento e bancos
de dados distribuidos. Nesses casos, a independncia proporcionada pelo uso de stored
procedures e triggers e Iundamental.
Triggers (Gatilhos)
Um trigger e um tipo especial de procedimento armazenado que sera disparado (executado
automaticamente pelo SGBD) na ocorrncia de um determinado evento. Como eventos
disparadores temos normalmente a execuo de alguma operao que atualize os dados do
banco de dados ou a violao de alguma regra de integridade.
Observe que, apesar de possivel, e desaconselhada a utilizao de triggers para a manuteno
de integridade. Seu uso e mais indicado em operaes com relao de conseqncia. Por
exemplo, ao incluir os dados de uma Iiscal de venda, um trigger pode ja incluir pedidos para
repor os itens vendidos.
Topicos Adicionais
Transaes
Uma transao e uma unidade logica de trabalho. Um grupo de operaes relacionadas que
devem ser executadas como uma unidade. Caso uma operao no seja concluida com
sucesso, nenhuma das outras deve ser executada e o banco de dados deve retornar ao estado
anterior.
Consideremos a incluso, no banco de dados, de uma nota Iiscal contendo varios itens. Caso
um dos itens no seja incluido (por qualquer razo), toda a incluso da nota deve ser
interrompida sob pena de criarmos inconsistncias nos dados (o total da nota no sera
condizente com o somatorio dos itens!).
Recuperao de Transaes
Como vimos, as instrues SQL responsaveis por implementar o controle de transaes so:
BEGIN TRANSACTION Indica o inicio de uma transao. Deve ser registrada a
situao atual do banco de dados e iniciado o registro das operaes para, no caso
de uma eventual Ialha, retornar o banco de dados a essa situao.
COMMIT Indica o termino com sucesso de uma transao. As inIormaes
atuais podem ser tornadas permanentes.
ROLLBACK Indica o insucesso na execuo de uma transao, e que SGBD
deve 'desIazer todas as alteraes ocorridas na transao.
Antes que cada operao seja executada, o SGBD deve registra-la no arquivo de log
(registro). Assim, se antes da execuo de todas as operaes que compem a transao, um
erro (previsto ou no) Ior observado, um ROLLBACK sera executado trazendo o banco de
dados de volta a situao anterior. Essa gravao antecipada tem o nome de Write-ahead
Logging (Gravao Antecipada do Registro).
Em intervalos predeterminados, em geral um numero preestabelecido de entradas no registro,
o SGBD grava Iisicamente a situao atual em disco e marca um checkpoint (ponto de
checagem) no registro. Esse checkpoint Iornece uma lista das transaes que estavam em
andamento naquele instante.
Caso haja uma Ialha no sistema (uma Ialta de energia por exemplo) que interrompa o
processamento abruptamente, quando o SGBD e reinicializado:
1. So criadas duas listas REDO (reIazer) e UNDO (desIazer). A lista UNDO contem
todas as transaes em andamento no momento do ultimo checkpoint. A lista
REDO comea vazia.
2. O SGBD pesquisa o registro a partir do ultimo checkpoint. Toda vez que e
encontrada uma instruo BEGIN TRANSACTION, essa transao e acrescentada
a lista UNDO. Quando e encontrada uma instruo COMMIT, a transao
correspondente e movida para a lista REDO. Finalmente, cada vez que e
encontrada uma instruo ROLLBACK, a transao correspondente e retirada da
lista UNDO.
3. Agora que o SGBD tem listas com todas as transaes a serem desIeitas e todas as
transaes a serem reIeitas, ele percorre as listas reIazendo as transaes
constantes da lista REDO e desIazendo as transaes constantes da lista UNDO.
So depois da concluso dessas atividades de recuperao de transaes, o sistema aceitara
alguma instruo.
Concorrncia
Apesar de a maioria dos sistemas de banco de dados serem multiusuarios, no levamos isso
em considerao nos nossos estudos ate o momento. Em um sistema de banco de dados
multiusuario, existe o problema da concorrncia, ou seja o acesso simultneo de mais de um
usuario aos dados.
Os problemas mais comuns de concorrncia so:
A atualizao perdida (lost update) Uma transao A acessa uma tupla num
momento T
1
. Uma transao B acessa a mesma tupla no instante T
2
. A transao
atualiza a tupla no momento T
3
com base nos dados lidos no momento T
1
. A
transao B atualiza a tupla no momento T
4
com os dados lidos no momento T
2
(os
mesmos do momento T
1
). As alteraes realizadas pela transao A so
sobrescritas pelas alteraes da transao B.
A leitura suja (dirtv read) Uma transao A realiza uma alterao numa tupla
num momento T
1
. Uma transao B acessa a mesma tupla no instante T
2
(antes que
a transao A seja devidamente encerrada). A transao A e cancelada por meio de
um ROLLBACK no momento T
3
. A transao B estara operando com base em
inIormaes que no so mais validas podendo inclusive realizar outras alteraes
(as vezes em outras tuplas) baseada nessas inIormaes.
A analise inconsistente A transao A realiza o somatorio das tuplas I e II no
momento T
1
. A transao B altera o valor da tupla I no momento T
2
. A transao
A adiciona ao somatorio o valor da tupla III no momento T
3
. O somatorio
retornado pela transao A esta incorreto pois tomou por base um valor que Ioi
alterado depois pela transao B. Esse caso normalmente e conseqncia de uma
leitura suja.
Bloqueios (Locks)
Uma maneira de evitar esses problemas e pela utilizao de bloqueios (locks). Toda vez que
uma transao precisar acessar uma ou mais tuplas e deseja garantir que os valores no sero
alterados por outra transao, ela pode solicitar o bloqueio dessas tuplas.
Existem varios tipos de bloqueio, consideraremos apenas os mais simples:
Bloqueio de Gravao (write lock) Impede qualquer solicitao de bloqueio das
tuplas por outra transao ate que a transao A seja concluida (com ou sem
sucesso).
Bloqueio de Leitura (read lock) Impede a solicitao de bloqueios de gravao
por qualquer outra transao ate que a transao A seja concluida (com ou sem
sucesso). As solicitaes de bloqueios de leitura so permitidas.
Uma transao que deseja ler uma tupla deve solicitar o bloqueio de leitura sobre ela. Caso
deseje alterar uma tupla, a transao deve solicitar o bloqueio de escrita sobre ela. Essas
solicitaes so, em geral implicitas e, ao termino da transao os bloqueios so liberados.
Se no Ior possivel obter o bloqueio solicitado por uma transao, a transao entra em estado
espera, permanecendo assim ate que a solicitao seja concedida. Para evitar que uma
determinada transao permanea em estado de espera indeIinidamente, o SGBD atende as
solicitaes na ordem 'primeiro a chegar, primeiro a ser atendido.
Bloqueio de duas Iases
O teorema do bloqueio de duas fases determina que uma transao deve possuir duas Iases:
uma Iase inicial em que obtem os bloqueios necessarios e uma Iase Iinal quando, apos as
alteraes, libera cada um dos bloqueios obtidos. Este teorema determina ainda que apos
liberado um bloqueio, nenhum outro pode ser obtido. De Iato, no padro SQL/92 no ha
instrues de bloqueio, somente o SGBD pode bloquear alguma tupla.
Entretanto como as transaes normalmente envolvem interao humana (entrada de dados),
para poupar recursos e melhorar o desempenho, normalmente os SGBD permitem que as
transaes liberem bloqueios antes do termino e obtenham outros e oIerecem algum recurso
de bloqueio explicito para que a segurana seja garantida pela aplicao.
Deadlocks
Utilizando o recurso do bloqueio, podemos resolver os problemas de concorrncia vistos
anteriormente. Entretanto existe a possibilidade de um novo problema: o deadlock (espera
indeIinida de duas ou mais transaes por um determinado evento; no caso, o bloqueio de
uma determinada tupla). O ideal e que o SGBD seja capaz de detectar um deadlock e
interromp-lo, escolhendo uma das transaes envolvidas e Iorando um ROLLBACK.
Nem todos os SGBD so capazes de detectar de Iato um deadlock. Alguns apenas utilizam o
criterio do tempo: uma transao que no realize qualquer trabalho num periodo
predeterminado de tempo sera considerada em deadlock e interrompida.
A transao interrompida precisa ser reIeita. Alguns (poucos) SGBD detectam que a transao
Ioi interrompida por deadlock e a reIazem automaticamente. A maioria simplesmente devolve
uma mensagem avisando o ocorrido. Se Ior esse o caso, a aplicao deve tomar as
providncias necessarias para reIazer a transao. Qualquer que seja a soluo, ela deve ser
transparente para o usuario Iinal.
Niveis de Isolamento
Por deIinio as transaes devem ser serializaveis, isto e, podem ser executadas em qualquer
ordem. Executar a transao A e em seguida a transao B tera o mesmo resultado que
executar a transao B e em seguida a transao A.
Para que as transaes sejam serializaveis, o nivel de isolamento deve ser maximo. O nivel de
isolamento de uma transao deIine qual o nivel de interIerncia que transaes concorrentes
tm entre si. Portanto, para que as transaes sejam serializaveis, as alteraes eIetuadas por
uma transao so invisiveis as demais ate a sua concluso.
Como vimos, o padro SQL/92 no oIerece opes explicitas de bloqueio, mas oIerece quatro
niveis de isolamento, em ordem decrescente de isolamento:
SERIALIZABLE Isolamento maximo. A transao atual no visualiza as
alteraes Ieitas pelas demais. Permite que as transaes sejam serializaveis.
REPEATABLE READ A transao atual no visualiza as alteraes que
ocorreram apos o primeiro acesso aos dados.
READ COMMITTED A transao atual no visualiza as alteraes que ainda
no Ioram gravadas (COMMIT) pelas demais transaes.
READ UNCOMMITTED A transao visualiza as alteraes das demais
transaes, independente de haverem sido gravadas (COMMIT).
O PostgreSQL por outro lado, oIerece apenas dois:
SERIALIZABLE Isolamento maximo. A transao atual no visualiza as
alteraes Ieitas pelas demais. Permite que as transaes sejam serializaveis.
READ COMMITTED A transao atual no visualiza as alteraes que ainda
no Ioram gravadas (COMMIT) pelas demais transaes. Opo padro.
Segurana do Banco de Dados
Mencionamos diversas vezes os termos 'integridade e 'segurana. E comum serem
conIundidos, mas os dois conceitos so bastante diIerentes. Enquanto integridade se reIere a
proteo dos dados quanto a sua exatido, segurana se reIere a proteo quanto aos acessos
(para consulta ou alterao) no autorizados.
A politica de segurana de um banco de dados esta diretamente ligada a politica da empresa.
Da mesma Iorma que o projeto do banco de dados, sua deIinio e atribuio do
administrador de dados e sua implementao (e posterior manuteno) e atribuio do DBA.
A segurana de um banco de dados ocorre sob diversos aspectos (acesso Iisico, escolha de
sistema operacional, dispositivos biometricos, etc.), porem daremos mais ateno ao aspecto
da segurana oIerecida pelo SGBD. De uma maneira geral, a segurana de um banco de dados
e Ieita por meio da autorizao ou negao do acesso de um usuario a um determinado objeto
do banco de dados (uma tabela, viso, stored procedure, etc.).
Quando um usuario deseja acessar o banco de dados, deve se identiIicar Iornecendo sua
userid (identiIicao de usuario) e uma conIirmao de identidade (senha, impresso digital
ou de retina, etc.). De posse dessa identiIicao, o banco de dados recupera as deIinies de
segurana do dicionario de dados e concede os privilegios ao usuario para aquela sesso de
trabalho. Existem dois principais sistemas de controle de acesso: mandatario e discricionario.
Controle Mandatario
Cada objeto tem um determinado nivel de classiIicao e cada usuario, um nivel de liberao.
Existe um nivel de liberao correspondente a cada nivel de classiIicao.
Um usuario so pode ter acesso de leitura a um objeto se seu nivel de liberao e
maior ou igual ao nivel de classiIicao do objeto.
Um usuario so pode excluir objetos que tenham um nivel de classiIicao igual ou
inIerior ao seu nivel de liberao.
Todos os objetos atualizados (incluidos e alterados) por um usuario assumem
automaticamente o nivel de classiIicao correspondente ao seu nivel de liberao.
Evita-se assim que um usuario leia um dado exclusivo para o seu nivel de
liberao e grave-o num nivel de classiIicao inIerior, quebrando o esquema de
segurana.
Esse sistema comeou a receber mais ateno quando Departamento de DeIesa norte-
americano estabeleceu as exigncias para aquisio de SGBD. E um sistema mais rigido e
hierarquico, sendo mais utilizado em organizaes militares e governamentais.
Controle Discricionario
So concedidos, aos usuarios, privilegios de acesso aos objetos do banco de dados. Esses
privilegios podem ser distintos para objetos e usuarios distintos. E um sistema mais Ilexivel e
o implementado pelo padro SQL/92.
A atribuio de privilegios e realizada por meio de instrues SQL e a cada comando dado
pelo usuario o SGBD veriIica o seu acesso aos dados solicitados. Caso o usuario no tenha o
privilegio solicitado, a ao padro e simplesmente negar o acesso e devolver uma mensagem
inIormando o ocorrido. O aplicativo ento opta por simplesmente inIormar ao usuario a
negativa, ou tomar aes mais drasticas como interromper a sesso do usuario ou avisar ao
DBA.
Outros recursos de segurana
Paralelamente aos sistemas de controle propriamente ditos, existem outros recursos de
segurana que so aplicados dependendo do nivel de segurana desejado:
Vises Um recurso muito simples, mas muito poderoso, da propria linguagem
SQL e a utilizao de vises. Simplesmente impedimos os usuarios de terem
acesso direto as tabelas, obrigando-os a utilizarem vises, que apresentaro a eles
apenas os dados desejados. Do ponto de vista dos usuarios no autorizados, os
demais dados simplesmente 'no existem.
Stored Procedures De modo semelhante ao uso de vises, limitamos o acesso
direto dos usuarios aos dados armazenados.
Auditoria O aplicativo (ou o SGBD, dependendo do Iabricante) grava em uma
tabela de auditoria todos os acessos ao banco de dados. Muitas vezes, so o Iato de
saber que suas aes sero registradas impede algum usuario mais ousado. De
qualquer Iorma, em caso de necessidade, os usuarios responsaveis pela segurana
podem consultar a tabela de auditoria, utilizando sua linguagem padro de consulta
para obter os dados do acesso.
CriptograIia de Dados Supomos ate o momento que a tentativa de acesso seria
utilizando os recursos do proprio SGBD. Pode ocorrer entretanto, que o invasor
tente contornar o SGBD, acessando diretamente os arquivos do banco de dados ou
espionando os dados que traIegam entre o cliente e o servidor. Para esses casos, a
providncia mais eIicaz e utilizar algum sistema de criptograIia. Existem diversos
metodos de criptograIia (e uma das cincias mais antigas da humanidade!), cada
um com suas vantagens e desvantagens.
Otimizao
As instrues DML normalmente tm mais de uma Iorma de serem executadas. Considerando
que maioria das instrues DML age sobre um grande numero de linhas, e que muitas dessas
instrues realizam diversas operaes sobre esse mesmo conjunto de linhas, a ordem em que
essas operaes so executadas causa enorme diIerena no tempo de resposta e nos recursos
envolvidos para obter essa resposta.
Otimizao e o processo de escolher o melhor modo de executar as operaes necessarias
para cumprir a instruo recebida. Todo SGBD utiliza algum tipo de otimizao porem, nos
sistemas no-relacionais essa otimizao Iica a cargo do usuario do sistema. Caso as escolhas
Ieitas pelo usuario no sejam as mais indicadas, no ha nada que o sistema possa Iazer.
Os sistemas relacionais, por utilizarem uma linguagem no-procedural de alto nivel (SQL)
que especiIica o 'QU Iazer em lugar do 'COMO Iazer, tm a liberdade de otimizarem as
instrues recebidas da Iorma mais conveniente. Na verdade, os sistemas relacionais
dependem de um sistema de otimizao para terem uma eIicincia razoavel.
Essa dependncia, que poderia ser um problema, termina sendo uma grande vantagem dos
sistemas relacionais pelo simples Iato que e quase certo que a otimizao Ieita
automaticamente pelo sistema seja melhor do que a otimizao escolhida pelo usuario.
Em primeiro lugar, porque o sistema dispe de inIormaes (como a estrutura do banco de
dados e suas estatisticas de utilizao) que no so do conhecimento do usuario. E em
segundo lugar, porque sendo o SGBD tem a seu Iavor o Iato que o procedimento de
otimizao e repetitivo e maante, muito mais adequado para uma maquina do que para um
ser humano.
Em certas ocasies pode ser interessante para o usuario seguir obrigatoriamente um plano
deIinido por ele, independente de no ser o mais eIiciente. Entretanto, o padro SQL/92 no
oIerece essa possibilidade. O objetivo e sempre a eIicincia maxima, independente da vontade
do usuario.
Existem SGBDR que permitem que o plano de execuo deIinido automaticamente pelo
sistema seja substituido por outro deIinido pelo usuario, mas isso varia de produto para
produto.
No caso do PostgreSQL, no e possivel trocar o plano de execuo. Porem o usuario pode
consultar o plano escolhido pelo SGBD para, baseado nessas inIormaes, criar as condies
(como indices alternativos ou vises) que permitam Iorar uma alterao nessa escolha de
acordo com suas necessidades.
BibliograIia
DATE, C. J. Introduo a Sistemas de Bancos de Dados. Rio de Janeiro: Campus, 2000.
Butzen, Fred; Forbes, Dorothy. Linux - Bancos de Dados. Rio de Janeiro: Cincia Moderna,
1997.
International Organization Ior Standardization (ISO). Database Language SQL. Documento
ISO 9075:1992.
RED HAT, INC. Red Hat Database: SQL Guide and Reference. |on line| Disponivel na
INTERNET via URL: http://www.redhat.com/docs/manuals/database. Arquivo capturado
em 02/07/2002.
Wirth, Niklaus. Algoritmos e Estruturas de Dados. Rio de Janeiro: Prentice/Hall do Brasil.

Banco Dados

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Banco Dados

Enviado por

Direitos autorais:

Formatos disponíveis

INTRODUO A BANCOS DE DADOS

1os Lus Carneiro

Você também pode gostar