O trabalho de um designer de banco de dados é traduzir os requisitos de negócios do cliente em um modelo de dados que não apenas armazene os dados de negócios corretamente, mas também suporte os processos que usam os dados.
Um designer de banco de dados, às vezes chamado de arquiteto de banco de dados ou oficial de dados, é responsável por projetar os bancos de dados em uma organização. Ele/ela avalia cuidadosamente os requisitos de negócios e elabora os modelos de dados. Em seguida, ocorrem as discussões iniciais com o negócio para validar o entendimento dos dados e dos processos de negócio. O trabalho de um designer de banco de dados também inclui preparar a documentação de suporte ao construir o banco de dados físico.
O que é modelagem de dados?
A modelagem de dados é um processo no qual um designer de banco de dados cria um modelo de dados que suporta sua aplicação. Seu objetivo é representar como os objetos de banco de dados interagem e como eles resolvem problemas de negócios.
Um modelo de dados descreve a estrutura dos dados nas tabelas do banco de dados e os relacionamentos entre eles. É representado por uma série de diagramas ER que contêm as principais entidades, seus atributos e os relacionamentos entre as entidades. É muito importante construir o modelo de dados correto desde o início.
A modelagem de dados também deve considerar a flexibilidade. Nenhum modelo de dados é imutável mesmo depois que o banco de dados é implantado. Um modelo de dados deve ser ajustado ao longo do tempo para refletir novos dados e novos requisitos. É por isso que a contabilização da flexibilidade é importante quando você a projeta.
A modelagem de dados ajuda você a traduzir os requisitos de negócios em requisitos técnicos para construir o banco de dados físico com mais facilidade. Também ajuda a encontrar possíveis problemas de desempenho com consultas antes mesmo de criar o banco de dados. Por todas essas razões, a modelagem de dados é muito importante.
Tipos de modelos de dados
Ao construir um novo banco de dados, seu trabalho como designer de banco de dados o conduz por pelo menos três fases principais. Um modelo de dados passa por um processo evolutivo a partir de um modelo de dados conceitual. Em seguida, ele é expandido em um modelo de dados lógico. Isso, por sua vez, é expandido ainda mais em um modelo de dados físico, posteriormente implementado com scripts SQL.
Cada tipo de modelo de dados é projetado para interagir com diferentes tipos de partes interessadas. Descreveremos brevemente e explicaremos o uso desses modelos de dados abaixo. Se você quiser uma explicação mais detalhada, dê uma olhada neste artigo.
Modelo de dados conceitual
O modelo de dados conceitual é o primeiro modelo de dados que construímos. Em um modelo de dados conceitual, as principais entidades são definidas, geralmente usando diagramas ER. É também quando participam os principais stakeholders do lado empresarial.
Um modelo de dados conceitual ajuda a identificar e definir o escopo inicial do problema de negócios, as entidades envolvidas na solução do problema e como elas interagem. Essas entidades são representações genéricas de conceitos como pedido, loja e funcionário.
Os relacionamentos entre essas entidades são tipicamente representados por linhas que ligam as entidades que interagem no mundo real. Assim, por exemplo, as entidades pedido, loja e funcionário devem ter relacionamentos que vinculem entre elas.
Modelo de dados lógicos
O modelo de dados lógico se baseia no modelo de dados conceitual. Técnicas de normalização como 3NF (a terceira forma normal) são aplicadas. Garantimos que todos os relacionamentos entre entidades sejam representados em nosso modelo de dados. Esta etapa é a principal diferença entre os modelos de dados conceituais e lógicos.
Modelo de dados físicos
O modelo de dados físico é a versão final e mais detalhada do nosso modelo de dados. Nesta etapa, definimos todas as tabelas em nosso aplicativo. Também definimos os relacionamentos entre tabelas, definimos sua cardinalidade, transformamos atributos de entidade em colunas e escolhemos ou definimos tipos de dados para cada coluna. Certificamo-nos de definir valores padrão ou restrições em valores de coluna, restrições entre tabelas e conjuntos de conjuntos.
Depois que um modelo de dados físico é projetado, geralmente construímos um conjunto de scripts SQL que definem essa estrutura para criar nosso banco de dados. Em vez de apenas escrever tudo à mão, é muito melhor usar uma ferramenta de modelagem de banco de dados como o Vertabelo Database Modeler.
O trabalho do designer de banco de dados
Os deveres de um designer de banco de dados não se limitam ao desenvolvimento técnico e design de diagramas. Um dia típico envolve olhar para a lista de pendências de requisitos de negócios e ver se alguma coisa mudou.
Um dia na vida de um designer de banco de dados
Quando há mudanças, o designer de banco de dados analisa os requisitos e se reúne com o negócio para esclarecer as implicações das mudanças no modelo de dados e no banco de dados. Após esses esclarecimentos, o designer do banco de dados atualiza o modelo com as alterações. Isso pode variar de apenas alterar um único tipo de dados para redesenhar relacionamentos de entidade e aplicar normalização se a alteração tiver um impacto maior.
Se houver uma métrica de desempenho que precise ser atendida, talvez o designer de banco de dados precise localizar e especificar os índices a serem criados. Se houver um processo ETL a ser mapeado, ele poderá especificar quais procedimentos armazenados realizam a transformação dos dados.
Um designer de banco de dados deve considerar as implicações das alterações nas tarefas de manutenção no banco de dados, como backups, restaurações e envio de logs. Se as alterações forem grandes, o designer do banco de dados precisa discutir com a equipe de administração do banco de dados ou com a equipe de desenvolvimento que monitora o banco de dados. Outra responsabilidade do designer é definir e manter o dicionário de dados para o banco de dados.
Riscos e problemas enfrentados por um designer de banco de dados
Como em qualquer trabalho, alguns problemas são previsíveis para que você possa ter um plano esboçado. Mas há problemas que você não pode prever, e o trabalho de um designer de banco de dados não é uma exceção.
Uma das coisas mais arriscadas que um designer de banco de dados pode fazer é fazer suposições. Isso pode causar problemas inesperados posteriormente no projeto. Sempre que estiver em dúvida, é melhor esclarecer com a empresa em vez de seguir em frente. Já vi isso acontecer muitas vezes, tanto comigo quanto com meus colegas.
Podemos fazer pequenas suposições sobre os tipos de dados ou a quantidade de dados para uma tabela específica. Se estivermos errados, no entanto, isso pode afetar o modelo de dados físico e causar muito retrabalho para atender às métricas de desempenho desejadas.
Outro problema é assumir que você cobriu tudo e que nunca haverá erros. Os problemas geralmente acontecem no final de um projeto quando tudo já está implantado.
Alguns cenários exigem ajustes, mesmo depois que seu banco de dados já estiver implantado. Isso pode ser devido a um aumento nos dados armazenados, mudanças nos requisitos de negócios ou necessidades de novos relatórios. Esses eventos afetam não apenas suas tabelas, mas também seus objetos de banco de dados, seus índices, possivelmente tipos de dados, relacionamentos e muitas outras coisas.
Os prós e os contras de ser um designer de banco de dados
Como em qualquer trabalho, há prós e contras dependendo de como você vê as coisas, do que gosta e de como quer viver.
As vantagens são que você sempre encontra contextos de negócios interessantes para mapear em um modelo de dados e construir em um banco de dados. É um ótimo trabalho para pessoas que podem se concentrar e que gostam de resolver problemas difíceis. É um ótimo trabalho se você gosta de se comunicar e resolver problemas técnicos e se você pode e tem curiosidade de entender os contextos de negócios e tecnologia.
Como acontece com qualquer habilidade difícil, o pagamento é muito bom. Se você está trabalhando em projetos com clientes de grandes empresas, as viagens de negócios podem ser um bônus se você gosta de viajar e conhecer novas pessoas em novos ambientes.
Os contras não são muitos a meu ver. Mas para algumas pessoas, algumas das coisas mencionadas nos prós são, na verdade, contras. Se você preferir se concentrar profundamente em seu trabalho e minimizar a comunicação ou se não puder ou não quiser viajar devido a restrições familiares, o trabalho de designer de banco de dados pode não ser adequado para você.
Torne-se um designer de banco de dados!
Com algum conhecimento técnico na área, alguma experiência em programação e abertura para comunicação, acho que qualquer pessoa pode ter a carreira de designer de banco de dados, mesmo que você não marque todas as caixas. Os requisitos de habilidade ideais para ser um designer de banco de dados estão listados abaixo.
- Técnicas de modelagem e normalização de dados.
- Conhecimento de consulta de banco de dados e ajuste de desempenho.
- Interiores de banco de dados específicos para o mecanismo de banco de dados exigido pelo cliente.
- Conhecimento de processos de ETL.
- Conhecimento de inteligência de negócios e relatórios.
- Conhecimento de arquitetura e design geral de software.
- Habilidades de gerenciamento de projetos.
- Boas habilidades de comunicação.
Pensando em se tornar um designer de banco de dados? Se você estiver verificando alguns itens da lista acima, não hesite - nós o apoiamos! Se você está se candidatando ao seu primeiro emprego como designer de banco de dados ou apenas quer se familiarizar com os tópicos mais importantes para a função, criamos uma lista de perguntas de entrevista relacionadas à modelagem de banco de dados.
Apenas começando com modelagem de banco de dados? É importante ter uma ferramenta como o Vertabelo Database Modeler para ajudá-lo a projetar, compartilhar e versionar seus modelos de dados.
Esperamos que tenha gostado do artigo! Sinta-se à vontade para navegar para obter mais informações sobre o incrível mundo dos bancos de dados.
