capÍtulo 2 – tabelas - eduardo terra morelli database … · 2009-06-01 · cluster), que...

Oracle DBA Essencial – Volume I – SQL 1

CAPÍTULO 2 – TABELAS

METAS • Possuindo um usuário Oracle previamente criado, realizar

conexão ao servidor utilizando SQL Developer;

• Criar uma tabela utilizando o comando CREATE TABLE;

• Conhecer tipos utilizados para caracterizar colunas de tabelas (number, date , etc.)

• Alterar a estrutura de uma tabela previamente criada (comando ALTER TABLE);

• Travar um primeiro contato com restrições de integridade (constraints);

• Eliminar uma tabela previamente criada (comando DROP TABLE);

• Compreender os mecanismos da Recycle Bin;

• Inserir dados em uma tabela previamente criada (comando INSERT);

• Criar uma sequence utilizando o comando CREATE SEQUENCE;

• Utilizar sequences para alimentar chaves primárias;

• Executar vários comandos SQL utilizando arquivos externos (scripts).

ARQUIVOS DE APOIO • 02_Cria_Constraints_Check_Filmes.sql;

• 02_Cria_Tabela_Exemplar.sql;

• 02_Cria_Tabela_Filme.sql;

• 02_Exemplo_Sequence.sql;

• 02_Projeto_Fisico_Locadora.sql;

• 02_Alimenta_Tabelas.sql.

ANTES DE COMEÇAR ESTE CAPÍTULO... • Verifique se você possui um usuário que possa conectar-se a

algum Servidor Oracle; Esta disponibilização normalmente é feita

1


por um administrador de bancos de dados, também chamado de DBA (Database Administrator);

• Também certifique-se da presença em sua máquina local de um conjunto de programas coletivamente conhecidos por Oracle Client (veja se existe um diretório chamado Oracle em seu disco rígido, por exemplo). Mais uma vez, o DBA proporcionará valiosa ajuda neste item;

• O usuário em questão também deve possuir privilégios para criar tabelas e alimentá-las com dados.

CENÁRIO MOTIVADOR

Oracle 30 anos: uma breve cronologia6

1979, julho: RSI lança o Oracle, o primeiro SGBDR comercial do mercado, utilizando o sistema operacional para mini computadores VAX. 1980: lançada versão 2, ainda sob VAX. Iniciados planos de migração para Unix. 1982: RSI passa a chamar-se Oracle Systems. Atendidos mainframes IBM com sistema operacional VM/CMS. 1983: lançada versão 3, totalmente escrita em C, o que permitiria executar o produto em qualquer sistema operacional que tivesse um compilador C. 1985: lançada versão 5, compatível com a arquitetura cliente-servidor. Isto permite instalar clientes em PCs. 1986: versão 5.1 permite execução de uma mesma consulta distribuída por vários servidores. 1987: Oracle expande sua linha de produtos passando a oferecer programas para acesso às bases (Oracle Applications). Passa a oferecer suporte e consultoria a clientes.

6 Veja mais detalhes em http://www.oracle.com/timeli ne/index.html


1988: lançada versão 6 oferecendo bloqueio (lock) em nível de linha ao invés de tabela e hot backup, permitindo cópias de segurança enquanto o banco estiver aberto. 1992: após 4 anos em desenvolvimento e mais dois sob testes em clientes, Oracle lança a versão 7 com triggers, stored procedures e permitindo regras para integridade referencial. 1994: disponibilizados produtos para armazenar e gerenciar aplicações multimídia. 1997: lançada versão 8, compatível com abordagem Network Computing, onde inteligência das aplicações fica armazenada em poderosos servidores e acessados via internet. Também lançada a quarta versão do Oracle Applications. 1998: lançada versão 8i. 1999: disponibilizada a Oracle Applications 11i, onde se reforça a mudança de foco de cliente/servidor para a internet. 2000: lançada a Oracle E-Business Suite 11i. 2001: lançada versão 9i, com tecnologia RAC (Real Applications Cluster), que demorou 10 anos para ser desenvolvida. Na verdade, já existia tecnologia semelhante, a Oracle Cluster, mais limitada. 2002: lançada campanha publicitária Oracle Unbreakable. 2003: Oracle adquire PeopleSoft; lançada versão 10g, oferecendo Grid Computing. 2006: Oracle adquire Siebel, empresa responsável pelo desenvolvimento de uma aplicação CRM (customer relationship management) e possuindo participação marcante no mercado. 2007: Em 11/7 é lançada a versão 11g.

TEORIA

2.1 – SQL Developer


Bancos de Dados Oracle normalmente ficam armazenados em servidores exclusivos. Para que seja possível interagir com estes Bancos utilizam-se ferramentas cliente tais como SQL Developer (gráfica) ou SQL*Plus7 (modo texto). A primeira pode ser obtida gratuitamente acessando a Oracle Technology Network (http://otn.oracle.com), um interessante aglomerado de informações úteis a qualquer interessado em desvendar os detalhes do Mundo Oracle. Vale a pena uma visita!

Além de ferramentas gratuitas, a OTN oferece artigos, exemplos e dicas. Entretanto, para que seja possível aproveitá-la plenamente, deve-se realizar um cadastro prévio, também gratuito.

2.2 – Conexão via SQL Developer Antes de interagir com um banco de dados Oracle, deve-se realizar uma conexão um cliente a um servidor. Ao longo deste livro, será utilizada a ferramenta cliente SQL Developer. Em ambientes gráficos como Windows XP ou Windows Vista, ativa-se a partir do menu Iniciar, Todos os Programas, Oracle – OraDb11g_home1, Desenvolvimento de Aplicações, SQL Developer8:

7 Já disponível junto com a instalação Client Oracle. Veja exemplo de

utilização na Figura 2.8 8 A localização pode variar, conforme o Sistema Oper acional utilizado. O

mais recomendado seria buscar o arquivo sqldeveloper.exe


Figura 2.1: Ambiente SQL Developer

Dica: recomenda-se manter sempre a última versão, que pode ser obtida disparando a cópia a partir do comando Help, Check for Updates. Neste livro, foi utilizada a versão 1.5.1.

Caso a aba Connections, não seja mostrada, deve-se executar View, Connections. Inicialmente, deve-se criar uma conexão pressionando no

botão:

A Figura 2.2 exibe uma provável conexão criada. Perceba o nome da conexão (locadora), do usuário (idem), bem como o Service Name, informação que deve ser checada junto ao DBA.

Atenção Para realizar conexões utilizando o usuário locadora, este já deve ter sido criado pelo administrador da base (DBA). Este usuário deve receber dois grupos de privilégios: resource e connect.


Figura 2.2: Criação de uma Conexão SQL Developer

Uma vez criada e realizada a conexão, o ambiente SQL Developer apresenta-se diferente, tal qual exibido na Figura 2.3. Connections exibe uma lista com tipos de objetos presentes em um banco de dados Oracle (tabelas, visões, índices, etc.). À direita, aparece uma janela de trabalho na qual será possível digitar comandos SQL; abaixo desta, mostram-se áreas auxiliares (resultado de execução de comandos, por exemplo).


Figura 2.3: Ambiente SQL Developer Após Conexão Realizada

2.3 – Tabelas: cuidados prévios à criação Tabelas consistem de matrizes compostas por linhas e colunas (campos denominados). Têm importância fundamental, já que atuam como repositórios, ou seja, onde os dados em si ficam armazenados. Normalmente, há uma coluna, a chave primária, cujo valor identifica univocamente cada linha.

Como visto no capítulo anterior, a criação das tabelas acontece durante o Projeto Físico, utilizando uma linguagem denominada SQL. Antes, porém, devem-se levar em consideração alguns cuidados.

2.3.1 – Nome da Tabela


Deve-se observar o nome utilizado no Projeto Lógico, porém tomando a precaução de não ultrapassar os trinta (30) caracteres, restrição imposta pelo Oracle para quaisquer nomes de objetos. Ainda que permitidos, espaços em branco e caracteres de acentuação devem ser evitados, pois tendem a dificultar tarefas futuras.

Finalmente, nomes de tabelas não podem começar por números, ainda que estes possam aparecer a partir da segunda posição.

2.3.2 – Nomes de Campos

Também extraídos do Projeto Lógico; valem os mesmos cuidados observados para o nome da tabela (tamanho, espaços em branco, acentos, números). Recomenda-se criar uma convenção clara e documentada, onde sejam explicitadas regras para nomes de colunas. Por exemplo, todo campo tipo data poderia começar por DT_; ou ainda, todo atributo atuando como chave primária poderia utilizar COD_ como prefixo.

2.3.3 – Tipos de Campos

Todo campo possui um tipo de dados (datatype), que restringe a gama de valores nele armazenados. Basicamente, existem três grupos9: numéricos, textuais e datas. A Tabela 2.1 apresenta os tipos numéricos mais importantes.

Tipo Observações

Number (p, e) Números com precisão (p, variando de 1 a 38) e escala (e, variando de -84 a +127). Number (7,2) significa cinco algarismos inteiros e dois decimais, ou seja, não seria possível armazenar números cujos valores absolutos ultrapassassem 99.999,99.

Dependendo da combinação (p, e) utilizada, pode-se gastar de um a 22 bytes. Escalas negativas arredondam números (por exemplo, number (5, -2) representa números arredondados na casa das centenas: 211 seria

9 Na verdade, adotou-se uma classificação simplifica da, para efeitos

didáticos. Ainda existem outros tipos (BLOB, Bfile, Rowid), mas, como não serão vistos neste livro, preferiu-se omiti-los.


representado como 200; 299 como 300).

Binary_Float Números armazenados em ponto flutuante (32 bits). Indicado para cálculos científicos. Requer apenas 5 bytes. Faixa representável: de 1.17549E-38F a 3.40282E+38F

Binary_Double Números armazenados em ponto flutuante (64 bits). Indicado para cálculos científicos que requeiram precisão maior. Ocupa 9 bytes. Faixa representável: de 1.79769313486231E+308 a 2.22507485850720E-308

Tabela 2.1: Tipos Numéricos mais Relevantes

A precisão do tipo NUMBER funciona como limite máximo de representação. Por exemplo, uma coluna do tipo NUMBER(2) não poderia receber números maiores do que 99. Já a escala, é utilizada para arredondamentos. Analise a Tabela 2.2 onde aparecem várias atribuições hipotéticas a uma coluna cujo tipo seria NUMBER (5,2).

Valor Atribuído Resultado

6 6

6,9 6,9

6,99 6,99

6,999 7

6,999748 7

Tabela 2.2: Exemplos de Atribuição a uma Coluna NUMBER(5,2)

A Tabela 2.3 apresenta os tipos textuais mais importantes.

Tipo Observações

Char (t) Cadeia de caracteres com tamanho fixo t, variando de 1(default) a 2.000.

Varchar2(t) Cadeia de caracteres com tamanho variável de um a t, Máximo: 4.000. Obrigatoriamente deve-se especificar t.

CLOB Acrônimo para Character Long Object, podendo armazenar cadeias de caracteres com até 4 GB. Sua manipulação,


entretanto, ocorre utilizando programas desenvolvidos em PL/SQL10.

Tabela 2.3: Tipos Textuais mais Relevantes

A Tabela 2.4 apresenta os tipos data mais importantes.

Tipo Observações

Date Datas de 1/1/4712 A.C. a 31/12/9999. Armazena ano, mês, dia, hora, minuto e segundo. Ocupa 7 bytes.

Timestamp(p) Estende o tipo Date, permitindo armazenar frações de segundos(p) de 0 a 9 (default: 6). Por exemplo, caso p seja 5, significa o armazenamento desde ano até a 1/100.000 parte de um segundo. Ocupa de 7 a 11 bytes, dependendo da precisão adotada.

Timestamp (p) with timezone

Estende o tipo Timestamp, acrescentando informações relativas ao fuso horário (diferença em horas e minutos em relação a Greenwich). Ocupa 13 bytes.

Timestamp(p) with local timezone

Estende o tipo Timestamp with timezone, mas levando em conta o fuso horário do cliente que está consultando o dado. No momento da consulta, existe um cálculo que leva em conta a configuração do cliente. Ocupa de 7 a 11 bytes, dependendo da precisão adotada

Interval Year(p) to Month

Armazena intervalos em anos e meses. P indica a quantidade de dígitos para o ano (0 a 9, default 2). Mais detalhes no próximo capítulo.

Interval Day(pd) to Second(ps)

Armazena intervalos em dias, horas, minutos e segundos. pd indica a quantidade de dígitos para o dia (0 a 9, default 2); ps indica a frações de segundos (0 a 9, default: 6). Mais detalhes no próximo capítulo.

Tabela 2.4: Tipos Data mais Relevantes

2.3.4 – Restrições (constraints)

Um dos grandes benefícios proporcionados pela utilização de Sistemas Gerenciadores de Bancos de Dados Relacionais (SGBDRs) consiste na

10 A linguagem de programação PL/SQL será abordada em detalhes no segundo

volume desta coleção, Oracle 11g Essencial – Volume II – PL/SQL.


possibilidade de proteção aos dados contra manipulações (inserções, atualizações, exclusões) incorretas. Por exemplo, suponha que na tabela de clientes haja dois indivíduos com o mesmo código (atributo COD_CLIENTE). Caso este código aparecesse na tabela de locações, qual cliente deveria receber a cobrança caso houvesse atraso na devolução?

Mais um exemplo: suponha que na tabela de participações exista um registro, cujo conteúdo em COD_PAPEL seja um número inexistente na tabela de papéis. Estas situações, dentre outras, são evitadas utilizando-se Restrições (Constraints).

Oracle permite, e até recomenda, dar nomes a restrições com intuito de facilitar sua manipulação. Assim como nomes de campos, resulta muitíssimo salutar criar uma convenção clara e bem documentada a respeito de nomes de restrições. Desta forma, a chave primária da tabela FILME poderia ser chamada FILME_PK ; a chave estrangeira (foreign key) entre as tabelas FILME e EXEMPLAR seria FILME_EXEMPLAR_FK11, e assim por diante.

Concluindo, as restrições (constraints) devem ser utilizadas para manter a integridade do banco de dados.

A Tabela 2.5 apresenta os possíveis tipos de restrições.

Constraint Descrição

Primary key Chave Primária. Garante unicidade de valores; somente pode existir um constraint deste tipo por tabela. Preenchimento obrigatório. Utilizado para relacionar duas tabelas; quem participa com a chave primária é dita tabela primária e representa o lado 1 do relacionamento 1xN, enquanto quem participa com a chave estrangeira é dita tabela relacionada e representa o lado N do relacionamento 1xN.

Unique Chave Única. Também garante a unicidade de valores, porém pode existir mais de um constraint UNIQUE por tabela. O preenchimento pode ser obrigatório, ou não.

Foreign Key Chave estrangeira. Utilizado para relacionar duas tabelas, porém criado na tabela relacionada (lado N do relacionamento 1xN). Impede a presença de linhas órfãs, ou seja, chaves primárias correspondentes não existam na tabela primária.

11 Nomes de restrições, assim como nomes de tabelas o u colunas, não podem

ultrapassar 30 caracteres.


Check Estende a limitação imposta pelo tipo de dados, acrescentando regras, geralmente simples, que limitem ainda mais a gama de valores possíveis.

Tabela 2.5: Constraints

Perceba que três das quatro restrições (PK, Unique e FK) existem para garantir a integridade dos dados. A restrição Check tem uma função diferente: existe para implementar regras de negócio no qual o Modelo de Dados está inserido. Na Vídeo Locadora Bonfilme, por exemplo, o campo UF (Unidade da Federação) na tabela de clientes está restrito aos valores: SP, MG, RJ ou ES.

Uma restrição pode afetar apenas um campo ou mais de um deles. Por exemplo, a chave primária composta da tabela de locações abarca os campos COD_EXEMPLAR e COD_CLIENTE. Já o campo CENSURA na tabela de filmes tem seu conteúdo restrito a números na faixa entre zero (livre) e dezoito.

2.3.5 – Obrigatoriedade de Preenchimento de Campos

Devido a razões de integridade, alguns campos devem ser forçosamente preenchidos. Por exemplo, resulta impossível armazenar um registro cujo campo chave primária esteja vazio. Aliás, ao caracterizar uma coluna como chave primária de uma tabela, esta automaticamente recebe a obrigatoriedade de preenchimento.

Além das chaves primárias, há no estudo de caso discutido neste livro diversos exemplos desta obrigatoriedade:

• Nomes de clientes;

• Data na qual um DVD foi alugado;

• Nomes de filmes.

Qual seria o sentido em possuir informações de um cliente caso seu nome fosse desconhecido?

Na verdade, o SGBDR Oracle trata essa obrigatoriedade também como constraint, já que se cria implicitamente uma regra que impede a presença de valores nulos.

2.3.6 – Valores Pré-Assumidos (defaults)


Alguns campos já podem ser definidos com valores pré-assumidos. Por exemplo, suponha que 99% dos clientes da rede de vídeo locadoras Bonfilme sejam residentes no estado de Minas Gerais. Seria um facilitador durante a inserção dos dados o fato de poder-se omitir esta informação.

2.4 – Tabelas: criação Uma vez compreendido o Projeto Lógico e também observados os cuidados recém expostos, pode-se dar início à confecção do Projeto Físico. A Tabela 2.6 elucida os detalhes necessários à construção do repositório de filmes.

Campo Tipo Constraint Obrigatório? Default

Cod_filme Number(10) PK Sim

Nome Varchar2(100) Unique Sim

Nome_ Original

Varchar2(100)

Ano Number(4) Check (maior que 1900)

Duracao_ Minutos

Number(3) Check (entre 10 e 300)

Preco_ Sugerido_ Locacao

Number(7,2)

Censura Number(2) Check (entre 0 e 18)

18

Tabela 2.6: Colunas da tabela FILME

Observação:

� A tabela de filmes apresenta cinco restrições, cujos nomes poderiam ser: FILME_PK, FILME_01_U, FILME_01_CK, FILME_02_CK e FILME_03_CK.

Utilizando o SQL Developer, cria-se rapidamente uma tabela pelo comando New Table (veja Figura 2.4).


Figura 2.4: Comando para Criar Nova Tabela

O resultado da criação da tabela de filmes aparece na Figura 2.5.


Figura 2.5: Tabela de Filmes Sendo Criada Graficamente

Observações:

� A escala da coluna PRECO_SUGERIDO_LOCACAO somente pôde ser informada após habilitar o modo estendido (ativando a caixa Advanced);

� Não foram criadas as restrições para os campos NOME, ANO, DURACAO_MIN e CENSURA.

Normalmente, novatos preferem executar suas primeiras tarefas interagindo graficamente com ferramentas cliente, como SQL Developer. Entretanto, à medida que vão ganhando confiança percebem que poderiam desempenhar seus trabalhos de uma forma mais eficiente, sem perder tanto tempo clicando em janelas. Quando precisam realizar tarefas ligeiras, como acrescentar uma restrição, por exemplo, percebem os benefícios proporcionados pela utilização de comandos SQL e arquivos com vários deles (scripts).

Antes, porém, de aventurar-se a elaborar suas próprias construções SQL, convém analisar alguns exemplos. O próprio SQL Developer gera comandos SQL para diversas tarefas, como por exemplo a criação de tabelas. Na Caixa de Diálogo exibida na Figura 2.5 existe uma aba, DDL, que descortinaria o seguinte texto:

1. CREATE TABLE FILME 2. ( 3. COD_FILME NUMBER(10,0) NOT NULL ENABLE , 4. NOME VARCHAR2(100 BYTE) NOT NULL ENABLE, 5. NOME_ORIGINAL VARCHAR2(100 BYTE) , 6. ANO NUMBER(4,0) , 7. DURACAO_MINUTOS NUMBER(3,0) , 8. PRECO_SUGERIDO_LOCACAO NUMBER(7,2) , 9. CENSURA NUMBER(2,0) DEFAULT 0 , 10. CONSTRAINT FILME_PK PRIMARY KEY ( COD_FILME ) ENABL E ;

Observações:

� O texto representa um exemplo de utilização do comando da família DDL, CREATE TABLE;

� Encerra-se todo comando SQL com ponto-e-vírgula; � Definem-se as colunas entre as linhas 3 e 9; cada uma vem com

nome, tipo, obrigatoriedade e, eventualmente, valor pré-assumido (CENSURA);

� A linha 10 apresenta a restrição (constraint) do tipo chave primária denominada como FILME_PK;


� A palavra chave ENABLE, opcional, apenas reforça o fato da imediata ativação das regras declaradas (obrigatoriedade de preenchimentos e restrição de chave primária). Mais detalhes aparecem no quinto capítulo;

� A palavra reservada BYTE indica como serão armazenados os caracteres nas cadeias NOME e NOME_ORIGINAL. Normalmente, um byte representa um caractere, exceto quando estiver sendo utilizado um character set12 que precise mais de um byte por símbolo.

2.5 – Tabelas: alteração Nesta seção apresenta-se o comando da família DDL, ALTER TABLE, cuja finalidade consiste em realizar mudanças em tabelas previamente criadas.

O exemplo 2.1 acrescenta uma restrição tipo Unique à tabela de filmes, sob o campo NOME.

ALTER TABLE FILME ADD CONSTRAINT FILME_01_U UNIQUE (NOME);

Exemplo 2.1: Restrição Unique

Existem duas alternativas de execução do comando apresentado no Exemplo 2.1. Pode-se fazê-lo utilizando uma SQL Worksheet do SQL Developer (Figura 2.7) ou, mais rapidamente, via SQL*Plus, uma aplicação não gráfica, porém bastante adequada para este tipo de tarefa (Figura 2.8).

12 Trata-se de uma característica interna do banco de dados, especificada na

sua criação. Caso utilize-se por base idiomas possu indo um conjunto de caracteres mais amplo (japonês, por exemplo), cada símbolo passa a requerer dois bytes. Nestes casos, ao especificar o tamanho de uma cadeia em, por exemplo, 100 bytes, significa, na verdade, 50 caracteres.


Figura 2.7: Restrição FILME_01_U Sendo Criada Graficamente

Figura 2.8: Restrição FILME_01_U Sendo Criada via SQL*Plus

A constatação da presença de FILME_01_U pode acontecer abrindo-se a Caixa de Diálogo mostrada na Figura 2.9, ativada clicando-se o botão


direito do mouse sobre o nome da tabela e selecionando-se Edit. Depois, basta ativar Unique Constraints.

Figura 2.9: Restrição FILME_01_U criada

A criação das demais restrições da tabela FILME será efetuada de uma vez, utilizando um script. Inicialmente serão gravados, em um arquivo à parte os comandos apresentados no Exemplo 2.2

ALTER TABLE FILME ADD CONSTRAINT FILME_01_CK CHECK (ANO > 1900); ALTER TABLE FILME ADD CONSTRAINT FILME_02_CK CHECK (DURACAO_MINUTOS BETWEEN 10 AND 300); ALTER TABLE FILME ADD CONSTRAINT FILME_03_CK CHECK (CENSURA BETWEEN 0 AND 18);

Exemplo 2.2: Restrições Check


Observações:

� Perceba como a criação de uma restrição check assemelha-se à de uma unique, mudando apenas a terceira linha do comando;

� O fato de uma coluna não ser mandatória, isto é, seu preenchimento não resultar obrigatório, faz com que suas restrições CHECK aceitem também valores nulos, além daqueles especificados na regra. Assim, podemos concluir que a coluna CENSURA aceitaria números entre 0 e 18, mais NULL.

� O operador BETWEEN informa os limites inferior e superior de uma faixa de valores. A seguinte expressão poderia ser utilizada no segundo comando, obtendo o mesmo efeito:

CHECK (DURACAO_MINUTOS >= 10 AND DURACAO_MINUTOS <= 300);

Assumindo que o script criado a partir do Exemplo 2.2 tenha sido gravado em E:\Scripts\02_Cria_Constraints_Check_Filmes.sql , a sua execução poderia acontecer de duas formas. Pelo SQL Developer, executar o comando File, Open informando localização e nome do arquivo cujos comandos desejam-se executar. Uma vez aberto, basta executá-lo pressionando no botão Run Script (Figura 2.10).

Figura 2.10: Execução de Script Utilizando SQL Developer


Uma alternativa mais interessante à criação gráfica consiste em utilizar a ferramenta SQL*Plus. Assumindo o diretório onde se localiza o arquivo por executar como sendo o corrente, a instrução descrita no Exemplo 2.3 invoca a ferramenta, realiza a conexão e executa o script.

E:\SCRIPTS>SQLPLUS locadora/bonfilme @02_CRIA_CONST RAINTS_CHECK_FILMES

Exemplo 2.3: Execução de Script Utilizando SQL*Plus

O comando DDL ALTER TABLE permite realizar diversas tarefas, como exemplificadas nos próximos exemplos.

ALTER TABLE FILME MODIFY NOME VARCHAR2(200);

Exemplo 2.4: Mudança de Tamanho de Campo

Observação:

� Permite-se aumentar ou reduzir tamanhos de campos, seguindo o exemplo 2.4. Entretanto, ao diminuí-lo, não podem existir dados cujos tamanhos superem o novo tamanho.

A comprovação da mudança pode ser feita tanto via SQL Developer, quanto SQL*Plus. No primeiro caso, deve-se executar o comando Open, disponibilizado no menu aberto após clicar com o botão direito sobre o nome da tabela. Já pelo SQL*Plus, basta executar o comando:

DESCRIBE FILME

O resultado aparece na Figura 2.11


Figura 2.11: Exibição da estrutura da tabela FILME

Perceba que DESCRIBE (ou DESC) não termina com ponto-e-vírgula, assim como todo comando SQL. O motivo é simples: trata-se de um comando específico da ferramenta SQL*Plus. Na verdade, esta instrução também pode ser utilizada em alguma SQL Worksheet do SQL Developer.

A obrigatoriedade de preenchimento de uma coluna também é passível de mudança, desde que o novo estado não contrarie dados pré-existentes. Por exemplo, na tabela FILME, o atributo NOME_ORIGINAL não poderia ser alterado de NULL para NOT NULL, caso existisse algum registro cujo conteúdo nesta coluna fosse vazio.

ALTER TABLE FILME MODIFY NOME_ORIGINAL NOT NULL;

Exemplo 2.5: Mudança de Obrigatoriedade de Preenchimento de Campo

Observações:

� Ainda que não produza erro algum, a tentativa de mudança de um atributo constituinte da chave primária da tabela para NULL, a mudança não acontece de fato.

� Nada impede que sejam alterados tamanho de campo e obrigatoriedade de preenchimento numa mesma instrução:

ALTER TABLE FILME MODIFY NOME_ORIGINAL VARCHAR2(200) NOT NULL;

A mudança de valores de coluna pré-definidos (defaults), também segue a mesma lógica, como apresentado no exemplo 2.6.


ALTER TABLE FILME MODIFY CENSURA DEFAULT 12;

Exemplo 2.6: Mudança de Valor Default

O acréscimo de uma nova coluna aparece no Exemplo 2.7

ALTER TABLE FILME ADD GENERO VARCHAR2(20);

Exemplo 2.7: Acréscimo de Nova Coluna

Uma coluna pode ter seu nome trocado, como apresentado no Exemplo 2.8.

ALTER TABLE FILME RENAME COLUMN GENERO TO CLASSE;

Exemplo 2.8: Coluna, cujo Nome foi trocado

Observações:

� Assim como colunas, tabelas podem ter seus nomes trocados utilizando a mesma cláusula RENAME. Por exemplo, a tabela de filmes poderia receber outro nome:

ALTER TABLE FILME RENAME TO PELICULA;

� Já para trocar o nome de uma restrição, deve-se acrescentar a palavra reservada CONSTRAINT:

ALTER TABLE FILME RENAME CONSTRAINT FILME_03_CK TO FILME_04_CK;

A remoção de uma coluna aparece no Exemplo 2.9

ALTER TABLE FILME


DROP COLUMN GENERO;

Exemplo 2.9: Remoção de Coluna

Observações:

� A exclusão de uma coluna implica necessariamente na perda dos dados nela armazenada, portanto, deve-se tomar MUITO cuidado antes de executar tal instrução.

� Não é permitida a exclusão de um campo participante de chave primária, caso exista ao menos uma chave estrangeira vinculada.

A remoção de uma restrição aparece no Exemplo 2.10.

ALTER TABLE FILME DROP CONSTRAINT FILME_01_CK;

Exemplo 2.10: Remoção de Restrição

O próximo exemplo, 2.11, exibe um script, 02_Cria_Tabela_ Exemplar.sql , onde cria-se a segunda tabela e ainda vincula-se a mesma com a tabela FILME atarvés da criação de uma chave estrangeira (foreign key).

CREATE TABLE EXEMPLAR( COD_EXEMPLAR NUMBER(10, 0) NOT NULL, COD_FILME NUMBER(10, 0) NOT NULL ); ALTER TABLE EXEMPLAR ADD CONSTRAINT EXEMPLAR_PK PRIMARY KEY (COD_EXEMPLAR); ALTER TABLE EXEMPLAR ADD CONSTRAINT FILME_EXEMPLAR_FK FOREIGN KEY (COD_FILME) REFERENCES FILME(COD_FILME) ;

Exemplo 2.11: Criação de Tabela EXEMPLAR com duas Restrições (Constraints)

Observação:


� Os três comandos descritos no exemplo acima poderiam ser

compactados em apenas um CREATE TABLE: CREATE TABLE EXEMPLAR( COD_EXEMPLAR NUMBER(10, 0) NOT NULL, COD_FILME NUMBER(10, 0) NOT NULL, CONSTRAINT EXEMPLAR_PK PRIMARY KEY (COD_EXEMPLA R), CONSTRAINT FILME_EXEMPLAR_FK FOREIGN KEY (COD_F ILME) REFERENCES FILME(COD_FILME) );

2.6 – Tabelas: eliminação A eliminação de tabelas ocorre utilizando-se a instrução do grupo DDL, DROP TABLE. Muito cuidado deve ser observado ao utilizar este comando, já que incorre na exclusão de dados. Quando a tabela for primária, isto é, sua chave principal é referenciada por restrições Foreign Key (chaves estrangeiras), deve-se reforçar a finalidade de supressão. A interação apresentada no Exemplo 2.12 demonstra este fato.

SQL> DROP TABLE FILME; DROP TABLE FILME * ERRO NA LINHA 1: ORA-02449: CHAVES PRIMÁRIAS/EXCLUSIVAS NA TABELA REFERENCIADAS POR CHAVES EXTERNAS SQL> DROP TABLE FILME CASCADE CONSTRAINTS; TABELA ELIMINADA. SQL>

Exemplo 2.12: Remoção da Tabela FILME

A cláusula CASCADE CONSTRAINTS acarreta na eliminação do constraint FILME_EXEMPLAR_FK, para somente depois proceder com a exclusão da tabela FILME. Evidentemente, também seria possível primeiro destruir EXEMPLAR, para depois eliminar FILME, agora sem a necessidade da referida cláusula.


2.7 – Tabelas: inserção de dados Concluído o Projeto Físico, já devem ter sido criadas todas as tabelas com suas respectivas restrições. O próximo passo consiste em alimentá-las, o que pode ser levado a cabo por aplicações desenvolvidas por qualquer ambiente de programação gráfico capaz de produzir formulários para entrada de dados.

O principal comando SQL responsável pela inserção de dados13 em tabelas pertence ao grupo DML (Data Manipulation Language) e chama-se INSERT. Cada execução insere um registro em uma determinada tabela.

Assumindo que tenha-se executado o script 02_Cria_Tabela_Filme.sql , o comando apresentado no Exemplo 2.13 insere um registro na tabela de filmes.

INSERT INTO FILME ( COD_FILME, NOME, NOME_ORIGINAL, ANO, DURACAO_MINUTOS, PRECO_SUGERIDO_LOCACAO, CENSURA) VALUES ( 2, 'Amor Além da Vida ', 'What Dreams May Come', 1998, 113, 6, 12);

Exemplo 2.13: Inserção de um Registro na Tabela FILME

Para cada coluna da tabela, existe um valor associado de forma posicional. Desta forma, para a quarta coluna, ANO, atribui-se o quarto valor, 1998.

Toda operação que altere dados incorre numa Transação, que significa um conjunto de comandos DML, cujo resultado pode ser ratificado ou

13 Como veremos no próximo capítulo, existem alternat ivas à inserção de um

registro por vez


descartado. Assim, para confirmar a inserção descrita no Exemplo 2.13, ainda deveria ser executado mais um comando:

COMMIT;

Caso contrário, ou seja, se a inserção deve ser descartada, deve-se emitir o comando:

ROLLBACK;

O conceito de Transação e suas diversas implicações será tema de estudo mais detalhado no Capítulo Quatro.

Caso a ordem dos valores corresponda à ordem e à totalidade das colunas, estas podem ser omitidas no comando INSERT. Assim, o comando a seguir teria efeito análogo ao utilizado no Exemplo 2.13:

INSERT INTO FILME VALUES ( 2 , 'AMOR ALÉM DA VIDA ' , 'WHAT DREAMS MAY COME', 1998,113,6,12 );

A prática de omissão de colunas deve ser evitada por três razões:

1. Perde-se em clareza, já que não se sabe qual campo recebeu qual valor;

2. Corre-se o risco de inserir valores incompatíveis. Por exemplo, uma cadeia de caracteres em uma coluna numérica, ou uma data inválida;

3. Mesmo que não haja incompatibilidades de tipos, pode-se facilmente trocar valores. Por exemplo, a simples troca de dois números faria com que duas colunas recebessem valores incorretos.

Caso existam colunas cujo conteúdo não seja obrigatório ou possuam valores pré-definidos (defaults), tanto colunas como valores podem ser omitidos. Não haveria nada incorreto nesta instrução:

INSERT INTO FILME (COD_FILME, NOME) VALUES (2,'Amor Além da Vida');

Colunas cujo preenchimento não seja obrigatório possuindo valores pré-definidos também podem receber o valor NULL:


INSERT INTO FILME (COD_FILME, NOME, CENSURA) VALUES (2,'Amor Além da Vida', NULL);

A comprovação de que uma linha foi inserida numa tabela pode ser feita realizando uma consulta à tabela, assunto largamente explorado no próximo capítulo:

SELECT * FROM FILME;

2.8 – Sequences Chaves primárias possuindo valores sequenciais podem ter seus conteúdos preenchidos utilizando uma sequence. Trata-se de um objeto Oracle, assim como tabela, que simplesmente gera números em sequência. O Exemplo 2.14 cria uma sequence utilizada logo a seguir numa inserção na tabela de filmes.

CREATE sequence s_filmes increment BY 1 START WITH 3 nomaxvalue nocycle; INSERT INTO FILME ( COD_FILME , NOME , NOME_ORIGINAL , ANO , DURACAO_MINUTOS , PRECO_SUGERIDO_LOCACAO, CENSURA ) VALUES ( s_filmes.nextval , 'Casa dos Espíritos, A' , 'The House of the Spirits', 1993,150, 8.16, 16 );

Exemplo 2.14: Sequence em ação


Observações:

� Criou-se uma sequence, cujo primeiro número fornecido será 3 (START WITH) e o último será determinado pelo maior número inteiro possível (1027). Na hipótese altamente improvável que este imenso número seja atingido, a sequência não será reiniciada (NOCYCLE);

� A pseudo-coluna NEXTVAL retorna o próximo número; � Caso omita-se START WITH, assume-se 1; Idem para INCREMENT

BY; � NOMAXVALUE e NOCYCLE são opções default; � Em princípio, S_FILMES poderia ser utilizada para alimentar outras

chaves primárias; � O comando acima foi extraído do arquivo de apoio

02_Exemplo_Sequence.sql .

Prática Recomendada Tenha o hábito de criar uma sequence para cada surrogate key (chave primária numérica). Além de NEXTVAL, existe a pseudo-coluna CURRVAL que mostra o último número fornecido (valor corrente). Para ativá-la, podemos utilizar o comando SELECT, que será visto exaustivamente no próximo capítulo. Analise o Exemplo 2.15.

SQL> SELECT S_FILMES.CURRVAL FROM DUAL; CURRVAL ---------- 3

Exemplo 2.15: CURRVAL em ação

Há um detalhe bastante inconveniente quanto à utilização da pseudo-coluna CURRVAL. Ela não pode ser utilizada em uma sessão que ainda não tenha utilizado NEXTVAL. Assim, o seguinte erro acontecerá caso repita-se o comando do Exemplo 2.15 em uma outra sessão:

SQL> SELECT S_FILMES.CURRVAL FROM DUAL; SELECT S_FILMES.CURRVAL FROM DUAL * ERRO NA LINHA 1: ORA-08002: A SEQUENCIA S_FILMES.CURRVAL AINDA NÃO F OI DEFINIDO NESTA SESSÃO


SQL>

A única possível solução consiste na chamada a NEXTVAL previamente à de CURRVAL:

SQL> SELECT S_FILMES.NEXTVAL FROM DUAL; NEXTVAL ---------- 4 SQL> SELECT S_FILMES.CURRVAL FROM DUAL; CURRVAL ---------- 4

O Exemplo 2.16 altera S_FILMES para que seu incremento seja de 5 ao invés de 1.

ALTER sequence s_filmes increment BY 5;

Exemplo 2.16: ALTER SEQUENCE em ação

Observação:

� Infelizmente, resulta impossível alterar o número inicial da sequence. Esta deve ser recriada.

O Exemplo 2.17 elimina S_FILMES.

DROP sequence s_filmes;

Exemplo 2.17: DROP SEQUENCE em ação

ENTREVISTA: RECYCLE BIN

Neste capítulo iniciamos a série de entrevistas com Samnir Queops Lepuzinevsky, ou S.Q.L, como é conhecido por seus colegas, clientes e


amigos. Ilustre Administrador de Bancos de Dados, filho de pai egípcio e mãe polonesa, construiu uma reputação inabalável nestes dez anos atuando como evangelista Oracle. A presente entrevista foi concedida ao notório jornalista Libriano Zuben-el-Genubi e trata sobre Recycle Bin, um interessantíssimo recurso presente desde a versão 10g.

- Boa tarde, senhor Samnir. É um prazer imenso recebê-lo mais uma vez em nosso programa. Hoje vamos falar sobre Recycle Bin, um recurso Oracle que dá margem ao arrependimento. Inicialmente, Senhor S.Q.L., gostaria que falasse um pouco sobre esta funcionalidade e o que exatamente a Oracle quis dizer com “arrependimento”.

- Boa tarde Senhor Libriano; Boa tarde queridos tele-espectadores. É uma satisfação muito grande estar aqui novamente e ter a chance de esclarecer assuntos tão cativantes. Bom, em resumo, Recycle Bin tem o mesmo papel de sua homônima em Sistemas Operacionais, ou seja, ao apagar uma tabela, esta não desaparece imediatamente; ao contrário, é movida para uma área especial. Daí a possibilidade de arrepender-se após um DROP TABLE; é possível desfazer o seu nefasto efeito.

- Incrível! Mostre como!

- Vamos criar uma tabela simples, NUMEROS, contendo apenas um atributo numérico chamado NUM:

CREATE TABLE NUMEROS (NUM NUMBER);

- Que tal uma linha?

INSERT INTO NUMEROS VALUES (1);

- A seguir vamos destruí-la:

DROP TABLE NUMEROS;

- Temporariamente podemos achar que nunca mais a veremos, porém, ao consultar uma área especial chamada Recycle Bin, vemos que nada foi perdido14:

SELECT OBJECT_NAME, ORIGINAL_NAME , OPERATION , TYPE ,

14 O comando SELECT será visto em detalhes no próximo capítulo.


CREATETIME , DROPTIME FROM RECYCLEBIN;

- Vejamos na figura 2.12 o resultado da operação acima:

Figura 2.12: Tabela eliminada ainda existe!

- O que ocorre, na verdade, é que o Oracle troca o nome da tabela original por outro, começando por BIN$. Inclusive, podemos consultar a tabela recém destruída, porém utilizando seu novo e esdrúxulo nome:

SQL> SELECT * FROM "BIN$XV9LWFZQTA+MSIYEXBW9CA==$0"; NUM ---------- 1

- Já que a tabela não foi realmente destruída, podemos recuperá-la utilizando um comando especial:

SQL> FLASHBACK TABLE NUMS TO BEFORE DROP; FLASHBACK CONCLUÍDO. SQL> SELECT * FROM NUMEROS;


NUM ---------- 1 SQL> SELECT * FROM RECYCLEBIN; não há linhas selecionadas - Então, toda tabela destruída vai para essa área especial chamda Recycle Bin?

- Perfeitamente!

- Faz diferença que tenha dados ou não?

- Nenhuma!

- Esta facilidade aplica-se a outros objetos, como índices e visões?

- Sim. Observe na Figura 2.12 a coluna type. Ela indica o tipo de objeto destruído. Infelizmente, não conseguimos recuperar constraints. Uma vez apagados via ALTER TABLE, não temos como utilizar a Recycle Bin para trazê-los à vida novamente.

- E como podemos “limpar” a Recycle Bin?

- Temos várias alternativas. Uma delas, nós já fizemos, ou seja, ao restaurar uma tabela via comando flashback, ela sai da Recycle Bin. Caso não desejássemos restaurá-la, mas realmente destrui-la, poderíamos fazer:

Purge table "BIN$BUeh4K2SR/GfOLgmVb31yg==$0"; - Caso não desejássemos nem ter a possibilidade de restaurá-la, poderíamos não enviá-la à Recycle Bin:

DROP TABLE NUMS PURGE; - Objetos eliminados ficam lá para sempre?

- Infelizmente, não. Objetos que ocupam espaço são armazenados em áreas especiais chamadas tablespaces, cujo controle de espaço é bastante automatizado. Acontece que, quando espaço se faz necessário (uma tabela cresceu, por exemplo), busca-se espaço disponível na tablespace corrente. Caso não seja encontrado, recupera-se a área utilizada pela Recycle Bin, apagando objetos lá existentes.

- Então, não vale confiar cegamente que toda tabela uma vez eliminada poderá ser recuperada.


- Correto!

- E como ficam as restrições? Elas também voltam?

- Aí temos um problema! Ao restaurar uma tabela com restrições, estas voltam, sim, porém com nomes gerados após a remoção.

- Como assim? Quer dizer que se eu tenho o salutar hábito de dar nomes aos meus constraints, tal qual FILME_CK_01, este nome não será restaurado?

- Infelizmente, não.

- Vimos que a Recycle Bin pode ser consultada via select. Existe algum recurso gráfico para inspecioná-la?

- Sim. Pelo SQL Developer. Veja a Figura 2.13

Figura 2.13: Consulta à Recycle Bin via SQL Developer

- Bom, Senhor Samnir, acho que foi possível esclarecer bastante o assunto. Gostaria de agradecer sua presença e contamos com sua visita em breve.


- Eu agradeço o convite e permaneço à disposição para quaisquer outras oportunidades.

EXERCÍCIOS 1) Elabore o Projeto Físico da tabela de clientes, tomando por base seu

Projeto Lógico (veja Capítulo 1, Tabela 1.10) e o Projeto Físico da tabela de filmes (Tabela 2.5)

2) Informe quais nomes de tabelas a seguir seriam válidos.

a) CLIENTE

b) 123

c) PROFISSIONAL DE CINEMA

d) CLIENTE2

e) LOCAÇÃO

3) Gere um SQL que permita criar a tabela de clientes:

a) Sete campos, sendo dois obrigatórios;

b) Uma chave primária;

c) Uma restrição para a coluna UF (RJ, SP, MG ou ES);

d) Valores pré-definidos para as colunas UF e Cidade (‘MG’ e ‘Bicas’, respectivamente).

As restrições podem ser geradas no próprio CREATE TABLE, ou via ALTER TABLE.

4) Faça NOME mandatório.

5) Estenda o atributo ENDERECO para 100 caracteres.

6) Acrescente mais duas colunas, CEP e BAIRRO (deduza seus tamanhos e obrigatoriedade de preenchimento).

7) Elimine a coluna de bairros, já que esta informação poderia fazer parte do endereço.

8) Faça alguns testes para melhor conhecer a Recycle Bin:

a) Crie uma tabela qualquer;


b) Elimine a tabela recém criada;

c) Crie outra tabela, homônima, porém possuindo estrutura diferente

d) Recupere a tabela original. Qual versão foi restaurada, a primeira ou a segunda?

e) Você conseguiria fazer uma nova restauração? Tente! E não se esqueça de anotar suas conclusões.

9) Neste exercício você compreenderá a relação entre os constraints PRIMARY KEY e UNIQUE com a obrigatoriedade de preenchimento.

a) Crie esta tabela:

CREATE TABLE TESTA_RESTRICAO (CHAVE NUMBER NOT NULL, CAMPO NUMBER, CONSTRAINT TESTA_RESTRICAO_PK PRIMARY KEY (CHAVE), CONSTRAINT CAMPO_U UNIQUE(CAMPO));

b) Execute o comando a seguir para inserir uma linha:

INSERT TESTA_RESTRICAO VALUES (1, NULL);

c) Agora insira mais uma linha:

INSERT TESTA_RESTRICAO VALUES (2, NULL);

d) Agora responda:

i) É possível atribuir NULL a uma coluna definida como PRIMARY KEY?

ii) E a uma coluna UNIQUE (sem NOT NULL)

iii) É possível inserir vários nulos em uma coluna definida como UNIQUE?

10) Abra o script 02_Projeto_Fisico_Locadora.sql e responda:

a) Alguma tabela está sendo eliminada?

b) Ocorrem relacionamentos?

c) Onde criam-se restrições? Nos comandos CREATE TABLE, ou nos comandos ALTER TABLE?

11) Execute o script 02_Projeto_Fisico_Locadora.sql .


12) Verifique se o seu usuário possui todas as tabelas citadas no script recém executado.

13) Crie uma sequence para alimentar a chave primária da tabela de clientes.

14) Insira pelo menos três registros na tabela CLIENTE. Leve em conta valores pré-assumidos. E não se esqueça de utilizar a sequence criada no exercício anterior.

15) Execute o script 02_Alimenta_Tabelas.sql. O resultado final deve ser:

TABLE_NAME NUM_ROWS ------------------------------ ---------- CLIENTE 33 EXEMPLAR 104 FILME 21 LOCACAO 1508 PAPEL 5 PARTICIPACAO 73 PROFISSIONAL_CINEMA 65 7 linhas selecionadas.

16) Como está a Recycle Bin? Esvazie-a.

capÍtulo 2 – tabelas - eduardo terra morelli database … · 2009-06-01 · cluster), que...

Documents