Soluzione esame scritto di Basi di Dati I, CdL in ...mb.unisalento.it/Basi di Dati I 2008-2009/Allegati/licenze asp 5... · Revisione della traccia di esame di Basi di Dati I, 11/02/2003

Revisione della traccia di esame di Basi di Dati I, 11/02/2003Vincenzo Masciullo (matr.: 10035815), Giacomo Russo (matr.: 10041804)

Soluzione esame scritto di Basi di Dati I, CdL in Ingegneria dell'Informazione

Prova di ammissione al Progetto del 11/02/2003Prof. Mario A. Bochicchio

Una società che fornisce accesso ad applicativi software in modalità ASP (Application Service Provider) via Web vuole realizzare un'applicazione per gestire le licenze d'uso dei propri applicativi e monitorare l'uso delle stesse nel tempo.

Una licenza d'uso è di fatto il permesso per un dato utente (cliente dell'ASP) di accedere e utilizzare alcuni dei software messi a disposizione dell'ASP per determinati periodi di tempo, a fronte del pagamento di un canone mensile o annuale, variabile in funzione del software scelto.

Ai clienti è data anche la possibilità di acquistare la licenza di accesso a un pacchetto di applicativi. In questo caso pagheranno un canone vantaggioso per l'intero pacchetto (mensile o annuale), e potranno avere accesso a tutte le applicazioni incluse nel pacchetto per il periodo scelto.

L'applicazione che si vuole realizzare, oltre ad occuparsi del controllo della validità dei permessi di accesso per un dato utente ad un dato software, si occuperà di memorizzare nel database informazioni che consentano la costruzione di statistiche di uso e di profitto dei vari software dell'ASP.

Facendo le ipotesi ritenute opportune e commentando sinteticamente quanto si scrive, si svolgano i seguenti punti:

1. Si descriva con un diagramma E-R lo schema concettuale di una base di dati a supporto di una tale applicazione.

2. Si costruisca uno schema logico relazionale per la base di dati di cui al punto 1.

3. Si esprimano in linguaggio SQL o mediante l'algebra relazionale le seguenti interrogazioni sullo schema relazionale ricavato al punto 2:

a) Trovare l'elenco dei clienti che hanno o hanno avuto il permesso di accedere a una determinata applicazione;

b) Trovare l'elenco dei clienti che hanno avuto il permesso di accedere ad una data applicazione ma non lo hanno mai sfruttato;

c) Trovare l'applicativo che in un dato anno ha fruttato di più per l'ASP.

Tempo a disposizione: 1,5 ore. È consentita la consultazione di libri e dei propri appunti.

- 1 -


Commenti, integrazioni ed osservazioni sulla traccia

La traccia, al momento della sua consegna in sede d'esame, è stata completata aggiungendo alla query c la precisazione:

Si considerino solo la vendita di applicativi singoli.

Si sono fatte inoltre delle assunzioni per quanto concerne la modellazione concettuale:

● Si ritiene opportuno modellare la realtà richiesta usufruendo dei costrutti dei diagrammi EER, che permettono di rappresentare in modo più fedele i vari elementi informativi presenti nel mini-mondo.

● In fase di progetto è utile distinguere tra clienti privati ed azienda che accedono alla piattaforma ASP, in quanto spesso le aziende sfruttano tali servizi per richiedere licenze multiple di applicativi di interesse. Ogni azienda è rappresentata, per ogni pacchetto di licenze acquistato, da un privato, ovvero da un consulente interno o esterno dell'azienda che si preoccupa di acquistare il software per conto di essa.

● Per rappresentare le informazioni utili a costruire le statistiche di uso, si sono incluse delle informazioni per ogni coppia cliente-programma a cui accede, memorizzando la data del primo e dell'ultimo accesso, nonché il numero degli accessi effettuati fino a quel momento.

● Per ogni applicativo si memorizzeranno l'ammontare del canone mensile e annuale, e lo stesso si farà per i pacchetti (in questo modo il venditore potrà fissare a piacimento il canone “vantaggioso”). Inoltre si memorizzerà il tipo di canone della licenza (mensile/annuale) e la sua durata (in mensilità o annualità, a seconda del tipo di licenza).

● Inoltre si suppone che la licenza a canone mensile non superi i 12 mesi (a quel punto infatti si stipulerebbero un certo numero di licenze a canone annuale e un certo numero di licenze a canone mensile in modo che il programma sia disponibile per l'accesso per il periodo desiderato dal cliente). Si assume inoltre che il profitto di un applicativo o un pacchetto per un dato anno, in caso di licenza con canone mensile, sia attribuito interamente all'anno in cui inizia a valere la licenza, anche nel caso in cui vi siano mesi che appartengono all'anno successivo (si considera il denaro da incassare per la licenza interamente come profitto per l'anno in cui è stipulata).

- 2 -


Svolgimento corretto

Modellazione ER/EER:

Il diagramma EER che rappresenta la realtà descritta è:

Si è scelto di coinvolgere i tipi di entità PRIVATO e AZIENDA in una Union type CLIENTE (che conterrà le credenziali di accesso al sistema), senza applicare la generalizzazione, in quanto si tratta di oggetti simili in rapporto al servizio che viene offerto loro, ma informativamente distinti (ad esempio i loro attributi chiave primaria sono diversi).

Inoltre si è deciso di generalizzare APPLICATIVO e PACCHETTO in quanto si è notato che partecipano, per la maggior parte, alle stesse relazioni, inoltre hanno molti attributi in comune, come ad esempio un canone mensile ed un canone annuale.

L'attributo Durata di LICENZA contiene il numero di mensilità/annualità, a seconda del valore dell'attributo Tipo_canone (se il canone è a scadenza mensile allora è memorizzato il valore 0, altrimenti se il canone è a scadenza annuale è memorizzato il valore 1).

Un'entità pacchetto partecipa alla relazione CONTENUTO_IN al minimo 2 volte, al massimo N volte, poiché si assume che un pacchetto contenga minimo due applicativi.

- 3 -


Modello relazionale:

Nella relazione RAPPRESENTA si è ritenuto opportuno definire come chiave primaria il solo attributo No_Seriale, invece della terna (Cod_Fiscale, P_IVA, No_Seriale), perché da solo è sufficiente ad identificare le tuple nella relazione.

- 4 -


Query SQL:

Si assume che al posto di Nome applicazione e Anno si inseriscano rispettivamente il nome dell'applicazione e l'anno da considerare per interrogare il database.

a) SELECT DISTINCT L.ID_ClienteFROM LICENZA AS LWHERE L.Nome_Prodotto = 'Nome applicazione'

OR L.Nome_Prodotto IN (SELECT Nome_Pacchetto FROM CONTENUTO_IN WHERE Nome_Applicativo = 'Nome applicazione');

Questa query seleziona i diversi (DISTINCT, così da non ottenere ripetizioni) ID_Cliente dalla relazione LICENZA che corrispondono a licenze che come nome del prodotto licenziato hanno il nome dell'applicazione desiderata oppure il nome di un pacchetto che la contiene.In alternativa è possibile riformulare la query usando gli operatori insiemistici dell'SQL:

(SELECT DISTINCT L.ID_ClienteFROM LICENZA AS LWHERE L.Nome_Prodotto = 'Nome applicazione')UNION(SELECT DISTINCT L.ID_ClienteFROM LICENZA AS L, PRODOTTO AS PRO, PACCHETTO AS PAC, CONTENUTO_IN AS CIWHERE L.Nome_Prodotto = PRO.Nome_Prodotto

AND PRO.Nome_Prodotto = PAC.Nome_PacchettoAND PAC.Nome_Pacchetto = CI.Nome_PacchettoAND CI.Nome_Applicativo = 'Nome applicazione');

Dove la query è l'unione fra gli insieme dei clienti a cui appartiene una licenza della data applicazione e l'insieme dei clienti a cui appartiene una licenza di un pacchetto contenente tale applicazione.

b) SELECT DISTINCT L.ID_ClienteFROM LICENZA AS LWHERE (L.Nome_Prodotto = 'Nome applicazione'

OR L.Nome_Prodotto IN (SELECT Nome_Pacchetto FROM CONTENUTO_IN WHERE Nome_Applicativo = 'Nome applicazione'))

AND NOT EXISTS (SELECT * FROM ACCEDE_A AS A WHERE A.ID_Cliente = L.ID_Cliente

AND A.Nome_Applicativo = 'Nome applicazione');

Questa query seleziona gli stessi ID_Cliente del caso precedente, con la condizione che non esista una tupla nella relazione ACCEDE_A che indichi che il cliente ha fatto accesso a tale applicazione.In alternativa, usando gli operatori insiemistici dell'SQL:

((SELECT DISTINCT L.ID_ClienteFROM LICENZA AS LWHERE L.Nome_Prodotto = 'Nome applicazione')UNION(SELECT DISTINCT L.ID_Cliente

- 5 -


FROM LICENZA AS L, PRODOTTO AS PRO, PACCHETTO AS PAC, CONTENUTO_IN AS CIWHERE L.Nome_Prodotto = PRO.Nome_Prodotto

AND PRO.Nome_Prodotto = PAC.Nome_PacchettoAND PAC.Nome_Pacchetto = CI.Nome_PacchettoAND CI.Nome_Applicativo = 'Nome applicazione'))

EXCEPT(SELECT DISTINCT A.ID_Cliente FROM ACCEDE_A AS AWHERE Nome = 'Nome applicazione');

La query è simile alla precedente versione con operatori insiemistici, tranne che al risultato dell'unione sono sottratti (in senso insiemistico) gli elementi dell'insieme dei clienti che hanno avuto accesso all'applicativo di interesse.

c) SELECT TOP 1 A.Nome_Applicativo, SUM(L.Durata * L.Quantità * (P.Prezzo_mensile * (1 – L.Tipo_canone) + P.Prezzo_annuale * L.Tipo_canone)) AS ProfittoFROM APPLICATIVO AS A, PRODOTTO AS P, LICENZA AS LWHERE A.Nome_Applicativo = P.Nome_Prodotto AND P.Nome_Prodotto = L.Nome_Prodotto AND L.Data_Inizio LIKE 'Anno%'GROUP BY A.Nome_ApplicativoORDER BY Profitto DESC;

Questa query seleziona la prima tupla in ordine decrescente di profitto, contenente il nome di un applicativo fra quelli la cui licenza ha come data di inizio un giorno dell'anno di interesse e un profitto calcolato secondo la formula:

Profitto = Durata licenza * Quantità licenze acquistate * (Prezzo mensile * (1 – Tipo canone) + Prezzo annuale * Tipo canone

Dove si è sfruttata l'assunzione che se Tipo canone è 0, la licenza è a scadenza mensile, altrimenti se è 1 la licenza è a scadenza annuale. Le tuple sono raggruppate per Nome_Applicativo, sommando i corrispettivi profitti.

- 6 -


Eventuali varianti ed altre soluzioni possibili

Sono possibili altre varianti della modellazione presentata prima. In particolare se si desidera fare a meno dei costrutti dei diagrammi EER, è possibile ripetere l'esercizio usando solo i costrutti ER.

Modellazione ER/EER:

Il diagramma ER che modella la realtà descritta è:

In questo caso il diagramma non discrimina tra utenti privati ed aziende (è una limitazione dello schema ma ciò non è esplicitamente richiesto nella traccia: ogni utente corrisponde ad un account della piattaforma ASP, nel caso delle aziende risulterebbe registrato colui che è stato incaricato degli acquisti).

Inoltre si sono introdotte le due relazioni CONCESSA_PER_PACCHETTO e CONCESSA_PER_APPLICATIVO che mettono in relazione le licenze con (rispettivamente) gli applicativi e i pacchetti in vendita.

Per ottenere le statistiche di profitto si è incluso un attributo calcolato che tiene conto del totale che il cliente pagherà all'azienda usufruendo di ogni licenza.

Il resto della modellazione è analogo alla soluzione EER precedentemente presentata.

- 7 -


Modello relazionale:

Nel mapping le relazioni CONCESSA_PER_APPLICATIVO e CONCESSA_PER_PACCHETTO sono state tradotte in relazioni invece di essere “inglobate” nella relazione nel lato N, poiché tale soluzione avrebbe portato alla presenza di valori NULL in tutte le tuple di licenza, dal momento che se la licenza è concessa per un applicativo allora avrebbe avuto valore NULL per la chiave esterna riferita a PACCHETTO, e viceversa. Inoltre si è ritenuto opportuno definire come chiave primaria solo No_Seriale, sufficiente ad identificare tutte le tuple nelle due relazioni in esame.

- 8 -


Query SQL:

Si assume che al posto di Nome applicazione e Anno si inseriscano rispettivamente il nome dell'applicazione e l'anno da considerare per interrogare il database.

Le query sono analoghe al caso EER, è sufficiente riferirsi alle nuove relazioni:

a) SELECT DISTINCT L.Cod_fiscaleFROM LICENZA AS LWHERE L.No_Seriale IN (SELECT No_Seriale

FROM CONCESSA_PER_APPLICATIVO WHERE Nome_App = 'Nome applicazione')

OR L.No_Seriale IN (SELECT No_Seriale FROM CONCESSA_PER_PACCHETTO AS CPP,

COMPONE AS C, PACCHETTO AS P WHERE CPP.Nome_Pac = P.Nome_Pac AND

P.Nome_Pac = C.Nome_Pac AND C.Nome_App = 'Nome Applicazione');

b) SELECT DISTINCT L.Cod_fiscaleFROM LICENZA AS LWHERE L.No_Seriale IN (SELECT No_Seriale

FROM CONCESSA_PER_APPLICATIVO WHERE Nome_App = 'Nome applicazione')

OR L.No_Seriale IN (SELECT No_seriale FROM CONCESSA_PER_PACCHETTO AS CPP,

COMPONE AS C, PACCHETTO AS P WHERE CPP.Nome_Pac = P.Nome_Pac AND

P.Nome_Pac = C.Nome_Pac AND C.Nome_App = 'Nome Applicazione')

AND NOT EXISTS (SELECT * FROM ACCEDE_A WHERE A.Cod_Fiscale = L.Cod_fiscale AND

A.Nome_App = 'Nome Applicazione' );

c) SELECT TOP 1 A.Nome_App, SUM(L.Durata * L.Quantità * (A.Prezzo_mensile * (1 – L.Tipo_canone) + A.Prezzo_Annuale * L.Tipo_canone)) AS ProfittoFROM APPLICATIVO AS A, LICENZA AS L, CONCESSA_PER_APPLICATIVO AS CPAWHERE A.Nome_App = CPA.Nome_App AND CPA.No_Seriale = L.No_Seriale AND L.Data_Inizio LIKE 'Anno%'GROUP BY A.Nome_AppORDER BY Profitto DESC;

In maniera analoga è possibile specificare le query usando, invece delle query innestate, gli operatori insiemistici dell'SQL, come visto nel caso della soluzione EER proposta.

- 9 -


Svolgimenti errati

Errori di notazione

Negli svolgimenti si è notato come spesso siano stati assegnati attributi di chiave primaria o parziale ai tipi di relazione. Ciò è errato dal punto di vista della notazione, la soluzione corretta è reificare il tipo di relazione e definire l'attributo chiave primaria sul tipo di entità che è venuto a crearsi.

Errori di modellazione

Per quanto concerne lo schema EER presentato in precedenza, potrebbe sorgere la questione se schematizzare la catena CLIENTE – ACQUISTA – LICENZA – RELATIVA_A – PRODOTTO come:

In realtà questa soluzione va evitata in quanto fornisce più informazioni di quanto è richiesto aumentando la complessità dello schema: in questa relazione viene memorizzata in aggiunta una relazione fra CLIENTE e PRODOTTO, informazione che è deducibile facendo il join fra le rispettive entità nella prima soluzione.

In alcune delle tracce analizzate è stata creata una chiave primaria ID_Cliente del tipo di entità CLIENTE, che è superflua in quanto essi possono essere individuati attraverso il loro codice fiscale (e non la terna (Nome, Cognome, Email) in quanto l'email può variare, e ciò comporterebbe l'aggiornamento di tutte le relazioni che vi fanno riferimento). Lo stesso vale per le chiavi primarie ID_Applicazione e ID_Pacchetto, se si suppone che le applicazioni e i pacchetti possono essere identificati attraverso il loro nome (comprensivo della major release, es. “Windows 95”, oppure “Windows XP”).Occorre poi ricordare di definire una chiave primaria per ogni tipo di entità, dal momento che questa dimenticanza è uno degli errori più comuni fra quelli osservati.

Inoltre in alcune tracce si è supposta l'esistenza di pacchetti con un solo applicativo contenuto, questo è di ausilio ai fini dell'interrogazione del database, ma è limitativo nei confronti della rappresentazione della realtà in esame.

In alcune modellazioni invece si è tralasciato il tipo di relazione RELATIVA_A fra il tipo di entità LICENZA e il tipo di entità PACCHETTO, ciò è errato perché l'acquisto di un pacchetto si traduce con l'acquisto delle licenze degli applicativi contenuti, non permettendo di tracciare gli acquisti dei pacchetti stessi.

Un altro errore di modellazione da segnalare sono la presenza di Username e Password come attributi di ogni licenza, ciò è sbagliato in quanto queste proprietà sono del tipo di entità CLIENTE. Inoltre in molte soluzioni si è tralasciata la definizione del canone annuale, assumendo che sia dato da 12 * canone mensile, ciò non tiene conto del fatto che il venditore potrebbe fare degli sconti su determinati prodotti, allo stesso modo è superfluo introdurre l'attributo (non calcolato) Totale_Licenza, perché è ridondante, dal momento che esso può essere calcolato con la formula già vista.

Infine in una delle soluzioni è stato introdotto il tipo di entità ARCHIVIO STORICO, ovvero la lista

- 10 -


delle applicazioni a cui è consentito l'accesso ad un dato cliente, che è informativamente poco significativa in quanto non prevista dalla specifica fornita.

Errori di mapping ER-relazionale

In alcune tracce si è notato l'inserimento di un attributo chiave primaria “ID” nelle relazioni che mappano i tipi di relazione M:N: questo è un errore poiché le chiavi primarie di queste relazioni sono la combinazione delle chiavi esterne riferentesi ai tipi di entità partecipanti.

Inoltre se si vuole mappare il numero di telefono come attributo multivalore, bisogna creare una nuova relazione che ha come attributi la chiave primaria del tipo di entità che possiede l'attributo multivalore e l'attributo multivalore stesso, è sbagliato inserire un numero arbitrario di campi come Telefono1, Telefono2, ecc., che porterebbero alla presenza di molti NULL nella relazione e sarebbe limitativo nei confronti di un cliente che possiede più numeri di telefono di quelli di cui si tiene conto.

Bisogna ricordare di definire i vincoli di chiave primaria nel modello relazionale.

Errori di SQL o algebra relazionale

Un errore di SQL riscontrato è stato la presenza di due funzioni di aggregazione (del tipo MAX(SUM(Attributo))) subito dopo la clausola SELECT, poiché il raggruppamento avviene una sola volta, mentre in questo caso, ipoteticamente, occorrerebbero due raggruppamenti. Si segnala poi che le funzioni di aggregazione possono essere presenti solo nelle clausole SELECT e HAVING, perché le altre sono valutate prima che avvenga il raggruppamento delle tuple.

Le query innestate non possono essere inserite nella clausola FROM (come si è visto in alcune query), dove sono consentite solo relazioni.

Poi si è riscontrato un errato uso del pattern matching nelle date per individuare le date che appartengono ad un certo anno: occorre tenere presente che il formato delle date è AAAA-MM-GG e non GG-MM-AAAA.

In una soluzione è presente la riga Numero_ore = NULL, invece del segno di uguale bisogna però usare la parola chiave IS. Inoltre il segno di “diverso da” in SQL è <> e non ≠.

Un uso errato delle query innestate è:

SELECT ...FROM ...WHERE Attr IN (SELECT * FROM ... WHERE ...)

Nel caso in cui le tuple della query innestata contengono un solo attributo la sintassi è corretta, altrimenti bisogna selezionare solo l'attributo da comparare ad Attr.

Una raccomandazione che si intende fare è quella di non dimenticare le condizioni di join nella clausola WHERE.

L'ultimo errore che si segnala è che nelle prime due query bisogna selezionare i clienti a seconda dell'applicazione di interesse, e non data la licenza dell'applicazione, per cui è noto come parametro della query il nome dell'applicazione e non il codice della licenza. È sbagliata per cui la soluzione che intende selezionare questi clienti basandosi sulla conoscenza del codice della licenza.

- 11 -


Osservazioni conclusive

Le tracce esaminate risultano per la maggior parte (nella misura del 70%) simili nella modellazione e nelle query effettuate al database, condividendo pregi e difetti dello svolgimento. Le restanti tracce non sono risultate esaustive, non rispecchiando le richieste date dalla specifica o aggiungendo inutilmente complessità alla modellazione tenendo conto di aspetti non richiesti.

- 12 -

Documents

Soluzione esame scritto di Basi di Dati I, CdL in ...mb.unisalento.it/Basi di Dati I 2008-2009/Allegati/licenze asp 5... · Revisione della traccia di esame di Basi di Dati I, 11/02/2003