¿Es el diseño de una buena base de datos menos importante para las bases de datos espaciales?

Tengo la fuerte sensación de que el diseño y la normalización de la base de datos a menudo son de segunda mano cuando se trata de datos espaciales.

Con un software que cuesta una fortuna y bases de datos con más de 100 tablas de campos, debo preguntar:

¿Hay buenas razones para tomar otras consideraciones que la normalización al diseñar una base de datos espacial?

Supongo que las personas pedirán ejemplos, pero eso no puedo darlo aquí, por lo que mi pregunta está quizás más dirigida a aquellos que significan que 100 campos no son un problema y son más fáciles de mantener que un diseño normalizado adecuado.

¿Cuáles son los argumentos?

Creo que las bases de datos espaciales no deberían tratarse de manera diferente a las bases de datos tradicionales. Básicamente están haciendo lo mismo, almacenando grandes cantidades de datos para una recuperación rápida. Como ejemplo, en PostgreSQL / PostGIS, la geometría es solo otro tipo de datos. Justo como texto o entero. Lo mismo en SQL Server 2008. Lo mismo en Oracle. Si la parte "espacial" es simplemente otro tipo de campo en la base de datos, entonces, ¿es realmente tan diferente de la base de datos original? ¿Significa esto que debemos descartar todas las reglas del diseño tradicional de bases de datos?

Obviamente, la normalización puede llevarse demasiado lejos, al igual que con las bases de datos tradicionales, por lo que es una compensación encontrar el mejor diseño que se adapte a sus necesidades.

Si planea crear una estructura altamente desnormalizada con tablas de 100 columnas, entonces debe preguntarse qué es probable que cambie en el futuro. Con un gran aumento de filas, ¿esto también afectará el rendimiento de las consultas? ¿Va a afectar esto la mantenibilidad en el futuro?

¿Qué tiene de malo crear una estructura normalizada y usar vistas para exponer todos los datos al cliente de la base de datos, ya sea SIG o cualquier otro cliente?

Todas estas preguntas se aplican tanto a las bases de datos tradicionales como a las bases de datos espaciales. Si visita http://en.wikipedia.org/wiki/Database_normalization encontrará que también se aplica a las bases de datos espaciales.

Si el software que está utilizando en la parte superior de la base de datos lo obliga a utilizar estructuras altamente desnormalizadas, entonces este es un argumento diferente. Está limitado por el software y no por la base de datos, por lo que no tiene opciones en el mejor diseño de base de datos.

Entonces, creo que la respuesta corta es (en mi opinión) que el diseño de la base de datos es tan importante con las bases de datos espaciales como con las bases de datos tradicionales.

Veo esto mucho. Siento que se debe al hecho de que tradicionalmente las personas con SIG provienen de entornos de encuestas y no tienen un conocimiento / comprensión de las bases de datos. Sin embargo, estoy viendo este cambio, a medida que más y más organizaciones trasladan la infraestructura SIG al área de TI.

Legado de software SIG

El alto costo anterior de ArcSDE y la falta de un tipo de datos espaciales en SQL Server (hasta 2008), y Oracle hasta la versión 10, significaba que no había más remedio que almacenar datos en archivos shape para muchas organizaciones (y por licitadores para mantener bajos los costos de oferta) .

La introducción de tipos espaciales nativos en SQL Server significó casi instantáneamente que ArcSDE pasó de ser una gran inversión, a ser incluido de forma gratuita en ArcGIS, y la "incorporación al pliegue" de datos espaciales en las organizaciones.

Las organizaciones que usaban ArcGIS y SQL Server anteriormente tenían tres opciones:

1. Pague la tarifa de más de 20k para comprar ArcSDE y almacenar datos espaciales en bases de datos de SQL Server "adecuadas".
2. Almacene datos espaciales en archivos de forma / GDB personales y enlace con el resto de los datos de la organización en bases de datos (o exporte estos atributos a DBF)
3. Cambie los proveedores de SIG y almacene datos espaciales en una sola base de datos, pero en un formato al que solo pueda acceder el nuevo software SIG

Una vez que SQL Server tenía un tipo espacial nativo, la mayoría de los proveedores lo usaban en lugar de sus formatos propietarios, lo que significa que otras aplicaciones podían acceder repentinamente a los datos espaciales. ESRI tuvo que reducir el costo de ArcSDE (lo que hicieron al integrarlo en ArcGIS) y / o permitir que los datos espaciales se almacenen en el formato de base de datos nativo.

Además, las consultas realizadas en ArcIMS en archivos shape asociados con DBF tenían que incluir todos los campos obligatorios y la duplicación, ya que no había opción para crear vistas espaciales, o vincular fácilmente características con una base de datos de fondo.

Razones Organizacionales

Estoy de acuerdo con otros en que, hasta hace poco, los datos espaciales se convertían en un tipo de base de datos nativa que los administradores de bases de datos de las organizaciones habían ignorado o mantenido durante mucho tiempo, y se convirtió en la responsabilidad de un administrador de SIG. Los conceptos de diseño de base de datos, normalización, replicación, seguridad y vistas de SQL requieren un conjunto de habilidades a menudo muy diferente y especializado y no se pueden aprender fácilmente a medida que avanza.

Razones de costo

Explicar en una licitación el requisito de una gran cantidad de tiempo y esfuerzo para gastar en un modelo de datos, y la limpieza / importación de datos en este modelo a menudo es imposible. A menudo, los compradores del proyecto provienen de una visión analítica de los SIG y pasan por alto la importancia de los datos estructurados.

Por tablas de 100 columnas, supongo que te refieres a los tipos de resultados que obtienes al construir superposiciones de "cobertura maestra" de múltiples entradas. Sí, estos son artefactos del flujo de trabajo Arc / INFO. Pero, en defensa, también puede pensar en ellas como tablas deliberadamente desnormalizadas para OLAP . Dado que se utilizan en gran medida para el procesamiento de consultas, no para la actualización de datos, la forma desnormalizada tiene algún sentido. Como un esquema estelar , pero sin los puntos. Bien, té débil, pero aún creo que hay algo allí.

Sí, si comenzar un nuevo diseño de proyecto GI es importante y puede ahorrar tiempo = dinero en el futuro. http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916 es una buena descripción de por qué es importante.