[talk] DBMS: OMNIA - Omnia Manager Not Interface Adapter

[talk] DBMS: OMNIA - Omnia Manager Not Interface Adapter

By Mario Rossano (‎Anak‎)
Date: Thursday, 22 October 2009 14:10
Duration: 40 minutes
Target audience: Any
Language: Italiano
Tags: archive automation database dbms office parametrico repository software

You can find more information on the speaker's site:


di Mario Rossano
software@netlogica.it;analyst@horizonsrl.net
346 336 16 24; 081 764 80 96

Source code
http://www.netlogica.it/omnia/makenetleg.cgi.txt per creare un’istanza di OMNIA
http://www.netlogica.it/omnia/netleg0.cgi.txt codice parametrico cui manca la definizione del record, stabilita tramite makenetleg
http://www.netlogica.it/omnia/netleg.cgi.txt una particolare istanza

Cos’è
OMNIA, è un database autosufficiente, 100% Perl è un DBMS programmato parametrizzando il codice sorgente.

Approfondimento
OMNIA sopperisce all’uso di sistemi database (ad es. basati su query a MS SQL Server o altri), in modo da avere un sistema “autosufficiente”, integrando anche le funzionalità di client di rete per le interrogazioni, poiché comprende e genera anche il supporto per il login degli utenti (oltre che una completa gestione utenti con diversi livelli di privilegio), le maschere di ricerca, inserimento, modifica ed altro ancora.

La parametrizzazione del codice permette di definire istanze del software database in luogo di tanti software che gestiscono la banca dati specifica. Esiste quindi un “OMNIA 0” parametrico, cui manca la subroutine di configurazione (array o hash di array di hash) ed un “MakeOMNIA” che permette di definire puntualmente la struttura dati che si vuole gestire (ovvero la subroutine di configurazione).

Questa è stato scelto di scorporarla dal corpo del software principale poiché si è inizialmente optato per non fornire, all’utente amministratore, il privilegio di creare e gestire n database non preordinati dallo sviluppatore.
Questa opzione è peraltro immediatamente e naturalmente implementabile integrando “MakeOMNIA” direttamente in “OMNIA0”.

E’ possibile effettuare interrogazioni anche complesse (il codice parametrico legge su quali campi effettuare ricerca e/o ordinamenti ed anche quanti di questi vincoli, a cascata, possano applicarsi): le maschere del software si genereranno di conseguenza.

E’ possibile associare anche n files ai records oltre che di personalizzare l’aspetto grafico.

Per sua natura il source code OMNIA è “autoadattante”, anche tramite l’utilizzo di funzioni eval, per generare, a runtime, il codice che necessita in funzione della particolare configurazione (istanza) creata. Quindi OMNIA non solo ha il file dati definito da vettori n-dimensionali, ma lo stesso codice sorgente è “generato” tramite funzioni legate agli stessi parametri, rendendo illimitato il numero di istanze e configurazioni possibili.

E’ possibile quindi gestire:

- X tabelle di Y campi a lunghezza variable e di vari tipi
- Un qualsiasi campo può essere collegato ad altro campo, anche di altra tabella, ottenendo un database relazionale oltre che normalizzato (se si ha la cura di costruire bene le relazioni)

Il sistema è multiutente, con possibilità di specificare diversi privilegi per le diverse classi utente; presenta un modulo “log” per leggere le operazioni fatte sui records; lavora su http e quindi sia su intranet che su internet.

Fisicamente il database è costituito da flatfile per cui le modalità di ricerca, coerenza e controllo dei dati sono affidati al codice progettato.

Il risultato di questo lavoro di parametrizzazione è uno strumento complesso e potente ma di semplice utilizzo che, oltre a velocizzare lo sviluppo di applicazioni che gestiscono basi dati di qualsivoglia genere, riduce anche la sensibilità del codice agli errori: una subroutine che genera il controllo per un campo, se esente da errori, può essere istruita a gestirne anche 100, restando necessariamente esente da errori.

Dalla configurazione parametrica si stabilisce tutto:
- Quante tabelle ha il database
- Quanti campi ha la tabella di database
- La tipologia dei campi
o testo
o testo multi riga
o Data
o data attuale
o file binario
o a scelta tra una determinata lista
o a scelta tra i valori di un altro campo (ad esempio, un campo utente, con gli “user” accreditati)
- Quali campi si visualizzano nel risultato sintetico di ricerca
- Quanti risultati si visualizzano per schermata di ricerca
- Quali campi vengono utilizzati nei filtri di ricerca
- Quali campi risultano obbligatori (autogenerando i relativi controlli)
- In funzione del tipo dato, viene inoltre prodotto il relativo controllo di coerenza, ad evitare immissioni anomale

Tutto questo ovvero la gestione, virtualmente, di ogni possibile database, parametrizzando il codice, si è ottenuto con sole 3500 righe di codice.

Importante:
Tra le diverse possibilità offerte da OMNIA, c’è quella di fornire in output anche files strutturati in XML. Questo ha enormi possibilità di applicazione nel mondo web2.0 poiché permette di costruire e gestire la base dati per qualsiasi applicazione sviluppata mediante AJAX, su Adobe Flash oppure in altro linguaggio di scripting. PERL compreso: purché legga dati XML, OMNIA ha la possibilità di candidarsi a “pannello di controllo”.
Integrate ad OMNIA ci sono diverse inoltre routine secondarie per:
- Definire il template grafico utilizzato dal sistema
- Definire l’indirizzo email per le comunicazioni all’amministratore in quanto a:
o Nuove registrazioni
o Accessi non autorizzati
? A questo proposito è presente un log accessi ed azioni svolte da ogni utente che tiene traccia della data ed orario dell’operazione svolta sul determinato record e da quale indirizzo IP
- Gestione completa utenti
- Copie di backup
- Routine di ripristino
- Gestione delle eccezioni
o Si tratta di quei casi particolari, richiesti nella quasi totalità dei casi dal committente, vuoi per una particolare rappresentazione, vuoi per una gestione specifica mediante interfaccia ad un preesistente gestionale, ecc. ecc. Per tutti questi casi viene costruita la subroutine “exception(integer)” che viene chiamata, dal punto dello script in cui si vuole l’elaborazione specifica, in modo da non intaccare l’algoritmo parametrico e contemporaneamente avendo tutte le eccezioni ben ordinate


Perché ho scritto OMNIA
La storia di OMNIA è quella, come spesso capita, di una commessa su cui si lavora di più, come investimento, per creare qualcosa di migliore, di riutilizzabile.
In breve, mi contattarono un noto magistrato del Tribunale di Napoli ed un professore di Giurisprudenza. I due avevano in progetto la costruzione di una testata tecnico-legale che, per necessità di contenimento dei costi, avrebbe avuto una redazione distribuita geograficamente. Mi fu chiesto di progettare un software con determinate caratteristiche e cioè:
- Utilizzabile in rete LAN come su web
- Multiutente, con diversi livelli di privilegio
- Che permettesse di archiviare dati, soprattutto testi ma anche files allegati, con semplicità
I record avrebbero contenuto gli articoli e relativo stato di avanzamento (oltre agli allegati, ad es. sentenze passate in giudicato), fino allo status di “pubblicato”.

I redattori, ognuno con il suo compito associato al relativo privilegio, avrebbe seguito l’iter dell’articolo.
La scelta del linguaggio più adatto fu subito quella del Perl, per le sue indubbie peculiarità di trattamento delle stringhe, il potente motore delle espressioni regolari, la possibilità quasi “naturale” di lavorare come CGI risolvendomi, in una volta, le idiosincrasie della comunicazione di rete.
L’idea dei committenti circa la struttura del record era però quanto mai vaga. Pensai che non avevo alcuna intenzione di riscrivere, ad ogni cambio di idea, le subroutine di lettura, scrittura, come pure di ricerca. Mi orientai così sulla programmazione di uno script che producesse il software al posto mio: un vero e proprio passo indietro, esasperando il livello di generalizzazione del progetto.


Nasce così “netleg” (ribattezzato OMNIA), parametrico, in modo da poter gestire le più disparate tabelle impiegando solo il tempo di definizione dei parametri di lavoro: poche righe nelle quali si imposta tutta la struttura del record, se ci sono allegati e quanti ad ogni record, tipo dei campi, quali sono obbligatori per l’immissione, su quali filtrare le ricerche, ecc.
Nel giro di qualche mese di febbrile lavoro era una realtà ed infatti, le continue modifiche alla struttura del record, venivano da me digerite con inconsueta calma :D ed implementate con velocità disarmante.

Perché usare OMNIA
E perché no? :) Battute a parte, OMNIA ha in sé, completamente integrato:
- la capacità di gestire le più disparate tabelle dati
- è multiutente
- dispone di tutte le interfacce:
o login utente
o registrazione utente
o recupero password utente
o inserimento record
o lettura record
o modifica record
o backup database
o ripristino database
o personalizzazione template (alla stregua di un CMS)
- log degli accessi e delle principali operazioni svolte sui dati
- filtri personalizzabili di ricerca
- lavora su http
- non necessita dell’installazione di alcun client
- ecc. ecc.
E questo con sole 3500 righe di codice.
Quindi, una volta installato sul server, può essere usato nella LAN o in WAN semplicemente accedendo con il proprio browser preferito



Success Stories
Da quel momento in poi, ogni qualvolta ho avuto la necessità di archiviare dati, ho utilizzato OMNIA per il cliente.
Attualmente viene utilizzato con soddisfazione:
- dalla SMG Srl (DPM Elettronica) con il nome di Archive – http://www.dpm-elettronica.it
o l’azienda in questione, importatore di elettronica dai mercati asiatici, utilizza il software internamente, per catalogare la manualistica e le immagini per i cataloghi dei proprio magazzino di circa 10000 articoli (alla fine dell’abstract url per il collegamento)
- dall’Hotel Neapolis (http://www.hotelneapolis.it)
o come anagrafica per i tour operator che operano con loro e come repository dei contratti in essere con questi ed altri fornitori
- dalla Magnetico SUD, incoming e tour operator (http://www.magneticosud.com)
o come repository per i modelli di contratto con altri tour operator
- dalla Horizon Srl (http://www.horizonsrl.net)
o tra i principali agenti Vodafone nel sud Italia, come database clienti: anagrafica, contratto, storico
- dalla netlogica Srl (http://www.netlogica.it)
o come archivio interno
o come CMS per il nuovo portale, utilizzandolo per avere output XML, letto tramite Javascript
- dallo Studio Legale Coluccio in Napoli
o come archivio pratiche



Requisiti
Web server: Apache (ma è stato testato anche su IIS, Sambar e Xitami)
Interfaccia CGI
Perl: testato con ver. 5.x. Librerie
CGI qw (:standard); (lettura parametri, cui si potrebbe facilmente ovviare)
File::Copy;
Socket (per le connessioni SMTP con autenticazione)



Direzioni future
Parametrizzare completamente anche l’output XML, nessun bug noto.


Applicazioni attuali:
OMNIA viene applicato in molti casi tra cui:
- Gestione archivio studio commercialista
- Archivio materiale grafico e manualistico per importante importatore di elettronica
- Anagrafica clienti per importante agenzia di primario operatore telefonico
- Gestione files dati XML per diversi siti web ed applicazioni in Flash
- Contenitore articoli per redazione testata tecnico-legale (redazione geograficamente distribuita)

Mario Rossano (Anak)
software@netlogica.it


Attended by: Ferruccio Zamuner (‎ferz‎), kurcky, andrea ciampalini, Alberto Gaia,

Diamond Sponsors

Istituto di Informatica e Telematica del CNR

Platinum Sponsors

Opera software Dada S.p.A. Seeweb Wind Telecomunicazioni SpA pair Networks

Gold Sponsors

Smart Open Software O'Reilly Media

Silver Sponsors

Italpro ActiveState Qubo VPS MySQL Live Reply Best Practical The Pragmatic Bookshelf No Starch Press Apress

Supporters

Geoesse Nestoria

Patronage

Regione Toscana Comune di Pisa YAPC Europe Foundation Perl Foundation

Media Partners

Società Italiana delle Scienze Informatiche e Tecnologiche Infomedia