Nell’ambito del corso vengono trattati il paradigma di programmazione web, le strutture principali del linguaggio PHP5, la programmazione ad oggetti. Inoltre, si fa riferimento costante ai problemi legati alla sicurezza ed allo stile di programmazione che previene le principali modalità di attacco ai siti realizzati in PHP: SQL injection, session fixation, ecc.

Gianfrasoft – Corso di PHP – parte 1

Gianfrasoft – Corso di PHP – parte 2

Gianfrasoft – Corso di PHP – parte 3

SELECT
  *
FROM
  Tabella
WHERE
  Tabella.Campo1 LIKE '%CHIAVE%'
ORDER BY
  Tabella.Campo1

Se talora la chiave coincide esattamente col campo sul quale stiamo effettuando la ricerca, ovvero si verifica che in almeno un record Tabella.Campo1 = ‘CHIAVE’, possiamo ottenere che il record che la contiene venga posizionato in testa alla query di ricerca sfruttando la clausaola ORDER BY CASE di SQL Server 2005 in questo modo:

SELECT
  *
FROM
  Tabella
WHERE
  Tabella.Campo1 LIKE '%CHIAVE%'
ORDER BY
  CASE WHEN Tabella.Campo1 = 'CHIAVE' THEN 1 ELSE 2 END,
  Tabella.Campo1

L’esempio è facilmente adattabile all’utilizzo con altri operatori.

Lo script INSERT che effettua l’inserimento di una riga duplicata deve, nella maggior parte dei casi, specificare la lista dei campi da caricare nel nuovo record e questo perché lo script non deve definire valori duplicati per i campi chiave, se richiesto non deve sovrascrivere i valori di default, non deve definire valori per i campi auto-incrementali e quant’altro.

Consideriamo il caso, piuttosto diffuso, di tabelle caratterizzate da una chiave primaria composta da un campo auto-incrementale, e realizziamo una procedura che:

• sia in grado di semplificare l’operazione di duplicazione della riga di una tabella, agendo indipendentemente dalla struttura della stessa;
• restituisca l’indice univoco del campo chiave del nuovo record;
• non valorizzi i campi che hanno valori di default;
• agisca su una qualsiasi tabella dove sia presente una chiave primaria composta da un campo auto-incrementale.

Il cuore della procedura è nella generazione al volo di uno script di insert completo della lista esplicita di tutti i campi della tabella su cui andiamo a duplicare il record. La lista dei campi viene recuperata mediante la view di sistema INFORMATION_SCHEMA mentre una chiamata alla stored procedure di sistema sp_executesql permetterà di eseguire lo script INSERT appena creato.

La procedura in questione esporrà, pertanto, tra i parametri:

1. il nome della tabella della quale s’intende duplicare una riga,
2. il nome del campo chiave,
3. l’id univoco della riga che si vuole duplicare

e restituirà l’id del record duplicato generato. Ecco il codice commentato:

IF EXISTS (SELECT SPECIFIC_NAME FROM INFORMATION_SCHEMA.ROUTINES WHERE SPECIFIC_NAME = 'ClonaRecord')
 DROP PROCEDURE dbo.ClonaRecord
GO

CREATE PROCEDURE dbo.ClonaRecord(
  @Tabella varchar(90),
  @NomeCampoID varchar(90),
  @IDSorgente varchar(16), 
  @IDDestinazione varchar(16) OUTPUT
) AS
BEGIN
  DECLARE @ErrMsg nvarchar(4000), @ErrSeverity int
  IF @IDSorgente IS NULL
  BEGIN
    SET @IDDestinazione = 'ERROR'
    
    -- Verifica che il campo @NomeCampoID non sia nullo. Se lo è, solleva un'eccezione
    SELECT @ErrMsg = 'Errore nei parametri - ' + @NomeCampoID + ' nullo.',
          @ErrSeverity = 1
    RAISERROR(@ErrMsg, @ErrSeverity, 1)
    RETURN
  END
  
  DECLARE @i int
  DECLARE @Script nvarchar(max)
  
  -- PROCESSAMENTO --
  BEGIN TRY
    -- La procedura lavora con le transazioni
    BEGIN TRANSACTION
    
    DECLARE @IDValue varchar(100) 
    DECLARE @Fields nvarchar(max)
    DECLARE @Ordinal integer
    
    SET @Script = ''

    -- La procedura inoltre accede alla view di sistema INFORMATION_SCHEMA
    -- per recuperare la lista dei campi indispensabili per la generazione
    -- dello script di INSERT
    SELECT @Ordinal = MIN(ORDINAL_POSITION) FROM 
      INFORMATION_SCHEMA.COLUMNS
      WHERE TABLE_NAME = @Tabella
    
    WHILE @Ordinal IS NOT NULL
    BEGIN
      SELECT @IDValue = COLUMN_NAME FROM 
        INFORMATION_SCHEMA.COLUMNS
        WHERE TABLE_NAME = @Tabella
        AND ORDINAL_POSITION = @Ordinal

      -- Un ciclo sul recordset individuato nella view INFORMATION_SCHEMA
      -- permette di popolare la stringa @Fields destinate a contenere la
      -- lista dei campi 
      IF @IDValue <> @NomeCampoID
      BEGIN
        IF @Fields IS NULL
          SET @Fields = @IDValue
        ELSE
          SET @Fields = @Fields + ', ' + @IDValue
      END
      
      SELECT @Ordinal = MIN(ORDINAL_POSITION) FROM 
        INFORMATION_SCHEMA.COLUMNS
        WHERE TABLE_NAME = @Tabella
        AND ORDINAL_POSITION > @Ordinal
        AND COLUMN_DEFAULT IS NULL  -- * NEW * --
    END

    -- Ecco finalmente lo script INSERT che viene generato al volo nell'ambito
    -- della stringa @Script di dimensioni nvarchar(max)
    SET @Script = 'INSERT INTO ' + @Tabella + ' (' + @Fields + ')' +
      ' SELECT ' + @Fields + ' FROM ' + @Tabella + 
      ' WHERE ' + @NomeCampoID + ' = ''' + @IDSorgente + ''''
    
    -- Lo script viene eseguito
    EXECUTE sp_executesql @Script

    -- Nella variabile @IDDestinazione viene conservato l'IDENTITY del nuovo
    -- record
    SET @IDDestinazione = @@IDENTITY
    
    COMMIT TRANSACTION
  END TRY
  BEGIN CATCH
    IF @@TRANCOUNT > 0
      ROLLBACK
    
    SET @IDDestinazione = 'ERROR'
    
    -- Se @IDDestinazione non è stato popolato, solleva un'eccezione
    SELECT @ErrMsg = ERROR_MESSAGE(),
      @ErrSeverity = ERROR_SEVERITY()
    RAISERROR(@ErrMsg, @ErrSeverity, 1)
  END CATCH  
END
GO

Un esempio di chiamata alla procedura appena descritta è riportata di seguito:

DECLARE @IDDestinazione varchar(16);
EXECUTE dbo.DuplicateRecord 'test', 'id', '6', @IDDestinazione OUTPUT
PRINT 'Nuovo id: ' + @IDDestinazione

dove alla chiamata segue la stampa nello standard output di SQL Server dell’id univoco del record appena generato.

Ad esempio, consideriamo una tabella che contiene le vendite effettuate da un’azienda nell’arco di un anno: vogliamo rappresentare in un recordset gli importi totali delle vendite di ogni mese. La questione si risolve con un semplice raggruppamento dati, ammenocché non si voglia riportare un importo nullo anche in corrispondenza dei mesi in cui non sono state effettuate vendite.

La soluzione ideale è quella di effettuare il raggruppamento dopo avere incrociato i dati delle vendite con un recordset contenente una riga per ciascuna data di inizio o di fine mese. Questo è possibile generando una tabella temporanea e popolandola, prima di effettuare la query sulle vendite.

Un’alternativa che agisca on the fly è quella basata sulle CTE ovvero Common Table Expression: le CTE consentono di effettuare query SQL di tipo ricorsivo, che è proprio quanto a noi serve.

Nell’esempio seguente, ho realizzato uno script SQL che produce un recordset contenente tutte le date di tipo inizio mese che coprono il periodo che va dall’01/01/2007 all’01/01/2008:

WITH CTE(X)
AS
(
  SELECT X = convert(datetime, '20070101')
  UNION ALL
  SELECT X = DATEADD(month, 1, X) FROM CTE
   WHERE X < '20080101'
)
SELECT X FROM CTE
ORDER BY X

Il recordset X può facilmente essere messo in join nell’ambito dello script “SELECT X…”.

Da questo script è facile ricavare recordset contenenti, ad esempio, intervalli di numerazione progressiva ascendene o discendente.

Attenzione, però: testando questa query su intervalli di date che richiedono più di 100 ricorsioni ci s’imbatterà nel messaggio di errore: “Istruzione interrotta. Numero massimo di ricorsioni 100 esaurito prima del completamento dell’istruzione.”. Difatti, il numero massimo di ricorsioni possibili di default in SQL Server è limitato a 100. Per consentire alla query di superare questo limite basterà fissare un nuovo limite e dichiararlo nell’ambito della stessa interrogazione con l’opzione MAXRECURSION come di seguito riportato:

WITH CTE(X)
AS
(
  SELECT X = convert(datetime, '20070101')
  UNION ALL
  SELECT X = DATEADD(month, 1, X) FROM CTE
  WHERE X < '20200101'
)
SELECT X FROM CTE
ORDER BY X 
OPTION (MAXRECURSION 500);

Nell’esempio appena descritto l’intervallo di date restituisce un recordset di 157 elementi e senza l’opzione di cui all’ultima riga andrebbe in errore.

Questo documento e tutto il lavoro che ne è scaturito, hanno come obiettivo la progettazione e l’implementazione di un sistema informatico che risponda alle richieste contenute nelle linee guida riportate di seguito: si è proceduto alla progettazione di una base dati per il supporto di un sistema informatico che realizzi un servizio web per la gestione di un insieme condiviso di risorse hardware per un dipartimento. Questo sistema informativo consente la prenotazione delle risorse da parte di utenti registrati, oltre a fornire come servizio la possibilità di verificare la disponibilità di una risorsa in uno specifico giorno ed in uno specifico orario.

Sono state così implementate tutte le funzionalità di:

• inserimento di una risorsa
• registrazione degli utenti
• consultazione delle risorse disponibili
• prenotazione delle risorse
• cancellazione di una prenotazione
• memorizzazione di dati relativi a utenti, risorse e prenotazioni

Strategia di progetto

Già nell’ambito delle linee guida si possono identificare le entità principali attorno alle quali il sistema informativo deve svilupparsi, e cioè: l’utente, la risorsa e la prenotazione.

Al fine di rendere il sistema quanto più possibile aperto e funzionale, si è ritenuto opportuno introdurre alcune ulteriori specifiche riguardanti le suddette entità:

• gli utenti del sistema si dividono in due categorie: amministratori e utenti semplici; ai primi è dato potere di accedere ad ogni parte del sistema mentre ai secondi alcune aree di lavoro sono interdette;
• ad ogni risorsa sono associati orari di disponibilità, cioè intervalli temporali all’esterno dei quali la risorsa non può mai essere prenotata;
• alla prenotazione delle risorse da parte di utenti generici o di amministratori viene fornito un sistema di visualizzazione grafica degli intervalli temporali di disponibilità della risorsa che rende superfluo qualsiasi ulteriore accorgimento;
• viene implementato a scopo didattico un semplice metodo di storicizzazione delle informazioni relativamente all’entità prenotazione che consente di aggirare alcuni problemi relativi all’aggiornamento delle risorse.

Definizioni

Riportiamo la prima parte di un glossario utile alla comprensione delle specifiche di lavoro come di seguito riportate:

Indicheremo con risorsa l’oggetto d’interesse di una prenotazione. Con la parola utente faremo riferimento ad un qualsiasi utente, con utente semplice o amministratore indicheremo invece gli utenti specifici.

Con la parola prenotabilità faremo riferimento alle ore in cui una risorsa risulta prenotabile, con disponibilità indicheremo le ore in cui la risorsa è prenotabile e libera: una risorsa prenotabile sarà pertanto disponibile in una particolare fascia oraria solo qualora non vi fossero già presenti in quelle ore altre prenotazioni.

I giorni di prenotabilità di una risorsa si indicheranno come giornate, ed anche queste verranno rappresentate nel database nell’ambito di una specifica entità che si chiamerà giorno.

Nell’ambito del database tutti gli oggetti di cui sopra saranno identificabili nell’ambito di entità che porteranno i nomi di: Risorse, Prenotazioni, Utenti (entità omogenea per utenti semplici ed amministratori) e Giorni.

Entià

Nell’ambito della progettazione concettuale dobbiamo per primo identificare le entità che partecipano al progetto. Abbiamo descritto in un primo momento tre entità: utenti, risorse e prenotazioni.

Al fine di rendere alcune funzionalità relative alle prenotazioni e di cui parleremo in seguito, anticipiamo che tra le altre viene introdotta una quarta entità che è il giorno.

Utenti

Si dividono in utenti semplici ed amministratori. Agli amministratori soltanto è riservato il potere di

• generare nuove risorse, modificarne o eliminarne di esistenti
• registrare nuovi utenti, modificarne o cancellarne di esistenti

Sia gli utenti semplici che gli amministratori possono prenotare risorse o cancellare prenotazioni proprie. Infine gli utenti semplici possono accedere alle informazioni associate a sé stessi per modificarne il contenuto mentre gli amministratori possono modificare le specifiche di qualsiasi utente presente in archivio.

L’entità utente contiene informazioni come: nome e cognome, indirizzo, contatti di vario genere oltre che login e password indispensabili per identificarsi nell’ambito del sistema informativo.

Risorse

Le risorse sono caratterizzate principalmente dalla propria descrizione. La generalità del concetto di risorsa è resa, nell’ambito del sistema informativo che stiamo descrivendo, ad un livello di astrazione tale da potersi considerare slegata dal contesto previsto nell’ambito delle linee guida. Parlare di risorsa hardware di un dipartimento equivale in questo contesto ad una qualsiasi risorsa prenotabile in un qualsiasi altro contesto.

Oltre alla descrizione, la risorsa è caratterizzata da una lista di (massimo) tre intervalli temporali (almeno uno deve essere valorizzato) che consentono al sistema di identificare le fasce orare di prenotabilità della risorsa nell’ambito di tutti i giorni della settimana.

Si noti che in questo contesto si assume che la risorsa sia disponibile tutti i giorni senza alcuna limitazione sulla data (limitazione che avrebbe richiesto l’introduzione di numerose variazioni nella gestione del front-end del sistema informativo). E’ altresì consentito indicare gli orari di prenotabilità a livello di risorsa che saranno il punto di riferimento per la definizione della prenotabilità nell’ambito di ogni singola giornata.

Prenotazioni

Le prenotazioni rappresentano relazioni che legano gli utenti alle risorse. In quanto tali le prenotazioni dovranno contenere null’altro che le informazioni indispensabili per la loro identificazione temporale e cioè data, orario di inizio ed orario di fine oltre ai riferimenti a risorsa ed utente.

La possibilità di prenotare una risorsa in una specifica data ed in una specifica fascia oraria richiede una verifica della sua disponibilità (e pertanto anche della sua prenotabilità) nella data/ora della nuova prenotazione. La presenza di altre prenotazioni in quella stessa fascia oraria, infatti invalida una qualsiasi nuova prenotazione, e lo stesso vale se la scelta di un intervallo per quest’ultima non ricade perfettamente nell’ambito della prenotabilità della risorsa stessa.

Problema della modifica della disponibilità di una risorsa

Se nell’ambito di una risorsa vengono modificati gli intervalli di disponibilità della stessa lì dove questa è già stata coinvolta una o più prenotazioni, nasce il problema di dovere definire una politica di comportamento del sistema informativo che aggiri la possibilità di conflitto tra gli intervalli di prenotazioni già effettuate e quelli delle nuove fasce di prenotabilità.

La politica di risoluzione del problema va in realtà determinata nell’ambito delle esigenze specifiche di chi commissiona la realizzazione del progetto. Avendo in questo ambito la libertà di determinare il più opportuno funzionamento da parte del sistema, si è deciso di provvedere descrivendo una nuova entità che ha il nome di giorno.

Giorni

Ciascuna entità di questa specie registra la prenotabilità della risorsa nell’ambito di una specifica giornata del calendario. La singola entità giorno conterrà oltre ad una data (relativa ad un qualsiasi giorno della settimana o del mese) le informazioni riguardo le fasce orarie di prenotabilità della risorsa al momento in cui, in quella specifica giornata, la prenotabilità sia stata definita una volta e per sempre.

Infatti, al momento di una prenotazione il sistema informativo farà riferimento, per la verifica della prenotabilità di una risorsa in una specifica giornata, alla entità giorno relativa alla risorsa e che fa riferimento alla giornata in questione. Se questa entità non è presente in archivio, il sistema informativo si occuperà di generarla assegnandole come data la giornata in cui si desidera attuare la prenotazione e come fasce di disponibilità quelle della risorsa che si desidera prenotare, così come sono definite in quel momento.

Pertanto le prenotazioni non faranno riferimento direttamente alle fasce orarie come descritte nella entità risorsa ma a quelle descritte nella entità giorno relativa alla data visitata.

Il fatto che la modifica delle fasce orarie di prenotabilità di ogni risorsa non si modifichi la prenotabilità come descritta nei giorni relative alla risorsa stessa, fa sì che le prenotazioni restino consistenti. Ciò equivale a dire che: qualora una risorsa venisse prenotata in uno specifico giorno ed in una specifica fascia oraria, eventuali modifiche alle fasce di disponibilità non interesserebbero i giorni in cui già fossero state effettuate prenotazioni.

Note

Questa politica di risoluzione del conflitto tra prenotazioni e risorse è sicuramente una politica discutibile sotto numerosi aspetti: sia perché non consente di stabilire il giorno in cui debba entrare in vigore il nuovo orario della risorsa, sia perché il cambio di orario determina per un numero imprecisato di giorni una alternanza di orari vecchi e nuovi a seconda della presenza o meno di prenotazioni che facciano riferimento a quelle giornate.

Una possibile migliore risposta alla questione dei conflitti prenotazioni-risorse è l’introduzione di un sistema di storicizzazione della modifica delle fasce orarie delle risorse che consentisse di registrare il periodo di validità dei vecchi e nuovi orari.

Questa soluzione, come numerose altre, sono state scartate per motivi di tempo.

Strategia di progetto

Data la semplicità della struttura della base dati, non ha propriamente senso parlare di strategie implementative di tipo top-down o bottom-up anche se per questo progetto vale forse parlare di strategia inside-out.

Partendo dalla entità che rappresenta il nucleo centrale di tutto il progetto, l’entità risorsa, possiamo considerare le entità utente e prenotazione come introdotte immediatamente dopo ed al fine di rendere la funzionalità legata alla prenotazione delle risorse stesse. Infine l’entità giorno interviene per risolvere problemi di progettazione legati alla struttura del database.

Progettazione logica

Per quanto detto sopra, le tabelle saranno quindi le seguenti:

(Utenti, Risorse, Prenotazioni, Giorni)

Schema logico

Ecco come appare la struttura sin qui descritta e realizzata logicamente mediante il case Embarcadero E/R Studio:

In questo modello entità-relazione la strutturazione logica mostra le relazioni che legano la tabella delle prenotazioni da tutte le altre tabelle. La tabella dei giorni è in relazione con la sola tabella delle risorse mentre quella degli utenti è completamente indipendente dalle altre.

Uno schema tanto semplice è tale da coincidere quasi perfettamente con la struttura implementativa del database.

Si noti nel report la presenza di due tipi dato definiti per rendere omogeneo l’utilizzo di campi che fanno riferimento ad indirizzi e-mail (tipo definito: EMAIL) ed a numeri telefonici (tipo definito: NUMEROTEL).

Funzionalità trasparenti

Alcune funzionalità del database hanno lo scopo di preservare l’integrità dei dati o di fornire controlli di vario genere sulla qualità dei dati immessi.

Alcune di queste sono state implementate per mezzo di trigger, altre per mezzo di procedure (o funzioni database) opportunamente inserite nel codice richiamato dal client del sistema informatico.

Integrità a livello di prenotazione

La cancellazione di una risorsa o di un utente dalla relativa tabella determina la necessità di ripulire le tabelle dei giorni e delle prenotazioni da tutti gli elementi che fanno riferimento alla risorsa o all’utente stesso. Questo viene reso mediante l’uso di due trigger sulle tabelle delle risorse e degli utenti.

Storicizzazione delle risorse

Come accennato precedentemente, s’intende far corrispondere alla eliminazione di un elemento della tabella delle risorse l’aggiornamento del campo Storicizzazione al fine di tenere in archivio traccia della risorsa non più utilizzata.

Una simile storicizzazione può essere attuata anche a livello di aggiornamento (dove la modifica di un qualsiasi campo della tabella Risorse genera una copia del record come era prima della modifica e con una data di validità introdotta nel campo Storicizzazione). Questo tipo di impiego non è utile in questa fase anche se renderebbe possibile alcune migliorie nel funzionamento della base dati.

Nell’ambito della visualizzazione, nel client, della lista delle risorse disponibili in archivio vengono pertanto escluse nella query tutte le risorse con campo Storicizzazione non nullo.

Controllo della disponibilità di una risorsa

Alcune funzionalità, che non possono essere rese agevolmente mediante semplici query, devono essere affidare a procedure (o funzioni) apposite: è il caso dei controlli sulla disponibilità delle risorse nelle fasce orarie in cui è richiesto di aggiungere una prenotazione. Il sistema database deve essere blindato, nel senso di non consentire procedure di INSERT di prenotazioni dove non fesse consentito.

Questi controlli sono resi trasparenti dal client che interroga il database con una apposita stored procedure per verificare che non si stiano violando le regole fondamentali della prenotabilità delle risorse: qualora le regole fossero violare, a lui è riservato il compito di annullare la procedura di inserimento ed avvertire l’utente della non avvenuta operazione. Un ulteriore controllo a livello database, affidato ad un trigger e pertanto trasparente anche al client stesso potrebbe ritenersi opportuno ma attualmente appare superfluo.

Anche con l’introduzione nel front-end di un sistema guidato alla prenotazione, realizzato mediante l’uso delle procedure di cui ai paragrafi seguenti, è da ritenersi necessario il controllo appena descritto per non permettere di introdurre in alcun modo in archivio dati che renderebbero aleatorio tutto il contenuto delle tabelle destinate alle prenotazioni.

Controllo della presenza del giorno di prenotabilità

In fase di interrogazione del database, è necessario che, qualora non fosse definita la prenotabilità di una risorsa in una specifica giornata, che corrisponde alla assenza del record della tabella dei giorni che fa riferimento a quella risorsa e quella giornata, sarà necessario generare quel record in modo da riprodurre tutte le fasce orarie di disponibilità della risorsa stessa.

Le fasce orarie saranno quelle della risorsa al momento della creazione del record nella tabella Giorni; ad una procedura sarà affidato il controllo della presenza dello specifico record della tabella Giorni e l’eventuale sua generazione qualora non fosse presente.

NOTA: La generazione dei record della tabella Giorni avverranno pertanto già in fase di visitazione della tabella stessa. Questo comportamento rappresenta una approssimazione forse grossolana alla quale si potrebbe ovviare in molti modi ma che si assume adatto alle esigenze di questo progetto.

Funzionalità accessorie
Calcolo automatico dell’id di una nuova risorsa

E’ spesso opportuno rendere automatico il calcolo, da parte del sistema informatico, del nuovo valore del campo chiave della tabella delle risorse (uguale al valore massimo presente in tabella aumentato di uno). Metodi più evoluti, mediante tabella delle sequenze sarebbero opportuni per applicazioni web destinate ad un numero di connessioni contemporanee alto, ma in questo progetto si considerano non necessari.

Generazione di viste sulle fasce orarie di disponibilità delle risorse

Una particolare “funzione tabellare” (strumento in uso in MS-SQL Server 2000) restituirà in output una tabella ad uso della visualizzazione delle fasce orarie di prenotazione e di disponibilità delle risorse al fine di consentire, nel client, una visualizzazione grafica.

Nella visualizzazione grafica compariranno tanti elementi quanti sono i time-slice interessati dall’intervallo di prenotabilità della risorsa: ogni elemento corrisponderà ad un record della tabella dinamica generata dalla funzione tabellare. Un particolare campo di questa tabella servirà ad indicare se nella specifica fascia oraria la risorsa è non disponibile, prenotabile o già prenotata: a questi valori il client farà corrispondere in visualizzazione colori diversi che rendano più intuitiva la lettura.

Indicazione degli estremi di un intervallo di disponibilità

Sempre al fine di generare funzionalità utili alla visualizzazione grafica sul lato client delle informazioni relative alla disponibilità delle risorse nelle specifiche fasce orarie, una particolare procedura si occuperà di determinare l’inizio e la fine di un intervallo di disponibilità a partire da un qualsiasi orario contenuto all’interno dell’intervallo stesso.

In fase di visualizzazione da parte del client, l’utilità di questa procedura è di rendere possibile all’utente di sapere se in un intorno di uno specifico orario, selezionato sulla grafica descritta sopra, esiste la possibilità di prenotare una risorsa e quanto può essere al limite grande questo intervallo.

Altri controlli

Al client dovranno essere affidati numerosi altri controlli sulla qualità dei dati in fase di inserimento o di modifica dei record; ciò si attua al fine sia di evitare l’inserimento di dati aleatori per i quali non sono previsti controlli a livello di database, sia di evitare che il database restituisca errori non gestiti dallo stesso client.

Implementazione

Quello che segue è la descrizione dettagliata del file usato per la generazione delle entità del database oggetto di studio, oltre ai tipi definiti dall’utente, ai trigger ed alle procedure ad uso della gestione del sistema informatico.

Si noti che nel database reale i nomi dei campi e delle entità sono leggermente modificati rispetto a come compaiono nella strutturazione logica. In particolare gli spazi sono sostituiti da caratteri underscore (“_”) e le lettere minuscole sono sostituite da maiuscole; così che il campo “Disp dalle” diventa “DISP_DALLE”.
Tipi definiti
“EMAIL”

“NUMEROTEL”

Questi tipi definiti sono introdotti per rendere omogeneo l’utilizzo dei campi relativi ad e-mail e numeri telefonici.
Entità

Le entità sono riportate nell’ordine logico con cui sono state concepite in fase di progettazione concettuale.

Risorse

Utenti

Giorni

Prenotazioni

Chiavi alternative

E’ presente in archivio una sola chiave alternativa che consente di individuare una risorsa mediante il suo nome ed il valore di storicizzazione.

AK1_RISORSE

Il campo storicizzazione fa chiave univoca con il campo Nome al fine di consentire la reintroduzione di elementi precedentemente storicizzati con un nuovo id primario ma non di introdurre due risorse attuve (campo Storicizzazione nullo) con lo stesso nome.

Chiavi esterne

Le foreign key vengono generate mediante il comando di ALTER TABLE al fine di non creare conflitti con le tabelle non ancora generate.

FK_RISORSE_DISPONIBILITA

Questa chiave mette in relazione la tabella Giorni con la tabella Risorse: individua pertanto la risorsa a cui fa riferimento lo specifico giorno.

FK_GIORNI_PRENOTAZIONI

Questa chiave mette in relazione la tabella Prenotazioni con la tabella Giorni: individua a quale giorno fa riferimento la specifica prenotazione.

FK_RISORSE_PRENOTAZIONI

Questa chiave mette in relazione la tabella Prenotazioni con la tabella Risorse: individua la risorsa alla quale fa riferimento la specifica prenotazione.

Questa informazione è ridondante se si considera che ogni prenotazione fa riferimento ad un record della tabella Giorni e che quest’ultimo contiene già il riferiento alla risorsa prenotata. Ripetere questa informazione nella tabella delle prenotazioni consente comunque un risparmio in termini computazionali e di tempo di risposta del database poiché, in fase di interrogazione dello stesso, consentirà di fare uso di query semplificate. La spesa in termini di inserimento dell’informazione sulla risorsa nei record delle prenotazioni non ha alcun costo perché già disponibile nel client al momento in cui un utente desidera prenotare.

FK_UTENTI_PRENOTAZIONI

Questa chiave mette in relazione la tabella Prenotazioni con la tabella Utenti: individua l’utente che ha effettuato la specifica prenotazione.

Trigger

Hanno tutti lo scopo di mantenere l’integrità del database.

OnDeleteRisorsa

Determina il comportamento del satabase al momento della eliminazione di una risorsa. E’ un trigger INSTEAD OF perché intende sostituire alla operazione di eliminazione l’aggiornamento del campo STORICIZZAZIONE.

OnDeleteRisorsa

Determina il comportamento del satabase al momento della eliminazione di un UTENTE. Anche questo è un trigger di tipo INSTEAD OF ma in questo caso avrebbe potuto essere anche di tipo AFTER: la sola condizione che si pone è che l’operazione di eliminazione dell’utente stesso non deve avvenire se non dopo l’eliminazione dei riferimenti ad esso nella tabella PRENOTAZIONI.

Stored procedure

Le procedure che seguono sono concepite per rendere i controlli e le funzionalità relative al calcolo delle fasce orarie di disponibilità delle risorse.

AbilitaPrenotabilitaRisorsa

Questa funzione verifica che per una specifica risorsa ed una specifica data sia prensente nella tabella GIORNI il record che ne consente la prenotazione, altrimenti lo genera.

TrovaInizioFineIntervallo

Questa procedura restituisce gli orari di inizio e di fine di un intervallo di prenotabilità riferito alla data ed all’ora passati come parametri di input.

VerificaPrenotabilitaRisorsa

Questa procedura verifica che una risorsa sia disponibile in una particolare fascia oraria. Essa restituisce un numero che può assumere i seguenti valori:

0: la risorsa è disponibile

1: la risorsa è prenotabile ma non disponibile

2: la risorsa non è prenotabile.

Function

Le funzioni sono una prerogativa specifica del MS-SQL Server 2000. Quelle qui descritte sono concepite per in massima parte per rendere i controlli e le funzionalità relative al calcolo delle fasce orarie di disponibilità delle risorse, ma anche per altre funzionalità.

ImmaginePrenotazioni

Questa funzione restituisce una tabella strutturata in maniera tale da indicare per ciascuna data e per uno specifico time-slice. Questo particolare tipo di funzione è detto “Funzione tabellare”.

L’obiettivo di questa funzione è di fornire al client una stuttura fondamentale sulla quale poggiare per la realizzazione della grafica riguardante la disponibilità di una risorsa in un particolare giorno.

Il parametro di input @TimeSliceInMin determina la precisione nella rappresentazione delle prenotazioni e degli intervalli di prenotabilità: una piccola modifica nell’ambito del programma client può agire in maniera da passare un valore numerico differente ed avere una rappresentazione grafica migliore.

Il campo STATO della tabella @TabellaPrenotazioni indica lo stato del time slice e per esso i valori possibili sono:

‘F’: time-slice disponibile

‘O’: time-slice prenotabile ma occupato

‘N’: time-slice non prenotabile

Il parametro @ErrorCode serve ad indicare se si sono verificati degli errori.

NOTA: Questa procedura lavora su record della tabella Giorni dando per scontato che essi esistano. Infatti il client non permette di accedere alle funzionalità offerte da questa funzione se non dopo avere lanciato almeno una volta pa procedura AbilitPrenotabilitaRisorsa.

ImmaginePrenotazioniUtente

Questa funzione restituisce una tabella strutturata in maniera tale da indicare per l’utente selezionato tutta la lista delle prenotazioni effettuate sulle risorse in archivio.

Questa funzione fornisce al client la base per la visualizzazione delle prenotazioni, lista dalla quale selezionare le eventuali prenotazioni da cancellare.

NuovoIdRisorse

Questa funzione serve a determinare il valore del campo ID_RISORSA per una nuova risorsa appena introdotta in archivio.

INSERT

Per concludere la generazione del database è necessario introdurre un utente standard, di tipo amministratore, che sia la base di partenza per il funzionamento di tutto il sistema informatico. Questo utente avrà un login ed una password noti (entrambi uguali ad “sa”).

Classico gioco del Master Mind in cui è consentito all’utente sia di giocare che di osservare il programma che individua una combinazione elaborata dall’utente stesso. Ralizzato in maniera da riprodurrela grafica del classico Mini Master Mind in commercio in Italia negli anni ’80.

Per scaricare il programma free, cliccare qui.

Il gioco richiede l’utilizzo del mouse per trascinare i pioli colorati sullo schema principale:

Nel caso in cui sia il programma a dover individuare la combinazione, i pioli colorati saranno il bianco ed il nero:

Il programma è realizzato in linguaggio Delphi 7 per Windows; l’algorimo per la risoluzione è basato sulla enumerazione totale delle soluzioni, che vengono poi scartate man mano che l’utente indica coi pioli bianchi e neri quelle errate.

One Million Sudoku è un programma completamente free orientato a quanti scrivono sudoku per mestiere. Esso consente di risolvere e quindi di verificare la risolvibilità di sudoku introdotti dall’utente, individuando quelli che non risolvibili e quelli che possiedono più di una soluzione; su richiesta dell’utente ne genera di propri.

Per scaricare una copia del programma click qui

Il programma può anche servire da sorgente infinita di gioco per quanti amano affrontare e risolvere questo tipo di rompicapo.

Nella finestra principale del programma sono presenti due schemi di sudoku: uno schema principale ed uno schema della soluzione (più piccolo a sinistra):

E’ possibile, appena lanciato il programma, introdurre i numeri nello schema principale mediante l’utilizzo del mouse ed interagire col menù per verificare i risultati. Le voci principali sono due:

• Game
• Options

Game attiva le operazioni:

1. create your own sudoku: abilita alla scrittura di sudoku nello schema principale;
2. solve the sudoku: verifica l’esistenza di una soluzione univoca per il sudoku descritto nello schema principal. Se la trova la riporta nello schema secondario;
3. auto-generate a new sudoku: senza perder tempo genera automaticamente e randomicamente un nuovo sudoku nello schema principaleriportandone la soluzione nello schema secondario.

La voce Options permette di attivare il diagonal filter che impone a tutti i sudoku in lavorazione che anche la sequenza di numeri sulle diagonali rispetti l’univocità di ciascun numero.

Qualche dettaglio tecnico: questo programma è scritto in linguaggio Delphi 7 per Windows. L’algoritmo per la risoluzione dei sudoku è un algoritmo di backtracking.

In PHP è facile accedere al contenuto di un array associativo anche se non se ne conosce la struttura interna. Per far ciò basta effettuare un semplice ciclo “foreach” come descritto di seguito:

foreach($array as $name => $value)

dove la variabile $array contiene l’array che vogliamo esaminare e le variabili $name e $value conterranno, ad ogni ciclo, il nome ed il valore di ciascun elemento dell’array.

Ad ogni ciclo, per stabilire se l’elemento dell’array associativo che stiamo esaminando è a sua volta un array, basta far riferimento alla funzione is_array del PHP: in caso positivo si può richiamare la stessa funzione ricorsivamente perché esamini il contenuto del nuovo array.

Generiamo, quindi, una struttura XML che in corrispondenza di ogni array produce un nodo XML che indicheremo con <bag> ed in corrispondenza di ciascun elemento semplice produca un nodo XML <item> contenente tra gli attributi il nome ed il tipo dello stesso:

function inspect_array($array, $indent, $string)
{
  foreach($array as $name => $value)
  {
    if (is_array($value))
    {
      $string = $string.$indent."<"."bag"."name=\"$name\""." phpType=\"array\">\n";

      // ricorsione
      $string = inspect_array($value, $indent.' ', $string);
      $string = $string.$indent."</"."bag".">\n";
    }
    else
    {
      $string = $string.$indent."<"."item"."name=\"$name\""." phpType=\"".
      gettype($value)."\">".htmlspecialchars($value)."</"."item".">\n";
    }
  }
  return $string;
}

$params = array_map_deep($_REQUEST["params"]);
$xmlstring = "<?xml version=\"1.0\"?>\n";
$xmlstring = $xmlstring."<resultString>\n";
$xmlstring = $xmlstring." <"."bag name=\"result\"phpType=\"object\">\n";
$xmlstring = inspect_obj_array($params, ' ', $xmlstring);
$xmlstring = $xmlstring." </"."bag".">\n";
$xmlstring = $xmlstring."</resultString>\n";

Sotto è riportato come esempio il risultato del processamento di un array contenente alcuni dati anagrafici: l’indirizzo è a sua volta un array contenente tre elementi semplici.

<?xml version="1.0" ?>
  <resultString>
    <bag name="result" phpType="object">
      <item name="nominativo" phpType="string">Gianfranco Fedele </item>
      <item name="eta" phpType="integer">31</item>
      <bag name="indirizzo" phpType="array">
        <item name="via" phpType="string">via del Maratoneta</item>
        <item name="civico" phpType="integer">8</item>
        <item name="citta" phpType="string">Napoli</item>
      </bag>
    </bag>
  </resultString>

Nel caso in cui s’intenda esaminare oggetti (array contenenti oggetti o oggetti contenenti array), il PHP mette a disposizione una importante funzione che consente di esaminare il contenuto di un oggetto come fosse un array associativo. La funzione di chiama get_object_vars.
Pertanto, volendo estendere la funzione al caso dell’ispezione, oltre che degli array associativi, anche degli oggetti, dovremo scrivere:

function inspect_obj_array($array, $indent, $string)
{
  foreach($array as $name => $value)

  {
    if (is_array($value))
    {
      $string = $string.$indent."<"."bag"." name=\"$name\""." phpType=\"array\">\n";
      // ricorsione
      $string = inspect_obj_array($value, $indent.' ', $string);
      $string = $string.$indent."</"."bag".">\n";
    }

    if (is_object($value))
    {
      $string = $string.$indent."<"."bag"." name=\"$name\""." phpType=\"object\">\n";

      // ricorsione
      $vars = get_object_vars($value);
      $string = inspect_obj_array($vars, $indent.' ', $string);

      $string = $string.$indent."</"."bag".">\n";

    }
    if (!(is_array($value)) && (!is_object($value)))
    {
      $string = $string.$indent."<"."item"." name=\"$name\""." phpType=\"".
      gettype($value)."\">".htmlspecialchars($value)."</"."item".">\n";
    }
  }
  return $string;
}

$params = array_map_deep($_REQUEST["params"]);$xmlstring = "<?xml version=\"1.0\"?>\n";
$xmlstring = $xmlstring."<resultString>\n";
$xmlstring = $xmlstring." <"."bag name=\"result\" phpType=\"object\">\n";
$xmlstring = inspect_obj_array($params, ' ', $xmlstring);
$xmlstring = $xmlstring." </"."bag".">\n";
$xmlstring = $xmlstring."</resultString>\n";

• dati_personali
  • nominativo
  • età
  • indirizzo
    • via
    • civico
    • città

E’ facile individuare in questa struttura dati l’albero delle informazioni che pone le proprie radici nel nodo dati_personali e che realizza tre livelli di profondità. Questo albero contiene in totale 7 nodi organizzati in 3 livelli.

In questo articolo esamineremo come sia possibile costruire una pagina dinamica in PHP che sia in grado di raccogliere le informazioni introdotte dall’utente nell’ambito di un form, e di elaborarle nel pieno rispetto della loro struttura gerarchica, qualunque sia in form. Nella fattispecie, la pagina dinamica recupererà le informazioni introdotte dall’utente riorganizzandole nell’ambito una struttura ricorsiva composta da array associativi: ad ogni livello dell’albero verrà associato un array ottenendo, nel caso descritto sopra, tre array:

il primo array conterrà tre informazioni: nominativo di tipo stringa, età di tipo intero ed un array associativo relativo all’indirizzo; l’array dell’indirizzo conterrà a sua volta tre informazioni: via di tipo stringa, civico di tipo intero e città anch’esso di tipo stringa.

Per prima cosa va fissata una rappresentazione delle informazioni nell’ambito del form HTML che dia modi di stabilire il tipo e la gerarchia dei dati introdotti dall’utente, ciò perché possano essere correttamente processati dalla pagina PHP. Un modo per effettuare questa rappresentazione è quello di strutturare i nomi delle etichette di input in modo che contengano sia il nome del parametro di input che il tipo dello stesso separati da un carattere speciale, ad esempio:

string%nominativo

inoltre, per rendere possibile la gerarchia delle informazioni, verranno introdotti nei nomi delle etichette <input> una coppia di parentesi quadre per ogni livello di annidamento dell’informazione associando al livello il particolare tipo array. Nel caso delle informazioni anagrafiche descritte nella pagina precedente avremo infatti:

dati_personali[string%nominativo]
dati_personali[int%eta]
dati_personali[array%indirizzo][string%via]
dati_personali[array%indirizzo][int%civico]
dati_personali[array%indirizzo][string%citta]

Dalle informazioni riportate sopra possiamo dedurre che:

• i tipi string, int ed array non devono necessariamente corrispondere ai tipi del PHP; essi rappresentano semplicemente un protocollo per la trasmissione di informazioni sul tipo dei dati e servono per un controllo dell’integrità da parte della pagina PHP;
• ai dati che rappresentano dei “contenitori” di informazioni veine associato il tipo array;
• le parentesi quadre aiutano a definire i differenti livelli di annidamento.

Ecco quindi come compare il testo della form HTML:

<form action="wsquery.php">
<p><font size="+2"><b>Lettura dei parametri:</b></font></p>
<table cellpadding="2" cellspacing="2"          border="1" width="100%">
<tr><td>Nominativo
<input type="text" name="dati_personali[string%nominativo]">
</td></tr>
<tr><td>Età
<input type="text" name="dati_personali[int%eta]">
</td></tr>
<tr><td>Indirizzo / via
<input type="text" name="dati_personali[array%indirizzo][string%via]">
</td></tr>
<tr><td>Indirizzo / civico
<input type="text" name="dati_personali[array%indirizzo][int%civico]">
</td></tr>
<tr><td>Indirizzo / città
<input type="text" name="dati_personali[array%indirizzo][string%citta]">
</td></tr>
<tr><td>
<input type="submit" name="button" value="Submit">
</td></tr>
</table>
</form> 

Nel form HTML appena descritto compare il nome della pagina dinamica “wsquery.php” che è proprio la pagina PHP che si occuperà del processamento dei dati.

La pagina “wsquery.php” sarà infatti caratterizzata dalla funzione principale array_map_deep riportata di seguito:

function array_map_deep($in_array)
{
  $out_array = array();
  if ($in_array != array())
  {
    foreach ($in_array as $key => $value)
    {
      // se il valore dell'array e' a sua volta un array attua la ricorsione
      if (is_array($value))
      {
        // elabora l'array contenuto "ricorsivamente"
        $temp = array_map_deep($value);

        // carica l'elaborazione nell'array di uscita
        $out_array[get_name($key)] = $temp;
      }
      else
      {
        // ricava il tipo dell'elemento nell'array in ingresso, fa il
        // cast del valore in esso contenuto e lo carica nell'array di uscita
        $out_array[get_name($key)] = set_the_type($value, get_schema_type($key));
      }
    }
  }
  return $out_array;
}

La funzione appena descritta è una funzione ricorsiva che, a partire da una array associativo contenente una lista di valori caratterizzati da nomi definiti come descritto sopra, restituisce un secondo array caratterizzato da una struttura ricorsiva dove ad ogni livello di profondità corrisponde un nuovo array associativo. Nel caso in esempio si avrà un array denominato dati_personali contenente una stringa (nominativo), un intero (eta) ed un array (indirizzo); quest’ultimo array conterrà due stinghe (via e citta) ed un intero (civico).

E’ facile immaginare che l’array in input a questa funzione sarà proprio

$_REQUEST["dati_personali"]

In questo modo la funzione array_map_deep si occuperà di esaminare tutti i parametri provenienti dall’interfaccia utente riferiti alla struttura dati_personali, esplorando ricorsivamente il contenuto dei parametri con struttura complessa (che nel linguaggio PHP sono univocamente rappresentati mediante array associativi).

Quando la funzione array_map_deep individua un tipo semplice, essa ne ricava il tipo mediante la funzione get_schema_type, e il nome mediante la funzione get_name semplicemente scomponendo la stringa contenuta nel nome del componente HTML <input> nella sottostringa che precede e che segue il carattere “%”:

function get_name($str)
{
  $i = strpos ($str, "%");
  return substr (substr ($str, $i ++), 1);
}

function get_schema_type($str)
{
  $i = strpos ($str, "%");
  return substr ($str, 0, $i);
}

Successivamente effettua la sua conversione nel tipo PHP corrispondente attraverso la funzione set_the_type. La funzione set_the_type individua una corrispondenza tra i tipi definiti come array, string,int e boolean e i tipi PHP veri e propri ed effettua la conversione del valore contenuto nel parametro.

function set_the_type($var, $schema_type)
{
  switch ($schema_type)
  {
    case "int":
    return (integer)$var;
    break;
    case "boolean":
    return (boolean)$var;
    break;
    case "string":
    return (string)$var;
    break;
    default:
    return (string)$var;
    break;
  }
}

Infine, per testare l’accesso alla struttura gerarchizzata possiamo usare il seguente codice che incolonna, nell’ambito di un file di testo, le informazioni trasferite dal form HTML alla pagina PHP:

$dati_personali = array_map_deep($_REQUEST["dati_personali"]);

echo $dati_personali['nominativo']." ";
echo $dati_personali['eta']." ";
echo $dati_personali['indirizzo']['via']." ";
echo $dati_personali['indirizzo']['civico']." ";
echo $dati_personali['indirizzo']['citta']." ";

L’array $dati_personali mantiene la gerarchia delle informazioni così come l’avevamo definita nel form chiamante. Notiamo infine che qualsiasi modifica alla gerarchia dei dati viene automaticamente assimilata dalla pagina dinamica PHP.

Infine, il codice PHP contenuto in questo articolo può essere combinato con il codice dell’articolo “PHP – Ispezione delle strutture complesse (array e oggetti)” in modo da automatizzare l’accesso ai dati provenienti dal form HTML senza conoscerne la struttura.