O bom design de banco de dados é menos importante para bancos de dados espaciais?

15

Tenho uma forte sensação de que o design e a normalização do banco de dados geralmente vêm em segunda mão ao lidar com dados espaciais.

Com o software que custa uma fortuna e os bancos de dados com mais de 100 tabelas de campos, tenho que perguntar:

Existem boas razões para levar outras considerações além da normalização ao projetar um banco de dados espacial?

Acho que as pessoas vão pedir exemplos, mas isso não posso dar aqui, então minha pergunta talvez seja mais direcionada para aqueles que querem dizer que 100 campos não são um problema e são mais fáceis de manter do que um design normalizado adequado.

Quais são os argumentos?

Nicklas Avén
fonte
No caso do ArcGIS, é difícil realizar um banco de dados normalizado com integridade referencial, pois você está limitado apenas aos recursos do banco de dados expostos a você e suportados pelo ArcGIS. Isso é muito frustrante como um cara de banco de dados relacional ... jogando um jogo de telefone, com o ArcSDE no meio.
Nw1 4/02

Respostas:

16

Sinto que os bancos de dados espaciais não devem ser tratados de maneira diferente dos bancos de dados tradicionais. Eles estão basicamente fazendo a mesma coisa, armazenando grandes quantidades de dados para recuperação rápida. Como exemplo, no PostgreSQL / PostGIS, a geometria é apenas outro tipo de dados. Assim como texto ou número inteiro. O mesmo no SQL Server 2008. O mesmo no Oracle. Se a parte "espacial" é apenas outro tipo de campo no banco de dados, será realmente diferente do banco de dados original? Isso significa que devemos descartar todas as regras do design tradicional de banco de dados?

Obviamente, a normalização pode ser levada longe demais, assim como nos bancos de dados tradicionais, por isso é uma troca encontrar o melhor design que atenda às suas necessidades.

Se você está planejando criar uma estrutura altamente desnormalizada com tabelas de 100 colunas, precisa se perguntar o que provavelmente mudará no futuro. Com um grande aumento de linhas, isso também afetará o desempenho da consulta? Isso afetará a manutenção no futuro?

O que há de errado em criar uma estrutura normalizada e usar visualizações para expor todos os dados ao cliente de banco de dados, seja GIS ou qualquer outro cliente?

Todas essas perguntas se aplicam aos bancos de dados tradicionais e aos bancos de dados espaciais. Se você acessar http://en.wikipedia.org/wiki/Database_normalization , descobrirá que isso também se aplica aos bancos de dados espaciais.

Se o software que você está usando no topo do banco de dados o forçar a usar estruturas altamente desnormalizadas, esse é um argumento diferente. Você é limitado pelo software e não pelo banco de dados; portanto, não há opções no melhor design de banco de dados.

Então eu acho que a resposta curta é (na minha opinião) o design de banco de dados é tão importante para bancos de dados espaciais quanto para bancos de dados tradicionais.

Kelso
fonte
1
+1 para o ponto principal da diferenciação entre a estrutura db do software e o design "melhor" para a natureza dos dados.
Matt Wilkie
Sim, concordo com esta resposta e com o comentário de Matt. Mas o que espero é que alguém possa explicar por que isso geralmente não é seguido. Vou editar a pergunta um pouco.
Nicklas Avén
Concordo. Uma coisa adicional que descobri é que o desempenho do banco de dados pode influenciar sua decisão de normalizar ou não. Em alguns casos, vejo que dois bancos de dados são usados, um banco de dados 'mestre' contendo dados normalizados e um banco de dados secundário usado apenas para fins de exibição. Este contém apenas o que é necessário para exibir dados (GIS), geralmente em uma única tabela.
Berend 28/05
Para expandir o ponto de Berends, uma das razões que contribuem para essa desnormalização é que as visualizações materializadas geralmente são um pouco difíceis e específicas para o banco de implementar, portanto, normalmente é melhor criar sua própria tabela / banco de dados para armazenar os dados desnormalizados.
Alexander
6

Eu vejo muito isso. Eu sinto que isso decorre do fato de que tradicionalmente as pessoas de GIS vêm de históricos de pesquisa e não têm um histórico / entendimento de bancos de dados. No entanto, estou vendo essa mudança, à medida que mais e mais organizações movem a infraestrutura GIS para a área de TI.

BlinkyBill
fonte
1
esse também é o meu sentimento, mas espero que, de alguma forma, a explicação seja mais como a discussão de Paulo, que seja uma escolha deliberada de alguma maneira. que daria mais sence ao buissness GIS com tantas palavras bonitas, modelos um" técnicas do que descobrir que o banco de dados na parte inferior foi mal utilizado por causa da ignorância.
Nicklas Aven
1
desculpe, mal utilizado está errado. se for delibirado por um bom motivo, não será usado de maneira incorreta.
Nicklas Avén
5

Legado do software GIS

O alto custo anterior do ArcSDE e a falta de um tipo de dados espaciais no SQL Server (até 2008) e o Oracle até a versão 10 significavam que havia pouca opção a não ser armazenar dados em shapefiles para muitas organizações (e pelos concorrentes para manter baixos os custos de licitação) .

A introdução de tipos espaciais nativos no SQL Server significou quase que instantaneamente que o ArcSDE passou de um grande investimento, passando a ser incluído gratuitamente no ArcGIS e a "recuperação" de dados espaciais nas organizações.

As organizações que usam ArcGIS e SQL Server anteriormente tinham três opções:

  1. Pague a taxa de 20k + para comprar o ArcSDE e armazenar dados espaciais em bancos de dados "adequados" do SQL Server.
  2. Armazene dados espaciais em shapefiles / GDBs pessoais e vincule ao restante dos dados organizacionais em bancos de dados (ou exporte esses atributos para DBFs)
  3. Alterne entre fornecedores GIS e armazene dados espaciais em um único banco de dados, mas em um formato acessível apenas pelo novo software GIS

Depois que o SQL Server tinha um tipo espacial nativo, a maioria dos fornecedores usava isso em vez de seus formatos proprietários, o que significa que os dados espaciais poderiam ser acessados ​​de repente por outros aplicativos. A ESRI teve que reduzir o custo do ArcSDE (o que eles fizeram ao integrá-lo ao ArcGIS) e / ou permitir que dados espaciais fossem armazenados no formato de banco de dados nativo.

Além disso, as consultas realizadas no ArcIMS em shapefiles, associadas aos DBFs, tinham que incluir todos os campos e duplicação necessários, pois não havia opção para criar visualizações espaciais ou vincular recursos facilmente a um banco de dados back-end.

Razões organizacionais

Concordo com outras pessoas que, até recentemente, os dados espaciais se tornaram um tipo de banco de dados nativo, por muito tempo foram ignorados ou mantidos separados pelos administradores de banco de dados nas organizações e se tornaram a responsabilidade de um gerente de GIS. Os conceitos de design de banco de dados, normalização, replicação, segurança e visualizações SQL requerem um conjunto de habilidades especializado muitas vezes muito diferente e especializado e não podem ser facilmente aprendidos à medida que você avança.

Razões de custo

Explicar em uma proposta a exigência de grande quantidade de tempo e esforço a serem gastos em um modelo de dados, e a limpeza / importação de dados para esse modelo geralmente é impossível. Muitas vezes, os compradores do projeto vêm de uma visão analítica do GIS e ignoram a importância dos dados estruturados.

geographika
fonte
Eu entendo e concordo com a maioria do que você escreve. Mas dizer que a parte SDE é fornecida gratuitamente após a renomeação para o servidor ArcGIS, não é o mesmo que dizer: Se você comprar a cor bonita deste carro por 100.000 dólares, receberá o restante do carro gratuitamente. Não conheço o ArcGIS tão bem, mas o que é o servidor ArcGIS sem a parte SDE? e nunca ouvi ninguém dizer que o servidor ArcGIS é barato. Realmente não vejo como os tipos espaciais do SQL Server afetaram o ArcGIS. Mas como os produtos Arc são tão amplamente difundidos, eu concordo que a estrada Arc tem um grande impacto sobre como as pessoas pensam em seus dados espaciais.
Nicklas Avén
Antes do ArcGIS Server, o ArcSDE costumava ser completamente separado do ArcMap e do ArcIMS e precisava ser comprado e licenciado separadamente. Como o ArcSDE era a única maneira de armazenar dados espaciais no SQL Server (ou Oracle na época), isso significava que os dados espaciais eram armazenados em outro local.
Geografika
ok, ArcIMS no pacote com SDE é o novo conceito. O Arcmap ainda precisa de licenças separadas por usuário ou flutuante, certo? offtopic, mas estou um pouco curioso.
Nicklas Avén
Não foi possível acessar / armazenar dados espaciais em um banco de dados relacional sem pagar grandes quantias de dinheiro extra. esri.com/software/arcgis/arcsde/index.html
geographika
o servidor ArcGIS não é uma quantia grande de dinheiro? Até onde eu sei, você não pode usar o formato sqlserver fomat ou postgis (sem ziggis) no arcmap sem sde, desculpe o ArcGIS Server no meio.
Nicklas Avén
4

Por tabelas de 100 colunas, suponho que você queira dizer os tipos de resultados obtidos ao criar sobreposições de "cobertura principal" de várias entradas. Sim, esses são artefatos do fluxo de trabalho do Arc / INFO. Mas, em defesa, você também pode pensar nelas como tabelas deliberadamente desnormalizadas para OLAP . Como eles estão sendo usados ​​principalmente para o processamento de consultas, não para atualização de dados, o formulário não normalizado faz algum sentido. Como um esquema em estrela , mas sem os, er, pontos. OK, chá fraco, mas ainda acho que há algo lá.

Paul Ramsey
fonte
1
sim Paul. Eu sabia que haveria alguma explicação por aí, incluindo palavras que eu realmente não entendo :-). Muito interessante que exista uma história deliberada por trás disso. Ótimo!
Nicklas Avén