Semin ario S2i: Banco de Dados - MySQL e PostgreSQL

Marcelo Moraes Minasi 0013021-4 Florian opolis, 26 de abril de 2004.

Lista de Tabelas
1 2 3 4 5 6 7 Tabela do fornecedor. . . . . . . . . . . . . . . . . . Tabela das pe cas. . . . . . . . . . . . . . . . . . . . . Tabela do relacionamento entre fornecedores e pe cas. Depend encias: um caso errado e outro correto. . . . Tabela do fornecedor. . . . . . . . . . . . . . . . . . Tabela da vari avel SEGUNDA e FP. . . . . . . . . . Tabela da vari avel FC e CS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 5 8 9 10 11

Lista de Figuras
1 2 3 4 5 6 7 Componentes de um sistema de banco de dados. . . . . . . . . . . . . . Relacionamento como entidade. . . . . . . . . . . . . . . . . . . . . . . . Primeira ilustra c ao da arquitetura de tr es n veis. . . . . . . . . . . . . . Segunda ilustra c ao da arquitetura de tr es n veis. . . . . . . . . . . . . . Tela ap os a simples execu c ao de um cliente SQL e seu status. . . . . . . Benchmark de banco de dados: p aginas da web retornadas por segundo. Benchmark de banco de dados: as respostas mais r apidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 7 7 16 19 20

C odigos
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 O banco de dados de fornecedores e pe cas (deni c ao dos dados). . . . . . . . . Exemplo de dom nios usando DOMAIN. . . . . . . . . . . . . . . . . . . . . . . Exemplo de falha de verica c ao de tipo em dom nios. . . . . . . . . . . . . . . . Exemplo de restri c ao usando SELECT. . . . . . . . . . . . . . . . . . . . . . . Exemplo de proje c ao usando SELECT. . . . . . . . . . . . . . . . . . . . . . . . Exemplo de proje c ao simplicada usando SELECT. . . . . . . . . . . . . . . . Exemplo de jun c ao usando SELECT. . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de INSERT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de UPDATE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de DELETE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de CREATE VIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de uma consulta sobre uma VIEW. . . . . . . . . . . . . . . . . . . . Exemplo de elimina c ao de registro na VIEW e suas implica c oes na tabela real. Exemplo de SQL Embutida com API para Java. . . . . . . . . . . . . . . . . . Exemplo de SQL Embutida com API para C++. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 12 13 13 13 14 14 15 15 16 16 17 17 21 23

Sum ario
1 Introdu c ao 1.1 Instala c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Conceitua c ao b asica 3 Projeto 3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Formas normais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 SQL 4.1 Opera c oes de deni c ao . . . . . . . . 4.2 Opera c oes de manipula c ao de dados 4.3 Opera c oes de Atualiza c ao . . . . . . 4.4 Sum ario das instru c oes SQL . . . . . 5 Exemplo 6 APIs - Application Program Interfaces 6.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Estudo comparativo entre MySQL e PostgreSQL 3 3 3 5 5 5 11 12 13 13 14 15 17 18 18 18

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Introdu c ao

Esse documento foi fortemente baseado na refer encia [C. 00]. Tenta-se dar uma boa base dos conceitos iniciais envolvendo bando de dados e do padr ao SQL, mostrando-se, no nal, um exemplo, uma simples compara c ao (benchmark ) envolvendo alguns sistemas de bancos de dados e algumas APIs - application program interface. Um interessante trabalho posterior seria algumas ferramentas gr acas para constru c ao de um banco de dados e uma melhor compara c ao de alguns sistemas de bancos de dados, como MySQL, PostreSQL, etc.

1.1

Instala c ao

Assume-se aqui que o leitor conseguiu instalar perfeitamente um servidor de banco de dados onde possa criar bancos e modic a-los, como tamb em executar buscas exemplicadas nesse documento atrav es de query da SQL. Como a instala c ao varia conforme o sistema operacional, indica-se aqui apenas alguns ponteiros para p aginas de instala c ao de dois dos mais usados programas para sistemas de gerenciamento de banco de dados: MySQL [MySb] na refer encia [MySa] e PostgreSQL em [Pos]. Outra refer encia interessante para instala c ao do MySQL [MySb] e: http://www.devshed.com /c/a/MySQL/MySQL-Installation-and-Conguration/. Ap os a instala c ao, algumas rotinas ainda precisam ser executadas, para maiores detalhes, veja o ponteiro: http://dev.mysql.com/doc/mysql/en/Unix post-installation.html.

Conceitua c ao b asica

Sistema de Banco de Dados e simplesmente um sistema computadorizado de armazenamento de registros, composto basicamente por quatro partes: dados (banco de dados), software (sistema de gerenciamento do banco de dados), hardware (armazenamento f sico) e usu arios (programadores de aplica c ao, usu arios nais e DBA - Administrador). Tais registros s ao as linhas de uma tabela, cujas colunas s ao os dados. Essa tabela e um arquivo computadorizado.

Figura 1: Componentes de um sistema de banco de dados. Um banco de dados e uma cole c ao de dados persistentes (n ao que eles durem para sempre, mas diferem de entradas, sa das, etc.) utilizada pelos sistemas de aplica c ao.

BASICA CONCEITUAC AO

Sua utiliza c ao possui as seguintes vantagens: compartilhamento de dados, redund ancia controlada (reduzida), inconsist encia controlada, suporte a transa c oes (opera c oes at omicas: tudo ou nada, ou atualiza todas as tabelas necess arias, ou nenhuma; que em conjunto com o log implica consist encia), integridade (restri c oes de integridade, por exemplo, idade 0), maior seguran ca (senhas), aplica c oes independente de dados, etc. Uma tabela (vari avel de rela c ao) cont em os dados relativos a um conjunto de entidades id enticas (livro, tema, leitor e requisi c ao). Cada linha (tuplo) caracteriza uma entidade desse conjunto. Cada coluna (atributo) representa uma caracter stica dessa entidade. Cada tabela apresenta um identicador u nico, chamado de chave prim aria. Nem sempre e vantagem acrescentar mais um campo designado a ser essa chave (como uma numera c ao seq uencial e c clica), pois essa pode ser limitada pelo tamanho do tipo de dado desse campo. Assim, ela pode ser constitu da de v arios dados agrupados da tabela. Por exemplo, o BD da Eletrosul apresenta 3.000.000.000 de registros mensais! As entidades s ao composta por registros, que s ao inst ancias daquele tipo, por exemplo: a entidade carro pode possuir os registros carroA, carroB, Monza etc. Al em de entidades, normalmente num banco de dados, haver a relacionamentos entre entidades, que segundo o paradigma relacional, tamb em s ao representadas em tabelas. Observe a gura [2]. Isso ser a melhor explicado mais abaixo. A seguir, apresenta-se alguns conceitos b asicos no contexto de banco de dados: Chave prim aria e um identicador u nico para cada tuplo de uma tabela. Cada tabela deve ter uma chave prim aria. Uma chave prim aria pode ser constitu da por um ou mais atributos. Chave estrangeira e a utiliza c ao da chave prim aria numa outra tabela para se poder criar um relacionamento. Transa c ao e uma unidade l ogica de trabalho (at omicas).

Figura 2: Relacionamento como entidade. #Fornecedor 1 2 NomeF A B

Tabela 1: Tabela do fornecedor. #Pe ca 1 2 NomeP Parafuso Prego

Tabela 2: Tabela das pe cas. Bancos de dados relacionais s ao sistemas de banco de dados baseados em uma fundamenta c ao normal (te orica) chamada de modelo relacional de dados, que apresenta tr es aspectos: Aspecto estrutural: os dados s ao representados por tabelas, e s o tabelas - propriedade de fechamento: a sa da de uma opera c ao e tamb em uma tabela, o que garante que a sa da de uma opera c ao pode ser a entrada de outra.

#Pe ca 1 2

#Fornecedor 1 2

Qtdade 2000 3000

Tabela 3: Tabela do relacionamento entre fornecedores e pe cas. Aspecto de integridade: essas tabelas satisfazem a certas condi c oes de integridade; Aspecto manipulativo: os operadores dispon vies para manipular tabelas derivam umas de outras - os tr es mais importantes s ao: Restri c ao (DEPTOs nos quais ORC AMENTO > R$8 milh oes), Proje c ao (DEPTOs sobre #DEPTO, ORC AMENTO) e Jun c ao (DEPTOs e EMPREGADOs sobre #DEPTO). Aqueles registros devem sofrer algum tipo de opera c ao em algum momento, como: Acrescentar novos arquivos (CREATE TABLE); Inserir novos dados em arquivos (INSERT); Buscar (SELECT), alterar (UPDATE) e eliminar dados em arquivos existentes (DELETE). Esses exemplos s ao todos expressos em uma linguagem chamada SQL. Ela ser a melhor explicada mais abaixo [4].

3
3.1

Projeto
Arquitetura
Geralmente, o projeto de um BD se d a em tr es n veis, como observado nas guras [3] e [4]: 1. Interno (f sico): como os dados s ao sicamente armazenados (n umero de bytes de cada campo, etc.); 2. Externo (l ogico do usu ario): como os dados s ao vistos por cada usu ario individualmente. CREATE VIEW teste AS (EMP WHERE SALARIO > 3K) { #EMP, NOMEEMP, SALARIO } ; 3. Conceitual (l ogico comunit ario): intermedi ario entre os dois.

Na concep c ao de um BD, tanto a Linguagem de deni c ao de dados (DDL), como ilustrado no c odigo [1], como a linguagem de manipula c ao de dados (DML) s ao transparentes para o usu ario. De um ponto de vista de mais alto n vel, pode ser considerado como uma arquitetura cliente/servidor.

3.2

Formas normais

O assunto de normaliza c ao e apenas uma formaliza c ao de uma id eia simples e muito usada na pr atica. Id eia que consiste em fazer um projeto de banco de dados seguindo o paradigma um fato em um lugar, isto e, evitar redund ancia. Al em disso, a normaliza c ao nos ajuda a estruturar o banco de dados de forma a tornar mais f acil as atualiza c oes de uma u nica tupla do que seria caso esse banco n ao estivesse normalizado.

PROJETO

1 2 3 4

TYPE #F . . . ; TYPE NOME . . . ; TYPE #P . . . ; TYPE QTD . . . ;

6 VAR F BASE RELATION 7 { #F #F o r n e c e d o r , 8 NOME NomeF } 9 PRIMARY KEY { # F o r n e c e d o r e s } ; 11 VAR P BASE RELATION 12 { #P #Peca , 13 NOME NomeP } 14 PRIMARY KEY { # Peca } ; 16 VAR FP BASE RELATION 17 { #F #F o r n e c e d o r , 18 #P #Peca , 19 QTD Qtdade } 20 PRIMARY KEY { # F o r n e c e d o r , # Peca } 21 FOREIGN KEY { # F o r n e c e d o r } REFERENCES F 22 FOREIGN KEY { # Peca } REFERENCES P ;


C odigo 1: O banco de dados de fornecedores e pe cas (deni c ao dos dados).

Algumas vari aveis poderiam, mesmo estando normalizadas - no sentido do par agrafo anterior justamente nesse sentido que v - possu rem propriedades indesej aveis. E em os princ pios de normaliza c ao avan cada, ou formas normais. Esses princ pios nos permitem reconhecer esses casos e substituir essas vari aveis por outras mais desej aveis de algum modo. Dizemos que uma vari avel est a em uma forma normal se ela satisfaz a um certo conjunto prescrito de condi c oes. Por exemplo, dizemos que uma vari avel de rela c ao - que modela um relacionamento - est a na segunda forma normal (2FN) se, e somente se, ela est a em 1FN e tamb em satisfaz uma outra determinada condi c ao, descrita mais abaixo em 3.2. Numerosas formas normais foram denidas por volta de 1972. As tr es primeiras por Codd em [E. 72]. Mais tarde, Boyce e Codd deniram tamb em uma outra terceira forma normal, mais abrangente, conhecida como forma normal de Boyce/Codd (FNBC). Subsequentemente, em Fagin deniu ainda a quarta e a quinta formas normais. A refer encia [E. 72] deniu tamb um procedimento de normaliza c ao, atrav es do qual uma vari avel de rela c ao que est a em alguma forma normal espec ca pode ser substitu da por um conjunto de vari aveis de rela c ao em alguma forma mais desejada. Esse procedimento e revers vel, o que signica que o processo de normaliza c ao preserva informa c oes. Embora existam outras formas normais al em dessas seis, esse documento abranger a apenas as tr es primeiras, visto que a implementa c ao de um banco de dados projetado de forma que suas vari aveis estejam na 3FN e uma boa solu c ao de compromisso entre a complexidade dos procedimentos de normaliza c ao subsequentes e o n vel de caracter sticas desejadas obtidas (baixa redund ancia, integridade, etc.). O processo de normaliza c ao consiste em decompor uma vari avel de rela c ao em outras vari aveis mais desejadas. Esse processo deve ser necessariamente ser perdas, i. e. revers vel.

PROJETO

Figura 3: Primeira ilustra c ao da arquitetura de tr es n veis.

Figura 4: Segunda ilustra c ao da arquitetura de tr es n veis. Para que uma decomposi c ao1 sem perdas seja realizada, e assim seja poss vel recompor2 o conjunto de informa c oes, precisa-se respeitar o conceito de depend encia funcional descrito a seguir. Para entender melhor a import ancia do conceito de depend encia funcional, imagine o seguinte problema: se R1 e R2 s ao proje c oes de alguma vari avel de rela c ao R, e se R1 e R2 em conjunto incluem todos os atributos de R, que condi c oes devem ser satisfeitas para garantir que a jun c ao de R1 e R2 nos dar a de volta a vari avel de rela c ao original R? Ver exemplo na tabela aqui que entram as depend [4] abaixo. E encias funcionais. Seja R uma vari avel de rela c ao, e sejam X e Y subconjuntos arbitr arios do conjunto de atributos de R. Ent ao, dizemos que Y e funcionalmente dependente de X em s mbolos, X Y, (X seta Y), se e somente se em todo valor v alido de R, cada valor X tem associado a ele exatamente um valor Y. Em outras palavras, em todo valor poss vel v alido de R, sempre que
1 2

O operador da decomposi c ao na algebra relacional e, na verdade, o de proje c ao. O operador da recomposi c ao na algebra relacional e, na verdade, o de jun c ao.

PROJETO #Fornecedor F3 F5 STATUS 30 30 CIDADE Paris Atenas

#Fornecedor Caso correto F3 F5

STATUS 30 30

#Fornecedor F3 F5

CIDADE Paris Atenas

Caso errado

#Fornecedor F3 F5

STATUS 30 30

STATUS 30 30

CIDADE Paris Atenas

Tabela 4: Depend encias: um caso errado e outro correto. duas tuplas concordam sobre seu valor X, elas concordam tamb em sobre seu valor Y. Todo conjunto de DFs depend encias funcionais e equivalente a pelo menos um conjunto irredut vel. Se I e um conjunto irredut vel equivalente a S, a imposi c ao das DFs em I impor a automaticamente as DFs em S. Deni-se um conjunto S de DFs como irredut vel se e somente se: 1. O lado direito (o dependente) de cada DF em S cont em apenas um atributo; 2. O lado esquerdo (o determinante) de cada DF em S e por sua vez irredut vel - signicando que nenhum atributo pode ser descartado do determinante sem converter S em algum conjunto n ao equivalente a S; 3. Nenhuma DF em S pode ser descartada de S sem converter S em em algum conjunto n ao equivalente a S. Existem Diagramas DF que representam convenientemente essas depend encias. Isso e interessante porque as DFs possuem uma no c ao sem antica, cuja interpreta c ao s o depende do projetista. Por exemplo, #F CIDADE signica que cada fornecedor est a localizado em exatamente uma cidade. Apenas para se ter uma no c ao do ponto que se deseja atingir, descreve-se informalmente o que seria a terceira forma normal (3FN). Terceira forma normal: uma vari avel est a na 3FN se e somente se os atributos n ao-chaves (qualquer atributo que n ao participa da chave-prim aria da vari avel de rela c ao) s ao: Mutuamente independentes, i. e., se nenhum deles e funcionalmente dependentes de qualquer combina c ao dos outros; Irredutivelmente dependentes da chave prim aria. O fato de dois ou mais atributos serem mutuamente independentes quer dizer que cada um deles pode ser atualizado independentemente dos demais. Descreve-se a seguir o processo de normaliza c ao. Antes, a deni c ao da primeira forma normal: Primeira forma normal: uma vari avel de rela c ao est a em 1FN se, e somente se, em todo valor v alido dessa vari avel de rela c ao, cada tupla cont em exatamente um valor para cada atributo.

PROJETO Por exemplo:

PRIMEIRA { #F, STATUS, #P, QDE, CIDADE } PRIMARY KEY { #F, #P } ; #F F1 F1 F1 F1 F1 F1 F2 F2 F3 F4 F4 F4 STATUS 20 20 20 20 20 20 10 10 10 20 20 20 CIDADE Londres Londres Londres Londres Londres Londres Paris Paris Paris Londres Londres Londres #P P1 P2 P3 P4 P5 P6 P1 P2 P2 P2 P4 P5 QDE 300 200 400 200 100 100 300 400 200 200 300 400

Tabela 5: Tabela do fornecedor. A principal desvantagem e a quantidade excessiva de redund ancias, que s ao tamb em chamadas de anomalias de atualiza c ao. No exemplo acima, n ao d a para inserir a informa c ao de que um determinado fornecedor est a numa cidade espec ca at e que ele efetivamente forne ca pelo menos uma pe ca. E se eliminarmos uma tupla da tabela acima, eliminaremos talvez muito mais informa c oes que gostar amos. Para solucionar, utiliza-se o processo de normaliza c ao, que informalmente pode ser entendido agora como uma processo de desempacotamento : inserir informa c oes logicamente isoladas em vari aveis de rela c oes separadas. Assim, a solu c ao para esses problemas seria: SEGUNDA { #F, STATUS, CIDADE } PRIMARY KEY { #F } ; e FP{ #F, #P, QDE } PRIMARY KEY { #F, #P } FOREIGN KEY { #F } REFERENCES SEGUNDA; Assim, deve car claro que essa estrutura resolve todos os problemas com opera c oes de atualiza c ao descritos anteriormente. Segunda forma normal: uma vari avel est a na 2FN se e somente se ela est a na 1FN e todo atributo n ao-chave e irredutivelmente dependente da chave prim aria. Mas a estrutura SEGUNDA ainda sofre pela falta de independ encia m utua entre seus atributos n ao-chaves. Mais detalhadamente, a depend encia de STATUS sobre #F, embora seja funcional e, de fato, irredut vel, e transitiva (atrav es de CIDADE): cada valor de #F determina uma CIDADE e esta, por sua vez, determina o valor de STATUS. Depend encias transitivas levam tamb em a anomalias de atualiza c ao. Mais uma vez a solu c ao e desempacotar, transformar a vari avel SEGUNDA em:

PROJETO #F F1 F2 SEGUNDA F3 F4 F5 STATUS 20 10 10 20 30 CIDADE Londres Paris Paris Londres Atenas

10

#F F1 F1 F1 F1 F1 F1 FP F2 F2 F2 F3 F4 F4 F4

#P P1 P2 P3 P4 P5 P6 P1 P2 P3 P2 P2 P4 P5

QDE

Tabela 6: Tabela da vari avel SEGUNDA e FP. FC { #F, CIDADE } PRIMARY KEY { #F } FOREIGN KEY { CIDADE } REFERENCES CS ; e CS{ CIDADE, STATUS } PRIMARY KEY { CIDADE } ;

Terceira forma normal: uma vari avel est a na 3FN se e somente se ela est a em 2FN e todo atributo n ao-chave e dependente de forma n ao transitiva da chave prim aria. Uma observa c ao importante a ser feita e que o n vel de normaliza c ao de uma vari avel de uma rela c ao dada e uma quest ao de sem antica, n ao apenas uma quest ao de valores de dados que essa vari avel de rela c ao possa conter em algum momento particular. Para resumir, pode-se dizer que para se chegar ao n vel da 3FN, deve-se realizar duas opera c oes: 1. Dada a vari avel de rela c ao R como esta: (Para reduzir depend encias, redund ancias triviais) R { A, B, C, D } PRIMARY KEY { A, B } ; Deve-se substituir R por suas duas proje c oes R1 e R2:

#F F1 F2 FC F3 F4 F5

CIDADE Londres Paris Paris Londres Atenas

CIDADE Atenas CS Londres Paris

STATUS 30 20 10

Tabela 7: Tabela da vari avel FC e CS. R1 { A, D } PRIMARY KEY{ A, D } ; R2 { A, B, C } PRIMARY KEY { A, B } FOREIGN KEY { A } REFERENCES R1 ; 2. Dada a vari avel de rela c ao R como esta: (Para reduzir depend encias transitivas, e.g. A B e B C) R { A, B, C } PRIMARY KEY { A } ; Deve-se substituir R por suas duas proje c oes R1 e R2: R1 { B, C } PRIMARY KEY{ B } ; R2 { A, B } PRIMARY KEY { A } FOREIGN KEY { B } REFERENCES R1 ;

SQL

A SQL e uma linguagem padr ao para intera c ao com banco de dados relacionais. Originalmente, o nome SQLsignicava Structured Query Language (Linguagem de Consulta Estruturada) e se pronunciava sequel. Por em, agora a linguagem se transformou num padr ao, e o seu nome agora e apenas um nome - n ao e ocialmente uma abreviatura para alguma coisa - e a pron uncia pendeu para esse-qu e- ele. Seu nome ocial e International Standard Database Language SQL (1992), largamente referenciada na literatura por SQL/92 ou SQL2, que foi a grande revis ao do padr ao proposto segundo o padr ao SQL. Posteriormente, teve-se um desenvolvimento da SQL2 para a SQL3, no que concerne ao suporte a objetos. Mais informa c oes a respeito do suporte a objetos podem ser obtidas no seguinte ponteiro: http://www.objs.com/x3h7/sql3.htm. Conceitualmente, SQL e um padr ao relacional, i.e., n ao-procedural (n vel de abstra c ao maior que C++, por exemplo): n ao se indica como mas o qu e se quer. A tarefa de como executar e denida pelo otimizador do SGBD. Um tutorial de SQL pode ser obtido em: http://www.devshed.com/c/a/MySQL/A-TechnicalTour-of-MySQL/. Uma simples refer encia de quais diretivas s ao padronizadas e suas sintaxes pode ser obtidas facilmente em http://www.1keydata.com/sql/sql.html.

SQL

12

Uma refer encia excelente para que deseja saber mais sobre SQL e o ponteiro http://sqlzoo.net/. Ele possui uma ferramenta interativa para se contruir declara c oes SQL e test a-las sobre diferentes bancos de dados.

4.1

Opera c oes de deni c ao

Na SQL3 e poss vel denir-se dom nios pr oprios do usu ario, na SQL2 n ao. Aqui, os dom nios ser ao considerados como tipos, mas uma discuss ao um pouco mais profunda mostra que eles est ao longe de serem a mesma coisa, como mostra o cap tulo 4 de [C. 00]. Os tipos internos permitidos pela SQL s ao: CHARACTER [ VARYING ] (n); BIT [ VARYING ] (n); NUMERIC (p,q); DECIMAL (p,q); INTEGER; SMALLINT; FLOAT (p); DATE; TIME; TIMESTAMP; INTERVAL. Como dito anteriormente, os dom nios em SQL n ao s ao tipos verdadeiros. Em SQL, eles servem apenas para permitir que um tipo embutido, j a denido, receba um nome que possa ser usado como abrevia c ao por v arias colunas em diversas deni c oes de tabelas. Um exemplo de dom nios podem ser vistos no c odigo [2].

1 CREATE D O M A I N tipo F#C H A R( 5 ) ; 2 CREATE D O M A I N tipo P#C H A R( 6 ) ; 4 CREATE TABLE F ( t i p o F # F # , . . . ) ; 5 CREATE TABLE P ( t i p o P # P # , . . . ) ; 6 CREATE TABLE FP ( t i p o F # F#, t i p o P # P # , . . . ) ;


C odigo 2: Exemplo de dom nios usando DOMAIN.

Como dom nio n ao constitui uma tipagem forte e, portanto, n ao existe uma verica c ao de tipo verdadeira, exige-se muito cuidado ao us a-la. Por exemplo, dadas as deni c oes do c odigo [2], a opera c ao de SQL descrita no c odigo [3] n ao falhar a em nenhuma verica c ao de tipo, embora logicamente devesse falhar. Pode-se criar uma base de dados no sistema de gerenciamento de banco de dados atrav es da instru c ao CREATE DATABASE nome bd . Ela cria uma base da dados vazia. A partir da , a

SQL

13

1 SELECT 2 F R O M FP 3 W H E R E F# = P# ;


C odigo 3: Exemplo de falha de verica c ao de tipo em dom nios.

instru c ao necess aria para se criar tabelas, j a mostrada acima pela facilidade em seu uso e pelo seu car ater auto-explicativo, e CREATE TABLE nome (tipoColuna1 nomeColuna1, tipoColuna2 nomeColuna2, ) . Essa instru c ao pode ser passada com mais par ametros. Para mais informa c oes, consulte [MyS04]. Depois de criada uma tabela, pode-se alter a-la atrav es da instru c ao ALTERTABLE nome ADD tipoColuna nomeColuna . Ela inclui uma coluna ` a uma tabela j a existente. Para remover um coluna, basta trocar o ADD por DROP, que ser a visto mais adiante. Finalmente, o u ltimo dos mais importantes comandos de deni c ao de dados, e o DROP. Essa instru c ao permite excluir base de dados DROP DATABASE nome bd ou mesmo tabelas DROP TABLE nome inteiras. Para a exclus ao de simples registros, usa-se DELETE, que ser a explicado mais adiante.

4.2

Opera c oes de manipula c ao de dados

Como dito anteriormente, os tr es principais aspectos manipulativos de um banco de dados relacional s ao: restri c ao, proje c ao e jun c ao. Essas tr es opera c oes podem ser implementadas pela instru c ao SELECT. Abaixo tem-se alguns exemplos que comprovam essa id eia.

1 SELECT #F, #P , QDE 2 F R O M FP 3 W H E R E QDE < 1 5 0 ;



C odigo 4: Exemplo de restri c ao usando SELECT.

1 SELECT F#, NomeF 2 F R O M F ;



C odigo 5: Exemplo de proje c ao usando SELECT.

Note que o c odigo [5] acima pode ser simplicado como o c odigo [6] abaixo. ` Obs.: As vezes pode ser necess ario o uso de nomes qualicados para tirar a ambiguidade de refer encias ` a colunas, por exemplo: P.P#, FP.P#. Inclusive o * pode ser qualicado, como em F.*.

4.3

Opera c oes de Atualiza c ao

As principais opera c oes de atualiza c ao denidas pela SQL s ao a inser c ao (INSERT), atua interessante notar que a elimina liza c ao (UPDATE) e elimina c ao (DELETE) de registros. E c ao de tabelas possui uma diretiva especial (DROP) j a mencionada anteriormente em 4.1. O exemplo [8] abaixo pressup oes que j a exista uma tabela com o nome temp, com duas colunas, P# e PESO. Essa instru c ao insere nessa tabela n umeros de pe cas e pesos correspondentes a todas as pe cas vermelhas.

1 SELECT 2 F R O M F ;


C odigo 6: Exemplo de proje c ao simplicada usando SELECT.

1 SELECT F . F#, P#, NomeF 2 F R O M F , FP 3 W H E R E F . F# = FP . F# ;



C odigo 7: Exemplo de jun c ao usando SELECT.

O pr oximo exemplo, c odigo [9], atualiza o status de tidis is fornecedores em Paris, duplicandoo. A instru c ao DELETE, no exemplo 10, elimina todas as remessas correspondentes ` a pe ca P2. J a foi citado em [3.1] que pode-se criar vis oes no projeto de um banco de dados. Elas representam o n vel mais externo da arquitetura de um banco. Em SQL pode-se criar vis oes a partir da diretiva CREATE VIEW. A partir da , essa vis ao e tratada exatamente como uma tabela, mas que n ao est a implementada sicamente. Um exemplo de como criar um vis ao e de uma consulta de SQL sobre essa vis ao pode ser observada abaixo nos c odigos [11] e [12] respectivamente. interessante notar que qualquer altera E c ao sobre uma VIEW, afetar a diretamente a tabelea correspondente que est a sicamente implementada. Imagine a seguinte vis ao criada como mostra o c odigo [13]. A opera c ao de exclus ao executada na linha 6, e o mesmo que executar a opera c ao da linha 8 sobre a tabela pai da vis ao.

4.4

Sum ario das instru c oes SQL

As instru c oes mais comuns usadas em SQL e mencionadas anteriormente nesse documento s ao: CREATE DOMAIN, CREATE TABLE, CREATE DATABASE, CREATE VIEW, ALTER DOMAIN, ALTER TABLE, ALTER VIEW, INSERT, UPDATE, DELETE, DROP DOMAIN, DROP TABLE, DROP VIEW, DROP DATABASE. Segue abaixo uma rela c ao resumida e simplicada das palavras reservadas denidas pelo padr ao SQL. Do padr ao SQL2 de 1992, dentre outras mais comuns, tem-se: AFTER, ALIAS, ASYNC, BEFORE, BOOLEAN, BREADTH, COMPLETION, CALL, CYCLE, DATA, BETWEEN, BIT, BIT LENGTH, BOTH, CASCADE, CASCADED, CASE, CAST, CATALOG, CHAR LENGTH, CHARACTER LENGTH, COALESCE, COLLATE, COLLATION, COLUMN, CONNECT, CONNECTION, CONSTRAINT, CONSTRAINTS, CONVERT, CORRESPONDING, CROSS, CURRENT DATE, CURRENT TIME, CURRENT TIMESTAMP, CURRENT USER, DATE, DAY, DEALLOCATE, DEFERRABLE, DEFERRED, DESCRIBE, DEPTH, DICTIONARY, EACH, ELSEIF, EQUALS, GENERAL, IF, IGNORE, LEAVE, DESCRIPTOR, DIAGNOSTICS, DISCONNECT, DOMAIN, DROP, ELSE, END-EXEC, EXCEPT, EXCEPTION, EXECUTE, EXTERNAL, EXTRACT, FALSE, FIRST, FULL, GET, GLOBAL, HOUR, IDENTITY, IMMEDIATE, INITIALLY, INNER, INPUT, INSENSITIVE, INTERSECT, INTERVAL, ISOLATION, JOIN, LAST, LEADING, LEFT, LEVEL, LOCAL, LOWER, MATCH, MINUTE, MONTH, NAMES, NATIONAL, LESS, LIMIT, LOOP, MODIFY, NEW, NONE, OBJECT, OFF, OID, OLD, NATURAL, NCHAR, NEXT, NO, NULLIF, OCTET LENGTH, ONLY, OUTER, OUTPUT, OPERATION, OPERATORS, OTHERS, PARAMETERS, PENDANT, PREORDER, PRIVATE, OVERLAPS, PAD, PARTIAL, POSITION, PREPARE, PRE-

1 INSERT 2 INTO temp ( 3 SELECT 4 F R O M 5 W H E R E



P#, PESO ) P#, PESO P COR = Vermelha ; C odigo 8: Exemplo de INSERT.

1 UPDATE F 2 SET STATUS = STATUS 2 3 W H E R E CIDADE = P a r i s ;



C odigo 9: Exemplo de UPDATE.

SERVE, PRIOR, READ, PROTECTED, RECURSIVE, REF, REFERENCING, REPLACE, RESIGNAL, RETURN, RELATIVE, RESTRICT, REVOKE, RIGHT, ROWS, SCROLL, SECOND, SESSION, RETURNS, ROLE, ROUTINE, ROW, SAVEPOINT, SEARCH, SENSITIVE, SEQUENCE, SESSION USER, SIZE, SPACE, SQLSTATE, SUBSTRING, SYSTEM USER, SIGNAL, SIMILAR, SQLEXCEPTION, SQLWARNING, STRUCTURE, TEST, THERE, TEMPORARY, THEN, TIME, TIMESTAMP, TIMEZONE HOUR, TIMEZONE MINUTE, TRAILING, TRANSACTION, TRANSLATE, TRANSLATION, TRIM, TRUE, UNKNOWN, TRIGGER, TYPE, UNDER, VARIABLE, VIRTUAL, VISIBLE, WAIT, WHILE, UPPER, USAGE, USING, VALUE, VARCHAR, VARYING, WHEN, WRITE, YEAR, WITHOUT, ABSOLUTE, ACTION, ADD, ALLOCATE, ALTER, ARE, ASSERTION, AT, ZONE. Do padr ao SQL3 de 1998, dentre outras mais comuns, tem-se: ACTION, ACTOR, AFTER, ALIAS, ASYNC, ATTRIBUTES, BEFORE, BOOLEAN, BREADTH, COMPLETION, CURRENT PATH, CYCLE, DATA, DEPTH, DESTROY, DICTIONARY, EACH, ELEMENT, ELSEIF, EQUALS, FACTOR, GENERAL, HOLD, IGNORE, INSTEAD, LESS, LIMIT, LIST, MODIFY, NEW, NEW TABLE, NO, NONE, OFF, OID, OLD, OLD TABLE, OPERATION, OPERATOR, OPERATORS, PARAMETERS, PATH, PENDANT, POSTFIX, PREFIX, PREORDER, PRIVATE, PROTECTED, RECURSIVE, REFERENCING, REPLACE, ROLE, ROUTINE, ROW, SAVEPOINT, SEARCH, SENSITIVE, SEQUENCE, SESSION, SIMILAR, SPACE, SQLEXCEPTION, SQLWARNING, START, STATE, STRUCTURE, SYMBOL, TERM, TEST, THERE, TRIGGER, TYPE, UNDER, VARIABLE, VIRTUAL, VISIBLE, WAIT, WITHOUT, CALL, DO, ELSEIF, EXCEPTION, IF, LEAVE, LOOP, OTHERS, RESIGNAL, RETURN, RETURNS, SIGNAL, TUPLE, WHILE.

Exemplo
Apenas algumas deni c oes interessantes:

Nome do servidor: Nome do cliente:

mysqld ou mysqld.exe; myslq ou mysql.exe.

Um exemplo de um comando t pico para iniciar o cliente e: c:\mysql\bin\mysql -h nome.do.host -u nomeDoUsuario -p nomeDaBaseDeDados Onde:

EXEMPLO

16

1 DELETE 2 F R O M FP 3 W H E R E P# = P2 ;


C odigo 10: Exemplo de DELETE.

1 CRETE VIEW b o m f o r n e c e d o r 2 AS SELECT F#, STATUS , CIDADE 3 F R O MF 4 W H E R E STATUS > 1 5 ;



C odigo 11: Exemplo de CREATE VIEW.

nome.do.host e o endere co do computador que est a rodando o servidor; nomeDoUsuario e o nome do usu ario; nomeDaBaseDeDados e o nome da base de dados que ser a usada; -p e a op c ao que exige um prompt para a senha do usu ario. De um modo mais simple ainda, basta o comando: mysql},para que se tenha a seguinte conex ao observada na gura [5]. Note que a conex ao se fez, por padr ao, com os seguinte atributos: usu ario, minasi - quem executou o programa; host, como nenhum argumento foi passado na chamada do programa, localhost ; dentre outros.

Figura 5: Tela ap os a simples execu c ao de um cliente SQL e seu status. A partir do prompt fornecido pelo programa cliente, pode-se fazer qualquer solicita c ao SQL, criar-se novas tabelas, base de dados (note que a e necess ario que se tenha permiss ao para tal), assim como elimin a-las, fazer consultas, inser c oes, atualiza c oes e etc. Al em disso, pode-se visualizar o banco de dados atrav es de alguns comandos bem u teis:

1 SELECT F#, STATUS 2 F R O M bom fornecedor 3 W H E R E CIDADE = Londres ;



C odigo 12: Exemplo de uma consulta sobre uma VIEW.

1 CREATE VIEW t e s t e 2 AS SELECT #EMP, Nome Emp , S a l a r i o 3 F R O M EMP 4 W H E R E S a l a r i o > 3K ; 6 DELETE F R O M teste W H E R E S a l a r i o < 5K ; 8 DELETE F R O M EMP W H E R E ( S a l a r i o > 3K && S a l a r i o < 5K ) ;


C odigo 13: Exemplo de elimina c ao de registro na VIEW e suas implica c oes na tabela real.

show databases; mostra todas as bases de dados do servidor que se tenha acesso. O comando mysqlshow funciona da mesma forma s o que este e executado no shell padr ao, n ao no do cliente. use baseDeDadosX; congura a base de dados a ser utilizada. Normalmente, ap os a instala c ao, existem duas pr e-denidas: mysql - que possui as permiss oes, usu arios, etc. - e a test - base para testes que qualquer usu ario pode alterar. show tables; mostra todas as tabelas da dase de dados congurada para uso. Note que antes e necess ario que se execute a instru c ao usebaseDeDadosX; . O comando mysqlshowbaseDeDadosX funciona da mesma forma, mas e executado no shell padr ao. describe tabelaX; descreve como s ao cada campo de uma tabela, quais s ao seus tipos, seus tamanhos, quais campos comp oem a chave-prim aria, etc. help mostra a ajuda. Um outro comando, o mysqladmin, chama um programa diferente do cliente SQL. Esse programa e usado para administrar v arios aspectos do servidor de banco de dados MySQL. Informa c oes mais detalhadas a esse respeito podem ser obtidas em: http://dev.mysql.com/techresources/articles/mysql intro.html#SECTION0005000000. Para nalizar, mostra-se abaixo dois exemplos de consultas SQL: a primeira executada na prompt do cliente mysql, enquanto que a segunda e executada como um comando normal no shell padr ao. SELECT* FROM tabelaX; mysql-e SELECT * FROM tabelaXbaseDeDadosY

APIs - Application Program Interfaces

As APIs, ou Interfaces para Programas de Aplica c ao, permite que instru c oes SQL estejam embutidas dentro de programas em linguagens comuns de programa c ao, como C++, Java, PHP, etc. Por isso mesmo, as APIs s ao tamb em referenciadas como SQL Embutida.

Existem tamb em refer encias para SQL Din amica, que nada mais e do que um conjunto de recursos embutidos de SQL que se destinam a oferecer suporte ` a constru c ao de aplica c oes generalizadas, on-line e possivelmente interativas.

6.1

Java

Destinado ao m anteriormente exposto, existe em Java um pacote chamado java.sql que permite executar as funcionalidades da SQL Embutida. Segundo a pr opria p agina de documenta c ao do pacote, ele fornece uma API para acesso e processamento dos dados gravados em uma fonte de dados (usualmente um banco de dados relacional) usando a linguagem de programa c ao JavaTM . Para acessar essa p agina, basta seguir o ponteiro http://java.sun.com/j2se/1.4.2/docs/api/index.html. Um exemplo interessante de como executar uma query em JavaTM e mostrado abaixo no c odigo [14]. O exemplo foi obtido do ponteiro http://www.ils.unc.edu/ lindgren/190/mysql-jdbc/. Ele possui um inconveniente que e a utiliza c ao de um JDBC3 driver muito espec co - da Terrance Zellars - para a comunica c ao com o banco de dados. Um JDBC driver GPL fornecido pela MySQL AB, e portanto mais con avel, e o MySQL Connector/J. Ele e o driver JDBC ocial para o MySQL. Mais informa c oes sobre o driver pode ser obtida em http://www.mysql.com/products/connector/j/. Pode-se baix a-lo gratuitamente em http://dev.mysql.com/downloads/connector/j/3.0.html

6.2

C++

Programas escritos na linguagem C++ que necessitem das funcionalidades da SQL embutida podem utilizar-se da API fornecida no ponteiro http://mysqlcppapi.sourceforge.net/. Um exemplo da utiliza c ao dessa API pode ser observado no c odigo [6.2] abaixo.

Estudo comparativo entre MySQL e PostgreSQL

Como dito na introdu c ao desse documento, uma an alise mais profunda comparando os bancos de dados dispon veis no mercado se faz bastante necess aria. Principalmente entre os dois mais comuns, MySQL [MySb] e PostgreSQL [Pos], e o considerado o mais eciente, o Oracle [Ora]. Assim, apenas para ilustrar como a performance do MySQL, que foi a base deste documento, e relativamente boa quando comparada com o Oracle 9i, mostra-se as guras [6] e [7] abaixo.

Refer encias
[C. 00] [E. 72] C. J. Date. Introdu c ao a Sistemas de Bancos de Dados. Editora Campus, tradu c ao da s etima edi c ao americana edition, 2000. 1, 4.1 E. F. Codd. further normalization of the data base relational model. Data Base Systems, Courant Computer Science Symposia Series 6, 1972. 3.2

[MySa] Instala c ao do mysql. Internet, http://dev.mysql.com/doc/#Installing. 1.1 [MySb] Mysql. Internet, http://www.mysql.org/. 1.1, 7 [MyS04] MySQL A.B. MySQL Reference Manual. MySQL http://dev.mysql.com/get/Downloads/Manual/manualA.B, a4.pdf/from/http://www.linorg.usp.br/mysql/, 1997-2004. 4.1
JDBC (Java Database Connectivity), de acrodo com a JavaSofts em http://www.javasoft.com/products/jdbc/overview.html, A API JDBC dene classes Java para representar conex oes com banco de bados, declara c oes SQL, etc..
3

 REFERENCIAS
Fonte: eWeek em Server Databases Clash

19

Figura 6: Benchmark de banco de dados: p aginas da web retornadas por segundo. [Ora] [Pos] Oracle. Internet, http://www.oracle.com/database/. 7 Postgresql. Internet, http://www.postgresql.org/. 1.1, 7

 REFERENCIAS

20

Fonte: eWeek em Server Databases Clash

Figura 7: Benchmark de banco de dados: as respostas mais r apidas.

 REFERENCIAS

21

1 import j a v a . s q l . ; 2 import twz1 . j d b c . mysql . ; 4 public c l a s s TestQuery { 6 7 9 11 12 13 14 15 17 18 19 20 21 22 23 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 }



public TestQuery ( ) { } public s t a t i c void main ( S t r i n g a r g s [ ] ) { S t r i n g u r l= j d b c : z1MySQL : / / l u n a . o i t . unc . edu /CES? u s e r=alexadmin ; Connection con ; S t r i n g query = SELECT FROM a l e x c o u r s e ; Statement stmt ; try { C l a s s . forName ( twz1 . j d b c . mysql . j d b c M y s q l D r i v e r ) ; } catch ( j a v a . l a n g . ClassNotFoundException e ) { System . e r r . p r i n t ( ClassNotFoundException : ) ; System . e r r . p r i n t l n ( e . getMessage ( ) ) ; } try { System . out . p r i n t l n ( Trying t o c o n n e c t . . . ) ; con = DriverManager . g e t C o n n e c t i o n ( u r l , alexadmin , x ) ; System . out . p r i n t l n ( c o n n e c t e d ! ) ; stmt = con . c r e a t e S t a t e m e n t ( ) ; R e s u l t S e t r e s u l t = stmt . executeQuery ( query ) ; while ( r e s u l t . next ( ) ) { S t r i n g name = r e s u l t . g e t S t r i n g ( 1 ) + + result . getString (2); System . out . p r i n t l n ( name ) ; } stmt . c l o s e ( ) ; con . c l o s e ( ) ; } catch ( SQLException ex ) { System . e r r . p r i n t ( SQLException : ) ; System . e r r . p r i n t l n ( ex . getMessage ( ) ) ; } }

C odigo 14: Exemplo de SQL Embutida com API para Java.

 REFERENCIAS

22

1 #include < mysqlcppapi / mysqlcppapi . h> 2 #include < i o s t r e a m > 3 #include < iomanip> 5 6 7 8 9 10 11 12 13 14 15 17 18 20 21 22 24 25 27 28 29 31 33 34 35 36 37 38 39 41 42 43 44 45 46 47 48 49 50 51 52 53 int main ( ) { // The f u l l fo r m a t f o r t h e Connection c o n s t r u c t o r i s // Connection ( c c h a r db , c c h a r h o s t =, // c c h a r u s e r =, c c h a r passwd =) // You may need t o s p e c i f y some o f them i f t h e d a t a b a s e i s not on // t h e l o c a l machine or your d a t a b a s e username i s not t h e same as // your l o g i n name , e t c . . try { mysqlcppapi : : Connection con ; con . c o n n e c t ( ) ; con . s e l e c t d a t a b a s e ( m y s q l c p p d a t a ) ; mysqlcppapi : : Query query = con . c r e a t e Q u e r y ( ) ; // This c r e a t e s a q u e r y o b j e c t t h a t i s bound t o con . query << s e l e c t from s t o c k ; // You can w r i t e t o t h e q u e r y o b j e c t l i k e you would any o t h e r // ostrem mysqlcppapi : : R e s u l t S t o r e r e s = query . s t o r e ( ) ; // Query : : s t o r e ( ) e x e c u t e s t h e q u e r y and r e t u r n s t h e r e s u l t s c o u t << Query : << query . p r e v i e w () << e n d l ; // Query : : p r e v i e w ( ) s i m p l y r e t u r n s a s t r i n g w i t h t h e c u r r e n t // q u e r y s t r i n g i n i t . c o u t << Records Found : << r e s . s i z e () << e n d l << e n d l ; cout . s e t f ( i o s : : l e f t ) ; c o u t << setw (17) << Item << setw ( 4 ) << Num << setw ( 7 ) << Weight << setw ( 7 ) << P r i c e << Date << e n d l << e n d l ; // The R e s u l t S t o r e c l a s s has a reado n l y Random Access // I t e r a t o r f o r ( mysqlcppapi : : R e s u l t S t o r e : : i t e r a t o r i = r e s . b e g i n ( ) ; i ! = r e s . end ( ) ; i ++) { mysqlcppapi : : Row row = i ; c o u t << setw (17) << row [ 0 ] << setw ( 4 ) << row [ 1 ] << setw ( 7 ) << row [ w e i g h t ] // you can use e i t h e r t h e i n d e x number or column // name when r e t r i e v i n g t h e colume d a t a as // d e m o n s t r a t e d above . << setw ( 7 ) << row [ 3 ]

 REFERENCIAS

23

53 54 55 56 57 58 59 60 62 63 64 65 66 67 68 69 70 71 72 73 }


<< row [ 4 ] < < e n d l ; } } catch ( mysqlcppapi : : ex BadQuery& e r ) { // h a n d l e any c o n n e c t i o n or q u e r y e r r o r s t h a t may come up c e r r << E r r o r : << e r . what () << e n d l ; return 1 ; } catch ( mysqlcppapi : : ex BadConversion & e r ) { // we s t i l l need t o c a t c h bad c o n v e r s i o n s i n c a s e s o m e t h i n g // g o e s wrong when t h e d a t a i s c o n v e r t e d i n t o s t o c k c e r r << E r r o r : T r i e d t o c o n v e r t \ << e r . g e t D a t a () << \ t o a \ << e r . get TypeName () << \ . << e n d l ; return 1 ; } return 0 ;

C odigo 15: Exemplo de SQL Embutida com API para C++.