Base de datos “supertabla” vs más tablas vs cuadro genérico

Question

Estoy tratando de decidir sobre un diseño de base de datos. Más específicamente, esta es una sub-parte de un diseño más grande. Básicamente, existen "Ubicaciones" - cada lugar puede tener cualquier número de sensores asociados a ella, y puede tener un registrador (pero sólo 1)

.

tengo lecturas de los sensores y tengo lecturas del registrador, cada uno lo suficientemente diferentes como para justificar creo mesas separadas.

Si una lectura del sensor sale del alcance, se genera una alerta. Mientras que una lectura del sensor se queda fuera de rango, ellos siguen siendo asociados con esa alerta por lo que terminan con 1 de alerta que contiene muchas lecturas que me permite representar gráficamente la alerta tarde para que pueda detectar tendencias, etc.

Lo mismo pasa con las lecturas del registrador.

Aquí están mis 3 ideas hasta ahora para almacenar estos datos:

Opción 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 montón de mesas repetidas (hace que realmente importa, aunque ??)

Opción 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: no hace cumplir "al menos 1 lectura por alerta" regla.
• Problema: permite más de un tipo de leer hacer referencia a la misma alerta.

Opción 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: Nada detener una LoggerAlert y SensorAlert Alerta misma referencia (mismo problema como la opción 2).
• Problema: la base de datos ofusca (no es súper mesa de más de un concepto OO? UN base de datos está destinado a ser puramente relacional no es así?)

creo que hasta ahora estoy opción 1 prefering ya que sólo parece tan limpio y la intención es clara (espero!), A pesar de que estoy repitiendo tablas de forma efectiva.

El único problema que acaba de ocurrir es que las lecturas de diferentes sensores todavía podrían llegar a ser asociado con la alarma.

Me pregunto qué son opiniones de la gente sobre las opciones anteriores. He visto el uso de "super tranquila" tablas recomendadas a menudo, pero por alguna razón, simplemente no se siente bien - que casi se siente como un poco de un truco sobre todo cuando veo los métodos para tratar de asegurar la integridad de los datos. Parece más parecido a una programación orientado a objetos de diseño relacional.

Gracias.

EDIT: Algo de información adicional para ayudar a responder algunas de las preguntas a continuación:

La mayoría de las veces la base de datos sólo se manipula a través de un servidor de aplicaciones, si hay alguna diferencia.

Las alertas activas y alertas registrador general se trata de la misma, por lo que probablemente voy a estar tratando con todas las alertas mayor parte del tiempo, en lugar de tratar con alertas logger y alertas en vivo de diferentes maneras.

El registrador tiene justa columnas específicas que viven en la tabla de ubicación. Dado que la ubicación y el registrador serían un mapeo 1 a 1 decidí en contra de tener una mesa registrador independiente y hasta ahora parece que de funcionó bien y mantuvo simple. Ejemplo columnas:. LoggerRFID (int), LoggerUpperLimit (float), LoggerLowerLimit (float), etc. Casi se podría argumentar que un registrador es un sensor, pero fui por ese camino y no salieron demasiado bien

casi puedo aceptar lo que las alertas genéricas, sino como una de las respuestas dicho que estoy tratando de ser muy seguro de esto por lo que la continuación de la investigación por el tiempo que me puedo antes de elegir un camino específico.

Answer 1

Algunos pensamientos (ideas y opiniones, no respuestas) sobre esto:

El modelo "supertabla" (tipo / subtipo) es convincente, pero puede ser difícil de poner en práctica y apoyo. Un par de trucos:

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

... es decir, la clave principal compuesto, donde "tipo" debe ser siempre L) og o S) Ensor.

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

(and again for SENSORALERT)

... es decir, la clave primaria mismo compuesto, y la clave externa es en ambas columnas. Hecho de esta manera, sólo puede haber una mesa para una mesa subtipo determinado tipo, y la tabla de arriba muestra claramente los que está implicado el subtipo. No hay manera de hacer cumplir la existencia de una fila en la tabla de subtipo, por lo que estableció sus datos con cuidado. Y gran parte de la complejidad de consulta pueden ser tratados (cubierta hasta?) Utilizando puntos de vista.

La desventaja es que es compleja, confundiendo a los que (todavía) no familiarizados con él, y requerirá el apoyo y el esfuerzo extra. La verdadera pregunta es, ¿merece la pena?

• ¿Con qué frecuencia debe usted hacer frente a todos alerta, no sólo Log o único sensor? Si la mayoría de las veces sólo tienen que lidiar con uno o el otro, no es probable que vale la pena.
• ¿Cuánto log-o-Sensor específicos detalles es lo que tiene que hacer frente? Más allá de los acontecimientos reales relacionadas con una alerta individual, cómo es similar en ambos tipos son los innumerables atributos (detalles en columnas) se le de seguimiento? Si los usuarios, los agradecimientos y las acciones correctivas son identicial (suficientemente), usted puede hacer que los atributos (columnas) de alerta, pero si no, entonces usted tiene que hacerlos atttributes del subtipo apropiado, y se pierde la ventaja de la consolidación del supertipo.
• Y usted tiene que conseguir que corregir ahora, durante el tiempo de diseño. La investigación, hacer preguntas, la mirada en las bolas de cristal (es decir, reflexionar sobre lo que podría suceder en el futuro al de todos invalidate actuales supuestos), porque si uno se equivoca ahora usted y sus sucesores que tenga que vivir con ella para siempre .

Answer 2

Se podría añadir una columna ObjectType a las tablas de espejo en la opción uno, y proporcionar valores de cualquiera de los sensores o registrador. El diseño de su base de datos sería entonces algo como esto:

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]

Este diseño hace obfuscate el propósito subyacente de la base de datos un poco, en gran parte porque no podía pensar en una mejor palabra para describir "sensor o registrador" que "objeto" - si hay algún término específico que pudiera describir colectivamente algo adjunta en un lugar, que sin duda facilitaría la comprensión de la base de datos.

También puede quitar la columna ID de ObjectType y hacer que el nombre de una clave principal si no está particularmente escrupuloso con los ID no enteros en tablas. He tenido malas experiencias con mesas como ObjectType donde la clave primaria no es un entero, sin embargo, por lo que casi siempre uso uno.

También estoy de acuerdo con la evaluación de kilómetros por encima de esa primaria ID de la llave de cada tabla debe tener asignado un nombre más largo que "Id".

Answer 3

creo que esta pregunta ha sido contestada en su otra pregunta , con el pleno de Datos Modelo; en caso contrario (si hay algo pendiente), por favor, puesto una edición a esta pregunta.

Si está interesado en la Supertype-Subtipo estructura relacional, en un sentido general, esta pregunta pueden ser de su interés.

¿Puedo sugerir que cierre esta pregunta.