Дизайн базы данных слишком повторяется? - PullRequest
Новая
       31

Дизайн базы данных слишком повторяется?

1 голос
/ 30 августа 2010

Я работаю над схемой базы данных, которая в настоящий момент сводит меня с ума, потому что я, кажется, повторяю одни и те же таблицы, чтобы воспроизвести поведение для различных типов.

По сути, система состоит из действующих датчиков, которыеконтролируются по сети и регистраторы, которые собираются через телефонную трубку.Датчики и регистраторы делятся на Места, а Места делятся на Области.Местоположение может иметь до 1 регистратора, но может иметь любое количество активных датчиков.

Я постараюсь нарушить правила:

  1. В системе может быть от 0 до многихрайоны
  2. В области может быть от 0 до нескольких мест
  3. Местоположение может иметь от 0 до 1 регистраторов
  4. Местоположение может иметь от 0 до многих LiveAnalogSensors
  5. Местоположение может иметь от 0 до многих LiveSwitchSensors
  6. Местоположение может иметь от 0 до многих разрешенных действий
  7. LiveAnalogSensor должен принадлежать 1 LiveSensorRelay
  8. LiveSwitchSensor должен принадлежать 1 LiveSensorRelay
  9. Регистратор может иметь от 0 до многих показаний
  10. LiveAnalogSensor может иметь от 0 до многих показаний
  11. LiveSwitchSensor может иметь от 0 до многих показаний
  12. Чтение может иметь будильник
  13. Система может иметь от 0 до многих действий
  14. Сигнал тревоги может иметь действие от 0 до 1
  15. Alarm может иметь от 0 до 1 AlarmResolution

Изображение схемы ЗДЕСЬ.

Таким образом, сценарий заключается в том, что чтение приходит и сохраняется (либо через загрузку Logger, либо через чтение в реальном времени).в сети).Показание выходит за пределы диапазона, поэтому у него есть код тревоги.Тревога генерируется для этого чтения.Действие в конечном итоге применяется к нему пользователем.Если приходит чтение, которое указывает, что состояние тревоги закончилось, запись AlarmResolution (или AlarmEnd, как я ее назвал в схеме) связывается с Alarm, чтобы показать, что оно закончилось, и время, когда оно закончилось.

На аналоговых тревогах, когда новое чтение выше, чем последнее, сохраняется новое «пиковое» чтение, для чего и предназначена таблица AnalogSensorReadingAlertPeak.

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

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

Спасибо.

РЕДАКТИРОВАТЬ: я немного изменил название и вопроспосле голосования «за», поскольку оно не было особенно конкретным.Я надеюсь, что теперь лучше ..

Ответы [ 4 ]

2 голосов
/ 30 августа 2010

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

Я бы попробовал сделать это, используя NORMA или аналогичный метод, чтобы проверить дизайн.

1 голос
/ 30 августа 2010

Я бы не стал слишком беспокоиться о слишком многих отношениях Zero-To-One.Я действительно беспокоюсь о том, что у есть отношения Zero-To-One.В долгосрочной перспективе это отношения типа «один ко многим».

Для меня нет ничего более запутанного, чем беспорядок в диаграмме ER, которая входит в стандартную комплектацию многих инструментов.Я использую технику под названием «Выровненные концептуальные диаграммы», чтобы помочь разобраться в моих отношениях.

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

Надеюсь, я сделаю это легко - одна сторона сверху, а другая сторона снизу.Многие ко многим разбиваются на две таблицы «один ко многим».

Повторяйте до конца.

Ссылка на полное изображение: http://i.stack.imgur.com/VKAGZ.jpg

alt text

0 голосов
/ 31 августа 2010

В Oracle ARC описывает взаимоисключающие отношения с другими таблицами.Эта концепция может быть реализована в других базах данных с использованием обнуляемых столбцов FK.

В зависимости от функциональности таблиц, вы можете выбрать объединение всех таблиц * Readings или всех * Alerts в одну таблицу, имеющую обнуляемые столбцы внешнего ключа.в соответствующие таблицы Logger, AnalogSensor и SwitchSensor.

Как следствие, таблицы * AlertEnd и * AlertAction также можно объединять (возможно, добавляя столбец типа, если требуется).

При необходимости,добавьте представления для трех доменов (Logger, AnalogSensor и SwitchSensor) для имитации исходных таблиц.

0 голосов
/ 30 августа 2010

Зачем вам нужны таблицы только с полями PK? Разве вы не можете связать их детей напрямую с их родителями?

Также рассмотрите возможность создания таблицы пределов с двумя полями и полем ключа contextID, поэтому вместо 2 таблиц с 4 полями пределов каждая (2 верхних и 2 нижних предельных поля) создайте новую таблицу с 3 полями и измените существующие иметь 2 поля с FK-связями с новым, с именами, такими как upperLimitContextID и lowerLimitContextID.

Кроме того, поскольку таблицы действий и конечные таблицы имеют одинаковое значение PK, рассмотрите возможность их объединения. Каждый раз, когда есть таблицы с одинаковым ПК, их можно объединять.

...