Как спроектировать базу данных в предметной области «Погода»?

Question

[stoxx2011]

Делаю курсовую работу по базам данных. У меня предметная область «Прогноз погоды». Даны три сущности: погода, прогнозы и отчёты.
Помогите, пожалуйста, хотя бы прикинуть модель этой базы: какие атрибуты должны быть у таблиц и какие типы связи между таблицами сделать.

Answer 1

[Алексей Черемисин]

Здесь как минимум нужно немного залезть в предметную область и ответить себе на вопросы (до таблиц и полей):
- что такое "погода", чем она измеряется, какие у нее характеристики, есть ли табличные данные: типа привязки к местности (город, район и т.д.), таблицы комфорта (комфортно не очень, не комфортно) или влажности (сухо, влажно, мокро и т.д.)?
- тоже самое расписываем для прогноза.
- теперь по отчетам, какие типы отчетов планируются ( за день по местности, пелевантность по прогнозу и т.д.).
Что касается отчетов, то они бывают (обычно) двух типов.
Одни формируются простой выборкой из базы данных с агрегацией - это простые агрегированные отчеты (средняя температура за час, или минимум/максимум за период по местности). Для таких отчетов обычно не нужно создавать таблиц и хранить промежуточные данные, если только не для ускорения предоставления и не в целях архивации (например подсчет и сохранение средней температуры день/ночь ежедневно по окончании суток).
Вторые - аналитические. Например средняя ошибка в прогнозах за одинаковые периоды по местностям. Это те отчеты, которые требуют агрегации нескольких выборок, здесь приходится создавать промежуточные таблицы с результатами выборок, и уже по ним формировать выходные данные ( как нахождение второй и третьей производных функций).
В общем, сначала описываете СЛОВАМИ что у вас есть на входе по погоде и температуре, и какие отчеты хотелось бы получить. А уже из этого делаете модель данных под простые отчеты, и в самом конце занимаетесь аналитикой. Также сразу позаботьтесь об объемах данных, вдруг их придется шардировать, архивировать и т.д..
Наводящие вопросы я задал. Отвечайте, двинемся дальше.

Comments

[stoxx2011]

Спасибо за такой развёрнутый ответ!

Я предполагал, что у меня будут две почти одинаковые таблицы - прогноз и погода. В обоих есть такие поля, как температура, давление, влажность, ветер, город и дата. Первая заполняется на несколько дней вперёд, а вторая непосредственно сегодня.

Теперь по поводу отчётов. Хотел бы там хранить такие данные: температура, которая прогнозировалась; температура, которая была; давление, которое прогнозировалось и давление, которое было. Ну и дальше в том же духе.

Интересует вопрос, как заносить данные в таблицу отчётов. Есть ли какие-то специальные возможности у MySQL для автоматического заполнения этой таблицы? Или лучше написать на сервере скрипт, который будет запускаться по расписанию?

[Алексей Черемисин]

stoxx2011:

Я предполагал, что у меня будут две почти одинаковые таблицы - прогноз и погода. В обоих есть такие поля, как температура, давление, влажность, ветер, город и дата. Первая заполняется на несколько дней вперёд, а вторая непосредственно сегодня.

Это нормально и правильно.

Теперь по поводу отчётов. Хотел бы там хранить такие данные: температура, которая прогнозировалась; температура, которая была; давление, которое прогнозировалось и давление, которое было. Ну и дальше в том же духе.

А вот это зачем?! В вас уже есть эти данные, не нужно плодить сущности. Тем более, что они получаются вообще одним запросом!

select * from pogoda, prognoz where pogoda.date between (cast('2014-02-01' as date) and cast('2014-02-28' as date) and  prognoz.date between (cast('2014-02-01' as date) and cast('2014-02-28' as date)

Как видите, здесь никаких дополнительных таблиц строить не нужно. Запрос простой агрегационный.

[Алексей Черемисин]

Ну и конечно у MySQL есть специальные возможности по переливке запросов из таблицы в таблицу. См. "insert into select" - www.mysql.ru/docs/man/INSERT_SELECT.html . Есть более правильный синкаксис "select into", но он в MySQL не реализован, но есть в PostgeSQL.

[Алексей Черемисин]

Я бы большее внимание обратил на сами данные и прогнозы. Прогноз же строится на какой-то период (по моему), а измерения проводятся в конкретный момент. Может быть имеет смысл связать сразу прогноз и измерения при заливке результатов измерений в базу? Другими словами, одна строка в таблице прогноза может соответствовать нескольким строкам с измерениями?

[Алексей Черемисин]

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

[stoxx2011]

Алексей Черемисин: То есть хранить в таблице прогнозов строку, допустим, прогноз на 25 число, а в другой таблице измерения в этот день в 9 часов, 12 часов и так далее?

[Алексей Черемисин]

Можно и одной таблицей обойтись, добавив битовое поле прогноз/измерение! Тогда и запросы будут легче и аналитика и расширять проще...

[stoxx2011]

Алексей Черемисин: Хорошо. Спасибо большое за помощь, Вы мне очень помогли =)

[Алексей Черемисин]

Пожалуйста! Надеюсь.