sql >> Databasteknik >  >> RDS >> Database

En datamodell för en väderapp

Många människor använder mobila väderappar för att planera sin dag – eller åtminstone bestämma om de behöver ha med sig ett paraply! Vilken typ av datamodell ligger bakom dessa populära program?

Vi vill alla veta hur otäckt vädret är innan vi går ut. Windows-, iOS- och Android-appar ger oss korrekt och pålitlig information om aktuella väderförhållanden. Den här artikeln förklarar en detaljerad datamodell som kan användas för sådana appar.

Vilka funktioner behöver en väderapp?

Nästan alla som har en smartphone har också minst en väderapp. Dessa appar tillhandahåller detaljerad väderinformation, vilket hjälper deras användare att förbereda sig för alla väderförändringar de kan stöta på under dagen.

Vad ska en väderapp göra?

  • Rapportera aktuella väderförhållanden, inklusive den övergripande statusen (d.v.s. soligt, delvis molnigt, molnigt, etc.) lufttemperatur, luftfuktighet, vindhastighet och riktning, en "känsla-liknande" temperatur, barometertryck och sikt. Den bör också rapportera allmän information som tider för soluppgång och solnedgång och dagens höga och låga temperaturer.
  • Visa timinformation (temperatur, luftfuktighet, nederbörd, övergripande väderförhållanden) för de kommande 24 timmarna.
  • Visa en grundläggande prognos (dagliga höga och låga temperaturer, väderförhållanden och tider för soluppgång/solnedgång) för varje dag under nästa vecka eller två.
  • Tillåt användare att ställa in sin lokala stad och andra städer där de vill se vädret.
  • Låt användarna se data i de måttenheter de väljer. Till exempel skulle amerikanska användare förmodligen föredra Fahrenheit-temperaturer och vindhastigheter i miles per timme, men kanadensiska och europeiska användare skulle föredra Celsius och kilometer per timme.

Kom ihåg att appen bara visas väderprognosen och (beroende på inställningarna) omvandling av måttenheter. Den gör inte själva prognosen; den tar helt enkelt emot prognosdata från en annan källa (som en statlig tjänst eller en väderprognosmyndighet) och visar den på användarens sätt.

Weather App Data Model




Jag har delat upp modellen i tre ämnesområden:

  1. Weather Logs
  2. User Preferences
  3. User Profiles

Vi kommer att diskutera varje område i den ordning de är listade.

Väderloggar

Detta är det viktigaste ämnesområdet. Alla väderappar bör fånga dessa grundläggande detaljer:

  • Aktuell verklig temperatur
  • Aktuell "känns som" temperatur, som kan skilja sig från den faktiska temperaturen på grund av ytterligare väderfaktorer (t.ex. hög luftfuktighet kan göra att en varm dag känns varmare eller en kall dag känns kallare).
  • Dagliga höga och låga temperaturer
  • Data om daggpunkt och/eller relativ fuktighet
  • Vindhastighet
  • Vindriktning
  • Barometertryck
  • Sykt (dvs. en dimmig dag har lägre sikt än en klar dag)
  • Soluppgång och solnedgång

Tillsammans ger dessa en helhetsbild av aktuella väderförhållanden. Detta är informationen som kommer att presenteras för användare, vanligtvis via en eller flera intuitiva skärmar.

Det finns två typer av attribut för varje väderprognos:de som ändras varje dag och de som ändras genom varje dag. Attribut som tider för soluppgång och solnedgång är baserade på händelser som inträffar en gång om dagen, så denna information samlas in en gång för varje dag. När det gäller långdistansprognoser (från 7 till 15 dagar i förväg) bör användarna ha tillräckligt med information om du inkluderar varje dags höga och låga temperaturer, luftfuktighetsnivå och övergripande väderförhållanden (d.v.s. soligt, molnigt, etc).

Attribut som aktuell temperatur, "känsla som" temperatur, vindhastighet och riktning, barometertryck och siktintervall kan ändras under en dag. Dessa bör fångas för ett visst tidsintervall, säg varje timme eller var tredje timme. För denna modells syften antar vi en tidsram på en timme.

Eftersom vi har två typer av attribut, har jag lagt två tabeller i detta ämnesområde. Den första, weather_daily_forecast_log , har de dagliga attributen. Den innehåller dessa kolumner:

  • city_id – Refererar till city tabell och anger den stad som dessa uppgifter gäller.
  • calendar_date – Kalenderdatum för denna data. Eftersom den här tabellen innehåller en post per stad och datum, är dessa kolumner (city_id och calendar_date ) bildar den sammansatta primärnyckeln för denna tabell.
  • weather_status_id – Refererar till weather_status tabell och anger väderförhållandena (dvs. regnigt, molnigt, delvis molnigt eller soligt).
  • min_temperature – Dagens lägsta (lägsta) temperatur.
  • max_temperature – Dagens högsta (högsta) temperatur.
  • avg_humidity_in_percentagegenomsnittet relativ fuktighet i luften den dagen. (Mängden vatten som luft kan hålla är i förhållande till dess temperatur.)
  • sunrise_time – En tidsstämpelskolumn som lagrar soluppgångstiden.
  • sunset_time – En tidsstämpelskolumn som lagrar solnedgångstiden.
  • last_updated_at – Innehåller datum och tid (som en tidsstämpel) när posten senast uppdaterades.
  • source_system – Namnet på källan till vår väderprognos. Dessa två sista kolumner sparas för revisionsändamål.

weather_hourly_forecast_log Tabellen innehåller alla attribut som kan ändras under dagen. Vi betraktar dessa attribut som en post för en specifik tidsram. Kolumnerna är:

  • id – Surrogatnyckeln för bordet.
  • city_id – Den aktuella staden.
  • start_timestamp – En tidsstämpelskolumn som anger när denna tidsram började.
  • end_timestamp – En tidsstämpelskolumn som anger när denna tidsram slutade.
  • weather_status_id – Den övergripande väderstatusen för tidsramen.
  • temperature – Aktuell temperatur för tidsramen.
  • feels_like_temperature – Den "känsla-som" temperaturen för tidsramen. Detta kan påverkas av många faktorer, inklusive vind, regn och hög eller låg luftfuktighet. Denna information ger ett mer realistiskt intryck av aktuella väderförhållanden.
  • humidity_in_percentage –Denna kolumn innehåller mängden (i procent) fukt i luften.
  • wind_speed_in_mph – Håller vindhastigheten i mph (miles per hour).
  • wind_direction – Den här textkolumnen lagrar ett eller två tecken som anger vindriktning (N, NW, NE, S, W, SW, etc.)
  • pressure_in_mmhg – Lagrar lufttrycksvärden, i mmHg.
  • visibility_in_mph – Lagrar siktvärden i miles.

Dessa tabeller kommer att innehålla de senaste uppgifterna för en viss tidsram. Ibland kan en framtidsprognos utfärdas och sedan ändras senare. I sådana fall kommer den befintliga posten för den relevanta dagen eller tidsramen att skrivas över av den senaste. Du kommer också att märka att vi bara har lagrat attribut i en mätenhet (t.ex. mph) per attribut. För att spara på lagringen kommer vi bara att lagra en post för varje attribut och låta gränssnittet konvertera dessa till användarens föredragna enheter vid behov.

Användarinställningar

Detta ämnesområde hanterar främst användarpreferenser för mätenheter. De flesta av kolumnerna är självförklarande, så vi kommer bara kortfattat förklara syftet med varje tabell.

users Tabellen innehåller grundläggande information om användare, som e-postadress och telefonnummer. id kolumnen tilldelar ett unikt nummer till varje användare som registrerar sig i applikationen.

attribute Tabellen lagrar en lista med attribut, som temperatur, vindhastighet, vindriktning, barometertryck, etc.

measuring_units Tabellen lagrar en lista över alla måttenheter, med deras motsvarande namn, beskrivning och attribute_id .

user_preferences Tabell kartlägger förhållandet mellan användare och mätenhetspreferenser. Observera att vi kan lagra information om användarnas preferenser för varje enskilt attribut. Eftersom användare kan välja vilken som helst mätenhet bland de givna alternativen för ett attribut, har vi skapat en sammansatt primärnyckel med hjälp av users_id och attribute_id kolumner.

Användarprofiler

Eftersom applikationen tillåter användare att övervaka vädret i så många städer som de vill, hanterar detta ämnesområde att associera en eller flera städer med varje användarprofil.

city tabell lagra en lista över städer och deras platsinformation (postnummer, land, kartkoordinater). Kolumnerna i den här tabellen är självförklarande, men det är bra att inse att city_longitude och city_latitude kolumner kan innehålla positiva eller negativa värden.

user_city Tabell associerar städer med användarprofiler. Eftersom användare bara kan lägga till en stad i sina profiler en gång har vi skapat en sammansatt primärnyckel med users_id och city_id kolumner.

Vad skulle du lägga till den här datamodellen?

Nu kommer vi till avsnittet där du berättar vad du skulle lägga till, ändra eller ta bort i en modell. Vad kan vi lägga till? Tja, den globala uppvärmningen har blivit ett stort problem. Forskning visar tydligt att det orsakas mer av mänskliga aktiviteter än naturliga förändringar. Men relativt få människor inser detta. Hur kan vi göra människor medvetna om klimatförändringar och global uppvärmning? Vi skulle kunna inkludera fakta om miljöförändringar och deras orsaker i appen. Eller så kanske vi kan inkludera procentandelen av trädtäcket i ett lokalt område för att öka medvetenheten.

Vad tror du? Låt oss veta dina idéer genom att kommentera nedan.


  1. Returnera lagrade procedurer och funktioner i en SQL Server-databas:RUTINER (T-SQL-exempel)

  2. Lagra den valda frågans utdata i en array i postgres

  3. How FOR XML PATH('') fungerar vid sammanlänkning av rader

  4. Hur man skapar ett användardefinierat datatypalias i SQL Server med T-SQL