Curso básico de FireBird – PARTE 01

Curso básico de FireBird – PARTE 01

http://firebirdsql.org/

IBExpert Downloadcenter 3.0

 
O Firebird (algumas vezes chamado de FirebirdSQL) é um sistema gerenciador de banco de dados. Roda em Linux, Windows, Mac OS e uma variedade de plataformas Unix. A Fundação FirebirdSQL coordena a manutenção e desenvolvimento do Firebird, sendo que os códigos fonte são disponibilizados sob o CVS da SourceForge.

História

O Firebird é derivado do código do Borland InterBase 6.0. Ele tem o código aberto e não possui licença dupla, portanto você pode utilizá-lo em qualquer tipo de aplicação, seja ela comercial ou não, sem pagar nada por isso - é totalmente GRATUITO!

A tecnologia usada no Firebird tem mais de 20 anos, fazendo com que ele seja um produto muito maduro e estável.

Principais Recursos

Não se engane com o tamanho do instalador! O Firebird é um SGBD completo e poderoso. Ele pode gerenciar bancos de dados de alguns Kbytes até dezenas de Gigabytes com boa performance e praticamente sem necessidade de manutenção!

Abaixo segue uma lista dos principais recursos do Firebird:
• Suporte total a Stored Procedures e Triggers
• Transações compatíveis com ACID
• Integridade Referencial
• Multi Generational Architecture
• Consome poucos recursos de processamento
• Linguagem nativa para Stored Procedures e Triggers (PSQL)
• Suporte para Funções Externas (UDFs)
• Praticamente não necessita de DBAs especializados
• Quase nenhuma configuração - instale e já comece a usar!
• Grande comunidade de usuários e vários lugares para se obter suporte gratuito
• Versão embedded do SGBD - perfeita para criação de catálogos em CDROM, aplicações "demo" ou standalone
• Dezenas de ferramentas de terceiros, incluindo aplicações gráficas de administração, replicação, etc.
• Careful writes - recuperação rápida, dispensa o uso de log de transações!
• Diversas formas de acesso ao banco de dados: nativo/API, dbExpress, ODBC, OLEDB, .Net provider, JDBC nativo tipo 4, Python module, PHP, Perl, etc.
• Suporte nativo para os maiores sistemas operacionais, incluindo o Windows, Linux, Solaris, MacOS.
• Backups incrementais
• Builds de 64bits disponíveis
• Total controle de cursores em PSQL
• Tabelas de Monitoramento
• Triggers de conexão e transação
• Tabelas temporárias

Métodos de acesso

As diversas maneiras de acessar um bancos de dados Firebird variam de acordo com a linguagem e sistema operacional utilizados. A seguir vemos os principais métodos disponíveis atualmente:
• ODBC - só deve ser utilizado quando não for possível usar um método de acesso nativo, pois sua performance é comprometida pela própria arquitetura do padrão.
• Drivers para .Net - já existe um driver .Net específico para o Firebird
• OLEDB - Existem alguns drivers OLEDB para Firebird. Detaque para o SIBPROvider, que é nacional e compatível com o Firebird e InterBase.
• JDBC - O JayBird é um driver JDBC tipo 4 desenvolvido especificamente para o Firebird.
• Diversos componentes de acesso nativo para Delphi, Kylix e C++Builder


http://firebirdsql.org/manual/generatorguide-rowids.html

Triggers

O AutoIncrement serve para que um valor de um campo seja automaticamente inserido toda a vez que se cria um novo registro, como um ID nas chaves primárias. No caso do Firebird, não há um campo de auto incremento nativo, por isso há um procedimento para realizar sua criação.

A criação precisa ser feita através de um generator e um trigger.
Pode ser criado via script, comandos SQL ou por um programa de conexão à bases Firebird

CREATE GENERATOR nome_do_generator

CREATE TRIGGER nome_da_trigger for nome_da_tabela -> Trigger é um gatilho
BEFORE INSERT position 0
AS
BEGIN
new.id = gen_id("nome_do_generator",1);
END;

Exemplo:
CREATE GENERATOR gen_clientes;
SET GENERATOR gen_clientes TO 7;

Trigger nada mais são do que “gatilhos”que são disparados após um determinado evento em uma tabela. As triggers podem definidas para execução antes ou depois das operações de insert, update e delete na tabela.
Exemplo:
set term !! ;
create trigger id_clientes for CLIENTES before insert position 0 as
begin
   if (new.ID is null) then new.ID = gen_id (gen_clientes, 1);
end!!
set term ; !!

select gen_id (gen_clientes, 0) from RDB$DATABASE;

Logando ao BD via Web (firebird.nomedoseusite.com.br)


Funções de Agregação (MAX, MIN, AVG, COUNT, SUM)

 MIN = Valor Mínimo de um conjunto de valores
 MAX = Valor Máximo de um conjunto de valores
 AVG = Média Aritmética de um conjunto de valores
 SUM = Total (Soma) de um conjunto de valores
 COUNT = Contar quantidade total de itens

A funções SUM e AVG somente aceitam como entrada um conjunto de números; já as demais funções podem operar também com outros tipos de dados não-numéricos, como por exemplo strings (caracteres) ou datas.

Exemplos:
Exemplos
1 – Retornar o número total de autores cadastrados na tabela de autores:
SELECT COUNT(*) FROM tbl_autores;
2 – Contar o número de autores que possuem livros cadastrados na tabela de autores, sem repetições
SELECT COUNT(DISTINCT id_autor) FROM tbl_Livro;
3 – Descobrir o preço mais alto dos livros:
SELECT MAX(Preco_Livro) FROM tbl_Livro;
4 – Descobrir a data de publicação do livro mais antigo:
SELECT MIN(Data_Pub) FROM tbl_Livro;
5 – Retornar o preço médio dos livros cadastrados no banco:
SELECT AVG(Preco_Livro) FROM tbl_Livro;
6 – Descobrir o valor total dos livros presentes na tabela de livros:
SELECT SUM(Preco_Livro) FROM tbl_Livro;

Domínios (domain's)

Um domínio é um tipo de dados personalizado definido pelo usuário global para o banco de dados . É usado para definir o formato e o intervalo de colunas , nos quais as definições de colunas reais nas tabelas podem ser baseadas. A integridade do domínio garante que uma coluna seja mantida dentro dos limites permitidos. Isso é obtido por meio de chaves e restrições.

No InterBase e FireBird domínios são como tipos de dados. Tais domínios têm grande semelhança com o conceito de domínio aplicado à matemática, ou seja, um domínio define um conjunto de valores válidos para uma dada situação.
Podemos criar qualquer banco de dados sem fazer uso explícito de domínios. No entanto usar domínios explicitamente pode deixar o banco de dados mais organizado, com regras claras e bem definidas, e ainda conseguir uma economia substancial de mão de obra na construção e manutenção do banco.
Exemplo:.
CREATE TABLE Cliente( Codigo INTEGER NOT NULL, Nome VARCHAR(40) NOT NULL, Fone VARCHAR(20), Fax VARCHAR(20), Celular VARCHAR(20), Renda NUMERIC(9,2) DEFAULT 0 NOT NULL, CONSTRAINT PK_Cliente PRIMARY KEY(Codigo), CONSTRAINT CHK_Cliente_Codigo CHECK(Codigo > 0), CONSTRAINT CHK_Cliente_Renda CHECK(Renda >= 0));


INNER JOIN [Juntar]

Na prática, raramente ocorre que todas as informações relevantes possam ser encontradas em uma única tabela do banco de dados . É muito mais comum que os dados necessários sejam distribuídos por várias tabelas e vinculados por relações. Na verdade, as informações em um banco de dados normalizado devem ser espalhadas por várias tabelas!

Em um banco de dados totalmente normalizado, a grande maioria das tabelas possui uma chave primária que consiste em apenas uma ou duas colunas . Se houver um relacionamento de integridade referencial , essas colunas de chave primária serão replicadas em outras tabelas para garantir a consistência dos dados. Essas são as colunas que permitem estabelecer links lógicos entre essas tabelas. Quando as consultas são realizadas, as tabelas são comumente unidas nessas colunas. Quando você estabelece uma junção, o Firebird / InterBase procura por valores correspondentes nas colunas designadas de cada tabela. Ele não se importa se um valor aparece uma vez em um lado da junção e várias vezes no outro lado, como costuma ser o caso.

VIEW [ver]

Para nós que trabalhamos com desenvolvimento de sistemas e administração de dados diretos, sabe o quanto é deprimente ter que escrever e reescrever determinadas consultas todos os dias ou mesmo mais de uma vez no mesmo dia. Muitas destas consultas são derivadas de várias tabelas o que nos dá um re-trabalho ao montar todos aqueles join's, utilizar esse ou aquele índice para esta ou aquela tabela para que também a performance de tal consulta tenha um tempo razoavelmente atraente. Com View podemos fazer consultas robustas e simples, e deixá-las prontas, para quando precisarmos, sem a necessidade de termos que repetir selects, algo muito interessante. Podemos unir várias tabelas, e utilizar apenas os campos que gostaríamos.

Stored Procedures

Uma Stored Procedure funciona como uma função que fica armazenada dentro do próprio banco. Para que possamos manipular os dados e metadados presentes dentro do banco de dados o IB/FB dispõem de uma linguagem de programação personalizada e otimizada.

Uma Stored Procedure suporta declarações de variáveis, testes de condições, loops, comentários etc. Uma característica muito importante das Stored Procedures é que as mesmas são executadas dentro do próprio banco de dados, o que as faz serem extremamente rápidas, e o melhor, rodam no servidor, e não na máquina cliente.

Através do uso de Stored Procedures temos acesso a todas as instruções SQL do tipo DML (Linguagem de Manipulação de Dados).

Stored Procedures suportam instruções DDL (Linguagem de Definição de Dados), isso é, você não consegue executar instruções de Create, Alter, Drop, Grant, Revoke, dentro a partir de uma Stored Pprocedure.

O uso de Stored Procedures dentro do banco de dados, traz diversas vantagens as nossas aplicações. Existem hoje, no mercado, aplicações que possuem todas as suas regras de negócio contidas dentro do próprio banco de dados.

A maior vantagem, sem duvida alguma é o grande ganho de performance e redução do tráfego de rede proporcionado pelas mesmas.

Podemos criar uma Stored Procedure diretamente no editor SQL da ferramenta que utilizamos para gerenciar nosso banco de dados. Ferramentas como o IBConsole e IBExpert trazem consigo interfaces visuais para facilitar a criação e manutenção de Stored Procedures. Para criar um Stored Procedure devemos utilizar a instrução Create Procedure:
Exemplo:
CREATE PROCEDURE NOME_DA_PROCEDURE LISTA_DE_PARAMETROS_DE_ENTRADA
RETURNS LISTA_DE_PARAMETROS_DE_SAIDA
AS
 LISTA_DE_VARIAVEIS_LOCAIS
     BEGIN
          CORPO_DA_PROCEDURE
 END;


Durante a definição de uma Stored Procedure, podemos definir parâmetros de entrada e de saída para a mesma. Uma lista de parâmetros de entrada representa uma lista de variáveis que são passadas pela aplicação cliente para a Stored Procedure. Essas variáveis, podem ser utilizadas dentro da Stored Procedure para modificar seu comportamento, fazendo parte de cálculos ou de filtros em instruções SQL, por exemplo. Suponhamos que exista uma Stored Procedure para calcular as vendas de um determinado cliente, nesse caso, devemos especificar um parâmetro de entrada onde passaremos o código do cliente o qual terá suas vendas processadas. Uma lista de parâmetros de saída, representa os valores de retorno que a Procedure pode passar de volta para a aplicação cliente que a chamou.