A place to share and follow researchSubmit an Article or Content File →

Banco de dados

loading
Loading file Wait!

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...................................................................................................................................... 10

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

I.2.14. DDL..................................................................................................................................................... 11

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

I.2.16. DML..................................................................................................................................................... 11

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.....................................................12

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

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.......................................................................................................................................................... 17

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............................................................................................................................. 22

III.3. group by...................................................................................................................................................... 23

III.3.1. HAVING.............................................................................................................................................. 23

III.4. ATIVIDADE III............................................................................................................................................. 24

Unidade IV. SEGURANÇA......................................................................................................................................................25

IV.1. controle de acesso..................................................................................................................................... 25

IV.1.1. GRANT...............................................................................................................................................25

IV.1.2. REVOKE............................................................................................................................................. 27

IV.1.3. CONTROLE DE ACESSO NO FIREBIRD.........................................................................................28

IV.2. ATIVIDADE IV............................................................................................................................................ 30

Unidade V. dsql - stored procedure.........................................................................................................................................31

V.1. STORED PROCEDURE..............................................................................................................................31

V.1.1. O comando CREATE PROCEDURE..................................................................................................31

V.1.2. Parâmetros.......................................................................................................................................... 31

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

V.1.4. Corpo da Procedure ........................................................................................................................... 33

V.1.5. Elementos de linguagem .................................................................................................................... 33

V.1.6. Bloco de comandos BEGIN-END........................................................................................................33

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

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

V.1.9. Usando FOR SELECT e DO ..............................................................................................................35

V.1.10. Usando o SUSPEND ........................................................................................................................ 35

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

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

V.1.13. Chamando Stored Procedures .........................................................................................................37

V.2. ATIVIDADE V.............................................................................................................................................. 39

Unidade VI. DSQL - TRIGGERS ............................................................................................................................................40

VI.1. Usando CREATE TRIGGER .....................................................................................................................40

VI.2. BEFORE/AFTER........................................................................................................................................ 41

VI.3. Usando OLD e NEW ................................................................................................................................. 41

VI.4. Gerando EXCEPTIONS ............................................................................................................................ 41

VI.5. Usando GENERATORS ............................................................................................................................ 41

VI.6. ALterando e excluindo Triggers .................................................................................................................42

VI.7. ATIVIDADE VI............................................................................................................................................ 43

Unidade VII. VIEWS................................................................................................................................................................44

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

VII.2. CRIANDO VIEW........................................................................................................................................ 44

VII.3. Views atualizáveis.....................................................................................................................................45

VII.4. atividade VII............................................................................................................................................... 46

Unidade VIII. TRANSAÇÕES..................................................................................................................................................47

VIII.1. Modos de Acesso..................................................................................................................................... 48

VIII.1.1. READ WRITE...................................................................................................................................48

VIII.1.2. READ ONLY.....................................................................................................................................48

VIII.2. Tipos de Bloqueio..................................................................................................................................... 48

VIII.2.1. WAIT.................................................................................................................................................48

VIII.2.2. NO-WAIT.......................................................................................................................................... 48

VIII.3. Nível de isolamento.................................................................................................................................. 48

VIII.3.1. Read uncommitted............................................................................................................................ 48

VIII.3.2. Read committed................................................................................................................................ 48

VIII.3.3. Snapshot...........................................................................................................................................49

VIII.3.4. Snapshot table stability.....................................................................................................................49

VIII.4. modo de pré-alocação..............................................................................................................................49

VIII.5. Exemplo de transação..............................................................................................................................50

VIII.6. ATIVIDADE VIII........................................................................................................................................51

Unidade IX. PROJETO COMPLETO (TRABALHO).................................................................................................................52

Unidade X. BANCO DE DADOS DISTRIBUÍDO......................................................................................................................53

X.1. Principais características de um BDD.........................................................................................................53

X.2. Exemplo da Descrição de UM BDD............................................................................................................55

X.3. PROJETO DE BDD.....................................................................................................................................56

X.4. ADMINISTRAÇÃO DE BDD........................................................................................................................ 57

X.4.1. Organização e Tarefas da Equipe de Administração..........................................................................57

X.4.2. Problemas que Afetam a Administração.............................................................................................58

X.5. ATIVIDADE X.............................................................................................................................................. 59

Unidade XI. Banco de dados ORIENTADO A OBJETOS........................................................................................................60

XI.1. ESTRUTURA E CARACTERÍSITICAS......................................................................................................60

XI.2. Banco de Dados OO no mercado .............................................................................................................62

XI.3. Object Definition Language (ODL ..............................................................................................................62

XI.4. Object Query Language (OQL) ................................................................................................................. 62

XI.5. Object Query Language ............................................................................................................................63

XI.6. atividade XI................................................................................................................................................. 67

Unidade XII. TECNOLOGIAS EMERGENTES........................................................................................................................68

XII.1. DATA WAREHOUSE................................................................................................................................68

XII.2. DATA MART.............................................................................................................................................. 69

XII.3. OLAP......................................................................................................................................................... 70

XII.3.1. OLAP com IBExpert........................................................................................................................... 71

XII.4. Data Mining............................................................................................................................................... 72

XII.4.1. Tarefas e técnicas em mineração de dados......................................................................................73

XII.5. Banco de dados orientado a documentos.................................................................................................73

XII.5.1. Comparativo Relacional e Orientado a Documentos .......................................................................74

XII.6. ATIVIDADE XII..........................................................................................................................................77

Figura 1 ? Clube.fdb................................................................................................................................................................14

Figura 2 ? Índice clusterizado..................................................................................................................................................20

Figura 3 ? índice B+.................................................................................................................................................................20

Figura 4 ? Tela de controle de acesso do Ibexpert..................................................................................................................29

Figura 5 - Transação...............................................................................................................................................................47

Figura 6 ? Esquema de um banco de dados distribuído..........................................................................................................54

Figura 7 ? Ambiente de Data Warehouse................................................................................................................................69

Figura 8 ? OLAP com IBExpert................................................................................................................................................71

Figura 9 ? Gráfico OLAP - IBExpert.........................................................................................................................................72

PREFÁCIO Este material compreende o conteúdo básico da disciplina Banco de dados II do curso de 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 Os seguintes recursos serão amplamente tratados: Análise de operações DML para buscar a otimização visando melhores resultados de Apresentar conceitos de transações em SGBDs, como concorrência e recuperação em caso de 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 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.

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 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 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.

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 Propriedades básicas de um SGDB: ? 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 ? 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) 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.

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 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 I.2.5. Tupla 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 I.2.7. Atributo 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 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 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 Uma restrição estática sempre valida os mesmo valores enquanto que uma restrição dinâmica 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 3 ? reduções de valores nulos ? sempre que possível deve-se reduzir o número de atributos que 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 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 Podemos dizer que sem o uso de SQL, o trabalho com banco de dados relacional se torna quase 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. 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) 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). 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 · 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 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.

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. Firebird ? Originado do Interbase, gratuito, muito disseminado no Brasil. Oracle ? Considerado por muitos o banco de dados ideal para grandes corporações, é pago e 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 IBExpert ? Ideal para modelar, manipular e administrar banco de dados Firebird é pago, mas 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.

I.4.ATIVIDADES I Questão 1.1: Crie um banco de dados com o nome CLUBE.fdb com a seguinte estrutura:

UNIDADE II. CONSULTAS AVANÇADAS COM SQL II.1. JOINS De acordo com (CANTU, 2006) faz relacionamento de diversas formas entre diversas tabelas em A sintaxe da cláusula JOIN precisa incluir a palavra reservada ON que estabelece a regra da 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. FULL: Retorna todos registros do stream esquerdo e todos do stream direito. Os campos cujo o 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 Exemplo: Uma tabela com 10 registros e outra com 100 irá retornar um conjunto com 1000 (mil) registros.

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 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 Este recurso permite a elaboração de consultas mais complexas sem ter que usar views ou 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 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.

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 Exemplo: SELECT NOME || ? ? || SOBRENOME FROM CLIENTES

UNIDADE III. ÍNDICES E FUNÇÕES III.1. ÍNDICES De acordo com Elmasri e Novate (2005), Índices são estruturas de acesso adicionais auxiliares usadas para aumentar a velocidade da recuperação de registros na resposta a certas condições 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 é 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 Elmasri e Novate (2005), 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: Exemplo: Chamamos de índice esparso quando os valores indexados nunca se repetem ou repetem O maior problema deste tipo de índice é o trabalho necessário para incluir e excluir registros, 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 Também é considerado esparso porque para cada registro haverá uma entrada no índice, 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.

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 Também possui dois campos, porém o segundo nem sempre é o bloco do arquivo, podendo ser III.1.4. Índice baseado em árvore Os índices baseados em árvore são usados geralmente para pesquisar intervalos de valores, mas Dentre as estruturas em árvore, B+ é a mais usadas pelos SGDBs. Um de seus pontos fortes é o 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+.

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 Isto quer dizer que quando executamos o comando ALTER TABLE para adicionar uma chave, 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 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

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 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 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.

DECLARE EXTERNAL FUNCTION UDF_LEN CSTRING(254) RETURNS INTEGER BY VALUE Esta função fica armazenada no arquivo tbudf.dll (Windows) ou tfudf.so (Linux). Serve para 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 Exemplo: SELECT CAT.CAT_DESCRICAO,COUNT(*) AS QTD FROM SOCIOS S INNER JOIN COTAS C ON S.SOC_COTA = C.COT_ID 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 Exemplo: SELECT CAT.CAT_DESCRICAO,COUNT(*) AS QTD FROM SOCIOS S INNER JOIN COTAS C ON S.SOC_COTA = C.COT_ID 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.

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:

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 - Integridade: Proteger os dados contra usuários autorizados, ou seja, ter certeza de que aquilo Principais aspectos relativos à segurança: · Controles físicos (sala dos equipamentos) · 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 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.

possui a soma dos privilégios concedidos diretamente para o mesmo, mais os privilégios concedidos para todos os grupos que este seja membro, mais os privilégios concedidos para 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 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 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 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 INSERT - Permite inserir (INSERT) novas linhas na tabela especificada. Também permite utilizar 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). 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. 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 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 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 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 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 Exemplos: GRANT ALL PRIVILEGES ON CONFIG TO ADM;

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 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 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 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 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 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 programasfirebirdfirebird_2_1bin" - Digite: gsec -user SYSDBA -password masterkey - No prompt "GSEC>" digite: display (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: - 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: 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.

IV.2. ATIVIDADE IV 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 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:

Informe aqui o comando que deve ser usado: Informe aqui o comando que deve ser usado:

Passo 6: Dê permissão para a tabela SOCIOS com GRANT OPTION para a role GERENTES . Informe aqui o comando que deve ser usado:

Passo 7: Tente Acesse o banco com o usuário LEITOR e tente modificar a tabela SOCIOS. Informe a mensagem apresentada pelo servidor.

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 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 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 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;

Usa-se o comando EXECUTE PROCEDURE para rodar esta stored procedure a partir de uma trigger, outra stored procedure ou qualquer console SQL. Exemplo: Para executar essa stored procedure a partir de sua aplicação Delphi, usa-se a seguinte sintaxe: with ProcDm.AdjustSalRngProc do begin 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).

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 · Triggers são criadas pelo comando CREATE TRIGGER.

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 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 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: 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 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;

vez que você o chama. Para criar um GENERATOR use o comando CREATE GENERATOR ou 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: 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: É 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 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: 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. 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 END ^ Para apagar uma trigger use o comando DROP TRIGGER. Por exemplo: 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).

UNIDADE VII. VIEWS 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: · Permitem que os mesmos dados sejamvistos por usuários diferentes de modos diferentes 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 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.

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) 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.

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).

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 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 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 Os conflitos podem aparecer não somente em operações de gravação, mas também em operações de leitura.

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 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 (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 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 Shared, read: permite a qualquer transação ler dados, e qualquer transação com acesso WRITE a 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 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 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 Considere o seguinte entrelaçamento (escalonamento):

Outro exemplo: Como o SGBD vê o segundo escalonamento: 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 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 COMMIT WORK na segunda e tente fazer o mesmo na primeira.

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.

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 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 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 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 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 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.

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 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 Independência de SGBD ? o sistema de bancos de dados distribuído poderá ter sites 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 Esquemas conceituais locais No modelo de dados local Esquemas externos locais No modelo de dados local

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 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 ] 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 No exemplo anterior, FORNECEDORES foi particionada horizontalmente em FORNECEDORES1 e FORNECEDORES2, o mesmo acontecendo com FORNECIMENTO. Já 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. 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 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: 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 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.

Resumo das estratégias de distribuição % de Exceções Tamanho do Arquivo Método de 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 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 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á 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 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 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.

X.5. ATIVIDADE X Passo 1: Cite as principais vantagens de um BDD:

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 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 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 é, 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 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 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 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 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 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 É 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. 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 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 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 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 GEMSTONE: trabalha com as seguintes linguagens: Java, C++, C#, XML e outras. Sua 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 MATISSE: Trabalha com as seguintes linguagens: Java, C#, C++, VB, Delphi, Perl,PHP, Eiffel, 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). É 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.

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, set, set 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 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 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 Existem três tipos de opções para especificar variáveis de interação: d in departamentos, É 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 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 é Por exemplo, Neste caso, retorna uma referência à coleção de todos os objetos persistentes em 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: 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 A segunda é bem parecida, só que retorna classificação do objeto Professor. A terceira expressão retorna um objeto do tipo set 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 ou bag, uma vez vários professores podem possuir a mesma classificação. Q3: Q3a: select f.classificacao Q3b: select distinct f.classificacao 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 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: V1: define possui_alunos(nomedepto) as select s from s in alunos 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 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);

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 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:

(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 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 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 é 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.

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 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, 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 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 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 Drill Down: ocorre quando o usuário aumenta o nível de detalhe da informação, diminuindo o Drill Up: é o contrário do Drill Down, ele ocorre quando o usuário aumenta o grau de 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 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, 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 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 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 XII.3.1. OLAP com IBExpert O IBExpert oferece uma ferramenta OLAP para ser usada com os resultados de qualquer Query 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 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 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 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 A utilização de data mining busca permitir que as empresas aumentem suas operações de 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 ?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 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 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.

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 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 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 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 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 Um pouco sobre CouchDB: 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.

BIBLIOGRAFIA ELMASRI, R. E.; NAVATHE S. Sistemas de Banco de Dados. 4 ed., São Paulo: Pearson 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, CANTU, Carlos Henrique. Firebird: O banco de dados do novo milênio. Rio de Janeiro: Editora WATSON, John; BERSINIC, Damir. Oracle Database 10g: Certificação OCP: Guia Completo THE POSTGRESQL GLOBAL DEVELOPMENT GROUP. Documentação do PostgreSQL 8.0.0. 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 ALAN, C. Galante et al. Banco de dados Orientado a Objetos: Uma realizada. Artigo.