Un giorno un Guru con la G maiuscola, proprio come il suo nome di battesimo, mi disse: “Mah, io farei una banalissima autorelazione, un campo calcolato e una semplice ricerca per *. O c’è qualcosa che mi sfugge?”.

Ora vi racconto cosa si nasconde dietro questa enigmatica frase.

Il problema dei record non univoci

La mia situazione era la seguente. Ipotizziamo di avere la seguente serie di record:

immagine 1La mia necessità era trovare tutti i record contenenti i nomi di quelle persone che, pur ripetendosi più volte, avevano numeri diversi. Nell’esempio sopra riportato si trattava quindi di trovare i 4 record contenenti il nome "Pietro", in quando il numero di telefono associato non era lo stesso per tutti e 4 i record. Non avevo però bisogno di trovare “Luca” o “Marco”, in quanto pur ripetendosi più volte questi ultimi avevano numeri di telefono univoci.

Il risultato che dovevo ottenere era questo:

immagine 2Come potevo fare?

Da parte mia avevo già messo in pista mirabolanti comandi “loop”, “trova”, etc. Avevo pensato: trovo tutti i record i cui nomi si ripetono con il comando “!”, poi metto in ordine per nome, faccio un bel loop e faccio passare uno ad uno i record, prendo per ogni record la variabile del nome chiamandola $nome, prendo la variabile del telefono chiamandola $telefono, vado al record successivo e se $nome = nome vedo se $telefono = telefono. Se uguale vado oltre, se diverso metto un flag in modo tale da riprendere il nome una volta finito il loop per poi ritrovare tutti i record con i nomi flaggati.

Insomma, un bel casino fatto e finito.

La parola al Guru

Ma ecco che il Guru appare e mi dice “...fare una bella relazione no?”.

Ecco a cosa alludeva:

immagine 3Oltre alla relazione, il Guru mi ha fatto aggiungere un campo calcolato che ho chiamato “chiave ricerca”, con appunto valorizzare il contenuto del campo “telefono” nella tabella autorelazionata. In altri termini, in uno specifico campo valorizzare i numeri telefonici a parità di nome con numero di telefono diverso (vedi sopra).

Il campo “chiave di ricerca” è stato così impostato:

immagine 4

A questo punto il gioco è fatto. Facendo una semplice ricerca inserendo il valore “*” nel campo “chiave ricerca” (ovvero cerco qualsiasi valore), ho ottenuto il risultato sperato.

immagine 5

In conclusione

Qual è l’insegnamento che possiamo trarre da questa piccola storia?

Prima di tutto, quello di valutare le relazioni in modo più ampio di quanto normalmente siamo abituati a fare. Non limitiamoci a pensare che una relazione tra due tabelle serva solo ad associare in modo canonico i relativi record (ad esempio, fattura e righe fattura, insegnante e alunni, etc.). Le relazioni possono rivelarsi utilissime anche per fare ricerche, magari sulla stessa tabella tramite autorelazione.

Teniamo presente inoltre che le relazioni si possono basare, oltre che sull’uguaglianza di due campi di confronto, anche su altri operatori. In termini più espliciti, oltre alla classica relazione campo A tabella 1 = campo B tabella 2 Filemaker offre la possibilità di mettere in pista relazioni del tipo campo A tabella 1 < campo B tabella 2, oppure campo A tabella 1 x  campo B tabella 2.

L’elenco degli operatori disponibili è qui di seguito riportato:

immagine 6
Come dicono i veri Guru, sforziamoci di usare le relazioni al meglio! Rendono più elegante ed efficace il nostro database, e soprattutto ci permettono di risparmiare tanto tempo e fatica. Senza contare che una relazione è quasi sempre più veloce di una ricerca, perché sfrutta indicizzazioni già esistenti.

Alle prese con un problema insormontabile in FileMaker? Raccontaci il tuo caso e trova la soluzione con il supporto degli altri Guru: scopri la comunità Filemaker su Guru Corner!

4 Commenti

  1. Il metodo è molto interessante, mi domando se può essere usato per risolvere un problema analogo.
    Se sia cioè possibile trovare sovrapposizione nella tabella delle prenotazioni di un albergo.
    Esempio.
    Data la tabella prenotazioni in un albergo coi campi:
    id, nome cliente, data arrivo, data partenza, camera

    e la prenotazione:
    25, Bianchi, 15/07/15, 25/07/15, camera

    Che arriva dopo che sono state accettate le seguenti:

    01, Rossini, 09/07/15, 16/07/15, 302
    . . .
    11, Verdini, 23/07/15, 03/08/15, 301
    . . . .

    È evidente che iIl sig. Bianchi non può occupare né la camera 301 né la camera 302
    perché già impegnata dalle prenotazioni 01 e 11.
    Come scoprire questa sovrapposizione utilizzando le relazioni, ed eventualmente una ricerca?

  2. Buongiorno, Salvatore.
    li la problematica è più complessa, in quanto il calcolo deve escludere tutti i periodi sovrapposti.
    abbiamo affrontato un problema molto simile nel guru corner, nella domanda con titolo "Lista Valori con contenuto variabile":
    https://www.filemakerguru.it/gurucorner/lista-valori-con-contenuto-variabile/?backlink=L2d1cnVjb3JuZXIvP3NlYXJjaD1saXN0YSt2YWxvcmk&ajax=1

    Se hai bisogno di suggerimnti possiamo continuare sul GuruCorner, nel qual caso è meglio aprire una nuova domanda che continuare un argomento già chiuso. 🙂
    a presto.

  3. Salve, grazie per la collaborazione,
    no, non manca alcuna relazione, la quarta che hai elencato è compresa nella prima.
    L'algoritmo è corretto, non so se è corretto tutto il resto, anche se i risultati
    sembra che lo siano, a parte la sospetta anomalia.
    Per l'utilizzo dei campi calcolati hai ragione, nei miei tentativi ero partito
    da lontano e alla fine mi sono portato appresso questi campi calcolati che
    non servono a nulla.
    Con il tuo suggerimento lo schema si semplifica:

    La Tabella "Prenotazioni" è così composta:

    n. 4 campi :

    DataArrivo (data), DataPartenza (data),
    idAppartamento (testo ), iDPrenotazione (testo univoco)

    n. 4 campi calcolati per il conteggio dei record trovati dalle 3 relazioni

    conteggioR1=Conteggio(R1::nFile)
    conteggioR2=Conteggio(R2::nFile)
    conteggioR3=Conteggio(R3::nFile)
    conteggioR=conteggioR1+conteggioR2+conteggioR3

    Le 3 autorelazioni sono le seguenti:
    R1
    DataArrivo > DataArrivo
    DataArrivo < DataPartenza
    idAppartamento = idAppartamento
    idPrenotazione idPrenotazione

    R2
    DataPartenza > DataArrivo
    DataPartenza <= DataPartenza
    idAppartamento = idAppartamento
    idPrenotazione idPrenotazione

    R3
    DataArrivo <= DataArrivo
    DataPartenza <= dPartenza
    idAppartamento = idAppartamento
    idPrenotazione idPrenotazione

    ---------------------------------------------------------------------
    Le altre considerazioni e il comportamento di FM resta lo stesso.
    I campi Conteggio restano vuoti ma le prenotazioni doppie vengono rilevate
    correttamente.
    Cosa c'è che non va?

    • Risolto, dopo tanto clamore un banale errore, la tabella di riferimento dei campi Conteggio era sbagliata per cui i campi inseriti nel report non potevano che essere vuoti, mentre era giusta nella formattazione condizionale, che funzionava come doveva.
      Una consolazione, il sistema delle 3 auto-relazioni funziona perfettamente.
      Per chi può essere interessato sono queste:
      R1
      DataArrivo > DataArrivo
      DataArrivo < DataPartenza
      idAppartamento = idAppartamento
      idPrenotazione idPrenotazione

      R2
      DataPartenza > DataArrivo
      DataPartenza <= DataPartenza
      idAppartamento = idAppartamento
      idPrenotazione idPrenotazione

      R3
      DataArrivo = DataPartenza
      idAppartamento = idAppartamento
      idPrenotazione idPrenotazione

      I segni di confronto tengono conto del fatto che l'appartamento deve essere liberato al mattino e può essere occupato solo dal pomeriggio in poi. Nello stesso giorno, e nello stesso apprtamento, si possono avere quindi arrivi e partenze.

LASCIA UN COMMENTO

Please enter your comment!
Please enter your name here