ANUNCIO

SQL
Magazine - 3
Índice
06
SQL News
Novas tecnologias, atualizações, lançamentos de
produtos,eventos e livros.
12
Otimização de comandos SQL
Conceitos e diretrizes para aumento da perfor-
mance na execução de comandos SQL.
22
Introdução a UML
Defnição, implementação e utilizção de um
modelo usando UML
34
Emacs SQL
Utilizando o Emacs para acesso e manutenção de
bancos de dados.
42
PostgreSQL
Uma análise dos recursos do postgre e vantagens
de sua distribuição nacional.
48
JDataStore
Conhecendo o banco de dados e uma entrevista
com Sergio Cardoso.
08
Guia Rápido da SQL
Explorando os princupais recursos do comando
SELECT.
18
Modelagem de dados com ErWin
Uma introdução aos recursos e utilização desta
ferramenta.
26
Conctando Front-Ends
Exemplos práticos para o acesso a banco de dados
com diversas ferramentas.
39
MySQL
Instalação, overview dos recursos e utlilização do
MySQL no linux.
44
Replicação de dados
Teoria e prática envolvendo replicação de dados
no SQL Server.
SQL
4 - Magazine
E DI T OR I A L
Coordenador Editorial
Gladstone Matos
gladstone@neoficio.com.br
Editor Geral
Gustavo Viegas
gustavo@sqlmagazine.com.br
Equipe Editorial
Cristina Viegas
Edgar Silva
Fábio Faldini
Gisele Nichols
Pedro Henrique dos Santos
Acessora de Imprensa
Kaline Dolabela
kalined@hotmail.com
Contribuíram nesta edição
Clementino Leal, Cleison Santos,
Everson Ramos, Edgar Silva, Fábio
Faldini, Gustavo Viegas, Gisele Nichols,
Gladstone Matos, Paulo Ribeiro, Pedro
Henrique
Editor de Arte
Vinicius O. Andrade
viniciusoandrade@gmail.com
Capa
Mauro Lassance
mauro@bitourisn.com
Gerente Geral
Rosângela Matos
rosangela@neoficio.com.br
Publicidade
Julio César Lopes
julio@neoficio.com.br
Jornalista Resposável
Sérgio Moraes C. Brandão
MTb: 15183-68-148
Impressão
Ediouro Gráfica e Editora S/A
Atendimento ao Leitor
info@sqlmagazine.com.br
Assinaturas
assinaturas@sqlmagazine.com.br
Colaboração de Artigos
gustavo@sqlmagazine.com.br
Na Web
www.sqlmagazine.com.br
Distribuição
Fernando Chinaglia Dist. S/A
Rua Teodoro da Silva, 907
Grajaú - RJ - CEP: 206563-900
Atualmente, na medida em que as tecnologias de banco de dados e ferramentas
para desenvolvimento de aplicações vem evoluindo, temos um abismo cada vez
maior entre o profissional de informática e as áreas de conhecimento fora de sua
especialização. Questiono: Até onde deve ir o conhecimento do profissional de
tecnologia da informação? Será que a especialização total é o melhor caminho? Seja
técnico, desenvolvedor ou analista, a questão é quanto de sua área ele precisa saber
para implementar, analisar, projetar e interagir num processo de desenvolvimento
e manutenção de uma aplicação? Será que podemos afirmar que um desenvolvedor
deve ter somente conhecimentos profundos de uma determinada ferramenta de
desenvolvimento e, no caso de uma aplicação que acesse um banco de dados, não
ter a mínima noção deste banco? Ou ainda: um DBA que tem a responsabilidade de
instalar, configurar, dimensionar, criar os objetos de um modelo, garantir uma boa
performance, entre outras, não faria suas tarefas de modo mais consciente sabendo
um pouco sobre como os dados serão acessados e manipulados? Podemos citar ainda
aqueles que participam das definições de um projeto, lá no estágio embrionário
do sistema. Para estes, o conhecimento do banco de dados, das tecnologias e
ferramentas utilizadas para desenvolvimento, afetariam na definição do projeto a
ponto de facilitar sua implementação e futura manutenção? Como disse, o abismo
que separa o conhecimento entre cada profissional de informática tem se mostrado
crescente, e isso, de certa forma, não é bom.
A SQL Magazine chega até você com o objetivo de trazer informações sobre
o “mundo” dos bancos de dados, tecnologias e ferramentas de desenvolvimento.
Temos uma árdua tarefa diante dos leitores: diminuir o abismo citado, através da
publicação de artigos de “base”, fomentando o conhecimento daqueles que ainda
não lidam com o assunto, artigos técnicos, para os que já utilizam algum tipo de
SGBD e artigos avançados, voltados para DBA´s. Além de novidades, previews,
cursos e dicas.
Espero que você encontre na SQL Magazine informações para o seu
crescimento profissional, tomada de decisão, auxílio na solução de problemas, base
para definição de projetos independente do seu papel nos mesmos e acima de tudo:
uma fonte de consultas e mais consultas. Boa leitura.
Gustavo Viegas
Editor
Gustavo@sqlmagazine.com.br
SQL
Magazine - 5
ANUNCIO
!
"
#

!
"
#
$
Usando UML Com .NET
Através do Rational XDE ( eXtended Development Environment ) Professional v2002
você pode ter na IDE do Visual Studio o ambiente nescessário para analisar, implementar e
documentar suas soluções baseadas no .Net FrameWork utilizando UML. Esta integração é
extremamente útil para implementação de sistemas complexo utilizando C#. O XDE suporta
os principais diagramas UML, possibilita a utilização de vários Design Patterns além de facilitar
a implementação de Design Patterns próprios. Consulte www.rational.com <http://www.
rational.com> para um overview do produto.
Application Server da Oracle oferece business intelligence incorporado
Integrado ao servidor de aplicação, o Oracle9i Application Server proporciona todo o
middleware necessário para uma eficiente comunicação de dados em e-business. Com um único
produto é possível executar diversas aplicações (Java, portal, integração de aplicativos, wireless
e outras). Foram efetuadas customizações que otimizam o processo de configuração de backup
e recovery, gerenciamento automático de backups e logs arquivados, backups e restaurações
reiniciáveis e restauração/recuperação de teste. O SQL e o PL/SQL receberam outras melhorias
no Oracle9iAS. Foi adicionada depuração no lado servidor para múltiplas linguagens, permitindo
que os ambientes de desenvolvimento integrado (IDEs) depurem tanto Java quanto PL/SQL
dentro da mesma estrutura. Mais informações em www.oracle.com.br.
Cresce a competição entre os bancos de dados da IBM, Microsoft, e Oracle
Enquanto a Microsoft fala de futuras implementações no SQL Server, a Big Blue disponibiliza a
versão DB2 8.1 UDB. Nesta última versão, a IBM está tentando tornar o seu banco de dados mais
fácil de ser utilizado, distribuído, e administrado. Implementações que aumentam a performance
na execução de queryes e capacidades autônomas estão entre as novidades do DB2 8.1.
A Microsoft anunciou a versão 64-bit do SQL Server (Beta) e espera conquistar maior confiança
dos usuários de banco de dados.
A Oracle, por sua vez, utilizou a OracleWorld User Conference em San Francisco para mostrar
detalhes do seu novo banco de dados, chamado até então de 10i e previsto para lançamento em
meados de 2003. Apesar do nome final do produto não estar definido, a Oracle falou oficialmente
que a nova versão terá seu foco no gerenciamento, aumento da capacidade, e novo suporte para
XML e Web services.

Computador que se conserta sozinho
A IBM está desenvolvendo sistemas
que se consertam sozinhos e necessitam
de menos intervenção humana.
Para isso, criou a divisão Autonomic
Computing, cuja meta é fazer com que
os computadores sejam autônomos de
maneira semelhante ao comportamento
do sistema nervoso humano, que
permite adaptar-se às mudanças à sua
volta, a defender-se de ataques externos
e a recuperar-se de falhas internas. As
capacidades autônomas estarão incluídas
inclusive no banco de dados DB2. A
idéia é permitir que os computadores
dêem conselhos sobre seu melhor
rendimento e, então, permitir que esses
sistemas executem os conselhos sem o
aval dos técnicos.
Oracle9i nas eleições
Mais de 185 milhões de votos foram
processados no primeiro e segundo turnos das
eleições pelo Tribunal Superior Eleitoral. Em
menos de 24 horas, os brasileiros já sabiam o
resultado dos 91 milhões de votos apurados
na primeira fase. Para realizar tal feito, o
TSE utilizou o banco de dados Oracle9i.
O sistema, desenvolvido em parceria do
TSE com a Oracle, é o mais avançado no
segmento. Os dados de todos os Tribunais
Regionais Eleitorais, correspondentes aos
votos para deputados estaduais e federais,
senadores e governadores, são totalizados
e somados aos do TSE, que é responsável
pela centralização e contagem dos votos
para presidente da República. Esse processo
permitiu a divulgação imediata dos resultados
nos telões de apuração e na Internet.
SQL
Magazine - 7
IBM DB2 UDB 8.1 para Linux (Beta)
A IBM se orgulha do seu compromentimento com o Linux. Desde o seu portal
Linux até a campanha ‘Paz, Amor, e Linux’ que foi “grafitada” nas ruas de cidades
americanas no ano passado, a companhia tem deixado claro que pretende ser
vista na linha de frente do desenvolvimento para este sistema. A versão 8.1 (Beta)
do DB2 UDB esta disponível para download no site da “Big Blue” (www.ibm.
com/db2/) e a IBM recomenda no mínimo 128Mb de memória e de 250Mb a
350Mb disponíveis em disco para instalação e utilização de um banco de dados
de tamanho médio. Uma novidade está no db2setup utility, um utilitário com
aparência e operação semelhante a de muitos programas para Windows.
Informações adicionais e uma análise do produto estão disponíveis no endereço
http://www.newarchitectmag.com/documents/s=7733/na1202m/index.html.
Microsoft SQL Server comemora seu 10 º Aniversário
A Microsoft Corp. anunciou no dia 20 de novembro o 10º aniversário do
Microsoft(R) SQL Server (TM) na Associação de Profissionais de SQL Server
(PASS) em Seattle, num grande evento exclusivamente dedicado ao banco. No
keynote de abertura, Gordon Mangione, vice presidente corporativo do SQL
Server na Microsoft, falou do passado e das futuras implementações no SQL Server
como motivos para os muitos clientes e parceiros continuarem a desenvolver
utilizando a plataforma Microsoft SQL Server. Com base nas inovações do
produto, Mangione anunciou a disponibilização do SQL Server 2000 (64-bit) Beta
2 e do Microsoft SQL Server 2000 Service Pack 3 (SP3) Beta 1. Ele encorajou aos
desenvolvedores a utilizarem ambas as versões Beta disponíveis e reforçou o
objetivo da Microsoft de desenvolver um conjunto de ferramentas que garantam
um alto nível de performance, gerenciamento e escalabilidade.
Backups seguros e contínuos
A Storageteck, fornecedora de soluções de armazenamento de dados, está
colocando no mercado as fitotecas robotizadas L20, L40 e L80, que permitem que os
backups sejam feitos continuamente, 24 horas por dia. O produto foi desenvolvido
para pequenas e médias empresas cujas plataformas rodam em ambientes NT,
Novell, Linux ou Unix. Focados no mercado entry level, as bibliotecas de backup
destinam-se a redes com necessidades de armazenamento a partir de 400 GB. Na
prática, os produtos da Série L são disponíveis nas versões 2, 4 ou 8 drives, com
capacidades de 110 GB a 220 GB cada.
Oracle 9i - O Manual do DBA
Autor: Kevin Loney
Editora Campus - 992 páginas.
R$ 159
Pertencente à série Oracle Press, cujos livros são guias oficiais da Oracle
produzidos por especialistas da própria empresa, este livro oferece uma cobertura
completa dos recursos mais recentes e as maneiras de incorporar esses recursos
no gerenciamento de um banco de dados Oracle.

Com este livro, o leitor aprenderá a implementar as soluções administrativas
de especialistas, a manter os seus importantes sistemas da Internet e de comércio
eletrônico flexíveis, seguros e disponíveis - tudo com informações exclusivas
autorizadas pela Oracle.

Este guia abrange todos os pontos importantes sobre Oracle 9i, fornecendo
exemplos e técnicas reais. Alguns tópicos:
ANUNCIO
SQL
Guia rápido da
!"# GIadstone Matos
Iinguagem SQL é sucinta e ao mesmo tempo poderosa. Através
de um idioma de fáciI entendimento, a SQL permitiu a padronização
na forma de comunicar os apIicativos front-ends com os diversos
bancos de dados disponíveis. Neste artigo veremos os principais
parâmetros do comando SELECT, a principaI forma de recuperar dados
através da SQL.
A
COMANDO SELECT
A SQL foi criada com o objetivo de
padronizar os comandos de manipulação
de dados em SGBD’s. Hoje em dia, apesar
da linguagem possuir uma quantidade
considerável de extensões e implementações
proprietárias, pode-se afirmar que a meta
foi alcançada. A maior parte do código
SQL escrito nas aplicações se encontra no
formato “puro”, conhecido como ANSI. O
sucesso da SQL trouxe uma produtividade
interessante para a manipulação de banco
de dados. Conhecendo bem a linguagem
é possível acessar os recursos básicos de
qualquer banco relacional, como Oracle,
SQL Server ou MySQL, sem praticamente
nenhuma mudança.
Veremos neste artigo um pequeno
guia de referência para os parâmetros
do comando SELECT, um dos mais
importantes da linguagem SQL.
SELECT Simples
O comando SELECT permite recuperar
os dados de um objeto do banco, como uma
tabela, uma view e, em alguns casos, uma
stored procedure (alguns bancos de dados
permitem a criação de procedimentos que
retornam valor). A sintaxe mais básica do
comando é:
SELECT <LISTA_DE_CAMPOS>
FROM <NOME_DA_TABELA>
Exemplo:
SELECT CODIGO, NOME FROM CLIENTES;
SELECT * FROM CLIENTES;
O caracter “*” representa todos os campos.
Apesar de prática, esta máscara não é muito
utilizada, pois, para o SGBD, é mais rápido
receber o comando com todos os campos
explicitados. O uso do * obriga o servidor
a consultar quais são os campos antes de
efetuar a busca dos dados, criando mais um
“passo” no processo.
COMANDO WHERE
A cláusula Where permite ao comando
SQL passar condições de filtragem, Veja o
exemplo:
SELECT CODIGO, NOME FROM CLIENTES
WHERE CODIGO = 10;
SELECT CODIGO, NOME FROM CLIENTES
WHERE UF = ‘RJ’

SELECT CODIGO, NOME FROM CLIENTES
WHERE CODIGO >= 100 AND CODIGO <=500;
SELECT CODIGO, NOME FROM CLIENTES
WHERE UF=’MG’ OR UF = ‘SP’
Guia Rápido da SQL
SQL
Magazine - 9
Os parênteses, corretamente utilizados,
dão mais poder a consulta:
SELECT CODIGO, NOME FROM CLIENTES
WHERE UF = ‘RJ’ OR (UF=’SP’ AND ATIVO=’N’);
Neste comando, todos os clientes
do Rio de Janeiro e apenas os clientes
inativos de São Paulo seriam capturados.
SELECT CODIGO, NOME FROM CLIENTES
WHERE (ENDERECO IS NULL) OR (CIDADE IS NULL)
Aqui todos os clientes que não possuem
endereco ou cidade cadastrados serão
selecionados.
FILTRO DE TEXTO
SELECT CODIGO, NOME FROM FUNCIONARIO
WHERE DEPARTAMENTO=’VENDAS’;
SELECT CODIGO FROM CLIENTES
WHERE NOME > “K”;
Para busca parcial de strings, o SELECT
fornece o operador LIKE:
SELECT CODIGO, NOME FROM CLIENTES
WHERE NOME LIKE “MARIA*”;
Neste comando, todos os clientes
cujo nome iniciam com Maria serão
retornados. Se quisermos retornar
os nomes que contenham “MARIA”
também no meio, podemos alterar para:
SELECT CODIGO, NOME FROM CLIENTES
WHERE NOME LIKE “*MARIA*”
O uso da máscara no início e no fim da
string fornece maior poder de busca, mas
causa considerável perda de performance.
Este recurso deve ser utilizado com
critério.
Nota: Em alguns bancos de dados a
máscara de fitro não é representada pelo
caracter “*”. Consulte a referência do banco
utilizado para verificar o caracter correto.
Por padrão, a SQL diferencia caixa
baixa de caixa alta. Para eliminar essa
diferença, utilize a função UPPER:
SELECT CODIGO, NOME FROM CLIENTES WHERE
UPPER(NOME) LIKE “MARIA*SILVA*”
ORDENAÇÃO
A ordenação pode ser definida com
o comando ORDER BY. Assim como
no comando WHERE, o campo de
ordenação não precisa estar listado como
campo de visualização:
SELECT CODIGO, NOME FROM CLIENTES
ORDER BY NOME
SELECT CODIGO, NOME FROM CLIENTES
ORDER BY UF, NOME
A inclusão da palavra DESC garante a
ordenação invertida:
SELECT CODIGO, NOME FROM CLIENTES ORDER BY
NOME DESC
SELECT CODIGO, NOME FROM CLIENTES ORDER BY
UF DESC, NOME
JUNÇÃO DE TABELAS
O SELECT permite juntar duas ou
mais tabelas no mesmo resultado. Isso
pode ser feito de várias formas:
SELECT CLIENTES.CODIGO, CLIENTES.NOME,
PEDIDOS.DATA, PEDIDOS.VALOR
FROM CLIENTES, PEDIDOS
WHERE CLIENTES.CODIGO = PEDIDOS.CODCLIENTE
Nesta linha as tabelas relacionadas
CLIENTES e PEDIDOS são unificada
através do campo chave, em uma
operação de igualdade. Repare que o
nome dos campos passam a ser prefixados
pelo nome das tabelas, resolvendo
duplicidades. Uma versão resumida desta
comando pode ser:
SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR
FROM CLIENTES A, PEDIDOS B
WHERE A.CODIGO = B.CODCLIENTE
O uso de aliases no código SQL torna a
manutenção mais simples.
No comando abaixo temos várias tabelas
unificadas em uma mesma cláusula:
SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR,
C.QTD, D.DESCRICAO
FROM CLIENTES A, PEDIDOS B, ITENS C, PRODUTOS D
WHERE A.CODIGO = B.CODCLIENTE
AND B.CODIGO = C.CODPEDIDO
AND C.CODPRODUTO = D.CODIGO
Neste comando unificamos as tabelas
relacionadas CLIENTES, PEDIDOS,
ITENS e PRODUTOS. Veja mais alguns
exemplos:
SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR
FROM CLIENTES A, PEDIDOS B
WHERE A.CODIGO = B.CODCLIENTE
AND A.UF= ‘RJ’
SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR
FROM CLIENTES A, PEDIDOS B
WHERE A.CODIGO = B.CODCLIENTE
AND UF = ‘RJ’ OR (UF=’SP’ AND ATIVO=’N’);
SELECT A.CODIGO, A.NOME, B.DATA, B.VALOR
FROM CLIENTES A, PEDIDOS B
WHERE A.CODIGO = B.CODCLIENTE
ORDER BY A.UF, A.NOME
Observe que a junção através da
igualdade de campos traz como resultado
somente os registros que possuem
referência nas duas tabelas. Observe o
comando abaixo:
SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO
FROM PRODUTOS A , COMPONENTES B
WHERE A.CODIGO = B.CODPRODUTO
Os produtos que não possuem
componentes não são selecionados.
Caso seja necessário criar uma listagem
incluindo também os registros que
não possuem correspondência, deve-se
utilizar o comando JOIN.
COMANDO JOIN
A junção de tabelas no comando
SELECT também pode ser feita com o
comando JOIN. Este comando deve ser
utilizado com a palavra reservada INNER
ou com a palavra OUTER:
INNER - Semelhante ao uso do
operador “=” na junção de tabelas. Aqui,
os registros sem correspondências não
são incluídos. Esta cláusula é opcional e
pode ser omitida no comando JOIN.
OUTER – Os registros que não se
relacionam também são exibidos. Neste
caso, é possível definir qual tabela será
incluída na seleção, mesmo não tendo
correspondência.
Para exemplificar, temos as tabelas
abaixo:
Produtos
Código Descrição Categoria
1 Martelo 1
2 Chave de Fenda 1
3 Alicate 2
4 Desmagnetizador 2
5 Parafuso <null>
Componentes
Código Cod.Produto Descrição Qtd
1 3 Adaptador CF 1
2 4 CaboMod A1 2
2 4 CaboMod A2 1
Categoria
Código Descrição
1 Ferramenta A1
2 Ferramenta B1
3 Ferramenta C1
4 Ferramenta D1
Observe os exemplos e o resultado
produzido:
SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO, B.QTD
FROM PRODUTOS A
INNER JOIN COMPONENTES B
ON (A.CODIGO = B.CODPRODUTO)
SQL
10 - Magazine
ResuItado 1
Cód Descrição Descrição Qtd
1 Alicate Adaptador CF 1
2 Desmagnetizador CaboMod A1 2
3 Desmagnetizador CaboMod A2 1
Este comando pode ser escrito na
versão resumida abaixo:
SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO
FROM PRODUTOS A
JOIN COMPONENTES B
ON (A.CODIGO = B.CODPRODUTO)
Como mostrado no resultado, os
produtos que não possuem componentes
não são incluídos na seleção.
SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO , B.QTD
FROM PRODUTOS A
LEFT OUTER JOIN COMPONENTES B
ON (A.CODIGO = B.CODPRODUTO)
ResuItado 2
Cód Descrição Descrição Qtd
1 Martelo 1
2 Chave de Fenda 2
3 Alicate Adaptador CF 1
4 Desmagnetizador CaboMod A1
4 Desmagnetizador CaboMod B2
5 Parafuso
Neste comando todos os produtos
serão incluídos na seleção, independente
de possuirem um componente. Observe
que a palavra LEFT se refere a primeira
tabela no relacionamento. O mesmo
comando poderia ser descrito na forma:
SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO
FROM COMPONENTES A
RIGHT OUTER JOIN PRODUTOS B
ON ( A.CODIGO = B.CODPRODUTO )
A ordem das tabelas foi invertida, mas
o resultado é o mesmo. Observe mais
alguns exemplos:
SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO ,
B.QTD
FROM PRODUTOS A
JOIN COMPONENTES B
ON ( A.CODIGO = B.CODPRODUTO )
WHERE A.CATEGORIA=1
ResuItado 3
Cód Descrição Descrição Qtd
<vazio> <vazio> <vazio> <vazio>
SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO
FROM PRODUTOS A JOIN COMPONENTES B
ON (A.CODIGO = B.CODPRODUTO )
WHERE A.CATEGORIA=1 OR A.CATEGORIA=2
ORDER BY A.CATEGORIA, A.DESCRICAO
ResuItado 4
Cód Descrição Descrição Qtd
3 Alicate Adaptador CF 1
4 Desmagnetizador CaboMod A1 2
4 Desmagnetizador CaboMod A2 1
FULL OUTER JOIN
Podemos ainda combinar o uso de
INNER e OUTER através do comando
FULL OUTER JOIN. Neste caso,
todos os registros das duas tabelas
envolvidas serão exibidos, tendo ou não
relacionamento. Observe:
SELECT A.CODIGO, A.DESCRICAO, B.DESCRICAO
FROM PRODUTOS A
FULL OUTER JOIN CATEGORIA B
ON ( A.CATEGORIA = B.CODIGO )
ORDER BY A.DESCRICAO
Produtos
Código Descrição Categoria
1 Martelo Ferramenta A1
2 Chave de Fenda Ferramenta A1
3 Alicate Ferramenta B1
4 Desmagnetizador Ferramenta B1
5 Parafuso
Ferramenta C1
Ferramenta D1
UNION
Existe ainda uma Segunda forma de
juntar tabelas com o comando SELECT.
Através do parâmetro UNION, é possível
“colar” o conteúdo de duas tabelas. Veja
o exemplo:
SELECT CODIGO, NOME FROM CLIENTES
UNION
SELECT CODIGO, NOME FROM FUNCIONARIOS
O resultado deste comando é a
listagem de todos os clientes e a listagem
dos funcionários, dentro do mesmo
result set. Repare que no comando JOIN
a união é horizontal e no UNION a união
é vertical.
Por default, os registros duplicados
são eliminados na cláusula UNION. No
exemplo anterior, se tivéssemos um
cliente com mesmo nome e código de
um funcionário, apenas o registro da
primeira tabela seria exibido. Para incluir
todos os registros, independente de
duplicidade, utilize a palavra ALL:
SELECT CODIGO, NOME FROM CLIENTES
UNION ALL
SELECT CODIGO, NOME FROM FUNCIONARIOS
FUNÇÕES DE AGRUPAMENTO
São cinco as funções básicas de
agrupamento:
AVG: Retorna a média do campo
especificado:
SELECT AVG(VALOR) FROM PEDIDOS;
MIN/MAX/SUM: Respectivamente,
retorna o menor valor, o maior e o
somatório de um grupo de registros:
SELECT MIN(VALOR) FROM PEDIDOS;
SELECT MAX(VALOR) FROM PEDIDOS;
SELECT AVG(VALOR) FROM PEDIDOS;
COUNT: Retorna a quantidade de
itens da seleção:
SELECT COUNT(CODIGO) FROM CLIENTES;
AGRUPAMENTO
Um poderoso recurso do comando
SELECT é o parâmetro GROUP
BY. Através dele podemos retornar
informações agrupadas de um conjunto
de registros, estabelecendo uma condição
de agrupamento. É um recurso muito
utilizado na confecção de relatórios. Para
exemplificar, temos as tabelas CLIENTES
e PEDIDOS:
CIientes
Código Nome
1 Gustavo Viegas
2 Vinicius Andrade
3 Rosangela Mattos
Pedidos
Código CodCliente Data Valor
1 1 01/10/2002 500
2 1 02/10/2002 100
3 2 01/10/2002 600
4 3 05/01/2002 100
5 3 10/10/2002 300
6 3 11/10/2002 80
SELECT CODCLIENTE, MAX(VALOR)
FROM PEDIDOS
GROUP BY CODCLIENTE
O comando acima retorna o maior
valor de pedido de cada cliente. Observe
o resultado:
ResuItado 6
CodCliente MAX (Valor)
1 500
2 600
3 300
Guia Rápido da SQL
SQL
Magazine - 11
SELECT CODCLIENTE, COUNT(*)
FROM PEDIDOS
GROUP BY CODCLIENTE
Aqui vemos quantos pedidos foram
feitos por cada cliente. Veja o resultado:
ResuItado 7
CodCliente COUNT(*)
1 2
2 1
3 3
HAVING
Através do comando HAVING
podemos filtrar a cláusula GROUP BY.
Observe o comando abaixo:
SELECT CODCLIENTE, COUNT(*)
FROM PEDIDOS
GROUP BY CODCLIENTE
HAVING COUNT(*) >= 2
ResuItado 8
CodCliente COUNT(*)
1 2
3 3
Somente os clientes com 2 ou mais
pedidos serão selecionados. Repare que
o HAVING é utilizado, geralmente,
com alguma função de agrupamento.
Para filtros normais, pode-se utilizar o
comando WHERE. Observe o exemplo
abaixo:
SELECT CODCLIENTE, COUNT(*)
FROM PEDIDOS
WHERE DATA > ‘06/10/2002’
GROUP BY CODCLIENTE
HAVING COUNT(*) >= 2
ResuItado 9
CodCliente COUNT(*)
3 2
Repare que o cliente número 3
apresentou apenas dois pedidos, visto
que o primeiro não possui data maior
que 6/10.
Conclusão
O uso correto do comando SELECT
fornece uma poderosa interface de filtro.
Utilizando sempre a sintaxe padrão,
o desenvolvedor conta com maior
independência de plataforma, pois o SQL
ANSI é compreendido pelos principais
bancos de dados. Existem ainda funções
especiais e funções de conversão, que
serão abordados em futuras edições da
SQL Magazine. Para maior eficiência no
uso do SELECT, é desejável também o
bom planejamentos dos índices do banco.
Para maiores informações a respeito do
uso de índices, leia a matéria de Everson
Ramos, publicada nesta edição. Espero
que este artigo introdutório sirva de
consulta em seus projetos!
A formatação no uso de campos do tipo
DATE pode sofrer alterações de acordo com
o banco utilizado. Consulte o manual de
referência do mesmo para maiores detalhes.
NOTA
webSITES
ClubeDelphi
www.clubedelphi.net/guias/index.asp
SQLAutor
Gladstone Matos é coordenador das
revistas ClubeDelphi, Java Magazine e SQL
Magazine..
Pode ser contactado através do email:
gladstone@clubedelphi.net
ANUNCIO
SQL
Otimização de comandos
!"# Everson VoIaco
esmo um aplicativo bem projetado poderá experimentar problemas
de desempenho se a frase SQL que usa for mal construída. Falhas no proje-
to do aplicativo e na construção do SQL causam a maioria dos problemas de
desempenho em bancos de dados projetados adequadamente. Veremos neste
artigo como melhorar o comando SQL, para garantir maior performance em
sua execução, tendo como base o ORACLE.
M
A forma como o banco de dados se or-
ganiza para responder a requisição de um
aplicativo é diretamente influenciada pela
maneira como a frase SQL é construída.
Existem vários pontos a serem observados
nesta construção.
O caminho mais
curto é o uso de ín-
dices para auxiliar a
pesquisa mas, é im-
portante observar,
a simples criação de
um índice nem sempre é o melhor cami-
nho para otimização de comandos SQL.
Alguns conceitos importantes
Antes de partir para como e quais as me-
lhores formas de se aplicar e se escrever
comandos SQL é importante relembrar-
mos alguns conceitos importantes.
Existem dois métodos básicos utilizados
pelos SGDB´s para localizar dados, tam-
bém conhecidos como caminhos de aces-
so. São eles:
-Full Table Scan: Leitura seqüencial, blo-
co por bloco, de toda a tabela. Neste mé-
todo, são verificados registro a registro os
critérios de seleção.
-Index Search: Procura de um índice so-
bre a coluna definida no critério de seleção,
identificando a localização dos registros
qualificados.
O ORACLE possui seu próprio meca-
nismo de otimi-
zação, chamado
otimizador, para
executar co-
mandos SQL e
dinamicamente
determinar que
caminho de acesso seguir, dependendo
das informações disponíveis. O melhor
caminho de acesso é, geralmente, o uso
de índices, mas isso nem sempre é verda-
deiro. Por exemplo, se existir uma forma
de identificar diretamente um registro
pelo seu endereço físico, a resposta será
mais rápida. (neste caso estamos falando
do rowid, endereço físico do registro em
uma tabela ORACLE).
Ex.:
SELECT rowid INTO :emp_rowid FROM EMP
WHERE emp.empno = 5353 FOR UPDATE OF emp.ename;
UPDATE emp SET emp.ename = “OTIMIZADOR”
WHERE rowid = :emp_rowid;
“A simples criação de índices nem
sempre é o melhor caminho para
otimização de comandos SQL”
Otimização de Comandos SQL
SQL
Magazine - 13
Excluindo registros duplicados:
DELETE FROM emp e
WHERE e.rowid > (SELECT MIN(x.rowid) FROM emp x
WHERE x.empno = e.empno);
Algumas informações para auxiliar o
acesso do otimizador:
Verificar nas colunas dentro da cláusu-
la WHERE:
- Que colunas são índices;
- Que colunas estão definidas como
NOT NULL;
- Que índices podem ser usados.
É possível ajudar o otimizador a procu-
rar o melhor caminho de acesso através
da criação de índices e clusters, o que será
considerado a partir de agora.
Regras de Utilização de Índices
Um índice será usado se :
- o índice existir;
- a coluna índice for referenciada na
cláusula WHERE;
Um índice pode ser usado para testes de:
- Igualdade:
SELECT e.empno, e.ename FROM emp e
WHERE e.job = ‘CLERK’;
- Intervalo ilimitado:
SELECT e.empno, e.ename FROM emp e
WHERE e.job > ‘CLERK’;
- Intervalo limitado:
SELECT e.empno, e.ename FROM emp e
WHERE e.job BETWEEN ‘CLERK’ AND ‘JONES’;
A criação de índices deve ser feita com
critério. A atualização (inserts, updates e
deletes) em tabelas de dados gera uma
ação equivalente nos índices, sendo que o
tempo de atualização dos índices é superior
ao de atualização da tabelas, pois além da
colocação do registro em seqüência dentro
do índice é necessário a atualização dos ra-
mos das árvores do índice.
Considerando os detalhes acima, índi-
ces devem ser criados somente quando
necessário, pois a sua simples existência
não implica em melhoria de performan-
ce, podendo muitas vezes ser a origem
de perda de performance.
Condições de não utilização de Índices
1) Funções ou Operadores Aritméticos
Se a coluna índice for modificada por
uma função ou por operadores aritméticos
(+,-,*,/), o índice não será utilizado.
Um índice sobre SAL ou ENAME não
será utilizado nos seguintes casos:
SELECT e.ename, e.empno FROM emp e
WHERE e.sal*12 = 2400;
SELECT e.ename, e.empno FROM emp e
WHERE SUBSTR(e.ename,1,3) = ‘JON’
Nos casos acima, as seguintes modifi-
cações permitem o uso de índice:
SELECT e.ename, e.empno FROM emp e
WHERE e.sal = 2400/12
SELECT e.ename, e.empno FROM emp e
WHERE e.ename LIKE ‘JON%’
2) Conversão de Dados
A conversão de dados pode inibir a
utilização do índice da coluna em ques-
tão se usado inadvertidamente.
Na seguinte sentença, um índice sobre
a coluna HIREDATE não será usado:
SELECT e.ename, e.empno FROM emp e
WHERE TO_CHAR(e.hiredate, ‘month dd,yyyy’) =
‘january 23,1982’

Esta mesma sentença SQL, modifica-
da, usará o índice como segue:
SELECT e.ename, e.empno FROM emp e
WHERE e.hiredate = to_date(‘january 23,1982’ ,
’mounth dd,yyyy’)
Se na cláusula WHERE os predicati-
vos utilizam dados de tipos diferentes,
o ORACLE automaticamente converte
um deles sem a preocupação sobre a me-
lhor escolha para a utilização dos índices.
A conversão por default é escolhida, pelo
caso mais comum (Ex.: O valor de uma
coluna, onde o tipo é number, rowid ou
date, comparado com uma constante de
tipo char). Em qualquer caso é muito re-
comendado o controle da conversão dos
dados de maneira explícita.
3) Caso de colunas com valores NULL
Os índices não contêm referência para
valores do tipo null. Isto quer dizer que os
valores null podem ser
recuperados somente
através de uma leitura
seqüencial completa da
tabela (Full Table Scan).
No comando abai-
xo o índice sobre a
coluna COMM não
será utilizado:
SELECT e.ename, e.empno FROM emp e
WHERE e.comm is null

Neste código o otimizador considera
que a maioria dos registros dentro da ta-
bela são valores not null e irá escolher a
leitura seqüencial (Full Table Scan):
SELECT e.ename, empno FROM emp e
WHERE e.comm > = 100
A velocidade de execução dependerá
dos dados da tabela. Se a maioria dos
registros contiver valores não nulos, a
cláusula “comm is not null” será mais
rápida.
Os índices concatenados não terão re-
ferência para os registros onde todas as
colunas que o compõem tiverem valores
nulos.
4) Caso de predicados com a condição
“NOT EQUAL”
Os índices sobre colunas referencia-
das pela condição not equal não serão
usadas. O otimizador considera que o
número de registros que irão satisfazer a
condição será maior do que os registros
que não a satisfazem.
O índice sobre DEPTNO não será usa-
do na seguinte sentença SQL:
SELECT e.ename, e.empno FROM emp e
WHERE e.deptno !=10

No comando abaixo, o índice sobre
deptno será utilizado:
SELECT e.ename, e.empno FROM emp e
WHERE not e.deptno > 20
O ORACLE executará a sentença SQL
como e.deptno <= 20
5) Casos de sentenças SQL com cláusu-
la “ORDER BY”
A cláusula ORDER BY aumenta con-
sideravelmente a necessidade de recursos
para execução de uma sentença SQL. Em
geral, tabelas temporárias serão necessá-
rias para operação de sort.
É possível evitar a utilização de tabelas
temporárias se um índice sobre a coluna
alvo do order by existir. As seguintes con-
dições devem ser cumpridas:
- A coluna order by
deve ser definida com
not null;
- A coluna order by
deve ser uma simples
coluna índice ou as
primeiras
colunas de índice
concatenado;
- A cláusula order by deve conter so-
mente colunas e não expressões;
- Não deve haver qualquer cláusula
group by, distinct ou for update;
- Não deve haver nenhum outro aces-
“Se a maioria dos registros
contiver valores não nulos, a
cláusula ‘comm is not null’ será
mais rápida.”
SQL
14 - Magazine
so alternativo que seja prioritário sobre o
índice da coluna order by;
A seguinte sentença SQL será executa-
da via índice em DNAME se os requisitos
mencionados acima forem respeitados:
SELECT d.dname FROM dept d order by d.dname;
SELECT d.dname, d.deptno FROM dept d
WHERE d.loc = ‘dallas’ order by d.dname;
SELECT d.dname, d.loc FROM dept d
WHERE d.dname != ‘accouting’ order by d.dname;
Na sentença abaixo, se um índice sobre
a coluna LOC existir, tornar-se-á prio-
ritário e o índice sobre dname não será
usado:
SELECT d.dname, d.deptno FROM dept d
WHERE d.loc = ‘dallas’ order by d.dname;
6) Casos de sentenças SQL contendo
funções MAX ou `MIN
Um índice será usado para executar
uma sentença SQL com MAX ou MIN se
as seguintes condições forem satisfeitas:
- MAX ou MIN devem ser apenas ex-
pressões da lista de seleção;
- A lista de seleção não deve ter qual-
quer outro operador de concatenação ou
adição a não ser somen-
te MAX ou MIN;
- A lista de seleção
não deve conter qual-
quer outra coluna a não
ser uma simples ocor-
rência da coluna como
agrupamento de MAX
ou MIN;
- A sentença SQL não pode ser um
JOIN;
- A cláusula WHERE e group by não
podem ser utilizadas;
- A coluna alvo do MAX ou MAX deve
ser indexada ou fazer parte das primeiras
colunas de um índice concatenado.
A seguinte sentença SQL utilizará um
índice sobre a coluna SAL:
SELECT (max(e.sal)*2) + 10000 FROM emp e;
7) Sentenças SQL recuperam informa-
ções sobre uma simples tabela
Uma sentença SQL pode ter vários
índices únicos e/ou não únicos à disposi-
ção do otimizador. A escolha do índice a
ser usado depende da presença de:
- Índices únicos e não únicos: os índices
“É possível ajudar o otimizador
a procurar o melhor caminho
de acesso através da criação de
índices e clusters”
únicos serão favorecidos sobre os índices
não únicos.
- Vários índices não únicos : os regis-
tros identificados pelo caminho de acesso
do índice condutor (o primeiro nome na
sentença SQL) serão unidos com aquele
identificado por outro índice. A meta é
identificar os registros pertencentes a to-
dos os índices.
Se o otimizador não tiver clara esco-
lha concernente a qual índice usar, então
irá arbitrariamente escolher o primeiro
mencionado dentro da sentença SQL
como índice condutor (Driving Index).
8) Caso de sentença SQL com inter-
seção de vários predicados de igualdade
dentro da cláusula WHERE com índice
não único.
O índice não único será sorteado pela
coluna rowid a fim de minimizar o nú-
mero de comparações necessárias.
Se nós temos índice não único sobre
JOB e DEPTNO:
SELECT e.ename FROM emp e WHERE e.job =
‘manager’ and e.deptno = 20;
a. Procura a primeira ou próxima
referência do índice sobre job (driving
index) con-
tendo ‘manager’.
b. Procura a pri-
meira ou a próxi-
ma referência do
índice deptno con-
tendo valor 20.
Compara as duas rowid.
- Se as duas forem iguais, registro en-
contrado. Vai a próxima referência de
“a.” e compara com a próxima refe-
rência de “b.”.
- Se forem diferentes guarda a referên-
cia de “a.” e passa a próxima referência
de “b.”.
- c. Continua a procura até que não
existam mais referências sobre o índice
de job (driving index).
9) Caso de sentença SQL com interse-
ção de um predicado de igualdade com
um predicado sem limite, dentro da cláu-
sula WHERE com índice não único.
Somente o índice sobre a igualdade
será usado. No exemplo que segue, se ín-
dices não únicos existirem sobre as colu-
nas JOB e DEPTNO, o índice sobre JOB
será utilizado, os registros corresponden-
tes serão recuperados e verificada a vali-
dade do segundo predicado.
SELECT e.ename FROM emp e
WHERE e.job = ‘manager’ and e.deptno > 10
10) Caso de índice Concatenado
Índices concatenados são índices for-
mados por várias colunas representados
como se fosse simplesmente uma única
coluna.
a) Interseção de vários predicados de
igualdade.
Se um índice concatenado existir sobre
DEPTNO e JOB, somente uma referên-
cia será necessária para localizar a
rowid correspondente :
SELECT e.ename FROM emp e
WHERE e.job = ‘manager’ and e.deptno = 10
b) Interseção de predicados sem limite
com predicados de igualdade.
Se um índice concatenado existir sobre
DEPTNO e JOB, será utilizado para
executar a seguinte sentença SQL :
SELECT e.ename FROM emp e
WHERE e.job = ‘manager’ and e.deptno > 10
c) Interseção de predicado sem limite.
Se um índice concatenado existir sobre
DEPTNO e JOB, será utilizado para
executar a seguinte sentença SQL:
SELECT e.ename FROM emp e
WHERE e.job > ‘manager’ and e.deptno > 10
d) Utilização parcial ou total dos índi-
ces concatenados.
O otimizador pode somente usar a ou as
primeira(s) parte(s) do índice concatenado.
No seguinte caso, um índice concate-
nado foi criado sobre as colunas EMP-
NO, ENAME e DEPTNO:
A seguinte sentença SQL usa plena-
mente o índice concatenado:
SELECT * FROM emp e
WHERE e.empno = 7369
AND e.ename = ‘smith’ and e.depnto = 20

SELECT * FROM emp e
WHERE e.ename = ‘smith’
AND e.empno = 7369
AND e.deptno = 20
As seguintes sentenças SQL utilizam
parcialmente o índice concatenado:
Otimização de Comandos SQL
SQL
Magazine - 15
Uso parcial do índice usando somente
EMPNO e ENAME:
SELECT * FROM emp e
WHERE e.empno = 7369 and e.ename = ‘smith’
Uso parcial do índice usando somente
EMPNO e ENAME :
SELECT*FROM emp e
WHERE e.empno = 7369 and e.deptno = 20
As seguintes sentenças SQL não usam
o índice :
SELECT * FROM emp e
WHERE e.ename = ‘smith’ and e.deptno = 20
SELECT * FROM emp e WHERE e.ename = ‘smith’
SELECT * FROM emp e WHERE e.deptno = 20
11) Casos de Índice único e não único
na mesma sentença SQL.
O otimizador favorecerá a utilização
do índice único.
No seguinte caso o índice não único
existe em SAL e um índice único em
EMPNO :
SELECT e.ename FROM emp e
WHERE e.sal = 3000 and e.empno = 7902
O índice único será usado para procurar a
rowid correspondente ao empno = 7902.
Nos registros recuperados serão verifi-
cados o valor de sal.
12) Caso de vários índices na mesma
sentença SQL.
Se vários índices únicos estão disponí-
veis, o otimizador irá escolher o primei-
ro mencionado na sentença SQL. Por
exemplo, se índices únicos existirem so-
bre ENAME e EMPNO, e um índice não
único existir sobre SAL, a seguinte sen-
tença SQL será executada sobre o índice
ENAME
SELECT e.deptno FROM emp e
WHERE e.sal = 3000
and e.ename = ‘scott’ and e.empno = 7602
Otimização da cláusula OR (União de
predicados)
O caminho de acesso é determinado
como se a cláusula OR e suas ramifica-
ções estivessem ausentes. O caminho é
determinado considerando cada ramifi-
cação da cláusula OR separadamente.
Exemplo A
Índice existente sobre SAL e JOB.
SELECT e.ename FROM emp e
WHERE e.deptno = 10
AND (e.sal = 3000 or e.job = ‘clerk’)
Neste caso, o caminho de acesso iden-
tificado por “2” é melhor que o identifica-
do por “1”, então a cláusula OR é otimi-
zada para utilização dos índices.
Exemplo B
Somente índice sobre SAL utilizando a
mesma sentença do exemplo
Os dois caminhos de acesso identifi-
cado por “2” não são melhores que o
identificado por “1”, então os índices não
serão utilizados e ocorrerá uma pesquisa
seqüencial na tabela. O otimizador na
Cláusula OR exige a presença dos índices
utilizáveis dentro de cada coluna referen-
ciada dentro da cláusula OR.
Verificando o “Caminho de Acesso” do
otimizador
Podemos verificar o caminho de aces-
so utilizado pelo SGDB para executar
uma determinada frase SQL. Chamare-
mos esse caminho de “Acesso de Plano
de Execução”. No plano de execução são
verificados todos os procedimentos fei-
tos pelo SGDB, como utilização ou não
de índices, clusters, rowid, além da verifi-
cação da quantidade de passos realizados
pelo banco para execução do comando.
Este procedimento é muito útil, pois
pode ser utilizado como recurso para ve-
rificarmos se as alterações efetuadas em
um comando realmente otimizam a exe-
cução do mesmo. A verificação do plano
de execução é feita no Oracle através do
comando EXPLAIN PLAN. A sintaxe do
comando é a seguinte:
EXPLAIN PLAN
SET STATEMENT_ID = ‘COMAND_ID’
INTO OUTPUT
FOR COMANDOSQL;
Onde:
- COMAND_ID é um String identifica-
1)Para DEPTNO = 10 - Pesquisa seqüencial na tabela;
2) Para SAL = 3000 - Índice não único sobre SAL;
Para JOB = ‘clerk’ - Índice não único sobre JOB;
AnáIise
1)Para DEPTNO = 10 - Pesquisa seqüencial na tabela;
2) Para SAL = 3000 - Índice não único sobre SAL;
Para JOB = ‘clerk’ - Pesquisa sequencial na tabela.
AnáIise
dor para posterior visualização do plano
de execução.
- OUTPUT é tabela onde o plano de
execução é gerado. O usuário que execu-
tar o EXPLAIN PLAN deve ter direitos
de INSERT sobre a mesma. O comando
para criação desta tabela émostrado da
listagem1.
O Script para criação desta tabela cha-
ma-se “UTLXPLAN.SQL” e é instalado
juntamente com oracle e a sua localiza-
ção depende da versão do banco.
- COMANDOSQL é o comando a ser
analisado.
Para verificação do plano de execução
gerado pelo EXPLAIN PLAN devemos
consultar a tabela informada no comando.
Este procedimento pode ser efetuado de
várias maneiras, uma delas é a que segue:
SELECT SUBSTR(LPAD(‘ ‘,2*(LEVEL-1))||
operation,1,50) operation, options,
object_name, position
FROM OUTPUT
START WITH id = 0 AND statement_id = ‘COMAND_ID’
CONNECT BY PRIOR id = parent_id AND
statement_id = ‘COMAND_ID’;
Onde,
- COMAND_ID é um String identifica-
dor do plano de execução informado no
EXPLAIN PLAN
Listagem 1.
create table NOME_DA_TABELA (
statement_id varchar2(30),
timestamp date,
remarks varchar2(80),
operation varchar2(30),
options varchar2(30),
object_node varchar2(128),
object_owner varchar2(30),
object_name varchar2(30),
object_instance numeric,
object_type varchar2(30),
optimizer varchar2(255),
search_columns number,
id numeric,
parent_id numeric,
position numeric,
cost numeric,
cardinality numeric,
bytes numeric,
other_tag varchar2(255),
partition_start varchar2(255),
partition_stop varchar2(255),
partition_id numeric,
other long,
distribution varchar2(30));
SQL
16 - Magazine
- OUTPUT é tabela onde o plano de
execução é gerado.
Vamos exemplificar a execução do
EXPLAIN PLAIN validando a seguinte
informação:
“Um índice é utilizado se ele existir e se
a coluna que faz parte deste índice estiver
contida na clausula WHERE do coman-
do SQL. Este mesmo índice não é utiliza-
do se existirem funções de conversão de
dados envolvendo esta coluna.”
Em outras palavras: a execução do co-
mando “SELECT * FROM EMP WHERE
EMPNO = 50” utilizará o índice da chave
primária, que contém a coluna EMPNO, e a
execução do comando “SELECT * FROM
EMP WHERE TO_CHAR(EMPNO) =
‘50’”, não utilizará o índice.
Utilizaremos o comando do quadro
em destaque acima para criação da tabela
que receberá o plano de execução, com
o nome de PLAN_TABLE. Em seguida
executaremos o EXPLAIN PLAN para
verificação da utilização do índice com o
seguinte comando:
EXPLAIN PLAN
SET STATEMENT_ID = ‘SQLMagazine Com Indice’
INTO PLAN_TABLE
FOR
SELECT * FROM EMP WHERE EMPNO = 50;
A verificação do plano de execução é
feita de seguinte forma:
SELECT SUBSTR(LPAD(‘ ‘,2*(LEVEL-1)) ||
operation,1,50) operation, options,
object_name, position
FROM PLAN_TABLE
START WITH id = 0 AND statement_id =
‘SQLMagazine Com Indice’
CONNECT BY PRIOR id = parent_id AND
statement_id = ‘SQLMagazine Com Indice’;
O resultado com o plano de execução
é mostrado na Tabela 2.
Analisando este resultado comprova-
mos que o índice referente a chave pri-
mária foi utilizado. Vamos verificar ago-
ra o mesmo comando alterado:
EXPLAIN PLAN
SET STATEMENT_ID = ‘SQLMagazine Sem Indice’
INTO PLAN_TABLE
FOR
SELECT * FROM EMP WHERE TO_CHAR(EMPNO) = ‘50’;
A verificação do plano de execução é
feita de seguinte forma:
SELECT SUBSTR(LPAD(‘ ‘,2*(LEVEL-1)) ||
operation,1,50) operation, options,
object_name, position
FROM PLAN_TABLE
START WITH id = 0 AND statement_id =
‘SQLMagazine Sem Indice’
CONNECT BY PRIOR id = parent_id AND
statement_id = ‘SQLMagazine Sem Indice’;
Este resultado mostra que a utilização
do índice foi anulada pela função aplicada
a coluna.
Conclusão
Os cuidados a serem tomados com o
acesso a dados da aplicação são parte im-
portante de um projeto. A forma como
as consultas são escritas e como o banco
de dados está projetado influencia direta-
mente na performance do produto. Esses
fatores não devem andar separados. Na
maioria dos casos é necessária a perfeita
integração entre a consulta escrita e o
estado do banco de dados. Muitas vezes
uma simples “arrumação” na consulta,
trocando algumas cláusulas ou mudando
um pouco a “lógica” das condicionais,
garante um ganho na velocidade de exe-
cução e resposta da mesma. Não esqueça
nunca de analisar se o índice a ser criado é
realmente necessário, para não adicionar
um mais um processo para o seu banco.
Boa sorte e bons projetos!
OPERATION OPTONS OBJECT_NAME
select statement
table access by index rowid emp
index unique scan pk_emp
OPERATION OPTONS OBJECT_NAME
select statement
table access full emp
ANUNCIO
Otimização de Comandos SQL
SQL
Magazine - 17
ANUNCIO
SQL
ModeIagem de dados com
!"# CIeison Santos
oIoca-se como de fundamentaI importância tanto a anáIise
como a modeIagem de dados para o processo de desenvoIvimento
de apIicações. Esses procedimentos garantem um maior controIe
das diversas etapas do projeto desde a de!nição das regras do
negócio até a impIementação e manutenção da apIicação como um
todo. Existem no mercado, atuaImente, diversas ferramentas para
modeIagem de dados, dentre as quais pode ser destacado o soft-
ware ErWin.
C
O ErWin pode ser usado de uma for-
ma simples e prática possibilitando uma
melhor visualização, controle e documen-
tação do que se tem no banco de dados.
Através dos diversos recursos disponíveis
(Figura 1) podemos “desenhar” o nosso
banco de dados definindo as entidades de
que compõe o modelo com seus respec-
tivos atributos e relacionamentos, definir
características dessas entidades tornando-
as reais em um modelo físico ou em vários
modelos físicos se for necessário o acesso a
SGDB´s distintos. Podemos ainda criar, de
forma automática, o modelo implemen-
tado num banco de dados ou gerar scripts
para atualização de alterações efetuadas no
modelo, “sincronizar” dois bancos de for-
ma a garantir uma estrutura idêntica em
ambos, e vários outros recursos.
Na parte superior direita, observa-se uma
barra de ferramentas com os principais ob-
jetos do ErWin, como mostrado na Figura
2, a seguir:
Alguns conceitos importantes
1) Entidades - Entidade é o local onde
ficam armazenadas as informações. Por
exemplo, a Entidade ‘CLIENTES’ pode
guardar informações referentes aos clien-
tes, e assim sucessivamente.
2) Subtipos - Podem
ser definidos como
um espelho de uma
ou mais entidades. Por
exemplo, pode-se criar
um subtipo chamado
CLIENTES_RJ que
contenha somente os
clientes que moram no
Rio de Janeiro, poden-
do ter ou não todos os
Figura 1. Tela inicial do ErWin
Modelagem de Dados com ErWin
SQL
Magazine - 19
atributos da Entidade CLIENTES.
3) Atributos - Os atributos podem ser
definidos como identificadores de cada
informação contida na entidade. O Códi-
go do Cliente, por exemplo, é um atribu-
to da Entidade CLIENTES.
4) Relacionamentos - Relacionamentos
são definidos como a ligação entre duas
ou mais entidades.
5) Cardinalidade - É o que caracteriza
o relacionamento.Por exemplo: um pai
pode ter mais de um filho, porém um fi-
lho só pode ter apenas um pai. Isso quer
dizer que a cardinalidade define o com-
portamento do relacionamento, definin-
do-o como um para muitos, muitos para
um ou até muitos para muitos.
Os tipos de modelo
! Modelo Lógico: É o modelo de abs-
tração do sistema. Neste, detalhes como
qual banco de dados será usado, o tipo
de campo, o tipo de hardware, entre ou-
tros aspectos não são relevantes. Aqui,
somente as necessidades do processo são
definidas, dando uma visão “global” do
sistema. No Erwin, podemos ter uma
visão da regra de negócio, ou seja, pode-
mos planejar uma estrutura lógica para
o banco de dados, onde são definidas as
validações, as restrições da regra de negó-
cio, a análise das entidades e dos atribu-
tos definidos para a aplicação como um
todo.
!Modelo Físico: É onde os detalhes
são definidos. Serve como um espelho
de tudo o que está no banco de dados,
permitindo controlar características de
tabelas e colunas (conhecidos no mode-
lo lógico como Entidades e Atributos) de
forma particular para o SGDB utilizado
além de possibilitar a definição de Proce-
dures, Triggers e outros processos.
Criando o modelo lógico
O tipo de modelo que está sendo visu-
alizado encontra-se na Combo situada
logo acima da barra de ferramentas, mos-
trada na Figura 1.
O modelo utilizado inicialmente será o
modelo lógico, pois começando por este
fica mais fácil definir o outro. Isso por-
que, como já foi visto, no modelo lógico
tem-se um melhor controle da aplicação,
sendo possível definir as validações ne-
cessárias, tanto para a regra de negócio
como para a implementação de banco de
dados no modelo físico. Posteriormente,
podem ser criados modelos físicos para
acessar a diferentes bancos de dados a
partir do mesmo modelo lógico.
Será criado um modelo simples, onde
definiremos algumas entidades com seus
respectivos atributos e relacionamentos
mostrando como utilizar alguns dos mui-
tos recursos disponíveis no ErWin para
modelagem de dados. O modelo será
feito com base em um sistema comercial
com as tabelas CLIENTES, VENDEDO-
RES, PRODUTOS, FORNECEDORES,
PEDIDOS E ITENS_PEDIDOS.
Criando as Entidades
Como já visto, as entidades podem
ser criadas através do primeiro objeto da
barra de ferramentas, clicando nesta, ar-
rastando para o modelo e trocando o seu
nome, como mostrado na Figura 3.
Criando os Atributos
Para criar os atributos, basta apenas dar
um duplo clique na entidade. É possível
criar novos atributos, renomear ou ex-
cluir um atributo já existente, como mos-
trado na figura 4. Pode-se, também, ao
lado direito da tela, definir várias caracte-
rísticas do atributo como chave primária
na opção Primary Key ou Requerido na
opção Required.
Figura 2. Barra de ferramenta do ErWin
Entidades
Criar subtipos de entidades existentes
Inserir textos no modelo, como comentário
de entidades, relacionamentos e outros
Relacionamento de cardinalidade um para muitos
Relacionamento de cardinalidade muitos para muitos
Relacionamento de cardinalidade um para um
Auxilio para mudar os atributos de posição ou de entidades
Figura 3. Criação da Entidade Clientes
Figura 4. Editor de Atributos
Figura 5. Editor de Relacionamentos entre entidades
SQL
20 - Magazine
Criando os Relacionamentos
Para definir um tipo de relacionamen-
to, basta escolher um dos três objetos já
mostrados da barra de ferramentas, clicar
na tabela pai e depois na tabela filho. Au-
tomaticamente, o relacionamento esco-
lhido é visualizado. A figura 5 mostra o
editor de Relacionamento e suas funcio-
nalidades.
Ao dar um duplo clique sobre o
relacionamento esta tela é automati-
camente aberta. Nela definimos a car-
dinalidade do relacionamento, assim
como a nulidade dos campos que estão
sendo relacionados.
A figura 6 mostra o modelo total-
mente criado, com suas entidades, atri-
butos e respectivos relacionamentos.
Criando o modelo físico
Após criar todo o modelo lógico é ne-
cessária a definição dos atributos do mo-
delo físico.
Para alternar entre os modelo físico e
lógico basta selecionar na Combo situada
logo acima da barra de ferramentas, mos-
trada na Figura 1.
No modelo físico iremos definir carac-
terísticas das entidades e atributos cria-
dos no modelo lógico de acordo com o
SGDB utilizado. Neste modelo temos
uma visão real das tabelas, colunas, pro-
cedures, triggers e outros objetos do nos-
so banco.
A figura 7 mostra o Editor de Coluna
do modelo físico.
Conforme o observado no modelo fí-
sico, não existem mais Entidades e Atri-
butos, e sim Tabelas e Colunas, nomes
comuns ao banco de dados. O editor de
coluna permite alterar o tipo e tamanho
de cada campo, assim como definir se ele
pode ou não receber valores nulos. Ain-
da pode-se utilizar a aba Comment para
comentar cada campo, assim como cada
tabela.
Criando o banco de dados a partir do
Modelo Físico criado
Terminada a implementação é neces-
sário criar os objetos definidos no ErWin
em um banco de dados. Para isso, é preci-
so fazer o modelo apontar para o SGDB
a ser utilizado acessando-se o menu: Ser-
ver\Target Server. Além da seleção do
SGDB e da versão do mesmo é possível
definir opções referentes ao tipo de da-
dos e a nulidade default para as colunas
definidas no modelo bem como máscara
para nomenclatura automática de índices
e tabelas. Vide Figura 9.
Após as configurações do Target Ser-
ver, basta acessar o menu Tasks\Forward
Engineer/Schema Generation para criar
o banco de dados. Vide Figura 10. Utiliza-
remos um banco criado no Oracle.
Como se pode ver a tela é bem intuiti-
va. Na pasta Summary indicamos os ob-
jetos do nosso modelo ( tabelas, colunas,
índices, triggers, etc.. ) que serão criados
no banco. Ao clicar no botão Generate,
o banco é criado, automaticamente, com
todas as tabelas, campos e relacionamen-
tos demonstrados no modelo físico.
A Figura 11 mostra os scripts com to-
dos objetos gerados no banco de dados a
partir do modelo implementado.
Criando um modelo a partir de um
banco existente
Em muitos casos, o banco de dados já
está totalmente implementado, sendo
necessária a criação do modelo a partir
deste. Este processo chama-se Enge-
nharia Reversa, e é acessado pelo menu
Tasks\Reverse Engineer. A primeira tela
a ser exibida é a ErWin Template Se-
lection, onde escolhe-se a opção Blank
Diagram para criar o modelo do zero.
Ao clicar em Next, depara-se com a tela
Select Taget Server, onde é informado o
tipo de banco de dados a ser utilizado e
a sua versão. Clicando-se mais uma vez
no botão Next, surge a tela Set Options
onde são definidos procedimentos neces-
sários à realização da engenharia reversa.
Vide figura 12.
Figura 6. Modelo lógico com entidades, atributos e relacionamentos.
Figura 7. Editor de Coluna
Figura 8. Modelo Físico com Tabelas, Colunas e Relacionamentos
Figura 9. Target Server – Configuração do Banco de Dados Figura 10. Tela de geração de banco de dados
Modelagem de Dados com ErWin
SQL
Magazine - 21
Deste modo, as opções da engenharia
reversa podem ser definidas como Da-
dos de Tabelas, Colunas, TableSpace,
Procedure, Triggers e outros. Na opção
Table/Views Owned By, foi seleciona-
da a opção Current User para importar
somente os objetos criados pelo usuário
conectado, poderíamos importar objetos
de todos os usuários do banco ou de um
usuário diferente do atualmente conecta-
do desde que o mesmo tenha privilégios
no banco suficientes para isso. Ainda há
possibilidade de se escolher formas de in-
dexação e outras coisas mais.
Clicando-se no botão Next, visualiza-se a tela
de conexão, conforme mostrado na Figura 13.
Esta é a tela que permite fazer a cone-
xão do modelo com o banco de dados
definido em Taget Server, mostrado na
Figura 9. Esta tela também é apresentada
quando o banco é criado a partir do mo-
delo. Nela são informados o Nome de
Usuário, a Senha e a Connect String que
repesenta a instância onde será efetuada
a conexão, neste caso, com o Oracle. Foi
criada uma Connection String, chamada
“Comercio” no TNSNAMES do Oracle
apontando para o banco de dados. Feito
tudo isso, é só clicar no botão Connect
que o modelo é criado automaticamen-
te, conforme mostrado na Figura 14.
Foi possível, a partir de um banco exis-
tente, criar um modelo semelhante ao já
implementado, conforme já mostrado.
No processo de Engenharia Reversa no
ErWin, os modelos lógico e físico são
criados automaticamente.
Criando vários modelos físicos a partir
de um único modelo lógico
Ainda se pode, a partir de um modelo
lógico, criar modelos físicos para acessar
bancos de dados diferentes do Oracle.
Será criado um modelo físico que acesse
um banco de dados Sql Server a partir
do mesmo modelo lógico criado para o
Oracle. Para isso basta acessar o Target
Server, mostrado na figura 9, mudar o
banco para o Sql Server, escolhendo a
versão, definindo os padrões (como já
mostrado) e efetuar os procedimentos
mostrados nas figuras 10 e 11.
A Figura 15 aponta como fica o modelo físi-
co para acessar o banco de dados Sql Server.
Observa-se que alguns tipos de campos
mudaram, como os campos de valores
monetários, que passaram de Number (7,2)
para Money, e os de data, que passaram de
Date para Date/Time. Com isso, conclui-
se que, a partir de um modelo lógico criado,
pode-se criar modelos físicos para acessar
diversos bancos de dados, e este se adapta à
situação de cada um automaticamente.
É importante ressaltar que o modelo
lógico continua o mesmo.
Conclusão
Estes são apenas alguns dos muitos
recursos que o ErWin oferece para mo-
delagem de dados. É possível criar Pro-
cedures, Triggers, Views, alterar o banco
de dados, alterar o modelo a partir de al-
guma alteração feita no banco, criar o di-
cionário de dados, etc. A implementação
de um modelo antes do início do desen-
volvimento de um sistema garante uma
visão ampla e unificada do mesmo, facili-
tando em muito a definição da regras de
negócio, a implementação, manutenção
e análise dos procedimentos, garantindo
inclusive a continuidade do trabalho no
caso de alterações na equipe de desenvol-
vimento com pouco ou nenhum retraba-
lho uma vez que o modelo disponibiliza
de forma clara e objetiva uma documen-
tação de toda infra-estrutura do sistema.
Figura 11. Script com o código de criação das tabelas de-
fnidas no modelo.
Figura 12. Tela de opções da Engenharia
Figura 13. Tela de Conexão com o Oracle.
Figura 15. Modelo Físico para acessar o Sql server.
Figura 14. Modelo criado apartir de um banco de dados existente usando a
Engenharia Reversa
SQLAutor
Cleilson Santos é Analista de Sistemas, trabalha no
Projeto SEP (Sistema de Engenharia de Poço) e SIRR
(Sistema de Reserva e Reservatório) na Petrobrás.
Pode ser contatado pelo e-mail cleilsonsantos@uol.com.br
UML
Introdução à
!"# Gustavo Viegas
o !naI dos anos 80 e início dos anos 90, tínhamos muitos con-
"itos de de!nições e nomencIaturas na área de modeIagem. A es-
coIha para utiIização de um determinado padrão era de!nido mais
peIo "gosto¨ pessoaI do que por fatores técnicos oferecidos. Então,
os três mais respeitados nomes nesse campo, cada quaI com seu
conceito e impIementação de modeIo, Ivar Jacobson (OOSE - Object
Oriented Software Engineering), Grady Booch (The Booch Method)
and James Rumbaugh (OMT -Object ModeIing Technique) decidi-
ram por !m aos debates e trabaIhar juntos na de!nição de um mod-
eIo único que veio a ser a UML.
N
A UML permite que você “desenhe”
uma “planta” do seu sistema. A compara-
ção ideal é a de um construtor que vai rea-
lizar um projeto sem antes ter toda a planta
que defina estrutura a ser construída. A ex-
periência do construtor garante, até certo
ponto, o sucesso do projeto. Mas, com
certeza, uma vez feito o planejamento, o
“cálculo estrutural”, o desenho da planta, a
garantia de sucesso antes, durante e depois
da efetivação da construção é incompara-
velmente maior. O mesmo acontece com
um projeto de software. A experiência
do desenvolvedor ou analista, não pode
substituir a necessidade de um projeto que
defina uma “planta” da solução como um
todo. Esta “planta” garante, em todas as
fases do projeto, seja na definição, desen-
volvimento, homologação, distribuição,
utilização e manutenção do mesmo, uma
maior clareza e objetividade para execu-
ção de cada ação, e, com certeza, quanto
maior a solução, maior a necessidade de
um projeto definido adequadamente. Des-
ta forma, a UML é uma linguagem padrão
para visualização, especificação, constru-
ção e documentação de um aplicativo ou
projeto de software, e objetiva aumentar a
produtividade, otimizar as etapas que en-
volvem o desenvolvimento de um sistema,
aumentando assim a qualidade do produto
a ser implementado. Ela independe da fer-
ramenta em que o aplicativo será desenvol-
vido. A idéia e prover uma visão lógica de
todo o processo de forma a facilitar a imple-
mentação física do mesmo.
A UML disponibiliza, através de concei-
tos, objetos, símbolos e diagramas, uma
forma simples, mas objetiva e funcional, de
documentação e entendimento de um sis-
tema. Você pode utilizar os diagramas e ar-
quivos que compõe um modelo UML para
o desenvolvimento, apresentação, treina-
mento e manutenção durante todo o ciclo
de vida da sua aplicação. Ela é mais com-
pleta que outras metodologias empregadas
para a modelagem de dados pois, tem em
seu conjunto todos os recursos necessários
para suprir as necessidade de todas as etapas
que compõe um projeto, desde a definição,
implementação, criação do modelo de ban-
co de dados, distribuição, enfim, proporcio-
nando sem qualquer outra ferramenta ou
metodologia adicional, um total controle
IIntrodução à UML
SQL
Magazine - 23
do projeto.
A UML implementa uma modelagem
com uma visão orientada a objetos. Atra-
vés dela podemos definir as classes que
compõe a nossa solução, seu atributos,
métodos e como elas interagem entre si.
Apesar da UML ter como base a orien-
tação a objetos, não significa que a fer-
ramenta e a linguagem utilizada para a
implementação do modelo seja também
orientada a objetos, embora seja reco-
mendável. Este artigo não irá explorar os
conceitos de orientação a objetos, e sim
a implementação de um modelo UML
simples, para início da documentação de
um sistema, utilizando dois diagramas
implementados pela UML que são o
“Diagrama de Casos e Uso” e o “Diagra-
ma de Classes”. Os diagramas têm como
objetivo representar, através de um con-
junto de elementos, como o sistema irá
funcionar e como cada peça do sistema
ira trabalhar e interagir com as outras.
Outra vantagem vem da facilidade de lei-
tura dos diagramas que compõe a UML,
além da facilidade de confeccioná-los,
pois existem inúmeras ferramentas para
modelagem de dados orientados a ob-
jetos (ferramentas Case), dentre elas o
Rational Rose, o Model Maker, e o Posei-
dom UML. Além dos diagramas citados
a UML disponibiliza outros diagramas,
dentre os quais podemos citar o Diagra-
ma de Objetos, Diagrama de Seqüência,
Diagrama de Colaboração, Diagrama de
Estado, Diagrama de Atividade e Diagra-
ma de Componentes.
Entendendo UML a partir de um ex-
emplo prático
Utilizaremos o Poseidon UML para im-
plementar o modelo do exemplo. O Po-
seidon UML é uma ferramenta case que
suporta os principais diagramas UML e é
desenvolvido em Java. Tem algumas fa-
cilidades no que se refere a interação com
o Java podendo, a partir de um modelo
gerar o código Java das classes definidas
no mesmo e também suporta a Enge-
nharia Reversa, que é gerar o modelo a
partir das classes implementadas. O Po-
seidon tem sua versão free e pode ser bai-
xado em www.gentleware.com.
O modelo aqui proposto começa a ser
implementado a partir de um problema
real que é a necessidade de um cliente. O
problema proposto é o seguinte:
“Desenvolver um sistema para um
caixa eletrônico onde é permitido a um
cliente realizar quatro tipos de opera-
ções: a de consulta de saldo, solicitação
de extrato, depósito e saque. Esse mes-
mo caixa eletrônico deve ser abastecido
de dinheiro e ter os depósitos recolhidos
por um funcionário do banco”
Para definição do modelo do nosso sis-
tema, iremos implementar primeiro um
Diagrama de Casos de Uso ou Use Cases.
Os objetivos principais de um diagrama
de Casos de Uso são:
• Descrever os requisitos funcionais do
sistema de maneira uniforme para usuá-
rios e desenvolvedores;
• Descrever de forma clara e consisten-
te as responsabilidades a serem cumpri-
das pelo sistema, formando a base para a
fase de projeto;
• Oferecer as possíveis situações do mundo
real para a fase de testes do sistema.
Os elementos básicos de um diagrama de
caso de uso são: ator, caso de uso, interação
e sistema, todos ilustrados na figura 1.
Um ator é uma entidade externa ao
sistema que de alguma forma participa
de um caso de uso. Um ator pode ser
um ser humano, máquinas, dispositivos,
ou outros sistemas. Atores típicos são
cliente, usuário, gerente, computador,
impressora, etc. Os atores representam
um papel e iniciam um caso de uso que
após executado, retorna um valor para o
ator. Um caso de uso especifica um ser-
viço que será executado ao usuário e é
composto por um ou mais cenários. Um
cenário é uma narrativa de uma parte do
comportamento global do sistema. Para
o problema proposto, o Diagrama de Ca-
sos de Uso pode ser implementado como
mostrado na figura 2.
No Diagrama de Casos de Uso imple-
mentado o sistema é o Caixa Eletrônico,
os atores representam o Cliente e o Fun-
cionário do banco. O Cliente interage
com os Casos de Uso consulta de saldo,
solicitação de extrato, depósito e saque e
o Funcionário interage com os Casos de
Uso Abastece de dinheiro e Recolher en-
velopes de depósitos.
Para melhor entendimento do Diagra-
ma de Casos de Uso é necessária a descrição
textual do fluxo do Caso de Uso (principal
e alternativo) e do Cenário ou dos Cenários
que compõe cada Caso de Uso. Iremos
descrever o Use Case Solicitação de Extrato
bem como o Cenário que o compõe.
Após a descrição textual de todos os
Casos de Uso e respectivos Cenário, nos-
sa documentação envolvendo o Diagra-
ma de Casos de Uso está completa.
O segundo diagrama a ser utilizado
para solução do problema proposto é
o Diagrama de Classes. Este diagrama,
contém as classes que caracterizam os
objetos do nosso sistema. As classes são
extraídas a partir da análise do Diagrama
de Casos de Uso e representam os com-
ponentes de interação do nosso sistema e
Figura2
SQL
24 - Magazine
como eles se relacionam. Vamos implementar um Diagrama
de Classe, a partir do Diagrama de Casos e Uso implementado,
com a definição das classes Cliente, ContaBancaria e Lança-
mentos da Conta. ( Vide Figura 4 )
Uma classe é representada por um retângulo sólido com três
partes: a primeira para o nome da classe; outra para os atributos
da classe ( que podem ser vistos como características da clas-
se); e a terceira para a declaração das operações definidas para a
classe. A Figura 3 mostra a notação UML para classes.
Através da classe Cliente implementada no diagrama da fi-
gura 4, nós definimos as características do nosso cliente (neste
caso um Identificador e um Nome que representam os atribu-
tos da classe), seu relacionamento com a classe ContaBancaria
que é de 1 para muitos ( isto representa a cardinalidade do re-
lacionamento ) e definimos uma operação realizada pela classe
que é ObterContaBancaria(). A mesma análise deve ser feita
para a classe ContaBancaria e LancamentoConta.
Com esse diagrama, já podemos identificar elementos que
existirão em nosso sistema, suas carcterísticas e operações. Es-
sas definições estão contidas nas classes. Essas classes tornam-se
reais em nosso sistema a quando são manipuladas por ele e, a
partir daí, são conhecidas como objetos, pois suas características
passam a “ter um valor” e elas começam a interagir com outros
objetos das classes relacionadas.
Conclusão
A UML se mostra como parte essencial no “ciclo de vida”
de uma aplicação. Foi mostrado, utilizando apenas dois dia-
gramas, toda a funcionalidade operacional de um sistema bem
como a definição de elementos internos referentes ao desen-
volvimento do mesmo. Esses dois diagramas fazem parte da
documentação do sistema, e podem ser utilizados para uma
apresentação da solução para o requisitante antes da imple-
mentação da mesma, visualização dos processos que o sistema
irá disponibilizar, definição de elementos inerentes ao desen-
volvimento como estrutura de telas, procedimentos operacio-
nais, referência para criação de objetos de persistência em um
banco de dados, etc.
Existem outros elementos a explorar, outros diagramas, ou-
tros tipos de relacionamentos e documentação, mas este foi
um passo inicial para conhecer todos os recursos que a UML
disponibiliza e aumentar a qualidade do desenvolvimento de
nossas aplicações.
Caso de Uso “Solicitação de Extrato”
1) Descrição textual do fluxo principal do Use Case Solicita-
ção de Extrato
Este Caso de Uso inicia-se quando o Cliente escolhe a opção Extrato após passar o cartão no caixa
eletrônico e ter a sua conta validada. Após a validação da conta o sistema pede ao cliente para escolher
dentre as opções de saldo:
Extrato Rápido - O subfluxo A1 (Imprimir Extrato Rápido) é executado.
Extrato no Período - O subfluxo A2 (Imprimir Extrato no Período) é executado.
Sair - O Caso de Uso é encerrado, o sistema volta a tela principal e solicita que o cliente passe o
cartão.
2) Descrição textual dos Subfluxos alternativos associados a
este use case
A1 - Imprimir Extrato Rápido
O sistema solicita que o cliente entre com a senha para autorizar a impressão do extrato (o sub-
fluxo B1 - Solicitar e Validar de senha alfabética - é executado). Caso a senha seja validada a conta
do cliente é consultada e o extrato é impresso (o subfluxo B2 – Imprimir Extrato - É executado). O
sistema volta a tela principal e solicita que o cliente passe o cartão.
A2 - Imprimir Extrato no período
O Sistema solicita que o cliente informe a data inicial e final pra impressão do extrato. Em seguida
O sistema solicita que o cliente entre com a senha para autorizar a impressão do extrato (o sub-
fluxo B1 - Solicitar e Validar de senha alfabética - é executado). Caso a senha seja validada a conta
do cliente é consultada de acordo com o período e o extrato é impresso (o subfluxo B2 – Imprimir
Extrato - É executado). O sistema volta a tela principal e solicita que o cliente passe o cartão.
B1- Solicitar e Validar de senha alfabética
O sistema solicita que a senha do cartão seja digitada. Consulta a conta do cliente validando a
senha digitada. Caso a senha não seja válida o sistema informa na tela e pede mais uma tentativa.
O sistema verifica a quantidade de erros de validação de senha ocorridos no dia e informa que
após 3 tentativas erradas o cartão do cliente será bloqueado e informa o número de tentativas
que o cliente ainda dispõe. O Cliente pode sair da operação e voltar para a tela inicial, ou tentar
novamente. Caso a senha seja válida, a operação prossegue. Caso contrário, após três tentativas o
cartão do cliente é bloqueado.
B2- Imprimir Extrato
O sistema verifica se a impressora do caixa eletrônico está ativa e se a mesma possui papel. Caso
apresente um dos problemas citados, o sistema mostra uma mensagem solicitando que o cliente
realiza a operação em outro caixa eletrônico e volta para a tela inicial e avisa do erro sempre que
uma operação que envolva impressão for solicitada. Caso contrário, o conteúdo solicitado para
impressão é impresso.
3) Cenário Primário
José dirige-se ao caixa eletrônico e passa o cartão na máquina. O Sistema, após validar a conta
exibe as opções disponíveis. José seleciona a opção de Solicitação de Extrato. Em seguida
José seleciona a opção de Extrato no Período. Informa a data inicial e final. O Sistema solicita a
senha a José. Após José digitar a senha e confirmar a operação, o Sistema valida a senha, consulta
a conta de José e imprime o extrato de movimentação da conta no período selecionado.
4) Cenário Secundário
O Sistema, ao verificar os requisitos para impressão, retornou que a impressora estava sem papel.
José, após ser informado do problema pelo sistema, dirigi-se a outro caixa eletrônico e inicia
novamente a operação.
Figura4
Figura3
SQLAutor
Gustavo Viegas é editor da revista SQL Magazine . Pode
ser contactado pelo email: gustavo@sqlmagazine.com.br
IIntrodução à UML
SQL
Magazine - 25
ANUNCIO
DeIphi, VB.Net e Java
Como conectar Front-Ends
!"# Pedro Henrique
PauIo Correia
Gustavo Viegas
tuaImente não podemos negar que deparamos diariamente
com diversas formas de armazenamento e manipuIação de dados.
Isto independe do Iugar que estamos ou do que fazemos. Se vamos
a um mercado, temos computadores que registram as vendas, má-
quinas de consuIta de preços de produtos, terminais para saques
eIetrônicos, máquinas de cartão de crédito, entre outros. É comum
encontrarmos em diversas áreas da nossa vida a presença de má-
quinas e apIicativos que, de aIguma forma, Iidam com dados arma-
zenados, dinamizando e faciIitando seu acesso.
A
É comum encontrar aplicações que inte-
ragem com algum tipo de informação ou
conjunto de informações. Independente
da linguagem que foram desenvolvidas,
elas visam garantir aos seus usuários segu-
rança, clareza e objetividade na recupera-
ção e manutenção do seu conteúdo. Mas
antes de falarmos dos sistemas que fazem
o usuário interagir diretamente com os
dados, visualizando-os e manipulando-os
de forma coerente e usual, é importante
termos conhecimento prévio de que as
informações manipuladas por eles, em sua
maioria, estão armazenadas em um Siste-
ma Gerenciador de Banco de Dados, ou
simplesmente SGBD.
Este SGBD deve garantir que os dados
estejam armazenados de forma organiza-
da, permitindo atualizações, inclusões e ex-
clusões e garantindo toda segurança e con-
sistência. Por definição temos que SGDB é
“um software (ou conjunto de Softwares)
responsável pelo gerenciamento (armaze-
namento e recuperação) dos dados no ban-
co de dados”.
Um SGBD pode gerenciar um ou mais
bancos de dados. Mas como definir um
banco de dados? Se nós temos um arquivo
contendo a tabela de preços dos produtos
de uma indústria, nós temos um banco de
dados? Conceitualmente, uma banco de da-
dos tem de representar uma coleção de da-
dos organizados de forma coerente e com
um significado real. Uma tabela de preços,
por si só, não tem um significado real sem
que existam outras tabelas que interajam
com ela. Se nós temos uma tabela de pre-
ços, uma tabela de clientes, uma tabela de
pedidos e uma tabela de produtos, já po-
demos montar um quadro que traduz um
processo de atendimento a clientes, venda e
controle de estoque, ou seja, uma situação
real armazenada num banco de dados.
A forma mais comum de intera-
ção entre usuário e banco de dados ocor-
re através de sistemas específicos, que por
sua vez acessam o volume de informações
geralmente através da linguagem SQL
(Strutured Query Language), padrão entre
os SGBD´s. A ferramenta de desenvolvi-
Conectando Front-Ends com Delphi, VB.Net e Java
SQL
Magazine - 27
mento utilizada para a implementação
desses sistemas é tão importante quanto
o SGBD que gerencia as informações a
serem acessadas por eles. Iremos analisar
três grandes ambientes para desenvolvi-
mento: Delphi, VB .Net e Java.
Por que o Delphi?
O Borland Delphi é uma grande opção
para o desenvolvimento de sistemas em
que é necessário utilizar servidores de
Banco de Dados SQL. Inicialmente, é im-
portante frisar que o Delphi possui um
suporte bem amplo aos Servidores SQL
encontrados hoje no mercado, através
da implementação de diversos drivers e
engines. Alguns são da própria Borland,
como o DbExpress e a obsoleta BDE.
Outros são de terceiros, como o ADO
(ActiveX Data Objects) da Microsoft. Um
driver geralmente é uma dll, um conjun-
to de funções utilizadas para acesso e ma-
nipulação de dados em um banco. Um
engine é um aplicativo que faz a interfa-
ce ou tradução das mensagens enviadas
NOTA
Para obter mais informações sobre o
ADO, acesse o Microsoft Universal Data
Access no endereço: http://www.micro-
soft.com/data. Lá é possível baixar a ver-
são mais recente do MDAC (conjunto de
componentes que, entre outros recursos,
inclui o ADO).
pela aplicação para o driver, de forma
que seja transparente para a aplicação o
tipo de driver que está sendo utilizado
para acesso ao banco. Uma das grandes
novidades do novo Delphi é o suporte
através da dbExpress ao servidor Micro-
soft SQL-Server 2000.
Neste artigo usaremos o DbExpress
e o ADO como engines de acesso e o
banco de dados será o Northwind do Mi-
crosoft SQL-Server 2000. O ADO, sendo
desenvolvido pela Microsoft, se caracte-
riza como uma ótima opção para cone-
xão ao MSSQL Server, além de facilitar a
distribuição da aplicação, uma vez que é
suportado nativamente por diversas ver-
sões do sistema operacional Microsoft
Windows (Win 98 SE, Win ME/2000
Professional, Win XP Home/Professio-
nal). Exemplificaremos o mesmo acesso
utilizando o DBExpress. Iremos verificar
que as diferenças de programação de um
Engine de acesso para outro no Delphi
são poucas. O que muda mais é o deploy
(distribuição) e a performance.
Figura1. Uma nova aplicação no Delphi
Figura2. Componentes SQL Connectiom
Figura3. Confguração do SQL Connection
Figura4. SQLConnection confgurado
Exemplo em Borland Delphi 7
Primeiro iremos exemplificar a cone-
xão utilizando DbExpress.
Passo 1 – Iniciando uma nova aplicação.
Clique menu File / New / Application
como mostra a figura 1
Passo 2 – Configurando a conexão
Adicione ao formulário form1 o com-
ponente SQLConnection, localizado na
paleta de componentes DbExpress. Em
seguida, clique com o botão inverso do
SQL
28 - Magazine
mouse no componente e selecione Edit
Connection Properties, como mostra a
figura 2.
Será exibida uma caixa de diálogo
para configuração das propriedades de
conexão com o banco de dados. Vamos
utilizar a conexão denominada MSSQL-
Connection (poderíamos adicionar uma
nova conexão clicando no botão “+”,
selecionando o driver MSSQL e dando
um nome para a mesma) e configurar
em Connection Settings os demais parâ-
metros:
HostName – Nome ou IP da máquina servidora
Database - Nome do banco de dados no SQL Server
User_Name- Nome do usuário
Password - Senha
Para testar a conexão clique no botão
“Test Connection” (último da barra de fer-
ramentas com um ícone de engrenagem).
A figura 3 mostra a janela preenchida.
A conexão é aberta através da pro-
priedade Connected do componente
SQLConnection (as propriedades são
acessadas através do Object Inspector).
Podemos alterar esse valor em tempo de
design ou tempo de execução. Altere a
propriedade LoginPrompt para false para
desabilitar a caixa de diálogo de login do
banco. Neste caso, o usuário e senha já
estão sendo passados diretamente pelo apli-
cativo. Observe as alterações na figura 4.
Passo 3 – Acessando os dados
Acessaremos a tabela Employees no
banco tomado como exemplo. Para isso,
insira um componente TSQLQuery, lo-
calizado também na paleta DBExpress.
Devemos conectar o SQLQuery ao
objeto SQLConnection. Selecione a pro-
priedade SQLConnection do SQLQuery
e aponte para SQLConnection1. Em
seguida definimos o código da consulta
SQL através da propriedade XXXX. Para
executar a consulta em tempo de proje-
to basta alterar a propriedade Active do
componente para true. Vide figura 5.
Passo 4 – Manipulando os dados e exe-
cutando a aplicação
Para permitir que o usuário manipule
os dados selecionados, utilizaremos um
componente DbGrid. Este componente
está localizado na paleta Data Controls.
Uma vez adicionado ao formulário é ne-
cessário que esse componente acesse os
dados retornados pelo SQLQuery confi-
gurado no passo 3. Para isso, utilizaremos
três outros componentes: ClientDataSet,
DataSetProvider e DataSource que estão
localizados na palheta Data Access. Esses
componentes devem ser adicionados ao
formulário e configurados da seguinte
forma:
DataSetProvider - A propriedade DataSet
aponta para o SQLQuery confgurado no passo 3.
ClientDataSet – A propriedade ProviderName
aponto para o objeto DataSetProvider.
DataSource – A propriedade DataSet aponta
para o ClientDataSet confgurado no passo an-
terior.
Por fim, para que os dados sejam exi-
bidos no grid adicionado ao formulário,
devemos apontar a propriedade Data-
Source do grid para o objeto DataSour-
ce1, alterarando a propriedade Active do
ClientDataSet para true. Dessa forma os
dados serão exibidos no grid, estando
prontos para serem manipulados confor-
me mostra a figura 6.
O ClientDataSet e o DataSetProvider
fazem parte de uma implementação da
Borland denominada DataSnap (antigo
MIDAS) que disponibiliza para o desen-
volvedor o que chamamos de “DataSet
Desconectado”. A partir de um DataSet
Figura5. Confgurando o SQLQuery
Figura6. Projeto com DBExpress fnalizado
Figura7. Componente ADOConnection
Conectando Front-Ends com Delphi, VB.Net e Java
SQL
Magazine - 29
qualquer, que no exemplo foi o SQL-
Query, o DataSetProvider monta um
conjunto de dados e envia para o Clien-
tDataSet. Feito isso, o SQLQuery, que é
o DataSet de origem, não é mais utiliza-
do, bem como a conexão com o banco,
e os dados podem ser manipulados sem
sobrecarga da rede e conseqüente degra-
dação da performance da aplicação. Após
o término da manipulação dos dados, é
necessário a execução do método Ap-
plyUpdates do ClientDataSet, para que
sejam aplicados no banco. No exemplo,
o evento “OnClick” do botão “Aplica Al-
terações” deve ser implementado com o
seguinte código:
procedure TForm1.BitBtn1Click(Sender: TObject);
begin
ClientDataSet1.ApplyUpdates(0);
end;
O parâmetro do método indica o nú-
mero de erros que serão desconsidera-
dos antes de ser gerada uma exceção na
aplicação. Neste caso o parâmetro indica
que não podem ocorrer erros no proces-
samento.
Para cancelar as alterações efetuadas é
necessário a execução do método Cance-
lUpdates. Neste caso, o evento “OnClick”
do botão “Cancela Alterações” deve ser
implementado com o seguinte código:
procedure TForm1.BitBtn2Click(Sender: TObject);
begin
ClientDataSet1.CancelUpdates;
end;
Outra grande vantagem do Client
DataSet e do DataSetProvider é a facili-
dade que eles disponibilizam para que, se
for necessário, seja efetuada uma troca
do engine de acesso ao banco. O mesmo
programa feito com DBExpress será uti-
lizado para exemplificar o acesso a dados
utilizando ADO.
ACESSO AO SQL SERVER COM ADO
Passo 1 – Trocando o componente de
conexão com o banco de dados.
Em primero lugar os componentes
SQLConnection e SQLQuery devem ser
Figura8. Confgurando ADOConnection
excluídos do formulário para que pos-
samos adicionar os componentes Ado-
Connection e AdoQuery localizados na
paleta ADO.
No ADO o componente responsável
pela conexão é o AdoConnection. Após
adicioná-lo no formulário devemos con-
figurá-lo através do acesso ao menu Edit
ConnectionString, conforme mostra a
figura 7.
A tela exibida por esta opção permite
que utilizemos um Data Link File ou
uma Connection String (figura 8). Utili-
zaremos esta última de forma a mostrar
todo o processo de configuração da cone-
xão. A vantagem de usar Data Link File
é que os parâmetros ficam armazenados
em um arquivo externo, possibilitando
alterações sem a necessidade de “recom-
pilação” do aplicativo.
Para montar a Connection String acessa-
remos o assistente através do botão build
da caixa de diálogo exibida (figura 8).
Em primeiro lugar devemos confi-
gurar o Provider que irá gerenciar a
conexão com o banco de dados. Esco-
lheremos o “Microsoft OLE DB Pro-
vider for SQL Server” (figura 9). Após
esta seleção devemos informar na pasta
Connection os parâmetros para que a
conexão seja efetuada. Indique o nome
do servidor de banco de dados em
“1. Select or enter a server name”, os
dados para login em “2. Enter the infor-
matino to log on to the server” e o banco
de dados a ser acessado em “3. Select the
database on the serever”. É importante
que a opção “Allow saving password”
esteja marcada para evitar erros na cone-
xão uma vez que os parâmetros de login
(usuário e senha) já estão definidos. En-
cerradas as configurações podemos testar
a conexão através do botão “Test Connec-
tion” e em seguida encerrar o assistente
através do botão ok (vide figura 10).
Passo 2 – Adicionando o componente
para acesso aos dados
No ADO o componente a ser utilizado
para substituir o SQLQuery é o ADO-
Query que está na paleta ADO. Uma vez
adicionado ao formulário, altere a pro-
priedade Connection apotando-a para
o objeto AdoConnection1. Altere a pro-
priedade SQL de forma análoga ao passo
3 do exemplo com DbExpress.
Feito isso, basta alterar a propriedade
DataSet do DataSetProvider apontando
para o ADOQuery configurado anterior-
mente. Altere a propriedade Active do
Figura9. Escolhendo o Provider Figura10. Montando o ConnectionString
SQL
30 - Magazine
ClientDataSet para true e pronto! (Vide
figura 11).
Por que o VisualBasic.Net?
O Visual Basic agora faz parte de um
novo conjunto de ferramentas para de-
senvolvimento de aplicações: a estratégia
.Net. O .Net é uma nova plataforma da
Microsoft, multi-linguagem, totalmente
formulada para lidar com XML e Web
Services e voltada para aplicações multi-
dispositivos. Nesta plataforma, o ADO
também ganhou uma nova implemen-
tação chamada ADO.Net e é este engine
que iremos focalizar.
O novo ADO.Net foi desenvolvido
para ser uma versão bem diferente das
anteriores, focando a completa compre-
ensão do XML, o uso de DataSets des-
conectados e uma implementação mais
leve para a Web.
Exemplo em Microsoft VisualStudio.
Net (utilizando VB.Net)
Inicie o VisualStudio.Net e clique no
menu File|New|Project. Na caixa de
diálogo, clique em Visual Basic Projects
e escolha Windows Applications na caixa
Templates. Digite o nome do projeto e
clique em OK.
Após estes passos o VisualStudio.Net
irá preparar o ambiente para o desenvol-
vimento de um projeto Visual Basic.
No ADO.Net, assim como nas versões
anteriores do ADO, existe o objeto Con-
nection que permite a conexão com o
Banco de Dados. Esse objeto, atualmen-
te, não é um objeto único para qualquer
tipo de conexão como antes. Agora ele é
implementado em diversas classes que
utilizam a interface IdbConnection em
comum. Usaremos o SQLConnection,
um componente Connection implemen-
tado para se conectar ao MSSQL-Server
versão 7x e superiores, para acessar o
banco Northwind que acompanha o
MSSQL-Server 2000.
Na ToolBox no lado esquerdo da apli-
cação clique na guia “Data” e insira no
formulário um componente SQLCon-
nection. Na caixa Properties clique na
propriedade ConnectionString e selecio-
ne “New Connection...” (Figura4). Será
exibida a janela padrão de configuração
de ConnectionString do ADO. O exem-
plo no Delphi 7 utiliza a mesma janela e
explica como configurar a ConnectionS-
tring para acessar o banco Northwind
em detalhes.
Configurado o componente de cone-
xão é necessário informar de onde serão
requisitados os dados. Esta requisição é
feita por um objeto Command. Porém,
assim como o objeto Connection, o
Command possui diversas versões que
variam de Provider para Provider. Por
exemplo, para acessar o SQL-Server, o
ADO.Net possui um Provider específi-
co que, para ser utilizado, precisa de um
SQLConnection pertencente ao names-
pace System.Data.SqlClient (implemen-
tação que aproveita recursos específicos
do MS-SQL) e para se executar uma
consulta no Banco deve-se utilizar um
objeto SQLCommand, ou mesmo um
SQLDataAdapter, também do mesmo
namespace (ou seja, também especifico
para o MS-SQL). O que implica que é ne-
cessário importar este namespace com o
comando “Imports”.
Na guia Data da ToolBox clique no
componente SQLDataAdapter e insira-o
no formulário. Automaticamente o Visual
Studio irá apresentar o “Data Adapter Con-
figuration Wizard”, que permite configu- Figura11. Projeto com ADO fnalizado
Figura12. Caixa de Diálogo de escolha do projeto no VisualStudio.NET
Figura13. SQLConnection Wizard
Conectando Front-Ends com Delphi, VB.Net e Java
SQL
Magazine - 31
rar de forma simples o SQLDataAdapter.
Este componente tem como função facili-
tar o gerenciamento das requisições com o
Servidor em relação ao DataSet (conjunto
de registros), armazenando consultas SQL
através das propriedades: DeleteCom-
mand, InsertCommand, SelectCommand
e UpdateCommand que permitem ao
desenvolvedor especificar comandos SQL
para controlar de forma otimizada e pa-
dronizada pelo ADO.Net os conjuntos de
registros armazenados no Servidor.
Utilizando o Wizard é possível confi-
gurar uma consulta simples e entender
como se utiliza o SQLDataAdapter no
VisualStudio.Net. Na primeira tela clique
no botão “Next”, onde será exibido o
passo: “Choose Your Data Connection”.
Esta tela permite configurar que conexão
irá requisitar os dados. Na caixa Combo
pode-se especificar a conexão que já foi
criada pelo componente SQLConnec-
tion inserido anteriormente. Após clique
no botão “Next”. Em “Choose a Query
Type” especificamos como os dados se-
rão requisitados. Abaixo, segue uma pe-
quena descrição de cada opção:
- Use SQL statements: Permite especi-
ficar uma Query SQL que faça o retorno
dos dados. O próprio Wizard irá gerar os
comandos Delete, Update e Insert basea-
dos nesta Query.
- Create New Stored Procedures: Per-
mite criar novos procedimentos armaze-
nados a partir de uma Query SQL para os
comandos Insert, Update e Delete.
- Use Existing Stored Procedures: Per-
mite especificar quais serão os procedi-
mentos armazenados que farão os co-
mandos: Select, Insert, Update e Delete
do conjunto de registros específicos para
cada situação.
Será utilizada a opção “Use SQL state-
ments” e a configuração da Query com o
comando SQL abaixo:
SELECT orderid, customerid, orderdate,
shippeddate, shipname, shipregion, shipcountry
FROM Orders
Conforme visto no exemplo acima,
será requisitado ao banco de dados ape-
nas alguns campos da tabela de pedidos.
Este comando SELECT será inserido na
propriedade SelectCommand do SQL-
DataAdapter.
Clique em “Next”. Serão gerados no
Wizard os comandos SQL de acordo
com o SELECT para configurar o com-
ponente automaticamente. Para finali-
zar, clique no botão “Finish”.
Pronto! Foi criado um componente
SQLDataAdapter que permite fazer con-
sultas e, ainda dentro do padrão ADO.
Net, modificar os dados selecionado,
através da SQL gerada pelo Wizard.
Os controles Data-Aware do .Net para
exibir dados necessitam que estes sejam
recebidos de um DataSet. Para gerar um
DataSet, clique com o botão direito na
figura do SQLDataAdapter no Form De-
signer e selecione “Generate DataSet”.
Será visualizada uma caixa de diálogo
onde, pressionando-se o botão “OK”, irá
aparecer o componente DataSet.
Em seguida insira um controle Data-
Grid. Linke a propriedade DataSource ao
DataSet recém-gerado e DataMember a
tabela Orders, visualizando os dados no
grid da mesma forma que no Delphi.
Por que o Java?
O Java tem demonstrado seu poder
com relação ao mundo multi-platafor-
ma. Cada vez mais conhecido no Brasil,
muito se tem produzido com Java. Um
ponto forte do Java é o fato de grandes
empresas estarem investindo nele, como
as gigantes Oracle e IBM. Uma das formas
de conexão de uma aplicação Java com um
banco de dados é através da API JDBC.
O JDBC, Java Database Connectivi-
ty, é uma API Java para conexão com
SGDB´s diversos e execução de expres-
sões SQL. Sendo mais específico, JDBC
é um conjunto de classes e interfaces que
permitem acesso a bases de dados rela-
cionais de maneira uniforme, numa solu-
ção similar ao ODBC. Existem inúmeras
implementações de drivers de bancos de
dados compatíveis com JDBC que se en-
quadram em quatro categorias de solu-
ções, definidas pela JavaSoft:
Tipo 1 - Ponte JDBC / ODBC
A ponte JDBC / ODBC foi desenvol-
vida em conjunto pela JavaSoft e a In-
tersolv, de modo a aproveitar a grande
quantidade de drivers ODBC que já exis-
tem instalados nas máquinas. Aplicação
Java faz uma chamada ao JDBC que por
sua vez faz essa chamada ao ODBC e
este à API de acesso nativa do banco.
Tipo 2 - Driver Java Parcial
+ API Nativa
Nesta solução o driver ODBC é
eliminado e o driver JDBC conver-
te as chamadas JDBC em chama-
das diretas à API nativa do banco.
Assim como os drivers do Tipo 1
é necessária a instalação de ¨apli-
cações cliente¨ do banco de dados
na máquina onde está sendo exe-
cutado o aplicativo.
Tipo 3 - Driver 100% Java +
Protocolo de Rede (arquitetu-
ra em 3 camadas)
Nesta configuração o driver JDBC con-
verte as chamadas JDBC em um protoco-
lo de rede independente (independente
do banco de dados). Estas chamadas são
convertidas, então, em chamadas à API
nativa do banco por um servidor inter-
mediário (middleware). Essa arquitetura
na verdade consiste de três camadas.
Tipo 4 - Driver 100% Java:
Nesta solução o driver converte as cha-
madas JDBC diretamente para o protoco-
lo de rede utilizado pelo banco de dados.
Escritos somente em Java, estes drivers
não necessitam de ODBC nem de API
nativa, gerando um enorme ganho de
desempenho e permitindo o desenvolvi-
mento de aplicações 100% Java.
Exemplo em Java
Utilizaremos para acessar o mesmo
banco de dados dos exemplos em Delphi
e VB .Net (NorthWind do SQL Server)
um Driver JDBC do tipo 4 denominado
Microsoft SQL Server 2000 JDBC Dri-
ver, que pode ser baixado no em http://
msdn.microsoft.com/downloads/de-
fault.asp?URL=/downloads/sample.
asp?url=/MSDN-FILES/027/001/779/
msdncompositedoc.xml.
Para exemplificar a conexão em Java,
utilizaremos um “console application”
onde será mostrado além da conexão a
execução de um comando SELECT e o
display dos dados retornados na tela. As
classes utilizadas e os procedimentos se-
rão explicados em seguida. Vale a pena
ressaltar que este exemplo mostra uma
das formas de acesso e manipulação de
dados em Java (listagem1.).
NOTA
Nesta parte do Wizard pode-se utilizar
o Query Builder do VisualStudio.Net,
uma ferramenta muito interessante
para desenvolver consultas SQL.
SQL
32 - Magazine
Inicialmente é declarado um objeto
que irá representar a conexão com o ban-
co de dados, neste exemplo chamado de
conn, do tipo Connection. Voltaremos a
falar nele adiante. Em seguida é executa-
da a seguinte chamada:
DriverManager.registerDriver(
new com.microsoft.jdbc.sqlserver.
SQLServerDriver());

O DriverManager é uma classe que
gerencia os drivers registrados no JDBC.
Este registro é feito através da chamada
ao método estático registerDriver. A
partir desse momento, a instância do dri-
ver passado como parâmetro passa a ser
mantida pelo DriverManager e o driver
fica disponível para utilização pela aplica-
ção Java.
A próxima linha abre uma co-
nexão com o banco de dados, que é atri-
buída para o objeto conn para ser mani-
pulada pela aplicação.
conn = DriverManager.getConnection
(“jdbc:microsoft:sqlserver:”+
“//servidor:1433;DatabaseName=NorthWind;
Selectmethod=cursor”, “usuario”, “senha”);

O método estático getConnection tem
como parâmetro um String de Conexão,
um String que representa o nome do
usuário e um último que representa a se-
nha do mesmo. O DriverManager verifi-
ca se o driver passado na primeira parte
de String de Conexão está registrado no
JDBC (como descrito anteriormente).
Caso o driver esteja registrado é solicita-
da a conexão de acordo com os parâme-
tros passados na segunda parte do String
de Conexão (onde temos o nome do
servidor, a porta do listner, o nome do
banco a ser acessado e o tipo de seleção)
além do usuário e senha. Caso a conexão
seja efetuada com sucesso, o objeto conn
passa a “apontar” para a mesma.
As linhas que seguem enviam o co-
mando SQL para o Servidor de Banco de
dados para que o mesmo seja compilado
no servidor e fique pronto para execução.
Este procedimento é executado através
do método prepareStatement do objeto
conn (instanciado pelo método getCon-
nection visto anteriormente). Este mé-
todo, se executado com sucesso, retorna
um PreparedStatement que é a instância
do comando “preparado” no Servidor e,
no nosso exemplo, é manipulado pelo
objeto pstmt.
PreparedStatement pstmt = conn.
prepareStatement(“SELECT * FROM EMPLOYESS”);
Para acessarmos os dados do comando
SQL preparado anteriormente é preciso
que tenhamos um objeto do tipo Result-
Set que é instânciado a partir do método
ExecuteQuery() do PreparedStatement,
como mostrado a seguir.
ResultSet rs = pstmt.executeQuery();
Os procedimentos seguintes executam
um “loop” nos dados resultantes do co-
mando SQL contidos no ResultSet rs lis-
tando na tela os valores das colunas Em-
ployeeID, LastName e FirstName.
while ( rs.next() ) {
System.out.println(rs.getInt(“EmployeeID”) + “ - “ +
rs.getString(“LastName”) + “,”+
rs.getString(“FirstName”) );
}
Por fim, fechamos o PreparedState-
ment pstmt e o Connection Conn libe-
rando com isso recursos do banco de
dados e finalizando a aplicação se forma
adequada.
É interessante notar que todos os pro-
cedimentos referentes a conexão, a exe-
cução de comandos e manipulação de
dados estão contidas num bloco protegi-
do (try...catch) pois todos os métodos uti-
lizados propagam SQLException, que re-
presenta uma exceção referente ao acesso
ou manipulação de um banco de dados,
Listagem1
import java.sql.*;

public class Principal {
public static void main (String[] args) {
Connection conn = null;
try {
DriverManager.registerDriver (
new com.microsoft.jdbc.sqlserver.SQLServerDriver());
conn = DriverManager.getConnection
(“jdbc:microsoft:sqlserver:”+
“//servidor:1433;DatabaseName=NorthWind;Selectmethod=cursor”,
“usuario”,
“senha”);
}
catch (SQLException e) {
System.out.println (‘\n’ + “Erro na conexão com o banco.”);
e.printStackTrace();
System.exit(1);
}

try {
PreparedStatement pstmt =
conn.prepareStatement(“SELECT * FROM EMPLOYESS”);

ResultSet rs = pstmt.executeQuery();
while ( rs.next() ) {
System.out.println(rs.getInt(“EmployeeID”) + “ - “ +
rs.getString(“LastName”) + “,”+
rs.getString(“FirstName”) );
}

pstmt.close();
conn.close();
}
catch (SQLException e) {
System.out.println (‘\n’ + “Erro ao recuperar dados no banco.”);
e.printStackTrace();
System.exit(1);
}
}
}
Conectando Front-Ends com Delphi, VB.Net e Java
SQL
Magazine - 33
devendo ser tratada pela aplicação.
Conclusão
Nosso objetivo foi mostrar os procedi-
mentos a serem efetuados em cada uma
das ferramentas analisadas para conexão
e manipulação de dados de um banco no
SQL Server, deixando alguns conceitos
de forma a facilitar ao analista a definição
sobre qual ferramenta usar para cada so-
lução a ser implementada.
De fato, não será somente a escolha da
ferramenta de desenvolvimento que irá
definir a melhor forma de implementar
um projeto com sucesso. O analista que
tiver um domínio completo do problema
proposto pelo cliente (além de conheci-
mento e experiência em cada ferramen-
ta) terá mais facilidade de escolher qual
tecnologia se tornará mais eficiente para
resolver o problema em questão.
ANUNCIO
Emacs
Acesso e manutenção de bancos com
!"# Fabio FaIdini
emacs é o editor de texto o!ciaI do projeto GNU, integrando-
se, portanto, com todas as suas ferramentas. Pode ser usado como
uma IDE, onde é possíveI editar, compiIar, depurar e rodar apIicati-
vos sem nunca precisar sair deIe . Oferece recursos de edição de
texto avançados como identação automática, highIight, auto-com-
pIetar, puIar para Iinha de erro automaticamente, aIém de estar inte-
grado com emaiI, news, web, gerenciadores de banco de dados, ftp,
teInet e muito mais.
O
“Perdi tudo” - grita furioso o usuário ao
ver aquela mensagem de erro no console
do SQLplus, depois de queimar horas es-
crevendo aquele comando SQL. “Porque
não usei um editor de textos antes !?”
Marca o texto com o mouse, Ctrl c... Ctrl
v... e nada ! Tenta uma, duas, três vezes e
nada... “O que está acontecendo?”
Ctrl F9... mais uma vez, Ctrl F9 ... não
vai ... não compila ... “O que houve?”
Tenta selecionar o texto e não vai. Clica
o botão esquerdo do mouse sobre aquelas
linhas e nada!
Essa é a reação de um analista MS-Visual
Studio/Windows que começa trabalhar
em ambientes heterogêneos, na frente
Windows, atrás Unix, nos lados Mac, Visu-
al Age daqui, Borland dali, Oracle, DB2, en-
fim... As mãos já estão acostumadas com o
Visual Studio. Só de pensar em compilar, o
fura-bolo esquerdo vai em direção do Ctrl
e o direito em direção do F9. É assim mes-
mo, após anos usando os mesmos atalhos,
acaba virando reflexo.
O emacs veio resolver esses problemas
e muito mais. Desenvolvido por Richard
Stallman, o fundador do projeto GNU, foi
originalmente escrito em Teco (uma lin-
guagem de macros). Hoje em dia o emacs
está na versão 21.2, podendo ser baixado no
site www.emacs.org e compilado na maio-
ria dos sistemas operacionais do mercado.
O emacs é um ambiente de trabalho to-
talmente customizável e escalável. O usu-
ário pode excluir, modificar e acrescentar
funcionalidades e teclas de atalho tranqüi-
lamente além da facilidade da Internet ofe-
recer uma infinidade de componentes para
serem instalados na IDE do emacs.
Cada linguagem tem suas peculiaridades:
highlight, compilador, interpretador, depu-
rador... enfim, o tratamento de um fonte
em C não é o mesmo tratamento dado à
um fonte em Java, e menos ainda à um fon-
te em Lisp ou em Prolog. Como o emacs
suporta tantas linguagens separadamente?
Major-mode
O emacs é como um esqueleto composto
por vários componentes, entre eles compo-
nentes especializados para as linguagens de
programação. Um conjunto de componen-
tes especializados constitui um major-mode
Acesso e manutenção de bando de dados com Emacs
SQL
Magazine - 35
(modo de edição de texto). Quando um
buffer (conteúdo de uma janela) é aberto,
o emacs associa automaticamente a ele
um major-mode para tratá-lo e controlar
todos os sinais passados para o determi-
nado buffer.
O nome do major-mode usado aparece
na mode-line (linha em cor inversa, situa-
da na parte inferior da tela). Alem disso, a
mode-line apresenta outras informações
úteis como o tipo de texto e se o mesmo
foi alterado. Vide Figura 1.
Nas primeira versão do Emacs, já era
notável a presença e a seleção automáti-
ca dos major-modes. Quando aberto um
fonte em ada (.a), logo entrava no ada-
mode. Para um fonte em lisp (.l), entrava
no lisp-mode, um fonte em prolog (.pl),
entrava no prolog-mode. Para rodar os
fontes em lisp no lisp-mode basta teclar o
enter do keypad e logo aparecia o resulta-
do na echo area, a linha que se encontra
abaixo da mode-line.
Para tratamento de código SQL, o
emacs-21.2 oferece dois major-modes: o
SQL-mode e o SQLi mode (modo SQL
interativo). O SQL-mode controla a edi-
ção de código em SQL e o SQLi-mode
interage diretamente com o gerenciador
de banco de dados - mysql, oracle, pos-
tgres, informix, sybase, db2, interbase e
SQLserver.
SQL-Mode
A forma mais simples de entrar direta-
mente no SQL-mode é abrir um arquivo
com extensão .sql. O atalho para a aber-
tura de um arquivo é:
C-x f ( M-x find-file ) *NomeDoArquivo* RET.
Se o arquivo não existir, será criado um
novo arquivo vazio.
Caso o arquivo não tenha extensão
.sql, ou o sql-mode não for carregado,
podemos carregá-lo manualmente:
M-x sql-mode RET
Para carregar automaticamente o SQL-
mode, ao abrir um arquivo com extensão
.sql, basta acrescentar a linha seguinte no
arquivo de configuração .emacs que fica no
diretório do usuário ( ~user/.emacs ):
(add-to-list ‘auto-mode-alist ‘(“\.sql\’” . sql-
mode))
Agora a Query pode ser escrita no sql-
Figura1.
mode. É interessante a verificação do hi-
ghlight no código escrito. Provavelmen-
te, o código não aparecerá em highlight,
já que por default, o highlight não está
habilitado. Para habilitar o highlight no
buffer corrente, basta digitar:
M-x font-lock-mode RET
Para habilitar o font-lock-mode em
todos os buffers basta digitar:
M-x global-font-lock-mode RET
Para habilitar o font-lock-mode ao
abrir qualquer arquivo, basta acrescentar
as linhas abaixo no arquivo .emacs
(custom-set-variables
‘(global-font-lock-mode t nil (font-lock)))
SQLi-mode
Após as configurações iniciais, para
executarmos a Query digitada, é preciso
entrar no SQLi-mode escolhendo uma
das opções abaixo:
M-x sql-mysql ( para usar com o MySQL )
M-x sql-informix ( para usar com o informix )
M-x sql-ingres ( para usar com o ingres )
M-x sql-postgres ( para usar com o postgres )
M-x sql-oracle ( para usar com o oracle )
M-x sql-sybase ( para usar com o sybase )
M-x sql-db2 ( para usar com o db2 )
M-x sql-interbase ( para usar com o interbase)
M-x sql-ms ( para usar com SQLserver )
Por exemplo, para entrar no MySQL
monitor e acessar uma base de dados, o
minibuffer (localizado embaixo da mode-
line) vai esperar que o usuário entre com
o nome do usuário, a senha, o host e o
nome da base de dados.
Se a opção do gerenciador de banco de
dados escolhida não for reconhecida, pri-
meiro deve-se carregar o SQL-mode e de-
pois procurar chamar o modo desejado.
Continuando com o exemplo do MyS-
SQL
O SQL-mode e o SQLi-mode
oferecem recursos de highlight
e de auto-completar. O high-
light, além de colorir o código
fonte também colore as men-
sagens exibidas no console.
Para facilitar a digitação de
certos comandos, o SQL-mode
disponibiliza abreviações que
podem ser auto-completadas
com um clicar na barra de es-
paço. Por exemplo: sel para se-
lect , upd para update, ins para
insert, del para delete, entre
outros.
QL seguem os procedimentos detalha-
dos para acesso e interação com este ban-
co de dados:
A) Preparando o ambiente (este pro-
cedimento pode ser pré-configurado no
arquivo .emacs):
1) Entrar no emacs
2) Abrir um arquivo em um buffer: C-x
C-f *nomearq* RET
3) Habilitar o modo sql no buffer atual:
M-x sql-mode RET
4) Habilitar o highlight no buffer atual:
M-x font-lock-mode RET
5) Habilitar abreviações no buffer atu-
al: M-x Abbrev-mode RET
B) Acessando o banco de dados
6) Abrir o monitor do mysql: M-x sql-
mysql RET
7) Entrar com o nome de um usuário
do banco no minibuffer e RET
8) Entrar com a senha deste usuário
no minibuffer e RET
SQL
36 - Magazine
9) Entrar com o nome do servidor
onde está localizado o mysql no minibu-
ffer e RET
10) Entrar com o nome da base de da-
dos a ser acessada no minibuffer e RET
11) Avisar ao emacs qual é o buffer que
contem o mysql monitor: M-x sql-set-
sqli-buffer RET *SQL* RET
12) Passar o foco para a janela com o
buffer em sql-mode: C-x o ou com o cli-
que do botão esquerdo do mouse sobre
o buffer
13) Enviar o buffer em sql-mode para o
buffer do monitor mysql: M-x M-b
Pronto ! Estamos dentro do MySQL
monitor! ( Figura 2 )
C) Organizando a tela
14) para quebrar a tela verticalmente:
M-x 3
15) para ativar o follow-mode:
M-x follow-mode RET
Quem diria, o MySQL monitor a co-
res! Se você não estiver vendo as cores,
habilite o font-lock-mode, como foi expli-
cado anteriormente. Você terá o prazer
de ter highlight na linha de comando,
não é formidável?
Agora você não tem mais riscos de per-
der tudo pela ausência do scroll na linha
de comando e se quiser pode até gravar
o buffer:
C-x C-s ( M-x save-buffer ) *NomeDoArquivo* RET
Para habilitar o modo de auto-comple-
tar, basta digitar:
M-x abbrev-mode RET
Como passar a Query de um buffer no
SQL-mode para o MySQL monitor ?
Temos várias possibilidades e a mais
fácil, por enquanto, é enviar o buffer in-
teiro de uma só vez, assim:
C-c C-b ( M-x sql-send-buffer )
*NomeDoBuffer* RET
Caso apareça no echo-area, “no SQL
process started”, é porque o buffer em
SQL-mode não sabe qual é o nome do
buffer que está em SQLi-mode. O nome
do buffer aparece na mode-line à esquer-
da. Para passar o nome do buffer em
SQLi-mode para o buffer em SQL-mode,
basta entrar com o nome do buffer em
SQLi-mode, assim:
M-x sql-set-sqli-buffer RET *NomeDoBuffer* RET
Janelas contínuas ( Follow mode )
Como sempre o resultado da Query
pode ter muitas linhas, não cabendo na
área visível da janela. Pois bem, o emacs
oferece a possibilidade de dividir vertical-
mente cada janela em duas outras janelas
(Figura 3), digitando:
C-x 3 ( M-x split-window-vertically )
As duas janelas que aparecem apre-
sentam o mesmo conteúdo! Para que
uma janela seja a continuação da ante-
rior, deve-se digitar:
M-x follow-mode RET
Para dividir uma janela na horizon-
tal, basta digitar:
C-x 2 ( M-x split-window-horizontally )
Para fechar uma única janela, basta colo-
car o foco do mouse sobre ela e digitar:
Figura2.
C-x 0 (M-x delete-window)
Para expandir uma janela em todo o
frame:
C-x 1 (M-x delete-other-windows)
Modo texto
O emacs não depende de ambientes
gráficos multi-janelas como o MS-Win-
dows ou Xwindow para rodar. O emacs
funciona perfeitamente em modo texto
podendo ser executado em modo DOS e
até mesmo em uma estação de trabalho
como um terminal burro.
Antes mesmo que os ambientes gráfi-
cos multi-janelas se difundissem, o emacs
oferecia um ambiente multi-janelas. Sem
o emacs não podíamos editar, compilar
e executar um programa sem precisar
fechar o editor de textos para compilar e
executar na linha de comando.
FRAME, WINDOW E BUFFER
Uma “janela” do emacs exibe o con-
teúdo de um único buffer. O buffer é
um objeto que contém o texto editado
em uma “janela” do emacs. O frame do
emacs é uma janela do MS-windows ou
do Xwindow.
Acesso e manutenção de bando de dados com Emacs
SQL
Magazine - 37
Para evitar confusão, vamos reservar a
palavra janela para as subdivisões de um
frame do emacs e a palavra frame para as
janelas do MS-windows ou Xwindow.
Um frame do emacs pode ser subdivi-
dido em duas ou mais “janelas”. Quando
executamos o emacs, por default, o fra-
me aparece com uma única janela aber-
ta. Este frame pode ser subdividido em
duas ou mais janelas, verticalmente ou
horizontalmente. Cada janela aberta tem
a sua mode-line particular, porém todas
as janelas de um frame compartilham a
mesma barra de títulos e a mesma echo-
area do frame.
Um buffer inteiro, ou uma parte de um
buffer, pode ser editado em uma ou mais
janelas. Cada arquivo aberto é carregado
em um buffer diferente. Podemos car-
regar inúmeros arquivos enquanto hou-
ver memória suficiente no computador.
Para carregar um arquivo em um buffer,
basta fazer:
C-x C-f ( M-x find-file ) *nomearq* RET
Todas as modificações feitas em uma
janela serão refletidas em todas as janelas
que estiverem editando o mesmo buffer.
Quando fechamos uma janela, o espaço
físico da janela é liberado para que outra
janela se expanda nele, porém o buffer
continua aberto. Para salvar o conteúdo
do buffer, basta fazer:
C-x C-s ( M-x save-buffer )
Buffer list
O emacs armazena os buffers abertos
na buffer-list, que é uma lista de buffers.
Para saber quais buffers estão abertos,
deve-se consultar a buffer-list digitando o
comando abaixo (A lista de buffers aber-
tos vai aparecer na janela adjacente):
Figura3.
C-x C-b ( M-x list-buffers )
Vamos analisar o resultado: Estamos
com 2 buffers abertos em 2 janelas. Uma
janela apresenta o arquivo editado, no
caso, o /tmp/teste.sql e a segunda jane-
la apresenta o buffer que contém a pró-
pria lista de buffers. O buffer *scratch* é
aberto por default depois da tela de apre-
sentação do emacs. O buffer *messages*
mantém um log das mensagens que apa-
recem na echo area. Podemos ver que,
com exceção do buffer teste.sql, todos os
outros estão entre asteriscos. O asteriscos
indicam que se trata de um buffer que in-
terage com o sistema.
A buffer-list também trás outras infor-
mações interessantes. Se o arquivo foi
modificado, vai aparecer um * na primei-
ra coluna e se o arquivo for read-only,
vai aparecer um % na segunda coluna. A
coluna size exibe o tamanho do arquivo
em bytes. A coluna mode exibe o major-
mode do buffer. E a coluna file exibe o
caminho do arquivo.
Buffer Menu mode
O buffer que contém a buffer-list não
é um simples buffer de dados estáticos.
A buffer-list está sendo editada no ma-
jor-mode BUFFER MENU, que permite
ao usuário manipular os buffers listados.
Caso tenhamos aberto inúmeros buffers
e queiramos fechar parte deles basta na-
vegar na buffer list e marcar os buffers
para serem fechados com um d (de de-
lete), e logo aparecerá um D no lugar
da primeira coluna da linha selecionada.
Selecionamos todos aqueles que que-
remos fechar e pressionamos a letra x
para fechar os buffers selecionados. Para
salvar arquivos, basta selecionar com a
ANUNCIO
SQL
38 - Magazine
letra s as linhas desejadas e executar com
x. Podemos também combinar o S e o D
na mesma linha. Para desmarcar, basta
pressionar a letra u (de unmark) sobre a
linha desejada.
Para ver o conteúdo do buffer na janela
adjacente, basta clicar em C-o quando o
cursor estiver na linha do buffer deseja-
do. O foco é mantido na buffer list. Para
passar o foco do cursor para o buffer se-
lecionado, em vez de pressionar o C-o,
pressiona-se somente a letra o. Para abrir
o buffer em uma janela que ocupe o fra-
me inteiro basta pressionar no numero 1
na linha desejada.
Em vez de entrar na buffer-list para
exibir outro buffer na janela, pode-se di-
gitar:
C-x b ( M-x switch-to-buffer ) :
( default: *sql* ) RET
O nome do buffer selecionado por de-
fault aparece entre parêntesis e o usuário
poderá introduzir o nome do buffer dese-
jado. Caso ele não se lembre, basta pres-
sionar o TAB e a lista de buffer aparecerá
na janela adjacente.
RM Buffer Size Mode File
*% *Buffer list* 90 Buffer Menu
teste.sql 0 SQL /tmp/teste.sql
* *scratch* 182 Lisp Interaction
* *Messages* 1501 Fundamental
O emacs funcionava em terminais
burros com teclado e monitor de fósforo
verde, desprovidos de mouse. para mu-
dar o foco de uma janela para outra jane-
la do mesmo frame sem o mouse basta
digitar:
C-x o (M-x other-window)
Boa parte dessas operações podem ser
executadas via menu. Em ambiente grá-
fico é só clicar com o mouse no item de
menu e será exibido um item pop-up.
Mas em ambiente texto pressiona-se o
F10 e os itens de menu aparecerão na ja-
nela adjacente. Se pressionássemos o F10
com o foco do cursor no buffer *scratch*,
apareceria na janela adjacente os itens
exibidos na barra de menus:
Possible completions are:
b==>Buffers
f==>Files
t==>Tools
e==>Edit
s==>Search
m==>Mule
h==>Help
b==>buffers
Para selecionar, um deles basta clicar
na letra que antecede o item de menu,
como b para buffer e t para tools, assim
por diante. Se pressionássemos a letra b
apareceria:
Possible completions are:
s==> *scratch* *
b==>*Buffer List* *%
m==> *Messages* *
c==>*Completions* *
l==> List All Buffers (C-x C-b)
Se o teclado não pussuir o F10, não
tem problema, é possível substituí-lo
com M-`.
Para sair dos menus, basta clicar C-g ou
três vezes escape: ESC ESC ESC.
Conclusão:
O emacs é um ambiente de desenvolvi-
mento integrado padronizado que pode
ser compilado e executado em qualquer
plataforma. Multi-janelas, multi-tarefas
e multi-funcional. Não depende de am-
bientes gráficos, monitores coloridos,
mouses e teclas especiais. Customizável,
o usuário pode editar e gravar suas confi-
gurações particulares no arquivo ~usua-
rio/.emacs para torná-las permanentes.
O emacs traz consigo inúmeros com-
ponentes, entre eles o SQL-mode e o
SQLi- mode. O SQL-mode facilita a edi-
ção de código SQL. O SQLi-mode incre-
menta a linha de comando que acompa-
nha os gerenciadores de banco de dados.
ANUNCIO
MySQL
SBGD no Linux:
!"# CIementino LeaI
m se tratando de soIuções em banco de dados para o Iinux,
um dos pré-requisitos é a "exibiIidade na aquisição da Iicença do
produto. Este fator é também verdade para a maioria dos softwares
para este sistema operacionaI. o MySQL traz, aIém de uma poIítica
de Iicenciamento bastante "exíveI, saIvo aIgumas exceções, recur-
sos que fazem so produto uma soIução ideaI para ser utiIizado em
ambiente Linux.
E
O MySQL é conhecido por ser um
servidor de banco de dados extremamente
rápido e robusto, configurando-se numa
das soluções de menor custo para redes
mistas onde, por exemplo, temos estações
clientes com Windows e servidores com
Linux. É um Banco de dados utilizado
principalmente em servidores web
para persistência de dados em sites, foi
desenvolvido pela T.c.X. DataKonsultAB
(http://www.tcx.se) e está disponível para
download em http://www.mysql.com.
Ao contrário do que se pensa, O MySQL
não é totalmente “free”. Com relação a
sua política de licenciamento podemos
destacar que ele é grátis para ser utilizado
tanto em uso privado como comercial,
existindo algumas restrições para aplicações
a serem utilizadas em ambiente Windows
ou quando for distribuído como parte
integrante de uma solução.
A versão utilizada aqui do MySQL é a
3.23. O MySQL também está disponível
na versão MySQL/Max, que disponibiliza
através de configurações adicionais o
suporte a transações e foreign keys para
determinados tipos de tabelas. A versão
4.0, em desenvolvimento, inclui o suporte
completo a transações, além de suportar
locks de linhas. Para versões futuras estão
previstas as implementações de backup on-
line e recursos de recuperação segura contra
falhas no desligamento. Mais informações
estão disponíveis em http://www.mysql.
com/products/mysql-4.0/index.html;
Instalação No Linux
Os arquivos de instalação do MySql
Servidor e Cliente estão disponíveis para
download em http://www.mysql.com.
• Possui versões disponíveis para vários sistemas
operacionais, entre eles FreeBSD, Unix, Mac OS X, OS/2
Warp 3 e 4, Solaris, SunOS, Windows 9x, Me, NT, 2000 e
XP.
• Facilidade de instalação e administração do Banco de
Dados.
• Capacidade de gerenciamento de um número ilimitado
de usuários simultâneos.
• Alta capacidade de manipulação de registros (mais de
50.000.000 de registros por tabela).
• Execução de comandos super otimizada;
• Simples e efciente sistema de privilégio de usuários.
• Não suporta transações (Commit, rollback, níveis de
isolamento )
• Não faz lock de linhas na atualização
• Não suporta constraints (Chave primária e chave
estrangeira, com capacidade de habilitar/desabilitar ou
dropar/adicionar. )
• Não tem recursos contra falhas no desligamento do
banco durante atualizações de dados.
• Não executa backup consistente com a base de dados no
ar e se atualizações estiverem sendo efetuadas.
VANTAGENS DESVANTAGENS
SQL
40 - Magazine
1) Instale o servidor com o comando:
Shell do Linux>
rpm –ivh MySQL-3.23.53a-1.i386.rpm
2) Instale o cliente com o comando:
Shell do Linux>
rpm –ivh MySQL-client-3.23.53a-1.i386.rpm
3) Depois da instalação teremos que
definir uma senha para o usuário root
com o comando:
Shell do Linux>
mysqladmin –u root –p password ‘senha’

Ele pedirá para confirmar a senha, pois
no primeiro acesso após a instalação a
mesma não estará ainda definida.
O tempo total de instalação foi de
aproximadamente 2 minutos sem a
necessidade de configurações adicionais,
disponibilizando de imediato o banco
para uso.
Durante a instalação do MySQL é
criado um banco de dados, chamado
mysql, contendo cinco tabelas: db, host,
user, tables_priv e columns_priv, que
implementam o controle de acesso aos
dados no MySQL.
Conectando ao Banco
Para entrar no banco digite:
Shell do Linux> mysql –u root –p
‘-p’ Pedirá a senha do usuário.
Welcome to the MySQL monitor. Commands end with ; or \g.
Type ‘help’ for help.
mysql>
A partir da entrada no MySQL
Monitor, é possível criar uma base, usar
uma já existente, consultar informações
etc. Alguns comandos administrativos
podem ser visualizados digitando help, \h
ou ? na linha de comando. Para consultar
as bases existentes digite:
mysql> show databases;
Nota-se que o comando foi seguido
por um ponto-e-vírgula (;). Quase todos
os comandos no MySQL são seguidos
por um ponto-e-vírgula. Caso este não
seja digitado, o cursor passará para a
próxima linha do prompt aguardando o
complemento do comando.
Criando um Banco de dados
No MySQL os bancos de dados
são implementados como diretórios
contendo arquivos que correspondem a
tabelas do mesmo.
Para criar uma base digite:
mysql> create database sqlmagazine;
Após a execução deste comando, será
criado no diretório de dados do MySQL
um subdiretório vazio com o nome
sqlmagazine. Ocorrerá um erro se o
banco de dados sqlmagazine já existir
ou se o usuário logado não possuir o
privilégio apropriado para criação de
uma base de dados.
Uma vez criada a base de dados deve-se
“usá-la”, ou seja, torná-la ativa para que
sejam manipulados os objetos e dados
contidos nesta base. Digite:
mysql> use sqlmagazine;
Criando Tabelas
Uma vez conhecidos os tipos de dados
mais utilizados, é possível criar as tabelas
do banco de dados. Para tal digite:
mysql> create table cliente (
> codigocliente INT NOT NULL,
> nome VARCHAR(30),
> endereco VARCHAR (30),
> cidade VARCHAR (30),
> uf CHAR (2),
> PRIMARY KEY(codigocliente));
Para consultar as tabelas existentes,
digite na base em uso:
mysql> show tables;
Para consultar as colunas da tabela
cliente criada anteriormente, digite:
mysql> show columns from cliente;
Atribuindo Privilégios
Como citado anteriormente, o MySQL
possui um sistema simples e eficiente
para atribuição de privilégios de acesso
a usuários. No nosso exemplo, estamos
conectados com o usuário local root
e com o banco sqlmagazine em uso.
Poderíamos atribuir direitos de acesso a
tabela cliente criada em nosso exemplo a
outro usuário através do comando
mysql> grant select on cliente to nomedousuario;
A opção de grant é bem mais
abrangente que o simples acesso a uma
tabela por determidado usuário. Vejamos
a sintaxe geral do comando:
grant privilégio [ (colunas) ] [, privilégio [ (colunas)... ]
on {*.* | * | bd.* | bd.tabela | tabela }
to usuário@host [ identifed by ‘senha’]
[, ...] [ with grant option ]
Onde os termos entre colchetes são
opcionais, os termos entre parênteses
representam um ou mais elementos e
os termos entre chaves são obrigatórios
com os possíveis valores indicados. Para
os termos em destaque temos:
!"#$#%&'#(: Se refere ao privilégio
a ser atribuído. Podemos destacar os
seguintes:
all [ privileges ] - Todos os Privilégios.
alter -Alterar tabelas e índices.
create - Criar bancos de dados e tabelas.
delete - Eliminar linhas de tabelas.
drop - Eliminar bancos de dados e tabelas.
index - Criar e eliminar índices.
insert - Inserir linhas em tabelas.
select - ler dados de tabelas.
update - alterar linhas em tabelas.
usage - sem privilégios.
)(%*+,-. Nomes das colunas às quais
os privilégios devem ser aplicados
(+.Especifica o nível do privilégio
*.* - Atribui os privilégios a todas as tabelas em todos
os bancos de dados do servidor.
* - Atribui os privilégios a todas as tabelas do banco de
Tipos de Dados mais utilizados no MSQL
CHAR(M) – É usado para representar strings de tamanho fxo, onde M pode ter de 1 à 255 caracteres.
VARCHAR(M) – Também é usada para representar strings, sendo mais fexível do que o tipo CHAR, por armazenar o
dado de forma variável, onde M pode ter de 0 à 255 caracteres. É aconselhável usar este tipo de dados no lugar do CHAR,
uma vez que só é armazenado a quantidade de caracteres que o dado contém. Para o tipo CHAR, todo o “tamanho”
referente ao campo é alocado, mesmo que ele não preencha todos os caracteres.
INT [(M)] [Unsigned] – Este tipo armazena inteiros que variam de -2147483648 a 2147483647 com sinal. Se for usado
Unsigned, o intervalo será 0 a 4294967295.
FLOAT [(M,D)] – Representa números decimais de precisão simples.
DOUBLE [(M,D)] – Representa números decimais de precisão dupla.
DATE – Armazena datas. O formato default é ‘AAAA-MM-DD’ Intervalo de ‘1000-01-01’ a ‘9999-12-31’.
DATETIME – Armazena data e hora no formato ‘AAAA-MM-DD HH:MM:SS’. Intervalo de ‘1000-01-01 00:00:00’ a ‘9999-
12-31 23:59:59’.
TEXT / BLOB – Este tipo de dado é utilizado para strings de 0 ate 65535 caracteres de armazenamento.
SET (“valor1”,”valor2”,...) [NOT NULL] – Permite especifcar uma lista com até 64 valores dos quais um ou mais podem
ser atribuídos a coluna.
Exemplo: sexo SET(“M”,”F”) NOT NULL;
transporte set (“caminhao”,”furgao”);
SGBD no Linux: MySQL
SQL
Magazine - 41
dados corrente.
bd.* - Atribui os privilégios a todas as tabelas do
banco de dados especifcado.
bd.tabela - Atribui os privilégios a todas colunas da
tabelas especifcada.
tabela - Atribui os privilégios a todas colunas da
tabelas especifcada no banco de dados default.
0(. Especifica o(s) nome(s) do(s)
usuário(s) a ter(em) privilégios atribuídos.
Formato usuário@host.
usuário - Nome do usuário ou string vazio para
especifcar um usuário anônimo.
host - Nome do host, ou endereço IP.
Identifed By - Atribui uma senha ao usuário, ou
altera a senha de um usuário existente.
1#02 3",+0 (!0#(+. Permite ao
usuário atribuir a outros usuários
qualquer um dos seus privilégios no nível
de privilégio especificado.
Manipulando o Banco de dados
A manipulação dos dados armazenados
num banco se dá de quatro formas:
inserção, alteração, deleção e seleção
de um ou mais registros. Com base na
tabela de cliente criada anteriormente
seguem alguns exemplos:
Para inserir um registro numa tabela já
existente digite:
mysql> INSERT INTO cliente (codigocliente, nome,
endereço, cidade, uf )
VALUES Ø (1,”JOSE DA SILVA”,”RUA ALTA,30”,
“RIO DE JANEIRO”,”RJ”);
mysql> INSERT INTO cliente (codigocliente, nome,
endereço, cidade, uf )
VALUES Ø (2,”MARIA DA SILVA”,”RUA BAIXA, 25”,
“NITEROI”,”RJ”);
mysql> INSERT INTO cliente (codigocliente, nome,
endereço, cidade, uf )
VALUES Ø (3,”JOAO SOUZA”,”RUA ESTREITA, 50”,
“SAO PAULO”,”SP”);
Para selecionar registro(s) de uma
tabela já existente, digite:
mysql> SELECT * FROM cliente;
Mostrará todos os registros da tabela.
mysql> SELECT * FROM cliente WHERE uf = “SP”;
Mostrará todos os registros com a uf=“SP”.
mysql> SELECT * FROM cliente WHERE uf = “RJ”
ORDER BY nome;
O “Order By” trará os registros
ordenados por nome.
mysql> SELECT * FROM cliente WHERE nome LIKE “J%”;
O “LIKE” substitui o “=” para fazer
uma procura estimada e não exata. O
“%” funciona como um coringa que
substitui qualquer caractere.
Para alterar registro(s) numa tabela já
existente, digite:
mysql> UPDATE cliente
SET endereco = “RUA ESTRELA, 65”
WHERE codigocliente = 3;
Para apagar registro(s) numa tabela já
existente, digite:
mysql> DELETE FROM cliente
WHERE codigocliente = 3;
Operadores Lógicos
AND (&&)
mysql> SELECT * FROM cliente WHERE uf = “RJ”AND
cidade = “NITEROI”;
mysql> SELECT * FROM cliente WHERE uf = “RJ”&&
cidade = “NITEROI”;
Mostrará os registros que tenha uf=“RJ”
e ao mesmo tempo a cidade= NITEROI”
OR ( || )
mysql> SELECT * FROM cliente WHERE uf = “RJ”OR
cidade = “SAO PAULO”;
mysql> SELECT * FROM cliente WHERE uf = “RJ”||
cidade = “SAO PAULO”;
Mostrará os registros que tenha uf =
“RJ” ou cidade = “SAO PAULO”
NOT (!)
mysql> SELECT * FROM cliente WHERE uf != “RJ”;
Mostrará os registros que tenha uf
diferente “RJ”.
Modificando uma Tabela
Para Renomear uma tabela já existente,
digite:
mysql> ALTER TABLE cliente
RENAME c-lientenovo;
Para adicionar uma coluna a uma
tabela já existente, digite:
mysql> ALTER TABLE clientenovo
ADD datanasc DATE;
Para alterar uma coluna de uma tabela
já existente digite:
mysql> ALTER TABLE clientenovo CHANGE nome
nomecliente VARCHAR(30);
Para remover uma coluna de uma
tabela já existente, digite:
mysql> ALTER TABLE clientenovo DROP complemento;
Conclusão
Até então a ausência de transações
vinha se mostrado um ponto negativo
para a utilização do Mysql de forma
mais abrangente, embora existam
muitas aplicações, como por exemplo
as de armazenamento de conteúdo
dinâmico para websites, que não exijam
transações e se beneficiem sobremaneira
do ganho de performance obtido com
a sua ausência, uma vez que desfazer
programaticamente uma operação com
múltiplas tabelas é trabalhoso e não
muito utilizado.
Hoje, esta questão já não pesa tanto
para utilização do MySQL devido ao
suporte parcial a transações, constraints
e foreign keys. No futuro o próximo o
Um pequeno exemplo
Segue um pequeno exemplo escrito em Java mostrando
o acesso ao banco e as tabelas criadas neste artigo. A
aplicação não disponibiliza uma interface gráfca, ela
simplesmente efetua a conexão com o banco e lista
num console os dados da tabela CLIENTENOVO criada
anteriormente.
O Driver JDBC MySQL utilizado para o exemplo pode
ser baixado no endereço http://www.mysql.com/
downloads/api-jdbc-stable.html.
import java.sql.*;
public class Principal
{ public static void main (String[] args)
{ Connection conn = null;
try
{
//registra o driver do mysq no jdbc
DriverManager.registerDriver
( new com.mysql.jdbc.Driver() );
//verifca se o driver está registrado e abre uma
conexão com o banco de acordo
//com os parâmetros do método getConnection
conn =DriverManager.getConnection
(“jdbc:mysql://localhost/sqlmagazine?user=root”);
}
catch (SQLException e)
{ System.out.println (‘\n’+ “Erro na conexão com o banco.”);
e.printStackTrace();
System.exit(1);
}
try
{
//envia o comando para o banco de dados para que /
//ele seja “compilado”pelo banco
//otimizando dessa forma a resposta do banco
//quando o mesmo for executado
PreparedStatement pstmt = conn.
prepareStatement(“SELECT * FROM CLIENTENOVO”);
//executa o comando preparado e retorna um
//ResultSet para ser manipulado pela aplicação
ResultSet rs = pstmt.executeQuery();
while ( rs.next() )
{ System.out.println(rs.getInt(“CODCLIENTE”) + “ - “ +
rs.getString(“NOMECLIENTE”));
}
pstmt.close();
conn.close();
}
catch (SQLException e)
{ System.out.println (‘\n’ +
“Erro ao recuperar dados no banco.”);
e.printStackTrace();
System.exit(1);
}
}
}
suporte completo a transações, locks
de linhas durante a atualização, backup
on-line e recuperação segura agregarão
valores a benefícios já existentes como alta
performance, simplicidade de instalação,
manutenção reduzida e versões para
vários sistemas operacionais, fazendo
com que o MySQL seja utilizado de
forma mais abrangente.
PostgreSQL
Conquistando novas fronteiras
!"# GiseIIi NichoIs
pesar dos sistemas de código aberto se mostrarem desa!a-
dores para muitos desenvoIvedores, uma parceIa consideráveI de
usuários ainda resiste em adotar um software que não pertence a
ninguém. Preocupada com a questão da credibiIidade e continui-
dade de desenvoIvimento do PostgreSQL, um banco de dados reI-
acionaI que permite ao desenvoIvedor a criação de operações to-
taImente personaIizadas, a dbExperts resoIveu fazer a Iigação do
mundo virtuaI com o reaI.
A
De acordo com Roberto Stern, diretor
da softhouse brasileira, a necessidade de
um contato físico com o produto ainda faz
parte do processo de fidelização do clien-
te. “O consumidor quer tocar o produto
e ter a certeza de que no dia seguinte não
vai sumir da internet. Apesar de trabalhar-
mos com o mundo virtual, vivemos no
mundo real e é ele que fala mais alto.”, es-
clarece. Segundo o executivo, a estratégia
da empresa está apresentando resultados.
Desde seu lançamento em março do ano
passado, foram vendidas 1.350 cópias do
PostgreSQL. Só este ano, 900 cópias foram
comercializadas e a expectativa para 2003 é
de que 1.500 licenças sejam contratadas.
Para justificar o preço de R$ 485 prati-
cado para um sistema originalmente open
source, a dbExperts fez algumas alterações
no PostgreSQL agregando valor ao banco
de dados. Introduziu um instalador para
Linux e uma versão única para Windows
e Mac OS X. O pacote de distribuição da
versão dbExperts PostgreSQL Professional
inclui ainda toda documentação em portu-
guês, 30 dias de acesso a suporte local e um
cartão-resposta que dá direito a um inci-
dente de suporte de desenvolvimento. “Ti-
vemos cuidado com o usuário. Criamos
um canal de distribuição e desenvolvemos
o design da embalagem”, acrescenta Stern.
A escolha do PostgreSQL pela dbExperts
foi criteriosa. A empresa brasileira, há mais
de 12 anos no mercado de desenvolvimen-
to de banco de dados, viu no aplicativo um
meio seguro de conquistar mercado. “O
banco é robusto, rápido e era pouco co-
nhecido até iniciarmos nossa distribuição, o
que nos garantia uma boa margem comer-
cial”. A empresa está preparando uma nova
versão, com lançamento previsto para ja-
neiro do próximo ano e promete muitas
novidades. Entre as implementações está
a replicação das instalações centralizadas,
agenda, ferramentas de CRM e gerenciador
de projetos.
A estratégia original da dbExperts em
alcançar pequenas e médias empresas está
mudando um pouco de foco. Hoje, o mer-
cado corporativo é um dos alvos de venda.
A mais recente aquisição do pacote foi feita
pela Vésper. A empresa de telefonia fixa,
com presença em 80 municípios brasilei-
ros, adotou o PostgreSQL para algumas
aplicações. Para José Luis Dadario, Dire-
tor de Projetos Especiais de TI, o PostGre
substitui com vantagens outros bancos de
dados similares. “Resolvemos adotar o Pos-
Conquistando novas fronteiras PostgreSQL
SQL
Magazine - 43
tgreSQL pela redução de custo, pois vi-
mos que em algumas aplicações não ha-
veria necessidade de continuarmos com
bancos shareware”. A empresa iniciou a
migração dos dados em abril e pretende
concluir o processo até o final do ano.
A versão brasileira do PostgreSQL ope-
ra em múltiplas plataformas, incluindo
Windows 95/98/ME/NT e 2000, Linux
e FreeBSD. Com características adequa-
das ao padrão ACID (Atomicidade, Con-
sistência, Isolamento e Durabilidade) de
bancos de dados, pode ser utilizado tanto
em redes ponto-a-ponto, cliente/servi-
dor ou em ambientes mono-usuários. O
licenciamento é por servidor, suportando
inúmeros usuários simultâneos sem cus-
to adicional. Para os ambientes Linux e
FreeBSD, a licença da dbExperts permite
que o software seja livremente utilizado e
distribuído. O mesmo CD pode ser reins-
talado um número ilimitado de vezes em
qualquer servidor. Já a licença para os sis-
temas operacionais Windows e Mac OS
X é limitada por servidor, de acordo com
a quantidade de licenças adquiridas. Se
o cliente possuir dois servidores vai pre-
cisar de duas licenças separadas. Não há
limite para o número de estações de tra-
balho locais ou usuários de Internet que
acessem o servidor simultaneamente.
O dbExperts PostgreSQL Professio-
nal 7.2 é um sistema de gerenciamento
de banco de dados relacional (SGBDR)
avançado que possui extensões obje-
to-relacionais e características de banco
de dados orientado a objetos (OODB).
Fornecido com o código fonte para as
versões Linux e FreeBSD, permite ao de-
senvolvedor criar e adicionar novas fun-
ções, adequando totalmente a operação
do banco de dados às suas necessidades
específicas.
O PostGreSQL é um banco de dados
com uma gama considerável de recursos,
incluindo o suporte a transações, stored
procedures e triggers, internacionaliza-
ção e diversos recursos de segurança.
Overview
O PostgreSQL surgiu em 1977, na Ca-
lifórnia, EUA, como um projeto acadê-
mico para a criação de um sistema 100%
Unix. Batizado inicialmente como In-
gres, o SGBDR deu origem à Relational
Technologies, empresa que melhorou
o código original, sendo posteriormente
adquirida pela Computer Associates.
Enquanto isso, na Universidade de
Berkley, uma equipe de universitários
passou a desenvolver um servidor de
banco de dados objeto-relacional que
foi nomeado de Posgres (“pós” Ingres).
Em 1986, a empresa Illustra Corporation
lançou a versão comercial do produto.
Comprado pela Informix, o banco foi in-
tegrado ao Informix Universal Server.
Em 1995, dois estudantes de gra-
duação de Berkeley incrementaram
o projeto, adicionando a linguagem
SQL, resultando no Postgres95. A
partir de 1996, o banco ganhou o
nome de!nitivo de PostgreSQL.
Principais Características
Transações – Suporte a múltiplas tran-
sações online concorrentes entre usuá-
rios. Comandos
COMMIT e ROLLBACK totalmente
suportados.
Backup Online – Realiza cópia de segu-
rança de um ou todos os bancos de dados
sem a necessidade de desconectar os usu-
ários, mesmo com transações simultâne-
as ativas.
Triggers – Perfeitamente suportados.
Segurança de acesso – Respeita defini-
ção de grupos e perfis e ainda oferece a
opção de limitação por HOST que pode-
rá acessar o banco.
Stored Procedures – São perfeitamente
aceitos.
Características MySQL PostgreSQL Interbase Adabas
Freeware X X X X versão D personal
Open Source X X menos para NT X -
Portabilidade
Linux, NT,
FSDB
Linux, NT, FSDB, Sun SI,
Windows 95, 98, ME, NT,
2000, XP e Mac OS X
Linux, NT
- Windows NT,
95 e 98
UNIX- IBM AIX - SNI
Sinix - SUN Solaris- Linux
- Windows NT, 95 e 98 Referencial
Stored Procedures/Triggers - X X X
Transações concorrentes - X - X
Sem limite de usuários X X X 3 sessões concorrentes
Integridade referencial - X X X
Transações - X X -
ODBC Free X X X -
Estabilidade X X X X
Disponibilidade (backup HOT) - X X X
Amigabilidade/Interface * *** *** *
Suite de apoio ao desenvolvimento Exige ferramentas adicionais
Extrator de relatórios Exige ferramentas adicionais
Objeto-relacional – Permite ao Post-
greSQL herdar tipos de dados, tabelas e
bancos de dados inteiros.
Tipos de dados definidos pelo usuário
– Além dos tipos de dados convencionais,
o usuário pode criar um tipo de dados
customizado que atenda às suas necessi-
dades.
Funções definidas pelo usuário – Além
das funções já disponíveis no PostgreS-
QL, o usuário pode criar funções nas
linguagens internas (PL/pgSQL, PL/Tcl
e PL/Perl) ou em C através de módulos
carregáveis .so e .dll.
Integridade de dados – As transações
são escritas em um log além de serem
registradas nos arquivos de dados, permi-
tindo que o sistema aplique um rollback/
rollforward no caso de um encerramento
anormal do servidor.
webSITES
www.postgresql.org
www.dbexperts.com.br
developer.postgresql.org
SQLAutor
Giselli Nichols (gnichols@sqlmagazine) é jor-
nalista, com pós-graduação em Assessoria de
Imprensa, webwriter e webdesigner.
RepIicação
Os meIhores recursos para
!"# PauIo Ribeiro
epIicação é uma feature importantíssima nos SGBD's atuais
- consiste em copiar, distribuir e manter a sincronia entre dados,
estes normaImente situados em servidores distintos. O modeIo
desenvoIvido peIa Microsoft para o SQL Server, que desde a versão
6.0 agregou repIicação de dados em seu engine, será o enfoque nes-
ta edição.
R
No mundo corporativo, a replicação de
dados está nitidamente ligada a ambientes
distribuídos, onde o acesso a dados bási-
cos (descrição de um produto numa loja,
por exemplo) é feito no próprio local da
consulta. Acessando dados localmente,
reduzimos a possibilidade de conflitos e
otimizamos tráfego de dados nos links de
comunicação entre as instalações distribuí-
das, que muitas vezes constituem gargalos
nos sistemas.
A escolha do modelo de replicação
adequado depende das características do
negócio. Considere-se uma empresa com
gestão de preços centralizada chamada
“Corp”, com matriz de mesmo nome em
São Paulo-SP e filiais no Paraná-PR, Rio de
Janeiro-RJ e Rio Grande do Sul-RS. Abai-
xo, seguem algumas perguntas que dire-
cionam na escolha do modelo apropriado:
a) A distribuição de dados deve ser efetu-
ada de maneira unilateral (da base central
para as filiais) ou a própria loja poderá alte-
rar o preço dos produtos? Se a própria loja
alterar o preço de um produto, será preciso
distribuí-lo para as demais?
b)Qual a latência desejável para sincro-
nia dos dados?
c) As filiais devem receber somente os
preços praticados naquele local ou uma loja
deve possuir acesso aos preços praticados
em toda a rede?
d) A sincronização deve ser feita sempre
para toda a lista de produtos ou somente
para os produtos cujo preço foi alterado?
A Microsoft, em face desses questiona-
mentos, sugere três modelos para réplica de
dados - Transacional, Merge e Snapshot - que
serão analisados tomando por base a empresa
fictícia “Corp”, onde toda a rede pratica a mes-
ma política de preços, ditada pela matriz em
atualizações semanais de listas.
O Modelo Transacional
Como o próprio nome sugere, esse mo-
delo baseia-se na atualização das filiais a par-
tir do log de transações copiado do servidor
principal. Ao atualizar o preço de um pro-
duto em “Corp” (figura-1), o log do coman-
do que gerou essa alteração será copiado
para uma base específica (“Distrib”), para
posterior distribuição nas filiais de RJ, PR
e RS. Resumidamente, a replicação transa-
cional armazena e distribui comandos de
manipulação de dados (Insert/Update/De-
lete) nas tabelas assinaladas para réplica de
dados. Note que a atualização é unidirecio-
nal (Central => Filiais).
Os Melhores recursos para replicação de dados
SQL
Magazine - 45
O Modelo Snapshot
Na replicação Snapshot, os objetos são
exportados integralmente a cada execu-
ção de um job específico no distribuidor,
também conhecido como “agente de sin-
cronização”. Isto significa que as listas de
preços nas filiais seriam substituídas se-
manalmente por cópias atualizadas, inde-
pendentemente de alteração de preços.
Essa modalidade de replicação não
controla atualizações, inserções e/ou
deleções; simplesmente substitui uma
cópia por outra.
O Modelo Merge
Baseia-se em triggers criadas nas ta-
belas replicadas. Essas triggers fazem a
movimentação de dados para tabelas
de sistema responsáveis pela sincroniza-
ção entre as bases replicadas. Os Jobs ou
“Agentes de Sincronização” que, no mo-
delo snapshot eram específicos do distri-
buidor, agora funcionam em todas as ins-
talações distribuídas. Eles identificam as
alterações e desencadeiam o processo de
atualização nas bases replicadas. Obser-
ve-se que, na figura-3, o preço Y, alterado
diretamente no ponto de venda PR, deve
ser atualizado primeiramente em “Corp”
para que depois seja sincronizado com os
outros pontos.
Um fato interessante diz respeito ao que
aconteceria se, na empresa “Corp”, após
uma reestruturação, fosse permitido que
as filiais tivessem autonomia para alterar
e divulgar preços para as outras filiais e,
conseqüentemente, em duas filiais, o pre-
ço de um mesmo produto fosse alterado
para valores diferentes. Na sincronização
semanal, surgiria um impasse: que preço
aplicar para a rede? O mais baixo? Aque-
le que foi primeiramente registrado? A
replicação merge possui um tratamento
especial para conflitos, que permite ras-
trear e resolver esse tipo de problema. O
algorítmo é bastante simples: na criação
do modelo, são definidas prioridades
para cada participante, vencendo quem
possuir a maior. Se o preço do produto
X for alterado na filial RJ (prioridade 0.3)
para R$ 4,00, e na filial RS (prioridade
0.8) para R$5,00, na ocasião do conflito
o preço da filial RS seria vencedor, sendo
então repassado para a rede.
Segue agora um exemplo prático para
criação do processo de replicação. Serão
definidas, passo a passo, as etapas existen-
tes na criação de um modelo que atenda
a empresa “Corp” na distribuição de lis-
tas de preços para suas filiais.
O primeiro passo é registrar no Enter-
prise Manager todos os servidores envol-
vidos (\Corp, \Distrib, \PR, \RJ e
\RS ) com uma conta que possua pri-
vilégios de “system administrator”, aqui
chamada de “replicador”, especialmente
criada para esse fim.
Definição do distribuidor
A replicação é um processo complexo
que envolve agentes específicos para o
controle das diversas operações. O passo
inicial é, portanto, definir um servidor,
aqui chamado de Distribuidor, para ge-
renciar esses agentes. As atribuições de
um distribuidor envolvem armazena-
mento, distribuição e controle das cópias
de dados. É aconselhável que o Distri-
buidor esteja num servidor separado do
banco de dados por questões de seguran-
ça (uma vez que ele precisa ter acesso as
instalações distribuídas e, se o banco de
dados estivesse fisicamente na mesma
máquina, teríamos o risco do acesso in-
devido a dados da base corporativa) e
também da otimização do processamen-
to tanto do distribuidor, que executa os
jobs referentes a replicação, quanto do
banco de dados que, se acessado por ou-
tros clientes, não teria sua performance
prejudicada. No servidor \Distrib, sele-
cione Replication\ ConfigurePublishing
. Na próxima tela confirme Make “Dis-
trib” its own Distributor e prossiga (Vide
Figura 4).
“Snapshot Folder” é uma pasta que
deve ser criada no distribuidor para ar-
mazenamento temporário do schema e
dados para inicialização das subscrições
(como podemos chamar as filiais recep-
toras das atualizações). Deve ser uma
pasta pública e visível pelas subscrições.
(Vide Figura 5)
Pra prosseguir selecione No, user the
following default settings em Customize
Configuration.
Definição do publicador, publicação e
modelo de réplica
É necessário definir que o servidor \
Corp (onde é efetuado o cadastro e alte-
ração das listas de preços), utilizará os ser-
viços de \Distrib para divulgação das
listas nas filiais. Nesse contexto, \Corp
passa a ser chamado de “Publicador”, por
ser responsável pela publicação da lista
de preços.
Inicialmente, é preciso liberar o acesso
de \Corp aos serviços do distribuidor.
Figura1.
Figura2.
Figura3.
Figura4.
SQL
46 - Magazine
Para isso, na máquina \Distrib, entre no
Enterprise Manager e clique com o bo-
tão direito do mouse em Replication. No
menu, selecione “Configure Publishing,
Subscribers and Distributor” e escolha a
guia Publishers conforme a figura 6.
Na guia Publishers, deve-se liberar o
acesso de \Corp para utilização dos ser-
viços de \Distrib (preste atenção pois
esse procedimento é executado no distri-
buidor \Distrib) identificando o servi-
dor Corp como Publisher. Para isso, mar-
que a Check Box e clique nas reticências
ao lado de “...distribution...”. Informe a
conta e senha que devem ser utilizadas
quando o agente de leitura – também co-
nhecido como “Log Reader”- se conectar
no publicador para leitura do log de tran-
sações a fim de efetuar a replicação. Essa
conta, como informado no início, é conta
definida no servidor de domínio da rede
e deve possuir privilégios de “system ad-
ministrator” em todos os servidores en-
volvidos na replicação (\Corp, \Dis-
trib, \RJ, \PR, \RS).
Uma vez definido que \Corp pode-
rá efetuar publicações controladas por
\Distrib o próximo passo será a cria-
ção da publicação. Para isso, no servidor
\Corp, clique com o botão direito do
mouse em Publication e selecione “New
Publication” (figura 7).
O modelo selecionado para a repli-
cação será o modelo transacional, pois,
de acordo com as regras de negócio do
exemplo que envolve a replicação de
uma tabela de preços, a entrada de dados
ocorre num único ponto, com distribui-
ção centralizada, as bases replicadas não
inserem ou alteram dados e, neste caso,
é exigido uma alta fidelidade da réplica
com as bases publicadas.
Dando continuidade, na tela “…Select
a Distributor ...”, é indicado o servidor
\Distrib, na opção “...Use the following
server (the selected server must already
be configured as distributor) “. Em se-
guida seleciona-se o database “db_Corp”
como publicador e posteriormente o
modelo de replicação.
Note que as listas são atualizadas so-
mente no Publicador (\Corp); as alte-
rações de preços devem ser enviadas de
maneira incremental para as filiais, o que
justifica a escolha do tipo Transacional.
Clique em next para a definição dos tipos
de subscrições.
Definição dos tipos de subscrições
As filiais receptoras das alterações de
preços passam a ser conhecidas por Subs-
crições. Serão criadas, portanto, três subs-
crições, uma para cada filial (RJ, PR e RS).
Nesse momento, será definido também
que cada filial deverá receber uma carga
inicial, que inclui criação do schema da
tabela “Preco_Item” e respectiva carga
de dados.
Como nosso ambiente é baseado na
plataforma SQL Server 7.0 & 2000 é
aconselhável a seleção das duas opções
marcadas na figura 9.
No próximo passo especificaremos os
Artigos.
Artigo é a unidade básica de replicação.
Um artigo pode representar uma tabela
ou uma stored procedure. Considerare-
mos o artigo “Preco_Item”, envolvendo,
a tabela de mesmo nome, localizada no
database “db_Corp” no servidor \Corp.
(Vide Figura 10)
Nas reticências (...) ao lado da tabela
“Preço_Item”, são confirmadas as op-
ções em evidência na guia “Snapshot” ,
conforme é mostrado na figura-11.
O snapshot (carga inicial da tabela “Pre-
ço_Item” nas subscrições) deverá criar a
estrutura da tabela, carregando também
índices e foreign keys. Se por algum mo-
tivo a tabela já existir no destino, sua es-
Figura5.
Figura6.
Figura7.
Figura8.
Figura9.
Figura10. Figura11. Figura12.
Os Melhores recursos para replicação de dados
SQL
Magazine - 47
trutura deverá ser atualizada.
Após a indicação do nome da publica-
ção como “Lista_Preços” a etapa é con-
firmada e não é aconselhável mais ne-
nhuma customização, pois todas as filiais
recebem o preço de todos os produtos,
bastando apenas a finalização da criação
da publicação.
Criação e inicialização das subscrições
Ao término da criação da publicação
definiremos as subscrições em \PR, \
RJ e \RS.
Antes, porém, é necessário conceder
permissão a essas subscrições para que
assinem a publicação “Lista_Preços”
definida no servidor \Corp. Para isso,
deve-se expandir o servidor \Corp, o
database “db_Corp” e clicar com o botão
direto do mouse em “Publication” aces-
sando o menu “ Configure Publishing,
Subscribers and Distribution ...” confor-
me demonstrado na figura-12.
Na guia Subscribers as subscrições \
PR, \RJ e \RS devem estar habilitadas
para que possam assinar a publicação a
ser definida em \Corp . Clicando nas
reticências, é obrigatório que o usuário
“replicador” - utilizado pelos jobs de sin-
cronização – esteja assinalado em “Use
SQL Server”.
Basicamente, a replicação Transacio-
nal fornece dois tipos de subscrição: Push
e Pull.
Na modalidade “Push”, o distribuidor
“empurra” as alterações para as subscri-
ções; todo o processo de distribuição é
controlado por jobs localizados no Dis-
tribuidor.
No modo “Pull”, as filiais “puxam” as
alterações do distribuidor; o job que con-
trola esse processo está localizado na pró-
pria subscrição.
Por facilidade de administração (todas
as filiais podem ser controladas de um
ponto único no distribuidor) escolhere-
mos o modelo “Push”. Para isso selecio-
ne a publicação Lista_Preços no database
db_Corp em \Corp e, com o botão di-
reito do mouse, selecione o menu “Push
New Subscription”. Vide figura 14.
Prossiga selecionando as subscrições
(figura-15) e o nome dos databases nas
mesma (figura-16).
Os nomes dos databases nas subscri-
ções \PR, \RJ e \RS são, respectiva-
mente, “db_PR”, “db_RJ” e “db_RS”. O
Próximo passo é definir a periodicidade
de sincronização. Neste exemplo utiliza-
remos um schedule para sincronizar as
filiais aos domingos, às 07:00hs da ma-
nhã. Vide figura 17.
Confirme a inicialização da subscrição
em “Yes, inicialize the schema and data”
(figura 18) e prossiga finalizando o pro-
cesso. Confirme no Enterprise Manager
em \Distrib a criação da subscrição.
Vide figura 19.
O último passo é a execução do snap-
shot, que irá inicializar a réplica na loja.
Selecione em Distrib “Lista_Precos” e
no painel da direita clique com o botão
direito do mouse em “Snapshot”. sele-
cione “Start”. Será então efetuada a cópia
do schema da tabela “Lista_Item” segui-
da da carga inicial dos dados. À partir daí
um job schedulado no servidor \Distrib
se encarregará da atualização semanal.
Para criação das outras subscrições, basta
repetir os processos a partir do passo 4.
Escolha Replicação Transacional quando:
- A entrada de dados ocorre num único
ponto, com distribuição centralizada;
- As subscrições não inputam dados;
- As características do negócio exigem
alta fidelidade da réplica com as bases pu-
blicadas (=latência baixa).
Escolha Replicação Snapshot quando:
- O volume de alterações de dados for
significativamente alto e justifique a subs-
tituição por completo das réplicas;
- A atualização das bases replicadas
ocorrer com menor frequência (=latên-
cia alta);
- As subscrições utilizarem as bases re-
plicadas somente para leitura.
Escolha Replicação Merge quando:
- Todos os participantes são responsá-
veis por alterações, inclusões e deleções
nas estruturas replicadas. Seu objetivo é
tornar o ambiente homogêneo, mesclan-
do dados oriundos de vários locais.
Figura13.
Figura14.
Figura15.
Figura16.
Figura17.
Figura18.
Figura19.
JDataStore
O banco de dados Java da BorIand
!"# Edgar SiIva
BorIand ao Iongo dos anos vem ganhando cada vez mais
respeito no mercado Java. A companhia, que tornou o JBuiIder o
IDE mais utiIizado do mundo, mantém mais uma frente Javanesa: O
JDataStore. AIém de ser "Pure Java¨, o banco possui uma caracter-
ística curiosa: seu arquiteto, Sérgio Cardoso, é um dos brasiIeiros
que trabaIham na BorIand USA.
A
Para utilização de um banco de da-
dos em Java, é necessário que se utilize
a JDBC. Semelhante ao modelo ODBC
da Microsoft, a JDBC é uma “ponte” en-
tre o aplicativo e o banco de dados. O
JDBC e o ODBC têm por base a mesma
idéia: deixar transparente para o aplicati-
vo qual banco de dados que está sendo
utilizado.

A API JDBC é dividida em quatro classes
de acesso. Cada uma destas classes pos-
suem características únicas que definem
como o banco será acessado, apresentando
vantagens e desvantagens, dependendo do
tipo da aplicação. Veja abaixo um pequeno
resumo dos tipos de acesso:
Tipo1: JDBC-ODBC - A aplicação
Java se conecta à um driver ODBC e este
se conecta ao banco. A vantagem é a am-
pla gama de banco de dados que oferecem
conexões via ODBC. O ponto negativo é a
baixa performance e o fato de a ODBC ser
instalada em cada máquina cliente.
Tipo2: Native-API partly Java technology-
enabled driver – O driver JDBC se comuni-
ca diretamente com o client do banco. É mais
veloz do que o tipo1 pela ausência da ODBC.
Como no tipo1, o cliente do banco precisa es-
tar instalado em cada máquina cliente.
Tipo3: Pure Java Driver for Database Mi-
ddleware – A aplicação se comunica com
uma camada intermediária, que traduz as
chamadas e repassa para o banco de dados.
Elimina a necessidade do cliente do banco
estar instalado na máquina cliente. Entre-
tanto, não é recomendável para aplicações
de pequeno porte.
Tipo4: Direct-to-Database Pure Java Dri-
ver. A mais rápida de todas. A aplicação se co-
munica diretamente com o banco de dados,
sem a necessidade de intermediário, através
do protocolo nativo do banco de dados.
O driver nativo JDBC para o JDataStore
6 é classe 4, assim como o do Oracle e do
novo InterBase 7.
JDataStore - O Banco de dados da Borland
SQL
Magazine - 49
JDataStore6: Banco de Dados 100%
Java, Ágil, Simples, Móvel e Dis-
tribuível.
O JDataStore é relacional e transacio-
nal, com suporte a StoredProcedures,
UDF´s (User Defined Functions), cone-
xões simultâneas e concorrentes. Apesar
de conter esses recursos é um produto
compacto, podendo até ser executado
em dispositivos wireless. É portável e
multi-plataforma, já que foi desenvolvi-
do totalmente em Java. Suporta o padrão
ansi92, tornando o acesso aos dados pra-
ticamente sem mistérios para quem já
usa algum outro banco relacional.
Um dos principais focos do JDataSto-
re na versão 6 é possibilitar a criação de
aplicações em dispositivos wireless, per-
mitindo sua utilização em plataformas
como Compaq Ipaq, Sharp Zaurus e
outros que suportem a plataforma Jeode
(PersonalJava e EmbeddedJava). O Palm
OS ainda não é suportado pelo JDS. Se-
gundo Sérgio Cardoso, arquiteto do JDa-
taStore, “Quando o PalmOS disponibili-
zar pelo menos 8Mbytes para processos
Java, poderemos rodar nestes modelos”.
Pontos Fortes
Baixo custo de investimento: Uma li-
cença para 10 usuários custa em torno de
US$ 1000,00.
Perfomance: Por se tratar de um ban-
co de dados simples, o JDS apresenta boa
performance.
Fácil Distribuição: É possível distribuir
os recursos necessários do engine do
JDS num disquete de 1.4 Mb. Distribuir
o Run time em formato Jar file do JDS
consome apensa 1 Mb.
Desenvolvimento: O JDataStore pos-
sui integração nativa com o JBuilder, for-
necendo um ambiente mais produtivo do
que em outras plataformas de desenvolvi-
mento. Isso não impede que o JDataStore
seja acessado por outras ferramentas.
Resumo das Caracteríticas Básicas do
JDataSore
• Totalmente escrito em Java;
• Roda em dispositivos com apenas
16Mbytes de memória;
• Suporta versões Java 1.1.8 à 1.4;
• Certificado para rodar em Windows
(XP, 2000, NT, 98 SE), Linux (RedHat 7.x,
Mandrake 7.x), Solaris (7, 8) e Mac OS X;
• Suporte à padrões (JavaBeans, SQL
92, stored procedures, foreign keys,
JDBC 3.0 scrollable, updatable cursors,
batch updates);
• Alta Performance;
• Suporte a transações;
• Suporte à múltiplos processadores;
• Recuperação automática de erros;
• Requer mínima administração;
• Fácil distribuição;
• Um único arquivo .jar file contém
toda funcionalidade;
• Pode ser distribuído junto à aplicação;
• Arquivo de dados tem o mesmo for-
mato para todas as plataformas de insta-
lação do produto e é até 50% menor que
um com a mesma estrutura gerado em
um banco de dados similar;
Algumas das Melhorias na Versão 6.0
• Maior suporte aos padrões adotados
pelo mercado;
• Maior suporte as propriedades da API
JDBC e Implementações adicionais para
interfaces JDBC 2 e JDBC 3;
• Mudanças para tipos de dados FLO-
AT, DATE e TIME;
• Implementação de novas funções de
sistema;
• Suporte a Subqueries ;
• Suporte a Foreign keys ;
• Suporte a Table expressions;
• Suporte a Stored procedures e UDFs
(User Defined Funcion);
Sobre as Stored Procedure e UDF´s
Stored Procedures: A maioria dos servi-
dores de banco de dados utilizam o Tran-
sactSQL e o PL-SQL para implementa-
ção de Stored Procedures. No JDataStore
6 a linguagem de procedures é o Java, de
forma que todos os recursos de funções
de sistema, mecanismos de conversão,
funções com tipos primitivos, bem como
manipulação de Strings e outras classes
Java, podem ser utilizados.
UDF (User Defined Functions): Como
no InterBase, é possível criar funções
personalizadas para o JDS. Com isso, as
possibilidades para tratamento dentro do
banco se tornam praticamente infinitas.
A desvantagem, assim como qualquer
UDF, é a queda de performance quando
o código realiza uma chamada à função.
Utilizando o JDataStore pela primeira vez
O JDataStore está disponível junta-
mente com a instalação do JBuilder para
download no site da Borland no endere-
ço http://www.borland.com/products/
downloads/download_jdatastore.html.
A instalação é simples e rápida, bem
como a utilização dos seus recursos. O
banco acompanha um utilitário para
manutenção visual, chamado JDataStore
Explorer (imagem 1).
Para criar um novo banco de dados se-
lecione o menu File->New. Na janela de
opções, indique a versão do banco a ser
criada, defina o diretório e dê um nome
para o arquivo de dados. A extensão do
banco será .jds. (Imagem 2).
Uma tabela pode ser construída atra-
vés do menu Tools/Create Table. A
janela para criação é intuitiva, deixando
qualquer um a vontade. Os dados da
tabela estão disponíveis na guia “View”,
conforme mostra a figura 3.
Imagem 1 – JDataStore Explorer
Imagem 2 – Criando o Arquivo JDS na versão 6.0
Imagem 3 – Manipulção da tabela criada.
SQL
50 - Magazine
Entrevista
com Sérgio Cardoso
(Engenheiro de Produtos da Borland USA)
Durante os últimos nove anos, Sérgio
Cardoso teve a oportunidade de participar
no desenvolvimento de vários releases do
Borland C++, JBuilder, Borland Applica-
tion Server e trabalhar no desenvolvimen-
to do Borland JDataStore. Esteve presente
este ano em São Paulo, na 1º BorCon Bra-
sil, ministrando uma palestra sobre o JDS.
O que é o JDataStore?
JDataStore é um banco de dados rela-
cional totalmente desenvolvido em Java.
Usuários do JBuilder Enterprise e do Bor-
land Enterprise Server contam com a tec-
nologia do JDataStore nestes produtos.
O JDataStore também é distribuído em
uma versão standalone. Ele integra-se de
maneira transparente ao JBuilder, nossa
solução para desenvolvimento Java.
Qual a missão do JDataStore?
O objetivo principal do JDataStore está
em facilitar o desenvolvimento de aplica-
ções Java que necessitem de um banco de
dados com alta performance, instalação
transparente, manutenção zero e pouco
uso de memória. Procuramos garantir que
o JDataStore seja compatível aos padrões
de mercado tais como J2EE, JDBC e SQL.
Por sua versatilidade e robustez, o JDataS-
tore tanto pode ser usado em dispositivos
móveis como em aplicações distribuídas.
A portabilidade do ambiente Java per-
mite também que o mesmo código e
arquivos de dados de uma aplicação que
use JDataStore possa ser utilizado sem
a necessidade de portes e conversões.
O mesmo arquivo .jar com cerca de
1Mbyte contendo todo a funcionalidade
do produto pode ser usada em Windo-
ws, Linux, Solaris e Mac OS X.
Exitem concorrentes do JDS?
Cloudscape e PointBase são dois outros
bancos de dados Java no mercado norte-
americano. Depois da compra da Informix
pela IBM, não se ouve muita coisa a respei-
to do futuro do Cloudscape. PointBase está
oferecendo hoje recursos que já existem no
JDataStore há vários releases.
Como funciona o JDataStore dentro
de dispositivos Móveis e como seria a
relação J2ME e JDataStore?
Boa parte do que se fala hoje sobre
J2ME está concentrado no MIDP. Mui-
tos dos modelos de telefone celular dis-
poníveis hoje possuem cerca de 2Mbytes
para execução de programas.
Estamos trabalhando para o mercado
de dispositivos com 16Mbytes de memó-
ria RAM ou mais, que oferecem suporte
para Personal Java hoje e ao CDC/Perso-
nal Profile no futuro, como os modelos
baseados na arquitetura ARM, rodando
Pocket PC. O iPaq da Compaq possui
modelos com 32Mbytes de memória
RAM. Desses 32Mbytes metade pode ser
utilizado como área de armazenamento
e outra metade para execução de aplica-
ções. A mesma quantidade de memória
está disponível nos modelos Zaurus da
Sharp que usam Embedded Linux como
sistema operacional.
A Nokia possui o Communicator 9210i
que é uma mistura de PC e telefone ce-
lular. Conseguimos executar aplicações
com o JDataStore neste equipamento.
Mas enfrentamos baixa velocidade nas
transferências de dados por estarem
baseados em redes GSM. Esses equipa-
mentos deverão ter uma aceitação muito
maior quando suportarem redes GPRS
que oferecem velocidades maiores para
transferência de dados.
Vai ser possível um dia utilizar JDataS-
tore com Palm´s?
Quando o PalmOS disponibilizar pelo
menos 8Mbytes para processos Java, po-
deremos rodar nestes modelos.
É simples trabalhar com repositórios
locais JDataStore e depois realizar a sin-
cronização com outros servidores de
banco de dados?
Sim, isso é possível. O JDataStore pos-
sui uma solucao “lightweight” para sin-
cronização de dados entre dispositivos
remotos e servidores de dados.
O JDataStore deixará de ser relacional
para tornar-se um banco de dados
orientado à objetos?
Você pode armazenar instâncias de ob-
jetos em uma tabela com o JDataStore.
Todo o suporte para a serialização existe
hoje. Também contribuímos com tecno-
logia de mapeamento relacional/objeto
na implementação do CMP do Borland
Enterprise Server (Enterprise Java Beans).
Como funciona o mecanismo de li-
cença do JDS?
O JDataStore possui basicamente 3 ti-
pos de licença: Developer, Local Server
e Server.
Quando você compra o JBuilder Ente-
prise ou o Borland Enterprise Server (BES),
você também está adquirindo uma licença
para desenvolvimento do JDS.
Quando uma aplicação desenvolvida
com o JDataStore precisa ser distribuída
você pode adquirir licenças para um ser-
vidor local onde, por exemplo, o arquivo
de dados será acessado pelo mesmo usu-
ário em uma mesma máquina.
Caso você precise que a base de dados
seja acessada por diferentes usuários,
você poderá utilizar o JDataStore Server
em um servidor por usuários remotos.
A licença de Servidor permite que até 10
conexões simultâneas sejam feitas a uma
mesma base de dados. Novas licenças po-
dem ser adquiridas e adicionadas.
O que podemos esperar no futuro do
JDataStore?
Estamos explorando os avanços em
.NET, segurança e dispositivos móveis.
Conclusão
Assim como o Interbase da Borland,
o JDataStore é uma solução para quem
busca um banco leve, portável, rápido e
de simples manutenção. Seu baixo custo,
aliado as vantagens de ser PureJava, faz
dele uma solução única para alguns tipos
de aplicação.
webSITES
http://bdn.borland.com
http://www.borland.com/jdatastore/index.html
http://wireless.java.sun.com/getstart/
http://java.sun.com/products/jdbc/.
SQLAutor
Edgar Silva é Diretor Técnico da Argos Tecnologia,
atuando em projetos envolvendo Multi-camadas
com J2EE e outras tecnologias Borland com
BizSnap e DataSnap. Está atuando no desenvolvi-
mento de várias API´s Java, bem como o Argos
Framework (EJB, Servlets, JSP e Struts).
Foi durante muitos anos um dos principais in-
strutores da Borland, viajando o país inteiro para
formação de novos instrutores e profissionais
certificados. É Borland Delphi Certified Developer
& Instructor e Borland JBuilder Certified Developer
& Instructor. É lider do Grupo de Usuários Java de
Belém (http://beljug.locaweb.com.br) e pode ser
contactado em esilva@argostecnologia.com.