Aproveitando a onda que estou, vidrado na ideia de me tornar oficialmente o DBA da empresa, vou escrever sobre os softwares que utilizo, nessalista apenas Multi-plataforma.

DBDesigner4 (www.fabforce.net)
Bom software se você vai trabalhar com Mysql 4.0, permite conectar o ER ao banco, ou fazer engenharia reversa, com o mysql 4.1 lembre-se de alterar a sua senha ( senha do usuario no banco)  para OLD_PASSWORD.
Infelizmente o desenvolvimento foi paralizado em 2004. sem dúvida seria um bom software para trabalhar com versões como o mysql 5.

Mysql WorkBench (dev.mysql.com)
Eu acompanho essa ferramenta desde a versão 0.0.09 (algo assim), ainda é um alpha release, mas ja mostra que vem pra suprir a necessidade que a suite de ferramentas da mysql precisa, Faz uma modelagem facil e intuitiva, falta ainda um recurso para gera o dicionário de dados, acreditoq ue esta bem próximo. A conexão com os bancos mysql 4.1 e 5 é perfeita, engenharia reversa também. Eu aposto nesse software. ( Em breve vou tentar fazer um scrpt para gerar o docionario de dados a partir dele   )

Mysql Administrator (dev.mysql.com) – Parte de mysql Gui tools
Tesão de software, administro tudo do mysql com ele, posso editar tabelas, databases, agendar backup, exportar dados, tudo que um adminsitrador de BD deve fazer ele faz. É nele que eu programo minhas Sp’s e Functions.

Mysql Query Browser (dev.mysql.com) – Parte deMysql Gui tools
Depois dela, pronpt nunca mais, tudo que se faz em pelo mysql> você faz nessa ferramenta, edita suas SP´s, faz qualquer query, executa scripts com um “Debug” … muito bom mesmo.

É isso, em breve escrevo sobre as ferramentas pagas, ou nao multi-plataforma, Toad, Erwin, Aqua fold.

Esse é um artigo que escrevi para a empresa em que trabalho, expondo as vantagens do trabalho de um DBA no processo de desenvolvimento, e na melhora na produtividade da equipe de programação.

Segurança

Da forma que funciona hoje, cada cliente tem um login e senha para acessar seu banco de dados, mas os programadores ou qualquer um que abra os fontes têm acesso a senha e consequentemente acesso à base de dados do cliente, podendo assim copiar, ou alterar dados importantes, alem de cometer erros que comprometem o desenvolvimento, como apagar uma tabela..

Com um DBA, cada projeto terá uma senha para o banco, porém apenas a permissão de executar sp’s, nessas já haverá uma limitação de registros por consulta, utilizando o mysql-proxy, ferramenta da mysql, já citada no email interno da empresa, que ao fazer consultas de dados confidencias esses retornam apenas ” *** “, como outras funcionalidades.

Logs configuráveis do mysql também farão sua parte.

Otimização de tempo no desenvolvimento.

Trabalhando com normas de padronização e conhecimento do banco utilizado, a produção dos programadores será muito maior.

O trabalho começa na analise, atuando em conjunto com os gerentes de projeto, uma vez feita a analise, passa-se a UML e modelagem do banco de dados, Dicionário de dados, criação do banco, criação de SPs e documentação dessas.

Quando o processo chegar aos programadores, o banco de dados e as rotinas de listagem, inclusão, edição e deleção de registros de todas as tabelas já estará pronto, bastando ao programador ler as documentações.

No caso de um banco de dados com mais recursos, (Oracle/Postgres), alem das sp’s, funções de tratamento de informação, antes utilizadas na programação, também já estarão no banco, bastando ao programador passar apenas parâmetros as funções.

Com o tempo, a padronização estará tão clara ao programador que pouco se necessitará da documentação.

Outra vantagem de restringir o acesso ao banco de dados, é passar a utilizar ao máximo os recursos que o banco oferece, aumentado o desempenho e diminuindo a incidência de erros que causam sobrecarga no banco.

Ex.

(Loops infinitos, consultas “select * from”, por exemplo) que também são tratadas pelo mysql-Proxy.

Otimização de tempo em manutenção.

Acontece muito de um programador que não trabalhou em determinado projeto ter que fazer a manutenção. O problema é que sem uma padronização, ele fica perdido, e demora muito a entender o processo, acaba criando tabelas desnecessárias, ou criando uma tabela que já existe, mas ele não conseguiu perceber pela falta de padronização.

Com a padronização se já não estiver clara ao programador, basta ler a documentação.

Resumo da Otimização

Cada vez mais o programador deixa de ter que se especializar em bancos de dados ele conhecendo o básico para usar as SP’s é o suficiente, não precisa se envolver com regras e particularidades de cada banco, o que acaba restringindo ainda mais a quantidade de profissionais no mercado, você passa a exigir somente que o programador seja especialista nas linguagens de programação, deixando toda a parte de bancos de dados para o administrador de banco de dados, DBA.

Redução de Custos

O resultado dessa mudança no processo de desenvolvimento, somando o aumento de produtividade, o programador voltado apenas para o que lhe compete e o padrão de desenvolvimento adotado no ultimo projeto da empresa, É a velocidade de desenvolvimento, diminuição de tempo para finalizar os projetos, e o melhor aproveitamento dos recursos existentes, dispensando a contratação de novos, podendo a empresa investir na melhor especialização dos programadores.

Valor Agregado

Com um DBA na empresa, agregamos valor a nossos produtos, garantindo os prazos de entrega de projeto, documentação, e segurança dos dados do cliente.

Responsabilidade do DBA

O DBA pode ser visto como o responsável pela organização,

segurança, manutenção e projetos de banco de dados. Ele deve participar da

elaboração do projeto lógico juntamente com os analistas de projetos, executa o projeto físico do banco de dados e coordena as atividades operacionais de manutenção dos mecanismos de segurança lógica e física dos bancos de dados, além de definir as políticas de segurança e planos de contingências.

Documentação do DBA:

1 ) MER (Modelo Entidade Relacionamento)

O MER (Modelo Entidade Relacionamento), também conhecido apenas como modelo de dados ou diagrama de entidade-relacionamento, é a principal documentação de um banco de dados. Neste diagrama são relacionadas as entidades (tabelas) e seus relacionamentos, além de alguns detalhes a respeito das entidades, como nome das colunas nas tabelas, tipos de dados e constraints.

2 ) Padrões de Variáveis (Tabelas, colunas etc) e Documentação

Uma das boas práticas de desenvolvimento é contar com padrões. Saber colocar nomes significativos e explicativos em funções, variáveis, classes etc, está se tornando cada vez mais um pré-requisito para quem trabalha com desenvolvimento. No que tange à banco de dados, a idéia não é diferente: possuir um padrão de nomes para tabelas, colunas, constraints e objetos de bancos de dados é muito importante. Aqui a idéia não é apenas possuir um padrão e utilizá-lo largamente, mas possuir um padrão eficaz que seja fácil de ser utilizado, além de fazer sentido no contexto de banco de dados.

3 ) Capacity Plan

A necessidade de prever recursos de hardware é uma das grandes responsabilidades de um DBA. Além de economizar recursos, a previsão mostra que há um controle não apenas para os recursos que estão sendo utilizados, mas também para os recursos que podem ser necessários no futuro.

4 ) Dicionário de dados

O Dicionário de dados é um documento que complementa o MER. Este documento deve conter mais detalhes a respeito das tabelas e seus relacionamentos. Por exemplo, além de listar todas as colunas de uma tabela, o documento deve fornecer também uma pequena descrição do significado desta coluna, quais são os valores possíveis, a quantidade típica de valores armazenados e quais constraints agem sobre esta coluna. Além das informações sobre colunas, este documento apresenta o nome dos objetos que dependem da tabela, como stored procedures, triggers, views, funções etc, e suas respectivas funções, além dos parâmetros necessários e o que é retornado.

5 ) Política de segurança

O documento contento a política de segurança é um documento não-técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas tanto à segurança das informações como do acesso à elas. Geralmente este documento contém uma política de usuários e senhas, que especificam várias regras, como as definidas abaixo:

* Troca de senha a cada três meses;

* Desabilitar as contas padrão;

* Forçar senhas com letras, números e caracteres especiais que tenham um tamanho mínimo de 10 posições;

Outras políticas gerais de senha, como o cancelamento após um algumas tentativas e horários definidos para certos usuários, também deve constar neste documento, sempre tendo em mente a utilização de sistemas e bancos de dados.

6 ) N.D.A (non-disclosure agreement) – Compromisso de sigilo

Imaginem a seguinte situação:

Somos responsáveis por uma base de dados que deve ser integrada com um sistema externo à empresa. Para discutir os detalhes desta integração, uma reunião é marcada com a equipe externa à empresa que desenvolve o sistema. Durante esta reunião são apresentadas informações sigilosas da empresa que trabalhamos, com o objetivo de discutir os aspectos da integração.

Vamos supor que na situação apresentada acima os profissionais da equipe externa hajam da má fé e utilizem as informações fornecidas para seu próprio benefício, seja comercialmente ou não. Este tipo de situação pode gerar diversos problemas, podendo chegar ao ponto onde a equipe que agiu de má fé ser acusada de roubo.

Para e proteger de situações como estas, é comum fazer uso de um documento chamado NDA (non-disclousure agreement), também conhecido como compromisso de sigilo. Este é o tipo de documento que protege todo mundo: tanto quem assina como quem solicita a assinatura. Em termos práticos, que assina compromete-se a não revelar nenhum detalhe da informação que lhe vai ser comunicada sob pena de ser alvo de procedimento legal.

7 ) S.L.A. (Service Level Agreement) – Acordo de nível de serviço (ANS)

O SLA, também conhecido como Acordo de nível de serviço – ANS é um acordo entre a área prestadora de serviços e seus clientes. Este acordo deve deixar claro quais serviços estão sendo oferecidos (serviços específicos) e o nível de cada serviço (horas de funcionamento, downtime, horário do suporte etc). Geralmente este acordo é colocado na forma de um contrato que deve ser assinado na contratação do serviço. Para banco de dados, em particular, pode-se utilizar um SLA interno, onde o DBA se compromete a dar algum tipo de retorno (feedback) ao solicitante.

8 ) Diagrama de arquitetura

Atualmente é comum encontrar nas empresas, diversos ambientes de bancos de dados. Estes ambientes são separados de acordo com a sua finalidade, isto é, seu principal objetivo. Por exemplo, é comum encontrar ambientes de desenvolvimento, onde os programadores/analistas executam diversos testes durante o processo de desenvolvimento, e ambientes de programação, onde os usuários finais trabalham com os dados reais dos sistemas.

Para documentar e organizar o gerenciamento destes ambientes, o DBA deve elaborar um diagrama de arquitetura, que indica, de forma gráfica, quais servidores pertencem ao ambiente de desenvolvimento e ao ambiente de produção, como eles estão localizados em relação aos usuários com informações sobre link, rede, zonas desmilitarizadas (DMZ), firewalls, roteadores, etc. Este tipo de diagrama contém informações relacionadas à estrutura arquitetural dos ambientes e é extremamente útil para quem não conhece a organização física e lógica dos componentes da rede e dos servidores. É importante lembrar que este documento pode ser flexível, ou seja, pode incluir detalhes específicos, como endereços I.P. e senhas, ou apresentar uma visão de alto nível, onde apenas os principais servidores são apresentados.

9 ) Estratégia de Backup

Todo DBA profissional deve possuir uma estratégia de backup adequada. Esta estratégia deve ser montada de acordo com as necessidades de recuperação e disponibilidade do sistema, ou seja, toda a estratégia de backup vai depender do quanto de downtime e tempo de recuperação é aceitável.

É importante documentar a estratégia de backup utilizada, tanto para oficializar este tipo de tarefa como para conscientizar os usuários a respeito do que pode ser recuperado, quando, sob quais condições e a qualidade do que foi recuperado. Geralmente este documento contém todos os bancos de dados envolvidos na estratégia, como o backup será realizado, qual a periodicidade, qual é o procedimento para recuperação, quem são os responsáveis e os recursos envolvidos. Por fim, é importante atualizar este documento conforme as necessidades de disponibilidade e recuperação mudam de acordo com o volume de informações manipuladas pelos sistemas.

Conclusão

A nossa empresa precisa de um DBA, já alcançou um volume de desenvolvimento onde o a padronização tanto da programação quanto dos bancos de dados é fundamental para a produtividade.

Os grandes clientes que já temos e os que estão por vir também necessitam de cuidados com a segurança de seus dados, padronização e documentação.

“Cada macaco no seu galho”, assim desafogamos um pouco o Adm de redes que volta e meia tem que criar um banco, uma tabela, definir permissões, tirar relatórios etc. Os programadores precisam se preocupar com a programação ou a integração html – php, não com o banco, até porque o conhecimento da maioria é básico, o que gera mais consultas pesadas exigindo mais do servidor de banco de dados, gera tabelas sem padrão, campos sem padrão, e entidades sem relacionamento.

Com um banco bem modelado, tabelas bem relacionadas e sp’s que fazem o trabalho antes feito pelos programadores, sobra mais tempo para os programadores utilizarem refinando a programação. Sobrando mais tempo a cada projeto, a empresa não precisa contratar mais recursos, que, gera custos, e tempo para o aprendizado da metodologia de trabalho, consequentemente atraso nos projetos.

Fontes: Google, Mauro Pichiliani e Cristian Pedroso.