Appunti per orale di Basi di Dati

Indipendenza fisica e logica dei dati: Si vuole intendere la netta separazione tra

l’implementazione fisica e logica di una base di dati. Ciò vuol dire che è possibile modificare la

struttura fisica di un database senza corromperne la struttura logica e viceversa.

Architettura ANSI a tre livelli: L'architettura ANSI/SPARC definisce dei livelli di astrazione per un

sistema di gestione dei database. C’è un primo livello che è quello fisico, che specifica come sono

immagazzinati i dati e i metodi per accedervi (database relazionale piuttosto che uno a grafo, per

esempio); si passa poi ad un livello concettuale, che invece definisce l’organizzazione logica delle

informazioni (organizzazione delle tabelle, ad esempio); infine, c’è un livello esterno, che

rappresenta ciò che gli utenti possono vedere della base di dati mediante apposite viste. Con

questa architettura è possibile garantire l’indipendenza fisica e logica dei dati, tant’è che si può

modificare uno qualsiasi di questi livelli senza il rischio di dover modificare anche gli altri.

Proprietà di una base di dati: Una base di dati rappresenta una collezione di dati in relazione tra

loro. Questi dati devono essere strutturati (ossia della forma attributo=valore) e non semi-

strutturato (come i file HTML) o non strutturati (come i file binari/multimediali). In passato venivano

utilizzati i file per gestire le basi di dati, mentre ora si predilige l’uso di un DataBase

Mangadgement System (DBMS).

Proprietà di un DBMS: Indipendenza fisica e logica dei dati (già descritte). Efficienza, ossia il

sistema deve garantire risposte alle richieste nel minor tempo possibile, implicando algoritmi di

ricerca rapidi. Manipolazione, ossia le persone devono essere capaci di descrivere correttamente

le proprie richieste pur non conoscendo i dettagli tecnici della base di dati. Consistenza: deve

dare gli strumenti necessari alla diminuzione della ridondanza, in modo da evitare sprechi di

memoria e possibili errori (è necessario rispettare i vincoli di integrità). Coerenza, ossia il DBMS

deve garantire che i dati siano in uno stato coerente. Indipendenza, ossia il DBMS deve garantire

un accesso multiutente alla base di dati e, di conseguenza, una corretta gestione della

concorrenza. Privatezza: il DBMS deve garantire dei meccanismi per gestire i permessi di accesso

ai dati mediante un’opportuna gestione di utenti e privilegi. Affidabilità: Il DBMS deve garantire

che, in caso di problemi hardware/software, tramite un algoritmo di ripristino, sia possibile

ripristinare lo stato del database.

Metadati e dati: I dati sono già stati descritti. I metadati possono essere visti come una sorte di

“dato oltre il dato”, nel senso che specificano un’informazione in più sui dati.

Svantaggi di un DBMS: Sebbene il DBMS sia uno strumento molto potente e utile per una

corretta manipolazione di una base di dati, esso soffre anche di alcuni svantaggi. Primo tra tutti è

sicuramente l’elevata richiesta di risorse. Questo implica che, nel caso in cui ci siano pochi dati da

gestire (dove con pochi ci si può riferire anche alle centinaia di migliaia, in quanto occorre metterlo

in relazione con le capacità hardware del tempo), l’uso di un DBMS potrebbe essere

controproducente.

Modellazione Concettuale: Con modellazione concettuale si intende quel processo attraverso cui

si descrive logicamente il mini-mondo di riferimento. Tramite un’attenta analisi, è possibile

identificare gli oggetti che lo caratterizzano (entità) e le loro caratteristiche (attributi delle entità),

così come eventuali relazioni che esistono tra essi (associazione). Un modo per rappresentare

queste informazioni è tramite Diagrammi E/R (Entity-Relationship) o tramite UML. Un’entità

possiede delle proprietà intensionali ed estensionali. Nel primo caso, ci si riferisce a proprietà

che caratterizzano lo schema, mentre nel secondo caso ci si riferisce a proprietà e caratteristiche

che dipendono da uno specifico stato dello schema. Gli attributi possono essere di diverso tipo,

come atomici (anno di nascita), strutturato (indirizzo), multivalore (telefono), derivati (età), univoco

(matricola), totale (non sono consentiti valori mancanti) o parziali (sono consentiti valori mancanti).

Non è possibile rappresentare tutte queste tipologie di attributo tramite modello E/R. Inoltre, è

necessario fare una distinzione tra attributi statici e dinamici. È preferibile evitare di inserire attributi

che variano fin troppo spesso nel tempo (dinamico) per ridurre al minimo le operazioni di

lettura/scrittura rispetto ad attributi statici. Chiaramente, i valori degli attributi in una base di dati

saranno soggetti a cambiamenti nel tempo, ma è sicuramente preferibile che questi restino

immutati per quanto più tempo possibile. Di un’associazione si può specificare la cardinalità

(numero minimo e massimo di istanze), che però non è previsto dalla notazione del Navathe.

Infatti, con la notazione del Navathe viene specificata la molteplicità, che può essere univoca

(1:N), biunivoca (1:1), multivalore (N:1) o multivalore doppia (M:N). Infine, occorre esprimere

se c’è totalità o meno, ossia se tutte le tuple delle entità sono coinvolte nell’associazione oppure

no. Un’associazione può essere ricorsiva, nel senso che mette in relazione un’entità con se stessa.

Può essere di grado 3 o più (dove il grado è definito dal numero di entità coinvolte) e sono

indispensabili quando, volendo rappresentare il tutto con associazioni di grado 2, si otterrebbero

due associazioni M-N, rendendo impossibile il recupero di alcune informazioni. Con associazioni di

grado 3, invece, questo problema viene risolto. In generale, è consigliabile restare su associazioni

di grado 2, al più di grado 3. Andare oltre potrebbe essere sintomo di una cattiva modellazione

concettuale. Sul modello E/R è possibile esprimere alcuni vincoli, in particolare quelli di chiave

primaria. Una chiave primaria è un vincolo che permette di identificare in modo univoco una tupla

all’interno di una relazione. Da qui si introducono i concetti di Superchiave, che identifica quegli

insiemi di attributi che permettono di identificare una tupla (può contenere attributi superflui). Da

qui si può poi dare la definizione di chiave minimale, con cui si identificano quegli insiemi di

attributi strettamente necessari per identificare una tupla (se da una superchiave tolgo un attributo,

potrei comunque essere in grado di identificare la tupla; se ripeto lo stesso procedimento su una

chiave minimale, non godo più di questa proprietà). Una chiave candidata, invece, è una

superchiave che è anche minimale. La scelta della chiave primaria di una relazione verrà presa

sull’insieme di chiavi candidate. In generale, è preferibile scegliere come chiave primaria un

attributo che, oltre a godere della proprietà di chiave candidata, rappresenti una proprietà

“naturale” dell’entità, in modo da favorirne la portabilità in altri sistemi. Tuttavia, in alcuni casi

questo non è possibile ed è necessario ricorrere a chiavi artificiali, che però dovranno essere

inequivocabilmente rappresentate come sequenze. Esistono poi entità deboli, così definite perché

necessitano di un’entità forte per essere identificate. Infatti, questo particolare tipo di entità è

dotata di una chiave parziale che si completa con quella dell’entità forte. La “debolezza” di

un’entità è però relativa, in quanto all’interno di uno schema questa potrebbe essere forte, mentre

all’interno di un altro potrebbe essere debole. In un modello E/R, non è possibile esprimere vincoli

particolarmente complessi. Infatti, gli unici visibili sono quelli relativi alla chiave primaria e alla

totalità. All’interno di un modello E/R, però, ci sono dei limiti sulla rappresentazione. Per questa

ragione è stato introdotto una sua versione estesa (EE/R) che permette di rappresentare qualche

concetto in più. SPECIALIZZAZIONE: ereditarietà in OOP (utile quando le entità hanno molti

attributi in comune). GENERALIZZAZIONE: Una rappresentazione che prende a raccolta degli

attributi comuni a più entità. Al contrario della specializzazione, ciascuna di queste entità mantiene

la propria identità (=ogni entità ha la sua specifica chiave primaria). TIPO UNIONE = mi sono

capito.

Classificazione di vincoli: I vincoli che caratterizzano una base di dati sono suddivisibili in due

macro-categorie: vincoli statici e vincoli dinamici. I vincoli statici sono così chiamati poiché non

dipendono dal particolare stato in cui si trova la base di dati. Al contrario, quelli dinamici dipendono

dallo stato in cui si trova il DB. Alla categoria dei vincoli statici appartengono tutti quei vincoli che

possono essere controllati tramite clausola check, inserita al momento della creazione della

tabella. Il check, in particolare, è un vincolo di tupla che verifica che i valori inseriti rispettino il

dominio per cui sono stati pensati. Permettono di accertarsi che si inseriscano dati coerenti con

controlli relativamente semplici (=non troppo articolato). Alla categoria dei vincoli dinamici

appartengono i trigger. Si tratta di un particolare blocco di codice (in Oracle di PL/SQL) che, in

seguito a specifici eventi che avvengono sulla base di dati, viene eseguito. Permettono di

specificare vincoli di integrità anche molto complessi. Controllano l’integrità dei dati rispetto allo

stato specifico in cui si trova la base di dati. Da questo, è deducibile che un trigger è “agganciato”

ad una specifica tabella. Questo comporta anche una riduzione in termini computazionali,

riducendo quindi l’overhead. Un’altra tipologia di vincolo è data dalle asserzioni. Le asserzioni

rappresentano un vincolo dichiarativo. Con dichiarativo si intende che questo vincolo è in realtà

generico perché controlla l’esito di una query (classicamente una query con NOT EXISTS).

Quando si usano le asserzioni, bisogna stabilire ogni quanto questa deve essere eseguita (trattasi

di un problema non banale). Inoltre, al contrario dei trigger, non è specifico su alcuna tabella. Per

queste ragioni, il costo computazionale potrebbe essere non trascurabile, con evidenti problemi di

overhead. Infatti, in molti sistemi le asserzioni non sono neanche disponibili, prediligendo l’uso dei

trigger. I trigger, oltre ad essere vantaggiosi in termini computazionali, permettono anche una

migliore gestione delle eccezioni sollevate, permettendo anche di e