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

15

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?

spatial-database database-design Nicklas Avén
la source
Dans le cas d'ArcGIS, une base de données normalisée avec intégrité référentielle est difficile à réaliser, car vous êtes limité aux seules fonctionnalités de base de données qui vous sont exposées et prises en charge par ArcGIS. C'est très frustrant en tant que type de base de données relationnelle ... de jouer à un jeu de téléphone, avec ArcSDE au milieu.
nw1

Réponses:

16

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.

Kelso
la source
1
+1 pour le point clé de différenciation entre le logiciel dictant la structure de base de données et le "meilleur" design pour la nature des données.
Matt Wilkie du
Oui, à la fois cette réponse et le commentaire de Matt, je suis d'accord. Mais ce que j'espère, c'est que quelqu'un puisse expliquer pourquoi cela n'est souvent pas suivi. Je vais modifier un peu la question.
Nicklas Avén
Je suis d'accord. Une autre chose que j'ai trouvée est que les performances de la base de données peuvent influencer votre décision de normaliser ou non. Dans certains cas, je constate que deux bases de données sont utilisées, une base de données «principale» contenant des données normalisées et une base de données secondaire utilisée uniquement à des fins d'affichage. Celui-ci contient uniquement tout ce qui est nécessaire pour afficher les données (SIG), généralement dans une seule table.
Berend
Pour développer le point Berends, l'une des raisons de cette dénormalisation est que les vues matérialisées sont souvent un peu difficiles et spécifiques à la base de données à implémenter, il est donc généralement préférable de créer votre propre table / base de données pour stocker les données dénormalisées.
Alexander
6

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.

BlinkyBill
la source
1
c'est mon sentiment aussi, mais j'espère en quelque sorte que l'explication ressemble plus à la discussion de Paul, que c'est un choix délibéré d'une certaine manière. cela donnerait plus de sens à l'utilité du SIG avec autant de mots fantaisistes, de modèles et de techniques que de découvrir que la base de données en bas a été utilisée à mauvais escient à cause de l'ignorance.
Nicklas Avén
1
désolé, mal utilisé est mauvais. s'il est délibéré pour une bonne raison, il ne s'agit pas d'une mauvaise utilisation.
Nicklas Avén
5

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.

geographika
la source
Je comprends et suis d'accord avec la plupart de ce que vous écrivez. Mais dire que la partie SDE est donnée gratuitement après le changement de nom vers le serveur ArcGIS, ce n'est pas comme dire: si vous achetez la belle couleur de cette voiture pour 100000 dollars, vous obtiendrez le reste de la voiture gratuitement. Je ne connais pas bien ArcGIS, mais qu'est-ce qu'ArcGIS Server sans la partie SDE? et je n'ai jamais entendu personne dire que le serveur ArcGIS est bon marché. Je ne vois pas vraiment comment les types spatiaux SQL Server ont affecté ArcGIS. Mais étant donné que les produits Arc sont si largement répandus, je conviens que la route Arc a une grande influence sur la façon dont les gens pensent de leurs données spatiales.
Nicklas Avén
Avant ArcGIS Server, ArcSDE était auparavant complètement séparé d'ArcMap et d'ArcIMS et devait être acheté et licencié séparément. Comme ArcSDE était le seul moyen de stocker des données spatiales dans SQL Server (ou Oracle à l'époque), cela signifiait que les données spatiales étaient stockées ailleurs.
geographika
ok, ArcIMS en package avec SDE est le nouveau consept. Arcmap a toujours besoin de licences distinctes par utilisateur ou flottantes, non? hors sujet, mais je suis un peu curieux.
Nicklas Avén
Pas d'accès / stockage de données spatiales dans une base de données relationnelle sans payer de grandes sommes supplémentaires était le nouveau concept. esri.com/software/arcgis/arcsde/index.html
geographika
le serveur ArcGIS n'est-il pas une grosse somme d'argent? Pour autant que je sache, vous ne pouvez pas utiliser sqlserver fomat ou postgis (sans ziggis) dans arcmap sans sde, désolé ArcGIS Server entre les deux.
Nicklas Avén
4

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.

Paul Ramsey
la source
1
oui, Paul. Je savais qu'il y aurait des explications, y compris des mots que je ne comprends pas vraiment :-). Très intéressant qu'il y ait une histoire délibérée derrière cela. Génial!
Nicklas Avén