スマートホームデータモデル

スマートホームは、厳密には将来的に使用されていました。今、彼らは現実です。私たちのほとんどはそれらについて聞いたことがありますが、近い将来になるほど普及していません。「スマート」な方法で家を管理すると、間違いなく大量のデータが生成されます。今日は、スマートホームデータの保存に使用できるデータモデルを分析します。

データモデル

スマートホームについて考えるとき、おそらく、リモートで家をロックおよびロック解除したり、アラーム、ライト、またはカメラを電話からアクティブにしたり、温度計を使用して暖房と冷房を自動的に管理したりすることを考えます。しかし、スマートホームはさらに多くのことを実行できます。多数のスマートデバイスとコントローラーを接続して、多くの複雑な機能を実現できます。どこにいても、デバイスに指示を送信したり、デバイスのステータスを読み取ったりできます。

そのような機能を実装できるようにするデータモデルを見てみましょう。そのデータモデルに加えて、登録ユーザーがアカウントを管理し、指示を送信し、ステータスを追跡できるようにするWebアプリケーションとモバイルアプリケーションを構築できます。

モデルは3つのサブジェクトエリアで構成されています：

不動産とデバイス
ユーザーとプロファイル
コマンドとデータ

これらの主題分野のそれぞれについて、リストされている順序で説明します。ただし、何よりもまず、 user_accountについて説明します。 テーブル。

User_Accountテーブル

user_accountから始めます 3つの主題分野すべてで使用されているためです。アプリケーションのすべての登録ユーザーのリストが保存されます。

user_account 表には、次のような、予想されるすべての標準属性が含まれています。

first_name およびlast_name –ユーザーの名前と名前。
user_name –ユーザーが選択した一意のユーザー名。
パスワード –ユーザーのパスワードのハッシュ値。
メール –登録プロセス中にユーザーから提供されたメールアドレス。
confirmation_code –登録プロセス中に生成されたコード。
confirmation_time –ユーザーがアカウントを確認して登録プロセスを完了したときのタイムスタンプ。
ts –このレコードがデータベースに挿入されたときのタイムスタンプ。

セクション1：不動産とデバイス

このデータベースを作成する背後にある全体的な動機は、私たちの不動産（つまり、家や財産）で何が起こっているかを監視することです。これらは、アパートや家などの私有地の場合もあれば、オフィスや倉庫などのビジネス用不動産の場合もあります。システムを限界まで押し上げたい場合は、車両にも使用できます。

このサブジェクトエリアの中央のテーブルは、 real_estateです。 テーブル。ここに、スマートホームアプリに接続されているさまざまな不動産やプロパティをすべて保存します。不動産ごとに、以下を保存します：

real_estate_name –特定のプロパティを参照する、ユーザーが選択した名前。
user_account_id –この不動産が関連するユーザーのID。 real_estate_name属性とともに、これはこのテーブルのUNIQUE（代替）キーを形成します。
real_estate_type –この物件の不動産の種類を示します。
アドレス –その不動産の実際の住所。このシステムを他のタイプの不動産（車両など）に使用する可能性があるため、これは無効になります。
詳細 –すべての追加の詳細はテキスト形式です。

 
 不動産の種類についてはすでに説明しました。可能なタイプの完全なリストは、  real_estate_typeに保存されています  辞書。これには、 type_nameという1つのUNIQUE値のみが含まれます。 。ここでは、「アパート」、「家」、「ガレージ」などの値を期待できます。
 
 1つの不動産はいくつかの領域に分割できます。これはアパートや家の部屋かもしれません。いくつかの部屋をグループ化したい場合や、庭や庭に関連するすべてのものを1つのグループにまとめたい場合などです。あるいは、工業団地や複数のオフィスがある複合施設がある場合もあります。私たちの物件が本当に大きい場合、特定のエリアを持つことは非常に便利です。これを実現するために、  areaを使用します  テーブル。  real_estate_idのUNIQUEペアが含まれています およびarea_name ユーザーが選択します。
 
 このサブジェクトエリアの最後の2つの表は、デバイスに関連しています。 
 
   device_type内  表には、すべての異なるデバイスタイプの完全なリストが格納されます。タイプごとに、UNIQUE  type_nameを使用します 追加のdescriptionを挿入します 必要に応じて。デバイスの種類には、さまざまなセンサー（温度、ガス）、ドアまたは窓のロック、照明、冷暖房システムなどがあります。
 
 これで、楽しい部分の準備が整いました。 デバイスを使用します  さまざまなスマートホームに含まれるすべてのデバイスのリストを格納するテーブル。これらのデバイスは、ユーザーが手動で追加するか、デバイスにそのオプションがある場合は自動的に追加します。デバイスごとに、以下を保存する必要があります：
    real_estate_id  –このデバイスがインストールされている不動産のID。
   area_id  –   areaを参照します  このデバイスがインストールされている場所。不動産が可能であるため、これはオプションの値です。 エリアに分割されますが、分割されない場合もあります。
   device_type_id  –   device_typeのID  このデバイスはに属します。
   device_parameters  –この属性を使用して、考えられるすべてのデバイスパラメータ（データを保存する間隔など）を構造化されたテキスト形式で保存します。これらのパラメータは、ユーザーまたはデバイスの通常の機能の一部（さまざまな測定値など）によって設定できます。
   current_status  –デバイスパラメータの現在のステータス。
   time_activate  およびtime_deactivate –このデバイスがアクティブだった間隔を示します。  time_deactivateの場合 が設定されていない場合、デバイスはアクティブであり、 is_active  属性もTrueに設定されています。
 
 セクション2：ユーザーとプロファイル
 
   user_accountについてはすでに説明しました  テーブル。このアプリケーションでは、ユーザーはさまざまなプロファイルを作成し、必要に応じて他のユーザーと共有できる必要があります。
   
 
 プロファイルは基本的に、ユーザーが所有するすべての不動産にインストールされているデバイスのサブセットです。各ユーザーは1つ以上のプロファイルを持つことができます。アイデアは、ユーザーがスマートホームデバイスを適切な方法でグループ化できるようにすることです。ユーザーは、すべてのデバイスで1つのプロファイルを持つことができますが、すべてのプロパティのフロントドアカメラのみを表示する1つのプロファイルを持つこともできます。または、アパートのすべての部屋に設置されている温度計用の1つのプロファイルかもしれません。 
 
 ユーザーが作成したすべてのプロファイルは、プロファイルに保存されます  テーブル。レコードごとに、次のものがあります。
    profile_name  –ユーザーが選択したプロファイルの名前。
   user_account_id  –このプロファイルを作成したユーザーを参照します。この属性とprofile_name テーブルのUNIQUEキーを形成する属性。
   allow_others  –このプロファイルが他のユーザーと共有されているかどうかを示すフラグ。
   is_public  –このプロファイルが公開されているかどうかを示すフラグ。ほとんどの場合、これはFalseに設定されると予想できますが、プロファイルを全員と共有したい場合もあります。
   is_active  –このプロファイルがアクティブかどうかを示すフラグ。
   ts  –このレコードが挿入されたときのタイムスタンプ。
 
 
 プロファイルごとに、それに含まれるすべてのデバイスのリストを定義します。このリストはprofile_device_listに保存されます  テーブルであり、UNIQUE  profile_idのリストが含まれています –  device_id  ペア。この外部キーのペアは、テーブルの主キーを形成します。
 
 この主題の最後の表により、ユーザーは自分のプロファイルを他の登録ユーザーと共有できます。これは非常に便利です。 1人の人がすべてを管理し、他の登録ユーザー（家族など）が所有者によって作成されたプロファイルを表示したい場合。   shared_with   テーブルには、 profile_idのすべてのUNIQUEペアのリストが格納されます –  user_account_id  。この場合も、この外部キーのペアがテーブルの主キーです。共有はprofile.allow_othersの場合にのみ機能することに注意してください 属性がTrueに設定されています。
 セクション3：コマンドとデータ
 
 この最後のサブジェクト領域のテーブルを使用して、ユーザーとデバイス間の通信を保存します。これは双方向通信になります。デバイスは操作中にデータを生成し、データベースにはシステム（またはデバイス）によって生成されたメッセージと同様にデータが保存されます。ユーザーは、これらのメッセージとデバイスから送信されたデータを見たいと思うでしょう。このデータに基づいて、ユーザーはスマートホーム用のプログラムを作成できます。これらのプログラムは、手動または自動で生成されたコマンド、あるいは各ユーザーが望むことを正確に実行する一連のコマンドです。
   
 
 まず、デバイスから提供されるデータから始めます。   device_data内  表には、デバイスで生成されたデータの説明とデータの場所が格納されます。この場合も、データはデバイスによって自動的に生成されます。これは、一連の測定値、ステータス（テキストデータ）、または視聴覚データである可能性があります。この表のレコードごとに、以下を保存します：
    device_id  –このデータを生成したデバイスのID。
   data_description  –保存されたデータの説明。例：何が保存され、いつデータがシステムに保存され、どのような形式で保存されたか。
   data_location  –このデータが保存されている場所へのフルパス。
   ts  –このレコードが挿入されたときのタイムスタンプ。
 
 
 デバイスが正常に機能しているかどうか、またはデータが期待される範囲外であるかどうかに関係なく、デバイスデータが保存されます。これは基本的に、デバイスによって記録されたすべてのログです。古いデバイスデータファイルを削除する戦略があると期待できますが、それはこの記事の範囲外です。 
 
 デバイスデータとは異なり、メッセージは予期しないことが発生した場合にのみ生成されると予想できます。デバイスの測定値が正常範囲外の場合、センサーが動きを検出した場合など。このような場合、デバイスはメッセージを生成します。このようなメッセージはすべて、  auto_messageに保存されます。  テーブル。各レコードには、次のものがあります。
    device_id  –このメッセージを生成したデバイスのID。
   message_text  –デバイスによって生成されたテキスト。これは、事前定義されたテキスト、予想される範囲外の値、またはこれら2つの組み合わせである可能性があります。
   ts  –このレコードが保存されたときのタイムスタンプ。
 読み取り –メッセージがユーザーによって読み取られたかどうかを示すフラグ。
 
 
 残りの3つのテーブルは、ユーザーのコマンドを格納するために使用されます。コマンドを使用すると、ユーザーは制御可能なデバイスを制御し、スマートホームとの双方向通信を確立できます。
 
 まず、可能なすべてのコマンドタイプのリストを定義します。これらは、「オン/オフ」、「温度の上昇/低下」などの値である可能性があります。条件付きコマンドを使用することもできます。特定の条件が真である場合にのみ満たされるコマンド。すべての異なるコマンドタイプのリストは、  command_typeに保存されます  辞書。タイプごとに、UNIQUE  type_nameを保存します 。また、そのタイプのコマンドに対して定義する必要があるすべてのパラメーターのリストも保存します。これは、デフォルト値が挿入された構造化テキスト形式になります。ユーザーは、新しいコマンドを挿入するときにこれらの値を設定します。
 
 ユーザーは、すべての  recurring_commandsを定義することもできます  前もって。たぶん、毎日午前7時にお湯が欲しいか、毎日午後4時に暖房/冷房システムを作動させたいと思います。このテーブルには、一連のルールと、定期的なコマンドを実行するために必要なすべての属性が格納されています。 
    user_account_id  –この定期的なコマンドを挿入したユーザーのID。
   device_id  –この定期的なコマンドに関連するデバイスのID。
   command_type_id  –   command_typeへの参照  辞書。
 パラメータ –そのコマンドタイプに対して定義する必要のあるすべてのパラメーターと、それらの目的の値。
   interval_definition  –このコマンドの2回の繰り返しの間隔。コマンドパラメータと同様に、これは構造化テキストフィールドになります。
   active_from  およびactive_to –このコマンドを繰り返す必要がある間隔。  active_to  そのコマンドを永久に（または active_to を定義するまで）繰り返す場合は、属性をNULLにすることができます。 日付）。
   ts  –このレコードが挿入されたときのタイムスタンプ。
 
 
 モデルの最後のテーブルには、単一のコマンドのリストが含まれています。これらのコマンドは、ユーザーが手動で挿入することも、自動的に生成することもできます（つまり、定期的なコマンドの一部として）。コマンドごとに、以下を保存します：
    recurring_command_id  –このコマンドをトリガーする定期的なコマンドのID（存在する場合）。
   user_account_id  –このコマンドを挿入したユーザーのID。
   device_id  –関連するデバイスのID。
   command_type_id  –   command_typeを参照します  辞書。
 パラメータ –このコマンドに関連するすべてのパラメーター。
 実行済み –このコマンドが実行されたかどうかを示すフラグ。
   ts  –このレコードが挿入されたときのタイムスタンプ。
 
 スマートホームデータモデルについてどう思いますか？
 
 この記事では、スマートホームの管理の最も重要な側面について説明しました。それらの1つは、間違いなくユーザーとシステム間の双方向通信です。ほとんどの「実際の」アクションはテキストパラメータとして保存され、特定のアクションを実行するときにこれらの値を解析する必要があります。これは、さまざまな種類のデバイスを操作するのに十分な柔軟性を持たせるために行われました。 
 
 スマートホームモデルに追加する提案はありますか？何を変更または削除しますか？以下のコメントで教えてください。