Model danych dla aplikacji pogodowej

Wiele osób korzysta z mobilnych aplikacji pogodowych, aby zaplanować swój dzień – lub przynajmniej zdecydować, czy muszą nosić parasol! Jaki model danych kryje się pod tymi popularnymi programami?

Wszyscy chcemy wiedzieć, jak paskudna jest pogoda, zanim wyjdziemy na zewnątrz. Aplikacje na systemy Windows, iOS i Android dostarczają nam dokładnych i wiarygodnych informacji o aktualnych warunkach pogodowych. W tym artykule wyjaśniono szczegółowy model danych, którego można użyć w przypadku takich aplikacji.

Jakich funkcji potrzebuje aplikacja pogodowa?

Prawie każdy, kto ma smartfon, ma też co najmniej jedną aplikację pogodową. Aplikacje te dostarczają szczegółowych informacji o pogodzie, które pomagają użytkownikom przygotować się na wszelkie zmiany pogody, jakie mogą napotkać w ciągu dnia.

Co powinna zrobić aplikacja pogodowa?

Zgłaszaj aktualne warunki pogodowe, w tym ogólny stan (tj. słonecznie, częściowo zachmurzenie, zachmurzenie itp.), temperaturę powietrza, wilgotność, prędkość i kierunek wiatru, temperaturę odczuwalną, ciśnienie atmosferyczne i widoczność. Powinien również podawać ogólne informacje, takie jak godziny wschodu i zachodu słońca oraz wysokie i niskie temperatury w ciągu dnia.
Wyświetlaj szczegóły godzinowe (temperatura, wilgotność, opady, ogólne warunki pogodowe) przez następne 24 godziny.
Pokaż podstawową prognozę (dzienne wysokie i niskie temperatury, warunki pogodowe oraz godziny wschodu/zachodu słońca) na każdy dzień w następnym tygodniu lub dwóch.
Zezwól użytkownikom na ustawienie ich lokalnego miasta i innych miast, w których chcą zobaczyć pogodę.
Pozwól użytkownikom zobaczyć dane w wybranych przez nich jednostkach miary. Na przykład użytkownicy z USA prawdopodobnie woleliby temperatury w stopniach Fahrenheita i prędkość wiatru podawane w milach na godzinę, ale użytkownicy z Kanady i Europy woleliby stopnie Celsjusza i kilometry na godzinę.

Pamiętaj, aplikacja dopiero się pokazuje prognozę pogody i (w zależności od ustawień) przeliczanie jednostek miar. Nie wykonuje rzeczywistego prognozowania; po prostu otrzymuje dane prognozy z innego źródła (takiego jak służba rządowa lub agencja prognozy pogody) i wyświetla je w preferowany przez użytkownika sposób.

Model danych aplikacji pogodowej

Podzieliłem model na trzy obszary tematyczne:

Weather Logs
User Preferences
User Profiles

Omówimy każdy obszar w kolejności, w jakiej jest wymieniony.

Dzienniki pogody

To najważniejszy obszar tematyczny. Każda aplikacja pogodowa powinna zawierać te podstawowe informacje:

Aktualna rzeczywista temperatura
Aktualna „odczuwalna” temperatura, która może być inna niż rzeczywista ze względu na dodatkowe czynniki pogodowe (np. wysoka wilgotność może sprawić, że upalny dzień będzie cieplejszy, a zimny dzień – chłodniejszy).
Codziennie wysokie i niskie temperatury
Dane dotyczące punktu rosy i/lub wilgotności względnej
Prędkość wiatru
Kierunek wiatru
Ciśnienie barometryczne
Widoczność (tj. mglisty dzień będzie miał mniejszą widoczność niż pogodny dzień)
Czas wschodu i zachodu słońca

Razem dają one całościowy obraz aktualnych warunków pogodowych. Są to informacje, które będą prezentowane użytkownikom, zwykle za pomocą jednego lub więcej intuicyjnych ekranów.

Każda prognoza pogody ma dwa rodzaje atrybutów:te, które zmieniają się każdego dnia i te, które zmieniają się przez cały czas każdego dnia. Atrybuty, takie jak godziny wschodu i zachodu słońca, są oparte na wydarzeniach, które mają miejsce raz dziennie, więc te informacje są zbierane raz dziennie. Jeśli chodzi o prognozy długoterminowe (od 7 do 15 dni z wyprzedzeniem), użytkownicy powinni mieć wystarczającą ilość informacji, jeśli uwzględnisz wysokie i niskie temperatury każdego dnia, poziom wilgotności i ogólne warunki pogodowe (np. słonecznie, pochmurno itp.).

Atrybuty takie jak aktualna temperatura, odczuwalna temperatura, prędkość i kierunek wiatru, ciśnienie atmosferyczne i zasięg widoczności mogą zmieniać się w ciągu dnia. Powinny one być rejestrowane przez określony czas, powiedzmy co godzinę lub co trzy godziny. Na potrzeby tego modelu przyjmiemy jednogodzinne ramy czasowe.

Ponieważ mamy dwa rodzaje atrybutów, umieściłem dwie tabele w tym obszarze tematycznym. Pierwszy, weather_daily_forecast_log , zawiera atrybuty dzienne. Zawiera te kolumny:

city_id – Odwołuje się do city tabeli i oznacza miasto, którego te dane dotyczą.
calendar_date – Data kalendarzowa dla tych danych. Ponieważ ta tabela zawiera jeden rekord na miasto na dzień, te kolumny (city_id i calendar_date ) tworzą złożony klucz podstawowy dla tej tabeli.
weather_status_id – Odwołuje się do weather_status tabeli i oznacza warunki pogodowe (tj. deszcz, zachmurzenie, częściowe zachmurzenie lub słonecznie).
min_temperature – Minimalna (najniższa) temperatura tego dnia.
max_temperature – Maksymalna (najwyższa) temperatura tego dnia.
avg_humidity_in_percentage – średnia wilgotność względna powietrza w tym dniu. (Ilość wody, którą może zatrzymać powietrze, zależy od jego temperatury.)
sunrise_time – Kolumna sygnatury czasowej, która przechowuje czas wschodu słońca.
sunset_time – Kolumna sygnatury czasowej, która przechowuje czas zachodu słońca.
last_updated_at – Przechowuje datę i godzinę (jako znacznik czasu) ostatniej aktualizacji rekordu.
source_system – Nazwa źródła naszej prognozy pogody. Te dwie ostatnie kolumny są przechowywane do celów kontrolnych.

weather_hourly_forecast_log tabela zawiera wszystkie atrybuty, które mogą się zmieniać w ciągu dnia. Traktujemy te atrybuty jako jeden rekord w określonym przedziale czasowym. Kolumny to:

id – Klucz zastępczy do stołu.
city_id – Odpowiednie miasto.
start_timestamp – Kolumna sygnatury czasowej, która wskazuje, kiedy ten przedział czasowy się rozpoczął.
end_timestamp – Kolumna sygnatury czasowej, która wskazuje, kiedy ten przedział czasowy się skończył.
weather_status_id – Ogólny stan pogody w ramach czasowych.
temperature – Aktualna temperatura w ramach czasowych.
feels_like_temperature – Temperatura „odczuwalna” w ramach czasowych. Może na to wpływać wiele czynników, w tym wiatr, deszcz oraz wysoka lub niska wilgotność. Ta informacja daje bardziej realistyczny obraz aktualnych warunków pogodowych.
humidity_in_percentage – Ta kolumna zawiera ilość (w procentach) wilgotności powietrza.
wind_speed_in_mph – Utrzymuje prędkość wiatru w milach na godzinę (milach na godzinę).
wind_direction – Ta kolumna tekstowa przechowuje jeden lub dwa znaki oznaczające kierunek wiatru (N, NW, NE, S, W, SW, itp.)
pressure_in_mmhg – Przechowuje wartości ciśnienia powietrza w mmHg.
visibility_in_mph – Przechowuje wartości zasięgu widoczności w milach.

Tabele te będą zawierały najnowsze dane z określonego przedziału czasowego. Czasami prognoza na przyszłość może zostać wydana, a następnie zmieniona. W takich przypadkach istniejący rekord dla danego dnia lub przedziału czasowego zostanie nadpisany przez najnowszy rekord. Zauważysz też, że przechowujemy atrybuty tylko w jednej jednostce miary (np. mph) na atrybut. Aby zaoszczędzić miejsce, będziemy przechowywać tylko jeden rekord dla każdego atrybutu i pozwolimy interfejsowi przekonwertować je na preferowane przez użytkownika jednostki, gdy zajdzie taka potrzeba.

Preferencje użytkownika

Ten obszar tematyczny zajmuje się głównie preferencjami użytkownika dotyczącymi jednostek miary. Większość kolumn nie wymaga wyjaśnień, więc pokrótce wyjaśnimy cel każdej tabeli.

users tabela zawiera podstawowe informacje o użytkownikach, takie jak adres e-mail i numer telefonu. id kolumna przypisuje unikalny numer każdemu użytkownikowi, który zarejestruje się w aplikacji.

attribute tabela przechowuje listę atrybutów, takich jak temperatura, prędkość wiatru, kierunek wiatru, ciśnienie atmosferyczne itp.

measuring_units tabela przechowuje listę wszystkich jednostek miary wraz z odpowiadającą im nazwą, opisem i attribute_id .

user_preferences Tabela odwzorowuje relacje między użytkownikami i preferencjami jednostek miary. Pamiętaj, że możemy przechowywać informacje o preferencjach użytkowników dla każdego indywidualnego atrybutu. Ponieważ użytkownicy mogą wybrać dowolną jednostkę miary spośród podanych opcji dla atrybutu, stworzyliśmy złożony klucz główny przy użyciu users_id i attribute_id kolumny.

Profile użytkowników

Ponieważ aplikacja pozwala użytkownikom monitorować pogodę w dowolnej liczbie miast, ten obszar tematyczny obsługuje powiązanie jednego lub więcej miast z każdym profilem użytkownika.

city tabela przechowuje listę miast i szczegóły ich lokalizacji (kod pocztowy, kraj, współrzędne mapy). Kolumny w tej tabeli nie wymagają wyjaśnień, ale dobrze jest zdać sobie sprawę, że city_longitude i city_latitude kolumny mogą zawierać wartości dodatnie lub ujemne.

user_city tabela kojarzy miasta z profilami użytkowników. Ponieważ użytkownicy mogą dodać miasto do swoich profili tylko raz, utworzyliśmy złożony klucz podstawowy przy użyciu users_id i city_id kolumny.

Co byś dodał do tego modelu danych?

Teraz dochodzimy do sekcji, w której mówisz nam, co chciałbyś dodać, zmienić lub usunąć w modelu. Co możemy dodać? Cóż, globalne ocieplenie stało się dużym problemem. Badania jasno pokazują, że jest to spowodowane bardziej działalnością człowieka niż naturalnymi zmianami. Jednak stosunkowo niewiele osób zdaje sobie z tego sprawę. Jak możemy uświadomić ludziom zmiany klimatyczne i globalne ocieplenie? W aplikacji moglibyśmy zawrzeć informacje o zmianach środowiskowych i ich przyczynach. A może moglibyśmy uwzględnić procent zadrzewienia na lokalnym obszarze, aby podnieść świadomość.

Co myślisz? Daj nam znać swoje pomysły, komentując poniżej.