Я пытаюсь определиться с дизайном базы данных. Точнее говоря, это часть более крупного дизайна. По сути, существуют «Местоположения» - каждое местоположение может иметь любое количество датчиков, связанных с ним, и может иметь регистратор (но только 1).
У меня есть показания датчиков, и у меня есть показания регистратора, каждый из которых достаточно различен, чтобы их можно было использовать в отдельных таблицах.
Если показания датчика выходят за пределы диапазона, генерируется предупреждение. Несмотря на то, что показания датчика остаются вне диапазона, они продолжают ассоциироваться с этим предупреждением, так что в итоге вы получаете 1 предупреждение, содержащее множество показаний, позволяющих мне позже составить график предупреждения, чтобы я мог определить тренды и т. Д.
То же самое с показаниями регистратора.
Вот мои 3 идеи для хранения этих данных:
Вариант 1:
Location [Table]
- Id [PK]
- Name
- HasLogger
LiveSensor [Table]
- LocationId [FK]
- Id [PK]
LiveSensorReading [Table]
- Id [PK]
- SensorId [FK]
- Value
LiveSensorAlert [Table]
- Id [PK]
- SensorReadingId [FK] (may not be needed - enforces need to always have at least 1 reading)
LiveSensorAlertCorrectiveAction [Table]
- LiveSensorAlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]
LiveSensorAlertAcknowledgement [Table]
- LiveSensorAlertId [FK]
- ByUserID [FK]
LiveSensorAlertReading [Table]
- SensorAlertId [FK]
- SensorReadingId [FK]
LoggerReading [Table]
- LocationId [FK]
- Value
LoggerAlert [Table]
- Id [PK]
- LoggerReadingId [FK] (may not be needed - enforces need to always have at least 1 reading)
LoggerAlertReading [Table]
- LoggerAlertId [FK]
- LoggerReadingId [FK]
LoggerAlertCorrectiveAction [Table]
- LoggerAlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]
LoggerAlertAcknowledgement [Table]
- LoggerAlertId [FK]
- ByUserID [FK]
- Проблема: множество повторяющихся таблиц (правда ли это имеет значение ??)
Вариант 2:
Location [Table]
- Id
- Name
- HasLogger
Sensor [Table]
- Id [PK]
- LocationId [FK]
SensorReading [Table]
- Id [PK]
- SensorId [FK]
- Value
LoggerReading
- LocationId [FK]
- Value
Alert [Table]
- Id [PK]
AlertCorrectiveAction [Table]
- AlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]
AlertAcknowledgement [Table]
- AlertId [FK]
- ByUserId [FK]
SensorAlertReading
- AlertId [FK]
- SensorReadingId [FK]
LoggerAlertReading
- AlertId [FK]
- LoggerReadingId [FK]
- Проблема: не применяется "по крайней мере 1
«чтение по предупреждению» правило.
- Проблема: допускает более одного типа
чтение для ссылки на то же предупреждение.
Вариант 3:
Location [Table]
- Id
- Name
- HasLogger
Sensor [Table]
- Id [PK]
- LocationId [FK]
SensorReading [Table]
- Id [PK]
- SensorId [FK]
- Value
LoggerReading
- LocationId [FK]
- Value
Alert [Table] "super table"
- Id [PK]
LoggerAlert [Table]
- AlertId [PK, FK]
- LoggerReadingId [FK]
SensorAlert [Table]
- AlertId [PK, FK]
- SensorReadingId [FK]
AlertCorrectiveAction [Table]
- AlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]
AlertAcknowledgement [Table]
- AlertId [FK]
- ByUserId [FK]
SensorAlertReading [Table]
- SensorAlertId [FK]
- SensorReadingId [FK]
LoggerAlertReading [Table]
- LoggerAlertId [FK]
- LoggerReadingId [FK]
- Проблема: ничто не мешает
LoggerAlert и SensorAlert
ссылка на то же самое оповещение (та же проблема
как вариант 2).
- Проблема: запутывает базу данных (не
супер стол больше концепции ОО?
База данных должна быть чисто
не так ли?)
Я думаю, что до сих пор я предпочитаю вариант 1, потому что он кажется таким чистым и цель ясна (я надеюсь!), Хотя я эффективно повторяю таблицы.
Единственная небольшая проблема, о которой я только что подумал, заключается в том, что показания для разных датчиков могут по-прежнему ассоциироваться с одним сигналом тревоги.
Мне интересно, что люди думают о вышеупомянутых вариантах. Я видел использование «супер таблиц», рекомендуемых тихо, часто, но по какой-то причине это просто нехорошо - это почти похоже на хак, особенно когда я вижу методы для обеспечения целостности данных. Кажется, это больше похоже на ОО-программирование, чем на реляционный дизайн.
Спасибо.
EDIT:
Некоторая дополнительная информация, чтобы помочь ответить на некоторые из вопросов ниже:
Большую часть времени базой данных манипулируют только через сервер приложений, если это имеет значение.
Живые оповещения и оповещения регистратора обычно обрабатываются одинаково, поэтому я, вероятно, буду иметь дело со всеми оповещениями большую часть времени, а не с оповещениями регистратора и оповещениями в реальном времени.
В логгере есть довольно специфические столбцы, которые находятся в таблице местоположений. Так как местоположение и регистратор были бы отображением 1: 1, я решил не иметь отдельную таблицу регистратора, и до сих пор она, кажется, работала нормально и оставалась простой. Пример столбцов: LoggerRFID (int), LoggerUpperLimit (float), LoggerLowerLimit (float) и т. Д. Можно почти утверждать, что регистратор является датчиком, но я пошел по этому пути, и он не получился слишком хорошо.
Я почти могу согласиться с тем, чтобы сделать оповещения общими, но, как сказал один из ответов, я стараюсь быть в этом очень уверенным, поэтому продолжаю исследования как можно дольше, прежде чем выбрать конкретный путь.