Um modelo de dados para um aplicativo meteorológico

Muitas pessoas usam aplicativos meteorológicos móveis para planejar seu dia – ou pelo menos decidir se precisam carregar um guarda-chuva! Que tipo de modelo de dados está por trás desses programas populares?

Todos nós queremos saber o quão desagradável está o tempo antes de sairmos. Os aplicativos para Windows, iOS e Android nos fornecem informações precisas e confiáveis sobre as condições climáticas atuais. Este artigo explica um modelo de dados detalhado que pode ser usado para esses aplicativos.

De quais funcionalidades um aplicativo de clima precisa?

Quase todo mundo que tem um smartphone também tem pelo menos um aplicativo de previsão do tempo. Esses aplicativos fornecem informações meteorológicas detalhadas, o que ajuda seus usuários a se prepararem para quaisquer mudanças climáticas que possam encontrar durante o dia.

O que um aplicativo de clima deve fazer?

Informe as condições meteorológicas atuais, incluindo o status geral (ou seja, ensolarado, parcialmente nublado, nublado etc.), temperatura do ar, umidade, velocidade e direção do vento, uma temperatura "sensível", pressão barométrica e visibilidade. Ele também deve relatar informações gerais, como os horários do nascer e do pôr do sol e as temperaturas altas e baixas do dia.
Exibir detalhes por hora (temperatura, umidade, precipitação, condições climáticas gerais) para as próximas 24 horas.
Mostrar uma previsão básica (temperaturas altas e baixas diárias, condições climáticas e horários do nascer e do pôr do sol) para cada dia na próxima semana ou duas.
Permita que os usuários definam sua cidade local e quaisquer outras cidades onde desejam ver o clima.
Permita que os usuários vejam os dados nas unidades de medida de sua escolha. Por exemplo, usuários dos EUA provavelmente prefeririam temperaturas Fahrenheit e velocidades do vento mostradas em milhas por hora, mas usuários canadenses e europeus prefeririam Celsius e quilômetros por hora.

Lembre-se, o aplicativo está apenas mostrando a previsão do tempo e (dependendo das configurações) conversão de unidades de medida. Não faz a previsão real; ele simplesmente recebe dados de previsão de outra fonte (como um serviço governamental ou uma agência de previsão do tempo) e os exibe da maneira preferida do usuário.

Modelo de dados do aplicativo de clima

Eu dividi o modelo em três áreas de assunto:

Weather Logs
User Preferences
User Profiles

Discutiremos cada área na ordem em que está listada.

Registros meteorológicos

Esta é a área temática mais importante. Qualquer aplicativo meteorológico deve capturar esses detalhes básicos:

Temperatura real atual
A temperatura atual "parece" que pode ser diferente da temperatura real devido a fatores climáticos adicionais (por exemplo, alta umidade pode fazer com que um dia quente pareça mais quente ou um dia frio pareça mais frio).
Temperaturas altas e baixas diárias
Dados de ponto de orvalho e/ou umidade relativa
Velocidade do vento
Direção do vento
Pressão barométrica
Visibilidade (ou seja, um dia de neblina terá menor visibilidade do que um dia claro)
Horário do nascer e pôr do sol

Juntos, eles fornecem uma visão holística da condição climática atual. Essas são as informações que serão apresentadas aos usuários, geralmente por meio de uma ou mais telas intuitivas.

Existem dois tipos de atributos para qualquer previsão do tempo:aqueles que mudam a cada dia e aqueles que mudam durante todo cada dia. Atributos como horários de nascer e pôr do sol são baseados em eventos que acontecem uma vez por dia, então essas informações são capturadas uma vez para cada dia. Quando se trata de previsões de longo prazo (de 7 a 15 dias de antecedência), os usuários devem ter informações suficientes se você incluir as temperaturas altas e baixas de cada dia, nível de umidade e condições climáticas gerais (ou seja, ensolarado, nublado etc.).

Atributos como temperatura atual, temperatura "sensível", velocidade e direção do vento, pressão barométrica e faixa de visibilidade podem mudar ao longo do dia. Estes devem ser capturados para um intervalo de tempo específico, digamos a cada hora ou a cada três horas. Para os propósitos deste modelo, assumiremos um prazo de uma hora.

Como temos dois tipos de atributos, coloquei duas tabelas nesta área de assunto. O primeiro, weather_daily_forecast_log , contém os atributos diários. Ele contém estas colunas:

city_id – Faz referência à city tabela e indica a cidade à qual esses dados se aplicam.
calendar_date – A data do calendário para esses dados. Como esta tabela contém um registro por cidade por data, essas colunas (city_id e calendar_date ) formam a chave primária composta para esta tabela.
weather_status_id – Faz referência ao weather_status tabela e indica a condição do tempo (ou seja, chuvoso, nublado, parcialmente nublado ou ensolarado).
min_temperature – A temperatura mínima (mais baixa) desse dia.
max_temperature – A temperatura máxima (mais alta) daquele dia.
avg_humidity_in_percentage – A média umidade relativa do ar naquele dia. (A quantidade de água que o ar pode conter é relativa à sua temperatura.)
sunrise_time – Uma coluna de carimbo de data/hora que armazena a hora do nascer do sol.
sunset_time – Uma coluna de carimbo de data/hora que armazena a hora do pôr do sol.
last_updated_at – Mantém a data e a hora (como um carimbo de data/hora) da última atualização do registro.
source_system – O nome da fonte da nossa previsão do tempo. Essas duas últimas colunas são mantidas para fins de auditoria.

O weather_hourly_forecast_log table contém todos os atributos que podem mudar ao longo do dia. Consideramos esses atributos como um registro para um período de tempo específico. As colunas são:

id – A chave substituta para a tabela.
city_id – A cidade relevante.
start_timestamp – Uma coluna de carimbo de data/hora que indica quando esse período de tempo começou.
end_timestamp – Uma coluna de carimbo de data/hora que indica quando esse período de tempo terminou.
weather_status_id – O status geral do clima para o período.
temperature – A temperatura atual para o período de tempo.
feels_like_temperature – A temperatura “sensível” para o período de tempo. Isso pode ser influenciado por muitos fatores, incluindo vento, chuva e umidade alta ou baixa. Essas informações dão uma impressão mais realista das condições climáticas atuais.
humidity_in_percentage –Esta coluna contém a quantidade (em porcentagem) de umidade no ar.
wind_speed_in_mph – Mantém a velocidade do vento em mph (milhas por hora).
wind_direction – Esta coluna de texto armazena um ou dois caracteres que denotam a direção do vento (N, NW, NE, S, W, SW, etc.)
pressure_in_mmhg – Armazena os valores da pressão do ar, em mmHg.
visibility_in_mph – Armazena valores de alcance de visibilidade, em milhas.

Essas tabelas conterão os dados mais recentes para um período de tempo específico. Ocasionalmente, uma previsão futura pode ser emitida e posteriormente alterada. Nesses casos, o registro existente para o dia ou período relevante será substituído pelo mais recente. Além disso, você notará que armazenamos apenas atributos em uma unidade de medida (por exemplo, mph) por atributo. Para economizar no armazenamento, armazenaremos apenas um registro para cada atributo e deixaremos o front end convertê-los nas unidades preferidas do usuário quando necessário.

Preferências do usuário

Esta área de assunto lida principalmente com as preferências do usuário para unidades de medida. A maioria das colunas é autoexplicativa, então vamos explicar brevemente o propósito de cada tabela.

Os users table contém informações básicas sobre os usuários, como endereço de e-mail e número de telefone. O id coluna atribui um número exclusivo a cada usuário que se registra no aplicativo.

O attribute A tabela armazena uma lista de atributos, como temperatura, velocidade do vento, direção do vento, pressão barométrica, etc.

As measuring_units table armazena uma lista de todas as unidades de medida, com seu nome, descrição e attribute_id correspondentes .

As user_preferences tabela mapeia a relação entre usuários e preferências de unidade de medição. Observe que podemos armazenar informações sobre as preferências dos usuários para cada atributo individual. Como os usuários podem escolher qualquer unidade de medida entre as opções fornecidas para um atributo, criamos uma chave primária composta usando o users_id e attribute_id colunas.

Perfis de usuário

Como o aplicativo permite que o usuário monitore o clima em quantas cidades quiser, esta área de assunto trata de associar uma ou mais cidades a cada perfil de usuário.

A city table armazena uma lista de cidades e seus detalhes de localização (código postal, país, coordenadas do mapa). As colunas nesta tabela são autoexplicativas, mas é bom perceber que a city_longitude e city_latitude as colunas podem conter valores positivos ou negativos.

A user_city A tabela associa cidades a perfis de usuários. Como os usuários podem adicionar uma cidade a seus perfis apenas uma vez, criamos uma chave primária composta usando o users_id e city_id colunas.

O que você adicionaria a este modelo de dados?

Agora chegamos à seção em que você nos diz o que adicionaria, alteraria ou excluiria em um modelo. O que podemos acrescentar? Bem, o aquecimento global tornou-se uma grande preocupação. A pesquisa mostra claramente que é causado mais por atividades humanas do que por mudanças naturais. No entanto, relativamente poucas pessoas percebem isso. Como podemos conscientizar as pessoas sobre as mudanças climáticas e o aquecimento global? Poderíamos incluir fatos sobre mudanças ambientais e suas causas no aplicativo. Ou talvez possamos incluir a porcentagem de cobertura de árvores em uma área local para aumentar a conscientização.

O que você acha? Por favor, deixe-nos saber suas ideias comentando abaixo.