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

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

Оскільки програмне забезпечення коштує цілий стан і бази даних з понад 100 таблицями полів, я повинен запитати:

Чи є вагомі причини брати інші міркування, ніж нормалізація, при розробці просторової бази даних?

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

Які аргументи?

Я вважаю, що просторові бази даних не повинні по-різному ставитися до традиційних баз даних. Вони по суті роблять те саме, зберігаючи велику кількість даних для швидкого пошуку. Наприклад, у PostgreSQL / PostGIS геометрія - це лише інший тип даних. Так само, як текст або ціле число. Те саме в SQL Server 2008. Те саме в Oracle. Якщо "просторова" частина - це лише інший тип поля в базі даних, то чи справді вона відрізняється від вихідної бази даних? Чи означає це, що ми повинні викинути всі правила традиційного дизайну баз даних?

Очевидно, що нормалізація може бути зайнята занадто далеко, як і у традиційних базах даних, тому потрібно знайти кращий дизайн, який відповідає вашим потребам.

Якщо ви плануєте створити сильно денормалізовану структуру з таблицями з 100 стовпців, то вам доведеться запитати себе, що може змінитися в майбутньому? Зі значним збільшенням рядків це також вплине на ефективність запитів? Чи це вплине на ремонтопридатність у майбутньому?

Що не так у створеній нормалізованій структурі та використанні поглядів для викриття всіх даних клієнтом бази даних, будь то ГІС чи будь-який інший клієнт?

Усі ці питання стосуються як традиційних, так і просторових баз даних. Якщо ви пройдете http://en.wikipedia.org/wiki/Database_normalization, ви побачите, що це стосується і просторових баз даних.

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

Тому я вважаю, що коротка відповідь - це (на мою думку) дизайн баз даних так само важливий як для просторових баз даних, так і для традиційних баз даних.

Я це багато бачу. Я відчуваю, що це випливає з того, що традиційно люди, що займаються ГІС, походять із фонового опитування та не мають досвіду / розуміння баз даних. Я бачу цю зміну, хоча все більше організацій переносить інфраструктуру ГІС у склад ІТ.

Спадщина програмного забезпечення GIS

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

Впровадження в SQL Server вітчизняних просторових типів майже миттєво означало, що ArcSDE перейшла від величезних інвестицій, до безкоштовного включення в ArcGIS та "внесення в складку" просторових даних в організаціях.

Організації, які використовують ArcGIS і SQL Server, раніше мали три варіанти:

1. Сплатіть 20k + плату за придбання 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 - це хороший огляд того, чому це важливо.