Newsgroup: it.comp.lang.javascript
Titolo: [OT] Informatica: Alberi incestuosi

Oggi ho fatto la conoscenza di questa meraviglia dell'informatica.
Scenario: AS/400, dove sono stati codificati per centri di costo i
dipendenti, ognuno dei quali ha un relativo responsabile.
Si direbbe una normale relazione padre/figli (anzi, "figlie", così
torna meglio l'analogia) tranne che per un "lieve" caso d'incesto.
In pratica, invece di avere una struttura di questo tipo:
	    Pietreppaolo
	    /        \
	  Lara     Mario
	  /   \    
	Anna Gianni
Abbiamo questo:
	    Pietreppaolo
	    /    |    \
	  Lara Silvia  Mario
	  /   \    
	Anna Silvia
Ovviamente l'unica conclusione plausibile del fatto che Silvia sia
al contempo figlia di Lara e sua sorella (diventando quindi, anche
la zia di se stessa), è che ci sia stato un incesto tra Lara ed il
padre.
Tornando in ambito informatico, "l'albero incestuoso" va contro al
concetto di "un solo nodo padre per ogni nodo figlio", dato che lo
stesso nodo ("Silvia") ha due "nodi padri".
Quindi, fintanto che si desidera ricostruire la gerarchia partendo
dalla root nessun problema: ma se uno volesse partire dal figlio e
ricostruirne la gerarchia al ritroso? Eccallallà.
Il bello dell'informatica è che non finisce mai di stupirti.
Certo, anche gli utonti spesso ci mettono il loro, per carità. :)
P.S.
Ogni riferimento a fatti, persone, animali o vegetali, è puramente
casuale. Se volete potete usare dei numeri al posto dei nomi nello
schema, come nella realtà è in effetti. Ma la metafora non sarebbe
riuscita altrettanto bene. :)
-- 
~ "Non sono solitamente un uomo che prega,
ma se sei lassù, per favore salvami,Superman."
(Homer Simpsons)

 padre.
LoL
Be' assolda un cecchino e fai fuori l'adultera! :)
Ciao! :)

 ricostruirne la gerarchia al ritroso? Eccallallà.
beh, di algoritmi di visita sui grafi ce ne sono dalla notte dei tempi...
-- 
Under construction

 beh, di algoritmi di visita sui grafi ce ne sono dalla notte dei tempi...
Se si trattasse di un grafo, concepito come un grafo e soprattutto se
fosse usato come un grafo, allora il problema non si porrebbe. Ma non
è così.
Va da sé che una cosa del genere non si dovrebbe mai verificare se il
sistema è fatto ammodino: In una struttura ad albero, dovrebbe essere
impedito "nativamente" l'associazione dello stesso nodo a più padri.
Ma volevo solo condividere con voi questa situazione "anomala" che mi
è capitato di vedere come "spettatore" :)
-- 
~ "Sono diventato un medico per le stesse ragioni di tutti:
Donne, soldi, potere, e donne." (Dr. Cox)



Fortuna vuole che non sia un mio problema. :) E tra parentesi, temo
che sarà ignorato anche da chi di dovere... applicherà la filosofia
del "fintanto che non causa problemi, lo lascio stare dov'è". :)
-- 
~ "E' impossibile svegliare chi fa finta di dormire."
(Proverbio navaho)

 impedito "nativamente" l'associazione dello stesso nodo a più padri.
in pratica, se si continua a "vedere" la struttura come un albero, mi
aspetto di trovare qualcosa (una funzione, metodo, vattelappesca) che dia
il padre di un nodo. Evidentemente questo vattelappesca, applicato
a "Silvia" farà una delle seguenti cose
1) ritornerà sempre uno dei due padri
2) ritornerà uno a caso tra i due padri
3) genererà un errore
4) guerra termonucleare globale
comunque, finchè non ci sono richieste strane, tipo "trovami tutti gli zii
di un nodo", non ci dovrebbero essere loop, e quindi si potrà "ignorare" il
problema (erh... cantando "finché la barca va, lasciala andare")
-- 
Under construction

 di un nodo", non ci dovrebbero essere loop, 
tranne che nel caso 4 :P

 di un nodo", non ci dovrebbero essere loop,
Ah, ma non è un "problema" di loop. E' un "problema" di dati non
congrui, ma a livello logico, non a livello tecnico.
L'albero identifica le relazioni tra i dipendenti, il loro CDC e
i loro responsabili.
Se ti trovi quindi, a dover recuperare il dirigente responsabile
di "Silvia", senza altri dati alla mano, è probabile che ciò che
ottieni non sia sempre corretto.
Questo perché "Silvia" pare sia un caso particolare, ricopre due
ruoli che dovrebbero essere ricoperti da due persone differenti.
Di fatto, in base alla funzione che "Silvia" esercita, cambia il
suo superiore.
Evidentemente il sistema non gestiva casistiche di questo tipo e
quindi qualche "genio" ha pensato di associare la stessa utenza,
a diversi "padri" (primo errore) e il sistema glielo ha permesso
(secondo errore).
Personalmente, nel momento in cui si vengono a creare situazioni
che il sistema non contempla, se possibile aggiorno quest'ultimo
in base alle nuove esigenze, dato che non modella più la realtà.
Oppure, se ciò non fosse stato possibile, o fosse sfociato in un
"bagno di sangue", avrei creato un'altra utenza, che si riferiva
allo stesso utente reale.
Del resto "se sembra un'oca, cammina come un'oca, starnazza come
un'oca; allora deve essere un'oca". :)
Ovvero, se quella persona ha tutte le caratteristiche di diverse
utenze, io dovrei considerarle come utenze diverse, appunto.
Ma il danno è fatto, non sono io che me ne occupo, ed il collega
che mi ha mostrato questa meraviglia informatica, come ho detto,
probabilmente se ne laverà le mani.
Questo almeno finché qualcun'altro non se ne lamenterà. :)
-- 
~ "Gesù ha avuto la sfortuna che su quello che ha detto ci hanno
costruito sopra una religione."
(Josè Saramago)

 allo stesso utente reale.
ecco, diciamo che la mia soluzione più idiota sarebbe stata questa
-- 
Under construction

 suo superiore.
Cioè, modellare i concetti di "persona" e "ruolo" come classi distinte no,
eh? :)
-- 
Nando [?]
Apostolo della Prova

 eh? :)
Stiamo parlando di una cosa differente, Nando.
Primo, con la programmazione OOP non ha nulla a che vedere (è uno
storaggio di dati "grezzo") e secondo non è un questione di ruoli
in senso stretto; quanto di ruoli che dovrebbero essere assegnati
a due persone distinte.
Per spiegarmi: se lavori in un'azienda come dipendente, lavorerai
in un reparto, avrai un centro di costo, e un dirigente a cui far
conto.
Tu nel tuo reparto, potrai anche avere più "ruoli", ma sei sempre
sotto il solito dirigente, nel solito reparto, con lo stesso CDC.
L'anomalia in questione, è che questa persona invece ha più di un
capo. E non nel senso gerarchico del termine (che avrebbe senso),
quanto che il suo "capo", cambia in base alla funzione che svolge
in quel momento.
La cosa - per me assurda - è che in un caso questa persona è allo
stesso livello gerarchico che del suo capo nell'altra funzione.
Così come puoi notare dallo schema del mio primo post, se vedi la
relazione invece che genitore/figlio come superiore/sottoposto.
Non so se mi sono spiegato. :)
E' già un'anomalia nella "realtà", questa situazione. Il fatto è,
che riportandola "paro paro" nel modello informatico, si è andato
a creare un'ulteriore problema, un'anomalia anche nel sistema.
-- 
~ "Ho avuto la fortuna di unire mestiere e passione,
che secondo Stendhal equivale alla felicità."
(Roland Barthes)

 a creare un'ulteriore problema, un'anomalia anche nel sistema.
Ho capito... diciamo che, in casi come questo, occorrerebbe rivedere
l'organizzazione aziendale e poi, di conseguenza, il software... vabbè,
giusto per chiacchierare. Buon weekend :)


 Buon weekend :)
Spero sia andato bene anche a te. :)
-- 
~ "Il giusto altro non č che l'utile del piů forte."
(Trasimaco)

 Spero sia andato bene anche a te. :)
Benissimo, decisamente. Speriamo che lo sia anche la settimana che inizia,
per me e per voi tutti :)
