Dato che (a) le informazioni con cui stai lavorando sembrano essere, di per sé, una risorsa organizzativa molto preziosa, e (b) il volume di dati sarà considerevole, vorrei decisamente (c) costruire un database relazionale su uno dei le principali piattaforme SQL.
Ciò ovviamente, da una prospettiva molto generale, richiede tre fattori essenziali:
Uno schema concettuale chiaramente definito , in cui è necessario identificare e contrassegnare con precisione i prototipi delle cose, ovvero i tipi di entità (comprese le loro proprietà e interrelazioni ) di pertinenza nell'ambiente aziendale con cui si sta lavorando (ad esempio, le Torri e Sensori di cui parli).
Come sapete, questo punto implica stabilire una comunicazione continua e produttiva con esperti di business.
Un layout logico che rifletta il livello concettuale con precisione, mediante tabelle (ad es. Relazioni matematiche) che contengono colonne ben delimitate con nomi e tipi di colonne appropriati (ad es. Attributi di relazione) e tutti i vincoli corrispondenti per garantire che i dati siano conformi tutte le regole determinate al livello precedente.
Pertanto, è qui che entra in gioco il vasto potere del modello relazionale (sebbene i suoi vantaggi abbiano ripercussioni positive ad altri livelli di astrazione).
Una disposizione fisica che, ad esempio, aumenta la velocità di esecuzione delle operazioni di manipolazione dei dati logici "dinamici" e garantisce i vincoli logici.
Poiché il modello relazionale offre l'indipendenza fisica dei dati , un sistema di gestione di database (DBMS per brevità) può fornire qualsiasi tipo di struttura a questo livello, non esclusivamente indici, per supportare le definizioni logiche. Nel caso delle principali piattaforme SQL, sì, questo implica comunemente, precisamente, l'impostazione di una strategia di indicizzazione basata sulle tendenze di query specifiche del database e hai sollevato considerazioni molto interessanti rispetto ad alcune possibili configurazioni ma, senza conoscere il particolare le necessità informative con esattezza, offrendo consigli specifici al riguardo non sarebbero adatte.
Altri elementi che meritano una valutazione sono, ad esempio, l'aggiornamento dell'infrastruttura di rete per aumentare la larghezza di banda, abilitare le configurazioni del server appropriate (dal punto di vista hardware e software), ecc. E, se e solo se, un professionista è abbastanza qualificato, potrebbe anche modificare il codice sorgente del DBMS di scelta (più fattibile in ambienti open source, naturalmente).
In questo modo, i seguenti aspetti evidenziati
- Gestisci e recupera le configurazioni torre / sensore per dare un senso all'analisi dei dati.
- Visualizzazione dei dati tramite sensore o intervalli di tempo per osservazioni meteorologiche.
- Fornire ai clienti risorse di dati / set di dati affidabili e persistenti per confrontare le prestazioni del modello e del sensore (potrebbe essere necessario un po 'di post-elaborazione per fornire nel formato richiesto?).
sarebbe ben indirizzato, perché si sarebbe facilmente in grado di dichiarare le domande, ad esempio, per ottenere informazioni in forme molto significative. Ad esempio, è possibile ottenere dati associati
- il sensore identificato da SensorNumber
1750, installato nella torre identificata da TowerNumber 31, tra la data 1 June 2017e la data27 June 2017 .
Inoltre, poiché (1) i dati in un database relazionale sono gestiti logicamente in termini di insiemi con l'ausilio di operazioni basate sull'algebra relazionale e (2) i diversi motori SQL sono fisicamente ottimizzati (alcuni più degli altri) per l' insieme elaborazione , è possibile, ad esempio,
- confronta l'insieme a con l'insieme b ;
- unire set c con set d ;
- ottenere sub set f attraverso una restrizione sul set e ;
- produce n sottoinsiemi da n intersezioni impostate;
- progetto n attributi dal set f
- recuperare informazioni da set z che è il risultato di un'unione di set x con set y ;
- e così via.
Le possibilità di manipolazione dei dati sono infatti enormi - dimostrando la versatilità senza pari del paradigma relazionale - poiché è possibile lavorare non solo con le tabelle di base (quelle dichiarate con le CREATE TABLE … ( … );dichiarazioni) ma anche con quelle derivate (quelle espresse tramite SELECT …;operazioni, a volte fissate come VIEWs) . In altre parole, è possibile (i) esprimere nuove strutture di dati basate su (ii) precedenti che operano su (iii) il singolo costrutto relazionale sottostante, ovvero la relazione matematica.
Evidentemente, la disposizione delle tabelle e delle colonne di base di un database relazionale può evolversi e (a) nuove tabelle o colonne di base possono essere incorporate in essa quando (b) tenere traccia di nuovi tipi di entità o proprietà del tipo di entità è ritenuto utile nel contesto aziendale pertinente. In altre parole, non si prevede che né la struttura iniziale né i vincoli di apertura di un database relazionale siano statici o immutabili. Inoltre, un database che è organizzato in modo appropriato sin dall'inizio tende ad essere molto più facile da modificare quando sorgono nuovi requisiti informativi.
In accordo con le considerazioni precedenti, il formato logico degli insiemi applicabili deve essere prodotto in modo dichiarativo , a livello logico del database. La formattazione grafica o di presentazione degli insiemi (ad es. Le facce di colorazione o dei caratteri utilizzate) deve a sua volta essere elaborata tramite il codice di uno o più programmi applicativi (sì, principalmente in modo procedurale , magari con l'aiuto di un oggetto orientato al framework, HTML, ecc.), al fine di rendere di facile utilizzo l'accesso e la presentazione di tali set. Certamente, potresti anche usare un software di reportistica che si collega al tuo database.
La modellazione di un database di rilevanza
Dato che lavorerai con i dati del sensore (che, tra le altre funzionalità, in genere coinvolge informazioni sotto forma di serie temporali ), potresti trovare aiuto nella progettazione di più database e nei principi di amministrazione generale contenuti nelle due risposte eccezionali, di @PerformanceDBA , alle domande intitolate:
Gli approcci relazionale, flat file e NoSQL
Il modello relazionale del Dr. Edgar Frank Codd , sebbene pubblicato nel 1970, rimane davvero il metodo più moderno ed elegante (basato sulla logica e la teoria degli insiemi) per affrontare il problema della gestione dei dati. I distinti DBMS SQL sono, a loro volta, le approssimazioni più popolari (che, sebbene non completamente conformi, sono comunque molto potenti) ai sistemi proposti nella teoria relazionale, e alcuni di essi sono stati fortemente ottimizzati (ad esempio, riguardo al loro meccanismi di livello) ormai da decenni. Inoltre, le principali piattaforme SQL possono ovviamente (e saranno in grado di) lavorare con le tecnologie di archiviazione (ad es. Hard disk) ed elaborazione (ad es. CPU) più aggiornate in modo abbastanza efficiente.
Se basato su un potente DBMS, un database relazionale che è adeguatamente progettato a livello concettuale, logico e fisico diventerebbe decisamente un asset autonomo, auto-descrittivo e auto-protettivo che (1) è affidabile e (2) offre un risposta rapida, due aspetti che, come sapete, sono di grande significato.
File piatti
Pertanto, l'affermazione che segue
Mi è stato detto che la logica per l'utilizzo di file flat è che ritenevano che un database relazionale avrebbe richiesto un sovraccarico eccessivo.
viene facilmente scartato, perché l'approccio file flat sarebbe:
- pre-scientifica;
- tutt'altro che ottimale per grandi volumi di dati;
- troppo ingombrante;
- dipendente dal programma applicativo (e dovresti implementare manualmente la maggior parte delle funzionalità che i DBMS corretti offrono in modo nativo);
- le sue prestazioni saranno facilmente compromesse;
- eccetera.
Considerando che la moda relazionale, molto più conveniente, per non dire altro:
- offrirebbe una grande scalabilità (è indipendente dal livello fisico, quindi potresti migliorare i meccanismi fisici sottostanti secondo necessità);
- porterebbe uno stile semplice per manipolare i dati (tramite operazioni astratte ) e
- potrebbe lavorare con più programmi applicativi simultaneamente (per esempio, uno o più mobili le applicazioni e / o uno o più applicazioni web, e / o una o più applicazioni desktop, ecc).
Se, tuttavia, si opta per l'utilizzo di file flat, è necessario valutare l'impiego di un'utilità affidabile come Awk che, sebbene non sia un DBMS (e non è stato progettato come tale), fornisce utili risorse per gestire file , record , campi , ecc. Vedere la Guida dell'utente di GNU Awk per ulteriori informazioni su questo argomento.
NoSQL
"Dati non strutturati" e termini associati
Secondo la loro propaganda, la giustificazione iniziale per l'uso dei DBMS NoSQL è che sono destinati a essere utilizzati in domini aziendali che comportano la gestione di "dati non strutturati", in modo da porre la domanda:
- Che cosa dovrebbe significare l'espressione "dati non strutturati"?
A tale proposito, si deve dire che i dati, per loro stessa natura, sono strutturati; se non avesse struttura, sarebbe qualcosa di insignificante, di conseguenza una cosa del genere (i) non potrebbe essere considerata come un dato e (ii) non varrebbe la pena amministrarla. Quindi, "dati non strutturati" è un'espressione contraddittoria e sfortunata.
Un'altra frase di questi contesti è "dati semi-strutturati". Questa frase suggerisce che esistono dati strutturati "in parte" o "a metà", quindi, in conformità con il paragrafo precedente, solo la "parte" o "metà" che è strutturata può essere dati reali, la restante "parte" o "metà" è semplicemente una cosa informe perché manca di struttura e non può essere definita come dati.
Ancora un altro, ahimè, termine tipico che si trova nel marketing NoSQL è "dati polimorfici". Se detto termine indica qualcosa di simile a "dati che hanno molte forme diverse", in realtà si tratta di dati ordinari , che si presentano in molte forme distinte come sempre. E poiché ha molte forme diverse, allora presenta molte strutture distinte , quindi non c'è niente di speciale in questo "tipo" di dati.
Inutile dire che i dati e le strutture di dati sono sempre stati suscettibili di cambiamenti , quindi non c'è nulla di insolito in questo senso.
Crescita del volume di dati
Evidentemente, i volumi di informazioni gestite mediante sistemi computerizzati sono sicuramente cresciuti nel corso degli anni e continueranno a crescere in modo esponenziale con il passare del tempo, perché ogni giorno vengono costruiti nuovi sistemi, ma questo è un fatto che non ha a che fare con la struttura delle informazioni in sé .
Mancanza di una base teorica arrotondata
Una limitazione critica dei sistemi NoSQL (esistono diverse classi, ad esempio documenti e basati su grafici ) è che nessuno dei prodotti attuali — sebbene fortemente commercializzato ed etichettato come “moderno” - possiede una solida base teorica (se non del tutto) che supporta ognuno dei tre elementi più importanti di un DBMS adeguato, ovvero strumenti per la definizione dei dati (a), (b) manipolazione e (c) costrizione. Pertanto, l'approccio NoSQL suggerisce in realtà una regressione a un'era antica in cui la gestione dei dati è stata eseguita in un corso d'azione ad hoc e non fondato, con tutta la complessità inutile che comporta.
Oggi, i sistemi grafici sono inclusi nello spettro "NoSQL". Questi prodotti software invitano a gestire i dati in virtù di operazioni su due strutture distinte: nodi e relazioni - che, ancora una volta, sono in conflitto con il termine "dati non strutturati" - e si distinguono nel gruppo "NoSQL" perché lo fanno avere una base matematica. Tuttavia, i prodotti grafici sono piuttosto simili alle piattaforme di rete , che sono considerate obsolete da decine di anni fa (un ovvio svantaggio è che, come suggerito sopra, hanno bisogno di due strutture per la rappresentazione dei dati, mentre un DBMS relazionale - come per il principio dell'informazione - ne ha bisogno solo uno).
Anche se la creazione dei diversi sistemi NoSQL è cronologicamente più recente rispetto alle origini della maggior parte dei DBMS SQL, la maggior parte dei concetti su cui si basano i prodotti NoSQL sono, in effetti, primitivi .
Un programma NoSQL dovrebbe essere impiegato, principalmente, in scenari in cui, ad esempio,
- il personale IT non dispone delle competenze tecniche necessarie per determinare (o determinare opportunamente) la struttura dei dati di interesse —eg, a causa della sua complessità—; e / o
- l'organizzazione non può permettersi un'adeguata istruzione e formazione per il personale attuale o non può assumere nuovo personale che possiede l'istruzione e la formazione richieste; e / o
- quando l'integrità e la coerenza dei dati non sono particolarmente importanti; e / o
- quando si fondono i dati relativi a quelli dei sistemi mission-critical che richiedono alta precisione non è previsto.
Tuttavia, anche se la struttura dei dati in questione non è definita prima della creazione dei relativi sistemi, una o più persone dovranno necessariamente
- scopri la suddetta struttura,
- scartare tutte le "interferenze" circostanti e
- raccogliere e collegare i dati corretti
dopo che il database e le app sono entrati nella fase di produzione per essere in grado di ottenere il massimo da tutte le risorse investite in un progetto, la delimitazione della struttura dei dati è un'attività che non può essere ignorata, deve essere eseguita prima o più tardi.
Quindi, mentre andare nel modo NoSQL è una possibilità, tutti i fattori precedentemente menzionati dovrebbero sicuramente essere presi in considerazione.
Il metodo più robusto
Al contrario, l'approccio ai requisiti informativi di un ambiente aziendale in modo relazionale —ie, con un paradigma generale dietro — offre la possibilità di (1) gestire i dati nella sua struttura naturale dall'inizio —che facilita l'integrazione con altre fonti di dati— e anche di (2) produrre nuove strutture affidabili a causa della manipolazione di un singolo strumento - come spiegato nelle sezioni precedenti - che ha una solida base scientifica.
Secondo la tua descrizione dello scenario in questione, hai già identificato una particolare struttura in termini di esigenze organizzative pertinenti, quindi ti suggerisco di richiedere la convalida da parte degli esperti del dominio aziendale. Successivamente, consiglio di sfruttare (i) i costrutti —la relazione, i vincoli e le operazioni — forniti dal modello relazionale per gestire detta struttura e i rispettivi dati, e (ii) il vostro DBMS SQL di scelta che sarà molto probabile offrire strumenti fisici molto efficienti in grado di soddisfare le esigenze attuali e fornire scalabilità futura.