[Gfoss] Tool UML per geodatabase design

[Andrea Peri]

Secondo me piu' che sapere usare bene un programma di case serve che
uno sappia far bene la progettazione di un DB.
Se e' bravo e sa progettare un DB, il case puo' anche non servirgli,
almeno finche' le tabelle sono poche.
Se non e' bravo, il case non serve a niente. Non aiuta a risolvere le carenze.

Poi, a parte questo discorso, se le tabelle sono molte serve
sicuramente un CASE, anche solo per gestire la costruzione grafica del
diagramma ER.

Che da sola aiuta moltissimo a identificare i problemi.

Poi, se si scende nell'operativo.
DIciamo che un case , su una progettazione importante , aiuta a
contenere i costi.
Faccio un esempio di brutta pratica.

Brutta pratica e' ad esmepio progettare una base dait pensando di
avere chiaro come debba essere fatta, contando esclusivamente sulla
propria esperienza e conoscenza dei dati, ma senza tenere in acun
conto l'uso che di essa va fatto e senza porsi il dilemma di come
verra' impiegata. Con quali strumenti e con quali meccanismi.
Quello che sovente succede, e' che viene progetttaa una base dati. Poi
su di essa si comincia a realizzare sistemi informativi che la
impiegano.
Quando si arriva in fondo al percorso, e tutto e' stato fatto, arriva
in mano agli utenti e si scopre che alcune informazioni essenziali o
comunque utili sono state trascurate o travisate.

Ecco che la revisione risale fino alla riprogettazione della Base
dati, con tutta una serie di costi che finiscono per esplodere.
Questo modo di operare non e' risolto dall'impiego di un RAD, perche'
l'errore sta' piuttosto nella testa delle persone.

Ci sono pero' altri casi in cui un RAD aiuta a evitare dei problemi.
Quando il problema non è di supponenza di chi progetta, ma piuttosto
di un mero errore materiale nel legare due o piu' tabelle. Nel
definire male una foreign-key o nel legarla al campo errato, magari
legando un campo stringa con un campo intero.
Oppure nel creare degli anelli di relazione che poi renderebbero
difficile la loro gestione.
In tutti questi casi e anche in altri, un buon RAD che controlla la
corretta impostazione delle regoledi integrita' referenziale di una
base dati. Sicuramente aiuta.

AIuta nel senso che se non ci si accorge dell'errore in sede di
progettazione e si passa alla realizzazione . Se si scopre l'errore
durante la programmazione.
Dubito che il programmatore si accolli lui a gratis lonere di
riscrivere il programma perche' il progettista dela DB aveva sbagliato
nel comporla.

Qui casca l'asino.

Se il progettista fosse chiamato a rispondere in solido dell'errata
progettazione di una BD, forse si porrebbe lui per primo il dubbio di
usare strumentiche lo aiutino nel suo lavoro.
Se invece si tratta di un costo che comunque finisce per riadere sul
committente di riffa o di raffa.
Allora il RAD non e' percepito come un aiuto nel proprio lavoro ed' e'
vissuto piuttosto come un costo inutile.
Ma qui forse sono cattivo io.
per cui scusatemi.

Termino citando che nel caso del nostro progetto OMERO.
Con cui si e' realizzato un plugin per qgis (disponibile sul repo di
qgis) per la catalogazione e la gestione di una anagrafe edilizia.
Il progetto e' basato su un db sqlite.

La base dati e' abbastanza complessa per i miei canoni usuali.
Va detto che pero' ce ne sono di ben piu' complicate e per chi lavora
qutidianamente sui DB questa sarebbe pure semplice.
In ogni caos la BD del progetto Omero e' di per se' gia' sufficiente
per essere considerata una BD non piccola e per questo ho dovuto fare
uso di un buon RAD. Nello specifico ho usato un prodotto commerciale
(che mi ero procurato autonomamente).

Con esso ho progettato la base dati e sempre con esso ho potuto
generare in automatico gli scrpts di creazione per sqlite/spatialite.

Le tabelle geometriche , le trattavo come blob e poi modificavo a mano
lo script. Le tabelle con geometria erano poche (2 solamente).

L'impiego del RAD e' risultato pero' fondamentale.
Infatti il committente (altri colleghi) vedevano lo schema grafico, si
discuteva e spesso emergevano esigenze di nuove tabelle o di
correzioni sulle esistenti.

Correggere su uno schema disegnato e poi con un click rigenerare la
miriade di tabelle e rigenerare sul momento anche lo schema grafico ER
in gif e' una comodita' assoluta e ha abbassato molto i tempi e quindi
i costi.

Per chi e' interessato a farsi una idea della base dati o vuole
curiosare nel plugin Omero.
Se vuole se lopuo' installare.
Poi se va nelle cartelle del plugin stesso, ci trova una sottocartella
di documentazione con lo schema grafico in GIF e lo script di
creazione della base dati.
Dal GF capisce subito la dimensione della base dati e la numerosit'a
delle relazione di FK presenti. Impossibili da gestire a mano libera.
Senza commettere errori, anche solo nel tenere allineati ildisegno e
gli script di creazione.


A.


Il 18 agosto 2015 18:18, Totò Fiandaca <pigrecoinfinito a gmail.com> ha scritto:
> spiego meglio il mio pensiero su 'usarlo molto bene' facendo un paragone
> stupido:
> quasi tutti usiamo Word o simili, e tutti diciamo che sappiamo usarlo; io
> invece dico sempre che è uno dei programmi più difficili che abbia mai
> usato; è facile scrivere una lettera, una lista di cose da fare, ma sfido ad
> usare Word per scrivere un libro, con capitoli, sotto sottocapitoli, indice,
> sommario, tabelle, immagini e chi ne ha più ne metta.
> In generale saper usare bene un programma semplifica la vita, ma saperlo
> usare bene è tutt'altra storia.
>
> Usare questi tool semplificano la vita ma bisogna saperli usare bene
> altrimenti in fase di generazione del DB escono fuori tabelle che non sapevi
> esistessero (per esempio nei casi di relazioni molti a molti) oppure ti
> genera nomi dei campi che non credevi avessi creato ecc...
>
>
>
> Il giorno 18 agosto 2015 17:53, Paolo Cavallini <cavallini a faunalia.it> ha
> scritto:
>>
>> Il 18/08/2015 17:45, nformica ha scritto:
>> > Non voglio risponderti al posto di Totò, ma ti dico una mia spiegazione
>> > .. se
>> > ti può essere utile !
>>
>> > E' una spiegazione poco "accademica" che spero ti sia utile !
>>
>> si', certo, grazie; questo e' anche il mio approccio.
>> sono sempre stato a favore del principio KISS[0], o per meglio dire del
>> rasoio di Occam[1]: gli strumenti migliori sono quasi sempre quelli più
>> semplici. Per questo mi interessa capire quali sono i casi reali in cui
>> sia giustificato l'uso di strumenti così complessi.
>> Saluti.
>>
>> [0] https://it.wikipedia.org/wiki/KISS_%28informatica%29
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> _______________________________________________
>> Gfoss a lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 750 iscritti al 18.3.2015
>
>
>
>
> --
> Salvatore Fiandaca
> mobile.:+39 327.493.8955
> m: pigrecoinfinito a gmail.com
> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>
>
>
> _______________________________________________
> Gfoss a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 750 iscritti al 18.3.2015



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------