Проектирование пространственной базы данных для временных данных? [закрыто]

Я работаю над ГИС-приложением, основанным на погоде.

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

Препятствия, с которыми я сталкиваюсь:

• В настоящее время есть 40 станций записи, но это может измениться
• Разные станции записывают разное количество параметров, некоторые записи 5, некоторые записи 7. т. Д.
• Некоторые параметры записываются ежедневно (например, максимальная температура), некоторые записываются ежечасно (текущая температура), а другие записываются еженедельно.
• Некоторые объекты на конкретной станции записи могут быть выведены из эксплуатации (например, станция, которая в настоящее время сообщает 7 параметров, может сообщить только 5 в следующем году)
• Иногда параметр может не сообщаться из-за технических проблем; Следовательно, я должен иметь возможность различать, значение = 0, нулевое значение и значение не записано.

Я работаю с ArcGIS (десктоп и сервер) для пространственной части этого веб-приложения, и использование ArcSDE не является проблемой, но я думаю, что такую ​​базу данных лучше всего оставить как чистую базу данных, а не включать в нее ArcSDE.

Кто-нибудь может предложить какие-нибудь книги или ссылки, которые могли бы мне помочь?

Самый простой подход, кажется, три таблицы:

• станция (идентификатор, имя, должность, ...)
• параметр (идентификатор, имя, единица измерения, ...)
• чтение (station_id, parameter_id, timestamp, value, ...)

• В настоящее время есть 40 станций записи, но это может измениться

Вы можете добавить любое количество станций. Может быть интересно добавить информацию о времени работы станции в таблицу.

• Разные станции записывают разное количество параметров, некоторые записи 5, некоторые записи 7. и т. Д.
• Некоторые объекты на конкретной станции записи могут быть выведены из эксплуатации

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

• Некоторые параметры записываются ежедневно (например, максимальная температура), некоторые записываются ежечасно (текущая температура), а другие записываются еженедельно.

Каждое чтение будет представлено одной записью в таблице чтения. Разные интервалы не проблема.

• Иногда параметр может не сообщаться из-за технических проблем

В этом случае просто не будет записи в таблице чтения.

Кроме того, я бы посоветовал взглянуть на OGC Sensor Observation Standard . Есть много примеров, охватывающих записи метеостанций. Такие реализации, как 52 ° северной широты, поставляются с хорошей общей схемой базы данных (в данном случае для PostGIS). Хотя этот стандарт (и другие стандарты SWE) требуют определенных усилий, я уверен, что инвестиции окупятся.

На этой неделе я проводил собственное исследование временных баз данных. Я нашел этот ответ на StackOverflow очень полезным. Для фундаментального понимания принципов стоит прочитать вступительные главы « Разработка приложений баз данных, ориентированных на время, в SQL от Snodgrass». Я нахожу, что настоящие временные базы данных довольно сложны, но может оказаться достаточным более простое решение, такое как в Подземье .