Appunti lezione Database del 07/10/2015

Transcript

1 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

2 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).

3 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.

4 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.

5 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

6 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:

7 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.

8 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.

9 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 adriano.alemanno@libero.it Gianluca Giannini gianlucagiannini1988@gmail.com