Siauna dipendenza funzionale contenuta in
, l'insieme delle dipendenze funzionali di uno schema graph
,
il fact node ed
l'insieme delle dipendenze funzionali dello schema graph ridotto come definito nel paragrafo 4.1.3 in
. Se
, allora B è una dimensione o una misura, altrimenti B è una proprietà o una misura derivata.
Dovendo connettere il nostro modello rappresentato dagli schema graph ad un modello logico, come ad esempio lo schema a stella, avremo quindi la difficoltà di definire le misure all'interno della fact table e le proprietà all'interno delle dimension table. Nelle figure 4.4, 4.5 e 4.6 la distinzione grafica tra misure e dimensioni è data dalla posizione degli attributi rispetto al fact node. Tutti i nodi inseriti sotto il fact node rispetto all'asse verticale rappresentano misure e misure derivate, mentre quelli sopra rappresentano le dimensioni e le proprietà.
Dal punto di vista formale, quindi, della definizione dello schema dei meta-dati, bisognerà distinguere tra proprietà e misure.
Come si vede quindi nello XML Schema relativo allo schema graph (figura 5.8), al momento del salvataggio il progettista dovrà avere distinto in maniera esplicita se un attributo è una misura oppure una proprietà.
In coerenza con la definizione di schema graph introdotta nel paragrafo 4.1.2, abbiamo suddiviso l'insieme degli attributi in
, insieme delle proprietà e delle dimensioni dello schema, ed
, l'insieme delle misure (semplici e derivate):
La figura 5.9 mostra una schermata di DWers in fase di modellazione dello schema graph relativo al fatto Shipment. Come si può notare, fatto, misure e proprietà sono stati distinti tramite una diversa colorazione dei nodi che li rappresentano, rispettivamente in azzurro, giallo ed in bianco.
All'atto dell'inserimento di un nuovo attributo, come mostrato in figura 5.10, viene richiesto il nome ed il tipo di dato. Una volta inserito, l'attributo è connesso direttamente con una dipendenza funzionale al fact node, ed è una proprietà. In qualsiasi momento all'interno di una transazione il progettista può trasformare una gerarchia di attributi da proprietà a misure e viceversa.
Come mostrato in figura 5.11, questa operazione è molto semplice. Siccome non è possibile creare dipendenze funzionali tra un componente di ed uno di
, l'eventuale connessione di due nodi di classe differente deve essere seguita dalla specificazione della classe di tutta la porzione di grafo corrispondente.
Le dimensioni e le misure derivate non sono state distinte rispettivamente dalle proprietà e dalle misure perché sono di facile derivazione rispetto all'insieme delle proprietà e delle dipendenze funzionali.
Sia . Se
tale che
allora
è una dimensione, viceversa è una proprietà. Analogamente sia
. Se
tale che
allora
è una misura, viceversa è una misura derivata. Per quanto riguarda le misure derivate, questa distinzione serve solo per controllare che le misure non direttamente inserite nella fact table siano derivabili attraverso una formula di derivazione, che può produrre una vista che può essere materializzata, se la sua complessità computazionale è tale da doverne ridurre il peso in fase di interrogazione.
Fact Node, proprietà e misure sono quindi univocamente determinate dall'elemento figlio name, che come abbiamo già visto è univoco in tutta la history come richiesto dalla Universal Relation Schema Assumption.
L'elemento dataType è necessario in fase di creazione in un nuovo nodo, per permettere al sistema di creare automaticamente l'attributo nella relazione della dimension table nel caso si tratti di una proprietà, oppure nella fact table nel caso si tratti di una misura.
L'elemento opzionale formula serve nel caso si inserisca una misura derivata, che necessita della stringa SQL per la creazione della vista sulla misura semplice corrispondente.