




























Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Tutorial sobre banco de dados postgre
Tipologia: Notas de estudo
1 / 36
Esta página não é visível na pré-visualização
Não perca as partes importantes!





























Tutorial do PostgreSQL 7.3. por The PostgreSQL Global Development Group Copyright © 1996-2002 The PostgreSQL Global Development Group
Legal Notice
PostgreSQL is Copyright © 1996-2002 by the PostgreSQL Global Development Group and is distributed under the terms of the license of the University of California below.
Postgres95 is Copyright © 1994-5 by the Regents of the University of California. Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies. IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PRO- VIDED HEREUNDER IS ON AN “AS-IS” BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
O PostgreSQL é um sistema de gerenciamento de banco de dados objeto-relacional (SGBDOR) baseado no POSTGRES, Versão 4.2^1 , desenvolvido no Departamento de Ciência da Computação da Universidade da Cal- ifórnia em Berkeley. O projeto POSTGRES, liderado pelo Professor Michael Stonebraker, foi patrocinado pelas seguintes instituições: Defense Advanced Research Projects Agency (DARPA); Army Research Office (ARO); National Science Foundation (NSF); e ESL, Inc.
O PostgreSQL descende deste código original de Berkeley, possuindo o código fonte aberto. Fornece suporte às linguagens SQL92/SQL99 além de outras funcionalidades modernas.
O POSTGRES foi o pioneiro em muitos conceitos objeto-relationais que agora estão se tornando disponíveis em alguns bancos de dados comerciais. Os Sistemas de Gerenciamento de Bancos de Dados Relacionais (SGBDR) tradicionais suportam um modelo de dados que consiste em uma coleção de relações com nome, contendo atribu- tos de um tipo específico. Nos sistemas comerciais em uso, os tipos possíveis incluem número de ponto flutuante, inteiro, cadeia de caracteres, monetário e data. É largamente reconhecido que este modelo não é adequado para aplicações futuras de processamento de dados. O modelo relacional substituiu com sucesso os modelos anteri- ores em parte devido à sua “simplicidade Espartana”. Entretanto, esta simplicidade tornou a implementação de certas aplicações muito difícil. O PostgreSQL oferece um substancial poder adicional, devido à incorporação dos conceitos mostrados abaixo de uma forma que os usuários podem facilmente estender o sistema:
Outras funcionalidades fornecem poder e flexibilidade adicionais:
Estas funcionalidades colocam o PostgreSQL dentro da categoria de bancos de dados referida como objeto- relacional. Repare que isto é diferente daqueles referidos como orientados a objetos que, em geral, não são muito adequados para dar suporte às linguagens de banco de dados relacionais tradicionais. Portanto, embora o PostgreSQL possua algumas funcionalidades de orientação a objetos, está firmemente ligado ao mundo dos bancos de dados relacionais. Na verdade, alguns bancos de dados comerciais incorporaram recentemente funcionalidades nas quais o PostgreSQL foi o pioneiro.
O sistema de gerenciamento de banco de dados objeto-relacional hoje em dia conhecido por PostgreSQL (e por um breve período de tempo chamado Postgres95) é derivado do pacote POSTGRES escrito na Universidade da Califórnia em Berkeley. Com mais de uma década de desenvolvimento por trás, o PostgreSQL é o mais avançado
i
Prefácio
banco de dados de código aberto disponível em qualquer lugar, oferecendo controle de concorrência multi-versão, suportando praticamente todas as construções do SQL (incluindo subconsultas, transações, tipos definidos pelo usuário e funções), e dispondo de um amplo conjunto de ligações com linguagens procedurais (incluindo C, C++, Java, Perl, Tcl e Python).
A implementação do SGBD POSTGRES começou em 1986. Os conceitos iniciais para o sistema foram apresen- tados em The design of POSTGRES , e a definição do modelo de dados inicial apareceu em The POSTGRES data model. O projeto do sistema de regras nesta época foi descrito em The design of the POSTGRES rules system. Os princípios básicos e a arquitetura do gerenciador de armazenamento foram detalhados em The design of the POSTGRES storage system.
O Postgres passou por várias versões desde então. A primeira “versão de demonstração” do sistema se tornou operacional em 1987, e foi exibida em 1988 na Conferência ACM-SIGMOD. A versão 1, descrita em The im- plementation of POSTGRES , foi liberada para alguns poucos usuários externos em junho de 1989. Em resposta à crítica ao primeiro sistema de regras ( A commentary on the POSTGRES rules system ), o sistema de regras foi re-projetado ( On Rules, Procedures, Caching and Views in Database Systems ) e a versão 2 foi liberada em junho de 1990, contendo um novo sistema de regras. A versão 3 surgiu em 1991 adicionando suporte a múltiplos geren- ciadores de armazenamento, um executor de consultas melhorado, e um sistema de regras de reescrita reescrito. Para a maior parte, as versões seguintes até o Postgres95 (veja abaixo) focaram a portabilidade e a confiabilidade.
O POSTGRES tem sido usado para implementar muitas aplicações diferentes de pesquisa e produção, incluindo: sistema de análise de dados financeiros, pacote de monitoramento de desempenho de turbina a jato, banco de dados de acompanhamento de asteróides, banco de dados de informações médicas, além de vários sistemas de informações geográficas. O POSTGRES também tem sido usado como uma ferramenta educacional em diversas universidades. Finalmente, a Illustra Information Technologies (posteriormente incorporada pela Informix^2 , que agora pertence à IBM^3 ) pegou o código e comercializou. O POSTGRES se tornou o gerenciador de dados primário para o projeto de computação científica Sequoia 2000^4 nos fins de 1992.
O tamanho da comunidade de usuários externos praticamente dobrou durante o ano de 1993. Começou a se tornar cada vez mais óbvio que a manutenção do código do protótipo e seu suporte estava consumindo uma grande quantidade de tempo que deveria ser dedicado a pesquisas sobre bancos de dados. Em um esforço para reduzir esta sobrecarga de suporte, o projeto do POSTGRES de Berkeley terminou oficialmente com a versão 4.2.
Em 1994, Andrew Yu e Jolly Chen adicionaram um interpretador da linguagem SQL ao POSTGRES. O Post- gres95 foi em seguida liberado para a Web para encontrar seu caminho no mundo como um descendente de código aberto do código original do POSTGRES de Berkeley.
O código do Postgres95 era totalmente escrito em ANSI C e reduzido em tamanho em 25%. Muitas mudanças internas melhoraram o desempenho e a facilidade de manutenção. O Postgres95 release 1.0.x era 30-50% mais rápido em comparação com o POSTGRES versão 4.2, utilizando o Wisconsin Benchmark. Além da correção de erros, as melhorias principais foram as seguintes:
ii
Prefácio
Seja bem-vindo ao PostgreSQL e ao Tutorial do PostgreSQL. Os poucos capítulos que se seguem têm por objetivo fornecer uma breve introdução ao PostgreSQL, aos conceitos de banco de dados relacional e à linguagem SQL, para os que são iniciantes em qualquer um destes tópicos. Somente assume-se um conhecimento geral sobre a uti- lização de computadores. Nenhuma experiência particular com Unix ou em programação é requerida. Este tutorial tem por objetivo principal fornecer experiência prática com relação aos aspectos importantes do PostgreSQL. Não existe nenhuma intenção em se dar um tratamento completo ou abrangente dos tópicos cobertos.
Após ler este tutorial pode-se prosseguir através da leitura do Guia do Usuário do PostgreSQL para obter mais conhecimento formal sobre a linguagem SQL, ou o Guia do Programador do PostgreSQL para obter informações sobre o desenvolvimento de aplicações para o PostgreSQL. Os que instalam e gerenciam seus próprios servidores também devem ler o Guia do Administrador do PostgreSQL.
A documentação do PostgreSQL está organizada em diversos livros:
Tutorial do PostgreSQL
Uma introdução informal para os novos usuários.
Guia do Usuário do PostgreSQL
Documenta o ambiente da linguagem de consulta SQL, incluindo tipos de dados e funções, assim como o ajuste do desempenho no nível de usuário. Todo usuário do PostgreSQL deve lê-lo.
Guia do Administrador do PostgreSQL
Informações sobre a instalação e a administração do servidor. Todos os que administram um servidor Post- greSQL, tanto para uso pessoal quanto para uso por outras pessoas, devem lê-lo.
Guia do Programador do PostgreSQL
Informações avançadas para programadores de aplicativos. Os tópicos incluem a extensibilidade de tipo e de função, interfaces com bibliotecas e questões relativas ao projeto de aplicativos.
Manual de Referência do PostgreSQL
Páginas de referência contendo a sintaxe para os comandos SQL, programas para a estação cliente e servidor. Este manual é um auxílio aos Guias do Usuário, do Administrador e do Programador.
Guia do Desenvolvedor do PostgreSQL
Informações para os desenvolvedores do PostgreSQL. Feito para àqueles que estão contribuindo para o projeto PostgreSQL. As informações sobre o desenvolvimento de aplicativos estão mostradas no Guia do Programador.
Além deste conjunto de manuais, existem outros recursos para ajudar na instalação e uso do PostgreSQL:
man pages
As páginas do Manual de Referência no formato tradicional “man” do Unix. Não existe diferença no con- teúdo.
iv
Prefácio
FAQs
As listas de perguntas freqüentemente formuladas (Frequently Asked Questions - FAQ) documentam tanto questões gerais como algumas questões específicas para uma plataforma.
READMEs
Os arquivos README (leia-me) estão disponíveis em alguns pacotes contribuídos.
Sítio na Web
O sítio na Web do PostgreSQL 5 possui detalhes sobre sobre a última versão, funcionalidades a serem incor- poradas, e outras informações para tornar o trabalho ou a diversão com o PostgreSQL mais produtiva.
Listas de discussão
As listas de discussão são um bom lugar para se conseguir ter as perguntas respondidas, para trocar exper- iência com outros usuários, e para fazer contato com os desenvolvedores. Consulte a seção User’s Lounge^6 do sítio na Web do PostgreSQL para obter mais informações.
Você mesmo!
O PostgreSQL é um trabalho de código aberto e, por isso, depende do apoio permanente da comunidade de usuários. Quando começamos a utilizar o PostgreSQL dependemos da ajuda de outros, tanto através da docu- mentação quanto das listas de discussão. Considere então em retribuir seus conhecimentos. Se você aprender alguma coisa que não faz parte da documentação, escreva e contribua. Se você adicionar funcionalidades ao código, contribua com estas funcionalidades. Mesmo àqueles que não possuem muita experiência podem fazer correções e pequenas alterações na docu- mentação, e esta é uma boa maneira de se começar. A lista de discussão é um lugar para se visitar com freqüência (N.T. - No Brasil veja PostgreSQL Brasil^7 ).
Um administrador normalmente é a pessoa responsável pela instalação e funcionamento do servidor. Um usuário pode ser qualquer um usando, ou querendo usar, qualquer parte do sistema PostgreSQL. Estes termos não devem ser interpretados ao pé da letra; este conjunto de documentos não estabelece premissas sobre os procedimentos do administrador do sistema.
É utilizado /usr/local/pgsql/ como sendo o diretório raiz da instalação e /usr/local/pgsql/data como o diretório contendo os arquivos dos banco de dados. Estes diretórios podem ser outros em sua máquina, os detalhes podem ser vistos no Guia do Administrador (N.T. /var/lib/pgsql/ e /var/lib/pgsql/data no Mandrake Linux).
Na sinopse dos comandos os colchetes ([]) indicam uma frase ou palavra chave opcional. Qualquer coisa entre chaves ({}) contendo, também, barras verticais (|), indica que uma das alternativas deve ser escolhida.
Os exemplos mostram comandos executados a partir de várias contas e programas. Os comandos executados a partir de uma “shell” do Unix podem estar precedidos por um caractere de cifrão (“$”). Os comandos executados a partir da conta de um usuário, tal como root ou postgres, são especialmente sinalizados e explicados. Os comandos SQL podem estar precedidos por “=>” ou não ter nada os precedendo, dependendo do contexto.
v
Prefácio
A coisa mais importante a ser lembrada quando vamos relatar erros é declarar todos os fatos, e somente os fatos. Não especule sobre o que você acha que está certo ou errado, o que “parece que deva ser feito”, ou qual parte do programa está falhando. Se você não está familiarizado com a implementação você provavelmente vai supor errado, e não vai nos ajudar nem um pouco. E, mesmo que você esteja familiarizado, uma explanação educada é um grande suplemento, mas não substitui os fatos. Se nós formos corrigir o erro, nós temos que vê-lo acontecer primeiro. Informar fatos cruamente é relativamente direto (provavelmente pode ser copiado e colado a partir da tela), mas geralmente detalhes importantes são deixados de fora porque alguém pensou que não tinha importância, ou que o relatório seria entendido de qualquer maneira.
Os seguintes itens devem estar contidos em todo relatório de erro:
Nota: No caso de erros fatais a mensagem de erro informada pelo cliente pode não conter toda a infor- mação disponível. Por favor, olhe também o log produzido no servidor de banco de dados. Se você não mantém a saída do log do servidor, esta é uma boa hora para começar a fazê-lo.
vii
Prefácio
Se estiver sendo utilizada uma distribuição pré-configurada que inicializa o servidor de banco de dados durante o boot, deve-se tentar descobrir como isto é feito.
Não tenha medo que seu relatório de erro se torne muito longo. Este é um fato da vida. É melhor relatar tudo da primeira vez do que nós termos que extrair os fatos de você. Por outro lado, se os seus arquivos de entrada são enormes, é justo perguntar primeiro se alguém está interessado em vê-los.
Não perca todo o seu tempo tentando descobrir que mudanças na sua entrada fazem o problema desaparecer. Isto provavelmente não vai ajudar a resolver o problema. Se for visto que o erro não pode ser corrigido imediatamente, você ainda vai ter tempo para compartilhar sua descoberta com os outros. Também, novamente, não perca seu tempo advinhando porque o erro existe. Nós o encontraremos brevemente.
Ao escrever o relatório de erro, por favor escolha uma terminologia que não confunda. O pacote de software em seu todo é chamado de “PostgreSQL” e, algumas vezes, de “Postgres” para abreviar. Se estiver se referindo especificamente ao processo servidor mencione isto, não diga apenas que o “PostgreSQL caiu”. A queda de um único processo do servidor é bem diferente da queda do processo “postmaster” pai; por favor não diga “o postmaster caiu” quando um único processo servidor caiu, nem o contrário. Além disso os programas cliente, como o terminal interativo “psql”, são completamente separados do servidor. Por favor, tente especificar se o problema está no lado do cliente ou no lado do servidor.
De uma maneira geral os relatórios de erro devem ser enviados para a lista de discussão de relatórios de erros em . É necessária a utilização de um assunto descritivo para a mensagem de correio eletrônico, talvez uma parte da própria mensagem de erro.
Outro método é preencher o relatório de erro disponível no sítio do projeto na Web em http://www.postgresql.org/. O preenchimento desta forma faz com que este seja enviado para a lista de discussão .
Não envie o relatório de erro para nenhuma lista de discussão dos usuários, tal como ou . Estas listas de discussão são para responder perguntas dos usuários, e seus subscritores normalmente não desejam receber relatórios de erro. Mais importante ainda, eles provavelmente não vão conseguir corrigir o erro.
Por favor, também não envie relatórios para a lista de discussão dos desenvolvedores em . Esta lista é para discutir o desenvolvimento do PostgreSQL e nós
viii
Antes de poder usar o PostgreSQL este deve estar instalado, é claro. É possível que o PostgreSQL já esteja instal- ado em sua máquina, seja porque está incluído na distribuição do sistema operacional, ou porque o administrador do sistema fez a instalação. Se este for o caso, deve-se obter informações na documentação do sistema operacional ou com o administrador do sistema sobre como acessar o PostgreSQL.
Se você não tiver certeza que o PostgreSQL está disponível, ou que pode ser usado para os seus experimentos, você poderá fazer a instalação por si mesmo. Proceder desta maneira não é difícil e pode ser um bom exercício. O PostgreSQL pode ser instalado por qualquer usuário sem privilégios, porque nenhum acesso de super-usuário (root) é necessário.
Se você for instalar o PostgreSQL por si mesmo, então consulte o Guia do Administrador do PostgreSQL para ler as instruções de instalação, e depois retorne para este manual quando a instalação estiver completa. Certifique-se de seguir de perto a seção relativa à configuração das variáveis de ambiente apropriadas.
Se o administrador do sistema não fez a configuração conforme o padrão, talvez algum trabalho adicional deva ser feito. Por exemplo, se a máquina servidora de banco de dados for uma máquina remota, será necessário definir a variável de ambiente PGHOST com o nome da máquina servidora de banco de dados. A variável de ambiente PGPORT talvez também tenha que ser definida. A regra básica é esta: se você tentar iniciar um programa aplicativo e este informar que não pode se conectar ao banco de dados, você deve consultar o administrador do servidor ou, caso seja você mesmo, a documentação para ter certeza de que o seu ambiente está corretamente configurado. Se você não entendeu o parágrafo anterior então, por favor, leia a próxima seção.
Antes de prosseguirmos, você deve entender as bases da arquitetura de sistema do PostgreSQL. Compreendendo como as partes do PostgreSQL interagem entre si torna este capítulo mais claro.
No jargão de banco de dados, o PostgreSQL utiliza o modelo cliente-servidor. Uma sessão do PostgreSQL consiste dos seguintes processos (programas) cooperando entre si:
É típico em aplicativos cliente-servidor o cliente e o servidor estarem em máquinas diferentes. Neste caso eles se comunicam através de uma conexão de rede TCP/IP. Deve-se ter isto em mente, porque arquivos que podem ser acessados na máquina cliente podem não ser acessíveis (ou podem somente ser acessíveis usando um nome de arquivo diferente) pela máquina servidora.
O servidor PostgreSQL pode tratar múltiplas conexões concorrentes dos clientes. Para esta finalidade é iniciado (“fork”) um novo processo para cada conexão. Deste ponto em diante, o cliente e o novo processo servidor passam
Capítulo 1. Iniciando
a se comunicar sem a intervenção do processo original postmaster. Portanto, o postmaster está sempre ex- ecutando aguardando por novas conexões dos clientes, enquanto os processos servidores associados aos clientes surgem e desaparecem (tudo isso, obviamente, é invisível para o usuário sendo somente mencionado para ficar completo).
O primeiro teste a ser feito para ver se é possível acessar o servidor de banco de dados é tentar criar um banco de dados. Um servidor PostgreSQL pode gerenciar muitos bancos de dados. Tipicamente, um banco de dados em separado é usado para cada projeto ou para cada usuário.
Possivelmente o administrador já criou um banco de dados para o seu uso. Ele deve ter dito qual é o nome de seu banco de dados. Neste caso esta etapa pode ser pulada, indo-se direto para a próxima seção.
para criar um novo banco de dados chamado meu_bd deve ser usado o seguinte comando:
$ createdb meu_bd
O que deve produzir a resposta:
CREATE DATABASE
Se isto acontecer, esta etapa foi executada com sucesso e o resto da seção pode ser saltada.
Se aparecer uma mensagem parecida com
createdb: command not found
então o PostgreSQL não foi instalado adequadamente. Ou não foi instalado, ou o caminho de procura não está correto. Tente executar o comando utilizando o caminho absoluto:
$ /usr/local/pgsql/bin/createdb meu_bd
O caminho na sua máquina pode ser diferente (N.T. /usr/bin/createdb no Mandrake Linux). Faça contato com o administrador ou verifique novamente as instruções de instalação para corrigir a situação.
Outra resposta pode ser esta:
psql: could not connect to server: Connection refused Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? createdb: database creation failed
Isto indica que o servidor não foi inicializado, ou que não foi inicializado aonde o createdb esperava que estivesse. Novamente, verifique as instruções de instalação ou consulte o administrador.
Se você não possuir o privilégio necessário para criar bancos de dados, a seguinte mensagem será exibida:
ERROR: CREATE DATABASE: permission denied createdb: database creation failed
Nem todo usuário possui autorização para criar novos bancos de dados. Se o PostgreSQL recusar a criação do banco de dados, então o administrador deve conceder a permissão para criar bancos de dados para você. Consulte
Capítulo 1. Iniciando
\h for help with SQL commands ? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit
meu_bd=>
A última linha também pode ser
meu_bd=#
Isto significa que você é um super-usuário do banco de dados, o que acontece geralmente quando você instala o PostgreSQL por si mesmo. Sendo um super-usuário significa que você não está sujeito a controles de acesso. Para as finalidades deste tutorial isto não tem importância.
Se você teve problemas ao inicializar o psql, então retorne à seção anterior. Os diagnósticos do psql e do createdb são similares, e se um funcionou o outro deve funcionar também.
A última linha exibida pelo psql é o prompt, indicando que o psql está aguardando você, e que você pode digitar comandos SQL dentro do espaço de trabalho mantido pelo psql. Tente usar estes comando:
meu_bd=> SELECT version(); version
PostgreSQL 7.3devel on i586-pc-linux-gnu, compiled by GCC 2. (1 row)
meu_bd=> SELECT current_date; date
2002-08- (1 row)
meu_bd=> SELECT 2 + 2; ?column?
4 (1 row)
O programa psql possui vários comandos internos que não são comandos SQL. Eles começam pelo caractere de contrabarra, “\”. Alguns destes comandos são mostrados na mensagem de boas vindas. Por exemplo, pode ser obtida ajuda na sintaxe de vários comandos SQL do PostgreSQL digitando-se:
meu_bd=> \h
Para sair do psql digite
meu_bd=> \q
e o psql vai terminar e retornar para a linha de comando do sistema operacional (para conhecer outros comandos internos digite ? no prompt do psql). Todas as funcionalidades do psql estão documentadas no Manual de Referência do PostgreSQL. Se o PostgreSQL estiver instalado corretamente, você também poderá digitar man psql na linha de comando do sistema operacional para ver a documentação. Neste tutorial nós não vamos utilizar estas funcionalidades explicitamente, mas você poderá usá-las por si próprio quando julgar adequado.
Este capítulo contém uma revisão sobre como utilizar a linguagem SQL para realizar operações simples. Este tutorial tem apenas o propósito de fazer uma introdução e, de forma alguma, é um tutorial completo sobre a linguagem SQL. Muitos livros foram escritos sobre o SQL, incluindo o Understanding the New SQL e A Guide to the SQL Standard. Você deve ficar ciente de que alguma funcionalidades da linguagem no PostgreSQL são extensões ao padrão.
Nos exemplos a seguir é assumido que você tenha criado o banco de dados chamado meu_bd, conforme descrito no capítulo anterior, e que tenha ativado o psql.
Os exemplos presentes neste manual também podem ser encontrados no fonte da distribuição do PostgreSQL no diretório src/tutorial/. Consulte o arquivo README neste diretório para saber como usá-los. Para iniciar o tutorial (em inglês) faça o seguinte:
$ cd .... /src/tutorial $ psql -s mydb ...
mydb=> \i basics.sql
O comando \i lê os comandos no arquivo especificado. A opção -s ativa o modo passo a passo, que faz uma pausa antes de enviar cada comando para o servidor. Os comandos utilizados nesta seção estão no arquivo basics.sql.
O PostgreSQL é um sistema de gerenciamento de banco de dados relacional (SGBDR). Isto significa que é um sistema para gerenciar dados armazenados em relações. Uma relação é essencialmente um termo matemático para tabela. A noção de armazenar dados em tabelas é um lugar tão comum hoje em dia que pode parecer totalmente óbvio, mas existem várias outras maneiras de se organizar bancos de dados. Arquivos e diretórios em sistemas operacionais tipo Unix são um exemplo de banco de dados hierárquico. Um desenvolvimento mais moderno são os bancos de dados orientados a objeto.
Cada tabela é uma coleção nomeada de linhas. Cada linha de uma determinada tabela possui o mesmo conjunto de colunas nomeadas, e cada coluna é de um tipo de dado específico. Enquanto as colunas possuem uma ordem fixa em cada linha, é importante lembrar que o SQL não garante a ordem das linhas dentro de uma tabela (embora as linhas possam ser explicitamente ordenadas para a exibição).
As tabelas são agrupadas em bancos de dados, e uma coleção de bancos de dados gerenciada por uma única instância do servidor PostgreSQL constitui um agrupamento de bancos de dados.
Uma nova tabela pode ser criada especificando-se o seu nome juntamente com os nomes das colunas e seus tipos:
CREATE TABLE clima ( cidade varchar(80), temp_min int, -- temperatura mínima
Capítulo 2. A linguagem SQL
A sintaxe usada anteriormente requer que seja lembrada a ordem das colunas. Uma sintaxe alternativa permite relacionar as colunas explicitamente:
INSERT INTO clima (cidade, temp_min, temp_max, prcp, data) VALUES (’São Francisco’, 43, 57, 0.0, ’1994-11-29’);
As colunas podem ser listadas em uma ordem diferente se for desejado, ou até mesmo omitir algumas colunas. Por exemplo, se a precipitação for desconhecida:
INSERT INTO clima (data, cidade, temp_max, temp_min) VALUES (’1994-11-29’, ’Hayward’, 54, 37);
Muitos desenvolvedores consideram relacionar explicitamente as colunas um estilo melhor do que confiar na ordem implícita.
Por favor, entre todos os comando mostrados acima para ter alguns dados com que trabalhar nas próximas seções.
Também pode ser utilizado o comando COPY para carregar uma grande quantidade de dados a partir de arquivos de texto. Geralmente isto é mais rápido porque o comando COPY é otimizado para esta finalidade, embora possua menos flexibilidade do que o comando INSERT. Um exemplo poderia ser:
COPY clima FROM ’/home/user/clima.txt’;
onde o arquivo de origem deve poder ser acessado pelo servidor e não pelo o cliente, uma vez que o servidor lê o arquivo diretamente. Pode-se obter mais informações sobre o comando COPY no Manual de Referência do PostgreSQL.
Para obter os dados de uma tabela, a tabela deve ser consultada. O comando SELECT do SQL é utilizado para esta função. O comando é dividido em lista de seleção (a parte que relaciona as colunas a serem retornadas), lista de tabelas (a parte que relaciona as tabelas de onde os dados vão ser extraídos), e uma qualificação opcional (a parte em que são especificadas as restrições). Por exemplo, para ver todas as linhas da tabela clima digite:
SELECT * FROM clima;
(aqui o * significa “todas as colunas”) e a saída deve ser:
cidade | temp_min | temp_max | prcp | data -----------------+----------+----------+------+------------ São Francisco | 46 | 50 | 0.25 | 1994-11- São Francisco | 43 | 57 | 0 | 1994-11- Hayward | 37 | 54 | | 1994-11- (3 rows)
Pode ser especificada qualquer expressão arbitrária na lista de seleção. Por exemplo, pode-se escrever:
SELECT cidade, (temp_max+temp_min)/2 AS temp_media, data FROM clima;
O que deve produzir:
cidade | temp_media | data -----------------+------------+------------
Capítulo 2. A linguagem SQL
São Francisco | 48 | 1994-11- São Francisco | 50 | 1994-11- Hayward | 45 | 1994-11- (3 rows)
Perceba que a cláusula AS foi utilizada para mudar o nome da coluna de saída (é opcional).
Operadores booleanos arbitrários (AND, OR e NOT) são permitidos na qualificação da consulta. Por exemplo, o comando abaixo obtém o clima de São Francisco nos dias de chuva:
SELECT * FROM clima WHERE cidade = ’São Francisco’ AND prcp > 0.0;
Resultado:
cidade | temp_min | temp_max | prcp | data -----------------+----------+----------+------+------------ São Francisco | 46 | 50 | 0.25 | 1994-11- (1 row)
Como nota final, pode-se desejar que os resultados de uma seleção retornem em uma determinada ordem, ou com as linhas duplicadas removidas:
SELECT DISTINCT cidade FROM clima ORDER BY cidade;
Hayward São Francisco (2 rows)
As cláusulas DISTINCT e ORDER BY podem ser usadas separadamente, é claro.
Até agora nossas consultas somente acessaram uma tabela de cada vez. As consultas podem acessar várias tabelas de uma vez, ou acessar a mesma tabela de uma maneira que várias linhas da tabela são processadas ao mesmo tempo. Uma consulta que acessa várias linhas da mesma tabela ou de tabelas diferentes de uma vez é chamada de consulta de junção. Como exemplo, digamos que se deseja listar todos os registros de clima junto com a localização da cidade associada. Para fazer isto, necessitamos comparar a coluna cidade de cada linha da tabela clima com a coluna nome de todas as linhas da tabela cidades, e selecionar os pares de linha onde estes valores são correspondentes.
Nota: Este é apenas um modelo conceitual, a junção real pode ser realizada de uma maneira mais eficiente, mas isto não é visível para o usuário. Esta operação pode ser efetuada através da seguinte consulta:
SELECT * FROM clima, cidades WHERE cidade = nome;