Ok, ci siamo chiariti in chat. La faccina normale significa che dipende dal numero di record selezionati...

Qualcuno ha capito se la ricerca esatta in un file heap con duplicati è 0,5 BD o solo BD?

essendoci valori duplicati non si dovrebbe scansionare tutto il file?

Qualcuno ha capito se la ricerca esatta in un file heap con duplicati è 0,5 BD o solo BD?

essendoci valori duplicati non si dovrebbe scansionare tutto il file?

0,5BD è per la ricerca 'secca', come ad esempio cerca gli impiegati con cognome=Meneguzzi, perche' mediamente questi record si trovano a meta'(un po come il discoro dell'analisi ammortizzata ad ASD).
Per un file Heap anche se ci sono valori duplicati non cambia niente, si deve sempre scandire.

Data l’operazione:

Stampare il nome e l’età di tutti gli impiegati che hanno il cognome che inizia per “L”:

Sulla relazione employee con D=”numero di data record per pagina”, B=”numero totale di pagine” ed F>2 come fan-out di un eventuale albero, selezionare la affermazione corretta tra le seguenti:



A - L’organizzazione basata su indice ad albero è migliore di quella basata su hash

B - Nessuna delle alternative

C - L’organizzazione basata su indice ad albero è peggiore di quella basata su ordinamento

D - La organizzazione ad heap è migliore della organizzazione basata su ordinamento



Io ho risposto C, ma non con convinzione, perché non si sa quanto è selettiva la selezione, inoltre non so se è possibile prelevare dati a blocchi, cosa che favorirebbe l’ordinamento del file.

Che ne pensate?

A raga', mo vi illumino io, spero solo di essere convincente: inanzitutto la ricerca non è a selezione di intervallo, quelle sono del tipo ad esempio, "trovare gli impiegati con eta compresa tra i 30 e i 45".
Quindi è come se fosse Trovare l'impieagato con Lxxxx per esempio, solo che potrebbero esserci piu' record trovati e questo cambia leggermente le cose.

Ma comunque un indice hashing è superiore a un B+, perche' 2D<Dlog(F)di 0.15B, quindi la A è vera al contrario, quindi è falsa.

L'organizzazione basata su indice ad albero è migliore di un file ordinato perche' F>2, quindi la C è falsa.

La D è palesemente falsa perche' gli heap sono ottimi solo per le scansioni. E un file ordinato ha comunque un dignitoso Dlog(2) di B per le ricerche.

Quindi è nessuna delle alternative! Spero leggiate questo post in tempo.

Qualcuno ha capito se la ricerca esatta in un file heap con duplicati è 0,5 BD o solo BD?

essendoci valori duplicati non si dovrebbe scansionare tutto il file?

Lo 0,5BD vale facendo un'analisi del caso medio, in media il record sarà a metà file. Se la ricerca è con duplicati, non abbiamo la certezza di aver trovato tutti i record validi finchè non abbiamo cercato in tutto il file, perciò in un'organizzazione a heap, nel caso di duplicati, il costo è BD...

Sicuro, riguardatevelo sul libor, non nello schemetto di Zirilli, che, come scrive all'inizio, ha molte semplificazioni!

Sempre dal libro:

FILE ORDINATI:
ricerca con selezione di uguaglianza:se più record soddisfano la condizione di ricera, essi saranno sicuramente adiacenti tra loro, e quindi il costo sarà pari al costo di localizzazione del primo più la lettura sequenziale degli altri record

che coincide esattamente con il costo di ricerca per intervallo!

FILE CON INDICE AD ALBERO:
ricerca con selezione di uguaglianza: se diversi record soddisfano la selezione, non possiamo essere certi siano adiacenti tra loro. Il costo coincide con quello di localizzazione della prima data entry rilevante più un operazione di I/O per ciascuno dei record.

anche questo coincide con il costo della selezione per intervallo.

Per questo avevo detto che si tratta di una selezione per intervallo: se più record soddisfano l'uguaglianza, i costi sono come quelli per l'intervallo!

oggi, qualcuno, cortesemente, potrebbe chiedere a zirilli quando ha intenzione di verbalizzare?
risposte multiple:
A)dicembre e settembre;
B)gennaio e settembre;
C)dicembre, gennaio e settembre;
D)settembre.
risposte sbagliate danno un punteggio negativo!!!

oggi, qualcuno, cortesemente, potrebbe chiedere a zirilli quando ha intenzione di verbalizzare?
risposte multiple:
A)dicembre e settembre;
B)gennaio e settembre;
C)dicembre, gennaio e settembre;
D)settembre.
risposte sbagliate danno un punteggio negativo!!!

Indecisione sulla B o sulla C :lol:
Visto che ha rimandato la consegna a gennaio e considerato che ti vuole vedere in faccia e giudicare dal numero di borse sotto gli occhi, con un fan-out F>2 fa l'orale... ... allora è B

...alla fine di tutto i progetti verranno valutati per uno 0,1%... sempre se verranno valutati...

...che branco de ghei !

A raga', mo vi illumino io, spero solo di essere convincente: inanzitutto la ricerca non è a selezione di intervallo, quelle sono del tipo ad esempio, "trovare gli impiegati con eta compresa tra i 30 e i 45".
Quindi è come se fosse Trovare l'impieagato con Lxxxx per esempio, solo che potrebbero esserci piu' record trovati e questo cambia leggermente le cose.

Ma comunque un indice hashing è superiore a un B+, perche' 2D<Dlog(F)di 0.15B, quindi la A è vera al contrario, quindi è falsa.

L'organizzazione basata su indice ad albero è migliore di un file ordinato perche' F>2, quindi la C è falsa.

La D è palesemente falsa perche' gli heap sono ottimi solo per le scansioni. E un file ordinato ha comunque un dignitoso Dlog(2) di B per le ricerche.

Quindi è nessuna delle alternative! Spero leggiate questo post in tempo.

Ma sei sicuro ? Nel senso che già ti è capitata....perchè anche il discorso che ha fatto arale non è del tutto sbagliato

Comunque raga non è possibile, bisogna abilitare l'edit in questo maledetto forum!!!!! :twisted: :twisted: :twisted: :twisted:

Scusate..

SEL nome=a (S) JOIN (M) = SEL nome=a (M) JOIN (S)

secondo voi quando è vera?

Io avevo pensato "quando M e S condividono l'attributo nome"...

c'ha ragione er fisicaccio! e chiudemola qua!

Scusate..

SEL nome=a (S) JOIN (M) = SEL nome=a (M) JOIN (S)

secondo voi quando è vera?

Io avevo pensato "quando M e S condividono l'attributo nome"...

Sì, ho provato facendo diversi esperimenti.

Scusate..

SEL nome=a (S) JOIN (M) = SEL nome=a (M) JOIN (S)

secondo voi quando è vera?

Io avevo pensato "quando M e S condividono l'attributo nome"...

Secondo me quella era "nessuna delle alternative" perchè:
Metti che ho in M "A" e "B" e in S "A" ed "A"se faccio la sel su S eppoi il join mi viene "A" "A" "A" "B",se faccio al contrario "B" non c'è...quindi è diverso...

Scusate..

SEL nome=a (S) JOIN (M) = SEL nome=a (M) JOIN (S)

secondo voi quando è vera?

Io avevo pensato "quando M e S condividono l'attributo nome"...

Si esatto.
L'uguaglianza quindi è sempre vera, il contenuto invece MAI.

Con il prodotto cartesiano invece risulta sempre falsa, sia l'uguaglianza che il contenuto.

Scusate..

SEL nome=a (S) JOIN (M) = SEL nome=a (M) JOIN (S)

secondo voi quando è vera?

Io avevo pensato "quando M e S condividono l'attributo nome"...

Secondo me quella era "nessuna delle alternative" perchè:
Metti che ho in M "A" e "B" e in S "A" ed "A"se faccio la sel su S eppoi il join mi viene "A" "A" "A" "B",se faccio al contrario "B" non c'è...quindi è diverso...

No, avrai in entrambi i casi A e A come risultato, come se facessi il JOIN sul campo nome.

Scusate ho detto una "BAGGIANATA"...

Pure io ho detto quella baggianata sul branching factor (RIP al mio ultimo neurone sopravvissuto... e lo sapevo pure perché me l'ero scritto a caratteri cubitali :? ) ....

Però se non l'avessi detta, magari non ti saresti accorto del ragionamento sbagliato


Ragà, che ve lo dico a ffà... 'sto compito c'ha poco di sicuro, a parte qualche domanda "umana" ... Zirilli ha fatto poco e niente, visto che le slide erano un mix tra quelle dell'Amari e quelle di Minenna... l'unico sforzo che ha fatto (oltre a ritirare l'assegno per il contratto) è stata aggiungere la striscia arancione in tutte le slide per mettere il suo nome sul lavoro degli altri.

In bocca al lupo!!!!!!!!!!!!!!