Это довольно многословно, но надежда может помочь. По сути, представлены таблицы конфигурации устройства и таблицы текущей конфигурации. Таким образом, показания отслеживают пару (DEV_MAC, DEV_CFG_NO), которая сохраняет исторические данные при изменении конфигурации устройств. Я также несколько переименовал атрибуты, чтобы сэкономить на экране.
[p 1] Тип датчика SNS_TYP типа чтения REA_TYP существует.
(c 1.1) Каждый тип датчика имеет только один тип чтения; возможно, что более одного типа датчика имеют одинаковый тип чтения.
SensorType {SNS_TYP, REA_TYP} -- p 1
PK {SNS_TYP} -- c 1.1
CHECK REA_TYP in (Measure, Switch)
-- sample
(Temperature, Measure)
(Humidity, Measure)
(Door, Switch)
[p 2] Тип устройства DEV_TYP существует.
(c 2.1) Тип устройства обозначается DEV_TYP.
DeviceType {DEV_TYP} -- p 2
PK {DEV_TYP} -- c 2.1
-- sample
(d_type_1)
(d_type_2)
[p 3] Тип устройства DEV_TYP содержит тип датчика SNS_TYP.
(c 3.1) Для каждого типа устройства этот тип может содержать более одного типа датчика; для каждого типа датчика этот тип датчика может содержаться более чем в типе устройства.
(c 3.2) Для каждого типа устройства и типа датчика этот тип датчика может содержаться не более в этом типе устройства. один раз.
(c 3.3) Если тип устройства содержит тип датчика, то этот тип устройства должен существовать.
(c 3.4) Если тип устройства содержит тип датчика, то этот датчик тип должен существовать.
DeviceTypeSensorType {DEV_TYP, SNS_TYP} -- p 3
PK {DEV_TYP, SNS_TYP} -- c 3.1, 3.2
FK1 {DEV_TYP} REFERENCES DeviceType -- c 3.3
FK2 (SNS_TYP} REFERENCES SensorType -- c 3.4
-- sample
(d_type_1, Temperature)
(d_type_1, Humidity)
(d_type_2, Temperature)
(d_type_2, Door)
[p 4] Устройство с MA C адресом DEV_MAC существует.
(c 4.1) Устройство идентифицируется по адресу MA C.
Device {DEV_MAC} -- p 4
PK {DEV_MAC} -- c 4.1
-- sample
(00:00:00:00:00:00)
(FF:FF:FF:FF:FF:FF)
[p 5] Конфигурация устройства DEV_MAC изменена на тип устройства DEV_TYP в качестве номера конфигурации устройства DEV_CFG_NO, на дату изменения VALID_FROM.
(c 5.1) Конфигурация устройства определяется устройством и номером конфигурации устройства.
(c 5.2) Для каждого устройства и даты изменения это устройство меняло конфигурацию на эту дату ровно один раз; возможно, что более чем одно устройство изменило конфигурацию на эту дату.
(c 5.3) Для каждой конфигурации устройства и типа устройства эта конфигурация устройства имеет ровно один тип устройства; возможно, что для этого типа устройства используется более одной конфигурации устройства.
(c 5.4) Если конфигурация устройства изменилась, то это устройство должно существовать.
(c 5.5) Если конфигурация устройства изменилась на тип устройства, то этот тип устройства должен существовать.
DeviceConfig {DEV_MAC, DEV_CFG_NO, DEV_TYP, VALID_FROM} -- p 5
PK {DEV_MAC, DEV_CFG_NO} -- c 5.1, 5.3
AK {DEV_MAC, VALID_FROM} -- c 5.2
FK1 {DEV_MAC} REFERENCES Device -- c 5.4
FK2 {DEV_TYP} REFERENCES DeviceType -- c 5.5
-- sample
(00:00:00:00:00:00, 1, d_type_1, 2019-05-01)
(00:00:00:00:00:00, 2, d_type_2, 2019-07-01)
(00:00:00:00:00:00, 3, d_type_1, 2019-09-01)
(FF:FF:FF:FF:FF:FF, 1, d_type_2, 2020-01-01)
(FF:FF:FF:FF:FF:FF, 2, d_type_1, 2020-03-01)
Время остановиться здесь и рассмотреть некоторые предположения. Я предполагаю, что новая конфигурация устройства известна и введена в DeviceConfig до того, как устройство начнет потоковую передачу данных.
Данные устройства могут выглядеть примерно так (JSON):
{ "device":"00:00:00:00:00:00",
"time":"2019-07-01T17:15:12",
"data":{ "Battery":75,
"Temperature":35.5,
"Humidity":1,
}
}
Этот формат обеспечивает:
{DEV_MAC, SNS_TYP, SNS_VALUE, READ_DTM}
Хотелось бы иметь:
{DEV_MAC, DEV_CFG_NO, DEV_TYP, SNS_TYP, REA_TYP, SNS_VALUE, REA_TYP, READ_DTM}
Чтобы "обогатить" данные датчика, ток создается вид конфигурации.
[P 6] Устройство DEV_MAC в текущей конфигурации DEV_CFG_NO, типа устройства DEV_TYP, содержит тип датчика SNS_TYP типа чтения REA_TYP.
-- implement as a view
CurrentConfig {DEV_MAC, DEV_CFG_NO, DEV_TYP, SNS_TYP, REA_TYP}
KEY {DEV_MAC, SNS_TYP} -- Logical
-- sample
(00:00:00:00:00:00, 3, d_type_1, Temperature, Measure)
(00:00:00:00:00:00, 3, d_type_1, Humidity, Measure)
(FF:FF:FF:FF:FF:FF, 2, d_type_1, Temperature, Measure)
(FF:FF:FF:FF:FF:FF, 2, d_type_1, Humidity, Measure)
-- sql server, postgreSQL
CREATE VIEW CurrentConfig AS
WITH
q_00 as (
SELECT DEV_MAC
, max(VALID_FROM) as LATEST
FROM DeviceConfig
)
SELECT c.DEV_MAC
c.DEV_CFG_NO
c.DEV_TYP
w.SNS_TYP
s.REA_TYP
FROM DeviceConfig AS c
JOIN q_00 AS q ON q.DEV_MAC = c.DEV_MAC
AND q.LATEST = c.VALID_FROM
JOIN DeviceTypeSensorType AS w ON w.DEV_TYP = c.DEV_TYP
JOIN SensorType AS s ON s.SNS_TYP = w.SNS_TYP
Приложение теперь может использовать это представление для обогащения данных потокового датчика - путем сопоставления (DEV_MAC, SNS_TYP) - и создания набора наборов для каждого устройства чтение.
{(DEV_MAC, DEV_CFG_NO, DEV_TYP, SNS_TYP, REA_TYP, SNS_VALUE, REA_TYP, READ_DTM)}
Теперь эти кортежи можно вставлять в таблицы чтения.
[p 7] Устройство DEV_MAC в конфигурации устройства DEV_CFG_NO отправленные данные во время чтения READ_DTM; этому чтению был присвоен номер READING_ID.
Reading {READING_ID, DEV_MAC, DEV_CFG_NO, READ_DTM} -- p 7
PK {READING_ID}
AK {DEV_MAC, DEV_CFG_NO, READ_DTM}
FK1 {DEV_MAC, DEV_CFG_NO} REFERENCES DeviceConfig
Подтипы теперь различаются по типу чтения (REA_TYP). Добавлены некоторые дополнительные элементы управления для проверки типов для SNS_TYP для подтипов.
[p 7.1] Показание измерения READING_ID для типа датчика SNS_TYP равно SNS_VALUE.
Reading_Meas {READING_ID, SNS_TYP, SNS_VALUE::Numeric} -- p 7.1
PK {READING_ID, SNS_TYP}
FK {READING_ID} REFERENCES Reading
CHECK SNS_TYP in (Temperature, Humidity, Battery)
[стр. 7.2] Показания переключателя READING_ID для типа датчика SNS_TYP равно SNS_VALUE.
Reading_Sw {READING_ID, SNS_TYP, SNS_VALUE::Boolean} -- p 7.2
PK {READING_ID, SNS_TYP}
FK {READING_ID} REFERENCES Reading
CHECK SNS_TYP in (Door)
Примечание:
All attributes (columns) NOT NULL
[p x] = predicate x
(c x.y) = constraint x.y
PK = Primary Key
AK = Alternate Key (Unique)
SK = Proper Superkey (Unique)
FK = Foreign Key