1
UNIVERSIDADE SÃO JUDAS TADEU - USJT
Osvaldo Rodrigues Sérgio
NOMENCLATURA EM BANCO DE DADOS
São Paulo 2010
2
UNIVERSIDADE SÃO JUDAS TADEU - USJT
Osvaldo Rodrigues Sérgio
NOMENCLATURA EM BANCO DE DADOS
Trabalho de Conclusão de Curso apresentado ao Pós-graduação Latu Sensu da Universidade São Judas Tadeu, como requisito parcial para conclusão do curso de Especialização em Engenharia de Software. ORIENTADOR: Prof. Mst Aluízio Saiter
São Paulo 2010
3
UNIVERSIDADE SÃO JUDAS TADEU - USJT
Osvaldo Rodrigues Sérgio
NOMENCLATURA EM BANCO DE DADOS
Trabalho de Conclusão de Curso apresentado ao Pós-graduação Latu Sensu da Universidade São Judas Tadeu, como requisito parcial para conclusão do curso de Especialização em Engenharia de Software. ORIENTADOR: Prof. Mst Aluízio Saiter
Aprovada em ____________________________
____________________________________ ORIENTADOR: Prof. Mst Aluízio Saiter
4
À todos que, de alguma forma ajudaram-me a realizar este trabalho.
5
RESUMO
Este trabalho tem por objetivo contribuir para conscientização de uso de normas de
padronização na nomenclatura utilizada objetos e atributos nos bancos de dados
relacionais (tabelas (entidades), atributos, chaves primárias, chaves estrangeiras,
visões (views), esquemas (schemas), procedimentos (procedures) e funções
(functions)). Tem-se por base a norma ISO/IEC 11.179-5.
Palavras-chave: Banco de dados; padronização; nomenclatura
6
ABSTRACT
This work has objetive to contribute for awareness about the use of rules of
standardization of nomenclature used by objects e attributes in data base relationals
(tables (entity), attributes, primarys keys, foreign keys, views, schemas, procedures
and functions. The base the norm ISO/IEC 11,179-5.
KeyWords: DataBase; standardization; nomenclature
7
SUMÁRIO
INTRODUÇÃO ...................................................................................................................................... 8
ANÁLISE DO PROBLEMA ........................................................................................................................ 10
ESTUDO DE CASO .................................................................................................................................. 13
SOLUÇÕES PROPOSTAS ......................................................................................................................... 17
PEQUENA EXPLANAÇÃO SOBRE BANCO DE DADOS ............................................................................. 18
NOMENCLATURAS ................................................................................................................................. 21
1ª SUGESTÃO - PROPOSTA DE NOMENCLATURA.................................................................................. 23
1. Objetos do banco de dados: .................................................................................................... 23
2ª SUGESTÃO – DICIONÁRIO DE DADOS BANCO DE DADOS ................................................................ 28
COMPARAÇÃO ENTRE AS PROPOSTAS .................................................................................................. 31
CONCLUSÃO .......................................................................................................................................... 33
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................................................. 35
ANEXOS ................................................................................................................................................. 36
1 – Apêndice A................................................................................................................................... 36
8
INTRODUÇÃO
Muito se fala sobre a importância de documentação e padronização na
confecção de projetos de softwares, de como isto é um facilitador para o trabalho de
codificação e mesmo de manutenção em sistemas de aplicativos.
Porém, pouco se fala sobre como deve ser documentado e padronizado o
banco de dados, especialmente a normatização da nomenclatura utilizada em banco
de dados (entidades, atributos, chave primária, chave estrangeira e outros).
Esta monografia visa aprofundar sobre como esta normatização facilitaria a
documentação e a manutenção do banco de dados e as vantagens que isto
acarretaria em todo o processo de confecção da codificação dos programas que o
acessa.
A resistência dos profissionais da área do uso de padrões vão desde a
aversão à documentação, principalmente no que se refere ao banco de dados, até a
clássica “desculpa” de que o projeto está atrasado e que não dará tempo de fazer as
revisões técnicas do código, sendo portanto desnecessário o uso de padrões.
Talvez esta “cultura” esteja dissiminada devido haver no mercado a
fragmentação do processo de codificação, passando para profissionais do tipo “free-
lancers” a responsabilidade de confeccionar parte do código, informando tão
somente o que esta parte de código deverá realizar.
9
Outra probabilidade estaria no fato de não haver um modelo aceito
universalmente por todos, apesar de já existir uma norma internacional que foi
imposta.
10
ANÁLISE DO PROBLEMA
Ao analisarmos código de programas de computadores escritos por
programadores, sejam em versões iniciais ou versões de manutenção, é muito
comum não encontrarmos a documentação deste programa, ainda mais se for uma
versão mais antiga, por volta de 05 anos de uso, nem encontrarmos uma
padronização no programa, seja de nomes de variáveis, de funções, de rotinas ou
de modo de programação. Mais raro ainda é encontrar documentação do dicionário
de dados do banco de dados, onde é descrito todo o banco de dados que este e
outros programas utilizam.
É natural, com o passar dos anos, que haja novos requisitos e que seja
necessário alterar ou adaptar o banco de dados. Relatar estas mudanças no
dicionário de dados é o que não ocorre, seja por simples descaso ou por não existir
o mesmo.
Neste caso, o analista ou programador que for analisar o código, precisará
analisar o programa inteiro para tentar compreender o que está sendo realizado pelo
código.
Com referência ao banco de dados, muitas vezes, os nomes dados a campos
do banco de dados não são nem um pouco sugestivos, tendo nomes como: campo1,
11
campo2, campo3, etc. Alguns nomes são melhores denominados, como: código,
nome, estado, descrição, valor, etc.
O problema do primeiro tipo de denominação é descobrir o que cada campo
está armazenando. No segundo é mais simples deduzir o que cada campo
armazenará. Nos dois casos, não sabemos de qual tabela pertence estes campos.
No caso dos relacionamentos entre as tabelas, também é uma análise a parte. No
primeiro caso, se uma tabela possui como chave primária o campo campo1, na
tabela em que esta chave é exportada, geralmente vai com nome diferente e com
uma contagem sequencial, ou seja, pode estar com o nome campo20, por exemplo.
E este tipo de denominação de nomes não está restrito à programas de
aplicativos vendidos em lojas, tipo Administração de Condomínios, Estoque e outros,
mas a empresas que desenvolvem aplicativos internos.
Quando uma equipe é contratada para analisar um programa e fazer
aperfeiçoamentos nele, a principal reclamação recai sobre o banco de dados, pois,
geralmente o banco de dados não está normalizado e há muitos dados redundantes,
causados pelo não levantamento de requisitos para sua concepção. E na análise
deste banco, a dificuldade de identificação dos conteúdos armazenados e a que se
refere este conteúdo, provoca atrasos nos prazos estabelecidos pelos gerentes ao
cliente. É bastante comum, devido a estes fatores, haverem na empresa vários
banco de dados para cada sistema implantado na organização, onde o usuário deve
repetir os dados para cada sistema existente. Com uma padronização, este
problema poderia ser, se não eliminado, pelo menos amenizado. E isto não ocorre
somente em pequenas empresas mas também nas médias e grandes empresas.
A necessidade de informações faz com que as organizações preocupem-se
em absorver dados das mais diversas maneiras e fontes. O grande problema é que,
12
muitas vezes, não existe o gerenciamento destas informações, que permeiam em
uma empresa ou órgão, a partir da criação e manutenção do banco de dados, o que
reflete na incoerência dos dados, podendo, assim, ocasionar significativos
problemas para as futuras análises. As empresas tem as informações, porém, não
tem como recuperá-las, ou recupera-as em parte. Um dos métodos de gerenciar as
informações é ter conhecimento delas, o que é facilitado pela implantação de
padronização.
A implantação de programas de padronização em banco de dados é vista
muitas vezes como mais uma burocracia e “burrice”, mas esquece que há
padronizações em linguagens de programação, como a Linguagem Java, em que
convencionou-se que todas as classes sejam escritas com a primeira letra em caixa
alta e as demais em caixa baixa de cada palavra que a compõe e que os métodos
sejam escritos em caixa baixa a primeira palavra, e em caixa alta a primeira letra das
demais palavras.
A princípio, houve vários argumentos contra este tipo de convenção, mas com
o passar dos anos e com o crescimento da linguagem, notou-se que é facilmente
identificável cada parte do programa. O mesmo espera-se para o banco de dados,
quando houver uma padronização ampla.
O maior dano que a não padronização acarreta é o aumento de custo na
manutenção destes sistemas, em que muitas vezes o retrabalho sai mais caro do
que reescrever todo ou parte do sistema.
13
ESTUDO DE CASO
Uma empresa de monitoramento de alarmes desenvolveu um sistema para
seu cliente, onde informações enviados de um painel de monitoramento de alarmes,
eram coletadas via porta serial pelo sistema e exibido no monitor o local onde o
alarme ocorreu. Este sistema foi desenvolvido 03 anos antes, sendo bem recente
sua confecção. Esta empresa solicitou uma atualização do sistema para acrescentar
novas funcionalidades e recursos, que fora solicitado pelo seu cliente.
Fazendo a verificação do sistema, constatou-se que não havia nenhuma
documentação sobre o sistema e nenhuma padronização de variáveis ou de rotinas,
sendo que várias rotinas eram repetidas em vários locais. Não havia comentários no
código também. Iremos focar somente a parte de banco de dados, no qual também
não tinha nenhuma documentação, dicionário de dados do banco de dados ou um
padrão na definição dos nomes dos campos.
O banco de dados utilizado neste sistema era o Microsoft Access, com o
nome de Sensor.mdb. Abaixo segue a relação das tabelas e seus respectivos
atributos, com o tipo de campo de cada um.
Tabela: Sensores
Nome do campo: Tipo de Dados
NPonto Número
NPorto Número
NPartição Número
NSensor Número
14
Descrição Texto
PosiçãoX Número
PosiçãoY Número
SeguirPartição Sim/Não
CorArmDes Número
CorArmAti Número
CorArmRes Número
CorByP Número
CorDes Número
Situação Número
Ponto Número
Condições Texto
Tipo Número
Tabela: TipoSensor
Nome do campo: Tipo de Dados
Tipo Número
Descrição Texto
Tabela: Partição
Nome do campo: Tipo de Dados
Porto Número
Partição Número
Descrição Texto
Tabela: Código
Nome do campo: Tipo de Dados
Código Texto
Descrição Texto
Tabela: 52@52@&
Nome do campo: Tipo de Dados
48@53@& Memorando
56@52@& Memorando
57@52@& Texto
Este sistema também gera, mensalmente, uma novo banco de dados, onde
são armazenados as ocorrências do sistema de alarme do referido mês, em que o
nome do banco de dados é Ano_Mês.mdb (AAAA_MM.mdb). Segue abaixo a
relação da tabela:
15
Tabela: Ocorrências
Nome do campo: Tipo de Dados
Contador Número
DataM Texto
HoraM Texto
DataP Texto
HoraP Texto
Porto Texto
Partição Texto
Sensor Texto
Ocorrência Texto
Operador Texto
Outros Texto
De posse destes dados, foi realizado uma análise do banco de dados. Porém,
como os nomes da maioria dos atributos não indicavam o que significavam,
levantamos os problemas:
1 – O que significava e o que armazenava cada atributo;
2 – A falta de relacionamentos entre as tabelas;
3 – Tabela e atributos com nomes totalmente estranhos (tabela
52@52&);
4 – Tabela de ocorrências não mantinha os tipos de dados compatíveis
com os das tabelas do sistema.
5 – Nomes de tabelas e atributos com caracteres especiais.
Para solução deste problema, foi proposto os seguintes passos:
1 – Executar o sistema linha a linha para entender como o sistema
trabalhava com os dados do banco de dados;
2 – Estudar o painel de monitoramento, para analisar os dados
enviados pelo mesmo ao sistema;
No trabalho realizado, devido aos problemas apresentados, a atualização do
sistema, que inicialmente tinha uma previsão de 03 meses, teve um atraso de 04
meses, sendo 01 mês referente ao banco de dados, totalizando 07 meses para
16
execução desta atualização. O sistema foi praticamente reescrito e o banco de
dados foi remodelado para melhor performance, ou seja, o nosso cliente teve um
acréscimo de custos devido a falta de documentação e padronização, custos estes
que poderiam não existir caso houvesse uma preocupação de se documentar, ou
pelo menos colocar comentários no código do sistema.
17
SOLUÇÕES PROPOSTAS
Nesta monografia há dois tipos de soluções apresentadas para o problema da
denominação dos nomes dos campos do banco de dados.
Na primeira proposta, será utilizado o uso de padronização, com base na
International Organization For Stantardadization / International Electrotechnical
Commission - ISO/IEC 11.759 (Organização Internacional de Padronização /
Comissão Internacional Eletrotécnica) na nomenclatura dos objetos que compõe um
banco de dados, em que apresento uma pequena introdução.
Na minha segunda proposta, será utilizado a implantação e uso do dicionário
de dados do banco de dados completo. Nesta proposta, será feito uma junção de
vários temas sobre o assunto e elementos utilizados por mim, já que a literatura
disponível, apesar de mencionarem sobre o tema, não os aprofunda.
18
PEQUENA EXPLANAÇÃO SOBRE BANCO DE DADOS
Banco de dados ou base de dados é um conjunto de registros dispostos em
estrutura regular que possibilita a reorganização dos mesmos e produção de
informação. Um banco de dados normalmente agrupa registros utilizáveis para um
mesmo fim. (Wikipédia). Segundo Celso Henrique Poderoso de Oliveira, um banco
de dados é um conjunto coerente e lógico de dados relacionados que possuem
significância intrínseca. Esses dados representam aspectos do mundo real e devem
ser mantidos para atender aos requisitos da empresa. Estes dados estão dispostos
em uma ordem predefinida para atender a determinadas necessidades dos usuários.
Como há mais de um tipo de banco de dados (hierárquico, relacional, rede e
objeto-relacional), nesta monografia, atentaremos para o banco de dados relacional,
mesmo que seja aplicado à outros modelos.
No modelo relacional, temos objetos a qual nomeamos de Esquemas, que é o
banco de dados em si, Entidades, também chamadas de tabelas, tuplas ou registros,
atributos, visões (view), procedimentos (procedures), chave primária (primary key),
chave estrangeira (foreign key) e chave única (unique key).
Entidades, mais conhecidas como tabelas, são os objetos centrais e mais
importantes em um banco de dados relacional. O propósito principal de qualquer
19
banco de dados é armazenar dados gravados logicamente em tabelas. Um dos
princípios no desenvolvimento do banco de dados relacional é que cada tabela
armazena informações sobre um específico tipo de coisa ou Entidade. (Kriegel, Alex
and Trukhnov, Boris M. SQL Bible, Second Edition, página 83).
Tuplas, comumente chamadas de registros, são linhas horizontais de dados e
cada registro contém dados sobre um item da entidade, por exemplo, um registro de
cliente contém informações sobre um único cliente.
Atributos são campos onde armazenamos um tipo particular de informação
para todos os registros da entidade, por exemplo, um atributo nome contém
informações sobre os nomes dos clientes.
Visões (views) são tabelas lógicas, em que selecionamos somente o que é
relevante para determinado usuário. Isto é feito para preservar a confidencialidade
de alguns atributos. As visões não são tabelas físicas, ou seja, não há dados
armazenados nela, somente comandos SQL (Structure Query Language) que
acessam as tabelas e retornam os dados desejados.
Procedimentos (store procedures) são funções internas aos bancos de dados
que realizam rotinas que o DBA (DataBase Administrator) queira automatizar. Cada
fabricante de banco de dados tem linguagem proprietária sobre os procedimentos.
Chave primária (Primary Key) são atributos que identificam unicamente uma
instância da entidade que representa.
Chave estrangeira (Foreing Key) são as chaves primárias que são exportadas
para outra entidade com a finalidade de realizarmos os relacionamentos do banco
de dados.
20
Chave única (Unique Key) são os atributos que, não podem ser chave
primária por não atender aos requisitos de chave primária, porém não podem ter
valores repetidos na tabela.
21
NOMENCLATURAS
Há atualmente a norma ISO/IEC 11.179, que tenta padronizar os nomes
atribuídos aos componentes do banco de dados. Por ser muito genérica e de pouco
conhecimento, ainda não foi absorvida pelos fabricantes de software e pelos
programadores.
Em vários fóruns sobre o tema, há muita discrepância entre os
programadores, sendo a favor ou sendo contra a implementação da padronização.
Muitos usuários acham isto uma completa tolice, que acarretaria em mais
documentação e restrição à programação, já que teriam que “decorar” as regras de
nomenclatura. Outros acham a idéia interessante, porém como cada organização
tem sua própria padronização, isto limita e/ou atrapalha na hora de codificar o
programa.
O que muitos programadores esquecem é que na codificação de um
programa, as idéias e a lógica estão “frescas” na memória e que é fácil lembrar-se
de detalhes. Porém, após algum tempo, estes detalhes são perdidos e torna-se
trabalhoso fazer manutenções no código. Isso quando é o mesmo programador.
Quando um outro programador irá continuar ou modificar o código, será necessário
uma perda de tempo para que o mesmo leia o código e entenda, não a lógica, mas
22
os termos utilizados pelo antecessor, o que causa um retrabalho desnecessário se
estivesse utilizando um padrão na codificação.
O mesmo ocorre na parte de banco de dados. Ocorrem fatos, dentro de uma
mesma organização, em que há ambiguidade para um mesmo banco de dados. Por
exemplo na tabela cliente, um atributo é chamado de Nome e em uma tabela
funcionario também é chamado de Nome. Na codificação, é muito comum que o
programador referencie um atributo de uma tabela na intenção de referenciar este
atributo a uma outra tabela.
Para evitar estes erros, é necessária a padronização. Como dito antes, muitas
empresas possuem padrões internos, e geralmente estes padrões são diferentes
entre as empresas. Como é comum no mercado a terceirização da codificação, um
programador pode codificar programas de várias empresas, o que torna trabalhoso
para o mesmo lembrar-se do padrão de cada um, o que leva a considerar a
padronização uma bobagem.
Lendo as padronizações de diversas empresas, nota-se que as diferenças
entre elas são pequenas, o que tornaria a implementação de uma padronização
universal mais simples.
23
1ª SUGESTÃO - PROPOSTA DE NOMENCLATURA
1. Objetos do banco de dados:
Todos os objetos poderão ser identificados com até 30 (trinta) caracteres,
serem em caixa alta e no singular.
Não poderão ser utilizadas palavras reservadas (vide apêndice A) e
caracteres especiais, incluindo parênteses, aspas, pontos de interrogação, dólar ($),
hash (#), barra (/), contra-barra (\) e hífen (-) .
Na tabela abaixo segue objetos, regras, exemplos e motivo das
nomenclaturas propostas.
Objeto Regras Exemplo Motivo
Banco de dados Iniciado por DB_
- Ter um nome relevante ao que armazena, ou; - Conter uma identificação resumida do sistema;
DB_CLIENTE DB_RH
A prefixo DB_ facilita o gerenciamento e o reconhecimento imediato de um objeto banco de dados.
Tabela Iniciado por TB_
- Ter um nome relevante ao que armazena;
TB_CLIENTE TB_FUNCIONARIO
Segue a norma ISO/IEC 11.179-5 e representa a entidade no banco de dados.
Visões (views) Iniciado por VW_
- Ter um nome relevante ao que armazena;
VW_CLIENTE VW_FUNCIONARIO
Idem ao da tabela
24
Objeto Regras Exemplo Motivo
Visões materializadas Iniciado por VM_
- Ter um nome relevante ao que armazena;
VM_CLIENTE VM_FUNCIONARIO
Idem ao da tabela
Tabelas de sistema Iniciado por TS_
- Ter um nome relevante ao que armazena;
TS_ESTADO TS_ESTADO_CIVIL
Idem ao da tabela.
Tabelas de log de operações Iniciado por TL_
- Ter o nome da tabela em que armazenará o log;
TL_CLIENTE
Idem ao da tabela.
Constraint Check Iniciado por CK_
- Ter o nome do atributo;
CK_CLI_SEXO Informa a tabela e o atributo a que pertence e impede de haver repetições de nome das constraint no banco de dados.
Constraint Primary Key (chave primária) Iniciado por PK_
- Ter o nome do atributo;
PK_CLI_COD Informa a tabela e o atributo a que pertence e o impede de haver repetições de nome das constraint no banco de dados.
Constraint Foreign Key (chave estrangeira) Iniciado por FK_
- Ter o nome do atributo da tabela de origem; - Ter o nome da tabela destino;
FK_CLI_COD_PED Informa a tabela de origem do atributo, o nome do atributo e a tabela que recebe o atributo.
Constraint Unique Key (chave única) Iniciado por UQ_
- Ter o nome do atributo;
UQ_CLI_CPF Informa a tabela e o atributo que é chave única e não chave primária.
25
Objeto Regras Exemplo Motivo
Index Iniciado por IN_
- Ter o nome da tabela e dos atributos que o compõe;
IN_CLI_NOM_END Informa a tabela e os atributos que o compõe.
Funções Iniciado por FC_
- Ter um nome relevante sobre o que faz;
FC_CALCULA_DV Informa o que a função realiza.
Stored Procedures ( Procedimentos armazenados) Iniciado por SP_
- Ter um nome relevante sobre o que faz; - Ter a tabela que será afetada;
SP_ALTERA_CLI Informa o que o procedimento faz e a tabela que afeta.
Trigger Before / After Insert (Gatilho antes / depois da inserção) Iniciado por TBI_ TBA_
- Ter o nome da tabela; - a tabela deve perder o prefixo TB_, exceto se for tabela de log;
TBI_CLIENTE TAI_CLIENTE TBI_TL_CLIENTE TAI_TL_CLIENTE
Informa qual em qual tabela gera o gatilho e quando.
Trigger Before / After Update (Gatilho antes / depois da atualização) Iniciado por TAU_ TBU_
- Ter o nome da tabela; - a tabela deve perder o prefixo TB_, exceto se for tabela de log;
TBU_CLIENTE TAU_CLIENTE TBU_TL_CLIENTE TAU_TL_CLIENTE
Informa qual em qual tabela gera o gatilho e quando.
Trigger Before / After Delete (Gatilho antes / depois da exclusão) Iniciado por TAD_ TBD_
- Ter o nome da tabela; - a tabela deve perder o prefixo TB_, exceto se for tabela de log;
TBD_CLIENTE TAD_CLIENTE TBD_TL_CLIENTE TAD_TL_CLIENTE
Informa qual em qual tabela gera o gatilho e quando.
26
Objeto Regras Exemplo Motivo
Trigger Before / After Insert /Update/Delete (Gatilho antes / depois da inserção/ atualização/ exclusão) (Trigger after/before all) Iniciado por TAA_ TBA_
- Ter o nome da tabela; - a tabela deve perder o prefixo TB_, exceto se for tabela de log;
TBA_CLIENTE TAA_CLIENTE TBA_TL_CLIENTE TAA_TL_CLIENTE
Informa qual em qual tabela gera o gatilho e quando.
Trigger Instead Of (Gatilho ao invés de) Iniciado por TIO_
- Ter o nome da tabela; - a tabela deve perder o prefixo TB_, exceto se for tabela de log;
TIO_CLIENTE TIO_TL_CLIENTE
Informa qual em qual tabela gera o gatilho e quando.
Obs: Nesta proposta estão os componentes mais utilizados em um banco de dados.
2. Objetos de atributos
Todos os atributos poderão ser identificados com até 30 (trinta) caracteres.
Um atributo não pode ser uma palavra reservada e nem conter caracteres especiais,
incluindo parênteses, aspas, pontos de interrogação, dólar ($), hash (#), barra (/),
contra-barra (\) e hífen (-) e acentuação.
Deve conter, nos 3 (três) ou 4 (quatro) caracteres iniciais, o nome da tabela
abreviado, logo após um sublinhado e o nome do atributo, podendo este ser
abreviado, conforme a tabela abaixo. O nome do atributo deve conter no mínimo 3
(três) caracteres, exceto quando for auto-explicativa (KG, GB, MB, KM, etc) e ser em
caixa alta.
27
Caso não seja possível a utilização de acrônimos ou a abreviação ainda ultrapasse o
limite de 30 (trinta) caracteres, utilize as técnicas abaixo, na ordem dada, para criar
uma abreviação de comprimento apropriado.
Remova as vogais da palavra
Ex: objeto viraria objt, calamidade ficaria clmdd.
Remova, sequencialmente as consoantes, a partir do final da palavra
Ex. capacidade => cpcdd => cpcd.
Na tabela abaixo, segue alguns atributos e sugestões de abreviação, por ordem
alfabética.
Atributo Sugestão Exemplo
Bairro BAI CLI_BAI
Cadastro INSS PIS CLI_PIS
Cadastro Pessoa Física CPF CLI_CPF
Carteira CRT CLI_CRT_MOTORISTA
Carteira Nacional de Habilitação
CNH CLI_CNH
Certidão CTD CLI_CTD_CASAMENTO
Cidade CID CLI_CID
Código COD CLI_COD
Código Endereçamento Postal
CEP CLI_CEP
Complemento COMP CLI_COMP
Data DT CLI_DT_NASCIMENTO
Descrição DESC CLI_DESC
Endereço END CLI_END
Hora HR CLI_HR_CADASTRO
Logradouro LOG CLI_LOG
Nome NOM CLI_NOM
Número NRO CLI_NRO
Quantidade QTD CLI_QTD
Registro Geral RG CLI_RG
Sexo SEX CLI_SEX
Sigla SG UF_SG
Situação ou Status ST CLI_ST
Taxa TX CLI_TX_GLICOSE
Telefone TEL CLI_TEL
Tipo TP CLI_TP_SANGUINEO
Título TIT CLI_TIT_ELEITORAL
Valor VLR CLI_VLR_RENDA
Obs: Nesta sugestão, não está sendo considerado nenhum tipo de normalização.
28
2ª SUGESTÃO – DICIONÁRIO DE DADOS BANCO DE DADOS
Para a confecção do dicionário do banco de dados, devemos ter em mente
que este trabalho deve ser realizado em paralelo com o desenvolvimento do
software.
No início do dicionário, deverá ser indicado o nome do banco de dados, como
exemplo abaixo:
Banco de dados: DB_CLIENTE
Após, vem a entidade (tabela) e seus respectivos atributos, como no exemplo
abaixo.
Entidade: TB_CLIENTE
Atributo: CLI_COD
Propriedade Descrição
O que armazena Código do cliente.
Datatype Inteiro
Tamanho 4 bytes
Domínio Número positivo, de 0 à 9
Valor mínimo 1
Valor máximo 231
Regra de negócio 1, 2, 4
Sistemas que o
utilizam
Aqui anotar todos os sistemas que o acessam, exemplo,
Sistema de Vendas .
Programas que o
utilizam
Aqui anotar todos os programas, funções, rotinas e/ou
classes que o acessam, exemplo frmCliente, frmVenda.
Relatórios que o
utilizam
Aqui anotar todos os relatórios que o acessam, exempo
rptCliente.
29
Para cada atributo da entidade, deverá ser anotado todos os dados
solicitados. Lembrando que no decorrer do desenvolvimento da codificação, é
necessário que estes dados sejam atualizados sempre que necessário. Isto facilitará
o término do dicionário de dados e diminuirá a probabilidade de esquecer de anotar
algum dado.
Um detalhe neste dicionário de dados está na regra de negócio. Muitas vezes,
um atributo possui a mesma ou as mesmas regras de negócio de outro atributo.
Para evitar a repetição de regras várias vezes no dicionário de dados e também de
que, se uma regra sofrer alteração, ter que percorrer todo o dicionário de dados para
fazer a correção e ficar sujeito a inconsistência nos dados, é aconselhável fazer um
apêndice com as regras de negócio, numerando-as e no espaço destinado a regra
de negócios, colocar o número da respectiva regra a que o atributo esteja sujeito.
Exemplo:
APÊNDICE – REGRAS DE NEGÓCIO
Regra Descrição
1 Campo chave primária
2 Valor nulo não permitido
3 Campo chave estrangeira
4 Este conteúdo deverá gerado pelo sistema
5 Cada palavra deverá começar com caixa alta, as demais com caixa
baixa. Palavras de ligação deverão permanecer em caixa baixa (da, do,
de, etc)
6 Não poderá conter dois espaços entre as palavras
7 Não poderá começar com espaços
... ...
E assim sucessivamente.
Lembrando que, as regras de negócio deverão ser o mais claro e simples
possível e deve evitar regras compostas, ou seja, se uma regra puder ser dividida
30
em duas ou mais, isto deverá ser feito. No exemplo dado, a regra de número 5 pode
ser dividida em duas, como mostrado abaixo:
5 Cada palavra deverá começar com caixa alta, as demais com caixa baixa
6 Palavras de ligação deverão permanecer em caixa baixa (da, do, de, etc),
exceto se começar por ela.
No dicionário de dados, deve evitar também o uso de “etc”. Não deve deixar
para o programador deduzir dados, já que o dicionário deverá ser o mais claro
possível. No exemplo da regra 6 acima, o uso da palavra etc pode gerar dúvidas. O
ideal é fazer como mostrado abaixo:
6 Palavras de ligação deverão permanecer em caixa baixa (da, do, de, das,
dos, e) exceto se começar por ela.
Caso seja necessário acrescentar novos detalhes, bastará acrescentar nas
regras de negócio.
O analista tem que ficar atento que, ao modificar uma regra de negócio,
deverá avaliar a real necessidade desta modificação e o custo que isto acarretará, já
que provavelmente muito código já foi escrito sobre as regras de negócio existente.
E se realmente for necessário, deverá verificar todos os programas que o acessam
para fazer as correções necessárias. Neste caso, se o dicionário de dados for
atualizado durante a codificação do sistema, a tarefa não será árdua, já que no
próprio dicionário de dados estará indicado quem está acessando esta regra de
negócio.
31
COMPARAÇÃO ENTRE AS PROPOSTAS
As soluções propostas nesta monografia são na verdade, complementares.
Uma não elimina outra, porém sabemos o quão é difícil mudar hábitos já muito
arraigados entre os profissionais da área de informática.
Mas, fazendo-se uma análise comparativa entre elas, nota-se:
- A primeira proposta é auto-explicativa, visto que o analista e/ou
programador, lendo o código entenderá sobre os dados que estão acessando, o que
se pretende armazenar e o seu conteúdo provável;
- Deverá haver um tempo de absorção por parte do analista e/ou programador
para acostumar-se com esta nomenclatura;
- Ela independe do banco de dados que a suportará (aqui estou
desconsiderando banco de dados mais antigos, que utilizavam o sistema
operacional DOS, tais como dBase, Paradox e outros);
- Ela independe também da linguagem de programação que o programador
utilizará.
- A segunda proposta, a princípio é mais trabalhosa, pois, a cada novo
programa, função ou rotina escrita, que utilize qualquer recurso do banco de dados,
deverá ser atualizada, porém para a manutenção de sistemas é extremamente útil;
32
- É uma fonte segura, se bem construída, de consulta sobre o banco de dados
do sistema;
- Consegue-se projetar com grande precisão qual o impacto que o sistema
terá ao alterar o banco de dados;
- Não consegue amenizar o trabalho do analista e/ou programador de
entender o código inicial, visto que não impede nomes de campos aleatórios.
O fato real é que a grande maioria dos analistas e/ou programadores, sempre
deixam a análise do banco de dados para depois, começando a codificação pelas
telas que o sistema terá, e “adapta-se” o banco de dados para estas telas.
Ao utilizar métodos, como o dicionário de dados do banco de dados, ou a
implantação de padronização, o processo necessariamente começará pela análise
do banco de dados, o que é o que eles não gostam de fazer, por isso esta grande
resistência a implantação de padronização e documentação.
33
CONCLUSÃO
Devemos fazer com que os programadores de software percebam que eles
codificam programas para outros e não para eles próprios, logo outros
programadores poderão fazer manutenções no código e a padronização deste
código diminui o prazo para que o novo programador, ou mesmo o próprio
programador analise o código e o repare. Devemos lembrar também que quem é
dono dos dados são quem contrata, e o contratante sentir-se-á mais confortável
sabendo que seus dados podem ser compartilhados com todos os seus sistemas e
não somente com um ou outro. A padronização inclusive ajuda a integridade dos
dados dos clientes.
Cada programador tem um modo de declarar e organizar os bancos de dados
que utilizarão, porém, assim como a linguagem de programação tem suas regras, é
necessário que estas regras sejam extendidas aos bancos de dados e que tornam a
manutenção e reusabilidade muito mais fácil.
Na pesquisa desta monografia, o maior problema encontrado, além da falta
de padronização, em que cada sistema similar que nomeava de modo
completamente diferente banco de dados que a priori tinham como finalidade
armazenar os mesmos tipos de dados, a total falta de documentação do banco de
dados.
34
Com a padronização de nomenclatura, talvez crie uma cultura de
documentação de banco de dados e melhore na qualidade do software
desenvolvido.
35
REFERÊNCIAS BIBLIOGRÁFICAS
CodePlex. (s.d.). Acesso em 07 de Maio de 2010, disponível em
http://sqlserversamples.codeplex.com/
DATE, C. J. (2004). Introdução a Sistemas de Banco de Dados. Campus.
DevMedia. (s.d.). Acesso em 07 de Maio de 2010, disponível em Fórum da DevMedia:
http://www.devmedia.com.br/articles/viewcomp.asp?comp=3221
FREEMAN, R. (2005). Oracle: Referência para o DBA. Campus.
ISO.org. (s.d.). Acesso em 06 de Maio de 2010, disponível em
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
MACHADO, F. N. (2004). Tecnologia e Projetos de Data Warehouse. Érica.
Oliveira, C. H. (2002). SQL Curso Prático. São Paulo: Novatec Editora Ltda.
Paraná, G. E. (s.d.). Companhia de Informática do Paraná. Acesso em 03 de 04 de 2010, disponível
em Companhia de Informática do Paraná:
http://www.documentador.celepar.pr.gov.br/documentador/acessoPublico.do?action=downloadArq
uivoUuid&uuid=9a21b4a4-5cbf-4590-bb30-da56f364373b
RAMEZ, E. E., & NAVATHE, S. (2005). Sistemas de Banco de Dados. Addison-Wesley.
SILBERSCHATZ, A., KORTH, H. F., & SUDARSHAN, S. (2006). Sistemas de Banco de Dados. Campus.
TEOREY, T., LIGHTSTONE, S., & NADEAU, T. (2006). Projeto e Modelagem de Banco de Dados.
Campus.
Wikipedia. (s.d.). Acesso em 05 de Maio de 2010, disponível em
http://en.wikipedia.org/wiki/Data_element_name
Wikipédia. (s.d.). Acesso em 20 de 04 de 2010, disponível em
http://pt.wikipedia.org/wiki/Banco_de_dados
36
ANEXOS
1 – Apêndice A
As tabela abaixo apresentam as palavras reservadas dos bancos de dados
ORACLE, MS SQLServer, MySQL.
1.1 – Oracle
ACCESS ADD* ALL* ALTER* AND*
ANY* ARRAY AS* ASC* AT
AUDIT AUTHID AVG BEGIN BETWEEN*
BINARY_INTEGER BODY BOOLEAN BULK BY*
CASE CHAR* CHAR_BASE CHECK* CLOSE
CLUSTER* COALESCE COLLECT COLUMN COMMENT*
COMMIT COMPRESS* CONNECT* CONSTANT CREATE*
CURRENT* CURRVAL CURSOR DATE* DAY
DECIMAL* DECLARE DEFAULT* DELETE* DESC*
DISTINCT* DO DROP* ELSE* ELSIF
END EXCEPTION EXCLUSIVE* EXECUTE EXISTS*
EXIT EXTENDS EXTRACT FALSE FETCH
FILE FLOAT* FOR* FORALL FROM*
FUNCTION GOTO GRANT* GROUP* HAVING*
HEAP HOUR IDENTIFIED IF IMMEDIATE*
IN* INCREMENT INDEX* INDICATOR INITIAL
INSERT* INTEGER* INTERFACE INTERSECT* INTERVAL
INTO* IS* ISOLATION JAVA LEVEL*
LIKE* LIMITED LOCK* LONG* LOOP
MAX MAXEXTENTS MIN MINUS* MINUTE
MLSLABEL* MOD MODE* MODIFY MONTH
NATURAL NATURALN NEW NEXTVAL NOAUDIT
NOCOMPRESS NOCOPY NOT* NOWAIT* NULL*
NULLIF NUMBER* NUMBER_BASE OCIROWID OF*
OFFLINE ON* ONLINE OPAQUE OPEN
OPERATOR OPTION* OR* ORDER* ORGANIZATION
OTHERS OUT PACKAGE PARTITION PCTFREE
PLS_INTEGER POSITIVE POSITIVEN PRAGMA PRIOR*
PRIVATE PRIVILEGES* PROCEDURE PUBLIC* RAISE
RANGE RAW* REAL RECORD REF
RELEASE RENAME RETURN RESOURCE REVERSE
REVOKE* ROW* ROWID* ROWNUM* ROWS*
37
ROWTYPE SAVEPOINT SECOND SELECT SEPARATE
SESSION* SET* SHARE* SIZE* SMALLINT*
SPACE SQL SQLCODE SQLERRM START*
STDDEV SUBTYPE SUCCESSFUL* SUM SYNONYM*
SYSDATE* TABLE* THEN* TIME TIMESTAMP
TIMEZONE_REGION TIMEZONE_ABBR TIMEZONE_MINUTE TIMEZONE_HOUR TO*
TRIGGER* TRUE TYPE UID* UNION*
UNIQUE* UPDATE* USE USER* VALIDATE*
VALUES* VARCHAR* VARCHAR2* VARIANCE VIEW*
WHEN WHENEVER* WHERE* WHILE WITH*
WORK WRITE YEAR ZONE
1.2 – MS SQLServer
ADD ABSOLUTE ACTION ADMIN AFTER
AGGREGATE ALIAS ALL ALLOCATE ALTER
AND ANY ARE ARRAY AS
ASC ASSERTION AT AUTHORIZATION BACKUP
BEFORE BEGIN BETWEEN BINARY BIT
BLOB BOOLEAN BOTH BREADTH BREAK
BROWSE BULK BY CASCADE CALL
CASCADED CASE CAST CATALOG CHAR
CHARACTER CHECK CHECKPOINT CLASS CLOB
CLOSE CLUSTERED COALESCE COLLATE COLLATION
COLUMN COMMIT COMPLETION COMPUTE CONNECT
CONNECTION CONSTRAINT CONSTRAINTS CONSTRUCTOR CONTAINS
CONTAINSTABLE CONTINUE CONVERT CORRESPONDING CREATE
CROSS CUBE CURRENT CURRENT_DATE CURRENT_PATH
CURRENT_ROLE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURSOR
CYCLE DATA DATABASE DATE DAY
DBCC DEALLOCATE DEC DECIMAL DECLARE
DEFAULT DEFERRABLE DEFERRED DELETE DENY
DEPTH DEREF DESC DESCRIBE DESCRIPTOR
DESTROY DESTRUCTOR DETERMINISTIC DIAGNOSTICS DICTIONARY
DISCONNECT DISK DISTINCT DISTRIBUTED DOMAIN
DOUBLE DROP DUMMY DUMP DYNAMIC
EACH ELSE END END-EXEC EQUALS
ERRLVL ESCAPE EVERY EXCEPT EXCEPTION
EXEC EXECUTE EXISTS EXIT EXTERNAL
FALSE FETCH FILE FILLFACTOR FIRST
FLOAT FOR FOREIGN FOUND FREE
FREETEXT FREETEXTTABLE FROM FULL FUNCTION
GENERAL GET GLOBAL GO GOTO
GRANT GROUP GROUPING HAVING HOLDLOCK
HOST HOUR IDENTITY IDENTITY_INSERT IDENTITYCOL
IF IGNORE IMMEDIATE IN INDEX
INDICATOR INITIALIZE INITIALLY INNER INOUT
INPUT INSERT INT INTEGER INTERSECT
INTERVAL INTO IS ISOLATION ITERATE
JOIN KEY KILL LANGUAGE LARGE
LAST LATERAL LEADING LEFT LESS
LEVEL LIKE LIMIT LINENO LOAD
LOCAL LOCALTIME LOCALTIMESTAMP LOCATOR MAP
MINUTE MODIFIES MODIFY MODULE MONTH
NAMES NATIONAL NATURAL NCHAR NCLOB
NEW NEXT NO NOCHECK NONCLUSTERED
NONE NOT NULL NULLIF NUMERIC
OBJECT OF OFF OFFSETS OLD
ON ONLY OPEN OPENDATASOURCE
OPENQUERY
OPENROWSET OPENXML OPERATION OPTION OR
ORDER ORDINALITY OUT OUTPUT OUTER
OVER PAD PARAMETER PARAMETERS PARTIAL
PATH PERCENT PLAN POSTFIX PRECISION
PREFIX PREORDER PREPARE PRESERVE PRIMARY
PRINT PRIOR PRIVILEGES PROC PROCEDURE
PUBLIC RAISERROR READ READS READTEXT
REAL RECONFIGURE RECURSIVE REF REFERENCES
REFERENCING RELATIVE REPLICATION RESTORE RESTRICT
38
RESULT RETURN RETURNS REVOKE RIGHT
ROLE ROLLBACK ROLLUP ROUTINE ROW
ROWCOUNT ROWGUIDCOL ROWS RULE SAVE
SAVEPOINT ESQUEMA SCOPE SCROLL SEARCH
SECOND SECTION SELECT SEQUENCE SESSION
SESSION_USER SET SETS SETUSER SHUTDOWN
SIZE SMALLINT SOME SPACE SPECIFIC
SPECIFICTYPE SQL SQLEXCEPTION SQLSTATE SQLWARNING
STATE STATEMENT STATIC STATISTICS STRUCTURE
SYSTEM_USER TABLE TEMPORARY TERMINATE TEXTSIZE
THAN THEN TIME TIMESTAMP TIMEZONE_HOUR
TIMEZONE_MINUTE TO TOP TRAN TRANSACTION
TRANSLATION TREAT TRIGGER TRUE TRUNCATE
TSEQUAL UNDER UNION UNIQUE UNKNOWN
UNNEST UPDATE UPDATETEXT USAGE USE
USER USING VALUE VALUES VARCHAR
VARIABLE VARYING VIEW WAITFOR WHEN
WHENEVER WHERE WHILE WITH WITHOUT
WORK WRITE WRITETEXT YEAR ZONE
MATCH START TRAILING
ADD ABSOLUTE ACTION ADMIN AFTER
1.3 – MySQL
ADD ALL ALTER ANALYZE AND
AS ASC ASENSITIVE BEFORE BETWEEN
BIGINT BINARY BLOB BOTH BY
CALL CASCADE CASE CHANGE CHAR
CHARACTER CHECK COLLATE COLUMN COLUMNS
CONDITION CONNECTION CONSTRAINT CONTINUE CONVERT
CREATE CROSS CURRENT_DAT
E CURRENT_TIME
CURRENT_TIMESTA
MP
CURRENT_USER CURSOR DATABASE DATABASES DAY_HOUR
DAY_MICROSECOND DAY_MINUTE DAY_SECOND DEC DECIMAL
DECLARE DEFAULT DELAYED DELETE DESC
LEFT LIKE LIMIT LINES LOAD
LOCALTIME LOCALTIMESTAMP LOCK LONG LONGBLOB
LONGTEXT LOOP LOW_PRIORITY MATCH MEDIUMBLOB
MEDIUMINT MEDIUMTEXT MIDDLEINT MINUTE_MICROSECO
ND MINUTE_SECOND
MOD NATURAL NOT NO_WRITE_TO_BINLO
G
NULL
NUMERIC ON OPTIMIZE OPTION OPTIONALLY
OR ORDER OUT OUTER OUTFILE
PRECISION PRIMARY PRIVILEGES PROCEDURE PURGE
READ REAL REFERENCES REGEXP RENAME
REPEAT REPLACE REQUIRE RESTRICT RETURN
REVOKE RIGHT RLIKE ESQUEMA ESQUEMAS
SECOND_MICROSECON
D SELECT SENSITIVE SEPARATOR SET
SHOW SMALLINT SONAME SPATIAL SPECIFIC
SQL SQLEXCEPTION SQLSTATE SQLWARNING SQL_BIG_RESULT
SQL_CALC_FOUND_RO
WS
SQL_SMALL_RESU
LT SSL STARTING STRAIGHT_JOIN
TABLE TABLES TERMINATED THEN TINYBLOB
TINYINT TINYTEXT TO TRAILING TRIGGER
TRUE UNDO UNION UNIQUE UNLOCK
UNSIGNED UPDATE USAGE USE USING
UTC_DATE UTC_TIME UTC_TIMESTAM
P VALUES
VARBINARY
39
VARCHAR VARCHARACTER VARYING WHEN WHERE
WHILE WITH WRITE XOR YEAR_MONTH
ZEROFILL
Top Related