Sentindo-se sobrecarregado com a quantidade de tempo que levará para aprender a ser um designer de banco de dados? Leia sobre as habilidades e talentos essenciais que você precisará – não é tão terrível!
Quando você anda pelos corredores do supermercado com o carrinho de compras em uma mão e a lista de compras na outra, o que você está pensando? Se você é como eu, está imaginando como melhorar a organização das prateleiras para que suas compras semanais sejam menos demoradas. Ou talvez você sinta o mesmo desejo de organizar e estruturar informações quando um amigo lhe mostra sua grande coleção de revistas. Ou talvez ocorra quando você estiver gerenciando suas listas de reprodução para melhor atender às suas preferências. Se você passa a vida pensando em como representar a realidade em termos de entidades, atributos e relacionamentos, então sua vocação é ser um modelador de banco de dados.
Talvez você não seja tão radical, mas ainda se sinta atraído pela ideia de seguir o design de banco de dados como carreira. De qualquer forma, você precisará dominar algumas novas habilidades. Alguns deles são puramente técnicos; você pode aprender essas habilidades estudando ou lendo e aprofundando-as através da experiência de trabalho. Outras habilidades envolvem conhecimento não técnico que você pode aprender por meio de cursos, artigos de blog ou observando outras pessoas.
Aqui está um resumo dos conhecimentos e habilidades essenciais que todo designer de banco de dados precisa ter.
Habilidades necessárias para designers de banco de dados
Hard skills são aquelas que são adquiridas através do estudo e aperfeiçoadas através da prática. Se você puder demonstrar com evidências concretas que dominou uma habilidade difícil, isso significa que você é capaz de realizar qualquer tarefa que a envolva.
Em termos de conhecimento de banco de dados, hard skills incluem os fundamentos da teoria de banco de dados e as várias técnicas usadas para aplicar conceitos teóricos para resolver problemas concretos. Vejamos cada uma das hard skills que os designers de banco de dados precisam.
Teoria do Banco de Dados
A teoria do banco de dados está cheia de conceitos abstratos que podem ser difíceis de entender se não estiverem associados a fatos da vida real. O modelo relacional, domínios, atributos, relações e relacionamentos, chaves primárias e estrangeiras, integridade de entidade, integridade referencial e restrições de domínio são apenas alguns exemplos. Se você adicionar assuntos ainda mais complexos (como álgebra relacional ou cálculo relacional), você pode se perguntar se não seria melhor escolher uma carreira lidando com coisas concretas como jardinagem ou culinária gourmet.
Não entrar em pânico. O conhecimento profundo da teoria do banco de dados é importante se você planeja dar aulas na faculdade ou inventar uma nova maneira de organizar as informações. Mas para projetar bancos de dados, você só precisa dominar os conceitos teóricos que se aplicam à solução de problemas da vida real. O mais importante – o ABC do design de banco de dados – é o modelo relacional.
O Modelo Relacional
Os professores universitários dirão que o modelo relacional é um mecanismo de organização de dados baseado na teoria dos conjuntos e na lógica de predicados. Mas isso não fará muito bem em seu trabalho diário como modelador de banco de dados. Na prática, você precisa saber que o modelo relacional é uma forma intuitiva e direta de organizar dados na forma de tabelas – chamadas relações – que são compostas por linhas (que também são chamadas de tuplas). Cada tabela (ou relação) é definida por seus atributos (ou colunas).
Conceitos fundamentais do modelo relacional.
Todas as relações devem ter um ou mais atributos pendentes que representem um identificador exclusivo para cada tupla. Na gíria do banco de dados, essa é a chave da tabela. Atributos não-chave são dependentes de chave no sentido de que cada valor de chave determina um único valor possível para cada atributo.
Imagine uma tabela de informações do veículo em que a chave é a placa. A placa determina os atributos de cada veículo (como fabricante, modelo, proprietário etc.), pois as regras do domínio impedem que dois veículos diferentes compartilhem a mesma placa.
Bancos de dados relacionais
Os sistemas de gerenciamento de banco de dados relacional (RDBMSs) implementam o modelo relacional, respeitando seus princípios. Eles oferecem maneiras de recuperar informações por meio de consultas e atualizar informações por meio de transações. Para que as informações em um banco de dados relacional reflitam fatos e situações da vida real, você pode definir condições ou restrições específicas ao domínio ao qual o banco de dados se aplica. Por exemplo, em uma tabela que armazena informações sobre alunos da escola, uma restrição pode ser imposta para que as datas de nascimento não permitam datas futuras ou datas muito distantes no passado.
A organização das tabelas em um banco de dados é comumente chamada de esquema de banco de dados. Além das tabelas, o esquema detalha as restrições envolvendo pares de tabelas chamadas relacionamentos. Um relacionamento conecta duas tabelas impondo a restrição de que os valores no campo de uma das tabelas correspondam aos valores da chave primária da outra tabela.
Os esquemas de banco de dados geralmente são representados pelo diagrama entidade-relacionamento (ERD), uma ferramenta comum para qualquer designer de banco de dados.
Um ERD representando um modelo de dados do cliente.
Anomalias e normalização
Todos os conceitos que discutimos até agora são bastante claros, certo? Agora podemos falar sobre as anomalias que ocorrem nos bancos de dados devido ao design defeituoso ou inadequado (ou seja, o banco de dados não reflete adequadamente a realidade que está tentando representar).
Anomalias ocorrem quando uma operação de inserção, atualização ou exclusão gera inconsistências nos dados. Por exemplo, suponha que você tenha uma tabela para armazenar dados de vendas. Para cada venda (ou seja, em cada registro da tabela), o nome e o endereço dos clientes são registrados. A anomalia é a seguinte:
- Se o endereço do cliente for modificado em uma das vendas e
- O mesmo cliente tem outras vendas,
- As outras vendas terão um endereço desatualizado.
Para evitar anomalias, você pode aplicar uma técnica de design chamada normalização de banco de dados. Isso envolve a decomposição de tabelas e colunas (ou seja, dividi-las em partes menores) para evitar falhas de design como:
- Colunas que contêm mais de uma informação (por exemplo, o número de identificação de um item e seu nome).
- Armazenar as mesmas informações mais de uma vez na mesma tabela.
- Campos que dependem de outros campos não-chave.
Tabela não normalizada (esquerda) versus esquema normalizado (direita).
Data Warehouses e Desnormalização
Alguns bancos de dados são usados para consultar grandes volumes de informações em vez do processamento de transações online (OLTP). Esses bancos de dados são chamados de data warehouses.
As informações em um data warehouse não vêm de interfaces de usuário (por exemplo, inseridas diretamente de um sistema de pedidos de comércio eletrônico). Ele vem de processos em lote que coletam informações de diferentes fontes, processam, limpam e armazenam em tabelas. Por esta razão, podemos supor que os data warehouses não estão expostos às mesmas anomalias que os bancos de dados convencionais.
Por isso, os data warehouses não precisam manter as mesmas condições de normalização de um banco de dados OLTP. Por outro lado, é mais importante otimizar a eficiência das consultas em data warehouses. É por isso que a desnormalização é aplicada em um data warehouse; essa técnica usa uma certa redundância para simplificar as consultas e evitar sobrecarregar os esquemas com um número excessivo de tabelas.
Um esquema típico de data warehouse.
Big Data
Assim como o armazenamento de dados, o conceito de Big Data refere-se a repositórios que armazenam grandes quantidades de dados. No entanto, há uma diferença importante entre os dois conceitos. Um data warehouse é projetado para uma finalidade específica e visa gerar relatórios cujo comportamento e formato são conhecidos antecipadamente.
O Big Data, por outro lado, visa coletar grandes volumes de dados gerados em alta velocidade de diferentes fontes – por exemplo, informações de mídias sociais, microtransações ou sensores inteligentes. Essa enorme quantidade de informações pode ser usada para exploração e análise ou para treinamento de modelos de aprendizado de máquina.
No design de banco de dados Big Data, a economia de espaço de armazenamento e o particionamento de dados (entre outras coisas) são priorizados para permitir o paralelismo e a captura de dados em tempo real. Além disso, são utilizados sistemas de banco de dados não relacionais ou NoSQL, que oferecem melhores alternativas para o tratamento de informações não estruturadas.
Tecnologias como NoSQL e o próprio conceito de Big Data são relativamente novos se comparados aos bancos de dados relacionais, que já têm mais de 40 anos. É por isso que, como designer de banco de dados, você deve estar atento aos novos desenvolvimentos nessa área. Tenha em mente que Big Data também é um grande negócio. Muitas empresas querem assumir uma posição de liderança e estão desenvolvendo novas ferramentas e tecnologias para isso.
Administração de banco de dados
Uma vez que um banco de dados está funcionando, alguém tem que cuidar de seu gerenciamento diário. Isso significa realizar tarefas rotineiras para que o banco de dados nunca se torne um gargalo para os aplicativos que o utilizam. As tarefas de administração incluem manter backups, monitorar o consumo de espaço de armazenamento, detectar falhas entre processos e corrigir problemas de dados que impedem a operação normal dos aplicativos.
A pessoa que tem as habilidades de banco de dados para cuidar dessas tarefas é o administrador de banco de dados, ou DBA – quando houver. Em organizações muito pequenas – ou em ambientes de desenvolvimento onde a operação dos bancos de dados não é crítica para o negócio – a responsabilidade pela manutenção do banco de dados pode recair sobre o modelador de banco de dados. Portanto, você deve ter algum conhecimento que lhe permita assumir o controle do DBA em determinadas situações. No entanto, em nenhuma circunstância você deve aceitar a responsabilidade de administrar um banco de dados em um ambiente de produção que suporte aplicativos de negócios ou de missão crítica .
As tarefas de administração variam muito dependendo do sistema de banco de dados e da infraestrutura na qual ele está montado. Por exemplo, as tarefas de gerenciamento de bancos de dados Microsoft SQL Server são muito diferentes daquelas de gerenciamento de bancos de dados MySQL ou Oracle. E gerenciar um servidor que você executa localmente em seu notebook é muito diferente de gerenciar um que é executado na nuvem.
Não recomendo dedicar muito esforço para aprender a gerenciar um determinado servidor de banco de dados, pois você lidará com bancos de dados e ambientes muito diferentes ao longo de sua carreira. Não vai adiantar muito se especializar em apenas um.
Gerenciamento de simultaneidade e transações
O acesso simultâneo a um banco de dados pode causar problemas em aplicativos quando vários usuários tentam acessar o mesmo recurso ao mesmo tempo. Podemos pensar que, como designers, isso não é da nossa conta e que é responsabilidade do DBA lidar com esses problemas. Também podemos pensar que é culpa dos programadores criar aplicativos que os permitem.
No entanto, os designers podem fazer sua parte para minimizar possíveis problemas de simultaneidade projetando esquemas que os evitam.
Muitos problemas de simultaneidade ocorrem quando transações longas e complexas são executadas em um banco de dados; enquanto a transação está sendo processada, as tabelas envolvidas são bloqueadas para outros processos que precisam delas para ler ou gravar informações. Para evitar esse tipo de problema, a melhor coisa que você pode fazer é garantir que seus projetos cumpram pelo menos até a terceira forma normal. Então será responsabilidade do programador pensar nas transações corretamente para evitar impasses.
Mas você também pode usar estratégias que evitem a simultaneidade, como particionar esquemas ou agrupar tabelas de acordo com a função que cada um cumpre.
Vamos imaginar um banco de dados para um site de comércio eletrônico. Você pode colocar as tabelas de dados mestre para produtos, estoque e preços em um esquema e pedidos e vendas em outro, juntamente com visualizações ou réplicas somente leitura das tabelas do primeiro esquema. Isso ajuda a evitar erros ao executar transações que atualizam os dados mestre.
Ferramentas de design de banco de dados
Se você entender o modelo relacional, os diagramas de entidade-relacionamento e as técnicas de normalização, poderá projetar bancos de dados com nenhuma outra ferramenta além de lápis e papel. No entanto, seu desempenho será muito aprimorado se você usar uma ferramenta inteligente, especialmente uma que possa automatizar certas tarefas de design, como realocar ou modificar objetos em um diagrama, detectar erros de design, gerar scripts SQL para criar ou atualizar um banco de dados e reverter engenharia de um projeto de banco de dados existente.
Dominar uma ferramenta especializada como a plataforma Vertabelo permitirá que você trabalhe muito mais rápido. E permitirá que você se destaque de outros designers que não têm essa ajuda.
SQL e programação
Todos nós gostaríamos de poder entregar um design de banco de dados, dizer com orgulho “Meu trabalho aqui está feito” e partir para umas merecidas férias. Mas geralmente, essa situação ideal nunca acontece. Depois de terminar seu design, os programadores de aplicativos precisarão usá-lo e precisarão ter você por perto para ajudá-los.
Uma maneira de continuar ajudando em um projeto de desenvolvimento é escrever exibições, gatilhos, procedimentos armazenados e outras coisas em SQL (Structured Query Language) para resolver necessidades específicas de aplicativos. Outra maneira é supervisionar as tarefas de programação que são realizadas com algo chamado Mapeamento Objeto-Relacional (ORM).
Os ORMs destinam-se a abstrair o acesso a dados de um RDBMS específico. O lado bom disso é que os programadores não precisam se preocupar com as especificidades do banco de dados que usarão – em outras palavras, eles não precisam se preocupar se o RDBMS é MySQL, Oracle, IBM DB2, MS SQL Server , ou outra coisa.
A desvantagem dos ORMs é que os objetos de design do banco de dados – tabelas, atributos e relacionamentos – são definidos no código de uma linguagem de programação de alto nível como Java, Python, R ou C#. Em outras palavras, eles estão onde nós, designers de banco de dados, não podemos vê-los.
A solução para este problema está nas metodologias de desenvolvimento Agile e sua filosofia colaborativa. Eles promovem designers e programadores trabalhando juntos ao longo de um projeto, então você vai querer manter um bom relacionamento com os programadores. Você deve estar disposto a sentar ao lado deles, examinar o código de programação e escrever em conjunto as definições dos objetos de dados.
Os designers de banco de dados de habilidades sociais devem ter
Além do conhecimento teórico e técnico específico para o design de banco de dados, um designer deve, idealmente, ter outras habilidades conhecidas como “soft skills”. Essas habilidades – como ser um bom comunicador e entender a visão do negócio para o produto final – impactam indiretamente no sucesso do seu trabalho. As que mencionei abaixo são apenas alguns exemplos, mas há muito mais soft skills que são muito valorizadas por potenciais empregadores.
Visão de Negócios
Ao projetar um banco de dados, você está representando a realidade de um negócio em termos de objetos de dados inter-relacionados. Vimos que o design deve atender às condições de padronização e que deve evitar inconsistências, anomalias e problemas de simultaneidade. Mas tão importante – ou talvez mais – é que o design esteja alinhado com a visão de negócio de quem está pagando seu salário.
Entender a visão do negócio permitirá que você compreenda melhor a importância de cada requisito e oriente suas decisões para que seus projetos estejam mais alinhados aos objetivos da organização.
Aqui está um exemplo simples de como a compreensão da visão de negócios moldará seu trabalho. Você pode pensar que usar uma chave substituta em uma mesa atrapalha seu design, adicionando um elemento desnecessário e irritante. Mas ao omitir a chave substituta, você pode tornar as consultas nessa tabela mais lentas porque uma chave do tipo INTEGER pode fornecer desempenho superior. Se a visão de negócios é fornecer consultas rápidas, a chave substituta é o caminho a seguir.
Habilidades de comunicação
Não é suficiente fazer grandes designs. Você também deve ser capaz de explicar por que seu design funciona. A maneira de fazer isso é saber apresentá-lo, tanto discursivamente (falado ou escrito) quanto visualmente.
Faça uma lista dos pontos fortes do seu design para que eles se destaquem. Pense nas decisões que você tomou para criá-lo e anote as razões para essas decisões. Esteja preparado para defender suas decisões e seu design para aqueles que não o entendem ou que desejam mudá-lo, tornando-o imperfeito ou falho.
Mas você também deve estar disposto a aceitar críticas construtivas e considerar pontos de vista diferentes dos seus. Às vezes, um programador pode identificar um problema que você não viu e dar bons conselhos. Não descarte seus colegas de trabalho, pensando que eles não têm conhecimento de banco de dados.
Habilidades interpessoais
Eu comentei acima sobre as vantagens de ter um bom relacionamento com os programadores. Por mais avançado que você seja em sua área de atuação, é importante que você mantenha uma atitude de companheirismo com todos os membros da equipe, seja um testador que detectou um defeito que o obriga a repensar parte do seu projeto ou um gerente de projeto que precisa você realizar uma tarefa em uma determinada data. Resumindo, você deve ser um jogador de equipe . Ninguém quer ter prima donnas em sua equipe que se sintam insubstituíveis e queiram impor suas regras.
Pode acontecer que você não seja o único designer de banco de dados em uma equipe de desenvolvimento. Talvez você deva liderar um subgrupo de seus colegas. Para isso, você deve demonstrar habilidades de liderança e atuar como gerente de projetos, garantindo que a equipe de designers de banco de dados cumpra seus objetivos e permaneça motivada.
Como aprender habilidades de design de banco de dados
Você pode adquirir as habilidades necessárias para ser um designer de banco de dados em diplomas universitários, cursos, livros e artigos especializados. A vantagem dos cursos universitários é que eles fornecem todo o conhecimento necessário e endossam esse conhecimento com um diploma reconhecido. A desvantagem é que eles exigem um grande investimento de tempo e dinheiro.
Se você preferir aprender por conta própria lendo livros e artigos, economizará tempo e dinheiro – mas precisará de um guia para guiá-lo pelos tópicos essenciais e avaliar seu conhecimento. E você terá que demonstrar seu conhecimento de forma prática, pois não terá um diploma para respaldar.
De qualquer forma, quer você aprenda fazendo cursos ou lendo, esse conhecimento servirá apenas como base. Você aprenderá mais criando modelos, enfrentando problemas reais e observando as ações de seus colegas e colegas de trabalho.
