Jusqu'où aller avec les contraintes de base de données?

Question

Cette question est en relation avec another question I asked. Dans mon autre question, je demande aux gens des opinions sur 3 différentes façons de construire une base de données. La façon plus propre que je peux penser à le faire sans (presque) répéter des tables et des notions étranges tels que « super tables » est l'option 2:

Location [Table] 
- Id 
- Name 
- HasLogger 
- LoggerRFID 
- LoggerUpperLimit 
- LoggerLowerLimit 

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

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

LoggerReading [Table] 
- LocationId [FK] 
- Value 

Alert [Table] 
- Id [PK] 

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

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

SensorAlertReading [Table] 
- AlertId [FK] 
- SensorReadingId [FK] 

LoggerAlertReading [Table] 
- AlertId [FK] 
- LoggerReadingId [FK] 

Maintenant, le problème avec cette option est qu'il permet des lectures de capteurs multiples et plusieurs emplacements à "lier" à une seule alerte.

développiez pourquoi est-ce un problème, je vais vous expliquer comment le système fonctionne:

Un emplacement peut contenir de nombreux « capteurs en direct », mais seulement 1 enregistreur. Pour cette raison, j'ai mis les attributs du consignateur dans la table de localisation (il s'agissait d'une relation de 1 à 1). Un enregistreur collecte les mesures jusqu'à ce qu'elles soient collectées ultérieurement, les capteurs en direct communiquent immédiatement les données via un réseau et possèdent des attributs supplémentaires, tels que les esclaves réseau ayant des attributs d'adresse réseau, ce qui est assez différent des enregistreurs. ne fonctionne pas bien).

Lorsqu'un capteur ou un enregistreur est hors de portée (indiqué par la lecture), le système génère une alerte. L'alerte concerne uniquement ce capteur et est considérée comme active jusqu'à ce que la lecture de ce capteur (ou enregistreur) indique qu'il est de nouveau dans la plage. Jusqu'à ce moment-là, les relevés qui éloignent le capteur sont «liés» à cette même alerte. Comme vous pouvez le voir, une seule alerte ne devrait vraiment avoir que des lectures pour le même capteur qui y est lié, mais ma conception ci-dessus permet d'associer une lecture différente de différents capteurs et enregistreurs à la même alerte - devrais-je être dérangé? que je n'ai pas contraint cela en quelque sorte? L'autre problème est qu'il permet aux alertes d'exister sans aucune lecture.

D'où ma question; Jusqu'à quel point faut-il aller avec des contraintes ou plier un design pour s'adapter à ces contraintes? J'aime la conception ci-dessus parce que c'est simple - les alertes peuvent avoir des lectures de capteur et des lectures d'enregistreur, donc c'est une relation simple pour les relier.

Je ne peux pas m'empêcher de penser qu'il me manque aussi un truc - y a-t-il une bien meilleure façon de faire ce design? J'ai tourné en rond avec lui depuis des lustres maintenant et il semble toujours y avoir un compromis (à moins que je répète tous les tableaux d'alerte pour les différents types de lecture).

Merci.

Answer 1

est-ce que je devrais être dérangé que je n'ai pas contraint cela en quelque sorte?

Oui.

Vous avez fait deux erreurs de base.

1. Coller les touches Id sur tout ce qui bouge.

   Cela a entravé votre capacité à modéliser les données, comme données (pas comme des lignes qui n'ont aucune signification, mais avec une unicité artificiellement imposée), et exposer les identifiants; et les dépendances (par exemple, un capteur dépend d'un emplacement). Vous modélisez des feuilles de calcul, avec des Row_Ids prédéfinis, contenant des données. Vous devez normaliser les données, en tant que données.

   Cela a entraîné le problème que vous avez identifié, mais il existe également d'autres problèmes.

   Si vous modélisez les données, les identificateurs seront effacés, et les contraintes Index et FK l'empêcheront. Quelles sont les données indépendantes? quelles données appartiennent (dépendent) de quelles autres données; quelles données fait quoi à d'autres données, et la base de ces actions. Puis (les problèmes majeurs ayant été résolus) il ne vous reste que des contraintes mineures pour adresser les zones mineures.

2. Sinon, vous êtes coincé avec ajoutant contraintes dans tous les sens pour essayer et obtenir ce que vous voulez, mais jamais tout à fait pour y arriver. Vous savez que vous en avez besoin, alors vous les cherchez.

Mauvais endroit. Nous devons sauvegarder jusqu'à (1).

J'ai répondu à autre question, et inclus un ▶Sensor Data Model◀. Cela ne répond pas aux lacunes que vous identifiez ici. Cependant, je viens de voir cette question, je vais mettre à jour le DM demain et inclure ces tableaux et colonnes.

▶Link to IDEF1X Notation◀ pour toute personne ne connaissant pas la norme pour la modélisation de bases de données relationnelles.

Questions

1. On dirait que vous avez besoin d'une table de référence pour les capteurs, l'élément de tablette, de tenir UpperLimit et LowerLimit; plutôt que de le répéter pour chaque emplacement. Ou sont-ils définis, localisés, pour chaque emplacement. Pensez à ce que l'enregistreur en cours de détection ne soit pas zéro. Pourquoi les capteurs n'ont-ils pas de RFID?

2. A chaque Location, est le Logger en option, est-il 1 :: 0-1?,

Answer 2

Pourquoi ne pas avoir:

Alert [Table] 
- Id [PK] 
- SensorReadingId [FK] 
- LoggerReadingId [FK] 

Et puis vous remplissez soit le SensorReadingId ou LoggerReadingId. Je suppose que votre structure est simplifiée, mais souvent une table avec rien d'autre qu'un PK est redondant.