Модел на данни за приложение за времето

Много хора използват мобилни приложения за времето, за да планират деня си – или поне да решат дали трябва да носят чадър! Какъв тип модел на данни се крие под тези популярни програми?

Всички искаме да знаем колко гадно е времето, преди да излезем навън. Приложенията за Windows, iOS и Android ни дават точна и надеждна информация за текущите метеорологични условия. Тази статия обяснява подробен модел на данни, който може да се използва за такива приложения.

Какви функции са необходими на приложението за времето?

Почти всеки, който има смартфон, има и поне едно приложение за времето. Тези приложения предоставят подробна информация за времето, която помага на потребителите им да се подготвят за всякакви метеорологични промени, които могат да срещнат през деня.

Какво трябва да прави приложението за времето?

Докладвайте текущите метеорологични условия, включително общото състояние (т.е. слънчево, частично облачно, облачно и т.н.), температура на въздуха, влажност, скорост и посока на вятъра, температура като „по усещане“, барометрично налягане и видимост. Той също така трябва да отчита обща информация като време на изгрев и залез и високи и ниски температури през деня.
Показване на подробности за час (температура, влажност, валежи, общо метеорологично състояние) за следващите 24 часа.
Показване на основна прогноза (дневни високи и ниски температури, метеорологични условия и време на изгрев/залез) за всеки ден през следващите седмица или две.
Позволете на потребителите да задават своя местен град и всички други градове, където искат да видят времето.
Позволете на потребителите да виждат данни в мерните единици по техен избор. Например потребителите в САЩ вероятно биха предпочели температурите по Фаренхайт и скоростите на вятъра, показани в мили в час, но канадските и европейските потребители биха предпочели Целзий и километри в час.

Не забравяйте, че приложението просто показва прогнозата за времето и (в зависимост от настройките) преобразуване на мерни единици. Той не прави реалното прогнозиране; той просто получава прогнозни данни от друг източник (като правителствена служба или агенция за прогнози за времето) и ги показва по предпочитания от потребителя начин.

Моделът на данните на приложението за времето

Разделих модела на три тематични области:

Weather Logs
User Preferences
User Profiles

Ще обсъдим всяка област в реда, в който е изброен.

Дневници за времето

Това е най-важната предметна област. Всяко приложение за времето трябва да улавя тези основни подробности:

Текуща действителна температура
Текущата температура, която се усеща като такава, която може да е различна от действителната температура поради допълнителни метеорологични фактори (напр. високата влажност може да направи горещ ден по-горещ или студен ден по-студен).
Дневни високи и ниски температури
Данни за точката на оросяване и/или относителната влажност
Скорост на вятъра
Посока на вятъра
Барометрично налягане
Видимост (т.е. мъглив ден ще има по-ниска видимост от ясен ден)
Часове на изгрев и залез

Заедно те дават цялостна представа за текущото метеорологично състояние. Това е информацията, която ще бъде представена на потребителите, обикновено чрез един или повече интуитивни екрани.

Има два вида атрибути към всяка прогноза за времето:такива, които се променят всеки ден и такива, които се променят през всеки ден. Атрибути като изгрев и залез се основават на събития, които се случват веднъж на ден, така че тази информация се улавя веднъж за всеки ден. Когато става въпрос за дългосрочни прогнози (от 7 до 15 дни предварително), потребителите трябва да имат достатъчно информация, ако включите всеки ден високи и ниски температури, ниво на влажност и общи метеорологични условия (т.е. слънчево, облачно и т.н.).

Атрибути като текуща температура, температура на усещане, скорост и посока на вятъра, барометрично налягане и диапазон на видимост могат да се променят през целия ден. Те трябва да бъдат заснети за определен интервал от време, да речем на всеки час или на всеки три часа. За целите на този модел ще приемем период от един час.

Тъй като имаме два типа атрибути, поставих две таблици в тази тематична област. Първият, weather_daily_forecast_log , съдържа ежедневните атрибути. Той съдържа следните колони:

city_id – Препраща city таблица и обозначава града, за който се отнасят тези данни.
calendar_date – Календарната дата за тези данни. Тъй като тази таблица съдържа по един запис на град на дата, тези колони (city_id и calendar_date ) формира съставния първичен ключ за тази таблица.
weather_status_id – Препраща към weather_status таблица и обозначава метеорологичните условия (т.е. дъждовно, облачно, частично облачно или слънчево).
min_temperature – Минималната (най-ниска) температура за този ден.
max_temperature – Максималната (най-висока) температура за този ден.
avg_humidity_in_percentage – Средното относителна влажност на въздуха през този ден. (Количеството вода, което въздухът може да задържи, е в зависимост от неговата температура.)
sunrise_time – Колона с времеви отпечатъци, която съхранява времето на изгрев.
sunset_time – Колона с времеви отпечатъци, която съхранява времето за залез.
last_updated_at – Съдържа датата и часа (като времева марка), когато записът е актуализиран последно.
source_system – Името на източника на нашата прогноза за времето. Последните две колони се съхраняват за целите на одита.

weather_hourly_forecast_log таблицата съдържа всички атрибути, които могат да се променят през деня. Ние считаме тези атрибути като един запис за определен период от време. Колоните са:

id – Сурогатният ключ за масата.
city_id – Съответният град.
start_timestamp – Колона с времеви отпечатък, която показва кога е започнала тази времева рамка.
end_timestamp – Колона с времеви отпечатък, която показва кога е приключил този период.
weather_status_id – Общото състояние на времето за периода.
temperature – Текущата температура за времевата рамка.
feels_like_temperature – Температурата, която се усеща, за периода от време. Това може да бъде повлияно от много фактори, включително вятър, дъжд и висока или ниска влажност. Тази информация дава по-реалистично впечатление за текущите метеорологични условия.
humidity_in_percentage – Тази колона съдържа количеството (като процент) влажност на въздуха.
wind_speed_in_mph – Задържа скоростта на вятъра в мили в час (мили в час).
wind_direction – Тази текстова колона съхранява един или два знака, които обозначават посоката на вятъра (N, NW, NE, S, W, SW и др.)
pressure_in_mmhg – Съхранява стойностите на въздушното налягане в mmHg.
visibility_in_mph – Съхранява стойностите на диапазона на видимост в мили.

Тези таблици ще съдържат най-новите данни за определен период от време. Понякога може да бъде издадена бъдеща прогноза и след това да бъде променена. В такива случаи съществуващият запис за съответния ден или времева рамка ще бъде презаписан от последния. Освен това ще забележите, че сме съхранявали атрибути само в една мерна единица (напр. mph) за атрибут. За да спестим съхранение, ще съхраняваме само един запис за всеки атрибут и ще оставим предния край да ги преобразува в предпочитаните от потребителя единици, когато е необходимо.

Потребителски предпочитания

Тази предметна област се занимава главно с предпочитанията на потребителите за мерни единици. Повечето от колоните са обясними сами по себе си, така че просто ще обясним накратко целта на всяка таблица.

users таблицата съдържа основна информация за потребителите, като имейл адрес и телефонен номер. id колоната присвоява уникален номер на всеки потребител, който се регистрира в приложението.

Атрибутът attribute таблицата съхранява списък с атрибути, като температура, скорост на вятъра, посока на вятъра, барометрично налягане и др.

measuring_units таблицата съхранява списък на всички мерни единици със съответното им име, описание и attribute_id .

user_preferences таблицата показва връзката между потребителите и предпочитанията за мерни единици. Имайте предвид, че можем да съхраняваме информация за предпочитанията на потребителите за всеки отделен атрибут. Тъй като потребителите могат да избират всяка една мерна единица от дадените опции за атрибут, ние създадохме съставен първичен ключ, използвайки users_id и attribute_id колони.

Потребителски профили

Тъй като приложението позволява на потребителите да наблюдават времето в толкова градове, колкото искат, тази тематична област обработва асоциирането на един или повече градове с всеки потребителски профил.

city таблица съхранява списък с градове и подробности за тяхното местоположение (пощенски код, държава, координати на картата). Колоните в тази таблица са обясними сами по себе си, но е добре да разберете, че city_longitude и city_latitude колоните могат да съдържат положителни или отрицателни стойности.

user_city таблицата свързва градовете с потребителски профили. Тъй като потребителите могат да добавят град към своите профили само веднъж, създадохме съставен първичен ключ с помощта на users_id и city_id колони.

Какво бихте добавили към този модел на данни?

Сега стигаме до секцията, в която ни казвате какво бихте добавили, променили или изтрили в модел. Какво можем да добавим? Е, глобалното затопляне се превърна в голяма грижа. Изследванията ясно показват, че то се причинява повече от човешка дейност, отколкото от естествени промени. Въпреки това, сравнително малко хора осъзнават това. Как можем да информираме хората за промените в климата и глобалното затопляне? Бихме могли да включим факти за промените в околната среда и техните причини в приложението. Или може би бихме могли да включим процента на дървесната покривка в местен район, за да повишим осведомеността.

Какво мислиш? Моля, уведомете ни вашите идеи, като коментирате по-долу.