Una buona progettazione di database è meno importante per i database spaziali?

Ho la netta sensazione che la progettazione e la normalizzazione del database siano spesso di seconda mano quando si tratta di dati spaziali.

Con software che costa una fortuna e database con oltre 100 tabelle di campi, devo chiedere:

Ci sono buone ragioni per prendere altre considerazioni oltre alla normalizzazione quando si progetta un database spaziale?

Immagino che la gente chiederà esempi, ma che non posso dare qui, quindi la mia domanda è forse più mirata per coloro che indicano che 100 campi non sono un problema e sono più facili da mantenere rispetto a un corretto design normalizzato.

Quali sono gli argomenti?

Ritengo che i database spaziali non debbano essere trattati diversamente dai database tradizionali. Sostanzialmente stanno facendo la stessa cosa, archiviando grandi quantità di dati per un rapido recupero. Ad esempio, in PostgreSQL / PostGIS, la geometria è solo un altro tipo di dati. Proprio come il testo o intero. Lo stesso in SQL Server 2008. Lo stesso in Oracle. Se la parte "spaziale" è solo un altro tipo di campo nel database, allora è davvero così diverso dal database originale? Questo significa che dovremmo buttare via tutte le regole della progettazione tradizionale del database?

Ovviamente la normalizzazione può essere portata troppo lontano, proprio come con i database tradizionali, quindi è un compromesso trovare il miglior design adatto alle tue esigenze.

Se stai pensando di creare una struttura altamente non normalizzata con tabelle da 100 colonne, allora devi chiederti cosa è probabile che cambi in futuro? Con un notevole aumento delle righe, ciò influirà anche sulle prestazioni delle query? Ciò influirà sulla manutenibilità in futuro?

Cosa c'è di sbagliato nel creare una struttura normalizzata e nell'utilizzare le viste per esporre tutti i dati al client del database, sia esso GIS o qualsiasi altro client?

Tutte queste domande si applicano sia ai database tradizionali che ai database spaziali. Se passi su http://en.wikipedia.org/wiki/Dormalizzazione_database troverai che si applica anche ai database spaziali.

Se il software che stai utilizzando nella parte superiore del database ti sta costringendo a utilizzare strutture altamente non normalizzate, allora questo è un argomento diverso. Siete vincolati dal software e non dal database, quindi non avete scelta nella migliore progettazione del database.

Quindi penso che la risposta breve sia (secondo me) la progettazione del database è importante tanto per i database spaziali quanto per i database tradizionali.

Lo vedo molto. Ritengo che derivi dal fatto che tradizionalmente le persone GIS provengono da contesti di rilevamento e non hanno un background / comprensione dei database. Tuttavia, vedo questo cambiamento, poiché sempre più organizzazioni spostano l'infrastruttura GIS nel settore IT.

Legacy software GIS

Il costo elevato precedente di ArcSDE e la mancanza di un tipo di dati spaziale in SQL Server (fino al 2008) e Oracle fino alla versione 10, significava che non c'era altra scelta che archiviare i dati in shapefile per molte organizzazioni (e dagli offerenti per mantenere bassi i costi delle offerte) .

L'introduzione di tipi spaziali nativi in ​​SQL Server ha significato quasi istantaneamente che ArcSDE è passato da un enorme investimento, a essere incluso gratuitamente in ArcGIS, e al "portare alla piega" dei dati spaziali nelle organizzazioni.

Le organizzazioni che utilizzano ArcGIS e SQL Server in precedenza avevano tre opzioni:

1. Paga la tassa di 20k + per acquistare ArcSDE e archiviare i dati spaziali nei database "corretti" di SQL Server.
2. Archivia i dati spaziali in shapefile / GDB personali e collega al resto dei dati organizzativi nei database (o esporta questi attributi in DBF)
3. Cambia i fornitori GIS e archivia i dati spaziali in un unico database ma in un formato accessibile solo dal nuovo software GIS

Una volta che SQL Server aveva un tipo spaziale nativo, la maggior parte dei fornitori lo utilizzava invece dei loro formati proprietari, il che significa che le altre applicazioni potevano accedere improvvisamente ai dati spaziali. ESRI ha dovuto ridurre il costo di ArcSDE (cosa che hanno fatto integrandolo in ArcGIS) e / o consentire che i dati spaziali fossero archiviati nel formato del database nativo.

Inoltre, le query eseguite in ArcIMS su shapefile intesi associati ai DBF dovevano includere tutti i campi richiesti e la duplicazione in quanto non vi era alcuna opzione per creare viste spaziali o collegare facilmente funzionalità con un database back-end.

Ragioni organizzative

Concordo con altri sul fatto che fino a poco tempo fa i dati spaziali sono diventati un tipo di database nativo, sono stati a lungo ignorati o tenuti separati dagli amministratori di database nelle organizzazioni e diventano la responsabilità di un gestore GIS. I concetti di progettazione del database, normalizzazione, replica, sicurezza e viste SQL richiedono un insieme di competenze spesso molto diverso e specializzato e non possono essere facilmente appresi man mano che procedi.

Ragioni di costo

Spiegare in una gara d'appalto il requisito di una grande quantità di tempo e sforzi da dedicare a un modello di dati e la pulizia / importazione di dati in questo modello è spesso impossibile. Spesso gli acquirenti del progetto provengono da una visione analitica del GIS e trascurano l'importanza dei dati strutturati.

Per tabelle a 100 colonne, suppongo che intendi i tipi di output che ottieni dalla creazione di overlay "copertura master" di più input. Sì, questi sono artefatti del flusso di lavoro Arc / INFO. Ma, in difesa, puoi anche pensarli come tavoli deliberatamente de-normalizzati per OLAP . Dal momento che vengono utilizzati principalmente per l'elaborazione delle query, non per l'aggiornamento dei dati, la forma non normalizzata ha un senso. Come uno schema a stella , ma senza i punti, ehm. OK, tè debole, ma penso comunque che ci sia qualcosa lì.

Sì, se iniziare un nuovo progetto IG è importante e può risparmiare tempo = denaro in futuro. http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916 è una buona panoramica del perché è importante.