¿Es el diseño de una buena base de datos 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 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?

spatial-database database-design Nicklas Avén
fuente
En el caso de ArcGIS, una base de datos normalizada con integridad referencial es difícil de lograr, ya que está limitado solo a las características de la base de datos expuestas a usted y respaldadas por ArcGIS. Esto es muy frustrante como un tipo de base de datos relacional ... jugando un juego de teléfono, con ArcSDE en el medio.
nw1

Respuestas:

16

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.

Kelso
fuente
1
+1 para el punto clave de diferenciar entre el software que dicta la estructura db versus el "mejor" diseño para la naturaleza de los datos.
Matt Wilkie
Sí, tanto esta respuesta como el comentario de Matt estoy de acuerdo. Pero lo que espero es que alguien pueda explicar por qué esto a menudo no se sigue. Editaré la pregunta un poco.
Nicklas Avén
Estoy de acuerdo. Una cosa adicional que encontré es que el rendimiento de la base de datos puede influir en su decisión de normalizar o no. En algunos casos, veo que se usan dos bases de datos, una base de datos 'maestra' que contiene datos normalizados y una base de datos secundaria que se usa solo con fines de visualización. Este solo contiene lo que sea necesario para mostrar datos (SIG), generalmente en una sola tabla.
Berend
Para ampliar el punto de Berends, una de las razones que contribuyen a esta denormalización es que las vistas materializadas a menudo son un poco difíciles y específicas de implementar, por lo que normalmente es mejor hacer su propia tabla / base de datos para almacenar los datos denormalizados.
Alexander
6

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.

BlinkyBill
fuente
1
este es mi sentimiento también, pero espero de alguna manera que la explicación se parezca más a la discusión de Paul, que sea una elección deliberada de alguna manera. eso le daría más sentido al negocio SIG con tantas palabras elegantes, modela "técnicas que descubrir que la base de datos en la parte inferior fue mal utilizada por ignorancia."
Nicklas Avén
1
lo siento, mal uso está mal. si es un delibirato con una buena razón, no es mal uso.
Nicklas Avén
5

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.

geographika
fuente
Entiendo y estoy de acuerdo con la mayoría de lo que escribes. Pero decir que la parte SDE se entrega de forma gratuita después del cambio de nombre al servidor ArcGIS, no es como decir: si compra el hermoso color de este automóvil por 100000 dólares, obtendrá el resto del automóvil de forma gratuita. No conozco ArcGIS tan bien, pero ¿qué es el servidor ArcGIS sin la parte SDE? y nunca escuché a nadie decir que el servidor ArcGIS es barato. Realmente no veo cómo los tipos espaciales de SQL Server han afectado a ArcGIS. Pero dado que los productos Arc están tan extendidos, estoy de acuerdo en que el camino Arc tiene un gran impacto en cómo la gente piensa en sus datos espaciales.
Nicklas Avén
Antes de ArcGIS Server, ArcSDE solía estar completamente separado de ArcMap y ArcIMS y tenía que comprarse y licenciarse por separado. Como ArcSDE era la única forma de almacenar datos espaciales en SQL Server (u Oracle en ese momento) significaba que los datos espaciales se almacenaban en otro lugar.
geographika
ok, ArcIMS en paquete con SDE es el nuevo concepto. Arcmap todavía necesita licencias separadas por usuario o flotante, ¿verdad? fuera del tema, pero tengo un poco de curiosidad.
Nicklas Avén
El nuevo concepto fue no acceder / almacenar datos espaciales en una base de datos relacional sin pagar grandes cantidades de dinero extra. esri.com/software/arcgis/arcsde/index.html
geographika
¿No es el servidor ArcGIS una gran cantidad de dinero? Por lo que sé, no puede usar el formato sqlserver fomat o postgis (sin ziggis) en arcmap sin sde, lo siento ArcGIS Server en el medio.
Nicklas Avén el
4

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í.

Paul Ramsey
fuente
1
si Paul. Sabía que habría alguna explicación, incluyendo palabras que realmente no entiendo :-). Muy interesante que haya una historia deliberada detrás de esto. ¡Excelente!
Nicklas Avén