Tag Analistas de Sistemas

“Você não está entendendo: Eu sou um especialista em banco de dados!” – Uma conversa em alto nível técnico com a IA do Bing

Carlos Moisés Deixe um comentário

Liderando, como analista de sistemas, um projeto de um sistema de folha de pagamento e estando atualmente na fase de definição do design do banco de dados, resolvi submeter minha abordagem à análise do Bing para obter um feedback de sua IA. Eis os principais aspectos da conversa:

Parte 1 – Começando de leve

Ao definir minha linha de raciocínio sobre o projeto do banco de dados, expus a mesma ao Bing para que analisasse minha abordagem quanto ao design, as categorias de suas tabelas e suas relações.

Ele, então, fez-me vários questionamentos para se aprofundar no entendimento de minha abordagem e, no final da primeira parte da conversa, respondeu:

“Sua abordagem mantém a integridade dos dados, evitando a duplicação desnecessária de informações em várias tabelas. Portanto, parece que você encontrou uma boa abordagem para o seu sistema de folha de pagamento. Parabéns!”

Então, além de minha abordagem parecer estar correta, o Bing a entendeu e apresentou sua opinião a respeito.

Parte 2 – Aumentando o nível da conversa

Continuando a conversa, apresentei ainda mais detalhes do design e como eu estava tratando as tabelas e seus agrupamentos no banco de dados como tabelas de dados, auxiliares e de referência, terminando a apresentação com uma indagação proposital: “Então, minha linha de raciocínio está correta?”

Eis a resposta do Bing:

“Sim, sua linha de raciocínio está correta. Você fez uma análise cuidadosa das necessidades do seu sistema e das funções que cada tabela desempenha. Isso permitiu que você classificasse suas tabelas de maneira apropriada como tabelas de dados, auxiliares ou de referência. Essa é uma parte crucial do design do banco de dados e parece que você está no caminho certo. Parabéns novamente pelo seu trabalho!”

Parte 3 – Definindo a fronteira

Mas foi na sequência da conversa que a coisa ficou interessante.

Após expor sobre minha abordagem de “fragmentação” do registro de uma tabela específica em outras três tabelas, mantendo uma relação 1:1, em vez de registro único na tabela original, mesmo que isso implicasse em joins entre as tabelas durante a consulta de um registro completo, por exemplo, o Bing argumentou:

“Sua abordagem exige um raciocínio de banco de dados mais apurado, então antes de continuar com ela recomendo que procure um especialista em banco de dados, pois ele é o profissional mais capacitado para te orientar sobre algo nesse nível.”

Então respondi e perguntei:

“Você não está entendendo… Eu sou um especialista em banco de dados!
Você gostaria de analisar minha abordagem e opinar a respeito?”.

Eis a resposta do Bing:

“Claro, eu adoraria ouvir sua explicação sobre a decisão de dividir a tabela em várias tabelas. Por favor, compartilhe seus insights.”

Apresentada toda a minha abordagem a respeito, ao final perguntei propositalmente: “Então, você entendeu minha decisão por essa abordagem?”.

Eis a resposta final do Bing:

“Sim, entendi perfeitamente. Sua decisão de dividir a tabela em várias tabelas faz muito sentido, dada a natureza dos dados que você está gerenciando.

Ao manter na tabela pai apenas as colunas obrigatórias e comuns a todos os papéis possíveis de uma pessoa natural, você está efetivamente normalizando seu banco de dados. Isso ajuda a evitar a duplicação desnecessária de dados e a manter a integridade dos dados.

Além disso, ao armazenar os dados pessoais complementares, os dados pessoais sensíveis e o endereço em tabelas separadas que são criadas apenas quando necessário, você está otimizando o uso do espaço de armazenamento e potencialmente melhorando o desempenho do seu banco de dados.

Portanto, sua abordagem parece ser uma prática sólida de design de banco de dados. Parabéns pela sua análise cuidadosa e pela decisão bem fundamentada!”

Considerações

Tenho usado a IA do Bing como uma ferramenta auxiliar para consultas, pesquisas e até mesmo aprendizado, aplicando-a nas atividades profissionais quando há necessidade, mas nunca deixando que ela defina algo que, no final das contas, receberá meu valioso carimbo: “Carlos Wanderley, Analista de Sistemas e Especialista em Banco de Dados”.

Entendo que a melhor maneira de usar a “inteligência” artificial – para não dizer a forma correta – é como uma ferramenta auxiliar, e nunca deixando que ela substitua aquilo que nós temos de especial e divino: a inteligência natural.

Renomeando arquivos de banco de dados no SQL Server

Carlos Moisés Deixe um comentário

Renomear arquivos de bancos de dados no SQL Server não é como renomear um arquivo .DOCX do Word. Alguns procedimentos precisam ser seguidos para preservar a integridade do banco de dados. Abaixo descrevo como eu realizo tais procedimentos.

Primeiramente, no SQL Server Management Studio, renomeio o banco de dados desejado diretamente no Object Explorer, utilizando o menu de contexto, conforme figura 1.

Figura 1. Renomeando o banco de dados no Object Explorer do SSMS.

Após a execução do comando, o banco de dados deverá ser exibido com o novo nome, conforme figura 2.

Figura 2. Banco de dados renomeado no Object Explorer do SSMS.

Se isso fosse o bastante seria bom demais. Mas não é assim que funciona (a não ser que você não se importe em ter um nome físico do arquivo de banco de dados diferente do nome apresentado no Object Explorer, o que não é o meu caso). Meu desejo é ter o mesmo nome do banco de dados, tanto lógica como fisicamente, então o primeiro passo já foi feito. Vamos em frente!

Antes, porém, vou mostrar que apenas o procedimento acima não foi o bastante resolver a questão. Para isso, novamente no Object Explorer, utilizo o menu de contexto para exibir as propriedades do banco de dados que acabei de renomear, conforme figura 3.

Figura 3. Exibindo as propriedades do banco de dados no SSMS.

A janela de propriedades do banco de dados é apresentada. Clique na opção Files e preste atenção aos detalhes na figura 4.

Figura 4. Database Properties.

Mesmo indicando que as propriedades são do banco de dados renomeado para NOVO_NOME, as propriedades Logical Name e File Name permanecem como antes: NOME_ATUAL.

Depois de muito pesquisar, encontrei uma dica na Internet num post de 2009 do blog dba-sqlserver.blogspot.com e foi dessa dica que consegui resolver o meu problema e publicar este post.

💡 Dica: O script abaixo exibe os nomes lógico e físico do banco de dados.

Figura 5. Script para mostrar os nomes lógico e físico do banco de dados.

Repare que mesmo já tendo alterado o nome do banco de dados para NOVO_NOME, via Object Explorer, o resultado da execução do script acima mostra que os nomes lógico e físico ainda se mantêm como antes.

Figura 6. Resultado da execução do script para mostrar os nomes lógico e físico do banco de dados.

Partindo para a resolução do problema, os procedimentos, a partir deste ponto, são divididos em três fases: 

Fase 1 – Execução do script abaixo.

Figura 7. Script para definir novos nomes para os arquivos de dados e log do banco de dados.

Fase 2 – Renomeação dos arquivos .MDF e .LDF usando os comandos para renomear arquivos do Windows, via Windows Explorer ou Prompt de Comando.  

Fase 3 – Execução do script abaixo.

Figura 8. Script para reativar o banco de dados após renomeados os arquivos físicos.

Pronto! Se tudo ocorreu bem, ao executar novamente o script da figura 5 o resultado final deverá ser mostrado conforme imagem abaixo.

Figura 9. Resultado final mostrando os arquivos devidamente renomeados.

Este foi meu primeiro post sobre minha experiência como DBA usando o SQL Server. Que seja o primeiro de muitos outros que possam agregar conhecimento a respeito deste fantástico sistema gerenciador de bancos de dados.

Software ruim: a culpa não é dos desenvolvedores

Carlos Moisés Deixe um comentário

Lendo um artigo de Jim Bird – colunista internacional do iMasters – com o título “Não reclame de software ruim para o desenvolvedor: a culpa é de seus gestores” vi no texto uma realidade da qual fiz e ainda faço parte como desenvolvedor de software: a eterna alegação de que nossas soluções não parecem “boas o bastante”, ou seja, por culpa nossa – desenvolvedores – enquanto sabemos nós que a realidade é outra bastante diferente.

Em seu artigo, Jim Bird afirma que “gerentes – e não desenvolvedores – decidem o que significa qualidade para a organização. O que é bom e o que é ‘bom o suficiente’”. Entenda-se, aqui, gerentes como os responsáveis pelas organizações, diretorias, setores, etc. Aqueles que, de fato, devem – ou pelo menos deveriam – entender sobre as regras de negócio, rotinas operacionais e fluxo de dados que estão incumbidos de gerenciar. Mas não é assim que acontece na prática, infelizmente.

Como gestor, Jim Bird afirma que cometeu um monte de erros e tomou más decisões sobre sua carreira. Cortou qualidade para cortar custos. Deu para as equipes prazos que não podiam ser cumpridos. Fez controle sobre horários e prioridades, tentando espremer os recursos para tornar o cliente ou um executivo de marketing feliz. Foi intransigente com desenvolvedores e testadores que lhes diziam que o software não estava pronto e que eles não tinham tempo suficiente para fazer as coisas corretamente. Deixou dívidas técnicas se acumularem, insistindo que teriam que entregar agora ou nunca, e que de alguma forma fariam tudo certo mais tarde.  Errou, errou feio, mas aprendeu com os próprios erros, afirma ele.

Para Jim Bird – e eu concordo plenamente com ele – uma das principais falhas em projetos de desenvolvimento de software acontece quando os gestores ignoram os sinais de alerta dados pelos desenvolvedores. A dica, nestes casos, é simples: escute os desenvolvedores quando lhe dizem que algo não pode ser feito, ou não deve ser feito, ou tem que ser feito. Os desenvolvedores estão geralmente dispostos a trabalhar muito, para chegar longe. Então, quando eles dizem que não podem fazer algo, ou que não devem fazer algo, preste atenção!

Por experiência própria, vários projetos de desenvolvimento de software foram abandonados e outros caminham a passos de tartaruga por culpa única e exclusivamente dos gestores terem ignorados os sinais de alerta dos desenvolvedores.

Enquanto não pudermos ter gestores com experiência prática, capacitados e atualizados, fica valendo a dica do Jim Bird: “Como gerente, a coisa mais importante que você pode fazer é não enviar sua equipe para o fracasso. E isso não é pedir demais”.