mitto98 / unige-bd2 Goto Github PK

• Query 1
• Query 2
• Query 5 (questa ha senso che non li usi, forse meglio cambiarla)

Progettare almeno 3 transazioni seguendo le seguenti specifiche:

(a) ciascuna transazione dovrà contenere almeno 3 operazioni
(b) una transazione dovrà contenere solo operazioni di lettura
(c) due transazioni dovranno contenere almeno due operazioni di aggiornamento (inserimenti, cancellazioni, modifiche) che coinvolgano un sottoinsieme delle tuple di una o più tabella della base di dati
(d) per ogni transazione dovrà essere scelto il livello di isolamento ritenuto più adeguato, giustificandone la scelta
(e) almeno due transazioni devono operare in scrittura su un insieme comune di tuple
(f) almeno due transazioni devono operare in lettura su un insieme comune di tuple
(g) almeno due transazioni devono operare rispettivamente in lettura e scrittura su un insieme comune di tuple
( h) almeno una transazione deve leggere almeno due volte in punti diversi del codice uno stesso insieme di tuple
(i) per ogni transazione dovrà essere individuato un adeguato livello di isolamento

Documentazione. Descrivere ogni transazione individuata, in linguaggio naturale e in pseudo-codice, indicando quali condizioni tra quelle sopra riportate soddisfa. Giustificare il livello di isolamento prescelto.

Dimostrare che lo schema fisico prescelto permette di ottimizzare l'esecuzione delle interrogazioni
contenute nel carico di lavoro. A questo proposito, per ciascuna interrogazione Qi nel carico di lavoro, si suggerisce di:

1. Eseguire Qi sia PRIMA della implementazione dello schema fisico (complessivo) sia DOPO, confrontando i piani di esecuzione e i tempi di risposta ottenuti nei due casi;
2. Confrontare i piani di esecuzione scelti dal sistema PRIMA e DOPO l'implementazione dello schema fisico e giustificare eventuali differenze;
3. Modificare eventualmente lo schema fisico, nel caso in cui l'analisi dei piani scelti e dal sistema metta in evidenza alcuni errori di progettazione.

Documentazione. Per ciascuna query nel carico di lavoro presentare il piano di esecuzione ottenuto PRIMA e DOPO la creazione dello schema fisica, con i tempi associati. Giustificare i comportamenti ottenuti al passo 4.ii e le eventuali modifiche adottate al passo 4.iii.

Implementare le transazioni utilizzando l'SQL operazionale supportato dal sistema prescelto e in Java, facendo attenzione al settaggio dell'autocommit (che deve essere posto a false). A questo proposito, potete adattare quanto proposto nel file labo.java. Scegliere per ciascuna transazione un adeguato livello di isolamento.

Documentazione. Riportare il codice delle transazioni in SQL operazionale e in Java (in appendice).

Concedere ai ruoli appena creati i privilegi che ritenete ragionevoli tenendo in considerazione il dominio applicativo considerato e la gerarchia dei ruoli. Giustificare le vostre scelte.

Documentazione. Tabella che sintetizza i privilegi attribuiti a ciascun ruolo e a ciascun utente. Giustificare i privilegi assegnati ai ruoli in linguaggio naturale.. Comandi di GRANT per l'assegnazione dei privilegi ai ruoli.

Eseguire le transazioni e analizzate lo scheduling generato dal sistema (utilizzando ad esempio stampe ausiliarie all'interno del codice transazionale). Giustificate lo scheduling ottenuto tenendo in considerazione i livelli di isolamento e il protocollo di controllo della concorrenza del sistema prescelto.
Se lo scheduling ottenuto è sempre seriale, allungare la durata delle transazioni aggiungendo dei "ritardi" nel codice Java (metodo wait()).

Documentazione. Descrizione dello scheduling ottenuto e giustificazione del risultato.

Modificare i livelli di isolamento delle transazioni, rieseguire le transazioni e giustificare il nuovo comportamento ottenuto.

Documentazione. Specifica dei nuovi livelli di isolamento prescelti, descrizione del nuovo scheduling ottenuto e giustificazione del risultato.

Definire un carico di lavoro per la base di dati creata nella parte A. Il carico di lavoro dovrà contenere 8 query e dovrà essere così caratterizzato:

• (a) almeno una query con condizione di selezione ad alta selettività
• (b) almeno una query con condizione di selezione a bassa selettività
• (c) almeno una query con join di due tabelle
• (d) almeno una query con join di tre tabelle
• (e) almeno una query con raggruppamento
• (f) almeno una query con sottointerrogazione semplice
• (g) almeno una query con sottointerrogazione correlata
• (h) almeno una query con almeno un join e almeno due condizioni di selezione
• (i) almeno un attributo deve comparire nelle condizioni di selezione di almeno due query
• (l) almeno un attributo per ogni tabella deve essere coinvolto in una condizione di selezione
• (m) almeno una query deve contenere la clausola DISTINCT

Documentazione. Descrivere ogni query individuata, in linguaggio naturale e in SQL, indicando quali condizioni tra quelle sopra riportate soddisfa.

Implementazione dello schema fisico nel sistema prescelto.

Documentazione. Presentare il codice SQL per la creazione dello schema fisico.

Individuare un insieme di ruoli (almeno 4) per il dominio considerato, collegati da una gerarchia.

Documentazione. Descrizione in linguaggio naturale dei ruoli individuati e della gerarchia corrispondente.

Creare i ruoli individuati e almeno 5 utenti nel sistema prescelto. Attribuire opportuni ruoli agli utenti creati, utilizzando opportuni comandi di GRANT.

Documentazione. Comandi di GRANT per la crezione dei ruoli e degli utenti. Comandi di GRANT per l'assegnazione dei ruoli agli utenti.

Descrivere un privilegio basato sul contenuto e concederlo a un ruolo tra quelli creati (se questo privilegio modifica un privilegio già esistente, revocarlo prima della concessione del privilegio basato sul contenuto).

Documentazione. Descrizione del privilegio basato sul contenuto in linguaggio naturale. Codice SQL per concedere il privilegio al ruolo.

Sulla base del carico di lavoro individuato, stabilire se lo schema logico è normalizzato (secondo la BCNF) oppure no. Sempre sulla base del carico di lavoro, stabilire inoltre se e sotto quali ipotesi può convenire normalizzare o denormalizzare lo schema. Proporre una soluzione adeguata e giustificare la risposta.

Documentazione. Ragionamento seguito per stabilire se lo schema è normalizzato o non normalizzato. Giustificazione tuning logico della normalizzazione o della denormalizzazione proposto.

Modificare il file ConcurrentTransactions.java disponibile su Aulaweb, in modo da simulare l'esecuzione concorrente delle transazioni progettate. Ogni thread deve corrispondere a una singola transazione. Ponete quindi attenzione alla modalità utilizzata (implicita o esplicita) per specificare l'inizio e la fine di ciascuna transazione, modificando opportunamente il codice del file ConcurrentTransactions.java

Documentazione. Riportare il codice Java per l'esecuzione concorrente delle transazioni (in appendice alla documentazione).

Scegliere una certa frequenza per l'esecuzione dei checkpoint e utilizzare le istruzioni disponibili nel sistema prescelto per dichiararla.

Documentazione. Descrizione frequenza scelta e comando per la sua specifica nel sistema prescelto.

Scegliere un DBMS da utilizzare per lo svolgimento del progetto. Basandosi sulla documentazione disponibile e su prove pratiche, documentare le differenze del sistema prescelto rispetto all'SQL standard (introdotto a lezione) in relazione a quanto sotto indicato. Riportare le fonti delle informazioni inserite nella documentazione:

• Elaborazione di interrogazioni: strutture di memorizzazione; metodi di indicizzazione; modalità di clusterizzazione; modalità di realizzazione dei vari operatori dell'algebra relazionale estesa; approcci utilizzati per ottimizzazione logica e fisica.
• Gestione di transazioni: tipo di transazioni; livelli di isolamento e protocollo di controllo della concorrenza; lock escalation; modalità di ripristino.
• Controllo dell'accesso: Tipo di soggetto, privilegio e oggetto; disponibilità e caratteristiche del controllo dell'accesso basato sui ruoli; disponibilità e caratteristiche del controllo dell'accesso basato sul contenuto

Documentazione. Massimo 10 pagine.

Revocare almeno un ruolo e almeno un privilegio a un ruolo, utilizzando sia la modalità CASCADE sia la modalità RESTRICT. Giustificare i comportamenti ottenuti.

Documentazione. Comandi di REVOKE per realizzare le revoche sopra descritte. Giustificazione dei comportamenti osservati.

Individuare un dominio di vostro interesse; progettare una base di dati relazionale per il vostro dominio e implementare la base di dati (schema + istanza) nel sistema prescelto. La base di dati sarà il punto di riferimento per lo svolgimento delle parti progettuali successive. La base di dati dovrà soddisfare le seguenti condizioni:

• contenere almeno 4 tabelle
• ciascuna tabella dovrà contenere almeno 4 attributi
• almeno una tabella dovrà essere memorizzata su circa 1000 pagine
• le altre tabelle dovranno essere memorizzate su almeno 100 pagine
• le tabelle dovranno essere create senza vincoli di chiave primaria e chiave esterna
• per la generazione dell'istanza, utilizzare un generatore automatico di dati disponibile in rete (ad esempio, www.GenerateData.com, www.datanamic.com ma ne esistono molti altri). Per ottenere il numero di pagine richiesto,
  potete giocare con gli attributi testuali ed eventualmente inserire un attributo dummy per estendere la lunghezza di ogni tupla.

Documentazione. Riportare nella documentazione: (i) schema relazionale in meta notazione (quella utilizzata nel corso di Basi di Dati); (ii) il codice SQL per la sua creazione; (iii) la dimensione di ciascuna tabella creata; (iv) approccio utilizzato per la generazione dell'istanza.

Applicare i principi di tuning delle interrogazioni al carico di lavoro.
Confrontare i piani di accesso e i tempi di esecuzione delle interrogazioni iniziali e delle riscritture proposte.

Documentazione. Per ogni interrogazione nel carico di lavoro, discutere quali principi del tuning delle interrogazioni possono essere applicati e presentare l'eventuale riscrittura proposta. Riportare i piani di esecuzione prima e dopo la riscrittura, con i relativi tempi di esecuzione, discutendone le differenze.

Progettare uno schema fisico adeguato alla base di dati e al carico di lavoro proposto. Per ogni indice creato, valutare attentamente chiave di ricerca, tipo, eventuale clusterizzazione, copertura della query.

Documentazione. Giustificare opportunamente lo schema fisico proposto, motivando opportunamente la scelta di ciascun indice tenendo in considerazione i principi di tuning visti a lezione.