カメラ、回転ドア、エレベーター、温度センサー、アラーム–これらのデバイスはすべて、私たちの周りで起こっているイベントに関連する多数の相互接続された信号を生成します。ここで、ステータスを追跡し、リアルタイムのレポートを作成し、このすべての信号データに基づいて予測を行う必要がある人物を想像してみてください。これを行うには、最初にそのデータを保存する必要があります。このような信号処理をサポートするデータモデルは、今日の記事のトピックです。
着信信号を保存する最も簡単な方法は、それらのテキスト表現を1つの巨大なリストに保存することです。このアプローチでは、挿入をすばやく実行できますが、更新には問題があります。また、そのようなモデルは正規化されないため、その方向に進むことはありません。
さまざまなデバイスによって生成されたデータを保存し、デバイスがどのように関連しているかを定義するために使用できる正規化されたデータモデルを作成します。このようなモデルは、必要なものすべてを効率的に保存し、分析や予測分析にも使用できます。
データモデル
信号処理データモデル
モデルは3つのサブジェクトエリアで構成されています：
複合体インストールとデバイス信号とイベント
これらの各主題分野について、記載されている順序で説明します。
複合体
このデータモデルを作成する際、私はそれを使用して、より大きな複合施設で何が起こっているかを追跡することを想定しました。複合施設のサイズは、シングルルームからショッピングモールまでさまざまです。すべての複合施設に少なくとも1つのデバイス/センサーがあることが重要ですが、おそらくもっと多くのデバイス/センサーがあります。
複合体について説明する前に、国と都市を処理するテーブルを定義する必要があります。これらは、各複合施設の場所のかなり詳細な説明を提供します。
国ごとに 、その一意の country_nameを保存します; 都市ごとに 、 postal_codeの一意の組み合わせを保存します 、 city_name 、および country_id 。ここでは詳しく説明しません。各都市には郵便番号が1つしかないことを前提としています。実際には、ほとんどの都市には複数の郵便番号があります。その場合、各都市のメインコードを使用できます。
複雑な データ生成デバイスがインストールされている実際の建物または場所です。前に述べたように、複合施設は、単一の部屋や測定ステーションから、駐車場、ショッピングモール、映画館などのはるかに大きな場所までさまざまです。これらは、分析の対象です。複雑なレベルで何が起こっているかをリアルタイムで追跡し、後でレポートと分析を作成できるようにしたいと考えています。複合施設ごとに、以下を定義します：
-
complex_code–各複合体の一意の識別子。別の主キー属性（id）がありますが ）このテーブルでは、複合体ごとに別の識別コードを別のシステムから継承することが期待できます。 -
complex_name–その複合体を説明するために使用される名前。ショッピングモールや映画館の場合、これは実際の有名な名前である可能性があります。測定ステーションには、一般的な名前を使用できます。 -
city_id–複合施設が配置されている都市への参照。 アドレス–その複合施設の物理アドレス。位置 –テキスト形式で定義された複合体の位置（つまり、地理座標）。説明–この複合体をより詳細に説明するテキストによる説明。-
ts_inserted–このレコードが挿入されたときのタイムスタンプ。 -
is_active–この複合体がまだアクティブであるかどうかを示すブール値。
インストールとデバイス
今、私たちはモデルの中心に近づいています。各複合施設には、多くのデバイスが設置される可能性があります。また、ほぼ確実に、これらのデバイスを目的に基づいてグループ化します。カメラ、ドアセンサー、ドアの開閉に使用するモーターは、連携して機能するため、グループにまとめることができます。
私たちのモデルでは、1つの複合施設で連携するデバイスがインストールにグループ化されています。これらは、玄関ドア、エスカレーター、温度センサーなどに使用できます。インストールごとに、次の詳細をインストールに保存します。 テーブル：
-
installation_code–そのインストールを示すために使用される一意のコード。 インストールtype_id–installation_typeへの参照辞書。この辞書には、一意のtype_nameのみが格納されます タイプを説明する属性。例：エスカレーター、エレベーター。-
complex_id–複合体への参照そのインストールはに属します。 位置 –コンプレックス内のそのインスタレーションのテキスト形式の座標。説明–そのインストールのテキストによる説明。-
current_status_id–現在のステータスへの参照（installation_status から）表）そのインストールの。 -
ts_inserted–このレコードがシステムに挿入されたときのタイムスタンプ。
インストールステータスについてはすでに説明しました。考えられるすべてのステータスのリストは、 installation_statusに保存されます。 辞書。各ステータスは、その status_nameによって一意に定義されます 。さらに、そのステータスを使用した場合に、インストールが is_brokenであることを示すフラグを保存します。 、 is_inactive 、 is_maintenance 、または is_active 。これらのフラグの1つだけを一度に設定する必要があります。
インストールにはすでに現在のステータスが割り当てられています。デバイスで何が起こっているかを追跡する場合は、その履歴も保存する必要があります。そのために、もう1つのテーブル installation_status_historyを使用します。 。ここでは、レコードごとに、関連するインストールとステータスへの参照と、その瞬間（ ts_inserted ）を保存します。 ）そのステータスが割り当てられたとき。
インストールは私たちの複合体の一部です。各インストールは単一のエンティティですが、それでも他のインストールに関連している可能性があります。 （たとえば、ショッピングモールの正面玄関のビデオシステムは、明らかにモールの正面玄関に関連しています。人々は最初にカメラで見られ、次にドアが開きます。）これらの関係を追跡したい場合は、それらを保存します。 related_installation テーブル。このテーブルには、2つのキーの一意のペアのみが含まれていることに注意してください。どちらもインストールを参照しています。 テーブル。
同じロジックがデバイスの保存に使用されます。デバイスは、関心のある信号を生成する単一のハードウェアです。インストールはコンプレックスに属しますが、デバイスはインストールに属します。 デバイスごとに 、保存します：
-
device_code–各デバイスを表す独自の方法。 -
device_name–このデバイスの名前。 -
installation_id–このデバイスが属するインストールへの参照。 -
current_status_id–デバイスの現在のステータス。 -
ts_inserted–このレコードが挿入されたときのタイムスタンプ。
ステータスは同じ方法で処理されます。 device_statusを使用します 考えられるすべてのデバイスステータスのリストを格納するテーブル。このテーブルの構造は、 installation_statusと同じです。 属性も同じように使用されます。 2つの個別のステータスディクショナリを使用する理由は、デバイスとそのインストールのステータスが、少なくとも名前では異なる可能性があるためです。
現在のステータスはdevice.current_status_idに保存されます 属性とステータス履歴はdevice_status_historyに保存されます テーブル。ここでは、レコードごとに、デバイスとステータス、およびこのレコードが挿入された瞬間との関係を保存します。
このサブジェクトエリアの最後のテーブルは、 related_deviceです。 テーブル。同じインストール内のすべてのデバイスが密接に関連していることはほぼ明らかですが、任意のインストールに属する2つのデバイスを関連付けるオプションが必要です。これを行うには、2つのデバイスIDをこのテーブルに保存します。
信号とイベント
これで、モデル全体の心臓部の準備が整いました。
デバイスは信号を生成します。すべての信号データは信号に保持されます テーブル。信号ごとに、次のものを保存します：
-
device_id–その信号を生成したデバイスへの参照。 値–その信号の数値。説明–その単一の信号に関連する追加のパラメーター（信号タイプ、値、使用される測定単位など）を含む可能性のあるテキスト値。このデータはJSONのような形式で保存されます。-
ts–このシグナルがテーブルに挿入されたときのタイムスタンプ。
このテーブルは、1秒間に多数の挿入が実行されるため、非常に頻繁に使用されることが予想されます。したがって、データベースの保守では、このテーブルのサイズの追跡に重点を置く必要があります。
最後に、データモデルにイベントを追加します。イベントは、信号によって自動的に生成されるか、手動で挿入されます。自動生成されたイベントの1つは「ドアが5分間開いている」ことであり、手動で挿入されたイベントは「この信号のためにデバイスの電源を切る必要があった」ことです。全体的なアイデアは、デバイスの動作の結果として発生したアクションを保存することです。後で、デバイスの動作分析を実行するときにこれらのイベントを使用できます。
イベントはevent_typeによって細分化されます 。各タイプは、その type_nameによって一意に定義されます 。
自動生成または手動で挿入されたすべてのイベントは、 eventに記録されます テーブル。ここのレコードごとに、以下を保存します：
-
event_type_id–関連するイベントタイプへの参照。 説明–そのイベントのテキストによる説明。-
signal_id–イベントの原因となったシグナル（存在する場合）への参照。 -
inserted_manually–このレコードが手動で挿入されたかどうかを示すフラグ。 -
event_tsおよびts_inserted–このイベントが実際に発生したとき、およびそのレコードが挿入されたときのタイムスタンプ。特にイベントレコードが手動で挿入される場合、これら2つは異なる可能性があります。
モデルの最後のテーブルはevent_device です テーブル。このテーブルは、イベントを関連するすべてのデバイスに関連付けるために使用されます。レコードごとに、UNIQUEペアの event_idを保存します – device_id およびレコードが挿入されたときのタイムスタンプ。
信号処理データモデルについてどう思いますか？
今日は、さまざまな場所に設置された一連のデバイスからの信号を追跡するために使用できる簡略化されたデータモデルを分析しました。モデル自体は、ステータスを追跡して分析を実行するために必要なすべてのものを格納するのに十分である必要があります。それでも、多くの改善が可能です。何を追加できますか？以下のコメントで教えてください。