Как далеко зайти с ограничениями базы данных?

Этот вопрос связан с другим вопросом, который я задал. В моем другом вопросе я спрашиваю мнения людей о 3 разных способах создания базы данных. Самый простой способ сделать это без (практически) повторения таблиц и таких странных понятий, как "супер таблицы", - это вариант 2:

Location [Table]
- Id
- Name
- HasLogger
- LoggerRFID
- LoggerUpperLimit
- LoggerLowerLimit

Sensor [Table]
- Id [PK]
- LocationId [FK]
- UpperLimit
- LowerLimit

SensorReading [Table]
- Id [PK]
- SensorId [FK]
- Value

LoggerReading [Table]
- LocationId [FK]
- Value

Alert [Table]
- Id [PK]

AlertCorrectiveAction [Table]
- AlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]

AlertAcknowledgement [Table]
- AlertId [FK]
- ByUserId [FK]

SensorAlertReading [Table]
- AlertId [FK]
- SensorReadingId [FK]

LoggerAlertReading [Table]
 - AlertId [FK]
 - LoggerReadingId [FK]

Теперь проблема с этим параметром заключается в том, что он позволяет "привязывать" показания нескольких датчиков и нескольких мест к одному предупреждению.

Чтобы объяснить, почему это проблема, я объясню, как работает система:

Местоположение может содержать много "живых датчиков", но только 1 регистратор. По этой причине я поместил атрибуты регистратора в таблицу местоположений (это было эффективное отношение 1 к 1). Регистратор собирает показания до тех пор, пока он не будет собран позднее, работающие датчики немедленно передают показания через сеть, и у них есть дополнительные атрибуты, такие как сетевые ведомые устройства, которые имеют атрибуты сетевого адреса... которые довольно сильно отличаются от регистраторов (я однажды пытался рассматривать регистраторы как датчики, не так ли? не получается хорошо).

Когда датчик или регистратор выходит за пределы диапазона (обозначенного показаниями), система генерирует предупреждение. Предупреждение относится только к этому датчику и считается активным до тех пор, пока показания этого датчика (или регистратора) не покажут, что он вернулся в диапазон. До этого времени показания, которые выводят датчик за пределы диапазона, "связаны" с этим же предупреждением.

Таким образом, как вы можете видеть, одно предупреждение должно действительно иметь показания только для одного и того же датчика, связанного с ним, однако моя схема выше позволяет связывать разные показания от разных датчиков и регистраторов с одним и тем же предупреждением - если меня беспокоит, что я не имею ' T как-то ограничен? Другая проблема заключается в том, что он позволяет оповещениям существовать без каких-либо показаний.

Отсюда мой вопрос; насколько далеко нужно идти с ограничениями или сгибать дизайн, чтобы соответствовать этим ограничениям? Мне нравится приведенная выше конструкция, потому что она проста - оповещения могут иметь показания датчиков и показания регистратора, поэтому их просто связать.

Я не могу удержаться от мысли, что мне тоже не хватает трюка - есть ли намного лучший способ сделать этот дизайн? Я ходил кругами с ним целую вечность, и всегда есть компромисс (если я не повторю все таблицы предупреждений для разных типов чтения).

Благодарю.

Источник

2 ответа

Решение

Должен ли я быть обеспокоен тем, что я как-то этого не сдерживал?

Да.

Вы сделали две основные ошибки.

  1. Вставлять Id все ключи на все, что движется.

    Это препятствует вашей способности моделировать данные как данные (не как строки, которые не имеют смысла, но с искусственно реализованной уникальностью) и предоставлять идентификаторы; и зависимости (например, датчик зависит от местоположения). Вы моделируете электронные таблицы с предварительно установленными Row_Ids, содержащими данные. Вам необходимо нормализовать данные, как данные.

    Это привело к проблеме, которую вы определили, но есть и другие проблемы.

    Если вы смоделируете данные, идентификаторы будут очищены, и ограничения Ind ex и FK предотвратят это. Какие данные являются независимыми; какие данные принадлежат (зависят от) к каким другим данным; какие данные делают с другими данными, и основа этих действий.

    Затем (основные проблемы были решены) у вас остались только незначительные ограничения для решения второстепенных вопросов.

  2. В противном случае вы застряли с добавлением ограничений повсюду, чтобы попытаться получить то, что вы хотите, но так и не добились этого. Вы знаете, что они вам нужны, поэтому вы ищете их.

Не то место. Нам нужно вернуться к (1).

Я ответил на другой ваш вопрос и включил ▶ Модель данных датчика ◀. Это не устраняет недостатки, которые вы укажете здесь. Однако, я только что увидел этот вопрос, завтра обновлю DM и включу эти таблицы и столбцы.

▶ Ссылка на нотацию IDEF1X ◀ для всех, кто не знаком со Стандартом моделирования реляционных баз данных.

Вопросы

  1. Похоже, вам нужна справочная таблица для датчиков, элемент полки, для хранения UpperLimit и LowerLimit; вместо того, чтобы повторять это для каждого местоположения. Или они установлены, локализованы, для каждого Местоположения.

  2. Подумайте о том, что Logger - это SensorNo ноль.

  3. Почему датчики не имеют RFID?

  4. На каждом Location, это Logger необязательно, это 1::0-1?

Источник

Почему бы не иметь:

Alert [Table]
- Id [PK]  
- SensorReadingId [FK]  
- LoggerReadingId [FK]

И затем вы заполняете либо SensorReadingId, либо LoggerReadingId. Я предполагаю, что ваша структура упрощена, но часто таблица с чем-то еще, кроме одного ПК, является избыточной.

Источник
Другие вопросы по тегам