Database “supertable” vs più tabelle vs tavolo generici

Question

Sto cercando di decidere su una progettazione di database. Più precisamente, si tratta di una sotto-parte di un disegno più grande. Fondamentalmente, ci sono "sedi" - ogni postazione può avere qualsiasi numero di sensori ad esso associati, e può avere un logger (ma solo 1)

.

Ho letture del sensore e ho letture logger, ciascuna abbastanza diverso credo per giustificare tabelle separate.

Se una lettura del sensore va fuori scala, viene generato un avviso. Mentre un sensore di lettura soggiorni fuori campo, continuano a essere associati a tale avviso così si finisce con 1 avviso contenente molte letture che mi permette di rappresentare graficamente l'alert in seguito in modo da poter individuare le tendenze, ecc.

Lo stesso con letture logger.

Qui sono i miei 3 idee finora per la memorizzazione di questi dati:

Opzione 1:

Location [Table]
- Id [PK]
- Name
- HasLogger

LiveSensor [Table]
- LocationId [FK]
- Id [PK]

LiveSensorReading [Table]
- Id [PK]
- SensorId [FK]
- Value

LiveSensorAlert [Table]
- Id [PK]
- SensorReadingId [FK] (may not be needed - enforces need to always have at least 1 reading)

LiveSensorAlertCorrectiveAction [Table]
- LiveSensorAlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]

LiveSensorAlertAcknowledgement [Table]
- LiveSensorAlertId [FK]
- ByUserID [FK]

LiveSensorAlertReading [Table]
- SensorAlertId [FK]
- SensorReadingId [FK]

LoggerReading [Table]
- LocationId [FK]
- Value

LoggerAlert [Table]
- Id [PK]
- LoggerReadingId [FK] (may not be needed - enforces need to always have at least 1 reading)

LoggerAlertReading [Table]
- LoggerAlertId [FK]
- LoggerReadingId [FK]

LoggerAlertCorrectiveAction [Table]
- LoggerAlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]

LoggerAlertAcknowledgement [Table]
 - LoggerAlertId [FK]
 - ByUserID [FK]

• Problema: Un sacco di tavoli ripetute (fa che realmente importa se ??)

Opzione 2:

Location [Table]
- Id
- Name
- HasLogger

Sensor [Table]
- Id [PK]
- LocationId [FK]

SensorReading [Table]
- Id [PK]
- SensorId [FK]
- Value

LoggerReading
- LocationId [FK]
- Value

Alert [Table]
- Id [PK]

AlertCorrectiveAction [Table]
- AlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]

AlertAcknowledgement [Table]
- AlertId [FK]
- ByUserId [FK]

SensorAlertReading
- AlertId [FK]
- SensorReadingId [FK]

LoggerAlertReading
 - AlertId [FK]
 - LoggerReadingId [FK]

• Problema: non rispettare "almeno 1 la lettura di ogni avviso" regola.
• Problema: Permette più di un tipo di a leggere per fare riferimento allo stesso avviso.

Opzione 3:

Location [Table]
- Id
- Name
- HasLogger

Sensor [Table]
- Id [PK]
- LocationId [FK]

SensorReading [Table]
- Id [PK]
- SensorId [FK]
- Value

LoggerReading
- LocationId [FK]
- Value

Alert [Table] "super table"
- Id [PK]

LoggerAlert [Table]
- AlertId [PK, FK]
- LoggerReadingId [FK]

SensorAlert [Table]
- AlertId [PK, FK]
- SensorReadingId [FK]

AlertCorrectiveAction [Table]
- AlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]

AlertAcknowledgement [Table]
- AlertId [FK]
- ByUserId [FK]

SensorAlertReading [Table]
- SensorAlertId [FK]
- SensorReadingId [FK]

LoggerAlertReading [Table]
 - LoggerAlertId [FK]
 - LoggerReadingId [FK]

• Problema: Niente arresto di un LoggerAlert e SensorAlert referenziare stesso Alert (stesso problema come opzione 2).
• Problema: banca dati offusca (non è super-tabella di più di un concetto OO? UN banca dati è destinata ad essere puramente relazionale non è vero?)

Credo finora sto opzione 1 preferendo perché sembra proprio così pulito e l'intento è chiaro (spero!), Anche se mi sto ripetendo in modo efficace le tabelle.

L'unico piccolo problema che ho pensato è che le letture per i diversi sensori potrebbero ancora diventare associato a quello di allarme.

mi chiedo che cosa opinioni popoli sono sulle opzioni di cui sopra. Ho visto l'utilizzo di "tavoli super" raccomandati tranquilla spesso, ma per qualche motivo solo non mi sembra giusto - ci si sente quasi come un po 'di hack soprattutto quando vedo i metodi per cercare di assicurare l'integrità dei dati. Sembra più simile nei confronti di programmazione OO di design relazionale.

Grazie.

Modifica Qualche ulteriore informazioni per aiutare a rispondere ad alcune delle domande qui sotto:

La maggior parte del tempo il database viene manipolata solo attraverso un application server, se questo fa alcuna differenza.

Gli avvisi in tempo reale e gli avvisi logger sono generalmente trattati allo stesso modo, quindi sono probabilmente andando a che fare con tutti gli avvisi maggior parte del tempo, piuttosto che fare con avvisi logger e avvisi in tempo reale in modi diversi.

Lo strumento deve equamente colonne specifiche che vivono nella tabella posizione. Dal momento che la posizione e logger sarebbe una mappatura 1 a 1 ho deciso contro avere un tavolo registratore separato e finora sembra di multa elaborato e tenni semplice. colonne Esempio:. LoggerRFID (int), LoggerUpperLimit (float), LoggerLowerLimit (float), ecc Si potrebbe quasi sostengono che un logger è un sensore, ma sono andato su questa strada e non sono andate troppo bene

Mi sembra quasi di accettare rendendo gli allarmi generici, ma come una delle risposte detto che sto cercando di essere molto sicuro di questo in modo da continuare la ricerca per tutto il tempo che posso prima di scegliere un percorso specifico.

Answer 1

Alcuni pensieri (idee e opinioni, non risponde) su questo:

Il modello "supertable" (tipo / sottotipo) è avvincente, ma può essere difficile da implementare e supportare. Un paio di trucchi:

ALERT
  AlertId    PK 1/2
  AlertType  PK 2/2  Check constraint (1 or 2, or better L or S)

... cioè, chiave primaria composta, dove "tipo" deve essere sempre L) og o S) Ensor.

LOGALERT
  LogAlertId  PK 1/2  FK 1/2
  AlertType   PK 2/2  FK 2/2

(and again for SENSORALERT)

... che è, chiave primaria stesso composto, e la chiave esterna è in entrambe le colonne. Fatto questo modo, vi può essere solo una tabella sottotipo per un dato tipo tabella, e la tabella superiore mostra chiaramente che è coinvolto sottotipo. Non c'è modo di far rispettare l'esistenza di una riga nella tabella sottotipo, in modo da impostare il backup dei dati con attenzione. E gran parte della complessità interrogazione possono essere affrontati (coperto?) Utilizzando le visualizzazioni.

Il rovescio della medaglia è, è complessa, di confusione per coloro che non (ancora) familiarità con essa, e richiederà un sostegno supplementare e fatica. La vera domanda è: ne vale la pena?

• Con quale frequenza si deve trattare con tutti avvisi, non solo Login oppure solo sensore? Se la maggior parte delle volte si hanno solo a che fare con uno o l'altro, non è probabilmente vale la pena.
• Quanto log- o Sensor-specifici dettagli avete a che fare con? Al di là delle eventi reali relativi ad un allarme individuale, quanto simile in entrambi i tipi sono la miriade di attributi (dettagli in colonne) sarete monitoraggio? Se utenti, riconoscimenti e le azioni correttive sono (sufficientemente) identicial, è possibile renderli attributi (colonne) di allerta, ma se poi non si deve renderli atttributes del sottotipo appropriata, e si perde il vantaggio di consolidamento del supertipo.
• E dovete farlo corretto ora, durante la fase di progettazione. La ricerca, fare domande, lo sguardo in sfere di cristallo (cioè riflettere su ciò che potrebbe accadere in futuro per in corso le assunzioni di tutti invalidate), perché se si sbaglia ora voi e ai vostri successori potrebbe essere necessario convivere con essa per sempre .

Answer 2

Si potrebbe aggiungere una colonna ObjectType alle tabelle a specchio in opzione uno, e fornire i valori di entrambi Sensore o Logger. La struttura del database sarebbe quindi simile a questa:

Location [Table]
- Id
- Name
- HasLogger

ObjectType [Table]
- Id [PK]
- Name -- either Sensor or Logger
- Description

Object [Table]
- Id [PK]
- LocationId [FK]
- ObjectTypeId [FK]

Reading [Table]
- Id [PK]
- ObjectId [FK]
- Value

ObjectReading
- ObjectId [FK]
- ReadingId [FK]

Alert [Table]
- Id [PK]
- ReadingId [FK]

AlertCorrectiveAction [Table]
- AlertId [FK]
- CorrectiveActionId [FK]
- ByUserId [FK]

AlertAcknowledgement [Table]
- AlertId [FK]
- ByUserId [FK]

Questo design fa offuscare la finalità alla base del database di un po ', in gran parte perché non riuscivo a pensare a una parola migliore per descrivere "sensore o logger" che "oggetto" - se c'è qualche termine specifico che potrebbe descrivere collettivamente qualcosa attaccato in un luogo, che sarebbe certamente facilitare la comprensione del database.

Si potrebbe anche rimuovere la colonna Id da ObjectType e fare il nome di una chiave primaria, se non siete particolarmente schizzinosi sugli ID non interi nelle tabelle. Ho avuto brutte esperienze con tabelle come ObjectType dove la chiave primaria non è un numero intero, però, così ho quasi sempre uso uno.

Sono anche d'accordo con la valutazione di KM superiore a quella di ogni tabella ID chiave primaria deve essere denominato qualcosa di più di "Id".

Answer 3

Penso che questa questione è stata risolta nel tuo altra domanda , con il pieno di dati Modello; altrimenti (se c'è qualcosa di eccezionale), si prega di inviare una modifica a questa domanda.

Se siete interessati alla Supertype-sottotipo struttura relazionale, in senso generale, questa domanda possono essere di interesse per voi.

mi permetto di suggerire di chiudere questa domanda.