1

UNIVERSIDADE SO JUDAS TADEU - USJT

Osvaldo Rodrigues Srgio

NOMENCLATURA EM BANCO DE DADOS

So Paulo 2010

UNIVERSIDADE SO JUDAS TADEU - USJT

Osvaldo Rodrigues Srgio

NOMENCLATURA EM BANCO DE DADOS

Trabalho de Concluso de Curso apresentado ao Ps-graduao Latu Sensu da Universidade So Judas Tadeu, como requisito parcial para concluso do curso de Especializao em Engenharia de Software. ORIENTADOR: Prof. Mst Aluzio Saiter

So Paulo 2010

UNIVERSIDADE SO JUDAS TADEU - USJT

Osvaldo Rodrigues Srgio

NOMENCLATURA EM BANCO DE DADOS

Trabalho de Concluso de Curso apresentado ao Ps-graduao Latu Sensu da Universidade So Judas Tadeu, como requisito parcial para concluso do curso de Especializao em Engenharia de Software. ORIENTADOR: Prof. Mst Aluzio Saiter

Aprovada em ____________________________

____________________________________ ORIENTADOR: Prof. Mst Aluzio Saiter

todos que, de alguma forma ajudaramme a realizar este trabalho.

RESUMO

Este trabalho tem por objetivo contribuir para conscientizao de uso de normas de padronizao na nomenclatura utilizada objetos e atributos nos bancos de dados relacionais (tabelas (entidades), atributos, chaves primrias, chaves estrangeiras, vises (views), esquemas (schemas), procedimentos (procedures) e funes (functions)). Tem-se por base a norma ISO/IEC 11.179-5.

Palavras-chave: Banco de dados; padronizao; nomenclatura

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

SUMRIO

INTRODUO ...................................................................................................................................... 8 ANLISE DO PROBLEMA ........................................................................................................................ 10 ESTUDO DE CASO .................................................................................................................................. 13 SOLUES PROPOSTAS ......................................................................................................................... 17 PEQUENA EXPLANAO SOBRE BANCO DE DADOS ............................................................................. 18 NOMENCLATURAS................................................................................................................................. 21 1 SUGESTO - PROPOSTA DE NOMENCLATURA.................................................................................. 23 1. Objetos do banco de dados: .................................................................................................... 23 2 SUGESTO DICIONRIO DE DADOS BANCO DE DADOS ................................................................ 28 COMPARAO ENTRE AS PROPOSTAS .................................................................................................. 31 CONCLUSO .......................................................................................................................................... 33 REFERNCIAS BIBLIOGRFICAS ............................................................................................................. 35 ANEXOS ................................................................................................................................................. 36 1 Apndice A................................................................................................................................... 36

INTRODUO

Muito se fala sobre a importncia de documentao e padronizao na confeco de projetos de softwares, de como isto um facilitador para o trabalho de codificao e mesmo de manuteno em sistemas de aplicativos. Porm, pouco se fala sobre como deve ser documentado e padronizado o banco de dados, especialmente a normatizao da nomenclatura utilizada em banco de dados (entidades, atributos, chave primria, chave estrangeira e outros). Esta monografia visa aprofundar sobre como esta normatizao facilitaria a documentao e a manuteno do banco de dados e as vantagens que isto acarretaria em todo o processo de confeco da codificao dos programas que o acessa. A resistncia dos profissionais da rea do uso de padres vo desde a averso documentao, principalmente no que se refere ao banco de dados, at a clssica desculpa de que o projeto est atrasado e que no dar tempo de fazer as revises tcnicas do cdigo, sendo portanto desnecessrio o uso de padres. Talvez esta cultura esteja dissiminada devido haver no mercado a fragmentao do processo de codificao, passando para profissionais do tipo freelancers a responsabilidade de confeccionar parte do cdigo, informando to somente o que esta parte de cdigo dever realizar.

Outra probabilidade estaria no fato de no haver um modelo aceito universalmente por todos, apesar de j existir uma norma internacional que foi imposta.

10

ANLISE DO PROBLEMA

Ao analisarmos cdigo de programas de computadores escritos por programadores, sejam em verses iniciais ou verses de manuteno, muito comum no encontrarmos a documentao deste programa, ainda mais se for uma verso mais antiga, por volta de 05 anos de uso, nem encontrarmos uma padronizao no programa, seja de nomes de variveis, de funes, de rotinas ou de modo de programao. Mais raro ainda encontrar documentao do dicionrio 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 necessrio alterar ou adaptar o banco de dados. Relatar estas mudanas no dicionrio de dados o que no ocorre, seja por simples descaso ou por no existir o mesmo. Neste caso, o analista ou programador que for analisar o cdigo, precisar analisar o programa inteiro para tentar compreender o que est sendo realizado pelo cdigo. Com referncia ao banco de dados, muitas vezes, os nomes dados a campos do banco de dados no so nem um pouco sugestivos, tendo nomes como: campo1,

11

campo2, campo3, etc. Alguns nomes so melhores denominados, como: cdigo, nome, estado, descrio, valor, etc. O problema do primeiro tipo de denominao descobrir o que cada campo est armazenando. No segundo mais simples deduzir o que cada campo armazenar. Nos dois casos, no sabemos de qual tabela pertence estes campos. No caso dos relacionamentos entre as tabelas, tambm uma anlise a parte. No primeiro caso, se uma tabela possui como chave primria 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 denominao de nomes no est restrito programas de aplicativos vendidos em lojas, tipo Administrao de Condomnios, Estoque e outros, mas a empresas que desenvolvem aplicativos internos. Quando uma equipe contratada para analisar um programa e fazer aperfeioamentos nele, a principal reclamao recai sobre o banco de dados, pois, geralmente o banco de dados no est normalizado e h muitos dados redundantes, causados pelo no levantamento de requisitos para sua concepo. E na anlise deste banco, a dificuldade de identificao dos contedos armazenados e a que se refere este contedo, provoca atrasos nos prazos estabelecidos pelos gerentes ao cliente. bastante comum, devido a estes fatores, haverem na empresa vrios banco de dados para cada sistema implantado na organizao, onde o usurio deve repetir os dados para cada sistema existente. Com uma padronizao, este problema poderia ser, se no eliminado, pelo menos amenizado. E isto no ocorre somente em pequenas empresas mas tambm nas mdias e grandes empresas. A necessidade de informaes faz com que as organizaes preocupem-se em absorver dados das mais diversas maneiras e fontes. O grande problema que,

12

muitas vezes, no existe o gerenciamento destas informaes, que permeiam em uma empresa ou rgo, a partir da criao e manuteno do banco de dados, o que reflete na incoerncia dos dados, podendo, assim, ocasionar significativos problemas para as futuras anlises. As empresas tem as informaes, porm, no tem como recuper-las, ou recupera-as em parte. Um dos mtodos de gerenciar as informaes ter conhecimento delas, o que facilitado pela implantao de padronizao. A implantao de programas de padronizao em banco de dados vista muitas vezes como mais uma burocracia e burrice, mas esquece que h padronizaes em linguagens de programao, 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 compe e que os mtodos sejam escritos em caixa baixa a primeira palavra, e em caixa alta a primeira letra das demais palavras. A princpio, houve vrios argumentos contra este tipo de conveno, mas com o passar dos anos e com o crescimento da linguagem, notou-se que facilmente identificvel cada parte do programa. O mesmo espera-se para o banco de dados, quando houver uma padronizao ampla. O maior dano que a no padronizao acarreta o aumento de custo na manuteno 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 informaes 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 confeco. Esta empresa solicitou uma atualizao do sistema para acrescentar novas funcionalidades e recursos, que fora solicitado pelo seu cliente. Fazendo a verificao do sistema, constatou-se que no havia nenhuma documentao sobre o sistema e nenhuma padronizao de variveis ou de rotinas, sendo que vrias rotinas eram repetidas em vrios locais. No havia comentrios no cdigo tambm. Iremos focar somente a parte de banco de dados, no qual tambm no tinha nenhuma documentao, dicionrio de dados do banco de dados ou um padro na definio dos nomes dos campos. O banco de dados utilizado neste sistema era o Microsoft Access, com o nome de Sensor.mdb. Abaixo segue a relao das tabelas e seus respectivos atributos, com o tipo de campo de cada um. Tabela: Sensores Tipo de Dados Nmero Nmero Nmero Nmero

Nome do campo: NPonto NPorto NPartio NSensor

14

Descrio PosioX PosioY SeguirPartio CorArmDes CorArmAti CorArmRes CorByP CorDes Situao Ponto Condies Tipo

Texto Nmero Nmero Sim/No Nmero Nmero Nmero Nmero Nmero Nmero Nmero Texto Nmero

Tabela: TipoSensor Nome do campo: Tipo de Dados Tipo Nmero Descrio Texto

Tabela: Partio Nome do campo: Tipo de Dados Porto Nmero Partio Nmero Descrio Texto

Tabela: Cdigo Nome do campo: Tipo de Dados Cdigo Texto Descrio Texto

Tabela: 52@52@& Nome do campo: Tipo de Dados 48@53@& Memorando 56@52@& Memorando 57@52@& Texto

Este sistema tambm gera, mensalmente, uma novo banco de dados, onde so armazenados as ocorrncias do sistema de alarme do referido ms, em que o nome do banco de dados Ano_Ms.mdb (AAAA_MM.mdb). Segue abaixo a relao da tabela:

15

Tabela: Ocorrncias Nome do campo: Tipo de Dados Contador Nmero DataM Texto HoraM Texto DataP Texto HoraP Texto Porto Texto Partio Texto Sensor Texto Ocorrncia Texto Operador Texto Outros Texto

De posse destes dados, foi realizado uma anlise do banco de dados. Porm, como os nomes da maioria dos atributos no 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 ocorrncias no mantinha os tipos de dados compatveis com os das tabelas do sistema. 5 Nomes de tabelas e atributos com caracteres especiais. Para soluo 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 atualizao do sistema, que inicialmente tinha uma previso de 03 meses, teve um atraso de 04 meses, sendo 01 ms referente ao banco de dados, totalizando 07 meses para

16

execuo desta atualizao. O sistema foi praticamente reescrito e o banco de dados foi remodelado para melhor performance, ou seja, o nosso cliente teve um acrscimo de custos devido a falta de documentao e padronizao, custos estes que poderiam no existir caso houvesse uma preocupao de se documentar, ou pelo menos colocar comentrios no cdigo do sistema.

17

SOLUES PROPOSTAS

Nesta monografia h dois tipos de solues apresentadas para o problema da denominao dos nomes dos campos do banco de dados. Na primeira proposta, ser utilizado o uso de padronizao, com base na International Organization For Stantardadization / International Electrotechnical Commission - ISO/IEC 11.759 (Organizao Internacional de Padronizao /

Comisso Internacional Eletrotcnica) na nomenclatura dos objetos que compe um banco de dados, em que apresento uma pequena introduo. Na minha segunda proposta, ser utilizado a implantao e uso do dicionrio de dados do banco de dados completo. Nesta proposta, ser feito uma juno de vrios temas sobre o assunto e elementos utilizados por mim, j que a literatura disponvel, apesar de mencionarem sobre o tema, no os aprofunda.

18

PEQUENA EXPLANAO SOBRE BANCO DE DADOS

Banco de dados ou base de dados um conjunto de registros dispostos em estrutura regular que possibilita a reorganizao dos mesmos e produo de informao. Um banco de dados normalmente agrupa registros utilizveis para um mesmo fim. (Wikipdia). Segundo Celso Henrique Poderoso de Oliveira, um banco de dados um conjunto coerente e lgico de dados relacionados que possuem significncia intrnseca. Esses dados representam aspectos do mundo real e devem ser mantidos para atender aos requisitos da empresa. Estes dados esto dispostos em uma ordem predefinida para atender a determinadas necessidades dos usurios. Como h mais de um tipo de banco de dados (hierrquico, 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, tambm chamadas de tabelas, tuplas ou registros, atributos, vises (view), procedimentos (procedures), chave primria (primary key), chave estrangeira (foreign key) e chave nica (unique key). Entidades, mais conhecidas como tabelas, so os objetos centrais e mais importantes em um banco de dados relacional. O propsito principal de qualquer

19

banco de dados armazenar dados gravados logicamente em tabelas. Um dos princpios no desenvolvimento do banco de dados relacional que cada tabela armazena informaes sobre um especfico tipo de coisa ou Entidade. (Kriegel, Alex and Trukhnov, Boris M. SQL Bible, Second Edition, pgina 83). Tuplas, comumente chamadas de registros, so linhas horizontais de dados e cada registro contm dados sobre um item da entidade, por exemplo, um registro de cliente contm informaes sobre um nico cliente. Atributos so campos onde armazenamos um tipo particular de informao para todos os registros da entidade, por exemplo, um atributo nome contm informaes sobre os nomes dos clientes. Vises (views) so tabelas lgicas, em que selecionamos somente o que relevante para determinado usurio. Isto feito para preservar a confidencialidade de alguns atributos. As vises no so tabelas fsicas, ou seja, no h dados armazenados nela, somente comandos SQL (Structure Query Language) que acessam as tabelas e retornam os dados desejados. Procedimentos (store procedures) so funes internas aos bancos de dados que realizam rotinas que o DBA (DataBase Administrator) queira automatizar. Cada fabricante de banco de dados tem linguagem proprietria sobre os procedimentos. Chave primria (Primary Key) so atributos que identificam unicamente uma instncia da entidade que representa. Chave estrangeira (Foreing Key) so as chaves primrias que so exportadas para outra entidade com a finalidade de realizarmos os relacionamentos do banco de dados.

20

Chave nica (Unique Key) so os atributos que, no podem ser chave primria por no atender aos requisitos de chave primria, porm no podem ter valores repetidos na tabela.

21

NOMENCLATURAS

H atualmente a norma ISO/IEC 11.179, que tenta padronizar os nomes atribudos aos componentes do banco de dados. Por ser muito genrica e de pouco conhecimento, ainda no foi absorvida pelos fabricantes de software e pelos programadores. Em vrios fruns sobre o tema, h muita discrepncia entre os programadores, sendo a favor ou sendo contra a implementao da padronizao. Muitos usurios acham isto uma completa tolice, que acarretaria em mais documentao e restrio programao, j que teriam que decorar as regras de nomenclatura. Outros acham a idia interessante, porm como cada organizao tem sua prpria padronizao, isto limita e/ou atrapalha na hora de codificar o programa. O que muitos programadores esquecem que na codificao de um programa, as idias e a lgica esto frescas na memria e que fcil lembrar-se de detalhes. Porm, aps algum tempo, estes detalhes so perdidos e torna-se trabalhoso fazer manutenes no cdigo. Isso quando o mesmo programador. Quando um outro programador ir continuar ou modificar o cdigo, ser necessrio uma perda de tempo para que o mesmo leia o cdigo e entenda, no a lgica, mas

22

os termos utilizados pelo antecessor, o que causa um retrabalho desnecessrio se estivesse utilizando um padro na codificao. O mesmo ocorre na parte de banco de dados. Ocorrem fatos, dentro de uma mesma organizao, 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 tambm chamado de Nome. Na codificao, muito comum que o programador referencie um atributo de uma tabela na inteno de referenciar este atributo a uma outra tabela. Para evitar estes erros, necessria a padronizao. Como dito antes, muitas empresas possuem padres internos, e geralmente estes padres so diferentes entre as empresas. Como comum no mercado a terceirizao da codificao, um programador pode codificar programas de vrias empresas, o que torna trabalhoso para o mesmo lembrar-se do padro de cada um, o que leva a considerar a padronizao uma bobagem. Lendo as padronizaes de diversas empresas, nota-se que as diferenas entre elas so pequenas, o que tornaria a implementao de uma padronizao universal mais simples.

23

1 SUGESTO - PROPOSTA DE NOMENCLATURA

1. Objetos do banco de dados: Todos os objetos podero ser identificados com at 30 (trinta) caracteres, serem em caixa alta e no singular. No podero ser utilizadas palavras reservadas (vide apndice A) e caracteres especiais, incluindo parnteses, aspas, pontos de interrogao, dlar ($), hash (#), barra (/), contra-barra (\) e hfen (-) . Na tabela abaixo segue objetos, regras, exemplos e motivo das nomenclaturas propostas. Objeto Banco de dados Iniciado por DB_ Regras Ter um nome relevante ao que armazena, ou; - Conter uma identificao resumida do sistema; - Ter um nome relevante ao que armazena; Exemplo DB_CLIENTE DB_RH Motivo A prefixo DB_ facilita o gerenciamento e o reconhecimento imediato de um objeto banco de dados.

Tabela Iniciado por TB_ Vises (views) Iniciado por VW_

TB_CLIENTE TB_FUNCIONARIO

Segue a norma ISO/IEC 11.179-5 e representa a entidade no banco de dados. Idem ao da tabela

- Ter um nome VW_CLIENTE relevante ao que VW_FUNCIONARIO armazena;

24

Objeto Vises materializadas Iniciado por VM_ Tabelas de sistema Iniciado por TS_ Tabelas de log de operaes Iniciado por TL_ Constraint Check Iniciado por CK_

Regras Exemplo - Ter um nome VM_CLIENTE relevante ao que VM_FUNCIONARIO armazena;

Motivo Idem ao da tabela

- Ter um nome TS_ESTADO relevante ao que TS_ESTADO_CIVIL armazena;

Idem ao da tabela.

- Ter o nome TL_CLIENTE da tabela em que armazenar o log; - Ter o nome CK_CLI_SEXO do atributo;

Idem ao da tabela.

Constraint - Ter o nome PK_CLI_COD Primary Key do atributo; (chave primria) Iniciado por PK_ Constraint Foreign Key (chave estrangeira) Iniciado por FK_ Constraint Unique Key (chave nica) Iniciado por UQ_ - Ter o nome FK_CLI_COD_PED do atributo da tabela de origem; - Ter o nome da tabela destino; - Ter o nome UQ_CLI_CPF do atributo;

Informa a tabela e o atributo a que pertence e impede de haver repeties de nome das constraint no banco de dados. Informa a tabela e o atributo a que pertence e o impede de haver repeties de nome das constraint no banco de dados. Informa a tabela origem do atributo, nome do atributo e tabela que recebe atributo. de o a o

Informa a tabela e o atributo que chave nica e no chave primria.

25

Objeto Index Iniciado por IN_ Funes Iniciado por FC_ Stored Procedures ( Procedimentos armazenados) Iniciado por SP_ Trigger Before / After Insert (Gatilho antes / depois da insero) Iniciado por TBI_ TBA_ Trigger Before / After Update (Gatilho antes / depois da atualizao) Iniciado por TAU_ TBU_ Trigger Before / After Delete (Gatilho antes / depois da excluso) Iniciado por TAD_ TBD_

Regras Exemplo - Ter o nome IN_CLI_NOM_END da tabela e dos atributos que o compe;

Motivo Informa a tabela e os atributos que o compe.

- Ter um nome FC_CALCULA_DV relevante sobre o que faz; - Ter um nome SP_ALTERA_CLI relevante sobre o que faz; - Ter a tabela que ser afetada; - 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 o que a funo realiza.

Informa o que procedimento faz e tabela que afeta.

o a

Informa qual em qual tabela gera o gatilho e quando.

- 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.

- 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 Trigger Before / After Insert /Update/Delete (Gatilho antes / depois da insero/ atualizao/ excluso) (Trigger after/before all) Iniciado por TAA_ TBA_ Trigger Instead Of (Gatilho ao invs de) Iniciado por TIO_

Regras - Ter o nome da tabela; - a tabela deve perder o prefixo TB_, exceto se for tabela de log;

Exemplo TBA_CLIENTE TAA_CLIENTE TBA_TL_CLIENTE TAA_TL_CLIENTE

Motivo Informa qual em qual tabela gera o gatilho e quando.

- Ter o nome TIO_CLIENTE da tabela; TIO_TL_CLIENTE - a tabela deve perder o prefixo TB_, exceto se for tabela de log;

Informa qual em qual tabela gera o gatilho e quando.

Obs: Nesta proposta esto os componentes mais utilizados em um banco de dados. 2. Objetos de atributos Todos os atributos podero ser identificados com at 30 (trinta) caracteres. Um atributo no pode ser uma palavra reservada e nem conter caracteres especiais, incluindo parnteses, aspas, pontos de interrogao, dlar ($), hash (#), barra (/), contra-barra (\) e hfen (-) e acentuao. Deve conter, nos 3 (trs) ou 4 (quatro) caracteres iniciais, o nome da tabela abreviado, logo aps um sublinhado e o nome do atributo, podendo este ser abreviado, conforme a tabela abaixo. O nome do atributo deve conter no mnimo 3 (trs) caracteres, exceto quando for auto-explicativa (KG, GB, MB, KM, etc) e ser em caixa alta.

27

Caso no seja possvel a utilizao de acrnimos ou a abreviao ainda ultrapasse o limite de 30 (trinta) caracteres, utilize as tcnicas abaixo, na ordem dada, para criar uma abreviao 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 sugestes de abreviao, por ordem alfabtica. Atributo Sugesto Exemplo Bairro BAI CLI_BAI Cadastro INSS PIS CLI_PIS Cadastro Pessoa Fsica CPF CLI_CPF Carteira CRT CLI_CRT_MOTORISTA Carteira Nacional de CNH CLI_CNH Habilitao Certido CTD CLI_CTD_CASAMENTO Cidade CID CLI_CID Cdigo COD CLI_COD Cdigo Endereamento CEP CLI_CEP Postal Complemento COMP CLI_COMP Data DT CLI_DT_NASCIMENTO Descrio DESC CLI_DESC Endereo END CLI_END Hora HR CLI_HR_CADASTRO Logradouro LOG CLI_LOG Nome NOM CLI_NOM Nmero NRO CLI_NRO Quantidade QTD CLI_QTD Registro Geral RG CLI_RG Sexo SEX CLI_SEX Sigla SG UF_SG Situao ou Status ST CLI_ST Taxa TX CLI_TX_GLICOSE Telefone TEL CLI_TEL Tipo TP CLI_TP_SANGUINEO Ttulo TIT CLI_TIT_ELEITORAL Valor VLR CLI_VLR_RENDA Obs: Nesta sugesto, no est sendo considerado nenhum tipo de normalizao.

28

2 SUGESTO DICIONRIO DE DADOS BANCO DE DADOS

Para a confeco do dicionrio do banco de dados, devemos ter em mente que este trabalho deve ser realizado em paralelo com o desenvolvimento do software. No incio do dicionrio, dever ser indicado o nome do banco de dados, como exemplo abaixo: Banco de dados: DB_CLIENTE Aps, vem a entidade (tabela) e seus respectivos atributos, como no exemplo abaixo. Entidade: TB_CLIENTE Atributo: CLI_COD Propriedade O que armazena Datatype Tamanho Domnio Valor mnimo Valor mximo Regra de negcio Sistemas que o utilizam Programas que o utilizam Relatrios que o utilizam Descrio Cdigo do cliente. Inteiro 4 bytes Nmero positivo, de 0 9 1 231 1, 2, 4 Aqui anotar todos os sistemas que o acessam, exemplo, Sistema de Vendas . Aqui anotar todos os programas, funes, rotinas e/ou classes que o acessam, exemplo frmCliente, frmVenda. Aqui anotar todos os relatrios 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 codificao, necessrio que estes dados sejam atualizados sempre que necessrio. Isto facilitar o trmino do dicionrio de dados e diminuir a probabilidade de esquecer de anotar algum dado. Um detalhe neste dicionrio de dados est na regra de negcio. Muitas vezes, um atributo possui a mesma ou as mesmas regras de negcio de outro atributo. Para evitar a repetio de regras vrias vezes no dicionrio de dados e tambm de que, se uma regra sofrer alterao, ter que percorrer todo o dicionrio de dados para fazer a correo e ficar sujeito a inconsistncia nos dados, aconselhvel fazer um apndice com as regras de negcio, numerando-as e no espao destinado a regra de negcios, colocar o nmero da respectiva regra a que o atributo esteja sujeito. Exemplo: APNDICE REGRAS DE NEGCIO Regra 1 2 3 4 5 Descrio Campo chave primria Valor nulo no permitido Campo chave estrangeira Este contedo dever gerado pelo sistema Cada palavra dever comear com caixa alta, as demais com caixa baixa. Palavras de ligao devero permanecer em caixa baixa (da, do, de, etc) No poder conter dois espaos entre as palavras No poder comear com espaos ...

6 7 ...

E assim sucessivamente. Lembrando que, as regras de negcio devero ser o mais claro e simples possvel 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 nmero 5 pode ser dividida em duas, como mostrado abaixo: 5 6 Cada palavra dever comear com caixa alta, as demais com caixa baixa Palavras de ligao devero permanecer em caixa baixa (da, do, de, etc), exceto se comear por ela.

No dicionrio de dados, deve evitar tambm o uso de etc. No deve deixar para o programador deduzir dados, j que o dicionrio dever ser o mais claro possvel. No exemplo da regra 6 acima, o uso da palavra etc pode gerar dvidas. O ideal fazer como mostrado abaixo: 6 Palavras de ligao devero permanecer em caixa baixa (da, do, de, das, dos, e) exceto se comear por ela.

Caso seja necessrio acrescentar novos detalhes, bastar acrescentar nas regras de negcio. O analista tem que ficar atento que, ao modificar uma regra de negcio, dever avaliar a real necessidade desta modificao e o custo que isto acarretar, j que provavelmente muito cdigo j foi escrito sobre as regras de negcio existente. E se realmente for necessrio, dever verificar todos os programas que o acessam para fazer as correes necessrias. Neste caso, se o dicionrio de dados for atualizado durante a codificao do sistema, a tarefa no ser rdua, j que no prprio dicionrio de dados estar indicado quem est acessando esta regra de negcio.

31

COMPARAO ENTRE AS PROPOSTAS

As solues propostas nesta monografia so na verdade, complementares. Uma no elimina outra, porm sabemos o quo difcil mudar hbitos j muito arraigados entre os profissionais da rea de informtica. Mas, fazendo-se uma anlise comparativa entre elas, nota-se: - A primeira proposta auto-explicativa, visto que o analista e/ou programador, lendo o cdigo entender sobre os dados que esto acessando, o que se pretende armazenar e o seu contedo provvel; - Dever haver um tempo de absoro 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 tambm da linguagem de programao que o programador utilizar. - A segunda proposta, a princpio mais trabalhosa, pois, a cada novo programa, funo ou rotina escrita, que utilize qualquer recurso do banco de dados, dever ser atualizada, porm para a manuteno de sistemas extremamente til;

32

- uma fonte segura, se bem construda, de consulta sobre o banco de dados do sistema; - Consegue-se projetar com grande preciso qual o impacto que o sistema ter ao alterar o banco de dados; - No consegue amenizar o trabalho do analista e/ou programador de entender o cdigo inicial, visto que no impede nomes de campos aleatrios. O fato real que a grande maioria dos analistas e/ou programadores, sempre deixam a anlise do banco de dados para depois, comeando a codificao pelas telas que o sistema ter, e adapta-se o banco de dados para estas telas. Ao utilizar mtodos, como o dicionrio de dados do banco de dados, ou a implantao de padronizao, o processo necessariamente comear pela anlise do banco de dados, o que o que eles no gostam de fazer, por isso esta grande resistncia a implantao de padronizao e documentao.

33

CONCLUSO

Devemos fazer com que os programadores de software percebam que eles codificam programas para outros e no para eles prprios, logo outros programadores podero fazer manutenes no cdigo e a padronizao deste cdigo diminui o prazo para que o novo programador, ou mesmo o prprio programador analise o cdigo e o repare. Devemos lembrar tambm que quem dono dos dados so quem contrata, e o contratante sentir-se- mais confortvel sabendo que seus dados podem ser compartilhados com todos os seus sistemas e no somente com um ou outro. A padronizao inclusive ajuda a integridade dos dados dos clientes. Cada programador tem um modo de declarar e organizar os bancos de dados que utilizaro, porm, assim como a linguagem de programao tem suas regras, necessrio que estas regras sejam extendidas aos bancos de dados e que tornam a manuteno e reusabilidade muito mais fcil. Na pesquisa desta monografia, o maior problema encontrado, alm da falta de padronizao, 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 documentao do banco de dados.

34

Com a padronizao de nomenclatura, talvez crie uma cultura de documentao de banco de dados e melhore na qualidade do software desenvolvido.

35

REFERNCIAS BIBLIOGRFICAS

CodePlex. (s.d.). Acesso em 07 de Maio de 2010, disponvel em http://sqlserversamples.codeplex.com/ DATE, C. J. (2004). Introduo a Sistemas de Banco de Dados. Campus. DevMedia. (s.d.). Acesso em 07 de Maio de 2010, disponvel em Frum da DevMedia: http://www.devmedia.com.br/articles/viewcomp.asp?comp=3221 FREEMAN, R. (2005). Oracle: Referncia para o DBA. Campus. ISO.org. (s.d.). Acesso em 06 de Maio de 2010, disponvel 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 Prtico. So Paulo: Novatec Editora Ltda. Paran, G. E. (s.d.). Companhia de Informtica do Paran. Acesso em 03 de 04 de 2010, disponvel em Companhia de Informtica 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, disponvel em http://en.wikipedia.org/wiki/Data_element_name Wikipdia. (s.d.). Acesso em 20 de 04 de 2010, disponvel em http://pt.wikipedia.org/wiki/Banco_de_dados

36

ANEXOS

1 Apndice A As tabela abaixo apresentam as palavras reservadas dos bancos de dados ORACLE, MS SQLServer, MySQL. 1.1 Oracle
ACCESS ANY* AUDIT BINARY_INTEGER CASE CLUSTER* COMMIT CURRENT* DECIMAL* DISTINCT* END EXIT FILE FUNCTION HEAP IN* INSERT* INTO* LIKE* MAX MLSLABEL* NATURAL NOCOMPRESS NULLIF OFFLINE OPERATOR OTHERS PLS_INTEGER PRIVATE RANGE RELEASE REVOKE* ADD* ARRAY AUTHID BODY CHAR* COALESCE COMPRESS* CURRVAL DECLARE DO EXCEPTION EXTENDS FLOAT* GOTO HOUR INCREMENT INTEGER* IS* LIMITED MAXEXTENTS MOD NATURALN NOCOPY NUMBER* ON* OPTION* OUT POSITIVE PRIVILEGES* RAW* RENAME ROW* ALL* AS* AVG BOOLEAN CHAR_BASE COLLECT CONNECT* CURSOR DEFAULT* DROP* EXCLUSIVE* EXTRACT FOR* GRANT* IDENTIFIED INDEX* INTERFACE ISOLATION LOCK* MIN MODE* NEW NOT* NUMBER_BASE ONLINE OR* PACKAGE POSITIVEN PROCEDURE REAL RETURN ROWID* ALTER* ASC* BEGIN BULK CHECK* COLUMN CONSTANT DATE* DELETE* ELSE* EXECUTE FALSE FORALL GROUP* IF INDICATOR INTERSECT* JAVA LONG* MINUS* MODIFY NEXTVAL NOWAIT* OCIROWID OPAQUE ORDER* PARTITION PRAGMA PUBLIC* RECORD RESOURCE ROWNUM* AND* AT BETWEEN* BY* CLOSE COMMENT* CREATE* DAY DESC* ELSIF EXISTS* FETCH FROM* HAVING* IMMEDIATE* INITIAL INTERVAL LEVEL* LOOP MINUTE MONTH NOAUDIT NULL* OF* OPEN ORGANIZATION PCTFREE PRIOR* RAISE REF REVERSE ROWS*

37

ROWTYPE SESSION* SPACE STDDEV SYSDATE* TIMEZONE_REGION TRIGGER* UNIQUE* VALUES* WHEN WORK

SAVEPOINT SET* SQL SUBTYPE TABLE* TIMEZONE_ABBR TRUE UPDATE* VARCHAR* WHENEVER* WRITE

SECOND SHARE* SQLCODE SUCCESSFUL* THEN* TIMEZONE_MINUTE TYPE USE VARCHAR2* WHERE* YEAR

SELECT SIZE* SQLERRM SUM TIME TIMEZONE_HOUR UID* USER* VARIANCE WHILE ZONE

SEPARATE SMALLINT* START* SYNONYM* TIMESTAMP TO* UNION* VALIDATE* VIEW* WITH*

1.2 MS SQLServer
ADD AGGREGATE AND ASC BEFORE BLOB BROWSE CASCADED CHARACTER CLOSE COLUMN CONNECTION CONTAINSTABLE CROSS CURRENT_ROLE CYCLE DBCC DEFAULT DEPTH DESTROY DISCONNECT DOUBLE EACH ERRLVL EXEC FALSE FLOAT FREETEXT GENERAL GRANT HOST IF INDICATOR INPUT INTERVAL JOIN LAST LEVEL LOCAL MINUTE NAMES NEW NONE OBJECT ON OPENROWSET ORDER OVER PATH PREFIX PRINT PUBLIC REAL REFERENCING ABSOLUTE ALIAS ANY ASSERTION BEGIN BOOLEAN BULK CASE CHECK CLUSTERED COMMIT CONSTRAINT CONTINUE CUBE CURRENT_TIME DATA DEALLOCATE DEFERRABLE DEREF DESTRUCTOR DISK DROP ELSE ESCAPE EXECUTE FETCH FOR FREETEXTTABLE GET GROUP HOUR IGNORE INITIALIZE INSERT INTO KEY LATERAL LIKE LOCALTIME MODIFIES NATIONAL NEXT NOT OF ONLY OPENXML ORDINALITY PAD PERCENT PREORDER PRIOR RAISERROR RECONFIGURE RELATIVE ACTION ALL ARE AT BETWEEN BOTH BY CAST CHECKPOINT COALESCE COMPLETION CONSTRAINTS CONVERT CURRENT CURRENT_TIMESTAMP DATABASE DEC DEFERRED DESC DETERMINISTIC DISTINCT DUMMY END EVERY EXISTS FILE FOREIGN FROM GLOBAL GROUPING IDENTITY IMMEDIATE INITIALLY INT IS KILL LEADING LIMIT LOCALTIMESTAMP MODIFY NATURAL NO NULL OFF OPEN OPERATION OUT PARAMETER PLAN PREPARE PRIVILEGES READ RECURSIVE REPLICATION ADMIN ALLOCATE ARRAY AUTHORIZATION BINARY BREADTH CASCADE CATALOG CLASS COLLATE COMPUTE CONSTRUCTOR CORRESPONDING CURRENT_DATE CURRENT_USER DATE DECIMAL DELETE DESCRIBE DIAGNOSTICS DISTRIBUTED DUMP END-EXEC EXCEPT EXIT FILLFACTOR FOUND FULL GO HAVING IDENTITY_INSERT IN INNER INTEGER ISOLATION LANGUAGE LEFT LINENO LOCATOR MODULE NCHAR NOCHECK NULLIF OFFSETS OPENDATASOURC E OPTION OUTPUT PARAMETERS POSTFIX PRESERVE PROC READS REF RESTORE AFTER ALTER AS BACKUP BIT BREAK CALL CHAR CLOB COLLATION CONNECT CONTAINS CREATE CURRENT_PATH CURSOR DAY DECLARE DENY DESCRIPTOR DICTIONARY DOMAIN DYNAMIC EQUALS EXCEPTION EXTERNAL FIRST FREE FUNCTION GOTO HOLDLOCK IDENTITYCOL INDEX INOUT INTERSECT ITERATE LARGE LESS LOAD MAP MONTH NCLOB NONCLUSTERED NUMERIC OLD OPENQUERY OR OUTER PARTIAL PRECISION PRIMARY PROCEDURE READTEXT REFERENCES RESTRICT

38

RESULT ROLE ROWCOUNT SAVEPOINT SECOND SESSION_USER SIZE SPECIFICTYPE STATE SYSTEM_USER THAN TIMEZONE_MINUTE TRANSLATION TSEQUAL UNNEST USER VARIABLE WHENEVER WORK MATCH ADD

RETURN ROLLBACK ROWGUIDCOL ESQUEMA SECTION SET SMALLINT SQL STATEMENT TABLE THEN TO TREAT UNDER UPDATE USING VARYING WHERE WRITE START ABSOLUTE

RETURNS ROLLUP ROWS SCOPE SELECT SETS SOME SQLEXCEPTION STATIC TEMPORARY TIME TOP TRIGGER UNION UPDATETEXT VALUE VIEW WHILE WRITETEXT TRAILING ACTION

REVOKE ROUTINE RULE SCROLL SEQUENCE SETUSER SPACE SQLSTATE STATISTICS TERMINATE TIMESTAMP TRAN TRUE UNIQUE USAGE VALUES WAITFOR WITH YEAR ADMIN

RIGHT ROW SAVE SEARCH SESSION SHUTDOWN SPECIFIC SQLWARNING STRUCTURE TEXTSIZE TIMEZONE_HOUR TRANSACTION TRUNCATE UNKNOWN USE VARCHAR WHEN WITHOUT ZONE AFTER

1.3 MySQL
ADD AS BIGINT CALL CHARACTER CONDITION CREATE CURRENT_USER DAY_MICROSECOND DECLARE LEFT LOCALTIME LONGTEXT MEDIUMINT MOD NUMERIC OR PRECISION READ REPEAT REVOKE SECOND_MICROSECON D SHOW SQL SQL_CALC_FOUND_RO WS TABLE TINYINT TRUE UNSIGNED UTC_DATE ALL ASC BINARY CASCADE CHECK CONNECTION CROSS CURSOR DAY_MINUTE DEFAULT LIKE LOCALTIMESTAMP LOOP MEDIUMTEXT NATURAL ON ORDER PRIMARY REAL REPLACE RIGHT SELECT SMALLINT SQLEXCEPTION SQL_SMALL_RESU LT TABLES TINYTEXT UNDO UPDATE UTC_TIME ALTER ASENSITIVE BLOB CASE COLLATE CONSTRAINT CURRENT_DAT E DATABASE DAY_SECOND DELAYED LIMIT LOCK LOW_PRIORITY MIDDLEINT NOT OPTIMIZE OUT PRIVILEGES REFERENCES REQUIRE RLIKE SENSITIVE SONAME SQLSTATE SSL TERMINATED TO UNION USAGE UTC_TIMESTAM P ANALYZE BEFORE BOTH CHANGE COLUMN CONTINUE CURRENT_TIME DATABASES DEC DELETE LINES LONG MATCH MINUTE_MICROSECO ND NO_WRITE_TO_BINLO G OPTION OUTER PROCEDURE REGEXP RESTRICT ESQUEMA SEPARATOR SPATIAL SQLWARNING STARTING THEN TRAILING UNIQUE USE VALUES AND BETWEEN BY CHAR COLUMNS CONVERT CURRENT_TIMESTA MP DAY_HOUR DECIMAL DESC LOAD LONGBLOB MEDIUMBLOB MINUTE_SECOND NULL OPTIONALLY OUTFILE PURGE RENAME RETURN ESQUEMAS SET SPECIFIC SQL_BIG_RESULT STRAIGHT_JOIN TINYBLOB TRIGGER UNLOCK USING VARBINARY

39

VARCHAR WHILE ZEROFILL

VARCHARACTER WITH

VARYING WRITE

WHEN XOR

WHERE YEAR_MONTH