6. Modifica al modello dati

Come esposto al Cap.5 del presente documento, per soddifare le richieste del RU, sarà necessario introdurre in GISFO il Progetto-Copia: una vera e propria copia del Progetto originale, creata in fase di apertura di un’area di Variazione Complessa.

Per gestire questo nuovo processo, saranno introdotte tre nuove tabelle nel DB GISFO:

r_parent_child_projects
r_parent_child_entities
transaction_claimed_areas_status
kv_variant_classification (vd.Par.8.9)

Tali tabelle si popoleranno contestualmente all’apertura dell’area di Variante (e quindi alla creazione del Progetto-Copia). La tabella r_parent_child_projects salverà tutte le informazioni riferite al Progetto-Padre e al Progetto-Copia, mentre la tabella r_parent_child_entities salverà le informazioni relative agli elementi (fisici, ottici) dei progetti. Infine, la tabella transaction_claimed_areas_status sarà necessaria a tracciare le transazioni di stato fra GISFO e P+ (vd.Par.8.3 per ulteriori informazioni).

Si riportano quindi di seguito le tabelle sopra citate:

*r_parent_child_projects*
pk_r_parent_child_projects bigint	fk_parent_project bigint	fk_child_project bigint	creation_date timestamp without time zone
######	xxxxx	yyyyy	gg-mm-aaaa h:m:s
######	xxxxx	yyyyy	gg-mm-aaaa h:m:s
######	xxxxx	yyyyy	gg-mm-aaaa h:m:s

*r_parent_child_entities*
pk_r_parent_child_entities bigint	fk_parent_entitiy bigint	fk_child_entity bigint	class_name bigint	fk_r_parent_child_projects bigint
######	xxxxx	yyyyyyy	zzzzzz	kkkkkk
######	xxxxx	yyyyyyy	zzzzzz	kkkkkk
######	xxxxx	yyyyyyy	zzzzzz	kkkkkk

*transactions_claimed_areas_status*
pk_transactions_claimed_areas_status bigint	fk_project bigint	fk_kv_claimed_areas_status bigint	fk_pplus_transaction bigint	nomeoperatore varchar	datamodifica timestamp without time zone
######	xxxxx	123	123	123	gg-mm-aaaa h:m:s
######	xxxxx	123	123	123	gg-mm-aaaa h:m:s

_{kv_variant_classification}
_{pk_kv_variant_classification bigint}	_{value varchar}	_{datamodifica timestamp without time zone}	_{isdeleted boolean}
₁	_{Esigenze derivanti da sopravvenute} _{disposizioni normative}	_{gg-mm-aaaa h:m:s}	_true/false
₂	_{Sopravvenute disposizioni o} _{prescrizioni del Concedente, o} _{Enti terzi}	_{gg-mm-aaaa h:m:s}	_true/false
₃	_{Cause di forza mìaggiore}	_{gg-mm-aaaa h:m:s}	_true/false
₄	_{Eventi imprevisti ed imprevedibili}	_{gg-mm-aaaa h:m:s}	_true/false
₅	_{In esito a variazioni e} _{integrazioni del progetto esecutivo}	_{gg-mm-aaaa h:m:s}	_true/false
₆	_{Raggiungimento degli impegni} _{verso il concedente}	_{gg-mm-aaaa h:m:s}	_true/false

Il DB verrà impattato anche per quanto riguarda alcune delle tabelle esistenti, risultando necessaria l’aggiunta di uno o più campi necessari a supportare il flusso prospettato. Le tabelle esistenti impattate sono quindi le seguenti:

kv_claimed_areas_status
generated_cmt
cmt_variant
prj_notes (vd.Par.8.9)

La tabella kv_claimed_areas_status verrà aggiornata con i nuovi possibili stati di una Variante (schematizzati ed accennati nel diagramma di flusso di cui al Par.8.1):

*kv_claimed_areas_status*
pk_kv_claimed_areas_status bigint	value varchar	datamodifica timestamp without time zone	isdeleted boolean
1	Approvata	gg-mm-aaaa h:m:s	true/false
3	Rifiutata	gg-mm-aaaa h:m:s	true/false
4	In Lavorazione	gg-mm-aaaa h:m:s	true/false
5	In attesa di approvazione	gg-mm-aaaa h:m:s	true/false
6	Approvazione Economica	gg-mm-aaaa h:m:s	true/false
7	Approvazione Operativa	gg-mm-aaaa h:m:s	true/false
8	Approvazione Operativa DL	gg-mm-aaaa h:m:s	true/false
9	Approvazione Operativa FM	gg-mm-aaaa h:m:s	true/false
10	In attesa di approvazione economica	gg-mm-aaaa h:m:s	true/false
11	Confermata DL	gg-mm-aaaa h:m:s	true/false
12	Confermata RdP	gg-mm-aaaa h:m:s	true/false
13	Approvata in attesa di emissione ODS	gg-mm-aaaa h:m:s	true/false

La tabella generated_cmt vedrà l’aggiunta di un nuovo campo booleano che permetterà di tracciare la storicizzazione delle voci passive in fase di generazione del CMT ai tempi t0 e t1:

*generated_cmt*
pk_generated_cmt bigint	fk_mat_capitolato bigint	fk_area_pfs bigint	drawing bigint	is_historicized boolean
	Tramite questo campo deduciamo se la voce è passiva/attiva			Tramite questo campo tracciamo la storicizzazione della voce specifica
######	xxxxx	yyyyyyy	zzzzzz	true/false
######	xxxxx	yyyyyyy	zzzzzz	true/false
######	xxxxx	yyyyyyy	zzzzzz	true/false

La tabella cmt_variant vedrà invece l’aggiunta di 3 nuovi campi riferiti ai valori del CMT0 passivo ai tempi t0 e t1 e al relativo delta fra i due valori (che verrà poi riportato in GUI, come mostrato al Par.8.5):

*cmt_variant*
pk_cmt_variant bigint	drawing bigint	[…]	cmt_p_0 integer	cmt_p_1 integer	cmt_p_delta integer	extension_days integer
			Questi campi si salveranno le informazioni (ricevute da P+) relative ai valori del passivo del CMT (al t0 e al t1)			Questo campo gesitrà il campo "Giorni di Proroga" in GUI (Scheda di dettaglio Variante)
######	xxxxx		123	123	123	123
######	xxxxx		123	123	123	123
######	xxxxx		123	123	123	123

*prj_notes*
pk_prj_notes bigint	descrizione varchar	drawing bigint	is_warning boolean	fk_kv_ variant_classification boolean
				Questo campo gestirà 'approv variante' in GUI
######	abc	zzzzzz	zzzzzz	1
######	abc	zzzzzz	zzzzzz	2
######	abc	zzzzzz	zzzzzz	3
######	abc	zzzzzz	zzzzzz	…

Nota bene: verrà inoltre previsto un nuovo campo booleano sulla tabella project denominato is_project_child_used che indicherà l’utilizzo o meno del workflow prospettato in questo documento (true) oppure l’utilizzo del metodo ad oggi in essere in GISFO live (false), per quanto riguarda ovviamente la gestione delle Varianti.