A ì A A•............................................................................................................•

Teoria e Pratica RelazionaleI conceHi fondamentali

Stiamo assistendo ad una vera e propria esplosione di prodotti di tipo ROBMS(Relational OataBase Management System), prodotti che servono per costruire

applicazionJ~prevalentemente di tipo gestionale, che si appoggiano su più tabellelegate tra di loro da regole relazionali.

Per poter utilizzare al meglio tali prodotti è necessario avere una buona conoscenzadelle teorie relazionali, altrimenti non si riesce a sfruttare tutte le loro potenzialità (dei

prodotti), anzi addirittura si rischia di usarli male fino a rendere inutilizzabilel'applicazione che si realizza.

di Francesco Petroni........................

Sull'argomento Teoria Relazionaleesistono decine di libri, ognuno deiquali in genere si riferisce ad uno spe-cifico «Modello Relazionale», che fauso di terminologie e di simbolismi gra-fici spesso in contrasto con quelli pro-posti per un modello concorrente. Noievitiamo di buttarci nella mischia pro-ponendo argomenti quanto più possibi-le semplici e comprensibili e cercandodi realizzare subito degli esempi pratici,riferendoci a terminologie comuni (equindi non tecniche) ed usando, per lenecessarie verifiche pratiche, qualcheprodotto RDBMS per PC.

Puntualizziamo alcune premesse:- le regole relazionali esistono indipen-dentemente da Il' esistenza dei prodottiRDBMS, dei computer/dell'uomo,- fortunatamente la Teoria Relazionale(che quindi come appena detto «esistein natura») e che come appena detto siesplicita in una serie di Modelli e in unaserie Regole Relazionali, è abbastanzasemplice ed in molti casi intuitiva, percui il suo studio non prevede ostacoliconcettuali insormontabili,- tutti i prodotti RDBMS pretendonoche l'utilizzatore conosca la teoria rela-zio naie, in quanto, nel momento in cuisi esplicitano le relazioni tra le tabelle,fanno uso della terminologia standard,che quindi viene data per nota.

316

Il nostro obiettivo è quello di affron-tare tale teoria, cercando di spiegarlacon parole semplici e con esempi prati-ci, realizzati con vari prodotti.

Il Caso Studio che vi proponiamo èadatto a coprire le principali strutturepresenti nella teoria relazionale. Alcunedi queste sono molto frequenti, altre,invece, lo sono di meno.

Realizzeremo quindi una serie di ta-belle, con pochi campi, in pratica soloquelli che servono per impostare le re-lazioni, e con pochissimi record, giustoper poter controllare l'esattezza del ri-sultato di certe operazioni.

Non ci occuperemo della costruzio-ne delle strutture, dell'immissione deidati, nè delle problematiche relative alcontrollo dei campi.

Ci limiteremo ad esamimare solo icontrolli incrociati derivanti dal fattoche le tabelle sono in relazione tra diloro.

Il Caso Studio riguarda un Databaseche inizialmente sarà così organizzato:- una tabella Numeri, di una rivista cheparla di Informatica,- una tabella Articoli, in relazione con laprecedente tramite il campo numerodella rivista, in cui l'articolo stesso èstato pubblicato.Inoltre l'articolo è identificato da un nu-mero progressivo,

- una tabella Autori, in relazione con laprecedente.La relazione è di tipo Uno a Molti congli autori dal lato uno e gli articoli latomolti,- una tabella Rubriche, cui fanno riferi-mento gli articoli. Anche qui la relazio-ne è di tipo Uno a Molti tra rubriche earticoli.

Useremo successivamente unaquinta tabella Insiemi quando vorremo,ma lo faremo alla fine, ipotizzare cheun articolo possa essere scritto a piùmani.

Dapprima costruiremo queste quat-tro tabelle.

Poi dando per scontato il fatto che letabelle già sono state costruite e riem-pite di dati, le maneggeremo sia con ildBase della Borland che con Access2.0 della Microsoft allo scopo, lo ripe-tiamo, di analizzare solo gli aspetti rela-zionali.

Costui remo poi una piccolissima se-rie di varianti che ci permetteranno dianalizzare dei casi particolari, di più dif-ficile reperimento.

Parleremo infine anche un po' diSOL.

In figura 1 vediamo i dati delle quat-tro tabelle (più una) e nella successivale strutture delle stesse in formatodBase.

MCmicrocomputer n. 146 - dicembre 1994

DATA BASE

Record ISIG INUM IPRG1 DD 101 022 EE 101 023 EE 101 034 FF 101 035 AA 101 056 CC 101 057 BB 102 058 EE 102 059 CC 102 05

righe di dettaglio, delle varie fatture).Altre varianti nascono quando occor-

re individuare le due Tabelle su cui ope-rano le relazioni. Si possono definiredue tipi di relazioni più particolari:- quando esiste una relazione uno amolti all'interno della stessa tabella, sia-mo di fronte ad una Gerarchia (che ve-dremo),- quando esiste una relazione molti amolti tra dati della stessa tabella si haun'ulteriore tabella detta Matrice chiu-sa. Questo è l'unico caso che non ve-dremo.

Se tra due tabelle esiste una relazio-ne le due tabelle assumono dei vincolireciproci che non possono essere viola-ti. I dati delle due tabelle devono, in al-tre parole, essere reciprocamente coe-renti. Deve essere rispettata la cosid-detta Integrità Referenziale.

Nei primissimi prodotti, es. il dBase

ANUM APRG AAUT ATIT ARUB100 01 AA IL PROCESSORE PENTIUM HW100 02 BB PROVA LOTUS 123 SW100· 03 EE PROVA AUTOCAD 13 SW100 04 DD LE API DI WINDOWS WN100 05 DD LE MODALITA' GRAFICHE GR100 06 AA LE SCHEDE SVGA HW100 07 CC I MODEM A 14400 BAUD TM101 01 AA COME SCEGLIERE IL.CLOCK GIUSTO HW101 02 CC I SEGRETI DI INTERNET TM101 03 BB DBASE V PER WINDOWS SW101 04 EE PROGRAMMARE IN LISP GR101 05 BB I NUOVI WORD PROCESSOR SW101 06 AA MODEM PER TUTTE LE TASCHE TM101 07 EE MODELLAZIONE SOLIDA - TEORIA GR101 08 AA I CHIP 64MEGABYTES ? HW102 01 DD I NUOVI PRODOTTI MICROGRAFX GR102 02 AA WINDOWS NT SERVER-WORKSTATION WN102 03 AA IL BUS - TIPOLOGIE HW102 04 DD PROGRAMMAZIONE VISUALE SW102 05 BB ATTERRARE CON FLIGHT SIMULATOR GM102 06 CC COLLEGAMENTI REMOTI TM

111,era l'utente che doveva preoccupar-si, nel realizzare le maschere di immis-sione e di modifica dei dati, anche delrispetto dell'integrità referenziale, e senon lo faceva o non ci riusciva, rischiavadi introdurre nel suo data base dati scor-retti.

Ora sono i più moderni RDBMS cheassumono su di sé il gravoso compitodi eseguire il controllo della correttezzareciproca tra le due tabelle.

Per Integrità Referenziale si intendeuno speciale controllo di congruità deidati ai due lati della relazione. Ad esem-pio in una relazione uno a molti non sipuò eliminare un record nella tabella Ia-to uno se esistono dei record collegatinella tabella lato molti (non si può elimi-nare un autore se esistono suoi articoli),inoltre non si può inserire un nuovo arti-colo se non di un autore già presentenella tabella autori.

SCAP SQLFCC COLLABORATORECC COORDINATOREDD CAPOREDATTORE

DIRETTORECC COLLABORATOREBB COLLABORATOREBB COLLABORATORE

SCOGALBANIBELLINICECCHETTIDONINIERCOLIFERRARIGALENI

RCOD RDESGM GIOCHIGR GRAFICAHW HARDWARESW SOFTWARETM TELEMATICAWN WINDOWS

RCOD RDESGM GIOCHIGR GRAFICAHW HARDWARESW SOFTWARETM TELEMATICAWN WINDOWS

SSIG SNOMAA ALDOBB BIAGIOCC CARLODD DARIOEE ENZOFF FRANCOGG GIANNI

Record123456789

101112131415161718192021

Record123456

Record123456

Record1234567

Figura l -Teoria e Pra-tica Relazionale - I datisu cui lavoreremo.Eseguiremo una seriedi esercizi sviluppati suun Database con quat-tro Tabelle, ma che poiaumenteremo a cin-que. I Numeri di una ri-vista, gli Articoli appar-si nei diversi numeri,gli Autori, scrittori degliarticoli e le Rubrichecui i vari articoli appar-tengono. Le strutturesono molto leggere econtengono solo i cam-pi che servono per im-postare le relazioni. An-che i dati sono pochis-simi, ma significativi,per eseguire efficace-mente le varie prove.Qui vediamo i dati ditutte e quattro le tabel-le, più quelli della quin-ta che vedremo alla fi-ne.

Un po' di terminologie

Un Dabatase è un insieme di Tabellecollegate tra di loro attraverso dei lega-mi logici chiamati Relazioni. Una relazio-ne si basa sulla corrispondenza tra uncampo di una tabella e un campo diun'altra tabella (esistono varianti quan-do il collegamento avvenga attraversopiù campi, o parte di campi).

I tipi principali di relazione sono due:- relazione Uno a Molti, la più diffusa inassoluto. Es. in un numero di MC ci so-no più articoli, uno specifico articolo èpubblicato in un numero di MC, quinditra numeri e articoli c'è una relazioneuno a molti. Es. un autore scrive più ar-ticoli, un articolo è scritto da un autore.- relazione Uno a Uno, meno diffusa.Es. un autore può essere un collabora-tore di MC, un collaboratore è tale se èautore.

Esiste teoricamente anche un altro ti-po di relazione:- relazione Molti a Molti.

Questo tipo, che esiste in teoria, perpoter essere risolto in pratica si DEVEspezzare in due relazioni Uno a Molti.Ad esempio tra numeri della rivista eautori degli articoli c'è una relazionemolti a molti. Infatti un autore può scri-vere più articoli nello stesso numero, esu uno stesso numero hanno scritto piùautori, quindi tra numeri e autori c'è unarelazione Molti a Molti.

La relazione molti a molti si risolve in-serendo una terza tabella, in questoesempio è proprio quella degli articoli,che è in relazione uno a molti sia latonumeri (un numero, molti articoli) sia Ia-to autori (un autore, molti articoli).

Quindi se tra le due tabelle c'è unarelazione molti a molti è necessario,SEMPRE, inserire una terza tabella in-termedia, che in alcune teorie relaziona-li assume il nome molto chiarificatore diMatrice.

Ad esempio tra le Fatture e gli Arti-coli, in un'applicazione di tipo gestiona-le, la relazione è molti a molti (una fattu-ra ha molti articoli, un articolo è presen-te in molte fatture). La tabella interme-dia si potrebbe chiamare dettaglio dellafattura (oppure righe) e sta in relazioneuno a molti con la fattura (una fattura hamolte righe di dettaglio) e con gli articoli(uno stesso articolo è presente in molte

MCmicrocomputer n. 146 - dicembre 1994 317

DATA BASE

Nella box Relazioni esiste anche unpulsante Tipo Join di cui parleremo traun po'.

Alcune operazioni usandoil d8ase standard

In un'applicazione dBase si costrui-scono più file OBF, ognuno dei qualicorrisponde ad una tabella, secondo laterminologia che stiamo utilizzando. Adognuno di questi file si possono asso-ciare degli indici, che sono anche questifile (desinenza NOX), e che servono so-stanzialmente a due cose, a mettere inordine i dati, secondo l'indice, e a faresul file, attraverso l'indice, delle ricer-che veloci.

Tra due tabelle è possibile, con unospecifico comando, stabilire una relazio-ne. La relazione indica il campo dellaprima tabella che punta al campo dellaseconda tabella, che deve obbligatoria-mente essere indicizzata su quel cam-po.

Stabilita così la relazione, quando siscorre la prima tabella viene contestual-mente scorsa la seconda tabella, che siposiziona via via sul primo record corri-spondente.

In pratica si verificano tre possibilità:- che al record della prima tabella corr[-sponda un solo record della seconda. Eil caso in cui la relazione è una Uno aMolti vista dal lato Molti. Nei nostriesercizi è il caso ad esempio della listadegli articoli con l'indicazione della rubri-ca,- che al record della prima tabella corri-spondano più record della seconda. E ilcaso di prima visto dalla parte Uno. Inquesto caso viene puntato il primo deirecord della seconda, per cui occorreràin qualche modo scorrere gli altri. Neinostri esercizi è il caso della lista dellerubriche a ciascuna delle quali corri-spondono più articoli,- che al record della prima non corri-sponda alcun record della seconda. Intal caso la seconda tabella si troverà incondizione EOF, fine file, nessun recordattivo.

In dBase occorre quindi aprire, in va-rie aree di lavoro, le varie tabelle con gliindici necessari, occorre stabilire le rela-zioni, se queste sono sufficienti a risol-vere il problema. Se la relazione non ba-sta occorre spostarsi tra le varie aree ecercare il record voluto, poi se i recordsono un gruppetto e il file è indicizzato,gli altri record risultano essere in se-quenza, per cui è molto facile trovarli.

Un buon utilizzatore di dBase 111 scri-ve con una certa facilità le varie istruzio-ni necessarie a raggiungere lo scopoprefissato.

In figura 4 proponiamo un program-

Prima bisognava costruire, con laprogrammazione, le procedure di con-trollo reciproco, oggi basta indicare alprodotto ROBMS che si desidera l'inte-grità referenziale e si può stare sicuriche non verranno accettati dati scorret-ti.

In figura 3 vediamo appunto il mo-mento della creazione delle relazionicon Access 2.0. Sono ben chiari i colle-gamenti (nei nostri esempi le relazionisono sempre tra due campi) e le loro«direzioni». Per ogni linea occorre poiimpostare alcune specifiche nell'apposi-ta dialog box (in basso a destra nella fi-gura), quindi: campi su cui si basa il col-legamento, il tipo di relazione (i tipi so-no due: Uno a Uno e Uno a Molti), poise si desidera che Access si occupidell'integrità referenziale (in alcuni casipotrebbe non essere necessario). Altredue possibilità sono Aggiorna in succes-sione e Cancella in successione. Se sisceglie quest'ultima opzione è possibilecancellare un record di una tabella e tut-ti i suoi collegati sulla tabella corre lata(es. se si cancella un autore sparisconotutti i suoi articoli). Aggiorna in succes-sione è ancora più micidiale. Si cambiala sigla di un autore e vengono cambia-te tutte le sigle nei record delle tabellecorrelate.

Si tratta come evidente di opzioni da«prendere con le molle» nel senso che,se usate male o per sbaglio, possonoprovocare cancellazioni o modifiche in-desiderate. Nella versione 1.1 di Accessqueste due opzioni non c'erano e quindinon si poteva cancellare un record cheaveva dei record correlati in un'altra ta-bella se non dopo aver cancellato questiultimi.

Figura 2 - Teoria e Pratica Relazionale - Le strutturedevono essere conosciute a memoriaOueste sono le strutture delle nostre cinque tabel-le, espresse in formato d8ase. I campi chiave e gliindici che permettono di costruire più organizzazio-ni logiche sui dati vanno, con d8ase, costruiti e ge-stiti a parte. Una delle più grosse differenze trad8ase e i prodotti più moderni è che i campi chia-ve, identificativi del record, e i campi indice, campisu cui si eseguono operazioni che si vuole veloci,sono definibili direttamente a livello di struttura.

Figura 3 - Teoria e Prati-ca Relazionale - L'impo-stazione delle Relazionicon Access 2.0.Per le prove useremo idue prodotti situabili alleestremità della tecnolo-gia RD8MS. Da una par-te il d8ase 111,con il qua-le costruiremo una seriedi programmini che ma-nipoleranno i dati, prele-vandoli dalle varie tabel-le, dall'altra l'Access2. O, in cui si lavora sustrutture, relazioni,query, ecc. sfruttando almeglio /'interfaccia grafi-ca. Sono in dirittura diarrivo altri prodotti, dipari categoria rispettoad Access 2.0, d8ase Ve Paradox 5. O della 80r-land, tanto per non farenomi, e li proveremo an-che dal punto di vista re-

lazionale non appena ci arriveranno. Oui vediamo la semplicità con cui si definiscono, graficamente, le rela-zioni in Access.

Struttura del file , D,ARTICOLI. dbfNumero totale record 21Data ultima revisione: 18/10/94Campo Nome campo Tipo Dim Dee

l ANUM Carattere 32 APRG Carattere 23 AAUT Carattere 24 ATIT Carattere 305 ARUB Carattere 2

Totale: 40

Struttura del file , D,RUBRICHE.dbfNumero totale record , 6Data ultima revisione: 18/10/94Campo Nome campo Tipo Dim Dee

l RCOD Carattere 22 RDES Carattere 10

Totale: 13

Struttura del file D,AUTORI.dbfNumero totale record 7Data ultima revisione: 18/10/94Campo Nome campo Tipo Dim Dee

l SSIG Carattere 22 SNOM Carattere 123 SCOG Carattere 124 SCAP Carattere 25 SQLF Carattere 14

Totale: 43Struttura del file D,RUBRICHE.dbfNumero totale record 6Data ultima revisione: 18/10/94Campo Nome campo Tipo Dim Dee

l RCOD Carattere 22 RDES Carattere 10

Totale: 13Struttura del file , D, INSIEMI .dbfNumero totale record , 9Data ultima revisione: 18/10/94Campo Nome campo Tipo Dim Dee

l ISIG Carattere 22 INUM Carattere 33 IPRG Carattere 2

Totale: 8

318 MCmicrocomputer n. 146 - dicembre 1994

DATA BASE

Figura 4 - Teoria e Pratica Relazionale - Caro vecchio dBase 111.Tutto ciò che si può ottenere con i nuovi strumenti «servocomandati" presenti nei prodotti delle ultimissi-me generazioni, lo si poteva già ottenere lO anni fa usando il dBase 111,o dal prompt dell'applicazione, op-pure realizzando dei programmini il cui scopo era quello di assemblare una serie di istruzioni, che permet-tessero sostanzialmente di passare da una tabella all'altra e di scorrere i record di una tabella.

rtUIlERI COli ARTICOLI E RUBRICA

100 91 IL PROCESSORE PEltt IlJl HU HARDWAREOZ PROVA LOros lZ3 su SOFtWARE03 PROVA AUtOCAD 13 SW SOFtWARE01 LE API DI WI"DOWS W" WI"DOWSOS LE "ODALIrA' GRAFICHE GR GRAFICA06 LE SCHEDE SUGA HU HARDWARE07 I noDEIt A 11100 BAUD m tELEllATlCA

101 al COltE SCEGLIERE IL CLOCK GIUSTO HW HARDWAREOZ I SEGRETI DI l"tEHIIEt tn tELEllATlCA03 DBASE V PER WI"DOWS SW SOFtWARE01 PROGRAnlfARE I" L ISP GR GRAFICAOS I ItUOVI WORD PROCESSOR su SOFtWARE06 "ODEIt PER rottE LE tASCHE tn tELEllATlCA07 noDELLAZIOIiE SOLIDA - tEURIA GR GRAFICA08 I CHIP 61nEGABY1ES 7 HW HARDWARE

19Z 01 I "lJOVl PRODOttI nlCROGRAFX GR GRAFICAOZ WI"DOWS n1 SERVER-WORKS1AtIDn W" WInDOWS03 IL 8US - TlPOLOGIE HW HARDWAREai PROGRAnlfAZlOIiE VISUALE SW SOFtWARE05 AttERRARE COIt PLIGH1 SIIlULATOR GlI GIOCHI06 COLLEGAllEltTl REItlITI tn 1ELEltATlCA

wait " QUARTA ELABORAZIONE

" TERZA ELABORAZIONE"iLitCLEAll ALL

CLEAll? "LA GERARCHIA"?USE AUTORI INDE AUTORIDO WHlLE .NOT. EOF()

? SSIG,SCOG,SQLFss-senRP-RECNO8UK 8Sli" .NOT. EOFO

?? SS,S8IG,SCOG,SQLFENDIFGO RPSKIP

ENDDOCLEAll ALL

CLEAll1 "ARTICOLI A QUATTRO MANI"?USE ARTICOLI INDE ARTICOLISBLECT 4U8E RUBRICHE INDE RUBRICHESELECT 3USE AUTORI INDXX AUTORISELECT 2USE INSIEMI INnO INSIEMI:SET RBLATION TO ISIG INTO CSELECT 1SET RBLATION TO ARUB INTO DDO WHlLE .NOT. EOF()

KK-ANUM+APRGAA-ANUMTT-ATITRR-ARUBSELECT 2SEEK KKFL-1DO WHlLE KK-lNUM+ IPRG

IF FL-l? AA,TT ,RR,D->RDES ,ISIG,C->SCOG,C->SNOMFL-O

ELSE? SPACE(4B) ,ISIG,C->SCOG,C->SNOM

ENDIFSKIP

ENDDOSELECT 1SKIP

ENDDOCLEAll ALL

ENDIFSKIPENDDO

ENDIFSELECT 1SKIP

ENDDOCLEAR ALL

'1 ti ",APRG,ATIT,ARUB,C->RDES

CLEAR ALL" PRIMA ELABORAZIONE

wu t "SECONDA ELABORAZIONE

CLEAll? "NUMERI CON ARTICOLI :E RUBRICA"?USE NUMERISELECT 2USE ARTICOLI INDEX ARTICOLISELECT 3USi: RUBRICHE INDEX RUBRICHESELECT 2SE'l RELATlOR TO ARUB INTO CSELECT 1DO WHlLE .NOT. EOF()

? llllUKNN-1lllUKSELECT 2FL-1SEEK NNIl' .NOT. EOFO

DO WHlLE NN-ANUMIl' FL-l

11" ",APRG,ATIT,ARUB,C->RDESFL-O

ELSE

CLEAll? "LE RUBRICHE E GLI ARTICOLI"?USE RUBRICHE INDEX RUBRICOSELECT 2USE ARTICOLI INDEX ARTICOL2SELECT 3USE AUTORI INDEX AUTORISELECT 2SE'I" ULATION 'lO AAUT INTO CSELECT 1DO lfHlLE .NOT. EOF()

? RCOD,RDESKK-RCODSELE 2SEEK KKFL-1DO WHlLE KK-ARUB

Il' FL - 111 " ",ARUB,ATIT,AAUT,C->SNOM,C->SCOGFLooO

ELSE? SPACE(14) ,ARUB,ATIT,AAUT,C->SNOM,C->SCOG

ENDIFSKIP

ENDDOSELECT 1SKIP

ENDDO

Figura 5 - Teoria e Pratica Relazionale -Elenco dei Numeri e degli Articoli.Questa e le prossime tre figure costi-tuiscono il risultato delle quattro elabo-razioni previste in sequenza dal pro-gramma di cui abbiamo visto il listato.La prima mostra i vari numeri con ildettaglio degli articoli del numero edelle rubriche cui gli articoli apparten-gono. Uno a Molti tra Numeri e Artico-li, e tra Rubriche e Articoli. Ce la cavia-mo con due cicli 00 WHILE... ENo00. uno dentro l'altro. Quello esternoscorre i numeri, quello interno scorregli articoli, a parità di numero. La rubri-ca è fornita dal comando SET RELA-nON, che permette in pratica di vede-re come fossero campi dell'articolo an-che i campi delle rubriche (perché ci sitrova sul lato Molti della relazione).

ma che esegue quattro elaborazioni dif-ferenti, che lavorano sui nostri dati, ilcui risultato è mostrato nelle successi-ve quattro figure (dalla 5 alla 8, ma della8 parliamo dopo).

Mostriamo nella tabella di figura 9 leprincipali istruzioni utilizzate. Nel listatoci sono molte altre istruzioni che servo-no in pratica solo per realizzare l'outputdei vari sottoprogrammi.

C'è da dire che il dBase III ha avutomolte evoluzioni, sia in termini di servo-comandi (l'Assist, il generatore diQuery, ecc.) che facilitano la scritturadelle varie istruzioni (ma in fondo ci so-no sempre i comandi puntino), sia intermini di nuove istruzioni (es. SET SKIPON/OFF del dBase IV) che migliorano leoperazioni relazionali.

Passiamo ad Access 2.OIn Access 2.0 il lavoro iniziale consi-

ste nel definire le strutture delle varietabelle (operazione che non vediamo).Rientrano nella definizione della struttu-ra la definizione dei singoli campi e ditutte le loro caratteristiche, ad esempioquale sia il campo chiave (identificativodel record), quali campi si vuole che sia-no associati ad indice (con o senza con-trollo dell'univocità), quali siano le even-tuali regole di validazione del dato im-messo, e così via.

Definite le tabelle occorre definire lerelazioni, operazione che si eseguenell'ambiente grafico già visto in figura3.

A questo punto il database è prontoall'uso, ma prima di usarlo è bene fareuna serie di precisazioni:- in dBase ed in Access sono ovvia-mente possibili chiavi complesse, adesempio quelle realizzate combinandodue campi. Non le vediamo nei nostriesempI,- mentre in dBase si creano tabelle edindici che rimangono fisicamente sepa-rati (sono file differenti), in Access tuttoil database, tabelle ed indici, dati, e tut-to il resto, rientra in un unico filone(grosso file) con desinenza MDB,- mentre in dBase è l'utente, o il suoprogramma, che si deve spostare dauna tabella all'altra, da un indice ad unaltro, in Access le cose si svolgono au-tomaticamente. Se si ricerca un datotramite una condizione su un campo ese su quel campo c'è un indice è Ac-cess che si posiziona su tale indice. Sesi aprono più tabelle si possono usaredati provenienti da tutte le tabelle, inquanto sono le relazioni definite che alli-neano correttamente i loro record,- in Access esistono in pratica due tipidi relazioni, quelle fisse, che rimangonoattive in ogni situazione, che servono a

MCmicrocomputer n. 146 - dicembre 1994 319

DATA BASE

LE RUBRIOlE E GLI ARTICOLI

GlI GIOCHI GlI ATTERRAJIE con FLIGHT SIIlULATOR BD BIAGIOGR GRAFICA GR LE ItODALIJA' GRAFIClIE DD DARIO

GR PROG_RE I" LISP EE EItZOGR ItODELLAZllJIIE SOLIDA - TEORIA EE EItZOGR I ItUOUl PRODOTTI HICROGRAFX DD DARIO

HlI HARDWA/lE HW IL PROCESSORE PEHTlUII AA ALDOHlI LE SClIEDE SUGA M ALDOHW COHE SCEGLIERE IL CLOCJ( GIUSTO M ALDOtIl I OlIP 6111EGABYtES 7 AA ALDOH\I IL BUS - TlPOLOGIE M ALDO

SW SOFTWARE SW PROVA LOWS lZ] BB D IAG IOSW PROUA AUTOCAD 13 EE EHZOSW I IlUDVI IIORD PROCESSOR BB BIAGIOSW DBASE V PER WI"DOlIS BB BIAGIOSW PROGRAMAZIOHE VISUALE DD DARIO

m TELEMTlCA T" I IUlDEH A liiOO BAUD cc CARLOm I SEGRETI DI l"tERHET cc CARLOm ItODEH PER TUTTE LE TASClIE AA ALDOT" COLLEGMEnT I REnOTl cc CARLO

WH WInDOWS W" LE API DI WI"DOWS DD DARIOW" WI"DOWS "t SERVER-WORJ<STATlO" M ALDO

BELLI"IDO"I"IERCOLIERCIlLIDO"I"IALBAItIALBAItIALBAItIALBAItIALBAIIIBELLI"IERCOLIBELLI"IBELLI"IDOIH" ICECCHETTICECCHETTIALBAIIICECCHETTI

DO"I"IALDAIII

Figura 6 - Teoria e Pra-tica Relazionale - Elen-co delle Rubriche e de-gli Articoli.In questo secondo ca-so si scorre la tabellalato Uno della relazio-ne. Per ogni elementolato Uno (in pratica perogni Rubrica) si cerca ilprimo articolo di quellarubrica e si scorronosolo gli articoli con lostesso codice di rubri-ca (che sarebbero iMolti). Anche in questocaso arricchiamo l'arti-colo con informazioniprese da un 'altra tabel-la. Quelle degli Autori.

merico potrebbe essere «Between 100And 200»,- controllo sulla chiave. Se un campo èdefinito come chiave oppure è comecampo indice senza duplicazioni risul-terà impossibile inserire un record cheabbia la stessa chiave di un record giàinserito,- controllo referenziale. È il controllo, ci-tato prima, che verifica la congruenzadai due lati di una relazione,- controllo da macro o programma. Nel-la scheda che serve per l'alimentazionedelle tabelle è infine possibile inseriredelle procedure (o Macro o procedureclassiche, che si costruiscono nell'am-biente Modulo) che vengono eseguiteal verificarsi di un evento, tipicamentel'evento «su disattivazione» ovveroall'uscita dal campo.

I tipi di JoinÈ possibile definire il tipo di Relazio-

ne in due modi differenti.Il primo modo parte dalla finestra

Prepariamo una QueryEseguito il lavoro di preparazione di

tabelle e relazioni, il successivo lavoroè assolutamente facilitato. Nella figura10 vediamo come si costruisce unaOuery, in pratica, attivato il comandoOuery Nuovo, viene proposto l'elencodelle tabelle (e delle altre query) utiliz-zabili. Se si scelgono tabelle già legateda relazioni, tali relazioni appaiono an-che graficamente. A questo punto sipossono scegliere i campi desideratiprendendoli da qualsiasi tabella, inquanto è Access che sfrutta i «sentie-ri» tracciati dalle relazioni per prelevarei dati corrispondenti.

Anche qui facciamo una serie di pre-cisazioni:- esistono più tipi di query. Ouella chevediamo è quella più usata, la Ouery diSelezione. Le altre non le vediamo, an-che se sono altrettanto interessanti,- è possibile, ma anche questo non lovediamo, scegliere campi, imporre cri-teri di selezione, inserire campi calcola-ti, definire regole di raggruppamento edi ordinamento, ecc.,- in caso di necessità, come detto, èpossibile definire delle relazioni «volan-ti» ,- Access salva la Ouery secondo la sin-tassi SOL (lo vediamo in figura 11). Ilcomando SOL può essere copiato edincollato da altre parti, ad esempio inuna macro o in una procedura, per as-sociarlo ad un pulsante, oppure in unaapplicazione Visual Basic 3.0 cheanch'esso riconosce SOL e lavora su fi-le MDB.

CAPOREDATTORECOORD IItATORECDORD IItATORE

CAPOREDATTORECAPOREDATTOREDIRETTORE

DAR IOEHZOE"ZOFRAHCIlALDOCARLOBIAGIOEHZOCARLO

COLLABORATORE cc cc CECCHETTICOORDIItATORE cc cc CECCHETTICAPOREDATTORE DD DD DOItI"1DIRETTORECOLLABORATORE cc cc CECCHETTICOLLABORATORE DB BB BELLI"ICOLLABORATORE BB BB BELLI"I

numero, può essere inserito solo un da-to coerente con il tipo,- controllo sulla maschera di immissio-ne. È possibile assegnare una «picture»come caratteristica del campo che quin-di funziona come filtro in fase di inseri-mento. Ad esempio il codice fiscale cheha 6 caratteri alfabetici, due numerici,ecc., può essere sottoposto a questo ti-po di filtro,- controllo eseguito dalle regole di vali-dazione. Ad un campo è possibile asso-ciare una regola di validazione. Adesempio una regola per un campo nu-

AA ALBAIIIBB BELLI"Icc CECCHETTIDD DOItI"1EE ERCOLIFF FERRAR IGG GALEnI

LA GERARCH lA

TH TELEltATlCA DD DOItI"1EE ERCOLI

SW SOFTWARE EE ERCOL IFF FERRARI

SW SOFTWARE M ALBAIIIcc CECCHETTIBB BELLI"IEE ERCOLIcc CECCHETTI

18Z ATTERRARE con FLIGHT SIIIlLATOR GlI GIOCHI

101 I SEGRETI DI I"TEMET

ARtiCOLI A QUATTRO _I

181 I ltUOU I WORD PROCESSOR

Figura 8 - Teoria e Prati-ca Relazionale - E se gliautori dell'articolo fos-sero due.Se gli autori dell'articolofossero due la strutturache abbiamo disegnatoper il nostro Databasecrollerebbe come un ca-stello di carte. Tra Auto-ri ed Articoli abbiamo fi-nora ipotizzato un rap-porto Uno a Molti. Seinvece lo stesso articololo hanno scritto in due

passiamo in una situazione Molti a Molti, che va obbligatoriamente gestita con una tabella intermedia. Noil'abbiamo chiamata Insiemi.

Figura 7 - Teoria e Pratica Relazio-naie - La gerarchia negli Autori.Supponiamo che un Autore abbiauna sua caratterizzazione (collabo-ratore, coordinatore, caporedattoree direttore) e abbia (eccetto il diret-tore) un superiore. Quindi nellastruttura della tabella abbiamo sia ilcodice dell'autore (che è il campoindice principale, altrimenti dettoChiave), sia il codice del suo supe-riore. Questo codice è in relazionecon il campo chiave della stessatabella. In dBase 111,per vederel'elenco degli Autori con il dettaglio dei loro capi, siamo costretti a scorrere una volta la tabella, e, poi indivi-duo per individuo, a cercare nella stessa tabella il superiore. Per tornare al punto di partenza si può memo-rizzare il numero del record al quale si era arrivati (lo fornisce la funzione RECNO()).

far funzionare il data base, e che sonoquelle che si definiscono con il coman-do Modifica Relazioni (visto in figura 3).Se ne possono creare altre «dinami-che», di tipo usa e getta, all'interno diuna Ouery semplicemente tracciandouna linea tra i campi su cui creare la cor-rispondenza. Usa e getta perché vivonosolo all'interno della Ouery.

Un altro aspetto che a questo puntoè bene puntualizzare riguarda i tipi dicontrollo eseguiti da Access:- controllo sul tipo di campo. Se si è de-finito un tipo di campo, es. data, oppure

320 MCmicrocomputer n. 146 - dicembre 1994

DATA BASE

Figura 9 - Teoria e Pra-tica Relazionale - Tabel-la con i principali co-mandi dBase da usarein problematiche rela-zionali.

ISTRUZIONI dBASE SIGNIFICATO

CLEARALL chiude tutte le tabelle, ed altro, es.le variabili.

USE XXXX INDEX YYYY aore un file e un suo indice.

SELECTY soosta l'area di lavoro attiva.

SEEKX cerca nella tabella attiva, su cui è attivo unindice, il orimo record la cui chiave sia X

SET RELATION TO X INTO Y stabilisce una relazione tra il campo X dellatabella attiva e la tabella aperta nell'area dilavoro Y. Questa deve essere statapreventivamente aperta e deve essereindicizzata sul camDo di corrisoondenza.

Y->nomecampo sintassi per utilizzare un campo del recordattivo di una altra area di lavoro.

DO WHILE .NOT. EOF() struttura di programmazione che serve perfar scorrere tutta la tabella fino al verificarsi...della condizione di file file (si verifica oltre

SKIP l'ultimo record).ENDDODO WHILEX=Y scorre dal record attivo (trovato con SEEK)

... fino quando X=Y, in genere fino a quando lachiave della tabella attiva è uguale a quella

SKIP che si sta cercando. Questo metodo si usaENDDO quando si scorre il versante moiti di una

relazione Uno a Molti.

basso verso l'alto: collaboratore, coordi-natore, capo redattore, direttore) e cheogni autore di una categoria sia sottopo-sto ad un altro autore di categoria supe-riore (non necessariamente), può na-scere il problema di gestire e/o di visua-lizzare questa gerarchia.

Da un punto di vista relazionale la ta-bella autori è in relazione Uno a Molticon se stessa: un capo ha più sottopo-sti, un sottoposto ha un solo capo. Macapi e sottoposti risiedono nella stessaTabella. Il problema si può facilmente ri-solvere creando una query che utilizzapiù volte la stessa tabella e tracciando amano le linee che rappresentano i colle-gamenti.

Nel nostro esempio, ben chiarito dal-la figura 13, abbiamo aperto quattro vol-te la tabella Autori, e abbiamo collegatoil campo SCAP, codice del capo, della

••

•

,.••

AAUTARTICOLI

RDESRUBRICHE

ARUBARTICOLI

di 21

ATITARTICOLI

Tìì2'~ SElECT DISTlNCTROW NUMERI.NNUM. NUMERI.NMES. ARTICOU.ATIT.._- ARTICOLl.ARUB. RUBRICHE.RDES. ARTICOLl.MUT. AUTORI.SCOG.1Q?FROM RUBRICHE INNER JOIN (AUTORIINNER JOIN (NUMERIINNER JOIN ARTICOLI

ON NUMERI.NNUM = ARTICOLl.ANUM] ON AUTORI.SSIG = ARTICOLl.MUT] ONRUBRICHE.RCOD = ARTICOLl.ARUB;

NMESNUMERI

APAGARTICOLI

•

c.nw NNUMT_ NUMERIFOIInlM:

O,dMl1let"llo:ModlO:

QitelCOppute;

.1

Figura IO - Teoria ePratica Relazionale -Come si prepara unaOuery in Access 2. O.In Access 2.0 le tappedel lavoro sono bendelineate. Prima si co-struiscono le Tabellepoi si definiscono leRelazioni.A questo punto sipossono immettere idati, che vengonocontrollati sia dalle re-gole di validazione in-terne alla tabella, defi-nite a livello di struttu-ra, sia dalle regole divalidazione dovuteall'avere opzionato ilrispetto della IntegritàReferenziale.Non ci si deve quindipiù occupare del con-trollo reciproco dei da-ti tra le due tabelle.

Ouando si costruisce una Ouery le relazioni definite appaiono fisicamente rappresentate da linee.

Figura Il -Teoria e Pra-tica Relazionale - Il latoSOL della Ouery.Access 2.0 memorizzala query, impostatadall'utente nell'ambien-te ObE, nel formatostandard SOL. Il co-mando così creato, inquesto caso si tratta diuna query che lavora evisualizza i dati di tuttee tre le tabelle, può es-sere visto in una sua fi-nestra, in cui può esse-re scritto, da chi prefe-risse farlo, invece diconfezionarlo con ObE.Il comando si può an-che copiare per farloeseguire ad esempio inuna procedura attivatada un tasto, o per esse-re trasferito in VisualBasic che è anche que-sto in grado di eseguirecomandi SOL.

La gerarchiaSupponendo che gli autori apparten-

gano ad una categoria (per ipotesi e dal

Relazione, in cui c'è un pulsante speci-fico (tipo di Join), il secondo modo siattiva eseguendo un doppio clic sulla li-nea che evidenzia la relazione tra duetabelle.

Appare una box, il cui contenuto èpersonalizzato nel senso che cita diret-tamente le due tabelle oggetto della re-lazione, che mostra tre varianti:1 - per far apparire solo i dati che rispet-tano la corrispondenza (sono presenti intutte e due le parti),2 - per far apparire anche i dati della pri-ma che non hanno corrispondenti nellaseconda,3 - per far apparire anche i dati della se-conda che non hanno corrispondentinella prima.

Se eseguiamo tali varianti con le no-stre tabelle Autori ed Articoli:- nel primo caso vediamo tutti gli artico-li, con i loro autori,- nel secondo caso vediamo tutti gli ar-ticoli, con i loro autori, più tutti gli autoriche non hanno articoli,- il terzo caso corrisponde al primo, masolo perché l'imposizione della integritàreferenziale impedisce di avere articolisenza autori.

Se si volesse l'elenco degli autoriche non hanno scritto articoli (oppure inuna tabella Clienti analizzare i clienti chenon hanno fatto ordini) basta inserire uncriterio «Is Null» in un qualsiasi campodella tabella correlata. Lo si può farenella variante 2. In Access «Is Null» si-gnifica campo vuoto, oppure non trova-to se si sta «pescando» in una tabellacorrelata.

MCmicrocomputer n. 146 - dicembre 1994 321

DATA BASE

La Uno a Uno, ma che cosa èEsistono due soli tipi di relazione. Il

primo, l'Uno a Molti, è il più diffuso e loabbiamo visto nelle sue numerosesfaccettature. Il secondo, che è moltomeno diffuso, è l'Uno a Uno. Lo spie-ghiamo con un esempio. Supponiamoche l'insieme dei nostri autori sia costi-tuito da due sottoinsiemi, i giornalistiinterni alla rivista, detti Redattori e iCollaboratori esterni, e supponiamoche di questi due sottoinsiemi sia ne-cessario memorizzare informazioni dif-ferenti. Occorrerà in pratica costruirenecessariamente altre due tabelle,quella dei Redattori e quella dei Colla-boratori, ciascuna delle quali è in rap-porto Uno a Uno con quella degli Auto-ri. Per il rispetto dell'integrità refe re n-ziale un collaboratore deve già esserememorizzato come autore mentre unautore può essere un collaboratore mapuò anche non esserlo.

In altre parole l'insieme degli Autorisi divide in due sottoinsiemi, Collabora-tori e Redattori.

Access 2.0 permetté di definire que-sto secondo tipo di relazione con lestesse modalità con le quali si defini-sce il primo, e anche da un punto di vi-sta grafico la visualizza correttamente(fig.14l.

Il vincolo è che esista un campo dicorrispondenza e che questo camposia chiave di ambedue le tabelle.

Per quanto riguarda l'utilizzo dellaUno a Uno, è del tutto analogo alla Unoa Molti, come evidenziato dalla querymostrata in figura 15, in cui elaboriamodati provenienti dalle tre tabelle (perl'occasione abbiamo alleggerito la strut-tura di quella degli autori, in quanto al-cuni dei dati ora risiedono sulle altredue tabelle).

In sostanza vogliamo realizzare unelenco di Autori con dettagli provenien-ti dalla tabella Redattori, se l'autore èun redattore, e con dettagli provenientidalla tabella Collaboratori, se l'autore èun collaboratore esterno.

Anche in questo caso, non essendo-

seconda con il campo chiave della pri-ma, SCAP della terza con il campo chia-ve della prima, e così via. Stiamo in pra-tica utilizzando la prima come tabelladei Direttori (per fortuna ce ne è unosolo), la seconda come tabella dei re-dattori, e così via.

La freccia sulla linea significa che ab-biamo scelto un tipo di Join che mostracomunque i dati della seconda tabella diogni relazione (variante 3).

Il risultato mostrato nella finestra èchiarissimo e non necessita di ulteriorichiarimenti.

. , ,

..Finestra 1

Figura 12 - Teoria ePratica Relazionale - Al-Ia ricerca dei ... lavativi.Il tipo di relazione piùdiffusa è la Uno a Mol-ti. Ad esempio quellatra i nostri Autori e i lo-ro Articoli, in cui un au-tore ha più articolimentre un articolo èscritto (per ora) da unsolo autore. Se è statoimpostato il rispettodell'integrità referen-zia le non possono esi-stere articoli scritti daautori non memorizzatinella tabella. Possonoesistere invece autoricui non corrispondonoarticoli (nei nostriesempi sono Ferrari eGaleni). Si possono fa-cilmente trovare sfrut-tando una vanante del-la relazione.

SSIGSNOMSCOGSCAPSQLf

(!li

Campo; UNO. SCOG DUE. SCOG TRE: SCOG UATTRO SCOG NOME: SNOMhbela. AUTORI AUTORI 1 AUTORI 2 AUTORI 3 AUTORI 3

O,liMmento;Moslfa:

C,~eri:OpplMe:

•

COLlABORATOR Il AUTORI I l'il.'[)J\TTOflLSSIG . . • ,,1 SSIG

SNOM ~~CAP I SNOMSCOG SQLF SCOGSCAP SCAPSTEL SINT

Elle

Figura 14 - Teoria e Pra-tica Relazionale - La re-lazione Uno a Uno - De-finizione.La seconda tipologia direlazione è la Uno aUno, la spieghiamo conun esempio.Supponiamo che l'insie-me dei nostri autori siacostituito da due sot-toinsieml, igiornalisti in-terni alla rivista e i colla-boratori esterni.Se di questi sottoinsie-mi è necessario memo-rizzare informazioni dif-ferenti occorre costruirealtre due tabelle, quelladegli interni e quella de-gli esterni, ciascuna del-le quali è in rapportoUno a Uno con quelladegli autori. Per il ri-spetto dell'integrità re-ferenziale un collabora-

tore DEVE già esistere come autore mentre un autore può essere anche un collaboratore.

Figura 13 - Teoria ePratica Relazionale - Lagerarchia completa.Se si suppone che tragli autori esista una ge-rarchia (ad esempio,dal basso verso l'alto:collaboratore, coordina-tore, capo redattore,direttore) può nascereIl problema di gestiree/o di visualizzare que-sta gerarchia. Da unpunto di vista relazio-naie la tabella autori èin relazione Uno a Mol-ti con se stessa: un ca-po ha più sottoposti,un sottoposto ha unsolo capo. Ma capi esottoposti risiedononella stessa Tabella.

-I Microsoft Access - Querv di selezione: Ouerv~ ~- file Modifico ~suallzza ll.uery finestra 1 I;

1~114'II!!DI[;[I)limiICilWI~;]I\lijììiilf/I"+I"1<1 ~IW Q ~AUTORI ARTICOU

.SSIG \ NllJNSNOM N'RGSCOG MUTSCAP ATITSOLf ARUB

rA •.'151m,

Campo; SCOG ATIT O 1; Includere aoItanto i fecord in cui i campi coIlegaliQ,dirwJmento:Modra: provenienti da entrambe le tabete tono uguai

Cr~eri: IsNtA(Equijoin).

OpplJfe: (i) !Z,;llncludefelulli i record di 'AUTORI' Il 1010 i record di'ARTICOLI'in cui i campi colegati sooo ~ti (ioine.lo.no).

O 1: Includo,. lutti i ,ecOId di 'ARTICOLI' Il .010 irecord di'AUTORI' in cui i CfUllpi coUegati tono uguali lioinIIlle,no).

+J, c::E:J I Annulla I +

P,ontO li ilMArrl'

322 MCmicrocomputer n. 146 - dicembre 1994

DATA BASE

ci (e non potendoci essere) corrispon-denza tra i dati di tutte e tre le tabelle,ma solo corrispondenza a due a due,occorre scegliere un tipo di relazioneche consenta la visualizzazione degliautori anche se non sono collaboratorie degli autori anche se non sono redat-tori.

Infine risolviamouna Molti a Molti

Uno degli errori più frequenti, che sicompiono quando si costruisce un'ap-plicazione, consiste nello sbagliare unarelazione (ad esempio il suo tipo) equesto, se l'applicazione viene già uti-lizzata, è un errore gravissimo e spessoirreparabile.

Supponiamo di avere già costruito lanostra applicazione in cui esistono unatabella Autori e una tabella Articoli. Tra

Autori Numeri

100 101 102 103Albani · · ·Bellini · · ·Cecchetti · · ·Doninl · ·Ercoli · ·Ferrari · ·Galeni ·

MATRICE TRA NUMERI E AUTORI

Figura 16 - Teoria Relazionale - Relazione Molti aMolti.La rappresentazione grafica di una relazione Molti aMolti è una matrice, che tralaltro chiarisce moltobene le cose. Ad esempio, ipotizzando che un auto-re possa scrivere un solo articolo per numero, pos-siamo affermare che un autore scrive su molti nu-meri, mentre su un numero scrivono molti autori.Ouindi Molti a Molti. Dal punto di vista pratico unarelazione Molti a Molti si risolve SEMPRE creandouna tabella intermedia, che la spezza in due relazio-ni Uno a Molti. Nel nostro esempio è chiaro che latabella intermedia è quella degli Articoli Un articoloè scritto da un autore, è pubblicato in un numero, epoi ha sue caratteristiche specifiche, come il titoloo la rubrica cui appartiene. Ouesta schematizzazio-ne diventa sbagliata nell'ipotesi che un autore scri-ve più articoli nello stesso numero.

informazioni non significative dal puntodi vista relazionale). Ad uno stesso au-tore possono corrispondere più articoli,ad un articolo più autori.

Nella Query Access che esplora taleulteriore caso (fig. 17) viene anche evi-denziata la relazione tra articoli ed insie-mi, basata su due campi. Nella finestravediamo a galla l'elenco degli articolicon i vari autori. È chiaro che questonon impedisce agli autori di scrivere ar-ticoli da soli. I questo caso c'è un solorecord nella tabella Insiemi. In altre pa-role una relazione Molti a Molti com-prende, per così dire, anche i casi Unoa Molti.

autori ed articoli c'è una Uno a Molti,ma solo se un articolo è scritto sempreda un solo autore. Se questo non è ve-ro in quanto ogni tanto, magari rarissi-mamente, un articolo viene scritto dadue autori, la relazione diventa Molti aMolti: un autore più articoli, un articolopiù autori.

Allora: quando si analizza il databasesu cui si basa un'applicazione si devefare, su ogni relazione, una specie diesame di coscienza per capire a qualetipo di relazione ci si trova di fronte. Seè di tipo Molti a Molti può sempre es-sere molto ben esplicitata con una ma-trice (fig. 16).

Nel caso in esame, ovvero un artico-lo scritto da più autori, il rapporto traautore e articolo fa nascere una terzatabella, che chiamiamo Insiemi, in cuic'è l'identificativo dell'autore e l'identi-ficativo dell'articolo (più eventuali altre

SSIGSCAP5 LF

I

~lsu8I1zZ8 !luery Finestra 1

Prorto

SSIGSNOMSCOGSCAPSTEL

Cempo: SIGLA: SSIGTabeIa: AUTORI

Orti1emerto:Moslta:

Criteri:Oppure:

Figura 15 - Teoria ePratica Relazionale - Larelazione Uno a Uno -Utilizzo.Nella figura precedenteabbiamo visto comeappaiono in Accessdue relazioni uno auno. Ora le utilizziamoper costruire un elencodi autori con i dati deicollaboratori, se l'auto-re è un collaboratore, ocon i dati degli interni,se si tratta di giornalistiinterni. Poiché un inter-no non può essereesterno i tipi di relazio-ne debbono consentirela visualizzazione deidati che non corrispon-dono in tutte e tre letabelle. Si deve usareuna variante del Join.

Figura 17 - Teoria ePratica Relazionale - Gliarticoli scritti a quattromani.In prima approssima-zione, lo abbiamo pre-cisato anche nel testo,abbiamo anche suppo-sto che un articolo ab-bia un solo autore, ilche corrisponde ad unarelazione Uno a Moltitra autori e articoli. Mase ora ipotizziamo chel'articolo possa esserescritto da più autori larelazione diventa Moltia Molti (un articolo piùautori, un autore più ar-ticoli). Va creata ((perforza)} una tabella inter-media. La nostra lachiamiamo Insiemi.

Campa ANUM APAG ISIG SNOM SCOG ATITOrdi1amento: Crescenle uetcenle

Most,a:Cr~erj:

OPPlMe:

ConclusioniL'obiettivo dell'articolo era quello di

spingere gli utilizzatori dei prodottoRDBMS allo studio delle problematicherelazionali, che vanno padroneggiateconcettuaimente, e di verificare chetutti i prodotti, dal dBase I1I in poi, invarie maniere, riescono a fronteggiarlee quindi a risolverle praticamente.

Per quanto riguarda i modelli relazio-nali e le relative problematiche, li abbia-mo analizzati quasi tutti, e abbiamoconstatato come risolverle con dBaseIII e con Access 2.0. Ci ripromettiamodi provare a risolvere gli stessi proble-mi anche con gli altri prodotti. Sarà an-che l'occasione per un ripasso degliaspetti teorici.

MCmicrocomputer n. 146 - dicembre 1994 323