016_SimpleAdmin

Prévia do material em texto

Centro Universitário do Sul de Minas – UNIS MG 
 
Unidade de Gestão da Educação Presencial – GEDUP 
 
Bacharelado em Ciência da Computação 
 
 
 
 
 
SimpleAdmin – Interface Gráfica para administração em bancos de dados 
Firebird 
 
 
 
 
Professor Paulo Roberto Rodrigues de Souza 
 
 
 
 
Joselara dos Santos Verginio 
Rodrigo Souza Rios 
Sebastião Tadeu de Rezende Silva 
 
 
 
 
Varginha, 2006 
 
 
 
 
2 
Centro Universitário do Sul de Minas – UNIS MG 
 
Unidade de Gestão da Educação Presencial – GEDUP 
 
 Bacharelado em Ciência da Computação 
 
 
 
SimpleAdmin – Interface Gráfica para administração em bancos de dados 
Firebird 
 
Professor Paulo Roberto Rodrigues de Souza 
 
Joselara dos Santos Verginio 
Rodrigo Souza Rios 
Sebastião Tadeu de Rezende Silva 
 
 
Projeto de Conclusão de Curso 
apresentado ao programa do curso de 
Bacharelado em Ciência da 
Computação do Centro Universitário 
do Sul de Minas, como requisito 
parcial para a obtenção do título de 
Bacharel em Ciência da Computação. 
 
 
 
 
 
Varginha, 2006 
 
 
 
 
3 
Folha de Aprovação 
 
 
Joselara dos Santos Verginio 
Rodrigo Souza Rios 
Sebastião Tadeu de Rezende Silva 
 
 
SimpleAdmin – Interface Gráfica para administração em bancos de dados 
Firebird 
 
Monografia apresentada ao curso de Ciência da Computação do Centro 
Universitário do Sul de Minas – UNIS/MG, como pré-requisito para obtenção do grau de 
bacharel pela Banca Examinadora composta pelos membros: Juliano Coelho Miranda, Lázaro 
Eduardo, Paulo Roberto Rodrigues de Souza. 
 
( ) Aprovado 
( ) Reprovado 
 
Data / / 
 
 
____________________________________________________ 
Profº. Ms. Paulo Roberto Rodrigues de Souza. 
 
____________________________________________________ 
Profº. Esp. Juliano Coelho Miranda. 
 
____________________________________________________ 
Profº. Esp. Lázaro Eduardo. 
 
 
 
 
 
4 
 
 
 
 
 
 
 
 
 
 
Dedicamos este trabalho 
primeiramente a Deus, nossos 
familiares, amigos e a comunidade 
docente do Unis – MG, na qual nos 
provém conhecimentos e fundamentos 
necessários em nosso dia a dia. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5 
Agradecimentos 
 
 
Agradecemos a Deus por nos privilegiar quanto ao dom do aprendizado, e 
oportunidade de estar cursando uma Faculdade. Também elevamos nossa estima em relação 
aos funcionários do Unis em geral, especialmente ao professor Paulo Roberto Rodrigues de 
Souza, na qual ministra a matéria fundamental para o desenvolvimento do projeto. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6 
Sumário 
AGRADECIMENTOS ..........................................................................................5 
SUMÁRIO..............................................................................................................6 
LISTA DE FIGURAS............................................................................................8 
RESUMO................................................................................................................9 
ABSTRACT .........................................................................................................10 
1. INTRODUÇÃO ..........................................................................................11 
1.1. OBJETIVOS ................................................................................................11 
1.2. PROBLEMATIZAÇÃO..................................................................................12 
1.3. JUSTIFICATIVA ..........................................................................................12 
1.4. ESTRUTURA DO TRABALHO ......................................................................12 
2. REFERENCIAL TEÓRICO .....................................................................13 
2.1. A LINGUAGEM DE PROGRAMAÇÃO DELPHI ...............................................13 
2.1.1. Considerações Iniciais......................................................................13 
2.1.2. Histórico do Delphi ..........................................................................13 
2.1.3. A linguagem de Programação Delphi ..............................................13 
2.1.4. O Delphi e seu IDE...........................................................................14 
2.1.5. Modelo Lógico Relacional................................................................15 
2.1.6. Sistema Gerenciador de Bancos de Dados Relacional (SGDBR)....15 
2.1.7. A Linguagem de Programação SQL.................................................19 
2.1.8. Firebird.............................................................................................22 
2.1.9. Acesso Nativo....................................................................................29 
2.1.10. Componentes de Acesso IBX ..........................................................29 
2.1.5.1 Componente IBDatabase ................................................................30 
2.1.5.2 Componente IBTransaction ............................................................31 
2.1.5.3 Componente IBQuery .....................................................................32 
2.1.5.4 Componente IBUpdateSQL ............................................................33 
2.1.11. Componentes de acesso e manipulação Data Access.....................35 
2.1.12. Interface Homem Máquina e Ergonomia Computacional..............38 
 
 
 
7 
2.1.13. Critérios Ergonômicos ...................................................................38 
2.1.14. Considerações Finais .....................................................................40 
3. DESENVOLVIMENTO.............................................................................41 
3.1. IMPLEMENTAÇÃO DO FORMULÁRIO PRINCIPAL ........................................41 
3.2. IMPLEMENTAÇÃO DO FORMULÁRIO REGISTRAR BANCOS .........................42 
3.3. VISUALIZAÇÃO DOS DETALHES DO BANCO ...............................................43 
3.3.1. Visualização dos Stored Procedures ................................................46 
3.3.2. Visualização dos Geradores (Generator).........................................47 
3.3.3. Visualização dos Domínios (Domains) ............................................48 
3.3.4. Visualização das Tabelas .................................................................48 
3.3.5. Visualização SQL .............................................................................49 
3.3.6. Execução Backup / Restauração ......................................................50 
3.3.7. Alteração de Valores dos Geradores................................................51 
3.3.8. Visualização e Execução de 3 Consultas SQL simultaneamente .....52 
4. CONCLUSÃO.............................................................................................54 
4.1. DIFICULDADES ENCONTRADAS.................................................................54 
4.2. TRABALHOS FUTUROS ..............................................................................54 
4.3. CONSIDERAÇÕES PESSOAIS.......................................................................54 
5. REFERÊNCIA BIBLIOGRÁFICA..........................................................55 
6. ANEXOS .....................................................................................................57 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
8 
Lista de Figuras 
 
 
FIGURA 2.1 – INTERFACE DE DESENVOLVIMENTO DO DELPHI 7 (IDE) ......................................14 
FIGURA 2.2 – PALHETA DE COMPONENTES IBX (INTERBASE) ...................................................30 
FIGURA 2.3 – PALHETA DE COMPONENTES IBX – COMPONENTE IBDATABASE ........................31 
FIGURA 2.4 – PALHETA DE COMPONENTES IBX – COMPONENTE IBTRANSACTION ...................32 
FIGURA 2.5 – PALHETA DE COMPONENTES IBX – COMPONENTE IBQUERY .............................33FIGURA 2.6 – PALHETA DE COMPONENTES IBX – COMPONENTE IBUPDATESQL ....................34 
FIGURA 2.6 – PALHETA DE COMPONENTES IBX – IBRESTORESERVICE E IBBACKUPSERVICE .34 
FIGURA 2.6 – PALHETA DE COMPONENTES DATA ACCESS ........................................................35 
FIGURA 2.6 – PALHETA DE COMPONENTES DATA ACCESS COMPONENTE DATAACCES............36 
FIGURA 2.6 – PALHETA DE COMPONENTES DATA ACCESS COMPONENTE CLIENTDATASET ....37 
FIGURA 2.6 – PALHETA DE COMPONENTES DATA ACCESS COMPONENTE DATASETPROVIDER 38 
FIGURA 3.1 – INTERFACE DO FORMULÁRIO PRINCIPAL..............................................................41 
FIGURA 3.2 – INTERFACE DO FORMULÁRIO PARA REGISTRAR OS BANCOS.................................42 
FIGURA 3.3 – INTERFACE DE VISUALIZAÇÃO DOS DETALHES DO BANCO. ...................................44 
FIGURA 3.4 – VISUALIZAÇÃO DOS STOREDPROCEDURES...........................................................46 
FIGURA 3.5 – VISUALIZAÇÃO DOS GERADORES (GENERATOR)..................................................47 
FIGURA 3.6 – VISUALIZAÇÃO DOS DOMÍNIOS (DOMAINS) .........................................................48 
FIGURA 3.7 – VISUALIZAÇÃO DAS TABELAS..............................................................................49 
FIGURA 3.8 – VISUALIZAÇÃO SQL............................................................................................50 
FIGURA 3.9 – VISUALIZAÇÃO SEGURANÇA BACKUP/RESTORE ..................................................50 
FIGURA 3.10 – VISUALIZAÇÃO MANUTENÇÃO INDICES GERADORES.........................................53 
FIGURA 3.11 – VISUALIZAÇÃO DOS RESULTADOS DAS CONSULTAS SQL..................................52 
 
 
 
 
 
 
 
 
9 
Resumo 
 
 
Esta monografia descreve o desenvolvimento de uma ferramenta capaz de 
fornecer recursos para administração e manutenção em bancos de dados Firebird, pois existe 
a necessidade de uma ferramenta interativa e descomplicada, livre de qualquer licença para 
usuários inexperientes e futuros Dba´s (Database Administrator). A ferramenta possui 
recursos didáticos que auxiliam no aprendizado da linguagem de Programação para banco de 
dados SQL. Esse projeto tem como funções principais a criação de uma interface gráfica para 
o banco Firebird. Dentre os recursos disponíveis podemos destacar: 
a) Acesso fácil aos bancos cadastrados. 
b) Listagem das Tabelas do banco de dados com opção de filtrar as tabelas da 
lista. 
c) Exibição detalhada da tabela selecionada como campos, índices e 
metadados. 
d) Exibição de outras particularidades do banco como Generators, Domais e 
Stored Procedures. 
e) Executa até três selects e vários comandos (update/delete) ao mesmo 
tempo. 
f) Permite efetuar o backup do banco e restaurar o mesmo. 
 Com uma gama bastante interessante de recursos, tal aplicação possibilitará 
interação total ao banco de dados através de uma interface gráfica. 
 
Palavras-chave: 
Banco de dados, interface, programação, Firebird, SQL. 
 
 
 
 
 
 
 
 
 
 
 
10 
Abstract 
 
 
This monograph describes the development of a tool capable to supply to 
resources administration and maintenance in data bases Firebird, therefore the necessity of an 
interactive tool exists and easy free of any license for inexperienced and future users Dba´s 
(Database Administrator). The tool possesss didactic resources that assist in the learning of 
the programming language for data base SQL. This project has as main functions the creation 
of a graphical interface for the Firebird bank. Amongst the available resources we can detach: 
a) Easy access to the registered in cadastre banks. 
b) Listing of Tables of the data base with option to filter tables of the list. 
c) Detailed exhibition of the selected table as fields, indices and metadata. 
d) Exhibition of other particularitities of the bank as Generators, Domais and Stored 
Procedures. 
e) It executes up to three selects and some commands (update/delete) at the same time. 
f) It allows to effect backup of the bank and to restore the same. 
With a sufficiently interesting gamma of resources, such application will make 
possible total interaction to the data base through a graphical interface. 
 
Keywords: 
Database Bank, interface, programming, Firebird, SQL. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
11 
1. Introdução 
 
Em meados de 1985, um grupo de engenheiros da DEC (Digital Equipament 
Corporation) deu inicio ao projeto chamado Groton, um banco de dados relacional, pois nessa 
época a idéia era construir um SGDBR (Sistema Gerenciador de Banco de Dados Relacional), 
contudo esse projeto ao longo dos anos veio sofrendo profundas alterações até finalmente em 
1986, receber o nome de Interbase®, iniciando na versão 2.0, e em julho de 2000 recebeu o 
nome de Firebird; uma versão OpenSource do Interbase® 6.0 quando a sua criadora Borland 
disponibilizou os fontes do projeto. 
O impulso inicial para a história do software livre foi dado em 1969, quando Ken 
Thompson, criou um sistema operacional multi-tarefa totalmente isento de custos. A sigla 
OSS (Open Source Software) é a que designa esse tipo de software, cuja estrutura do software 
pode ser modificada por qualquer usuário com conhecimentos tangíveis em informática. 
O uso de uma ferramenta livre para administração em bancos de dados Firebird, 
contribui maciçamente com o crescimento da legião de usuários que procuram alternativas 
viáveis, tanto para o uso próprio quanto comercial, visto que cada vez mais o Firebird vem 
conquistando mercados antes explorados somente pelos “gigantes” comerciais. 
 
 
1.1. Objetivos 
 
• Geral 
− Projetar e desenvolver uma ferramenta capaz de administrar bancos de 
dados Firebird, provendo de uma maneira clara e intuitiva a administração e o 
controle do banco, facilitando o uso tanto para fins didáticos como para aplicações 
profissionais, sem restrições de uso. 
 
• Específicos 
− Fazer um estudo detalhado dos recursos necessários como: IHM 
(Interface Homem Máquina) e ergonomia computacional, linguagem de 
programação, estrutura de manipulação e acesso à Banco de Dados, linguagem de 
pesquisa declarativa para banco de dados relacional (SQL) e Firebird. 
− Implementar os recursos básicos para a administração do banco. 
 
 
 
12 
− Implementar rotinas e métodos de segurança do banco utilizando 
componentes de manipulação de dados em memória. 
− Gerenciamento de backup e restauração do banco. 
 
1.2. Problematização 
 
Existe alguma ferramenta livre de licenças para essa finalidade, em proporções 
regionais? O usuário conseguirá obter retorno positivo através da utilização do software? 
 
• Hipóteses 
Com o desenvolvimento do SimpleAdmin, o software poderá se tornar uma 
vitrine para atrair investimentos de empresas ligadas ao setor de Desenvolvimento 
Computacional, gerando renda, empregabilidade e contribuindo com o crescimento local 
aquecendo o mercado interno de software. 
 
Delimitação do Problema 
O desenvolvimento do projeto se limitará basicamente nos controles 
administrativos do banco de dados. 
 
1.3. Justificativa 
 
Utilizando o SimpleAdmin, o usuário poderá estar ampliando seus conhecimentos 
sobre os assuntos na qual ele abrange, sendo Banco de Dados, Linguagem SQL e 
particularidades do Firebird. Portanto sendo uma ferramenta tanto didática quanto 
profissional. 
 
1.4. Estrutura do Trabalho 
 
O respectivo trabalho está dividido em 4 capítulos, sendo estes: 
− Capítulo 1: introdução e definição do escopo do projeto; 
− Capítulo 2: referencial teórico; 
− Capítulo 3: desenvolvimento; 
− Capítulo 4: conclusão. 
 
 
 
13 
2. Referencial Teórico 
 
 
2.1. A linguagem de Programação Delphi 
 
2.1.1. Considerações Iniciais 
 
Este estudo visa apresentar informações úteis quanto ao desenvolvimento 
utilizando a linguagem de programação Delphi. 
 
2.1.2. Histórico do Delphi 
 
Segundo o WIKIPÉDIA, quando lançado em 1995 para a plataforma Windows 16 
bits, Delphi foio primeiro a ser descrito como ambiente Rapid Application Development 
(RAD - em português, Desenvolvimento Rápido de Aplicações). A sua segunda versão, 
lançada um ano depois com o Delphi 2 já produzia aplicativos para a plataforma Windows 32 
bits, sendo que uma versão em C++, o C++ Builder surgiu alguns anos depois. Em 2001 uma 
versão para plataforma Linux, conhecida como Kylix foi disponibilizada. 
As principais diferenças entre o Delphi/Kylix e outras ferramentas de 
desenvolvimento são: a Linguagem Delphi, as paletas VCL e CLX, forte ênfase na 
conectividade com diversos bancos de dados e um grande número de componentes 
produzidos por terceiros, muitos deles disponíveis na internet e grande parte deles com o 
código fonte disponível. 
 
2.1.3. A linguagem de Programação Delphi 
 
O Ambiente de desenvolvimento Delphi, baseia-se em uma extensão orientada à 
objetos da linguagem de programação Pascal, conhecida como Object Pascal. Recentemente a 
Borland declarou sua intenção de referir à linguagem como “a linguagem Delphi”. As 
linguagens de programação mais modernas fornecem suporte para programação orientada à 
objetos (POO). As linguagens POO baseiam-se em três conceitos fundamentais: o 
encapsulamento (em geral implementado com as classes), a herança e o polimorfismo ou 
ligação tardia (late binding). 
 
 
 
14 
“A Sintaxe da linguagem Pascal é bastante prolixa e mais legível do que, por 
exemplo, a linguagem C ”.(CANTÚ, 2003). Sua extensão orientada à objetos segue a mesma 
estratégia, apresentando o mesmo poder da geração mais recente de linguagens POO. 
 
2.1.4. O Delphi e seu IDE 
 
De acordo com as definições de Cantú em seu livro “Dominando o Delphi 7: a 
bíblia”, em uma ferramenta de programação como o Delphi, o papel do IDE (ambiente 
integrado de desenvolvimento), é muitas vezes, ainda mais importante do que a linguagem de 
programação. O Delphi fornece recursos visuais e não visuais através de sua IDE, ao 
trabalhar com desenvolvimento visual, o tempo gasto é dividido em duas partes diferentes do 
aplicativo: nos Projetistas e no Editor de Códigos. 
Os projetistas permitem que você trabalhe com componentes à nível visual 
(quando incluímos um botão em um formulário), e nível não visual (quando criamos uma 
estrutura de acesso à bancos de dados através de dataset´s e data modules). 
O editor de códigos é o local onde escrevemos o código. O modo mais óbvio de 
escrever códigos em um ambiente visual, é responder aos eventos, iniciando com aqueles 
ligados à operações executadas pelos usuários do programa. 
Cantu, salienta que à medida que os programadores conhecem melhor o Dephi, 
eles passam a escrever principalmente códigos de manipulação de eventos e, em seguida 
passam a escrever suas próprias classes e componentes. 
“Object Inspector”
Propriedades dos Componentes
Editor de Código
Formulário Padrão
Componentes
“Object TreeView”
Organiza os componentes utilizados
no projeto em árvore.
 
FIGURA 2.1 – INTERFACE DE DESENVOLVIMENTO DO DELPHI 7 (IDE) 
 
 
 
15 
2.1.5. Modelo Lógico Relacional 
 
De acordo com Codd (Codd, 1985) criador da abordagem relacional, usamos o 
modelo lógico de dados relacional para realizarmos o projeto lógico do BD, considerando que 
as informações contidas em uma base de dados, podem ser consideradas como relações 
matemáticas e que estão representadas de maneira uniforme através do uso de tabelas 
bidimensionais. Este princípio coloca os dados dirigidos para estruturas mais simples de 
armazenamento, que são as tabelas. 
O modelo relacional apresenta conceitos para representação dos dados do BD e 
apresenta conceitos de operações que podem ser realizadas sobre os dados. Esses conceitos 
são baseados em um formalismo matemático (álgebra relacional). 
No modelo relacional os dados do BD são representados como relações (tabelas). 
Cada relação possui um nome e um esquema, que é um conjunto de atributos usados para 
descrever a relação. Cada atributo possui um nome. Uma tupla (linha da tabela) é um 
conjunto de valores relacionados, um valor para cada atributo (coluna da tabela) do esquema 
da relação. Uma tupla é uma instância da relação. Cada atributo possui um domínio, que é o 
conjunto de valores válidos para aquele atributo. 
 
2.1.6. Sistema Gerenciador de Bancos de Dados Relacional (SGDBR) 
 
Segundo definição de Codd, criador do modelo Lógico Relacional, um banco de 
dados relacional é um conceito abstrato que define maneiras de armazenar, manipular e 
recuperar dados estruturados unicamente em formas de tabelas, constituindo assim um Banco 
de Dados. 
O termo também é aplicado aos próprios dados, quando organizados dessa forma 
ou um programa de computador que implementa abstração. Codd publicou em 1985 um artigo 
que define as 12 regras para que um Sistema Gerenciador de Banco de Dados fosse 
considerado relacional. 
A arquitetura de um banco de dados relacional pode ser descrita de maneira 
informal ou formal. Na descrição informal estamos preocupados com aspectos práticos da 
utilização e usamos os termos tabela, linha e coluna. Na descrição formal estamos 
preocupados com a semântica formal do modelo e usamos termos como relação(tabela), 
tupla(linha) e atributo(coluna). 
 
 
 
16 
2.1.6.1. Regras de Definição de um SGDBR 
 
Segue abaixo as 12 regras definidas por Codd, para que um SGDB fosse 
considerado relacional. 
 
• 1ª Regra – Regra Fundamental: Um SGDB relacional deve gerenciar seus 
dados usando apenas suas capacidades relacionais. 
 
• 2ª Regra – Regra da Informação: Toda informação deve ser representada 
de uma única forma, como os dados em uma tabela. 
 
• 3ª Regra – Regra da Garantia de acesso: Todo dado pode ser acessado 
logicamente usando o nome da tabela, o valor da chave primária da linha e 
o nome da coluna. 
 
• 4ª Regra – Tratamento Sistemático de Valores Nulos: Os valores nulos 
existem, de forma a representar dados não existentes de forma sistemática 
e independente do tipo de dados. 
 
• 5ª Regra – Catálogo Dinâmico on-line baseado no modelo relacional: A 
descrição do banco de dados é representada no nível lógico como dados 
ordinários(isso é, em tabelas), permitindo que usuários autorizados 
apliquem as mesmas forma de manipular dados aplicada aos dados 
comuns ao consultá-las. 
 
• 6ª Regra – Da sub-linguagem compreensiva: Um sistema relacional pode 
suportar várias linguagens e formas de uso, porém deve possuir ao menos 
uma linguagem com sintaxe bem definida e expressa por cadeia de 
caracteres e com habilidade de apoiar a definição de dados, a definição de 
visões, a manipulação de dados, as restrições de integração, a autorização 
e a fronteira de transações. 
 
 
 
 
 
17 
• 7ª Regra – Da atualização de visões: Toda visão que for teoricamente 
atualizável será também atualizável pelo sistema. 
 
• 8ª Regra – Inserção, atualização e eliminação de alto nível: A capacidade 
de manipular a relação base ou relações derivadas como um operador 
único não se aplica apenas a recuperação de dados, mas também a 
inserção, alteração e eliminação de dados. 
 
• 9ª Regra – Independência dos dados físicos: Programas de aplicação ou 
atividades de terminal permanecem logicamente inalteradas quaisquer que 
sejam as modificações na representação de armazenagem ou métodos de 
acesso internos. Independência lógica de dados :Programas de aplicação 
ou atividades de terminal permanecem logicamente inalteradas quaisquer 
que sejam as mudanças de informação que permitam teoricamente a não 
alteração das tabelas base. 
 
• 10ª Regra – Independência de integridade: As relações de integridade 
específicas de um banco de dados relacional específica devem ser 
definidas em uma sub-linguagem de dados e armazenadas no catálogo (e 
não em programas). 
 
• 11ª Regra – Independência de distribuição: A linguagem de manipulação 
de dados deve possibilitar que as aplicações permaneçam inalteradas 
estejam os dados centralizados ou distribuídos fisicamente. 
 
• 12ªRegra – Da não-subversão: Se o sistema relacional possui uma 
linguagem de baixo nível (um registro por vez), não deve ser possível 
subverter ou ignorar as regras de integridade e restrições definidas no alto 
nível (muitos registros por vez). 
 
 
 
 
 
 
 
18 
2.1.6.2. Registros ou Tuplas 
 
De acordo com Codd, cada linha formada por uma lista ordenada de colunas 
representa um registro, ou tupla. Os registros não precisam conter informações em todas as 
colunas, podendo assumir valores nulos quando assim se fizer necessário. Resumidamente, 
um registro é uma instância de uma tabela, ou entidade. 
 
2.1.6.3. Chaves 
 
As tabelas relacionam-se umas as outras através de chaves. Uma chave é um 
conjunto de um ou mais atributos que determinam a unicidade de cada registro. 
Por exemplo, se um banco de dados tem como chaves Código do Produto e ID 
Sistema, sempre que acontecer uma inserção de dados, o sistema de gerenciamento de banco 
de dados irá fazer uma consulta para identificar se o registro já não se encontraria gravado na 
tabela. Neste caso, um novo registro não será criado, resultando esta operação apenas da 
alteração do registro existente. A unicidade dos registros, determinada por sua chave, também 
é fundamental para a criação dos índices. 
Temos dois tipos de chaves: 
 
• Chave primária: (PK - Primary Key) é a chave que identifica cada 
registro dando-lhe unicidade. A chave primária nunca se repetirá. 
 
• Chave Estrangeira: (FK - Foreign Key) é a chave formada através de um 
relacionamento com a chave primária de outra tabela. Define um 
relacionamento entre as tabelas e podem ocorrer repetidas vezes. Caso a 
chave primária seja composta na origem, a chave estrangeira também o 
será. 
 
2.1.6.4. Stored Procedure 
 
Segundo o Wikikpédia, um procedimento armazenado ou Stored Procedure é uma 
coleção de comandos em SQL para gerenciamento de Banco de dados. Encapsula tarefas 
repetitivas, aceita parâmetros de entrada e retorna um valor de status (para indicar aceitação 
 
 
 
19 
ou falha na execução). O procedimento armazenado pode reduzir o tráfego na rede, melhorar 
a performance, criar mecanismos de segurança, etc. 
 
2.1.6.5. Domains 
 
Utilizamos domais ou domínios para definirmos parâmetros de restrições à um 
dado atributo de uma tabela, validação de informação, etc. É definida pelo usuário, e 
consideramos um domínio como sendo um tipo de dado inexistente no banco de dados. 
 
2.1.6.6. Generator 
 
É usado para simular o campo auto-incremento dos campos numéricos das tabelas 
evitando chaves duplicadas. Seu valor inicial é 0 (zero), mas é atualizado toda vez em que 
ocorre uma chamada da função para incrementar ou decrementar. 
 
2.1.6.7. MetaDados ou Meta Informação 
 
Segundo o MTD-BR (Padrão Brasileiro de Metadados para Teses e Dissertações), 
Metadados são dados capazes de descrever outros dados, ou seja, dizer do que se tratam, dar 
um significado real e plausível a um arquivo de dados, são a representação de um objeto 
digital. Basicamente, poderíamos caracterizar metadados como a estrutura do banco de dados. 
 
2.1.7. A Linguagem de Programação SQL 
 
SQL é uma linguagem padronizada para a definição e manipulação de bancos de 
dados relacionais. Tipicamente, um SGBD oferece um interpretador SQL que permite isolar a 
aplicação dos detalhes de armazenamento dos dados. Se o projetista da aplicação tiver o 
cuidado de usar apenas as construções padronizadas de SQL, ele poderá desenvolver a 
aplicação sem se preocupar com o produto SGBD que estará sendo utilizado depois. 
(RICARTE, 2002). 
SQL pode ser utilizado diretamente pelo usuário, quando o SGBD oferece um 
interpretador SQL interativo, ou através de comandos embutidos em uma aplicação 
desenvolvida em uma linguagem de programação. No caso do SimpleAdmin foi utilizado a 
linguagem de programação Delphi, e a interação da aplicação Delphi com o banco se dará por 
 
 
 
20 
meio dos componentes de acesso nativos da palheta IBX. SQL pode ser utilizado diretamente 
pelo usuário, quando o SGBD oferece um interpretador SQL interativo, ou através de 
comandos embutidos em uma aplicação desenvolvida em uma linguagem de programação. 
No desenvolvimento do SimpleAdmin a interação com o banco de dados é feita 
utilizando componentes nativos da linguagem Delphi. A SQL pode ser definida em 3 
componentes integrantes da linguagem que são: 
• Uma linguagem de definição dos dados (DDL), usados para definir e 
revisar a estrutura de um determinado banco relacional; 
• Uma linguagem de controle de dados (DCL), para especificar mecanismos 
de segurança e integridade referencial dos dados; 
• Uma linguagem de manipulação dos dados (DML), usados para ler e 
escrever dados. 
 
2.1.7.1. Comandos para definição de Relações (DDL) 
 
Uma das necessidades de uma aplicação que irá armazenar seus dados em um 
sistema de banco de dados relacional é criar uma identidade para o conjunto de tabelas de sua 
aplicação.(Ricarte, 2002). Esse mecanismo não é padronizado em SQL, podendo variar de 
fornecedor a fornecedor de banco de dados. 
 
• Comando CREATE TABLE: Cria uma nova tabela com seus campos e 
define as restrições de campo. Ex.: “CREATE TABLE 
ABREFECHACAIXA( CODIGO INTEGER NOT NULL, 
DATAABERTURA DATE, DATAFECHA DATE, CONSTRAINT 
PRIMARY KEY (CODIGO))”. Com a execução desse comando será criada 
uma tabela com o nome de ABREFECHACAIXA e com seus respectivos 
campos. 
 
• Comando ALTER TABLE: Altera as definições de campos e restrições. 
Ex.: “ALTER TABLE ABREFECHACAIXA (ADD SITUACAO 
VARCHAR(30))”. Com essa instrução será inserido mais um campo na 
tabela, denominado situação do tipo varchar com limite de 30 caracteres. 
 
 
 
 
21 
• Comando CREATE INDEX: Cria um novo índice em uma tabela já 
existente. Ex.: “CREATE DESC INDEX CODIGO ON 
DATAABERTURA(ABREFECHACAIXA)”, especificamos através desse 
código que o campo DATAABERTURA pertencente a tabela 
ABREFECHACAIXA, será um índice identificador. 
 
• Comando DROP: Exclui uma tabela existente de um banco de dados ou 
um índice existente de uma tabela, e podemos excluir quais forem as 
funções existentes no banco, tais como, StoredProcedures, Triggers, 
Domains, Databases, etc. Ex.: “DROP TABLE ABREFECHACAIXA” , 
com esse comando excluímos a tabela ABREFECHACAIXA do banco. 
 
2.1.7.2. Comandos para controle de dados e mecanismos de segurança (DCL) 
 
• Comando GRANT: É o comando responsável por determinar quais 
usuários ou grupo de usuários podem ou não fazer nas tabelas do banco, de 
acordo com o tipo de permissão dada aos usuários. Ex.: “GRANT ALL ON 
TAB_FORNECEDORES TO RODRIGO”, definimos o nível de acesso ao usuário 
Rodrigo, na qual terá acesso completo na tabela fornecedores. 
 
• Comando REVOKE: É responsável pelo processo inverso ao GRANT, 
isto é, revogar os direitos dos usuários. Ex.: “REVOKE 
SELECT,INSERT,UPDATE,DELETE ON TAB_FORNECEDORES TO 
PUBLIC”, portanto houve uma redefinição em relação à quais usuários 
poderão acessar a tabela fornecedores. 
 
2.1.7.3. Comandos para manipulação dos Dados (DML) 
 
De acordo com definições de Roberto em sua apostila “Banco de Dados II – 
2006”, a operação select é utilizada para selecionar um subconjunto de tuplas de uma relação, 
sendo que estas tuplas devem satisfazer uma condição de seleção. A forma geral de uma 
operação select é: 
σ <condição de seleção> ( <nome da relação> ). 
 
 
 
22 
• Comando SELECT: permite a seleção de registros e atributos em uma ou 
mais tabelas. A forma básica para o uso do comando select é: 
SELECT <lista de atributos> FROM <lista de tabelas> WHERE 
<condições>; 
• Comando INSERT: permite inserir registros em um banco de dados, 
enviando a requisição ao SGDBR. A forma básica para o uso do comando 
insert é: 
INSERT INTO <tabela> [<campos>] [VALUES <valores>] 
 
• Comando UPDATE: permite atualizar alterações ocorridas nos dados 
existentes nas tabelas do banco. A forma básica para a utilização do 
comando update é: 
UPDATE<tabela> SET <campo> = <expressão> [WHERE 
<condição>]; 
 
• Comando DELETE: permite a exclusão de informações contidas nas 
tabelas do banco. A forma básica de utilização do comando delete é: 
DELETE FROM <tabela> [WHERE <condição>]; 
 
Devemos notar que a linguagem SQL consegue implementar estas soluções, 
somente pelo fato de estar baseada em Banco de Dados, que garantem por si mesmo a 
integridade das relações existentes entre as tabelas e seus índices. 
 
2.1.8. Firebird 
 
O Firebird é um poderoso banco de dados relacional que é compatível com SQL-
ANSI-92, e foi desenvolvido para ser um banco de dados independente de plataformas e de 
sistemas operacionais. 
 Este banco de dados, dispensa maiores estruturas dentro da empresa, ( DBA / 
Preparação ), onde basta instalar o software e usá-lo, sem a interferência freqüente de 
profissionais, especializados na manutenção do banco de dados de produção. 
 Acompanhando, isso tudo ele ainda dispensa o uso de super-servidores, usando 
pouco espaço em disco para sua instalação e utilizando pouca memória em situações normais 
de uso. Por isso a plataforma necessária para a sua instalação e utilização pode ser reduzida 
 
 
 
23 
diminuindo consideravelmente os custos do projeto. Outra grande vantagem do Firebird é que 
ele é múlti-plataforma, ou seja funciona em vários Sistemas Operacionais, 
 Os comandos da série DML (Data Manipulation Language – Manipulação de 
Dados Declarados), destinados a consultas, inserções, exclusões e alterações em um ou mais 
registros de uma ou mais tabelas podem ser feitas de maneira simultânea. Como exemplo de 
comandos da classe DML temos os comandos Select, Insert, UpDate, Delete, Commit e 
Rollback. 
 
2.1.8.1. Transações no Firebird 
 
Transações são isolamentos no Banco de Dados, desta forma, ”protegemos” os 
dados envolvidos na transação de algum erro ocorrido no processamento dessa transação. Isto 
é, sempre que iniciou uma transação, é garantido que os dados envolvidos na mesma, serão, 
ou gravados e ou cancelados, isto serve para todos os dados envolvidos na transação. 
Todas as funções do firebird como consultas, inserções, alterações, exclusões, 
enfim, qualquer acesso ao banco de dados, o firebird inicia uma nova transação para cada uma 
delas, garantindo assim a concorrência dos dados e a consistência da base de dados. 
Sob a abordagem de Cantu, o controle de transação do Firebird, consiste em 
identificar e discernir cada conexão ativa, que faz requisições ao banco, tornando-o um banco 
de dados bastante atrativo e robusto. 
 
2.1.8.2. Snapshot 
 
Fornece a visão atual dos dados do Banco de Dados. Este é o isolamento padrão 
do Firebird. Isto é, outras transações, incluem, alteram, excluem dados, mas, esta transação, 
não os enxergará, até que seja iniciada outra transação, e aí teremos acesso a o que realmente 
existe no Banco de Dados. Este isolamento, é mais usado para geração de Relatórios e 
Processamentos. 
 
2.1.8.3. Read Commited 
 
Permite que a transação enxergue todos os dados que foram “commitados” por 
outras transações. Isto é, outras transações estão incluindo dados, e a transação que estiver 
com está configuração, terá acesso a todos os dados atualizados. É o nível de transação mais 
 
 
 
24 
utilizado, pois, é usado para sistemas Multi-Usuários, Multi-Empresas e Sistemas para 
Internet. 
 
2.1.8.4. Comandos e Funções utilizados no Firebird 
 
A seguir serão listados os principais comandos e funções SQL do Firebird, essas 
podendo ser introduzidas no SimpleAdmin dependendo da situação do banco cadastrado e 
com o nível de privilégios definidos no banco. 
 
• ALTER DATABASE: Adiciona arquivos secundários ao Banco de 
Dados. Isso significa que poderemos ter um banco de Dados com vários 
arquivos dentro do mesmo GDB. Para a alteração da Base de Dados, o 
usuário SYSDBA, precisa ter acesso exclusivo ao Banco de Dados 
Firebird. Este comando, auxilia na repartição do Banco, deixando em 
algumas vezes o acesso aos Dados mais rápido. 
 
• ALTER DOMAIN : Altera a definição de um domínio que já tenha sido 
criado. Pode-se alterar qualquer elemento de domínio, exceto os domínios 
de NOT NULL e a troca do tipo de Dado. Para redefinir o tipo de domínio 
e ou alterar o NOT NULL, deve apagar o domínio e criá-lo novamente. 
 
• ALTER EXCEPTION: Altera a mensagem associada a uma exceção; caso 
ocorra alguma. 
 
• ALTER INDEX: Torna um índice ativo e ou inativo. Este comando está 
relacionado diretamente na performance do índice no Banco de Dados. Em 
certos momentos, o índice no Firebird pode ficar desbalanceado, desta 
forma, este comando recria o índice do Firebird. 
 
• ALTER TABLE: Altera a estrutura de uma tabela e ou a integridade da 
mesma. 
 
 
 
 
25 
• ALTER TRIGGER: Altera a definição de uma Trigger. Caso algum 
argumento for omitido, é assumido o valor definido no CREATE 
TRIGGER, ou no ALTER TRIGGER. 
 
• AVG: Retorna a média de valores de uma coluna da tabela. 
 
• CAST (): Usado em colunas, onde há a necessidade de utilizar a 
conversão de tipo de dados para outros formatos. 
 
• COMMIT: Efetiva as alterações e transações permanentemente no banco 
de dados. 
 
• COUNT: Retorna a quantidade de registros para uma condição em um 
select. 
 
• CREATE DATABASE: Cria um novo banco de dados “.GDB”. 
 
• CREATE DOMAIN: Cria uma definição de um “novo tipo de dado”. 
Onde pode ser feito também, checagem de valor, isto é, regras para o dado 
ser gravado nesse “novo tipo de dado”. 
 
• CREATE EXCEPTION: Cria uma mensagem de erro, armazenado no 
servidor, e só pode ser usado em StoredProcedures e ou Triggers. 
 
• CREATE GENERATOR: Cria um Generator de números inteiros e 
seqüenciais. Um Generator em conjunto com um Triggere ou 
StoredProcedures é usado para simular o campo auto-incremento, servindo 
para evitar chaves duplicadas em campos numéricos. 
 
• CREATE INDEX: Cria um índice para uma ou mais colunas especificas 
da tabela. O índice está ligado diretamente a performance do banco de 
dados. 
 
 
 
 
26 
• CREATE PROCEDURE: Cria uma Stored Procedure “SP”, e, define 
seus parâmetros de entrada/saída e o corpo da procedure. Uma “SP” é 
escrita em linguagem Firebird, e armazenada no próprio banco de dados 
para posteriores chamadas da aplicação. 
 
• CREATE TABLE: Cria uma nova tabela no banco de dados Firebird. 
 
• CREATE TRIGGER: Cria um Trigger (Gatilho) para a tabela 
espeificada. Relembrando que trigger é um gatilho disparado após alguma 
alteração ocorrida na tabela, isto é, podendo existir trigger de insert, delete, 
update e delete. 
 
• DROP DATABASE: Exclui o banco de dados “.GDB” Firebird, onde o 
mesmo só podendo ser excluído pelo seu criador ou pelo usuário 
SYSDBA do banco de dados. 
 
• DROP DOMAIN: Exclui um domínio previamente criado no banco de 
dados Firebird. Se o domínio estiver em uso, será necessário excluir o 
campo da tabela e posteriormente excluir o domínio. 
 
• DROP EXCEPTION: Exclui uma exceção previamente criada no banco 
de dados. Se a exceção estiver sendo utilizada por alguma Stored 
Procedure e/ou Trigger a exclusão falhará. Desta forma precisamos retirar 
a Exception da Stored Procedure e/ou Trigger, e executar novamente o 
DROP EXCEPTION. 
 
• DROP INDEX: Exclui o índice definido pelo usuário do banco de dados 
Firebird. 
 
• DROP PROCEDURE: Exclui uma Stored Procedure criado pelo usuário 
do banco de dados. As Stored Procedures referenciadas por Triggers não 
podem ser excluídas. 
 
 
 
 
27 
• DROP TABLE: Apaga uma tabela do banco de dados, índices e trigger´s 
referenciados pela tabela. 
 
• DROP TRIGGER: Exclui uma Trigger do banco de dados. 
 
• EXECUTE PROCEDURE: Executa uma Stored Procedure não seletável, 
ou seja não compatível com a instrução DML Select. 
 
• INSERT: Comando responsável para adicionar um ou mais registros na 
tabela de Banco de Dados Firebird. Os campos que forem omitidos 
recebem valores NULOS “NULL”. 
 
• ROLLBACK: Desfaz as mudançasocorridas até o exato momento no 
Banco de Dados Firebird, sem que o comando COMMIT tenha sido 
executado. Este comando e o Commit fecham a transação aberta pela 
aplicação e ou ferramenta de gerenciamento as tabelas. 
 
 
• UPDATE: Comando responsável pela atualização da tabela no Banco de 
Dados Firebird. Update trabalha de forma semelhante ao DELETE, é 
claro, com sua enorme diferença, se não passarmos a cláusula WHERE, 
toda a coluna da tabela será atualizada. 
 
2.1.8.5. Tipos de dados do Firebird 
 
O Firebird, suporta a maioria dos tipos de Dados do SQL, apenas não tem como 
tipo de dado, o tipo Boolean. Mas, isto não é uma falha do Firebird, outro SGDB´s também 
não tem este tipo de dado. Apesar de não ter este tipo de dado, podemos criar o nosso “tipo 
boolean” através de DOMAINS. 
 
• BLOB: O tipo de dado BLOB, tem o tamanho variável, isto é, não 
sabemos na hora da criação do campo BLOB qual será o seu tamanho 
realmente, mas, o limite do campo Blob que está na documentação do 
Firebird, é de 64k por segmento. 
 
 
 
28 
 
• CHAR(N): O tipo de dado CHAR, tem o seu tamanho definido na hora da 
criação da tabela. Seu tamanho máximo é de 32767, 32k. Este tipo tem o 
seu tamanho fixo. 
 
• VARCHAR(N): O tipo de dado VARCHAR, tem o seu tamanho definido 
na hora da criação da tabela. Seu tamanho máximo é de 32767, 32k. Este 
tipo tem o seu tamanho variado na tabela. Isto é, se você criar uma coluna 
de 45 caracteres, mas, a coluna tenha apenas 20 caracteres gravados, o 
restante, os 25 caracteres são descartados. 
 
• DATE: O tipo de Dado DATE, no DIALECT 3, armazena a Data, e seu 
tamanho é de 32 bits inteiros longos. 
 
• TIME: O tipo de dado TIME, armazena a hora, e seu tamanho é de 32 
bits inteiros longos. 
 
• TIMESTAMP: O tipo de dado TIMESTAMP, armazena a Data e a hora 
ao mesmo tempo, e seu tamanho é de 32 bits inteiros longos. 
 
• DECIMAL: O tipo de dado DECIMAL, armazena dígitos a serem 
gravados na precisão especificada na criação da tabela. 
 
• NUMERIC: O tipo de dado NUMERIC, armazena dígitos a serem 
gravados com precisão especificada na criação da tabela. 
 
• SMALLINT: O tipo de dado SMALLINT, armazena dígitos a serem 
gravados, mas, com o limite de : -32768 a 32767. Serve para armazenar 
dados numéricos pequenos. 
 
• INTEGER: O tipo de dado INTEGER, armazena dígitos a serem 
gravados, mas, diferente do SMALLINT, não existe um limite 
aparentemente, este tipo é de 32 bits, tem a escala de valores em : 
2.147.483.648 (negativo) à 2.147.483.648 (positivo). 
 
 
 
29 
• FLOAT: O tipo de Dado FLOAT, armazena dígitos a serem gravados, 
mas, com precisão simples de 7 dígitos. 
 
• DOUBLE PRECISION: Este é o tipo de campo no qual é recomendado 
para uso monetário/valores no Firebird. Sua precisão é de 64 bits. 
 
2.1.9. Acesso Nativo 
 
Acesso nativo significa que não há componentes de acesso que acessam a base de 
dados diretamente, sem que haja necessidade de uso de conexões acessórias. Neste meio, não 
existe nada “BDE/ODBC/OLE DB” e ou outro driver. Isto é, e a aplicação e a base de dados, 
nada mais envolve na conversação dos dados. E isto é feito através de Funções da API do 
Firebird.. 
 
2.1.10. Componentes de Acesso IBX 
 
Está é a palheta responsável pela comunicação de dados entre o aplicativo e o 
Banco de Dados Firebird. Nela existem 12 componentes, mas não houve a necessidade de se 
implementar o software utilizando todos os componentes, portanto apresentaremos apenas os 
componentes utilizados. 
 
 
 
30 
 
FIGURA 2.2 – PALHETA DE COMPONENTES IBX (INTERBASE) 
 
2.1.5.1 Componente IBDatabase 
 
 É o componente responsável pela conexão do Sistema ao Banco de dados 
Firebird. 
 
Propriedades: 
Connected : Ativa ou desativa a conexão com a base de Dados. 
DataBaseName : Nome do arquivo de Base de Dados do Firebird ".GDB". 
DefaultTransaction : Especifica qual Transação “IBTransaction”, é ligado automaticamente 
ao IBDataBase. Serve para aplicações onde existe apenas uma transação envolvida em todo o 
sistema. Isto é, para sistemas pequenos, onde o controle de transação não é tão importante 
para o bom funcionamento da aplicação. 
IdleTimer : Especifica quanto tempo o Cliente irá esperar por uma resposta do servidor. Caso 
o tempo tenha se excedido, a conexão será desfeita. 
Palheta de Componentes IBX (Interbase) 
 
 
 
31 
LoginPrompt : Se ativa ou não o pedido de senha quando houver a conexão com o Banco de 
Dados Firebird. 
SQLDialect : Indica qual o Dialeto que será utilizado pela conexão. 
TraceFlags : Indica quais serão as ações monitoradas pelo TIBSQLMonitor. 
 
 
FIGURA 2.3 – PALHETA DE COMPONENTES IBX (INTERBASE) – COMPONENTE IBDATABASE 
 
2.1.5.2 Componente IBTransaction 
 
É o componente responsável pelo controle de transações do sistema. 
 
Propriedades: 
 
Active : Inicia a transação, tem o mesmo efeito do método StartTransaction. 
DefaultAction : Indica a sua transação qual será o método executado quando o parâmetro 
IdleTimer exceder. 
Componente IBDataBase 
 
 
 
32 
DefaultDataBase : Indica a qual conexão a transação pertence. 
Params : Propriedade onde você especifica o tipo de transação, isto é, como a sua transação 
se portará na sua aplicação. 
IdleTimer : Especifica quanto tempo a transação ira esperar para executar a propriedade 
DefaultAction. 
 
 
FIGURA 2.4 – PALHETA DE COMPONENTES IBX (INTERBASE) – COMPONENTE IBTRANSACTION 
 
2.1.5.3 Componente IBQuery 
 
Faz a conexão SQL com a Base de Dados Firebird e repassa ao Firebird a 
instrução na qual será executada. 
 
Propriedades: 
BufferChunks : Número de Registros no Buffer. 
DataBase : Onde você especifica a qual Data Base “IBDataBase” a Query está ligada. 
Componente IbTransaction 
 
 
 
33 
Transaction : Onde você especifica qual a Transação “IBTransaction” a Query está ligada. 
Unidirectional* : Especifica se a navegação será Unidirecional, isto é, em um sentido apenas. 
E este sentido é somente para navegação para os próximos registros, como next (próximo) e 
prior (anterior). 
 
 
FIGURA 2.5 – PALHETA DE COMPONENTES IBX (INTERBASE) – COMPONENTE IBQUERY 
 
2.1.5.4 Componente IBUpdateSQL 
 
Permite definir instruções DML para cada método Insert, Edit e Delete. 
IBUpdateSQL + IBQuery representa toda a funcionalidade SQL de manipulação de Dados. 
 
Propriedades: 
InsertSQL - Instrução SQL de Inserção de Dados. É executado quando for chamado o 
método Append/Insert. 
Componente IBQuery 
 
 
 
34 
ModifySQL - Instrução SQL de alteração de Dados. É executada quando a tabela for 
colocada em modo de Edição 
DeleteSQL - Instrução SQL para deletar Dados. É executada quando o método Delete for 
chamado. 
RefreshSQL - Instrução SQL para executar o Refresh. É executada quando for chamado o 
método Refresh. 
 
 
FIGURA 2.6 – PALHETA DE COMPONENTES IBX (INTERBASE) – COMPONENTE IBUPDATESQL 
 
2.1.10.1. Componente IBBackupService e IBRestoreService 
 
Componentes responsáveis por efetuar o backup e a restauração do banco de 
dados firebird, através de parâmetros definidos pelo usuário. 
 
FIGURA 2.6 – PALHETA DE COMPONENTES IBX – IBRESTORESERVICE E IBBACKUPSERVICE 
Componente IBUpdateSQL 
 
 
 
35 
2.1.11. Componentes de acesso e manipulação Data Access 
 
É a palheta do Delphi que provê recursos para a manipulação dos dados em 
memória, antes que ocorra alterações diretas no banco. 
 
 
FIGURA 2.6 – PALHETA DE COMPONENTES DATA ACCESS 
 
2.1.11.1. Componente ClientDataAcces 
 
É o componente responsável por prover acesso à informações contidas no banco 
de dados. Através desse componente é possível realizar a conexão entre os vários 
componentes de acesso ao banco. 
Palheta de Componentes Data Access 
 
 
 
36 
 
FIGURA 2.6 – PALHETA DE COMPONENTES DATA ACCESS – COMPONENTE DATAACCESS 
 
2.1.11.2. Componente ClientDataSet 
 
É o componente responsável por montar a estrutura existente no banco Firebird, 
em uma estrutura em memória, onde a manipulação de inserção,alteração, exclusão não são 
feitas diretamente no banco de dados Firebird. Garantindo assim uma arquitetura mais 
confiável e com um maior controle de redundância. 
Utilizando esse componente, as requisições ao banco de dados são menore e as 
transações ficam “abertas” por menos tempo, impedindo que outros usuários tenham acesso À 
dados obsoletos. 
Componente DataAccess 
 
 
 
37 
 
FIGURA 2.6 – PALHETA DE COMPONENTES DATA ACCESS – COMPONENTE CLIENTDATASET 
 
2.1.11.3. Componente DataSetProvider 
 
Utilizamos o componente DataSetProvider para gerar as instruções SQL, para 
aplicar cada modificação no banco de dados firebird, ou seja, é responsável por estar enviando 
ao banco as alterações ocorridas nos dados contidos em memória através de um clientdataset. 
Componente ClientDataSet 
 
 
 
38 
 
FIGURA 2.6 – PALHETA DE COMPONENTES DATA ACCESS – COMPONENTE DATASETPROVIDER 
 
2.1.12. Interface Homem Máquina e Ergonomia Computacional 
 
De acordo com o LABIUTIL (Laboratório de Usabilidade da Informática da 
Universidade Federal de Santa Catarina), onde ressalta a importância da ergonomia 
computacional e usabilidade através de métodos e aplicações pré definidos, entre eles 
Presteza, Legibilidade, Concisão, Ações Mínimas, Flexibilidade, Experiência dos Usuários, 
etc. Com base nesses aspectos, foi desenvolvida uma padronização dos aspectos ergonômicos 
e usuais do projeto. 
 
2.1.13. Critérios Ergonômicos 
 
Com base nas definições do estudo realizado por Scapin, visando a organização 
dos conhecimentos sobre ergonomia de interfaces homem-computador, de modo a torná-los 
facilmente disponíveis, tanto para especialistas como para não especialistas nessa disciplina. 
Componente DataSetProvider 
 
 
 
39 
O sistema de critérios definido por Scapin resulta desse esforço e visa facilitar a recuperação 
de conhecimento ergonômico. 
Através de experimentos variados, esse conjunto de critérios está sendo 
continuadamente validado e apurado em suas definições. A lista atual de critérios foi definida 
em 1993 por Dominique Scapin e Christian Bastien. 
Os critérios principais são os seguintes: Condução, Carga de Trabalho, Controle 
Explícito, Adaptabilidade, Gestão de Erros, Consistência, Significado dos Códigos e 
Compatibilidade. 
 
• Condução: A condução refere-se aos meios disponíveis para aconselhar, 
orientar, informar e conduzir o usuário na interação com o computador 
(mensagens, alarmes, rótulos, etc.). 
 
• Carga de Trabalho: O critério Carga de Trabalho diz respeito a todos os 
elementos da interface que têm um papel importante na redução da carga 
cognitiva e perceptiva do usuário e no aumento da eficiência do diálogo. 
 
• Controle Explicito: O critério Controle Explícito diz respeito tanto ao 
processamento explícito pelo sistema das ações do usuário, quanto ao controle 
que os usuários têm sobre o processamento de suas ações pelo sistema. 
 
• Adaptabilidade: A adaptabilidade de um sistema diz respeito a sua capacidade 
de reagir conforme o contexto e conforme as necessidades e preferências do 
usuário. 
 
• Gestão de Erros: A gestão de erros diz respeito a todos os mecanismos que 
permitem evitar ou reduzir a ocorrência de erros e, quando eles ocorrem, que 
favoreçam sua correção. Os erros são aqui considerados como entrada de dados 
incorretos, entradas com formatos inadequados, entradas de comandos com 
sintaxes incorretas, etc. 
 
• Consistência: O critério homogeneidade/coerência/consistência refere-se à 
forma na qual as escolhas na concepção da interface (códigos, denominações, 
 
 
 
40 
formatos, procedimentos, etc.) são conservadas idênticas, em contextos 
idênticos, e diferentes, em contextos diferentes. 
 
• Significado dos Códigos: O critério significado dos códigos e denominações 
diz respeito à adequação entre o objeto ou a informação apresentada ou pedida e 
sua referência. Códigos e denominações significativas possuem uma forte 
relação semântica com seu referente. Termos pouco expressivos para o usuário 
podem ocasionar problemas de condução, podendo levá-lo a selecionar uma 
opção errada. 
 
• Compatibilidade: O critério compatibilidade refere-se ao acordo que possa 
existir entre as características do usuário (memória, percepção, hábitos, 
competências, idade, expectativas, etc.) e as tarefas, de uma parte, e a 
organização das saídas, das entradas e do diálogo de uma dada aplicação, de 
outra. Ela diz respeito também ao grau de similaridade entre diferentes 
ambientes e aplicações. 
 
2.1.14. Considerações Finais 
 
O desenvolvimento de ferramentas para essa finalidade, não é bastante difundida 
entre a comunidade de desenvolvedores, onde existe uma certa dificuldade em obter materiais 
didáticos que suprem essa necessidade. Porém a indústria de desenvolvimento de softwares no 
Brasil está em um estágio bastante promissor, e não somente o desenvolvimento dessas 
ferramentas, mas de inúmeras outras com finalidades distintas. Portanto, a qualquer 
desenvolvedor que deseje ingressar nesse ramo de atividade, passará por períodos difíceis, 
principalmente na obtenção de materiais didáticos. Com o passar dos tempos, esse cenário 
tende a melhorar juntamente com o avanço tecnológico do país. 
 
 
 
 
 
 
 
 
 
41 
3. Desenvolvimento 
 
O SimpleAdmin foi desenvolvido sob a perspectiva de uma interface bastante 
fácil de se trabalhar, onde não exista a necessidade de abrir vários formulários para a correta 
utilização, na qual o usuário terá total visão do software. 
 
3.1. Implementação do Formulário Principal 
 
Após um estudo elaborado em se tratando de Interfaces, usabilidade e ergonomia 
computacional, o formulário principal do projeto é bastante subjetivo no que tange sua 
utilização por menos experiente que seja o usuário. 
 
 
FIGURA 3.1 – INTERFACE DO FORMULÁRIO PRINCIPAL 
 
Após a confecção do formulário principal, deu-se inicio ao processo de 
desenvolvimento de suas funcionalidades. 
 
 
 
 
42 
3.2. Implementação do formulário Registrar Bancos 
 
Para melhor trabalharmos com os banco de dados, criamos uma interface na qual 
“registramos” os atributos necessários para a conexão com a base de dados. Esses valores 
salvos, correspondem ao path (caminho) em que o banco se encontra no disco rígido ou até 
mesmo remotamente, para isso atribuímos o valor do atributo host, e conseqüentemente o 
nome do banco de dados registrado, será o host (caso seja remoto) concatenado ao path do 
banco. Precisamos definir questões de caracteres especiais, em que o banco trabalhe sem erros 
e com o máximo de performance, através da escolha do “Character Set”, e por fim os 
atributos como Usuário e Senha. 
 
FIGURA 3.2 – INTERFACE DO FORMULÁRIO PARA REGISTRAR OS BANCOS. 
 
 
 
 
 
 
 
 
 
43 
• Código Fonte da Implementação Registrar Bancos 
 
begin 
 frmRegistrarBD := TfrmRegistrarBD.Create(self); 
 try 
 if FrmRegistrarBD.ShowModal = mrOk then 
 begin 
 id := mdBancos.RecordCount + 1; 
 mdBancos.Append; 
 mdBancosid.Value := id; 
 mdBancosnome.Value := FrmRegistrarBD.EditNome.Text; 
 mdBancoshost.Val := FrmRegistrarBD.EditHost.Text; 
 mdBancoscaminho.Value := FrmRegistrarBD.EditFilename.text; 
 mdBancosusuario.Value := FrmRegistrarBD.EditUsuario.Text; 
 mdBancossenha.Value := FrmRegistrarBD.EditSenha.Text; 
 mdBancosset.Value := FrmRegistrarBD.cbCharSet.Text; 
 mdBancos.Post; 
 end; 
 finally 
 FrmRegistrarBD.Free; 
end; 
 
 
3.3. Visualização dos Detalhes do banco 
 
Após o registro do banco de dados, é necessário abri-lo para a visualização de 
todos o tipo de informação na qual o SimpleAdmin se propõe a fazer. Após a definição e 
registro do álias (máscara) é possível visualizar os detalhes pertencentes ao banco registrado, 
onde toda a estrutura do banco será armazenada em uma tabela temporária, onde quaisquer 
alterações serão salvas em memória, para posteriormenteser efetivada a transação no banco 
de dados, efetuando um Commit. 
 
 
 
44 
 
FIGURA 3.3 – INTERFACE DE VISUALIZAÇÃO DOS DETALHES DO BANCO. 
 
• Código Fonte da implementação de visualização dos dados do banco cadastrado 
 
Para as tabelas do banco: 
begin 
 if not IBDatabase.Connected then exit; 
 mdEstrutura.EmptyTable; 
 mdGenerator.EmptyTable; 
 mdIndices.EmptyTable; 
 QueryAux.Close; 
 QueryAux.sql.Text := ''; 
 if cbTabelasInternas.Checked then 
 QueryAux.sql.Text := 'SELECT RDB$RELATION_NAME TABELA FROM 
RDB$RELATIONS ORDER BY 1' else 
 QueryAux.sql.Text := 'SELECT RDB$RELATION_NAME TABELA FROM 
RDB$RELATIONS WHERE RDB$RELATION_ID > 127 ORDER BY 1'; 
 
 
 
45 
 QueryAux.Open; 
 LabelTabelas.Tag := 0; 
 ListTabelas.Items.Clear; 
 while not QueryAux.Eof do 
 begin 
 if (EditFiltro.text = '') or 
(Pos(UpperCase(EditFiltro.text),UpperCase(QueryAux.FieldByName('TABELA').AsStrin
g)) > 0) then 
 begin 
 nometabela := Trim(QueryAux.FieldByName('TABELA').AsString); 
 FItensIdentificador.Add(LowerCase(nometabela) + '==' + LowerCase(nometabela)); 
 ListTabelas.Items.Add( nometabela ); 
 LabelTabelas.Tag := LabelTabelas.Tag + 1; 
 end; 
 QueryAux.Next; 
 end; 
 LabelTabelas.Caption := ' Foram listadas ' + FormatFloat(',0',LabelTabelas.Tag) + ' 
tabelas.'; 
 
 if LabelTabelas.Tag > 0 then 
 begin 
 ListTabelas.ItemIndex := 0; 
 ListTabelasClick(nil); 
 if LabelTabelas.Tag = 1 then 
 AbrirTabelaSelecionada; 
 end; 
end; 
 
 
 
 
 
 
 
 
 
46 
3.3.1. Visualização dos Stored Procedures 
 
Visualização dos procedimentos armazenados existentes no banco de dados, 
sendo possível analisar seu respectivo código metadata. 
 
FIGURA 3.4 – VISUALIZAÇÃO DOS STOREDPROCEDURES 
 
• Código Fonte da implementação de visualização dos Stored Procedures 
 
IBExtract.ExtractObject(eoProcedure,ListStoredProcedures.Items.Strings[ListStoredProce
dures.ItemIndex]); 
CodigoStoredProcedures.Lines.Text := IBExtract.Items.text; 
MemoMetadataGeral.Lines.Text := codigoStoredProcedures.Lines.Text; 
 
 
 
 
 
 
 
 
 
47 
3.3.2. Visualização dos Geradores (Generator) 
 
Interface que provê acesso à todos os geradores existentes no banco de dados 
firebird, no caso, o banco registrado pelo usuário. 
Para edita-lo basta apenas clicar 2x sobre o gerador e alterar o seu respectivo 
valor. 
 
FIGURA 3.5 – VISUALIZAÇÃO DOS GERADORES (GENERATOR) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
48 
3.3.3. Visualização dos Domínios (Domains) 
 
Interface que provê acesso à todos os domínios existentes no banco de dados 
firebird, no caso, o banco registrado pelo usuário. 
 
 
 
FIGURA 3.6 – VISUALIZAÇÃO DOS DOMÍNIOS (DOMAINS) 
 
3.3.4. Visualização das Tabelas 
 
Fácil visualização das tabelas existentes no banco de dados firebird, onde o 
usuário poderá acessar a estrutura, índices e metadados da tabela na qual foi selecionada. 
 
 
 
49 
 
FIGURA 3.7 – VISUALIZAÇÃO DAS TABELAS 
 
3.3.5. Visualização SQL 
 
Interface na qual provê ao usuário acesso direto as instruções SQL a serem 
executadas no banco de dados firebird, informando também o retorno (os dados), a instrução 
SQL executada, o plan (plano de otimização interna de consultas do firebird) e os erros, caso 
tenha algum. 
 
 
 
50 
 
FIGURA 3.8 – VISUALIZAÇÃO SQL 
 
3.3.6. Execução Backup / Restauração 
 
De maneira rápida e fácil, em alguns segundos é possível efetuar o Backup e 
Restauração. 
 
 
 
51 
 
FIGURA 3.9 – VISUALIZAÇÃO DO BACKUP / RESTAURAÇÃO 
 
 
3.3.7. Alteração de Valores dos Geradores 
 
Para podermos alterar os valores dos campos dos geradores existentes no banco de 
dados, basta-nos clicar 2 x sobre o gerador correspondente e um novo formulário irá abrir, 
com as opções de mudança e efetivação da alteração. 
 
 
 
 
52 
 
FIGURA 3.10 – VISUALIZAÇÃO MANUTENÇÃO INDICES GERADORES 
 
3.3.8. Visualização e Execução de 3 Consultas SQL simultaneamente 
 
Visualização do resultado obtido através das 3 consultas SQL, inseridas no 
SimpleAdmin, retornando os valores correspondentes. 
 
 
 
53 
 
FIGURA 3.11 – VISUALIZAÇÃO DOS RESULTADOS DAS CONSULTAS SQL 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
54 
4. Conclusão 
 
 
Através da realização deste trabalho foi possível concluir a importância dos 
bancos de dados para as aplicações computacionais e a diversidade de recursos existentes em 
um Sistema Gerenciador de Banco de Dados. Sob o ponto de vista de mercado de trabalho, 
percebemos a necessidade de ferramentas e aplicativos desta natureza, tornando-se uma área 
de atuação do Cientista da Computação. Além disso, com as dificuldades encontradas e os 
desafios que foram superados, foi possível perceber o quão é importante o trabalho de 
conclusão de curso para nós, acadêmicos, com relação ao aprendizado e experiências 
adquiridas. 
 
4.1. Dificuldades Encontradas 
 
Dentre as dificuldades encontradas, talvez a mais difícil tenha sido conciliar 
nossas atividades acadêmicas de final de curso com a pesquisa e o desenvolvimento do 
projeto. Além disso, percebemos também, a escassez de material bibliográfico sobre este 
assunto. 
 
4.2. Trabalhos Futuros 
 
Para trabalhos futuros, sugerimos o aperfeiçoamento da ferramenta, assim como, o 
desenvolvimento dos recursos avançados, como por exemplo Triggers, Views, Tabelas (novos 
recursos). 
 
4.3. Considerações Pessoais 
 
Todo o aprendizado ocorrido durante a vida acadêmica, foi de extrema 
importância para o aprimoramento intelectual, social e pessoal. Portanto uma série de fatores 
contribuíram para o desenvolvimento do projeto. 
 
 
 
 
 
 
55 
5. Referência Bibliográfica 
 
 
CANTÚ, MARCO. Dominando o Delphi 7: a bíblia. Tradução de Kátia 
Aparecida Roque. Revisão técnica de Álvaro Rodrigues Antunes. São Paulo, SP: Pearson 
Education do Brasil, 2003. 
 
CANTU, CARLOS HENRIQUE. Firebird Essencial. São Paulo, SP: Ciência 
Moderna. 2005. 
 
WIKIPÉDIA. Delphi. Disponível em: <http://pt.wikipedia.org> Acessado em 09 
de Novembro de 2006. 
 
WIKIPÉDIA. Stored Procedure. Disponível em: 
<http://pt.wikipedia.org/wiki/Stored_procedure> Acessado em 15 de Novembro de 2006 
 
 MTD-BR. Metadados ou MetaInformação. Disponível 
em:<http://bdtd2.ibict.br/index.php?option=com_content&task=view&id=82&Itemid=135> 
Acessado em 12 de Novembro de 2006. 
 
ROBERTO, PAULO ROBERTO R.S. Apostila Banco de Dados II – 2006. 
Disponível em: http://www.paulo.varginha.br/bd2006_2.zip> Acessado em 21 de Novembro 
de 2006. 
 
 WIKIPÉDIA. Sistema Gerenciador de Bancos de Dados Relacionais. 
Disponível em: 
<http://pt.wikipedia.org/wiki/Banco_de_dados_relacional#Porque_usar_um_Banco_de_Dado
s_Relacional.3F> Acessado em 09 de Novembro de 2006. 
 
TODD, Bill. . ClientDataset . Disponível em: 
<http://www.activedelphi.com.br/apostilas/cds.pdf > Acessado em 12 de Novembro de 2006. 
 
 
 
 
56 
RODRIGUES, Anderson Haertel. . Apostila Interbase Express IBX . 
Disponível em: <http://www.firebase.com.br/articles/clientdatasetibx.pdf > Acessado em 12 
de Novembro de 2006. 
 
LABIUTIL. Laboratório de Usabilidade da Informática da Universidade Federal 
de Santa Catarina. Usabilidade e Ergonomia Computacional. Disponível em: < 
www.labiutil.inf.ufsc.br/ >; Acessado em 19 de Novembro de 2006. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
57 
6. Anexos 
 
Agradeço primeiramente à Deus, 
por ter me dado condições físicas e psíquicas 
para realizar essa jornada, à minha namorada 
Cristiane na qual fui ausente em vários 
momentos de nossas vidas devido à atividade 
acadêmica, dispersando em mim sua 
tolerância, consentimento, paciência e por 
acreditar nas minhas capacidades. 
Quero agradecer também aos meus 
pais pelo apoio irrestrito que tive durante todo 
o períododo curso, à minha tia Maria Ângela 
P.S.Miyake e o sr. Khimity Miyake por ter me 
dado condições de ingressar e concluir com 
sucesso um curso superior. A minha sogra 
Rosilene e sogro Sebastião (Tião Cruzeiro). 
por ter proporcionado uma base complementar 
e por ter acreditado em meus propósitos. 
Agradeço a todos os funcionários 
do Unis MG, à todo corpo docente, 
principalmente o professor Paulo Roberto 
Rodrigues, que nos propiciou a base para 
desenvolvermos o projeto. 
Por fim agradeço à todos os meus 
amigos que estiveram presentes durante essa 
longa jornada acadêmica. 
 
 Rodrigo S. Rios 
 
 
 
 
 
 
58 
Agradeço primeiramente a DEUS 
por ter me dado condições fisicas e mentais 
para realizar esta tarefa e meu namorado 
Alexandre também pela dedicação, paciência e 
até mesmo tolerância neste período o qual não 
pude participar tanto de suas vidas o quanto 
mereciam. 
Agradeço também a professor 
Paulo Roberto, pela orientação neste trabalho e 
também pelo enriquecimento de informações 
sempre presentes em suas aulas. 
 Agradeço a equipe do Unis-MG : 
Professores,funcionários ,secretarias,etc .Sem 
os quais simplesmente não seria possível a 
conclusão deste trabalho. 
Por fim agradeço também aos meus 
colegas que me ajudaram muito e em especial 
Rodrigo e Tadeu, que contribuíram para a 
realização desse trabalho. 
 
 Joselara S. Verginio 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
59 
Agradeço a Deus pela 
oportunidade de mais esta valiosa 
conquista, com certeza de que foi 
alcançada por ser necessária para 
continuidade de minha caminhada, pois 
sei que Ele não nos dá o que desejamos, 
mas o que necessitamos. À toda equipe 
UNIS MG, professores, diretores e 
funcionários especialmente ao Jean 
Roger, meus sinceros agradecimentos, e 
desculpem-me aqueles os quais não tive 
a oportunidade de conhecê-los 
pessoalmente, mas sei que também 
trabalharam por mim. Aos meus colegas 
que por tantas vezes me auxiliaram, 
nunca os esquecerei. À minha família, e 
em especial ao meu irmão Vicente que 
sempre tem as palavras certas quando 
penso errado. Aos primos Marçal 
Batista, Marcelo Tavares e o sobrinho 
Flávio Baroncelli que são engenheiros 
mecânicos e engenheiros de 
prestatividade, os quais estão sempre 
prontos a ajudarem. Sou grato à minha 
ex-esposa Andréia, por suas lições de 
vida e perseverança, ensinando-me que 
por menor que seja a chance, poderá ser 
o início de um grande projeto. E que as 
pessoas citadas, representem toda a 
humanidade, pois somos parte do 
sistema e as partes só acontecem quando 
sincronizadas. 
Tadeu.