Seminário S2i: Banco de Dados - MySQL e PostgreSQL

Transcrição

1 Seminário S2i: Banco de Dados - MySQL e PostgreSQL Marcelo Moraes Minasi Florianópolis, 26 de abril de Lista de Tabelas 1 Tabela do fornecedor Tabela das peças Tabela do relacionamento entre fornecedores e peças Dependências: um caso errado e outro correto Tabela do fornecedor Tabela da variável SEGUNDA e FP Tabela da variável FC e CS Lista de Figuras 1 Componentes de um sistema de banco de dados Relacionamento como entidade Primeira ilustração da arquitetura de três níveis Segunda ilustração da arquitetura de três níveis Tela após a simples execução de um cliente SQL e seu status Benchmark de banco de dados: páginas da web retornadas por segundo Benchmark de banco de dados: as respostas mais rápidas Códigos 1 O banco de dados de fornecedores e peças (definição dos dados) Exemplo de domínios usando DOMAIN Exemplo de falha de verificação de tipo em domínios Exemplo de restrição usando SELECT Exemplo de projeção usando SELECT Exemplo de projeção simplificada usando SELECT Exemplo de junção 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ção de registro na VIEW e suas implicações na tabela real Exemplo de SQL Embutida com API para Java Exemplo de SQL Embutida com API para C

2 Sumário 1 Introdução Instalação Conceituação básica 3 3 Projeto Arquitetura Formas normais SQL Operações de definição Operações de manipulação de dados Operações de Atualização Sumário das instruções SQL Exemplo 15 6 APIs - Application Program Interfaces Java C Estudo comparativo entre MySQL e PostgreSQL 18

3 1 Introdução Esse documento foi fortemente baseado na referência [C. 00]. Tenta-se dar uma boa base dos conceitos iniciais envolvendo bando de dados e do padrão SQL, mostrando-se, no final, um exemplo, uma simples comparação (benchmark) envolvendo alguns sistemas de bancos de dados e algumas APIs - application program interface. Um interessante trabalho posterior seria algumas ferramentas gráficas para construção de um banco de dados e uma melhor comparação de alguns sistemas de bancos de dados, como MySQL, PostreSQL, etc. 1.1 Instalação Assume-se aqui que o leitor conseguiu instalar perfeitamente um servidor de banco de dados onde possa criar bancos e modificá-los, como também executar buscas exemplificadas nesse documento através de query da SQL. Como a instalação varia conforme o sistema operacional, indica-se aqui apenas alguns ponteiros para páginas de instalação de dois dos mais usados programas para sistemas de gerenciamento de banco de dados: MySQL [MySb] na referência [MySa] e PostgreSQL em [Pos]. Outra referência interessante para instalação do MySQL [MySb] é: /c/a/mysql/mysql-installation-and-configuration/. Após a instalação, algumas rotinas ainda precisam ser executadas, para maiores detalhes, veja o ponteiro: post-installation.html. 2 Conceituação básica Sistema de Banco de Dados é 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ários (programadores de aplicação, usuários finais e DBA - Administrador). Tais registros são as linhas de uma tabela, cujas colunas são os dados. Essa tabela é um arquivo computadorizado. Figura 1: Componentes de um sistema de banco de dados. Um banco de dados é uma coleção de dados persistentes (não que eles durem para sempre, mas diferem de entradas, saídas, etc.) utilizada pelos sistemas de aplicação.

4 2 CONCEITUAÇÃO BÁSICA 4 Sua utilização possui as seguintes vantagens: compartilhamento de dados, redundância controlada (reduzida), inconsistência controlada, suporte a transações (operações atômicas: tudo ou nada, ou atualiza todas as tabelas necessárias, ou nenhuma; que em conjunto com o log implica consistência), integridade (restrições de integridade, por exemplo, idade 0), maior segurança (senhas), aplicações independente de dados, etc. Uma tabela (variável de relação) contém os dados relativos a um conjunto de entidades idênticas (livro, tema, leitor e requisição). Cada linha (tuplo) caracteriza uma entidade desse conjunto. Cada coluna (atributo) representa uma característica dessa entidade. Cada tabela apresenta um identificador único, chamado de chave primária. Nem sempre é vantagem acrescentar mais um campo designado a ser essa chave (como uma numeração seqüencial e cíclica), pois essa pode ser limitada pelo tamanho do tipo de dado desse campo. Assim, ela pode ser constituída de vários dados agrupados da tabela. Por exemplo, o BD da Eletrosul apresenta de registros mensais! As entidades são composta por registros, que são instâncias daquele tipo, por exemplo: a entidade carro pode possuir os registros carroa, carrob, Monza etc. Além de entidades, normalmente num banco de dados, haverá relacionamentos entre entidades, que segundo o paradigma relacional, também são representadas em tabelas. Observe a figura [2]. Isso será melhor explicado mais abaixo. A seguir, apresenta-se alguns conceitos básicos no contexto de banco de dados: Chave primária é um identificador único para cada tuplo de uma tabela. Cada tabela deve ter uma chave primária. Uma chave primária pode ser constituída por um ou mais atributos. Chave estrangeira é a utilização da chave primária numa outra tabela para se poder criar um relacionamento. Transação é uma unidade lógica de trabalho (atômicas). Figura 2: Relacionamento como entidade. #Fornecedor NomeF 1 A 2 B Tabela 1: Tabela do fornecedor. #Peça NomeP 1 Parafuso 2 Prego Tabela 2: Tabela das peças. Bancos de dados relacionais são sistemas de banco de dados baseados em uma fundamentação normal (teórica) chamada de modelo relacional de dados, que apresenta três aspectos: Aspecto estrutural: os dados são representados por tabelas, e só tabelas - propriedade de fechamento: a saída de uma operação é também uma tabela, o que garante que a saída de uma operação pode ser a entrada de outra.

5 #Peça #Fornecedor Qtdade Tabela 3: Tabela do relacionamento entre fornecedores e peças. Aspecto de integridade: essas tabelas satisfazem a certas condições de integridade; Aspecto manipulativo: os operadores disponívies para manipular tabelas derivam umas de outras - os três mais importantes são: Restrição (DEPTOs nos quais ORÇAMENTO > R$8 milhões), Projeção (DEPTOs sobre #DEPTO, ORÇAMENTO) e Junção (DEPTOs e EMPREGADOs sobre #DEPTO). Aqueles registros devem sofrer algum tipo de operação 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ão todos expressos em uma linguagem chamada SQL. Ela será melhor explicada mais abaixo [4]. 3 Projeto 3.1 Arquitetura Geralmente, o projeto de um BD se dá em três níveis, como observado nas figuras [3] e [4]: 1. Interno (físico): como os dados são fisicamente armazenados (número de bytes de cada campo, etc.); 2. Externo (lógico do usuário): como os dados são vistos por cada usuário individualmente. CREATE VIEW teste AS (EMP WHERE SALÁRIO > 3K) { #EMP, NOMEEMP, SALÁRIO } ; 3. Conceitual (lógico comunitário): intermediário entre os dois. Na concepção de um BD, tanto a Linguagem de definição de dados (DDL), como ilustrado no código [1], como a linguagem de manipulação de dados (DML) são transparentes para o usuário. 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ção é apenas uma formalização de uma idéia simples e muito usada na prática. Idéia que consiste em fazer um projeto de banco de dados seguindo o paradigma um fato em um lugar, isto é, evitar redundância. Além disso, a normalização nos ajuda a estruturar o banco de dados de forma a tornar mais fácil as atualizações de uma única tupla do que seria caso esse banco não estivesse normalizado.

6 3 PROJETO 6 1 TYPE #F... ; 2 TYPE NOME... ; 3 TYPE #P... ; 4 TYPE QTD... ; 6 VAR F BASE RELATION 7 { #F #Fornecedor, 8 NOME NomeF } 9 PRIMARY KEY { # Fornecedores } ; 11 VAR P BASE RELATION 12 { #P #Peca, 13 NOME NomeP } 14 PRIMARY KEY { # Peca } ; 16 VAR FP BASE RELATION 17 { #F #Fornecedor, 18 #P #Peca, 19 QTD Qtdade } 20 PRIMARY KEY {# Fornecedor, # Peca } 21 FOREIGN KEY { # Fornecedor } REFERENCES F 22 FOREIGN KEY { # Peca } REFERENCES P ; Código 1: O banco de dados de fornecedores e peças (definição dos dados). Algumas variáveis poderiam, mesmo estando normalizadas - no sentido do parágrafo anterior - possuírem propriedades indesejáveis. É justamente nesse sentido que vêm os princípios de normalização avançada, ou formas normais. Esses princípios nos permitem reconhecer esses casos e substituir essas variáveis por outras mais desejáveis de algum modo. Dizemos que uma variável está em uma forma normal se ela satisfaz a um certo conjunto prescrito de condições. Por exemplo, dizemos que uma variável de relação - que modela um relacionamento - está na segunda forma normal (2FN) se, e somente se, ela está em 1FN e também satisfaz uma outra determinada condição, descrita mais abaixo em 3.2. Numerosas formas normais foram definidas por volta de As três primeiras por Codd em [E. 72]. Mais tarde, Boyce e Codd definiram também uma outra terceira forma normal, mais abrangente, conhecida como forma normal de Boyce/Codd (FNBC). Subsequentemente, Fagin definiu ainda a quarta e a quinta formas normais. A referência [E. 72] definiu também um procedimento de normalização, através do qual uma variável de relação que está em alguma forma normal específica pode ser substituída por um conjunto de variáveis de relação em alguma forma mais desejada. Esse procedimento é reversível, o que significa que o processo de normalização preserva informações. Embora existam outras formas normais além dessas seis, esse documento abrangerá apenas as três primeiras, visto que a implementação de um banco de dados projetado de forma que suas variáveis estejam na 3FN é uma boa solução de compromisso entre a complexidade dos procedimentos de normalização subsequentes e o nível de características desejadas obtidas (baixa redundância, integridade, etc.). O processo de normalização consiste em decompor uma variável de relação em outras variáveis mais desejadas. Esse processo deve ser necessariamente ser perdas, i. e. reversível.

7 3 PROJETO 7 Figura 3: Primeira ilustração da arquitetura de três níveis. Figura 4: Segunda ilustração da arquitetura de três níveis. Para que uma decomposição 1 sem perdas seja realizada, e assim seja possível recompor 2 o conjunto de informações, precisa-se respeitar o conceito de dependência funcional descrito a seguir. Para entender melhor a importância do conceito de dependência funcional, imagine o seguinte problema: se R1 e R2 são projeções de alguma variável de relação R, e se R1 e R2 em conjunto incluem todos os atributos de R, que condições devem ser satisfeitas para garantir que a junção de R1 e R2 nos dará de volta a variável de relação original R? Ver exemplo na tabela [4] abaixo. É aqui que entram as dependências funcionais. Seja R uma variável de relação, e sejam X e Y subconjuntos arbitrários do conjunto de atributos de R. Então, dizemos que Y é funcionalmente dependente de X em símbolos, X Y, ( X seta Y ), se e somente se em todo valor válido de R, cada valor X tem associado a ele exatamente um valor Y. Em outras palavras, em todo valor possível válido de R, sempre que 1 O operador da decomposição na álgebra relacional é, na verdade, o de projeção. 2 O operador da recomposição na álgebra relacional é, na verdade, o de junção.

8 3 PROJETO 8 #Fornecedor STATUS CIDADE F3 30 Paris F5 30 Atenas Caso correto #Fornecedor STATUS #Fornecedor CIDADE F3 30 F3 Paris F5 30 F5 Atenas Caso errado #Fornecedor STATUS STATUS CIDADE F Paris F Atenas Tabela 4: Dependências: um caso errado e outro correto. duas tuplas concordam sobre seu valor X, elas concordam também sobre seu valor Y. Todo conjunto de DFs dependências funcionais é equivalente a pelo menos um conjunto irredutível. Se I é um conjunto irredutível equivalente a S, a imposição das DFs em I imporá automaticamente as DFs em S. Defini-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ém apenas um atributo; 2. O lado esquerdo (o determinante) de cada DF em S é por sua vez irredutível - significando que nenhum atributo pode ser descartado do determinante sem converter S em algum conjunto não equivalente a S; 3. Nenhuma DF em S pode ser descartada de S sem converter S em em algum conjunto não equivalente a S. Existem Diagramas DF que representam convenientemente essas dependências. Isso é interessante porque as DFs possuem uma noção semântica, cuja interpretação só depende do projetista. Por exemplo, #F CIDADE significa que cada fornecedor está localizado em exatamente uma cidade. Apenas para se ter uma noção do ponto que se deseja atingir, descreve-se informalmente o que seria a terceira forma normal (3FN). Terceira forma normal: uma variável está na 3FN se e somente se os atributos não-chaves (qualquer atributo que não participa da chave-primária da variável de relação) são: Mutuamente independentes, i. e., se nenhum deles é funcionalmente dependentes de qualquer combinação dos outros; Irredutivelmente dependentes da chave primária. 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ção. Antes, a definição da primeira forma normal: Primeira forma normal: uma variável de relação está em 1FN se, e somente se, em todo valor válido dessa variável de relação, cada tupla contém exatamente um valor para cada atributo.

9 3 PROJETO 9 Por exemplo: PRIMEIRA { #F, STATUS, #P, QDE, CIDADE } PRIMARY KEY { #F, #P } ; #F STATUS CIDADE #P QDE F1 20 Londres P1 300 F1 20 Londres P2 200 F1 20 Londres P3 400 F1 20 Londres P4 200 F1 20 Londres P5 100 F1 20 Londres P6 100 F2 10 Paris P1 300 F2 10 Paris P2 400 F3 10 Paris P2 200 F4 20 Londres P2 200 F4 20 Londres P4 300 F4 20 Londres P5 400 Tabela 5: Tabela do fornecedor. A principal desvantagem é a quantidade excessiva de redundâncias, que são também chamadas de anomalias de atualização. No exemplo acima, não dá para inserir a informação de que um determinado fornecedor está numa cidade específica até que ele efetivamente forneça pelo menos uma peça. E se eliminarmos uma tupla da tabela acima, eliminaremos talvez muito mais informações que gostaríamos. Para solucionar, utiliza-se o processo de normalização, que informalmente pode ser entendido agora como uma processo de desempacotamento: inserir informações logicamente isoladas em variáveis de relações separadas. Assim, a solução 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 ficar claro que essa estrutura resolve todos os problemas com operações de atualização descritos anteriormente. Segunda forma normal: uma variável está na 2FN se e somente se ela está na 1FN e todo atributo não-chave é irredutivelmente dependente da chave primária. Mas a estrutura SEGUNDA ainda sofre pela falta de independência mútua entre seus atributos não-chaves. Mais detalhadamente, a dependência de STATUS sobre #F, embora seja funcional e, de fato, irredutível, é transitiva (através de CIDADE): cada valor de #F determina uma CIDADE e esta, por sua vez, determina o valor de STATUS. Dependências transitivas levam também a anomalias de atualização. Mais uma vez a solução é desempacotar, transformar a variável SEGUNDA em:

10 3 PROJETO 10 SEGUNDA #F STATUS CIDADE F1 20 Londres F2 10 Paris F3 10 Paris F4 20 Londres F5 30 Atenas FP #F #P QDE F1 P1 F1 P2 F1 P3 F1 P4 F1 P5 F1 P6 F2 P1 F2 P2 F2 P3 F3 P2 F4 P2 F4 P4 F4 P5 Tabela 6: Tabela da variável 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ável está na 3FN se e somente se ela está em 2FN e todo atributo não-chave é dependente de forma não transitiva da chave primária. Uma observação importante a ser feita é que o nível de normalização de uma variável de uma relação dada é uma questão de semântica, não apenas uma questão de valores de dados que essa variável de relação 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ções: 1. Dada a variável de relação R como esta: (Para reduzir dependências, redundâncias triviais) R { A, B, C, D } PRIMARY KEY { A, B } ; Deve-se substituir R por suas duas projeções R1 e R2:

11 FC #F CIDADE F1 Londres F2 Paris F3 Paris F4 Londres F5 Atenas CS CIDADE STATUS Atenas 30 Londres 20 Paris 10 Tabela 7: Tabela da variável 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ável de relação R como esta: (Para reduzir dependências transitivas, e.g. A B e B C) R { A, B, C } PRIMARY KEY { A } ; Deve-se substituir R por suas duas projeções R1 e R2: R1 { B, C } PRIMARY KEY{ B } ; R2 { A, B } PRIMARY KEY { A } FOREIGN KEY { B } REFERENCES R1 ; 4 SQL A SQL é uma linguagem padrão para interação com banco de dados relacionais. Originalmente, o nome SQL significava Structured Query Language (Linguagem de Consulta Estruturada) e se pronunciava sequel. Porém, agora a linguagem se transformou num padrão, e o seu nome agora é apenas um nome - não é oficialmente uma abreviatura para alguma coisa - e a pronúncia pendeu para esse-quê-éle. Seu nome oficial é International Standard Database Language SQL (1992), largamente referenciada na literatura por SQL/92 ou SQL2, que foi a grande revisão do padrão proposto segundo o padrão SQL. Posteriormente, teve-se um desenvolvimento da SQL2 para a SQL3, no que concerne ao suporte a objetos. Mais informações a respeito do suporte a objetos podem ser obtidas no seguinte ponteiro: Conceitualmente, SQL é um padrão relacional, i.e., não-procedural (nível de abstração maior que C++, por exemplo): não se indica como mas o quê se quer. A tarefa de como executar é definida pelo otimizador do SGBD. Um tutorial de SQL pode ser obtido em: Tour-of-MySQL/. Uma simples referência de quais diretivas são padronizadas e suas sintaxes pode ser obtidas facilmente em

12 4 SQL 12 Uma referência excelente para que deseja saber mais sobre SQL é o ponteiro Ele possui uma ferramenta interativa para se contruir declarações SQL e testá-las sobre diferentes bancos de dados. 4.1 Operações de definição Na SQL3 é possível definir-se domínios próprios do usuário, na SQL2 não. Aqui, os domínios serão considerados como tipos, mas uma discussão um pouco mais profunda mostra que eles estão longe de serem a mesma coisa, como mostra o capítulo 4 de [C. 00]. Os tipos internos permitidos pela SQL são: 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ão são tipos verdadeiros. Em SQL, eles servem apenas para permitir que um tipo embutido, já definido, receba um nome que possa ser usado como abreviação por várias colunas em diversas definições de tabelas. Um exemplo de domínios podem ser vistos no código [2]. 1 CREATE DOMAIN tipo F # CHAR( 5 ) ; 2 CREATE DOMAIN tipo P # CHAR( 6 ) ; 4 CREATE TABLE F ( tipo F # F #,... ) ; 5 CREATE TABLE P ( tipo P # P #,... ) ; 6 CREATE TABLE FP ( tipo F # F#, tipo P # P #,... ) ; Código 2: Exemplo de domínios usando DOMAIN. Como domínio não constitui uma tipagem forte e, portanto, não existe uma verificação de tipo verdadeira, exige-se muito cuidado ao usá-la. Por exemplo, dadas as definições do código [2], a operação de SQL descrita no código [3] não falhará em nenhuma verificação de tipo, embora logicamente devesse falhar. Pode-se criar uma base de dados no sistema de gerenciamento de banco de dados através da instrução CREATE DATABASE nome bd. Ela cria uma base da dados vazia. A partir daí, a

13 4 SQL 13 1 SELECT 2 FROM FP 3 WHERE F# = P# ; Código 3: Exemplo de falha de verificação de tipo em domínios. instrução necessária para se criar tabelas, já mostrada acima pela facilidade em seu uso e pelo seu caráter auto-explicativo, é CREATE TABLE nome (tipocoluna1 nomecoluna1, tipocoluna2 nomecoluna2, ). Essa instrução pode ser passada com mais parâmetros. Para mais informações, consulte [MyS04]. Depois de criada uma tabela, pode-se alterá-la através da instrução ALTERTABLE nome ADD tipocoluna nomecoluna. Ela inclui uma coluna à uma tabela já existente. Para remover um coluna, basta trocar o ADD por DROP, que será visto mais adiante. Finalmente, o último dos mais importantes comandos de definição de dados, é o DROP. Essa instrução permite excluir base de dados DROP DATABASE nome bd ou mesmo tabelas DROP TABLE nome inteiras. Para a exclusão de simples registros, usa-se DELETE, que será explicado mais adiante. 4.2 Operações de manipulação de dados Como dito anteriormente, os três principais aspectos manipulativos de um banco de dados relacional são: restrição, projeção e junção. Essas três operações podem ser implementadas pela instrução SELECT. Abaixo tem-se alguns exemplos que comprovam essa idéia. 1 SELECT #F, #P, QDE 2 FROM FP 3 WHERE QDE < ; Código 4: Exemplo de restrição usando SELECT. 1 SELECT F#, NomeF 2 FROM F ; Código 5: Exemplo de projeção usando SELECT. Note que o código [5] acima pode ser simplificado como o código [6] abaixo. Obs.: Às vezes pode ser necessário o uso de nomes qualificados para tirar a ambiguidade de referências à colunas, por exemplo: P.P#, FP.P#. Inclusive o * pode ser qualificado, como em F.*. 4.3 Operações de Atualização As principais operações de atualização definidas pela SQL são a inserção (INSERT), atualização (UPDATE) e eliminação (DELETE) de registros. É interessante notar que a eliminação de tabelas possui uma diretiva especial (DROP) já mencionada anteriormente em 4.1. O exemplo [8] abaixo pressupões que já exista uma tabela com o nome temp, com duas colunas, P# e PESO. Essa instrução insere nessa tabela números de peças e pesos correspondentes a todas as peças vermelhas.

14 1 SELECT 2 FROM F ; Código 6: Exemplo de projeção simplificada usando SELECT. 1 SELECT F. F#, P#, NomeF 2 FROM F, FP 3 WHERE F. F# = FP. F# ; Código 7: Exemplo de junção usando SELECT. O próximo exemplo, código [9], atualiza o status de tidis is fornecedores em Paris, duplicandoo. A instrução DELETE, no exemplo 10, elimina todas as remessas correspondentes à peça P2. Já foi citado em [3.1] que pode-se criar visões 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ões a partir da diretiva CREATE VIEW. A partir daí, essa visão é tratada exatamente como uma tabela, mas que não está implementada fisicamente. Um exemplo de como criar um visão e de uma consulta de SQL sobre essa visão pode ser observada abaixo nos códigos [11] e [12] respectivamente. É interessante notar que qualquer alteração sobre uma VIEW, afetará diretamente a tabelea correspondente que está fisicamente implementada. Imagine a seguinte visão criada como mostra o código [13]. A operação de exclusão executada na linha 6, é o mesmo que executar a operação da linha 8 sobre a tabela pai da visão. 4.4 Sumário das instruções SQL As instruções mais comuns usadas em SQL e mencionadas anteriormente nesse documento são: 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ção resumida e simplificada das palavras reservadas definidas pelo padrão SQL. Do padrão SQL2 de 1992, dentre outras mais comuns, tem-se: AFTER, ALIAS, ASYNC, BE- FORE, 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, DIAGNOS- TICS, DISCONNECT, DOMAIN, DROP, ELSE, END-EXEC, EXCEPT, EXCEPTION, EXE- CUTE, EXTERNAL, EXTRACT, FALSE, FIRST, FULL, GET, GLOBAL, HOUR, IDEN- TITY, IMMEDIATE, INITIALLY, INNER, INPUT, INSENSITIVE, INTERSECT, INTER- VAL, 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, PEN- DANT, PREORDER, PRIVATE, OVERLAPS, PAD, PARTIAL, POSITION, PREPARE, PRE-

15 1 INSERT 2 INTO temp ( P#, PESO ) 3 SELECT P#, PESO 4 FROM P 5 WHERE COR = Vermelha ; Código 8: Exemplo de INSERT. 1 UPDATE F 2 SET STATUS = STATUS 2 3 WHERE CIDADE = P a r i s ; Código 9: Exemplo de UPDATE. SERVE, PRIOR, READ, PROTECTED, RECURSIVE, REF, REFERENCING, REPLACE, RESIGNAL, RETURN, RELATIVE, RESTRICT, REVOKE, RIGHT, ROWS, SCROLL, SE- COND, SESSION, RETURNS, ROLE, ROUTINE, ROW, SAVEPOINT, SEARCH, SENSI- TIVE, SEQUENCE, SESSION USER, SIZE, SPACE, SQLSTATE, SUBSTRING, SYSTEM USER, SIGNAL, SIMILAR, SQLEXCEPTION, SQLWARNING, STRUCTURE, TEST, THERE, TEM- PORARY, THEN, TIME, TIMESTAMP, TIMEZONE HOUR, TIMEZONE MINUTE, TRAI- LING, TRANSACTION, TRANSLATE, TRANSLATION, TRIM, TRUE, UNKNOWN, TRIG- GER, 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ão SQL3 de 1998, dentre outras mais comuns, tem-se: ACTION, ACTOR, AF- TER, 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, PRE- ORDER, PRIVATE, PROTECTED, RECURSIVE, REFERENCING, REPLACE, ROLE, ROU- TINE, 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. 5 Exemplo Apenas algumas definições 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 é: c:\mysql\bin\mysql -h nome.do.host -u nomedousuario -p nomedabasededados Onde:

16 5 EXEMPLO 16 1 DELETE 2 FROM FP 3 WHERE P# = P2 ; Código 10: Exemplo de DELETE. 1 CRETE VIEW bom fornecedor 2 AS SELECT F#, STATUS, CIDADE 3 FROM F 4 WHERE STATUS > 1 5 ; Código 11: Exemplo de CREATE VIEW. nome.do.host é o endereço do computador que está rodando o servidor; nomedousuario é o nome do usuário; nomedabasededados é o nome da base de dados que será usada; -p é a opção que exige um prompt para a senha do usuário. De um modo mais simple ainda, basta o comando: mysql},para que se tenha a seguinte conexão observada na figura [5]. Note que a conexão se fez, por padrão, com os seguinte atributos: usuário, minasi - quem executou o programa; host, como nenhum argumento foi passado na chamada do programa, localhost; dentre outros. Figura 5: Tela após a simples execução de um cliente SQL e seu status. A partir do prompt fornecido pelo programa cliente, pode-se fazer qualquer solicitação SQL, criar-se novas tabelas, base de dados (note que aí é necessário que se tenha permissão para tal), assim como eliminá-las, fazer consultas, inserções, atualizações e etc. Além disso, pode-se visualizar o banco de dados através de alguns comandos bem úteis:

17 1 SELECT F#, STATUS 2 FROM bom fornecedor 3 WHERE CIDADE = Londres ; Código 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 FROM EMP 4 WHERE S a l a r i o > 3K ; 6 DELETE FROM t e s t e WHERE S a l a r i o < 5K ; 8 DELETE FROM EMP WHERE ( S a l a r i o > 3K && S a l a r i o < 5K) ; Código 13: Exemplo de eliminação de registro na VIEW e suas implicações 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ó que este é executado no shell padrão, não no do cliente. use basededadosx; configura a base de dados a ser utilizada. Normalmente, após a instalação, existem duas pré-definidas: mysql - que possui as permissões, usuários, etc. - e a test - base para testes que qualquer usuário pode alterar. show tables; mostra todas as tabelas da dase de dados configurada para uso. Note que antes é necessário que se execute a instrução usebasededadosx;. O comando mysqlshowbasededadosx funciona da mesma forma, mas é executado no shell padrão. describe tabelax; descreve como são cada campo de uma tabela, quais são seus tipos, seus tamanhos, quais campos compõem a chave-primária, etc. help mostra a ajuda. Um outro comando, o mysqladmin, chama um programa diferente do cliente SQL. Esse programa é usado para administrar vários aspectos do servidor de banco de dados MySQL. Informações mais detalhadas a esse respeito podem ser obtidas em: intro.html#section Para finalizar, mostra-se abaixo dois exemplos de consultas SQL: a primeira executada na prompt do cliente mysql, enquanto que a segunda é executada como um comando normal no shell padrão. SELECT* FROM tabelax; mysql-e SELECT * FROM tabelax basededadosy 6 APIs - Application Program Interfaces As APIs, ou Interfaces para Programas de Aplicação, permite que instruções SQL estejam embutidas dentro de programas em linguagens comuns de programação, como C++, Java, PHP, etc. Por isso mesmo, as APIs são também referenciadas como SQL Embutida.

18 Existem também referências para SQL Dinâmica, que nada mais é do que um conjunto de recursos embutidos de SQL que se destinam a oferecer suporte à construção de aplicações generalizadas, on-line e possivelmente interativas. 6.1 Java Destinado ao fim anteriormente exposto, existe em Java um pacote chamado java.sql que permite executar as funcionalidades da SQL Embutida. Segundo a própria página de documentação 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ção Java TM. Para acessar essa página, basta seguir o ponteiro Um exemplo interessante de como executar uma query em Java TM é mostrado abaixo no código [14]. O exemplo foi obtido do ponteiro lindgren/190/mysql-jdbc/. Ele possui um inconveniente que é a utilização de um JDBC 3 driver muito específico - da Terrance Zellars - para a comunicação com o banco de dados. Um JDBC driver GPL fornecido pela MySQL AB, e portanto mais confiável, é o MySQL Connector/J. Ele é o driver JDBC oficial para o MySQL. Mais informações sobre o driver pode ser obtida em Pode-se baixá-lo gratuitamente em C++ Programas escritos na linguagem C++ que necessitem das funcionalidades da SQL embutida podem utilizar-se da API fornecida no ponteiro Um exemplo da utilização dessa API pode ser observado no código [6.2] abaixo. 7 Estudo comparativo entre MySQL e PostgreSQL Como dito na introdução desse documento, uma análise mais profunda comparando os bancos de dados disponíveis no mercado se faz bastante necessária. Principalmente entre os dois mais comuns, MySQL [MySb] e PostgreSQL [Pos], e o considerado o mais eficiente, o Oracle [Ora]. Assim, apenas para ilustrar como a performance do MySQL, que foi a base deste documento, é relativamente boa quando comparada com o Oracle 9i, mostra-se as figuras [6] e [7] abaixo. Referências [C. 00] [E. 72] C. J. Date. Introdução a Sistemas de Bancos de Dados. Editora Campus, tradução da sétima edição americana edition, , 4.1 E. F. Codd. further normalization of the data base relational model. Data Base Systems, Courant Computer Science Symposia Series 6, [MySa] Instalação do mysql. Internet, [MySb] Mysql. Internet, 1.1, 7 [MyS04] MySQL A.B. MySQL Reference Manual. MySQL A.B, JDBC (Java Database Connectivity), de acrodo com a JavaSofts em A API JDBC define classes Java para representar conexões com banco de bados, declarações SQL, etc..

19 REFERÊNCIAS 19 Fonte: eweek em Server Databases Clash Figura 6: Benchmark de banco de dados: páginas da web retornadas por segundo. [Ora] Oracle. Internet, 7 [Pos] Postgresql. Internet, 1.1, 7

20 REFERÊNCIAS 20 Fonte: eweek em Server Databases Clash Figura 7: Benchmark de banco de dados: as respostas mais rápidas.