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...

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:

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?

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:

Cmq...

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

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... !?!?

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"...

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.

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

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

Sul libro è scritto così...

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...

Qualcuno l'ha contattata?[/size]

Ciao

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

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

Io l'avevo simile con i prodotti cartesiani...
il tuo caso non dovrebbe verificarsi mai (perchè sono sempre uguali!)

Comunque la famosa slide con le faccine ha degli errori. In pratica dovete spostare tutte le faccine di una posizione verso l'alto, così spariscono le organizzazioni con doppia faccina.

Secondo me l'ha fatto apposta per confonderci ancora di più le idee....

dal sito del prof....

PER ACCOGLIERE LE NUMEROSE RICHIESTE, LA CONSEGNA DEL PROGETTO SARA' A GENNAIO CON DATA DA DEFINIRE


grandiosa notizia... :lol: :lol: :lol:

Sì infatti, ci si potrà lavorare su più tranquilli

Qualcuno puo' dirmi la procedura per il progetto? cioe' se dipende anche per Minenna il calcolo del resto?..o possimao scegliere quello che ci pare?
:?:

poi c'era l'SQL della creazine di 3 tabelle (primo, secondo, terzo) legate, le ultime due alla prima, attraverso una Foreign Key e si chiedeva in generale cosa significasse: tra le risposte c'era "il codice è scritto erroneamente", "le tabelle secondo e terzo hanno una relazione binaria con primo", "la tabella primo è una generalizzazione delle altre due tabelle"

Ecco io avevo questa ed ho risposto che il codice era scritto erroneamente, perchè nelle tabelle che avevano la foreign key, nella parte

FOREIGN KEY(id) REFERENCES TO ..

l'id era la chiave primaria della stessa tabella... non era una chiave di un'altra tabella!

c'era un diagramma E/R (X)-(R)<-(Y) (all'incirca così), era prima di tutto una domanda con più rispsote e chiedeva le affermazioni corrette fra le risposte: "R è una relazione uno-a-molti tra X e Y", "R è una relazione uno-a-molti tra Y e X", "X partecipa totalmente a R", "X e Y sono definiti univocamente dagli attributi XID e YID"

Avevo anche questa, e ho messo che è una relazione uno-a-molti tra X ed Y, e che gli attributi di X e Y sono definiti univocamente da xid e yid..
che, ovviamente, erano indicati come chiavi primarie!

Che dite?

Ecco io avevo questa ed ho risposto che il codice era scritto erroneamente, perchè nelle tabelle che avevano la foreign key, nella parte

FOREIGN KEY(id) REFERENCES TO ..

l'id era la chiave primaria della stessa tabella... non era una chiave di un'altra tabella!

Su questa ho qualche dubbio...
l'id che sta tra parentesi dopo FOREIGN KEY non deve essere quello della tabella che viene referenziata.
Tramite quell'id si referenzia l'id dell'altra tabella..
in quel caso Tid e Sid referenziano Pid.

Sulla seconda risposta sono d'accordo.

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?