CORSO DI DATABASE
A.A 2015/2016
Prof. Mario Bochicchio
APPUNTI DEL GIORNO 30/09/2015
Sommario
RAPPRESENTAZIONE INTENSIONALE E ESTENSIONALE: ...............................................................2
RELAZIONI N-ARIE ......................................................................................................................3
RELAZIONE TERNARIA ........................................................................................................................ 3
REIFICAZIONE..................................................................................................................................... 4
CARDINALITA’ DELLA RELAZIONE TERNARIA ....................................................................................... 5
DESIGN PATTERN PER APPLICAZIONI DATA-CENTRIC ..................................................................8
PRESENTATION LAYER ........................................................................................................................ 8
BUSINESS RULES ................................................................................................................................ 9
VALIDATORE.............................................................................................................................................. 9
FSM (Macchina a stati finiti) ................................................................................................................... 10
PATTERN DATA-LAYER...................................................................................................................... 10
Angelo Quarta
[email protected]
Omar De Mitri
[email protected]
RAPPRESENTAZIONE INTENSIONALE E ESTENSIONALE:
Considerando un generico problema esso è rappresentabile dal punto di vista intensionale o
estensionale.
Un esempio di rappresentazione intensionale è il modello E-R:
Figura 1
dove A e B sono le Entità ed R la relazione tra A e B.
La rappresentazione estensionale può essere schematizzata attraverso diagrammi di Venn:
Figura 2
dove apA e bqB e l’elemento ri={ap,bq} rappresenta la singola istanza della relazione che lega ap
con bq.
Un database contiene diversi tipi di informazione e la quantità di esse, nella rappresentazione
estensionale, è misurata dalla quantità di dati contenuti nel database mentre la rappresentazione
intensionale è meta-informazione, cioè informazione sull’informazione contenuta nel diagramma.
Ad esempio, come si vede nel diagramma sottostante, l’aggiunta di una relazione nella
rappresentazione intensionale comporta l’aggiunta di un ulteriore insieme nella rappresentazione
estensionale e quindi un aumento di informazione.
2
Figura 3
RELAZIONI N-ARIE
Vengono chiamate relazioni N-arie delle relazioni in cui le entità partecipanti sono N.
Un caso particolare di tali relazioni è la relazione ternaria.
RELAZIONE TERNARIA
Il modello in figura 4 rappresenta una relazione ternaria tra le entità PARTE,FORNITORE e
PROGETTO.
Figura 4
FORNITORE fornisce PARTE relativa a PROGETTO
In questo caso, la relazione FORNIRE in rappresentazione estensionale sarà la terna delle istanze
delle entità coinvolte nella relazione.
3
E’ possibile dimostrare che la quantità di informazione contenuta all’interno di una relazione
ternaria è maggiore rispetto a quella contenuta in 3 relazioni binarie del tipo:
(1.5)
Figura 5
La differenza fondamentale tra i due diagrammi è legata alla tracciabilità della parte. Mentre nel
diagramma rappresentante la relazione ternaria si può stabilire il fornitore relativo alla singola
parte impiegata in un progetto, nel diagramma contenente le tre relazioni binarie ciò non è
possibile.
REIFICAZIONE
Viene chiamata REIFICAZIONE il processo che permette di trasformare una relazione in un entità.
Nel caso in esame:
Figura 6
utilizzando il concetto di FORNITURA abbiamo trasformato il tipo di relazione in un tipo di entità.
In questo modo troviamo tutta l’informazione contenuta nella ternaria con l’aggiunta di quella
relativa all’insieme di oggetti che costituiscono la singola fornitura.
4
CARDINALITA’ DELLA RELAZIONE TERNARIA
Nell’esempio portato avanti finora è stata omessa la cardinalità. Essa, per una relazione ternaria è
stabilita eliminando a turno un’entità e fissandola cardinalità della relazione rimanente.
Nel caso specifico:
- Eliminando l’entità PROGETTO, quante coppie (PARTE, FORNITORE) vedo?
Figura 7
-
(1.7a)
Eliminando l’entità PARTE, quante coppie (FORNITORE, PROGETTO) vedo?
Figura 8
5
-
Eliminando l’entità FORNITORE, quante coppie(PARTE,PROGETTO) vedo?
Figura 9
si ottiene quindi il diagramma E-R seguente completo delle cardinalità associate ad ogni relazione:
Figura 10
Reificando la relazione ternaria, supponendo di contenere lo stesso contenuto di informazione del
diagramma precedente abbiamo:
6
Figura 11
Come accennato precedentemente, la reificazione potrebbe consentire una rappresentazione
contenente maggiori informazioni rispetto a quelle contenute nella relazione ternaria.
Ipotizzando, nel modello considerato, di voler gestire forniture contenenti più parti, le
informazioni contenute nella relazione ternaria non sono sufficienti a stabilire quante parti sono
state acquistate in relazione ad un'unica fornitura. Ciò è possibile invece, nel modello con
relazione reificata, prevedendo una relazione tra PARTE e FORNITURA con cardinalità P:Q.
(1.9b)
Figura 12
7
DESIGN PATTERN PER APPLICAZIONI DATA-CENTRIC
Viene chiamato Design pattern una soluzione usualmente utilizzata per la risoluzione di problemi
ricorrenti.
Nelle applicazioni data-centric, i design pattern aiutano a ridurre errori legati alla progettazione.
Considerando il modello standard di architettura a 3 livelli:
(2.0)
Figura 13
in ogni livello è possibile evidenziare problematiche ricorrenti che richiedono design pattern
appropriati.
(2.2)
Figura 14
PRESENTATION LAYER
Nelle applicazioni odierne viene utilizzata un interfaccia navigazionale che può essere
schematizzata attraverso una struttura ad albero detta “albero di navigazione” contenenti le unità
macroscopiche di informazione cioè le pagine su cui è possibile navigare.
8
Figura 15
All’interno di esse sono presenti oggetti informativi detti WIDGET.
La navigazione può essere suddivisa in due categorie:
- “In-The-Large” (ITL): relativa ad albero di navigazione
- “In-The-Small” (ITS): relativa a pagina e widget
Gli oggetti informativi possono presentarsi come:
- Vista Elenco
- Vista di dettaglio
Ognuno di essi possiede dei metodi di interazione che li contraddistinguono.
I metodi di gestione dell’elenco sono ad esempio pagginatore, filtraggio, ricerca, ordinamento,
acceleratore, ecc.. Di particolare rilievo sono i metodi CRUD: CREATE (per copia1), UPDATE ( solo
per cambiamenti massivi), DELETE2.
Nella vista di dettaglio sono utilizzati meccanismi di navigazione ITS e metodi CRUD nella loro
accezione più classica: CREATE (from scratch), READ , UPDATE, DELETE (logica).
BUSINESS RULES
A livello di business rules, i due pattern più utilizzati sono i VALIDATORI e le FSM(macchine a stati
finiti).
VALIDATORE
Vengono chiamati VALIDATORI delle regole di business che ci consentono di capire se un dato
appartiene o meno ad un dato dominio.
Esistono tre tipi di validatori:
- LOCALE: Regola che discrimina i dati ammissibili.
- GLOBALE: Regola che discrimina l’ammissibilità di un dato in relazione ad altri dati
correlati. Esso richiede una query per la validazione del criterio di scelta.
- PAGINA: Organizza i messaggi provenienti dai validatori di tipo locale e globale.
1
Esistono due tipi di creazione: FROM SCRATCH (ex-novo) e PER COPIA. Nel primo viene creato un
oggetto vuoto, nel secondo viene effettuata una copia di un oggetto esistente e modificato
opportunamente
2 Esistono due tipi di cancellazione: CANCELLAZIONE LOGICA e CANCELLAZIONE FISICA. Nella
prima, l’oggetto non è visualizzato ma permane nel database, nel secondo l’oggetto viene
fisicamente cancellato dal database. Nella progettazione di una base di dati E’ BUONA NORMA
EFFETTUARE SOLO CANCELLAZIONI LOGICHE.
9
FSM (Macchina a stati finiti)
Ci permette di scrivere in maniera atemporale i possibili stati in cui può trovarsi l’applicazione
progettata.
Figura 16
PATTERN DATA-LAYER
Nella modellazione di una base di dati ci sono due approcci differenti per affrontare il medesimo
problema. E’ possibile studiare lo specifico dominio applicativo oppure utilizzare un dominio
applicativo più ampio che permette di evidenziare alcune caratteristiche comuni. Ad esempio, nel
caso in cui si dovesse progettare una base di dati per una banca, si potrebbe studiare il contesto
singolarmente oppure ricondursi al fatto che in generale le applicazioni di Industria e commercio
effettuano principalmente la vendita di prodotti o vendita di servizi.
Figura 17
Figura 18
10
