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

Я працюю над GIS-додатком на основі погоди.

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

Перешкоди, з якими я стикаюсь:

• Наразі 40 записуючих станцій, але це може змінитися
• Різні станції записують різну кількість параметрів, деякі записують 5, деякі записують 7. ect
• Деякі параметри записуються щодня (наприклад: Максимальна температура), деякі записуються щогодини (поточна температура), а інші записуються щотижня.
• Деякі споруди на певній станції звукозапису можуть бути зняті з експлуатації (наприклад: Станція, яка наразі повідомляє про 7 параметрів, може повідомити лише про 5 наступного року)
• Іноді параметр може не повідомлятися через технічні проблеми; Отже, я повинен мати можливість розмежовувати значення, значення = 0, нульове значення та значення, яке не записується.

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

Хтось може запропонувати будь-які книги чи посилання, які допомогли б мені?

Найпростішим підходом здаються три таблиці:

• станція (id, ім'я, посада, ...)
• параметр (id, ім'я, одиниця, ...)
• читання (station_id, parameter_id, часова мітка, значення, ...)

• Наразі 40 записуючих станцій, але це може змінитися

Ви можете додати будь-яку кількість станцій. Можливо, буде цікаво додати інформацію про час роботи станції до таблиці.

• Різні станції записують різну кількість параметрів, деякі записують 5, деякі записують 7. ect.
• Деякі споруди на певній станції звукозапису можуть бути зняті з експлуатації

Не проблема, оскільки відношення між записаними параметрами та станціями неявно зберігається в таблиці читання.

• Деякі параметри записуються щодня (наприклад: Максимальна температура), деякі записуються щогодини (поточна температура), а інші записуються щотижня.

Кожне читання буде представлено одним записом у таблиці читання. Різні інтервали - це не проблема.

• Іноді параметр може не повідомлятися через технічні проблеми

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

Крім того, я б запропонував переглянути стандарт спостереження OGC Sensor . Існує багато прикладів, що висвітлюють записи метеостанцій. Такі реалізації, як 52 ° північніше, мають гарну загальну схему баз даних (для PostGIS - у цьому випадку). Хоча цей стандарт (інші стандарти SWE) докладають певних зусиль для вивчення, я переконаний, що інвестиції окупляться.

На цьому тижні я займався власними дослідженнями тимчасових баз даних. Я знайшов цю відповідь на StackOverflow дуже корисною. Для фундаментального розуміння принципів варто прочитати вступні глави розробки програм, орієнтованих на базу даних, орієнтованих на час у SQL від Snodgrass. Я вважаю, що справжні тимчасові бази даних є досить складними, але більш простого рішення - наприклад, підкреслення, - може бути достатньо.