FileMaker Pro è un ambiente di sviluppo che contiene al proprio interno un database relazionale, ovvero una base dati che consente di creare legami, detti appunto relazioni, tra entità del database chiamate tabelle.
Un database relazionale, se ben progettato, consente di gestire i dati in modo coerente, riducendone al minimo le ridondanze.
Supponiamo di avere una tabella contenente l’anagrafica clienti e una tabella contenente i preventivi: com’è facile intuire, ogni preventivo deve essere intestato a un cliente. Se il nostro sistema database non fosse in grado di gestire le relazioni, avremmo dei problemi a costruire una procedura che riporti nei preventivi i dati della tabella anagrafica senza doverli ricopiare. Procedura che, potendosi avvalere di una relazione, è estremamente semplice: per stabilire una relazione occorre individuare un criterio unificante che permetta di associare i dati delle due tabelle. Questo elemento si chiama chiave.
Quando creiamo una tabella in FileMaker, è decisamente consigliato definire un campo che identifichi i record in modo inequivocabile. Il modo più semplice è di creare un campo numerico e impostarne le opzioni di auto-inserimento e di verifica in modo che il sistema gli assegni una sequenza auto-incrementante e un vincolo di convalida che ne verifichi l’univocità.
Questo tipo di campo viene definito chiave primaria o PK (primary key). In genere una chiave primaria non deve mai essere modificabile dall’utente: per questo motivo spesso non viene nemmeno mostrata, nei formati scheda.
La presenza di una chiave primaria in ogni tabella, tuttavia, non è sufficiente a impostare una relazione: per associare un preventivo a un cliente, dovremo disporre di una chiave che dovrà contenere l’identificativo cliente anche nei preventivi. Questo tipo di chiave si chiama chiave esterna o FK (foreign key).
Dal momento che abbiamo definito la chiave primaria come campo numerico, per creare una chiave esterna è sufficiente creare nella tabella Preventivi un campo numerico. A differenza della chiave primaria, la chiave esterna non deve avere sequenze, perché riporterà un dato definito in un’altra tabella, e in questo caso non richiede un vincolo di univocità, perché potremmo avere più di un preventivo intestato allo stesso cliente.
A questo proposito, apriamo un brevissimo excursus sulle principali tipologie di relazione presenti nei sistemi relazionali.
Relazioni 1:1: una relazione uno a uno impone che a un record nella tabella di partenza corrisponda al massimo un record nella tabella di destinazione. Pensiamo al nostro archivio Clienti: una relazione con un’ipotetica tabella Condizioni di pagamento sarebbe di tipo uno a uno. A ogni record della tabella Clienti può essere associata una sola condizione di pagamento standard.
Relazioni 1:n: una relazione uno a molti, invece, consente di associare a un record della tabella di partenza uno o più record della tabella di destinazione.
Questo è il tipo di relazione più comune: venendo al nostro esempio, la relazione tra Clienti e Preventivi rientra in questa casistica (a un cliente possono essere intestati molti preventivi).
Relazioni n:m: questo tipo di relazione, detta “molti a molti”, è meno frequente e richiede un po’ di lavoro extra per essere gestita correttamente. Pensiamo a una gestione abbonamenti: una persona può abbonarsi a più riviste e, al contempo, è auspicabile che una rivista abbia più di un abbonato. Solitamente questo tipo di relazione non viene gestita direttamente dagli strumenti nativi dei database relazionali. Esistono tuttavia delle prassi codificate per gestire queste situazioni in maniera corretta, che avremo modo di esaminare in seguito.
Primi passi con le relazioni
Ora che abbiamo creato le due chiavi primarie e la chiave esterna, abbiamo tutto ciò che ci serve per impostare la nostra prima relazione. Accediamo alla gestione del database tramite File > Gestisci > Database…, spostiamoci nel grafico relazionale, selezioniamo la chiave primaria dalla tabella Clienti e trasciniamo il mouse verso Preventivi, indicando come destinazione la chiave esterna: la relazione è stabilita.
Se facciamo doppio clic sull’icona posta a metà strada della linea che ora unisce Clienti e Preventivi, FileMaker ci mostrerà la finestra dei dettagli relazione. Possiamo notare come le opzioni siano presenti per entrambe le tabelle. Questo accade perché, in FileMaker, le relazioni sono bidirezionali: ciò significa che, avendo impostato una relazione tra Clienti e Preventivi, nello stesso tempo ne abbiamo impostata una tra Preventivi e Clienti. Quindi, senza che sia necessario definire due relazioni distinte, potremo richiamare i dati del cliente quando intestiamo il preventivo e, al contempo, potremo vedere tutti i preventivi del cliente direttamente dalla scheda anagrafica.
Diamo una rapida occhiata alle opzioni aggiuntive che FileMaker ci mette a disposizione nella definizione della relazione.
La prima opzione è “Consenti la creazione di record in questa tabella tramite questa relazione” che, se attivata, abiliterà la creazione diretta di record correlati attraverso istruzioni script come Imposta campo e strumenti come i portali. Questi ultimi mostreranno una riga vuota in ultima posizione, la quale diventerà un record correlato non appena inseriremo un dato in un campo.
La seconda opzione è “Elimina i record correlati in questa tabella quando un record viene eliminato nell’altra tabella”. Questa è un’opzione molto importante dal punto di vista dell’integrità referenziale: se attivassimo questa opzione dal lato dei Preventivi, faremmo in modo che, eliminando un cliente, FileMaker eliminasse tutti i preventivi a esso collegati. In molte circostanze l’utilizzo di questa funzionalità tiene i nostri database al riparo da situazioni che renderebbero inconsistenti i nostri dati, come la presenza di preventivi che non fanno capo a nessun cliente.
Tuttavia le funzionalità di eliminazione in cascata vanno usate con molta prudenza e, soprattutto, dobbiamo prestare attenzione ad attivare l’opzione dal lato corretto. Se ci sbagliassimo e attivassimo l’eliminazione dalla parte dei clienti anziché dai preventivi, finiremmo per trovarci in una situazione sicuramente incresciosa: eliminando un preventivo, elimineremmo anche il cliente dall’anagrafica.
La terza e ultima opzione è “Ordina i record”, che regola il modo in cui i record correlati vengono prelevati dal database. È importante non confondere l’ordinamento assegnato alla relazione con l’ordinamento che possiamo assegnare all’oggetto portale: l’impostazione sulla relazione agisce alla fonte e influenza il comportamento di qualsiasi elemento (formula, istruzione script ecc.) che richieda l’accesso a un record correlato, mentre l’ordinamento del portale agisce su uno specifico oggetto del formato scheda. Possiamo infatti creare due portali identici e porli l’uno accanto all’altro assegnandogli ordinamenti diversi: i dati verranno mostrati in ordine diverso ma solo dopo essere stati prelevati dal database nell’ordine impostato nella relazione. Se lasciamo disattiva l’opzione della relazione, i record correlati verranno richiamati in ordine di creazione.
Mostrare i record correlati
Vediamo ora come realizzare una semplice procedura di intestazione.
Prima di tutto spostiamoci in un formato scheda basato su Preventivi e posizioniamo la chiave esterna, ovvero il campo id_cliente della tabella Preventivi, sul formato scheda. Aggiungiamo quindi, i campi del cliente che riteniamo corretto mostrare, ad esempio ragione_sociale e partita_iva.
Selezioniamo File > Gestisci > Liste valori… e creiamo una lista che prelevi i valori dalla tabella Clienti, usando i valori di id_cliente come primo campo e di ragione_sociale come secondo, ovvero quello che sarà visualizzato dall’utente. Dal momento che il campo non è significativo per l’utente, selezioniamo l’opzione “Mostra valori solo dal secondo campo” come in figura.
Torniamo in formato scheda, associamo la lista valori alla chiave esterna e formattiamo il campo come lista a tendina: ora l’utente si vede proporre una lista di nominativi perfettamente comprensibili mentre il meccanismo di base della relazione continua a funzionare.
Naturalmente, una procedura di intestazione come questa è adatta soltanto a situazioni con pochi nominativi: se la nostra lista valori dovesse contenere migliaia di nominativi, si renderà necessario adottare un approccio diverso, che però esula dagli scopi di questo articolo.
Relazioni multicriterio e non equijoin
L’esempio di relazione appena descritto presuppone un criterio per parte, messo in relazione tramite un operatore di uguaglianza: possiamo vedere, infatti, un piccolo “=” in mezzo alla linea che unisce Clienti con Preventivi. Ma FileMaker non si limita a gestire questo tipo di situazioni: possiamo creare relazioni che confrontano più di una coppia di criteri per volta e, al contempo, possiamo utilizzare operatori come “>”, “<“, “≠” (diverso da) e via dicendo.
Quando la nostra relazione attiva il confronto su due o più coppie di campi, siamo in presenza di una relazione multicriterio (o multi-predicato). In questo caso il confronto è di tipo AND: supponendo che la relazione stia usando due coppie di campi, perché la relazione sia valida, è necessario che entrambe le coppie siano valide.
Selezioniamo File > Gestisci > Database… e aggiungiamo due campi alla tabella Clienti: g_data_inizio e g_data_fine. Entrambi i campi saranno di tipo data e dovranno essere definiti con modalità di memorizzazione globale: questo perché serviranno soltanto come filtri e non dovranno contenere dati veri e propri. Ricordiamo infatti che, in FileMaker, un campo globale contiene lo stesso valore per tutti i record e si comporta quindi come una variabile, ma con la possibilità di poter essere incluso in una relazione.
Spostiamoci nel grafico relazionale, duplichiamo la ricorrenza di tabella Preventivi e chiamiamola “PREVENTIVI_CLI_periodo”. Tracciamo quindi una relazione da Clienti: come prima coppia di criteri, utilizziamo sempre id_cliente = id_cliente. Aggiungiamo poi altre due coppie: la prima sarà g_data_inizio ≤ data_preventivo, mentre l’altra sarà g_data_fine ≥ data_preventivo. In questo modo potremo visualizzare tutti i preventivi del cliente su cui ci troviamo che siano stati emessi nell’intervallo di tempo indicato dai due campi globali.
Passiamo in formato scheda, posizioniamo i globali e il nuovo portale, confermiamo e facciamo qualche verifica: se tutto funziona come deve, cambiando il periodo di riferimento dovremo vedere i cambiamenti riflessi nel portale dei preventivi.
___________________________________________________
800×600
Continua la lettura su Applicando Magazine per vedere come risolvere le relazioni uno a molti e multikey.
Clicca qui per scaricare l’applicazione gratuita Applicando+ Puoi acquistare la
rivista e leggerla e conservarla sul tuo iPad.
Normal
0
14
false
false
false
IT
X-NONE
X-NONE
MicrosoftInternetExplorer4
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Tabella normale”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:”Times New Roman”,”serif”;}
