You are on page 1of 8

Structure Query Language – SQL

Guilherme Pontes – lf.pontes.sites.uol.com.br

1. Abordagem geral
Em primeiro plano, deve-se escolher com qual banco de dados iremos
trabalhar. Cada banco possui suas vantagens, desvantagens e
características. Por conveniência, aqui trabalharemos com softwares
livres, para que o leitor possa a qualquer momento adquirir os bancos
gratuitamente na Internet e desenvolver sua aplicação sem custos
contratuais relacionados ao SGBD. As bases aqui trabalhadas serão:
 A versão gratuita do banco de dados mais poderoso do
mundo conhecido como Oracle 10g. Pode-se realizar o
download no site oficial da Oracle (http://www.oracle.com).
 A versão livre do banco de dados Interbase denominada
Firebird. Poderemos baixar seu instalador em
http://www.firebirdsql.org/.
 Por fim, mostraremos também um dos mais conhecidos SGBD
de código aberto para desenvolvimento WEB, o MySQL. Seu
download pode ser realizado em http://www.mysql.com.

2. Gerenciando o Banco de Dados


Antes da criação das tabelas, devemos nos concentrar na criação do
banco de dados. Abaixo iremos abordar a criação de um novo banco de
dados em cada uma das ferramentas citadas acima.

Gerenciando um banco de dados MySQL


Todos os procedimentos realizados no banco de dados
MySQL serão inseridos através do MySQL Command
Line Client instalado no pacote do MySQL. Logo que o
prompt for iniciado, ele irá pedir a senha de acesso
(senha definida durante a instalação). Digite a senha
corretamente e trabalhe com o SGBD.
Todas as tabelas estarão dispostas em um banco de dados.
Inicialmente, o MySQL só possui os bancos necessários para sua
própria configuração. Deve-se destacar que para a finalização de um
comando (ou seqüência de comandos) deve-se, indispensavelmente,
usar o ponto-e-vírgula. Abaixo tempos os principais comandos de
gerenciamento do banco.

Exibir bancos de dados existentes


show databases;

Criar um novo banco de dados. Todos os procedimentos de criação,


alteração, exclusão de tabelas e inserção, atualização e exclusão de
dados só poderão ser realizados posteriormente a criação de um
banco de dados.
create database nome_do_banco;

Excluir um banco de dados


drop databases nome_do_banco;

Selecionar um banco de dados. Todos os comandos de manutenção


de um banco de dados qualquer só poderão ser expressos quando o
prompt estiver apontando para o mesmo, ou seja, deve-se, antes de
executar quaisquer comandos de manutenção da base, selecionar o
banco em questão. Para selecionar outro banco, deve-se usar o
mesmo comando.
use nome_do_banco;

Sair do MySQL Command Line Client


exit;

Gerenciando um banco de dados Firebird


Como ressaltado acima, o SGBD FireBird é a versão
livre do Banco de Dados Interbase (Borland). O acesso
ao servidor Firebird (ibserver.exe ou fbserver.exe) pode
ser realizado de duas (ou mais) formas: Através do
terminal Isql ou pelo IBConsole (já bastante conhecido
por ser a ferramenta de acesso padrão no Interbase).

Neste estudo vamos trabalhar com o Isql. O Isql funciona de maneira


análoga ao MySQL Command Line Client trabalhado no tópico anterior.
Através dele poderemos trabalhar com os recursos oferecidos pelo
SGBD por meio de comandos na linguagem SQL.
Em primeiro lugar, o servidor FireBird deverá estar ativo (rodando). Você
poderá acessar a ferramenta Isql através do Prompt de Comando do
Windows com o seguinte comando:

Abrindo o Isql
c:\Arquiv~1\Firebird\Firebird_2_0\bin\isql –user
SYSDBA –password masterkey
Observe que o usuário padrão é SYSDBA (maiúsculo) e que sua senha
é masterkey (minúsculo). O path pode variar.

A partir de agora, estamos acessando o SGBD Firebird. O uso do ponto-


e-vírgula também é necessário. Veremos agora as principais ações de
gerenciamento de um banco de dados.

Criar um novo banco de dados: Nesta criação poderemos especificar a


localização da base de dados na estrutura de diretórios do sistema.
Por exemplo, o banco nome_do_banco.gdb (insira também a
extensão) será criado em F:\BASE. Os apóstrofos são necessários.
create database ‘f:\base\nome_do_banco.gdb’;

Selecionar um banco de dados. Para que os comandos de


manipulação do banco sejam aceitos, o usuário deve se conectar. O
path do banco deve ser inserido por completo. Os apóstrofos e a
extensão também são necessários.
connect ‘f:\base\nome_do_banco.gdb’;

Excluir um banco de dados: Para que a exclusão seja aceita, o usuário


deve estar conectado a banco. Caso o comando seja efetuado sem
uma prévia conexão, o último banco de dados criado será excluído.
drop database;

Sair do Isql
exit;

Gerenciando um banco de dados Oracle 10g


Em primeiro plano devemos ressaltar que a
definição da senha para os usuários SYS e
SYSTEM será realizada no processo de
instalação do SGBD (análogo ao MySQL). Deve-
se ter bastante espaço disponível no disco de
instalação (superior a 1,5 GB).
Finalizada a instalação, o assistente de gerenciamento Oracle Database
Express Edition (Oracle Database XE). Entre com o usuário SYSTEM e
com a senha definida na instalação. Pela interface, pode-se constatar a
superioridade imposta pelos bancos de dados da Oracle.

A filosofia trabalhada pelo Oracle XE é um pouco diferente das outras


bases mostradas neste estudo. Nesta versão, não poderemos criar
outras instâncias (Database) além da default oferecida durante a
instalação (XE). Através do menu Administration, About Database e
Settings você poderá acessar os dados desta instância.
Cada usuário (Schemas) possui objetos do banco relacionados, ou seja,
o usuário SYSTEM possui os elementos responsáveis pela
administração do SGBD. Para que você trabalhe com determinados
elementos específicos para um sistema, é conveniente (recomendado) a
criação de um novo usuário. Ainda como SYSTEM, acesse
Administration, Database Users e Create User.

Nesta sessão teremos disponíveis campos para inserir as


informações/permissões do novo usuário. Usuários só podem conectar
ao sistema com contas Unlocked, portanto, criaremos um usuário deste
tipo. Nas Roles daremos ao nosso usuário permissão básica de acesso
(CONNECT) e permissão para criação de objetos para a base
(RESOURCE). Para dar permissão de Administrador de Banco de
Dados, marcaremos a opção DBA, contudo, por estarmos criando um
usuário com acesso, opcionalmente, restrito, não marcaremos este item.
Abaixo, em Direct Grant System Privileges temos os privilégios do
usuário. Vamos marcar todos.
Preencha o Username com nome_do_usuario e defina uma senha de
sua escolha. Efetue o logout (no canto superior direito) e posteriormente
(clicando em login) indique ao sistema uma nova conexão. Entre com
nome_do_usuario e a senha anteriormente definida.

Gerenciamento da Base de Dados: Todos os objetos, a partir de agora,


estarão relacionados ao usuário (Schemas) nome_do_usuario. Se
criarmos, por exemplo, uma tabela com este usuário, outros usuários
(não administradores) não terão acesso à tabela. Deve-se destacar que
este processo não cria uma nova instância (Database). Simplesmente
associa ao usuário os objetos criados em sua conta.
3. Restrições de Integridade
Qualquer SGBD relacional robusto trabalha com uma série comandos
SQL (geralmente padronizados) que garantem à base de dados
integridade e eficiência. Alguns elementos são usados para a criação
das restrições relacionais, tais como as chaves primárias e estrangeiras.
Outras restrições evitam a existência de duplicidade indesejada, campos
com preenchimento nulo, entre outros problemas.
Em geral, todos os SGBD oferecem uma ferramenta de console, na
qual, o usuário será capaz de especificar tais restrições por comandos
SQL. Outros bancos (ou interfaces, melhor dizendo) oferecem a
possibilidade da inserção de tais regras de forma mais interativa (com
menus visuais e componentes análogos). Neste estudo, todas as regras
tratadas serão unicamente apresentadas em comandos.
Os três bancos sugeridos, neste caso, trabalham com a mesma sintaxe,
evitando explanações específicas aos mesmos.

Constraint: Os Confinamentos ou regras de integridade são chamados


de constraint. Podemos inseri-los/manipula-los de duas possíveis
formas: com ou sem o uso da sintaxe constraint, respectivamente,
criando ou não uma identificação para determinada restrição. A
vantagem de se criar uma identificação para a restrição centra-se na
melhor manipulação da mesma, em casos de mudança posterior. Por
exemplo, na definição de uma restrição check sem identificação para
o campo nome da tabela clientes, a remoção/modificação da regra
exigiria a exclusão do campo. Criando o mesmo campo com a
identificação regra_nome_cliente (por exemplo), o ato de
exclusão/alteração da regra simplesmente seria imposta ao elemento
chamado regra_nome_cliente. Os exemplos abaixo facilitarão o
entendimento da questão anterior.

Criando uma restrição unique sem identificação para o campo nome:


nome varchar2(60) unique

Neste caso, para remover a regra unique, o DBA excluiria o campo


nome (junto com a restrição) para em seguida, implementa-lo
novamente.

Criando uma restrição unique com identificação para o campo nome:


nome varchar2(60),
constraint regra_nome unique(nome)

Para futura exclusão/manipulação da regra unique, o DBA recorreria


unicamente à sua identificação regra_nome (sem afetar o campo).
Alguns tipos de restrição não aceitam a definição de um identificador
através da cláusula constraint quando definida separadamente do
campo. A restrição not null, por exemplo, só poderá ser identificada
após a definição do campo. Na prática, aconselho identificar apenas
as restrições de chave primária e chave estrangeira. Regras como
unique e not null, podemos definir sem o uso de constraint.
Chave Primária: A chave primária de uma tabela representa de forma
exclusiva cada linha (tupla) existente na mesma evitando a existência
de campos nulos e repetidos. Podemos identificar ou não a chave
primária, contudo, aqui, mostraremos sua criação (primeiro comando)
através da cláusula constraint (com identificação id_pk). O segundo
código exibe a criação de chave primária composta (obrigatoriamente
realizada conforme demonstrado).
constraint id_pk primary key (nome_do_campo)
constraint id_pks primary key (campo1,campo2)

Chave Estrangeira: A chave estrangeira é usada para realizar as


restrições referenciais de uma base de dados. Ela será usada quando
existir a necessidade de associar determinado registro (linha) de uma
tabela a um registro específico em uma outra tabela. Por exemplo,
queremos associar o cliente de código (primary key) 21 ao
dependente João. A tabela de dependentes deverá conter um campo
específico para armazenar o código do cliente associado. Este campo
será uma chave estrangeira. Isso nos obriga a valorá-lo com nulo ou
com um dos registros existentes na chave primária da tabela
clientes (neste caso, o número 21). Outras restrições podem ser
impostas juntamente com a chave estrangeira. Em alguns casos, é
necessária a existência da cláusula not null, que impediria a definição
de um valor nulo para a chave estrangeira.
Na prática, podemos referenciar campos primary key e unique,
contudo, não seria uma boa prática trabalhar com referências de
campos unique (pois estaremos nos referenciando a uma outra tabela
sem usufruir do campo de chave primária). Aqui mostraremos
referências a campos primary key, unicamente.
No exemplo abaixo estamos indicando que a chave primária codigo,
da tabela clientes, está associada com o campo cod_cliente (chave
estrangeira identificada como fk_dep) da tabela dependentes. Para
facilitar o entendimento, visualize o diagrama de estrutura de dados a
seguir e interprete o relacionamento. Observe que neste caso,
cod_cliente, além de chave estrangeira, também é assumido como
chave primária. Por conseqüência, a implementação da tabela
dependentes implicaria na adoção da cláusula de chave primária –
que deverá ser especificada separadamente.

constraint fk_dep foreign key (cod_cliente)


references clientes(codigo)
Default: A cláusula default impõe ao campo um valor caso este não
seja definido durante o processo de inserção de dados. Podemos, por
exemplo, definir que, por padrão, o campo data_nasc do cliente seja
01/01/1980 (primeiro comando). Caso a data não seja especificada,
automaticamente o campo seria preenchido com este valor. No
segundo comando definimos um valor default para nome e no terceiro,
para codigo. Observe também que, para textos e datas o uso dos
apóstrofos é obrigatório.
data_nasc date default ‘01/01/1980’
nome varchar2(60) default ‘Guilherme’
codigo integer default 01

Check: Através desta cláusula poderemos fazer a restrição de


domínio, ou seja, verificar a atribuição de valores a determinado
campo de acordo com uma regra específica. No primeiro comando, o
valor de codigo deverá ser superior a 10. No segundo exemplo, UF
pode variar entre RJ, SP e ES. Por fim, ano_nasc, estará
obrigatoriamente entre 1980 e 1990.
codigo number(10) check (codigo > 10)
UF varchar2(2) check (UF IN (‘RJ’,‘SP’,‘ES’))
ano_nasc number(4) CHECK (ano_nasc between 1980 and 1990)

Unique: Com a regra unique, os campos, obrigatoriamente serão


únicos na tabela. É válido definir a cláusula unique para campos como
CPF, nome, CNPJ e similares.
CPF varchar2(14) unique

Not null: Impede que o campo em questão assuma um valor nulo.


Geralmente, aplicamos este tipo de restrição a todos os campos de
uma tabela – se um campo foi associado a uma tabela, na prática, seu
valor dificilmente poderia ser nulo.
nome varchar2(60) not null

Em geral, as bases de dados trabalhão com definições similares às


apresentadas nesta seção. Os tipos (domínios) de dados, por sua vez,
são distintos entre os SGBD’s. Esta será a próxima abordagem.