¿Un buen diseño de base de datos es menos importante para las bases de datos espaciales?

15

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 el software que cuesta una fortuna y las bases de datos con más de 100 tablas de campos, debo preguntar:

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

Supongo que la gente pedirá ejemplos, pero que no puedo dar aquí, por lo que mi pregunta quizás esté más dirigida a aquellos que quieren decir que 100 campos no son un problema y es más fácil de mantener que un diseño normalizado adecuado.

¿Cuáles son los argumentos?

    
pregunta Nicklas Avén 13.11.2010 - 15:50

5 respuestas

16

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

Obviamente, la normalización se puede llevar 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 está planeando crear una estructura altamente des-normalizada con tablas de 100 columnas, entonces debe preguntarse qué es probable que cambie en el futuro. Con un gran aumento en las filas, ¿esto también afectará el rendimiento de las consultas? ¿Esto va a afectar 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 GIS o cualquier otro cliente?

Todas estas preguntas se aplican tanto a las bases de datos tradicionales como a las espaciales. Si analiza enlace , descubrirá 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 usar estructuras altamente des-normalizadas, 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 la base de datos.

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.

    
respondido por el Kelso 13.11.2010 - 23:19
6

Veo esto mucho. Siento que se debe al hecho de que, tradicionalmente, las personas de SIG provienen de estudios de antecedentes, y no tienen un fondo / comprensión de las bases de datos. Sin embargo, estoy viendo este cambio, a medida que más y más organizaciones mueven la infraestructura de SIG al sector de TI.

    
respondido por el BlinkyBill 14.11.2010 - 22:01
5

Legado del software GIS

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, significaban que no había más opción que almacenar datos en shapefiles para muchas organizaciones (y por licitadores para mantener la oferta). cuesta abajo).

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

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

  1. Pague la tarifa de 20k + para comprar ArcSDE y almacenar datos espaciales en bases de datos "adecuadas" de SQL Server.
  2. Almacene datos espaciales en shapefiles / personal GDBs, y enlace al resto de los datos de la organización en bases de datos (o exporte estos atributos a DBFs)
  3. Cambie a 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 usaban esto en lugar de sus formatos propietarios, lo que significa que otras aplicaciones podrían acceder a los datos espaciales de forma repentina. ESRI tuvo que reducir el costo de ArcSDE (lo que hicieron integrándolo 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 shapefiles relacionados con DBF tenían que incluir todos los campos requeridos y la duplicación ya que no había opción para crear vistas espaciales, o vincular fácilmente las características con una base de datos de back-end.

Razones de organización

Estoy de acuerdo con los demás en que, hasta hace poco, los datos espaciales se convirtieron en un tipo de base de datos nativo, los administradores de bases de datos en organizaciones las han ignorado o mantenido durante mucho tiempo, y se convierten en la responsabilidad de un administrador de SIG. Los conceptos de diseño de bases de datos, normalización, replicación, seguridad y vistas SQL requieren un conjunto de habilidades a menudo muy diferentes y especializadas y no se pueden aprender fácilmente a medida que avanza.

Razones de los costos

Explicar en una licitación el requerimiento 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 GIS y pasan por alto la importancia de los datos estructurados.

    
respondido por el geographika 15.11.2010 - 09:34
4

Por tablas de 100 columnas, asumo que te refieres a los tipos de resultados que obtienes al construir superposiciones de "cobertura maestra" de entradas múltiples. Sí, estos son artefactos del flujo de trabajo de Arc / INFO. Pero, en defensa, también puedes pensar que son tablas des-normalizadas deliberadamente para OLAP . Dado que se están utilizando en gran medida para el procesamiento de consultas, no para la actualización de datos, la forma des-normalizada tiene algún sentido. Como un esquema en estrella , pero sin los puntos, er ,. Vale, té débil, pero aún creo que hay algo allí.

    
respondido por el Paul Ramsey 14.11.2010 - 17:54
3

Sí, si comenzar un nuevo diseño de proyecto GI es importante y puede ahorrar tiempo = dinero en el futuro. enlace es una buena descripción general de por qué es importante.

    
respondido por el Mapperz 13.11.2010 - 18:00

Lea otras preguntas en las etiquetas