Apostila Banco de Dados LL

FACULDADE CENECISTA DE VARGINHA
Apostila
BANCO DE DADOS II
2012
ÍNDICE
Unidade I. REVISÃO CONCEITUAL ......................................................................................................................... 9
I.1. SGDB ........................................................................................................................................................................... 9
I.2. MODELO de dados relacional ........................................................................................................................... 9
I.2.1. Esquema ..................................................................................................................................................... 9

I.2.2. Banco de dados ....................................................................................................................................... 10
I.2.3. Tabela........................................................................................................................................................... 10
I.2.4. Relação ........................................................................................................................................................ 10
I.2.5. Tupla ............................................................................................................................................................. 10

I.2.6. Domínio ...................................................................................................................................................... 10
I.2.7. Atributo ....................................................................................................................................................... 10

I.2.8. Chave-primária ......................................................................................................................................... 10
I.2.9. Chave estrangeira ................................................................................................................................... 10

I.2.10. Chave única .......................................................................................................................................... 10
I.2.11. Chave de verificação......................................................................................................................... 10

I.2.12. Normalização ...................................................................................................................................... 11
I.2.13. SQL .......................................................................................................................................................... 11

I.2.14. DDL .......................................................................................................................................................... 11
I.2.15. DCL .......................................................................................................................................................... 11
I.2.16. DML ......................................................................................................................................................... 12

I.2.17. Metadata ............................................................................................................................................... 12
I.2.18. Dicionário de dados ......................................................................................................................... 12
I.2.19. Catálogo de dados ............................................................................................................................ 12
I.3. ALGUMAS TECNOLOGIAS PARA BANCO DE DADOS RELACIONAL ................................................. 13
I.3.1. Servidores de banco de dados relacionais ................................................................................... 13
I.3.2. Ferramentas para manipulação ......................................................................................................... 13
I.4. ATIVIDADES I ........................................................................................................................................................... 14
Unidade II. CONSULTAS AVANÇADAS COM SQL ............................................................................................. 16

II.1. JOINS .......................................................................................................................................................................... 16
II.1.1. INNER JOIN................................................................................................................................................ 16

II.1.2. OUTER JOIN (LEFT/RIGHT/FULL) ....................................................................................................... 16
II.1.3. CROSSJOIN ................................................................................................................................................ 16
II.2. UNION ........................................................................................................................................................................ 17

II.3. SELECT FROM SELECT .......................................................................................................................................... 17
II.4. FIRST ........................................................................................................................................................................... 17
II.5. SKIP .............................................................................................................................................................................. 17
II.6. ROWS.......................................................................................................................................................................... 18
II.7. CONCATENAÇÃO .................................................................................................................................................. 18
II.8. ATIVIDADE II ............................................................................................................................................................ 18

Unidade III. ÍNDICES E FUNÇÕES......................................................................................................................... 19
III.1. Índices ............................................................................................................................................................... 19

III.1.1. Índice Primário .................................................................................................................................... 19
III.1.2. Índice de agrupamento (clustering) ........................................................................................... 19

III.1.3. Índice secundário............................................................................................................................... 20
III.1.4. Índice baseado em árvore .............................................................................................................. 20
III.1.5. SQL para manipulação de índices ............................................................................................... 21
III.2. Funções ............................................................................................................................................................. 21
III.2.1. Funções Internas ................................................................................................................................ 21
III.2.2. Funções de usuário ........................................................................................................................... 25
III.3. group by ........................................................................................................................................................... 25
III.3.1. HAVING ................................................................................................................................................. 25
III.4. ATIVIDADE III .................................................................................................................................................. 27

Unidade IV. SEGURANÇA ........................................................................................................................................ 28
IV.1. controle de acesso ....................................................................................................................................... 28
IV.1.1. GRANT.................................................................................................................................................... 28
IV.1.2. REVOKE .................................................................................................................................................. 30

IV.1.3. CONTROLE DE ACESSO NO FIREBIRD....................................................................................... 31
IV.2. ATIVIDADE IV.................................................................................................................................................. 33
Unidade V. dsql - stored procedure ........................................................................................................................ 34
V.1. STORED PROCEDURE ........................................................................................................................................... 34

V.1.1. O comando CREATE PROCEDURE .................................................................................................... 34
V.1.2. Parâmetros ................................................................................................................................................. 34
V.1.3. Declarando variáveis locais ................................................................................................................. 35
V.1.4. Corpo da Procedure ............................................................................................................................... 36
V.1.5. Elementos de linguagem ..................................................................................................................... 36

V.1.6. Bloco de comandos BEGIN-END ....................................................................................................... 36
V.1.7. Comandos de atribuição ...................................................................................................................... 36
V.1.8. Comandos SQL nas STORED PROCEDURES ................................................................................. 37

V.1.9. Usando FOR SELECT e DO ................................................................................................................... 38
V.1.10. Usando o SUSPEND .......................................................................................................................... 38
V.1.11. Criando e modificando Stored Procedures ............................................................................. 39
V.1.12. Apagando e alterando Stored Procedures .............................................................................. 39
V.1.13. Chamando Stored Procedures ..................................................................................................... 40
V.2. ATIVIDADE V ............................................................................................................................................................ 42

Unidade VI. DSQL - TRIGGERS .............................................................................................................................. 43
VI.1. Usando CREATE TRIGGER .......................................................................................................................... 43

VI.2. BEFORE/AFTER ............................................................................................................................................... 44
VI.3. Usando OLD e NEW ..................................................................................................................................... 44

VI.4. Gerando EXCEPTIONS ................................................................................................................................. 44
VI.5. Usando GENERATORS ................................................................................................................................ 45
VI.6. ALterando e excluindo Triggers .............................................................................................................. 45
VI.7. ATIVIDADE VI.................................................................................................................................................. 47
Unidade VII. VIEWS ..................................................................................................................................................... 48
VII.1. O QUE É UMA View? ................................................................................................................................... 48
VII.2. CRIANDO VIEW ............................................................................................................................................. 48
VII.3. Views atualizáveis ......................................................................................................................................... 49
VII.4. atividade VII .................................................................................................................................................... 50

Unidade VIII. TRANSAÇÕES ...................................................................................................................................... 51
VIII.1. Modos de Acesso ......................................................................................................................................... 52
VIII.1.1. READ WRITE ......................................................................................................................................... 52
VIII.1.2. READ ONLY .......................................................................................................................................... 52

VIII.2. Tipos de Bloqueio ......................................................................................................................................... 52
VIII.2.1. WAIT ....................................................................................................................................................... 52
VIII.2.2. NO-WAIT............................................................................................................................................... 52
VIII.3. Nível de isolamento ..................................................................................................................................... 52

VIII.3.1. Read uncommitted ........................................................................................................................... 52
VIII.3.2. Read committed................................................................................................................................. 52
VIII.3.3. Snapshot ............................................................................................................................................... 53
VIII.3.4. Snapshot table stability ................................................................................................................... 53
VIII.4. modo de pré-alocação ............................................................................................................................... 53

VIII.5. Exemplo de transação ................................................................................................................................. 54
VIII.6. ATIVIDADE VIII ............................................................................................................................................... 55
Unidade IX. PROJETO COMPLETO (TRABALHO) ............................................................................................ 56

Unidade X. BANCO DE DADOS DISTRIBUÍDO .................................................................................................... 57
X.1. Principais características de um BDD ............................................................................................................. 57
X.2. Exemplo da Descrição de UM BDD ................................................................................................................ 59
X.3. PROJETO DE BDD................................................................................................................................................... 60
X.4. ADMINISTRAÇÃO DE BDD ................................................................................................................................. 62
X.4.1. Organização e Tarefas da Equipe de Administração ................................................................ 62

X.4.2. Problemas que Afetam a Administração ....................................................................................... 63
X.5. ATIVIDADE X ............................................................................................................................................................ 64

Unidade XI. Banco de dados ORIENTADO A OBJETOS ............................................................................... 65
XI.1. ESTRUTURA E CARACTERÍSITICAS ......................................................................................................... 65

XI.2. Banco de Dados OO no mercado .......................................................................................................... 67
XI.3. Object Definition Language (ODL .......................................................................................................... 67
XI.4. Object Query Language (OQL) ................................................................................................................ 68
XI.5. Object Query Language ............................................................................................................................. 68
XI.6. atividade XI ...................................................................................................................................................... 72
Unidade XII. TECNOLOGIAS EMERGENTES ....................................................................................................... 74
XII.1. DATA WAREHOUSE ..................................................................................................................................... 74
XII.2. DATA MART .................................................................................................................................................... 75
XII.3. OLAP .................................................................................................................................................................. 76

XII.3.1. OLAP com IBExpert ........................................................................................................................... 77
XII.4. Data Mining .................................................................................................................................................... 78
XII.4.1. Tarefas e técnicas em mineração de dados ............................................................................ 79
XII.5. Banco de dados orientado a documentos ......................................................................................... 79

XII.5.1. Comparativo Relacional e Orientado a Documentos .......................................................... 80
XII.6. ATIVIDADE XII ................................................................................................................................................ 83

6
ÍNDICE DE FIGURAS
Figura 1 – Clube.fdb ..........................................................................................................................................................................14

Figura 2 – Índice clusterizado .......................................................................................................................................................20
Figura 3 – índice B+ ..........................................................................................................................................................................20
Figura 4 – Tela de controle de acesso do Ibexpert ..............................................................................................................32
Figura 5 - Transação .........................................................................................................................................................................51
Figura 6 – Esquema de um banco de dados distribuído ...................................................................................................58
Figura 7 – Ambiente de Data Warehouse ................................................................................................................................75
Figura 8 – OLAP com IBExpert ......................................................................................................................................................77
Figura 9 – Gráfico OLAP - IBExpert .............................................................................................................................................78
PREFÁCIO
Este material compreende o conteúdo básico da disciplina Banco de dados II do curso de

Sistemas de Informação.
O objetivo principal é desenvolver um banco de dados relacional considerando os principais
requisitos conceituais de um SGDB e tecnologias emergentes relacionadas a banco de dados.
São requisitos básicos as disciplinas de banco de dados I, lógica de programação e inglês
básico. Espera-se capacitar o aluno a entender/manipular conceitos/ferramentas associados aos
sistemas gerenciadores de banco de dados relacionais (SGBDR) e as principais atividades de
administração de banco de dados.
Os seguintes recursos serão amplamente tratados:
Desenvolvimento de procedimentos na linguagem nativa do SGBD;
Construção de consultas complexas através da SQL;
Análise de operações DML para buscar a otimização visando melhores resultados de
performance;
Apresentar conceitos de transações em SGBDs, como concorrência e recuperação em caso de
falhas.
Além de trazer um referencial que possibilita a compreensão dos principais conceitos, este
material apresenta ferramentas, exemplos e aplicações práticas que possibilitam ao aluno
entender, observar e praticar a construção de bancos de dados de acordo com o cenário de
estudo.
A linguagem SQL será abordada de forma mais aprofundada para permitir que o aluno possa
executar operações avançadas para tirar melhor proveito do banco de dados.
Ao final do período o aluno terá condições de projetar banco de dados relacional, manipular
dados e extrair informações conforme suas necessidades, gerenciar e administrar um banco de
dados completo.
8
INTRODUÇÃO
Depois de conhecer os principais conceitos que envolvem banco de dados, na disciplina de

banco de dados I, este material visa complementar o estudo desta tecnologia, completando os
conceitos não abordados anteriormente.
Para um bom aproveitamento dos conteúdos apresentados é imprescindível que o aluno reveja
os conceitos vistos anteriormente e pratique todos os comandos apresentados.
É importante frisar que um profissional de sucesso em banco de dados precisa experimentar
diversas ferramentas, tecnologias em múltiplos cenários para desenvolver com tranqüilidade as
tarefas e superar os desafios atípicos.
Recomenda-se buscar outras fontes de informações como livros, disponíveis na biblioteca da
Instituição, visitar sites especializados, instalar servidores de bancos de dados e implementar
soluções desde as mais simples até aquelas que usam todos os conceitos abordados.
9
UNIDADE I. REVISÃO CONCEITUAL
I.1. SGDB
Um SGBD - Sistema de Gerenciamento de Banco de Dados é uma coleção de programas que

permitem ao usuário definir, construir e manipular Bases de Dados para as mais diversas
finalidades.
Propriedades básicas de um SGDB:
Autocontenção;
Independência dos Dados;
Abstração dos Dados;
Múltiplas Visões de dados;
Transações;
Acesso automático;
Controle de redundância dos dados;
Compartilhamento de dados entre múltiplos usuários;
A restrição de acesso aos dados para usuários não autorizados;
Os diferentes tipos de interface para os diferentes usuários;
A representação dos dados com um nível grande de complexidade;
Garantia da restrição de integridade, que mantém os dados íntegros;
Mecanismos de segurança dos dados, tais como, cópia (backup) e recuperação (recovery)
de dados;
Flexibilidade na mudança das estruturas de dados;
Garantia de que dados sempre atuais estão disponíveis;
Economia de escala relacionada com a redução do tempo de desenvolvimento da
aplicação, já que um dado usado uma vez continuará disponível para outras aplicações.
I.2. MODELO DE DADOS RELACIONAL
O modelo relacional é um dos modelos mais utilizados e, apesar das recentes atualizações,
ainda é considerado um padrão para a maioria das aplicações em banco de dados.
A base da moderna tecnologia de banco de dados é, sem dúvida, o modelo
relacional: é essa base que faz da área uma ciência. (DATE, 2003, p. 93)
I.2.1. Esquema
Esquema relacional é um conjunto de entidades e relações do tipo: R(A1,A2,...,An)

Onde: R – é o nome de uma relação;
Ai – é o nome de um atributo que representa um papel de um domínio D em R – dom (Ai);
n – é o grau da relação.
10
I.2.2. Banco de dados
É um conjunto de tabelas relacionadas incluindo suas restrições, regras e dados.
I.2.3. Tabela
Uma tabela é, na verdade, uma matriz de linhas e colunas, onde as linhas também são
chamadas de registros e as colunas são chamadas de campos.
I.2.4. Relação
Uma relação r(R) é um conjunto de n-tuplas r = {t1, t2,..., tn}, onde cada n-tupla t é uma lista
ordenada de n valores t=(v1, v2,...,vn), sendo cada vi um elemento do dom(Ai) ou um valor
especial nulo.
I.2.5. Tupla
É cada linha da tabela, também chamada de registro.
I.2.6. Domínio
Um domínio D é um conjunto de valores atômicos (indivisível). Um método comum para

especificação de domínio é definir um tipo de dado do qual os valores de dados que formam o
domínio sejam retirados.
I.2.7. Atributo
Um atributo é cada coluna de uma tabela, também chamado de campo.
I.2.8. Chave-primária
É o atributo ou conjunto de atributos que serve para identificar uma tupla.

Dizemos que uma chave primária (Primary key) é simples quando é formada por apenas um
atributo, ou composta quando formada por mais de um atributo.
As relações em um banco de dados se estabelecem a partir das chaves primárias.
Uma chave primária não pode ser duplicada e não pode aceitar valor nulo (null).
I.2.9. Chave estrangeira
São atributos que identificam registros em outras tabelas. A chave estrangeira (constraints key)
serve para representar uma tupla armazenada em outra tabela do mesmo banco de dados para
estabelecer uma restrição.
I.2.10. Chave única
Uma chave única tem a função de impedir a duplicidade de atributos denominados chave
candidata, ou seja, que serve para identificar a tupla, mas não é chave primária.
Podemos dizer que toda chave primária é única mas nem toda chave única é primária.
I.2.11. Chave de verificação
Check constraint é uma chave que restringe ou valida os valores de um atributo. Geralmente
usada para definir domínio de usuário estático ou dinâmico.
Uma restrição estática sempre valida os mesmo valores enquanto que uma restrição dinâmica
valida conforme os valores de uma tabela ou seleção de registros.
11
I.2.12. Normalização
Normalização é um processo através do qual esquemas de relação, que não sejam satisfatórios
às características do modelo relacional, são decompostos em esquemas menores que satisfaçam
as propriedades desejáveis.
Na normalização, são analisadas algumas medidas de qualidade para o projeto de um esquema
de relação. Estas medidas de qualidade visam, por exemplo, evitar um mau uso da memória. As
medidas são as seguintes:
1 – correta representação semântica – os dados devem ser projetados de forma a terem seus
significados bem definidos e coerentes com o que realmente querem representar;
2 – reduções de valores redundantes – sempre que possível deve-se reduzir ao máximo os
valores redundantes desnecessários, ou seja, valores que muitas vezes aparecem repetidos
quando isto não seria preciso;
3 – reduções de valores nulos – sempre que possível deve-se reduzir o número de atributos
que por alguma razão receberão muitos valores nulos;
4 – evitar tuplas espúrias (sem sentido) – durante o processo de normalização deve-se atentar
para evitar que sejam geradas tuplas que não façam sentido diante da realidade, isto pode
ocorrer devido a alguma decomposição.
I.2.13. SQL
Linguagem Estruturada de Consulta (Structured Query Language) usada para:

• definição (DDL) e manipulação (DML) de dados
• definição de visões e autorizações de acesso
• definição de restrições de integridade
• definição de transações.
Podemos dizer que sem o uso de SQL, o trabalho com banco de dados relacional se torna quase
impossível.
SQL é a linguagem padrão para se lidar com bancos de dados relacionais, e é
aceita por quase todos os produtos existentes no mercado. (DATE, 2003, p. 93).
I.2.14. DDL
Subconjunto de comandos SQL destinado a definição de dados (Data Definition Language).

Seus principais comandos são:
CREATE TABLE – Para criar tabelas
ALTER TABLE – Para alterar tabelas (adicionar, alterar / remover atributos, adicionar/remover
chaves)
DROP TABLE – Para excluir tabela.
CREATE VIEW – Para criar visões.
I.2.15. DCL
Subconjunto de comandos SQL destinado ao controle de acesso aos dados (Data Control
Language). Seus principais comandos são:
GRANT – Para atribuir direitos
REVOKE – Para revogar direitos
Os comandos DCL são considerados por muitos como comandos de manipulação (DDL).
12
I.2.16. DML
Subconjunto de comandos SQL destinado a manipulação de dados (Data Manipulation

Language). Seus principais comandos são:
INSERT – Para inserir registro
UPDATE – Para alterar registro(s)
DELETE – Para excluir registro(s)
SELECT – Para consultar um conjunto de registros (relação).
I.2.17. Metadata
Metadados ou Metainformação são dados capazes de descrever outros dados, ou seja, dar um
significado real e plausível a um arquivo de dados, são a representação de um objeto digital.
I.2.18. Dicionário de dados
Dicionário de dados é um grupo de tabelas, habilitadas apenas para leitura ou consulta, ou seja,
é uma base de dados, que entre outras coisas, mantém as seguintes informações:
• Definição precisa sobre elementos de dados
• Perfis de usuários, papéis e privilégios.
• Descrição de objetos
• Integridade de restrições
• Stored procedures e gatilhos
• Estrutura geral da base de dados
• Informação de verificação
• Alocações de espaço
Notação usada no dicionário de dados:
Símbolo Significado
= Constituído por ou definido por
+ E (conjunção ou concatenação)
() Componentes opcionais
[] Componentes alternados
| Separador de componentes alternáveis [ ]
{} Componentes repetidos ou não
** Comentários
@ Chave primária
Exemplos:
Nome = tratamento + primeiro_nome + ultimo_nome
Cortesia = [Sr|Sra|Prof|Dr]
Caracter = [A-Z|a-z| | -]
Descrição = {Caracter}
I.2.19. Catálogo de dados
Catálogos são os locais (estruturas/tabelas) onde os SGDBs armazenam os metadados do

esquema. (tabelas, colunas e outras informações).
Podemos dizer que os catálogos são as tabelas internas do banco de dados que armazenam
informações sobre todos os objetos do banco, ou seja, tudo que foi criado pelo projetista.
13
I.3. ALGUMAS TECNOLOGIAS PARA BANCO DE DADOS RELACIONAL
I.3.1. Servidores de banco de dados relacionais
MySql – Gratuito, rápido e muito utilizado em aplicações WEB e projetos WEB opensource.
PostGreSQL – Gratuito, poderoso e muito conceitual.
Firebird – Originado do Interbase, gratuito, muito disseminado no Brasil.
Oracle – Considerado por muitos o banco de dados ideal para grandes corporações, é pago,
possui muitas soluções integradas e é mutiplataforma.
MS SQL – É pago, ideal para aplicações de médio e grande porte. Usado preferencialmente para
integrar soluções Microsoft. Não é multiplataforma.
I.3.2. Ferramentas para manipulação
dbDesigner – Ferramenta free para modelar diversos bancos de dados.

IBExpert – Ideal para modelar, manipular e administrar banco de dados Firebird é pago, mas tem
versão pessoal free com limitações.
ISQL – Ferramenta nativa e básica para acesso a banco de dados Firebird
Oracle SQLDeveloper - Ferramenta gráfica para administração Oracle no Linux. É free.
SQL Server Manager – Ferramenta para gerenciar banco de dados MS SQL Server. Tem versão
free e paga.
14
I.4. ATIVIDADES I
Questão 1.1: Crie um banco de dados com o nome CLUBE.fdb com a seguinte estrutura:
Figura 1 – Clube.fdb
Questão 1.2: Defina os campos chaves e a integridade referencial envolvendo todas as tabelas
do banco de dados:
15
16
UNIDADE II. CONSULTAS AVANÇADAS COM SQL
II.1. JOINS
De acordo com (CANTU, 2006) faz relacionamento de diversas formas entre diversas tabelas em
um mesmo comando select.
A sintaxe da cláusula JOIN precisa incluir a palavra reservada ON que estabelece a regra da
relação. Chamamos de stream as informações vindas de cada tabela.
II.1.1. INNER JOIN
Também chamado de exclusive join (junção exclusiva) faz o relacionamento entre os streams de
acordo com a expressão da cláusula ON, ignorando registros que não satisfaçam a condição.
A palavra JOIN é opção, ou seja, terá o mesmo efeito se for usada ou não.
Exemplo:
SELECT S.SOC_ID,S.SOC_NOME, C.COT_VALIDADE
FROM SOCIOS S
INNER JOIN COTAS C ON S.SOC_COTA = C.COT_ID
II.1.2. OUTER JOIN (LEFT/RIGHT/FULL)
Uma junção do tipo OUTER irá retornar, inclusive, os registros que não satisfazem a condição da
expressão do stream esquerdo ou direito de acordo com a sintaxe escolhida.
LEFT: Retorna todas as linhas do stream esquerdo.
RIGHT: Retorna todas as linhas do stream direito.
FULL: Retorna todos registros do stream esquerdo e todos do stream direito. Os campos cujo o
registro não satisfaz condição da expressão é representado por NULL.
Exemplo:
SELECT S.SOC_NOME,C.COT_VALIDADE
FROM SOCIOS S
LEFT JOIN COTAS C ON S.SOC_COTA = C.COT_ID
Neste caso, mesmo que não exista na tabela de contas um registro correspondente ao sócio, o
nome dele irá aparecer no stream e o campo COT_VALIDADE irá apresentar o valor NULL.
II.1.3. CROSSJOIN
Retorna o produto cartesiano formado pelos registros das tabelas relacionadas.

Cuidado!
O conjunto dos registros de um CROSSJOIN pode demandar muito
recurso do servidor de banco de dados se as tabelas envolvidas forem
muito grandes.
Exemplo: Uma tabela com 10 registros e outra com 100 irá retornar um
conjunto com 1000 (mil) registros.
17
II.2. UNION
A função do UNION é unir os registros do select anterior aos registros do segundo select.
Um bom exemplo do uso de UNION seria para gerar um conjunto de registros de pessoas
físicas e jurídicas armazenados em tabelas diferentes.
SELECT NOME FROM PESSOA_FISICA
UNION
SELECT NOME FROM PESSOA_JURIDICA
Neste caso os nomes que ocorrerem nas duas tabelas serão apresentados sem repetição.
Para exibir todos os registros é preciso adicionar a palavra ALL na frente de UNION (Union all).
O número de colunas de cada select deve ser igual, bem como, o tipo de cada coluna.
Recomenda-se o uso de funções de conversão (CAST) para adequar a esta restrição do UNION.
II.3. SELECT FROM SELECT
Segundo (CANTU, 2006), SELECT FROM SELECT também chamado de recurso de tabelas
derivadas e está previsto no padrão ANSI SQL.
Este recurso permite a elaboração de consultas mais complexas sem ter que usar views ou
stored procedures.
Exemplo:
SELECT FIRST 10 AVG(NF.TOTAL)
FROM (
SELECT F1.TOTAL FROM FILIAL1 F1
UNION ALL
SELECT F2.TOTAL
FROM FILIAL2 F2
ORDER BY 1 DESC) AS NF
II.4. FIRST
Define quantos registros serão recuperados pelo select, mesmo que existam outros que
satisfaçam aos critérios.
Exemplo:
SELECT FIRST 10 S.SOC_ID, SOC_NOME
FROM SOCIOS S
WHERE UPPER(S.SOC_NOME) CONTAINING ‘SILVA’
Retorna apenas os 10 primeiros registros que atendem aos critérios, ou seja, com a palavra silva
no nome.
II.5. SKIP
Define quantos registros iniciais serão ignorados pelo select antes de começar a retornar dados.
Exemplo:
SELECT FIRST 10 SKIP 5 S.SOC_ID, SOC_NOME
FROM SOCIOS S
WHERE UPPER(S.SOC_NOME) STARTING WITH ‘A’
Os 5 primeiros registros serão ignorados e depois serão retornados os próximos 10.
18
II.6. ROWS
Define o intervalo de registros que serão retornados com o objetivo de limitar o número de
registros.
Exemplo:
SELECT S.SOC_ID,SOC_NOME
FROM SOCIOS S
WHERE UPPER(S.SOC_NOME) LIKE ‘%SILVA%’
ROWS 10
Retorna apenas os 10 primeiros registros que atendem aos critérios, ou seja, com a palavra silva
no nome. Mesmo efeito que a cláusula SKIP.
II.7. CONCATENAÇÃO
O operador de concatenação é utilizado para unir dois valores do tipo string.

No caso Firebird usa-se ‘|’ pipe duplo.
Exemplo:
SELECT NOME || ‘ ‘ || SOBRENOME FROM CLIENTES
II.8. ATIVIDADE II
Passo1: Descreva uma situação onde é preciso utilizar SELECT from SELECT para resolver.
19
UNIDADE III. ÍNDICES E FUNÇÕES
III.1. ÍNDICES
De acordo com Elmasri e Novate (2011), Índices são estruturas de acesso adicionais auxiliares
usadas para aumentar a velocidade da recuperação de registros na resposta a certas condições
de busca.
Quando uma relação não possui índices definidos, o SGBD deve percorrer toda a relação para
localizar os dados desejados. Isso pode demorar muito, mas quando há índices, a busca é
facilitada pelo endereçamento dos dados armazenados.
O uso de índices deve ser regrado, pois, a criação, manutenção e atualização dos índices
demandam recursos de processamento e seu uso sem critérios pode levar a perda de
desempenho ou aumento desnecessário do volume armazenado.
Elmasri e Novate (2011), classificam os índices em:
III.1.1. Índice Primário
É um arquivo ordenado em que os registros são de tamanho fixo e contêm dois campos:
Chave primária: É o conteúdo do mesmo tipo do atributo do registro indexado
Ponteiro: É o ponteiro para o bloco do disco onde o registro se encontra.
Representação: <K(i), P(i)>
Exemplo:
<K(1) = (Pedro), P(1) = endereço do bloco 1>
<K(1) = (João), P(2) = endereço do bloco 1>
<K(1) = (Ana), P(2) = endereço do bloco 2>
Chamamos de índice esparso quando os valores indexados nunca se repetem ou repetem
poucas vezes. Denso quando há várias ocorrências do mesmo valor.
O maior problema deste tipo de índice é o trabalho necessário para incluir e excluir registros, ou
seja, será preciso realizar a ordenação do índice.
III.1.2. Índice de agrupamento (clustering)
Também é um arquivo ordenado e com dois campos, assim como, o índice primário, porém, ao
invés de armazenar a chave primária, armazena um campo que não é chave, logo, há repetições
dos valores, por isto é chamado de agrupamento.
Também é considerado esparso porque para cada registro haverá uma entrada no índice,
ocasionando a repetição.
O problema da inclusão no índice de agrupamento é amenizado reservando-se um bloco inteiro
ou um conjunto de blocos adjacentes para cada valor do campo de clustering.
20
Figura 2 – Índice clusterizado
III.1.3. Índice secundário
Um índice secundário fornece um acesso secundário para um arquivo que já possui acesso
primário. Geralmente usado para campo que é chave candidata e possui valor único para cada
registro com repetição permitida.
Também possui dois campos, porém o segundo nem sempre é o bloco do arquivo, podendo ser
uma chave do índice primário.
Também é classificado como índice denso.
III.1.4. Índice baseado em árvore
Os índices baseados em árvore são usados geralmente para pesquisar intervalos de valores, mas
servem também para pesquisas com operador de igualdade.
Dentre as estruturas em árvore, B+ é a mais usadas pelos SGDBs. Um de seus pontos fortes é o
fato de ser uma estrutura dinâmica.
Exemplo de uma estrutura B+:
Figura 3 – índice B+
Índice multinível:
Para aumentar o desempenho da busca em arquivos muito grandes os
arquivos ordenados (arquivos de índice) possuem seus arquivos
ordenados conforme a necessidade. Estes diversos níveis possíveis são
implementados usando técnicas avançadas para facilitar as inclusões e
exclusões. Quando há uma reserva de entradas para os níveis do índice
dissemos que são índices multiníveis dinâmicos. Exemplos: B-tree e
B-tree+.
21
III.1.5. SQL para manipulação de índices
A criação de índices na maioria dos servidores de banco de dados está implicitamente associada
à criação de chaves (Primária, estrangeira e única).
Isto quer dizer que quando executamos o comando ALTER TABLE para adicionar uma chave,
automaticamente um índice é criado pelo SGDB.
Quando queremos forçar a criação de um índice para um campo que teremos muitas consultas
usamos a seguinte sintaxe:
Para criar índices secundários:
CREATE INDEX [NOME_INDICE] ON [TABELA] ([CAMPO])
Exemplo de criação:
CREATE INDEX T_CLIENTES_IDX1 ON T_CLIENTES (T_CLIENTES_NOME)
Exemplo de exclusão:
DROP INDEX T_CLIENTES_IDX1
O Firebird suporta somente um tipo de índice: uma variação do b-tree. Índices podem ser
únicos ou permitir duplicidades; Eles podem ter uma chave simples ou composta, ascendente
ou descendente.
Para recomputador um índice:
SET STATISTICS INDEX [NOME_INDICE]
Para desativar um índice:
ALTER INDEX [NOME_INDICE] INACTIVE
Para ativar um índice:
ALTER INDEX [NOME_INDICE] ACTIVE
Sintaxe para Firebird 2.5:
CREATE [UNIQUE] [ASC[ENDING] | [DESC[ENDING]] INDEX indexname
ON tablename
{ (<col> [, <col> ...]) | COMPUTED BY (expression) }
<col> ::= a column not of type ARRAY, BLOB or COMPUTED BY
Exemplo:
create descending index ix_events_yt
on MyEvents
computed by (extract(year from StartDate) || Town);
III.2. FUNÇÕES
As funções SQL permitem realizar operações aritméticas, extrações, conversões e agrupamentos

envolvendo dados armazenados ou argumentos especificados em comandos SQL DML.
Há um seleto grupo de funções já previstas pelo padrão ANSI que são encontradas na maioria
dos servidores de banco de dados, mas nem todos os bancos possuem todas as funções
especificadas pelo ANSI.
As funções de agrupamento SUM, AVG, COUNT, MAX e MIN são utilizadas frequentemente com
a cláusula GROUP BY do comando SELECT.
III.2.1. Funções Internas
As funções internas não precisam de nenhum procedimento extra para funcionar, porque já são
disponibilizadas automaticamente quando instalamos o servidor. Na maioria dos bancos de
22
dados, encontramos todas as funções mais comuns. Mas há bancos com funções específicas,
tornando obrigatória a consulta aos manuais de referência.
Até a versão 2.0 do Firebird as seguintes funções internas estavam disponíveis:
Função Descrição ANSI SQL
SUM Retorna a soma de um campo ou expressão de todas as tuplas ANSI
percorridas.
Sintaxe: SUM(arg1)
MAX Retorna o valor máximo de um campo ou expressão encontrado nas ANSI
tuplas percorridas.
Sintaxe: MAX (arg1)
MIN Retorna o valor mínimo de um campo ou expressão encontrado nas ANSI
tuplas percorridas.
Sintaxe: MIN (arg1)
AVG Retorna a média de um campo ou expressão de todas as tuplas ANSI
percorridas.
Sintaxe: AVG(arg1)
COUNT Retorna a contagem dos registros do select de acordo com a cláusula ANSI
group by
IIF Retorna um dos valores possíveis de acordo com o resultado da INTERBASE/
avaliação de uma expressão lógica. FIREBIRD
Sintaxe: IIF (<Condição>, <valor1>, <valor2>)
NULLIF Retorna NULL se um dos valores (valor1, valor2) forem iguais ou valor1 INTERBASE/
se forem diferentes. FIREBIRD
Sintaxe: NULLIF(valor1, valor2)
COALEASE Retornar o primeiro valor não nulo de uma seqüência de valores. INTERBASE/
Sintaxe: Coalease(valor1, valor2,valor3,...) FIREBIRD
CAST Conte uma informação de um determinado tipo em outro tipo. ANSI
Sintaxe: CAST (arg1 as tipo)
EXTRACT Extrai elementos individuais de um campo Data/Hora. ANSI
YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, WEEKDAY, YEARDAY.
Sintaxe: EXTRACT (parte from valor)
Exemplo: EXTRACT(YEAR FROM DATA_EMISSAO)
SUBSTRING Retorna parte de uma String. ANSI
Sintaxe: SUBSTRING(arg1 FROM início [FOR tamanho])
UPPER Converte uma String em letras maiúsculas. ANSI
Sintaxe: UPPER(arg1)
LOWER Converte uma String em letras minículas. ANSI
Sintaxe: LOWER(arg1)
TRIM Remove a ocorrência de espaço ou um determinado caractere ANSI
especificado do início, fim ou ambos de uma String.
Sintaxe: TRIM([[{leading|trailing|both}] [arg1] FROM ] arg2)
GEN_ID Recupera o valor de um GENERATOR. INTERBASE/
Sintaxe: GEN_ID(nome_do_generator, incremento) FIREBIRD
A partir da versão 2.5, foram incluídas muitas outras funções listadas a seguir:
ABS (number)
ACOS (number)
ASCII_CHAR (<code>) - code> ::= an integer in the range [0..255]
ASCII_VAL (ch) - ch ::= a [VAR]CHAR or text BLOB of max. 32767 bytes
ASIN (number)
ATAN (number)
23
ATAN2 (y, x)
BIN_AND (number [, number ...])
BIN_OR (number [, number ...])
BIN_SHL (number, shift)
BIN_SHR (number, shift)
BIN_XOR (number [, number ...])
BIT_LENGTH (str)
CAST (expression AS <target_type>)
CEIL[ING] (number)
CHAR_LENGTH (str)
CHARACTER_LENGTH (str)
CHAR_TO_UUID (ascii_uuid)
COALESCE (<exp1>, <exp2> [, <expN> ... ])
COS (angle)
COSH (number)
COT (angle)
DATEADD (<args>)
DATEDIFF (<args>)
DECODE ( <test-expr>, <expr>, result [, <expr>, result ...] [, defaultresult] )
EXP (number)
EXTRACT (<part> FROM <datetime>) <part> ::= YEAR | MONTH | WEEK | DAY |
WEEKDAY | YEARDAY | HOUR | MINUTE | SECOND | MILLISECOND <datetime> ::=
a DATE, TIME or TIMESTAMP expression
FLOOR (number)
GEN_ID (generator-name, <step>) <step> ::= An integer expression.
GEN_UUID ()
HASH (string)
IIF (<condition>, ResultT, ResultF)<condition> ::= A boolean expression.
LEFT (string, length)
LN (number)
LOG (x, y)
LOG10 (number)
LOWER (str)
LPAD (str, endlen [, padstr])
MAXVALUE (expr [, expr ...])
MINVALUE (expr [, expr ...])
MOD (a, b)
NULLIF (<exp1>, <exp2>)
OCTET_LENGTH (str)
OVERLAY (string PLACING replacement FROM pos [FOR length])
PI ()
24
POSITION (<args>) <args> ::= substr IN string | substr, string [, startpos]

POWER (x, y)
RAND ()
REPLACE (str, find, repl)
REVERSE (str)
RIGHT (string, length)
ROUND (<number> [, <scale>])
<number> ::= a numerical expression
<scale> ::= an integer specifying the number of decimal places
toward which should be rounded, e.g.:
2 for rounding to the nearest multiple of 0.01
1 for rounding to the nearest multiple of 0.1
0 for rounding to the nearest whole number
-1 for rounding to the nearest multiple of 10
-2 for rounding to the nearest multiple of 100
RPAD (str, endlen [, padstr])
SIGN (number)
SIN (angle)
SINH (number)
SQRT (number)
SUBSTRING (str FROM startpos [FOR length])
TAN (angle)
TANH (number)
TRIM ([<adjust>] str)
<adjust> ::= {[where] [what]} FROM
where ::= BOTH | LEADING | TRAILING /* default is BOTH */
what ::= The substring to be removed (repeatedly if necessary)
from str's head and/or tail. Default is ' ' (space).
TRUNC (<number> [, <scale>])
<number> ::= a numerical expression
<scale> ::= an integer specifying the number of decimal places
toward which should be truncated, e.g.:
2 for truncating to a multiple of 0.01
1 for truncating to a multiple of 0.1
0 for truncating to a whole number
-1 for truncating to a multiple of 10
-2 for truncating to a multiple of 100
UPPER (str)
UUID_TO_CHAR (uuid) uuid ::= a string consisting of 16 single-byte characters
25
III.2.2. Funções de usuário
Apesar de já existirem diversas funções previstas pelo padrão ANSI SQL, muitos servidores de
banco de dados possuem suas próprias funções ou não seguem a mesma sintaxe e nome das
funções padronizadas.
Alguns servidores permitem a criação de funções de usuário diretamente em um editor de
código incorporado ao gerenciador.
No caso do INTERBASE/FIREBIRD há poucas funções nativas, mas podemos facilmente adicionar
novas funções disponíveis na Internet, compiladas conforme o sistema operacional.
Para incluir novas funções no Firebird é preciso baixar o arquivo de funções (.DLL) e coloca-lo na
pasta UDF, criada pelo instalador.
Antes de usar a função é preciso realizar a sua declaração.
Veja no exemplo abaixo o comando de declaração de uma função de usuário do Firebird:
DECLARE EXTERNAL FUNCTION UDF_LEN
CSTRING(254)
RETURNS INTEGER BY VALUE
ENTRY_POINT 'udf_Len' MODULE_NAME 'tbudf';
Esta função fica armazenada no arquivo tbudf.dll (Windows) ou tfudf.so (Linux). Serve para
retornar o tamanho de um conteúdo String.
Exemplo de utilização da função declarada acima:
SELECT NOME, UDF_LEN(NOME) AS TAMANHO FROM CLIENTES.
III.3. GROUP BY
A cláusula GROUP BY define os campos que serão agrupados quando se quer usar funções de
agrupamento.
Exemplo:
SELECT CAT.CAT_DESCRICAO,COUNT(*) AS QTD
FROM SOCIOS S
INNER JOIN CATEGORIAS CAT ON CAT.CAT_ID = C.COT_CATEG
GROUP BY CAT.CAT_DESCRICAO
ORDER BY CAT.CAT_DESCRICAO
III.3.1. HAVING
Podemos dizer que HAVING é uma restrição assim como WHERE, porém, aplicável ao resultado
do agrupamento.
Exemplo:
SELECT CAT.CAT_DESCRICAO,COUNT(*) AS QTD
FROM SOCIOS S
INNER JOIN CATEGORIAS CAT ON CAT.CAT_ID = C.COT_CATEG
GROUP BY CAT.CAT_DESCRICAO
HAVING COUNT(*) > 1
ORDER BY CAT.CAT_DESCRICAO
Neste caso, apenas os registros cujo resultado da função de agrupamento COUNT(*) for maior
que 1, serão exibidos. Não seria possível obter o mesmo resultado apenas usando a cláusula
WHERE.
26
Quando devemos usar GROUP BY no SELECT?

Sempre que usamos pelo menos uma função de agrupamento e uma das
colunas do select não tiver função de agrupamento, a cláusula Group by
é necessária para agrupar o resultado.
Exemplo: SELECT CIDADE, SUM(VENDA) AS TOTVENDAS FROM VENDAS
WHERE ESTADO = ‘MG’
GROUP BY CIDADE
27
III.4. ATIVIDADE III
Usar como referência o banco de dados clube.fdb (Figura 1, página 14)

Questão 3.1: Quais campos do banco de dados são indicados como índices secundários?
Questão 3.2: Informe o comando SQL que conta o número de sócios cadastrados agrupando
por descrição da cota:
Questão 3.3: Informe o comando SQL que soma o débito de sócios cadastrados agrupando por
mês/ano:
28
UNIDADE IV.SEGURANÇA
De acordo com (DATE, 2004), as questões de segurança de um banco de dados se referem a:

- Segurança: Proteger os dados contra usuários não autorizados, ou seja, garantir que os
usuários terão permissão de fazer aquilo que estão tentando fazer.
- Integridade: Proteger os dados contra usuários autorizados, ou seja, ter certeza de que aquilo
que os usuários estão tentando fazer está correto.
Principais aspectos relativos à segurança:
• Aspectos legais (direito à informação, previsto em lei).
• Controles físicos (sala dos equipamentos)
• Questões políticas (Quem poderá ter acesso?).
• Problemas operacionais (tipo de senha e sua duração)
• Controles de hardware (Chave de proteção)
• Suporte do sistema operacional (arquivos temporários e logs)
• Questões específicas do SGDB (tem conceito de propriedade dos dados?).
Controle discriminatório: usuário terá direito de acesso diferente sobre objetos diferentes.
Controle mandatário: cada objeto é assinalado com certo nível de classificação e cada usuário
recebe certo nível de liberação.
Criptografia: Para garantir que maior segurança dos dados armazenados, quando um usuário
desrespeita as regras de acesso ou realiza uma invasão local (acesso aos equipamentos) a
contramedida mais eficaz é a criptografia. Basicamente, esta técnica consiste na utilização de
algoritmos que embaralham os dados para dificultar sua leitura sem conhecer os detalhes
usados na codificação.
IV.1. CONTROLE DE ACESSO
Uma das principais propriedades de um SGDB é realizar o controle de acesso aos dados para
permitir que os usuários acessem apenas as informações que o administrador planejou.
IV.1.1. GRANT
Sintaxe:
GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER }
[,...] | ALL [ PRIVILEGES ] }
ON [ TABLE ] nome_da_tabela [, ...]
TO { nome_do_usuário | GROUP nome_do_grupo | PUBLIC } [, ...] [ WITH GRANT OPTION ]
O comando GRANT concede privilégios específicos para um objeto (tabela, visão, seqüência,
banco de dados, função, linguagem procedural, esquema ou espaço de tabelas) para um ou
mais usuários ou grupos de usuários. Estes privilégios são adicionados aos já concedidos, se
existirem.
A palavra chave PUBLIC indica que os privilégios devem ser concedido para todos os usuários,
inclusive aos que vierem a ser criados posteriormente. PUBLIC pode ser considerado como um
grupo definido implicitamente que sempre inclui todos os usuários. Um determinado usuário
possui a soma dos privilégios concedidos diretamente para o mesmo, mais os privilégios
29
concedidos para todos os grupos que este seja membro, mais os privilégios concedidos para
PUBLIC.
Se for especificado WITH GRANT OPTION quem receber o privilégio poderá, por sua vez,
conceder o privilégio a terceiros. Sem a opção de concessão, quem recebe não pode conceder o
privilégio. Atualmente as opções de concessão somente podem ser concedidas a usuários
individuais, e não a grupos ou PUBLIC.
Não é necessário conceder privilégios para o dono do objeto (geralmente o usuário que o
criou), porque o dono possui todos os privilégios por padrão (Entretanto, o dono pode decidir
revogar alguns de seus próprios privilégios por motivo de segurança). O direito de remover um
objeto, ou de alterar a sua definição de alguma forma, não é descrito por um privilégio que
possa ser concedido; é inerente ao dono e não pode ser concedido ou revogado. O dono possui
também, implicitamente, todas as opções de concessão para o objeto.
Dependendo do tipo do objeto, os privilégios padrão iniciais podem incluir a concessão de
alguns privilégios para PUBLIC. O padrão é: não permitir o acesso público às tabelas, esquemas
e espaços de tabelas; para os bancos de dados conceder o privilégio CONNECT e o privilégio de
criação de tabela TEMP; para as funções conceder o privilégio EXECUTE; e para as linguagens
conceder o privilégio USAGE. O dono do objeto poderá, é claro, revogar estes privilégios (para a
máxima segurança o comando REVOKE deverá ser executado na mesma transação que criar o
objeto; dessa forma não haverá espaço de tempo para outro usuário utilizar o objeto).
Os privilégios possíveis são:
SELECT - Permite consultar (SELECT) qualquer coluna da tabela, visão ou seqüência
especificada. Também permite utilizar o comando COPY TO. Para as seqüências, este privilégio
também permite o uso da função currval.
INSERT - Permite inserir (INSERT) novas linhas na tabela especificada. Também permite utilizar
o comando COPY FROM.
UPDATE - Permite modificar (UPDATE) os dados de qualquer coluna da tabela especificada. O
comando SELECT ... FOR UPDATE também requer este privilégio (além do privilégio SELECT).
DELETE - Permite excluir (DELETE) linhas da tabela especificada.
RULE - Permite criar regras para a tabela ou para a visão.
REFERENCES - Para criar uma restrição de chave estrangeira é necessário possuir este privilégio,
tanto na tabela que faz referência quanto na tabela que é referenciada.
TRIGGER - Permite criar gatilhos na tabela especificada.
CREATE - Para bancos de dados, permite a criação de novos esquemas no banco de dados.
Para esquemas, permite a criação de novos objetos no esquema. Para mudar o nome de um
objeto existente é necessário ser o dono do objeto e possuir este privilégio no esquema que o
contém.
Para espaços de tabelas, permite a criação de tabelas e índices no espaço de tabelas, e permite
a criação de bancos de dados possuindo este espaço de tabelas como seu espaço de tabelas
padrão (Deve ser observado que revogar este privilégio não altera a colocação dos objetos
existentes).
TEMPORARY - TEMP - Permite a criação de tabelas temporárias ao usar o banco de dados.
EXECUTE - Permite utilizar a função especificada e qualquer operador implementado utilizando
a função. Este é o único tipo de privilégio aplicável às funções (Esta sintaxe funciona para as
funções de agregação também).
30
USAGE - Para as linguagens procedurais, permite o uso da linguagem especificada para criar
funções nesta linguagem. Este é o único tipo de privilégio aplicável às linguagens procedurais.
Para os esquemas, permite acessar os objetos contidos no esquema especificado (assumindo
que os privilégios requeridos para os próprios objetos estejam atendidos). Essencialmente,
concede a quem recebe o direito de "procurar" por objetos dentro do esquema.
ALL PRIVILEGES - Concede todos os privilégios disponíveis de uma só vez.
Os privilégios requeridos por outros comandos estão listados nas páginas de referência dos
respectivos comandos.
Exemplos:
GRANT SELECT, UPDATE ON CATEGORIAS TO ADM;
GRANT ALL PRIVILEGES ON CONFIG TO ADM;
IV.1.2. REVOKE
Sintaxe:
REVOKE [ GRANT OPTION FOR ] privilégios
ON objeto [ ( coluna [, ...] ) ]
FROM { PUBLIC | nome_do_usuário [, ...] }
{ RESTRICT | CASCADE }
O comando REVOKE revoga, um ou mais papéis, privilégios concedidos anteriormente. A
palavra chave PUBLIC se refere ao grupo contendo todos os usuários, definido implicitamente.
Deve ser observado que um determinado papel possui a soma dos privilégios concedidos
diretamente para o próprio papel, mais os privilégios concedidos para os papéis dos quais o
papel é membro no momento, mais os privilégios concedidos para PUBLIC. Daí, por exemplo,
revogar o privilégio SELECT de PUBLIC não significa, necessariamente, que todos os papéis
perderão o privilégio SELECT para o objeto: os papéis que receberam o privilégio diretamente,
ou através de outro papel, ainda terão o privilégio.
Se for especificado GRANT OPTION FOR somente a opção de concessão do privilégio é
revogada, e não o próprio privilégio. Caso contrário, tanto o privilégio quanto a opção de
concessão serão revogados.
Se o usuário possui um privilégio com opção de concessão, e concedeu este privilégio para
outros usuários, então os privilégios que estes outros usuários possuem são chamados de
privilégios dependentes. Se o privilégio ou a opção de concessão que o primeiro usuário possui
for revogada, e existirem privilégios dependentes, estes privilégios dependentes também serão
revogados se for especificado CASCADE, senão a ação de revogar falhará. Esta revogação
recursiva somente afeta os privilégios que foram concedidos através de uma cadeia de usuários
começando pelo usuário objeto deste comando REVOKE. Portanto, os usuários afetados
poderão manter o privilégio, se o privilégio também tiver sido concedido por outros usuários.
Ao revogar o privilégio de membro de um papel, GRANT OPTION passa a se chamar ADMIN
OPTION, mas o comportamento é semelhante.
Um determinado usuário pode revogar somente os privilégios que foram concedidos
diretamente por este usuário. Se, por exemplo, o usuário A concedeu um privilégio com opção
de concessão para o usuário B, e o usuário B por sua vez concedeu o privilégio para o usuário C,
então o usuário A não poderá revogar diretamente o privilégio de C. Em vez disso, o usuário A
poderá revogar a opção de concessão do usuário B usando a opção CASCADE, para que o
privilégio seja, por sua vez, revogado do usuário C. Outro exemplo é o caso em que tanto A
quanto B concederam o mesmo privilégio a C: neste caso A poderá revogar sua própria
31
concessão, mas não poderá revogar a concessão feita por B e, portanto, C continuará com o
privilégio mesmo que A revogue o privilégio.
Se alguém que não for dono do objeto tentar revogar privilégios sobre o objeto, o comando
falhará inteiramente caso o usuário não possua ao menos um privilégio para o objeto. Se o
usuário possuir algum privilégio para o objeto o comando prosseguirá, mas só revogará os
privilégios para os quais o usuário tem a opção de concessão. A forma REVOKE ALL PRIVILEGES
emite uma mensagem de advertência quando o usuário não possui ao menos uma opção de
concessão, enquanto as outras formas emitem uma mensagem de advertência quando o
usuário não possui opção de concessão para algum dos privilégios especificamente
identificados no comando (Em princípio estas informações também se aplicam ao dono do
objeto, mas como o dono é sempre tratado como possuindo todas as opções de concessão
estes casos nunca ocorrem).
Se um superusuário decidir submeter o comando GRANT ou REVOKE, o comando será
executado como se tivesse sido submetido pelo dono do objeto afetado. Uma vez que todos os
privilégios partem do dono do objeto (possivelmente de forma indireta através de cadeias de
opções de concessão), um superusuário pode revogar todos os privilégios, mas pode ser
necessário usar CASCADE conforme mostrado acima.
O comando REVOKE também pode ser submetido por um papel que não é o dono do objeto
afetado, mas é membro do papel que é dono do objeto, ou é um membro de um papel que
possui privilégios com WITH GRANT OPTION no objeto. Neste caso, o comando será executado
como se tivesse sido emitido pelo papel que realmente possui o objeto ou possui privilégios
com WITH GRANT OPTION. Por exemplo, se a tabela t1 pertencer ao papel g1, do qual o papel
u1 é membro, então u1 poderá revogar privilégios sobre t1 registrados como tendo sido
concedidos por g1. Isto inclui concessões feitas por u1 assim como por qualquer outro membro
do papel g1.
Se o papel que está executando o comando REVOKE possuir os privilégios requeridos
indiretamente, através de um caminho de membro de mais de um papel, é incerto qual dos
papéis será registrado como tendo executado o comando. Nestes casos, a melhor prática é
utilizar o comando SET ROLE para assumir o papel específico com o qual se deseja executar o
comando REVOKE. Caso isto não seja feito, poderá resultar na revogação de privilégios além
dos pretendidos, ou até em não revogar nada.
Exemplos:
Revogar o privilégio de inserção na tabela socios concedido para o usuário ADM:
REVOKE INSERT ON SOCIOS FROM ADM;
IV.1.3. CONTROLE DE ACESSO NO FIREBIRD
O utilitário nativo do Firebird para manutenção de usuários é o GSEC que pode ser usado em
linha de comando ou interativamente.
Roteiro de exemplo para criar um usuário (mhs – Márcio Henrique Silva):
- Execute o prompt de comando (cmd ou command)
- Entre na pasta "c:\arquivos de programas\firebird\firebird_2_1\bin"
- Digite: gsec -user SYSDBA -password masterkey <Enter>
- No prompt "GSEC>" digite: display <Enter> (para ver os usuários cadastrados)
- Criando o usuário: add mhs -pw 123 -fmarcio -mName Henrique -lName Silva;
Para modificar a senha do SYSDBA no GSEC:
32
- Digite: modify sysdba -pw novasenha

Para sair do GSEC digite quit
Para criar um role, podemos usar a ferramenta ISQL ou qualquer executor de script conectado
ao servidor. Exemplo:
CREATE ROLE CONSULTAS;
Outra forma de gerenciar usuários e roles é através do IBExpert, acessando: Tools -> User
Manager
Para atribuir e revogar direitos no IBExpert clique em Tools->Grant Manager.
Figura 4 – Tela de controle de acesso do Ibexpert

33
IV.2. ATIVIDADE IV
Passo 1: Abra o GSEC e conecte-se ao servidor usando SYSDBA.

Informe aqui o comando que deve ser usado:
Passo 2: Crie um usuário chamando ADM com a senha 123, LEITOR com a senha 456 e saia do
GSEC.
Informe aqui os comandos que devem ser usados:
Passo 3: Conecte-se ao banco de dados (clube.fdb) usando o ISQL:

Relacione abaixo os passos necessários:
Passo 4: Crie uma role com o nome GERENTES.

Passo 5: Coloque o usuário ADM na role GERENTES.

Passo 6: Dê permissão para a tabela SOCIOS com GRANT OPTION para a role GERENTES .
Passo 7: Tente Acesse o banco com o usuário LEITOR e tente modificar a tabela SOCIOS.
Informe a mensagem apresentada pelo servidor.
34
UNIDADE V. DSQL - STORED PROCEDURE
V.1. STORED PROCEDURE
Uma SP (Stored Procedure – Procedimento armazenado) é um programa escrito em uma

linguagem específica do Firebird (DSQL – Dinamic SQL) que é armazenada como parte do
banco de dados. SPs podem ser chamadas por aplicações cliente ou por outras SPs/Triggers.
Porque usar Stored Procedures:
• Redução de tráfico na rede porque são executadas pelo servidor.
• Aumento o desempenho porque são analisadas, otimizadas e armazenadas em uma
forma executável no momento em que são criadas.
• Podem também executar operações muito mais complexas que uma simples query.
• Padroniza e concentra a codificação das regras de negócio.
• Facilita a atualização do sistema, porque evita a compilação e distribuição de aplicações.
• Aumentam a segurança do banco de dados uma vez que podem acessar tabelas que o
usuário não direito de acesso.
V.1.1. O comando CREATE PROCEDURE
Sintaxe:
CREATE PROCEDURE NomedaProcedure
<parâmetros de entrada>
RETURNS
<parâmetros de saída>
AS
<declaração de variáveis locais>
BEGIN
<comandos da procedures>
END
V.1.2. Parâmetros
Parâmetros de entrada: Permite à aplicação cliente passar os valores que serão usados para
modificar o comportamento da SP.
Parâmetros de saída ou de retorno: São informações retornadas para a aplicação cliente.
Obs: Um parâmetro pode ser de qualquer tipo de dados do Firebird exceto BLOB ou ARRAY.
CREATE PROCEDURE SUB_TOT_BUDGET(
HEAD_DEPT CHAR(3))
RETURNS (
TOT_BUDGET NUMERIC (15, 2),
AVG_BUDGET NUMERIC (15, 2),
MIN_BUDGET NUMERIC (15, 2),
MAX_BUDGET NUMERIC (15, 2))
AS
BEGIN
SELECT SUM(BUDGET),
AVG(budget), MIN(budget), MAX(budget)
FROM department
WHERE head_dept = :head_dept
INTO :tot_budget, :avg_budget, :min_budget, :max_budget;
SUSPEND;
END ^
35
Esta SP declara um parâmetro de entrada, HEAD_DEPT cujo tipo é CHAR(3) e quatro parâmetros
de saída, TOT_BUDGET, AVG_BUDGET, MIN_BUDGET, e MAX_BUDGET todos do tipo
NUMERIC(15, 2). Tanto os parâmetros de entrada quando os de saída devem estar entre
parênteses. O comando SUSPEND pausa a SP até que o cliente busque os valores dos
parâmetros de saída.
V.1.3. Declarando variáveis locais
É possível declarar variáveis locais de qualquer tipo suportado pelo Firebird dentro de uma SP.
Estas variáveis só existem enquanto a SP está sendo executada e seu escopo é local. Variáveis
locais são declaradas depois da palavra chave AS e antes da palavra chave BEGIN que identifica
o início do corpo da SP. Para declarar variáveis use:
DECLARE VARIABLE <Nome variável> <Tipo variável>
DECLARE VARIABLE OrderCount Integer;
DECLARE VARIABLE TotalAmount NUMERIC(15,2);
Note que cada comando DECLARE VARIABLE só pode declarar uma variável. A SP a seguir ilustra
o uso do comando DECLARE VARIABLE. Ela declara quatro variáveis locais , ord_stat, hold_stat,
cust_no and any_po. Observe que quando uma variável é usada na cláusula INTO de um
comando SELECT um sinal de dois pontos ':' deve anteceder o nome da variável.
CREATE PROCEDURE SHIP_ORDER(
PO_NUM CHAR(8))
AS
DECLARE VARIABLE ord_stat CHAR(7);
DECLARE VARIABLE hold_stat CHAR(1);
DECLARE VARIABLE cust_no INTEGER;
DECLARE VARIABLE any_po CHAR(8);
BEGIN
SELECT s.order_status, c.on_hold, c.cust_no
FROM sales s, customer c
WHERE po_number = :po_num
AND s.cust_no = c.cust_no
INTO :ord_stat, :hold_stat, :cust_no;
/* Este pedido já foi enviado */

IF (ord_stat = 'shipped') THEN
BEGIN
EXCEPTION order_already_shipped;
SUSPEND;
END
/* Cliente está em atraso. */

ELSE IF (hold_stat = '*') THEN
BEGIN
EXCEPTION customer_on_hold;
SUSPEND;
END
/*
* Se existe uma conta não paga de pedidos enviados a mais de 2 meses,
* passe o cliente para cliente em atraso.
*/
FOR SELECT po_number
FROM sales
WHERE cust_no = :cust_no
AND order_status = 'shipped'
AND paid = 'n'
AND ship_date < CAST('NOW' AS DATE) - 60
INTO :any_po
DO
BEGIN
EXCEPTION customer_check;
UPDATE customer
SET on_hold = '*'
36
WHERE cust_no = :cust_no;

SUSPEND;
END
/*
* Envia o pedido.
*/
UPDATE sales
SET order_status = 'shipped', ship_date = 'NOW'
WHERE po_number = :po_num;
SUSPEND;
END ^
V.1.4. Corpo da Procedure
O corpo da SP consiste em um conjunto de qualquer número de comandos da linguagem

interna do Firebird dentro de um bloco BEGIN/END. O corpo da procedure, abaixo, consiste em
um comando SELECT e um SUSPEND entre as palavras chave BEGIN e AND.
CREATE PROCEDURE SUB_TOT_BUDGET(
HEAD_DEPT CHAR(3))
RETURNS (
TOT_BUDGET NUMERIC (15,2),
AVG_BUDGET NUMERIC (15,2),
MIN_BUDGET NUMERIC (15,2),
MAX_BUDGET NUMERIC (15,2))
AS
BEGIN
SELECT SUM(budget), AVG(budget),MIN(budget), MAX(budget)
FROM department
WHERE head_dept=:head_dept
INTO :tot_budget, :avg_budget,:min_budget, :max_budget;
SUSPEND;
END ^
Cada comando no corpo de uma procedure tem que terminar com um ponto-e-virgula ';'.
V.1.5. Elementos de linguagem
A linguagem interna do Firebird inclui todas as construções de uma linguagem de programação

estruturada, assim como, declarações próprias para trabalhar com dados em tabelas. A seguinte
seção descreve estes elementos.
Comentários: Você pode colocar comentários onde quiser em uma SP usando a sintaxe /*
Este é um comentário */. Um comentário pode ter várias linhas, mas comentários aninhados não
são permitidos.
V.1.6. Bloco de comandos BEGIN-END
A linguagem interna do FB se assemelha ao Pascal em algumas construções como IF-THEN-ELSE

e loops WHILE que somente podem conter um comando. Porém, as palavras chave BEGIN e
END podem ser usadas para agrupar uma série de comandos de forma que eles se tornem um
comando composto. Nunca coloque um ponto-e-vírgula após um BEGIN ou um END.
V.1.7. Comandos de atribuição
A linguagem interna do FB suporta comandos de atribuição da seguinte forma:

Var1 = Var2 * Var3;
Var1 tanto pode ser uma variável local quanto um parâmetro de saída. Var2 e Var3 tanto podem
ser variáveis locais como parâmetros de entrada.
IF-THEN-ELSE
A sintaxe do comando IF no Firebird é a seguinte:
IF <expressão condicional> THEN
<comando>
37
ELSE
<comando>
Onde <comando> pode ser tanto um comando simples quanto um bloco de comandos
delimitado por um BEGIN-END. Na <expressão condicional> além dos operadores lógicos
normais (=, <, >, <=, >=, <>) pode-se usar também os seguintes operadores SQL:
Exemplos de comandos IF válidos são:
IF (any_sales > 0) THEN
BEGIN
EXCEPTION reassign_sales;
SUSPEND;
END
IF (first IS NOT NULL) THEN
line2=first || ' ' || last;
ELSE
line2=last;
Note no exemplo acima que na linguagem do Firebird o operador de concatenação de strings é
|| (Duas barras verticais) e não o + como acontece na maioria das linguagens de programação.
IF (:mngr_no IS NULL) THEN
BEGIN
mngr_name='--TBH--';
title='';
END
ELSE
SELECT full_name, job_code
FROM employee
WHERE emp_no=:mngr_no
INTO :mngr_name, :title;
WHILE-DO
A estrutura WHILE-DO permite criar loops nas stored procedures e triggers. A sintaxe é:
WHILE (<expressão condicional) DO <comando>
Onde <comando> pode ser um bloco de comandos delimitado por um par BEGIN-END.
Observe que a expressão condicional tem que estar entre parênteses.
WHILE (i <=5) DO
BEGIN
SELECT language_req[:i] FROM job
WHERE ((job_code=:code) AND (job_grade=:grade) AND (job_country=:cty)
AND (language_req IS NOT NULL))
INTO :languages;
IF (languages=' ')THEN /* Imprime 'NULL' ao invés de espaços */
languages='NULL';
i=i +1;
SUSPEND;
END
V.1.8. Comandos SQL nas STORED PROCEDURES
É possível usar os comandos SQL SELECT, INSERT, UPDATE e DELETE em uma SP exatamente
como se faz em uma query, apenas com algumas pequenas alterações na sintaxe. Para todos
esses comandos pode-se usar variáveis locais ou parâmetros de entrada em qualquer lugar que
um valor literal seria aceito. Por exemplo, no comando INSERT, a seguir, os valores inseridos são
obtidos de um parâmetro de entrada.
CREATE PROCEDURE ADD_EMP_PROJ(
EMP_NO SMALLINT,
PROJ_ID CHAR(5) )
AS
BEGIN
INSERT INTO employee_project (emp_no, proj_id) VALUES (:emp_no,
:proj_id);
WHEN SQLCODE -530 DO
EXCEPTION unknown_emp_id;
38
END
SUSPEND;
END ^
Outra diferença é a adição da cláusula INTO ao comando SELECT de modo que se possa
selecionar valores diretamente para variáveis ou parâmetros de saída, como mostrado no
exemplo a seguir:
CREATE PROCEDURE CUSTOMER_COUNT
RETURNS (
CUSTOMERCOUNT INTEGER)
AS
BEGIN
SELECT COUNT(*) FROM CUSTOMER INTO :CustomerCount;
SUSPEND;
END ^
Pode-se usar comandos SQL DDL em uma SP. Esta restrição se aplica aos comandos CREATE,
ALTER, DROP, SET, GRANT, REVOKE, COMMIT e ROLLBACK.
V.1.9. Usando FOR SELECT e DO
O exemplo anterior do comando SELECT que seleciona um ou mais valores para uma variável
funciona desde que o SELECT retorne apenas uma linha. Quando for preciso processar várias
linhas retornadas por um SELECT deve-se usar o comando FOR SELECT e DO como mostrado a
seguir:
CREATE PROCEDURE ORDER_LIST(
CUST_NO INTEGER)
RETURNS(PO_NUMBER CHAR(8))
AS
BEGIN
FOR SELECT PO_NUMBER FROM SALES
WHERE CUST_NO=:CUST_NO
INTO :PO_NUMBER
DO
SUSPEND;
END ^
Esta procedure pega um código de cliente de seu parâmetro de entrada e retorna os números
de todas as compras do cliente da tabela SALES (vendas). Observe que os números das vendas
são todos retornados através de uma única variável de saída. Veja como isso funciona: A palavra
chave FOR diz paro o Firebird abrir um cursor no conjunto de resultados (result set) do
comando SELECT. O comando SELECT tem que incluir a cláusula INTO que atribui cada campo
retornado pelo SELECT a uma variável local ou parâmetro de saída. O comando após a palavra
chave DO será executado para cada linha retornada pelo SELECT. O comando após o DO pode
ser um bloco de comandos delimitado por um BEGIN-END.
V.1.10. Usando o SUSPEND
No exemplo acima, o comando SUSPEND diz para a stored procedure suspender a execução até
que uma solicitação de dados (fetch) seja recebida pelo cliente, então, a procedure lê o primeiro
PO_NUMBER para o parâmetro de saída e o retorna para o cliente. Cada vez que o cliente emite
uma requisição, o próximo PO_NUMBER é lido para o parâmetro de saída e retornado para o
cliente. Isso continuará até que todas as linhas retornadas pelo SELECT tenham sido
processadas. SUSPEND não é só usado com FOR SELECT. Ele é usado sempre que a stored
procedure retorna um valor para o cliente, evitando que a SP termine antes que o cliente tenha
recebido o resultado. A seguir um exemplo muito simples de uma SP que retorna um valor em
um parâmetro de saída:
CREATE PROCEDURE CUSTOMER_COUNT
RETURNS (
39
CUSTOMERCOUNT INTEGER)
AS
BEGIN
SELECT COUNT(*) FROM CUSTOMER INTO :CustomerCount;
SUSPEND;
END ^
V.1.11. Criando e modificando Stored Procedures
O método normal de se criar um banco de dados e seus objetos no Firebird é criar um script
SQL, para ser executado em executor de script qualquer.
Para evitar que o executor de script confunda o final do comando com o final de cada comando
da procedure, deve-se usar o comando SET TERM, que muda o caracter de terminação de
comando. Veja abaixo:
SET TERM ^;
CREATE PROCEDURE Customer_Count
RETURNS (
CustomerCount Integer)
AS
BEGIN
SELECT COUNT(*) FROM CUSTOMER
INTO :CustomerCount;
SUSPEND;
END ^
SET TERM; ^
O primeiro comando SET TERM altera o caracter de término de comando para o caracter (^).
Note que este comando ainda tem que terminar com um ponto-e-vírgula já que este ainda será
o caracter de término até que o SET TERM ^ seja executado. O executor de script irá agora
ignorar os ponto-e-vírgula no final dos comandos no corpo da procedures. Um (^) é colocado
logo após o END final no comando CREATE PROCEDURE. Quando o executor encontra este
caracter ele processa todo o comando CREATE PROCEDURE. O último SET TERM volta o
terminador para o ponto-e-vírgula.
V.1.12. Apagando e alterando Stored Procedures
Para remover uma stored procedure use o comando DROP PROCEDURE como a seguir:
DROP PROCEDURE Nome_Procedure;
Somente o SYSDBA ou o proprietário da procedure podem apagá-la. Use o comando ALTER
PROCEDURE para alterar uma stored procedure. ALTER PROCEDURE tem exatamente a mesma
sintaxe do comando CREATE PROCEDURE.
Por padrão, o script de criação de um banco cria a estrutura de cada um das procedures e
depois altera cada uma implementando por completo:
CREATE PROCEDURE ADD_EMP_PROJ (
EMP_NO SMALLINT,
PROJ_ID CHAR(5))
AS
BEGIN
EXIT;
END ^
CREATE PROCEDURE ALL_LANGS

RETURNS (
CODE VARCHAR(5),
GRADE VARCHAR(5),
COUNTRY VARCHAR(15),
LANG VARCHAR(15))
AS
BEGIN
EXIT;
40
END ^
Depois de todas as procedures terem sido criadas o script criado pelo Firebird usa o comando
ALTER PROCEDURE para adicionar o corpo de cada uma. Veja:
ALTER PROCEDURE ADD_EMP_PROJ(
EMP_NO SMALLINT,
PROJ_ID CHAR(5))
AS
BEGIN
INSERT INTO employee_project (emp_no, proj_id) VALUES (:emp_no,
:proj_id);
WHEN SQLCODE -530 DO
EXCEPTION unknown_emp_id;
END
SUSPEND;
END ^
Desta forma o Firebird elimina qualquer dependência entre as procedures quando elas estão
sendo criadas. Já que o corpo de toda procedure esta vazio não pode haver dependência de
procedures chamando outra(s). Quando os comandos ALTER PROCEDURE são executados eles
podem ser rodados em qualquer ordem porque a declaração de qualquer procedure que
eventualmente seja chamada pela que está sendo alterada no momento, já existirá.
V.1.13. Chamando Stored Procedures
Stored procedures no Firebird são divididas em dois grupos de acordo com como são
chamadas. Procedures que retornam valores através de parâmetros de saída são chamadas de
”select procedures” porque elas podem ser usadas no lugar de um nome de tabela em um
comando SELECT.
Chamando “Select Procedures”:
“Select procedures” atribuem valores a parâmetros de saída e então executam um SUSPEND
para retornar estes valores. Abaixo, um exemplo simples de “select procedure”.
SELECT CUSTOMERCOUNT FROM PROCEDURE_CUSTOMER;
É possível ainda chamar procedures que necessitem de parâmetros de entrada a partir de um
console SQL ou dentro de uma aplicação, conforme o código abaixo:
SELECT TOTAL FROM PROCEDURE_CALC(20)
WHERE UF=’MG’
ORDER BY 1;
O parâmetro de entrada, CUST_NO, é passado para a procedure entre parênteses logo após o
nome da procedure no comando SELECT. Note também que este comando SELECT inclui uma
cláusula WHERE e uma cláusula ORDER BY.
No exemplo abaixo, temos a demonstração do uso de parâmetros na chamada de uma
procedure:
SELECT * FROM ORDER_LIST(:CUST_NO)
WHERE (PO_NUMBER > :PO_NUMBER)
ORDER BY PO_NUMBER DESC
O código a seguir foi retirado do evento “onclik” do botão “Execute” do formMostra (Código em
Delphi) como os valores são atribuídos aos parâmetros de entrada antes da stored procedure.
procedure TProcForm.SelectBtnClick(Sender: TObject);
begin
with ProcDm.OrderListQry do
begin
Params.ParamByName('CUST_NO').Value := CustomerNoEdit.Text;
Params.ParamByName('PO_NUMBER').Value := OrderNoEdit.Text;
Open;
end; //with
end;
41
Chamando uma “Non-Select Procedure”:

A stored procedure a seguir é um exemplo de uma “non-select procedure”, que não retorna
qualquer resultado. Esta procedure tem apenas um parâmetro de entrada, FACTOR, e ajusta os
salários mínimo e máximo na tabela JOB por este fator.
CREATE PROCEDURE ADJUST_SALARY_RANGE(
FACTOR FLOAT)
AS
BEGIN
UPDATE JOB
SET MIN_SALARY=MIN_SALARY * :FACTOR, MAX_SALARY=MAX_SALARY * :FACTOR;
END ^
Usa-se o comando EXECUTE PROCEDURE para rodar esta stored procedure a partir de uma
trigger, outra stored procedure ou qualquer console SQL. Exemplo:
EXECUTE PROCEDURE ADJUST_SALARY_RANGE(1.1);
Para executar essa stored procedure a partir de sua aplicação Delphi, usa-se a seguinte sintaxe:
with ProcDm.AdjustSalRngProc do
begin
Params.ParamByName('Factor').Value := StrToFloat(FactorEdit.Text);
Prepare;
ExecProc;
end; //with
O conteúdo deste capítulo é uma adaptação do artigo escrito por Bill Todd (Borland Developers
Conference San Diego 2000), traduzido por Alessandro Fernandes e publicado no site da
Comunidade Firebird de Língua Portuguesa (http://www.comunidade-firebird.org).
42
V.2. ATIVIDADE V
Passo 1: Crie uma procedure para cadastrar cotas no banco de dados clube.fdb.
Parâmetros de entrada: Id da categoria, validade, valor da cota, Quantidade de cotas
Parâmetro de saída: nenhum
Rotina: A procedure deverá incluir a quantidade informada de registros na tabela COTAS.
Informe abaixo o código fonte da procedure:
43
Unidade VI. DSQL - TRIGGERS
Triggers são semelhantes a stored procedures, exceto pelo modo como são chamadas. Triggers
são chamadas automaticamente quando ocorre uma alteração em um registro da tabela.
Características das triggers:
• Triggers são chamadas automaticamente quando os dados da tabela a qual ela esta
conectada são alterados.
• Triggers não tem parâmetros de entrada.
• Triggers não retornam valores.
• Triggers são criadas pelo comando CREATE TRIGGER.
VI.1. USANDO CREATE TRIGGER
O comando CREATE TRIGGER, a seguir, mostra todos os elementos da sintaxe. As palavras-chave

CREATE TRIGGER são seguidas do nome da trigger, a seguir a palavra-chave FOR e então o
nome da tabela a qual a trigger estará relacionada. Em seguida vem a palavra ACTIVE (ativa) ou
INACTIVE (inativa) indicando se a trigger deverá ou não ser executada. Se a trigger está inativa
ela não será executada. O próximo elemento do comando CREATE TRIGGER indica quando a
trigger será executada.
1. BEFORE UPDATE - Antes de uma atualização.
2. AFTER UPDATE - Após uma atualização.
3. BEFORE INSERT - Antes de uma inclusão.
4. AFTER INSERT - Após uma inclusão.
5. BEFORE DELETE - Antes de uma exclusão.
6. AFTER DELETE - Após uma exclusão.
A seguir vem a palavra chave opcional POSITION seguida de um número inteiro. O Firebird
permite várias triggers ao mesmo evento. É possível ter quatro triggers ligadas à tabela SOCIOS
todas como AFTER UPDATE. Esta é uma grande característica já que permite a modularização do
código. Entretanto a ordem em que as trigger vão ser executadas pode eventualmente ser
importante. A palavra chave POSITION permite definir a ordem de execução. No exemplo
abaixo a trigger mostrada será executada antes de qualquer outra porque a sua posição é 0
(zero). É aconselhável deixar um espaço entre a numeração para facilitar a inserção de outras
triggers com pontos de execução entre as já criadas.
CREATE TRIGGER SAVE_SALARY_CHANGE FOR EMPLOYEE
ACTIVE
AFTER UPDATE
POSITION 0
AS
BEGIN
IF (old.salary <> new.salary) THEN
INSERT INTO salary_history
(emp_no, change_date, updater_id, old_salary, percent_change)
VALUES (
old.emp_no,
'NOW',
user,
old.salary,
(new.salary - old.salary) * 100 / old.salary);
44
END^
Após a palavra chave AS vem a declaração de qualquer variável local usando o comando
DECLARE VARIABLE igual ao que foi usado para stored procedures. Finalmente vem o corpo da
trigger delimitado pelos comandos BEGIN-END.
Recomenda-se a máxima atenção com a codificação de triggers para evitar uma execução em
cadeia que poderá ocasionar erro quando iniciar a primeira execução.
VI.2. BEFORE/AFTER
Triggers do tipo AFTER são usadas para garantir que a atualização que disparou a trigger esteja
completa com sucesso antes de executar outras ações. A trigger acima é um bom exemplo.
Insere uma linha na tabela “salary_history” sempre que o salário de um funcionário é alterado. A
linha de histórico contém o salário antigo e o percentual de alteração. Como a atualização do
registro do funcionário pode falhar por várias razões, como um valor em um campo que viola
restrições impostas, por exemplo, o histórico é importante somente no caso de uma atualização
completada com sucesso.
VI.3. USANDO OLD E NEW
Observa-se na trigger SAVE_SALARY_CHANGE as palavras “OLD” e “NEW”. No corpo de uma

trigger o Firebird deixa disponíveis tanto o valor antigo como o novo valor de qualquer coluna,
por exemplo old.salary e new.salary. Usando os valores OLD e NEW é possível criar registros de
histórico, calcular o percentual de alteração de um valor numérico, encontrar em outras tabelas
registros que combinem como valor antigo, valor novo de um campo ou fazer qualquer
operação necessária para garantir a regra de negócio exigida.
VI.4. GERANDO EXCEPTIONS
Se algum processamento ou validação não atender as condições exigidas, é possível disparar

um erro (exception) para interromper a execução da transação corrente. Antes de usar uma
exception é preciso criá-la com o comando create.
CREATE EXCEPTION. Por exemplo:
CREATE EXCEPTION CUSTOMER_STILL_CURRENT ‘Este cliente comprou nos últimos
dois anos.’
Onde as palavras-chave CREATE EXCEPTION são seguidas do nome da exceção e do texto da
mensagem de erro para esta exceção. Para gerar esta EXCEPTION em uma trigger ou stored
procedure use a palavra chave EXCEPTION como mostrado abaixo:
EXCEPTION CUSTOMER_STILL_CURRENT;
Ao gerar uma EXCEPTION a execução da trigger ou da stored procedure é encerrada. Qualquer
comando na trigger ou stored procedure depois da exceção não será executado. No caso de
uma trigger do tipo BEFORE a atualização que disparou a trigger é abortada. Finalmente a
mensagem de erro da exceção é retornada para a aplicação.
Para deletar uma EXCEPTION basta usar o comando DROP EXCEPTION e para alterar a
mensagem associada usa-se o comando ALTER EXECEPTION. Por exemplo:
ALTER EXCEPTION CUSTOMER_STILL_CURRENT ‘Este cliente ainda está ativo.’;
DROP EXCEPTION CUSTOMER_STILL_CURRENT;
45
VI.5. USANDO GENERATORS
O Firebird não tem um tipo de campo com auto incremento. Ao invés disso tem uma
ferramenta mais flexível chamada GENERATOR. Um GENERATOR retorna um valor incrementado
toda vez que você o chama. Para criar um GENERATOR use o comando CREATE GENERATOR ou
CREATE SEQUENCE como a seguir.
CREATE GENERATOR CUSTOMER_ID;
Para excluir um GENERATOR basta usar o comando DROP GENERATOR. Para obter o próximo
valor de um GENERATOR use a função GEN_ID() por exemplo:
GEN_ID(CUSTOMER_ID, 1);
O primeiro parâmetro é o nome do GENERATOR e o segundo é o incremento. No exemplo
acima o valor retornado será o último valor mais um. O Incremento pode ser qualquer valor
inclusive zero, o que é muito útil para se obter o valor corrente de um GENERATOR sem alterar
seu valor. Você pode também alterar o valor de um GENERATOR a qualquer momento usando o
comando SET GENERATOR com a seguir:
SET GENERATOR CUSTOMER_ID TO 1000;
É importante saber que o incremento de um GENERATOR não depende da transação, ou seja,
não irá voltar ao valor anterior se for executado o comando ROLLBACK. GENERATORS são
frequentemente usados em triggers para fornecer um valor para uma chave primária como no
exemplo a seguir:
CREATE TRIGGER SET_EMP_NO FOR EMPLOYEE
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
new.emp_no=gen_id(emp_no_gen, 1);
END ^
É possível usar a função GEN_ID em uma stored procedure que retorna o valor do GENERATOR
em um parâmetro de saída para a aplicação cliente. O cliente pode então atribuir o valor a sua
chave primária e apresenta-la ao usuário quando este cria um novo registro antes mesmo que
este tenha sido gravado com um POST. Neste caso recomenda-se criar uma trigger como a
mostrada acima para o caso de um cliente inserir um registro e não fornecer um valor para a
chave primária. Basta alterar o código conforme a seguir:
IF new.emp_no IS NULL THEN new.emp_no = gen_id(emp_no_gen, 1);
Agora a trigger só irá fornecer um valor para a chave primária no caso do campo ser nulo.
VI.6. ALTERANDO E EXCLUINDO TRIGGERS
Basta usar o comando ALTER TRIGGER para alterar tanto o cabeçalho quanto o corpo da trigger.
O uso mais comum da alteração do cabeçalho é ativar e desativar uma trigger. Outro uso é
trocar o POSITION da trigger. O comando a seguir irá inativar a trigger.
ALTER TRIGGER SET_EMP_NO INACTIVE;
Para alterar o corpo da trigger preserve seu nome, as outras informações do cabeçalho e
informe o novo corpo como mostrado a seguir:
ALTER TRIGGER SET_EMP_NO
AS
BEGIN
IF new.emp_no IS NULL THEN new.emp_no = gen_id(emp_no_gen, 1);
END ^
Para apagar uma trigger use o comando DROP TRIGGER. Por exemplo:
DROP TRIGGER SET_EMP_NO;
46
O conteúdo deste capítulo é uma adaptação do artigo escrito por Bill Todd (Borland Developers
Conference San Diego 2000), traduzido por Alessandro Fernandes e publicado no site da
Comunidade Firebird de Língua Portuguesa (http://www.comunidade-firebird.org).
47
VI.7. ATIVIDADE VI
Passo 1: Descreva abaixo os detalhes da trigger a seguir:

CREATE TRIGGER RECEITAS_ATUDEB FOR RECEITAS
ACTIVE AFTER INSERT OR UPDATE OR DELETE POSITION 0
AS
DECLARE VARIABLE IDDEB INTEGER;
BEGIN
-- Validando a troca de id do débito
IF ((UPDATING) AND (NEW.REC_IDDEB <> OLD.REC_IDDEB)) THEN
EXCEPTION ERRO_PADRAO 'A troca do ID do débito não é permitida.';
-- Atualização do valor recebido
IF (DELETING) THEN IDDEB = OLD.REC_IDDEB;
ELSE IDDEB = NEW.REC_IDDEB;
UPDATE DEBITOS D SET D.DEB_RECEBIDO = COALESCE((SELECT
SUM(R.REC_VALREC) FROM RECEITAS R WHERE R.REC_IDDEB =
:IDDEB),0)WHERE D.DEB_ID = :IDDEB;
END
48
UNIDADE VII. VIEWS
VII.1. O QUE É UMA VIEW?
Segundo (CANTU, 2006), View é uma representação personalizada das informações de uma ou
mais tabelas do banco de dados. Os dados retornados por uma View são recuperados no
momento de sua execução. Essas visões podem ser acessadas através do comando SELECT
convencional, bastando para isto indicar o nome da view no lugar do nome da tabela.
De acordo com (DATE, 2003) uma view serve para:
• Fornecem um recurso de abreviação ou de “macro”;
• Permitem que os mesmos dados sejamvistos por usuários diferentes de modos diferentes
de modos diferentes ao mesmo tempo;
• Fornecem segurança automática para dados ocultos;
• Podem fornecer independência de dados lógicos;
Quando uma visão é definida, o sistema de banco de dados armazena sua definição ao invés do
resultado da expressão SQL que a definiu. Sempre que a relação visão é usada, ela é sobreposta
pela expressão da consulta armazenada, de maneira que, sempre que a consulta for solicitada, a
relação visão será recomputada.
Alguns sistemas de banco de dados permitem que as relações de visões sejam materializadas,
garantindo que se ocorrerem modificações nas relações reais usadas na definição da visão,
também a visão será modificada. Contudo, esta abordagem pode incorrer em custos de
armazenamento e atualizações de sistema.
VII.2. CRIANDO VIEW
A sintaxe para criação de view é:

CREATE VIEW nome
[(nome da coluna [, nome da coluna [, ...]])]
As
<comando select> WITH CHECK OPTION];
Exemplo de view:
CREATE VIEW BOM_FORNECEDOR
AS
SELECT F.F#,F.STATUS, F.CIDADE
FROM F
WHERE D.STATUS > 15
WITH CHECH OPTION;
WITH OPTION CHECK: significa que as operações de INSERT e UPDATE sobre a view serão
rejeitadas se violarem qualquer restrição de integridade implícita na expressão de definição da
visão. Portanto, observe que tais operações só falharão se WITH CHECK OPTION for
especificado – isto é, por default, elas não falharão. Recomenda-se, portanto, que WITH CHECK
OPTION sempre seja especificada na prática.
Para excluir uma view utilize o comando: DROP <nome_da_view>
49
VII.3. VIEWS ATUALIZÁVEIS
Uma view é atualizável quando reúne as características necessárias para permitir que operações
de manipulação de dados (inserção, remoção ou atualização) nas tabelas utilizadas por ela,
possam ser feitas diretamente na própria view.
Se uma view possuir algumas das características listadas abaixo, ela não será “naturalmente
atualizável”:
• Utilizar UNIONs;
• Trazer dados de mais de uma tabela (Joins)
• Trazer dados de outra view que não seja atualizável;
• Possuir campos definidos por subqueries, funções de agregação (count, sum, etc) ou
outras expressões;
• Deixar de recuperar algum campo definido como NOT NULL, na tabela utilizada;
• Utilizar GROUP BY;
• Utilizar as cláusulas distinct, first, skitp ou rows;
Na maioria das vezes, views que não são “naturalmente atualizáveis”, devido a alguma das
razões expostas acima, poderão se tornar atualizáveis através da criação de triggers que serão
responsáveis pela manipulação dos dados nas tabelas referenciadas pela view.
Uma view é naturalmente atualizável se:
• Recuperar informações de uma única tabela ou view atualizável;
• Listar todos os campos not null da tabela ou view referenciada;
• Não utilizar funções de agregação, subqueries,UDFs, etc.
Controle de acesso às views
O usuário que está criando a view deve ter direito de acesso (select) nas tabelas acessadas perla
view.
Todos os usuários que acessarem a view deverão ter direito de acesso à view concedidos. E
ainda é necessário que o dono da view, ou usuário que está acessando, ou a própria view tenha
direito de acesso às tabelas acessadas por ela.
No caso de view naturalmente atualizável, é necessário que a mesma tenha direitos de select,
update, insert e delete na tabela utilizada. Caso a view seja atualizada através de trigger, cada
trigger deverá ter seu direito de acesso garantido nas tabelas que serão manipuladas, para as
respectivas operações.
Outro exemplo de view:
CREATE VIEW V_ASSOCIADOS(
SOC_ID, SOC_NOME, SOC_CPF,
SOC_TITULAR, SOC_NASCIMENTO, SOC_ENDER_RES,
SOC_ENDER_COB, SOC_ADMISSAO, SOC_VENCIMENTO,
SOC_CELULAR, SOC_COTA, SOC_CATEG,
SOC_VALMENSAL, SOC_EMAIL,
SOC_STATUS, ENDRES_TIPOLOG,
ENDRES_NOMELOG, ENDRES_NUMERO,
ENDRES_COMPL, ENDRES_BAIRRO,
ENDRES_MUNIC, ENDRES_CEP,
ENDRES_FONEFIXO, ENDRES_INCLUSAO,
ENDRES_ALTERACAO, ENDCOB_TIPOLOG,
ENDCOB_NOMELOG, ENDCOB_NUMERO,
ENDCOB_COMPL, ENDCOB_BAIRRO,
ENDCOB_MUNIC, ENDCOB_CEP,
ENDCOB_FONEFIXO, ENDCOB_INCLUSAO,
ENDCOB_ALTERACAO, CATEGORIA)
AS
SELECT S.SOC_ID, S.SOC_NOME, S.SOC_CPF, S.SOC_TITULAR, S.SOC_NASCIMENTO,
50
S.SOC_ENDER_RES, S.SOC_ENDER_COB, S.SOC_ADMISSAO, S.SOC_VENCIMENTO,

S.SOC_CELULAR, S.SOC_COTA, S.SOC_CATEG, S.SOC_VALMENSAL, S.SOC_EMAIL,
S.SOC_STATUS, ER.END_TIPOLOG, ER.END_NOMELOG, ER.END_NUMERO,
ER.END_COMPL, ER.END_BAIRRO, ER.END_MUNIC, ER.END_CEP, ER.END_FONEFIXO,
ER.END_INCLUSAO, ER.END_ALTERACAO, EC.END_TIPOLOG, EC.END_NOMELOG,
EC.END_NUMERO, EC.END_COMPL, EC.END_BAIRRO, EC.END_MUNIC, EC.END_CEP,
EC.END_FONEFIXO, EC.END_INCLUSAO, EC.END_ALTERACAO, CATEGORIAS.CAT_DESCRICAO
FROM SOCIOS S
INNER JOIN CATEGORIAS ON (S.SOC_CATEG = CATEGORIAS.CAT_ID)
INNER JOIN ENDERECOS ER ON (S.SOC_ENDER_RES = ER.END_ID)
INNER JOIN ENDERECOS EC ON (S.SOC_ENDER_COB = EC.END_ID);
Exemplo de utilização da View:
SELECT V.SOC_NOME,V.SOC_CPF,V.ENDRES_TIPOLOG,
V.ENDRES_NOMELOG, V.ENDRES_NUMERO, V.CATEGORIA,
M.MUN_NOME
FROM V_ASSOCIADOS V
INNER JOIN MUNICIPIOS M ON V.ENDRES_MUNIC = M.MUN_CODIGO
WHERE V.SOC_NOME LIKE '%A%'
ORDER BY V.SOC_NOME
Observe que apenas algumas colunas da view foram selecionadas e ainda foi realizado um JOIN
com a tabela de MUNICIPIOS que não foi utilizada pela view.
VII.4. ATIVIDADE VII
Passo 1: Crie uma view para exibir apenas os sócios devedores. Deverão ser definidos os
seguintes campos: CPF, Nome do sócio e valor total dos débitos:
51
UNIDADE VIII. TRANSAÇÕES
Em ambientes multi-usuários existem operações que precisam ser serializadas, ou seja,

colocadas em fila para que sejam executadas “uma a uma”, não permitindo tarefas em paralelo.
Essas operações são amparadas por um conceito muito importante nos SGDBs denominado
transação, cujo objetivo é agrupar uma seqüência de comandos que precisam ser tratados
como um bloco único e indivisível, para que se mantenham a integridade e a consistência dos
dados.
Uma transação é uma unidade lógica de trabalho; ela começa com a execução
de uma operação BEGIN TRANSACTION e termina com a execução de uma
operação COMMIT ou ROLLBACK (DATE, 2003, p. 382).
Figura 5 - Transação
Principais propriedades de uma transação (ACID):
• Atomicidade: Ou todas as ações da transação acontecem, ou nenhuma delas acontece.
• Consistência: Se a transação é consistente e o BD começa consistente, ele termina
consistente.
• Isolamento: A execução de uma transação é isolada da execução de outras transações.
• Durabilidade: Se uma transação é concluída com sucesso (através de uma operação
commit bem sucedida), então seus efeitos são persistentes (duráveis).
A sintaxe básica de transação é:
SET TRANSACTION [NAME transaction]
[READ WRITE | READ ONLY]
[WAIT | NO WAIT]
[[ISOLATION LEVEL] {SNAPSHOT [TABLE STABILITY]
| READ COMMITTED [[NO] RECORD_VERSION]}]
[RESERVING <reserving_clause>
| USING dbhandle [, dbhandle ...]];
<reserving_clause> = table [, table ...]
[FOR [SHARED | PROTECTED] {READ | WRITE}] [, <reserving_clause>]
52
VIII.1. MODOS DE ACESSO
É o tipo, ou modo de acesso que a transação terá no banco de dados. Os tipos de acesso
podeM ser:
VIII.1.1. READ WRITE
(Leitura & Gravação): é o modo padrão. Ele provê ao usuário, que iniciou a transação, o poder
de ler informações e alterar o conteúdo do banco de dados;
VIII.1.2. READ ONLY
(Somente leitura): permite ao usuário apenas ler as informações do banco de dados não
permitindo a ele executar comandos que possam alterar qualquer conteúdo.
Observe que o modo RW pode executar, dentro do seu contexto, comandos como
INSERT/UPDATE/DELETE e o modo RO permitem somente os comandos SELECT/REFERENCE.
VIII.2. TIPOS DE BLOQUEIO
Especificam como o servidor procederá quando ocorrer algum conflito de leitura ou gravação
dos dados.
VIII.2.1. WAIT
O modo padrão é WAIT (esperar), neste modo o usuário que encontrou o conflito fica
aguardando até que a transação anterior que ainda não foi confirmada seja encerrada. O
controle não retorna para o cliente até que a operação possa continuar.
VIII.2.2. NO-WAIT
No modo NO-WAIT (sem esperar), o usuário que gerou o conflito com outra transação não
confirmada receberá uma mensagem de erro imediatamente.
Os conflitos podem aparecer não somente em operações de gravação, mas também em
operações de leitura.
VIII.3. NÍVEL DE ISOLAMENTO
VIII.3.1. Read uncommitted
Chamado “Dirty Read” (leitura suja) permite a uma transação ler todas as mudanças feitas por
outra transação em qualquer registro, mesmo que estas mudanças não tenham sido
confirmadas. Este nível não é recomendado para bancos relacionais por que ele permite ler
inconsistências e informações parciais. Os valores que uma transação UPDATE/INSERT/DELETE
no banco de dados, depois de confirmados, devem ser vistos pelas outras transações com um
novo estado consistente do banco de dados, e o modo de isolamento “dirty read” vai contra
esta idéia básica. Este nível não é suportado pela maioria dos SGDBs. DB2 e Informix suportam.
VIII.3.2. Read committed
Na maioria dos servidores relacionais, este é o nível típico de qualquer mecanismo. Ele permite
a transação ler somente mudanças confirmadas feitas por outras transações.
53
Este nível de isolamento ajuda a garantir que as transações verão apenas estados consistentes
do banco (é claro que isto assume que todos os clientes irão fazer um conjunto de mudanças
inter-relacionadas dentro de uma transação englobada). Mesmo se uma transação confirmar
depois de uma outra transação, usando “read committed” ter iniciado, estas mudanças poderão
ser lidas. Existem dois sub-modos que se aplicam somente a este nível:
Record version - a última versão confirmada do registro é lida imediatamente. Esta é o padrão.
No Record version - se estiver ali uma versão não confirmada de um registro gerado por outra
transação, a transação atual fará o seguinte: se o Tipo de Bloqueio for WAIT, ela irá esperar até o
registro ser confirmado (commit) ou descartado (rollback), ou se o Tipo de Bloqueio for NO-
WAIT um erro será gerado imediatamente. De qualquer forma, a transação sempre tentará ler a
versão mais recente de um registro. Isto se aplica a mudanças feitas por outras transações, por
que uma transação sempre pode ler suas mudanças não confirmadas. Este sub-modo causa a
exibição de mensagens de “deadlock”, e por isto deve ser usado com muito cuidado.
VIII.3.3. Snapshot
Chamado de “Repeatable Read” (leitura repetitiva) permite que uma transação possa obter uma
imagem completa do banco de dados quando ela for iniciada. Esta transação não consegue ver
qualquer mudança feita por outras transações concorrentes. Este nível é ideal para relatórios,
porque na mesma transação, um registro pode ser lido muitas vezes, e seu valor deve ser o
mesmo até que a sua própria transação mude algum valor. Esta transação pode ver mudanças
feitas por ela mesma. Este nível de isolamento não é recomendado para usuários interativos, por
que eles precisam de dados atuais, e não de dados congelados. Pode ser usado para operações
obrigatórias e, portanto devem ser confirmadas ou descartadas; por que ela previne “garbage
collection” (lixos): todas as versões até o momento que a transação foi iniciada se manterão
para manter uma visão estável do banco de dados. Um servidor relacional “normal” paga um
preço caro em performance ou recursos para suportar este modo.
VIII.3.4. Snapshot table stability
Conhecido também pelo nome de “Forced Repeatable Read” (leitura repetitiva forçada), este
nível é específico do Firebird/Interbase e não existe em outro servidor relacional. Ele pode ser
chamado de escrita de estabilidade “Snapshot”, porque ela tem as mesmas propriedades do
nível anterior, mas também quando for feita a leitura da tabela esta será bloqueada para escrita,
para as outras transações. Então, a transação com este nível tem o controle sobre a tabela e
todas as outras transações poderão somente ler a partir desta tabela. Este nível não é
recomendado para propósitos gerais; ele só deve ser utilizado quando realmente for necessário
e em curtos períodos de tempo deve ser confirmada ou descartada, porque cada uma das
outras transações que estiverem tentando gravar na mesma tabela receberá uma mensagem de
erro ou será colocada em espera até que a transação seja concluída. Este nível pode gerar
muitos conflitos ou causar um “deadlock” geral no banco de dados.
VIII.4. MODO DE PRÉ-ALOCAÇÃO
Também pode ser chamado de “table reservation” (reserva de tabela) na documentação oficial.
Como SET TRANSACTION está disponível em SQL, DSQL e ISQL, ele pode ser embutido em
aplicações SQL. Ele permite um fino acabamento através dos recursos requisitados (neste caso,
tabelas) quando uma transação inicia no lugar de ficar aguardando, a transação tenta suas
operações na tabela. Esta técnica reduz a possibilidade de deadlocks. A cláusula RESERVING
54
(reservando), é seguida de uma lista de tabelas separadas por vírgula e depois a palavra
reservada FOR que tem as seguintes opções de compartilhamento:
SHARED: as tabelas podem ser compartilhadas com outras transações concorrentes para leitura.
PROTECTED: as tabelas não podem ser compartilhadas com outras transações para leitura ou
gravação.
Opções de modo de acesso:
READ: a transação irá querer antecipar somente usos do tipo RO, de acordo com uma ou outra
opção de compartilhamento mostrada anteriormente.
WRITE: a transação irá querer antecipar uso de WRITE nas tabelas, de acordo com uma ou outra
opção de compartilhamento mostrada anteriormente. Há quatro possibilidades de combinação.
Depois da vírgula pode-se colocar uma lista de tabelas separadas por vírgula e seguida da
palavra reservada FOR e seu modo de pré-alocação desejado. Tente uma dessas quatro
combinações:
Shared, write: permite a qualquer transação com modo de acesso WRITE e nível de isolamento
“concurrency” ou “read committed”, atualizar enquanto outras transações com outros níveis de
isolamento e acesso READ podem ler dados.
Shared, read: permite a qualquer transação ler dados, e qualquer transação com acesso WRITE
a atualizar. Este é modo de reserva mais liberal.
Protected, write: previne que outras transações atualizem. Outras transações com níveis de
isolamento “concurrency” ou “read committed” podem ler dados, mas somente esta transação
pode atualizar.
Protected, read: previne que todas as transações atualizem, mas permite que todas as
transações leiam os dados.
VIII.5. EXEMPLO DE TRANSAÇÃO
Intuitivamente, a primeira transação está transferindo R$100 da conta B para a conta A. A

segunda está creditando 6% de juros em ambas as contas.
Não há garantia que T1 vai executar antes de T2 ou vice- versa, se ambas forem submetidas
praticamente juntas. Contudo, o efeito visível tem de ser equivalente ao dessas duas transações
rodando serialmente (uma depois da outra), numa ordem qualquer.
Considere o seguinte entrelaçamento (escalonamento):
Outro exemplo:
Como o SGBD vê o segundo escalonamento:

55
O SGBD não pode permitir escalonamentos como este!
Grafo de dependências: Um nó por transação, flecha de Ti para Tj se Tj ler ou escrever um

objeto escrito pela última vez por Ti.
O ciclo no grafo revela o problema. O resultado de T1 depende de T2 e vice-versa.
Notas sobre a autoria:
Este capítulo foi baseado, principalmente, no artigo de Claudio Valderrama disponível em
http://www.cvalde.com/document/TransactionOptions.htm, traduzido e adaptado por Jiancarlos
Kleinebing, disponível no site da CFLP (http://www.comunidade-firebird.org).
VIII.6. ATIVIDADE VIII
Passo 1: Faça duas conexões ao banco de dados clube.fdb e realize testes de transação.
Execute um update na tabela de sócios nas duas conexões.
Execute COMMIT WORK na segunda e tente fazer o mesmo na primeira.
56
UNIDADE IX.PROJETO COMPLETO (TRABALHO)
Este capítulo será apresentado a partir do documento de divulgação do trabalho em grupo que
valerá como terceira nota da disciplina.
57
UNIDADE X. BANCO DE DADOS DISTRIBUÍDO
De acordo com Elmasri e Novate (2005), um sistema de computação distribuída consiste de

vários elementos de processamento, não necessariamente homogêneos, que são
interconectados por uma rede de computador, e que cooperam na execução de certas tarefas.
Já um banco de dados distribuído é uma coleção de múltiplos bancos logicamente inter-
relacionados distribuídos por uma rede de computadores.
Ainda os mesmo autores conceituam um sistema de gerenciamento de banco de dados
distribuídos (SGBDD) como um sistema de software que permite o gerenciamento de um
banco de dados distribuído e que torna a distribuição transparente ao usuário.
X.1. PRINCIPAIS CARACTERÍSTICAS DE UM BDD
Autonomia local – apesar de existirem diversos servidores no sistema, para o cliente existe
somente um servidor de dados, sendo transparente para o mesmo, a distribuição tanto dos
dados como do processamento.
Inexistência de um servidor central – em um sistema distribuído não há uma hierarquia de
servidores, mas todos podem trabalhar independentemente. Com a queda de um servidor, o
sistema continua executando, mas com uma redução de recursos proporcional à representação
do potencial computacional do servidor que caiu em relação ao sistema.
Operação contínua – uma importante característica de um sistema de dados distribuído é a sua
alta tolerância a falhas tanto de hardware, software, como de rede. Em um sistema monolítico,
havendo falha em qualquer dos quesitos mencionados anteriormente, ocorre a
indisponibilidade do mesmo. Em um sistema distribuído, as chances de indisponibilidade são
inversamente proporcionais à quantidade de servidores. Havendo falha em um servidor, o
sistema poderá continuar processando de forma reduzida ao invés de sair do ar. Há uma queda
de desempenho, e até indisponibilidade de alguns dados, mas não a indisponibilidade do
serviço.
Independência de localização – em um sistema distribuído, o cliente solicitará qualquer dado
existente no sistema sem a preocupação em acessar o servidor onde se encontra armazenada
cada informação. Para o cliente, todas as informações estarão no servidor que ele acessa.
Independência de fragmentação – um sistema de bancos de dados distribuído deverá acatar a
possibilidade fragmentar os dados de forma a manter em um servidor as informações que seus
clientes solicitam mais, distribuindo assim os dados e o processamento das informações. Estes
dados são unificados por meio de junções para fragmentações verticais (colunas) e de uniões
para fragmentações horizontais (tuplas). Para o cliente esta fragmentação não é visível.
Processamento de consultas distribuído – o sistema distribuído é capaz de envolver diversos
servidores na otimização e execução de consultas a dados considerando a localização dos
mesmos, sendo transparente para o usuário.
Gerenciamento de transações distribuído – um sistema distribuído será capaz de conferir
atomicidade a uma transação, mesmo que ela envolva servidores diferentes.
Independência de hardware – um sistema de dados distribuído deve operar em cima de uma
abstração de software capaz de operar em diferentes arquiteturas – daí o suporte a diversos
tipos de hardwares.
58
Independência de sistema operacional – um sistema de dados distribuído assim como deve

oferecer tolerância a diversas arquiteturas, deverá oferecer implementação em diversos sistemas
operacionais por meio de versões do SGBD capazes de operar em diversos sistemas
operacionais.
Independência da rede – se o SGBD utilizado para implantação da rede distribuída suporta
diversos sistemas operacionais, deverá ser capaz de operar sobre um sistema operacional que
tenha suporte a diversos tipos de rede.
Independência de SGBD – o sistema de bancos de dados distribuído poderá ter sites
implementados com SGBDs diferentes.
A descrição de um banco de dados distribuído é afetada pelo tipo de sistema da seguinte
forma. Se o SGBD for homogêneo, todos os esquemas do nível lógico utilizarão o mesmo
modelo de dados. Já no caso de sistemas heterogêneos, teremos a seguinte situação:
Esquema conceitual global No modelo de dados pivot
Esquemas externos globais Podem ser tanto no modelo de dados pivot, para usuários
globais, ou em um modelo de dados local, no caso de se
desejar oferecer a um usuário local uma visão do BDD no
modelo que ele está acostumado.
Esquemas conceituais No modelo de dados local
locais
Esquemas externos locais No modelo de dados local
Figura 6 – Esquema de um banco de dados distribuído

59
X.2. EXEMPLO DA DESCRIÇÃO DE UM BDD
O banco de dados usado como exemplo refere-se a fornecedores, com número, nome e cidade-
sede; peças, com código e nome; e fornecimentos relacionando um fornecedor a cada peça que
fornece e indicando a quantidade fornecida. Assumindo que o banco é descrito no modelo
relacional, o esquema conceitual seria:
Esquema Conceitual Global
FORNECEDORES [ NUMERO,NOME,SEDE ]
PECAS [ CODIGO,NOME,COR,PESO ]
FORNECIMENTO [ NUMERO,CODIGO,QUANTIDADE ]
Poderíamos definir dois esquemas externos globais da seguinte forma:
Esquema Externo Global A:
Esquema de relação:
FORN_PECA [ NUMERO,CODIGO,NOME ]
Definição:
FORN_PECA = (FORNECIMENTO * PECAS) [ NUMERO,CODIGO,NOME ]
Esquema Externo Global B:
Esquema de relação:
FORN_PECA [ NUMERO,CODIGO ]
Definição:
FORN_PECA = FORNECIMENTO [ NUMERO,CODIGO ]
A álgebra relacional será usada para indicar mapeamentos neste exemplo; a operação de junção
natural será indicada pelo símbolo '*' e as operações de projeção e seleção serão denotadas da
forma usual, ou seja, R[X] indicará a projeção de R na lista de atributos X e R[B], onde B é uma
qualificação, indicará uma seleção das tuplas de R que satisfazem B.
Assumindo que o sistema é homogêneo e distribuído em apenas dois nós, os esquemas
conceituais locais e a distribuição do esquema conceitual global seriam então descritos da
forma abaixo (o primeiro nó conterá todos os fornecedores com sede em Varginha, todos os
fornecimentos em que estão envolvidos e o nome e código das peças; o segundo nó conterá o
resto dos fornecedores e seus fornecimentos, além do código, cor e peso das peças.
Esquemas Conceituais Locais:
Primeiro Nó:
FORNECEDORES1 [ NUMERO,NOME,SEDE ]
PECAS1 [ CODIGO,NOME ]
FORNECIMENTO1 [ NUMERO,CODIGO,QUANTIDADE ]
Segundo Nó:
FORNECEDORES2 [ NUMERO,NOME,SEDE ]
PECAS2 [ CODIGO,COR,PESO ]
FORNECIMENTO2 [ NUMERO,CODIGO,QUANTIDADE ]
Mapeamentos Definindo o Critério de Distribuição:
Primeiro Nó:
FORNECEDORES1 = FORNECEDORES [ SEDE='PASSA TRES' ]
PECAS1 = PECAS [ CODIGO,NOME ]
FORNECIMENTO1 = FORNECIMENTO * (FORNECEDORES1 [ NUMERO]
Segundo Nó:
FORNECEDORES2 = FORNECEDORES [ SEDE ≠ 'PASSA TRES' ]
FORNECIMENTO2 = FORNECIMENTO * (FORNECEDORES2 [ NUMERO]
PECAS2 = PECAS [ CODIGO,COR,PESO ]
60
Como os esquemas internos locais dependem do SGBD local em questão, não faz sentido
apresentá-los aqui. Esquemas externos locais também são omitidos.
X.3. PROJETO DE BDD
Em primeiro lugar, o projeto do esquema conceitual global e o dos esquemas externos globais é
inteiramente semelhante ao caso centralizado, já que o banco de dados distribuído deverá se
comportar como centralizado perante os usuários globais. Além disto, o projeto dos esquemas
internos locais é também idêntico ao de bancos centralizados, exceto que a carga imposta por
acessos remotos aos dados locais também deve ser levada em consideração. Portanto, o
problema básico de projeto de bancos de dados distribuídos reside no projeto dos esquemas
conceituais locais, pois estes refletem a estratégia de distribuição do banco.
As estratégias de distribuição são classificadas em particionamento e replicação. Seja D uma
estrutura (lógica) de dados do esquema conceitual global. Dizemos que D é particionada
verticalmente (ou estruturalmente) quando D é mapeada em duas ou mais estruturas (lógicas)
de dados que não são idênticas a D e que pertencem a diferentes esquemas conceituais locais.
Dizemos que D é particionada horizontalmente (ou particionada por ocorrência) quando D é
mapeada em estruturas idênticas a D e pertencentes a dois ou mais esquemas conceituais locais
de tal forma que o mapeamento define um particionamento (no sentido matemático) do
conjunto de dados associado a D.
No exemplo anterior, FORNECEDORES foi particionada horizontalmente em FORNECEDORES1 e
FORNECEDORES2, o mesmo acontecendo com FORNECIMENTO. Já PECAS foi particionada
verticalmente em PECAS1 e PECAS2.
Dizemos que D é replicada quando D é mapeada em duas ou mais estruturas (lógicas) de dados
idênticas a D e pertencentes a diferentes esquemas conceituais locais de tal forma que o
mapeamento de D em cada uma destas estruturas é sempre a identidade. Ou seja, existirão
cópias idênticas do conjunto de dados associado a D armazenadas em dois ou mais nós. A
replicação é total quando cada banco de dados local contém uma cópia completa do banco.
Caso contrário, a replicação é parcial.
A escolha da estratégia de distribuição do banco exige cuidados especiais, pois, se vier a gerar
um tráfego de dados exagerado entre os vários nós, o custo de comunicação tornará o projeto
anti-econômico.
Inicialmente, deve-se verificar se a solução distribuída é de fato uma opção viável. Isto significa,
essencialmente, detetar se o banco é fortemente integrado, ou se pode ser dividido em partes
mais ou menos independentes; se este for o caso, deve-se então determinar qual a vantagem
de descentralizar o banco. Um estudo do perfil da população de transações existentes no
sistema centralizado em uso (se este for o caso) deverá ser feito, tentando determinar se é
possível dividir o sistema - banco de dados e transações - em subsistemas mais ou menos
independentes. Se este for o caso, o custo de transmissão de dados deverá ser reduzido,
descentralizando-se o banco e suas funções. Acessos que cortem fronteiras geográficas ainda
serão suportados, desde que não sejam muito freqüentes. Uma vez identificado que a solução
distribuída é viável, deve-se escolher a técnica de distribuição, levando-se em conta os
seguintes fatores:
Particionamento:
61
Um BDD particionado não fica limitado à memória secundária disponível localmente e,

comparativamente a uma solução centralizada (com acesso distribuído), aumenta a
confiabilidade e eficiência do sistema, se há um alto grau de localidade de referência;
Replicação:
Um BDD replicado aumenta a confiabilidade, disponibilidade e pode aumentar a rapidez do
sistema, mas por outro lado cria problemas de propagação de atualizações nos dados e exige
mais memória secundária local.
Naturalmente, o grau de replicação do BDD traduz um compromisso entre o custo de acesso a
dados remotos e o custo de atualizar cópias múltiplas.
62
Resumo das estratégias de distribuição

% de Tamanho do Método de
Exceções Arquivo Distribuição
-- pequena replicação
pequena grande particionamento
alta grande centralizado
Nota: percentagem de exceções refere-se à freqüência com que uma transação necessita de
dados que não estão armazenados localmente.
Por fim, considerações envolvendo "hardware" devem ser mencionadas com relação ao projeto
de BDDs. A análise do equipamento necessário deverá responder, pelo menos, às seguintes
perguntas: Que processadores existem na organização (ou precisam ser adquiridos)? Qual a
configuração mínima dos processadores para suportar o SGBDD? Que periféricos são
necessários? Que equipamentos de comunicação de dados são necessário para interligar os
processadores?
X.4. ADMINISTRAÇÃO DE BDD
X.4.1. Organização e Tarefas da Equipe de Administração
A organização da equipe de administração, no caso distribuído, deve acompanhar a própria

estratégia de descentralização. Controle centralizado de um banco distribuído não faz sentido.
Uma organização plausível seria criar uma equipe local para cada nó onde o banco reside com
autoridade para propor e implementar mudanças em detalhe no banco local e nos esquemas
externos locais. Haveria ainda uma equipe central com autoridade para coordenar e vetar, se
necessário, mudanças no sistema (a serem implementadas pelas equipes locais).
As tarefas tradicionais da equipe de administração de um banco de dados (centralizado)
incluem o projeto lógico e físico do banco e sua documentação, definição dos vários esquemas
externos em consulta com os analistas de aplicação, definição dos critérios de autorização,
criação de rotinas de recuperação do banco, monitoração da utilização do banco e
reestruturação do banco. No caso de bancos de dados distribuídos, deve-se acrescentar ainda a
tarefa mais geral de garantir a cooperação entre os usuários em prol de uma compartilhamento
efetiva dos dados.
Três facetas da administração de um BDD merecem especial atenção: documentação do banco,
administração dos recursos locais de cada sistema e monitoração do sistema. (A tarefa básica de
projeto lógico e físico do banco já foi brevemente abordada na seção anterior).
A documentação do BDD deve tornar claro a todos os usuários o significado dos ítens de dados
armazenados pelo banco. Isto requer regras para sistematizar a nomenclatura e a descrição
informal dos ítens de dados, definição dos tipos de cada ítem de dados e regras para traduzir
um tipo utilizado em uma máquina para o tipo equivalente de outra (e.g., representação e
precisão de reais em máquinas diferentes).
A administração da carga imposta a cada sistema que compõe o BDD exige, antes de mais nada,
a definição de critérios de medição. Feito isto, é necessário criar regras que assegurem a
usuários remotos acesso a recursos locais e que atinjam um balanceamento entre a carga local e
a imposta por acessos remotos. Administração da carga inclui, também, definir como será
cobrado aos usuários locais e remotos a utilização do sistema.
63
Finalmente, uma vez estabelecidas regras para administração do banco, a equipe deverá auditar
periodicamente o sistema para assegurar a aderência a tais regras. A carga, tempo de resposta e
utilização do sistema deverá ser constantemente monitorada, prevendo-se reestruturação do
banco ou mudanças nas regras de administração para corrigir desequilíbrios.
X.4.2. Problemas que Afetam a Administração
Os problemas a serem enfrentados pela equipe de administração para atingir os seus objetivos
podem ser compreendidos considerando-se três cenários básicos para um banco de dados
distribuído.
Se o BDD resultou da interligação de sistemas existentes então certamente aparecerão
problemas devidos a: heterogeneidade do sistema global, introdução de padrões globais sem
que seja comprometida a autonomia local, critérios de alocação de custos tendo em vista
acessos locais e remotos, além do balanceamento do tempo de resposta de acessos locais e
remotos.
Se o cenário admite a criação de novos bancos locais de forma semi-autônoma, aparecerão
problemas relativos a: definição de regras e responsabilidades locais, descrição da semântica
dos dados definidos localmente, grau de cooperação entre os núcleos locais, principalmente no
que se refere à alocação de recursos para processamento de acessos remotos.
Finalmente, em um cenário onde o BDD foi criado pela distribuição em nós homogêneos de um
sistema centralizado, haverá o problema fundamental de definir uma estratégia de distribuição
que otimize o tempo de resposta global, sem penalizar demasiadamente grupos de usuários.
Resumo:
Um Sistema de Banco de Dados Distribuído oferece maior disponibilidade, confiabilidade,
segurança e maior desempenho. Porém sua implementação é mais cara e sua manutenção é
mais dispendiosa. Um banco de dados distribuído é uma solução ideal para sistemas de alta
disponibilidade como bancos e grandes sites de compras da Internet. Cabe ao engenheiro do
sistema escolher a opção de armazenamento e acesso a dados mais viável para sua aplicação.
64
X.5. ATIVIDADE X
Passo 1: Cite as principais vantagens de um BDD:
Passo 2: Cite as principais desvantagens de um BDD:
Passo 3: Explique a diferença entre replicação e particionamento:

65
UNIDADE XI.BANCO DE DADOS ORIENTADO A OBJETOS
Um banco de dados orientado a objeto é um banco em que cada informação é armazenada na

forma de objetos, e só pode ser manipuladas através de métodos definidos pela classe que
esteja o objeto. O conceito de banco de dados OO é o mesmo da LOO, com apenas uma
pequena diferença: a persistência de dados.
Existem pelo menos dois fatores que levam a adoção desse modelo, a primeira é que banco de
dados relacional se torna difícil trabalhar com dados complexos. A segunda é que aplicações
são construídas em linguagens orientadas a objetos (java, C++, C#) e o código precisa ser
traduzido para uma linguagem que o modelo de banco de dados relacional entenda, o que
torna essa tarefa muito tediosa. Essa tarefa também é conhecida como “perda por resistência”.
(ELMASRI, 2005)
O modelo OO ganhou espaço nas áreas como banco de dados espaciais, telecomunicações, e
nas áreas científicas como física de alta energia e biologia molecular. Isso porque essa
tecnologia oferece aumento de produtividade, segurança e facilidade de manutenção. Como
objetos são modulares, mudanças podem ser feitas internamente, sem afetar outras partes do
programa. O modelo OO não teve grandes impactos nas áreas comerciais embora tenha sido
aplicado em algumas.
Em 2004 os bancos de dados orientados a objeto tiveram um crescimento devido ao
surgimento de banco de dados OO livres. A Object Data Management Group (ODMG) com a
Object Query Language (OQL) padronizou uma linguagem de consulta para objetos.
Uma característica que vale a pena ser ressaltada, é que o acesso a dados pode ser bem mais
rápido, porque não é necessário junções. Já que o acesso é feito diretamente ao objeto
seguindo os ponteiros. Outra característica importante é que o BDOO oferece suporte a versões,
isto é, um objeto pode ser visto de todas e várias versões.
Os bancos de dados OO e relacionais apresentam uma série de características, e cada um tem a
sua vantagem e desvantagem. Como por exemplo, os modelos OO utilizam interfaces
navegacionais ao invés das relacionais, e o acesso navegacional é bem eficiente implementada
por ponteiros. Um problema seria a inconsistência desse modelo em trabalhar com outras
ferramentas como OLAP, backup e padrões de recuperação. E os críticos afirmam que o modelo
relacional é fortemente baseado em fundamentos matemáticos o que facilita a consulta, já os
modelos OO não, o que prejudicaria e muito as consultas. A dificuldade de implementar
encapsulamento seria um outro problema, porque como serão feitas as consultas se não é
possível ver os atributos.
XI.1. ESTRUTURA E CARACTERÍSITICAS
O objeto é formado como se fosse uma tripla (i, c, v), onde o i é o OID do objeto, o c é um
construtor, ou seja, que tipo de valor ele vai receber exmplo: atom, tuple, set, list, bag, array e v
é o valor corrente. Então o objeto passa a suportar aquilo que foi definido para ele. Se ele vai
receber um valor atômico ele só aceitará valores atômicos.
Os construtores de tipos sets, bags, lists e arrays são caracterizados como tipos de coleções e a
diferença entre eles é a seguinte: sets e bags, o primeiro só aceita valores distintos enquanto o
66
segundo aceita valores duplicados. Lists e arrays, o primeiro só aceita números arbitrários,
enquanto o segundo, o tamanho deve ser pré-estabelecido.
Umas das características dos sistemas OO é ocultar informação e tipos abstratos de dados,
sendo que é muito complicado aplicar esse modelo na prática. Por exemplo, nos sistemas atuais
para uma consulta em uma determinada tabela é necessário saber todos os atributos da tabela,
para formar a consulta. Em um sistema OO, que preza pelo encapsulamento nem toda tabela
pode enxergar a outra, o que dificultaria muito as consultas.
A idéia do encapsulamento em um BD OO, já que não dá para ser aplicado a rigor, é pelo
menos tratar o comportamento do objeto com funções pré-definidas. Por exemplo, insert,
delete, update etc. Ou seja, a estrutura interna do objeto é escondida, e os usuários externos só
conhecem a interface do tipo de objeto como os argumentos (parâmetros), de cada operação.
Então a implementação é oculta para usuários externos que está incluído a definição da
estrutura interna, de dados do objeto e a implementação das operações que acessam essas
estruturas. Enfim o BD OO propõe o seguinte, dividir estrutura do objeto em partes visíveis e
ocultas então para operações que exigem atualização da base de dados torna se oculta e para
operações que exige consultas, torna-se visível. (ELMASRI, 2005).
Em grande parte, os bancos de dados OO tem suas restrições com relação às extensões, isto é,
as extensões possuem o mesmo tipo ou classe. Na Linguagem OO nem sempre é assim.
SMALLTALK, por exemplo, permite ter uma coleção de objetos de diferentes tipos.
É comum em aplicações de banco de dados que cada tipo ou subtipo de dado possua uma
extensão associada, que mantenha a coleção de todos os objetos persistentes daquele tipo ou
subtipo. Nesse caso, a restrição é de que todo objeto numa extensão que corresponda a um
subtipo também deva ser um membro de extensão que corresponda a seu supertipo. Alguns
sistemas de banco de dados OO possuem um tipo de sistema predefinido (chamado de classe
raiz (root) ou classe OBJETO, cuja extensão contém todos os objetos do sistema. A classificação
então segue, designando objetos para supertipos adicionais que são significativos para a
aplicação, criando uma hierarquia de tipo ou hierarquia de classe para o sistema).
Grande parte do modelo OO separa claramente o que é objeto persistente, e objeto transiente.
Por exemplo, quando é realizada uma consulta, é carregada uma lista de objetos numa classe
transiente (temporária), o sistema pode manipular os dados nessa classe e assim que forem
feitas as manipulações necessárias elas deixam de existirem.
Uma das grandes vantagens de um SGBDOO é que ele permite salvar objetos grandes e depois
obter a recuperação facilmente desses grandes objetos como texto longos, imagens etc. Eles
são considerados não estruturados porque o SGBD não conhece a sua estrutura. A aplicação
pode utilizar várias funções para manipular esses objetos. E o mais importante é que o SGBD
não conhece essas funções, mas através de técnicas oferecidas por ele é capaz de reconhecer
esses
objetos e buscá-los no banco de dados. Caso o objeto seja muito grande ele pode utilizar
técnicas como buffering e caching.
É importante frisar que SGBDOO não é capaz de processar diretamente condições de seleções e
outras operações desses objetos. É necessário que esses dados sejam passados para o BD para
que ele possa saber tratar os objetos corretamente. Por exemplo, considere objetos que são
imagens bitmap bidimensional. Suponha que a aplicação precise selecionar a partir de uma
coleção de tais objetos somente aqueles que incluem certo padrão. Nesse caso, o usuário deve
fornecer o programa de reconhecimento do padrão, como um método em objetos do tipo
bitmap. O SGBDOO recupera, então, um objeto do banco de dados e aplica nele o método para
o reconhecimento do padrão para determinar se o objeto adere ao padrão desejado.
67
Objetos complexos estruturados são os objetos que contém vários tipos de objetos dentro
deles. Por exemplo, um objeto é composto de um list, de tupla, de um set, isto é, o SGBDOO
conhece todas essas estruturas, porém o objeto se torna complexo por composto de tipos de
objetos diferentes.
XI.2. BANCO DE DADOS OO NO MERCADO
Existem vários bancos de dados orientados a objeto, discutir cada um deles é essencial para a
tomada de decisão. É importante saber qual modelo é mais apropriado para o uso da sua
aplicação. A seguir estão alguns exemplos:
CACHÉ: trabalha com as seguintes linguagens: Java, .Net, C++, XML e outras. É um banco de
dados comercial.
VERSANT: trabalha com as seguintes linguagens: Java e C++. É bastante utilizado nos sistemas
telecomunicações, redes de transporte, áreas médicas e financeiras. É um banco de dados
comercial.
DB4Objects: Trabalha com as seguintes linguagens: Java e .Net. Sua linguagem de Consulta é a
Object Query Language (OQL) e é um banco de dados distribuído em duas licenças, a GPL
(licença pública Geral) e uma licença comercial.
O2: Trabalha com as seguintes linguagens: C, C++ e o ambiente O2. Sualinguagem de Consulta:
O2Query, OQL. Seu gerenciador do Banco de Dados é oO2Engine, e é um banco de dados
comercial.
GEMSTONE: trabalha com as seguintes linguagens: Java, C++, C#, XML e outras. Sua linguagem
de Consulta é o DML. É um banco de dados comercial.
JASMINE: Possui alta conectividade com Web, suporte à linguagem Java. Pode-seainda
desenvolver aplicações em Visual Basic usando Active/X, em HTML(HyperText Markup
Language) usando as ferramentas de conectividade para Web disponíveis no Jasmine, em C e
C++ usando APIs e em Java usando interfaces demiddleware embutidas no Jasmine. É um
banco de dados comercial.
MATISSE: Trabalha com as seguintes linguagens: Java, C#, C++, VB, Delphi, Perl,PHP, Eiffel,
SmallTalk. É um banco de dados comercial.
Objectivity/DB: trabalha com as seguintes linguagens: C#; C++; Java; Python,Smalltalk; SQL++
(SQL com objeto - extensões orientadas) e XML (para aimportação e a exportação somente). É
um banco de dados comercial.
Ozone: trabalha com as seguintes linguagens: Java e XML. É um banco de dados opensource.
XI.3. OBJECT DEFINITION LANGUAGE (ODL
A ODL foi feita para dar suporte aos construtores semânticos do modelo de objetos ODMG e é
independente de qualquer linguagem de programação em particular. O objetivo da ODL é criar
especificações de objetos, isto é, classes e interfaces. A ODL não é considerada uma linguagem
de programação completa. Ela permite que o usuário especifique um banco de dados
independente da linguagem de programação, e utilizando o binding específico com a
linguagem para especificar como os componentes ODL podem ser mapeados para
componentes em linguagens de programação específica, como C++, SmallTalk e Java.
68
XI.4. OBJECT QUERY LANGUAGE (OQL)
É a linguagem de consulta declarativa definida pela ODMG (1995). Prevê suporte ao tratamento
de objetos complexos, invocação de métodos, herança e polimorfismo. É projetada para
trabalhar acoplada com as linguagens de programação com as quais o modelo ODMG define
um biding, como C++, SMALLTALK e JAVA. Isso faz com que qualquer consulta OQL embutida
em uma dessas linguagens de programação pode retornar objetos compatíveis com os
sistemas de tipos dessa linguagem. Fornece suporte para lidar com set, structure, list e array,
tratando estas construções com a mesma eficiência. Permite expressões aninhadas. Pode
chamar
métodos dos tipos envolvidos na consulta. Não fornece operadores para atualização, mas pode
chamar operações definidas nos objetos para realizar esta tarefa, não violando assim a
semântica do modelo de objetos, o qual, por definição, é gerenciado pelos métodos
especificados no objeto. É possível definir um nome para uma determinada consulta, que é
armazenada no BD. Para uso posterior, a consulta é referenciada através do nome definido.
Apresenta construtores de objetos, structure, set, list, bag e array. Uma consulta em OQL parte
dos pontos de entrada do banco de dados e constrói como resposta, um objeto que é
tipicamente uma coleção. Suporta as cláusulas SELECT, FROM, WHERE, GROUP BY, HAVING e
ORDER BY.
XI.5. OBJECT QUERY LANGUAGE
A sintaxe básica da OQL é uma estrutura select ... from ... where, igual a da SQL. A seguir será
mostrado uma consulta, o nome de todos os departamentos na faculdade 'Engenharia‟:
SELECT d.dnome From d in departamentos WHERE d.faculdade ='Engenharia';
Na maioria das vezes, é necessário um ponto de entrada para o banco de dados para cada
consulta, que pode ser qualquer objeto persistente nomeado. Em muitas consultas, ponto de
entrada é o nome da extensão de uma classe, ou seja, uma extensão é considerada como sendo
o nome de um objeto persistente cujo tipo é uma coleção. Onde na maioria das vezes é um
conjunto, exemplos: set<Pessoa>, set<Professor>, set <Disciplinas> e assim por diante.
A utilização de um nome de extensão, por exemplo, departamentos em OQL, como um ponto
de entrada refere-se a uma coleção persistente de objetos. Toda vez que uma coleção for
referenciada em uma consulta OQL, devemos definir uma variável de interação (é parecido com
as variáveis de tupla que percorrem as tuplas nas buscas da SQL), d em OQL que percorre cada
objeto na coleção.
A consulta exemplificada irá selecionar certos objetos de acordo com a cláusula where
d.faculdade = 'Engenharia' e serão selecionados para o resultado da consulta. Sendo assim o
resultado da consulta é do tipo Bag<string> porque o tipo de cada valor dnome é recuperado
no resultado da consulta (embora o resultado seja um set porque dnome é um atributo chave).
É importante ressaltar que em geral, uma consulta seria do tipo bag para select ... from ... e do
tipo set para select distinct.
Existem três tipos de opções para especificar variáveis de interação: d in departamentos,
departamentos d, departamentos as d.
É importante ressaltar que qualquer objeto persistente nomeado que se refira a um objeto
atômico (simples) ou a um objeto coleção pode ser utilizado como um ponto de entrada para o
banco de dados.
69
Uma consulta não precisa seguir necessariamente a estrutura select ... from ... where ... . Por
exemplo, qualquer nome persistente por si mesmo é uma consulta, e neste cado o resultado é
uma referência a esse objeto persistente.
Por exemplo,
Q1: departamentos;
Neste caso, retorna uma referência à coleção de todos os objetos persistentes em
departamentos, cujo tipo seja set <departamento>.
Caso um nome persistente departamentocc estivesse atribuído a um departamento específico,
tipo 'ciencia da computação'. Q1a: departamento; O resultado seria “ciência da computação‟.
Uma vez que o ponto de entrada é especificado, o resultado, o conceito de expressão de
caminho (path expression) pode ser utilizado para indicar o caminho de atributos e objetos
relacionados. Normalmente, uma expressão de caminho inicia-se pelo nome de um objeto
persistente ou pela variável de interação que percorre os objetos individuais de uma coleção.
Esse nome será acoplado por zero ou mais nomes de relacionamentos ou nomes de atributos
conectados utilizando-se a notação de ponto.
Veja no exemplo a seguir, considerando um banco de dados UNIVERSIDADE:

Q2 : departamentocc.coordenador;
Q2a: departamentocc.coordenador.classificacao;
Q2b: departamentocc.possui_professores;
Fórmula 1 – Consulta de um banco de dados UNIVERSIDADE – exemplo.
A primeira retorna um objeto do tipo Professor, porque é o tipo do atributo coordenador da
classe Departamento. O objeto professor que está relacionado com o objeto Departamento cujo
nome persistente é departamentocc pelo atributo coordenador.
A segunda é bem parecida, só que retorna classificação do objeto Professor.
A terceira expressão retorna um objeto do tipo set <Professor> mesmo quando aplicada a um
objeto simples, pois é o tipo do relacionamento possui_professor da classe Departamento. O
resultado vão ser todos os professores que trabalham no Departamento ciência da computação.
Consultas como a Q3, não são permitidas porque o resultado poderia ser do tipo set<string>
ou bag<string>, uma vez vários professores podem possuir a mesma classificação. Q3:
departamentocc.possui_professores.classificaçao;
Q3a: select f.classificacao
from f in departamentocc.possui_professores;
Q3b: select distinct f.classificacao
from f in departamentocc.possui_professores;
Fórmula 2: Q3a: retorna os professores com suas respectivas classificações. Q3b: retornar o
mesmo resultado só que não retorna os resultados repetitivos. Fonte: ELMASRI, 2005.
A OQL Q3a retorna a classificação de todos os professores que trabalham no Departamento de
“ciência da computação”, o resultado é do tipo bag, ou seja, trará valores de classificação
duplicados. Já a segunda Q3b, trará o mesmo resultado da primeira, com uma exceção, os
valores não serão duplicados.
Na OQL também é possível especificar Visões como Consultas Nomeadas.
Na OQL visão (view da SQL), da-se o nome de consulta nomeada. Para realizar uma visão, usa-
se a palavra-chave define é utilizada para especificar um identificador para a consulta nomeada,
e deve ser único entre todos os nomes de objetos, classes, métodos e funções do esquema.
Uma vez definida a consulta torna se persistente até que seja redefinida ou removida. Veja o
exemplo:
70
V1: define possui_alunos(nomedepto) as

select s
from s in alunos
where s.estuda_em.dnome = nomedepto;
Fórmula 3: V1: retorna os alunos com seus respectivos departamentos. Fonte: ELMASRI, 2005
Da expressão estuda_em para Aluno, pode utilizar a visão V1, para representar seu inverso sem
ter que definir um relacionamento explicitamente. Também pode ser utilizado para representar
os relacionamentos inversos que não possuem expectativa de uso freqüente. É possível então
fazer: possui_alunos ('ciência da computação'). Essa OQL retornará um bag de alunos que
estudam no departamento de ciência da computação.
Na maioria das consultas é retornada uma lista de objetos. Caso seja necessário retornar um
único elemento pode ser feito o seguinte. Existe um operador chamado element na OQL que
garante o retorno desse único elemento e de uma coleção unitária c que contém somente um
elemento. Se c contiver mais que um elemento ou se c estiver vazia, o operador element causa
uma exceção. Veja o caso Q6:
Q6 : element (select d
from d in departamentos
where d.dnome = ''ciencia da computacao);
Fórmula 4: Extrai elementos únicos de coleções unitárias. Fonte: ELMASRI, 2005
Considerando que o departamento é único para todos os departamentos, o resultado será um
único departamento. O resultado é do tipo d:Departamento. Os operadores de agregação (min,
max, count, sum, e avg) operam sobre uma coleção. Esses operadores têm a mesma função, que
em SQL. O operador count retorna um tipo inteiro. Os outros (min, max, sum e avg) retornam o
mesmo tipo da coleção. Para compreender melhor esses operadores será mostrado duas
pesquisas a Q7 e a Q8. A primeira retorna o número de alunos que estudam 'ciência da
computação', enquanto a segunda retorna a média mdc de todos os aluno de nível superior que
se especializam em ciência da computação.
Q7 : count (s in estuda_em ('ciencia da
computacao'));
Q8 : avg (select s.mdc from s in alunos
where s.especializa_em.dnome = 'ciencia da
computação') and s.turma = 'superior');
Fórmula 5: q7: A primeira retorna o número de alunos que estudam 'ciencia da computação', q8
: retorna a média mdc de todos os alunos de nível superior que se especializam em ciencia da
computacao. Fonte: ELMASRI, 2005.
As expressões de pertinência e quantificação retornam um tipo booleano. Seja v um variável, c
uma expressão de coleção, b uma expressão do tipo booleano e é um elemento do tipo dos
elementos da coleção c. Então :
(e in c ) - retorna verdadeiro se o elemento e for um membro da coleção c.
(for all v in c:b) – retorna verdadeiro se todos os elementos da coleção c satisfizerem b.
(exists v in c:b) – retorna verdadeiro se existir pelo menos um elemento em c que satisfaça b.
A situação a seguir ilustrará a condição de pertinência, por exemplo, é necessário recuperar os
nomes de todos os alunos que completaram o curso chamado 'sistema de banco de dados I'.
Veja a Q10:
Q10 : select s.nome.unome, s.nome.p.nome
from s in alunos
where 'sistema de banco de dados I' in
(select c.nome from c in
s.disciplinas_cursadas.disciplinas.do_curso);
71
Fórmula 6: q10: Retorna os nomes de todos os alunos que completaram o curso chamado
'sistema de banco de dados I'. Fonte: ELMASRI, 2005.
A OQL Q10 mostra um modo mais simples de se especificar a clausula select de consultas que
retornam uma coleção de estruturas.
Consultas que retornam valores booleanos, true ou false. Assume-se que exista um objeto
jeremy do tipo Aluno. Então a consulta Q11, responde à seguinte pergunta: “jeremy se
especializa em ciencias da computaçao”. E a Q12, responde à pergunta “Todos os alunos de
ciência da computação são orientados por professores do departamento de ciência da
computação”. Tanto Q11 quanto Q12 retornam true ou false, que são interpretados como
resposta sim ou não para perguntas anteriores.
Q11: jeremy in especializa_em (ciencia da
computação);
Q12: for all g in (select s from s in grad_aluno
computação') : g.orientado_por in
departamentocc.trabalha_em;
Fórmula 7: Q11: Responde à seguinte pergunta: “jeremy se especializa em ciencias da
computação?” Q12: responde à pergunta “Todos os alunos de ciência da computação são
orientados por professores do departamento de ciência da computação ?” Fonte: ELMASRI,
2005.
Pode ser observado na consulta Q12 a herança de atributos, relacionamentos e operações é
aplicada em consultas. Seja s um interator que percorre grad_aluno, pode se escrever
s.especializa_em porque o relacionamento especializa_em é herdado por Grad_Aluno de Aluno
via Extends. Para finalizar, será mostrado o quantificador exists, representado na consulta Q13,
respondendo a seguinte pergunta: “Algum aluno de ciencia da computação possui mdc (média
das disciplinas cursadas) igual a 4.0 ?”. Também é possível notar a operação mdc herdada da
classe Grad_Aluno de Aluno via Extends.
Q13 : exists g in (select s from s in grad_aluno
computacao'; : g.mdc = 4;
Fórmula 8: Q13: respondendo a seguinte pergunta: “Algum aluno de ciencia da computação
possui mdc (média das disciplinas cursadas) igual a 4.0?” Fonte: ELMASRI, 2005.
Podem existir casos de recuperar o i-ésimo, do primeiro e do último elemento, ou extrair uma
subcoleção e concatenar duas listas. Observe a consulta Q14:
Q14: first (select struct (professor : f.nome.unome,
salario : f.salario) from f in professor order by
f.salario desc)
Fórmula 9: Q14: operador first em uma coleção list que contém os salários dos professores em
ordem decrescente de salário Fonte: ELMASRI, 2005.
A OQL 14 mostra o operador first em uma coleção list que contém os salários dos professores
em ordem decrescente de salário. Então, o primeiro elemento dessa lista ordenada contém o
professor com o maior salário. Neste caso, o resultado mostra um membro da faculdade que
ganha o maior salário.
Esta consulta Q15 recupera os três melhores alunos que se especializam em ciência da
computação, considerando o mdc;
Q15: (select struct (sobrenome : s.nome.unome,
primeiro_nome: s.nome.pnome, mdc: s.mdc)
from s in departamentocc.forma_especialistas order by
mdc desc) [0:2];
72
Formula 10: Q15: recupera os três melhores alunos que se especializam em ciência da
computação, considerando o mdc Fonte: ELMASRI, 2005.
Essa consulta select-from-order-by retorna uma lista de alunos de ciência da computação,
ordenados por mdc em ordem descendente. Sendo que o primeiro elemento de uma coleção
possui índice 0, de maneira que a expressão [0:2] retorna uma lista contendo o primeiro,
segundo, e o terceiro elemento.
A cláusula group by da OQL, é bem parecida com da SQL, só que ela fornece uma referência
explícita à coleção de objetos em cada grupo ou partição. Observe a Q16:
Q16 : select struct (nomedepto,
numero_de_especialistas : count (partition)) from s
in alunos group by nomedepto :
s.especializa_em.dnome;
Fórmula 11: Q16: Operador de agrupamento. Retorna o número de alunos em cada
departamento Fonte: ELMASRI, 2005.
O resultado é do tipo set<struct> (nomedepto: string, partition: bag <struct> (s:Aluno)>)>, que
contém uma estrutura para cada grupo partition com dois componentes: o valor do atributo de
agrupamento (nomedepto) e a bag de objetos de aluno no grupo (partition). A cláusula select
retorna o atributo de agrupamento (nome) e a bag de objetos de aluno no grupo (partition). A
cláusula de select retorna o atributo de agrupamento (nome do departamento) e uma
contagem do número de elementos em cada partição (ou seja, o número de alunos em cada
departamento), na qual partition é a palavra-chave utilizada para se referir a cada partição.
Conclusão:
É possível implementar um sistema de complexo usando um SGBD Orientado a Objetos. A
manipulação de objetos nativamente, aumenta a performance e os ganhos de desempenho de
linguagens orientadas a objeto como o Java e as linguagens da plataforma .NET. Permite maior
desempenho e redução no tempo de desenvolvimento do software, já que não é necessário
traduzir o modelo orientado a objeto para um modelo relacional, eliminando a complexidade
extra e a perda de performance com a conversão para outros formatos como SQL. Uma outra
vantagem desse banco é de não precisar de um DBA, pois sua administração é de
responsabilidade do próprio analista de sistemas.
Por ser uma tecnologia nova, muitas empresas preferem não arriscar, pois o modelo relacional
ainda é muito empregado nos dias atuais. Migrar de uma tecnologia bem difundida no mercado
para uma que está apenas começando seria muito arriscado. Essa é uma das desvantagens do
BD OO. O que ocasiona poucas aplicações nessa nova tecnologia. Muitos ainda não confiam na
sua integridade. À medida que a complexidade for aumentando, as empresas vão cada vez mais
buscar por alternativas que consigam adequar às suas necessidades.
Notas sobre a autoria:

Este capítulo foi baseado, principalmente, no artigo BANCO DE DADOS ORIENTADO A
OBJETOS: UMA REALIDADE cujos autores são ALAN CARVALHO GALANTE, Msc, ELVIS
LEONARDO RANGEL e FLÁVIO CAMILO.
XI.6. ATIVIDADE XI
Passo 1: Cite as principais vantagens de um banco de dados OO:

73
Passo 2: Cite as principais desvantagens de um banco de dados OO:

74
UNIDADE XII. TECNOLOGIAS EMERGENTES
XII.1. DATA WAREHOUSE
Data WareHouse Pode ser traduzido como “depósito de dados”. Sua função principal é o
armazenamento de informações de um banco de dados referente a uma ou mais atividades de
uma empresa de forma consolidada, voltada à tomada de decisões. É como um agrupamento
inteligente de dados de uma mesma fonte, como: origem, formato, nomes, tipo de negócio,
regras, conexões entre outros. Este princípio é muito discutido quando relacionado a BI
(Business Intelligence). Tudo isso favorece um resultado completo ao usuário, sem a
necessidade de executar várias consultas (relatórios), cruza-las e finalmente chegar a um
resultado. Em Data Warehouse os relatórios são exibidos dinamicamente de acordo com a
necessidade focando pontos estratégicos. Seu objetivo é trabalhar com uma grande quantidade
de informação e principalmente dados históricos. Estamos falando de sistemas transacionais
(OLTP), que, de uma forma bem ampla, são sistemas responsáveis por registrar todos os
acontecimentos de uma organização. Resumindo, são os acontecimentos históricos que nos
levam a uma melhor tomada de decisão e à prevenção de eventos futuros. Esses dados estão no
Data Warehouse. Por definição esses dados armazenados não mudam, exatamente por serem
dados históricos, salvo quando é necessário executar correções em alguma informação
específica. Um detalhe importante é que esses dados estão disponíveis somente para consulta.
Uma base modificável deixa de ser uma Data Warehouse. O que faz a leitura dessa base
histórica e inalterável é chamado de OLAP, nada mais do que um processador das informações
contidas na Data Warehouse. É através dele que o usuário consegue visualizar os resultados
palpáveis através de relatórios consistentes e inteligentes (a possibilidade de tomada de decisão
descrita acima).
O assunto DW é constantemente tratado na literatura devido a sua importância estratégica
dentro da empresa, na medida em que proporciona a tomada de decisão apoiada em dados
confiáveis e de fácil acesso. "Há décadas, as empresas tem sistematicamente coletado dados
operacionais através de seus sistemas OLTP (Online Transaction Processing Systems). Mas na
maioria dos casos, não houve preocupação com a integração entre as fontes de dados e com o
tratamento dos dados históricos".
Por outro lado, a metodologia e os mecanismos utilizados em projetos de interface
Homem/Máquina eram limitados a terminais orientados a caracteres até o surgimento das GUI
(Interfaces gráficas). Além da interface gráfica, novas tecnologias orientadas a objeto como
ActiveX e OLE disponibilizaram novos e poderosos recursos para a construção de interfaces HM.
A tecnologia de software componente interoperável apresenta os componentes como objetos
distribuídos que suportam a compatibilidade com interfaces binárias de intercomunicação. A
chave para o software componente é definir as interfaces entre os componentes e deixar o
construtor do componente escolher o melhor caminho para construí-lo de acordo. Desta forma,
OLE (Object Linking and Embeding) é um recurso importante para o projeto e implementação
de interfaces, pois permite a utilização de objetos não relacionados, que trocam informações
sem terem sido explicitamente programados para suportar uns aos outros.
"A interface ser humano-computador, normalmente chamada interface com o usuário, é a porta
de entrada para uma aplicação de software interativa". O valor de um DW está na qualidade das
decisões que ele suporta. Ferramentas poderosas de análise de informações nas áreas de OLAP
75
(Online Analytical Processing) e Data Mining, quando incorporadas a uma arquitetura de DW,
aumentam a competitividade das empresas.
Figura 7 – Ambiente de Data Warehouse
XII.2. DATA MART
Data Mart (entreposto ou bazar de dados) é sub-conjunto de dados de um Data warehouse

(armazém de dados). Geralmente são dados referentes a um assunto em especial (ex: Vendas,
Estoque, Controladoria) ou diferentes níveis de sumarização (ex: Vendas Anual, Vendas Mensal,
Vendas 5 anos), que focalizam uma ou mais áreas específicas. Seus dados são obtidos do DW,
desnormalizados e indexados para suportar intensa pesquisa. Data marts extraem e ajustam
porções de DWs aos requisitos específicos de grupos/departamentos.
As questões de planejamento, projeto e implementação são as mesmas encontradas em
qualquer fase da implementação de um DW, pois uma parte dos especialistas argumenta que o
DW é uma evolução natural de um Data Mart que começou localizado e cresceu para atender
um escopo maior. Essa visão tem defesa menos técnica e mais intuitiva do que sua contra-parte:
o Data Mart é criado a posteriori do DW, pois ele seria montado com dados extraídos do DW
para atender especificamente um setor da organização.
Numa visão comparativa dos dados, onde consideramos os quesitos escopo, integração, tempo,
agregação, análise e dados voláteis, percebemos que a diferença está no escopo, pois enquanto
o DW é feito para atender uma empresa como um todo, o data mart é criado para atender um
sub-conjunto da empresa. Repare que atender um sub-conjunto da empresa pode significar
reunir dados de outros setores, já que, na prática, raramente um único setor possui ou gera
toda informação que precisa. Vem dessa observação a defesa da tese de que o Data Mart é
construído após o DW.
Não se pode dizer que um Data warehouse é um conjunto de Data Marts. Seria o mesmo que
dizer que o armazém geral de um supermercado, onde todos os itens vão antes de seguir para
as lojas, é o agrupamento de supermercados.
76
XII.3. OLAP
OLAP – On line analytical processing (Processamento analítico on-line) designa uma ferramenta
que oferece um método de acessar, visualizar e analisar uma gama de dados corporativos com
alta flexibilidade e performance, visando oferecer relatórios gerenciais que servirão como
instrumento de apoio a decisões corporativas.
Ela se baseia no uso de dados consolidados que serão armazenados para criação futura de
cubos e posterior análise deles. Tais cubos armazenam valores quantitativos ou medidas, que,
por sua vez, são identificadas por duas ou mais categorias descritivas denominadas dimensões,
compondo a estrutura do cubo.
A utilização desses cubos proporciona uma análise multidimensional das informações, ou seja,
permite que um mesmo fato seja visto de diferentes ângulos. Por exemplo, um cubo que
contenha informações sobre vendas de uma empresa pode ser composto de diversas
dimensões, como tempo, região, produto, cliente e medidas (valor de venda, unidades vendidas,
custos, margem, etc). Cada dimensão ainda pode ser subdividida em níveis. No caso, a
dimensão região poderia conter os níveis país, região, estado e cidade. Ficam, assim, garantidas
pesquisas complexas e análises comparativas.
A ferramenta OLAP tem a capacidade de efetuar algumas operações que acabam tornando-se
características desse tipo de recurso, as quais são ótimos mecanismos de agilização e
flexibilização de consultas. São elas drill across, drill down, drill ip, drill throught e sice and dice,
esta última é responsável por modificar a posição de uma informação, trocar linhas por coluna,
facilitando a compreensão dos usuários, girando o cubo sempre que houver necessidade.
Características da análise OLAP:
Drill Across: ocorre quando o usuário pula um nível intermediário dentro de uma mesma
dimensão. Por exemplo: a dimensão tempo é composta por ano, semestre, trimestre, mês e dia.
O usuário estará executando um Drill Across quando ele passar de ano direto para semestre ou
mês.
Drill Down: ocorre quando o usuário aumenta o nível de detalhe da informação, diminuindo o
grau de granularidade.
Drill Up: é o contrário do Drill Down, ele ocorre quando o usuário aumenta o grau de
granularidade, diminuindo o nível de detalhamento da informação.
Drill Throught: é quando o usuário passa de uma informação contida em uma dimensão para
uma outra. Por exemplo: Estou na dimensão de tempo e no próximo passo começo a analisar a
informação por região.
Slice and Dice: é uma das principais características de uma ferramenta OLAP. Como a
ferramenta OLAP recupera o microcubo, surgiu a necessidade de criar um módulo que
convencionou-se de Slice and Dice para ficar responsável por trabalhar esta informação. Ele
serve para modificar a posição de uma informação, alterar linhas por colunas de maneira a
facilitar a compreensão dos usuários e girar o cubo sempre que tiver necessidade.
Alertas: são utilizados para indicar situações de destaque em elementos dos relatórios,
baseados em condições envolvendo objetos e variáveis. Servem para indicar valores mediante
condições, mas não para isolar dados pelas mesmas.
Ranking: permite agrupar resultados por ordem de maiores / menores, baseado em objetos
numéricos (Measures). Esta opção impacta somente uma tabela direcionada (relatório) não
afetando a pesquisa (Query).
77
Filtros: Os dados selecionados por uma Query podem ser submetidos a condições para a leitura
na fonte de dados. Os dados já recuperados pelo usuário podem ser novamente “filtrados” para
facilitar análises diretamente no documento.
Sorts: servem para ordenar uma informação. Esta ordenação pode ser customizada, crescente
ou decrescente.
Breaks: servem para separar o relatório em grupos de informações (blocos). Por exemplo: O
usuário tem a necessidade de visualizar a informação por cidades, então ele deve solicitar um
Break. Após esta ação ter sido executada, automaticamente o relatório será agrupado por
cidades, somando os valores mensuráveis por cidades.
XII.3.1. OLAP com IBExpert
O IBExpert oferece uma ferramenta OLAP para ser usada com os resultados de qualquer Query
que tenha sido executada dentro da IDE do IBExpert.
A figura e código abaixo representa uma visualização no cubo de decisão, baseada no resultado
da Query executada. Para acessar a ferramenta, basta executar qualquer query, e na tela de
apresentação do resulta, clicar no botão com o ícone de um cubo, na barra de botões.
select cli.customer, c.country, c.currency, vend.total_value,
vend.order_date
from customer cli
inner join country c on (cli.country = c.country)
inner join sales vend on (cli.cust_no = vend.cust_no)
Figura 8 – OLAP com IBExpert

78
Figura 9 – Gráfico OLAP - IBExpert

Através da ferramenta, é possível configurar dinamicamente o cubo, invertendo as posições e
agrupamentos dos dados, trocando linhas por colunas, etc. Com uma ferramenta deste tipo, é
possível em poucos minutos extrair informações para análise de negócio e verificar, por
exemplo, áreas deficientes, etc.
XII.4. DATA MINING
Data Mining é um termo em inglês que quer dizer mineração de dados e é empregada como
sinônimo de extração de informações implícitas constantes de base de dados, sendo muito
usada como ferramenta de apoio a decisões.
Esse assunto vem ganhando atenção de muitas áreas de interesse, sejam comerciais ou
científicas, pois todos os dias são armazenadas milhares de informações em meios eletrônicos,
com tendência a esse número crescer exponencialmente, e as empresas em geral estão
interessadas em buscar tecnologias e ferramentas que extraiam informações úteis desses dados
de forma a se ter acesso a elementos valiosos que contribuirão na competitividade entre as
empresas, bem como em seus resultados. Várias tendências, como a economia crescente
baseada em serviços, personalização em massa e crescente importância da informação é que
vêm influenciando no aumento da importância da informação sob o enfoque da
competitividade.
Apesar de essa coleta de dados e posterior análise poder ser feita manualmente, são atividades
lentas, em razão do volume de dados que cresce exponencialmente, além de serem caras e com
tendências pessoais. Por isso, tem-se buscado utilizar outras técnicas para a realização dessa
tarefa. A utilização do Data mining ainda é um campo pouco explorado devido ser uma
concepção desconhecida e ainda requer muita pesquisa e desenvolvimento, dessa forma, é um
campo promissor para aqueles profissionais de tecnologia da informação que se identificam
com o assunto de banco de dados e com essa área emergente de extração de conhecimento de
dados.
A utilização de data mining busca permitir que as empresas aumentem suas operações de
marketing, de vendas e de apoio aos clientes.
Basicamente os autores dividem o processo de descoberta do conhecimento utilizando a
técnica de data mining nos seguintes estágios: seleção dos dados, pré-processamento,
transformação, data mining propriamente dito, interpretação e avaliação. Sendo que a fase
79
“data mining” se preocupa com a extração de padrões dos dados, utilizando algoritmos de
procura.
Grandes empresas já vêm aplicando essa ferramenta como instrumento de suporte a tomada de
decisões, como Lojas Brasileiras, Wal-Mart, Bank of America, entre tantas outras.
XII.4.1. Tarefas e técnicas em mineração de dados
Descobrir padrões e tendências escondidos em grandes massas de dados não é um processo

trivial. Em mineração de dados este processo envolve o uso de diversas tarefas e técnicas. As
tarefas são classes de problemas, que foram definidas através de estudos na área. As técnicas
são grupos de soluções (algoritmos) para os problemas propostos nas tarefas. Cada tarefa
apresenta várias técnicas, e algumas técnicas podem ser utilizadas para solucionar tarefas
diferentes.
As classes de tarefas básicas são:
Classificação: consiste em examinar as características de um objeto (ou situação) e atribuir a ele
uma classe pré-definida. Ou seja, esta tarefa objetiva a construção de modelos que permitam o
agrupamento de dados em classes. Essa tarefa é considerada preditiva (afirmar sobre algo que
ocorrerá no futuro), pois uma vez que as classes são definidas, ela pode prever
automaticamente a classe de um novo dado. Por exemplo, uma população pode ser dividida em
categorias para avaliação de concessão de crédito com base em um histórico de transações de
créditos anteriores. Em seguida, uma nova pessoa pode ser enquadrada, automaticamente, em
uma categoria de crédito específica, de acordo com suas características.
Associação: estuda um padrão de relacionamento entre itens de dados. Por exemplo, uma
análise das transações de compra em um supermercado pode encontrar itens que tendem a
ocorrerem juntos em uma mesma compra (como café e leite). Os resultados desta análise
podem ser úteis na elaboração de catálogos e layout de prateleiras de modo que produtos a
serem adquiridos na mesma compra fiquem próximos um do outro. Essa tarefa é considerada
descritiva, ou seja, ela é usada para identificar padrões em dados históricos.
Clusterização (segmentação): as informações podem ser particionadas em classes de elementos
similares. neste caso, nada é informado ao sistema a respeito das classes existentes. O próprio
algoritmo descobre as classes a partir das alternativas encontradas na base de dados,
agrupando assim um conjunto de objetos em classes de objetos semelhantes. Por exemplo,
uma população inteira de dados sobre tratamento de uma doença pode ser dividida em grupos
baseados na semelhança de efeitos colaterais produzidos; acessos a WEB realizados por um
conjunto de usuários em relação a um conjunto de documentos podem ser analisados para
revelar clusters ou categorias de usuários. Essa tarefa é considerada descritiva.
Estimativa (regressão): objetiva definir um valor (numérico) de alguma variável desconhecida a
partir dos valores de variáveis conhecidas. Exemplos de aplicações são: estimar a probabilidade
de um paciente sobreviver dado o resultado de um conjunto de diagnósticos de exames;
predizer quantos carros passam em determinado pedágio, tendo alguns exemplos contendo
informações como: cidades mais próximas, preço do pedágio, dia da semana, rodovia em que o
pedágio está localizado, entre outros. Essa tarefa é considera preditiva.
XII.5. BANCO DE DADOS ORIENTADO A DOCUMENTOS
Os Bancos de Dados Orientados a Documentos foram construídos tendo a arquitetura Web

como principal referência de implementação. Portanto, seria mais interessante armazenar e
recuperar estas informações como foram construídas. Os SGBDRs por definição trabalham com
80
tabelas e suas relações, uma linguagem de manipulação e definição de dados, que são
estruturas de tabulação de dados, fugindo do conceito dos documentos, que são estruturas
livres, com dados autocontidos e autodescritivos.
Os bancos orientados a documentos surgiram devido a dificuldades do SQL de se lidar com
bancos de dados gigantescos e com diversos tipos de documentos.
Um movimento chamado de noSQL fomentou o desenvolvimento de algumas tecnologias para
ligar com bases de dados "super poderosas".
Algumas iniciativas de projetos open-source criaram padrões de bancos nosql como:
MongoDB é um banco de dados orientado a documentos de alta performance, open source e
schema-free, escrito em C++ e CouchDB é um banco de dados Orientado a Documentos que
funciona bem com a linguagem Ruby.
Grandes empresas também criaram suas tecnologias para melhorar os resultados de bancos
relacionais tradicionais ou orientados a objetos:
Google Bigtable - Usado para armazenar bases de dados com n petabytes de dados e muito
rápido. Armazenamento em coluna e não em linhas com os bancos relacionais.
Amazon Dynamo (Sistema de armazenamento distribuído com processamento em cluster)
Hadoop (Pataforma Java para aplicações distribuídas criada pelo Yahoo). O Facebook também
usa esta plataforma.
Cassandra (Criado pelo Facebook baseado no Dynamo e Bigtable)
Estas tecnologias foram desenvolvidas para atender a alta demanda de consultas, volumes de
dados e principalmente para garantir melhor disponibilidade.
A principal característica destes bancos é a implementação de diversos algoritmos de
indexação/busca que permita alta performance mesmo com grandes volumes de dados e
diversos tipos de documentos.
XII.5.1. Comparativo Relacional e Orientado a Documentos
Modelagem de Dados:
Os BDODs utilizam o conceito de dados e documentos autocontidos e autodescritivos, isso
implica que o documento em si já define como ele deve ser apresentado e o significado dos
dados em cuja sua estrutura estão armazenados. Os autores explicam que o conceito de dados
autocontidos ajudam a entender como se dá a modelagem orientada a documentos e utilizam o
exemplo de uma nota fiscal para mostrar como funcionam os documentos no mundo real. Em
um documento fiscal, todas as informações sobre uma transação já estão lá contidas: nome do
tomador do serviço, dados do prestador do serviço, data de prestação, serviços efetuados, entre
outras. Não há nenhuma referência abstrata para um outro pedaço de papel que indique o
nome do prestador do serviço ou o nome os itens que compõem aquela nota fiscal. Mesmo
assim, esta é a forma como os dados são armazenados em um banco de dados relacional: cada
nota fiscal é gravada em uma tabela tal que suas tuplas referenciem outras tuplas em outras
tabelas, onde teríamos uma tupla para as informações do prestador de serviço, uma para o
tomador do serviço, outra para cada item cobrado e assim por diante. Os autores deixam claro
que muitas vezes a forma como o modelo deve ser projetado, de acordo com seu paradigma,
muitas vezes não refletem a forma como um desenvolvedor gostaria de ter seus dados
armazenados.
A forma como os dados são modelados em BDODs permitem que haja redundância e
inconsistência dos dados, sem que haja nenhuma camada semântica para permitir o acesso a
uma única versão de um dado.
81
HÁ ainda, outra forma de modelagem de dados baseada em: uma pilha de cartões de visita. Da
mesma forma que uma nota fiscal, um cartão de visita contém todas as informações
importantes em um único documento. A maioria dos cartões de visita contém as mesmas
informações: a identificação de uma pessoa, sua afiliação e informações de contato. A diferença
principal é que o cartão de uma pessoa A pode conter o número do seu telefone celular,
enquanto de uma pessoa B, somente seja informado um telefone fixo. Como a pessoa B não
informou o número de um telefone celular, ela não tem a necessidade de tornar isso explícito,
escrevendo no cartão algo como “Telefone Celular: nenhum”. Ao invés, por simplesmente omitir
esta informação, a pessoa já está declarando que não possui um contato deste tipo disponível.
Observa-se logo, que documentos do mundo real tendem a variar de forma similar na
semântica dos dados, ou seja, o tipo de informação que estes documentos apresentam. Porém,
a sintaxe com a qual as informações são apresentadas, ou seja, sua estrutura, pode variar
enormemente. Em face ao exposto, conclui-se que enquanto num modelo relacional tradicional
é necessário que os dados estejam modelados antes de serem utilizados, em um BDOD livre de
esquema, os documentos estão prontos para agregarem informações após serem criados,
exatamente da mesma forma como é feita com os documentos do mundo real. Desta forma, os
documentos estão preparados para a evolução natural dos dados. Esta evolução pode ser
exemplificada quando uma pessoa com um cartão de visitas risca um número desatualizado e
escreve a informação mais atual, “evoluindo” os dados do documento.
Estado Global de Recursos:
Durante o processo de modelagem relacional, uma das premissas é a identificação única de
registros. A chave natural é a coleção de colunas que identificam uma tupla como única dentro
de uma tabela e que uma forma de facilitar a criação de chaves únicas em uma tupla, ao invés
da utilização de chaves naturais está na atribuição de um identificador numérico único para
cada tupla. A maioria dos bancos de dados relacionais provê estruturas chamadas de sequences,
que podem atribuir automaticamente estes identificadores numéricos a uma tupla. O principal
problema das sequences é que elas representam um estado global compartilhado, ou seja, a fim
de atribuir um identificador numérico para uma tupla, a obtenção do valor desta entidade deve
ser realizada de forma seqüencial, com um único acesso por vez. Isso se torna um problema
quando há dois bancos de dados em redes distintas que necessitam realizar uma atualização
concorrente de dados, pois não há uma forma de ambos os bancos saber em qual será o
próximo valor a ser atribuído. Surge então o conceito que “em uma arquitetura sem nada
compartilhado (shared-nothing architecture) não há um estado ou valor próximo”, pelo fato que
nenhum estado global é armazenado entre os bancos, ou seja, cada instância toma decisões
baseadas somente no seu estado atual.
Para contornar o problema das sequences, os BDODs podem utilizar o conceito de Universally
Unique Identifiers (Identificadores Únicos Universais, ou somente UUID), onde a possibilidade de
acidentalmente utilizar um mesmo identificador que outro banco de dados é efetivamente zero.
Os UUIDs são atribuídos como identificadores do documento, que devem ser únicos dentro de
um BDOD. Caso o usuário ache necessário atribuir uma chave natural a um documento, ele deve
utilizar campos específicos e armazená-los dentro do documento.
No que concerne a melhorias em relação aos bancos de dado relacionais, o conceito de UUID
não apresenta muita utilidade. O importante é entender que em BDODs não será necessário
consultar os documentos através de um identificador, já que estes oferecem métodos
avançados de agrupamento e filtragem de documentos baseado em seu conteúdo, através das
views e do MapReduce.
Um pouco sobre CouchDB:
82
O CouchDB é um sistema distribuído, acessível através de uma API RESTful, realiza o

armazenamento versionado de objetos que utiliza a abstração de documentos, disponibiliza
uma forma de agregar e consultar dados através do MapReduce e replica seus dados de forma
incremental, bi-direcional e multi-master, utilizando o MVCC, um algoritmo de consenso de
conflitos, onde os dados estão sujeitos a consistência eventual em cada nó.
O projeto Apache CouchDB ainda está nos seus estágios iniciais e a versão mais atual do
software (denominada 0.9) ainda é considerada alfa (software que ainda não está pronto para
produção). Apesar disso, aplicações como wikis, blogs, fóruns de discussão e sistemas de
gerenciamento de documentos têm evitado a utilização de SGBDRs a fim de tornar-se cada vez
mais eficientes no que concerne ao gerenciamento de revisão de documentos e a contínua
mudança de requisitos de esquema de dados, e utilizam o CouchDB em suas aplicações.
Conclusão
Bancos de Dados Relacionais definem uma estrutura rígida a fim de prover a manutenção de
consistência de dados para uma aplicação. Os BDODs oferecem uma nova forma de
armazenamento dos dados, referenciada como livre de esquema, por permitir o
armazenamento de dados de forma semi-estruturada, ainda fornecendo mecanismos de tornar
estes dados acessíveis e manipuláveis, sendo construídos especificamente no contexto da Web.
Em despeito a sua abordagem diferenciada em relação ao armazenamento, consulta e
distribuição de dados, os BDODs não substituem os SGBDRs, apenas realizam tarefas específicas
de forma mais eficiente, como o armazenamento versionado de objetos.
83
XII.6. ATIVIDADE XII
Passo 1: Utilize o IBExpert versão Trial para testar o recurso de OLAP e descreva abaixo os
passos necessários para realizar Slice and dice:
84
REFERÊNCIAS
ELMASRI, R. E.; NAVATHE S. Sistemas de Banco de Dados. 6 ed., São Paulo: Pearson
Prentice Hall, 2011.
DATE, C. J. Introdução a sistemas de banco de dados. 7 ed. São Paulo: Campus, 2000.
www.devmedia.com/br acessado em 01/12/2009
www.firebase.com.br acessado em 03/01/2010
CANTU, Carlos Henrique. Firebird Essencial. Rio de Janeiro: Editora Ciência Moderna Ltda, 2005.
CANTU, Carlos Henrique. Firebird: O banco de dados do novo milênio. Rio de Janeiro: Editora
Ciência Moderna Ltda, 2006.
WATSON, John; BERSINIC, Damir. Oracle Database 10g: Certificação OCP: Guia Completo
para o Exame. Rio de Janeiro: Editora Alta Books, 2006.
THE POSTGRESQL GLOBAL DEVELOPMENT GROUP. Documentação do PostgreSQL 8.0.0. Rio
de Janeiro, 2005.
MySQL-AB. MySQL Technical Reference for Version 5.1 Including MySQL Cluster NDB
6.X/7.X Reference Guide, 2011.
TODD, Bill. Introdução a Stored Procedures e Triggers no Firebird. Artigo, 2002.
http://www.comunidade-firebird.org/modules.php?name=Downloads&d_op=getit&lid=43
acessado em 09/01/2010.
ALAN, C. Galante et al. Banco de dados Orientado a Objetos: Uma realidade. Artigo.

Apostila Banco de Dados LL

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Banco de Dados LL

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE CENECISTA DE VARGINHA

Unidade I. REVISÃO CONCEITUAL ......................................................................................................................... 9

I.1. SGDB ........................................................................................................................................................................... 9

I.2. MODELO de dados relacional ........................................................................................................................... 9

I.2.1. Esquema ..................................................................................................................................................... 9

I.2.4. Relação ........................................................................................................................................................ 10

I.2.5. Tupla ............................................................................................................................................................. 10

I.2.7. Atributo ....................................................................................................................................................... 10

I.2.9. Chave estrangeira ................................................................................................................................... 10

I.2.11. Chave de verificação......................................................................................................................... 10

I.2.13. SQL .......................................................................................................................................................... 11

I.2.15. DCL .......................................................................................................................................................... 11

I.2.16. DML ......................................................................................................................................................... 12

I.2.18. Dicionário de dados ......................................................................................................................... 12

I.2.19. Catálogo de dados ............................................................................................................................ 12

I.3. ALGUMAS TECNOLOGIAS PARA BANCO DE DADOS RELACIONAL ................................................. 13

I.3.1. Servidores de banco de dados relacionais ................................................................................... 13

I.3.2. Ferramentas para manipulação ......................................................................................................... 13

I.4. ATIVIDADES I ........................................................................................................................................................... 14

Unidade II. CONSULTAS AVANÇADAS COM SQL ............................................................................................. 16

II.1.1. INNER JOIN................................................................................................................................................ 16

II.1.3. CROSSJOIN ................................................................................................................................................ 16

II.2. UNION ........................................................................................................................................................................ 17

II.4. FIRST ........................................................................................................................................................................... 17

II.5. SKIP .............................................................................................................................................................................. 17

II.7. CONCATENAÇÃO .................................................................................................................................................. 18

II.8. ATIVIDADE II ............................................................................................................................................................ 18

III.1. Índices ............................................................................................................................................................... 19

III.1.2. Índice de agrupamento (clustering) ........................................................................................... 19

III.1.4. Índice baseado em árvore .............................................................................................................. 20

III.1.5. SQL para manipulação de índices ............................................................................................... 21

III.2. Funções ............................................................................................................................................................. 21

III.2.1. Funções Internas ................................................................................................................................ 21

III.2.2. Funções de usuário ........................................................................................................................... 25

III.3. group by ........................................................................................................................................................... 25

III.3.1. HAVING ................................................................................................................................................. 25

III.4. ATIVIDADE III .................................................................................................................................................. 27

IV.1. controle de acesso ....................................................................................................................................... 28

IV.1.2. REVOKE .................................................................................................................................................. 30

IV.2. ATIVIDADE IV.................................................................................................................................................. 33

Unidade V. dsql - stored procedure ........................................................................................................................ 34

V.1. STORED PROCEDURE ........................................................................................................................................... 34

V.1.2. Parâmetros ................................................................................................................................................. 34

V.1.3. Declarando variáveis locais ................................................................................................................. 35

V.1.4. Corpo da Procedure ............................................................................................................................... 36

V.1.5. Elementos de linguagem ..................................................................................................................... 36

V.1.7. Comandos de atribuição ...................................................................................................................... 36

V.1.8. Comandos SQL nas STORED PROCEDURES ................................................................................. 37

V.1.10. Usando o SUSPEND .......................................................................................................................... 38

V.1.11. Criando e modificando Stored Procedures ............................................................................. 39

V.1.12. Apagando e alterando Stored Procedures .............................................................................. 39

V.1.13. Chamando Stored Procedures ..................................................................................................... 40

V.2. ATIVIDADE V ............................................................................................................................................................ 42

VI.1. Usando CREATE TRIGGER .......................................................................................................................... 43

VI.3. Usando OLD e NEW ..................................................................................................................................... 44

VI.5. Usando GENERATORS ................................................................................................................................ 45

VI.6. ALterando e excluindo Triggers .............................................................................................................. 45

VI.7. ATIVIDADE VI.................................................................................................................................................. 47

Unidade VII. VIEWS ..................................................................................................................................................... 48

VII.1. O QUE É UMA View? ................................................................................................................................... 48

VII.2. CRIANDO VIEW ............................................................................................................................................. 48

VII.3. Views atualizáveis ......................................................................................................................................... 49

VII.4. atividade VII .................................................................................................................................................... 50