Sefaz-ba secretaria da Fazenda do Estado da Bahia sgf superintendência da Gestão Fazendária dti



Baixar 351.96 Kb.
Página3/10
Encontro18.07.2016
Tamanho351.96 Kb.
1   2   3   4   5   6   7   8   9   10

COMPLEXIDADE FUNCIONAL

O número de ALIs e AIEs, associado à complexidade funcional de cada um deles, determina os pontos obtidos com a contagem dos arquivos do tipo Dados.


A complexidade funcional dos ALIs e AIEs é calculada baseando-se no número de Dados Elementares Referenciados (DER) e no número de Registros Lógicos Referenciados (RLRs) associados a cada ALI e AIE.

      1. DADO ELEMENTAR REFERENCIADO

DER (Dado Elementar Referenciado) consiste em cada campo único, não repetido e reconhecido pelo usuário.


REGRAS PARA A IDENTIFICAÇÃO:


  • Contar um DER para cada campo não repetido e reconhecido pelo usuário, mantido ou recuperado do ALI/AIE através da execução de um processo elementar;

Exemplo: Um CNPJ, dividido fisicamente em num_cnpj_base, num_cnpj_filial e dig_cnpj, que é sempre referenciado pela aplicação como um campo único, deve ser contado como 1 DER apenas. Porém, se a aplicação referenciar os 3 elementos do CNPJ separadamente (para fazer filtragem de consultas, inserção, alteração, etc), este deve ser contado como 3 DERs.


  • Contar apenas 1 DER para o conjunto dos campos de uma tabela de histórico que são uma imagem (cópia) dos campos da tabela original. Para os demais campos “não-repetidos” do histórico, desde que reconhecidos pelo usuário, contar conforme as regras padrão;




  • Campos calculados que sejam armazenados em um ALI ou recuperados de um AIE devem ser contados como DERs do mesmo, desde que cruzem a fronteira da aplicação;

Exemplo: Num detalhamento dos itens de uma nota fiscal, o valor total de cada item (qtde X valor unitário) é calculado e mostrado na tela, e é inserido no ALI junto com os demais campos da nota.


  • Campos Timestamps (data/hora de determinados eventos), se reconhecidos pelo usuário;




  • Se duas aplicações mantêm e/ou referenciam o mesmo ALI/AIE, mas cada uma mantém/referencia DERs separados, contar apenas os DERs que estão sendo utilizados por cada aplicação para dimensionar o ALI/AIE;

Exemplo: Se as aplicações X e Y atualizam/consultam os campos campo1 e campo2 da tabela Tabela1, ambos são contados como DERs para as duas aplicações. Caso a aplicação Z atualize/consulte apenas o campo1, o campo2 não é contado como DER para essa aplicação.


  • Contar um DER para campos repetitivos que são idênticos em formato e que existem para permitir ocorrências múltiplas de um valor de dados;

Exemplo: Em um ALI/AIE contendo campos de quantia de um orçamento mensal de 12 meses e um campo de quantia de um orçamento anual deve-se contar 3 DERs (um para o campo de orçamento mensal, outro para indicar o mês e outro para o campo de orçamento anual).


  • Contar um DER para cada pedaço de dado requerido pelo usuário para estabelecer um relacionamento com outro ALI ou AIE. Em outras palavras, deve-se contar um DER para cada campo que compõe as FKs das tabelas, garantindo que cada campo seja contado apenas uma vez ao longo do ALI/AIE.

Exemplo: Um ALI/AIE contendo dados de Cargo e outro ALI/AIE contendo dados de Empregados se relacionam através do código do cargo. Esse campo que relaciona os dois ALRs (campo da FK) deve ser contado como um DER.

      1. REGISTRO LÓGICO REFERENCIADO

RLR (Registro Lógico Referenciado) consiste em um subgrupo de elementos de dados reconhecido pelo usuário dentro de um ALI/AIE.


Esses subgrupos de elementos de dados dividem-se em dois tipos:


Exemplo: Em um Sistema de Recursos Humanos, as informações básicas de um empregado (número de matrícula, nome) são cadastradas em uma tabela chamada empregado. As informações relativas à forma de pagamento do funcionário (assalariado ou contratado por hora) são cadastradas separadamente em tabelas distintas (empregado_assalariado e empregado_por_hora). Além disso, o empregado pode ou não ter dependentes, sendo essas informações armazenadas na tabela de nome dependente. Nesse caso temos, para o arquivo lógico empregado:


Tabelas empregado_assalariado e empregado_por_hora => Subgrupos Obrigatórios (deve ser escolhido pelo menos um deles)

Tabela dependente => Subgrupo Opcional


Neste caso, deve ser pontuado 1 ALR com 3 RLRs: empregado_assalariado, empregado_por_hora e dependente.
Convém destacar que esses subgrupos de elementos de dados podem estar dispostos fisicamente na mesma tabela ou em tabelas separadas. Assim, mesmo se as informações de dependentes ou forma de pagamento fossem mantidas na tabela de empregado, a pontuação não seria alterada, devendo ser pontuado 1ALR com 3 RLRs.

N
OS RLRs são tipicamente representados em um DER (Diagrama de Entidade-Relacionamento) através do relacionamento pai-filho. No entanto, deve-se observar a relevância da entidade filha dentro do negócio. Caso essa entidade seja forte o suficiente (ou seja, não dependa da tabela pai para existir), deve ser contada como ALI.
Exemplos: Contribuinte e seus Endereços (Dados de Endereço constituem um RLR p/ o DSCAD).

Contribuinte e seus Responsáveis (Dados de Responsáveis compõem um novo ALI p/ o DSCAD).


OTA:



REGRAS PARA A IDENTIFICAÇÃO:


  • Contar um RLR para cada subgrupo opcional ou obrigatório de dados de um ALI ou AIE;

  • Se não existem subgrupos de dados, deve-se contar o próprio ALI ou AIE como um RLR.


1   2   3   4   5   6   7   8   9   10


©principo.org 2016
enviar mensagem

    Página principal