Olá a todos!!

Hoje quero compartilhar com vocês um assunto de suma importância na área de TI: a comunicação.

Hoje em dia se fala muito sobre padronização, desenvolvimento orientado a processos, mapeamento de fluxos e etc. Mas, isso tudo vai por água abaixo quando não existe um processo de comunicação eficiente entre as áreas envolvidas.

Quero deixar claro que não tenho nada contras as metodologias de desenvolvimento de software. Pelo contrário, acho bastante importante uma empresa adotar e/ou desenvolver uma metodologia. Sem ela, o desenvolvimento de um software se torna caótica e a qualidade do mesmo fica comprometida.

Mas, quando falamos em comunicação, estamos também referenciando a recurso principal no processo de desenvolvimento: o recurso humano. Através dele é que surgem a maioria das falhas de comunicação.

Imaginem a cena: um analista informa para um cliente uma data provável de entrega de um módulo do software. O analista não informa ou esquece de avisar ao gerente de projeto sobre essa data. O gerente de projeto monta um cronograma, estabelece uma outra data (posterior a que foi passada para o cliente) e informa o cliente sobre a nova data. Por fim, o cliente fica bastante insatisfeito, pois foi feita uma programação prévia sobre a primeira data.

Este é um exemplo simples que poderia ser resolvido com uma simples anotação da data (fato importante) ou uma ata da reunião.

No dia a dia das empresas, qualquer situação pode ocasionar uma falha de comunicação. E claro, nosso foco aqui é a área de TI, mas as falhas de comunicação acontecem em qualquer lugar, até mesmo dentro de casa.

Portanto, é necessário o estabelecimento de padrões e processos de comunicação que utilizem ferramentas que facilitem o acesso às informações importantes para o perfeito funcionamento das engrenagens de uma empresa, principalmente em empresas de desenvolvimento de software, onde o processo é dinâmico e o contexto muda com muita freqüência.

Até +.

Estamos de volta. Bom, nesta última parte sobre padronização no banco de dados, falaremos sobre um assunto que é desconhecido por muitos: o uso de domínio como tipo de dado.

Domínios são essencialmente tipos de dados com restrições (constraints), que podem ser uma checagem de valores (check constraints), uma verificação de campos NOT NULL ou atribuição de um valor DEFAULT.

A utilização de domínios, como tipo de dado, é útil para manter as restrições, que são comuns à várias colunas, em um só lugar, facilitando a manutenção dos mesmos. Por exemplo, podemos ter várias colunas de email que possuem uma checagem para validar o endereço. Podemos então criar um domínio para esta situação, no lugar de colocar esta restrição para cada coluna.

Lembrando que, apesar do comando CREATE DOMAIN seguir o padrão SQL ANSI, nem todos os SGBDs dão suporte a ele. O Oracle, por exemplo, não possui este comando. O equivalente no Oracle é o comando CREATE TYPE.

No PostgreSQL, a criação de um domínio é feita pelo comando abaixo.

CREATE DOMAIN name [ AS ] data_type
[ DEFAULT expression ]
[ constraint [ ... ] ]

onde constraint é:

[ CONSTRAINT constraint_name ]
{ NOT NULL | NULL | CHECK (expression) }


No exemplo abaixo, utilizando os campos de email para demonstrar o uso do domínio.

-- tabela antes de utilizar o domínio
CREATE TABLE tb_pessoa (
id_pessoa SERIAL PRIMARY KEY,
ds_email_1 varchar(50),
ds_email_2 varchar(50),
ds_email_3 varchar(50),
CONSTRAINT tb_pessoa_ds_email_1_check CHECK (ds_email_1 ilike '%@%.com' or ds_email_1 ilike '%@%.com.br'),
CONSTRAINT tb_pessoa_ds_email_2_check CHECK (ds_email_2 ilike '%@%.com' or ds_email_2 ilike '%@%.com.br'),
CONSTRAINT tb_pessoa_ds_email_3_check CHECK (ds_email_3 ilike '%@%.com' or ds_email_3 ilike '%@%.com.br')
);

-- criação do domínio
create domain email varchar(50) check (value ilike '%@%.com' or value ilike '%@%.com.br');

-- tabela depois de utilizar o domínio
CREATE TABLE tb_pessoa (
id_pessoa SERIAL PRIMARY KEY,
ds_email_1 email,
ds_email_2 email,
ds_email_3 email
);

Abaixo estão algumas sugestões de domínios.

Olá pessoal. Vamos dar continuidade ao tema sobre padronização nos bancos de dados. Nesta terceira parte, abordaremos as nomenclaturas das colunas das tabelas e índices.

Assim como a nomenclatura das tabelas (abordado na parte 2), as colunas podem ter seus nomes prefixados para facilitar o entendimento e rápida identificação do tipo de dado atribuído às mesmas. E também devem ter seus nomes criados de forma a identificar o conteúdo que guardam, ou seja, nada de “col1”, “col2” e etc. Abaixo estão os prefixos sugeridos.

cd_ (Código gerado pela aplicação)
id_ (Identificador auto-incremento))
nr_ (Número)
dt_ (Data)
vl_ (Valor)
ds_ (Descrição)
nm_ (Nome)
tp_ (Tipo)
qt_ (Quantidade)
st_ (Status)
in_ (Indicador)
ob_ (Binário - Imagens, arquivos etc.)
sg_ (Sigla)

EX: cd_forma_pagamento
       __ ______________
                      |------------ Identifica o conteúdo do atributo
         |---------------------- Identifica o tipo de dado do atributo


Com isso, podemos, por exemplo, identificar na leitura de uma coluna “dt_pagamento” que ela é um campo que armazena uma data, sem precisar olhar a definição física da tabela ou modelo de dados. Isto facilita a programação, no sentido de que o programador não precisa recorrer a todo instante a estes artefatos para saber como tratar o dado.

Para os nomes de índices, podemos ter duas configurações possíveis. A primeira é ter o nome do índice com o nome da tabela a que está vinculada, seguido de um número, como segue abaixo.

idx_tb_pagamento1
idx_tb_pagamento2
idx_tb_pagamento3
...

A outra, é termos o nome do índice com o nome da coluna que ele está vinculado, conforme visto abaixo. É claro que isto se aplica apenas para índices simples, ou seja, de uma única coluna. Para índices compostos, a única alternativa viável é a primeira.

idx_cd_forma_pagamento
idx_id_usuario

Em minha opinião, para índices simples, a segunda forma é mais clara, pois temos uma noção clara de qual coluna o índice está vinculado.
No próximo post, ainda sobre o tema de padronização, abordaremos o uso dos domínios nas definições dos tipos de dados das colunas. Até mais.

Sejam bem-vindos. Dando continuidade a nossa série relacionada à padronização de bancos de dados, hoje iremos comentar um exemplo de padronização de nomenclatura, relacionados aos objetos do banco de dados, como tabelas, índices e etc.

Uma prática bastante comum é utilizar prefixos que identificam o tipo de objeto no database. Um exemplo que pode ser seguido é o que está descrito na tabela abaixo.

tb_ (Tabelas)
vs_ (Visões)
pr_ (Procedures)
ru_ (Regras)
dt_ (Data Types)
tg_ (Triggers)
idx_ (Índices)
fn_ (Funções)
ob_ (Objetos)
sq_ (Seqüências)
pg_ (Packages)
sn_ (Sinônimos)

Os nomes de todos os objetos, especialmente das tabelas, podem ser formados pelo seu respectivo prefixo seguido dos termos que identificam o conteúdo do objeto, separados pelo caractere “_” e em minúscula.

Ex.: TABELA
tb_forma_pagamento
__ _______________
|------------------------ Identifica o tipo do objeto no banco de dados
                |--------- Identifica o conteúdo do objeto

Podemos ainda seguir algumas regrinhas:

• Não usar “Ç”, acentos, hífen, #, @, %, $. !, *, +, -, /, = ;
• Os nomes dos objetos devem estar no singular;
• Não usar abreviaturas, nem outros símbolos que podem nos levar a ter uma interpretação ambígua do objetivo do objeto.

Os nomes dos objetos do tipo seqüência (sequences), usados para definir os valores incrementais dos identificadores das tabelas, podem ser formados pelo prefixo, seguidos do nome da tabela.

Ex.:
Tabela: tb_forma_pagamento
Seqüência: sq_tb_forma_pagamento

O objetivo de fazermos isto com as sequences é ter um relacionamento direto com a tabela que este objeto está relacionado, bem como facilitar em alguma manutenção, seja quando precisamos fazer consultas no catálogo do sistema do banco de dados, seja para uma listagem ou manipulação dos objetos, quando estamos trabalhando com os metadados.

Por hoje é só. Na próxima parte, falaremos um pouco sobre a padronização das nomenclaturas das colunas das tabelas. Até lá.