Tag Archive for 'sql'

Banco de Dados

Hoje em dia, temos muitas informações digitalizadas, dados sobre tudo e sobre todos, informações das mais diversas áreas de conhecimento, e o banco de dados é parte importante nos sistemas de informação, senão a mais importante!
Para termos um bom sistema de informação, temos que ter um bom banco de dados.

Mas o que é um bom banco de dados ?

Podemos começar pelo software do banco de dados em si, onde temos uma série de ótimos bancos para trabalhar, como: Oracle, PostgreSQL, MS SQL Server, DB2, etc… e cada um com seu modo de trabalhar, e cada um com suas features.
Uns requerem mais maquina e mais trabalhos de DBA, outros você simplesmente instala e se preocupa somente com sua aplicação. Temos também outros modelos de bancos de dados como o Orientado a Objetos por exemplo. Mas o importante é escolher um que tenha tudo que seu software vai necessitar.

Outro passo é fazer uma boa analise dos requisitos do seu software e suas funcionalidades para poder criar um bom design para seu banco. Onde teremos tabelas, triggers, sequences, views, e por ai vai ….
Hoje se fala muito em transparência ao banco de dados, ou seja, criar aplicações que rodem, teoricamente, em qualquer banco de dados, ou pelo menos na maioria deles, mas eu realmente nao gosto disto. Por que eu acho que cada software de banco de dados tem muitas coisas boas que poderemos utilizar para melhorar ainda mais nossa aplicação, seja em termos de design, seja em termos de performance, e se utilizarmos esta abstração do banco não teremos isto ! Gerando assim mais trabalho para nosso aplicativo, o que pode gerar uma perda de performance e até mesmo uma “não garantia” dos dados no banco. Pois erros humanos ( e de programação ) acontecem !

Dica: Uma boa análise dos problemas para a geração do Modelo ER do banco é sempre feita entre o analista do software e o DBA juntos. E sempre manter o Diagrama Logico e Fisico atualizados com o que realmente existe no banco de dados é otimo e gera confiança e facilidades para o dia-a-dia.

E o que é um bom design para seu banco ?
Tudo caminha passo a passo. Primeiro temos que ter as tabelas ! Ohhhhh, mas as tabelas não podem ser simplesmente um lugar onde gravamos dados, simplesmente um monte de tabelas soltas dentro do bd, o básico é que atendam as 4 formas normais do banco de dados. A partir daí já teremos um bom banco básico para o aplicativo.

As formas normais estão documentadas no wikipedia, no link a seguir:
http://pt.wikipedia.org/wiki/Normalização_em_banco_de_dados

Depois, poderemos começar a pensar em utilizar as features “ANSI” ( que tem em quase todos os bancos ) para ajudar em nossa jornada de desenvolvimento de uma boa aplicação:

SQL: É a linguagem que conversamos com o nosso banco de dados. Este SQL é padronizado e tem seu formado ANSI bem definido pela entidade chamada ANSI (American National Standards Institute), que define bem suas partes e funcionalidades que todos os bons bancos de dados devem seguir. Mas cada banco agrega mais features e características a esta linguagem, deixando-o assim mais completo ainda e mais robusto, com mais funcionalidades. Por isto que é sempre bom conhecer bem o banco onde se está trabalhando, pois poderemos gerar assim bons e rápidos SQL.

Uma boa documentação sobre o SQL tem também no wikipedia: http://pt.wikipedia.org/wiki/SQL

SEQUENCES/Campos AutoIncremento: São ótimas, pois nos tiram o trabalho de estar verificando e gerando IDs para nossos registros nas tabelas. Perfeito ! Acho que não pode faltar em uma boa base de dados.

VIEWS: São bem interessantes, e ajudam bastante na hora de criar modos de visão diferentes para os mesmos dados. Podem ser utilizadas por exemplo para geração de relatorios, na listagem de dados no sistema, lembrando que temos muitas funcionalidades que custam menos rodando diretamente no banco do que se fizermos a mesma coisa na nossa linguagem de programação.

TRIGGERS: São ótimas ! Nos ajudam em atualização automática de dados, em geração de LOGS, de históricos, em validações mais complexas, etc. Mas eu não as utilizaria para validar campos ou dados simples ou ligações entre dados de outras tabelas, lembrem-se que um bom banco de dados está bem definido em seus tipos de dados de cada coluna e PKs e FKs também, que já fazem todos este trabalho.

PROCEDURES/FUNCTIONS: São um caminho alternativo para grandes conversões de dados, manutenção nos dados da base, agendamento de tarefas repetitivas mais simples e até formatação de valores em formatos nao customizados.
Aqui tem dois pontos: Formatação de dados com functions eu nao gosto de utilizar, a não ser em relatorios, pois elas ajudam a pesar bastante nossos SQLs, e outro ponto é que: as regras de negócio não devem estar no banco de dados. O BD serve somente para guardar e manusear os dados. Não para as regras de negocio do seu software.

INDICES: Perfeitos ! Indispensáveis. Sempre que montamos uma query, seja ela para o proposito que for, temos sempre que rodar, ajustar o melhor possivel dentro das ligações das tabelas e depois disto, criar os indices que irão melhorar sua performance. Mas lembrando sempre que: criamos o indice que achamos necessário, rodamos as estatísticas, e rodamos novamente a query. Se este indice não foi utilizado NÃO DEIXE ELE NO BANCO. Pois ao invés de ajudar, ele irá atrabalhar, principalmente nas atualizações de dados, pois o banco , a cada comando DML terá que atualizar este indice que nao está sento utilizado para nada.

E depois disto, se necessário, podemos utilizar qq outro recurso que nosso banco de dados nos dá para melhorar ainda mais a performance e garentia de veracidade de nossos dados, e fora isto temos ainda as configurações de rede, maquina servidora do banco e segurança do mesmo e ainda um bom sistema de backup que devem ser observados também para manter a segurança dos dados e em caso de pane a menor perda de dados possivel.

Em alguns proximos posts pretendo explicar um pouco mais sobre SQL e sobre Modelagem Logica e Fisica do Banco de Dados.

Sejam felizes e desenvolvam otimas aplicações !
[]´s a todos…