Problème de conception de base de données

Je travaille sur une base de données pour un système de surveillance de bâtiment. Cela ressemble un peu à ceci: Il y a un bâtiment. Un bâtiment a plusieurs zones qui peuvent contenir des enregistreurs ou des groupes de capteurs d'alimentation en direct. Un enregistreur a un seul capteur et ses données sont collectées par des combinés qui sont ensuite téléchargés dans le système plus tard.Problème de conception de base de données

Ainsi, par exemple:

Building: 
    + Area1: 
      Cold room 1 (Logger) 
      Cold room 2 (Logger) 
      + Freezer 1 (Live monitoring): 
       Live sensor 1 
       Live sensor 2

Un enregistreur a des lectures qui sont stockés dans la base de données, comme les capteurs de surveillance en direct, et les lectures peuvent générer des alertes. Mon problème est qu'un enregistreur et un capteur de surveillance en direct sont très similaires, mais parce qu'ils existent à différents niveaux de la hiérarchie, je trouve difficile de modéliser d'une manière qui semble agréable. Voici ce que j'ai trouvé jusqu'à présent. Ceci est juste une maquette de jouer avec des idées, beaucoup theres manquant:

http://thejunkroom.co.uk/~marks/db1.png

peu de désordre, je sais ..

Il est dommage qu'il ne peut pas être comme ceci:

Building: 
    + Area1: 
      + Foo 
       Cold room 1 (Logger) 
       Cold room 2 (Logger) 
      + Freezer 1 (Live monitoring): 
       Live sensor 1 
       Live sensor 2

comme il pourrait être plus comme ceci:

http://thejunkroom.co.uk/~marks/db2.png

Mais hélas, ce n'est pas comme ça.

Alors, y a-t-il une meilleure conception pour cela?

J'espère que cela une sorte de sens ..

Merci, Mark.

Source

2010-08-28 Mark

Comment éviter quelque chose comme ça?

seconde structure avec la relation sous-classe ...

Building 
    BuildingId pk 
    BuildingName 
    etc 

Area 
    AreaId  pk 
    AreaName 
    BuildIngId fk -> Building 
    etc 

Location 
    LocationId   pk 
    LocationType (LiveMonitor, Logger, Handprobe) pk 
    LocationName 
    AreaId  fk -> Area 
    etc 

LiveMonitorLocation 
    LocationId pk, fk -> Location 
    LocationType ConstantValue = LiveMonitor fk -> Location  

LoggerLocation 
    LocationId pk, fk -> Location 
    LocationType ConstantValue = Logger fk -> Location  


HandprobeLocation 
    LocationId pk, fk -> Location 
    LocationType ConstantValue = Handprobe fk -> Location  

Logger 
    LoggerId  pk 
    LocationId fk -> LoggerLocation 
    SensorId  fk -> Sensor 

Handprobe 
    HandProbeId pk 
    Locationid fk -> HandprobeLocation 

Sensor 
    SensorId  pk 

LiveMonitorSensors 
    SensorId  pk, fk -> Sensor 
    LocationId pk, fk -> LiveMonitorLocation 

SensorReadings 
    SensorId  pk, fk -> Sensor 
    ReadingUtc pk 
    ReadingValue data

Source

2010-08-28 16:27:08

Merci Charles - une chose, avez-vous dire avoir LoggerId FK-> Logger dans la salle? Une salle n'a pas toujours un enregistreur - plus tard, même si je vois que vous mettez RoomId fk -> Room dans la table Logger, ce qui serait tout ce dont j'ai besoin pour Loggers? – Mark

Il y a un léger problème - cette conception permet à l'emplacement (ou à la pièce comme vous l'appelez) d'avoir un enregistreur * et * le congélateur - ils ne le veulent pas. Devrais-je essayer de limiter cela dans la base de données ou simplement me fier à la logique métier? – Mark

Donc, vous dites que le "lieu" est une propriété à la fois d'un enregistreur et d'un congélateur? plutôt que la façon dont je l'ai modélisé? Je vais refaire le modèle pour refléter cela ... –

Problème de conception de base de données

Répondre

Questions connexes