좋은 데이터베이스 디자인은 공간 데이터베이스에 덜 중요합니까?

공간 데이터를 다룰 때 데이터베이스 디자인과 정규화가 종종 사용된다는 느낌이 듭니다.

100 개가 넘는 필드 테이블이있는 소프트웨어 및 재산 비용으로 데이터베이스를 요청해야합니다.

공간 데이터베이스를 설계 할 때 정규화 이외의 다른 고려 사항을 고려해야하는 이유가 있습니까?

나는 사람들이 예제를 요구할 것이라고 생각하지만 여기서는 말할 수 없기 때문에 내 질문은 아마도 100 개의 필드가 문제가없고 적절한 표준화 된 디자인보다 유지하기 쉽다는 것을 의미하는 사람들을위한 것입니다.

논쟁은 무엇입니까?

공간 데이터베이스는 기존 데이터베이스와 다르게 취급해서는 안된다고 생각합니다. 빠른 검색을 위해 많은 양의 데이터를 저장하여 본질적으로 동일한 작업을 수행합니다. 예를 들어 PostgreSQL / PostGIS에서 지오메트리는 또 다른 데이터 유형입니다. 텍스트 나 정수처럼. SQL Server 2008에서도 동일합니다. Oracle에서도 동일합니다. "공간"부분이 데이터베이스의 다른 필드 유형 인 경우 원래 데이터베이스와 실제로 다른가요? 이것이 전통적인 데이터베이스 디자인의 모든 규칙을 포기해야한다는 것을 의미합니까?

기존 데이터베이스와 마찬가지로 정규화가 너무 멀리 진행될 수 있으므로 사용자의 요구에 맞는 최상의 디자인을 찾는 것이 절충됩니다.

100 개의 열로 구성된 표를 사용하여 고도로 비정규 화 된 구조를 만들 계획이라면 앞으로 어떤 변화가 있을지 스스로에게 물어봐야합니까? 행이 크게 증가하면 쿼리 성능에도 영향을 미칩니 까? 향후 유지 관리에 영향을 미치나요?

정규화 된 구조를 만들고 뷰를 사용하여 모든 데이터를 데이터베이스 클라이언트, GIS 또는 다른 클라이언트에 노출시키는 데 문제가 있습니까?

이러한 모든 질문은 기존 데이터베이스와 공간 데이터베이스 모두에 적용됩니다. http://en.wikipedia.org/wiki/Database_normalization 을 거치면 공간 데이터베이스에도 적용됩니다.

데이터베이스 위에서 사용중인 소프트웨어가 고도로 비정규 화 된 구조를 사용하도록 강요하는 경우 이는 다른 주장입니다. 데이터베이스가 아닌 소프트웨어에 의해 제한되므로 최상의 데이터베이스 디자인을 선택할 수 없습니다.

따라서 짧은 대답은 (제 생각에) 데이터베이스 디자인은 기존 데이터베이스와 마찬가지로 공간 데이터베이스에서도 중요하다고 생각합니다.

나는 이것을 많이 본다. 나는 전통적으로 GIS 사람들이 설문 조사 배경에서 왔으며 데이터베이스에 대한 배경 / 이해가 없다는 사실에서 비롯된 것이라고 생각합니다. 점점 더 많은 조직이 GIS 인프라를 IT 부서로 옮기면서 이러한 변화가 일어나고 있습니다.

GIS 소프트웨어 레거시

이전의 높은 ArcSDE 비용과 SQL Server (2008 년까지) 및 Oracle 버전 10까지의 공간 데이터 유형이 없었기 때문에 많은 조직에서 데이터를 셰이프 파일에 저장하는 것 외에 입찰 비용을 낮출 수있는 선택의 여지가 거의 없었습니다. .

SQL Server에 기본 공간 유형이 도입됨에 따라 ArcSDE는 대규모 투자에서 ArcGIS에 무료로 포함되고 조직에서 공간 데이터의 "접이식"에 들어갔습니다.

ArcGIS 및 SQL Server를 사용하는 조직은 이전에 세 가지 중에서 선택할 수있었습니다.

1. ArcSDE를 구입하고 "적절한"SQL Server 데이터베이스에 공간 데이터를 저장하려면 20k + 이상의 요금을 지불하십시오.
2. 공간 파일을 shapefile / 개인 GDB에 저장하고 데이터베이스의 나머지 조직 데이터에 연결하거나 이러한 속성을 DBF로 내보내십시오.
3. GIS 공급 업체를 전환하고 공간 데이터를 단일 데이터베이스에 저장하지만 새로운 GIS 소프트웨어에서만 액세스 할 수있는 형식으로 저장

SQL Server에 기본 공간 유형이 있으면 대부분의 공급 업체가 독점 형식 대신이 형식을 사용하므로 다른 응용 프로그램에서 공간 데이터에 갑자기 액세스 할 수 있습니다. ESRI는 ArcSDE 비용 (ArcGIS에 통합하여 수행 한 비용)을 줄이거 나 공간 데이터를 기본 데이터베이스 형식으로 저장해야했습니다.

또한 DBF와 연관된 쉐이프 파일에 대해 ArcIMS에서 수행 된 쿼리는 공간 뷰를 작성하거나 백엔드 데이터베이스와 기능을 쉽게 링크 할 수있는 옵션이 없기 때문에 모든 필수 필드 및 복제를 포함해야했습니다.

조직 이유

나는 최근에 공간 데이터가 기본 데이터베이스 유형이 될 때까지 조직의 데이터베이스 관리자에 의해 오랫동안 무시되거나 분리되어 GIS 관리자의 책임이되었다는 것에 동의합니다. 데이터베이스 디자인, 정규화, 복제, 보안 및 SQL보기의 개념에는 매우 다르고 전문화 된 기술이 필요하며 진행하면서 쉽게 배울 수 없습니다.

비용 이유

데이터 모델에 많은 시간과 노력이 필요하다는 것을 부드럽게 설명하고 데이터를이 모델로 정리 / 가져 오기하는 것은 종종 불가능합니다. 종종 프로젝트 구매자는 GIS에 대한 분석적 관점에서 왔으며 구조화 된 데이터의 중요성을 간과합니다.

100 열 테이블이란 다중 입력의 "마스터 커버리지"오버레이를 구축하여 얻을 수있는 출력의 종류를 의미한다고 가정합니다. 예, 이들은 Arc / INFO 워크 플로우의 인공물입니다. 그러나 방어에서는 의도적으로 OLAP의 비정규 화 된 테이블이라고 생각할 수도 있습니다 . 데이터 업데이트가 아닌 쿼리 처리에 주로 사용되므로 비정규 화 된 형식이 의미가 있습니다. 유사한 스타 스키마 하지만, 어, 포인트없이. 좋아, 약한 차이지만 여전히 거기에 뭔가 있다고 생각합니다.

예, 새로운 GI 프로젝트 디자인을 시작하는 것이 중요하고 미래에 시간 = 돈을 절약 할 수 있다면. http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916 은 중요한 이유에 대한 좋은 개요입니다.