Basi di dati

Sistema informativo e database

Sistema informativo: si dice sistema informativo un sistema che permette di gestire i dati in modo strutturato.

Database

Database: ci permette di strutturare i dati per evitare ridondanza e incongruenze.

DBMS: DataBase Management System, serve per la gestione di un database.

Lo schema di progettazione del DataBase è il Modello dei Dati.

Fasi di realizzazione di un database

• Analisi - Raccolta dei requisiti
• Progettazione concettuale - Modello ER (Entità - Relazione)
• Progettazione logica - Si trasforma il Modello ER in una struttura dati (Modello relazionale)
• Progettazione fisica - Implementazione del DB tramite linguaggio SQL e scelta del DBMS (es. MySQL…)
• Database

Progettazione concettuale

Entità

Entità: è un qualsiasi elemento reale e identificabile che possiede delle caratteristiche (dette attributi).

Gli attributi possono essere di vario tipo:

• Atomici - può assumere un solo valore non scindibile (es. nome, cognome…).
• Composti - contengono più informazione all’interno dello stesso campo (es. indirizzo). Gli attributi data e ora, pur essendo composti, possono essere considerati atomici perché esiste un tipo che permette di gestirli.
• Derivati - è possibile calcolarli mediante altri attributi (es. età, calcolabile da data di nascita). Si indicano con un cerchio tratteggiato oltre quello normale.
• Multivalore - che può avere più valori associato allo stesso campo (es. numero di telefono). Si indicano con due cerchi.
• Chiave - attributi che rappresentano univocamente l’entità (es. matricola). Si rappresenta sottolineando il nome dell’attributo.

In definitiva, considerando gli attributi come funzioni:
A : E -> P(V) U NULL

• P - rappresenta i possibili vincoli che possono limitare i valori ammissibili del dominio (es. V: numeri interi - P: max 50 min 0).
• V - rappresenta tutti i valori associabili al dominio dell’attributo (es. matricola: valori numerici - nome: valori stringa).
• NULL - rappresenta un valore non conosciuto, un valore vuoto. È diverso dallo zero.

Grado: numero di entità collegate con una singola relazione, il grado deve essere sempre pari a 2.

Cardinalità: numero di istanze di ciascuna entità che partecipa alla relazione. Può essere:

• 1 a 1 (uno a uno)
• 1 a N (uno a molti)
• N a N oppure N a M (molti a molti)

N.B. La cardinalità può essere espressa anche come coppia di valori numerici che rappresentano il minimo e il massimo numero di istanze.

Partecipazione:

• Totale: tutte le istanze sono collegate attraverso relazioni.
• Parziale: non tutte le istanze sono collegate attraverso relazioni.

La partecipazione totale nel diagramma ER viene rappresentata con un tratto in grassetto dal lato della relazione che ha partecipazione totale (in questo caso dal lato di studente).

È possibile che una relazione abbia come chiave univoca le chiavi di altre entità. In questo caso si rappresenta un arco che collega le relazioni che offrono l’attributo.

Entità ricorsiva e gerarchia IS-A

Entità ricorsiva: quando un’entità è collegata a se stessa mediante una relazione.

Gerarchia IS-A: è utilizzate nel caso in cui ci siano delle entità che siano più specifiche di alcune già date, ovvero sono caratterizzazioni più dettagliate che aggiungono altre informazioni all’entità di partenza (entità padre).

Partecipazione totale: nel caso della gerarchia IS-A si parla di partecipazione totale nel caso in cui l’entità padre è sempre riconducibile ad un’entità figlia.

Esclusività della gerarchia: si parla di esclusività della gerarchia nel caso in cui l’entità padre può essere ricondotta ad almeno una delle entità figlie. Se non esiste esclusività si parla di gerarchia sovrapposta.

Traccia d'esame - 2 Settembre 2015

Una base di dati deve essere utilizzata per gestire gli annunci pubblicati su un portale online. Ogni annuncio è identificato da un codice univoco di 10 caratteri, nome, descrizione, categoria (elettronica, immobili, veicoli, altro), data pubblicazione, data scadenza e utente che lo ha pubblicato. Ogni utente è caratterizzato da codice fiscale, nome, cognome e indirizzo e-mail. Per ogni annuncio è possibile inoltre indicare una serie di keywords (parole chiave) identificate attraverso codice e nome. Gli annunci si suddividono inoltre in: vendite, si conosce il prezzo indicato e il comune in cui si trova l'oggetto; acquisti, è presente un attributo booleano che indica se l'acquisto dovrà avvenire esclusivamente con consegna di persona o meno. Ad ogni annuncio sono associate delle offerte di cui si conosce data, ora, importo, note eventuali e utente che ha inviato l'offerta. Per ogni offerta occorre verificare che la data sia compresa tra la data di pubblicazione e di scadenza del relativo annuncio e che l'offerta non provenga dallo stesso utente che ha pubblicato l'annuncio. Indicare le cardinalità delle relazioni e un identificatore per ciascuna entità.

Modello ER

Business Rules:

• Codice annuncio max 10 caratteri
• Categoria: elettronica, veicoli, immobile, altro
• IDPersona di tipo Boolean
• Note:
• L’aggiunta di un nuovo attributo (es. in offerta, l’attributo ID come chiave univoca anziché utilizzare CFAnnuncio, data, ora) presenta alcuni problemi: spazio, vincoli (non può più ripetersi), range (valori che può assumere).
• L’entità “offerta” è detta entità debole perché:
• I suoi attributi non bastano per definire una chiave univoca,
• Non esiste se presa singolarmente, ma solo a seguito di “annuncio”. Quindi la sua esistenza è legata ad un'altra entità.

Per la gestione della gerarchia (vendita e acquisto) ci sono tre metodi:

Figlie del padre

L’entità padre eredita tutti gli attributi delle entità figlie, comprese le relazioni. Spesso si utilizza un ulteriore attributo “tipo” per indicare l’entità figlia specifica. È preferibile utilizzarlo quando:

• Ci sono poche figlie
• Pochi attributi delle figlie
• Le figlie hanno poche/non hanno relazioni.

Pro: Risparmio di memoria, dato che evita la creazione di nuove tabelle. Velocità, essendo tutte le informazioni presenti in un’unica tabella.

Contro: Non tutti gli attributi servono contemporaneamente, quindi andranno aggiunte delle Business Rules.

Business Rules:

• TIPO = vendita/acquisto
• (TIPO = vendita AND idPers IS NULL AND prezzo, comune IS NOT NULL) OR (TIPO = acquisto AND idPers IS NOT NULL AND prezzo, comune IS NULL)

Padre nelle figlie

Tutti gli attributi e relazioni del padre vengono ereditati da ciascuna delle figlie. Si utilizza soprattutto quando il padre ha poche relazioni.

Contro: Complessità della realizzazione. n×m, dove n sono le relazioni delle figlie e m sono le relazioni del padre.

Figlie deboli rispetto al padre

Le entità figlie restano identiche nel modello ER. La gerarchia si trasforma in relazioni 1:1 tra padre e figlie. Le figlie diventano deboli rispetto al padre, quindi senza chiavi parziali, che si rappresentano con una linea con cerchio che taglia la relazione dal lato debole (figlie). Si usa quando:

• Ci sono molte figlie
• Ogni figlia ha tanti attributi
• Le figlie hanno tante relazioni

Pro: Facilità di implementazione. Nessuna Business Rule da aggiungere.

Contro: Più tabelle da inserire. Bisogna fare un’operazione di JOIN per interagire con le figlie.

Traccia d'esame - 12 Novembre 2015

Una base di dati deve essere utilizzata per gestire un sito di car sharing. Occorre memorizzare i dati riferiti a ciascun utente di cui si conosce codice fiscale, nome, cognome e e-mail. Si conoscono inoltre le informazioni delle auto utilizzate durante i viaggi, identificate da targa, modello, cilindrata, km percorsi e utente proprietario. Per ogni viaggio invece occorre memorizzare data e ora di partenza, auto utilizzata, numero massimo di persone, costo del viaggio, comune di partenza e di arrivo (per ciascun comune si conosce CAP e nome) e lista di utenti passeggeri. Ogni passeggero indicherà anche un voto e una recensione del viaggio. Verificare inoltre che per ciascun viaggio il numero di passeggeri non sia superiore rispetto al numero massimo indicato. Un viaggio può essere di tipo:

• Diretto (senza soste intermedie), di cui si conosce la lunghezza complessiva in km;
• Con soste, di cui si conosce la lista dei comuni in cui verrà effettuata una sosta e la relativa durata.

Indicare le cardinalità delle relazioni e un identificatore per ciascuna entità.

Modello ER

Business Rules:

• Voto: valori da 1 a 5
• maxPersone >= numero utenti per viaggio
• Tipo: diretto/con soste
• (tipo = diretto AND km IS NOT NULL) OR (tipo = con soste AND km IS NULL)
• La relazione “fa” tra Viaggio e Comune esiste solo per viaggio con soste

Modello logico RDBMS

RDBMS: Si parla di (DBMS Relazionale).

Relazione: rappresenta una tabella nell’RDBMS.

R(A₁, A₂, … , A_n)

Intensione: lista ordinata di attributi della relazione.

Per ciascun attributo è definito un dominio:
D(A₁) = valori che può assumere A₁ U NULL

Istanza: di una generica relazione R è l’insieme non ordinato delle tuple appartenenti alla relazione r(R) = (t₁, t₂, … , t_n)

Tupla: insieme ordinato di valori associati a ciascun attributo della relazione (riga della tabella) t = <v₁, v₂, … , v_n>

La chiave univoca va sottolineata anche nel modello logico.

Superchiave (SK): l’insieme di attributi che rispettano la relazione t [SK] ≠ t [SK] ∀i, ∀j i ≠ j

ovvero il valore degli attributi che rappresentano la superchiave deve essere sempre diverso per ogni tupla.

Es. per la tabella UTENTE

SK = (CF, nome) = Chiave Candidata₁
SK = (CF, cognome) = Chiave Candidata₂
SK = (CF) = Chiave Primaria PK

La chiave quindi rappresenta il numero di attributi minimo per rispettare la condizione della superchiave.

La chiave univoca scelta è detta Primary Key (PK).

Tutte le altre possibili combinazioni di chiavi scartate sono dette Chiavi Candidate.

Grado: di una relazione è il numero di attributi che questa possiede.

Cardinalità: di una relazione è il numero di tuple (righe) che questa possiede.

Modello logico - Traccia del 12 Novembre 2015

• UTENTE(CF, nome, cognome, email)
• AUTO(targa, modello, cilindrata, km, CFUtente)

N.B: per le relazioni 1:N (dal lato N) si aggiunge un attributo chiave per collegare le due tabelle. Questo tipo di attributo è detto Chiave Esterna FK (Foreign Key).

FK = UTENTE(PK) U NULL

La FK deve contenere la PK della tabella a cui è collegata (vincolo di integrità referenziale). È possibile inserire il valore NULL solo quando la partecipazione non è totale.

• COMUNE(CAP, nome)
• VIAGGIO(data, ora, maxPersone, costo, km, tipo, capPartenza, capArrivo)

N.B: per le relazioni N:N si crea un’ulteriore tabella con le chiavi primarie delle due tabelle collegate e gli attributi della relazione.

• UTENTE_VIAGGIO(CFUtente, targaAutoViaggio, dataViaggio, oraViaggio, voto, desc)
• COMUNE_VIAGGIO(targaAutoViaggio, dataViaggio, oraViaggio, capSosta, durata)

N.B: per le relazioni 1:1, la chiave primaria della entità con partecipazione parziale si trasporta nella tabella con partecipazione totale.

Traccia d'esame - 12 Febbraio 2019

Una base di dati deve memorizzare le informazioni relative allo sviluppo di progetti software. Ogni progetto è identificato attraverso un codice univoco, nome e descrizione. Per ciascuno progetto si conosce inoltre la lista di sviluppatori che ci lavora identificati da un username univoco, password, e-mail e un attributo booleano che indica se lo sviluppatore possiede i permessi di amministratore per il particolare progetto. Ogni progetto prevede differenti versioni caratterizzate da un numero progressivo univoco solo rispetto al progetto e data di rilascio. Ciascuna versione prevede inoltre una serie di attività, aventi un codice univoco solo rispetto alla versione, descrizione, data di creazione e sviluppatore di riferimento. Le attività si dividono in: (i) segnalazione bug, si conosce lo stato (risolto, non risolto) e la priorità (alta, media, bassa); (ii) inserimento di nuove funzionalità, si conosce la data di completamento e la lista di bug risolti. Per ogni attività, verificare che lo sviluppatore indicato si presente tra quelli associati al relativo progetto. Indicare le business rules, le cardinalità delle relazioni e un identificatore per ciascuna entità.

Modello ER

Business Rules:

• admin booleano
• stato bug = risolto/non risolto
• priorità = alta/media/bassa
• sviluppatore attività deve essere tra sviluppatore progetto

Per la risoluzione della gerarchia BUG/NUOVA FUNZIONE conviene lasciare deboli le entità figlie avendo una relazione che le collega tra di loro.

Modello logico

• PROGETTO(cod, nome, desc)
• SVILUPPATORE(user, psw, email)
• PROGETTO_SVILUPPATORE(codProgetto, userSvil, admin)
• VERSIONE(codProg, num, dataRilascio)
• ATTIVITÀ(codProgetto, numVersione, cod, desc, dataCreazione, userSvil)
• BUG(codProgetto, numVersione, codAttivita, stato, priorità)
• NUOVAFUNZIONE(codProgetto, numVersione, codAttività, dataCompl)
• BUG_FUNZIONE(codProgettoBug, numVerBug, codAttrBug, codProgFun, numVerFun, codAttrFun)

Algebra relazionale

Algebra relazionale: sono operazioni che operano su una/due relazioni e producono una nuova relazione (algebra chiusa). È di tipo procedurale, cioè le operazioni sono eseguite in ordine.

→O(R) R’
→O₂(O₁(R)) R’

Gli operatori si dividono in unari, ovvero che ricevono in input un’unica relazione, e binari, ovvero che ricevono due relazioni in input.

Operatori unari

• Selezione σ (sigma): Serve per filtrare le tuple di una relazione di partenza mediante una condizione
  • →σ<condizione>(R) R’
  • →σ<nome = ‘Mario’>(STUDENTE) R’
  • grado(R) = grado(R’)
  • cardinalità(R) ≥ cardinalità(R’)
  • Gode della proprietà commutativa: σ<cond. 1>(σ<cond. 2>(R)) = σ<cond. 2>(σ<cond. 1>(R))
• Proiezione π (pi): Serve per filtrare gli attributi della relazione di partenza mediante una condizione
  • →π<lista attributi>(R) R’
  • →π<nome>(STUDENTE) R’
  • grado(R) ≥ grado(R’)
  • cardinalità(R) ≥ cardinalità(R’)
  • perché le tuple non sono prese se hanno NULL all’attributo preso in considerazione.
  • Non gode della proprietà commutativa: π<attr.>(σ<cond.>(R)) ≠ σ<cond.>(π<attr.>(R))
• Ridenominazione ρ (ro): Serve per ridenominare gli attributi nella relazione di output
  • →ρ<lista attributi lista attributi rinominata>(R) R’
  • →ρ<nome Nome Studente>(STUDENTE) R’
  • grado(R) = grado(R’)
  • cardinalità(R) = cardinalità(R’)

Operatori binari

Operatori insiemistici: per utilizzare gli operatori insiemistici è necessario che le relazioni siano UNION-COMPATIBLE, ovvero che abbiano lo stesso schema (stesso numero di attributi, anche con nome diverso, e ogni coppia di attributi delle due relazioni appartiene allo stesso dominio).

• Unione: R ∪ S → R’
  • Unisce le tuple delle due relazioni, le tuple uguali verranno inserite una sola volta.
  • grado(R) = grado(S) = grado(R’)
  • cardinalità(R) + cardinalità(S) ≥ cardinalità(R’)
• Intersezione: R ∩ S → R’
  • Prende solo le tuple comuni alle due relazioni.
  • grado(R) = grado(S) = grado(R’)
  • cardinalità(R’) ≤ min(cardinalità(R), cardinalità(S))
• Sottrazione: R - S → R’
  • Toglie le tuple della prima relazione contenute anche nella seconda relazione.
  • grado(R) = grado(S) = grado(R’)
  • cardinalità(R) ≤ cardinalità(R’)
• Join
  • Relazioni non devono essere per forza compatibili. Unisce gli attributi delle tabelle di partenza.