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

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

2 голосов
/ 02 декабря 2010

Этот вопрос связан с другим вопросом, который я задал. В моем другом вопросе я спрашиваю мнение людей о 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).Регистратор собирает показания до тех пор, пока он не будет собран позже, работающие датчики немедленно передают показания через сеть, и у них есть дополнительные атрибуты, такие как сетевые ведомые устройства, которые имеют атрибуты сетевого адреса ... которые довольно сильно отличаются от регистраторов (я однажды пытался рассматривать регистраторы как датчикине работает).

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

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

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

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

Спасибо.

Ответы [ 2 ]

3 голосов
/ 05 декабря 2010

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

Да.

Вы допустили две основные ошибки.

  1. Наклейка Id йот на все, что движется.

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

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

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

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

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

Неправильное место. Нам нужно выполнить резервное копирование на (1).

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

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

Вопросы

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

  2. Подумайте о том, что регистратором является SensorNo ноль.

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

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

0 голосов
/ 02 декабря 2010

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

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

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

...