Beh...si può anche pensare come "Seleziona tutti gli impiegati che hanno come prima lettera del proprio cognome la L".

Così è per uguaglianza....in questo caso io direi B (nessuna delle alternative), a meno che si riuscisse a capire se Dlog(base2)B è migliore o peggiore di D(1+log(baseF)1.5B). Considerando che le faccine sono uguali, senza dati precisi non si può dire.

Una domanda, R deve per forza essere maggiore di 1 giusto ? Lo chiedo perchè altrimenti, per R piccoli(<0.85), sulla scansione un indice ad albero unclustered può essere anche migliore del file heap...

In questo caso, infatti, le prestazioni sono come quelle nel caso di selezione di intervallo, perchè se la chiave di ricerca è duplicata, non si sa a prescindere quanti record si devono cercare!

Ho proposto il dubbio su quella domanda anche a Zirilli:

ecco la risposta:

Dei capitoli previsti, quindi nel caso specifico,

deve basarsi sul capitolo del “File ed indici”, capire che tipo di operazione è

richiesta, e ricordare la tabella del confronto dei costi di I/O per poter valutare

quale affermazione è la più corretta.

La domanda si riferisce ad una “ricerca per uguaglianza”… consideri la colonna

Del confronto e valuti quali affermazione è corretta o se …nessuna….



Il consiglio è che non molte sono le cose importanti da ricordare ma…

Se c’è qualche lacuna il test tendenzialmente la evidenzia..

Nel caso degli indici deve ben capire e ricordare la tabella dei confronti, oltre ad avere ben chiara

L’indicizzazione e le strutture dei dati per gli indici.

Infine :

Una risposta sbagliata determina un valore negativo. Una non risposta, un valore pari a zero.

Un compito con cinque risposte corrette e cinque non risposte è sufficiente laddove

Lo stesso compito con 5 risposte sbagliate è insufficiente.

Buono studio

Secondo lui è una ricerca per uguaglianza...

Si, anche se nella ricerca di uguaglianza si puo' avere anche piu' di un risultato.
Es. stampare tutti gli impiegati che si chiamano Antonio.

I'm sorry!!
Forse hai ragione. :wink:
Solo che ha prima vista la pensi come selezione solo sulla L.

Direi sia più che rara una persona che si chiama L... :wink:


Per stevieray: appunto per quello, l'uguaglianza è sul valore intero del campo! Difficile che ci sia una solo persona che inizi per L, specialmente per grandi basi di dati...

Arale, m'hai quasi convinto...

...anche perchè l'uguaglianza andrebbe semmai fatta sul valore di un certo campo e non su una parte di esso.

I'm sorry!!
Forse hai ragione. :wink:
Solo che ha prima vista la pensi come selezione solo sulla L.

Secondo me è per intervallo perchè possono esserci più impiegati che iniziano per 'L'... deve cercare tutti i nomi che vanno da la* a lu*!

Se desse un nome o cognome preciso, ad esempio 'Lorenzo', sarebbe per selezione!

Non dovrebbe essere una ricerca di uguaglianza!!

Anche secondo me è la C.

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.

Insomma, la chiave che referenzio può avere un nome diverso da quella della tabella "principale"???

Mhhhh... :?

Dal libro

La chiave esterna nella relazione referenziantedeve essere uguale alla chiave primaria della relazione referenziata; cioè deve avere lo stesso numero di colonne e tipi compatibili, sebbene i nomi delle colonne possano essere diversi.

Hai ragione!!!

Si tratta di una selezione con intervallo, quindi secondo me la A è giusta... perchè l'indice hash in questa selezione impiega B*D op di I\O, che è di gran lunga maggiore di D*log(1.5B)...

No???

Si anche secondo me è la C

Bisogna fare una scansione completa e quindi l'ORDINAMENTO è migliore dell'ALBERO.

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?

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.

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?

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?
:?:

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

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:

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

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!)