Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
código fontePadronização de nomenclatura - Revista SQL Magazine 100
Este artigo tem por objetivo mostrar, de forma simples e eficiente, como montar uma padronização de estrutura de dados para empresas de qualquer seguimento, com o foco na evolução e aumento do nível de maturidade da construção de bases de dados.
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
SQL Magazine 100
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 100
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 100
A padronização da nomenclatura de estrutura de dados nada mais é do que criar os objetos de banco de dados que possuem as mesmas funções de uma maneira uniforme, onde só de olhar seu nome seja possível identificar o que é, a quem pertence e o que ele faz.
Apesar de parecer algo óbvio, a padronização das estruturas de bases de dados não é uma prática entre a maioria das empresas que tem desenvolvimento próprio ou possuem sistemas feitos por encomenda.
Hoje não é difícil encontrar bases de dados geradas a partir de modelos de classes, onde os atributos descritos em cada classe se transformam em colunas de uma tabela sem nenhum tratamento, e por este motivo, algumas colunas não possuem significado. Por exemplo, observe a coluna “Nome” da Figura 1, este termo não é auto explicativo, ou seja, ele deixa dúvidas. Não é possível afirmar se o “Nome” é o nome do cliente, do atendente ou qualquer outra coisa.
Existem vários outros exemplos que não necessariamente são derivados de modelos de classes. Há casos de tabelas sem significado aparente, com nomes indecifráveis como "XX", "tblTeste", "tbl_001", "Plan1" e etc, e suas colunas seguem com os mesmos problemas de entendimento e na grande maioria, não tem seu comentário preenchido, dificultando ainda mais o entendimento.
É claro que a padronização não é essencial para que uma base de dados funcione adequadamente e nem tem obrigação de tornar os dados confiáveis, mas mostra o nível de maturidade da empresa e dos profissionais responsáveis pela administração ou criação das estruturas de dados.
Então, da mesma forma que usamos endentação para melhorar a visualização e facilitar o entendimento de nossos códigos SQL, é possível adotar padrões simples que vão deixar sua base de dados organizada e de fácil entendimento.
A intenção aqui não é criar um manual de padrões e normas para construção de bases de dados, nosso foco é melhorar a qualidade das estruturas de dados de uma maneira simples e eficiente.
Certamente se a empresa que você trabalha tem um administrador de dados, muitos desses conceitos já são utilizados, mas de qualquer maneira você vai descobrir o porquê foram aplicados.
É possível criar inúmeros modelos de padronização, sendo assim, não existe certo ou errado, mas tome cuidado com os exageros ou falta de critérios, não deixe nenhum item de fora para não gerar duvidas no momento da aplicação.
Regras básicas
Antes de tudo, você deve sempre respeitar as características e limitações do seu SGBD (ler Nota DevMan 1), por exemplo: o Oracle não aceita mais do que 30 caracteres para nomear um objeto, mas temos que concordar que ultrapassar essa limitação, mesmo para os SGBDs que permitem 256 caracteres, seria um exagero.
"
Este é um post disponível para assinantes MVP
Apesar de parecer algo óbvio, a padronização das estruturas de bases de dados não é uma prática entre a maioria das empresas que tem desenvolvimento próprio ou possuem sistemas feitos por encomenda.
Hoje não é difícil encontrar bases de dados geradas a partir de modelos de classes, onde os atributos descritos em cada classe se transformam em colunas de uma tabela sem nenhum tratamento, e por este motivo, algumas colunas não possuem significado. Por exemplo, observe a coluna “Nome” da Figura 1, este termo não é auto explicativo, ou seja, ele deixa dúvidas. Não é possível afirmar se o “Nome” é o nome do cliente, do atendente ou qualquer outra coisa.
Existem vários outros exemplos que não necessariamente são derivados de modelos de classes. Há casos de tabelas sem significado aparente, com nomes indecifráveis como "XX", "tblTeste", "tbl_001", "Plan1" e etc, e suas colunas seguem com os mesmos problemas de entendimento e na grande maioria, não tem seu comentário preenchido, dificultando ainda mais o entendimento.
É claro que a padronização não é essencial para que uma base de dados funcione adequadamente e nem tem obrigação de tornar os dados confiáveis, mas mostra o nível de maturidade da empresa e dos profissionais responsáveis pela administração ou criação das estruturas de dados.
Então, da mesma forma que usamos endentação para melhorar a visualização e facilitar o entendimento de nossos códigos SQL, é possível adotar padrões simples que vão deixar sua base de dados organizada e de fácil entendimento.
A intenção aqui não é criar um manual de padrões e normas para construção de bases de dados, nosso foco é melhorar a qualidade das estruturas de dados de uma maneira simples e eficiente.
Certamente se a empresa que você trabalha tem um administrador de dados, muitos desses conceitos já são utilizados, mas de qualquer maneira você vai descobrir o porquê foram aplicados.
É possível criar inúmeros modelos de padronização, sendo assim, não existe certo ou errado, mas tome cuidado com os exageros ou falta de critérios, não deixe nenhum item de fora para não gerar duvidas no momento da aplicação.
Regras básicas
Antes de tudo, você deve sempre respeitar as características e limitações do seu SGBD (ler Nota DevMan 1), por exemplo: o Oracle não aceita mais do que 30 caracteres para nomear um objeto, mas temos que concordar que ultrapassar essa limitação, mesmo para os SGBDs que permitem 256 caracteres, seria um exagero.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Roberto De Angelantonio Jr.
Bacharel em Administração de Sistemas da Informação pela Universidade Ibero-Americana. Atua na área de sistemas a mais de vinte anos, sendo que, na maior parte da carreira trabalhou como Administrador de Dados. Experiência em implementar e reestruturar a área de Administração de Dados em diversas em...
O que você achou deste post?
Cursos relacionados
Publicidade
