disegno migliore database per un "sistema di sensori"

Question

sto facendo un lavoro scolastico e ..

devo fare un sistema del veicolo inseguitore. Ho pensato a questi tre progetti. Cosa ne pensi?

miei schemi di database

Opinioni?

Answer 1

• Se si misura sempre e memorizzare tutti i parametri all'interno di una sessione di misura, poi per la progettazione 1.

  Lo spostamento degli attributi in tabelle separate ha senso solo se gli attributi sono raramente memorizzati e/o raramente necessari.

• Se si dispone di sensori separati per posizione e temperatura, passare al modello 3.

  Questo è più probabile, in quanto la posizione viene misurata da un GPS tracker e livello di temperatura e dell'olio sono misurate dai sensori del veicolo, che sono dispositivi separati e le misure sono effettuate in tempi diversi.

  Potrebbe anche essere necessario aggiungere una tabella separata per ciascun sensore (ad esempio se diversi sensori misurano gas e temperatura in momenti diversi, quindi creare due tabelle per essi).

• Spostamento liquid in una tabella separata (come nel disegno 2) senso se l'elenco dei liquidi che utilizzi non è nota in fase di progettazione (cioè alcuni terzo liquido, come l'idrogeno o elio-3 o qualunque cosa inventerà sarà utilizzato dai veicoli e sarà necessario rintracciarlo senza ridisegnare il database).

  Questo non è uno scenario probabile, ovviamente.

Answer 2

se stai leggendo dai sensori allo stesso tempo il secondo disegno mi sembra eccessivo. Avrebbe senso tenere separate le informazioni solo se leggessi quelle informazioni in momenti diversi.

Suggerirei il primo progetto.

Answer 3

L'applicazione deve affrontare due tipi di cose

• Sensori = quale tipo, dove nel motore, e anche parametri come frequenza di polling e tale ..
• Letture = registrazioni temporizzate individuali da uno (o più?) Sensori.

Ci sono alcune cose a cui pensare:
- Come possiamo trovare il modo di astrazione del concetto sensore? L'idea è che potremmo quindi identificare e gestire le istanze dei sensori attraverso le loro proprietà, piuttosto che dover sapere dove si trovano nel database.
-È meglio mantenere tutte le misure per un determinato timestamp in un singolo record "Read" o per avere un record per sensore, per lettura, anche se diverse misure sono disponibili in serie.

Una risposta rapida all'ultima domanda è che l'evento di lettura singola per record sembra più flessibile; saremo in grado di gestire, nello stesso modo, entrambi i gruppi di misure che vengono sistematicamente interrogati contemporaneamente e altre misure che sono asin- cronde al primo. Anche se proprio adesso tutte le misurazioni arrivano in una sola volta, la possibilità di aggiungere facilmente i sensori senza modificare lo schema del databasee per gestirli in modo simile, è allettante.

Forse il seguente disegno sarebbe più vicino a quello che vi serve:

 
tblSensors 
    SensorId PK 
    Name  clear text description of the sensor ("Oil Temp.") 
    LongName longer description ("Oil Temperarure, Sensor TH-B14 in crankshaft") 
    SensorType enumeration ("TEMP", "PRESSURE", "VELOCITY"...) 
    SensorSubType enumeration ("OIL", "AIR"...) 
    Location enumeration ("ENGINE", "GENERAL", "EXHAUST"...) 
    OtherCrit other crietrias which may be used to identify/seach for the sensor. 


tblReads 
    Readid PK 
    DateTime 
    SensorId FK to tblSensors 
    Measurment INTeger value 
    Measurement2 optional extra meassurement (maybe to handle say, all 
        of a GPS sensor read as one "value" 
    Measurement3 ... also may have multiple columns for different types of 
       variables (real-valued ?) 

In aggiunta a quanto sopra si avrebbe un paio di tavoli in cui sono definiti i "enumerazioni" per i vari tipi di sensori, e il legame con la logica dell'applicazione sarebbe attraverso le "chiavi" mnemoniche di queste enumerazioni. per esempio.

SELECT S.Name, R.DateTime, R.Measurement 
FROM tblReads R 
JOIN tblSensors S ON S.SensorId = R.SensorID 
WHERE S.SensorType IN ('Temp', 'Pres') 
    AND S.Location = "ENG" 
    AND R.DateTime > '04/07/2009' 
ORDER BY R.DateTime 

Questo non impedirebbe di chiamare anche i sensori per la loro identificazione, e al gruppo si legge sulla stessa linea di risultati. per esempio.

SELECT R1.DateTime, R1.Measurement AS OilTemp, R2.Measurement AS OilPress, 
     R3.Measurement AS MotorRpms 
FROM tblReads R1 
LEFT OUTER JOIN tblReads R2 ON R1.DateTime = R2.DateTime 
LEFT OUTER JOIN tblReads R3 ON R1.DateTime = R3.DateTime 
WHERE R1.SensorId = 17 
    AND R2.SensorId = 11 
    AND R3.SensorId = 44 
    AND R1.DateTime > '04/07/2009' AND R1.DateTime < '04/08/2009' 
ORDER BY R3.Measurement DESC -- Sorte by Speed, fastest first