Schemi di Basi di dati

WITH

viene effettuata attraverso il costrutto .

asserzioni

Le sono un costrutto per definire vincoli generici a livello di schema. Consentono di

definire vincoli non altrimenti definibili con i costrutti visti fin qui e può essere immediato o differito

(ossia verificato al termine di una transazione).

Vengono create con il costrutto CREATE ASSERTION NomeAsserzione CHECK Condizione.

COSTRUTTI AVANZATI

Oltre a tutti costrutti visti fino ad adesso, esistono molti costrutti avanzati dipendenti dallo

specifico DBMS.

STORED PROCEDURES

Sono dei frammenti di codice SQL, con la possibilità di specificare un nome, dei parametri in

ingresso e dei valori di ritorno (similmente a delle funzioni o metodi).

È possibile richiamare la procedura al di fuori del DB, come in un terminale, attraverso il costrutto

CALL.

Le estensioni procedurali consentono di aggiungere strutture di controllo al linguaggio SQL (come

cicli, if-else, etc.), di dichiarare variabili e tipi di dato user-defined e definire procedure sui dati che

sono ritenute “sicure” dal DBMS.

Un modello DBMS che usa Stored

Procedure permette

all’applicazione esterna di

comunicare con il Database senza

utilizzare il linguaggio SQL ma

richiamando direttamente le

procedure (specificandone i

parametri).

Questo modello garantisce

maggiore efficienza, sicurezza ed

espressività.

TRIGGER

Sono dei meccanismi di gestione del DB basati sul paradigma ECA ovvero Evento -> Condizione

-> Azione, in genere vengono usati per “automatizzare” i database a svolgere determinate azioni

al verificarsi di un evento.

Occorre gestire nel modo appropriato ogni fase:

• Evento: insert, delete,

si inseriscono i costrutti primitivi per la manipolazione dei dati (

update)

• Condizione: si inserisce un predicato booleano da verificare

• Azione: si definiscono una sequenza di istruzioni SQL

PERMESSI

Sono dei meccanismi che controllano l’accesso alle risorse del DB, di norma infatti, ogni risorsa

privilegi:

appartiene all’utente che l’ha definita il quale possiede tutti i insert, update, delete,

select… GRANT

Il comando consente di assegnare i privilegi su una certa risorsa ad utenti specifici, la

scritta consente di propagare il privilegio ad altri utenti del sistema.

with grant option

REVOKE

il comando invece consente di revocare privilegi su una certa risorsa ad utenti specifici.

noSQL

Only SQL)

Il linguaggio NoSQL (Not comprende una vasta categoria di sistemi di gestione di

database che definiscono un’approccio alternativo al modello relazionale dei database SQL

tradizionali. Hanno principalmente due proprietà: di solito sono database distribuiti e sono open-

source.

I sistemi NoSQL si stanno diffondendo per 3 motivazioni principali:

- Diffusione dei Big-Data: Occorre trovare tecniche migliori per la gestione dei Big-Data. Con

big-data si denotano una famiglia di dati che si possono riconoscere attraverso la proprietà

delle 4V: Volume, Velocità, Varietà e Valore.

- Limitazioni del modello relazionale: il modello relazionale presenta diverse limitazioni:

1. Presuppone sempre implicitamente la presenza di dati strutturati in rappresentazione

tabellare.

2. Alcune operazioni non possono essere implementate in SQL (ad esempio la

memorizzazione di un grafo).

3. Scalabilità orizzontale, ovvero la capacità di aumentare le risorse di un sistema

distribuito aggiungendo nuovi nodi o server al sistema anziché aumentare le risorse di

un singolo nodo. In altre parole, consiste nell'espandere la capacità di un sistema

distribuito sistemando il carico su più dispositivi, piuttosto che migliorare le prestazioni

di un singolo dispositivo.

- Teorema CAP: è un teorema recente che afferma che un sistema distribuito può soddisfare al

massimo solo due di queste proprietà:

Consistency = tutti i nodi della rete vedono gli stessi dati (ovvero se l’utente A modifica

• il dato X sul server 1, e B legge X dal server 2, B legge l’ultima versione disponibile di

X).

Availability = il servizio è sempre disponibile (ovvero se un utente effettua una query sul

• server A o B, la query restituisce un risultato).

Partion Tolerance = il servizio continua a funzionare correttamente anche in presenza di

• perdita di messaggi o di partizionamenti della rete.

Il sistema distribuito non funziona correttamente con nessuna delle combinazioni di due di

queste proprietà.

Le proprietà base di un DBMS NoSQL sono:

• Basically Available: I nodi del sistema distribuito possono essere soggetti a guasti, ma il

servizio è sempre disponibile.

• Soft State: La consistenza dei dati non è garantita in ogni istante.

• Eventually Consistent: Il sistema diventa consistente dopo un certo intervallo di tempo, se le

attività di modifica dei dati cessano. MongoDB,

L’esempio di Database non relazionale che vediamo è in cui non valgono i principi

visti fino ad ora per i database relazionali (chiave primaria, chiave esterna….).

collezioni documenti

MongoDB è strutturato in (tabelle); le collezioni contengono liste di (righe),

campi

e ogni documento è un insieme di (colonne).

Per interfacciassi con l’utente, MongoDB utilizza linguaggio JSON. I documenti JSON sono

facilmente interpretabili da macchine e serve a fare da “tramite” tra due software (ne aumenta la

interoperabilità). chiave : valore.

I dati di un documento JSON sono racchiusi tra {} e assumono la forma:

PROGETTAZIONE DI BASI DI

DATI

Il ciclo di vita di un sistema informativo perdere diverse fasi:

Fino ad ora abbiamo visto come implementare una base di

dati in SQL partendo da uno schema relazionale già

IMPLEMENTAZIONE

definito. (Fase studiata nel capitolo

precedente).

Vediamo ora come si dovrebbe procedere nella fase

realizzazione da zero di un nuovo sistema informativo, (Fase

RACCOLTA/ANALISI REQUISITI + PROGETTAZIONE

esaminata in questo capitolo).

In questo caso, partire direttamente con l’implementazione delle tabelle SQL può essere

problemi

complesso se non impossibile. Ci sono diversi che dobbiamo considerare:

1) Il dimensionamento del DB di un sistema informativo di medie dimensioni può comprendere

decine di tabelle.

2) Capire le richieste dei clienti è un processo solo apparentemente semplice, bisogna fare

un’analisi dei requisiti per comprendere quali sono le specifiche, quali sono i dati e quali sono

le operazioni sui dati.

3) La traduzione nel modello logico, ovvero passare da una specifica informale dei dati ad uno

schema logico, può far emergere diverse anomalie ed errori.

Esistono quindi delle metodologie consolidate per progettare una “buona” base di dati partendo

raccolta/analisi dei requisiti.

dalla

Questa fase consiste nella completa individuazione dei problemi che il sistema informativo da

realizzare deve risolvere e le caratteristiche che il sistema software deve avere.

Le fonti di questa fase sono:

• Utenti dell’applicazione:

- Interviste con i committenti.

- Documentazione scritta.

• Documentazione esistente

- Normative esistenti

- Procedure aziendali

- Regolamenti interni

• Realizzazioni/applicazioni preesistenti

progettazione

Successivamente la metodologia di viene divisa su 3 fasi in cui ogni si produce

una rappresentazione della base di dati attraverso uno schema:

progettazione concettuale

Nella fase di ci si focalizza sul contenuto informativo dei dati ad alto

livello di astrazione, senza focalizzarsi sull’implementazione nel modello logico di riferimento.

modello concettuale:

In output, si produce un che è indipendente dallo schema logico ed

indipendente dal DBMS in uso.

L’utilità della progettazione concettuale è:

- Creare un’astrazione completa dei dati da rappresentare.

- Capire le dipendenze concettuali tra i dati del modello.

- Fornire una documentazione della base di datiIl modello concettuale prodotto può essere

rappresentato in diverse modi (modello entità-relazione, il modello UML…).

progettazione logica

Nella fase di si rappresenta la base di dati nello schema logico del DMBS

(nel nostro caso, nel modello relazionale).

La progettazione logica comprende i seguenti passaggi:

1) Traduzione dello schema concettuale

2) Ottimizzazione dello schema logico ottenuto

3) Rimozione delle ridondanze (normalizzazione)

4) Analisi delle prestazioni

progettazione fisica

Nella fase di si descrivono le strutture per la memorizzazione dei dati su

memoria secondaria, e l’accesso (efficiente) ai dati.

MODELLO E-R

Il Modello Entità-Relazione è un modello per la rappresentazione concettuale dei dati ad alto

livello di astrazione ed è basato su rappresentazione grafica (diagramma). È utile per modellare i

dati di interesse e per essere usato come documentazione di un DB.

Inoltre, il Modello ER è indipendente dal modello logico in uso e dal DBMS di riferimento. (Ciò

significa che il diagramma ER può essere applicato con successo indipendentemente dal

contesto specifico in cui viene implementato il database.)

Le componenti di un diagramma E-R sono:

- Entità

- Relazioni

- Attributi

- Cardinalità Identificatori

delle relazioni, degli attributi e

- Generalizzazioni

Entità

Un’entità è una classe di oggetti (fatti, persone, cose) della realtà di interesse con proprietà

comuni e con esistenza autonoma. Ad ogni entità è associato un nome (al singolare), che

identifica l’oggetto rappresentato.

Graficamente, un’entità viene rappresentata attraverso un rettangolo (con nome dell’entità al

centro).

In prima approssimazione, un’entità può essere tradotta in una tabella (del modello relazionale), di

cui però non è ancora definito lo schema.

Relazione

Una relazione è un legame logico fra due o più entità del sistema che si sta modellando. Gli è

associato un nome, che la identifica nello schema.

Graficamente, una relazione viene rappresentata attraverso un rombo collegato ad entità (anche

più di due).

L’istanza di una relazione è una combinazione di istanze dell’entità che prendono parte

all’associazione.

Es. La coppia (c,d) è un’istanza della relazione Lavoro, dove c è un’istanza di Impiegato, e d è

un’istanza di Dipartimento.

In generale, una relazione può coinvolgere un numero arbitrario di entità (relazioni n-arie).

relazione ricorsiva.