Più vado avanti e più mi rendo conto che il “Database Relazionale” per sua stessa definizione non esiste più, o almeno, la moda è quella di realizzare una base dati e di questa, la parte del nome che ha più importanza è proprio base, cioè niente di più che uno strumento per il salvataggio delle informazioni.

Vi starete chiedendo: ma tu che problema hai? Io ho diversi problemi ed oggi ve ne espongo qualcuno!

Allora, il mio lavoro non consiste solo nella progettazione e realizzazione di software, molte volte, in casi estremi quando nemmeno gli stessi dirigenti plurilaureati che si presentano dicendo

“Salve, io sono un espertissimo nell’elaborazione dati”

riescono a risolvere, forniamo al cliente supporto per la gestione dei database proprietari di cui proprio non riescono a capirci nulla. Capita spesso che venga acquistato un software da altre aziende che forniscono l’RDBMS spacciato per RELAZIONALE insieme al software atto alla sua manutenzione, la maggior parte delle volte, il cliente chiede sempre qualcosa in più relativamente allo stesso, tipo reports complicati, quadramenti, conteggi, roba che il Tool offerto per il Management non è in grado di offrire.

Qui interveniamo noi che forniamo supporto come CED (Centro Elaborazione Dati), ci infiltriamo in questi complessi database e tiriamo fuori le informazioni che servono (le più svariate e complesse query che il mondo possa conoscere, delle volte il cliente è cosi al punto tale da chiedere cose cosi complesse da non capirci nemmeno lui nulla mentre cerca di farci capire che vuole).

Il problema diventa inquietante quando per la prima volta abbiamo a che fare con la mappa della base dati.

Con il caro PAINT ho disegnato quelli che sono i tre tipi di RDBMS con cui sono abituato a lavorare, ci tengo a sottolineare RDBMS perché questi database che vi sto per presentare, vengono spacciati e garantiti come TALI, andando in ordine di stress e trauma post-job a cui si è sottoposti per analizzarli.

 

La RETE

La Rete

Questo tipo di Database per definizione è una RETE LAN adattata a base dati, si presenta come una struttura Figlia dei Fiori in cui ogni Tabella è amica, parente, madre e padre di tutte le altre che la circondano. La sua stessa composizione è indice dell’insicurezza del suo creatore, non sicuro di poter collegare tutto tramite una semplice relazione, ha deciso di creare una rete le cui caratteristiche delle volte spaventano chiunque si avvicini. Il motto per lavorare con questi database è:

Le vie del signore sono infinite.

L’INCOGNITA

L'incognita

Le tabelle appaiono timide ed introverse, non amano comunicare tra loro, ne tantomeno si impegnano per rendere la vita del DBA facile, per poter capire quali siano i collegamenti è necessario interrogarle una ad una, investigando sul loro carattere (colonne, nomi e tipi) ottenendo un risultato finale in tempi davvero molto lunghi. Per queste basi di dati vale un simpaticissimo commento letto in un articolo:

// Questo codice lo conosco solo io e DIO. 
Qualche tempo dopo...
// Questo codice ora lo conosce solo DIO.

Il senso della frase, relativa al contesto sviluppo codice, penso possa valere anche per queste situazioni.

UTOPIA

Utopia

Lettori ecco a voi quello che un database [ garantito RDBMS ] dovrebbe essere e che in realtà non è mai. Una base dati in cui ogni relazione e tabella sono progettate in modo tale da rendere chiara l’idea di quello che è il dato contenuto. Questo, è il tipo di database con cui non avrete mai a che fare!

CONCLUSIONI

Ad oggi non esiste un reale standard che definisca quali siano le regole per distinguere un Database Relazionale da un semplice contenitore di dati senza alcuna struttura e semantica, allo stesso modo una base dati non può essere definita relazionare solo perché presenta relazioni al suo interno.

Personalmente do una mia interpretazione per descrivere un database di questo tipo: un contenitore di dati con una struttura ben definita in cui tutto è al posto giusto, dai nomi delle tabelle alle loro relazioni, dai dati contenuti alle chiavi primarie scelte. Quando realizzo un progetto penso al database come ad un modulo indipendente dal resto dell’applicazione, modulo in cui devo essere in grado di operare senza essere a conoscenza di quella che è la parte applicativa, Stored Procedure, Chiavi Internet ed Esterne, Vincoli, Trigger etc. sono gli strumenti di cui mi avvalgo (se possibile, cioè se le tecnologie che utilizzo me lo permettono) per modellare l’intero sistema di gestione dei dati.

Ognuno ha il suo modo di lavorare, il contesto è una variabile imprescindibile in base a cui tutto cambia, seguendo queste linee guida realizzo le mie applicazioni ottenendo un vantaggio finale di non poco conto. Quando semantica e regole per una corretta rappresentazione vengono messe da parte, diventa un rischio per la mia salute psicofisica lavorare. Quando sono il diretto responsabile nella realizzazione di una base dati cerco di pensare a chi si troverà a dover interpretare il mio RDBMS e cerco di garantire un ingresso piacevole e senza troppi rischi  .

Tratto da: Come rovinare la vita di un DBA.