Jump to content
Manimal

Introdução aos Banco de Dados

Recommended Posts

Olá a todos.


Programas são fantásticos e podem fazer inúmeras coisas, mas tem sua limitação em relação à armazenamento permanente de informações.

Ou seja, todas as informações que o programa tenha, são trabalhadas e armazenadas na memória RAM, portanto ao fechar o programa estas informações se perdem!

Para preservar estas informações para uma próxima sessão, precisamos guardá-las em um local mais "seguro".


Este local seguro são os ARQUIVOS, em quaisquer formatos. Para exemplos simples, temos os arquivos TEXTO (.TXT) ou arquivos de INICIALIZAÇÃO (.INI) que são excelentes para armazenar pequenas quantidades de dados. Porém quando trabalhamos com grandes quantidades de informação não só é necessário armazenar como também utilizar ou recuperar estas informações de uma forma lógica e simples.


Mas afinal, qual a diferença entre DADOS e INFORMAÇÕES? Informações são dados ORGANIZADOS!


Para exemplificar, pense numa lista de telefones que vc possua. Todos aqueles nomes e números formam uma pilha de dados. Para procurar algo, vc precisa olhar um por um dos nomes até achar o que vc precisa. E repetir este processo todas as vezes que procura um telefone de alguém. Isto são DADOS. Um monte de dados apenas.

Mas, se vc organizar esta lista em ordem alfabética, por exemplo, vc passa de DADOS a INFORMAÇÃO, porque torna-se muito mais simples de recuperar a informação necessária.


Antigamente, cada linguagem de programação possuía sua própria estrutura de arquivos, com seus métodos próprios de acesso. Desta forma, raramente uma base de dados era acessível por outra aplicação ou linguagem. Daí nasceram os arquivos intermediários de importação/exportação como os arquivos TXT de tamanho fixo (SDF - Standard Data Format) ou os delimitados (CSV - Comma Separated Values) que utilizam vírgulas (ou outro separadores/delimitadores) para separar os campos. Até hoje são muito utilizados para conversar entre bancos de dados e Excel, para citar apenas uma das utilizações.


Vamos mais a fundo. Imaginem apenas uma empresa que desenvolve softwares comerciais. Agora, vamos pegar apenas o cadastro de clientes para fins de entendimento.

Este cadastro precisa de uma definição de campos (ESTRUTURA). Esta definição serve tanto para identificar o que será gravado, mas em que formato também.

Imaginemos também que temos mais de uma equipe desenvolvendo. Uma equipe faz o módulo financeiro e outra faz o módulo de faturamento. Ambas precisam do cadastro de clientes! Obviamente que a estrutura dos clientes (campos, tipos e tamanhos) precisam ser compartilhados entre as equipes e há uma necessidade constante de manutenção e atualização desta estrutura para que ambas equipes possam trabalhar satisfatoriamente e o software final seja homogêneo.


Mas além da definição estrutural do arquivo, existe uma segunda camada, tão ou mais importante do que a estrutura que é chamada de INTEGRIDADE ESTRUTURAL em relação aos demais arquivos. Porque para cada equipe, se mantiver a estrutura do arquivo está bom, ao trabalharmos numa situação mais ampla, identificamos alguns problemas no processo. Por exemplo, a equipe financeira permite a EXCLUSÃO de um cliente e procede a verificação nos seus arquivos de CONTAS A PAGAR E RECEBER, mas não avisa a equipe do faturamento. Esta, por sua vez, não percebe (ou não sabe) que o cliente foi excluído e daí as notas começam a dar pau na pesquisa!

Outro exemplo: Para o faturamento o CPF/CNPJ de um cliente é obrigatório (exigência fiscal) e o seu módulo de cadastro OBRIGA a digitação do CPF/CNPJ. Já no módulo financeiro, o CPF/CNPJ é apenas mais um dado e PERMITE que seja informado em branco. Imagina a confusão quando for tentar emitir uma nota com o CPF/CNPJ em branco! E tem vários outros exemplos de confusão.


Para o cliente final, esse "erros" internos representam a qualidade do software ou da empresa. Assim temos sistemas melhores e outros que são "pura bucha".


Visando evitar estas situações, surgiu o DICIONÁRIO DE DADOS, que além das definições estruturais, também tem os relacionamentos entre os demais arquivos e assim por diante. Mas quanto maior o projeto, mais complicado é de manter essa estrutura toda coesa. E finalmente como resolver o compartilhamento entre aplicações?


Como podemos notar, as evoluções e conceitos foram surgindo a medida que as situações os exigiam. Temos muito chão percorrido desde os primórdios da informática até agora. Naturalmente chegou uma época que era necessário ter uma estrutura própria de dados que fosse ou tivesse:

  • independente da linguagem

  • junção de todos os arquivos em apenas um local físico

  • auto-contida de tal forma que as aplicações estejam sujeitas aos controles e definições internas

  • definições de segurança para permitir o acesso e a modificação dos dados por quem tem realmente poder para tal

Assim surgiram os BANCOS DE DADOS, que possuem as características acima e muitas outras e estão em permanente evolução.


Para podermos utilizar estes bancos de dados faz-se necessária uma conexão ao gerenciador, informando quem somos (usuário e senha) que por sua vez vai permitir um acesso relativo de consultas, manutenção das tabelas e/ou estrutura dependendo do nosso nível de acesso. Dessa forma, podemos utilizar quaisquer bancos por quaisquer linguagens, desde que obedeçamos ao princípios do gerenciador. A grande vantagem é que podemos utilizar várias ferramentas adequadas à função do nosso software sem nos preocuparmos com o armazenamento, organização e consistência dos dados.


E todo o gerenciamentos dos dados, estruturas e relacionamentos ficam por conta do gerenciador do banco de dados. Assim, se eu excluir um cliente (tendo poder para isto), tenho a certeza que o cliente também será excluído tanto do cadastro, como das tabelas de CONTAS A PAGAR E RECEBER e da tabela das NOTAS FISCAIS. Ou não será, exatamente por possuir esses relacionamentos ou ramificações. Tudo depende de como o banco foi montado!


Na minha opinião, atualmente temos alguns expoentes na categoria: Oracle (pago), Postgres (gratuito), MySQL, SQL Server, Firebird e SQLite, além de vários outros não menos importante ou menos utilizados. Esta é apenas uma pequena lista para referência. Eu considero hoje que, PARA PROJETOS PEQUENOS, o SQLite é uma excelente alternativa além de ser gratuita e acessível em várias plataformas.


Por favor, complementem om seus conhecimentos e experiências.

Obrigado.


Breve estarei postando um pequeno tutorial sobre SQLite em AutoIt.


  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×