Preparazione dell'ambiente Per effettuare qualche esperimento creiamo una tabella come quella indicata dallo script seguente.

Transcript

1 Hierarchyid Di Gianluca Negrelli Introduzione Hierarchyid è un nuovo tipo dato introdotto con SQL Server 2008 finalizzato alla gestione di dati gerarchici. Tradizionalmente la soluzione al problema della gerarchizzazione dei dati si risolve attraverso l'uso di una doppia chiave di cui viene dotata ogni entità: la chiave principale rappresenta l'entità stessa mentre la chiave secondaria rappresenta il padre diretto. La nuova soluzione di SQL Server, come vedremo, utilizza un'unica chiave che indica sia la relazione dell'entità con il padre, che la sua posizione nell'albero. Preparazione dell'ambiente Per effettuare qualche esperimento creiamo una tabella come quella indicata dallo script seguente. CREATE TABLE Tree( TreeId int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, TreePosition hierarchyid NOT NULL UNIQUE, Name varchar(50) NOT NULL, Surname varchar(50) NOT NULL, MilitaryRank varchar(50) NULL ) La gerarchia che andiamo a rappresentare è di tipo militare. I campi che descrivono le singole entità (soldati) sono: nome (Name), cognome (Surname) e grado (MilitaryRank). La tabella è dotata anche di un campo hierarchyid (TreePosition) che serve a costruire la gerarchia vera e propria e da un'identità che funge da chiave primaria (TreeId). Il campo hierarchyid è decorato dell'attributo UNIQUE per delegare a SQL Server il controllo di univocità dei nodi. Nativamente HierarchyId non ha preclusioni nel creare nodi la cui posizione sia perfettamente sovrapponibile cioè non teme le duplicazioni di nodi. Se permettessimo la sovrapponibilità dei nodi, togliendo il vincolo UNIQUE dal campo TreePosition, riusciremmo comunque ad ottenere una struttura gerarchica organizzata a livelli ma non sarebbe più possibile imporre un ordinamento orizzontale tra gli elementi e, cosa anche più importante, non riusciremmo più ad attribuire i figli di un nodo duplicato al giusto padre. Il consiglio è senza dubbio di mantenere l'univocità delle posizioni. Un'altra possibilità da valutare nella progettazione della tabella è quella di promuovere il campo hierarchyid a chiave primaria clustered. Il vantaggio in questo caso risiede nel fatto che si riuscirebbe ad ottenere una maggiore velocità di selezione, riordinamento o spostamento dei nodi dell'albero. Il campo TreeId diventa utile quando è necessario riferirsi ai record (nelle clausole WHERE) senza dover per forza utilizzare il contenuto del campo TreePosition, che è un po' ostico da trattare rispetto ad un campo Int.

2 Creazione del nodo root Il metodo che permette la restituzione del nodo principale di una gerarchia è hierarchyid::getroot(). Hierarchyid utilizza internamente una notazione esadecimale per la gestione dei propri valori. La rappresentazione stringa equivalente del nodo root (0x) è il carattere /. Per inserire il primo nodo GetRoot() va utilizzato in uno statement di inserimento. SELECT hierarchyid::getroot(), 'William', 'Adama', 'Commander' Ripetendo lo statement di creazione del nodo root, SQL Server segnalerà una violazione del vincolo UNIQUE definito su TreePosition. Creazione di un nodo figlio Il presupposto nella creazione di un qualunque nodo che non sia root, è che si disponga di un riferimento al nodo padre. Nel nostro caso il nuovo figlio sarà discendente diretto di root (unico nodo creato fin'ora in tabella). Il riferimento a root si ottiene attraverso la funzione GetRoot(), già vista al momento dell'inserimento, oppure direttamente grazie alla chiave TreeId. Una volta ottenuto il riferimento desiderato si può istruire SQL Server ad accodare il nodo figlio attraverso la funzione GetDescendant(child1, child2) SELECT hierarchyid::getroot().getdescendant(null, NULL), 'Saul', 'Tigh', 'Colonel' Analizzeremo in seguito il significato dei due parametri di GetDescendant che, in questo caso, sono stati lasciati a NULL. Selezione degli elementi della gerarchia Proviamo ora ad eseguire la seguente query SELECT TreeId, TreePosition, TreePosition.ToString() AS TreePositionString, TreePosition.GetLevel() AS TreeLevel, Name, Surname, MilitaryRank FROM Tree

3 La query di selezione ha alcune particolarità che meritano una spiegazione. TreePosition restituisce il valore hierarchyid. Come si può rilevare anche dall'immagine del resulteset ottenuto, SQL server memorizza il tipo dato hierarchyid in forma esadecimale. TreePosition.ToString() converte il valore hierarchyid in una rappresentazione più facilmente comprensibile. Il tipo dato che si ottiene dal metodo ToString() è un nvarchar(4000). Il nodo root è rappresentato da una barra (/) mentre i nodi figlio sono rappresentati da numeri progressivi suddivisi a loro volta da barre (/1/). Vedremo in seguito con quali criteri questi numeri vengono distribuiti all'interno di uno stesso livello dell'albero. Da notare che la funzione ToString(), così come tutte le funzioni legate alla gestione di hierarchyid, è case sensitive. La gestione delle gerarchie è infatti delegata non tanto al motore TSQL quanto all'assembly.net che espone il tipo dato hierarchyid (si tratta di un tipo dato esposto direttamente dal CLR). TreePosition.GetLevel() restituisce il livello di profondità in cui risiedono i vari nodi. Nel nostro caso i livelli occupati sono lo 0 (da root) e l'1. Creazione di più nodi allo stesso livello NULL), 'Karl', 'Agathon', 'Captain' = TreePosition FROM Tree WHERE TreeId SELECT 'Lee', 'Adama', 'Captain' hierarchyid = TreePosition FROM Tree WHERE TreeId SELECT 'Kara', 'Thrace', 'Captain' SELECT TreeId, TreePosition, TreePosition.ToString() AS TreePositionString, TreePosition.GetLevel() AS TreeLevel, Name, Surname, MilitaryRank FROM Tree ORDER BY TreePosition Procediamo ora con il commentare il codice T-SQL riportato sopra. Con questa istruzione di selezione si ricava che assumerà il ruolo

4 di nodo padre delle nuove entità. NULL), 'Karl', 'Agathon', 'Captain' = TreePosition FROM Tree WHERE TreeId Con l'istruzione precedente si provvede ad inserire il primo nodo di terzo livello. Successivamente si ricava l'identificativo hierarchyid del nodo appena inserito 'Lee', 'Adama', 'Captain' hierarchyid = TreePosition FROM Tree WHERE TreeId Il secondo nodo del livello viene aggiunto sempre come figlio ma l'istruzione di aggiunta è ora corredata di un parametro. Il significato dei due parametri del metodo GetDescendant è il seguente: primo parametro => il nodo inserito dovrà essere maggiore del nodo riportato nel parametro; secondo parametro => il nodo inserito dovrà essere minore del nodo riportato nel parametro. Nel nostro verrà aggiunto prima e assumerà quindi il valore hierarchyid /1/0/. Un eventuale ordinamento tra i due nodi mostrerà prima /1/0/ e poi /1/1/ anche se i momenti di inserimento, testimoniati dalla progressione del campo identity, sono esattamente 'Kara', 'Thrace', 'Captain' L'ultimo capitano viene inserito tra i due precedenti. Il metodo vede, in questo caso, valorizzati entrambi i parametri rispettando l'ordine orizzontale delle entità, in quanto il nuovo inserimento deve essere maggiore del primo nodo e minore del secondo. E' interessante constatare come SQL Server risolva il problema dell'inserimento di una nuova entità tra due adiacenti (/1/0/ e /1/1/). Il nuovo nodo avrà come valore hierarchyid /1/0.1/ che, nell'assunzione del sistema adottato, significa appunto tra 0 e 1.

5 Vincoli nell'inserimento dei nodi allo stesso livello Avendo vincolato il campo hierarchyid con la clausola UNIQUE potremmo ottenere un errore se provassimo ad inserire un nuovo nodo tra 0 e 1. = TreePosition FROM Tree WHERE TreeId = 3 hierarchyid = TreePosition FROM Tree WHERE TreeId = 'Aaron', 'Kelly', 'Captain' L'errore viene originato dal fatto che anche il nuovo nodo avrebbe come valore hierarchyid /1/0.1/. Utilizzando la clausola UNIQUE siamo quindi vincolati ad inserire un nuovo nodo esclusivamente tra altri due nodi immediatamente adiacenti tra loro oppure in testa alla serie o in coda. Il codice precedente diventa quindi il seguente = TreePosition FROM Tree WHERE TreeId = 3 hierarchyid = TreePosition FROM Tree WHERE TreeId = 'Aaron', 'Kelly', 'Captain' Restituzione del padre A fronte dell'esistenza di un figlio è possibile risalire al padre attraverso l'istruzione GetAncestor(n) dove n rappresenta l'ennesimo livello degli ascendenti da restituire. hierarchyid = TreePosition FROM Tree WHERE TreeId = 5 SELECT * FROM Tree WHERE TreePosition SELECT * FROM Tree WHERE TreePosition SELECT * FROM Tree WHERE TreePosition Nel caso in esame il padre di primo livello è Tigh. Al secondo livello troviamo Adama, mentre al terzo la SELECT non restituirà valori in quando abbiamo già raggiunto root.

6 Restituzione dei discendenti Con la stessa facilità con cui vengono estratti gli ascendenti di un certo nodo, è possibile ottenere la lista dei discendenti. Questa volta l'operazione con cui effettuare la selezione è atomica SELECT * FROM Tree WHERE TreePosition.IsDescendantOf(@ColonelTigh)=1 La query restituisce tutti i militari a disposizione Da notare la sintassi booleana (se c'è riscontro positivo il metodo torna il valore 1) e il fatto che nel resultset ottenuto compaia lo stesso nodo su cui si sta operando (@ColonelTigh). Spostamento di nodi Ipotizziamo che arrivi il nuovo colonnello Jurgen Belzen alle dirette dipendenze del comandante Adama. Esso si posizionerebbe allo stesso livello del colonnello Tigh. Chiaramente Belzen non può rimanere senza uomini e quindi Adama gli assegna due capitani. hierarchyid = TreePosition FROM Tree WHERE TreeId = 3 = TreePosition FROM Tree WHERE TreeId = 5 SELECT hierarchyid::getroot().getdescendant(@coloneltigh, NULL), 'Jurgen', 'Belzen', 'Colonel' hierarchyid = TreePosition FROM Tree WHERE TreeId UPDATE Tree SET TreePosition (@ColonelTigh,@ColonelBelzen) WHERE TreePosition UPDATE Tree SET TreePosition (@ColonelTigh,@ColonelBelzen) WHERE TreePosition Il risultato sarà quello di aver attribuito a Belzen i capitani Agathon e Thrace. Vantaggi e limiti di hierarchyid Il nuovo tipo dato presenta indubbi vantaggi nella semplificazione di alcune operazioni classiche di gestione delle gerarchie. I principali sono: facilità nell'ottenere il livello corrente di qualunque entità attraverso il metodo GetLevel(); possibilità di gestire l'ordine orizzontale dei figli di uno stesso padre;

7 atomicità nell'operazione di restituzione dei discendenti di un nodo grazie al metodo IsDescendantOf(); esistenza di due diverse strategie di indicizzazione dei dati gerarchici in base alla strutturazione dell'albero (Depth First, Breadth First). E' altresì indubbio che questo nuovo tipo di dato porti con sé alcune grosse limitazioni tra cui la più rilevante riguarda lo spostamento di interi rami di una gerarchia. Negli esempi sopra riportati abbiamo sperimentato lo spostamento di nodi da un padre ad un altro, attraverso il metodo GetReparentedValue(). In un caso reale i nodi spostati sarebbero stati, con molta probabilità, a loro volta padri di altri nodi. Il metodo GetReparented() non si occupa dello spostamento dell'intero ramo ma solo del nodo in oggetto, rischiando di lasciare sul campo entità orfane. La mancanza di cui soffre il metodo è molto grave considerato che le gerarchie statiche, che non necessitano di spostamenti o modifiche, rappresentano situazioni abbastanza rare mentre le strutture dinamiche si incontrano più frequentemente. Pensiamo alla gerarchia militare dell'esempio, ma anche alla rappresentazione di un file system o di un organigramma aziendale. Il metodo classico di gestione delle gerarchie (doppia chiave padre-figlio) non soffre dello stesso problema: lo spostamento di un intero ramo si realizza con un semplice UPDATE del campo padre del nodo da muovere. D'altra parte è comunque vero che operazioni massive su una struttura a doppia chiave richiedono del codice di gestione ad hoc solitamente gestito con funzioni ricorsive. Basti pensare all'estrazione di tutti i figli di un nodo o al calcolo del livello di profondità. Si può concludere che l'adozione di hierarchyid in un caso reale, va attentamente vagliata alla luce dei pro e dei contro di questa tecnologia affiancando all'analisi una lucida riflessione sui requisiti richiesti e sulle caratteristiche intrinseche della gerarchia da rappresentare. Confidiamo che nella prossima versione di SQL Server, possa essere migliorato l'approccio al problema smussando le criticità attuali e rendendo hierarchyid il metodo ideale per la gestione di qualunque tipo di gerarchia. Bibliografia