Manual de Normas E Padrões de Modelagem de Dados: VERSÃO 01 - 08/07/2013

MANUAL DE NORMAS E PADRÕES DE MODELAGEM DE DADOS
VERSÃO 01 - 08/07/2013
Elaborado por Sérgio Luiz Rodigues Chaves

Capítulo 1. INTRODUÇÃO ........................................................................................................ 3
Capítulo 2. OBJETIVOS DA ADMINISTRAÇÃO DE DADOS ............................................................. 4
1. Objetivos ........................................................................................................................ 4
2. Atribuições da função de Administração de dados ................................................................ 4
3. Premissas ....................................................................................................................... 5
4. Responsabilidade das Equipes de Desenvolvimento de Sistemas ............................................ 5
Capítulo 3. POLÍTICAS ............................................................................................................ 6
1. Categorias de Modelos de Dados ........................................................................................ 6
2. Principal Ferramenta de Trabalho ....................................................................................... 6
3. Técnica de Modelagem de Dados Lógica e Física .................................................................. 6
4. Diretriz para Definição de Chave Primária ........................................................................... 7
5. Utilização de Domínio ....................................................................................................... 7
6. Documentação de Conceitos .............................................................................................. 7
7. Diretrizes para Documentação de Restrições de Integridade .................................................. 7
Capítulo 4. ELABORAÇÃO DE MODELOS DE DADOS DURANTE O PROCESSO DE DESENVOLVIMENTO
DE SISTEMAS ........................................................................................................................ 9
1. Macro-Processo ............................................................................................................... 9
2. Planejamento do Projeto ................................................................................................. 10
3. Fase 1 – ENTENDIMENTO DO PROBLEMA / MODELO CONCEITUAL........................................ 10
3.1. Atividades ............................................................................................................... 10
3.2. Produtos Gerados ..................................................................................................... 11
4. Fase 2 - ANÁLISE / MODELO LÓGICO ............................................................................... 11
4.1. Atividades ............................................................................................................... 11
5. Fase 3 – DESENHO / MODELO FÍSICO .............................................................................. 11
5.1. Atividades ............................................................................................................... 11
6. Fase 4 – CONSTRUÇÃO / IMPLEMENTAÇÃO DA BASE DE DADOS.......................................... 13
6.1. Atividades ............................................................................................................... 13
7. OUTRAS CONSIDERAÇÕES .............................................................................................. 13
7.1. Share / unshare de objetos ....................................................................................... 13
7.2. Solicitação de acesso ao Software de Modelagem de dados ........................................... 13
Capítulo 5. PADRÕES ............................................................................................................ 14
1. ORGANIZAÇÃO DOS OBJETOS ......................................................................................... 14
1.1. APLICAÇÕES E LOCALIZAÇÃO DOS OBJETOS DO CASE ................................................. 14
1.2. DIAGRAMA ENTIDADE - RELACIONAMENTOS (Visão Gráfica) ......................................... 14
1.3. O QUE DEVE ESTAR documentado NO MODELO FÍSICO e não deve estar no modelo lógico 15
2. PADRÕES PARA OBJETOS DO MODELO LÓGICO (Objetos do CASE) ...................................... 16
2.1. APLICAÇÃO.............................................................................................................. 16
2.2. ENTIDADE ............................................................................................................... 16
2.3. RELACIONAMENTO ................................................................................................... 18
2.4. DOMÍNIO ................................................................................................................ 18
2.5. ATRIBUTO ............................................................................................................... 18
2.6. FUNÇÕES ................................................................................................................ 20
3. PADRÕES PARA OBJETOS DO MODELO FÍSICO (Objetos de Banco de Dados) ........................ 21
3.1. TABELAS E SINÔNIMOS CORPORATIVOS ..................................................................... 21
3.2. VIEWS .................................................................................................................... 22
3.3. VIEW DE AMBIENTE DE BANCO DE DADOS - UTILIZAÇÃO ............................................. 23
3.4. COLUNAS ................................................................................................................ 23
3.5. CONSTRAINTS ......................................................................................................... 24
3.6. INDEX, SNAPSHOT E SEQUENCES .............................................................................. 25
3.7. TRIGGERS ............................................................................................................... 25
Capítulo 6. DICAS ................................................................................................................. 26
Capítulo 7. NORMAS PARA PROGRAMAÇÃO .............................................................................. 27
Página 1 de 29
1.1. Neste capítulo serão descritos algumas normas de programação fundamentais para a
garantia da qualidade de dados ou facilitar o diagnóstico de problemas relacionados ao Banco de
Dados............................................................................................................................ 27
2. INDEPENDÊNCIA PROGRAMA X DADOS............................................................................. 27
3. TRATAMENTO DE ERROS ................................................................................................ 27
Capítulo 8. GLOSSÁRIO ......................................................................................................... 28
Página 2 de 29
Capítulo 1. INTRODUÇÃO
Este manual tem por finalidade divulgar os objetivos, a metodologia, políticas, normas e padrões
relativos ao processo de Administração e Modelagem de Dados.
Visa facilitar o trabalho dos profissionais de Informática, possibilitando um entendimento mais rápido
do processo de Modelagem e dos Modelos de Dados existentes na Empresa.
Página 3 de 29
Capítulo 2. OBJETIVOS DA ADMINISTRAÇÃO DE DADOS

Para orientar o trabalho de Modelagem, seguem os objetivos e as atribuições da Administração de
Dados.
Como atividade em implantação, os objetivos não serão atingidos imediatamente.
1. Objetivos
São os seguintes os objetivos que determinam a necessidade da função de Administração de Dados:
 Gerenciar os dados como recurso patrimonial estratégico da Empresa.
 Implantar a filosofia de que os dados pertencem à empresa, não sendo propriedade de Áreas
ou Sistemas. Os Sistemas devem ser adaptados para evolução nas estruturas de dados para
atendimento de novas necessidades.
 Proporcionar uma visão abrangente e integrada da Empresa, facilitando assim a compreensão

do negócio, o planejamento estratégico, a tomada de decisão, o controle operacional e as
próprias operações.
 Preservar a qualidade dos dados eliminando redundâncias, identificando seus relacionamentos

e padronizando seus nomes e definições.
 Possibilitar o compartilhamento ou a integração de dados entre ambientes operacionais,

sistemas e usuários, através de modelos lógicos de dados compatíveis, contribuindo
decisivamente para a melhoria da qualidade das informações e, em longo prazo, para o
incremento da produtividade dos processos de desenvolvimento de sistemas e recuperação de
informações.
2. Atribuições da função de Administração de dados

São os seguintes as atribuições necessárias para atendimento dos objetivos:
 Administrar os modelos de Dados Corporativos e de Áreas de Negócio e apoiar os modelos

sistêmicos. Mesmo quando os Modelos de Dados são elaborados pelas Equipes
Desenvolvedoras, a responsabilidade final sobre a organização e estrutura dos Modelos
Corporativos e de Áreas de Negócio é da Administração de Dados.
 Estabelecer, juntamente com a Administração de Banco de Dados, padrões de nomenclatura e

de dicionarização para os elementos de dados, bem como definir normas e procedimentos
visando assegurar a qualidade dos dados e da documentação.
 Administrar o dicionário de dados de forma a garantir uma documentação completa, íntegra e

atualizada dos dados que possibilite o perfeito entendimento sobre os modelos de dados e
banco de dados. Entre os principais tipos de perguntas que a Administração de Dados deve
responder, citam-se:
 Que dados existem nos modelos?
 Quais seus significados?
 Apoiar as equipes de desenvolvimento nas atividades de levantamento e modelagem de seus

sistemas específicos, orientando-os quanto às técnicas e padrões a serem obedecidos, bem
como resolvendo conflitos decorrentes de incompatibilidade de conceito ou de representação
entre os modelos.
 Estabelecer, juntamente com os Analistas e Administração de Banco de Dados, medidas de

integridade dos dados.
Página 4 de 29
3. Premissas
 O conhecimento, a organização e a gerência dos dados corporativos são elementos essenciais
para que as empresas atinjam seus objetivos estratégicos.
 Os dados são o alicerce dos sistemas de informação, os quais são basicamente, funções
atuando sobre os dados.
 Quanto maior o conhecimento do Administrador de Dados sobre o negócio (dinâmica dos

dados), melhor e mais eficientemente conseguirá atingir seus objetivos e executar suas
atribuições.
4. Responsabilidade das Equipes de Desenvolvimento de Sistemas

É responsabilidade das equipes de Desenvolvimento de Sistemas:
 Seguir as políticas, metodologia, normas e padrões contidos neste documento.
 Desenvolver os modelos de dados e manter a exatidão, clareza e atualização da

documentação sobre os Modelos de Dados no Case, de aplicações de sua responsabilidade,
contribuindo para a qualidade dos dados e da correta divulgação das estruturas existentes.
 Desenvolver os mecanismos de garantia de integridade de dados, conforme definido nos

modelos, contribuindo para a qualidade das informações da Empresa.
 Utilizar corretamente as Estruturas de Dados: Utilizar uma estrutura de dados (tabela ou

coluna) para armazenamento de dados diferentes do objetivo para o qual a estrutura foi
criada é um grande obstáculo ao entendimento dos modelos de dados.
 Atribuir nomes adequados, descrever e utilizar corretamente as estruturas.
Página 5 de 29
Capítulo 3. POLÍTICAS
Esse capítulo tem objetivo de descrever diretrizes gerais para o processo de modelagem de dados.
1. Categorias de Modelos de Dados

Este item define as diretrizes para que um modelo de dados ou entidade seja considerado como
Corporativo, de Área de Negócio ou Sistêmico.
 Modelo Corporativo de Dados:

Esse modelo deve conter dados que apresentem as seguintes características:
 Sejam fundamentais ao negócio da Empresa;
 Sejam compartilhados com entidades externas e disponíveis para várias áreas de
negócio da empresa;
 Apresentem alto grau de reusabilidade.
A responsabilidade final do modelo lógico é do Administrador de Dados.
 Modelos de Dados das Áreas de Negócio:

Esses modelos devem conter dados que suportem mais fortemente uma Área de Negócio da
Empresa.
A responsabilidade final do modelo lógico é do Administrador de Dados.
 Modelos Sistêmicos:
Esses modelos atendem a necessidade de um sistema específico e são criados pelos Analistas de
Sistemas, cabendo à Administração de Dados apoiar o processo de modelagem, garantindo a
correção dos modelos e sua aderência aos padrões. Normalmente são objetos de controle ou
dados de processos operacionais de utilização do sistema.
 Pacotes:
Estruturas de dados fornecidas pelo fabricante do pacote e não integrado às estruturas
desenvolvidas para a Leader.
2. Principal Ferramenta de Trabalho

No processo de planejamento e gerência dos modelos de dados, o ERWIN ou Outro modelador de
dados se constitui em uma ferramenta imprescindível para o Administrador, logo, toda
documentação a respeito dos dados, deve estar armazenada no Designer.
Ressaltando que duas visões são extremamente importantes:
 Visão gráfica através do diagrama Entidade – Relacionamento;
 Visão lingüística através do repositório que contenha a definição detalhada e clara dos
elementos do modelo.
3. Técnica de Modelagem de Dados Lógica e Física

Em linhas gerais, a metodologia de Modelagem utilizada está baseada na definição conceitual de
Entidade – Relacionamento que deve sofrer o processo de normalização até a terceira forma, devido
à tecnologia relacional utilizada.
O modelo conceitual puro não será guardado, pode ser efetuado nas primeiras fases do
desenvolvimento (Estudo Preliminar), para levantamento de informações que são posteriormente
refinadas. O objetivo é não aumentar a burocracia na manutenção da documentação, levando-se o
modelo lógico o mais próximo da tecnologia.
Página 6 de 29
O modelo físico deve, em um primeiro momento, ser totalmente derivado do Modelo Lógico e, se
necessário, desnormalizado de acordo com os recursos tecnológicos.
Visando não poluir o modelo lógico facilitando seu entendimento, as tabelas auxiliares criadas com
único objetivo de atender a tecnologia aumentando performance ou a facilidade de programação e
que não contem dados que serão guardados, não devem ter entidade correspondente.
4. Diretriz para Definição de Chave Primária

A chave primária de uma entidade deve, sempre que possível, ser uma chave natural escolhida entre
os atributos que definem univocamente uma linha na tabela. O objetivo dessa diretriz é permitir a
análise de dependência funcional dos diversos atributos de uma entidade e garantir a "real"
integridade referencial nos relacionamentos.
A "sequence" ou “id” do Banco de dados como chave primária não deve ser utilizada exceto nas
seguintes situações:
 A entidade não possui uma chave natural;
 Preservação do histórico do dado na possível alteração da composição da chave natural;
Problemas técnicos, detectados no projeto físico, que devem ser discutidos com o Administrador de
Banco de Dados e Administrador de Dados.
O projeto lógico deve sempre considerar a chave natural e, se houver uma chave natural que não é
utilizada como primary key, as regras de integridade da chave natural devem ser implementadas.
5. Utilização de Domínio
A padronização na definição de tamanho, formato, nome e valores válidos dos atributos é
extremamente importante para integração dos sistemas e para o entendimento das informações.
O Designer disponibiliza o objeto domínio para facilitar essa padronização, não só para valores
possíveis para os atributos e colunas.
Com o objetivo de evitar que a mesma informação seja criada com definições diferentes, toda
informação que tenha a possibilidade de existir em mais do que uma entidade/tabela, que faça parte
de entidades corporativas ou de grande importância para o negócio, deve ser primeiramente criada
como um domínio e posteriormente associada ao atributo da tabela. A implementação será
gradativa.
Todo domínio criado deve ser corporativo visando prever impactos de mudança nas definições do
mesmo.
6. Documentação de Conceitos
Alguns conceitos são importantes para entendimento do Modelo de Dados esclarecendo o significado
de alguma expressão que aparece nas descrições de Entidades e Atributos.
Conceitos desse tipo devem estar documentados no Designer no objeto Business Terminology, na
aplicação relativa a Área de Negócio, que também pode ser utilizado para documentação de outros
conceitos importantes para os sistemas.
7. Diretrizes para Documentação de Restrições de Integridade

As restrições de integridade dos dados devem ser documentadas já no modelo lógico, exceto aquelas
existentes em decorrência de alterações do projeto físico (documentação apenas no projeto físico). A
seguir, a orientação para documentação das restrições no Designer:
Página 7 de 29
TIPO DE RESTRIÇÃO TIPO DE RESTRIÇÃO

Integridade Referencial obrigatória Na própria especificação do relacionamento do Designer
(“optionality”).
Integridade Referencial opcional Na própria especificação do relacionamento do Designer
(“optionality”). A condição da opcionalidade deve estar
documentada no “description” do relacionamento.
Unicidade das linhas “Primary Key” (“Unique key”, P/S = 1). Caso seja criada uma
“sequence” para ser utilizada como PK, se houver atributos
naturais na Entidade que identificam a linha, estes devem ser
documentados como “Unique Key”.
Valores válidos “Allowable values” ou domínio.
Preenchimento obrigatório “Opcional = false”
Preenchimento opcional “Optional = true” / “on condition” especificando a situação que
o atributo deve estar preenchido, se houver.
Derivação de valores de outras Na propriedade "Description" da coluna derivada.
colunas
Valores válidos dependendo de Na propriedade "Description" da coluna derivada.
outras colunas
Página 8 de 29
Capítulo 4. ELABORAÇÃO DE MODELOS DE DADOS DURANTE O PROCESSO

DE DESENVOLVIMENTO DE SISTEMAS
O objetivo deste capítulo é definir o processo de Modelagem de Dados dentro do processo de

Desenvolvimento de Sistemas.
Só serão listadas as atividades que devem ter participação do Administrador de Dados. Não se
propõe a detalhar ou redefinir o processo de Desenvolvimento de Sistemas nem a Metodologia de
Modelagem de Dados.
A participação do Administrador de Dados no processo de Desenvolvimento de Sistemas tem por

objetivo, não só cumprir suas atribuições descritas no Capítulo 1 quanto obter melhor conhecimento
sobre o negócio estando cada vez mais preparado para atingir seus objetivos.
Todo novo sistema ou manutenção evolutiva ou legal que signifique grande impacto, deve passar por
todas as etapas abaixo. As manutenções muito pequenas, como exemplo a criação de apenas uma
coluna, podem ser tratadas como uma solicitação isolada.
1. Macro-Processo
Planejamento Modelo Conceitual Modelo Lógico Modelo Físico Implementação Implementação

(Desenvolvimento) (Produção)
Desenvolvedor ( Analista Responsável pelos Dados da Área de Negócio )
Planeja Levanta Elabora Elabora modelo Solicita Solicita

projeto problema modelo físico e solicita
lógico implementação
Administrador de Dados
Valida modelo Valida modelo, Verifica

Verifica físico quanto a documentação Designer x
abrangência / Participa das Valida modelo aderência ao e padrões DSV
impacto e cria reuniões lógico, lógico,
aplicação no conceituais de documentação documentação e
Case levantamento e padrão padrão
Autoriza Autoriza
Administrador de Banco de Dados
Apoia, valida e Especifica Especifica
complementa parâmetros parâmetros
modelo físico físicos físicos
performance /
produção
Implementa Implementa
base de dados base de dados
Em linhas gerais, a elaboração do modelo de dados é responsabilidade do Analista de Sistemas, no

Designer, evoluindo desde o Modelo Conceitual até o Modelo Físico e sua implementação.
Página 9 de 29
O Administrador de Dados é responsável pela homologação do Modelo de Dados e o Administrador
de Banco de Dados pela implementação.
A participação do Administrador de Dados nas fases anteriores visa, além de apoiar e entender o
negócio para estar capacitado à homologação, identificar os problemas antes da fase de
implementação evitando re-trabalho dos Desenvolvedores.
2. Planejamento do Projeto
A participação do AD e do DBA na elaboração do cronograma e o conhecimento sobre o andamento
do Sistema é importante para que o mesmo possa estimar esforços e se planejar para que possa
cumprir suas atribuições evitando o máximo possível o impacto sobre os prazos acordados com os
usuários.
O Administrador de Dados deve:
 Verificar se esse Sistema se refere a uma nova Área de Negócio.

 Se sim, o Administrador de Dados deve criar uma nova aplicação no Designer para que
possa ser utilizado na Modelagem Conceitual. Nesse caso, o Administrador de Dados dará
o "share" dos objetos corporativos para essa aplicação e de outros objetos de outras
aplicações na medida da necessidade. Veja Capítulo 5 Item ORGANIZAÇÃO DOS OBJETOS
/ APLICAÇÕES E LOCALIZAÇÃO DOS OBJETOS DO CASE.
 Se não, deve verificar o volume de manutenção existente no modelo de dados e decidir se
transfere os objetos para a uma aplicação temporária para que o Desenvolvedor elabore o
modelo de dados de forma independente ou se efetua ele próprio às modificações
necessárias.
3. Fase 1 – ENTENDIMENTO DO PROBLEMA / MODELO CONCEITUAL

Essa fase se destina ao levantamento e análise das necessidades de informação da área, avaliando
alternativas de projeto para a solução das necessidades identificadas. Tem como produtos gerados,
entre outros, o Modelo Preliminar de Dados (conceitual).
Participação do Administrador de Dados:
3.1. Atividades
 Levantamento de Necessidades
Sempre que necessário, e de acordo com planejamento prévio, o Administrador de Dados pode
participar do Levantamento de Necessidades com objetivo de, em modelos mais complexos,
entender melhor a necessidade de informação. Essa estratégia tem como objetivo prover o AD de
conhecimento para apoio nas fases seguintes.
 Elaboração do Modelo Conceitual de Dados

O Modelo Conceitual de Dados tem como objetivo o entendimento das estruturas de dados
necessárias, é elaborado pelo Analista e vai evoluir para Modelo Lógico em fase posterior. É
responsabilidade do Administrador de Dados apoiar o Analista, caso seja solicitado.
 Análise de Integração com Outros Sistemas

Cabe ao Administrador de Dados analisar se as informações já existem em outros modelos
implementados ou em fase de implementação. Caso exista, a utilização dessas entidades deve
ser negociada pelo Administrador de Dados que deve verificar também se os conceitos são
comuns e tentar unificá-los.
O que deve ser verificado pelo Administrador de Dados:

Página 10 de 29
 As entidades importantes para atendimento ao negócio e o relacionamento entre elas, ou

seja, o diagrama de Dados (modelo Lógico).
 A existência de entidades com mesmo objetivo em outros modelos de dados.
3.2. Produtos Gerados

 Diagrama de Entidade – Relacionamento (conceitual / macro) elaborado pelo Analista de
Sistemas organizado em aplicação definida no Planejamento. Não há necessidade de estar
normalizado nem com a lista de atributos completa.
4. Fase 2 - ANÁLISE / MODELO LÓGICO

Nessa fase o Modelo Lógico de Dados é detalhado pelo Desenvolvedor a partir do Modelo Conceitual
de Dados.
A documentação do modelo tem como premissa básica estar suficientemente clara para o pleno
entendimento do mesmo.
4.1. Atividades
O Analista de Sistemas deve:
 Detalhar o Modelo Lógico de Dados com seus atributos, descrições e regras de integridade.
O Administrador de Dados deve:

 Homologar o Modelo Lógico verificando todas as informações do modelo lógico quanto à
estrutura, padrões e descrições suficientes. Sem essa etapa poderá haver impacto nas fases
subseqüentes uma vez que erros podem ser herdados pelo projeto físico gerando re-trabalho
para correção.
O que deve ser verificado pelo Administrador de Dados:

 Objetivo de cada entidade.
 Objetivo de cada relacionamento (e opcionalidade/obrigatoriedade).
 Primary Key de cada entidade.
 Objetivo de cada atributo e a dependência da Primary Key.
 Atributos que devem ter domínio correspondente.
 As regras de integridade dos dados (para cada ocorrência da entidade, atributo,
relacionamento, entre atributos e entre entidades) e a documentação. Já pode ser
discutido qual o mecanismo de controle que será utilizado (domínio, constraint, trigger,
etc).
Opcionalmente essas regras podem ser verificadas no projeto físico. Ver Políticas.

 Diagrama Entidade – Relacionamento completo elaborado pelo Analista de Sistemas e
aprovado pelo Administrador de Dados, com definição de todas as entidades e seus atributos
e domínios e de acordo com os padrões descritos neste manual.
5. Fase 3 – DESENHO / MODELO FÍSICO

Essa fase visa preparar as estruturas de dados para sua implementação.
5.1. Atividades
 Projeto das Estruturas de Dados
A primeira tarefa a ser feita pelos Analistas é a transformação do projeto lógico em físico. A partir
do modelo físico criado à imagem do modelo lógico, o Analista deve fazer os ajustes necessários
Página 11 de 29
para a implementação física e só deve voltar ao Modelo Entidade – Relacionamento para
complementação de alguma informação que não tenha sido percebida nas atividades anteriores.

 Elaborar o modelo físico de dados.
 Aprovar o projeto físico junto ao Administrador de Dados e junto ao Administrador de Banco
de Dados.
 Implementar os mecanismos de controle de integridade de dados de acordo com as definições
da fase anterior e as definidas nesta fase para controle das redundâncias/desnormalizações
geradas.
O Administrador de BANCO de Dados:

 Analisar o projeto de Banco de Dados do ponto de vista de melhor implementação física com
foco nas tabelas e funções críticas, evitando desnormalizações desnecessárias.
 Complementar a documentação no Designer com os parâmetros físicos: tablespace,
particionamento, etc. Opcionalmente essa etapa pode ser efetuada na fase seguinte a essa.
O Administrador de Dados:
 Verificar se todas as redundâncias/desnormalizações geradas foram acordadas e se os
mecanismos de controle das mesmas (check constraint, trigger, etc) foram definidos no
Designer.
 Verificar se todas as views existentes, possuem os conceitos requeridos pelo ponto de vista
do analista, validando este conceito com as tabelas que dão origem as views.
 Verificar se as tabelas auxiliares criadas nesta fase não contem informações consideradas
importantes para a Empresa que não estejam mapeadas em alguma entidade.
Para a análise do projeto físico do banco de dados pelo DBA, o Desenvolvedor deve entregar ao DBA:
 Informações de volume das tabelas no Designer.
 Lista de funções críticas (com os devidos acessos).
Plano de Mapeamento Entidades - Tabelas: A relação Entidade(s)-Tabela(s) pode ser alterada no

projeto físico. Se isso ocorrer, o Desenvolvedor deve refazer o mapeamento no Designer para que as
referências fiquem corretas mesmo que isso signifique re-gerar as tabelas através da ferramenta
Database Design Transformer. Se preferir, o Desenvolvedor pode apresentar o modelo lógico ao DBA
antes da geração do modelo físico no Case.
Mapeamentos lógicos · físicos não suportados pelo Designer são difíceis de se manterem
documentados uma vez que a alteração não pode partir da(s) entidade para a(s) tabela(s). Nesse
caso, o modelo lógico também deve ser alterado.
Ao utilizar a ferramenta “Database Design Transformer”, cuidado para não gerar tabelas que não
pertençam á aplicação (shared). Todas as entidades de todas as aplicações existentes no
repositório são listadas pelo Transformer que permite a geração por uma aplicação que não seja
“owner” da entidade.

 “Data Schema” preenchido completamente, elaborado pelo Analista de Sistemas e aprovado
pelo Administrador de Banco de Dados e Administrador de Dados. Todas as informações a
respeito dos dados devem estar completas e de acordo com os padrões descritos neste
manual.
Página 12 de 29
6. Fase 4 – CONSTRUÇÃO / IMPLEMENTAÇÃO DA BASE DE DADOS
Esse é o momento em que todas as informações do Design são revisadas pelo AD. Todos os objetos
são validados antes da criação dos objetos no banco de dados.
A responsabilidade de criação das bases de dados é do Administrador de Banco de Dados que só fará
a criação após a aprovação do Administrador de Dados.
6.1. Atividades
 Solicitar a implementação ao Administrador de Dados.
O Administrador de Dados:
 Validar todas as informações de todos os objetos do Designer. Verificar padrões, clareza e se
todos os objetos foram previamente aprovados.
 Autorizar a implementação ao Administrador de Banco de Dados.
O Administrador de BANCO de Dados:

 Complementar a documentação no Designer com os parâmetros físicos: Filegroups,
particionamento, etc, caso não tenha sido efetuado na fase anterior.
 Implementar os objetos de dados.

 Bases de Dados criadas pelo Administrador de Banco de Dados.
7. OUTRAS CONSIDERAÇÕES
7.1. Share / unshare de objetos

Durante qualquer fase do projeto, o Desenvolvedor deve consultar a aplicação Corporativa para
verificar se há objetos (entidades, domínios, tabelas, etc.) a serem compartilhados. Se existem, o
share desses objetos deve ser solicitado ao Administrador de Dados. O share deve ser solicitado
também para utilização de objetos de outras aplicações.
7.2. Solicitação de acesso ao Software de Modelagem de dados

O acesso ao Software de Modelagem de Dados deve ser solicitado ao Administrador de Banco de
Dados que vai criar o usuário e enviar a solicitação ao Administrador de Dados que dará os direitos
de acesso às aplicações.
Página 13 de 29
Capítulo 5. PADRÕES
Este capítulo tem o objetivo de documentar os padrões que devem ser utilizados para os modelos e
objetos de dados no Designer. Toda vez que houver algum impeditivo para o cumprimento de algum
padrão, o Administrador de Dados deve ser consultado.
1. ORGANIZAÇÃO DOS OBJETOS
1.1. APLICAÇÕES E LOCALIZAÇÃO DOS OBJETOS DO CASE
As aplicações são definidas no Designer com três objetivos:
 “Aplicação” CORPORATIVA para Entidades Corporativas que são aquelas compartilhadas por
várias Áreas de Negócio. É criada uma única vez pelo Administrador de Dados.
 “Aplicação” das ÁREAS DE NEGÓCIO

Essas aplicações devem conter dados que suportem uma Área de Negócio da Empresa. Nesta
aplicação devem estar documentados todos os objetos de dados do Modelo Lógico (Entidades
e objetos subordinados a elas) e Físico (Tabelas e objetos subordinados a ela) que suportam a
Área.
Os objetos de Função de um sistema não devem estar documentados nestas aplicações, com
exceção do Macro-Modelo Funcional da Área de Negócio, se houver ou rotinas genéricas
utilizadas por todos os sistemas da Área de Negócio.
 “Aplicação” para documentação dos SISTEMAS

Essas aplicações devem conter todos os objetos (de dados e funções) relativas a um sistema
específico. As Entidades consideradas de um sistema específico são aquelas que tem objetivo
único de controle da operação do sistema ou auxiliares na emissão de relatórios e funções
cujos dados não são mantidos. Serão criadas como aplicações "filhas" da aplicação da ÁREA
DE NEGÓCIO ou como aplicações independentes.
 “Aplicação” para PACOTE

Estudado caso a caso. Normalmente terá apenas o modelo físico documentado a partir do
processo de re-engenharia do Designer, em aplicação dedicada ao pacote.
Os Modelos de Dados já existentes e que não estão nesse padrão devem continuar na localização
atual até que seja possível rearrumá-los.
1.2. DIAGRAMA ENTIDADE - RELACIONAMENTOS (Visão Gráfica)

A elaboração do modelo E-R para representação gráfica do modelo é fundamental para o seu
entendimento e divide os diversos assuntos de uma Área de Negócio. Idealmente, seria interessante
ter a visão de todo o modelo de uma determinada Área em um único diagrama, o que não é viável
na maioria dos casos, dado o volume de Entidades. Nesses casos, deve ser criado um diagrama por
assunto.
Algumas regras:
 O nome do diagrama não será padronizado, deve apenas conter o prefixo “ERD_” e deve
identificar o melhor possível o assunto que está representando.
 Diagramas gerados apenas para teste ou estudo pelo Desenvolvedor, deverão ter o nome do
Desenvolvedor e devem ser removidos ao final do teste ou estudo.
Página 14 de 29
O Administrador de Dados manterá diagramas E-R por assunto nas Aplicações/Áreas de Negócio e na
aplicação CORPORATIVA, independentes de Aplicações/Sistemas, com objetivo de visualizar todo o
modelo de dados da Empresa. Esses diagramas terão o prefixo "AD_ERD_" e não devem ser
alterados pelos desenvolvedores sendo responsabilidade do Administrador de Dados mantê-los.
1.3. O QUE DEVE ESTAR documentado NO MODELO FÍSICO e não deve estar no modelo
lógico
Objetos que não devem constar do Modelo Lógico:
 Tabelas auxiliares que permanecerão nos sistemas com finalidades operacionais

diversas como carga periódica, geração de consultas, etc., devem ter o prefixo “A_”
no nome e não devem ter Entidade correspondente.
Página 15 de 29
2. PADRÕES PARA OBJETOS DO MODELO LÓGICO (Objetos do CASE)
Este item destina-se a definir os padrões de documentação que devem ser adotados nos projeto
lógico de dados (Entidades, Atributos, Relacionamentos, etc).
2.1. APLICAÇÃO
O cadastramento no Designer de aplicações deve seguir o seguinte padrão:
2.1.1. Name (Nome)

Essa propriedade deve ter o texto preenchido com a seguinte formação:
XXX - <texto> onde:
XXX: Sigla da aplicação que será utilizada para composição da identificação de

módulos e outros objetos físicos, quando for o caso.
<texto>: Nome da aplicação.
Exemplo:
GEL - COMERCIAL - Aplicação da Área de Negócio Comercial.
COM - COMPRAS - Aplicação para os módulos de Compras da Área Comercial.
2.1.2. Objectives (Objetivos)

Essa propriedade deve relacionar claramente os objetivos do sistema.
Exemplo:
Essa aplicação tem como objetivo principal apoiar a Área de Compras desde o cadastramento de
mercadorias e fornecedores até a elaboração de pedidos.
Principais funções apoiadas:
- Planejamento de Compras;
- Cadastramento de fornecedores;
- Cadastramento de Mercadorias;
- Reposição de Mercadorias.
2.2. ENTIDADE
As entidades devem estar documentadas no Designer da seguinte forma:
2.2.1. Name (Nome)

Conjunto de palavras no singular, separado por "brancos", sem acentos e sem uso de preposições. A
abreviatura só deve ser utilizada se exceder o tamanho máximo permitido e, nesse caso, deve estar
de acordo com o glossário de termos (ver Glossário de Termos neste documento). Deve refletir o
melhor possível o conteúdo da Entidade.
Evitar a utilização de termos de processamento, tais como controle, processo, arquivo, sigla, etc.
Exemplo: MERCADOLOGICO
GRADE TAMANHO.
Página 16 de 29
2.2.2. Short Name
Uma abreviatura do nome da entidade usada como referência em outras telas do Case e como
default para o "alias" de uma tabela em um comando SQL. Recomendado a utilização de quatro a
sete caracteres.
Se não for informado, é gerado automaticamente pelo Case.
Exemplo: MERC
GTAM.
2.2.3. Plural
Nome que será usado como nome da tabela no banco de dados. Deve, sempre que possível, ser o
mesmo da Entidade com a substituição do “branco” por “_”. As palavras podem ser abreviadas de
acordo com o "glossário de termos (ver Glossário de Termos neste documento).".
GRADE_TAM.
2.2.4. Description
Deve ser preenchido com informações a respeito do(s) objetivo(s) e conteúdo da Entidade, ou seja,
que conjunto de dados é representado pela Entidade. Deve ser o mais completo e claro possível de
maneira a facilitar o entendimento a respeito da mesma. Sempre que houver exceção, também deve
ser explicada.
Exemplo: Propriedade Description da Entidade SKU:

"Registra, para cada produto, as diversas combinações de tamanhos e cores que a
empresa comercializa (Stock Keeping Unit)".
Exemplo: Produto: Sapato XYZ referência ABCDEF
Skus: Sapato XYZ referência ABCDEF cor Marrom tamanho 36
Sapato XYZ referência ABCDEF cor Marrom tamanho 37
Sapato XYZ referência ABCDEF cor Marrom tamanho 38
Sapato XYZ referência ABCDEF cor Preto tamanho 36.".
2.2.5. Atributos para Auditoria / depuração

Toda entidade, e posteriormente toda tabela, deverá ter os atributos definidos abaixo. Estes
atributos, se necessário, serão usados para futuras auditorias:
Para os sistemas do Comercial :
DAT_INCL DATE Obrigatório

NOM_USU_INCL VARCHAR2(15) Obrigatório
DAT_ALTER DATE Opcional
NOM_USU_ALTER VARCHAR2(15) Opcional.
Para o Sistema do Cartão e Automação :

USUARIO_INCL NUMBER(5) Obrigatório
USUARIO_ALTER NUMBER(5) Opcional.
Para o Sistema Web :

Página 17 de 29
INTMATRICULA_INCL VARCHAR2 (9) Obrigatório
INTMATRICULA_ALTER VARCHAR2 (9) Opcional.
Observação: Há domínios criados para os atributos acima e os mesmos devem ser utilizados para
efeito de padronização.
2.2.6. Organização dos atributos na Entidade

Os atributos e posteriormente as colunas devem inicialmente estar ordenados na Entidade da
seguinte forma:
Atributos da chave natural (não formados pelos relacionamentos),
Atributos da Entidade,
Atributos de Auditoria.
2.3. RELACIONAMENTO
2.3.1. Nome
Nome do relacionamento expresso por um verbo no presente, infinitivo ou particípio. Sempre que
possível, criar frase significativa do relacionamento.
Exemplo: CURSO freqüentado por ALUNO
ALUNO freqüenta CURSO.
2.4. DOMÍNIO
O nome do domínio segue o mesmo padrão do nome do atributo, exceto nas situações abaixo:
Caso o domínio seja "parte" de outro domínio por divisão de colunas, deve levar um prefixo de
numeração estruturado para agrupar as partes e deve conter a coluna "subset of" apontando para
um item de grupo.
Exemplo: Domínio 1. NUM_CGC
Domínio 1.1 NUM_CGC_RADIC subset of 1. NUM_CGC.
Domínio 1.2 NUM_CGC_ESTAB subset of 1. NUM_CGC.
Domínio 1.3 NUM_DV subset of 1. NUM_CGC.
Caso o domínio seja “parte” de outro domínio por utilizar um subconjunto de valores, deve conter o
nome do domínio já existente na coluna "subset of". Nesse caso, o nome do domínio deve ser o
mesmo do domínio que contem todos os valores, com algum complemento.
Exemplo: Domínio IND_ESTADO_CIVIL valores (Solteiro, Separado, Casado, Divorciado,
Desquitado, Outros).
Domínio IND_ESTADO_CIVIL_XXX valores (solteiro, Casado, Separado, Outros).
Atenção: Para a CG_REF_CODES que não tem o conceito de aplicação. Ao ser gerado um domínio
com mesmo nome de outro, o anterior é recoberto. Por esse motivo, analisar a necessidade de
inclusão do domínio na aplicação CORPORATIVA (veja Utilização de Domínio).
2.5. ATRIBUTO
2.5.1. Name (Nome)

O nome deve refletir o máximo possível o dado contido no atributo. Deve ter a seguinte formação:
XXX_YYYYYY_..._YYYYYY onde:
Página 18 de 29
XXX - Três letras que identificam a natureza da coluna, de acordo com o Glossário de termos
(ver Glossário de Termos neste documento).
YYYYYY - Abreviatura até seis letras que identifica cada qualificador da coluna, de acordo com
o Glossário de termos (ver Glossário de Termos neste documento).
Exemplo: VAL_PAGTO
DSC_PRODUT.
Se houver domínio correspondente, e o domínio não refletir apenas uma lista de valores genérica, o
nome do atributo deve ser formado pelo nome do domínio podendo ser complementado (o prefixo de
agrupamento do domínio deve ser retirado).
Exemplos: IND_ESTADO_CIVIL.
Exemplo: domínio "1.1. NUM_CGC_RADIC", atributo: "NUM_CGC_RADIC".

Exemplo de domínio cujo nome não deve ser utilizado como nome do atributo: IND_SIM_NÃO.
Exemplo de domínio cujo nome deve ser utilizado como nome do atributo: IND_ESTADO_CIVIL.
2.5.2. Existência de Domínio

Ao criar um novo atributo, o Desenvolvedor deve verificar se existe um domínio para esse dado. Se
sim, deve associá-lo ao atributo.
2.5.3. Comment
Descrição reduzida do objeto.
2.5.4. Description
Deve ser preenchido com a descrição do objetivo, significado e conteúdo, de forma completa e clara,
de maneira a facilitar o entendimento a respeito do atributo.
Exemplo: TXT_EMAIL
Endereço eletrônico completo utilizado para envio de mensagens eletrônicas via
Internet.
2.5.5. Diversos
 As propriedades FORMAT e MAXIMUM LENGHT devem estar preenchidos.
 Regras de integridade que não tem documentação natural no Designer (ver Capítulo 3 Item
Diretrizes para Documentação de Restrições de Integridade).
2.5.6 Tipo de Prefixos dos Atributos

Tipos de prefixo permitidos para os atributos
 NUM
utilizado para campos numérico
 NUM_SEQ
para chaves primárias seqüências ex: num_seq_padronização da tabela padronização
 COD
cógido alfanumérico para identificar um domínio que pode virar uma tabela
 VAL /VLR
para atributos com valores
 QTD
para atributos com quantidade
 PRC
para atributos com percentuais
 DSC
Página 19 de 29
para atributos descritivos ex: dsc_casa significa a descrição da casa
 TXT
para campos textos
 IND
para indicadores de máximo 2 elementos
 DAT
para campos data
 NOM
para atributos com nome ex: nom_cliente
2.6. FUNÇÕES
Padrão não verificado pelo Administrador de Dados.
2.6.1. Short Definition

Macro-função: Formado por um ou mais substantivos.
Exemplo: ELABORAÇÃO PEDIDOS.
Função elementar: Combinação de um verbo com um ou mais substantivos.

Exemplo: VERIFICAR PLANEJAMENTO DE VENDAS.
2.6.2. Label
Formado pela sigla do sistema e uma numeração que define a hierarquia no diagrama de funções.
Exemplo
Sigla do sistema: COM
Label da função inicial: COM
Label de duas macro-funções (segundo nível): COM1
COM2
Label de uma função elementar (terceiro nível) hierarquicamente subordinado a COM1:
COM1.1 ou COM1.1.
Página 20 de 29
3. PADRÕES PARA OBJETOS DO MODELO FÍSICO (Objetos de Banco de Dados)
3.1. TABELAS E SINÔNIMOS CORPORATIVOS
3.1.1. Name (Nome)

Conjunto de nomes no singular, separados por “_”, sem acentos, sem uso de preposições. Deve,
sempre que possível, ser igual ao nome da entidade com a substituição do "branco" por "_". As
PALAVRAS NÃO PODEM SER ABREVIADAS e se tiver a necessidade dever ser tentar abreviar
em 6 posições .
Deve ter o mesmo conteúdo da propriedade PLURAL da Entidade.
GRADE_TAMANHO.
REGRA_CONCOR_PRECO_FILIAL ( CONCOR vem de concorrência e foi abreviada em
6 posições ).
Em exceção, sinônimos criado com o objetivo de forçar o acesso a tabelas de instância/owner

diferente, devem ter a seguinte formação:
 <OWNER da tabela na instância>_<nome da tabela>.
Exemplo:
GEL_ABRANG_INVENT: Sinônimo criado no owner CDR na instância CD01 para acesso a
tabela ABRANG_INVENT, owner GEL em LMPRD03.
3.1.2. Nome para Tabelas Auxiliares

Mesma regra de nome de Tabela sendo precedida por “A_” para tabelas auxiliares que permanecerão
no sistema com finalidades diversas, tais como, carga periódica, geração de consultas, etc.
Exemplo: A_RANK_FORNECEDOR_01
3.1.3. Nome para Tabelas Temporárias

Mesma regra de nome de Tabela sendo precedida por “A_DROPAR_” para tabelas criadas para
trabalhos temporários e que serão "dropadas" após a finalização do trabalho, tais como, carga inicial,
conversão de sistemas, etc.
Exemplo: A_DROPAR_ANALISE_ITEM_NATAL_2002.
3.1.4. Existência da Entidade correspondente.

Para cada Tabela definida, deve existir a Entidade correspondente com exceção das Tabelas
Auxiliares e Temporárias, que são aquelas com prefixo “A_” e “A_DROPAR_” utilizadas para
processos de carga, facilitar consultas, implantação de sistemas, etc. Estas tabelas não precisam ter
Entidades correspondentes, não precisam estar no Diagrama E-R e devem ser criadas na aplicação
do sistema.
3.1.5. Alias
Uma abreviatura do nome da tabela. Deve, sempre que possível, ser o mesmo do Short Name da
Entidade. Recomendado de quatro até sete caracteres.
Exemplo: MERC
GTAM.
Página 21 de 29
3.1.6. Description
Deve ser preenchido com informações a respeito do(s) objetivo(s) e conteúdo da Tabela. Deve ser o
mais completo e claro possível de maneira a facilitar o entendimento a respeito da mesma. Sempre
que houver exceção, também deve ser explicada.
Sempre que houver a Entidade correspondente, deve ser igual à descrição da Entidade com as
modificações e observações que existem na Tabela.
Exemplo: Propriedade Description da tabela CURSO:

"Contem todos os cursos que são ou já foram ministrados pela Instituição exceto aqueles que
estão em fase de teste para análise de viabilidade técnica e aceitação. Os cursos que
sofreram modificação em sua estrutura (tópicos do programa, forma de treinamento, etc)
serão marcados descontinuados e cadastrados como novos".
3.1.7. Comment
Deve ser preenchido com um resumo da descrição da Tabela.
Exemplo: Tabela: CURSO
Comment: Cursos que são ou já foram ministrados pela Instituição.
3.1.8. Colunas para Auditoria

Toda tabela, exceto tabela auxiliar, deverá ter as colunas definidas abaixo:

NOM_USU_INCL VARCHAR2(15) Obrigatório
NOM_USU_ALTER VARCHAR2(15) Opcional.
Observação: Há domínios criados para os atributos acima e os mesmos devem ser utilizados para
efeito de padronização.
3.1.9. Organização das colunas na Tabela

As colunas devem inicialmente estar ordenadas na Tabela da seguinte forma:
PK,
FK,
Atributos da Entidade,
Trilha de Auditoria,
Trilha de Auditoria de Acertos.
No mapeamento de uma entidade “fraca”, a PK da tabela “forte” deve ser a primeira coluna da
tabela “fraca”.
Esta ordem também deve estar na definição da Constraint FK de tabelas relacionadas.
3.2. VIEWS
3.2.1. Nome
Segue a mesma regra do nome da Entidade com exceção que deve ser precedido por:
“V_” - para views que só as aplicações estruturadas utilizam.
“V_U” - para views do ambiente transacional que são utilizadas pelos usuários através de
Ferramentas abertas (exemplo: Excel).
Página 22 de 29
Exemplo: V_VENDA_DIARIA_SKU.
Em exceção, views criadas em substituição a sinônimos, com o objetivo de acessar tabelas em outra
instância de banco de dados, devem ter a seguinte formação:
<OWNER da instância onde reside a tabela>_<nome da tabela>.
Exemplo:
 View criada em LMPRD03, owner GEL para acesso à tabela CONTROLE_NOTA existente em
CD01, owner CDR:
CDR_CONTROLE_NOTA.
3.3. VIEW DE AMBIENTE DE BANCO DE DADOS - UTILIZAÇÃO

Views de ambiente banco de dados, exemplo V_$OPTION ou sys.sysobjects , não podem ter
comandos de INSERT, UPDATE e DELETE. Views de aplicativos que se referenciam a views de
ambiente Oracle também não podem utilizar esses comandos.
3.4. COLUNAS
3.4.1. Nome
Segue a mesma regra do Nome de Atributo e deve ser o mesmo quando houver atributo
correspondente.
Exemplo: VAL_PAGTO
DSC_PRODUT.
3.4.2. Comment
Descrição reduzida do objeto.
3.4.3. Description
Deve ser preenchida com a descrição o mais completa e clara possível de maneira a facilitar o
entendimento a respeito do atributo. Se houver atributo correspondente, deve ser igual ao atributo
com as observações de diferenças, se houver.
Exemplo: DSC_EMAIL
Endereço eletrônico completo utilizado para envio de mensagens eletrônicas via
Internet.
A mesma regra sobre utilização de domínio especificada para o atributo é válida para a coluna.
3.4.4. Source Attribute

Se houver atributo correspondente, deve estar preenchido com o nome do mesmo. Atenção para
tabelas e colunas não criadas através do Transformer.
3.4.5. Manutenção em Colunas de Tabelas já existentes

Deve ser verificado o impacto sobre os dados já existentes. No caso de inclusão e alteração, se as
linhas existentes ficarão com valor íntegro. Em qualquer caso, se há outras colunas relacionadas,
como total, por exemplo, e se ficarão com valor íntegro.
Página 23 de 29
3.4.6. Diversos
 As propriedades DATATYPE e MAXIMUM LENGHT devem estar preenchidas e iguais às colunas
FORMAT e MAXIMUM LENGTH da Entidade, quando houver.
As colunas que são criadas para armazenar Foreign Keys devem ter o mesmo nome, tamanho,
formato, comentário e descrição da coluna original. Podem ser complementadas com algum prefixo
quando fundamental para o entendimento do significado do relacionamento ou houver mais de um
relacionamento.
3.5. CONSTRAINTS
O padrão de nome de constraint deve ser utilizado para aquelas que não são geradas
automaticamente pelo Designer. As constraint geradas pelo Designer não precisam ter seu nome
alterado.
3.5.1. Primary Key

 NOME
O nome deve ter a seguinte formação: <name> ou <short name da tabela>_PK, onde:
PK = sufixo identificador de Primary Key.
Observação: Padrão gerado pelo Designer.
 ALTERAÇÃO DE VALOR DE PRIMARY KEY

Toda tabela, exceto as Auxiliares e Temporárias, deve possuir o trigger que impede alteração de
chave primária, pois o Oracle não restringe esta alteração.
Exemplo:
/* Verifica se o código da aplicação foi alterado. */
IF updating(‘cod_aplic’) THEN
IF :new.cod_aplic != :old.cod_aplic THEN
raise_application_error(-20001,
‘BR02 – O Código da Aplicação não pode ser alterado.’);
END IF;
END IF;
 MANUTENÇÃO DE PK
Deve ser avaliado o impacto em outras tabelas e negociada a alteração com todas as Áreas de
Desenvolvimento impactadas. A responsabilidade é Desenvolvedor que pode solicitar o apoio do
Administrador de Dados.
Atenção para o fato do Designer não replicar a alteração para as tabelas que utilizam a PK como
Foreign KEY.
3.5.2. Nome de Unique Key

O nome deve ter a seguinte formação: <short name da tabela>_UKnn, onde:
UK = sufixo identificador de Unique Key
nn = numeração sequencial a partir da Segunda constraint UK da
tabela.
3.5.3. Nome de Foreign Key

O nome deve ter a seguinte formação:
<short name da tabela (destino)>_<short name da tabela (origem)>_FK ou
Página 24 de 29
<short name da tabela (destino)>_<short name da tabela (origem)>_FKnn, onde:
FK = sufixo identificador de Foreign Key
nn = número seqüencial para o caso de haver mais que um relacionamento entre as mesmas
tabelas.
3.5.4. Nome de Check

O nome deve Ter a seguinte formação: C_< nome da tabela >_CK_nn ou
C_< short name da tabela >_CK_nn, onde:
C = prefixo da Constraint
CK = sufixo de Check
nn = número seqüencial por constraint CK da tabela.
3.5.5. Diversos
 Para cada Foreign Key deve haver o relacionamento definido no projeto lógico
(relacionamento entre as entidades envolvidas) com a propriedade “relationship” preenchida
com o nome do relacionamento.
3.6. INDEX, SNAPSHOT E SEQUENCES

Estes padrões não serão verificados pelo Administrador de Banco de Dados.
3.6.1. Nome
O nome deve ter a seguinte formação: x_< nome da tabela >_nn ou
x_< short name da tabela >_nn, onde
x = I para Index de colunas que não sejam PK ou UK,

SP para Snapshot,
S para Sequence.
nn = Numeração seqüencial de cada objeto para a tabela.
Exemplo: S_TIPO_ATENDIMENTO_03
S_D_FUNCI_O2.
3.7. TRIGGERS
3.7.1. Nome
O nome deve ter a seguinte formação: T_< nome da tabela >_tynn ou
T_< short name da tabela >_tynn, onde
t = A para After
B para Before
Y = R para Row
S para Statement
nn = 01 para insert
02 para update
03 para delete
04 para insert/update
05 para insert/delete
06 para update/delete
07 para insert/update/delete.
Página 25 de 29
Exemplo: T_FUNCIONARIO_AR01.
T_DIM_FUNCIONARIO_AR01.
Capítulo 6. DICAS
Este capítulo se destina a documentar algumas “dicas”, apenas como apoio às Equipes de
Desenvolvimento de Sistemas.
Página 26 de 29
Capítulo 7. NORMAS PARA PROGRAMAÇÃO
1.1. Neste capítulo serão descritos algumas normas de programação fundamentais para a garantia
da qualidade de dados ou facilitar o diagnóstico de problemas relacionados ao Banco de Dados.
2. INDEPENDÊNCIA PROGRAMA X DADOS

A fim de preservar a independência programas x dados, comandos SQL de acesso ou atualização de
dados que não especificam as colunas (SELECT *, INSERT INTO <tabela> VALUES, etc) não devem
ser utilizados mesmo que inicialmente o programa utilize todas as colunas.
Esses comandos, além de aumentar o grau de dependência do programa às colunas não utilizadas,
sobrecarregam o banco de dados além da necessidade.
3. TRATAMENTO DE ERROS
Erros do Banco de dados devem ser tratados pelos programas mesmo que o tratamento seja o mais
simples possível identificando o ponto ou comando do banco de Dados do programa onde o erro
ocorreu.
No caso de programas de atualização de dados, o não tratamento pode ter conseqüências

gravíssimas uma vez que uma próxima atualização pode "commitar" a transação incompleta
anterior.
Em programas de atualização o tratamento do erro do Banco de Dados deve incluir o comando

"rollback". A exceção a essa norma deve ser cuidadosamente analisada.
Em programas de consulta e atualização, o erro deve ser mostrado em forma de log, tela ou
qualquer outro mecanismo, ajudando no diagnóstico de algum problema de banco de dados.
Página 27 de 29
Capítulo 8. GLOSSÁRIO
AD - Administrador de Dados.
DBA - Administrador de Banco de Dados.
Desenvolvedor - Qualquer pessoa que participe do Desenvolvimento de

Sistemas que, segundo a atribuição especificada pelo Gerente de Equipe da Área Responsável pela
Aplicação, participe da definição dos dados.
Glossário de Termos - Dicionário mantido pela Administração de Dados, que

relaciona termos mnemônicos, e seu significado, que devem ser utilizados sempre que houver
necessidade de abreviar termos na nomeação de objetos. Define também, mnemônicos que podem
ser usados como natureza na nomeação de atributos e colunas. Está descrito no documento
Leader_Glossario_Termos. Pode ser acessado através do objeto Document criado na aplicação AD
no Designer.
Objetos Banco de dados - ou Objetos de Banco de Dados - Qualquer objeto que

necessite ser identificado e cadastrado no ambiente de Banco de dados. São eles: Função,
Procedure, Tabela, Coluna, Índice, Constraint, Trigger e View. O domínio, como exceção, também é
encarado como um objeto de banco de dados para efeito deste manual.
Página 28 de 29

Manual de Normas E Padrões de Modelagem de Dados: VERSÃO 01 - 08/07/2013

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Manual de Normas E Padrões de Modelagem de Dados: VERSÃO 01 - 08/07/2013

Enviado por

Direitos autorais:

Formatos disponíveis

MANUAL DE NORMAS E PADRÕES DE MODELAGEM DE DADOS

Elaborado por Sérgio Luiz Rodigues Chaves

Capítulo 2. OBJETIVOS DA ADMINISTRAÇÃO DE DADOS

 Gerenciar os dados como recurso patrimonial estratégico da Empresa.

 Proporcionar uma visão abrangente e integrada da Empresa, facilitando assim a compreensão

 Preservar a qualidade dos dados eliminando redundâncias, identificando seus relacionamentos

 Possibilitar o compartilhamento ou a integração de dados entre ambientes operacionais,

2. Atribuições da função de Administração de dados

 Administrar os modelos de Dados Corporativos e de Áreas de Negócio e apoiar os modelos

 Estabelecer, juntamente com a Administração de Banco de Dados, padrões de nomenclatura e

 Administrar o dicionário de dados de forma a garantir uma documentação completa, íntegra e

 Apoiar as equipes de desenvolvimento nas atividades de levantamento e modelagem de seus

 Estabelecer, juntamente com os Analistas e Administração de Banco de Dados, medidas de

 Quanto maior o conhecimento do Administrador de Dados sobre o negócio (dinâmica dos

4. Responsabilidade das Equipes de Desenvolvimento de Sistemas

 Seguir as políticas, metodologia, normas e padrões contidos neste documento.

 Desenvolver os modelos de dados e manter a exatidão, clareza e atualização da

 Desenvolver os mecanismos de garantia de integridade de dados, conforme definido nos

 Utilizar corretamente as Estruturas de Dados: Utilizar uma estrutura de dados (tabela ou

 Atribuir nomes adequados, descrever e utilizar corretamente as estruturas.

1. Categorias de Modelos de Dados

 Modelo Corporativo de Dados:

 Modelos de Dados das Áreas de Negócio:

2. Principal Ferramenta de Trabalho

Ressaltando que duas visões são extremamente importantes:

 Visão gráfica através do diagrama Entidade – Relacionamento;

3. Técnica de Modelagem de Dados Lógica e Física

4. Diretriz para Definição de Chave Primária

7. Diretrizes para Documentação de Restrições de Integridade

TIPO DE RESTRIÇÃO TIPO DE RESTRIÇÃO

Capítulo 4. ELABORAÇÃO DE MODELOS DE DADOS DURANTE O PROCESSO

O objetivo deste capítulo é definir o processo de Modelagem de Dados dentro do processo de

A participação do Administrador de Dados no processo de Desenvolvimento de Sistemas tem por

Planejamento Modelo Conceitual Modelo Lógico Modelo Físico Implementação Implementação

Planeja Levanta Elabora Elabora modelo Solicita Solicita

Valida modelo Valida modelo, Verifica

Em linhas gerais, a elaboração do modelo de dados é responsabilidade do Analista de Sistemas, no

O Administrador de Dados deve:

 Verificar se esse Sistema se refere a uma nova Área de Negócio.

3. Fase 1 – ENTENDIMENTO DO PROBLEMA / MODELO CONCEITUAL

Participação do Administrador de Dados:

 Elaboração do Modelo Conceitual de Dados

 Análise de Integração com Outros Sistemas

O que deve ser verificado pelo Administrador de Dados:

 As entidades importantes para atendimento ao negócio e o relacionamento entre elas, ou

3.2. Produtos Gerados

4. Fase 2 - ANÁLISE / MODELO LÓGICO

O Administrador de Dados deve:

O que deve ser verificado pelo Administrador de Dados:

4.2. Produtos Gerados

5. Fase 3 – DESENHO / MODELO FÍSICO

O Analista de Sistemas deve:

O Administrador de BANCO de Dados:

Plano de Mapeamento Entidades - Tabelas: A relação Entidade(s)-Tabela(s) pode ser alterada no

5.2. Produtos Gerados

O Administrador de BANCO de Dados:

6.2. Produtos Gerados

7.1. Share / unshare de objetos

7.2. Solicitação de acesso ao Software de Modelagem de dados

1. ORGANIZAÇÃO DOS OBJETOS

1.1. APLICAÇÕES E LOCALIZAÇÃO DOS OBJETOS DO CASE

As aplicações são definidas no Designer com três objetivos: