NORMA TCNICA PARA DEFINIO DE OBJETOS DE BANCO

DE DADOS E DE ESTRUTURAS DE ARMAZENAMENTO QUE

CONSTITUEM O BANCO DE DADOS CORPORATIVO
Referncia: NT-AI.04.04.01
http://www.unesp.br/ai/pdf/nt-ai.04.04.01.pdf
Data: 31/07/2000

STATUS: EM VIGOR
__________________________________________________________________
A Assessoria de Informtica, rgo executivo responsvel pela normatizao e
padronizao de procedimentos referentes rea de informtica, de acordo com o
Regulamento Geral para Uso e Administrao de Computadores e Redes da
Unesp (RG-AI.00.01.01, Portaria UNESP 65/98), define a seguinte NORMA
TCNICA:
1. RESUMO
Este documento estabelece normas, regras e procedimentos que devem ser seguidos
para se definir objetos do banco de dados, objetos estes pertencentes ao Banco de Dados
Corporativo, estabelecendo assim uma padronizao de nomes. Esta norma tambm
estabelece a padronizao na definio das estruturas fsicas e lgicas relacionadas com o
armazenamento dos dados propriamente ditos. Entenda-se aqui por definio tanto a
questo da nomenclatura quanto a questo de como devem ser constitudos os objetos de
banco de dados e estruturas de armazenamento, abrangendo, inclusive, regras sobre os
scripts de criao e alterao.

2. PALAVRAS CHAVES
PL/SQL, tabela, coluna, ndice, tablespace, datafile, schema, owner, banco de dados,
corporativo, Oracle, trigger, view, sequence, constraint, chave, username, role, script,
sinnimos.
3. DEFINIES
3.1

Terceiros : toda e qualquer entidade (empresa, micro-empresa, conjunto de um ou

mais tcnicos em informtica tais como analistas, programadores, etc. que atuem
como profissional liberal, consultores independentes ou ligados a alguma
corporao, etc.) que porventura presta ou venha a prestar servios para a UNESP,

contratada temporariamente ou no, independente da atividade que desempenhe ou

venha a desempenhar relacionada ao desenvolvimento de sistemas e banco de
dados.
3.2

Banco de Dados Corporativo : um banco de dados relacional contendo objetos

(tabelas, vises, procedimentos, etc.) que so compartilhados e usados por diversas
aplicaes ou sistemas ao mesmo tempo, evitando assim redundncia de dados e
garantindo integridade das informaes, alm de outras vantagens. Ele composto
por outros dois bancos de dados independentes, cada qual constitudo por uma
instncia e uma base de dados. So assim denominados : Banco de Dados de
Desenvolvimento e Banco de Dados de Produo.

3.3

Banco de Dados de Desenvolvimento : corresponde a uma instncia e a uma base de

dados com o objetivo de armazenar objetos de banco de dados e dados para testes
dos novos sistemas ou aplicaes, sendo um banco de dados relacional. S
utilizado pelas equipes de desenvolvimento, devidamente autorizadas. Todo novo
sistema ou aplicao deve, antes de ser colocado em produo, ser colocado no
Banco de Dados de Desenvolvimento para testes e validao por parte do usurio
final.

3.4

Banco de Dados de Produo : corresponde a uma instncia e a uma base de dados

com o objetivo de armazenar objetos de banco de dados e dados de sistemas ou
aplicaes j em produo, constituindo assim dados vlidos e que so acessados
por diversos usurios do banco de dados, devidamente autorizados. Tambm um
banco de dados relacional

3.5

DBA : O termo DBA uma sigla de origem inglesa para Database Administrator.
Como no jargo tcnico, no comrcio, em empresas, enfim, em tudo que se
relaciona com administrao de banco de dados no mundo (inclusive no Brasil) se
utiliza o termo DBA, ao invs da traduo para a lngua local, resolvemos adot-lo
tambm na UNESP para referenciar aquele que responsvel por gerenciar e
administrar o banco de dados.

3.6

Equipe de DBAs : um grupo formado por dois ou mais tcnicos e/ou analistas da
Assessoria de Informtica responsveis pela administrao do Banco de Dados
Corporativo, devidamente treinados para tal tarefa de administrao. A necessidade
de uma equipe deve-se ao fato de que a administrao de um banco de dados no
deve ficar centralizada em uma nica pessoa.

3.7

Equipe de Desenvolvimento : qualquer grupo de dois ou mais tcnicos, analistas

e/ou programadores de uma Unidade responsveis por definir, projetar, desenvolver
e implantar sistemas, sejam de uso local e restrito Unidade, seja de mbito da
comunidade UNESP.

3.8

Schema : um schema na terminologia Oracle um conjunto de vrios objetos de

bancos de dados que esto associados a um usurio especfico do banco de dados
(tambm chamado de owner ou proprietrio).

3.9

Owner : um owner um usurio do banco de dados que tem poder total de ao

sobre os objetos de banco de dados do schema a que est associado sem precisar de
algum direito ou privilgio especial para isso. Ele pode executar comandos DML e
DDL naturalmente. Assim sendo, seu poder de ao muito grande.

3.10

Tabela : a unidade bsica de armazenamento de dados sendo composta por linhas

e colunas.

3.11

Coluna : uma parte de uma Tabela que contm dados do mesmo tipo e que,
semanticamente, so de mesma natureza.

3.12

Linha : corresponde a uma instncia ou registro de uma Tabela.

3.13

View (Viso) : logicamente representam subconjuntos de uma ou mais tabelas e se

comportam como tabelas quanto a insero, alterao, excluso e consulta de dados;
ou seja, pode-se inserir, alterar, excluir ou consultar dados em uma view,
respeitando sempre as regras de integridade e de segurana que estiverem definidas
sobre as Tabelas envolvidas na constituio da view. Preferimos utilizar o termo em
ingls por ser mais comumente utilizado do que a traduo para lngua local.

3.14

Pacote : um conjunto de procedimentos PL/SQL agrupados numa mesma estrutura

que fica armazenada no banco de dados. (???). Um pacote tem duas partes : a
especificao do pacote e o corpo do pacote.

3.15

Especificao do Pacote : tambm conhecido como cabealho do pacote; e a parte

do Pacote que contm informaes sobre o contedo do pacote mas no contm
nenhum cdigo de nenhum dos procedimentos.

3.16

Corpo do Pacote : a parte do Pacote que contm o cdigo de todos os

procedimentos definidos na Especificao do Pacote.

3.17

Sequence (sequncia) : um objeto de banco de dados usado para gerar nmeros

nicos. Devido a isso, ela geralmente utilizada para implementar chave primria
em uma Tabela. Ela gerada e incrementada (ou decrementada) internamente por
uma rotina do prprio banco de dados Oracle. Preferimos utilizar o termo em ingls
por ser mais comumente utilizado do que a traduo para lngua local.

3.18

ndice : um objeto de banco de dados de um Schema que pode acelerar o acesso e

a recuperao de linhas em uma Tabela atravs do uso de ponteiros, provendo assim
um acesso direto e rpido s linhas da Tabela.

3.19

Constraint (regra de integridade) : correspondem a uma regra de integridade

aplicada sobre uma determinada Tabela. A constraint definida e mantida no banco
de dados Oracle. Em linhas gerais, constraints, so utilizadas para prevenir entrada
invlida de dados nas Tabelas. Ou seja, implementam regras a nvel de Tabela que
so verificadas toda vez que uma linha inserida, alterada ou excluda na Tabela; se

a regra no for respeitada, a operao no concluda no banco de dados.

Preferimos utilizar o termo em ingls por ser mais comumente utilizado do que a
traduo para lngua local.
3.20

Sinnimo : um nome alternativo para um objeto do banco de dados.

3.21

Trigger (gatilho) : um conjunto de comandos PL/SQL que so executados quando

se realiza uma insero, alterao e/ou excluso em uma Tabela. A trigger
executada (disparada) antes da consumao da operao sobre a Tabela. Se, por
algum motivo, a execuo da trigger no for completada, a operao sobre a Tabela
tambm no . Por isso mesmo, geralmente se utiliza triggers para implementar
regras de integridade complexas e que por isso no podem ser implementadas por
Constraints; tambm so utilizadas para execuo de aes diversas desencadeadas
pela operao de insero, alterao ou excluso sobre a Tabela. Preferimos utilizar
o termo em ingls por ser mais comumente utilizado do que a traduo para lngua
local.

3.22

Role (cargo) : um grupo de privilgios (de sistema e/ou sobre objetos do banco de
dados) que podem ser concedidos a um ou mais usurios. Preferimos utilizar o
termo em ingls por ser mais comumente utilizado do que a traduo para lngua
local.

3.23

Username (nome do usurio): corresponde a um nome pelo qual o usurio

identificado e reconhecido no banco de dados, no sendo necessariamente parte do
nome da pessoa que o usurio do banco de dados. Preferimos utilizar o termo em
ingls por ser mais comumente utilizado do que a traduo para lngua local.

3.24

Tablespace : corresponde a uma rea lgica para armazenamento. Dentro de uma

tablespace so armazenados objetos do banco de dados alm dos prprios dados,
inclusive os dados sobre o banco de dados (dicionrio de dados). Preferimos utilizar
o termo em ingls por ser mais comumente utilizado do que a traduo para lngua
local.

3.25

Datafile : uma estrutura fsica (um arquivo do sistema operacional) onde

fisicamente o contedo de uma Tablespace armazenado. Uma Tablespace
constituda por um ou mais datafiles. Preferimos utilizar o termo em ingls por ser
mais comumente utilizado do que a traduo para lngua local.

4. NORMA TCNICA
4.1

Esta Norma Tcnica deve ser seguida por Equipe de DBAs, Equipes de
Desenvolvimento e Terceiros.

4.2

A denominao do owner de um schema contendo todos os objetos de banco de

dados diretamente relacionados a um sistema ou aplicao deve ser igual sigla
pela qual este mesmo sistema ou aplicao conhecido.

4.3

O nome de uma Tabela deve ser alusivo a natureza dos dados que sero
armazenados nela,

4.4

O nome de uma Coluna de uma Tabela deve ser alusivo a sua finalidade dentro da
Tabela; no caso de um nome muito extenso, deve-se abrevi-lo mantendo, no
entanto, a finalidade da Coluna.

4.5

O nome de uma Coluna deve, obrigatoriamente, comear com um grupo de trs

letras indicando o tipo de dado mais especfico da Coluna, conforme tabela a seguir:
Tipo de dado
Varchar2

Grupo de Letras
STR

Char

CHR

Number

NUM

Integer

INT

REAL

RAL

Data

DAT

Texto

TXT

Imagens

IMG

Utilizao
Utilizado para dados que representam
cadeias de caracteres com um tamanho
varivel mas com possibilidade de se
estimar o tamanho mximo. Cadeias de
caracteres deste tipo podem variar de
tamanho mas sem ultrapassar o tamanho
mximo.
Utilizado para dados que representam
cadeias de caracteres com tamanho fixo
e invarivel, ou seja, todas as cadeias de
caracteres representadas por este tipo
possuem um tamanho nico.
Utilizado para dados que representam
nmeros de uma forma genrica
Utilizado para dados que representam
nmeros inteiros, ou seja, que no
possuem de forma alguma casas
decimais.
Utilizado para dados que representam
nmeros reais, ou seja, de ponto
flutuante e que apresentam casas
decimais.
Utilizado para dados que representam
datas
cronolgicas
informando
obrigatoriamente dia, ms e ano, no
importa a ordem de disposio destas
informaes.
Utilizado para dados que representam
cadeias de caracteres com um tamanho
varivel e sem possibilidade de se
estimar o tamanho mximo. Cadeias de
caracteres deste tipo constituem textos
que podem ser longos ou curtos.
Utilizado para dados que representam
imagens estticas ou vdeos.

4.6

O nome de uma trigger deve ter o seguinte formato :

TG<nome_da_tabela>_<ocasio_disparo><operaes>
onde :
<nome_da_tabela> - nome da Tabela
<ocasio_disparo> - indica se a ocasio do disparo da trigger :
PRE - Antes da operao de insero, alterao ou excluso.
POS - Depois da operao de insero, alterao ou excluso.
<operaes> - indica o tipo de operao sobre o registro:
INS - Insero
UPD - Alterao
DEL - Excluso

4.7

O nome de um procedimentos deve comear com PROC_, ser sugestivo e de fcil

compreenso.

4.8

O nome da funo deve comear com FUNC_, ser sugestivos e de fcil

compreenso.

4.9

O nome da especificao de um Pacote deve comear com PKES_, ser sugestivo e

de fcil compreenso.

4.10

O nome do corpo de um Pacote deve comear com PKBY_, ser sugestivo e de fcil
compreenso.

4.11

O nome de uma View deve comear com VIEW_, ser sugestivo e de fcil
compreenso.

4.12

O nome de uma Sequence deve comear com SEQ_, ser sugestivo e de fcil
compreenso.

4.13

O nome de um ndice deve ser sugestivo, de fcil compreenso, indicar pelo menos
o nome da Coluna a qual indexa e sempre terminar com _I.

4.14

O nome de uma Constraint cuja finalidade estabelecer a chave-primria (primarykey) de uma Tabela, deve indicar o nome da Coluna sobre a qual est definida a
Constraint e deve terminar com _PK.

4.15

O nome de uma Constraint cuja finalidade estabelecer uma chave-estrangeira

(foreign-key) em uma Tabela, deve indicar o nome da Coluna sobre a qual est
definida a Constraint e deve terminar com _FK.

4.16

O nome de uma Constraint cuja finalidade estabelecer uma chave-nica (uniquekey) em uma Tabela, deve indicar o nome da Coluna sobre a qual est definida a
Constraint e deve terminar com _UK.

4.17

O nome de uma Role deve ter o seguinte formato :

RL<sigla_do_sistema>_<nome_do_grupo>
onde :
<sigla_do_sistema> corresponde sigla do sistema que originou a Role, mesmo que
ela esteja atribuda a usurios de outros sistemas ou aplicaes.
<nome_do_grupo> nome do grupo de usurios que compartilham a Role. No h
restris sobre este nome, mas recomenda-se que seja um nome
sugestivo.

4.18

Quando for criada uma conta para um novo usurio no Banco de Dados
Corporativo, o Username para este novo usurio deve ser igual a identificao que
constar no e-mail (antes do smbolo @ ) da pessoa na UNESP associada a este novo
usurio.

4.19

Quando for criada uma conta para um novo usurio no Banco de Dados
Corporativo, se a pessoa associada a este novo usurio no possuir e-mail na
UNESP ou j existir outro usurio com Username igual ao que seria dado ao novo
usurio, cabe Equipe de DBAs definir qual o Username a ser dado para o novo
usurio.

4.20

O nome de uma Tablespace deve ter o seguinte formato :

<sigla_do_sistema_mdulo><finalidade>
onde :
<sigla_do_sistema_mdulo> corresponde sigla do sistema ou a sigla do mdulo
(quando o sistema muito grande e for sub-dividido em
mdulos menores) cujos dados devem ficar armazenados na
Tablespace.
<finalidade> pode ser :
DATA - se a Tablespace se destinar a armazenar dados puros e
os objetos de banco de dados do sistema ou aplicao.
IDX - se a Tablespace se destinar a armazenar ndices.

4.21

O nome do arquivo que representa um Datafile deve ser igual ao nome da

Tablespace a qual estiver associado o Datafile, seguido da extenso .ora, sendo este
nome e a extenso em letras minsculas.

4.22

Quando houver a necessidade de se acrescentar mais Datafiles a uma Tablespace

com o objetivo de aumentar a capacidade de armazenamento dela, o nome de cada
arquivo que representa cada um destes Datafiles (nome este em letras minsculas
apenas) deve ter o seguinte formato :
<nome_do_datafile_original><nmero_sequencia>.ora
onde :
<nome_do_datafile_original> o nome do primeiro Datafile que foi associado
Tablespace quando ela foi criada.
<nmero_sequncia> o nmero de sequncia de cada um dos Datafiles
subsequentes que forem sendo acrescentados Tablespace; este nmero deve ser
representado por dois dgitos, preenchido com zero esquerda quando necessrio e
o primeiro nmero da sequncia deve ser 01.

4.23

As regras de nomenclatura para Tablespaces e Datafiles definidas nesta Norma

Tcnica devem ser seguidas apenas quando tais Tablespaces e Datafiles estiverem
associados a sistemas ou aplicaes desenvolvidos por Equipes de Desenvolvimento
e Terceiros, no se aplicando, portanto, a Tablespaces e Datafiles prprios da
estrutura do Banco de Dados Corporativo ou associados a alguma de suas
funcionalidades ou servios que o banco oferece.

4.24

Quando, num script de criao ou de alterao de um objeto do banco de dados,

aparecer o nome do objeto do banco de dados, este deve ser antecedido sempre pelo
Owner do Schema ao qual pertence o objeto de banco de dados, seguido por um
ponto, ficando no seguinte formato :
Owner_do_Schema.nome_do_objeto_de_banco_de_dados
Isto se aplica para os seguintes objetos de banco de dados :

4.25

Tabela
ndice
View
Procedimento
Funo
Especificao de Pacote
Corpo de Pacote
Trigger
Sequence

O nome de um Sinnimo deve ser exatamente igual ao nome dado ao objeto do

banco de dados sem a parte do Owner do Schema.

4.26

Apenas a Equipe de DBAs deve poder criar, alterar ou excluir Sinnimos.

4.27

Os scripts para criao de Tabelas devem ter as Colunas ordenadas segundo os

critrios a seguir :

4.28

4.29

Primeiro devem vir as Colunas cujo preenchimento obrigatrio (NOT NULL).

A seguir devem vir as Colunas cujo preenchimento no obrigatrio (NULL)

mas que tem maior probabilidade de serem preenchidas futuramente.

Por ltimo devem vir as Colunas cujo preenchimento no obrigatrio (NULL)

e que tem maior probabilidade de no serem preenchidas.

No script de criao ou alterao de uma Tabela, deve ser colocado o parmetro

CACHE para o comando CREATE TABLE quando :

a Tabela ser ou acessada com muito frequncia;

a Tabela possuir poucas Colunas;

a Tabela possuir poucas linhas.

Esta Norma Tcnica est sujeita a revises e alteraes peridicas em funo da

evoluo da tecnologia existente no banco de dados Oracle e da evoluo e
expanso do prprio Banco de Dados Corporativo.

__________________________________________________________________
Fim do Documento : 31/07/2.000
Este documento pode ser obtido em
http://www.unesp.br/ai/pdf/nt-ai.04.04.01.pdf