Nomenclatura em Banco de Dados

1

UNIVERSIDADE SÃO JUDAS TADEU - USJT

Osvaldo Rodrigues Sérgio

NOMENCLATURA EM BANCO DE DADOS

São Paulo 2010

2




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




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


Tipo Número

Descrição Texto

Tabela: Partição


Porto Número

Partição Número

Descrição Texto

Tabela: Código


Código Texto

Descrição Texto

Tabela: 52@52@&


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


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_


VW_CLIENTE VW_FUNCIONARIO

Idem ao da tabela

24


Visões materializadas Iniciado por VM_


VM_CLIENTE VM_FUNCIONARIO

Idem ao da tabela

Tabelas de sistema Iniciado por TS_


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_


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_


UQ_CLI_CPF Informa a tabela e o atributo que é chave única e não chave primária.

25


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_


TBU_CLIENTE TAU_CLIENTE TBU_TL_CLIENTE TAU_TL_CLIENTE


Trigger Before / After Delete (Gatilho antes / depois da exclusão) Iniciado por TAD_ TBD_


TBD_CLIENTE TAD_CLIENTE TBD_TL_CLIENTE TAD_TL_CLIENTE


26


Trigger Before / After Insert /Update/Delete (Gatilho antes / depois da inserção/ atualização/ exclusão) (Trigger after/before all) Iniciado por TAA_ TBA_


TBA_CLIENTE TAA_CLIENTE TBA_TL_CLIENTE TAA_TL_CLIENTE


Trigger Instead Of (Gatilho ao invés de) Iniciado por TIO_


TIO_CLIENTE TIO_TL_CLIENTE


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

Nomenclatura em Banco de Dados

Documents

Transcript of Nomenclatura em Banco de Dados