sql >> Database teknologi >  >> RDS >> Database

En datamodel til en vejrapp

Mange mennesker bruger mobile vejrapps til at planlægge deres dag – eller i det mindste beslutte, om de skal have en paraply med sig! Hvilken slags datamodel ligger under disse populære programmer?

Vi vil alle gerne vide, hvor grimt vejret er, før vi træder udenfor. Windows-, iOS- og Android-apps giver os nøjagtige og pålidelige oplysninger om aktuelle vejrforhold. Denne artikel forklarer en detaljeret datamodel, der kan bruges til sådanne apps.

Hvilke funktioner har en vejrapp brug for?

Næsten alle, der har en smartphone, har også mindst én vejr-app. Disse apps giver detaljerede vejroplysninger, som hjælper deres brugere med at forberede sig på vejrændringer, de kan støde på i løbet af dagen.

Hvad skal en vejr-app gøre?

  • Rapportér aktuelle vejrforhold, inklusive den overordnede status (dvs. solskin, delvist overskyet, overskyet osv.) lufttemperatur, fugtighed, vindhastighed og retning, en "følelsesagtig" temperatur, barometertryk og sigtbarhed. Den bør også rapportere generelle oplysninger som solopgang og solnedgang samt dagens høje og lave temperaturer.
  • Vis timeoplysninger (temperatur, luftfugtighed, nedbør, overordnet vejrforhold) for de næste 24 timer.
  • Vis en grundlæggende vejrudsigt (daglige høje og lave temperaturer, vejrforhold og tidspunkter for solopgang/solnedgang) for hver dag i den næste uge eller to.
  • Tillad brugere at indstille deres lokale by og andre byer, hvor de vil se vejret.
  • Lad brugerne se data i de måleenheder, de selv vælger. For eksempel ville amerikanske brugere sandsynligvis foretrække Fahrenheit-temperaturer og vindhastigheder vist i miles i timen, men canadiske og europæiske brugere ville foretrække Celsius og kilometer i timen.

Husk, at appen kun vises vejrudsigten og (afhængigt af indstillingerne) konvertering af måleenheder. Den udfører ikke selve prognosen; den modtager simpelthen prognosedata fra en anden kilde (såsom en offentlig tjeneste eller et vejrudsigtsbureau) og viser det på brugerens foretrukne måde.

Weather App Data Model




Jeg har opdelt modellen i tre emneområder:

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

Vi diskuterer hvert område i den rækkefølge, det er angivet.

Vejrlogger

Dette er det vigtigste fagområde. Enhver vejrapp bør fange disse grundlæggende detaljer:

  • Aktuel faktisk temperatur
  • Den aktuelle "føles som" temperatur, som kan være anderledes end den faktiske temperatur på grund af yderligere vejrfaktorer (f.eks. høj luftfugtighed kan få en varm dag til at føles varmere eller en kold dag føles koldere).
  • Daglige høje og lave temperaturer
  • Dugpunkt og/eller relativ fugtighedsdata
  • Vindhastighed
  • Vindretning
  • Barometrisk tryk
  • Sigtbarhed (dvs. en tåget dag vil have lavere sigtbarhed end en klar dag)
  • Tidspunkter for solopgang og solnedgang

Tilsammen giver disse et holistisk overblik over den aktuelle vejrtilstand. Dette er den information, der vil blive præsenteret for brugerne, normalt gennem en eller flere intuitive skærme.

Der er to slags attributter til enhver vejrudsigt:dem, der ændrer sig hver dag, og dem, der ændrer sig gennem hver dag. Attributter som tider for solopgang og solnedgang er baseret på begivenheder, der sker én gang om dagen, så disse oplysninger fanges én gang for hver dag. Når det kommer til langsigtede prognoser (fra 7 til 15 dage i forvejen), bør brugerne have nok information, hvis du inkluderer hver dags høje og lave temperaturer, fugtighedsniveau og overordnede vejrforhold (dvs. solrigt, overskyet osv.).

Attributter som nuværende temperatur, "føles som" temperatur, vindhastighed og retning, barometertryk og sigtbarhed kan ændre sig i løbet af en dag. Disse skal fanges i et bestemt tidsinterval, f.eks. hver time eller hver tredje time. I forbindelse med denne model antager vi en tidsramme på én time.

Fordi vi har to typer attributter, har jeg lagt to tabeller i dette emneområde. Den første, weather_daily_forecast_log , har de daglige attributter. Den indeholder disse kolonner:

  • city_id – Henviser til city tabel og angiver den by, som disse data gælder for.
  • calendar_date – Kalenderdatoen for disse data. Da denne tabel indeholder én post pr. by pr. dato, er disse kolonner (city_id og calendar_date ) danner den sammensatte primærnøgle for denne tabel.
  • weather_status_id – Henviser til weather_status tabel og angiver vejrforholdene (dvs. regnfuld, overskyet, delvist overskyet eller solrig).
  • min_temperature – Dagens minimum (laveste) temperatur.
  • max_temperature – Dagens maksimale (højeste) temperatur.
  • avg_humidity_in_percentagegennemsnittet relativ fugtighed i luften den dag. (Mængden af ​​vand, som luft kan holde, er i forhold til dens temperatur.)
  • sunrise_time – En tidsstempelkolonne, der gemmer solopgangstiden.
  • sunset_time – En tidsstempelkolonne, der gemmer solnedgangstiden.
  • last_updated_at – Indeholder datoen og klokkeslættet (som et tidsstempel), da posten sidst blev opdateret.
  • source_system – Navnet på kilden til vores vejrudsigt. Disse to sidste kolonner opbevares til revisionsformål.

weather_hourly_forecast_log tabel indeholder alle de attributter, der kan ændre sig i løbet af dagen. Vi betragter disse attributter som én registrering for en bestemt tidsramme. Kolonnerne er:

  • id – Surrogatnøglen til bordet.
  • city_id – Den relevante by.
  • start_timestamp – En tidsstempelkolonne, der angiver, hvornår denne tidsramme startede.
  • end_timestamp – En tidsstempelkolonne, der angiver, hvornår denne tidsramme sluttede.
  • weather_status_id – Den overordnede vejrstatus for tidsrammen.
  • temperature – Den aktuelle temperatur for tidsrammen.
  • feels_like_temperature – Den "føles-som" temperatur for tidsrammen. Dette kan være påvirket af mange faktorer, herunder vind, regn og høj eller lav luftfugtighed. Disse oplysninger giver et mere realistisk indtryk af de aktuelle vejrforhold.
  • humidity_in_percentage –Denne kolonne indeholder mængden (i procent) af fugt i luften.
  • wind_speed_in_mph – Holder vindhastigheden i mph (miles per time).
  • wind_direction – Denne tekstkolonne gemmer et eller to tegn, der angiver vindretning (N, NW, NØ, S, V, SV osv.)
  • pressure_in_mmhg – Gemmer lufttrykværdier i mmHg.
  • visibility_in_mph – Gemmer værdier for sigtbarhed i miles.

Disse tabeller vil indeholde de seneste data for en bestemt tidsramme. Lejlighedsvis kan der udsendes en fremtidsprognose og så senere ændres. I sådanne tilfælde vil den eksisterende rekord for den relevante dag eller tidsramme blive overskrevet af den seneste. Du vil også bemærke, at vi kun har gemt attributter i en måleenhed (f.eks. mph) pr. attribut. For at spare på lageret gemmer vi kun én post for hver attribut og lader frontenden konvertere disse til brugerens foretrukne enheder, når det er nødvendigt.

Brugerpræferencer

Dette fagområde håndterer hovedsageligt brugerpræferencer for måleenheder. De fleste af kolonnerne er selvforklarende, så vi vil blot kort forklare formålet med hver tabel.

users tabel indeholder grundlæggende oplysninger om brugere, såsom e-mailadresse og telefonnummer. id kolonne tildeler et unikt nummer til hver bruger, der tilmelder sig applikationen.

attribute tabel gemmer en liste over attributter, såsom temperatur, vindhastighed, vindretning, barometertryk osv.

measuring_units tabel gemmer en liste over alle måleenheder med deres tilsvarende navn, beskrivelse og attribute_id .

user_preferences tabel kortlægger forholdet mellem brugere og præferencer for måleenheder. Bemærk, at vi kan gemme oplysninger om brugernes præferencer for hver enkelt egenskab. Da brugere kan vælge en hvilken som helst måleenhed ud af de givne muligheder for en attribut, har vi oprettet en sammensat primærnøgle ved hjælp af users_id og attribute_id kolonner.

Brugerprofiler

Da applikationen giver brugerne mulighed for at overvåge vejret i så mange byer, som de ønsker, håndterer dette emneområde at knytte en eller flere byer til hver brugerprofil.

city tabel gemmer en liste over byer og deres placeringsoplysninger (postnummer, land, kortkoordinater). Kolonnerne i denne tabel er selvforklarende, men det er godt at indse, at city_longitude og city_latitude kolonner kan indeholde positive eller negative værdier.

user_city tabel forbinder byer med brugerprofiler. Da brugere kun kan tilføje en by til deres profiler én gang, har vi oprettet en sammensat primærnøgle ved hjælp af users_id og city_id kolonner.

Hvad ville du tilføje til denne datamodel?

Nu kommer vi til afsnittet, hvor du fortæller os, hvad du vil tilføje, ændre eller slette i en model. Hvad kan vi tilføje? Nå, global opvarmning er blevet en stor bekymring. Forskning viser tydeligt, at det er forårsaget mere af menneskelige aktiviteter end naturlige ændringer. Men relativt få mennesker er klar over dette. Hvordan kan vi gøre folk opmærksomme på klimaændringer og global opvarmning? Vi kunne inkludere fakta om miljøændringer og deres årsager i appen. Eller måske kunne vi inkludere procentdelen af ​​trædække i et lokalt område for at øge bevidstheden.

Hvad synes du? Fortæl os venligst dine ideer ved at kommentere nedenfor.


  1. Kørsel af SQL-databasevedligeholdelsesopgaver ved hjælp af SQLCMD

  2. Hvordan LocalTime() virker i PostgreSQL

  3. Kø i OneWay WCF-meddelelser ved hjælp af Windows Service og SQL Server

  4. Overvågning af tilgængelighed Gruppereplikasynkronisering