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 |
fk_parent_project |
fk_child_project |
creation_date |
|
###### |
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 |
fk_parent_entitiy |
fk_child_entity |
class_name |
fk_r_parent_child_projects |
|
###### |
xxxxx |
yyyyyyy |
zzzzzz |
kkkkkk |
|
###### |
xxxxx |
yyyyyyy |
zzzzzz |
kkkkkk |
|
###### |
xxxxx |
yyyyyyy |
zzzzzz |
kkkkkk |
|
transactions_claimed_areas_status |
|||||
|
pk_transactions_claimed_areas_status |
fk_project |
fk_kv_claimed_areas_status |
fk_pplus_transaction |
nomeoperatore |
datamodifica |
|
###### |
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 |
value |
datamodifica |
isdeleted |
|
1 |
Esigenze derivanti da sopravvenute disposizioni normative |
gg-mm-aaaa h:m:s |
true/false |
|
2 |
Sopravvenute disposizioni o prescrizioni del Concedente, o Enti terzi |
gg-mm-aaaa h:m:s |
true/false |
|
3 |
Cause di forza mìaggiore |
gg-mm-aaaa h:m:s |
true/false |
|
4 |
Eventi imprevisti ed imprevedibili |
gg-mm-aaaa h:m:s |
true/false |
|
5 |
In esito a variazioni e integrazioni del progetto esecutivo |
gg-mm-aaaa h:m:s |
true/false |
|
6 |
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 |
value |
datamodifica |
isdeleted |
|
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 |
fk_mat_capitolato |
fk_area_pfs |
drawing |
is_historicized |
|
|
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 |
drawing |
[…] |
cmt_p_0 |
cmt_p_1 |
cmt_p_delta |
extension_days |
|
|
|
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 |
descrizione |
drawing |
is_warning |
fk_kv_ variant_classification |
|
|
|
|
|
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.
No Comments