私はデータベースの設計を決定しようとしています。より具体的には、これはより大きな設計のサブパーツです。基本的に、「ロケーション」があります。各ロケーションには、任意の数のセンサーを関連付けることができ、ロガーを含めることができます（ただし、1つのみ）。
私にはセンサーの測定値があり、ロガーの測定値があります。それぞれが、別々のテーブルを保証するのに十分異なると思います。
センサーの読み取り値が範囲外になると、アラートが生成されます。センサーの読み取り値が範囲外にある間、それらはそのアラートに関連付けられ続けるため、多くの読み取り値を含む1つのアラートになり、後でアラートをグラフ化して傾向などを見つけることができます。
ロガーの測定値と同じです。
このデータを保存するためのこれまでの私の3つのアイデアは次のとおりです。
オプション1：
場所[表] -ID [PK] - 名前 -HasLogger LiveSensor[表] --LocationId [FK] -ID [PK] LiveSensorReading[表] -ID [PK] --SensorId [FK] - 価値 LiveSensorAlert[テーブル] -ID [PK] --SensorReadingId [FK]（必要ない場合があります-常に少なくとも1つの読み取り値が必要です） LiveSensorAlertCorrectiveAction[表] --LiveSensorAlertId [FK] --CorrectiveActionId [FK] --ByUserId [FK] LiveSensorAlertAcknowledgement[表] --LiveSensorAlertId [FK] --ByUserID [FK] LiveSensorAlertReading[テーブル] --SensorAlertId [FK] --SensorReadingId [FK] LoggerReading[表] --LocationId [FK] - 価値 LoggerAlert[テーブル] -ID [PK] --LoggerReadingId [FK]（必要ない場合があります-常に少なくとも1つの読み取り値が必要です） LoggerAlertReading[テーブル] --LoggerAlertId [FK] --LoggerReadingId [FK] LoggerAlertCorrectiveAction[テーブル] --LoggerAlertId [FK] --CorrectiveActionId [FK] --ByUserId [FK] LoggerAlertAcknowledgement[表] --LoggerAlertId [FK] --ByUserID [FK]
- 問題：繰り返しテーブルがたくさんあります（それは本当に重要ですか??）
オプション2：
場所[表] -ID - 名前 -HasLogger センサー[表] -ID [PK] --LocationId [FK] SensorReading[表] -ID [PK] --SensorId [FK] - 価値 LoggerReading --LocationId [FK] - 価値 アラート[表] -ID [PK] AlertCorrectiveAction[テーブル] --AlertId [FK] --CorrectiveActionId [FK] --ByUserId [FK] AlertAcknowledgement[表] --AlertId [FK] --ByUserId [FK] SensorAlertReading --AlertId [FK] --SensorReadingId [FK] LoggerAlertReading --AlertId [FK] --LoggerReadingId [FK]
- 問題：「アラートごとに少なくとも1つの読み取り」ルールを適用しません。
- 問題：複数のタイプの読み取りで同じアラートを参照できるようにします。
オプション3：
場所[表] -ID - 名前 -HasLogger センサー[表] -ID [PK] --LocationId [FK] SensorReading[表] -ID [PK] --SensorId [FK] - 価値 LoggerReading --LocationId [FK] - 価値 アラート[テーブル]「スーパーテーブル」 -ID [PK] LoggerAlert[テーブル] --AlertId [PK、FK] --LoggerReadingId [FK] SensorAlert[表] --AlertId [PK、FK] --SensorReadingId [FK] AlertCorrectiveAction[テーブル] --AlertId [FK] --CorrectiveActionId [FK] --ByUserId [FK] AlertAcknowledgement[表] --AlertId [FK] --ByUserId [FK] SensorAlertReading[表] --SensorAlertId [FK] --SensorReadingId [FK] LoggerAlertReading[テーブル] --LoggerAlertId [FK] --LoggerReadingId [FK]
- 問題：同じアラートを参照するLoggerAlertとSensorAlertを停止するものはありません（オプション2と同じ問題）。
- 問題：データベースをわかりにくくします（スーパーテーブルはOOの概念ではありませんか？データベースは純粋にリレーショナルであることが意図されていますね？）
これまでのところ、オプション1を選択していると思います。これは、テーブルを効果的に繰り返しているにもかかわらず、オプション1が非常にクリーンで、意図が明確であるためです（私は願っています！）。
私が今考えた唯一のわずかな問題は、さまざまなセンサーの読み取り値が1つのアラームに関連付けられる可能性があることです。
上記の選択肢について、人々の意見はどうなっているのだろうか。静かにすることをお勧めする「スーパーテーブル」をよく使用しますが、何らかの理由で正しく感じられません。特に、データの整合性を確保する方法を見ると、ちょっとしたハックのように感じます。リレーショナル設計よりもオブジェクト指向プログラミングに似ているようです。
ありがとう。
編集： 以下の質問のいくつかに答えるのに役立ついくつかのさらなる情報：
ほとんどの場合、データベースは、違いが生じる場合は、アプリケーションサーバーを介してのみ操作されます。
ライブアラートとロガーアラートは通常同じように扱われるため、ロガーアラートとライブアラートを異なる方法で処理するのではなく、ほとんどの場合、すべてのアラートを処理することになります。
ロガーには、ロケーションテーブルに存在するかなり特定の列があります。場所とロガーは1対1のマッピングになるので、別のロガーテーブルを使用しないことにしました。これまでのところ、問題なく機能し、シンプルに保たれているようです。列の例：LoggerRFID（int）、LoggerUpperLimit（float）、LoggerLowerLimit（float）など。ロガーはセンサーであるとほぼ主張できますが、私はその道を進みましたが、あまりうまくいきませんでした。
私はアラートを一般的なものにすることをほぼ受け入れることができますが、回答の1つが言ったように、私はこれについて非常に確信を持って努力しているので、特定のパスを選択する前にできるだけ長く調査を続けます。