Внедрение специализированной структуры в ER диаграмме

Question

Я проектирование БД и найти ситуацию, когда им не уверены, что делать, так что в первую очередь позволяет ilustrate части диаграммы ER с изображением:

Как можно видеть, у меня есть следующие:

• устройство производит 0: N обработки данных
• данные могут быть получены из различных типов данных (Например, устройство может производить темп а также данные о влажности и данные о влажности при той же самой отметке )
• Конкретные данные были получены только устройством 1: 1
• Связь 1: N между устройством и данными. Поскольку данные являются слабым объектом (возможно, существуют данные без устройств), у меня будет составной ПК в данных, образованных идентификаторами ID_DEVICE и TIMESTAMP (не представлены на изображении)
• Поскольку конкретные данные могут быть только одного типа, У меня есть специализированные «подтипы», от DataType1 до DataType10, а в случае DataType2 i имеют другую специализацию. Очевидно, что каждый из этих объектов имеет разные атрибуты.

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

С другой стороны, если я должен создать таблицу для супертипа данных, я могу добавить поле «тип» в отношении специализации, чтобы однозначно идентифицировать каждую строку данных.

¿Как я должен действовать в этом случае? Поскольку я думаю, что оба варианта верны, что дает больше преимуществ и почему? Любое улучшение или предложение разрешено! : D

Answer 1

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

Я применил первый вариант, который я дал, чтобы наследовать ПК от объекта данных (ID_DEVICE, TIMESTAMP) в каждый из подтипов. Таким образом, данные супертипа не станут таблицей в db.

Причина, по которой я делал это, был из-за типа запросов, которые пользователь собирается делать. В 95% случаев запросы будут выполняться с одним устройством и с одним конкретным типом данных, поэтому нет смысла иметь таблицу данных, которая включает ссылки на количество строк WHOLE в каждом типе данных.

В этом случае, если им было предложено показать все значения DATATYPE3, сгенерированные DEVICE 1, сначала я должен запросить общую таблицу DATA (которая содержит ссылки на все другие DATATYPES, даже если я знаю, что они мне не нужны) и после это, я должен запросить таблицу DATATYPE3 для фактического восстановления желаемых значений (поскольку таблица DATA не имеет значений). Я думаю, что это очень мало.

Надеюсь, это поможет кому-то! :)

Answer 2

Ошибка с ERD в том, что вам нужна только 1 таблица для типа данных и одна для подтипа. Затем у вас должно быть отношение между данными и общими понятиями и другое отношение между подтипом и типом данных.

Причина в том, что данные принадлежат только к определенному подтипу (humidity10, которая сама по себе влажности типа)