MGD Manual de Administracao e Nomenclatura

Prévia do material em texto

PRINT - Manual de Técnicas e Administração de Dados do Projeto Integração 
 
 
Manual de Padrões de Nomenclatura de Objetos 
 
Versão 1 - 23/6/2010 Página 1 de 1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Manual de Técnicas e 
Administração de Dados do 
Projeto Integração 
 
 
 
 
Versão 2.0 
14 de julho de 2009 
 
 
PRINT - Manual de Técnicas e Administração de Dados do Projeto Integração 
 
 
Manual de Padrões de Nomenclatura de Objetos 
 
Versão 1 - 23/6/2010 Página 2 de 2 
Ficha Técnica 
Marcos Vinicius Ferreira Mazoni 
Diretor-Presidente 
Gilberto Paganotto 
Diretor-Superintendente 
Antonio Sérgio Borba Cangiano 
Jorge Luiz Guimarães Barnasque 
José Antônio Borba Soares 
Nivaldo Venâncio da Cunha 
Vera Lucia de Moraes 
Diretores 
Marcus Vinicius da Costa 
Líder do Projeto 
Alex Pires Bacelar 
Márcia Pacitti Teles 
Raul Coelho Soares 
Rosângela Gomes da Nóbrega 
Welson de Marino Vianna 
Equipe Responsável pela Elaboração 
 
Público Alvo 
Este manual destina-se aos administradores de dados, analistas de negócio do Serpro e dos 
clientes, desenvolvedores e especialistas envolvidos nos serviços de integração e de 
macroprocessos do Governo Federal. 
 
 
 
 
 
Este manual foi elaborado envolvendo as Superintendências de Relacionamento com Clientes 
Administração Tributária e Comércio Exterior – SUNAC, Administração Financeira – SUNAF, 
Sistemas Fazendários e Judiciais – SUNFJ, Planejamento, Orçamento e Gestão – SUNMP, Novos 
Negócios – SUNNE e Serviços Especiais – SUNSE, as Superintendências de Suporte à 
Tecnologia – SUPST e Desenvolvimento – SUPDE, além da Coordenação Estratégica de 
Tecnologia – CETEC, contando com a colaboração de todas as áreas de administração de 
dados do SERPRO, em especial a que atende a Receita Federal do Brasil, devida a sua larga 
experiência e proficiência em administração de dados. 
 
PRINT - Manual de Técnicas e Administração de Dados do Projeto Integração 
 
 
Manual de Padrões de Nomenclatura de Objetos 
 
Versão 1 - 23/6/2010 Página 3 de 3 
Sumário 
INTRODUÇÃO .......................................................................................................... 4 
REFERÊNCIAS.......................................................................................................... 5 
ÁREAS DE NEGÓCIO ............................................................................................... 6 
Regras de Sintaxe...................................................... 6 
ENTIDADES COMPARTILHADAS........................................................................... 7 
ENTIDADES .............................................................................................................. 8 
Entidades Normalizadas ............................................. 8 
Nome de Entidades ................................................... 8 
Descrição................................................................... 8 
Outras informações.................................................... 8 
Compartilhamento de Entidades ............................... 9 
Unicidade na nomeação de Entidades ....................... 9 
Regras de Sintaxe...................................................... 9 
ATRIBUTOS ............................................................................................................ 10 
Ordem na Entidade.................................................... 10 
Descrição................................................................... 10 
Outras informações.................................................... 10 
Formato para atributos Numéricos ............................. 11 
Formato para atributos Alfanuméricos ........................ 11 
Regras de Sintaxe...................................................... 11 
RELACIONAMENTOS ............................................................................................ 13 
Nomeação ................................................................. 13 
Fontes ....................................................................... 14 
Cores......................................................................... 15 
Grau do Relacionamento............................................ 18 
Restrição de Integridade............................................ 18 
Relacionamento N-ário (onde N >=2). ....................... 19 
Agregação ................................................................. 20 
Entidade Fraca........................................................... 21 
Uma Categorização Exclusiva ..................................... 23 
Várias Categorizações Exclusivas ................................ 24 
Auto Relacionamento - Caso 1 – 1:N .......................... 25 
Auto Relacionamento - Caso 2 – N:N.......................... 26 
GLOSSÁRIO............................................................................................................ 28 
BIBLIOGRAFIA ...................................................................................................... 30 
 
Manual de Padronização de Nomenclatura de Objetos 
Manual de Padrões de Nomenclatura de Objetos 
 
Introdução - P4 / 1
Versão 1 - 23/6/2010 Página 4 de 4 
 
Introdução 
O objetivo desse Manual é orientar os técnicos na execução dos trabalhos 
desempenhados pelos Administradores de Dados (AD), Desenvolvedores e Analistas 
de Negócio do SERPRO e dos Clientes considerando: 
� Normas e padrões adotados durante a modelagem; 
� Uso do Oracle Designer 10G, conjunto de ferramentas de apoio à 
engenharia de sistemas, utilizando de forma produtiva os recursos que 
esta ferramenta CASE oferece e definindo procedimentos que superem 
as limitações da mesma. 
A abordagem adotada é que cada objeto utilizado na modelagem de dados seja 
apresentado em um capítulo específico, na seqüência natural de trabalho, facilitando, 
assim, a forma de acesso e aplicabilidade deste manual. 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 5 de 5
 
Referências 
 Modelo Global de Dados MGD do projeto PRINT, primeira, segunda, terceira e quarta 
versões, no nível conceitual de dados. 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 6 de 6
 
Áreas de Negócio 
Cada área de negócio identificada no MGD será, a princípio, representada no CASE em 
um Application System (AS). 
 
Quando as entidades modeladas em uma mesma área de negócio do MGD tiverem 
uma dependência muito forte entre si, representa-se as mesmas em um único AS para 
evitar compartilhamentos excessivos e desnecessários de objetos comuns; 
Uma AS conterá entidades de negócio e de domínio; 
Por exemplo, as principais áreas de negócio do Ministério de Planejamento 
contempladas no MDG são: 
 Planejamento e Orçamento 
 Administração de Pessoal 
 Administração de Compras e Contratações 
 Administração de Patrimônio 
 Gestão Governamental e Integração 
Regras de Sintaxe 
Objeto do CASE que será utilizado de várias maneiras a fim de representar: Classes de 
negócio, Classes de domínio, Área de desenvolvimento de sistemas 
 {Sigla dona da Área de negócio } + mnemônico do Application System_;GLOBAL 
A Sigla dona da área de negócio deve dizer o contexto e escopo necessário para 
correta identificação,auxiliando também na organização do repositório. 
Ex.: MP PLANEJAMENTO E ORÇAMENTO; MP ADMINISTRAÇÃO DE COMPRAS E 
CONTRATACOES; MF EXECUCAO ORCAMENTARIA 
 
GLOBAL para entidades de negócio e domínio de uso compartilhado por mais de 
uma AS. 
 
 
 
 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 7 de 7
Entidades Compartilhadas 
Será criada uma única AS chamada de GLOBAL. Esta AS conterá todas as entidades 
de uso compartilhado por mais de uma AS de Negócio. Poderá conter entidades de 
domínio e entidades de negócio de uso geral. 
 
 
 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 8 de 8 
Entidades 
Entidades Normalizadas 
As entidades ao serem dicionarizadas no Designer devem estar modeladas seguindo as 
regras de normalização até a terceira forma normal. 
Nome de Entidades 
A nomeação de entidades deve estar vinculada ao nome utilizado pelo negócio. Usar 
propriamente preposições e concordância verbal e nominal e não ferir o português, uma 
vez que algumas locuções exigem o plural: Centro de Custos, Suprimento de Fundos, 
Fonte de Recursos. Não usar acentuação no Nome da Entidade por haver restrição na 
ferramenta CASE na exibição de caracteres acentuados. 
Descrição 
A descrição da entidade será colocada no item "Description" (Descrição) na tela de 
propriedades da entidade. Deve ser obtida no antigo Dicionário de Dados do MGD, 
quando possível. Quando uma classe do MGD se desdobrar em mais de uma entidade 
as descrições devem ser adaptadas e refeitas. 
Outras informações 
Para inserir outras informações referentes a entidade pode-se utilizar o campo “Notes“ 
(Notas) na tela de propriedades da entidade. Estas informações podem ser: Exemplos 
de preenchimento da entidade, legislação relacionada a entidade, sistema que origina a 
informação, tabela física. A organização destas informações pode ser feito através de 
palavras-chave: 
 Exemplo: xxxxxxxxxxxxxxxxx 
 Tabela Física: yyyyyyyyyyyyyyyyyyyy 
 Sistema: nnnnnnnnnnnnnnnnnn 
 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 9 de 9 
Compartilhamento de Entidades 
Uma entidade é criada em apenas uma AS pelo Administrador de Dados (AD) responsável. 
Quando ela for mencionada para ser referenciada em outra AS, no digrama ER ou para criar 
relacionamentos, ela deve ser compartilhada pelo AD dono da entidade. 
Unicidade na nomeação de Entidades 
As entidades devem ter nomes distintos. 
A propriedade Search Repository (“Pesquisar Repositório”) do módulo ROB pode ser 
consultada para pesquisar os nomes existentes no repositório, evitando que nomes iguais 
sejam criados. 
Regras de Sintaxe 
 
� String mnemônica que identifique a entidade – no singular 
Notas: 
1. A nomeação de entidades deve ser no singular. Usar propriamente preposições e 
concordância verbal e nominal e não ferir o português, uma vez que algumas 
locuções exigem o plural: Centro de Custos, Suprimento de Fundos, Fonte de 
Recursos. 
2. Usar espaços em branco para separação das palavras. 
3. O nome da entidade deve ser único no repositório. 
4. Não deverão ser usados caracteres especiais, por exemplo _ / ? ! etc. 
5. Uma entidade é criada em apenas um AS pelo Administrador de Dados (AD) 
responsável. Quando ela for mencionada para ser referenciada em outro AS ( no 
diagrama ER ou para criar relacionamentos com ela a entidade deve ser 
compartilhada pelo AD dono da entidade para a outra AS interessada. 
 
Ex.: ACAO, PRODUTO, UNIDADE DE MEDIDA
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 10 de 10
 
Atributos 
Ordem na Entidade 
Os atributos em uma entidade serão ordenados conforme as seguintes características: 
1. Atributo(s) que compõe(m) a Chave Primária 
2. Atributos de Chave Única 
3. Atributos obrigatórios 
4. Atributos opcionais - deverão ser agrupados ao final da entidade, em ordem 
decrescente de possibilidade de atribuição de valor. 
Caso os atributos não tenham sido criados nessa ordem, esses poderão ser ordenados 
através da propriedade de atributo "Sequence in Entity" (Sequência na Entidade). 
 Descrição 
A descrição do atributo será colocada no item "Description" (Descrição) na tela de 
propriedades do atributo. 
Outras informações 
Para inserir outras informações referentes ao atributo pode-se utilizar o campo 
“Notes“ (Notas) na tela de propriedades da entidade. Estas informações podem ser: 
Exemplos de preenchimento da entidade, legislação relacionada a entidade, sistema 
que origina a informação, tabela física. A organização destas informações pode ser 
feito através de palavras-chave: 
 Valores de Exemplo: xxxxxxxxxxxxxxxxx 
 Coluna da tabela: yyyyyyyyyyyyyyyyyyyy 
 Arquivo Físico: ccccccccccccccccccccccc 
 Sistema: nnnnnnnnnnnnnnnnnn 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 11 de 11
Formato para atributos Numéricos 
Mesmo que não sejam utilizados em cálculos, os atributos definidos originalmente no 
Modelo de Dados como Numéricos serão também definidos no Case como numéricos, 
ou seja, não serão transformados para VARCHAR2. 
Os atributos que representem valores monetários utilizarão o formato Money (formato 
monetário). 
Os atributos numéricos utilizarão o formato Number (formato numérico), sendo que 
nos casos que forem necessários, deverá ser especificado o número de casas 
decimais. 
Os atributos DDD e DDI do telefone serão definidos como VARCHAR2 . 
 
 
Formato para atributos Alfanuméricos 
Para atributos definidos como alfanuméricos será utilizado o formato VARCHAR2 e não 
o CHAR, inclusive para os atributos de tamanho fixo. 
A decisão de se utilizar o formato VARCHAR2 para atributos alfanuméricos deve-se ao 
fato de que tanto o formato VARCHAR2 como o CHAR utilizam um caractere de 
controle. No Formato VARCHAR2 este campo é utilizado para manter o tamanho da 
coluna e no formato CHAR para indicar a quantidade de bytes diferentes de branco. A 
única diferença encontrada dá-se quando o tamanho da coluna for superior a 256 
caracteres, neste caso o formato VARCHAR2 exigirá mais caracteres de controle que o 
CHAR. 
As comparações feitas entre colunas definidas como CHAR têm desempenho pior do 
que entre colunas definidas como VARCHAR2 porque o uso de coluna definida como 
CHAR em pesquisa utiliza freqüentemente funções intermediárias (LPAD, LTRIM etc), 
o que inviabiliza o uso do índice associado a coluna, caso exista. O uso de funções 
intermediárias em coluna definida como VARCHAR2 é menos comum. 
A coluna definida como CHAR tem a característica de manter tamanho do campo fixo, 
independentemente de estar preenchido ou não. Este fato poderia é uma vantagem 
por facilitar a precisão na estimativa de tamanho de Banco derivado do Repositório. 
Regras de Sintaxe 
 
 descrição que identifique o atributo 
Notas: 
1. Usar espaço em branco para separação das palavras que formam o nome do 
atributo. 
2. Os atributos não possuem qualificador. 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessosManual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 12 de 12
Quando for necessário esclarecer o nome do atributo, além do uso dos padrões 
acima descritos, usar um complemento de fácil compreensão e igual em todos os 
atributos da entidade. 
 Padrões de nomeação de atributos utilizados na derivação do MGD 
para o Oracle Designer: 
Apenas o atributo que identifica a chave primária seguirá o padrão prefixo + 
descrição: 
Identificador .......................... ID 
 
Ex.: ID ORGAO 
Os demais atributos de uma entidade terão um descritivo que caracterize o atributo. 
Ex.: CODIGO DE PROGRAMA; TITULO DA ACAO; FINALIDADE DA ACAO 
Obs.: este padrão de nomenclatura conceitual para o atributo foi adotado para 
simplificar o esforço de refinamento e facilitar a comunicação com os clientes apesar 
de não estar utilizando a forma preconizada pela administração de dados para 
nomenclatura de atributos de um MER em nível lógico. 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 13 de 13
 
 
Relacionamentos 
Nomeação 
A nomeação dos relacionamentos deve seguir as seguintes recomendações: 
1. Os nomes atribuídos deverão ser os mais reduzidos possível evitando o uso de 
preposições. Pode-se colocar apenas um “.” (ponto) quando o significado do 
relacionamento é extremamente óbvio e não existir mais de um relacionamento entre 
duas entidades. 
2. Para leitura e nomeação serão desconsiderados as expressões Must Be e May Be 
adotadas pelo Case; (expressões “deve ser” e “pode ser”) 
3. No caso da utilização de verbos, utilizá-los na terceira pessoa ou no particípio 
passado, respeitando o gênero atribuído à entidade (ex.: exercido ou exercida); 
4. Quando o relacionamento envolver uma entidade de uma classe de domínio (ex.: 
situação cadastral), sugere-se o uso dos nomes enquadra/enquadrado(a). 
5. Os nomes de relacionamentos utilizados no Dicionário serão mantidos em 
glossário a fim de permitir a padronização e facilitar a nomeação de novos 
relacionamentos. 
6. No caso de nomeação de mais de um relacionamento entre as mesmas 
entidades, o nome dos relacionamentos devem ser iniciados de forma diferente. 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 14 de 14
Diagramas ER 
Em cada AS serão criados tantos diagramas quantos forem necessários para melhor 
dar contexto aos dados. 
Fontes 
Nos diagramas E/R serão utilizados os seguintes tipos de fontes 
1. Nome do Diagrama (Cabeçalho) 
� Letra = Maiúscula 
� fonte = Arial 
� tamanho = 9 
� Atributo = Normal 
2. Título do Diagrama (Cabeçalho) 
� Letra = 1ª Maiúsculas e demais minúsculas 
� fonte = Arial 
� tamanho = 9 
� Atributo = Normal 
3. Nomes de entidades 
� Letra = Maiúscula 
� fonte = Arial 
� tamanho = 8 
� Atributo = Normal; 
4. Nomes de relacionamentos 
� Letra = minúscula 
� Fonte = Arial 
� Tamanho = 8 
� Atributo = Normal. 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 15 de 15
 
Cores 
Para facilitar a identificação visual das entidades representadas no diagrama quanto à 
sua origem, ou seja, se pertencem ou não à Entidade representada, foram 
estabelecidos os seguintes critérios, conforme palheta a seguir: 
 As entidades que fazem parte da classe de negócio para a qual o diagrama foi 
criado serão coloridas em CINZA; 
 As entidades que fazem parte da classe de domínio relativa à classe de negócio 
diagramada serão coloridas em AMARELA; 
 As entidades originárias de outras AS’s do macroprocesso e que não façam parte 
desses grupos serão coloridas em LILÁS; 
 As entidades externas ao macroprocesso serão representadas em branco. 
 
 
 Exemplo de Diagrama ER no Oracle Designer 
 
 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 16 de 16
 
 
 
Palheta de Cores do Oracle Designer 
 
 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 17 de 17
Anexos 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 18 de 18
Conversão para Notação Case Oracle 
Grau do Relacionamento 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Restrição de Integridade 
A alteração é devido à localização de convenção de opcionalidade/obrigatoriedade, 
que muda de lugar. O exemplo abaixo ilustra a situação de um relacionamento 1:N de 
Recurso Humano (RH) com Dependente (DEPENDENTE), onde: 
Um RH pode ter um ou mais DEPENDENTE 
Um DEPENDENTE deve estar pertencer a apenas um RH 
 
 
 
RH 
DEPENDENTE 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 19 de 19
Relacionamento N-ário (onde N >=2). 
.1 No Modelo de Dados 
 
2. No Case da Oracle 
 
 
 
 
 
 
 
 
 
 
 
 
Regras de Conversão 
1. Relacionamento ternário "A/B/C" deve ser definido como "Entidade". 
2. Declara-se a Chave Primária da entidade A/B/C como sendo composta pelo 
relacionamento com A, B e C. 
 
 
A B 
C 
A/B/C 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 20 de 20
 
Agregação 
Um relacionamento se relacionando com outras entidades. 
1. No Modelo de Dados 
 
2. No Case da Oracle 
 
 
 
 
 
 
AB 
C A/B/C 
D 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 21 de 21
 
Regras de Conversão 
1. Recai no caso anterior. 
Entidade Fraca 
1. No Modelo de Dados 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 22 de 22
2. No CASE Oracle 
 
 
 
 
 
 
 
 
 
 
Regra de conversão 
 A indicação de que uma Entidade (SETOR UA) é fraca passa a ficar próxima dela e não 
da Entidade "Forte" (UA) como era representado na convenção anterior. 
 A Chave Primária da Entidade "Fraca" (SETOR UA) deve ser declarada como formada 
pelo relacionamento com a Entidade "Forte" (UA) e mais um outro atributo. 
UA 
SETOR UA 
#A 
#A 
#N 
Indica que SETOR UA é fraca de UA 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 23 de 23
 
Uma Categorização Exclusiva1. No Modelo de Dados 
 
 
 
 
2. No Oracle CASE 
 
 
 
 
 
 
 
 
 
 
 
 
Regra de Conversão 
Não é necessária. 
 
 
X 
A B D 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 24 de 24
 
Várias Categorizações Exclusivas 
Mesma entidade "X" tendo duas ou mais categorizações 
 
1. No Modelo de Dados 
 
 
2. Case da Oracle 
 
 
 
 
 
 
 
 
 
No caso de representação de mais de uma categorização, há algumas considerações a 
serem feitas: 
1. Somente uma das categorizações será representada graficamente devido a 
característica do Case Oracle, como no caso de A/B/C. 
2. As demais categorizações podem ser mantidas através de relacionamentos em 
arco, como no caso de X1/X2. Neste caso, o conceito de Herança de Atributos deverá 
ser preservada por controles não automatizados. 
3. Ainda poderão as demais categorizações ser denotadas por atributos indicadores 
na entidade super-tipo, não sendo mantida assim a representação gráfica. Nesse caso, 
os atributos próprios dos sub-tipos seriam definidos como opcionais e o 
preenchimento desses seria controlado por regras. 
 
 
 
X 
A B D 
X1 
X2 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 25 de 25
 
Auto Relacionamento - Caso 1 – 1:N 
1. No Modelo de Dados 
 
2. Case da Oracle 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3. Observação: 
Na alternativa 2 está-se considerando a utilização de indicadores para representar a 
categorização X1/X2. Nesse caso, os atributos próprios dos sub-tipos seriam definidos como 
opcionais e o preenchimento desses seriam controlados por regras. 
 
 
 
 
X 
X1 X2 
X 
Alternativa 1 
Alternativa 2 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 26 de 26
Auto Relacionamento - Caso 2 – N:N 
1. No Modelo de Dados 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 27 de 27
2. No Oracle CASE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Observação: Na alternativa 2 está-se considerando a utilização de indicadores para 
representar a categorização X1/X2. Nesse caso, os atributos próprios dos sub-tipos 
seriam definidos como opcionais e o preenchimento desses seriam controlados por 
regras. 
 
X 
X1 X2 
X 
Alternativa 1 
Alternativa 2 
X1/X2 
X1/X2 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 28 de 28
Glossário 
AD 
Administrador de Dados. 
AS 
Application System é um conjunto de objetos em um repositório. Uma application 
system é uma unidade de trabalho que pode representar classes de negócio, classes 
de domínio, sistemas e subsistemas. 
CASE 
Computer-Aided System Engeneering – Conjunto de ferramentas que visam dar apoio 
as fases previstas para a engenharia de sistemas. 
Constraint 
Regras de validação que podem ser de integridade, de negócio ou estar sujeitas a 
determinadas condições como valores ou intervalos. 
DBA 
Database Administrator é o técnico responsável pelo projeto e adminstração do banco 
de dados. 
DDL 
Data Definition Language – Objetos SQL usados para criar, alterar, excluir objetos de 
banco ou mudar suas definições. 
Diagrama ER 
Diagrama Entidade-Relacionamento. 
Entidade Fraca 
Entidade dependente da extistência da entidade principal. 
FK 
Foreign Key ou chave estrangeira. 
MGD 
Modelo Global de dados contruído no nível conceitual para atender o Projeto PRINT| - 
Projeto de Integração do Ministério do Planejamento, Orçamento e Finanças. 
MP 
Ministério do Planejamento, Orçamento e Finanças 
Repositório 
É uma facilidade multi-usuário para armazenar informações sobre a definição de 
sistemas e de ciclos de vida. A Secretaria da Receita Federal usa o repositório do 
DESIGNER/2000 para registrar as fases do desenvolvimento dos sistemas corporativos 
da SRF. 
RON 
Repository Object Navigator é uma ferramenta do DESIGNER/2000 para criação e 
manutenção de Applications Systems no Repositório. O RON permite a criação, a 
edição a exclusão de objetos nos AS, e execução de procedimentos administrativos em 
relação ao repositório como controle de acesso e backups. 
PRINT – Manual de Técnicas de Administração de Dados do Projeto de Integração de MacroProcessos 
 
 
Manual de Técnicas de Administração de Dados 
Versão 1 - de 23/6/2010 Página 29 de 29
RFB 
Receita Federal do Brasil. 
SERPRO 
Serviço Federal de Processamento de Dados 
SUNAC 
Superintendência de Relacionamento com Clientes - Administração Tributária e 
Comércio Exterior 
Trigger 
Trigger é um evento que causa a execução de uma ou mais funções ou processos.
Manual de Padronização de Nomenclatura de Objetos 
Manual de Técnicas de Administração de Dados 
Bibliografia - P30 / 1
 
Versão 1 - de 23/6/2010 Página 30 de 30
Bibliografia 
Manual de Padronização de Nomenclatura de Objetos 3.1 – Receita Federal do Brasil - 
Novembro de 2002. 
 
Modelo Global de Dados – MGD – Projeto de Integração do Ministério do 
Planejamento, Orçamento e Finanças – Abril de 2009. 
 
Manual Padrão de Nomenclatura 1 - PGFN III Milênio 
Documento de Referência do Projeto de Integração do Marcoprocesso de 
Planejamento, Orçamento e Finanças, fevereiro de 2009 
Modelo Global de Dados – MGD, do Projeto de Integração do Macroprocesso 
Planejamento, Orçamento e Finanças, abril de 2009 
Manuais Oracle referentes aos produtos Designer 2000 
BRASIL. Secretaria da Receita Federal, Trabalhando no Case. Versão 3, setembro de 
1996. 
BRASIL. Secretaria da Receita Federal, Ata da reunião Seminário de Normas e Padrões 
da DIDAD, agosto de 1997.