Regole e convenzioni
In questo capitolo vengono riportate quelle che sono le regole e le convenzioni da rispettare nell'utilizzo del DWH.
Per comodità le regole e le convenzioni riportate di seguito sono state suddivise per entità (DB, schemas, tabelle, viste ecc...) e sono state contrassegnate da un simbolo che ne definisce l'obbligatorietà (‼️) o la raccomandazione (❕).
Databases
| ‼️ | I nomi dei database devono essere scritti senza caratteri speciali e gli spazi devono essere sostituiti dal carattere _ |
| ‼️ | Il nome dei database di tipo raw data store deve richiamare la data source da cui provengono i dati (ad es. "mysond", "jira" ecc...) |
Schemas
| ‼️ | Per la nomenclatura degli schemas dei DB di analisi attenersi alle regole specificate nella pagina DB di analisi |
| ‼️ | Per i database di tipo Raw data store che hanno come data source più di un database relazionale (ad es. Mysond) il nome degli schemas deve essere nomeDB_nomeschema, dove nomeDB è il nome del database di origine (datasource), e nomeschema è il nome dello schema che sto considerando (ad es. DB: _03489760540db; Schema: public --> nomenclatura all'interno del raw data store: _03489760540db_public). |
| Se la data source è costituita da un unico database relazionale è sufficiente utilizzare come nomenclatura per lo schema nomeschema, ovvero il nome dello schema che sto considerando all'interno del database di origine (ad es. DB: afcdb; Schema: hr --> nomenclatura all'interno del raw data store: hr) | |
| ❕ | Per i database di tipo Raw data store che non hanno come data source database relazionali, è comunque opportuno che la nomenclatura degli schemas richiami l'ambito a cui si riferiscono i dati interessati (ad es. DB: aree_grigie; Schema: pni) |
| ‼️ | Nella scelta di nuovi nomi per gli schemas utilizzare sempre caratteri minuscoli, senza caratteri speciali e sostituire gli spazi con il carattere _ |
Tabelle
| ‼️ | Tutte le tabelle devono avere una PRIMARY KEY |
| ❕ | La PRIMARY KEY deve essere la prima colonna della tabella e deve chiamarsi "id" |
| ❕ | All'inserimento di un nuovo record nella tabella il campo che definisce la PRIMARY KEY deve popolarsi automaticamente tramite una sequenza definita dall'utente oppure impostando il tipo di dato a SERIAL o BIGSERIAL |
| ‼️ | I nomi delle colonne devono essere scritti in minuscolo, senza caratteri speciali e gli spazi devono essere sostituiti dal carattere _ |
| ‼️ | Le tabelle di storico devono sempre essere nominate con il prefisso "storico" (ad es. storico_banca_ore) e devono sempre avere un campo "data_inserimento" definito direttamente nella definizione della tabella come DEFAULT now() |
| ‼️ | Le tabelle di log devono sempre essere nominate con il prefisso "log" |
| ‼️ | Le tabelle temporanee devono sempre essere nominate con il prefisso "temp" |
| ‼️ | Le tabelle di tipo key-value devono sempre essere nominate con il prefisso "kv" (ad es. kv_trripa_codice_giustificativo_paghe) |
| ‼️ | Le tabelle di relazione devono sempre essere nominate con il prefisso "r" (ad es. r_voce_mensile_voce_paghe) |
Viste
| ‼️ | I nomi delle viste devono essere scritti in minuscolo, senza caratteri speciali e gli spazi devono essere sostituiti dal carattere _ |
| ‼️ | I nomi delle viste devono sempre iniziare con il prefisso "view", devono essere per quanto possibile brevi, ma allo stesso tempo devono descrivere in maniera chiara ciò che rappresentano (ad es. view_indennita_di_viaggio) |
| ‼️ | Le viste necessarie per i report di anomaly detection devono sempre iniziare con il prefisso "view_ad" (ad es. view_ad_tipologia_part_time_mancante) |
Viste materializzate
| ‼️ | I nomi delle viste materializzate devono essere scritti in minuscolo, senza caratteri speciali e gli spazi devono essere sostituiti dal carattere _ |
| ‼️ | I nomi delle viste materializzate devono sempre iniziare con il prefisso "mater_view", devono essere per quanto possibile brevi, ma allo stesso tempo devono descrivere in maniera chiara ciò che rappresentano (ad es. mater_view_interventi_totale) |
| ‼️ | Le viste materializzate devono sempre avere un campo "data_ultimo_refresh", possibilmente come ultima colonna, definito direttamente nel codice della vista come now() |
No Comments