Orientações para Modelagem de Dados

A Administração de Dados em uma instituição é uma área que deve ter uma ampla atuação e andar em conjunto com a área de Desenvolvimento de Sistemas.

A Administração de Dados tem como objetivo principal fazer a gestão do modelo de dados corporativo da instituição, promovendo sua conceituação, segurança, integridade, compartilhamento e qualidade.

Para isso a administração de Dados deve atuar de forma à:

  • Conhecer o negócio da empresa de forma, a saber, as áreas que utilizam os dados, considerando o nível de acesso que cada um terá do dado;
  • Modelar os dados corporativamente;
  • Respeitar as múltiplas visões e utilizações de um mesmo dado;
  • Disponibilizar os dados de forma organizada;
  • Compartilhar os dados evitando redundância;
  • Servir como base para a construção de sistemas de informações flexíveis, integrados e eficientes.

Para isso temos que  

Administração de Dados e a Equipe de Desenvolvimento trabalhem em parceria e com uma boa documentação do projeto.

Assim o modelo de dados pode ser construído / mantido a "4 mãos", mas sempre pensando em sua qualidade, pois isso é  é imprescindível para que o Ministério da Saúde possa prestar seus serviços ao cidadão

Modelo de Dados com Qualidade

Para que um modelo de dados seja considerado de boa qualidade, deve atender aos requisitos funcionais do projeto a que se propõe atender, seguir as boas práticas de modelagem de dados e ser bem documentado. Então para que um modelo seja considerado de qualidade, seguindo as boas práticas, os seguintes indicadores devem ser considerados.

 

Indicador

Descrição

Acessibilidade

O modelo disponibiliza as informações de forma clara,  fácil e rápida manipulação.

Amplitude

O modelo deve ser completo, profundo e objetivo de forma a  atender todas as necessidades de informações do negócio, sendo que estas deverão ser de fácil compreensão de todos e possuírem condições de serem atualizadas.

Credibilidade

No modelo deve ter tratamento para as informações de forma que o armazenamento das mesmas seja dentro da realidade, correto e confiável e que por isso seja capaz de ser considerada verdadeira e crível. Além disso, as informações devem ser bem conceituadas quanto a sua origem, conteúdo e legislação vigente, além de apresentar uma representação consistente, isto é, informações do mesmo tipo deverão ser apresentadas sempre no mesmo formato em todos os modelos (por exemplo, não é interessante se ter a informação de sexo de uma pessoa definida em um modelo com F e M e em outro como 1 (Feminino) e 2 (Masculino)).

Documentação

Todos os elementos contidos no modelo de dados devem ser nomeados de acordo com os padrões definidos para este órgão, bem como estar documentados com definições completas e inequívocas.

Flexibilidade

Omodelo de dados deve ser flexível, de forma a suportar  as mudanças necessárias sem grandes impactos.

Legibilidade

O gráfico do modelo de dados deve ser legível, ou seja, respeita critérios de estética que tornam o diagrama agradável para a leitura. Por exemplo:  evita cruzamento de ligações dos relacionamentos; evita curvas; sempre que possível respeita a hierarquia, ou seja, coloca os “pais” acima dos “filhos”.

Representação Concisa

No modelo devem estar representadas a quantidade correta de informações que o negócio necessita, isto é, deverá conter as informações que são importantes e de interesse ao negócio, que são aplicáveis à tarefa a que se propõe, sendo que normalmente informação que não se tem condição de mantê-la atualizada normalmente não é importante (excesso de informações pode não auxiliar na análise, além de se gastar mais tempo na escolha de informações relevantes, por exemplo tabelas com muitas colunas NULL).

Reutilização

O modelo apresenta facilidade de reutilização de seus objetos em outros negócios da instituição e com isso facilita a existência de um modelo corporativo.

Valor Agregado

O modelo devem estar contidas informações que trazem benefício ou provem vantagens pelo seu uso.

Regras Técnicas

Começaremos agora a descrever as regras técnicas para que possamos ter modelo de dados de qualidade, procurando obter  um uso de objetos de banco de dados e como já foi dito, devem obrigatoriamente ser seguidas.

 

 

 

Toda tabela deve ter uma primary key para identificação única do registro, que pode ser um sequencial (controlada por uma sequence do banco de dados) que não tem significado negocial, ou uma chave negocial, simples ou composta. No caso da PK ser um sequencial, é interessante que se defina uma UK como chave negocial da tabela, por exemplo, em uma tabela de Pessoas Físicas a chave negocial seria o nº do CPF. O não atendimento deste item contraria os indicadores de qualidade acessibilidade, reutilização e amplitude.

 

Uma ou mais colunas que são geradas por um relacionamento com a tabela detentora destas colunas e mais outra tabela, que vai determinar os valores possíveis para estas colunas. Em uma FK podemos ter uma coluna ou mais de uma (chave composta). No caso de chave composta é interessante que as colunas tenham preenchimento obrigatório, pois o SGBD somente realiza a verificação de integridade quando todas as colunas estiverem preenchidas. O não atendimento deste item contraria os indicadores de qualidade acessibilidade e credibilidade.

 

Para essas constraints não há necessidade de se definir um nome, pois estas são criadas automaticamente pelo banco de dados. O não atendimento deste item contraria o indicador de qualidade documentação. .

 

Para colunas se requer um valor padrão para o preenchimento da mesma quando não é definido nenhum valor na inclusão de uma linha na tabela. Nestes casos a coluna deve ter seu preenchimento obrigatório, para que este valor default seja utilizado, como pode ser visto na seguinte tabela.

Preenchimento

Constraint Default

Conteúdo Informado na Inclusão

Resultado

Obrigatório

Sim

Sim

Valor informado na inclusão

Obrigatório

Sim

Não

Valor default

Opcional

Sim

Sim

Valor informado na inclusão

Opcional

Sim

Não

Valor default

Obrigatório

Não

Sim

Valor informado na inclusão

Obrigatório

Não

Não

Ocorre erro

Opcional

Não

Sim

Valor informado na inclusão

Opcional

Não

Não

NULL

 É importante ressaltar que o valor default é obrigatório somente nos casos de criação de coluna com preenchimento obrigatório em tabela já existente.

Para essas constraints não há necessidade de se definir um nome, pois estas são criadas automaticamente pelo banco de dados.

O não atendimento deste item contraria os indicadores de qualidade acessibilidade e documentação.

 

Esta situação se refere a colunas que possuem um domínio definido, por exemplo, estado civil, tipo sanguíneo, tipo de pessoa, situação de contrato, etc. É importante ficar claro que nestas situações é imperativo que:

• Haja a implementação de controles com os valores válidos constantes na lista, que pode ser por check constraint (CK) ou tabela de domínio, conforme regras definidas neste item;

• Todos os valores devem ter o significado de cada um definido e documentado, pois isso diminui os problemas com informações sem credibilidade por falta de entendimento dos dados armazenados na base de dados.

Então para a implementação de lista de valores devem ser seguidas obrigatoriamente as s regras descritas a seguir.

1. Devem ter preenchimento obrigatório.

O preenchimento obrigatório é importante, pois NULL não é um valor pré-definido e sim ausência de valor. Acrescentando-se que registros com NULL prejudicam a performance de consulta, pois estes não são considerados em index.

Além disso, na obtenção de indicadores que envolvam essas colunas de domínio com valores NULL, esses registros também não são considerados.

Nos casos onde é necessário NULL, deve-se definir como valor no domínio, a coluna preenchida totalmente com o dígito 9, seja para datatype numérico ou de caracter. Por exemplo:

  • Coluna numérica de tamanho 1, o valor correspondente deve ser 9;
  • Coluna numérica de tamanho 2, o valor correspondente deve ser 99;
  • Coluna numérica de tamanho 3, o valor correspondente deve ser 999;
  • Coluna caracter de tamanho 1, o valor correspondente deve ser ‘9’;
  • Coluna caracter de tamanho 2, o valor correspondente deve ser ‘99’;
  • Coluna caracter de tamanho 3, o valor correspondente deve ser ‘999’.

A descrição do valor deve ser definida da forma mais adequada ao negócio que está atendendo.

2. Utilizar CK com a definição dos valores do domínio:

  • Domínio possui dois valores e mais o valor para NULL conforme descrito acima;
  • Os valores contidos na lista devem indicar que são estáveis, isto é, que a lista não vai aumentar;
  • Para o caso da CK depender do conteúdo de uma outra coluna da tabela, deve ser criada uma CK da tabela;
  • No comentário do campo, onde é descrita a sua finalidade, é obrigatório que contenha cada valor e a descrição do significado de cada um.

Na situação aqui indicada é obrigatório o uso de uma CK.

3. Domínio Sim ou Não

Para colunas cujo conteúdo deve expressar Sim ou Não, os valores do domínio devem ser S ou N, respectivamente.

4. Utilizar uma tabela de domínio, quando o domínio não se encaixa nas situações relacionadas com indicação de uso de CK.

5. Como incluir dados em tabela de domínio?

  • Para tabelas do DBGERAL, a responsabilidade é da DAAED;
  • Para tabelas de negócio temos as seguintes situações:
    • Manutenção de dados em tabela que não tem impacto no negócio e pode ter muitas alterações: o indicado é que o sistema tenha telas para manutenção das tabelas;
    • Manutenção de dados em tabela que não tem impacto no negócio e que o previsto é que praticamente não haja alterações em seu conteúdo: o indicado é que o sistema não tenha telas para manutenção das tabelas (atualização por script);
    • Manutenção de dados em tabela que tem impacto no negócio: o indicado é que o sistema não tenha telas para manutenção das tabelas, até porque em caso de alterações no conteúdo, a equipe responsável precisa analisar o impacto no sistema.

O não atendimento deste item contraria os indicadores de qualidade acessibilidade, credibilidade e flexibilidade.

 

A utilização desses datatypes as vezes causa um pouco de confusão. Quando devo usar cada um?

Utilize o DATE quando é necessário apenas a DATA ou DATA e HORA com precisão de segundos.

Utilize o TIMESTAMP quando é necessário DATA e HORA com precisão de milissegundos ou para utilização de timezone. O timezone é apropriado quando é necessário exibir informações de data e horários usando o fuso horário do sistema cliente.

 

Tabelas que permitem efetuar um rastreamento de qualquer operação que ocorre nos dados de uma tabela. Para que uma tabela de auditoria seja eficaz, deve responder quem fez a operação, quando foi feita e o que foi feito. A GAAD possui um padrão de auditoria, que responde a essas perguntas. As tabelas que devem ser auditadas são:

• As que possuem privilégio de DELETE, sendo neste caso obrigatório. Caso a tabela e trigger não sejam criadas, o privilégio de DELETE não será fornecido, ou se já existe, será retirado.

• Outras tabelas sem privilégio de DELETE, o usuário decide quais devem ser auditadas (normalmente por possuírem dados críticos para o Ministério da Saúde).

A alimentação de tabela de auditoria pode ser feita por trigger ou pela aplicação. A GAAD sugere a utilização de trigger, pois julga ser um método mais efetivo.

Para garantir a confiabilidade e a rastreabilidade das informações, tabelas de auditoria não podem ter seu dado alterado. Por isso os privilégios de acesso a essas tabelas seguem as seguintes regras:

  • Alimentada por trigger: GRANT de SELECT;
  • Alimentada pelo aplicativo: GRANT de SELECT e INSERT.

Mas então como proceder para sistemas legados em que a equipe decide por utilizar a nova estrutura:

  • Se não há auditoria, a AD deve criar a auditoria no padrão da AD.
  • Se há auditoria em outro formato, a AD deve sugerir a utilização do padrão da equipe, mas a decisão é da equipe responsável pelo aplicativo. Nunca se esquecer, que na criação da uma nova auditoria para uma tabela, a trigger da antiga deve ser desabilitada.
  • Para projetos novos deve ser adotado o padrão da AD.

A estrutura da tabela de auditoria no padrão da AD possui as mesmas colunas da tabela origem e mais as de controle, conforme definido na seguinte tabela.

Coluna

Tipo/Tamanho

Descrição

AU_DT_OPERACAO

TIMESTAMP(6)

Data da operação, armazenada no formato TIMESTAMP “DD/MM/YYY HH24:MI:SS.FF”.

AU_TP_OPERACAO

VARCHAR2(1)

Indica a operação efetuada pelo usuário na origem. Podendo ser: (I: para inclusão de registro (comando insert)); (A: para alteração de registro (comando update)); (E: para exclusão de registro (comando delete)).

AU_DS_USUARIO_SESSAO

VARCHAR2(30)

Usuário de banco da sessão ORACLE.

AU_NU_IP_SESSAO

VARCHAR2(15)

Endereço IP da máquina que originou a sessão ORACLE.

AU_DS_USUARIO_REDE

VARCHAR2(40)

Usuário de rede logado na máquina.

AU_DS_HOST_REDE

VARCHAR2(40)

Nome da máquina na rede.

AU_DS_USUARIO_APLICACAO          

VARCHAR2(100)

Nome do usuário final, informado pela aplicação. Informado e recuperado através da package DBGERAL.PKG_INFO_LOG.

AU_NU_IP_APLICACAO

VARCHAR2(15)

Endereço IP do usuário final, informado pela aplicação. Informado e recuperado através da package DBGERAL.PKG_INFO_LOG.

AU_CO_TRANSACAO

VARCHAR2(20)

Código identificador da transação no banco de dados.

 

1. GERA A AUDITORIA PARA A TABELA INFORMADA

O AD deve enviar a linha de comando a seguir para que o DBA a execute e gere a auditoria para os casos em que há necessidade de que uma tabela tenha auditoria.

 EXEC DBDBA.PKG_AUDITORIA.PC_GERA_AUDITORIA('OWNER','TABLE_NAME'); 

2. ATUALIZA A AUDITORIA PARA A TABELA INFORMADA

O AD deve enviar a linha de comando a seguir para que o DBA a execute e atualize a auditoria.

Mas atenção nos casos de RENAME de coluna, se a package for executada diretamente, será incluída uma nova coluna com o novo nome. Então nessas situações o correto é executar o comando para renomear a coluna na tabela de auditoria à é bom que o AD passe esse comando para o DBA.

 EXEC DBDBA.PKG_AUDITORIA.PC_GERA_AUDITORIA('OWNER','TABLE_NAME');

COMANDOS QUE DEVEM SER INSERIDOS NA APLICAÇÃO PARA OBTENÇÃO DO USUÁRIO FINAL E IP DA MÁQUINA QUE ESSE USUÁRIO ESTÁ LOGADO à PROCURE SEMPRE OREINTAR AS EQUIPES DE DESENVOLVIMENTO

---Login/Identificador do usuário como parâmetro EXEC DBGERAL.PKG_INFO_LOG.PC_INFORMA_USUARIO('USERNAME');

 -- IP do usuário como parâmetro

EXEC DBGERAL.PKG_INFO_LOG.PC_INFORMA_IP('10.0.0.1');

3. PARA GERAÇÃO DOS SCRIPTS DLL DE UM ESQUEMA COMPLETO (todas as tabelas de um schema)

DECLARE

  CURSOR TBS IS

    SELECT OWNER, TABLE_NAME

      FROM DBA_TABLES

     WHERE OWNER = 'DBGERAL'

       AND (TABLE_NAME LIKE 'TB\_%' ESCAPE '\'

         OR TABLE_NAME LIKE 'RL\_%' ESCAPE '\'

                        OR TABLE_NAME LIKE 'RT\_%' ESCAPE '\');

BEGIN

  FOR R IN TBS LOOP

    DBGERAL.PKG_INFO_LOG.PC_ATUALIZA_ESTRUTURA(R.OWNER, R.TABLE_NAME);

  END LOOP;

END;

 

4. PARA VERIFICAÇÃO DE ESTRUTURAS DESATUALIZADAS EM UM ESQUEMA

SELECT TB.OWNER, TB.TABLE_NAME

  FROM DBA_TABLES AU,

       DBA_TABLES TB

WHERE AU.OWNER = TB.OWNER

   AND AU.OWNER = 'OWNER'

   AND SUBSTR(AU.TABLE_NAME,3,30) = SUBSTR(TB.TABLE_NAME,3,30)

   AND AU.TABLE_NAME LIKE 'AU\_%' ESCAPE '\'

   AND (TB.TABLE_NAME LIKE 'TB\_%' ESCAPE '\'

     OR TB.TABLE_NAME LIKE 'RL\_%' ESCAPE '\'

     OR TB.TABLE_NAME LIKE 'RT\_%' ESCAPE '\')

   AND DBGERAL.PKG_INFO_LOG.FC_VERIFICA_ESTRUTURA(TB.OWNER,TB.TABLE_NAME) > 0;

5. Observações Importantes:

  • Campos BLOB não são auditados, para o caso de tabelas que ainda possuem campos desse tipo.
  • Na exclusão de colunas da tabela origem, estas não são excluídas da tabela de auditoria, pois esta visa manter o controle das informações existentes e as que já existiram na tabela de origem.
  • Tabela de auditoria não deve possuir constraint, pois as restrições de integridade devem ser garantidas pela tabela origem.
  • Quando uma tabela de auditoria nos padrões da GAAD é criada, é importante comunicar a necessidade dos comandos que devem ser inseridos na aplicação (citados na figura 12).

Para tabelas que devem ter auditoria, o não atendimento deste item contraria o indicador de qualidade credibilidade.

 

 

 

Tabela utilizada para armazenar os dados históricos para atender de uma determinada funcionalidade necessária para o negócio. Diferentemente de tabelas de auditoria, não há necessidade de que as tabelas com dados históricos possuam todas as colunas da tabela de origem. A definição de quais colunas devem fazer parte da tabela de histórico deve constar nos requisitos no aplicativo, assim como a forma de manutenção de seus dados, que pode ser por trigger ou pelo próprio aplicativo. O não atendimento deste item não contraria nenhum indicador de qualidade, mas é importante observar bem a diferença entre histórico e auditoria.

 

Uma tabela associativa representa uma entidade que não existe por si só e sua existência está condicionada à existência de duas ou mais entidades com relacionamento do tipo N:N. Além disso, o identificador negocial da tabela é formado exclusivamente pelas colunas que são geradas pela FK dessas tabelas relacionadas. Vale ressaltar que mesmo que estas tabelas possuam atributos próprios devem ser tratadas como associativas (tabelas com prefixo RL_ ou TL_) Conforme Anexo I, o não atendimento deste item contraria o indicador de qualidade documentação.

 

Para o caso de tabelas com exclusão lógica, é importante verificar qual será o mecanismo de controle quanto ao uso de registros que estejam marcados como “Excluídos”, isto porque estes registros não podem ser utilizados. Sendo assim, ou a aplicação deve tratar isso ou então devem ser implementadas triggers nas tabelas que recebem FK dessas tabelas com exclusão lógica, de forma, que os registros marcados como excluídos não seja mais utilizados. Mas o que é importante de observar é que a exclusão lógica de uma tabela deve ser tratada por um coluna, onde o nome obrigatoriamente é ST_REGISTRO_ATIVO com datatype VARCHAR2(1) e preenchimento obrigatório. Além disso, deve possuir uma check constraint com os valores ‘S’ ou ‘N’ e a descrição pode ser “Indica se o registro está ativo ou não (excluído logicamente). O seu domínio é: S – Sim (está ativo) ou N – Não (não está ativo). O controle no uso de registros excluídos deve ser feito pela aplicação.”. Uma observação importante é que quando a tabela é criada já com essa coluna, não é obrigatório a definição de um valor DEFAULT, mas quando a coluna é adicionada em uma tabela já existente, deve-se definir o valor DEFAULT, pois assim a coluna pode ser criada como NOT NULL e o valor DEFAULT será preenchido para todos os registros existentes na tabela. O não atendimento deste item contraria os indicadores de qualidade acessibilidade e documentação.

  

A criação de index deve ser feita visando uma melhoria de performance em consultas ao banco de dados, sendo que isso é possível na criação de index adequados. Outra forma de termos performance melhor é ter uma melhoria de hábitos de forma a produzirmos os comandos SQL mais eficientes que implicarão em respostas mais rápidas para os usuários dos sistemas e uma melhoria no funcionamento dos bancos de dados, mas este será um assunto para ser tratado posteriormente. A criação de index deve ser bem planejada, pois eles ajudam nas consultas, mas em inclusões, atualizações e deleções de registros, eles também são atualizados e com isso há uma perda de performance nessas operações. Então a criação de index deve ser feita de forma a sejam bem utilizados nas consultas e tragam bons ganhos de performance, que valha a pena o tempo perdido nas atualizações.

Sendo assim a criação de index é importante quando:

1. Uma coluna é referenciada em um comando SQL de consulta na cláusula de restrição (filtro), através de:

- Uma igualdade: sg_uf = ‘DF’;

- Comparação com intervalo ilimitado: nu_vaga > 100;

- Comparação com intervalo limitado: nu_vaga between 100 AND 200.

2. Para ORDER BY ou GROUP BY é bom que tenhamos um index considerando todas as colunas envolvidas e na ordem em que são especificadas nessas cláusulas (é bom que estas colunas tenham valores preenchidos, pois colunas com NULL não são consideradas em index). No caso do ORDER BY é melhor que as colunas sejam NOT NULL;

3. Utilizando-se MAX ou MIN, desde que a função faça parte da seleção e esteja sozinha, pois em caso contrário o index não é utilizado;

4. Para colunas que são FK, desde que estas não tenham pouca variação de valores, por exemplo, colunas de domínio;

5. Na utilização de OR na cláusula de junção / restrição, deve-se ter index em todas as colunas envolvidas no OR;

6. Quando se fizer uso de função na cláusula de junção / restrição, definir um index baseado em função;

7. O uso de consultas envolvendo na cláusula de restrições campos textuais deve ser evitado. Caso seja inevitável e o SGBD for o Oracle, utilizar index Intermedia Text (para campos VARCHAR2, CHAR e CLOB).

O não atendimento deste item contraria o indicador de qualidade acessibilidade.

 

 

O uso de triggers para implementação de regras de negócio é aconselhável evitar, sendo interessante a utilização para auditoria, histórico e garantia de integridade quando não é possível a implementação por constraints. Nos casos de uso de Trigger em implementação de regra de negócio do aplicativo, a responsabilidade é da equipe de sustentação. O não atendimento deste item contraria os indicadores de qualidade acessibilidade e credibilidade.

  

O uso de view tem como objetivo facilitar a visualização dos dados, sendo que com elas é possível simplificar comandos com colunas resultantes de agrupamentos de dados de mais de uma tabela, cálculos, quando há necessidade de inibir colunas ou linhas de tabelas, por questões de segurança, etc. Sendo assim, o uso de views é interessante quando se quando se tem uma consulta de uso frequente, consultas complexas, para restringir o acesso a visualização de dados. Conforme Anexo I, o não atendimento deste item não contraria nenhum indicador de qualidade, mas deve-se ter parcimônia no uso de views e observar a real necessidade do uso de view.

 

Tipo especial de view com característica com armazenamento de dados próprio, originados de uma ou mais tabelas. Bastante utilizadas para facilitar consultas sem impactar na performance das tabelas transacionais. Também permite tratamento de regras negociais e criação de index, diferentemente das views convencionais. Conforme Anexo I, o não atendimento deste item contraria o indicador de qualidade.

 

Quanto ao uso de campos com tipo BLOB, o armazenamento não deve ocorrer em base de dados, mas sim utilizando a tecnologia NFS (Network Fife System). Havendo a necessidade de armazenar o nome do arquivo e a descrição do local de armazenamento na base de dados, devem ser utilizados campos com prefixo NO (nome) e DS (descrição, respectivamente. Para o armazenamento em filesystem, a equipe de responsável pelo aplicativo deverá procurar a equipe de Infraestrutura para obter as devidas orientações. Para maiores informações consultar o memorando n° 32/2016/CGAM/DATASUS/SE/MS, SIPAR 2500.083574/2016-10 e Nota Técnica nº. 063/2016/Infraestrutura/DATASUS. O não atendimento deste item não contraria nenhum indicador de qualidade.

 

 

Normas Para a Modelagem Relacional

 

Um modelo de dados deve estar de acordo com as "Normas Técnicas"  definidas acima e mais as normas de modelo relacional definidas a seguir.

Estas normas apresentam boas práticas.

 

a) Sempre que for identificada a existência de tabelas distintas com muitas propriedades, atributos e relacionamentos em comum, recomenda-se avaliar a possibilidade de aplicar o conceito de generalização / especialização.

b) Em princípio, as tabelas deverão ser modeladas respeitando-se as regras de normalização. Desnormalizações poderão ser feitas desde que haja justificativa técnica da sua necessidade, como por exemplo, para facilitar o acesso às informações e/ou para melhoria de performance. No entanto, para qualquer desnormalização deverá haver um procedimento implementado no banco de dados que garanta a integridade da informação. As justificativas para tais procedimentos deverão ser documentadas na ferramenta case.

c) Em princípio todas as tabelas deverão possuir PK. Para os casos de tabelas em que a Primary Key é uma coluna sequencial, não temos a garantia de unicidade de registros de forma negocial e para essas situações deverá ser verificada a existência de pelo menos uma Unique Key (UK) composta ou simples. Nessa verificação não são levadas em consideração tabelas de apoio, log e temporárias.

d) O relacionamento entre as tabelas deverá ser feito através da criação de chave estrangeira (FK). Excepcionalmente, quando isso não for possível, deverá ficar documentado na tabela o motivo e a forma que será utilizada para garantir a integridade dos dados, devendo ser observado o item que trata de Primary Key no documento.

e) As tabelas mais volumosas deverão ser estudadas de forma a se decidir a criação de índices, bem como outras questões físicas como por exemplo, particionamento.

f) Tabelas com muitas colunas sem preenchimento obrigatório deve-se avaliar real necessidade de tais colunas ou até da tabela. Havendo a necessidade de se manter essa ocorrência, deve haver uma justificativa técnica e esta documentada.

 

 

a) Toda coluna cujo conteúdo é uma lista de valores deve ter seu domínio definido.

b) Colunas cujo conteúdo é uma lista de valores implementada por FK com tabela de domínio ou CK devem possuir preenchimento obrigatório, pois para colunas desse tipo não se deve admitir ocorrência nula, visto que o nulo não é um valor pré-definido e sim ausência de valor.

c) Colunas cujo conteúdo representam a mesma informação em modelos diferentes devem possuir o mesmo tipo/tamanho e lista de valores quando for o caso.

  

a) As tabelas e colunas devem estar documentadas conforme definido neste documento.

b) No caso de ausência de constraint onde deveria existir, deve ser verificado motivo desse tipo de ocorrência e caso seja necessário a não alteração, isso deve possuir uma justificativa técnica e ser documentada.

c) O desenho gráfico do modelo de dados deve possuir estética agradável com utilização de cores para diferenciar módulos funcionais e tabelas compartilhadas de outros modelos, além do que deve ser evitado o cruzamento de linhas.

 

a) Nome de qualquer objeto deve estar de acordo com a sua finalidade, sendo que para tabelas e colunas isso deve ser sempre verificado e para outros tipos de objetos, somente aqueles que devem ter o nome representativo de acordo com o negócio, conforme especificado no documento de normas de nomenclatura de objetos de banco de dados.

b) O modelo de dados deve ser aderente aos documentos de especificação do projeto. No caso de situações onde esta regra não é seguida, deve ser documentada a justificativa para tal.

 

 

Com as orientações contidas neste documento de "Regras Técnicas" e "Normas para Modelagem de Dados Relacionais",  poderemos ter um modelo com qualidade negocial.

Resta apenas a parte relativa a documentação do modelo de dados denominada "Dicionário de Dados".

 

 

Dicionário de Dados

 

Diretrizes para Documentação de Modelos de Dados

Neste item vamos descrever algumas regras básicas que devem ser seguidas para que possamos ter um bom dicionário de dados que é o “Registro detalhado dos conceitos que compõem um universo pré-definido”.

Portanto é importante entender que  “A representação gráfica e denominação dos elementos que compõem um modelo de dados não são suficientes para traduzir todos os conceitos do negócio”.

 

Para que tenhamos uma boa descrição dos elementos de dados devemos considerar os seguintes fatores: clareza, objetividade, respeito à legislação e normativos, respeito à terminologia da área negocial que está sendo tratada, respeito às normas da língua portuguesa, citação de  exemplos.

 

Então, não corra o risco de interpretações equivocadas e não claras, ou você prefere isso?