Sviluppo applicativi con Ms Access™

Periodico n. 1 - Febbraio 1999 -

Introduzione

Sempre più, aziende e priviati sentono la necessità di informatizzare i processi delle proprie attività lavorative. I problemi più sentiti trovano spesso risposta in un programma gestionale. Programma che, a seconda delle particolari esigenze copre aree di diverso interesse. Lo sviluppatore oggi disponde di numerosi strumenti per sintetizzare e concretizzare le particolari esigenze del cliente.

L'obiettivo di questo periodico sarà di esporre allo sviluppatore alle prime armi, le potenzialità del database relazionale Access, considerando tutti gli aspetti legati allo sviluppo vero e proprio e alla progettazione della struttura dell'applicativo.
L'analisi terminerà con una proiezione delle tecnologie Access su database relazionali di alto livello quali Ms SQL Server™. Verranno infine prese in esame tecnologie di condivisione dati attraverso Server Web (files ASP) su Access e Sql Server.

La versione di Access trattata nel seguito sarà la 97, mentre il SQL Sever farà riferimento alla 6.5 (tra breve alla 7.0)

Durante tutta la trattazione verranno proposti link e testi interessanti per ulteriori approfondimenti sui temi trattati.

... cose da sapere assolutamente !!!

Tanto per sfatare qualche detto popolare mi preme esordire con un bel: "Access non dispone di un compilatore". A molti potrà apparire come una citazione inutile, ma pare che sull'argomento esistano ancora diversi dubbi.
C'è da dire che la versione 97 del prodotto, permette di salvare l'applicativo creato come MDE. Il che ne migliora notevolmente le prestazioni, sia in termini di velocità d'esecuzione che di occupazione di spazio dello stesso file. Inoltre un MDE non è modificabile dall'utente, cosa normalmente molto gradita agli sviluppatori.

Il programmatore ha due strade per distribuire i suoi applicativi; la prima consiste nel distribuire direttamente i files mde (mdb, mda...) necessari per la corretta esecuzione del programma. In queste condizioni però il cliente dovrà possedere una copia di Ms Access per ogni macchina su cui è installato l'applicativo. L'operazione è analoga a quella seguita nella distribuzione di un documento Word o Excel.
Il documento può essere venduto tranquillamente, ma per interpretarlo il cliente dovrà disporre del programma con cui è stato creato.
La seconda strada che uno sviluppatore può decidere di seguire, è quella di distribuire il software in versione Run-Time. Il che significa che grazie ad un gradito Wizard, possiamo creare dei veri e propri dischetti (o meglio CD) d'installazione contenenti tutti i componenti Access (una sorta di Access Lite per intenderci...) necessari al nostro applicativo (oltre ovvimanete ai nostri mdb...).
Ovviamente quest'ultima strada è la più consigliata se vogliano dare al nostro lavoro un'aspetto più omogeneo e professionale. Inutile dire che questa strada ha un costo per lo sviluppatore, che dovrà acquistare quello che nelle versioni precedenti di Access veniva chiamato Access Developer Kit (ADK). Nella versione 97 di Access, l'ADK è stato integrato in Office Professional - Developer Edition, a tutti gli effetti un Office Pro con in aggiunta alcuni utili strumenti di sviluppo.

I limiti di Access sono ben noti, la dimensione fisica di un singolo file non può superare il Gb, avendo però la possibilità di collegare diversi mdb (mde) tra loro questo limite è facilmente sormontabile.
Access permette di realizzare applicazioni File Server, cioè separando l'applicativo dai dati si possono concepire applicazioni distribuite e condivise tra più utenti attraverso una rete. In questo caso il limite consigliato di accessi contemporanei non deve superare le 15 unità.
Altri limiti (di minore utilità per questa panoramica iniziale) sono la mancanza di lock di riga, e di una relativa limitatezza nella gestione delle paginazioni.

Analisi e progetto di un'applicazione

Innanzi tutto è la prima fase che incontriamo nello sviluppo di un'applicazione, a tutti gli effetti è una fase molto delicata e preclude inevitabilmente la buona riuscita di uno sviluppo.

In questa fase normalmente lo sviluppatore incontra una persona con tanti problemi da risolvere e tante idee su come risolverli. A questo punto lo sviluppatore deve cercare di differenziare nettamente i problemi dalle idee proposte dal cliente, questo perchè spesso le idee non tengono conto di aspetti formali e logici dei problemi, finendo per influenzare le analisi dello sviluppatore. Subito dopo un brifieng iniziale col cliente, allo sviluppatore spetta il compito di documentarsi su eventuali particolari procedure (per esempio contabili) necessarie al particolare problema da risolvere.
E' sempre bene cominciare il progetto definendo le tabelle, i campi, gli indici e non di meno le relazioni tra le tabelle, come opportunamente dettagliato nella relativa sezione di questo testo.

La struttura del problema è fondamentale, è bene tracciarne dettagliatamente i particolari su di un foglio di carta prima di cominciare un nuovo mdb.
Una volta assicurati che tutte le funzioni richieste e tutti i dati necessari sono memorizzabili nella struttura creata, allora possiamo cominciare con lo sviluppo vero e proprio.
Modifiche sulle strutture tabellari direttamente nel database si pagano sia in termini di tempo che in termini di futura stabilità e linearità dell'applicazione.

Tabelle e relazioni

La tabella si presenta come una sorta di foglio Excel, le colonne sono identificate dai Campi, mentre le righe dai Valori memorizzati negli stessi campi.

Creando una nuova tabella, ci troviamo a dover dettagliare le caratteristiche dei campi che intendiamo utilizzare, tali caratteristiche sono principalmente:

La chiave primaria, rappresenta quel campo (o insieme di campi) che per ragioni di unicità di valore, deve essere esclusiva nella tabella. Nel caso classico di una tabella anagrafica, troviamo campi quali: Ragione Sociale, Via, Telefono.... e sicuramente Codice Cliente. Tale codice deve ovviamente essere univoco nella tabella così che non possa mai sussistere la codizione di due clienti con uguale codice. Definiremo questo Codice come chiave primaria, in altre parole Codice sarà quel valore utilizzabile per relazionare la tabella Anagrafica con per esempio una tabella Contatti.

In una tabella normalmente esistono campi più soggetti a ricerche e ordinamenti da parte dell'utente. Sempre in riferimento ad una Anagrafica, la Ragione Sociale può diventare un utile mezzo di ricerca all'interno della tabella. Per migliorare le prestazioni di queste ricerche, si definiscono gli Indici.
Esistono Indici a valori Univoci (chiavi primarie) e Indici a valori Dupplicabili.
Troppi Indici appesantiscono la memoria del PC peggiorando le prestazioni dell'applicativo; è quindi un dovere limitarne l'utilizzo ai campi strettamente necessari.

Nell'esempio Anagrafica Cliente-Contatti, si potrebbero adottare le seguenti indicizzazioni:

A questo punto sorge naturale la necessità di relazionare le due tabelle in modo da chiarire al database che i due codici Clienti uniscono a tutti gli effetti le tue tabelle.
Parliamo quindi di Relazioni:
Le relazioni posso essere di diverso tipo:

Le prime indicano una semplice corrispondenza tra due campi di altrettante tabelle, senza però chiarirne il particolare Tipo di Corrispondenza.
In riferimento ai Clienti-Contatti, potremmo dire che ad Un Cliente possono corrispondere Molti Contatti. Ecco che abbiamo preso una relazione Uno-Molti.
Se volessimo migliorare ulteriormente questa relazione, potremmo specificarne le Integrità Referenziali.
Queste sono come la stessa definizione suggerisce, proprietà che garantiscono l'integrità tra due tabelle. Supponendo di cancellare un Cliente, i relativi contatti non avrebbero più senso di esistere, è possibile quindi fare in modo che alla cancellazione di un Cliente, vengano automaticamente cancellati i Contatti associati.

Specificare Integrità Referenziali su tabelle preesistenti può non essere sempre fattibile, è bene innanzi tutto controllare che le regole di integrità per i dati esistenti siano verificare (ed eventualmente correggerle), devono essere anche corrette le definizione degli indici e le corrispondenze tra i Tipi di Campi.
Ovviamente non è possibile relazionare un Campo Testuale con un Campo Numerico...

Access 97 non permette di stampare su carta la struttura tabellare, solo grazie ad alcuni add-in aggiuntivi è possibile ottenere tale funzionalità.

Home Page

webmaster: [email protected]