Appunti lezione Database del 07/10/2015

Appunti lezione Database del 07/10/2015
Nelle lezioni precedenti si è visto come qualunque applicazione informativa è almeno formata da
tre livelli o layers che ogni progettista conosce e sa gestire:
•
•
•
Livello visuale o Presentation Layer
Livello logico o Business-Logic Layer
Livello dei dati o Persistence Layer
Abbiamo visto come il Presentation Layer si occupa di gestire gli input dell’utente e fornire un
output visuale allo stesso. Il Business-Logic Layer invece esegue le necessarie trasformazioni sui
dati da visualizzare all’utente e di conseguenza ingloba gli algoritmi che sono alla base del
funzionamento di un software. Il Persistence Layer si occupa di assicurare che i dati vengano
salvati su un dispositivo di storage.
Ricordando che lo scopo primario del Presentation Layer è quello di esporre i dati nella maniera più
efficace possibile, un widget, ovvero un componente grafico di una interfaccia utente con scopo di
facilitare all'utente l'interazione con il programma stesso, spesso utilizzato è il master-detail.
In computer user interface design,
un’interfaccia master–detail è la
fusione di una vista elenco e di
dettaglio.
Tale widget può essere utilizzato
nella sua versione base o in una
forma gerarchica a più livelli, una
sorta di Master-Master-detail.
Tra le librerie di widget più
importanti si ricordano: QT
(multipiattaforma), JQUERY.UI e
DHTML.
A livello Business-Rule in generale si utilizzano dei formalismi per modellare ad alto livello le
azioni in un’azienda. Un esempio è la notazione BPMN.
La notazione BPMN, acronimo per “Business Process Management Notation” ha come obiettivo
fornire uno standard di rappresentazione efficace facile da utilizzare e da comprendere da parte
degli utenti business interessati al problema della modellazione, progettazione ed eventuale
informatizzazione dei processi aziendali: analisti di processo che costruiscono le bozze iniziali dei
processi organizzativi in esame o da progettare, programmatori e sviluppatori delle applicazioni
informatiche per la gestione di tali processi, e infine manager e dirigenti responsabili della gestione
e del monitoraggio dei processi stessi. La BPMN è sostanzialmente una derivazione del formalismo
dei flow chart ma con alcune aggiunte e modificazioni che permettono di superarne alcuni limiti
nella modellazione dei processi aziendali. Permette di costruire dei diagrammi di processo (BPD –
Business Process Diagram) che rappresentano in pratica dei grafi o reti costituiti da “oggetti”
rappresentati dalle attività di processo, collegati da flussi di controllo che definiscono la relazione
logica, le dipendenze e l’ordine di esecuzione delle attività stesse.
La BPMN consente spesso una stretta integrazione con i sistemi di sviluppo software. Sono infatti
disponibili applicazioni che consentono al modellista di rappresentare i dettagli di un processo
tramite BPMN e traducono poi tale modello in programmi sofware per la gestione del processo
stesso, consentendo di simulare ed “animare” il processo.
La notazione è ricca e complessa ma gli elementi chiave sono i seguenti:
Le quattro categorie fondamentali di
elementi grafici sono le seguenti:
•
•
•
•
Elementi di flusso (flow object)
Connettori (connecting object)
Corsie (swimlane)
Artefatti(artifact)
Un esempio di processo è quello di una richiesta da parte di uno studente di un certificato di laurea presso lo sportello della segreteria della sua Università Anche a livello dati vi sono dei design pattern, delle soluzioni ricorrenti a problemi di
progettazione.
L’utilizzo dei design pattern permette di facilitare la realizzazione delle componenti standard di un
database, ottenendo un database generico da “customizzare” in una fase successiva al fine di
ottenere un prodotto ritagliato sulle esigenze del cliente oppure per realizzare un prodotto
competitivo sul mercato (competive edge).
I principali DP che si presentano nel Data Engineering sono:
• Business Type
• Archiviazione
• Preventivo-consuntivo
• Catena di attributi
• Storicizzazione
• Oggetto / tipo di oggetto
1) Business Type
Qualsiasi tipo di attività o azienda può essere sempre incasellata in due tipi di macro-categorie.
Bisogna chiedersi, nel contesto in cui ci si trova, se l’entità di interesse è un prodotto o un servizio.
Questo tipo di struttura definisce lo scheletro elementare di ogni database.
2) Archiviazione
Un pattern di archiviazione consente agli utenti di un DB di accedere alle informazioni necessarie
tanto più agevolmente quanto più i dati risultano essere vicini all’attuale interesse dell’utente.
Un esempio è quello del gestore di mail: in questo caso l’utente che accede alla propria casella di
posta, generalmente, ha interesse a visualizzare le mail più recenti.
Un altro esempio significativo è l'organizzazione degli articoli sul sito web di una testata
giornalistica: all'utente che visita la pagina vengono mostrate inizialmente le notizie del giorno, solo
successivamente vengono presentate altre notizie che possono comunque essere di interessi ma che
risultano essere meno recenti. Questo pattern, utilizzato nella realizzazione di database molto popolati, ha lo scopo di raggruppare
e organizzare le informazioni in categorie, dove ogni categoria è più o meno vicina agli interessi
dell'utente. Si raggruppano più informazioni, che risultano lontane nel tempo, andando a rendere
noti minor dettagli per queste.
Un’estensione è l’archiviazione gerarchica: nell’esempio del gestore mail, i messaggi ricevuti si
possono raggruppare per "ultima settimana", "ultimo mese", "ultimo anno". In questo modo si
costruisce una gerarchia degli archivi che permette di avere un criterio chiaro di classificazione dei
messaggi.
3) Preventivo-consuntivo Questo Design Pattern può essere utilizzato ogni qualvolta una determinata azione può essere
scomposta in due fasi distinte. Supponiamo ad esempio che un persona voglia affittare una camera;
questa operazione in realtà è suddivisa in 2 fasi distinte: in una prima fase la camera viene prenotata
ma solo in una seconda fase la camera sarà occupata.
Esistono quindi due relazioni che legano le stesse entità e che hanno scopi diversi.
Le due fasi prendono i nomi di preventivo (ovvero la fase iniziale in cui ci prepariamo allo
svolgimento di un'azione, ad es. "cliente prenota camera") e consuntivo (ovvero la fase in cui
l'azione preventivata iene effettivamente svolta, ad es. "cliente occupa stanza") 4) Catena di attributi Si prenda in considerazione il seguente esempio. Un prodotto P viene realizzato da un fornitore per essere venduto ad un cliente. Il proprietario di un
negozio deve quindi interessarsi dell'acquisto del prodotto dal fornitore e della vendita al cliente.
Ma qual è il prezzo del prodotto? E come si può tener conto di eventuali variazioni del prezzo? Il prezzo non può essere descritto solo come singolo attributo del prodotto, perché ad esempio ho
bisogno di avere informazioni sul prezzo di acquisto dal fornitore e sul prezzo di vendita al cliente,
eventuali sconti applicati ecc. In questo caso quindi non ho un singolo prezzo ma piuttosto una
catena di prezzi. Tale attributo si propaga nel database, dando così origine ad una catena di attributi, ed assume
generalmente significati diversi (nell'esempio sopra citato si parla sempre di "prezzo del prodotto",
ma a seconda di dove ritroviamo questo attributo, esso farà riferimento a "prezzo di acquisto",
"prezzo di listino" o "prezzo di vendita") 5) Storicizzazione
Come si gestisce la necessità di cambiare il valore di uno o più attributi nel tempo? Ovviamente non
è possibile sostituire semplicemente il vecchio valore con quello nuovo perché si perderebbero
definitivamente le precedenti informazioni e tale pratica andrebbe generalmente evitata. La Storicizzazione è il Design Pattern adatto a gestire questo aspetto dinamico dei database.
Tenendo conto del fatto che all'interno di un Database qualsiasi valore potrebbe cambiare, tranne lo
schema stesso del DB in quanto statico statico, possono presentarsi problemi di:
• storicizzazione di attributi, in cui una possibile soluzione è quella di trasformare ogni
attributo dinamico in un'entità; • storicizzazione di un'entità, una cui possibile soluzione è quella di
aggiungere una relazione ricorsiva all'entità da storicizzare; in questo
modo ottengo una lista di variazioni in cui tutte le istanze
rappresentano uno stesso oggetto, ma solo un elemento della lista
sarà effettivamente "attivo" nel DB; •
storicizzazione di relazioni, la soluzione più comune in questo caso è la reificazione della
relazione, successivamente la nuova entità viene storicizzata come nel punto precedente. 6) Oggetto / Tipo di oggetto
In alcuni casi bisogna fare attenzione a cosa vogliamo associare ad una specifica entità del database.
È necessario quindi fare una distinzione tra gli oggetti e i tipi di oggetto: la differenza è
nell'individualità di un prodotto. Ci sono oggetti che hanno delle caratteristiche che li rendono diversi dal tipo di oggetto (es. targhe
delle auto), quindi questa seconda soluzione va bene per un prodotto ben definito (auto, case),
mentre nel caso di un supermercato in cui si vendono diversi prodotti è l’entità di interesse è il tipo
di oggetto.
ALGORITMO DI MAPPIG SEMPLIFICATO
L’algoritmo di mapping semplificato definisce i passaggi fondamentali per la traduzione di uno
schema ER in un modello relazionale (ER àMR). In particolare prenderemo in considerazione
l’algoritmo di mapping semplificato nel quale:
•
•
Ogni tipo di entità da origine a una tabella (relazione)
Ogni tipo di relazione da origine a una tabella (relazione)
Prendiamo in esame il seguente modello ER per esaminare alcuni casi particolari.
Nel tradurre i tipi di associazione possiamo ritrovarci in tre differenti casi:
• ASSOCIAZIONE DI TIPO M:N - l’entità cliente e l’entità prodotto danno luogo a due
tabelle (tabella cliente, tabella prodotto) contenenti tante colonne quanti sono gli attributi di
ognuna. Il tipo di relazione dà luogo a una tabella, in cui sono inserite le chiavi esterne che si
riferiscono alle chiavi primarie di cliente e prodotto, oltre agli eventuali attributi della relazione
acquista.
• ASSOCIAZIONE DI TIPO 1:N - Se si scegliesse di procedere come nel punto precedente
si avrebbero anche in questo caso tre differenti tabelle. Si osservi però che nella relazione
“acquista” si avrebbe lo stesso numero di righe della tabella prodotto in quanto ogni prodotto viene
acquistato da un cliente, ma non è detto che ogni cliente abbia acquistato un prodotto. È possibile
quindi rivedere il “mapping” eliminando la tabella “acquista” e aggiungendo una colonna nella
tabella prodotto, contenente una chiave esterna che fa riferimento al cliente che ha acquistato
ciascun prodotto.
• ASSOCIAZIONE DI TIPO 1:1 – Per questo tipo di associazione faremo riferimento a
questo diagramma ER.
Anche in questo caso ogni entità dà luogo a una tabella. Per quanto riguarda le relazioni invece, è
possibile decidere di aggiungere una colonna di chiave esterna o nella tabella a destra della
relazione o in quella nella sua sinistra. La scelta più opportuna è quella di inserire la colonna di
chiave esterna nella tabella che consente di avere il minor numero di NULL. In alternativa, nel caso
in cui le due tabelle abbiano la stessa cardinalità, possiamo creare un'unica tabella.
Come visto nelle lezioni precedenti, la progettazione di un database avviene su tre livelli
denominati LIVELLO CONCETTUALE, LIVELLO LOGICO e LIVELLO FISICO.
Per ogni livello si costruisce un MODELLO che contiene le informazioni da rappresentare e che è
rivolto agli attori che partecipa alla progettazione. Nello specifico, si ha che il MODELLO
CONCETTUALE, data la sua essenza molto “vicina all’utente”, è rivolto al COMMITTENTE, il
MODELLO LOGICO è rivolto agli IMPLEMENTATORI e, infine, il MODELLO FISICO è una
RAPPRESENTAZIONE 1:1 della realizzazione finale.
Il Diagramma E/R (Entità/Relazioni) è una prima rappresentazione del livello concettuale e
permette di disegnare in maniera semplice delle strutture dati anche molto complesse, come ad
esempio quelle ricorsive (che permettono di rappresentare semplicemente costrutti come la
SEQUENZA, l’ALBERO e la FORESTA, dispendiose in termini di risorse e righe di codice da
implementare con un linguaggio di programmazione).
La rappresentazione del livello logico, invece, si basa su una teoria nota come ALGEBRA
RELAZIONALE; tale tipo di algebra permette di definire delle “espressioni” che vanno a
rappresentare le INTERROGAZIONI che è possibile effettuare su un database, ossia le operazioni
che consentono di estrarre da un database determinate informazioni di interesse e che vanno poi
tradotte in SQL, il linguaggio di programmazione che opera sui database.
Adriano Alemanno
[email protected]
Gianluca Giannini
[email protected]