Является ли хороший дизайн базы данных менее важным для пространственных баз данных?

У меня есть сильное чувство, что проектирование и нормализация баз данных часто становятся второстепенными при работе с пространственными данными.

С ценным программным обеспечением и базами данных с более чем 100 полями таблиц я должен спросить:

Есть ли веские причины для принятия других соображений, кроме нормализации, при проектировании пространственной базы данных?

Я думаю, что люди будут просить примеры, но я не могу привести здесь, так что мой вопрос, возможно, больше ориентирован на тех, кто имеет в виду, что 100 полей не проблема и их легче поддерживать, чем надлежащий нормализованный дизайн.

Каковы аргументы?

Я чувствую, что пространственные базы данных должны рассматриваться не иначе, как традиционные базы данных. По сути, они делают то же самое, сохраняя большие объемы данных для быстрого поиска. Например, в PostgreSQL / PostGIS геометрия - это просто еще один тип данных. Так же, как текст или целое число. То же самое в SQL Server 2008. То же самое в Oracle. Если «пространственная» часть - это просто другой тип поля в базе данных, то действительно ли она отличается от исходной базы данных? Значит ли это, что мы должны выбросить все правила традиционного проектирования баз данных?

Очевидно, что нормализацию можно зайти слишком далеко, как и в случае с традиционными базами данных, поэтому стоит найти оптимальный дизайн, соответствующий вашим потребностям.

Если вы планируете создать сильно ненормализованную структуру с таблицами из 100 столбцов, то вам следует спросить себя, что может измениться в будущем? При значительном увеличении количества строк это также повлияет на производительность запросов? Это повлияет на ремонтопригодность в будущем?

Что не так с созданием нормализованной структуры и использованием представлений для предоставления всех данных клиенту базы данных, будь то ГИС или любой другой клиент?

Все эти вопросы относятся как к традиционным базам данных, так и к пространственным базам данных. Если вы пройдете через http://en.wikipedia.org/wiki/Database_normalization, то обнаружите, что она также применима к пространственным базам данных.

Если программное обеспечение, которое вы используете поверх базы данных, заставляет вас использовать сильно ненормализованные структуры, то это другой аргумент. Вы ограничены программным обеспечением, а не базой данных, поэтому у вас нет выбора в лучшем дизайне базы данных.

Поэтому я думаю, что короткий ответ (на мой взгляд) дизайн базы данных так же важен для пространственных баз данных, как и для традиционных баз данных.

Я вижу это много. Я чувствую, что это связано с тем фактом, что люди, занимающиеся ГИС, традиционно имеют опыт работы в сфере съемок и не имеют опыта работы с базами данных. Однако я вижу это изменение, так как все больше и больше организаций перемещают ГИС-инфраструктуру в область ИТ.

ГИС Software Legacy

Прежняя высокая стоимость ArcSDE и отсутствие пространственного типа данных в SQL Server (до 2008 года) и Oracle до версии 10 означали, что у многих организаций не было иного выбора, кроме как хранить данные в шейп-файлах (и участниками торгов, чтобы снизить затраты на торги) ,

Внедрение собственных пространственных типов в SQL Server почти мгновенно означало, что ArcSDE превратился из огромных инвестиций в бесплатное включение в ArcGIS и «привнесение в сгиб» пространственных данных в организациях.

Организации, использующие ArcGIS и SQL Server, ранее имели три варианта:

1. Заплатите 20 000+ за покупку ArcSDE и хранение пространственных данных в «правильных» базах данных SQL Server.
2. Сохраняйте пространственные данные в шейп-файлах / личных GDB и связывайте их с остальными организационными данными в базах данных (или экспортируйте эти атрибуты в DBF)
3. Переключение поставщиков ГИС и хранение пространственных данных в одной базе данных, но в формате, доступном только для нового программного обеспечения ГИС

Когда SQL Server имеет собственный пространственный тип, большинство поставщиков используют его вместо своих собственных форматов, что означает, что другие приложения могут внезапно получить доступ к пространственным данным. ESRI пришлось либо снизить стоимость ArcSDE (что они сделали, интегрировав его в ArcGIS), и / или позволить хранить пространственные данные в собственном формате базы данных.

Кроме того, запросы, выполняемые в ArcIMS для шейп-файлов, означающие, что они связаны с DBF, должны включать все обязательные поля и дублирование, поскольку не было возможности создавать пространственные представления или легко связывать объекты с внутренней базой данных.

Организационные Причины

Я согласен с другими в том, что до недавнего времени пространственные данные становились родным типом базы данных, они долгое время игнорировались или держались отдельно администраторами баз данных в организациях и становились ответственными за ГИС-менеджера. Концепции проектирования базы данных, нормализации, репликации, безопасности и представлений SQL требуют зачастую очень разных и специализированных навыков и не могут быть легко изучены в процессе работы.

Стоимость Причины

Объяснение в тендере требует большого количества времени и усилий, затрачиваемых на модель данных, и очистка / импорт данных в эту модель часто невозможны. Часто покупатели проекта исходят из аналитической точки зрения ГИС и упускают из виду важность структурированных данных.

Под таблицами в 100 столбцов я предполагаю, что вы имеете в виду виды выходных данных, которые вы получаете при построении оверлеев «основного покрытия» нескольких входов. Да, это артефакты рабочего процесса Arc / INFO. Но, в защиту, вы также можете думать о них как о намеренно ненормализованных таблицах для OLAP . Так как они используются в основном для обработки запросов, а не для обновления данных, ненормализованная форма имеет некоторый смысл. Как схема звезды , но без точек. Хорошо, слабый чай, но все же я думаю, что-то есть.

Да, если запуск нового проекта GI важен и может сэкономить время = деньги в будущем. http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916 - хороший обзор того, почему это важно.