views:

106

answers:

1

Hi, I'm working on a database design for a building monitoring system. It goes a bit like this: There's a building. A building has multiple areas which can contain loggers or groups of live feed sensors. A logger has a single sensor and it's data is collected by handsets which is then downloaded into the system later.

So for example:

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

A logger has readings that are stored in the database, as do the live monitoring sensors, and the readings can generate alerts.

My problem is that a logger and a live monitoring sensor are very similar, but because they exist at different levels of the hierachy I'm finding it difficult to model in a way that seems nice. Here is what I have come up with so far. This is just a mock up to play with ideas, theres plenty missing:

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

Bit of mess I know..

It's a shame it can't be like this:

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

As then it could be more like this:

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

But alas it isn't this way.

So, is there a better design for this?

I hope this makes some kind of sense..

Thanks, Mark.

+3  A: 

How abnout something like this?

Second structure with subclass relationship...

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
Charles Bretana
Thanks Charles - one thing, did you mean to have LoggerId fk-> Logger in Room? A Room doesn't always have a Logger - later on though I see you put RoomId fk -> Room in the Logger table, which would be all I need I think for Loggers?
Mark
There is one slight issue - this design allows the location (or room as you've called it) to have a logger *and* the freezer - they don't want this. Should I try and limit this in the database or just rely on the business logic?
Mark
So you're saying that the "location" is a property of both a logger and a freezer? rather than the way I modeled it? I will redo the model to reflect that...
Charles Bretana
Basically; and this is the company's terminology - you add areas, and then you add locations. At each location you choose an activity - logging, live monitoring or handprobing (though don't worry about the latter).I advocated they just make it so if the customer wants a logger and live monitoring at the same location, they could, but the problem is that their handreader software is not designed to cope with this and they don't want to redo it..So each "thing" added to an area is *exclusively either* a logger-location, a live-monitoring-location, or a handprobe-location..
Mark
Maybe I should just enforce this at the business layer..
Mark
ahhh then what you have is a "subclass" type of relationship... You can enforce this at db level... I'll add a second tabl;e structure to show you
Charles Bretana
Bare in mind.. freezer should not be a table; when I put "freezer" in my original tree, that was just the name of the item I'd added. Freezer is an example of a live monitoring location.
Mark
+1 I've never seen this trick for enforcing subclass-specific relationships. @Charles Bretana, can you recommend a good reference on this?
grossvogel
Thanks Charles, Interesting, I'm going to go play with that for a while. I have read comments about avoiding object oriented concepts in a standard database system (i.e. there should be no IS-A's), but that's not to say it isn't the answer in this case.
Mark
@grossvogel, No unfortunately, I don't have a reference for this. I picked this up some time ago and frankly do not remember where I got it from ...
Charles Bretana