Une bonne conception de base de données est-elle moins importante pour les bases de données spatiales?

J'ai le fort sentiment que la conception et la normalisation de bases de données viennent souvent de seconde main lorsqu'il s'agit de données spatiales.

Avec un logiciel qui coûte une fortune et des bases de données avec plus de 100 tables de champs, je dois demander:

Y a-t-il de bonnes raisons de prendre d'autres considérations que la normalisation lors de la conception d'une base de données spatiale?

Je suppose que les gens demanderont des exemples, mais que je ne peux pas donner ici, donc ma question s'adresse peut-être davantage à ceux qui veulent dire que 100 champs ne sont pas un problème et sont plus faciles à entretenir qu'une conception normalisée appropriée.

Quels sont les arguments?

Je pense que les bases de données spatiales ne devraient pas être traitées différemment des bases de données traditionnelles. Ils font essentiellement la même chose, stockant de grandes quantités de données pour une récupération rapide. Par exemple, dans PostgreSQL / PostGIS, la géométrie n'est qu'un autre type de données. Tout comme du texte ou un entier. Idem dans SQL Server 2008. Idem dans Oracle. Si la partie "spatiale" n'est qu'un autre type de champ dans la base de données, est-ce vraiment différent de la base de données d'origine? Cela signifie-t-il que nous devrions rejeter toutes les règles de la conception de bases de données traditionnelles?

Évidemment, la normalisation peut être poussée trop loin, tout comme avec les bases de données traditionnelles, c'est donc un compromis pour trouver la meilleure conception qui convient à vos besoins.

Si vous envisagez de créer une structure hautement dénormalisée avec des tables de 100 colonnes, vous devez vous demander ce qui est susceptible de changer à l'avenir? Avec une augmentation considérable des lignes, cela affectera-t-il également les performances des requêtes? Est-ce que cela va affecter la maintenabilité à l'avenir?

Quel est le problème avec la création d'une structure normalisée et l'utilisation de vues pour exposer toutes les données au client de base de données, qu'il s'agisse d'un SIG ou de tout autre client?

Toutes ces questions s'appliquent aux bases de données traditionnelles et aux bases de données spatiales. Si vous passez par http://en.wikipedia.org/wiki/Database_normalization, vous constaterez que cela s'applique également aux bases de données spatiales.

Si le logiciel que vous utilisez au-dessus de la base de données vous oblige à utiliser des structures hautement dénormalisées, alors c'est un argument différent. Vous êtes contraint par le logiciel et non par la base de données, vous n'avez donc pas le choix dans la meilleure conception de base de données.

Je pense donc que la réponse courte est (à mon avis) la conception de bases de données est tout aussi importante avec les bases de données spatiales qu'avec les bases de données traditionnelles.

Je le vois souvent. Je pense que cela découle du fait que traditionnellement, les gens du SIG viennent de milieux d'arpentage et n'ont pas de connaissances / connaissances des bases de données. Je constate cependant ce changement, car de plus en plus d'organisations déplacent l'infrastructure SIG dans le domaine informatique.

Héritage du logiciel SIG

Le coût élevé antérieur d'ArcSDE et l'absence d'un type de données spatiales dans SQL Server (jusqu'en 2008) et Oracle jusqu'à la version 10, signifiait qu'il n'y avait pas d'autre choix que de stocker les données dans des fichiers de formes pour de nombreuses organisations (et par les soumissionnaires pour réduire les coûts des offres). .

L'introduction de types spatiaux natifs dans SQL Server a signifié presque instantanément qu'ArcSDE est passé d'un énorme investissement à une inclusion gratuite dans ArcGIS et à la "mise au pli" des données spatiales dans les organisations.

Les organisations utilisant ArcGIS et SQL Server avaient auparavant trois choix:

1. Payez les 20k + frais pour acheter ArcSDE et stocker les données spatiales dans des bases de données SQL Server "appropriées".
2. Stocker des données spatiales dans des fichiers de formes / GDB personnels et les lier au reste des données organisationnelles dans des bases de données (ou exporter ces attributs vers des DBF)
3. Changez de fournisseur SIG et stockez les données spatiales dans une seule base de données mais dans un format uniquement accessible par le nouveau logiciel SIG

Une fois que SQL Server avait un type spatial natif, la plupart des fournisseurs l'utilisaient à la place de leurs formats propriétaires, ce qui signifie que les données spatiales pouvaient soudainement être accessibles par d'autres applications. ESRI devait réduire le coût d'ArcSDE (ce qu'ils ont fait en l'intégrant dans ArcGIS) et / ou permettre le stockage des données spatiales au format de base de données natif.

De plus, les requêtes effectuées dans ArcIMS sur des fichiers de formes signifiées associées à des DBF devaient inclure tous les champs requis et la duplication car il n'y avait pas d'option pour créer des vues spatiales ou lier facilement des entités à une base de données principale.

Raisons organisationnelles

Je suis d'accord avec d'autres pour dire que jusqu'à récemment, les données spatiales sont devenues un type de base de données natif, elles ont longtemps été ignorées ou maintenues séparées par les administrateurs de base de données dans les organisations et sont devenues la responsabilité d'un gestionnaire SIG. Les concepts de conception de base de données, de normalisation, de réplication, de sécurité et de vues SQL nécessitent un ensemble de compétences souvent très différent et spécialisé et ne peuvent pas être facilement appris au fur et à mesure.

Raisons des coûts

Il est souvent impossible d'expliquer dans un appel d'offres la nécessité de consacrer beaucoup de temps et d'efforts à un modèle de données et de nettoyer / importer des données dans ce modèle. Souvent, les acheteurs du projet proviennent d'une vision analytique du SIG et négligent l'importance des données structurées.

Par tables de 100 colonnes, je suppose que vous entendez les types de sorties que vous obtenez en créant des superpositions de "couverture principale" de plusieurs entrées. Oui, ce sont des artefacts du flux de travail Arc / INFO. Mais, en défense, vous pouvez également les considérer comme des tables délibérément dénormalisées pour OLAP . Puisqu'ils sont largement utilisés pour le traitement des requêtes, pas pour la mise à jour des données, la forme dénormalisée a un certain sens. Comme un schéma en étoile , mais sans les, euh, points. D'accord, du thé faible, mais je pense quand même qu'il y a quelque chose.

Oui, si le démarrage d'une nouvelle conception de projet GI est important et peut faire gagner du temps = de l'argent à l'avenir. http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916 est un bon aperçu des raisons pour lesquelles il est important.