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.
