Apostila de Programação III. Direito sobre o conteúdo reservado aos autores da apostila.

1. UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)
COORDENAÇÃO GERAL DE EDUCAÇÃO A DISTÂNCIA (EAD/UFRPE)
Programação III
Fernando Antonio Mota Trinta
Volume 3
Recife, 2011

2. Universidade Federal Rural de Pernambuco
Reitor: Prof. Valmar Corrêa de Andrade
Vice-Reitor: Prof. Reginaldo Barros
Pró-Reitor de Administração: Prof. Francisco Fernando Ramos Carvalho
Pró-Reitor de Atividades de Extensão: Prof. Delson Laranjeira
Pró-Reitora de Ensino de Graduação: Profª. Maria José de Sena
Pró-Reitora de Pesquisa e Pós-Graduação: Profª Antonia Sherlânea Chaves Véras
Pró-Reitor de Planejamento: Prof. Romildo Morant de Holanda
Pró-Reitor de Gestão Estudantil: Prof. Valberes Bernardo do Nascimento
Coordenação Geral de Ensino a Distância: Profª Marizete Silva Santos
Produção Gráfica e Editorial
Capa e Editoração: Rafael Lira, Italo Amorim e Everton Felix
Revisão Ortográfica: Elias Vieira
Ilustrações: Allyson Vila Nova
Coordenação de Produção: Marizete Silva Santos

3. Sumário
Apresentação................................................................................................................. 5
Conhecendo o Volume 3 ................................................................................................ 6
Capítulo 1 – Uma visão geral sobre bancos de dados...................................................... 8
1. Introdução ...................................................................................................................8
2. Por que os Bancos de Dados existem? ........................................................................9
3. Arquitetura Geral de um SGBD ..................................................................................12
3.1 Banco de Dados e uma visão em camadas ........................................................13
4. A modelagem e a representação de dados em um SGBD .........................................14
4.1 O Modelo Relacional ..........................................................................................15
4.2 Um modelo relacional para o sistema bancário.................................................17
Capítulo 2 – A linguagem estruturada de consulta: SQL ................................................ 23
1. Introdução .................................................................................................................23
2. Classificação de comandos SQL .................................................................................24
3. Instalação e utilização do HyperSQL ..........................................................................25
4. Comandos DDL ..........................................................................................................27
4.1 Criando tabelas ..................................................................................................27
4.2 Alterando tabelas ...............................................................................................31
4.3 Apagando tabelas ..............................................................................................31
5. Comandos DML e DQL ...............................................................................................32
5.1 Inserindo dados em tabelas ...............................................................................32
5.2 Visualizando dados das tabelas..........................................................................35
5.3 Alterando dados em tabelas ..............................................................................41
5.4 Removendo registros ........................................................................................42

4. Capítulo 3 – A especificação JDBC ................................................................................ 47
1. Introdução .................................................................................................................47
2. JDBC ...........................................................................................................................48
3. Configurando eclipse para usar JDBC ........................................................................50
4. Utilizando a API JDBC .................................................................................................55
4.1 Estabelecendo uma conexão com o banco ........................................................55
4.2 Acessando o banco de dados .............................................................................56
4.3 Parametrizando consultas ..................................................................................61
5. Transações com JDBC ................................................................................................63
6. Integrando o Banco com o Sistema de Contas ..........................................................64
Conheça o Autor .......................................................................................................... 76

5. Apresentação
Caro Cursista,
Seja bem-vindo(a) ao curso de Programação III. Esta disciplina dará seqüência aos estudos iniciados
na disciplina de linguagem de programação II, apresentando conceitos avançados relacionados à construção
de aplicações orientadas a objetos. Este curso é composto por 4 volumes. No primeiro volume, estudamos a
importância da boa organização dos sistemas, por meio dos conceitos de arquitetura de software e padrões de
projeto. Em seguida, vimos como podemos criar aplicações multitarefa utilizando threads de threads, para, por fim,
aprendermos a gerenciar arquivos em aplicações orientadas a objetos.
O segundo volume foi dedicado ao estudo do conceito de frameworks e à construção da interface do usuário,
utilizando recursos avançados como janelas, botões, listas de seleção, e outras metáforas bastante conhecidas das
aplicações modernas. Este assunto aborda ainda o chamado modelo de programação orientado a eventos.
Este terceiro volume é totalmente dedicado ao estudo da integração de aplicações com bancos de dados.
Para isto, veremos primeiramente conceitos fundamentais sobre bancos de dados, para depois vermos como se dá
sua integração com aplicações.
No quarto e último volume, você aprenderá a criar aplicações distribuídas utilizando duas abordagens: a
de sockets e a de objetos distribuídos. Em todos estes volumes, re-utilizaremos conceitos aprendidos no curso de
linguagem de programação II, e sempre que possível, utilizaremos o estudo de caso desenvolvido anteriormente, o
sistema de controle bancário, para apresentar os novos conceitos de cada capítulo.
Portanto, é de fundamental importância que você tenha bem sedimentado os conceitos de orientação
a objetos para dar prosseguimento a esta disciplina. No mais, espero que você aproveite este material para
aprofundar-se ainda mais sobre como deve-se construir aplicações mais robustas e próximas de cenários reais do
desenvolvimento de software na atualidade.
Bons estudos!
Professor Fernando Trinta
5

6. Programação III
Conhecendo o Volume 3
Neste terceiro volume, você irá encontrar o Módulo 3 da disciplina Programação III.
Para facilitar seus estudos, veja a organização deste terceiro módulo.
Módulo 3 – Uma introdução à integração de programas com bancos de
dados
Carga Horária do Módulo 3: 15 h
Objetivo do Módulo 3: Introduzir os conceitos básicos de bancos de dados, sua
organização interna de dados e relação com o mundo orientado a objetos. Apresentar a
linguagem SQL para manipulação de dados. Apresentar a especificação JDBC para conexão
de programas escritos em linguagem Java com bancos de dados.
Conteúdo Programático do Módulo 3
» Introdução a bancos de dados;
» A Linguagem SQL;
» A Especificação JDBC.
Como relatado anteriormente, o terceiro volume desta disciplina é totalmente
dedicado à integração de programas como bancos de dados. Este é um assunto muito
importante. Praticamente todo sistema de informação é composto por programas que
interagem com bases de dados que são gerenciadas por um software específico, o sistema
gerenciador de bancos de dados ou SGBD. A importância da manutenção correta destes
dados é tanta, que esta é considerada uma área de pesquisa específica dentro da ciência da
computação, com disciplinas inteiras dedicadas a conceitos específicos e a forma correta de
se definir e manipular bancos de dados.
Não é objetivo desta disciplina abordar todos os conceitos relacionados à área de
bancos de dados. Para isto, existem dentro do curso disciplinas específicas para tal. Esta é
uma disciplina que busca abordar como se dá a integração entre o mundo do das aplicações
escritas em linguagens de programação orientadas a objetos e o mundo dos bancos de
dados. Desta forma, este volume apresenta apenas um subconjunto dos conceitos mais
relevantes de bancos de dados, e que são necessários para integração entre um programa
escrito em Java e uma base de dados.
Posso afirmar então que esta é uma disciplina com viés prático. Você verá no primeiro
capítulo, conceitos básicos sobre bancos de dados, enfatizando sua evolução histórica
e principalmente, como se dá a organização interna de um banco de dados. O segundo
capítulo é dedicado à linguagem SQL. Esta é a linguagem padrão para manipulação de dados
em um SGBD. No terceiro e último capítulo é apresentado o Java Database Connectivity, ou
simplesmente JDBC, a especificação padrão para integração entre programas orientados a
objetos escritos em Java e uma gama de bancos de dados disponibilizados pela indústria.
6

7. Programação III
Capítulo 1
O que vamos estudar neste capítulo?
Neste capítulo, vamos estudar o seguinte tema:
» Introdução a bancos de dados.
Metas
Após o estudo deste capítulo, esperamos que você consiga:
» Aprender os conceitos relacionados com bancos de dados e suas diferenças em
relação ao mundo orientado a objetos.
7

8. Programação III
Capítulo 1 – Uma visão geral sobre
bancos de dados
Vamos conversar sobre o assunto?
Caro cursista,
A importância da informática é evidente pela dependência que a sociedade
contemporânea tem dos sistemas de informação (SI). Independente de seus diferentes
propósitos, estas aplicações tem como característica comum a manipulação de dados
de diversas formas, números e texto até conteúdo multimídia, como imagens e vídeos.
Gerenciar tais dados de forma eficiente é de fundamental importância para qualquer
instituição. Portanto, entender como os dados de uma aplicação devem ser representados
e como interagir com tais dados é também importante para qualquer desenvolvedor de
aplicações. Por conta disso, neste capítulo, vamos estudar os conceitos básicos necessários
para entender a importância e o funcionamento dos bancos de dados.
1. Introdução
Um Banco de Dados (também chamado de Base de Dados) é uma coleção de
dados relacionados, organizados e armazenados visando facilitar a manipulação dos dados
armazenados, permitindo realizar alterações, inserções, remoções e consultas. Neste
contexto, um “dado” representa um elemento que mantém a sua forma bruta (texto,
imagens, sons, vídeos, etc.) e que sozinho não levará a compreender determinada situação.
Já “Informação” é o conjunto de dados coletados de forma a se tornarem aplicáveis
a determinada situação, ou seja, sua forma e conteúdo são apropriados para um uso
específico.
A informação não existe por si só, ela é obtida através de uma interpretação
realizada sobre um grupo de dados. Por exemplo, em um sistema acadêmico os dados
representam as notas individuais de cada aluno, assim como seus nomes, idades, dentre
outros. Destes dados pode-se extrair como informação o fato que os alunos de uma turma
específica tiveram notas inferiores à média das demais turmas, e que portanto, precisam de
uma atenção maior por parte da coordenação da escola.
Em nosso cotidiano, existem várias bases de dados com as quais interagimos
diariamente. Verificar o saldo bancário de uma conta, consultar livros no sistema da
biblioteca, fazer a matrícula em um curso na universidade; em todos estes casos temos
exemplos de aplicações que manipulam dados como contatos, livros ou dados pessoais. Para
facilitar a interação das aplicações com estes dados, uma categoria especial de aplicações
foi desenvolvida ao longo dos anos, os chamados Sistemas Gerenciadores de Bancos de
Dados (SGBDs ou DBMS – Database Management System). Estes pacotes de software foram
desenvolvidos com funções específicas para manipular dados, com operações pré-definidas
para inserção, remoção, atualização e consulta dos dados armazenados.
Neste capítulo vamos estudar os conceitos fundamentais sobre bancos de dados,
8

9. Programação III
desde a motivação para sua existência, passando por a arquitetura geral destes sistemas,
chegando até a forma mais comum para representação dos dados, o modelo relacional
baseado em tabelas.
2. Por que os Bancos de Dados existem?
No capítulo 3 do primeiro volume desta disciplina, vimos que é possível armazenar
dados em arquivos, permitindo que estas informação sejam salvas entre sessões de uso das
aplicações. Historicamente, esta foi a primeira forma pela qual aplicações gerenciaram seus
dados, onde cada aplicação definia a forma específica como seus dados eram manipulados.
Se mais de um programa desejasse utilizar os dados definidos em uma aplicação, todos
os programas precisavam também compartilhar a estrutura de como tais dados eram
armazenados.
Com a popularização dos sistemas de informação, as empresas começaram a
enfrentar problemas relacionados à esta forma de gerenciamento. Se um determinado
sistema precisasse realizar alguma mudança na estrutura de dados, todos os demais sistemas
que acessassem os dados tinham que ser alterados, mesmo que a alteração ocorresse em
dados não manipulados pelos outros programas. Em outra situação, se os sistemas distintos
de uma mesma empresa utilizassem os mesmos dados, porém representados de forma
distinta por cada sistema, estes dados precisavam ser replicados em cada sistema. Esta
replicação trazia uma série de consequências negativas, dentre as quais pode-se destacar:
» Alta possibilidade de inconsistência de dados replicados: Caso um dado replicado
fosse atualizado em uma aplicação, o mesmo deveria ser atualizado em todos os
demais sistemas. Caso contrário, um mesmo dado apresentaria valores distintos
para a empresa, ocasionando inconsistência de informações. Por exemplo: Uma
empresa que tivesse dois sistemas, um de controle de pessoal e outro financeiro
precisaria manter informações replicadas sobre seus funcionários. Se o endereço de
um funcionário fosse atualizado em um sistema, precisaria também ser atualizado
no outro;
» Maior custo de armazenamento: Os mesmos dados seriam armazenados diversas
vezes, o que além de ocupar mais recursos, levaria a procedimentos extras para
replicar as atualizações sobre os dados. No mesmo exemplo anterior, se houvessem
mais sistemas que necessitassem das informações de um funcionário, os dados
precisariam ser replicados para cada sistema.
Com o passar dos anos e o aumento da importância dos sistemas de informação e
também de sua complexidade, buscou-se uma solução para tais problemas. O cenário vivido
então à época motivou à criação de um modelo onde dados fossem isolados de aplicações.
Os dados, então representados por arquivos, seriam responsáveis unicamente por guardar
as informações que fossem manipuladas pelos programas dos sistemas, representando
assim a própria base de dados (BD). Todo acesso ao BD passa a ser realizado de forma
centralizada e unificada por um sistema intermediário, o Sistema Gerenciador de Banco de
Dados - SGBD.
O SGBD funciona como um sistema intermediário, que atua como ponte entre cada
aplicação e a base de dados representada pelos arquivos onde os dados são persistidos
fisicamente, como visto na Figura 1.
9

10. Programação III
Figura 1 – A visão de um SGBD como intermediário entre aplicações e dados
Dentre as vantagens desta abordagem tem-se:
» O acesso e manipulação de dados entre diferentes sistemas passa a ser feito de uma
forma padronizada, que pode ser então compartilhadas entre várias aplicações;
» Diferentes sistemas podem compartilhar os mesmos dados, delegando ao SGBD a
intermediação de acesso entre aplicações e dados;
» Os sistemas passariam a enxergar apenas os dados que lhes interessam, criando a
idéia de visões. Por exemplo, se um banco de dados guarda todas as informações de
um determinado funcionário, como dados pessoais, salário, cargo, dentre outras,
um SGBD pode definir que uma determinada aplicação só consiga enxergar uma
parte destes dados;
» Os sistemas não precisariam conhecer os detalhes de como seus dados estão
gravados fisicamente;
» Os sistemas não precisariam ser modificados se a estrutura de dados que utilizam
não for modificada;
» Funcionalidades importantes como auditoria, cópias de segurança (backups) e
segurança de acesso podem ser centralizadas e delegadas aos SGBD, abstraindo tais
questões para as aplicações que utilizam os dados.
Com tais vantagens, o uso de sistemas gerenciadores de bancos de dados foi
rapidamente aceito e se tornou um padrão na indústria. Hoje é difícil imaginar um sistema
comercial que não faça uso de SGBDs. Com o passar dos anos e a evolução de tais sistemas,
o SGBD passou de programas simples para complexos sistemas de programas com função
de habilitar desenvolvedores a criar e manter um banco de dados. Dentre suas funções
principais estão:
» Definição do banco de dados: Envolve especificar estruturas e tipos de dados para
serem gravados no banco de dados, com uma descrição detalhada de cada tipo de
dado.
» Construção do banco de dados: Processo de consistir e gravar inicialmente dados
no banco de dados.
» Manipulação de um banco de dados: Inclui funções como consulta por dados
específicos e atualização para refletir as alterações no mundo real.
Hoje existem vários bancos de dados disponíveis no mercado, que possuem um
núcleo comum de funcionalidades, mas variam em relação ao suporte a quantidade de
usuários simultâneos, funcionalidades extras, eficiência e robustez. Obviamente, de acordo
com estes critérios, um SGBD pode custar até centenas de milhares de dólares. Porém, é
possível encontrar ótimas opções gratuitas disponíveis na Internet para serem utilizadas
como SGBDs. Alguns dos principais SGBDs disponíveis no mercado nos últimos anos são:
» Oracle - Sistema comercial, mas possui versões gratuitas para uso acadêmico e/
10

11. Programação III
ou doméstico (em casa). Ele foi o primeiro Banco de Dados Corporativo (cliente/
servidor) possuindo grande variedade de distribuições (para Macintosh, Windows,
Linux, FreeBSD, Unix) e para computadores de grande porte. Foi um dos primeiros
a fazer parte do mercado Web. A participação do Oracle no mercado de Banco de
Dados é bastante acentuada, principalmente em grandes empresas e em conjunto
com sistemas de médio e grande porte. É um SGBD robusto e seguro, quando
bem administrado. A Oracle também desenvolve uma suíte de desenvolvimento
chamada de Oracle Developer Suite, utilizada na construção de programas de
computador que interagem com a sua base de dados. Site Oficial em http://www.
oracle.com/us/products/database/index.htm
» Microsoft SQL Server – é o banco de dados comercial da Microsoft. Ele é um dos
principais concorrentes do Oracle. Tem como uma das vantagens o fato de, por
ser um produto Microsoft, se integrar nativamente com produtos e linguagens
da Microsoft (talvez seja esse o fator que o popularizou!). As versões atuais
são independentes e operam exclusivamente sobre Windows. É um software
proprietário e pago, como a maioria dos produtos Microsoft. Algumas empresas
que usam o MS SQL Server e são consideradas casos de sucesso no Brasil são o
Hipercard, o Banco Itaú e a ANEEL (vide: http://www.microsoft.com/brasil/
servidores/sql/default.mspx). Site Oficial em http://www.microsoft.com/
sqlserver/2008/en/us/
» MySQL - é, atualmente, um dos bancos de dados mais populares, com mais de 10
milhões de instalações pelo mundo. Ele possui versões para Windows, Solaris, Unix,
FreeBSD, Linux e é gratuito para uso não-comercial. Algumas das empresas mais
famosas que fazem uso deste banco estão: NASA, Banco Bradesco, Dataprev, HP,
Nokia, Sony e Lufthansa. O MySQL é usado principalmente para desenvolvimento
WEB como servidor de dados para comércio eletrônico. Passou a ser considerado
um SGBD de verdade (com conceito de transação) a partir da versão 5. Site Oficial
em http://www.mysql.com/
» PostgreSQL - é um sistema gerenciador de banco de dados objeto relacional
(SGBDOR), desenvolvido como projeto de código aberto. Ele é um dos SGBDs
(Sistema Gerenciador de Bancos de Dados) de código aberto mais avançados, é
grautito e tem uma boa aceitação no mercado. Originalmente concebido para
rodar em Linux, ele possui versões para Windows. É usando, principalmente, para
comércio eletrônico juntamente com linguagem PHP. O PostgreSQL é um projeto
open source coordenado pelo PostgreSQL Global Development Group. Site Oficial
em http://www.postgresql.org/
» Microsoft Access: é um banco de dados da Microsoft para uso em micros desktops
e não em servidores. Esta é a principal diferença dele para os demais bancos
SGBD como o Oracle, SQL Server e MySQL, por exemplo. Contudo, ele tem sido
muito usado em pequenas e médias empresas para armazenamento de dados em
pequenas quantidades. Agora, o MS Access não é considerado um SGBD completo,
por não possuir todas as características de um. Mas ele permite o desenvolvimento
rápido de aplicações que envolvem tanto a modelagem e estrutura de dados como
também a interface a ser utilizada pelos usuários. A linguagem de programação
disponível no access é a Microsoft Visual Basic for Applications, igualmente a
outros produtos da série Microsoft Office. Maiores informações em: http://office.
microsoft. com/pt-br/access/default.aspx
Dos SGBDs listados acima vale ressaltar que o SQL Server e o Oracle tem versões
gratuitas, porém limitadas. O PostgreSQL é open source e e o MS Access é pagos (sendo que
o Access já vem em algumas versões do pacote Microsoft Office) e o MySQL é gratuito para
11

12. Programação III
desenvolvimento, mas pago para produção.
A escolha de qual SGBD usar depende muito do projeto sendo desenvolvido e do
quanto a empresa está disposta a investir para armazenamento dos seus dados. Um SGBD
gratuito e muito popular nos dias de hoje é o PostGreSQL e vários sistemas de instituições
públicas vêm adotando o mesmo. Já no mundo corporativo o Oracle tem sido um dos mais
adotados, por ser um dos mais robustos.
3. Arquitetura Geral de um SGBD
Apesar de existir vários SGBD’s, uma arquitetura genérica para estes sistemas é
apresentada na literatura. Esta arquitetura apresenta os componentes citados na Figura 2.
Figura 2 - Arquitetura Geral de um SGBD
De acordo com esta arquitetura, os componentes funcionais de um sistema de
banco de dados incluem:
» Gerenciador de arquivos, que gerencia a alocação do espaço na armazenagem do
disco e as estruturas de dados usadas para representar a informação armazenada
no disco;
» Gerenciador do banco de dados, que fornece a interface entre os dados de baixo
nível armazenados no disco e os programas aplicativos e de consulta submetidos ao
sistema;
» Processador de consultas, que traduz os comandos numa linguagem de consulta
para instruções de baixo nível que o gerenciador do banco de dados pode
interpretar. Além disso, o processador de consultas tenta transformar uma
requisição do usuário em uma forma compatível e mais eficiente com respeito ao
banco de dados, encontrando uma boa estratégia para a executar a consulta;
» Pré-compilador da DML (Data Manipulation Language), que converte comandos
da DML embutidos em um aplicativo para chamadas de procedimento normal
na linguagem hospedeira. DML é uma linguagem para manipular dados e será
melhor vista no capítulo 2 deste volume. O pré-compilador precisa interagir com o
12

13. Programação III
processador de consultas pra gerar o código apropriado;
» Compilador da DDL (Data Definition Language), que converte comandos da DDL em
um conjunto de tabelas contendo metadados ou “dados sobre dados”. DDL permite
que a estrutura de um banco seja criado, e assim como DML, será melhor abordado
no capítulo 2;
Adicionalmente, diversas estruturas de dados são requeridas como parte da
implementação do sistema físico, incluindo:
» Arquivos de dados, que armazenam o banco de dados propriamente dito;
» Dicionário de dados, que armazena metadados sobre a estrutura do banco de
dados. O dicionário de dados é usado com freqüência. Assim, deve-se dar grande
ênfase no desenvolvimento de um bom projeto e implementação eficiente do
dicionário;
» Índices, que fornecem acesso rápido aos itens de dados guardando determinados
valores.
3.1 Banco de Dados e uma visão em camadas
Uma outra forma de se enxergar a arquitetura de um banco de dados é por meio
de uma visão em camadas. Nesta visão, um banco de dados é composto de três camadas,
como descrito na figura abaixo.
O nível físico ou nível interno é aquele que está mais próximo ao armazenamento
físico dos dados. Este nível físico é descrito por meio de um esquema interno que define
como registros, campos e índices são representados, principalmente em relação à sequência
física dos dados.
Já o nível lógico situa-se acima do físico e é responsável por descrever como dados
são representados e relacionamentos entre os próprios dados. Esta representação é mais
abstrata que os nível físico. Pode-se dizer que esta visão possibilita representar os dados
como estes realmente são, sem restrições que um usuário possa ter para visualizá-los, por
conta de uma linguagem de programação em particular.
O nível do usuário é aquele em que os usuários possuem diferentes visões dos
dados, onde muitas vezes não é necessário o acesso a todos os dados da base. Neste nível
estão os programadores e usuários finais das aplicações.
13

14. Programação III
4. A modelagem e a representação de dados em
um SGBD
Pela arquitetura e visão em camadas de um banco de dados, é importante perceber
que bancos de dados tem um modelo específico de como os dados são representados e
armazenados. Os modelos de dados utilizados em bancos de dados correspondem a como
dados, relacionamentos, suas restrições e seus significados são descritos. Existem diferentes
classificações para os modelos de dados, de acordo com diferentes critérios de separação. A
seguir, apresentam-se cinco modelos de representação dos dados.
O modelo hierárquico foi a primeira proposta para a representação de dados, onde
os dados são representados por uma estrutura de árvore semelhante àquelas estudadas na
disciplina de estrutura de dados. Dados são acessados segundo um sequência hierárquica
com uma navegação do topo (raiz) para as folhas (nós sem folhas) e da esquerda para a
direita dentro de um mesmo nó ou registro.
Figura 3 - Modelo Hierárquico de Dados
Apesar de representar uma primeira tentativa na padronização da representação
de dados, o modelo hierárquica sofreu críticas por necessitar replicar dados em virtude
do modelo de árvore utilizado, o que também levava a desperdício de espaço de
armazenamento e à possibilidade de inconsistência de dados.
O modelo em rede, assim como o modelo hierárquico, utiliza apontadores entre
os dados. Porém, as associações entre os dados não necessariamente segue um modelo de
árvore top-down como anteriormente.
Figura 4 - Modelo de dados em rede
Na abordagem em rede não aparecem as anomalias de manutenção da base de
dados que aparecem em modelos hierárquicos. Porém, a necessidade que o programador
conheça as várias ligações existentes na base cria uma forte dependência da implementação.
As consultas são complicadas pois o programador é forcado a pensar em termos de ligações
14

15. Programação III
e, em como percorrê-las para obter as informações de que necessita. A independência de
dados fica prejudicada, pois a criação ou eliminação de ligações implica em alteração dos
programas.
O modelo relacional utiliza a teoria dos conjuntos e álgebra relacional para definir
dados em função de tabelas, e relacionamentos entre os campos que formam os dados de
cada tabela. Falaremos mais sobre o modelo relacional ao final deste capítulo.
Figura 5 - Modelo Relacional de Dados
O modelo objeto é aquele que procura utilizar os conceitos já conhecidos do
paradigma orientado a objetos para representar as informações da base. Os dados são
representados através de classes que apresentam dados membros. Campos são instâncias
destas classes.
Figura 6 - Modelos de dados como objetos
Os bancos de dados orientados a objetos tem como objetivo integrar a orientação a
objeto com as aptidões dos bancos de dados, disponibilizando mais abstração da estrutura
de dados do que os bancos de dados convencionais. Existem atualmente ainda poucos
produtos no mercado.
De todos estes modelos, o relacional são os de maior sucesso comercial até hoje, e
portanto, serão melhor estudados na próxima seção e servirão de base para os exemplos de
nosso volume.
4.1 O Modelo Relacional
Este modelo foi o primeiro modelo de dados efetivamente utilizado em aplicações
comerciais. Este foi apresentado em 1970 por Codd em seus estudos na IBM sobre a
15

16. Programação III
modelagem de dados. É o modelo que possui a base mais formal entre os modelos de
dados, entretanto é o mais simples e com estrutura de dados mais uniforme.
A estrutura fundamental do modelo relacional é a relação, mas conhecido como
tabela. Na verdade, o modelo é composto por uma coleção de tabelas de nomes únicos.
Cada relação ou tabela é constituída por uma ou mais colunas chamadas de atributos
(campos) que são os tipos dos dados contidos na relação. O conjunto de valores passíveis
de serem assumidos por um atributo será intitulado de domínio. Cada linha da relação é
chamada de tupla (registro). O esquema de uma relação nada mais é do que os campos
(colunas) existentes em uma relação ou tabela. Já a instância da relação consiste no conjunto
de valores que cada atributo assume em um determinado instante. Na intersecção de uma
linha com uma coluna encontra-se o dado. Para exemplificar tais conceitos, a figura abaixo
apresenta uma tabela para representar a entidade funcionário, com os campos CPF, Nome,
Idade e Salário. Nesta tabela, três registros são apresentados para representar os dados de
três funcionários.
Figura 7 – Exemplo de uma tabela em um SGBD relacional
As relações não podem ser duplicadas (por exemplo, não podem existir dois estados
de Pernambuco, no conjunto de estados brasileiros) e a ordem de entrada de dados no Banco
de Dados não deverá ter qualquer importância para as relações, no que concerne ao seu
tratamento. Diferentemente dos modelos que o precederam o modelo relacional não tem
caminhos pré-definidos para se fazer acesso aos dados. Os relacionamentos entre as tabelas
são feitos através do uso de valores de atributos. Para exemplificar este relacionamento,
as relações funcionário e departamento representam as informações sobre funcionários
e departamentos que são relacionados pelo campo depto. Este relacionamento permite
identificar quais são os departamentos que cada funcionário trabalha.
Figura 8 - Exemplo de relacionamento entre duas tabelas
16

17. Programação III
Para trabalhar com tabelas, algumas restrições precisaram ser impostas para evitar
aspectos indesejáveis, como: Repetição de informação, incapacidade de representar parte
da informação e perda de informação. Essas restrições são: integridade referencial e chaves.
Em relação as chaves, existem três principais tipos usadas em SGBDs relacionais:
as chaves primárias, as chaves candidatas e as chaves estrangeiras. A chave estrangeira é
aquela que consegue identificar de forma unívoca um registro. Por exemplo, os campos
CPF e registro nas tabelas apresentadas anteriormente são exemplos campos que não
se repetem ( ou que não devem se repetir), e portanto, seriam chaves primárias de suas
respectivas tabelas. Em geral, toda tabela deve possuir uma chave primária. Chaves
primárias não podem ter valores nulos e tendem a ser mínimas.
Chaves candidatas possuem a mesma característica que uma chave primária,
mas que por questões funcionais não foram escolhidas como chave primária. Chaves
estrangeiras são valores que correspondem a chaves primárias de outras tabelas ou até
mesma da própria tabela, e que estabelecem relacionamentos entre entidades.
Já a integridade referencial remete à garantia que haja integridade de dados,
através dos relacionamentos entre entidades. Por exemplo, na relação entre funcionários
e departamentos há uma garantia que para um funcionário ser incluído na base, ele deve
referenciar departamento válido. Ao mesmo tempo, um registro de um departamento não
pode ser excluído se algum registro de funcionário fizer menção a tal departamento.
4.2 Um modelo relacional para o sistema bancário
Para ilustrar um modelo relacional, vamos criar um modelo de tabelas para
armazenar as informações do sistema bancário, utilizado como estudo de caso em nossa
disciplina. Lembrando um pouco deste sistema, em nosso banco, correntistas possuem uma
conta, que pode ser tanto uma conta convencional, uma conta especial ou uma poupança.
O diagrama de classes abaixo mostra as principais entidades de nosso sistema.
Figura 9 - Diagrama de Classes do sistema bancário
Uma coisa importante é entender que o mundo OO é diferente do mundo de
bancos de dados relacionais. Enquanto o primeiro trabalha com objetos, polimorfismo,
herança, o segundo é constituído de tabelas, chaves e restrições. Porém, alguns elementos
conseguem ser relacionados, como atributos de objetos mapeados em campos de uma
tabela. Boa parte das classes de um diagrama de classes é diretamente mapeada em uma
tabela em um modelo relacional. Porém, outros conceitos precisam adaptações. Veja por
exemplo, a relação de herança entre as classes Conta, ContaEspecial e Poupanca. Os dados
de um objeto Conta podem ser mapeados para uma tabela também chamada CONTA, onde
os atributos da classe sejam mapeados em campos na tabela. Em geral, os bancos possuem
17

18. Programação III
tipos semelhantes à maioria das linguagens de programação. Além disso, o campo numero
pode ser marcado como uma chave primária, pois toda conta deve ter um número único
que a identifica na base.
Esta mesma abordagem poderia ser utilizada para mapear as classes ContaEspecial
e Poupanca. Porém, isto acarretaria problemas para certas operações, como por exemplo,
fazer uma consulta do saldo de uma conta, sem conhecimento de seu tipo. Seria necessário
fazer consultas nas três tabelas, além de se replicar informações, o que dificultaria, por
exemplo, a introdução ou remoção de campos.
Para isto, pode-se utilizar a integridade referencial para melhorar a modelagem
relacional de tabelas. A Figura 10 mostra uma outra abordagem.
Figura 10 – Mapeando herança com integridade referencial e chaves estrangeiras
18

19. Programação III
Nesta nova abordagem, os elementos comuns a todo tipo de campo são
representadas na tabela CONTA. É introduzido um campo para identificar que tipo de conta
se trata um registro na tabela. As tabelas CONTA_ESPECIAL e POUPANCA fazem referencia
à tabela CONTA por meio de uma chave estrangeira que aponta para os dados comuns,
enquanto armazenam informações específicas sobre seus tipos. Com isto, acaba-se a
replicação de informações e centraliza-se as modificações no modelo de dados.
Com a idéia das chaves estrangeiras também é possível mapear os relacionamentos
existentes entre as classes do modelo OO. Por exemplo, uma conta possui um
relacionamento um objeto Pessoa que representa o correntista da conta. O correntista por
sua vez, possui dois relacionamentos com objetos do tipo Endereco, para representar os
endereços comercial e residencial do correntista. A figura abaixo mostra o modelo para o
mapeamento das classes Pessoa e Conta.
Neste caso, as tabelas PESSOA e ENDERECO devem representar os objetos Pessoa
e Endereco. Para criar os mapeamentos é necessário as chaves em cada tabela. Para a
tabela PESSOA, a chave primária é facilmente identificada. Cada pessoa é identificada por
seu cpf, que é único para cada correntista. Porém, no caso do endereço, não há uma chave
explícita. Neste caso, a solução é criar um campo que assuma a função de chave e sirva
para identificar cada registro da tabela. Nestas situações, por via de regra, este campo é
preenchido automaticamente a cada inserção de um novo registro na tabela.
Em certos casos, o simples relacionamento por meio de chaves estrangeiras não é
viável para representar o mapeamento de classes. Veja por exemplo a situação descrita no
diagrama UML a seguir.
19

20. Programação III
Figura 11 – Diagrama de classes representando o relacionamento entre professores e disciplinas
O diagrama busca representar a situação onde um professor pode lecionar várias
disciplinas, e uma disciplina pode ser lecionada por diferentes professores. Nesta relação
de M:N (muitos para muitos) a solução passa pela criação de uma tabela intermediária. Esta
tabela cria mapeamentos de chave estrangeira para as tabelas que representam as duas
classes. Desta forma, é possível representar este tipo de relacionamento de dados, como
representado pela figura abaixo.
Figura 12 - Mapeamento M:N no modelo relacional
Neste exemplo, a tabela PROFESSOR_DISCIPLINA possui a chave primária composta
pela união dos campos MATRICULA e CODIGO. O primeiro é chave estrangeira para a tabela
PROFESSOR, enquanto o segundo é chave estrangeira para a tabela DISCIPLINA. Pelos dados
do exemplo, o professor Fernando Trin ta (matrícula 1) leciona as disciplinas matemática
(código 55) e física (código 100).
Exercícios
1. Descreva as motivações para o surgimento de sistemas gerenciadores de bases
de dados. Cite exemplos de seu dia a dia que utilizam bases de dados com muitos
dados (milhares de registros).
2. Busque na Internet, bancos de dados que sigam os seguintes modelos de dados: (a)
hierárquico, (b) em rede, (c) relacional e (d) orientado a objetos.
3. Utilizando o modelo de dados relacional, crie modelos para bancos de dados que
precisem guardar informações sobre:
a) Uma biblioteca que permita empréstimos de livros a seus usuários;
20

21. Programação III
b) Um sistema acadêmico que represente alunos, professores e disciplinas;
c) Uma loja de produtos eletrônicos.
Vamos Revisar?
Resumo
Neste capítulo, você aprendeu conceitos básicos sobre bancos de dados, desde a
motivação para seu surgimento, passando por sua arquitetura e os principais modelos de
representação e organização de dados existentes na literatura. A maior importância deste
capítulo é apresentar o modelo relacional, pois este é o modelo dominante das aplicações
modernas. Entender como objetos são mapeados para tabelas é fundamental para
entender como sistemas escritos em linguagens orientadas a objetos podem persistir suas
informações em bases de dados relacionais.
21

22. Programação III
Capítulo 2
O que vamos estudar neste capítulo?
Neste capítulo, vamos estudar o seguinte tema:
» A Linguagem SQL de manipulação de dados.
Metas
Após o estudo deste capítulo, esperamos que você consiga:
» Entender os principais comandos da linguagem SQL;
» Aprender a utilizar um banco de dados simples chamado HyperSQL;
» Realizar operações no HyperSQL com alguns dos principais comandos SQL.
22

23. Programação III
Capítulo 2 – A linguagem estruturada
de consulta: SQL
Vamos conversar sobre o assunto?
Caro cursista, depois de estudar e ter uma visão geral sobre como os bancos de
dados são organizados, é preciso então entender como os dados são manipulados por
usuários e aplicações. Para isto, este capítulo é dedicado totalmente ao estudo da linguagem
SQL, o padrão da indústria para a realização de operações em bases de dados relacionais.
1. Introdução
Em qualquer base de dados, uma questão importante é como são realizadas as
operações sobre os dados armazenados. Em geral, todo SGBD fornece uma linguagem
de consulta por meio da qual usuários obtêm informações do banco de dados. Em geral,
estas linguagens são de nível mais alto que as linguagens de programação tradicionais, e
são categorizadas como procedurais ou não-procedurais (também referenciadas como
declarativas). Em uma linguagem procedural, o usuário deve “ensinar” ao sistema a
realização de uma seqüência de operações no banco de dados para obter o resultado
desejado. Em uma linguagem não-procedural, o usuário descreve a informação desejada
sem fornecer um procedimento específico para a obtenção dessas informações. Neste
contexto, uma linguagem que precisa ser estudada para manipulação de SGBDs relacionais
é a linguagem SQL.
SQL (Linguagem de Consulta Estruturada, do inglês Structure Query Language)
é uma linguagem declarativa utilizada para manipulação de bases de dados relacionais,
desenvolvida no início da década de 70 nos laboratórios da IBM, originalmente com o nome
de SEQUEL (acrônimo para “Structured English Query Language” - Linguagem de Consulta
Estruturada em Inglês). O propósito da concepção de SEQUEL era demonstrar a viabilidade
do modelo relacional proposto por Codd. SQL
O projeto de SEQUEL foi divulgado nos meios acadêmico por meio de conferências
e revistas especializadas, o que permitiu que seus conceitos pudessem ser implementados
por terceiros.
No final da década de 70, duas outras companhias além da IBM iniciaram
desenvolvimento de produtos similares, que vieram a ser Oracle e Ingres. A Oracle
Corporation introduziu a primeira implementação de SQL comercialmente disponível, e é
hoje líder no mercado de servidores de bancos de dados. A IBM também implementou SQL
em seus sistemas de banco de dados DB2 e SQL/DS. Entre os anos 80 e 90, os produtos
com SQL se multiplicaram e hoje SQL é largamente implementada e aceita como o padrão
de facto da indústria para linguagem de acesso a bancos de dados, desde sistemas desktop
como o Microsoft Access para Windows até sistemas de gerenciamento e servidores de
bancos de dados de médio e grande porte em Unix, NT e mainframes.
Hoje, SQL é padronizada por instituições normativas como a ANSI (Instituto
23

24. Programação III
Americo de Normas, do inglês American National Standards Institute) e ISO (Organização
de Padrões Internacionais, do inglês International Standard Organization). Porém, certos
fabricantes introduzem extensões e variações específicas a seus produtos, o que acaba por
comprometer a portabilidade de programas que utilizem tais extensões para manipular
SGBDs.
No capítulo que segue, você aprenderá comandos básicos da linguagem SQL que
serão necessários para a manipulação de dados em seus programas escritos em Java. Para
que você veja na prática o uso destes comandos, você também aprenderá a manipular um
SGBD simples chamado HyperSQL, que também será utilizado nos exemplos do próximo
capítulo, quando finalmente virmos a integração de Java com este SGBD.
2. Classificação de comandos SQL
SQL oferece uma série de comandos para realizar suas operações e tem como
principais características a simplicidade e facilidade de uso. As operações em SQL podem
tanto definir o modelo de dados da base, quanto inserir, alterar ou apagar registros. De
forma a melhor organizar o conjunto completo de comandos, SQL classifica tais comandos
em cinco grupos:
» DDL (Linguagem de Definição de Dados, do inglês Data Definition Language):
subconjunto que permite ao desenvolvedor definir tabelas novas e elementos
associados. Fazem parte deste grupo os comandos CREATE, ALTER TABLE e DROP.
» DML(Linguagem de manipulação de dados, do inglês Data Manipulation Language):
subconjunto da linguagem da SQL que são utilizados para realizar inclusões,
consultas, exclusões e alterações de dados presentes em registros. Incluem o
comandos INSERT, UPDATE e DELETE.
» DQL(Linguagem de consulta de dados, do inglês Data Query Language): formada
por apenas um comando, é a parte mais utilizada de SQL. Por meio do comando
SELECT, é possível realizar consultas dos mais diversos tipos, de acordo com
cláusulas e opções que podem ser utilizadas no comando.
» TCL(Linguagem de controle de transações, do inglês Transaction Control Language):
Conjunto de operações utilizados para tratamento de transações. Uma transação é
um conjunto de operações individuais que devem ser agrupadas e tratadas como
uma só. Fazem parte desta classe os comandos START TRANSACTION, COMMIT e
ROLLBACK.
» DCL(Linguagem de controle de dados, do inglês Data Control Language): Este
conjunto de comandos controla os aspectos de autorização de dados e permissões
de usuários para controlar quem tem acesso para ver ou manipular dados dentro
do banco de dados. Dois dos principais comandos são o GRANT e o REVOKE, que
respectivamente concedem e retiram permissões de usuários.
Em nossa disciplina, nós veremos principalmente os comandos DDL, DML e DQL.
Para isto, os comandos serão apresentados no contexto da criação de um banco de dados
para o sistema de controle bancário que nos acompanha desde a disciplina de linguagem de
programação II. Para que podemos ver na prática o uso de SQL, utilizaremos um banco bem
simples disponível na Internet chamado HyperSQL (http://hsqldb.org/). O HyperSQL é um
SGBD relacional escrito em Java que implementa as funcionalidades básicas necessárias para
nossos exemplos. Mas que isso, é um banco extremante portável, já que o seu executável
ocupa menos que 2Mb.
24

25. Programação III
3. Instalação e utilização do HyperSQL
Para instalar e executar o HyperSQL é preciso ter a plataforma Java instalada e
baixar o aplicativo do site http://hsqldb.org/. Na sua distribuição, o HyperSQL é um arquivo
compactado, que quando descompactado cria uma árvore de diretórios contendo scripts
de execução, documentação, exemplos, código-fonte do banco, dentre outros, como
apresentado na Figura abaixo.
Figura 13 - Estrutura do HyperSQL, depois de descompactado
Porém, apesar de todas essas informações, o único arquivo necessário para
executar o banco é o arquivo hsqldb.jar, localizado na pasta lib. Este arquivo representa o
banco, assim como a interface de administração e o driver JDBC que será necessário para
integrar os programas Java com o HyperSQL, a ser visto no próximo capítulo.
O HyperSQL é um programa Java. Logo, para executá-lo basta usar o interpretador
java para executar a aplicação, cuja classe principal é a org.hsqlbd.server.Server. Logo, a
forma mais simples para isso é abrir uma janela para disparar o comando:
java -cp .;<<caminho completo para o arquivo hsqldb.jar>> org.hsqlbd.server.Server
Ao fazer isto, o processo é iniciado e são criados arquivos que representam os
dados no diretório onde o interpretador Java foi chamado. Na própria estrutura definida
na descompactação, já é sugerida a pasta Data para este fim. Logo, é sugerido que você
execute o processo dentro desta pasta, como apresentado na Figura abaixo.
Figura 14 - Rastro de execução do HyperSQL
25

26. Programação III
Ao fazer isso, o processo fica em execução. Para finalizar a execução do processo,
basta pressionar [CRTL] + [C]. Ao executar o banco na forma mais simples, o HyperSQL cria
uma série de arquivos, padronizados pelo prefixo test, como visto na Figura.
Figura 15 - Arquivos gerados na execução do HyperSQL
Estes arquivos representam os dados da base. É possível armazenar mais de uma
base, assim como criar arquivos com nomes específicos para cada banco. Tais informações
podem ser obtidas na documentação do HyperSQL. Nos exemplos utilizados neste livro,
utilizaremos o padrão fornecido para facilitar a didática.
Uma vez o banco estando em execução, é necessário interagir com a base. Para isto,
o HyperSQL fornece uma aplicação simples, baseada em uma janela Swing, que permite
visualizar o conteúdo do banco, bem como executar comandos a partir de uma janela de
interação. Esta aplicação também é fornecida com o arquivo hsqldb.jar, por meio da classe
org.hsqldb.util.DatabaseManagerSwing. Logo para executá-la, basta disparar o comando:
java -cp .;<<caminho completo para o arquivo hsqldb.jar>> org.hsqldb.util.DatabaseManagerSwing
Este comando pode ser disparado de qualquer diretório e a figura abaixo apresenta
a tela principal da aplicação.
Figura 16 - Tela de Abertura da aplicação DatabaseManagerSwing
26

27. Programação III
Na execução do aplicativo, é apresentada uma janela com uma série de opções para
conexão com o banco. Para a correta conexão, devem ser mantidas as opções apresentadas
na Figura, e então pressionado o botão OK. Feito isso, você estará conectado ao Banco e
pronto para executar operações. Nas próximas seções, utilizaremos esta interface para ver
na práticas exemplos de vários comandos SQL.
4. Comandos DDL
Os primeiros comandos que precisam ser realizados para se manipular um banco de
dados são aqueles que permitem a criação das tabelas, índices, chaves, e demais elementos
que compõem a base de dados. São três os principais comandos DDL existentes em SQL:
» CREATE: comando que permite que sejam criados as tabelas, seus campos, chaves,
além dos relacionamentos entre tais elementos;
» ALTER TABLE: comando que permite que sejam feitas alterações em elementos já
existentes da base de dados;
» DROP: comando que apaga um elemento da base de dados.
Vamos começar a ver tais comandos e a criar nossa base de testes. Primeiramente,
vamos criar a base.
4.1 Criando tabelas
Vamos começar pelo comando CREATE, que tem sua sintaxe simplificada da
seguinte forma:
CREATE <<NOME_TABELA> (<<CAMPO1>> <<TIPO_CAMPO1>> <<OPÇÕES_CAMPO1>>,
<<CAMPO1>> <<TIPO_CAMPO1>> <<OPÇÕES_CAMPO1>>,
...
<<CAMPON>> <<TIPO_CAMPON>> <<OPÇÕES_CAMPON>>
FOREIGN KEY(<<CAMPO>>) REFERENCES <<TABELA>> (<<CAMPO_CHAVE>>)
Nesta definição, dá-se um nome para uma tabela e em seguida faz-se a definição de
cada um de seus campos. Cada campo tem obrigatoriamente um nome e um tipo, além de
cláusulas a mais que definem se um campo é chave primária, se ele pode ou não ter valores
nulos.
Em relação aos tipos, os bancos definem tipos primários para valores de seus
campos, da mesma forma que linguagens de programação definem seus tipos básicos.
Embora SQL defina valores padrões para os principais de dados como inteiros, alfanuméricos,
booleanos, dentre outros, é importante verificar a documentação da base de dados a ser
utilizada, para verificar os tipos definidos por tal SGBD.
No caso do HyperSQL, os principais tipos que serão usados neste volume são
apresentados na tabela a seguir:
27

28. Programação III
Tipo Descrição
INTERGE Valores numéricos inteiros
DOUBLE Valores numéricos de ponto flutuante
VARCHAR (TAMANHO) Valores alfanuméricos com tamanho definido
BOOLEAN Valores lógicos
IDENTITY Valores inteiros pré-definidos em uma sequência
Tabela 1 - Tipos de Dados do HyperSQL
É possível observar que com exceção do tipo IDENTITY, os demais são equivalentes
a tipos já vistos na linguagem Java, como int, double, String e boolean. O tipo IDENTITY é
uma opção muito útil para definirmos uma chave primária de uma tabela cujo valor seja
gerado automaticamente pelo próprio banco. Veremos mais sobre o tipo IDENTITY logo a
seguir.
Existem ainda opções que podem ser associadas a cada campo. Uma das principais
opções é identificar se um determinado campo é a chave primária da tabela. Para isto,
utiliza-se a expressão PRIMARY KEY associado ao campo que será a chave primária da
tabela. Se for uma chave composta, cada campo da chave composta deve ser marcada com
este atributo. Também é possível determinar se um campo pode ou não ter valores nulos
em algum registro da tabela. Caso isso não seja permitido, pode-se adicionar à definição do
campo a expressão NOT NULL.
Para exemplificar, vamos utilizar o comando CREATE para criar a tabela Endereco do
sistema de controle bancário. Para isto, utilizamos então o seguinte comando:
CREATE TABLE ENDERECO (ID_ENDERECO IDENTITY PRIMARY KEY,
RUA VARCHAR(255) NOT NULL,
NUMERO VARCHAR(255) NOT NULL,
BAIRRO VARCHAR(255) NOT NULL,
CIDADE VARCHAR(255) NOT NULL,
ESTADO VARCHAR(20) NOT NULL,
CEP VARCHAR(8) NOT NULL)
Neste comando, está sendo criada uma tabela chamada ENDERECO com 7 campos.
Todos os campos, com exceção de ID_ENDERECO são alfanuméricos. O campo ESTADO pode
ter valores com no máximo 20 caracteres, enquanto o campo CEP pode ter valores com no
máximo 8 caracteres. Os demais podem ter o valor máximo de 255 caracteres.
O campo ID_ENDERECO é definido como um IDENTITY. Além disso, este campo
também é definido como chave primária da tabela, que será utilizado para o relacionamento
com os correntistas. Lembrando: cada correntista possui dois endereços: um comercial
e outro residencial. O número associado a cada registro de endereço será utilizado para
efetuar esta relação. Para que o desenvolvedor não se preocupe com a geração dos valores
deste campo, o tipo IDENTITY é utilizado. A figura abaixo mostra a execução do comando na
aplicação de gerenciamento do HyperSQL.
28

29. Programação III
Figura 17 – Execução do Comando CREATE no HyperSQL
Para executar o comando basta digitá-lo, e depois pressionar o botão ‘Execute SQL’.
Note que no painel esquerdo, após a realização do comando, a tabela ENDERECO é listada.
Continuando a criação do nosso banco, é necessário criar a tabela PESSOA, que
guardará os dados dos correntistas do banco. Esta tabela deve possuir os campos CPF, NOME,
SEXO, além de chaves estrangeiras para a tabela endereço. Estas chaves representarão os
endereços comercial e residencial de cada correntista. Para criar a tabela pessoa utiliza-se
então o comando CREATE da seguinte forma:
CREATE TABLE PESSOA (CPF VARCHAR(11) PRIMARY KEY NOT NULL,
NOME VARCHAR(255) NOT NULL,
SEXO VARCHAR(1) NOT NULL,
END_RESIDENCIAL INTEGER NOT NULL,
END_COMERCIAL INTEGER NOT NULL,
FOREIGN KEY(END_RESIDENCIAL) REFERENCES ENDERECO(ID_ENDERECO),
FOREIGN KEY(END_COMERCIAL) REFERENCES ENDERECO(ID_ENDERECO))
Veja que cada campo utiliza a sintaxe já explicada anteriormente. O campo CPF é um
candidato natural a chave primária da tabela, uma vez que o CPF de uma pessoa nunca deve
ser igual ao de outra. A novidade é a definição de duas chaves estrangeiras pelos campos
END_RESIDENCIAL e END_COMERCIAL. Veja que inicialmente eles são definidos como dois
campos inteiros convencionais. Porém, nas duas últimas linhas, a cláusula FOREIGN KEY faz
uma associação entre estes campos, e o campo ID_ENDERECO da tabela ENDERECO. Desta
forma, esta associação indica que para serem válidos, os dois campos devem conter valores
válidos para o campo ID_ENDERECO da tabela ENDERECO. Esta regra será reforçada quando
começarmos a colocar dados nas tabelas. Porém, este mesmo tipo de raciocínio vale para a
criação da tabela CONTA.
Toda conta possui seu número e saldo. Mas além disso, precisa estar relacionada a
uma pessoa que represente o correntista da conta. Logo, é necessário também a definição
29

30. Programação III
de uma chave estrangeira para estabelecer este relacionamento. O comando apresentado a
seguir cria a tabela PESSOA:
CREATE TABLE CONTA (NUMERO INTEGER PRIMARY KEY NOT NULL,
TIPO INTEGER NOT NULL,
SALDO DOUBLE NOT NULL,
CPF VARCHAR(11) NOT NULL,
FOREIGN KEY(CPF) REFERENCES PESSOA(CPF))
Observe que o número da conta é utilizado como chave primária da tabela, pois
não devem haver contas com o mesmo número. O campo CPF é definido e, por fim, definido
como chave estrangeira relacionada com a tabela PESSOA.
Note que existe um campo a mais na definição da tabela CONTA: o campo tipo.
Lembre-se que uma conta pode ser uma conta normal, uma conta especial ou mesmo uma
poupança. Logo é preciso determinar este tipo na tabela. Além disso, nos casos da conta
especial e da poupança, é necessário ainda armazenar informações extras. Por isso, são
definidas novas tabelas: CONTA_ESPECIAL e POUPANCA. Cada uma delas possui uma relação
com a tabela CONTA por meio de uma chave estrangeira, e suas definições são apresentadas
a seguir:
CREATE TABLE CONTA_ESPECIAL (NUMERO INTEGER PRIMARY KEY NOT NULL,
LIMITE FLOAT NOT NULL,
FOREIGN KEY(NUMERO) REFERENCES CONTA(NUMERO))
CREATE TABLE POUPANCA (NUMERO INTEGER PRIMARY KEY NOT NULL,
DIA_ANIVERSARIO INTEGER NOT NULL,
TAXA_JUROS DOUBLE NOT NULL,
FOREIGN KEY(NUMERO) REFERENCES CONTA(NUMERO))
A Figura abaixo mostra o banco de dados, após todas a tabelas terem sido criadas.
Figura 18 - Visão do SGBD após criação das tabelas
30

31. Programação III
Percebe-se que existe uma ordem natural na criação das tabelas no banco. Primeiro,
deve-se criar sem nenhum tipo de dependência com outras tabelas, para então se partir
para aquelas com maior número de referências a outras tabelas do banco.
4.2 Alterando tabelas
Uma vez criada uma tabela, é possível fazer modificações na estrutura da mesma.
Tais ações são fundamentais para alterações em bancos de dados que sofram modificações
para atender novos requisitos, como surgimento de novos campos ou novos relacionamentos
com outras tabelas. Para isto, utiliza-se o comando ALTER TABLE, cuja sintaxes básicas são
apresentadas a seguir:
ALTER TABLE <<TABELA>> {ADD COLUMN <<CAMPO>> <<TIPO>> <<OPÇÕES>>}
{ADD FOREIGN KEY<<CAMPO>> REFERENCES <<TABELA(CAMPO)>>}
{DROP COLUMN <<CAMPO>>}
{ALTER COLUMN <<CAMPO>> RENAME TO <<NOVO_NOME_CAMPO>>}
ou
ALTER TABLE <<TABELA>> RENAME TO <<NOVO_NOME_TABELA>>
Seguem alguns exemplos do uso do comando ALTER TABLE:
» Para adicionar um campo ESCOLARIDADE na tabela pessoa, utiliza-se o comando:
ALTER TABLE PESSOA ADD COLUMN ESCOLARIDADE VARCHAR NOT NULL
» Para remover o campo criado:
ALTER TABLE PESSOA DROP COLUMN ESCOLARIDADE
» Para mudar o nome do campo END_COMERCIAL para ENDERECO_COMERCIAL na
tabela PESSOA:
ALTER TABLE PESSOA ALTER COLUMN END_COMERCIAL RENAME TO ENDERECO_COMERCIAL
O comando ALTER TABLE permite fazer outras mudanças nas tabelas, como mudar
o tipo de um campo ou seu tamanho, que porém nesta disciplina não serão abordados.
Uma coisa importante é que fazer alterações em tabelas que não possuam dados é muito
menos restritivo que naquelas que já possuem informações. Por exemplo, se quiséssemos
criar uma campo com a restrição NOT NULL em uma tabela que já possua 10 registros, isso
não seria possível, pois ao criar o campo, todo registro possuiria um campo sem nenhum
valor. Neste caso, a solução seria primeiro criar o campo, depois atribuir valores para cada
registro existente, para só então aplicar a restrição sobre valores nulos.
4.3 Apagando tabelas
Por fim, o último comando DDL é o DROP. Este comando permite apagar uma tabela
da base de dados, e sua sintaxe é bem sucinta:
DROP TABLE <<TABELA>>
É importante observar que apesar de sua simplicidade, existem ressalvas ao se
apagar uma tabela. Por exemplo, se você tentar apagar a tabela CONTA do banco de dados
31

32. Programação III
obterá uma mensagem de erro, como demonstrado abaixo.
Figura 19 - Erro ao se apagar uma tabela que possui referências a outras tabelas
A razão para este erro são os relacionamentos que uma tabela pode ter com outras
tabelas, que impossibilitam que a mesma seja removida do banco. No nosso caso, as tabelas
CONTA_ESPECIAL e POUPANCA referenciam a tabela CONTA, ou seja, são dependentes de
informações contidas nesta última tabela. Portanto, a tabela CONTA não pode ser removida
sem que antes, tais relacionamentos sejam desfeitos. No caso, ou as relações são desfeitas,
ou as tabelas CONTA_ESPECIAL e POUPANCA são removidas primeiramente.
5. Comandos DML e DQL
Uma vez a base criada, o banco se vê pronto para receber dados em cada tabela.
Em SQL as instruções DML (Data Manipulation Language) são usadas para manipulação
de dados e consiste nas operações de inserir dados (insert into), alterar dados (update) e
excluir dados (delete), e são consideradas operações essenciais e de grande aplicação nas
operações com banco de dados. Já o único comando DQL é o SELECT, que é utilizado para
retornar os resultados de consultas. Estes comandos serão apresentados em conjunto para
que a medida que dados sejam alterados, tais modificações possam ser visualizadas. Vamos
ver cada um deles a seguir.
5.1 Inserindo dados em tabelas
Vamos começar com o comando INSERT INTO, cuja sintaxe é apresentada abaixo:
INSERT INTO <<TABELA>> [( <<COLUNA1>>, <<COLUNA2>>,...,<<COLUNA_N>>] ) ] {
VALUES(<<VALOR1>>, << VALOR 2>>,...,<< VALOR _N>>)}
O comando insert into permite que sejam criados registros em uma tabela. De
acordo com esta sintaxe, um exemplo para inserção de dados na tabela ENDERECO seria
como descrito a seguir.
INSERT INTO ENDERECO(RUA, NUMERO, BAIRRO, CIDADE, ESTADO, CEP) VALUES(‘Avenida
Recife’,’213’,’Boa Viagem’, ‘Recife’, ‘Pernambuco’, ‘51020021’);
32

33. Programação III
Note que há uma correspondência entre cada campo e seu respectivo valor, e que
os valores alfanuméricos são delimitados por aspas simples. No caso específico da tabela
ENDERECO, você deve se lembrar que existe o campo ID_ENDERECO, definido como do tipo
identidade e que também é a chave primária da tabela. Relembrando, o valor deste campo
é determinado pelo próprio banco de dados como uma sequência de valores inteiros que
começa com 0 (zero) e que a cada novo registro é adicionado uma unidade.
Ao executar este comando no HyperSQL, obtém-se como resultado o número de
registros afetados pelo comando. Neste caso, o valor obtido é 1(um), como ilustrado a
seguir.
Figura 20 - Comando Insert no HyperSQL
Um detalhe importante na inserção de dados é a atenção em relação as
dependências entre as tabelas. Por exemplo, para inserir dados na tabela PESSOA, são
necessárias informações dos endereços comercial e residencial de cada correntista. Logo, é
necessário que estas informações estejam previamente cadastradas. Tome como exemplo,
o cadastro de uma pessoa com os seguintes dados:
Dados Valor
Nome Fernando Trinta
CPF 111111111-11
Sexo Masculino
Endereço Residencial Avenida Recife, 213, Boa Viagem, Recife – Pernambuco, CEP: 51020021
Endereço Comercial Avenida Caxangá, 23, Cordeiro, Recife – Pernambuco, CEP: 51040031
O endereço residencial já foi cadastrado anteriormente. Mas para cadastrar a
pessoa, é necessário cadastrar seu endereço comercial. Logo, primeiro tem-se que executar
o seguinte comando:
INSERT INTO ENDERECO(RUA, NUMERO, BAIRRO, CIDADE, ESTADO, CEP) VALUES(‘Avenida
Caxangá’,’23’,’Cordeiro’, ‘Recife’,’Pernambuco’, ‘51040031’);
Assume-se que ao criar este segundo endereço, o valor de seu campo ID_
ENDERECO será igual a 1 (um), pois o primeiro registro iniciou com 0 (zero). Agora com os
dois endereços cadastrados, é possível cadastrar o registro da pessoa na tabela PESSOA.
33

34. Programação III
INSERT INTO PESSOA(CPF, NOME, SEXO, END_RESIDENCIAL, END_COMERCIAL)
VALUES(‘11111111111’,’Fernando Trinta’, ‘M’, 0, 1)
Se por acaso, ao tentar incluir uma pessoa, se utiliza-se um valor para os endereços
que não fosse válido, ou seja, inexistente, a operação seria invalidada. Veja por exemplo, o
que acontece ao tentar inserir o registro passando o valor 3 para END_COMERCIAL.
Figura 21 - Erro ao inserir um registro sem as devidas dependências satisfeitas
Isso atesta o fato que é necessário ter atenção em se manter as relações de
integridade referencial entre as tabelas. Por exemplo, para inserir um registro na tabela
CONTA, é necessária a informação sobre o correntista. No caso, é necessário o CPF de uma
pessoa cadastrada na tabela PESSOA. O comando abaixo cria um registro de uma conta cujo
correntista é a pessoa de CPF igual a 11111111111, com número da conta igual a 1 e saldo
de R$ 1000,00.
INSERT INTO CONTA(NUMERO, SALDO, TIPO, CPF) VALUES (1, 1000, 1, ‘11111111111’);
Em relação ao campo tipo, o valor estabelecido é determinado pelo desenvolvedor.
No caso desta base de dados, será utilizada a seguinte tabela:
Tipo da Conta Valor do Campo Tipo
Normal 0
Especial 1
Poupança 2
Logo, a conta criada anteriormente é uma conta especial. Sendo uma conta
especial, é necessário também inserir informações na tabela CONTA_ESPECIAL, como por
exemplo, com o comando a seguir.
INSERT INTO CONTA_ESPECIAL(NUMERO, LIMITE) VALUES(1, 300);
Veja que neste caso, os valores dos campos NUMERO nas duas tabelas são iguais,
estabelecendo a ligação entre os dois registros. Neste caso, estabelece-se que a conta
especial de número 1 tem como limite o valor de R$ 300,00.
É importante também ressaltar que as restrições sobre dados nulos e chaves
34

35. Programação III
primárias são verificadas na inserção de novos dados. Caso se tente burlar algumas destas
regras, uma mensagem de erro é exibida, como no caso abaixo, onde tenta-se cadastrar
uma conta com número igual a de outra conta já cadastrada na base de dados.
Figura 22 - Erro ao se tentar incluir um registro com uma chave primária já existente
5.2 Visualizando dados das tabelas
Até então, a certeza sobre a inserção dos dados nas tabelas só poderia ser verificada
pelas respostas dos comandos INSERT realizados. Porém, uma maneira mais segura seria
verificar se os dados constam ou nas tabelas. Para isto, devemos utilizar o comando SELECT,
cuja sintaxe simplificada é apresentada a seguir.
SELECT { EXPRESSÃO | TABELA.CAMPO | * } [, ... ]
FROM <<LISTA DE TABELAS>
[WHERE <<EXPRESSÃO>>]
[ORDER BY <<CAMPO>> [{ASC | DESC}] ]
[GROUP BY <<EXPRESSÃO>> ]
Esta é uma versão simplificada do comando SELECT. Existem outras cláusulas que
não serão apresentas aqui por questões de escopo da disciplina, e também porque as
cláusulas aqui citadas serão suficientes para nossos exemplos.
Na sua versão mais simples, é possível listar todos os registros e campos de
uma determinada tabela. Por exemplo, caso você queira ver todos os registros da tabela
ENDERECO, deve usar o comando a seguir:
SELECT * FROM ENDERECO
Este comando indica que queremos visualizar todos os campos de todos os registros
da tabela ENDERECO. Porém, é possível especificar que queremos ver apenas um conjunto
dos campos, listando-os individualmente no comando SELECT, como exemplificado abaixo.
SELECT RUA FROM ENDERECO
35

36. Programação III
Veja na Figura abaixo, o resultado da execução do comando SELECT no banco criado
até então:
Note que há outros registros. Estes registros foram inseridos propositadamente por
meio de outros comandos INSERT. Note também que como havíamos dito, o campo ID_
ENDERECO tem valores numéricos que são atribuídos automaticamente para cada registro.
Com isto, podemos utilizar o comando SELECT para visualizar qual o valor gerado para um
registro de um endereço e depois utilizá-lo para inserir uma pessoa.
Caso se queira refinar uma busca, é possível utilizar a cláusula WHERE. Esta cláusula
define uma condição de busca que deve ser satisfeita por um registro para que ele seja
retornado como resposta ao SELECT. Para definir esta condição, SQL utiliza operadores
lógicos e relacionais já conhecidos das linguagens de programação. A tabela a seguir
apresenta os operadores lógicos presentes em SQL.
Tabela 2 – Operadores lógicos de SQL
Operador Descrição
“E” lógico, avalia duas condições e retorna verdadeiro apenas se ambas
AND
forem verdadeiras
“OU” lógico, avalia duas condições e retorna verdadeiro se alguma das
OR
condições for verdadeira
NOT Negacão lógica, retorna o valor contrário da expressão avaliada
Em relação aos operadores relacionais, estes são usados para realizar comparações
entre valores. A tabela abaixo apresenta os principais operadores relacionais presentes em
SQL.
36

37. Programação III
Tabela 3 – Operadores relacionais em SQL
Operador Descrição
< Menor
> Maior
<= Menor ou igual
>= Maior ou igual
= Igual
!= Diferente
BETWEEN Utilizado para especificar um intervalo de valores
Utilizado na comparação de um modelo e para especificar registros de um
LIKE banco de dados.”Like” + extensão % vai significar buscar todos resultados
com o mesmo início da extensão
Para ilustrar sua utilização, vamos apresentar alguns exemplos. Para listar todas as
ruas de endereço localizados no bairro de Boa Viagem:
Para listar todas as ruas que começam com a palavra ‘AVENIDA’:
Para listar todas as ruas que começam com a palavra ‘AVENIDA’ e que o ID_
ENDERECO estejam entre 1 e 3.
37

38. Programação III
A cláusula ORDER BY permite que os resultados apresentados sejam ordenados de
acordo com seus valores. É possível definir tanto a ordenação crescente (que é o padrão),
quanto decrescente de valores. Por exemplo, para listar os nomes de todas as ruas em
ordem decrescente, utilizaríamos o seguinte comando
SELECT RUA FROM ENDERECO ORDER BY RUA DESC
Veja a execução do comando na figura abaixo
Antes de valor sobre a última cláusula, a GROUP BY, é necessário dizer que SQL
fornece também um conjunto de funções para agregação de valores. A cláusula GROUP
utiliza estas funções para que os resultados de sua chamada sejam aplicadas em um
conjunto de registros que são agrupados por um critério comum. A tabela a seguir apresenta
as principais funções de agregação.
Tabela 4 - Operadores escalares em SQL
Função Descrição
AVG Utilizada para calcular a média dos valores de um campo determinado
COUNT Utilizada para devolver o número de registros da seleção
SUM Utilizada para devolver a soma de todos os valores de um campo determinado
MAX Utilizada para devolver o valor mais alto de um campo especificado
MIN Utilizada para devolver o valor mais baixo de um campo especificado
38

39. Programação III
Para exemplificar o uso das funções de agregação e da cláusula GROUP BY, tome
com exemplo a tabela CONTA, com os seguintes dados cadastrados.
Imagine então que se queira saber qual é a média dos saldos entre todas as contas
cadastradas. Para isso, utiliza-se a função AVG, como apresentado a seguir.
Caso se queira descobrir o maior e o menor saldo de uma conta, utiliza-se as
funções MAX e MIN, como ilustrado a seguir.
A cláusula GROUP BY permite que as funções de agregação sejam agrupadas. Para
ilustrar, imagine a consulta onde se queira saber qual o menor e maior saldo das contas de
39

40. Programação III
cada correntista, dado que existem pessoas com mais de uma conta no banco. Para isto,
utiliza-se a cláusula GROUP BY, como exemplificado a seguir.
Note que nesta última consulta, utiliza-se um novo recurso. Cada campo utilizado
na consulta pode ter um ‘apelido’. No caso, utiliza-se a palavras ‘AS’ como uma ligação entre
o valor do campo e seu apelido. Este novo identificador é utilizado na resposta da consulta,
como visto na Figura.
Por fim, deixamos as consultas mais complexas. Imagine a situação onde você
queira visualizar o nome de todos os correntistas que tenham contas especiais. Neste caso
há um problema, pois a informação sobre o tipo da conta é armazenada na tabela CONTA,
e o nome de cada correntista fica na tabela PESSOA. A princípio, teríamos que fazer duas
consultas. Primeiro, descobrir quais são os cpfs das contas especiais na tabela CONTA, e
depois utilizar estes valores para criar uma segunda consulta na tabela PESSOA.
Porém, é possível fazer esta consulta com um único comando SQL, por meio da
junção de tabelas. Veja que tanto a tabela CONTA, quanto a tabela PESSOA possuem um
campo em comum: o CPF. Logo, este campo servirá de ligação entre as duas tabelas em uma
consulta. A consulta que pretendemos é apresentada a seguir
SELECT NOME FROM CONTA AS C, PESSOA AS P WHERE (TIPO = 1) AND (C.CPF = P.CPF)
Nesta consulta, verifica-se que podem-se ser obtidos todos os campos das tabelas
citadas na cláusula FROM, no caso, as tabelas CONTA e PESSOA. No caso, só estamos
querendo retornar o nome. Este é um campo que só existe na tabela PESSOA, então o
compilador SQL não vai se perder para obter esta informação. Caso houvessem dois campos
com o mesmo nome em tabelas distintas, é necessário especificar qual campo de que tabela
se deseja retorna. Para isto, deve-se utilizar o nome da tabela (ou seu apelido), seguido por
um ponto “.” e o nome do campo.
Note que da mesma forma que campos podem ser renomeados, tabelas também.
Neste exemplo, CONTA passa ser referenciada por “C”, e PESSOA por “P”. Esta substituição é
para diminuir o tamanho das cláusulas SQL. A junção das tabelas se dá na cláusula WHERE.
Nela, além de se filtrar as contas pelo seu tipo, faz uma ligação entre as duas tabelas através
dos números de CPF. A Figura a seguir apresenta a execução desta consulta no HyperSQL.
40

41. Programação III
Outro exemplo de junção mais complexo seria: Qual o estado do endereço
residencial do correntista cuja conta seja a de número 1?
Neste caso, é necessário fazer a junção de 3 tabelas: CONTA, PESSOA e ENDERECO,
pois o estado é parte da tabela ENDERECO, enquanto o número da conta está na tabela
CONTA. A única ligação entre as duas tabelas é a tabela PESSOA. A figura abaixo apresenta o
comando SELECT e sua execução no HyperSQL.
5.3 Alterando dados em tabelas
Uma vez que já existam dados, o comando UPDATE permite que os valores de um
ou vários campos de um ou mais registros sejam alterados. Sua sintaxe é descrita a seguir.
UPDATE <<TABELA>> SET <<COLUNA1>> = <<VALOR1>>,
<<COLUNA2>> = <<VALOR2>>
[WHERE <<EXPRESSÃO>>]
A idéia do comando UPDATE é especificar novos valores para campos que devem
ser alterados de acordo com uma condição de pesquisa. Por exemplo, imagine que se queira
modificar o nome do correntista ‘Fernando Trinta’ para ‘Fernando Antonio Mota Trinta’.
Neste caso, utiliza-se o seguinte comando:
UPDATE PESSOA SET NOME = ‘Fernando Antonio Mota Trinta’ WHERE CPF = ‘11111111111’
41

42. Programação III
Note que neste caso, a condição indica que apenas o registro cujo CPF seja igual a
‘11111111111’ tenha o nome alterado para ‘’Fernando Antonio Mota Trinta’. De acordo com
os dados cadastrados até então, só existe um registro que satisfaça esta condição, e este
será o único registro alterado. Se não houvesse nenhum registro que satisfizesse a condição,
nenhum registro seria alterado.
É importante salientar que se nenhum condição de seleção for especificada na
cláusula WHERE, a atualização se dá em todas os registros da tabela. Por exemplo, caso se
queira aumentar o saldo de todas as contas em 50%. Neste caso, não há necessidade de se
definir a cláusula WHERE, como ilustrado na figura abaixo.
Duas observações importantes neste último exemplo. Primeiro, é possível utilizar
expressões matemáticas para atualizações, assim como nos critérios de busca bem como
nos resultados das consultas. Segundo, o resultado do comando UPDATE é o número
de registros afetados por sua execução. No nosso exemplo, cinco linhas da tabela foram
modificadas pelo comando UPDATE.
5.4 Removendo registros
O último dos comandos DML é aquele que permite a exclusão de registros, o
comando DELETE. A sintaxe simplificada do comando é apresentada a seguir
DELETE FROM <<TABELA>> [ WHERE CONDIÇÃO ]
42

43. Programação III
O comando DELETE remove todas os registros de uma determinada tabela que
obedeçam ao critério de busca definido na cláusula WHERE. Se não for definido nenhum
critério, todas as linhas da tabela são removidas, o que indica que o comando deve ser
utilizado com cuidado.
É importante também frisar que para que as linhas de uma coluna sejam removidas,
as condições de integridade referencial entre os dados da tabela devem ser satisfeitos. Por
exemplo, na tabela CONTAS, existem registros que são referenciados por outras tabelas,
com as contas especiais ou poupanças.
A tentativa de se remover um registro nestas condições ocasionará um erro, como
apresentado pela figura abaixo.
Logo, para efetivamente se apagar um registro, deve-se seguir a ordem correta
de remoção de dependência entre registros que estejam relacionados. No caso de nosso
exemplo, primeiro deve-se apagar o registro na tabela CONTA_ESPECIAL, para então
remover o registro na tabela CONTA, como apresentado a seguir.
Note que os dois comandos (assim como mais de um comando) podem ser
disparados na mesma janela. Estes são executados na ordem em que são digitados na
ferramenta.
43