DO PARADOX PARA O FIREBIRD – VIA IBX

Parte II – Conceitos Básicos

Tabelas São entidades que armazenam os dados. Estes dados serão dispostos em
linhas e colunas.
Linhas são os correspondentes aos registros em tabelas Paradox
Colunas São os correspondentes aos campos do Paradox
Datatype Tipo de dados das colunas
Blob Datatype para armazenamento de dados binários ou de grande tamanho.
Podem guardar um memo, uma imagem, um vídeo, um executável de
uma aplicação, etc.
VarChar Datatype que armazena strings com tamanho variável. Quando se define
uma coluna varchar informa-se somente o tamanho máximo
Array Datatype que como o nome já diz permite armazenar uma matriz dentro
de uma coluna
Comandos (de Data Manipulation Language) Comando de manipulação de dados.
DML Inclusão, seleção, alteração e exclusão
Comando (de Data Definition Language) Comandos de definição de dados
DDL
Transação Contexto único onde são “aculumados” todas as manipulações de dados e
modificações nas estruturas solicitadas/efetudas ao banco de dados.
Todas estas manipulações realizadas desde o início da transação não são
diretamente passadas para o banco
Commit Grava efetivamente as alterações dos dados da transação em aberto,
confirmando-as
RollBack Descarta todas as alterações da transação em aberto, retornando o dados a
exata situação em que se encontrava antes de iniciar a transação
Primary Key (ou PK) Chave primária ou índice primário. índice que dá a linha seu
caráter único dentro de uma tabela. Uma PK pode ser simples (de
somente 1 campo) ou composta (com 2 ou mais campos)
Unique Key (ou UK) Tipo de índice de chave única. Ao se definir um UK não será
permitida a sua repetição em qualquer outra linha da tabela. A diferença
entre uma UK e uma PK é que a UK pode ser desativada. As UK’s
podem ser simples ou compostas.
Foreign Key (ou FK) Chave estrangeira. Corelação entre um ou mais campos com
uma UK/FK de outra tabela. Só é permitido a inclusão de um dados se o
mesmo existir na FK. As FK podem ainda conter as especificações On
Update/On Delete Cascade/Set Null. Estas especificações indicam que se
o dado da FK for alterado/apagado na tabela estrangeira, a linha “filha”
será apagada (em cascata) ou deixada em branco
Stored (ou SP) São procedimentos que podem ser disparados no servidor,
Procedure através de uma chamada do cliente, de outra SP ou de uma trigger. As SP
contém uma serie de comados DML que podem somente manipular os
 dados dentro do servidor, realizar alguma tarefa, retornar algum valor ou
até mesmo linhas de tabelas
Trigger Ou gatilho. São procedimentos com comandos DML que são vinculados
a uma tabela e são disparados automaticamente quando a ocorrência a
qual ele está atrelado ocorre. As trigger podem ser antes ou depois de
uma insersão, alteração ou exclusão de dados (before/after
insert/update/delete)
View Visão de tabela ou tabelas. Funciona como uma pseudo-tabela, pois é
somente guardado no banco a “receita” da visão. Quando acessada ela
busca os dados nas tabelas reais e os apresentam da forma desejada
Colate “Tabela” de referência utilizada pelo banco para a ordenação de um ou
mais campos tanto em índices quanto em resultados de seleções. É ele
que determina a
ordem, procura e comparação
Character Set Conjunto de caracteres que poderão ser utilizados no banco de dados /
coluna (campo). Também é definido o caracter Set a ser utilziado no
momento da conexão ao banco de dados
Dialeto Indicativo da versão do banco de dados. O dialeto 1 é utilizado para
compatibilizar o Firebird com bancos de dados Interbase até a versão 5.x.
O dialeto 2 é utilizado na depuração do banco. O dialeto 3 compatível ao
Firebird 1.0 e interbase 6.x. Ele introduz novos data types que não
existiam no IB antes da versão 6, como o tipo data e time
Joined Tables/ São designadas joined as tabelas/selects/view que unem dos dados
Select / Views (linhas/colunas) de duas ou mais tabelas, referenciando as linhas de uma
tabela a outra(s) de uma tabela distinta. Este “join” pode obrigar a
existência de uma correspondência dos dados em ambas tabelas. Exite a
possibilidade de se utilizar o parametro “Outer” que desobrigará a
necessidade da correspondência em uma das tabelas ou em ambas. Há
um outro aritgo na Comunidade que trata deste assunto especificamente.
Generator Entidade do banco Firebird que tem como função fornecer um valor
inteiro (tipo integer) único. A cada solicitação de um valor ao generator
ele devolve um inteiro único e sem repetição. O generator trabalha em
um contexto fora das transações ativas no banco, portanto ele não é
afetado por commits ou rollbacks. Uma das aplicações dos generator é a
implementação de campos auto-incrementais (que naturamente não
consta com um datatype do Firebird). Para isto utlizamos uma
combinação de generator e triggers
Constraint Regra de restrição aos dados de uma coluna de uma tabela. As constraints
podem der do tipo Unique Key (UK), Foreign Key (FK) ou Check (de
verificação). As constraints tem como função dar uma maior integridade
as dados armazenados no banco
UDF De User Defined Function, função definida pelo usuário. Um dos mais
preciosos recursos do Firebird. É permitido ao administrados do baco de
dados desenvolver funções externas (em Delphi, C, free pascal, etc.) no
formato DLL ou SO (linux) que podem ser chamadas diretamente no
banco. Tem como função aumentar a capacidade de processamento dos
 dados e atender necessidades que normalmente o servidor não atenderia.
Esta funcioalidade torna possível realizar qualquer operação planejada
Domain Ou Domínio. São definições globais de colunas. Funcionam como
Datatypes definidos pelo usuário. Em um domínio definimos o tipo de
dado, tamanho, consistência (check), obrigatoriedade, colate e character
set. Podemos criar infinitas colunas baseadas em um único domínio.
Outra vantagem é que a alteração aplicada a um domínio passa a valer
para todas as colunas que foram criadas basadas nele. O firebird tem
como característica sempre criar um domínio para cada coluna criada. Ou
seja, mesmo que você não indique um domínio ao criar uma coluna o
firebird criará um domínio para ele. Assim sendo é muito mais fácil,
didático e "limpo" criarmos domínios para todos os tipos de colunas que
utilizarmos em nossos bancos, deixando na mão do administrador o
controle total da situação

Para acessarmos o Firebird temos uma infidade de meios e métodos. Citarei a seguir
os principais:

BDE Tem como maior desvantagem ser baseado emuma tecnologia antiga
da Borland que conforme noticiado pela prórpia empresa está sendo
desativada. Normalmente permite acesso a bancos Firebird somente
com o dialeto 1 (há um upgrade que promete compatibilidade ao
dialeto 3, mas confesso não ter testado para dar certeza da informação)
DBX Database Express. Nova suite de compomentes para acesso genérico a
servidores de banco de dados. Possui drivers para Interbase/Firebird,
Oracle, MySQL, além da possibilidade de desenvolvimento de novos
drivers de conexão, como já existem para SQL Server. Tem como
maior vantagem a facilidade de portabilidade das aplicações. É claro
uma total portabilidade dependerá do desenho de sua aplicação
IBX Interbase Express. Suite de componentes para acesso nativo ao
Interbase/Firebird. Por ser nativo e exclusivo para IB/Firebird é mais
rápido do que o DBX. É desta suite que iremos tratar neste artigo
IBO - Suite de compomentes desenvolvida por Jason W. que possui
total compatibilidade com o Firebird, com excelentes componentes de
acesso
Zeos Suite de componentes a vários SGDB
API FireBird Acesso direto ao Firebird através da API Cliente

Cabe ao programador estudar a melhor forma de acesso e componentes disponíveis

para atender as suas necessidades específicas. Pessoalmente optei pelo uso do IBX por não
pretender portar minhas aplicações para outro banco e estar familiarizado com os
componentes dataware nativos do Delphi.
 O segundo passo é compreender o conceito de aplicação Cliente/Servidor.

Já se fala a muito tempo em aplicações cliente/servidor e não irei aqui fazer uma
discertação técnica e acadêmica sobre o mesmo. Vamos á pratica.

Em uma aplicação C/S como já falei temos duas instâncias básicas. A cliente, é a a
interface que possibilita o usuário ter acesso a base e a servidora, que provem os dados e
os manipula. Ao contrário das aplicações que acessam base de dados desktop (como o
Paradox) que trabalham com toda a massa de dados nas estações, as aplicações C/S
normalmente trabalham com a menor quandidade possível de dados nas estações. A idéia é
somente trazer para a aplicação os dados necessários para a operação desejada. Um
exemplo: Por que trazer todos os dados dos clientes (nome, endereço, etc) para uma
pesquisa se o que necessitamos é somente o nome, ou ainda, se você vai somente
manipular os dados de 1 cliente por que trazer os dados dos demais?

Além disto, sempre que possível utilize os recursos do SGDB como Stored
Procedures, Triggers, FK para ter um ganho de performance. Lembre-se que quem tem
que garantir a integridade dos dados é o SGDB e não sua aplicação. Tenha sempre em
mente que sua aplicação é apenas mais uma interface de acesso aos dados. Isto nos remete
ao conceito de aplicações em n-camadas (neste caso trabalharemos em 2 camandas -
interface e servidor), mas isto é um assunto para outra ocasião (é incrível como um assunto
leva ao outro). É possível existir várias camadas intermediárias entre a ponta cliente e a
outra banco de dados. Estas camadas intermediárias tem como função de reduzir o
trabalho do banco de dados oferecendo “regras de negócio” para a aplicação em seu todo.

E o que eu quero dizer com tudo isto ? Bem vamos imaginar um caso simples. Um
banco com as seguintes tabelas: Clientes, Notas e itens da nota. Com o Paradox a
integridade/ligação entre as tabelas seria atribuição de sua aplicação. Com um SGDB a
coisa fica um pouco diferente. Inicialmente teriamos FK's (lembram-se das definições que
falei antes ?) ligando os itens a nota e a nota ao cliente. Para enriquecer o exemplo, a FK
que liga os itens à nota seria do tipo cascade delete e a que liga a nota à tabela clientes
seria somente update cascade. Quando a aplicação excluir uma nota, automatica os itens
ligados a ela seriam excluidos pela FK. Ao passo que a tentativa exclusão de um cliente
retornaria um erro de violação da FK que liga as notas aos clientes, pois teriamos notas
apontando para um cliente que nçao existiria mais. Então o SGDB simplesmente não
realiza a operação mantendo sua integridade. Caso se fizesse a alteração do codigo do
cliente (supondo que esta seja a ligação entre as tabelas clientes-Notas) o seu valor é
automaticamente atualizado na tabela notas. Não se gasta 1 linha de código para
inplementar esta segurança. Imagine fazer isto com o Paradox ? Sem falar que as regras
valem tanto para as alterações efetuadas pela aplicação quanto para alterações realizadas
por uma ferramenta externa, por exemplo o IBConsole. Imaginemos ainda que houvesse
mais uma tabela, a Clientes desativados, onde se guardaria os dados dos clientes que
fossem exclídos da tabela de clientes. Com o uso de uma simples trigger Before Delete
podeiramos jogar os dados deste cliente para a outra tabela antes de excluí-la sem ter que
implementar uma única linha de código na aplicação.

Outra grande vantagem é a possibilidade da mudança das regras. imagine se

desistissemos da idéia do arquivo de cliente de clientes desativados, bastaria a desativação
temporária ou exclusão da trigger para implementar esta mudança, sem novamente
precisarmos mexer no código da aplicação.

Agora é só dar asas a imaginação e fazer uma boa análise da estrutura de seu futuro
banco de dados. Não se esqueça de um detalhe que me atormentou no início de minha
migração: O Firebird,assim como os demais SGBD estão sempre verificando se as
alterações realizadas no banco de dados, tando dos dados em si quando da estrutura do
mesmo não causaram quedra da integridade das informações armazenadas. O que quero
dizer com isto ? No Paradox podiamos nudar a estrutura de uma tabela facilmente,
excluir/modificar campos e índices, excluir os dados ou mesmo as tabelas. Com o Firebird
já não é bem assim. Se existir alguma amarração a uma tabela/campo as modificações
poderão ser negadas pelo servidor.

Continua ....

Este artigo foi escrito originalmente por Jean Paul F. Lopes, sócio da empresa TSA
Tecnologia Sistemas e Automação Ltda – Gravataí – RS – Brasil,
Colaborador da Comunidade Firebird de Língua Portuguesa para uso exclusivo da mesma

Artigo Original

Jean Paul F. Lopes

(Colaborador da CFLP)

jeanlopes@tsa-sistemas.com.br Comunidade Firebird de Língua Portuguesa

Visite a Comunidade em:

http://www.comunidade-firebird.org

Este texto é exclusivo da CFLP