Dúvida com modelagem, generalização?

Boa noite Ricardo,

Pelo que percebi, você está trabalhando com um banco de dados relacional, certo?

Você pode explicar melhor o que seria checklist para apontar os vícios destes procedimentos? Não entendi ainda o que seriam os tais vícios de procedimentos, nem como os procedimentos se relacionam com os conceitos que você mencionou (licitacao, adesao, contratacao_direta e contrato).

Já há uma tabela procedimentos no seu modelo? Se sim, pode dizer as colunas delas?

Contudo, do que você explicou até agora, parece que a abordagem do item 3 é a melhor. A primeira, como você mesmo disse, talvez não seja boa, por ter bastante dados desnormalizados e muitos nulls. Poderia fazer sentido se fosse um modelo em que desempenho era primordial em relação à consistência, mas não parece ser teu caso.

A segunda abordagem também não parece boa, pois, caso surja algum tipo novo de checklist, uma tabela nova deveria ser criada. Assim como, caso deixe de existir alguma, talvez ela deveria ser removida. Não sei quão fácil é isso no ambiente em que você esta trabalhando (em geral, aplicações de alterações e exclusões em Produção não costumam ser rápidas).

Aguardo as informações que te perguntei para tentar te ajudar mais.

Abraço!

Oi Rafael, obrigado por responder.

Bom aqui trabalhamos com auditoria, as tabelas licitacao, adesao,contrato e contratacao são tabelas do sistema de contratações publicas que os municipios tem obrigação de informar para o estado, eles estão no banco de dados oracle.

O checklist nada mais é que uma auditoria que o técnico faz nos procedimentos que o municipio envia, o checklist tem itens sobre os procedimentos que o técnico tem que dizer se o municipio cumpriu ou descumpriu aquele item naquele processo que está sendo analisado. os vícios são os itens que o município descumpre naquele processo analisado.As tabelas de checklist, checklist_item,etc.. estão em um banco de dados postgres

a questão de estarem em bancos diferentes nem é o problema, problema mesmo é que na checklist eu tenho que saber a qual processo(contrato, licitacao,adesão...) aquela checklist pertence

Bom dia Ricardo,

De nada. Também agradeço tua mensagem anterior, pois deixou mais claros alguns conceitos sobre os quais tinha dúvidas e te questionei.

Pensei na seguinte abordagem:

• checklist:

  checklist_id, -- (PK) 
  procedimento_id, -- (PK e FK)
  status_procedimento -- item cumprido ou descumprido

• procedimento:

  procedimento_id, -- (PK)
  desc_procedimento

• checklist_contrato:

  checklist_id, -- (PK e FK)
  contrato_id -- (PK e FK)

• checklist_licitacao:

  checklist_id, -- (PK e FK)
  licitacao_id -- (PK e FK)

• checklist_adesao:

  checklist_id, -- (PK e FK)
  adesao_id -- (PK e FK)

Na tabela checklist, a coluna status_procedimento indicaria se o item do checklist foi cumprido ou não. Ou seja, estou partindo do pressuposto que tanto procedimentos quanto vícios são a mesma coisa, exceto pelo fato de o procedimento ser um item que foi cumprido e o vício um item que não foi. Faz sentido isso na aplicação? Se não fizer, me explique a diferença, por favor.

A seguir, pensei na tabela procedimento, que contém o id dele e uma descrição. Supus que o nome da tabela poderia ser também checklist_item, pois, pelo que entendi, um item do checklist nada mais é do que algo que a auditoria verifica se foi cumprido ou não, dado um checklist. É isso mesmo?

Quando você mencionou "(...) na checklist eu tenho que saber a qual processo(contrato, licitacao,adesão...) aquela checklist pertence", ficaram umas dúvidas:

1. uma checklist não pode pertencer a um contrato, a uma licitação e a uma adesão ao mesmo tempo, certo? Ou pode?

2. Além disso, um mesmo checklist pode pertencer a mais de um contrato? A mais de uma adesão? A mais de uma licitação?

Parti do pressuposto que a resposta à questão 1 é sim e para a questão 2 é sim. Confirma?

Caso a resposta para a pergunta 1 seja "não", podemos criar na tabela checklist uma coluna NOT NULL (algo como tipo_processo_pai ) que diz se a checklist se refere a um contrato, a uma licitação ou a uma adesão, com 3 valores (char ou string) limitados por uma constraint. E só haverá inserção em uma das três tabelas (checklist_contrato, checklist_licitacao ou checklist_adesao) conforme o valor desta coluna (uma limitacao via trigger ou via procedure, por exemplo). E se tentar inserir nas outras tabelas, também deve haver limitação.

Caso a resposta para a pergunta 2 seja "não", podemos ter na própria tabela checklist o id do processo-pai ao qual o checklist pertence. E, para determinar se é contrato, licitação ou adesão, usar o esquema de uma coluna com a constraint como sugeri no parágrafo anterior. Neste caso, não precisaríamos das três tabelas (checklist_contrato, checklist_licitacao ou checklist_adesao), já que a relação seria 1:1 com um dos processos pai.

Avisa aí se conseguimos resolver ou se ainda há pontos pendentes.

Abraço!

A proposta que vc me deu foi mto boa e bem organizada entretanto eu escolhi o caminho da simplicidade. A estrutura da tabela ficou assim como na observação que vc fez referente a sua pergunta número "2" (a checklist pertence apenas a um processo, mas nada impede que um processo possa ter vários checklists, pois processos licitátorios tem 'fases', cada fase o auditor pode fazer um checklist diferente para esse processo)

• long pk checklist_id

• long procedimento_id(era para ser uma FK mas as tabelas de procedimentos ficam em um oracle e as tabelas do checklist em um postgres)

• varchar tipo_procedimento(Enumerated do Java, valores constantes)
• timestamp data

então se eu tiver:

checklist_id |tipo_procedimento |procedimento_id 1 LICITACAO 150010 2 CONTRATO 1300030

eu sei que a checklist de id=1 é da licitação de id =150010 e que a checklist de id=2 é do contrato de id = 1300030

obrigado pela atenção