|
Tables |
| 1.36 Esempio di struttura anagrafica basata sulla tecnica dei pattern |
| Luca Dall'Olio |
|
Questa struttura di anagrafica rappresenta una possibile implementazione in Access di una struttura dati suggerita da David C. Hay in "Data Model Patterns, Conventions of Thought" (Dorset House Publishing, isbn 0932633293) A partire da "A Pattern Language" di Christopher Alexander (Oxford University Press New York, isbn 0195019199) fino a "Design Patterns" di Gamma et. alt. (Addison Wesley isbn 0201633612 e recentemente tradotto anche in italiano) i pattern hanno fatto il loro ingresso nel mondo della progettazione. Con pattern si intende una soluzione nata dall'esperienza rivolta ad un problema specifico. Un pattern deve avere un nome e devono essere documentate le caratteristiche positive, negative e i collegamenti verso altri pattern. Dei pattern sono normalmente forniti esempi pratici di utilizzo. Mentre nel mondo della programmazione sono stati prodotti centinaia di pattern, per le basi di dati il libro di Hay rappresenta il primo tentativo di presentarne alcuni nati dalla sua esperienza ventennale di progettista in basi di dati. Dato che i pattern sono dei concetti universali, indipendenti dalla tecnologia mi e' sembrato interessante provare a realizzarli in Access. I primi tre capitoli del libro trattano dell'impresa e del suo mondo e descrivono come modellare i dati e le relazioni che vengono genericamente detti "di anagrafica". La speranza e' che questa struttura si dimostri piu' espressiva e riutilizzabile delle soluzioni normalmente costruite con meno progettazione, magari prevedendo da subito la possibilita' di gestire relazioni piu' complesse delle solite tabelle clienti e fornitori. Ho implementato le casistiche piu' complesse indicate nel libro, ma la struttura puo' essere semplificata se non necessaria. Come tutti i codici basati su pattern, resta comunque semplice "complicare" in modo ordinato la struttura al crescere delle esigenze, cosa che invece generalmente per mia esperienza sporca i data model progettati in modo troppo "personalizzato". Questo nasce anche dal semplice fatto che l'informatizzazione della struttura segue spesso l'organizzazione cartacea preesistente e, con gli anni, se ne svincola aumentando le proprie richieste di flessibilità. Spesso ho visto rifiutare una commessa o costringere a stravolgimenti del codice perché la situazione richiesta non era esprimibile dalla base dati e questo puo' essere un argomento contro l'ovvia accusa di troppo entusiasmo espressivo (detto anche "mettere le mutande al mondo"). Ulteriori e meglio espresse considerazioni si trovano nel libro. Dato che una struttura dati dovrebbe essere versatile e un programma semplice, l'idea del libro e' di avere una struttura adeguata e anche complessa, lasciando il compito all'interfaccia utente di renderne semplice la gestione. Per questo ho provato ad implementare anche le maschere. La convenzione che ho usato e' di denominare le tabelle in tbl... le maschere in frm... e le sottomaschere in sfrm... Ho mantenuto di proposito i nomi usati nel libro per semplificarne il confronto, mentre l'interfaccia e' in italiano sottolineando che e' lo strato di presentation a dover trasofrmare i nomi prodotti dall'analisi. Il diagramma delle relazioni puo' essere ordinato, come consiglia lo stesso Hay, mettendo le entita' "lato 1" piu' a destra di quelle "lato molti", purtroppo il diagramma delle relazioni perde nelle conversioni questo ordinamento. Per abitudine personale ho estratto tutti i valori del genere "tipo di ..." in una tabella a parte, per sfruttare l'integrita' referenziale. D'altronde, la frase "tipo di" sottintende per definizione un concetto e non un dato, quindi merita spesso una tabella a se'. Si legga a proposito il paragrafo "about types" del terzo capitolo. Viene introdotto il concetto di Party (tblParty) come insieme di tutte le "persone fisiche" (tblPerson) e "persone giuridiche" (tblOrganization). Si noti la relazione 1:1 tra tblParty/tblPerson e tblParty/tblOrganization, a indicare che una Person e' un Party e cosi' e' un' Organization. Ne segue un modo abbastanza elegante per esprimere tramite integrita' referenziale quando un concetto vale solo per le persone fisiche, solo per le organizzazioni o quando vale per entrambi indistintamente. Il legame "rapporto di lavoro" (tblEmployment) viene espresso da una relazione "molti a molti" tra Person e Organization. Un'azienda ha molti collaboratori e una persona puo' avere piu' rapporti di lavoro anche contemporaneamente con diverse aziende. In molti contesti e' inoltre piu' importante (ai fini dello stipendio, dei poteri e delle responsabilita') il ruolo ricoperto dalla persona che la persona stessa. A volte le aziende assegnano i loro collaboratori ad altre aziende, spesso temporaneamente, quindi l'incarico deve essere possibile anche verso un'impresa diversa da quella con cui si e' stabilito il rapporto di lavoro (per esempio assegnando un collaboratore ad un'azienda cliente). Questo e' un'applicazione del principio detto a volte "conta la sedia e non la persona che ci si siede". Ancora, una persona mantiene l'assegnamento solo in virtu' del suo rapporto di lavoro con l'impresa. Questa relazione e' percio' espressa da un assegnamento (tblPositionAssignment) di un Employment (e non di una Person) ad una posizione (tblPosition) definita da un'Organization. Dato che una persona puo' avere contemporaneamente diversi incarichi, PositionAssignment e' un pivot nella relazione "molti a molti" tra Person e Position. Ho aggiunto un mio concetto personale : l'idea di riferimento generico (tblReference), utile visto il proliferarsi di campi nella vecchia tabella degli indirizzi che, se trattati come colonne, devono prevedere maschere enormi per essere gestiti magari solo per una persona su 100, senza tenere conto che di ogni dato possono essere richiesti piu' valori, soprattutto da quando oltre ai 3 cellulari sono comparsi 4 email, web site, icq, skype, ... Il concetto di collocazione fisica e' affrontato tenendo conto che una persona puo' avere piu' domicilii anche contemporaneamente (casa, sede di lavoro, vacanze, trasferte) e un'impresa avere piu' sedi e cantieri, realizzate tramite la relazione molti a molti (tblPlacement) tra Party e il Site (tblSite). Le gerarchie geografiche (comune, provincia, diocesi, parco, ...) sono descrizioni importanti al fine di ricerche e selezioni ma spesso non esplicitate nella struttura dati. Inoltre, i raggruppamenti non sono sempre gerarchici (per esempio il rapporto tra i comuni, decisi dallo stato, e le diocesi, decise dalla Curia o gli Atenei, decisi dalle universita') ed ecco quindi una relazione molti a molti (tblGeographicStructureElement) tra le collocazioni geografiche (tblGeographicLocation) che descrivono dove si trovano uno o piu' siti (tblSite). Il concetto generico di relazione vale sia per le persone (rapporti di parentela, appartenenza a club) che per le imprese (gruppi di societa', consorzi, distretti, ...) e anche misti (contratti di consulenza) e vengono quindi genericamente definiti tra due Party. Quando poi si vuole rappresentare anche il rapporto tra dipartimenti nelle strutture pubbliche, si nota che questa in realta' e' una relazione molti a molti tra i Party e le loro relazioni (tblReportingRelationship). Una volta descritta la struttura dati, le maschere dovrebbero risultare abbastanze chiare : frmPerson descrive le persone fisiche, frmOrganization quelle giuridiche e frmLocation permette di definire le geografie di interesse. Le relazioni uno a molti sono spesso realizzate con combo box e quelle molti a molti con subform. Non e' stato praticamente usato codice e questo per me e' un buon segno per la struttura dati, dato che i pattern di interfaccia disponibili in access realizzano in maniera naturale tutte le relazioni necessarie senza necessita' di "trucchi di programmazione". Ho inserito dati che spero siano significativi e mostrino come i problemi affrontati siano piu' comuni di quanto possa sembrare dal numero complessivo di tabelle. Non commento le singole maschere perche' spero siano intuitive... Il libro ha 12 capitoli. Download: |
