Qualcuno aveva la domanda (σcampo=a A) JOIN B contenuto (σcampo=a B) JOIN A ?

Qualcuno l'ha contattata?[/size]

Ciao

F è l'altezza dell'albero. Più è alto, meno è efficiente..

Ma F non è il numero medio di figli di ogni nodo?

Sul libro è scritto così...

Concordo...

F è l'altezza dell'albero. Più è alto, meno è efficiente..

Ma F non è il numero medio di figli di ogni nodo?

Sul libro è scritto così...

Si sono possibili più indici, è scritto alla fine del paragrafo dove spiega le data entry, 10.2.
Avevo io la domanda sulle data entry ma non ricordo assolutamente le altre risposte.

Comunque "eventuali altre indici del file devono essere non-clustered" dovrebbe essere giusta perché come hai già detto, sul libro dice proprio che non più di un indice dovrebbe usare l'alternativa 1, perché bisogna evitare di memorizzare i record più di una volta.
Tutti gli altri indici quindi saranno non clustered. :wink:

E poi, stando a quello che dice lui... un file può essere clustered su al più una chiave... il che lascerebbe lo spiraglio ad altri indici non-clustered... !?!?

Un indice clustered dovrebbe includere la chiave primaria, e quindi è un indice primario.

Stavo scrivendo mentre postavi... :lol:
Ma sono possibili più indici!?!?!? Mica l'ho trovata 'sta cosa...

Sì, più indici sono possibili..

E poi, stando a quello che dice lui... un file può essere clustered su al più una chiave... il che lascerebbe lo spiraglio ad altri indici non-clustered... !?!?

Infatti la risposta che credo giusta è "eventuali altri indici sul file devono essere non-clustered"...

Stavo scrivendo mentre postavi... :lol:
Ma sono possibili più indici!?!?!? Mica l'ho trovata 'sta cosa...


E poi, stando a quello che dice lui... un file può essere clustered su al più una chiave... il che lascerebbe lo spiraglio ad altri indici non-clustered... !?!?

Cmq...

Quando un indice coincide con i record:
- Implica un indice clustered
- Un file può essere clustered su al massimo una chiave

Sì... appunto per questo!

Un indice che ha le data entry che coincidono con il record effetivo, è la prima alternativa, che coincide con un file clustered... e di organizzazioni clustered ce ne possono essere al più una...

nessuno aveva questa domanda? Non ricordo le altre alternativa di risposta! ops:

No, 'spè...
Non mi pare c'entri molto!!

Coincidono con i record se hai fatto l'indicizzazione raggruppandoli nel data entry secondo una determinata K

Ma non è sempre così!!
Si può decidere di indicizzare secondo la chiave K e il record id (quindi non con il record stesso) e via dicendo...

Ti ricordi le alternative?

Scusate, altra domanda:

Nell'indice di un file le data entry coincidono con i record

La risposta: eventuali altre indici del file devono essere non-clustered, è giusta? :roll:

C'era il solito F>2

Allora la a sa di trappola. Come al solito, con l'italiano ... :roll:
In questo frangente, un indice ad albero è peggiore di un file ordinato...

Sì, questo l'ho capito...ma è anche vero che per la scansione un'organizzazione ad heap è ottima (B*D), così come per il file ordinato.

Uhm... stavo rileggendo le slide...
Dell'heap dice che va bene quando l'accesso è una scansione di tutti gli elementi, non importa che siano ordinati. Nella domanda, non viene esplicitamente richiesto che siano in ordine!!
Ricordandosi che è "vera quella più vera", direi che la a diventa candidata ad essere la risposta più corretta.
Rimanendo vera pure la b, cmq...

Non capisco cosa cambia con il valore di F...

F è l'altezza dell'albero. Più è alto, meno è efficiente...

Comunque, nelle domande, quando elenca una query e dice cosa è meglio non specifica mai quanto è selettiva la query...
ad esempio, quando dice di dover stampare il nome l'età di tutti gli impiegati che hanno cognome che inizia per 'L' è uguale a "stampare nome e età di tutti gli impiegati il cui cognome è "Rossi"?

Più leggo questo argomento sul libro e meno sono in grado di dare una risposta...

Avanzo l'ipotesi ...
"Rossi" -> Ricerca esatta
"L" -> Ricerca per range

Ragazzi, giusto per ricapitolare, mi sembra di aver capito che le domande sono solo su:

algebra relazionale, modello entità-relazione, file e indici, linguaggio sql

Niente Jdbc e Odbc, Sqlj &co., giusto?

Yep! Per scrupolo ricontrollati anche la parte di slide sul buffer ... hai visto mai...

Cmq sia, credo che ci saranno nuovamente le stesse domande...

Ragazzi, giusto per ricapitolare, mi sembra di aver capito che le domande sono solo su:

algebra relazionale, modello entità-relazione, file e indici, linguaggio sql

Niente Jdbc e Odbc, Sqlj &co., giusto?

ciao ..volevo sapere se qualcuno ha testi di esoneri o esami passati d questa materia....sempre se in giro ci sono..grazie mille a tutti!

Quoto... e aggiungo, Jubilee, se ci sei batti un colpo... :cry:

Credo tu abbia molti msg in PVT! :wink:

ciao ..volevo sapere se qualcuno ha testi di esoneri o esami passati d questa materia....sempre se in giro ci sono..grazie mille a tutti!

Mi sembra che alla domanda di Rizzi c'era anche un'altra opzione:

L'organizzazione basata su indice ad albero è peggiore di quella basata su ordinamento solo se F>2

Non capisco cosa cambia con il valore di F...

Comunque, nelle domande, quando elenca una query e dice cosa è meglio non specifica mai quanto è selettiva la query...
ad esempio, quando dice di dover stampare il nome l'età di tutti gli impiegati che hanno cognome che inizia per 'L' è uguale a "stampare nome e età di tutti gli impiegati il cui cognome è "Rossi"?

Più leggo questo argomento sul libro e meno sono in grado di dare una risposta...

C'era il solito F>2

Allora la a sa di trappola. Come al solito, con l'italiano ... :roll:
In questo frangente, un indice ad albero è peggiore di un file ordinato...

Sì, questo l'ho capito...ma è anche vero che per la scansione un'organizzazione ad heap è ottima (B*D), così come per il file ordinato.

Prova a farti un esempio pratico ... ed applica quelle operazioni...

Per quei pochi dati che ha.. non è detto che quelle uguaglianze siano verificate!!!!!
Stessa storia per il "contiene"...
Avevo quello con i JOIN, sia all'esonero che all'appello. Ho risposto "MAI" ...