sql >> データベース >  >> RDS >> Database

天気アプリのデータモデル

    多くの人がモバイル天気アプリを使用して1日の計画を立てます。または、少なくとも傘を持っていく必要があるかどうかを判断します。これらの人気のあるプログラムの下には、どのような種類のデータモデルがありますか?

    外に出る前に、天気がどれほどひどいのか知りたいのです。 Windows、iOS、およびAndroidアプリは、現在の気象条件に関する正確で信頼できる情報を提供します。この記事では、そのようなアプリに使用できる詳細なデータモデルについて説明します。

    天気アプリにはどのような機能が必要ですか?

    スマートフォンを持っているほとんどの人は、少なくとも1つの天気アプリも持っています。これらのアプリは詳細な天気情報を提供し、ユーザーが日中に遭遇する可能性のある天気の変化に備えるのに役立ちます。

    天気アプリは何をすべきですか?

    • 全体的なステータス(晴れ、部分的に曇り、曇りなど)、気温、湿度、風速と風向、「感じのような」気温、気圧、視程など、現在の気象条件を報告します。また、日の出と日の入りの時刻、その日の最高気温と最低気温などの一般的な情報も報告する必要があります。
    • 次の24時間の時間ごとの詳細(気温、湿度、降水量、全体的な気象条件)を表示します。
    • 翌週または2週間の各日の基本的な予報(毎日の最高気温と最低気温、気象条件、日の出/日の入り時刻)を表示します。
    • ユーザーが自分の地元の都市や天気を確認したい他の都市を設定できるようにします。
    • ユーザーが選択した測定単位でデータを表示できるようにします。たとえば、米国のユーザーは華氏の気温と風速をマイル/時で表示することを好むでしょうが、カナダとヨーロッパのユーザーは摂氏とキロメートルを時速で好むでしょう。

    アプリは表示中であることに注意してください 天気予報と(設定に応じて)測定単位の変換。実際の予測は行いません。別のソース(政府機関や天気予報機関など)から予測データを受信し、ユーザーの好みの方法で表示するだけです。

    天気アプリのデータモデル




    モデルを3つのサブジェクトエリアに分割しました:

    1. 気象ログ
    2. ユーザー設定
    3. ユーザープロファイル

    各領域について、記載されている順序で説明します。

    気象ログ

    これは最も重要な主題分野です。天気予報アプリは、次の基本的な詳細をキャプチャする必要があります:

    • 現在の実際の温度
    • 現在の「感じ」の温度。これは、追加の気象要因により実際の温度とは異なる場合があります(たとえば、湿度が高いと、暑い日が暑く感じられたり、寒い日が寒く感じられたりする可能性があります)。
    • 毎日の高温と低温
    • 露点および/または相対湿度データ
    • 風速
    • 風向
    • 気圧
    • 可視性(つまり、霧の日は晴れた日よりも可視性が低くなります)
    • 日の出と日の入りの時間

    一緒に、これらは現在の気象条件の全体的なビューを提供します。これは、通常1つ以上の直感的な画面を通じてユーザーに表示される情報です。

    天気予報には2種類の属性があります。1つは毎日変化する属性、もう1つは全体的に変化する属性です。 毎日。日の出や日の入りの時刻などの属性は、1日に1回発生するイベントに基づいているため、この情報は1日に1回取得されます。長期予報(7〜15日前)に関しては、毎日の最高気温と最低気温、湿度レベル、および全体的な気象条件(晴れ、曇りなど)を含めると、ユーザーは十分な情報を得る必要があります。

    現在の気温、「感じ」の気温、風速と風向、気圧、視程範囲などの属性は、1日を通して変化する可能性があります。これらは、特定の時間間隔、たとえば1時間ごとまたは3時間ごとにキャプチャする必要があります。このモデルでは、1時間の時間枠を想定しています。

    2種類の属性があるため、このサブジェクト領域に2つのテーブルを配置しました。最初のWeather_daily_forecast_log 、毎日の属性を保持します。次の列が含まれています:

    • city_id cityを参照します 表であり、このデータが適用される都市を示します。
    • calendar_date –このデータの暦日。このテーブルには、日付ごとに都市ごとに1つのレコードが保持されるため、これらの列( city_id およびcalendar_date )このテーブルの複合主キーを作成します。
    • Weather_status_id Weather_statusを参照します 表は、気象条件(つまり、雨、曇り、部分的に曇り、または晴れ)を示します。
    • min_temperature –その日の最低(最低)気温。
    • max_temperature –その日の最高(最高)気温。
    • avg_humidity_in_percentage 平均 その日の空気中の相対湿度。 (空気が保持できる水の量は、その温度に比例します。)
    • sunrise_time –日の出時刻を格納するタイムスタンプ列。
    • sunset_time –日没時刻を格納するタイムスタンプ列。
    • last_updated_at –レコードが最後に更新された日時を(タイムスタンプとして)保持します。
    • source_system –天気予報のソースの名前。これらの最後の2つの列は、監査目的で保持されます。

    Weather_hourly_forecast_log テーブルには、1日を通して変更される可能性のあるすべての属性が含まれています。これらの属性は、特定の時間枠の1つのレコードと見なされます。列は次のとおりです。

    • id –テーブルの代理キー。
    • city_id –関連する都市。
    • start_timestamp –この時間枠がいつ開始したかを示すタイムスタンプ列。
    • end_timestamp –この時間枠がいつ終了したかを示すタイムスタンプ列。
    • Weather_status_id –時間枠の全体的な気象ステータス。
    • 温度 –時間枠の現在の温度。
    • feels_like_temperature –時間枠の「感じのような」温度。これは、風、雨、高湿度または低湿度など、多くの要因の影響を受ける可能性があります。この情報は、現在の気象条件のより現実的な印象を与えます。
    • humidity_in_percentage –この列には、空気中の湿度の量(パーセンテージ)が表示されます。
    • wind_speed_in_mph –風速をmph(マイル/時)で保持します。
    • wind_direction –このテキスト列には、風向(N、NW、NE、S、W、SWなど)を表す1文字または2文字が格納されます。
    • pressure_in_mmhg –気圧値をmmHgで保存します。
    • visibility_in_mph –可視範囲の値をマイル単位で保存します。

    これらのテーブルは、特定の時間枠の最新データを保持します。場合によっては、将来の予測が発行され、後で変更されることがあります。このような場合、該当する日または時間枠の既存のレコードが最新のレコードで上書きされます。また、属性ごとに1つの測定単位(mphなど)に属性のみが保存されていることに気付くでしょう。ストレージを節約するために、属性ごとに1つのレコードのみを保存し、必要に応じてフロントエンドがこれらをユーザーの優先単位に変換できるようにします。

    ユーザー設定

    このサブジェクトエリアは、主に測定単位のユーザー設定を処理します。ほとんどの列は自明なので、各表の目的を簡単に説明します。

    ユーザー テーブルには、メールアドレスや電話番号などのユーザーに関する基本情報が含まれています。 id 列は、アプリケーションに登録するすべてのユーザーに一意の番号を割り当てます。

    属性 テーブルには、温度、風速、風向、気圧などの属性のリストが格納されます。

    Measurement_units テーブルには、すべての測定単位のリストが、対応する名前、説明、および attribute_idとともに格納されます。 。

    user_preferences 表は、ユーザーと測定単位の設定との関係を示しています。個々の属性に対するユーザーの設定に関する情報を保存できることに注意してください。ユーザーは属性に指定されたオプションから任意の1つの測定単位を選択できるため、 users_idを使用して複合主キーを作成しました。 およびattribute_id 列。

    ユーザープロファイル

    このアプリケーションを使用すると、ユーザーは必要な数の都市の天気を監視できるため、このサブジェクトエリアでは、1つ以上の都市を各ユーザープロファイルに関連付けることができます。

    都市 テーブルには、都市とその場所の詳細(郵便番号、国、地図の座標)のリストが格納されます。この表の列は一目瞭然ですが、 city_longitudeであることを理解しておくとよいでしょう。 およびcity_latitude 列は正または負の値を保持できます。

    user_city テーブルは都市をユーザープロファイルに関連付けます。ユーザーはプロファイルに都市を1回しか追加できないため、 users_idを使用して複合主キーを作成しました およびcity_id 列。

    このデータモデルに何を追加しますか?

    次に、モデルで何を追加、変更、または削除するかを説明するセクションに移動します。何を追加しますか?さて、地球温暖化は大きな関心事になっています。研究によると、それは自然の変化よりも人間の活動によって引き起こされていることがはっきりと示されています。しかし、これを理解している人は比較的少数です。どうすれば人々に気候変動と地球温暖化を認識させることができるでしょうか?アプリに環境の変化とその原因に関する事実を含めることができます。あるいは、意識を高めるために、地域の樹木被覆率を含めることもできます。

    どう思いますか?以下にコメントして、あなたのアイデアを教えてください。


    1. データベースクエリとは何ですか?

    2. いつテーブル値関数を使用しますか?

    3. @@ ROWCOUNT –SQLServerの最後のステートメントの影響を受ける行数を取得する

    4. MariaDB JSON_QUERY()の説明