センサーとトリガーの 2 つの主要コンポーネントで構成されるシステムがあります。
システムは、センサーから送信された情報を記録し、特定のトリガーがアクティブまたは非アクティブになった時間をユーザーに報告する役割を果たします。
センサーに関するいくつかの情報:
- すべてのセンサーが同じフィールドのセットを記録します
- センサーは、記録されたときのタイムスタンプを付けて記録を送信します
トリガー:
- トリガーはユーザー定義
- 入力は 1 つのセンサーの 1 つの読み取りのみです (つまり、経時的な読み取りや複数のセンサーの読み取りではありません)。
- アクティブ/非アクティブ状態のみを持つ
センサーは、多対多ベースでトリガーに割り当てられます。
私が抱えている問題は、トリガーがアクティブまたは非アクティブになった「時期」を追跡することに関連しています。
たとえば、トリガー チェック値 > 1 の場合
sensor_id | reading | value | trigger_value
1 2011-04-25T20:09:00 0 false
1 2011-04-25T20:11:00 1 false
1 2011-04-25T20:13:00 4 true
1 2011-04-25T20:15:00 5 true
1 2011-04-25T20:17:00 3 true
1 2011-04-25T20:19:00 6 true
1 2011-04-25T20:21:00 1 false
それは返すかもしれません:
sensor_id | reading | event
1 2011-04-25T20:13:00 1 -- 'went active'
1 2011-04-25T20:21:00 0 -- 'went in-active'
私の現在のアプローチでは、各センサーの一連のトリガーの現在の状態を記録します。次の入力がセンサーに到着し、トリガーが評価されると、これがそのセンサーの現在のトリガー状態のリストと比較されます。状態が変化するたびに、「アクティブ化」または「非アクティブ化」が記録されます。
このアプローチは非常に単純ですが、データベースに「すでに存在する」状態変化に関するデータを生成します。ただし、データは単一のタプルではなく、タプル間の関係 (同じテーブル内) にあります。
したがって、質問は次のとおりです。
データが「すでにある」ため、アプローチを変更しますか。スキーマを変更してタプル間の関係にあまり依存しないようにするか、ビュー/ストアド プロシージャを作成して要求に応じて分析する
また
問題を解決し、同じテーブル内のタプル間に一時的な関係があるという事実を隠すので、このシステムを使い続けますか (これは悪いことだとわかっています)。
より一般的な形で:
時間ベースの統計/データをテーブルに保存し、RDBMSを荒らすことなく連続した統計間の違いを分析するにはどうすればよいですか?
現在の実装構造の例:
-- log incoming sensor data, keyed by sensor and when it was recorded
create table sensor_log (
sensor_id integer references sensors (sensor_id),
reading timestamp,
data_point_a integer NOT NULL, -- example name only
data_point_b integer NOT NULL,
-- ... various other data points
primary key(sensor_id, reading)
);
-- data storage for trigger configuration
create table triggers (
trigger_id integer,
-- ... configuration for the triggers
primary key(trigger_id)
);
-- associate triggers with particular sensors on a many to many basis
create table sensor_triggers (
sensor_id integer references sensors (sensor_id),
trigger_id integer references triggers (trigger_id),
-- ... configuration for the triggers
primary key(sensor_id, trigger_id)
);
-- record which triggers were active for a particular sensor input
-- not necessary, unless to save on recomputing past trigger activations
create table sensor_trigger_activations (
sensor_id integer,
reading timestamp,
trigger_id integer references triggers (trigger_id),
primary key (sensor_id, reading, trigger_id),
foreign key (sensor_id, reading) references sensor_log (sensor_id, reading)
);
-- record trigger 'activations' & 'deactivations'
-- activation: active state preceded by in-active state (for a particular trigger)
-- deactivation: in-active state preceded by an active state ""
-- absense
create table sensor_trigger_events (
sensor_id integer,
reading timestamp,
trigger_id integer,
event_type smallint CHECK (event_type = 0 OR event_type = 1), -- 0 = deactivation, 1 = activation
primary_key (sensor_id, reading, trigger_id),
foreign key (sensor_id, reading) references sensor_log (sensor_id, reading)
);