Database
 sql >> Base de données >  >> RDS >> Database

Un modèle de données pour une application météo

Beaucoup de gens utilisent des applications météo mobiles pour planifier leur journée - ou du moins décider s'ils doivent porter un parapluie ! Quel type de modèle de données se cache sous ces programmes populaires ?

Nous voulons tous savoir à quel point le temps est mauvais avant de sortir. Les applications Windows, iOS et Android nous fournissent des informations précises et fiables sur les conditions météorologiques actuelles. Cet article explique un modèle de données détaillé qui pourrait être utilisé pour de telles applications.

De quelles fonctionnalités une application météo a-t-elle besoin ?

Presque tous ceux qui ont un smartphone ont également au moins une application météo. Ces applications fournissent des informations météorologiques détaillées, ce qui aide leurs utilisateurs à se préparer aux changements météorologiques qu'ils pourraient rencontrer au cours de la journée.

Que doit faire une application météo ?

  • Rapportez les conditions météorologiques actuelles, y compris l'état général (c'est-à-dire ensoleillé, partiellement nuageux, nuageux, etc.), la température de l'air, l'humidité, la vitesse et la direction du vent, une température "ressemblante", la pression barométrique et la visibilité. Il doit également indiquer des informations générales telles que les heures de lever et de coucher du soleil et les températures maximales et minimales de la journée.
  • Afficher les détails horaires (température, humidité, précipitations, conditions météorologiques générales) pour les prochaines 24 heures.
  • Afficher une prévision de base (températures maximales et minimales quotidiennes, conditions météorologiques et heures de lever/coucher du soleil) pour chaque jour de la semaine ou des deux prochaines semaines.
  • Autoriser les utilisateurs à définir leur ville locale et toute autre ville où ils souhaitent voir la météo.
  • Permettez aux utilisateurs de voir les données dans les unités de mesure de leur choix. Par exemple, les utilisateurs américains préféreraient probablement des températures en Fahrenheit et des vitesses de vent exprimées en miles par heure, mais les utilisateurs canadiens et européens préféreraient Celsius et kilomètres par heure.

N'oubliez pas que l'application ne fait que s'afficher les prévisions météo et (selon les paramètres) la conversion des unités de mesure. Il ne fait pas la prévision proprement dite; il reçoit simplement les données de prévision d'une autre source (telle qu'un service gouvernemental ou une agence de prévision météorologique) et les affiche de la manière préférée de l'utilisateur.

Le modèle de données de l'application météo




J'ai divisé le modèle en trois domaines :

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

Nous aborderons chaque domaine dans l'ordre dans lequel il est répertorié.

Journaux météo

C'est le domaine le plus important. Toute application météo devrait enregistrer ces informations de base :

  • Température réelle actuelle
  • La température "ressenti" actuelle, qui peut être différente de la température réelle en raison de facteurs météorologiques supplémentaires (par exemple, une humidité élevée peut rendre une journée chaude plus chaude ou une journée froide plus froide).
  • Températures maximales et minimales quotidiennes
  • Données de point de rosée et/ou d'humidité relative
  • Vitesse du vent
  • Direction du vent
  • Pression barométrique
  • Visibilité (c'est-à-dire qu'un jour de brouillard aura une visibilité inférieure à un jour clair)
  • Heures de lever et de coucher du soleil

Ensemble, ceux-ci donnent une vue globale des conditions météorologiques actuelles. Ce sont les informations qui seront présentées aux utilisateurs, généralement via un ou plusieurs écrans intuitifs.

Il existe deux types d'attributs pour toute prévision météo :ceux qui changent chaque jour et ceux qui changent tout au long chaque jour. Les attributs tels que les heures de lever et de coucher du soleil sont basés sur des événements qui se produisent une fois par jour, de sorte que ces informations sont capturées une fois pour chaque jour. En ce qui concerne les prévisions à long terme (de 7 à 15 jours à l'avance), les utilisateurs devraient disposer de suffisamment d'informations si vous incluez les températures élevées et basses de chaque jour, le niveau d'humidité et les conditions météorologiques générales (c'est-à-dire ensoleillé, nuageux, etc.).

Des attributs tels que la température actuelle, la température ressentie, la vitesse et la direction du vent, la pression barométrique et la plage de visibilité peuvent changer tout au long de la journée. Ceux-ci doivent être capturés pendant un intervalle de temps spécifique, disons toutes les heures ou toutes les trois heures. Pour les besoins de ce modèle, nous supposerons un délai d'une heure.

Parce que nous avons deux types d'attributs, j'ai mis deux tableaux dans ce domaine. Le premier, weather_daily_forecast_log , contient les attributs quotidiens. Il contient ces colonnes :

  • city_id – Référence la city table et indique la ville à laquelle ces données s'appliquent.
  • calendar_date – La date calendaire de ces données. Étant donné que cette table contient un enregistrement par ville et par date, ces colonnes (city_id et calendar_date ) forment la clé primaire composée pour cette table.
  • weather_status_id – Fait référence au weather_status tableau et indique les conditions météorologiques (c'est-à-dire pluvieux, nuageux, partiellement nuageux ou ensoleillé).
  • min_temperature – La température minimale (la plus basse) de ce jour.
  • max_temperature – La température maximale (la plus élevée) de ce jour.
  • avg_humidity_in_percentage – La moyenne l'humidité relative de l'air ce jour-là. (La quantité d'eau que l'air peut contenir est relative à sa température.)
  • sunrise_time – Une colonne d'horodatage qui stocke l'heure du lever du soleil.
  • sunset_time – Une colonne d'horodatage qui stocke l'heure du coucher du soleil.
  • last_updated_at – Contient la date et l'heure (sous forme d'horodatage) de la dernière mise à jour de l'enregistrement.
  • source_system – Le nom de la source de nos prévisions météo. Ces deux dernières colonnes sont conservées à des fins d'audit.

Le weather_hourly_forecast_log table contient tous les attributs qui peuvent changer tout au long de la journée. Nous considérons ces attributs comme un enregistrement pour une période spécifique. Les colonnes sont :

  • id – La clé de substitution pour la table.
  • city_id – La ville concernée.
  • start_timestamp – Une colonne d'horodatage qui indique quand cette période a commencé.
  • end_timestamp – Une colonne d'horodatage qui indique quand cette période s'est terminée.
  • weather_status_id – L'état météorologique global pour la période.
  • temperature – La température actuelle pour la période.
  • feels_like_temperature – La température « ressentie » pour la période. Cela peut être influencé par de nombreux facteurs, notamment le vent, la pluie et une humidité élevée ou faible. Ces informations donnent une impression plus réaliste des conditions météorologiques actuelles.
  • humidity_in_percentage –Cette colonne contient la quantité (en pourcentage) d'humidité dans l'air.
  • wind_speed_in_mph – Maintient la vitesse du vent en mph (miles par heure).
  • wind_direction – Cette colonne de texte stocke un ou deux caractères indiquant la direction du vent (N, NW, NE, S, W, SW, etc.)
  • pressure_in_mmhg – Stocke les valeurs de pression atmosphérique, en mmHg.
  • visibility_in_mph – Stocke les valeurs de plage de visibilité, en miles.

Ces tableaux contiendront les dernières données pour une période donnée. Occasionnellement, une prévision future peut être émise puis modifiée ultérieurement. Dans de tels cas, l'enregistrement existant pour le jour ou la période concernée sera écrasé par le plus récent. De plus, vous remarquerez que nous n'avons stocké les attributs que dans une seule unité de mesure (par exemple, mph) par attribut. Pour économiser sur le stockage, nous ne stockerons qu'un seul enregistrement pour chaque attribut et laisserons le frontal les convertir dans les unités préférées de l'utilisateur si nécessaire.

Préférences utilisateur

Ce domaine traite principalement des préférences de l'utilisateur pour les unités de mesure. La plupart des colonnes sont explicites, nous allons donc expliquer brièvement le but de chaque tableau.

Les users table contient des informations de base sur les utilisateurs, telles que l'adresse e-mail et le numéro de téléphone. L'id attribue un numéro unique à chaque utilisateur qui s'inscrit à l'application.

L'attribut attribute table stocke une liste d'attributs, comme la température, la vitesse du vent, la direction du vent, la pression barométrique, etc.

Les measuring_units table stocke une liste de toutes les unités de mesure, avec leur nom correspondant, leur description et attribute_id .

Les user_preferences Le tableau cartographie la relation entre les utilisateurs et les préférences d'unité de mesure. Notez que nous pouvons stocker des informations sur les préférences des utilisateurs pour chaque attribut individuel. Étant donné que les utilisateurs peuvent choisir n'importe quelle unité de mesure parmi les options données pour un attribut, nous avons créé une clé primaire composite en utilisant le users_id et attribute_id colonnes.

Profils utilisateur

L'application permettant aux utilisateurs de suivre la météo d'autant de villes qu'ils le souhaitent, ce domaine gère l'association d'une ou plusieurs villes à chaque profil utilisateur.

La city table stocke une liste de villes et leurs détails de localisation (code postal, pays, coordonnées cartographiques). Les colonnes de ce tableau sont explicites, mais il est bon de réaliser que la city_longitude et city_latitude les colonnes peuvent contenir des valeurs positives ou négatives.

La user_city table associe les villes aux profils d'utilisateurs. Étant donné que les utilisateurs ne peuvent ajouter une ville à leur profil qu'une seule fois, nous avons créé une clé primaire composite à l'aide de l'users_id et city_id colonnes.

Qu'ajouteriez-vous à ce modèle de données ?

Nous arrivons maintenant à la section où vous nous dites ce que vous ajouteriez, modifieriez ou supprimeriez dans un modèle. Que pourrions-nous ajouter ? Eh bien, le réchauffement climatique est devenu une grande préoccupation. La recherche montre clairement qu'elle est davantage causée par les activités humaines que par les changements naturels. Cependant, relativement peu de gens s'en rendent compte. Comment sensibiliser les gens aux changements climatiques et au réchauffement climatique ? Nous pourrions inclure des faits sur les changements environnementaux et leurs causes sur l'application. Ou peut-être pourrions-nous inclure le pourcentage de couvert arboré dans une zone locale pour sensibiliser le public.

Qu'en penses-tu? Faites-nous part de vos idées en commentant ci-dessous.